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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp