On Wed, May 27, 2015 at 11:23 AM, Davanum Srinivas <dava...@gmail.com> wrote:
> Joe, > > Given that the code once lived in nova and the team across has spent > quite a bit of time to turn it into a library which at last count was > adopted by 6 projects at least. i'd like to give the team some credit. > Agreed, they have done a great job. I was just pointing out a lot of OpenStack libs don't use semver's 0.x.x clause much. > > openstack/ceilometer/test-requirements.txt:oslo.vmware>=0.11.1 > # Apache-2.0 > openstack/cinder/requirements.txt:oslo.vmware>=0.11.1 > # Apache-2.0 > openstack/congress/requirements.txt:oslo.vmware>=0.11.1 > # Apache-2.0 > openstack/glance/requirements.txt:oslo.vmware>=0.11.1 > # Apache-2.0 > openstack/glance_store/test-requirements.txt:oslo.vmware>=0.11.1 > # Apache-2.0 > openstack/nova/test-requirements.txt:oslo.vmware>=0.11.1,!=0.13.0 > # Apache-2.0 > > Shit happens! the team that works on oslo.vmware overlaps nova too and > others. There were several solutions that came up quickly as well. we > can't just say nothing should ever break or we should not use 0.x.x > then we can never make progress. This is not going to get any better > either with the big tent coming up. All that matters is how quickly we > can recover and move on with our collective sanity intact. Let's work > on that in addition as well. I'd also want to give some more say in > the actual folks who are contributing and working on the code as well > in the specific discussion. > > Anyway, with the global-requirements block of 0.13.0, nova should > unclog and we'll try to get something out soon in 0.13.1 to keep > @haypo's python34 effort going as well. > Thanks! I think it would be good to move to 1.x.x soon to show that the API is stable. But then again we do have a lot of other libraries that are below 0.x.x so maybe we should look at that more holistically. > > +1000 to "release fewer unexpectedly incompatible libraries and > continue working on improving how we handle dependencies in general". > i'd like to hear specific things we can do that we are not doing both > for libraries under our collective care as well as things we use from > the general python community. > For openstack libraries that have a fairly limited number of consumers we can test source of the lib against target unit test suites, in addition to a devstack run. So oslo.vmware would have a job running source oslo.vmware against nova py27 unit tests. As for in general, is cooking up a plan. > thanks, > dims > > On Wed, May 27, 2015 at 1:52 PM, Joe Gordon <joe.gord...@gmail.com> wrote: > > > > > > On Wed, May 27, 2015 at 12:54 AM, Gary Kotton <gkot...@vmware.com> > wrote: > >> > >> Hi, > >> I prefer the patched posted by Sabari. The patch has two changes: > >> > >> It fixes unit tests > >> In the even that an instance spawn fails then it catches an exception to > >> warn the admin that the guestId may be invalid. The only degradation > may be > >> that the warning will no longer be there. I think that the admin can get > >> this information from the logged exception too. > > > > > > > > So this breakage takes us into some strange waters. > > > > oslo.vmware is at version 0.x.x which according to semver [0] means > "Major > > version zero (0.y.z) is for initial development. Anything may change at > any > > time. The public API should not be considered stable." If that is > accurate, > > then nova should not be using oslo.vmware, since we shouldn't use an > > unstable library in production. If we are treating the API as stable then > > semver says we need to rev the major version ("MAJOR version when you > make > > incompatible API changes"). > > > > What I am trying to say is, I don't know how you can say the nova unit > tests > > are 'wrong.' either nova using oslo.vmware is 'wrong' or oslo.vmware > > breaking the API is 'wrong'. > > > > With OpenStack being so large and having so many dependencies (many of > them > > openstack owned), we should focus on making sure we release fewer > > unexpectedly incompatible libraries and continue working on improving > how we > > handle dependencies in general (lifeless has a big arch he is working on > > here AFAIK). So I am not in favor of the nova unit test change as a fix > > here. > > > > > > [0] http://semver.org/ > > > >> > >> Thanks > >> Gary > >> > >> From: Sabari Murugesan <sabari.b...@gmail.com> > >> Reply-To: OpenStack List <openstack-dev@lists.openstack.org> > >> Date: Wednesday, May 27, 2015 at 6:20 AM > >> To: OpenStack List <openstack-dev@lists.openstack.org> > >> Subject: Re: [openstack-dev] oslo.vmware release 0.13.0 (liberty) > >> > >> Matt > >> > >> I posted a patch https://review.openstack.org/#/c/185830/1 to fix the > nova > >> tests and make it compatible with the oslo.vmware 0.13.0 release. I am > fine > >> with the revert and g-r blacklist as oslo.vmware broke the semver but > we can > >> also consider this patch as an option. > >> > >> Thanks > >> Sabari > >> > >> > >> > >> On Tue, May 26, 2015 at 2:53 PM, Davanum Srinivas <dava...@gmail.com> > >> wrote: > >>> > >>> Vipin, Gary, > >>> > >>> Can you please accept the revert or figure out the best way to handle > >>> this? > >>> > >>> thanks, > >>> dims > >>> > >>> On Tue, May 26, 2015 at 5:41 PM, Matt Riedemann > >>> <mrie...@linux.vnet.ibm.com> wrote: > >>> > > >>> > > >>> > On 5/26/2015 4:19 PM, Matt Riedemann wrote: > >>> >> > >>> >> > >>> >> > >>> >> On 5/26/2015 9:53 AM, Davanum Srinivas wrote: > >>> >>> > >>> >>> We are gleeful to announce the release of: > >>> >>> > >>> >>> oslo.vmware 0.13.0: Oslo VMware library > >>> >>> > >>> >>> With source available at: > >>> >>> > >>> >>> http://git.openstack.org/cgit/openstack/oslo.vmware > >>> >>> > >>> >>> For more details, please see the git log history below and: > >>> >>> > >>> >>> http://launchpad.net/oslo.vmware/+milestone/0.13.0 > >>> >>> > >>> >>> Please report issues through launchpad: > >>> >>> > >>> >>> http://bugs.launchpad.net/oslo.vmware > >>> >>> > >>> >>> Changes in oslo.vmware 0.12.0..0.13.0 > >>> >>> ------------------------------------- > >>> >>> > >>> >>> 5df9daa Add ToolsUnavailable exception > >>> >>> 286cb9e Add support for dynamicProperty > >>> >>> 7758123 Remove support for Python 3.3 > >>> >>> 11e7d71 Updated from global requirements > >>> >>> 883c441 Remove run_cross_tests.sh > >>> >>> 1986196 Use suds-jurko on Python 2 > >>> >>> 84ab8c4 Updated from global requirements > >>> >>> 6cbde19 Imported Translations from Transifex > >>> >>> 8d4695e Updated from global requirements > >>> >>> 1668fef Raise VimFaultException for unknown faults > >>> >>> 15dbfb2 Imported Translations from Transifex > >>> >>> c338f19 Add NoDiskSpaceException > >>> >>> 25ec49d Add utility function to get profiles by IDs > >>> >>> 32c61ee Add bandit to tox for security static analysis > >>> >>> f140b7e Add SPBM WSDL for vSphere 6.0 > >>> >>> > >>> >>> Diffstat (except docs and test files) > >>> >>> ------------------------------------- > >>> >>> > >>> >>> bandit.yaml | 130 +++ > >>> >>> openstack-common.conf | 2 - > >>> >>> .../locale/fr/LC_MESSAGES/oslo.vmware-log-error.po | 9 - > >>> >>> .../locale/fr/LC_MESSAGES/oslo.vmware-log-info.po | 3 - > >>> >>> .../fr/LC_MESSAGES/oslo.vmware-log-warning.po | 10 - > >>> >>> oslo.vmware/locale/fr/LC_MESSAGES/oslo.vmware.po | 86 +- > >>> >>> oslo.vmware/locale/oslo.vmware.pot | 48 +- > >>> >>> oslo_vmware/api.py | 10 +- > >>> >>> oslo_vmware/exceptions.py | 13 +- > >>> >>> oslo_vmware/objects/datastore.py | 6 +- > >>> >>> oslo_vmware/pbm.py | 18 + > >>> >>> oslo_vmware/service.py | 2 +- > >>> >>> oslo_vmware/wsdl/6.0/core-types.xsd | 237 +++++ > >>> >>> oslo_vmware/wsdl/6.0/pbm-messagetypes.xsd | 186 ++++ > >>> >>> oslo_vmware/wsdl/6.0/pbm-types.xsd | 806 > >>> >>> ++++++++++++++ > >>> >>> oslo_vmware/wsdl/6.0/pbm.wsdl | 1104 > >>> >>> ++++++++++++++++++++ > >>> >>> oslo_vmware/wsdl/6.0/pbmService.wsdl | 16 + > >>> >>> requirements-py3.txt | 27 - > >>> >>> requirements.txt | 8 +- > >>> >>> setup.cfg | 2 +- > >>> >>> test-requirements-bandit.txt | 1 + > >>> >>> tox.ini | 14 +- > >>> >>> 27 files changed, 2645 insertions(+), 262 deletions(-) > >>> >>> > >>> >>> > >>> >>> Requirements updates > >>> >>> -------------------- > >>> >>> > >>> >>> diff --git a/requirements.txt b/requirements.txt > >>> >>> index 807bcfc..dd5a1aa 100644 > >>> >>> --- a/requirements.txt > >>> >>> +++ b/requirements.txt > >>> >>> @@ -5 +5 @@ > >>> >>> -pbr>=0.6,!=0.7,<1.0 > >>> >>> +pbr>=0.11,<2.0 > >>> >>> @@ -23,3 +23,3 @@ PyYAML>=3.1.0 > >>> >>> -suds>=0.4 > >>> >>> -eventlet>=0.16.1,!=0.17.0 > >>> >>> -requests>=2.2.0,!=2.4.0 > >>> >>> +suds-jurko>=0.6 > >>> >>> +eventlet>=0.17.3 > >>> >>> +requests>=2.5.2 > >>> >>> diff --git a/test-requirements-bandit.txt > >>> >>> b/test-requirements-bandit.txt > >>> >>> new file mode 100644 > >>> >>> index 0000000..38c39e1 > >>> >>> --- /dev/null > >>> >>> +++ b/test-requirements-bandit.txt > >>> >>> @@ -0,0 +1 @@ > >>> >>> +bandit==0.10.1 > >>> >>> > >>> >>> > >>> >>> > >>> >> > >>> >> There is now a blocking vmware unit tests bug in nova due to the > >>> >> oslo.vmware 0.13.0 release: > >>> >> > >>> >> https://bugs.launchpad.net/nova/+bug/1459021 > >>> >> > >>> >> Since the vmware driver unit test code in nova likes to stub out > >>> >> external APIs there is probably a bug in the nova unit tests rather > >>> >> than > >>> >> an issue in oslo.vmware, but I'm not very familiar so I can't really > >>> >> say. > >>> >> > >>> > > >>> > I have a revert for oslo.vmware here: > >>> > > >>> > https://review.openstack.org/#/c/185744/ > >>> > > >>> > And a block on the 0.13.0 version in global-requirements here: > >>> > > >>> > https://review.openstack.org/#/c/185748/ > >>> > > >>> > > >>> > -- > >>> > > >>> > Thanks, > >>> > > >>> > Matt Riedemann > >>> > > >>> > > >>> > > >>> > > __________________________________________________________________________ > >>> > OpenStack Development Mailing List (not for usage questions) > >>> > Unsubscribe: > >>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>> > >>> > >>> > >>> -- > >>> Davanum Srinivas :: https://twitter.com/dims > >>> > >>> > >>> > __________________________________________________________________________ > >>> OpenStack Development Mailing List (not for usage questions) > >>> Unsubscribe: > >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > >> > __________________________________________________________________________ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > -- > Davanum Srinivas :: https://twitter.com/dims > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev