| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-03-26 | |||
| 15:36:55 | gmann | gibi: yeah. I am ok to add in existing PUT as making other PUT or action API is a big change from implementation and users perspective. having api-ref clear about this PUT = swap + updating resources based on how you use this API. | |
| 15:37:18 | gibi | gmann: ack, thanks | |
| 15:37:53 | gmann | though it makes this API more complex but its tradeoff as dansmith mentioned that any other way is not less complex for client. | |
| 15:40:04 | sean-k-mooney | gmann: i think calling it a swap + updating resources is still the wrong way to think about it | |
| 15:40:19 | gmann | gibi: on the instance fault things: i will wai for dansmith to come back and discuss if somehow we can minimize the info leak to non-admin. other part like policy things is ok for me. | |
| 15:40:25 | sean-k-mooney | gmann: it is just declaritivly updatin the resouces and a sidefect of that can be to trigger swap | |
| 15:40:43 | sean-k-mooney | that is how we should explain it to endusers | |
| 15:40:55 | gibi | gmann: re instance fault: thanks | |
| 15:41:08 | johnthetubaguy | gmann: my preference is to not document the crazy cinder API, and move that to some developer docs or something? | |
| 15:41:36 | johnthetubaguy | should stop some confusion for the 99% of API users | |
| 15:41:37 | sean-k-mooney | johnthetubaguy: do end users ever call that directly | |
| 15:41:40 | gmann | sean-k-mooney: humm, having the swap as side-efect is my concern. that is big change to enduser machine so it has to be very explicit operation from usage doc side. | |
| 15:41:47 | johnthetubaguy | sean-k-mooney: they do, but they never should | |
| 15:41:58 | johnthetubaguy | its for cinder only, else odd things happen | |
| 15:42:07 | sean-k-mooney | gmann: not really that is how i alwasy tought of it already | |
| 15:42:42 | sean-k-mooney | johnthetubaguy: ok so this is just for the callback form cinder | |
| 15:42:51 | johnthetubaguy | that is my understanding, yes | |
| 15:42:56 | johnthetubaguy | hence the big red warning | |
| 15:43:04 | gmann | johnthetubaguy: can we make that internal than ? at least from doc side. i mean api-ref not at all talk about swap operation for users as currently we have ? | |
| 15:43:09 | sean-k-mooney | johnthetubaguy: and yes im pretty sure we have had downstream bugs filed as a result of users calling it directly | |
| 15:43:20 | johnthetubaguy | gmann: +1 that | |
| 15:43:24 | gmann | sean-k-mooney: yeah we had few in past | |
| 15:43:35 | johnthetubaguy | sean-k-mooney: yeah, what they wanted to do was call the Cinder swap API, but they got confused | |
| 15:43:39 | gibi | for me the difference is like change my house (swap) or repaint the kitchen in my house (update) | |
| 15:44:36 | sean-k-mooney | actully i think our customer wanted to bypass a check in the ciner side a and force it so that is why they used nova | |
| 15:45:35 | johnthetubaguy | gibi: or you swap out your oven to a hot one, or just change tell it to self destruct when your pizza is done. its the same thing you are changing. | |
| 15:45:45 | openstackgerrit | Stephen Finucane proposed openstack/nova master: api: Add framework for extra spec validation https://review.opendev.org/704643 | |
| 15:45:46 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Add documentation for flavor extra specs https://review.opendev.org/710037 | |
| 15:45:46 | sean-k-mooney | anyway when we have had issue related to swap volume we havne pretty much always fixed it once for them and told them not to do that again | |
| 15:45:46 | openstackgerrit | Stephen Finucane proposed openstack/nova master: api: Add microversion 2.84, extra spec validation https://review.opendev.org/708436 | |
| 15:45:55 | stephenfin | gibi: I'd to rebase that ^ after losing the race for 2.83. Could you hit https://review.opendev.org/#/c/708436/9 again? | |
| 15:46:18 | johnthetubaguy | sean-k-mooney: yeah, sounds like they were doing something bad. something we shouldn't tell them to do in the docs | |
| 15:46:19 | stephenfin | and johnthetubaguy, any chance you'll stick that on your list? iirc, that was also on your list of gripes ^ | |
| 15:46:21 | gibi | johnthetubaguy: yeah like that. replace the whole v.s. tweak a prt of the whole | |
| 15:46:45 | gibi | stephenfin: sure | |
| 15:46:56 | johnthetubaguy | stephenfin: well played, and yes on both counts | |
| 15:47:05 | gibi | stephenfin: I think I caused you to lose :) | |
| 15:47:34 | stephenfin | well, thankfully it's just lyarwood and I duking it out for 2.84 now, afaict :) | |
| 15:48:05 | gibi | :) | |
| 15:50:38 | sean-k-mooney | johnthetubaguy: have you had any futher issues with the libosinfo feature where we try to set some default based on the disto name/version | |
| 15:51:13 | johnthetubaguy | sean-k-mooney: mostly given up on it I think, not had time to dig | |
| 15:51:19 | sean-k-mooney | johnthetubaguy: we backported the fix for the last one downstream and fond that new libosinfo broke use in another way | |
| 15:51:54 | sean-k-mooney | johnthetubaguy: ok so i would like to remove it in victoria since it was broken from the start given it ignores architeture and machine type | |
| 15:52:13 | sean-k-mooney | would that cause issues for you if we did that | |
| 15:52:30 | johnthetubaguy | sean-k-mooney: it would make my life easier I think | |
| 15:52:54 | sean-k-mooney | we likely would fix the issue we hit so we can backport then kill it with fire in the next patch | |
| 15:52:55 | johnthetubaguy | sounds like a good idea, and just replace it with some decent documentation | |
| 15:53:29 | sean-k-mooney | ya we have explict image properties to set everyting it can set anyway | |
| 15:53:43 | gibi | stephenfin: done. | |
| 15:53:48 | stephenfin | thanks | |
| 15:54:00 | sean-k-mooney | and i alreay recommend people to use those anyway since libosinfo change its default out of our contol anyway | |
| 15:54:34 | gibi | nova meeting starts in 5 and a half minutes on #openstack-meeting-3 | |
| 16:10:54 | lyarwood | stephenfin: oOOoOoo shiny.. WAIT A MINUTE! | |
| 16:11:19 | lyarwood | stephenfin: feel free to land on 2.84 btw, I need to rework something in my series today anyway | |
| 16:11:33 | lyarwood | stephenfin: if it's just the two of us I'll land on 2.85 | |
| 16:12:09 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Use neutronclient's port binding APIs https://review.opendev.org/706295 | |
| 16:19:00 | artom | stephenfin, for the record, I hate https://review.opendev.org/#/c/631053/ and everything it stands for | |
| 16:19:17 | artom | I'll still review it because I started, but I will forever hold this grudge in my hear. | |
| 16:19:20 | artom | *heart. | |
| 16:20:14 | stephenfin | 🕺🕺🕺 | |
| 16:20:14 | stephenfin | 🕺🕺🕺 | |
| 16:21:15 | artom | ... man dancing? | |
| 16:25:32 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: libvirt: support to create instance with dedicated and shared CPUs https://review.opendev.org/714655 | |
| 16:25:32 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: Take the instance dedicated CPU list from 'cpu_pinning' if possible https://review.opendev.org/713352 | |
| 16:25:33 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: Remove 'InstanceNUMACell.cpu_pinning_requested' field https://review.opendev.org/714656 | |
| 16:25:33 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: 'cpu_pinning_requested' property could be derived directly from cpu_policy https://review.opendev.org/713353 | |
| 16:25:34 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: Introduce 'MIXED' CPU allocation policy for instance https://review.opendev.org/713354 | |
| 16:25:34 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: Refactor the code in checking available host CPUs https://review.opendev.org/714657 | |
| 16:25:35 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: metadata: export the vCPU IDs that are pinning on the host CPUs https://review.opendev.org/688936 | |
| 16:25:35 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: Introduce the interface of creating 'MIXED' policy instance through 'PCPU' and 'VCPU' https://review.opendev.org/713355 | |
| 16:25:36 | openstackgerrit | Huaqiang Wang proposed openstack/nova master: [WIP] An alternative way for keeping instance dedicated CPUs https://review.opendev.org/714658 | |
| 16:26:09 | gmann | johnthetubaguy: you already have noticed this. I added no-deprecation tests for admin-api also which does not make a difference than enable-scope tests but still to check if nothing weird happens when remove deprecation. - https://review.opendev.org/#/c/715085/2/nova/tests/unit/policies/test_instance_usage_audit_log.py@99 | |
| 16:26:24 | gmann | hope that is fine, in some cases it is just removing the deprecatiob from base rule and checks | |
| 16:26:47 | johnthetubaguy | gmann: yeah, seemed good to check anyways | |
| 16:26:55 | gmann | ok | |
| 16:27:16 | johnthetubaguy | its a bit like nova-next tests | |
| 16:27:22 | huaqiang | stephenfin: I updated the series for 'mixed policy instance', but only the last patch I changed this time | |
| 16:27:22 | gmann | yeah | |
| 16:27:48 | huaqiang | https://review.opendev.org/714658 [WIP] An alternative way for keeping instance dedicated CPUs | |
| 16:28:14 | huaqiang | this 'pcpuset approach' one, | |
| 16:28:59 | huaqiang | If you have time please have a look for this patch, | |
| 16:29:27 | huaqiang | I just want your comments for if it is ready to drop the 'cpu_pinning' approach now | |
| 16:30:00 | huaqiang | it the answer is comfirmative, I'll drop it and submit new series. | |
| 16:32:27 | huaqiang | this patch is still a 'WIP' patch, I still have several 'TODO's, I'll address tomorrow. | |
| 16:32:30 | openstackgerrit | John Garbutt proposed openstack/nova master: Add legacy limits and usage to unified limits https://review.opendev.org/713498 | |
| 16:32:30 | openstackgerrit | John Garbutt proposed openstack/nova master: Enforce resource limits using oslo.limit https://review.opendev.org/615180 | |
| 16:32:31 | openstackgerrit | John Garbutt proposed openstack/nova master: Update quota apis with keystone limits and usage https://review.opendev.org/713499 | |
| 16:48:32 | openstackgerrit | John Garbutt proposed openstack/nova master: Tell oslo.limit how to count nova resources https://review.opendev.org/713301 | |
| 16:49:08 | openstackgerrit | John Garbutt proposed openstack/nova master: Enforce resource limits using oslo.limit https://review.opendev.org/615180 | |
| 16:49:18 | openstackgerrit | John Garbutt proposed openstack/nova master: Add legacy limits and usage to unified limits https://review.opendev.org/713498 | |
| 16:49:25 | openstackgerrit | John Garbutt proposed openstack/nova master: Update quota apis with keystone limits and usage https://review.opendev.org/713499 | |
| 16:53:07 | gmann | dansmith: johnthetubaguy on - delete_on_termination via PUT, do we want to control it via separate policy or with swap operation policy which is admin by default - https://review.opendev.org/#/c/693828/19/nova/api/openstack/compute/volumes.py@494 | |
| 16:53:31 | johnthetubaguy | its a new policy I think, admin_or_owner one | |
| 16:53:45 | johnthetubaguy | probably need to rename the old one I guess | |
| 16:54:54 | dansmith | yeah, new policy | |
| 16:54:54 | gmann | ok. | |
| 16:55:44 | johnthetubaguy | gmann: update -> swap, new one called "put" ? | |
| 16:56:19 | gmann | i was thinking new one to 'update' but that is existing and conflcit at deprecation logic | |
| 16:56:37 | johnthetubaguy | yeah, agreed | |
| 16:56:40 | gmann | 'put' will be inconsistentname from other one | |