Earlier  
Posted Nick Remark
#openstack-nova - 2017-01-24
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 bauzas 7.0.0 is breaking more than the token thing ?
15:34:00 mriedem well by 'break' i mean, intentional changes to remove functionality
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 mriedem on https://review.openstack.org/#/c/423808/ i would have made the min 6.0, and u-c 7.0
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: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
15:49:10 cdent k
15:49:16 artom Tags were optional, so if you tried to use them in 2.33 it would break, but no one filed a but so no one noticed
15:49:32 artom But if you weren't using them re-adding them as an optional parameter doesn't break anything
15:49:43 artom Hrmm, maybe we *can* just silently re-add them
15:49:53 artom Same logic goes for networks
15:50:33 bauzas dansmith: quick question on grenade, do you think it's a valid approach to just source the placement lib, and call out the appropriate functions, or try to modify local.conf to include placement?
15:50:34 mriedem i doubt anyone noticed because (a) most clouds aren't at newton yet and/or (b) no one is using them, yeah
15:50:47 dansmith bauzas: source and use existing functions
15:50:58 mriedem however,
15:50:59 bauzas dansmith: that would mean local.conf wouldn't be accurate then
15:51:25 mriedem 2.1 and microversions is all about correcting mistakes, and in the old 2.0 API we always said we couldn't fix things regardless of the wart
15:51:29 bauzas dansmith: if that's not a necessary requirement, I'm fine
15:51:33 mriedem unless we used extensions or some garbage like that
15:51:38 dansmith bauzas: oh, thought you meant nova.conf.. I still think that's okay and consistent, FWIW
15:52:13 bauzas dansmith: the fact is that the grenade-upgrade local.conf wouldn't be valid in case the deployer wants to unstack/stack
15:52:20 mriedem andreykurilin: ping me when your requirements change is up to change the minimum back to 6.0 and blacklist 7.0
15:52:27 cdent mriedem: sounds like you should join the thread about api compatbility/stability seeing as you have opinions ;)/2
15:52:45 andreykurilin mridem: it is here https://review.openstack.org/#/c/424705/
15:53:14 mriedem cdent: well i lean toward the microversion fix
15:53:24 mriedem just because it's the "right thing to do"
15:53:34 openstackgerrit Balazs Gibizer proposed openstack/nova: handle uninited fields in notification payload https://review.openstack.org/415857
15:54:18 openstackgerrit sahid proposed openstack/nova: numa: add numa constraints for emulator threads policy https://review.openstack.org/385023
15:54:21 openstackgerrit sahid proposed openstack/nova: objects: add new field cpuset_reserved in NUMACell https://review.openstack.org/400874
15:54:21 openstackgerrit sahid proposed openstack/nova: libvirt: return a CPU overhead if isolate emulator threads requested https://review.openstack.org/385364
15:54:22 artom mriedem, it *is* more transparent
15:54:22 openstackgerrit sahid proposed openstack/nova: numa: fit instance topology with cpus reserved onto cores https://review.openstack.org/400875
15:54:23 openstackgerrit sahid proposed openstack/nova: virt: update overhead to take into account vCPUs https://review.openstack.org/385024
15:54:27 openstackgerrit sahid proposed openstack/nova: libvirt: make emulator threads to run on the reserved pCPU https://review.openstack.org/400878

Earlier   Later