| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-03-26 | |||
| 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 | |
| 16:57:15 | gmann | 'os-volumes-attachments:volume:update' for new ? | |
| 16:57:32 | gmann | volume is redundant though | |
| 16:57:38 | johnthetubaguy | that seems more inconsistent though | |
| 16:57:43 | gmann | :) | |
| 16:58:38 | dansmith | I would think that it would be okay to rename the existing one, given the conflict | |
| 16:58:40 | dansmith | with a reno | |
| 16:59:03 | dansmith | the existing one, if opened to non-admin users wouldn't be terrible if it applied to the delete flag, and probably expected | |
| 16:59:05 | johnthetubaguy | yeah, I am tempted to just reno about the conflict | |
| 16:59:11 | gmann | ok, deprecation message saying this old policy is being used for this new operation ? | |
| 16:59:18 | dansmith | in all likelihood nobody has changed this one since it _is_ supposed to be for cinder only | |
| 16:59:41 | dansmith | gmann: maybe not deprecation, but a warning if it's set to non-default? | |
| 16:59:55 | johnthetubaguy | nah, skip deprecation, make existing "update" PROJECT_MEMBER_OR_SYSTEM_ADMIN, then add new rule for swap | |
| 17:00:17 | dansmith | yeah, that | |
| 17:00:45 | gmann | ok, that is better. | |
| 17:00:48 | johnthetubaguy | they shouldn't have changed it, if they did, they should read the reno note | |
| 17:01:24 | dansmith | exactly | |
| 17:01:41 | dansmith | if this was for any other thing I would take more care, but this is suuuper obscure and special | |
| 17:02:22 | gmann | and cinder will keep working as new defaults keep allowing admin to access | |
| 17:02:53 | dansmith | yeah | |
| 17:03:09 | gmann | ok adding comment on the review for brinzhang_ | |
| 17:03:19 | sean-k-mooney | gibi: looking at that os-vif repo we have not merged any patches since we did the last release so i think we can stick with the 2.0.0 release for m3 which we created at m2 | |
| 17:04:22 | sean-k-mooney | gibi: if we do merge something between no and next week i can request a release but for now we are good. | |
| 17:14:48 | openstackgerrit | John Garbutt proposed openstack/nova master: Add reno for unified limits https://review.opendev.org/715271 | |
| 17:49:37 | gmann | dansmith: please let me your opinion on this, 'not expose the non-nova exception name to non-amdin' - https://review.opendev.org/#/c/694428/9/nova/objects/instance_action.py@200 | |
| 17:52:24 | dansmith | mnaser: right, which is why we hide the message now | |
| 17:52:41 | dansmith | mnaser: the question is whether or not hiding the actual name of the exception (i.e. LibvirtError) is a problem and I assert that it is not | |
| 17:53:22 | mnaser | dansmith: i agree with that, especially if its a libvirt-specific error | |
| 17:53:29 | mnaser | makes life easier | |
| 17:57:39 | sean-k-mooney | mnaser: to be fair the cve that we had in the past was not acatlly as sever as the bug suggested since the cpeh monitor details specifcaly the ip are also availabel to non admins via the attachment which they can see. but just reporting the name avoids that entirely | |
| 17:59:10 | sean-k-mooney | the only infomation leak that actully causes was the name of the ceph keyfile, still not ideal. | |
| 17:59:23 | sean-k-mooney | but that is fixed in that case at least | |
| 18:02:35 | gmann | mnaser: does any user ask about what driver you use for your cloud and my VM will be running on? before they buy :) | |
| 18:02:54 | gmann | or hypervisor | |
| 18:02:55 | openstackgerrit | Sasha Andonov proposed openstack/nova master: rbd_utils: increase _destroy_volume timeout https://review.opendev.org/705764 | |
| 18:03:03 | mnaser | gmann: i don't think we've actually ever had a customer ask what hypervisor/backend storage/etc | |
| 18:03:10 | sean-k-mooney | gmann: in principaly they should not care | |
| 18:04:00 | gmann | yeah, they should not. I was curious if they make the decision based on that. | |
| 18:04:24 | sean-k-mooney | they might make a dession based on specific features | |
| 18:05:08 | sean-k-mooney | which might only work with specific hyperviors but if vmware and libvirt but suppoted the features/api actions they cared about they proably would not care as long as there application worked fine | |
| 18:06:33 | sean-k-mooney | i mean i think aws uses xen in some from and google cloud suses some form of kvm with its own lightweight qemu alternitive but i dont think most people care when they use either product | |
| 18:08:38 | gmann | in one of our RFP, the customer asked to provide hypervisor-based choice to the user request of VM. not sure how good/bad/usable that was. | |