Earlier  
Posted Nick Remark
#openstack-nova - 2019-03-25
13:56:23 openstack Launchpad bug 1821594 in OpenStack Compute (nova) "Error in confirm_migration leaves stale allocations and 'confirming' migration state" [Undecided,New]
13:56:35 ganso mriedem: thanks!
14:05:52 efried thanks ganso
14:07:38 mriedem i need to email claudiub about https://review.openstack.org/#/c/543971/
14:14:17 sean-k-mooney mriedem: sorry was on 1:1 will check thatreview now
14:16:33 sean-k-mooney mriedem: we made kuryr-kubernetes-tempest-daemon-octavia non-voting on master and kuryr removed it a few weeks ago so im not surpised that it failed
14:20:04 sean-k-mooney mriedem: it looked like it failed becasue the devstack-plugin-container tried to install linux kernel package that are not found on the repos anymore
14:20:34 sean-k-mooney it looks like it was installin kernel 4.4.0 packages which would correspond to ubuntu 16.04
14:20:52 sean-k-mooney if this ran on ubunut bionic then it would explain why it was not found
14:21:37 sean-k-mooney actully its a ubuntu-xenial node i would guess the package is just not in te repo anymore
14:28:14 openstackgerrit Merged openstack/nova-specs master: Fix warnings in the document generation https://review.openstack.org/631150
14:33:59 sean-k-mooney mriedem: ill propose the backport of making that non voting to the sable branches
14:34:29 openstackgerrit Merged openstack/nova master: Update contributor guide for Train https://review.openstack.org/645581
14:34:33 mriedem thanks
14:43:28 mnaser btw, I raised this on the mailing list .. I dunno how release-critical this can be considered considering it's been a long time bug -- http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004206.html
15:09:10 openstackgerrit sean mooney proposed openstack/os-vif stable/rocky: make kuryr-kubernetes-tempest-daemon-octavia non voting https://review.openstack.org/647500
15:10:02 sean-k-mooney mriedem: that will do it for rocky ^ but i need to check project-conifg for older branches
15:10:54 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add falvor to requested_resources in RequestSpec https://review.openstack.org/647396
15:11:29 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add flavor to requested_resources in RequestSpec https://review.openstack.org/647396
15:13:12 sean-k-mooney actully no never mind
15:13:39 sean-k-mooney we have zuul config in repo for older release se just do not run that job
15:16:11 openstackgerrit Matt Riedemann proposed openstack/os-vif stable/rocky: Replace openstack.org git:// URLs with https:// https://review.openstack.org/646868
15:22:55 openstackgerrit Merged openstack/python-novaclient stable/stein: Replace openstack.org git:// URLs with https:// https://review.openstack.org/647075
15:32:14 openstackgerrit Merged openstack/os-vif master: Replace openstack.org git:// URLs with https:// https://review.openstack.org/646867
15:37:12 openstackgerrit Matt Riedemann proposed openstack/nova master: Do not persist RequestSpec.ignore_hosts https://review.openstack.org/647513
15:37:12 openstackgerrit Matt Riedemann proposed openstack/nova master: Overwrite RequestSpec.ignore_hosts during evacuate https://review.openstack.org/647512
15:37:21 mriedem bauzas: cfriesen: dansmith: ^ fixes that super latent bug
15:39:30 cfriesen mriedem: nice. will take a look.
15:39:51 mriedem only took 2+ years
15:41:43 mriedem i can't wait until my next "don't persist field x in request spec" adventure
15:45:12 mriedem i guess i need to squash the 2nd and 3rd changes anyway...doing that
15:48:58 bauzas mriedem: nice
15:49:16 bauzas mriedem: once I'm done with some internal meeting + the vgpu docs, you're next in the queue
15:52:25 openstackgerrit Matt Riedemann proposed openstack/nova master: Add functional regression test for bug 1669054 https://review.openstack.org/646006
15:52:26 openstackgerrit Matt Riedemann proposed openstack/nova master: Do not persist RequestSpec.ignore_hosts https://review.openstack.org/647512
15:52:26 openstack bug 1669054 in OpenStack Compute (nova) "RequestSpec.ignore_hosts from resize is reused in subsequent evacuate" [Medium,In progress] https://launchpad.net/bugs/1669054 - Assigned to Matt Riedemann (mriedem)
15:55:38 cfriesen found a grammar bug in the commit message for https://review.openstack.org/#/c/647512
15:55:41 cfriesen mriedem: ^
15:55:51 cfriesen see review
15:56:34 openstackgerrit Sylvain Bauza proposed openstack/nova master: Remove expiremental note in the VGPU docs https://review.openstack.org/647518
15:56:35 openstackgerrit Sylvain Bauza proposed openstack/nova master: Add doc on VGPU allocs and inventories for nrp https://review.openstack.org/647519
15:56:51 bauzas mriedem: you could be interested in ^
15:59:27 openstackgerrit Matt Riedemann proposed openstack/nova master: Do not persist RequestSpec.ignore_hosts https://review.openstack.org/647512
15:59:29 mriedem cfriesen: done
15:59:43 dansmith wow a grammar nit in a mriedem patch
16:02:28 openstackgerrit Sylvain Bauza proposed openstack/nova master: Add doc on VGPU allocs and inventories for nrp https://review.openstack.org/647519
16:09:00 openstackgerrit Merged openstack/python-novaclient stable/queens: Replace openstack.org git:// URLs with https:// https://review.openstack.org/647073
16:09:49 mriedem bauzas: a few nits in that top docs patch but otherwise really nice
16:09:50 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add flavor to requested_resources in RequestSpec https://review.openstack.org/647396
16:11:05 gibi mriedem: regarding your patch about prefiltering for multiattach capable nodes. I tried to make your first approach (request group) work by creating request group for the flavor resource too ^^
16:12:41 openstackgerrit Merged openstack/python-novaclient stable/rocky: Replace openstack.org git:// URLs with https:// https://review.openstack.org/647074
16:12:42 openstackgerrit Merged openstack/python-novaclient stable/ocata: Replace openstack.org git:// URLs with https:// https://review.openstack.org/647071
16:12:44 mriedem gibi: seems kind of gross to have to call a new helper method in conductor for all move operations
16:13:32 openstackgerrit Merged openstack/python-novaclient stable/pike: Replace openstack.org git:// URLs with https:// https://review.openstack.org/647072
16:14:25 mriedem i guess it's not all move ops
16:15:20 gibi mriedem: I tried to hook into the RequestSpec.flavor property setter but property setter doesn't seem to work on ovos
16:16:15 gibi mriedem: there are another problem noted in the commit message. The numbering of the request groups are lost during the process
16:17:39 mriedem so if someone is resizing with a flavor that has numbered request groups in it, we could lose that
16:17:42 mriedem and break something later
16:17:49 mriedem because we don't persist requested_resources
16:17:50 mriedem right?
16:18:11 gibi mriedem: we are not loosing the group we are loosing the number used in the flavor extra_spec for a given group
16:18:24 dansmith surely we don't want to persist requested_resources
16:18:25 gibi mriedem: besically the patch renumbers each group when generating the a_c query
16:18:35 dansmith since those could change in format or structure across releases
16:18:42 gibi dansmith: I agree
16:18:57 mriedem gibi: isn't the flavor group number coming from the flavor extra specs? which are persisted in RequestSpec.flavor.extra_specs
16:19:25 gibi mriedem: yes. The goal of this patch to create RequestGroup ovos from the flavor
16:19:25 mriedem dansmith: i'm not so sure here, persisting things in request spec has really helped us out thus far......
16:19:31 dansmith mriedem: heh
16:19:56 dansmith the resources in the flavor *are* structural and fixed, but the full set that we calculate from the flavor and other requirements (i.e. from the image, etc) shouldn't be persisted I think
16:20:00 gibi mriedem: there is no place currently in the RequestGroup to store it's ident
16:24:06 mriedem gibi: i'm not sure what that means for this
16:24:24 mriedem what is the ident? requester_id? or just the group number?
16:24:28 mriedem index?
16:24:47 mriedem request groups baffle me which is why i've deprioritized that multiattach patch :)
16:24:57 gibi the group number from the flavor.extra_spec
16:25:18 mriedem i thought that was baked into the extra spec key name?
16:25:20 mriedem resources1 etc
16:25:22 gibi the flavor create can use resourceN where N is a positive number
16:25:34 gibi and that N ends up in the a_c query
16:25:42 gibi but the current patch renumbers the groups
16:26:01 openstackgerrit Merged openstack/nova master: Replace openstack.org git:// URLs with https:// https://review.openstack.org/646682
16:26:01 gibi it will be 1,2,3,... in the a_c query
16:26:08 openstackgerrit Merged openstack/nova stable/stein: Replace openstack.org git:// URLs with https:// https://review.openstack.org/646688
16:26:48 mriedem gibi: ok so i guess the question is does that matter as long as the groups remain....grouped
16:27:14 gibi they remain grouped. So it only hardens the troubleshooting
16:30:26 openstackgerrit Surya Seetharaman proposed openstack/nova-specs master: Support server power state update through external event https://review.openstack.org/636132
16:34:49 openstackgerrit Surya Seetharaman proposed openstack/nova-specs master: Support server power state update through external event https://review.openstack.org/636132
16:49:51 melwitt mriedem: I was wondering re: counting quotas, since we're doing a blocker migration for user_id this cycle, does that mean we don't need to check whether it's populated and fall back to legacy counting anymore? or do we still need to?
16:51:06 mriedem melwitt: i think the blocker migration missed stein so it has to be in U now
16:51:33 mriedem but probably a better question for dansmith
16:51:39 mriedem doing the blocker migration right away in Train seems overly aggressive
16:52:24 dansmith melwitt: if we do a blocker, then yes that's what that means, but if we're going to be a little softer about it, then we'd need to handle the compat
16:52:26 melwitt mriedem: ok, yeah I wasn't sure how that usually works. I was thinking since we landed all of the migration code in stein, then the blocker migration might only be related to that
16:52:30 dansmith generally we do a blocker so we can drop support for something
16:52:52 dansmith and doing that right after we opened the window would be rather aggressive as mriedem said
16:52:56 melwitt oh, I see. yeah, then T would be too early
16:53:02 mriedem i think trying to drop the compat in the same release that we add the new code that depends on that compat seems aggressive
16:53:07 dansmith and remember,

Earlier   Later