Open Stack

On Mon, Nov 17, 2014 at 8:51 AM, Doug Hellmann <doug at doughellmann.com>
wrote:

>
> On Nov 17, 2014, at 6:16 AM, Sean Dague <sean at dague.net> wrote:
>
> > On 11/16/2014 11:23 AM, Doug Hellmann wrote:
> >>
> >> On Nov 16, 2014, at 9:54 AM, Jeremy Stanley <fungi at yuggoth.org> 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
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141119/f0763933/attachment.html>