| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-02 | |||
| 09:31:44 | gibi | that is a good question | |
| 09:32:03 | gibi | I'm not sure I want to create a separate spec for the scheduling part | |
| 09:32:10 | gibi | that would need a lot of context building in the spec | |
| 09:32:20 | gibi | I would keep the whole thing in a single doc | |
| 09:32:32 | gibi | bauzas, sean-k-mooney: how do you feel about it? | |
| 09:32:41 | sean-k-mooney | well we will need to copy it to the right repo | |
| 09:32:45 | gibi | sure | |
| 09:32:47 | sean-k-mooney | and a few minor updates | |
| 09:32:56 | gibi | re-proposing it is OK | |
| 09:32:57 | sean-k-mooney | baiscaily startign her <=== | |
| 09:33:04 | sean-k-mooney | *here | |
| 09:33:06 | gibi | yes | |
| 09:33:09 | gibi | that is OK | |
| 09:33:15 | gibi | but I don't want to split and rewrite | |
| 09:33:53 | sean-k-mooney | ok i guess we can see what that looks like | |
| 09:34:28 | sean-k-mooney | so keep the same blueprint then for AA too | |
| 09:34:43 | sean-k-mooney | thats proably ok | |
| 09:34:52 | gibi | I'm OK to create a new bp if that helps tracking, but I don't want to create a totally new spec | |
| 09:35:37 | sean-k-mooney | ack lets just update the work items to mark what is left | |
| 09:36:15 | gibi | my plan sort term: 1) move the existing two FUPs to master and merge them before RC1 2) update the Zed spec and merge that 3) re-propose the spec to AA | |
| 09:37:18 | sean-k-mooney | sure ping me when those are ready to review | |
| 09:38:37 | gibi | ack, thanks | |
| 09:38:43 | opendevreview | John Garbutt proposed openstack/nova master: update default overcommit https://review.opendev.org/c/openstack/nova/+/830829 | |
| 09:39:54 | bauzas | gibi: sorry, dad taxi here, will reply later | |
| 09:42:07 | gibi | bauzas: no worries, it is not urgent | |
| 09:43:04 | sean-k-mooney | bauzas: gibi john just remmebered one of my patches https://review.opendev.org/c/openstack/nova/+/830829 | |
| 09:43:20 | sean-k-mooney | can we land that | |
| 09:45:48 | gibi | being at FF makes this comment https://review.opendev.org/c/openstack/nova/+/830829/3#message-12aca1ab8f202fbfa1793c458103055db16a67a5 pretty heavy | |
| 09:46:25 | sean-k-mooney | we punted this last feature freeze for the same reason | |
| 09:48:01 | sean-k-mooney | i orginally created the patch right at the end of yoga because we agreed to change it in the ptg and the person that raised it did not work on it | |
| 09:48:09 | sean-k-mooney | i had tought this already landed this cycle | |
| 09:48:32 | sean-k-mooney | if we delay it to AA i would like to merge it right after RC1 | |
| 09:48:48 | gibi | it sit with a -1 since Jul unfortunately | |
| 09:49:05 | sean-k-mooney | ya i forgot this existied | |
| 09:49:09 | sean-k-mooney | which is my bad | |
| 09:51:07 | gibi | one alternative I imagine is to merge it and at the same time check the effect of it very carefully and be ready to revert it before RC1 if we see anomalies in CI due to this | |
| 09:51:32 | auniyal | O/ | |
| 09:51:37 | sean-k-mooney | ya we could | |
| 09:51:47 | auniyal | for VM resize, why its required to run resize confirm | |
| 09:52:02 | sean-k-mooney | auniyal: becaue the resize might break the vm | |
| 09:52:15 | sean-k-mooney | resizing is changing the flavor | |
| 09:52:31 | auniyal | but how can I know, that it may break, I can verify | |
| 09:52:37 | sean-k-mooney | which may increase or deccreate the resouces allocated and may also change other aspect like numa toplogy or cpu pinning | |
| 09:52:58 | sean-k-mooney | yes if the vm is running before you resize it | |
| 09:53:04 | sean-k-mooney | in the resize verify status | |
| 09:53:08 | sean-k-mooney | you can ssh in | |
| 09:53:12 | sean-k-mooney | and check the vm | |
| 09:53:28 | sean-k-mooney | its in resize_verify when you need to conrim or revert | |
| 09:53:53 | auniyal | okay. while instance.status is verify_resize, we can go and check VM | |
| 09:54:07 | sean-k-mooney | yep that is why that state exists | |
| 09:54:11 | sean-k-mooney | for you to verify the vm | |
| 09:54:38 | sean-k-mooney | we have discused changing this and actully partly agree too but i have not had time to write the spec and work on it | |
| 09:55:35 | sean-k-mooney | its a nice UX feature enahcnment but not one that PM prioritiesed | |
| 09:57:18 | sean-k-mooney | https://etherpad.opendev.org/p/r.321f34cf3eb9caa9d87a9ec8349c3d29 | |
| 09:57:38 | sean-k-mooney | https://etherpad.opendev.org/p/r.321f34cf3eb9caa9d87a9ec8349c3d29#L613 | |
| 09:57:56 | sean-k-mooney | that is where we last discussed this if you want context of what we considerd changing. | |
| 09:59:53 | sean-k-mooney | whoami-rajat: hehe ^ last line of the agreement is "wait for the rebuild of bvf solution before we do the --image part" context is server recreate api/resize enhancements we discussed back in the wallaby ptg | |
| 10:06:30 | bauzas | gibi: what you can do is to use the same spec for Antelope | |
| 10:07:08 | bauzas | and just saying what you need to do in AA in the work items if you want | |
| 10:07:31 | gibi | bauzas: ack, I think this is aligned with sean-k-mooney's view. | |
| 10:07:31 | bauzas | this way, we should just accept again this spec for Antelope quickly | |
| 10:08:02 | gibi | OK | |
| 10:08:03 | gibi | thanks | |
| 10:10:10 | sean-k-mooney | auniyal: i ment to link this before https://docs.openstack.org/nova/latest/contributor/resize-and-cold-migrate.html | |
| 10:14:37 | opendevreview | Justas Poderys proposed openstack/nova-specs master: Improve multiqueue network adapter support https://review.opendev.org/c/openstack/nova-specs/+/855514 | |
| 10:18:32 | gibi | JayF, sean-k-mooney: I think I figured out the root cause of https://bugs.launchpad.net/nova/+bug/1988482 will push a requirements patch soon | |
| 10:23:35 | sean-k-mooney | ack i assume its sqlalcemey related or similar? | |
| 10:23:58 | sean-k-mooney | oh PrettyTable | |
| 10:24:18 | sean-k-mooney | did know tha was a thing we used | |
| 10:37:12 | justas_napa | Sorry for spamming the channel with proposals. Finally pass all syntax checks. While uploading our source changes we noticed that the codebase changes, we are porting the changes tp the latest and will uppload them in coming days. | |
| 10:38:35 | sean-k-mooney | justas_napa: is that the multi queue spec? | |
| 10:38:50 | sean-k-mooney | im reviewing it now and it has many issues form a design point of view | |
| 10:39:25 | justas_napa | yes it is. I'm open to discuss all issues | |
| 10:39:47 | sean-k-mooney | if we add support for multiqueue with hardware offloaded ovs i woudl exepct it to look differnt then you propose | |
| 10:42:20 | justas_napa | should we discuss your ideas here in IRC or rather in Gerrit? | |
| 10:42:58 | sean-k-mooney | im leaving commets in gerrit now | |
| 10:43:18 | sean-k-mooney | in general requesting the number of quese via the port binding profiel is not ok | |
| 10:43:29 | sean-k-mooney | you will need a new neutron extesion | |
| 10:43:36 | auniyal | ack, thanks sean-k-mooney | |
| 10:44:00 | sean-k-mooney | that will need a neutron spec and there will have to be a dicussion of if that shoudl be something that the operator defince and a user slects | |
| 10:44:05 | sean-k-mooney | kind of like qos polcies | |
| 10:44:12 | auniyal | I was looking this one https://docs.openstack.org/nova/ussuri/user/resize.html | |
| 10:44:13 | sean-k-mooney | or if the user should be able ot request quese | |
| 10:49:59 | justas_napa | in my PoV, it should be something that operator defines, because it is related to the underlying HW | |
| 10:50:21 | justas_napa | like a flavor of an instance | |
| 10:50:30 | sean-k-mooney | justas_napa: which is not compatible how openstack is ment to work | |
| 10:50:46 | sean-k-mooney | openstack is ment to be an cloud abstraction | |
| 10:51:21 | sean-k-mooney | there are some atribute that we can expsoe but low level hardware turnign is out of scope | |
| 10:51:44 | sean-k-mooney | justas_napa: what we can do is scudle based on how many quee are avaible with some constriats | |
| 10:52:07 | sean-k-mooney | and provide a way to ask for a VF with x queue | |
| 10:52:26 | justas_napa | yes, I think this would be OK | |
| 10:52:57 | sean-k-mooney | we can also have the libvirt driver do min(vf_queue,vcpus) | |
| 10:53:09 | sean-k-mooney | on a per interface basis | |
| 10:53:21 | justas_napa | that is actually a very good idea | |
| 10:53:54 | sean-k-mooney | those are the types of abstration that we need to build to make this useable in a openstack context. | |
| 10:54:16 | sean-k-mooney | where the end user does not know anything about the hardware and the operator knows nothing about the worklaod | |
| 10:55:20 | gibi | elodilles: JayF: sean-k-mooney: the requirement fix for the stable/yoga prettytable gate block https://review.opendev.org/c/openstack/requirements/+/855643 | |
| 10:57:04 | gibi | frickler: ^^ this is also related to the prettytable issue you reported last weekend | |
| 10:59:40 | justas_napa | but allowing to ask for VF w/ X queues meant that we expose the use to some kind of knowledge of underlying HW | |
| 11:00:36 | sean-k-mooney | it depens on how its done | |