| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-24 | |||
| 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 | |
| 15:54:28 | openstackgerrit | sahid proposed openstack/nova: numa: take into account cpus reserved https://review.openstack.org/400876 | |
| 15:54:29 | openstackgerrit | sahid proposed openstack/nova: numa: update numa usage incording the cpu reserved https://review.openstack.org/400877 | |
| 15:54:55 | artom | Yeah, anyone can dig through the git logs and review history, but putting it in the API version history is more accessible if folks start wondering wtf | |
| 15:55:45 | lyarwood | mdbooth: https://review.openstack.org/399735 could use another review if you have time today | |
| 15:57:26 | mdbooth | lyarwood: Yep. It takes me almost 10 minutes to make a moka of coffee, I'll do it then :) | |
| 16:02:00 | mriedem | sfinucan: "While this doesn't cause any issues currently, it is a latent bug that has caused issues downstream." - in other words, it's currently causing issues :) | |
| 16:02:34 | sfinucan | mriedem: You got it :) | |
| 16:03:25 | sfinucan | I meant "this doesn't cause issues with upstream-only code", of course | |
| 16:05:00 | andreykurilin | mriedem: btw, are you ok about putting 7.1.0 to u-c ? | |
| 16:05:32 | mriedem | sfinucan: is it blowing up another out of tree scheduler filter or something? | |
| 16:05:40 | mriedem | sfinucan: or you're just not allowed to talk about it? | |
| 16:05:46 | mriedem | andreykurilin: yes | |
| 16:05:52 | andreykurilin | nice | |
| 16:06:57 | mriedem | sfinucan: dansmith: ok +W | |
| 16:07:02 | sfinucan | mriedem: Aye, we've a downstream only workaround to handle that long running "nova doesn't recalculate CPU topologies on live migration" bug | |
| 16:07:05 | mriedem | thanks for not ramming that in all red hat cores | |
| 16:07:43 | andreykurilin | johnthetubaguy: your comment about transmitting --os-user-id in case of token auth made gates to fail :( it requires more changes in novaclient's code. will recent a fix soon | |
| 16:08:45 | sfinucan | We check for CPU pinning info in the topology and compare it against the free host cores. The pinning info should only exist in a live migrate case, but that bug broke the assumption and broke scheduling :) | |
| 16:09:00 | sfinucan | mriedem: Thanks for the review. I can go sleep now, heh | |
| 16:09:01 | dansmith | yea, it's pretty nasty | |
| 16:13:02 | mdbooth | lyarwood: I've still got a -1 on its parent, right? | |
| 16:13:53 | mdbooth | Or is it direct on master now? Gerrit doesn't make this clear. | |
| 16:14:02 | mdbooth | At a glance, anyway. | |
| 16:14:46 | lyarwood | mdbooth: yeah it really doesn't, it's direct on master now | |
| 16:14:54 | mdbooth | k | |
| 16:15:06 | lyarwood | mdbooth: there's an additional workaround in there so it can be btw | |
| 16:15:10 | openstackgerrit | Andrey Kurilin proposed openstack/python-novaclient: [CLI] Fix token auth type https://review.openstack.org/424256 | |
| 16:15:37 | lyarwood | mdbooth: https://review.openstack.org/#/c/399735/18/nova/virt/libvirt/guest.py | |
| 16:16:11 | mdbooth | lyarwood: How's your xpath-fu? | |
| 16:16:38 | lyarwood | mdbooth: not great but that's a copy paste from the original | |
| 16:16:41 | mdbooth | and xslt | |
| 16:17:10 | mdbooth | You can do the source/target thing in a single query :) | |
| 16:17:21 | mdbooth | I won't inflict that on anybody, though. | |
| 16:17:29 | mdbooth | (Well, I probably would if I'd written it ;)) | |
| 16:17:52 | lyarwood | even with a different attribute for both? | |
| 16:17:54 | lyarwood | nice | |
| 16:18:00 | mdbooth | Yeah | |
| 16:18:15 | mriedem | dansmith: so what do you want me to look at for cells v2? | |
| 16:18:43 | dansmith | mriedem: this and the following: https://review.openstack.org/#/c/410473/13 | |
| 16:18:45 | mriedem | keeping in mind i've got a 5 year old girl asking me when i'm going to take a shower so i can go swimming | |
| 16:18:58 | dansmith | mriedem: I had to recheck the d-g patch, let me go check that again | |
| 16:19:09 | mriedem | i just rechecked it | |
| 16:19:15 | dansmith | okay it's +1 | |
| 16:19:40 | dansmith | I emailed sdague about it yesterday but don't see that he looked at it | |
| 16:19:42 | mriedem | on https://review.openstack.org/#/c/396775/ and the stable sort limitation, | |
| 16:19:44 | dansmith | I'll poke clarkb | |
| 16:20:04 | mriedem | are we going to just doc that in a reno? or will we just say in release notes that multiple cells aren't supported in ocata? | |
| 16:21:13 | dansmith | mriedem: yeah, I've been kinda waiting to see how far I get, but a release note with the status of things was my plan | |