Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-24
15:25:17 dansmith cool
15:26:26 dansmith mriedem: if you want an easy one to +W to make your vacation feel productive, this trivial one from sfinucan would be good: https://review.openstack.org/#/c/419479/5
15:26:44 amrith thx andreykurilin
15:26:54 amrith please let me know once the novaclient patch is released
15:27:00 amrith that'll be the easiest way to test in the gate
15:27:04 amrith could we mark 7.0.0 as bad?
15:27:25 mriedem amrith: 7.0 isn't in g-r is it?
15:27:41 mriedem or u-c rather
15:27:43 amrith well, it is what we're getting now from pypi
15:27:50 andreykurilin mriedem: 7.0 is a version from u-c now :)
15:27:51 mriedem are you using upper-constraints?
15:28:01 andreykurilin also it is a min version of requirements
15:28:03 mriedem andreykurilin: ok, then i guess we should blacklist 7.0 in g-r
15:28:09 mriedem really? why?
15:28:10 amrith mriedem, yes
15:28:26 diana_clarke mriedem: it was merged into u-c on the 19th https://review.openstack.org/#/c/414170/
15:28:39 amrith global-requirements.txt:python-novaclient>=2.29.0,!=2.33.0 # Apache-2.0
15:28:39 amrith projects.txt:openstack/python-novaclient
15:28:39 amrith upper-constraints.txt:python-novaclient===7.0.0
15:28:54 amrith mriedem, yes we're using u-c
15:28:54 andreykurilin mriedem: I think today we will have everything for next release (7.0.1/7.1.0) and we will able to make everything together - blacklist and put right version
15:29:22 mriedem i don't know why we'd require 7.0 as the minimum
15:29:49 amrith mriedem, andreykurilin it may be a good idea to have periodic jobs that test against the tip of master in nova client like we do with oslo. I'll propose such a periodic job
15:29:51 mriedem also the wifi here sucks so everything takes forever to load
15:30:16 mriedem amrith: and where do the results of those jobs go and who is going to be monitoring them?
15:30:41 amrith mriedem, I get an email when they fail
15:30:46 amrith let me find out how that is setup
15:30:55 amrith it is something that dims (I believe) setup a while back
15:30:56 mriedem ok
15:31:15 amrith in general, I'd think that is something that for trove, should be trove's to monitor
15:31:19 mriedem amrith: have you talked to the requirements team about getting a trove unit test job to run as part of changes like this? https://review.openstack.org/#/c/414170/
15:31:32 amrith have not
15:31:34 andreykurilin mriedem: because all "right version" from min to max should be compatible. we have too much changes now to use 2.29 as a min (like it was previously)
15:31:39 amrith but it is a good idea as well
15:32:14 andreykurilin I mean it is a hard task to write a compatible code for 2.29 and 7.0
15:32:28 mriedem andreykurilin: well yeah, and that's why we use semver for major changes
15:32:49 mriedem even with fixing the token thing, 7.0 probably breaks a bunch of things
15:33:26 andreykurilin mriedem: it breaks two things - token auth via python API (for CLI it was broken for a year) and list_extension
15:33:41 andreykurilin both of these things have fixes on review
15:34:00 mriedem well by 'break' i mean, intentional changes to remove functionality
15:34:00 bauzas 7.0.0 is breaking more than the token thing ?
15:34:12 mriedem which is why we released it with a major version bump
15:34:16 bauzas do we have a g-r change that blocks it ?
15:34:32 mriedem bauzas: the requirements changes aren't run against trove unit tests,
15:34:38 mriedem otherwise something might have been caught
15:34:45 bauzas and if we have a couple of fixes, let's name the next release 7.0.1 even if we add the osprofiler thing
15:34:47 andreykurilin mriedem: I think we done everything in backward compatible way (except usage of our inner variables)
15:35:23 bauzas mriedem: yeah, but as per andreykurilin 7.0.0 blew up more than just trove
15:35:38 bauzas mriedem: at least the tripleo folks and the murano folks AFAICS
15:35:39 mriedem bauzas: new features need to be a min version bump at least to 7.1.0
15:35:57 bauzas I know
15:35:58 andreykurilin bauzas: one more thing that is broken by 7.0 - https://review.openstack.org/#/c/424570/ :)
15:36:22 bauzas I'm saying 7.0.0 is doomed so we would signal that there is a new release fixing it
15:36:22 mriedem on https://review.openstack.org/#/c/423808/ i would have made the min 6.0, and u-c 7.0
15:36:57 andreykurilin ok, let's use 6.0 as a min, but not 2.29 like it was
15:36:58 bauzas yup :(
15:37:12 mriedem andreykurilin: do you want me to push that change quick?
15:37:24 mriedem >=6.0.0,!=7.0.0
15:37:41 andreykurilin mriedem: no, please take a rest. you are on vacation
15:37:47 andreykurilin I'll do it
15:38:10 mriedem it's morning and i've got a caffiene headache but ok
15:38:29 mriedem *caffeine
15:38:36 bauzas mriedem: you okay if I'm tagging a 7.1.0 with the help of andreykurilin ?
15:38:50 bauzas once all the fixes are done of course
15:38:55 mriedem bauzas: that's fine
15:39:19 mriedem alex_xu: cdent: artom: gmann: where are we on the device tags thing?
15:39:20 bauzas mriedem: client libraries freeze is thursday as well ?
15:39:27 mriedem bauzas: yes client release freeze is thursday
15:39:34 bauzas ok
15:40:06 cdent mriedem: I don't know, haven't revisited since I lit the fire...
15:40:27 mriedem it's a time that i wish we could just fix the bugs in the api w/o the microversion
15:40:33 artom mriedem, nowhere as far as I can tell - what's the plan? We document before ocata FF and unfuck it in Pike?
15:41:03 artom If so I can submit the documentation patch
15:41:05 mriedem (a) this version works, but (b) x-y don't work, except z, so (c) we'll fix it all in microversion 2.50
15:41:11 artom But I wasn't sure we had consensus on that
15:41:15 robcresswell diana_clarke: Thanks for the response on the horizon discussion, that was useful
15:41:49 mriedem artom: if we're not going to fix it with a microversion in ocata we can document it probably whenever before ocata rc1
15:42:23 artom mriedem, do we have time to squeeze it in in 2 days? I can write the code...
15:42:28 artom (The new microversion I mean)
15:42:52 mriedem artom: we probably don't have the review bandwidth in 2 days
15:43:16 mriedem alternatively we microversion it for a bug fix and it's not tied to FF since it's not a feature, it's a bug fix
15:43:23 diana_clarke robcresswell: np, I know the whole approach is somewhat sub-optimal, but I'm not sure how else we could have proceeded.
15:43:28 mriedem i thought we did that with the vm status microversion in newton
15:43:41 artom mriedem, oh right, I forgot FF != halt all evarything
15:44:33 artom mriedem, if I have your PTLness backing me on this, I can drive it as a microversion bugfix before ocata release
15:44:36 artom ;)
15:44:46 cdent I think bugfix sounds like the right approach
15:44:52 cdent gives some time to do it right
15:44:56 cdent and it _is_ a bugfix
15:45:30 robcresswell diana_clarke: Yeah, understood
15:45:38 mriedem especially this one https://review.openstack.org/#/c/304510/64/nova/api/openstack/compute/block_device_mapping.py i'd really like to just fix that w/o a microversion,
15:45:49 mriedem but that probably goes against everything we've always said
15:47:06 artom mriedem, I don't think we can. For all intents and purposes, there's no tag in >=2.33. And adding an API parameter is a new microversion...
15:48:05 mriedem yes i know, but 2.33->2.43 or whatever with no bdm tag support, and then it's back in, is just super terrible UX
15:48:11 cdent bauzas: are your placement changes in a good state to review now?
15:48:18 bauzas cdent: it is indeed
15:48:23 cdent on it
15:48:45 bauzas cdent: I need to write a grenade change for fixing the related jobs but that shouldn't be impacting my WIP
15:48:46 artom mriedem, I totally agree on that point... And to be fair, I can't think of any core that would stop working
15:49:03 bauzas cdent: FWIW, there is now only one patch left, I abandoned the fixture one

Earlier   Later