On Mon, Nov 17, 2014 at 8:51 AM, Doug Hellmann <[email protected]> wrote:
> > On Nov 17, 2014, at 6:16 AM, Sean Dague <[email protected]> wrote: > > > On 11/16/2014 11:23 AM, Doug Hellmann wrote: > >> > >> On Nov 16, 2014, at 9:54 AM, Jeremy Stanley <[email protected]> wrote: > >> > >>> On 2014-11-16 09:06:02 -0500 (-0500), Doug Hellmann wrote: > >>>> So we would pin the client libraries used by the servers and > >>>> installed globally, but then install the more recent client > >>>> libraries in a virtualenv and test using those versions? > >>> > >>> That's what I was thinking anyway, yes. > >>> > >>>> I like that. > >>> > >>> Honestly I don't, but it sucks less than the other solutions which > >>> sprang to mind. Hopefully someone will come along with a more > >>> elegant suggestion... in the meantime I don't see any obvious > >>> reasons why it wouldn't work. > >> > >> 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. > >> > >> 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. > >> > >> Doug > > > > I think this idea sounds good on the surface, though what a working > > system looks like is going to be a little interesting to make sure you > > are in / out of the venv. > > > > I actually think you might find it simpler to invert this. > > > > Create 1 global venv for servers, specify the venv before launching a > > service. > > > > Install all the clients into system level space, then running nova list > > doesn't require that it is put inside the venv. > > > > This should have the same results, but be less confusing for people > > poking at devstacks manually. > > 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. > > Another piece is middleware, for example the auth_token middleware in the keystonemiddleware package. - Brant > Doug > > > > > -Sean > > > > -- > > Sean Dague > > http://dague.net > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
