Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-25
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,
16:53:40 dansmith blocker migrations are a pain for FFU people, so we should use them sparingly for when we need to fully drop support for something vs. just avoiding some compat code
16:53:48 dansmith like if we need to drop a column or something
16:54:25 melwitt oh, ok :/ might have to amend the spec in that case
16:54:58 melwitt (since it mentions a blocker migration)
16:55:14 dansmith I'm not saying we can't (I don't remember what the spec says), I'm just saying we should be judicious in our application of that technique
16:55:53 melwitt the spec says blocker migration for being able to remove compat code/stop legacy counting
16:55:58 melwitt understood
16:56:21 dansmith right, so, when we remove that code, we should have a blocker, so depending on how the spec words it, it may not be wrong :)
16:56:33 melwitt (although we have to keep legacy counting indefinitely until partitioning of placement allocations is possible)
16:56:49 dansmith okay
16:57:20 dansmith we could also do it a different way and just roll the blocker and new constraints together in one migration, but we definitely need to give some buffer between adding the thing and requiring the thing I thnk
16:58:11 melwitt yeah, understood and agreed
17:01:04 cdent melwitt: speaking of partitioning placement allocations. Is that a thing you were planning to spec or is that a broader all of us kind of thing?
17:01:40 melwitt cdent: broader thing
17:01:41 cdent or "dunno" is of course a reasonable answer
17:02:07 cdent ✔

Earlier   Later