| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-11-17 | |||
| 14:41:53 | tkajinam | (tooz patch need further work because we first need a new release of etcd3gw... | |
| 14:41:57 | bauzas | sounds a good path to me | |
| 14:42:32 | bauzas | we may ban the current tooz release and just await for a newer release once everything is fine | |
| 14:42:38 | jangutter | tkajinam: one question - if etcd gets updated (v3alpha disappears and v3 appears) - would this case be handled? | |
| 14:44:33 | tkajinam | jangutter, yes. with that code etcd checks the etcd server version using version api and use the latest api version available | |
| 14:44:47 | tkajinam | jangutter, though you may need to restart servers because the detected api is cached after the first detection. | |
| 14:44:57 | tkajinam | s/servers/services/ I mean | |
| 14:45:10 | tkajinam | s/etcd checks/tooz checks/ | |
| 14:45:44 | jangutter | takjinam: so it will appear if cinder "remembers" the version of etcd it first connected to and never try a newer version? | |
| 14:46:37 | tkajinam | there is tradeoff. we can let tooz check api version every time but it always requires additional api call | |
| 14:46:47 | tkajinam | we may probably implement expire but I'd leave it for now | |
| 14:46:58 | tkajinam | jangutter, I probably had to say this first. yes, you are correct | |
| 14:49:19 | jangutter | tkajinam: yeah, gracefully redetecting the endpoint on error is also another option, that adds time to report errors. | |
| 14:50:40 | jangutter | but this covers 95% of the pain. | |
| 14:58:08 | tkajinam | https://bugs.launchpad.net/python-etcd3gw/+bug/2043810 | |
| 14:59:01 | tkajinam | I've created a bug here... in case you want something you can refer to | |
| 14:59:04 | tkajinam | jangutter, we can discuss how we can realize the automated switch without restart, but I'd prefer leaving it for follow-up. | |
| 15:00:05 | jangutter | tkajinam: right, I'm fine with just documenting the behavior (i.e. we expect dependent services to be restarted on etcd upgrade) | |
| 15:04:38 | jangutter | (that's a much more reasonable expectation than requiring operators to update etcd + tooz in lockstep. | |
| 15:15:17 | tonyb | bauzas: You probably need to remove your -W on 901079 | |
| 15:15:36 | bauzas | ack I will | |
| 15:49:43 | bauzas | dansmith: before I shutdown for the weekend and before your PTOs, just a quick question about https://review.opendev.org/c/openstack/nova/+/899625 | |
| 15:50:39 | bauzas | for non-SRIOV GPUs, shall we cap the total of the inventory by the max_instances or should we rather provide total=0 if the GPU has more than the max ? | |
| 15:51:03 | bauzas | for example, a GPU type supporting 8 vGPUs | |
| 15:51:10 | bauzas | and the operator saying max_instances=2 | |
| 15:51:34 | bauzas | shall we then accept one GPU and providing a total=2 or should we rather not accept it? | |
| 15:51:41 | dansmith | we can't *actually* have total=0 right? | |
| 15:51:53 | bauzas | we can now | |
| 15:52:06 | bauzas | with https://review.opendev.org/c/openstack/nova/+/899625/4/nova/virt/libvirt/driver.py | |
| 15:52:16 | bauzas | I'm just writing the unittests | |
| 15:52:20 | dansmith | right but that's just internally, placement won't allow it right? | |
| 15:52:49 | bauzas | dansmith: if we would say total=0 then the driver would ask to remove the GPU | |
| 15:53:10 | dansmith | right, so just internal notation for us to know what to do when we update placement | |
| 15:53:22 | dansmith | I guess I'm not sure what you're asking then | |
| 15:53:38 | bauzas | okay, then nevermind | |
| 15:53:51 | bauzas | I'll create a test and we'll discuss with gerrit | |
| 15:53:59 | dansmith | I was also going to ask on that patch why you continue to have providers above the limit, but with total=0, but I thought maybe that was related to cleanup for people who already have more providers than they should | |
| 15:54:05 | dansmith | okay | |
| 15:54:07 | bauzas | tbc, sriov gpus only have a total=1 for each of the VFs | |
| 15:54:23 | bauzas | so it's simple | |
| 15:54:34 | bauzas | either we accept a VF or we don't | |
| 15:54:57 | bauzas | but for non-sriov gpus, we can have a capacity for say 8 or 16 | |
| 15:55:12 | bauzas | so we create an inventory with a total=16 | |
| 15:55:39 | bauzas | now, the question is, what would happen if the operator would add a max_instances value for the type ? | |
| 15:55:57 | dansmith | just total=min(actual, max_instances) right? | |
| 15:56:10 | bauzas | that's my question | |
| 15:56:15 | dansmith | why not? | |
| 15:56:25 | bauzas | because for the moment, we have https://review.opendev.org/c/openstack/nova/+/899625/4/nova/virt/libvirt/driver.py#8144 | |
| 15:56:36 | bauzas | we calculate per GPU (or VF) | |
| 15:57:09 | bauzas | and if the number of possible vGPU for it is above the max_instances value, then we eventually say "heh, no, total=0" | |
| 15:57:18 | bauzas | so we don't really cap the GPU, we rather don't accept it | |
| 15:57:28 | bauzas | which is fine too | |
| 15:57:46 | dansmith | oh I see, you're saying your current patch doesn't add the inventory _at_all_ if they specify max_instances<total instead of just capping it? | |
| 15:58:01 | dansmith | I didn't pick up on that when I looked, but.. why would we do that? | |
| 15:58:28 | dansmith | isn't the point of this to be able to say "I know it says 16 available, but we can really only allocate 2 of this mdev_type because it takes so much of the card's resource" ? | |
| 15:58:40 | dansmith | if you don't allow them to set max_instances below total, we lose the ability to do that, no? | |
| 15:59:05 | bauzas | you know what ? I can upload my change | |
| 15:59:11 | bauzas | I'm done with the unitteests | |
| 15:59:45 | bauzas | I can create a functional test (and I want to) but for the sake of discussing, let me just upload it now | |
| 16:00:13 | opendevreview | Sylvain Bauza proposed openstack/nova master: WIP: libvirt: Cap with max_instances GPU types https://review.opendev.org/c/openstack/nova/+/899625 | |
| 16:01:57 | dansmith | okay, but .. the above question is what I need answered to really say anything... | |
| 16:02:33 | dansmith | but I can put that comment in gerrit if you prefer | |
| 16:04:19 | opendevreview | Sylvain Bauza proposed openstack/nova master: WIP: libvirt: Cap with max_instances GPU types https://review.opendev.org/c/openstack/nova/+/899625 | |
| 16:04:28 | bauzas | dansmith: I added some comments ^ | |
| 16:04:53 | dansmith | okay I'll just drop this comment/question in gerrit and we can iterate from there.. I have a call starting in a bit anyway | |
| 16:05:51 | bauzas | dansmith: fwiw, haven't seen your comments from PS4 but we run the periodic just after starting the service | |
| 16:05:56 | bauzas | so this works | |
| 16:06:33 | bauzas | given operators would modify the option, they would restart the nova-compute service so it will then delete the non-needed inventories then | |
| 16:07:11 | dansmith | yeah, but we may have boot requests pending for us when we start, and it means we're technically doing the cleanup on each run right? | |
| 16:17:57 | bauzas | dansmith: that's a tradeoff but I see your point | |
| 16:18:26 | bauzas | we could force a update_rp() right after init_host in the compute manager before we run RPC | |
| 16:18:41 | bauzas | but I think the problem is the same for all things | |
| 16:19:53 | bauzas | oh wait | |
| 16:20:17 | bauzas | https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L1778 | |
| 16:20:20 | bauzas | we're fine then | |
| 16:22:13 | bauzas | I just replied | |
| 16:22:23 | bauzas | anyway, I'll need to go errand | |
| 16:22:34 | bauzas | my patch is up, with a proposition | |
| 16:23:06 | bauzas | an alternative could be to cap the GPU inventory instead of refusing it as a whole, but meh, people can review | |
| 16:23:22 | bauzas | I'll add functests on Monday when I'm back | |
| 16:26:43 | dansmith | ack | |
| 23:36:33 | tonyb | bauzas: your revert has merged | |
| #openstack-nova - 2023-11-18 | |||
| 14:48:46 | opendevreview | Merged openstack/nova master: Fix missing oslo.versionedobjects library option https://review.opendev.org/c/openstack/nova/+/890718 | |
| 15:18:53 | opendevreview | Takashi Kajinami proposed openstack/os-vif master: Deprecate Windows support https://review.opendev.org/c/openstack/os-vif/+/901382 | |
| 17:37:29 | opendevreview | Takashi Kajinami proposed openstack/os-vif master: Deprecate Windows support https://review.opendev.org/c/openstack/os-vif/+/901382 | |
| #openstack-nova - 2023-11-19 | |||
| 13:49:22 | opendevreview | Merged openstack/nova master: Fix wrong description about minimum values https://review.opendev.org/c/openstack/nova/+/874061 | |
| #openstack-nova - 2023-11-20 | |||
| 09:36:53 | opendevreview | Takashi Kajinami proposed openstack/os-vif master: Clean up remaining python 2.7 support https://review.opendev.org/c/openstack/os-vif/+/896598 | |
| 09:36:58 | opendevreview | Takashi Kajinami proposed openstack/os-vif master: Clean up remaining python 2.7 support https://review.opendev.org/c/openstack/os-vif/+/896598 | |
| 10:40:19 | tkajinam | wondering if placement can/should be added to https://docs.openstack.org/project-team-guide/stable-branches.html#project-teams-which-asserted-they-follow-the-stable-branch-policy | |
| 12:26:05 | opendevreview | Rajesh Tailor proposed openstack/python-novaclient master: Fix typos https://review.opendev.org/c/openstack/python-novaclient/+/901457 | |
| 12:42:12 | opendevreview | Takashi Kajinami proposed openstack/nova master: Detect maximum number of SEV guests automatically https://review.opendev.org/c/openstack/nova/+/899381 | |
| 12:42:58 | opendevreview | Takashi Kajinami proposed openstack/nova master: Detect maximum number of SEV guests automatically https://review.opendev.org/c/openstack/nova/+/899381 | |
| 12:44:13 | opendevreview | Takashi Kajinami proposed openstack/nova master: Detect maximum number of SEV guests automatically https://review.opendev.org/c/openstack/nova/+/899381 | |
| 12:48:05 | opendevreview | Takashi Kajinami proposed openstack/nova master: Detect maximum number of SEV guests automatically https://review.opendev.org/c/openstack/nova/+/899381 | |
| 12:54:32 | sahid | o? | |
| 12:54:36 | sahid | o/ | |
| 12:54:50 | sahid | if some of you have a moment to look at this one: https://review.opendev.org/c/openstack/nova/+/896512 | |
| 12:55:11 | sahid | bauzas, dansmith ^ you already have context on it :-) | |
| 14:01:22 | opendevreview | Danylo Vodopianov proposed openstack/nova master: Packed virtqueue support was added. https://review.opendev.org/c/openstack/nova/+/876075 | |
| 14:27:38 | sean-k-mooney | sahid: before proceeding with that i would like you to justify why we cant just do this with https://docs.openstack.org/nova/latest/admin/aggregates.html#tenant-isolation-with-placement | |