<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/19/2014 08:55 PM, Brant Knudson
wrote:<br>
</div>
<blockquote
cite="mid:CAHjeE=Qaa5CQL4XmcffKEKMjJzm7498qW0wKVDst56PvpHuHRg@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Nov 17, 2014 at 8:51 AM, Doug
Hellmann <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb">
<div class="h5"><br>
On Nov 17, 2014, at 6:16 AM, Sean Dague <<a
moz-do-not-send="true" href="mailto:sean@dague.net">sean@dague.net</a>>
wrote:<br>
<br>
> On 11/16/2014 11:23 AM, Doug Hellmann wrote:<br>
>><br>
>> On Nov 16, 2014, at 9:54 AM, Jeremy Stanley
<<a moz-do-not-send="true"
href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>>
wrote:<br>
>><br>
>>> On 2014-11-16 09:06:02 -0500 (-0500),
Doug Hellmann wrote:<br>
>>>> So we would pin the client libraries
used by the servers and<br>
>>>> installed globally, but then install
the more recent client<br>
>>>> libraries in a virtualenv and test
using those versions?<br>
>>><br>
>>> That's what I was thinking anyway, yes.<br>
>>><br>
>>>> I like that.<br>
>>><br>
>>> Honestly I don't, but it sucks less than
the other solutions which<br>
>>> sprang to mind. Hopefully someone will
come along with a more<br>
>>> elegant suggestion... in the meantime I
don't see any obvious<br>
>>> reasons why it wouldn't work.<br>
>><br>
>> Really, it’s a much more accurate test of
what we want. We have, as an artifact of our test
configuration, to install everything on a single box.
But what we’re trying to test is that a user can
install the new clients and talk to an old cloud. We
don’t expect deployers of old clouds to install new
clients — at least we shouldn’t, and by pinning the
requirements we can make that clear. Using the
virtualenv for the new clients gives us separation
between the “user” and “cloud” parts of the test
configuration that we don’t have now.<br>
>><br>
>> Anyway, if we’re prepared to go along with
this I think it’s safe for us to stop using alpha
version numbers for Oslo libraries as a matter of
course. We may still opt to do it in cases where we
aren’t sure of a new API or feature, but we won’t have
to do it for every release.<br>
>><br>
>> Doug<br>
><br>
> I think this idea sounds good on the surface,
though what a working<br>
> system looks like is going to be a little
interesting to make sure you<br>
> are in / out of the venv.<br>
><br>
> I actually think you might find it simpler to
invert this.<br>
><br>
> Create 1 global venv for servers, specify the
venv before launching a<br>
> service.<br>
><br>
> Install all the clients into system level space,
then running nova list<br>
> doesn't require that it is put inside the venv.<br>
><br>
> This should have the same results, but be less
confusing for people<br>
> poking at devstacks manually.<br>
<br>
</div>
</div>
That makes sense. I’m a little worried that it’s a bigger
change to devstack vs. the job that’s testing the clients,
but I’ll defer to you on what’s actually easier since
you’re more familiar with the code. Either way, installing
the servers and the clients into separate packaging spaces
would allow us to pin the clients in the stable branches.<br>
<span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote>
<div><br>
</div>
<div>Another piece is middleware, for example the auth_token
middleware in the keystonemiddleware package.<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Right, so that would get dragged into the system libs for the CLI
pieces at whatever the clients want, and would get additionally
dragged into the global venv for the server based on the server's
needs. I think the only question would be if LIBS_FROM_GIT did both
system and global venv in this case. Perhaps we'd need another
SYSLIBS_FROM_GIT or something to specify the differences.<br>
<br>
Anyway, I think I have most of the ideas in my head, but will write
all this out in a spec before implementing, because there are
probably enough edge cases that we'll want plenty of eyes looking at
it.<br>
<br>
-Sean<br>
<pre class="moz-signature" cols="72">--
Sean Dague
<a class="moz-txt-link-freetext" href="http://dague.net">http://dague.net</a>
</pre>
</body>
</html>