| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-02 | |||
| 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 | |
| 11:00:40 | justas_napa | Isn't this like allowing a user to choose an instance with 1G or 4G of RAM? | |
| 11:01:15 | sean-k-mooney | for example if we created a neutron qos policy that enabled (packeed queues, multi queue and 4 queue) | |
| 11:01:21 | sean-k-mooney | then the user could select that | |
| 11:01:24 | justas_napa | ant then allocating this instance on a server that has enough resources (in this case, a VF with required number of queues) | |
| 11:01:30 | sean-k-mooney | the operator is provideeing the hward ware knoladge | |
| 11:01:41 | sean-k-mooney | the user is jsut select the mutliqueue qos policy | |
| 11:02:10 | sean-k-mooney | justas_napa: if we did it ^ way | |
| 11:02:12 | sean-k-mooney | it woudl be | |
| 11:02:26 | sean-k-mooney | if we jsut put the number of quese in the bining profile its not | |
| 11:03:26 | frickler | gibi: ah, I'd rather see a fix than a pin, but anyway. also not sure how we actually py39 pins when we don't have them there globally | |
| 11:03:35 | justas_napa | I think we are aligned on the overall idea of implementation. The only question is the implementation. | |
| 11:05:01 | sean-k-mooney | i think you will need to build agreement between both nova and neutron to move this forward | |
| 11:05:06 | gibi | frickler: the above pin is for stable/yoga. I'm not sure we ever intended to test with unconstrained deps on stable | |
| 11:05:06 | sean-k-mooney | it will require 2 specs | |
| 11:05:26 | sean-k-mooney | justas_napa: and it will require quite a bit more designg work before it can proceed | |
| 11:05:47 | sean-k-mooney | justas_napa: im not against supprot multi queue with hardware offloead ovs | |
| 11:06:10 | sean-k-mooney | but just seting expectation that his is a lot more invoveld then your spec implies. | |
| 11:08:14 | frickler | gibi: right, let's discuss that in the requirements team. | |
| 11:08:31 | sean-k-mooney | justas_napa: have you read https://specs.openstack.org/openstack/nova-specs/specs/zed/approved/pci-device-tracking-in-placement.html | |
| 11:08:31 | gibi | frickler: sure | |
| 11:08:53 | sean-k-mooney | justas_napa: if not you shoudl read it in detail becasue your propoals will ahve to be compatable with that and its futrue direction | |
| 11:10:20 | sean-k-mooney | gibi: https://review.opendev.org/c/openstack/nova-specs/+/855514/ that would be good for you to add to your review list as the scdhuling aspecst will directly affect pci in placment eventually | |
| 11:11:47 | sean-k-mooney | justas_napa: have you spoken to the neutron team about this by the way | |
| 11:15:06 | sean-k-mooney | gibi: just reviewd https://review.opendev.org/c/openstack/placement/+/849348 form stephen. we are just pass FF bug this is a bug fix as far as im concerned so is it still ok to merge it | |
| 11:16:12 | gibi | sean-k-mooney: this is a bugfix so I'm OK to land it | |
| 11:16:19 | gibi | sean-k-mooney: bug we don't have the tracking bug for it | |
| 11:16:44 | gibi | bug/but | |
| 11:17:13 | sean-k-mooney | ya i noticed that. we dont always require it but it is nice to have. it would be a story because placment | |
| 11:17:31 | sean-k-mooney | i stongly dislike story broard | |
| 11:17:58 | sean-k-mooney | i suspect that is why stephen did not file one too | |
| 11:19:17 | sean-k-mooney | bauzas: any input ^ | |
| 11:19:31 | sean-k-mooney | or stephenfin if you are about | |
| 11:26:18 | elodilles | gibi: thanks, looks good! | |
| 11:29:15 | gibi | sean-k-mooney: I've added my immediate questions and suggestions the the smartnic mutiqueue spec | |
| 11:29:22 | gibi | thanks for the headsup | |
| 11:29:25 | elodilles | gibi: i just wonder why this does not affect master branch :-o | |
| 11:30:03 | gibi | elodilles: on master prettytable is pinned | |
| 11:30:08 | gibi | in upper constarints | |
| 11:30:13 | gibi | I think | |
| 11:30:13 | elodilles | oh, is it? :-o | |
| 11:30:34 | gibi | https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L141 | |
| 11:30:37 | gibi | it is | |
| 11:30:40 | gibi | without python version filter | |
| 11:30:44 | gibi | but on stable/yoga | |
| 11:30:54 | gibi | it is only pinned for py38 and py36 | |
| 11:31:07 | gibi | not for py39 | |
| 11:31:36 | gibi | the general issue that there is no py39 pins in upper constarints on stable/yoga is now raised in the requirements channel | |
| 11:32:44 | elodilles | for the record, this means whenever prettytable reqs will be bumped on master branch things will break on master as well :S | |
| 11:36:08 | opendevreview | Balazs Gibizer proposed openstack/nova master: Rename _to_device_spec_conf to _to_list_of_json_str https://review.opendev.org/c/openstack/nova/+/855648 | |
| 11:36:09 | opendevreview | Balazs Gibizer proposed openstack/nova master: Reproduce PCI pool filtering bug https://review.opendev.org/c/openstack/nova/+/855649 | |
| 11:36:09 | opendevreview | Balazs Gibizer proposed openstack/nova master: Strictly follow placement allocation during PCI claim https://review.opendev.org/c/openstack/nova/+/855650 | |
| 11:37:36 | gibi | elodilles: yes it was detected during the last weekend by frickler here https://zuul.opendev.org/t/openstack/build/2e4535d6aa2d4fd987ddfd0d0bc296d1 | |
| 11:37:48 | gibi | elodilles: and the master constraint was not bumped | |
| 11:38:01 | gibi | https://review.opendev.org/c/openstack/requirements/+/854862/2..3/upper-constraints.txt | |
| 11:40:02 | elodilles | yet | |
| 11:40:16 | elodilles | but we'll need to bump after some time | |
| 11:41:11 | elodilles | today is the Requirements Freeze date, so for Zed this is probably OK | |
| 11:42:15 | gibi | yes, I agree that we should do something on master | |
| 11:42:40 | gibi | I'm not sure at the moment that we need to directly adapt to the breaking change in a minor version or what | |