Open Stack

On 07/29/2012 07:47 PM, Monty Taylor wrote:
> Hey!
> 
> This might be fairly tricky to fix properly given the design of the
> devstack gate. I could be wrong, it might not be terrible now that we
> can release new client lib versions to PyPI more quickly. The devstack
> gate explicitly tests proposed change to trunk of one project against
> tip of trunk across all the other projects. That's great for the dev
> purpose, and can solidify through sequencing during the
> milestone-proposed period, but if we have people with standalone horizon
> installations that are tracking trunk more closely, we might need to do
> some more thinking.

Ok. jeblair and I chatted about this some last night in prep, and it
might not be as tricky as I was thinking. In fact, we're already doing
some testing that you could take advantage of to prevent the kind of
breakage you're talking about, and a few things that are new enough that
we haven't really taken advantage of them yet. Let me 'splain:

The devstack gate works as I mentioned above, and will test you against
trunk of other branches. That's important, because that's how we ensure
that everything works together as we're developing on it.

However, we also do unittest runs, which will test the project in
question using the specific dependency versions the project declares.
Those tests for horizon will use the released versions of all of the
client libs, and would be the automated trap against patches to horizon
that depend on changes that have not yet been released to pypi from
client libs.

Of course, horizon is tricky, being a django app, and unittests
themselves don't always tell the full story. We have just in the last
week added selenium test running (which you know, but for completeness
I'm including here) Those tests also will run with released versions of
libs from pypi.

Also important to note here is that we have just recently gotten
everything hooked up properly so that the client libs can release to
pypi whenever they need to - so while we haven't started taking
advantage of this fully yet, I think as people add functionality to the
client libs, we may not have to wait as long for it to land.

Anyhow - you can also totally just not accept patches to horizon that
use things that aren't in released versions via code review - but if
it's helpful, we are running a set of tests against horizon and the
declared/released depends, so if you can figure out some sensible tests
to add to unit or selenium tests that would trip this, they will
definitely get run.

We'll still be there at the CI meeting of course, but I wanted to set
the stage a little bit so that we didn't have to cover all that in IRC.


> Could I request that you drop by the CI meeting on Tuesday so we can
> chat about it interactively? I think this is important and that we
> should do everything we can to get this right.
> 
> Monty
> 
> On 07/29/2012 06:34 PM, Gabriel Hurley wrote:
>> Public bug reported:
>>
>> We patched this bug: https://bugs.launchpad.net/horizon/+bug/1027210
>>
>> However, that fix worked for devstack and broke stand-alone
>> installations of horizon because devstack pulled the clients from Github
>> while Horizon's requirements file pulls them from PyPI. This is no good.
>>
>> Now anytime you try to list out images from glance (except when using
>> devstack) you get this error:
>>
>> list() got an unexpected keyword argument 'page_size'
>>
>> We need to reconcile devstack with Horizon, and in the future Horizon
>> will *only* accept changes that work with *released* client versions.
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>