| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-02 | |||
| 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 | |
| 11:43:29 | gibi | as I haven't looked it into what exactly changed in prettytable and what our test expects exacltly | |
| 11:43:40 | elodilles | yepp, i also don't know whether this is a feature or a bug in prettytable :) | |
| 11:43:46 | gibi | exactly | |
| 11:43:59 | justas_napa | sean-k-mooney: sorry for a late reply, work meeting. No, I have not talked with Neutron yet, I check the proposal you've linked. | |
| 11:43:59 | auniyal | I am getting lot of these - http://pastebin.test.redhat.com/1072393, for unknown reason | |
| 11:44:39 | auniyal | flavour is available, I can see it user openstack flavor show, but still .... | |
| 11:44:45 | gibi | auniyal: you have to put that into a public pastebin as the linked one is RH internal | |
| 11:44:56 | gibi | ie. you can use https://paste.opendev.org/ | |
| 11:45:44 | gibi | I can look at it as I'm in RH but like elodilles cannot | |
| 11:46:15 | auniyal | thanks, gibi, sure will use opendev | |
| 11:46:29 | auniyal | copied here as well - https://paste.opendev.org/show/bDpuAInn7ZW6bETeUVjU/ | |
| 11:48:58 | gibi | auniyal: GET /flavors/ |
|