Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
Gabriel Hurley gabriel.hur...@nebula.com writes: Hi Gabriel, As the former Horizon PTL, I have a great respect for the importance of the contributions the distro maintainers/developers make to Horizon and OpenStack as a whole. From how many bugs the distros manage to find, to their diligence in vetting the software that we as Horizon developers provide, to their overall passion for the work they do. It is interesting to me to see the level to which the distros have not had to address this problem before. It shows a significant disconnect between the Node/JavaScript community and the distros as a whole (not surprising since node.js wasn't packaged on many distros until quite recently). I'm not excited to see the OpenStack community leading the charge on resolving packaging issues that ought to be settled between the JS community and the distros. Yet, if we have to in order to move forward I would urge us to reach out to the NPM maintainers, major library maintainers, etc. to try and make decisions that will benefit everyone for years to come. It's also interesting to see how strongly people take sides in this debate... who is OpenStack for? How crucial are the distros? Obviously if you work for RedHat or Canonical the distros are the end-all; OpenStack has to be packaged. Other companies? Opinions vary. Flexibility on this issue is not consistent, as has been pointed out already. I'm sorry if I came across as being hostile towards packagers and distros. I've been running Debian for 15 years and that is because of the work the Debian developers put into making the system work well together at a whole. When it comes to installing software, I only use apt to touch paths outside my home directory. That is to ensure that the integrity of the system isn't compromised. That means that software not yet packaged for Debian has a low change of being installed by me. However, the chances of me installing it improve significantly if I can install it with pip or npm. Simply because this allows me to do a local installation in a home directory -- I know then that I can easily remove the sofware later. -- Martin Geisler http://google.com/+MartinGeisler pgpXzFJPPlcp8.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
1. *make a minor concession to proportionality* - while keeping the focus on consensus, e.g. by adopting the proportional Condorcet variant. It would be interesting to see the analysis again, but in the past this proved to not make much difference. For the record, I just ran the ballots in CIVS proportional mode and obtained the same set of winners: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_88cae988dff29be6 Thanks for doing this Thierry, Not surprising that it made no difference to the outcome this time, given the smaller number of seats contested and the gap between the first 6 and the trailing pack. IIRC the only previous election where your analysis showed the proportional variant would have any impact was the Oct 2013 contest for 11 seats, where the margins were tighter in the lower preferences. So in the absence of switching to simultaneous terms, adopting the proportional variant of Condorcet is probably not worth the extra conceptual complexity for the interested voter to digest. Of course, we could just throw in the towel and cede the community leadership to a deck of playing cards ;) Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
It's certainly not a fun thing to do (trying to guide a community of disjoint folks) and it likely comes with little recognition when successful, but IMHO we surely need more of this active technical leadership vs. blessing of projects; of course the boundary between being a engaging leadership and one that is perceived as trying to dictate technical goals for projects must be approached carefully (and with thoughtfulness) to avoid creating more problems than solutions... That's a good point Josh, TBH I'm not entirely sure if the likely result of the proposed big tent / small core duality would be more or less active technical leadership, given the absence of carrots and sticks. Certainly, I couldn't foresee anything like the Juno gap analysis exercise happening under that structure, at least not for any of the projects outside the ring-zero laager. I suspect that example-based nudges[1] on common concerns would be the practical alternative (hey, this is what we've done to address issue X, you might want to try that approach also ...) Cheers, Eoghan [1] http://en.wikipedia.org/wiki/Nudge_theory ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] testtools 1.2.0 release breaks the world
Testtools 1.2.0 release apparently broke subunit.run discover --list which breaks the way that tempest calls the test chain. No tempest runs have passed since it's release. https://review.openstack.org/#/c/134705/ is a requirements pin, though I think because of grenade this is actually going to have to be laddered up from icehouse = juno = master. https://review.openstack.org/#/q/I2f8737b44c703c3094d6bbb6580993f86a571934,n,z It's probably half a day babysitting getting all the pins in place to make the world work again. I'm offline from here on out for the weekend, but I'll put a +2/+A on all of these so if someone wants to recheck them in the right order to land them, they can get things fixed. Also... lets try not to release libraries on Fridays before disappearing for the weekend... please. Pretty please. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
Sean, I can baby sit these 3 thanks, dims On Sat, Nov 15, 2014 at 9:25 AM, Sean Dague s...@dague.net wrote: Testtools 1.2.0 release apparently broke subunit.run discover --list which breaks the way that tempest calls the test chain. No tempest runs have passed since it's release. https://review.openstack.org/#/c/134705/ is a requirements pin, though I think because of grenade this is actually going to have to be laddered up from icehouse = juno = master. https://review.openstack.org/#/q/I2f8737b44c703c3094d6bbb6580993f86a571934,n,z It's probably half a day babysitting getting all the pins in place to make the world work again. I'm offline from here on out for the weekend, but I'll put a +2/+A on all of these so if someone wants to recheck them in the right order to land them, they can get things fixed. Also... lets try not to release libraries on Fridays before disappearing for the weekend... please. Pretty please. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] A more dynamic wiki, introducing Categories
On 11/14/2014 09:11 PM, Jeremy Stanley wrote: Categories emerge automatically as you tag pages into them. No separate category creation step is required. True although incomplete. Categories are just pages, like almost anything in mediawiki, so if you add text [[Category: New_Category]] in a page, you're one step closer to creating a new category. To complete the step, you need to actually create the New_Category page, going to http://wiki.openstack.org/wiki/Category:New_Category and follow the steps to create a new category. To nest categories you can add a category page to a 'parent' category tagging it with [[Category: Parent_Category]]. For example, see the Category:Programs page, is itself tagged as [[Category:Home]] so that the page https://wiki.openstack.org/wiki/Category:Home shows the categories as a navigable tree. If you don't create the New_Category page, it will end up in the 'wantedCategories' special page: https://wiki.openstack.org/wiki/Special:WantedCategories Convoluted? Yes, I agree but it is what it is. Probably it's better though because if you have too many categories it's like having none. I would suggest to discuss widely the taxonomy before adding/removing items. Cheers, stef ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 2014-11-15 09:25:54 -0500 (-0500), Sean Dague wrote: Testtools 1.2.0 release apparently broke subunit.run discover --list [...] Also... lets try not to release libraries on Fridays before disappearing for the weekend... please. Pretty please. Also reported upstream as https://github.com/testing-cabal/testtools/issues/121 in case any of the cabal stuck around for the weekend to keep an eye on things. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] A more dynamic wiki, introducing Categories
On 2014-11-15 16:37:50 +0100 (+0100), Stefano Maffulli wrote: [...] If you don't create the New_Category page, it will end up in the 'wantedCategories' special page: https://wiki.openstack.org/wiki/Special:WantedCategories [...] Oh, neat! This is a new feature. In older* versions it just populated the categorized articles list at the category page URL but was otherwise undecorated until you added content. [*] no idea how long ago that was since I've been using MW for more than a decade and haven't set up new categories for quite some years -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 15 November 2014 14:25, Sean Dague s...@dague.net wrote: Testtools 1.2.0 release apparently broke subunit.run discover --list which breaks the way that tempest calls the test chain. No tempest runs have passed since it's release. https://review.openstack.org/#/c/134705/ is a requirements pin, though I think because of grenade this is actually going to have to be laddered up from icehouse = juno = master. https://review.openstack.org/#/q/I2f8737b44c703c3094d6bbb6580993f86a571934,n,z It's probably half a day babysitting getting all the pins in place to make the world work again. I'm offline from here on out for the weekend, but I'll put a +2/+A on all of these so if someone wants to recheck them in the right order to land them, they can get things fixed. Also... lets try not to release libraries on Fridays before disappearing for the weekend... please. Pretty please. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev This change has landed in stable/icehouse but... stable/juno is currently blocked by oslo.messaging Master which introduces oslo.middleware, which is not part of stable/juno. I have added pinning to stable/juno global-requirements via https://review.openstack.org/#/c/134727/ This should unblock stable/juno, allowing this to progress. Please be reviewing :) -- Kind Regards, Dave Walker ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
It probably needs to be backed out of stable/icehouse. The issue is that we were installing unittest2 via distro packages *and* testtools new dependency on unittest2 did not express a minimum version. We're just about to issue 1.2.1 which will have such a minimum version. And for the record, this was released on saturday, not friday :). -Rob On 16 November 2014 08:38, Dave Walker em...@daviey.com wrote: On 15 November 2014 14:25, Sean Dague s...@dague.net wrote: Testtools 1.2.0 release apparently broke subunit.run discover --list which breaks the way that tempest calls the test chain. No tempest runs have passed since it's release. https://review.openstack.org/#/c/134705/ is a requirements pin, though I think because of grenade this is actually going to have to be laddered up from icehouse = juno = master. https://review.openstack.org/#/q/I2f8737b44c703c3094d6bbb6580993f86a571934,n,z It's probably half a day babysitting getting all the pins in place to make the world work again. I'm offline from here on out for the weekend, but I'll put a +2/+A on all of these so if someone wants to recheck them in the right order to land them, they can get things fixed. Also... lets try not to release libraries on Fridays before disappearing for the weekend... please. Pretty please. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev This change has landed in stable/icehouse but... stable/juno is currently blocked by oslo.messaging Master which introduces oslo.middleware, which is not part of stable/juno. I have added pinning to stable/juno global-requirements via https://review.openstack.org/#/c/134727/ This should unblock stable/juno, allowing this to progress. Please be reviewing :) -- Kind Regards, Dave Walker ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 15 November 2014 19:51, Robert Collins robe...@robertcollins.net wrote: It probably needs to be backed out of stable/icehouse. The issue is that we were installing unittest2 via distro packages *and* testtools new dependency on unittest2 did not express a minimum version. We're just about to issue 1.2.1 which will have such a minimum version. And for the record, this was released on saturday, not friday :). -Rob We've discussed this on IRC, but I fail to see how this is an appropriate fix for stable/* . This would mean introducing new minima to stable branches, which for stable branches is totally inappropriate. This causes the effect of both distros and deployers requiring a higher version which they have not planned for. If we pin oslo.messaging (which is what we started agreeing in Paris), this problems goes away. -- Kind Regards, Dave Walker ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 2014-11-16 08:51:34 +1300 (+1300), Robert Collins wrote: [...] The issue is that we were installing unittest2 via distro packages *and* testtools new dependency on unittest2 did not express a minimum version. [...] BTW, patches to stop installing unittest2 from distro packages in devstack: https://review.openstack.org/#/q/Ib0e27fd,n,z -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 16 November 2014 03:25, Sean Dague s...@dague.net wrote: Testtools 1.2.0 release apparently broke subunit.run discover --list which breaks the way that tempest calls the test chain. No tempest runs have passed since it's release. https://review.openstack.org/#/c/134705/ is a requirements pin, though I think because of grenade this is actually going to have to be laddered up from icehouse = juno = master. https://review.openstack.org/#/q/I2f8737b44c703c3094d6bbb6580993f86a571934,n,z It's probably half a day babysitting getting all the pins in place to make the world work again. I'm offline from here on out for the weekend, but I'll put a +2/+A on all of these so if someone wants to recheck them in the right order to land them, they can get things fixed. Also... lets try not to release libraries on Fridays before disappearing for the weekend... please. Pretty please. So this has tweaked me - I'm going to rant a little here. It wasn't Friday - it was saturday, when I had some time to do personal stuff and instead chose to push forward on a long arc that has been blocking oslo.db changes for a couple months. I released knowing I'd need to be around to follow up, and the very first thing I did when I got up Sunday morning after dealing with nappies etc was to check for fallout. The release was thoroughly tested upstream, and I explicitly tested it with OpenStack trees as well. I didn't disappear for the weekend, and I didn't even disappear straight to bed... and given how well you know me, you know that I rarely do disappear fully *anyway*, and finally - I'm reachable 24x7 if things really need that (but no-one rang me so clearly its not panic button time) - nor did anyone ask any of the other other testing-cabal committers to do an urgent action. And, and this is perhaps the most annoying aspect, noone in OpenStack tried to reproduce this upstream (which is a 4 command test - make a virtualenv, pip install, cd to a tree, perform discovery) and if they had, such a hypothetical person would have seen that the issue *isn't* testtools, its the use of system-site-packages permitting the old (0.5.1 - current is 0.8.0) unittest2 causing the issue. And thats something thats entirely in the OpenStack space to fix - not upstream. So by going 'oh its testtools problem', 8 or so hours when it could have been fixed have passed with noone looking at it. I totally get the omg its broken and that that makes everyone unhappy when it happens. However I don't like the feeling of being accused of irresponsibility when I was still around for some time (just not at 02:58 am when I was first pinged ( sdague lifeless: https://review.openstack.org/#/c/134705/ should you actually be checking in this weekend). I think everyone is aware that releases have some risk, and doing them cavalierly would be bad. But running with stale dependencies isn't going to be part of the test matrix upstream, since the entire project goal is to fold all its learning into upstream: as things move upstream we have to depend on newer releases of those components (via things like unittest2, importlib2, traceback2 etc etc). -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 16 November 2014 09:03, Dave Walker em...@daviey.com wrote: On 15 November 2014 19:51, Robert Collins robe...@robertcollins.net wrote: It probably needs to be backed out of stable/icehouse. The issue is that we were installing unittest2 via distro packages *and* testtools new dependency on unittest2 did not express a minimum version. We're just about to issue 1.2.1 which will have such a minimum version. And for the record, this was released on saturday, not friday :). -Rob We've discussed this on IRC, but I fail to see how this is an appropriate fix for stable/* . This would mean introducing new minima to stable branches, which for stable branches is totally inappropriate. This causes the effect of both distros and deployers requiring a higher version which they have not planned for. If we pin oslo.messaging (which is what we started agreeing in Paris), this problems goes away. Huh? I think you're working a different bug, no? The testtools thing is what I thought this thread was about :) The oslo.messaging/middleware thing is separate but both are happening at the same time on juno/stable. I was only referring to backing out a pin of testtools - which is needed because with single-version-tempest we can't pin any of tempests dependencies in just stable, we have to have the pins be consistent across all versions tested by tempest (with the current install strategy). -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 15 November 2014 20:23, Robert Collins robe...@robertcollins.net wrote: On 16 November 2014 09:03, Dave Walker em...@daviey.com wrote: On 15 November 2014 19:51, Robert Collins robe...@robertcollins.net wrote: It probably needs to be backed out of stable/icehouse. The issue is that we were installing unittest2 via distro packages *and* testtools new dependency on unittest2 did not express a minimum version. We're just about to issue 1.2.1 which will have such a minimum version. And for the record, this was released on saturday, not friday :). -Rob We've discussed this on IRC, but I fail to see how this is an appropriate fix for stable/* . This would mean introducing new minima to stable branches, which for stable branches is totally inappropriate. This causes the effect of both distros and deployers requiring a higher version which they have not planned for. If we pin oslo.messaging (which is what we started agreeing in Paris), this problems goes away. Huh? I think you're working a different bug, no? The testtools thing is what I thought this thread was about :) The oslo.messaging/middleware thing is separate but both are happening at the same time on juno/stable. I was only referring to backing out a pin of testtools - which is needed because with single-version-tempest we can't pin any of tempests dependencies in just stable, we have to have the pins be consistent across all versions tested by tempest (with the current install strategy). -Rob You are right, I accidently folded two issues into 1. However, I do not understand how we can resolve this issue the way you have outlined without introducing a new minimum version on unittest2, which was not previously a requirement on stable/*. This surely has the same effect that I outlined? Thanks -- Kind Regards, Dave Wa;ler ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 16 November 2014 09:38, Dave Walker em...@daviey.com wrote: On 15 November 2014 20:23, Robert Collins robe...@robertcollins.net wrote: On 16 November 2014 09:03, Dave Walker em...@daviey.com wrote: On 15 November 2014 19:51, Robert Collins robe...@robertcollins.net wrote: It probably needs to be backed out of stable/icehouse. The issue is that we were installing unittest2 via distro packages *and* testtools new dependency on unittest2 did not express a minimum version. We're just about to issue 1.2.1 which will have such a minimum version. And for the record, this was released on saturday, not friday :). -Rob We've discussed this on IRC, but I fail to see how this is an appropriate fix for stable/* . This would mean introducing new minima to stable branches, which for stable branches is totally inappropriate. This causes the effect of both distros and deployers requiring a higher version which they have not planned for. If we pin oslo.messaging (which is what we started agreeing in Paris), this problems goes away. Huh? I think you're working a different bug, no? The testtools thing is what I thought this thread was about :) The oslo.messaging/middleware thing is separate but both are happening at the same time on juno/stable. I was only referring to backing out a pin of testtools - which is needed because with single-version-tempest we can't pin any of tempests dependencies in just stable, we have to have the pins be consistent across all versions tested by tempest (with the current install strategy). -Rob You are right, I accidently folded two issues into 1. However, I do not understand how we can resolve this issue the way you have outlined without introducing a new minimum version on unittest2, which was not previously a requirement on stable/*. This surely has the same effect that I outlined? But stable MUST permit new requirements, or tempest cannot change ever, since it must match the versions of the oldest release we're grenading with master tempest. So saying 'stable tests can never change requirements' is a non-starter, unless we change the way we're installing tempest there, and if we do that the unittest stuff is only applicable to tempest and thus irrelevant to the stable branches. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 2014-11-15 20:38:02 + (+), Dave Walker wrote: You are right, I accidently folded two issues into 1. However, I do not understand how we can resolve this issue the way you have outlined without introducing a new minimum version on unittest2, which was not previously a requirement on stable/*. This surely has the same effect that I outlined? You only need a new unittest2 if you're using a new testtools. The argument that we're introducing a newer requirement there is somewhat circular. If you're installing with distro packages of testtools and unittest2 then presumably your distro has pre-selected versions of them which are known to interoperate? -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] updated release instructions
Doug, I can help with oslo library releases this cycle. thanks, dims On Fri, Nov 14, 2014 at 10:23 AM, Doug Hellmann d...@doughellmann.com wrote: Last cycle Thierry put together a tool to make releasing Oslo libraries easier for us. Using the tool will ensure that all of our releases are tracked consistently, but it’s going to mean a few procedural changes for us in launchpad, especially with the way we use milestones. I’ve updated https://wiki.openstack.org/wiki/Oslo/ReleaseProcess with the basic instructions, and I think all of our existing libraries are configured with the relevant series and milestones. Please look over the instructions and let me know if you have questions. I would like to ensure that each library lead (or someone they designate) is able to handle library releases this cycle so I am not a bottleneck for us. Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 15 November 2014 21:22, Jeremy Stanley fu...@yuggoth.org wrote: On 2014-11-15 20:38:02 + (+), Dave Walker wrote: You are right, I accidently folded two issues into 1. However, I do not understand how we can resolve this issue the way you have outlined without introducing a new minimum version on unittest2, which was not previously a requirement on stable/*. This surely has the same effect that I outlined? You only need a new unittest2 if you're using a new testtools. The argument that we're introducing a newer requirement there is somewhat circular. If you're installing with distro packages of testtools and unittest2 then presumably your distro has pre-selected versions of them which are known to interoperate? -- Jeremy Stanley Ah, Good Point. I (wrongly?) assumed we were looking to put a minimum version of unittest2 in requirements. Which would cause this undesired behaviour. However, that doesn't need to be the case. I assume with this approach we WILL put an upperbound on unittest2 in stable/* requirements? If so - my point is mute. Pah. -- Kind Regards, Dave Walker ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world
On 16 November 2014 09:06, Robert Collins robe...@robertcollins.net wrote: On 16 November 2014 03:25, Sean Dague s...@dague.net wrote: Testtools 1.2.0 release apparently broke subunit.run discover --list which breaks the way that tempest calls the test chain. No tempest runs have passed since it's release. ... I think everyone is aware that releases have some risk, and doing them cavalierly would be bad. But running with stale dependencies isn't going to be part of the test matrix upstream, since the entire project goal is to fold all its learning into upstream: as things move upstream we have to depend on newer releases of those components (via things like unittest2, importlib2, traceback2 etc etc). We did find a further issue, which was due to the use of setUpClass in tempest (a thing that testtools has never supported per se - its always been a happy accident that it worked). I've hopefully fixed that in 1.3.0 and we're babysitting tempest now to see. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Solving the client libs stable support dilemma
During the Kilo design summit session on Oslo versioning changes, we mostly resolved to switch to semver without alphas and pin stable branch libs to less than the next nontrivial version number (allowing for backports to fix bugs with subsequent point releases on a stable branch when needed). This however raises a question for other library dependencies, including dependencies on client libraries. Specifically, if we're going to limit the Oslo libraries consumed by stable branches of integrated release servers (bear in mind we already do this in one way by declaring they can't suddenly start requiring new dependencies), then how does that play out when we allow client libraries which are also dependencies of our stable release servers to depend on later versions of (or for that matter additional) Oslo libs? It seems likely we need to apply a similar versioning and branching model across our client libraries to address this, but this raises the end-user/app-dev interoperability concern we discuss from time to time: with a recent enough client library, you should be able to interact with multiple OpenStack deployments made from different integrated releases (or non-releases, continuous deployment, et al). The challenge, then, is to test interactions using our client libraries under development against older stable servers while installing those stable servers using different, older versions of the same client libraries. Perhaps something similar to how devstack+tempest jobs install devstack/server requirements globally on the system but then tempest requirements are installed separately into a virtualenv? -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
