| __ministry | Above bug happened when I do resize in same host compute. So, never had "it was not supported". Can you help me fix this bug? | 02:22 |
|---|---|---|
| plibeau | hello guys, I need your help on this change to merge also on neutron side: https://review.opendev.org/c/openstack/nova/+/861172 | 08:34 |
| opendevreview | Konrad Gube proposed openstack/nova-specs master: Re-propose using extend volume completion action for 2023.2 https://review.opendev.org/c/openstack/nova-specs/+/877233 | 08:39 |
| dvo-plv | Hello, Sean. I would like to discuss this blueprint https://review.opendev.org/c/openstack/neutron/+/869510 . Previously we implemented our separate linkvirt driver, but you prefer to move to the default openvswitch driver. We made our internal poc and published it to the opendev to simplify our discussion on how it would be better to be implemented | 09:03 |
| Uggla | gibi, hello, ouch you gave me a lot of homework. :) | 09:09 |
| bauzas | Uggla: fwiw, starting to review your series again :) | 09:12 |
| Uggla | bauzas, cool thanks. So I will wait for your comments before changing anything. | 09:13 |
| bauzas | ack | 09:14 |
| bauzas | Uggla: so, I have like the same concerns than gibi here | 09:51 |
| bauzas | the first patch is only getting a soft -1 because I'd want you to test some deletion behaviour | 09:52 |
| bauzas | apart from this, I'm OK | 09:52 |
| bauzas | now, I have more concerns for the objects patc | 09:52 |
| bauzas | patch | 09:52 |
| bauzas | it looks to me that we should discuss how to use this object between the services | 09:53 |
| bauzas | and what it could do | 09:53 |
| Uggla | bauzas, ok | 10:27 |
| bauzas | Uggla: I need to get my daughter in 10 mins but we can discuss that in the afternoon if you want | 10:28 |
| Uggla | ok sounds good | 10:28 |
| bauzas | I'll ping you later around 2pm CET | 10:29 |
| opendevreview | Rajesh Tailor proposed openstack/nova master: Fix duplicate cell creation with same name https://review.opendev.org/c/openstack/nova/+/876940 | 10:47 |
| dvo-plv | @sean-k-mooney, are you here ? | 12:05 |
| sean-k-mooney | o/ | 12:10 |
| sean-k-mooney | dvo-plv: hi yes i am | 12:11 |
| dvo-plv | I would like to discuss this blueprint https://review.opendev.org/c/openstack/neutron/+/869510 . Previously we implemented our separate linkvirt driver, but you prefer to move to the default openvswitch driver. We made our internal poc and published it to the opendev to simplify our discussion on how it would be better to be implemented | 12:15 |
| dvo-plv | btw, I can not figure out, how to mention user here? | 12:15 |
| sean-k-mooney | as in to ping people | 12:16 |
| sean-k-mooney | on irc | 12:16 |
| sean-k-mooney | or something else | 12:16 |
| dvo-plv | yes, how to ping pople here. How do you do it with me? | 12:19 |
| sean-k-mooney | just dvo-plv or dvo-plv: | 12:19 |
| sean-k-mooney | dvo-plv: so like this | 12:19 |
| sean-k-mooney | does that highlight for you | 12:19 |
| sean-k-mooney | basicaly most client auto highlight on the nic you are connected with and you can configure others | 12:20 |
| dvo-plv | i see, thank you | 12:20 |
| sean-k-mooney | the : at the end generally gets added if you tab complete but it shoudl not be required | 12:21 |
| dvo-plv | so ,if you have a time, I would like to discuss solution how to support our nic propperly | 12:21 |
| sean-k-mooney | my client will match on my nic regardless or prefix or sufix | 12:21 |
| sean-k-mooney | dvo-plv: so im in two minds | 12:21 |
| sean-k-mooney | if you intend to someday upstream supprot for your nic to vanilla ovs then it should be in the generic openvswich/ovn drivers in tree | 12:22 |
| sean-k-mooney | if you plan to maintain a fork then your orginal approch is fine | 12:22 |
| sean-k-mooney | in general if the way you connect to a network backend it common acorrss vendors we like to have only one implemation of that | 12:23 |
| sean-k-mooney | in your specific case i see there are some special requriements around the name of the vhost-user socket | 12:23 |
| sean-k-mooney | i suspect that is specific to your vswith implmation | 12:24 |
| dvo-plv | yes, we have our own dpdk driver what requires some specific moments | 12:25 |
| sean-k-mooney | as currently written i think your patch might break the exiting virtio-forwarder code | 12:26 |
| dvo-plv | when you are talking about original approach. You mean separate driver or implementation support with openvswitch | 12:26 |
| sean-k-mooney | when i was suggesting using a singel ml2/driver for both i was suggesting ensuring your nic works with the dpdk_user supprot in vaniall ovs | 12:27 |
| sean-k-mooney | and i was asking if that was what you were trying to enable | 12:27 |
| sean-k-mooney | the answer to the second quetion is no | 12:27 |
| sean-k-mooney | you are not trying to enabel to upstream ovs feature | 12:28 |
| sean-k-mooney | your are trying to enable your vendor specific version | 12:28 |
| sean-k-mooney | in which case usign an out of tree ml2 dirver is appropreiate | 12:28 |
| sean-k-mooney | that way you do not need to worry about compatiablity with netonomes implamation of virtio forward | 12:28 |
| sean-k-mooney | nova just uses the vhost-user path provided by neutron so as long as you set it to the correct value that should be transparent to nova | 12:29 |
| sean-k-mooney | dvo-plv: have dpdk removed or raised the limit on dpdk type ports above 32 yet | 12:32 |
| sean-k-mooney | dvo-plv: what i would suggest is adding a VIF_DETAILS_VHOSTUSER_NAPATECH_PLUG | 12:37 |
| sean-k-mooney | so in the port binding details set a flag to indicate taht its napatech | 12:37 |
| sean-k-mooney | continue to use vnic_type=vritio-forwarder | 12:38 |
| justas_napa | Hi. To answer the question regarding ovs support - it really depends on the end user requirements | 12:39 |
| sean-k-mooney | in nova check for both and in a new if in os_vif_util implement the logic you require | 12:39 |
| justas_napa | we maintain our own OvS to support features like QinQ and some special QoS schemes | 12:40 |
| sean-k-mooney | justas_napa: the in tree ml2/ovs and ml2/ovn dirver are only ment to supprot ovs form openvsiwtch.org | 12:40 |
| sean-k-mooney | so if the basic virtio-forward fucntionality is not upstream to vanilla ovs it should be in a seperatem ml2 driver and os_vif driver | 12:41 |
| justas_napa | I think we are OK to limit ourselves to vanilla ovs | 12:41 |
| justas_napa | unless adding support for our own OVS is trivial | 12:41 |
| sean-k-mooney | well vaniall ovs has two ways to enabel vhost-user but the proposal is not using either of them | 12:42 |
| sean-k-mooney | https://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/ | 12:42 |
| sean-k-mooney | instead you are created dpdk vdevs https://docs.openvswitch.org/en/latest/topics/dpdk/vdev/ | 12:43 |
| sean-k-mooney | there is supprot for dpdk representor prots | 12:44 |
| justas_napa | so then it's custom ml2 and os_vif driver | 12:45 |
| sean-k-mooney | https://docs.openvswitch.org/en/latest/topics/dpdk/phy/#representors | 12:45 |
| sean-k-mooney | am i think so. | 12:46 |
| justas_napa | yes, we are heavy users of representors | 12:46 |
| sean-k-mooney | if you go with the out of tree ml2/os-vif drivers then all that is requried in nova is a minor change to call them | 12:46 |
| sean-k-mooney | so ok maybe we need to level set | 12:46 |
| sean-k-mooney | justas_napa: the dpdk type port that you are creating for use with virio-forward | 12:47 |
| sean-k-mooney | is that a vf representor | 12:47 |
| sean-k-mooney | as descirbed here https://docs.openvswitch.org/en/latest/topics/dpdk/phy/#representors | 12:47 |
| justas_napa | yes | 12:47 |
| justas_napa | becuase all dataplane is offloaded to FPGA | 12:47 |
| sean-k-mooney | ok so if that is what we are enableing and the supprot in upstream ovs also works with your nics we can enabel that in the intree support | 12:48 |
| sean-k-mooney | so next question you require the vhost-user socket path to have a specific format to corralate teh vhost-user path to the dpdk representor correct | 12:48 |
| justas_napa | I don't think we require specific path, just the socket name | 12:49 |
| sean-k-mooney | the orginal requriements when vhsot-user was first added to ovs was the socket path's final segment and port name must be the same | 12:49 |
| sean-k-mooney | right so for normal vhost-user when it was first added the socket-name and port name had to be the same | 12:50 |
| sean-k-mooney | later we added a socket path to ovs to remove that limiation as part of supproting vhost-user-client mode where qemu is the server | 12:50 |
| justas_napa | -chardev socket,id=char0,path=/usr/local/var/run/stdvio5,server | 12:51 |
| justas_napa | so we are flexible on thje path, but the last part is stdvio<#VF> | 12:51 |
| sean-k-mooney | ya so your dirver breaks the convention that the final segment of the name matches the name of the ovs port which is fine | 12:52 |
| sean-k-mooney | ack | 12:52 |
| sean-k-mooney | https://review.opendev.org/c/openstack/neutron/+/869510/2/neutron/plugins/ml2/drivers/openvswitch/mech_driver/mech_openvswitch.py#217 | 12:52 |
| sean-k-mooney | so that is why you need this code | 12:52 |
| justas_napa | yep | 12:53 |
| sean-k-mooney | so the problem i see is the pci_slot is always going to be set for vnic_type virtio-forwarder | 12:53 |
| sean-k-mooney | but we only want to take the else branch if its napatech | 12:53 |
| sean-k-mooney | so ninstead of the current if we shoudl add a config value to the agent and check if that is set | 12:54 |
| sean-k-mooney | so just like | 12:54 |
| sean-k-mooney | sockdir = agent['configurations'].get('vhostuser_socket_dir', | 12:54 |
| sean-k-mooney | ovs_const.VHOST_USER_SOCKET_DIR) | 12:54 |
| sean-k-mooney | you shoudl add something like sockdir = agent['configurations'].get('vhostuser_socket_name_scheme','port_name') | 12:55 |
| sean-k-mooney | and for napatech you woudl set vhostuser_socket_name_scheme to VF_index | 12:55 |
| sean-k-mooney | or something liek that | 12:55 |
| justas_napa | OK | 12:55 |
| justas_napa | dvo-plv - does this work for us? | 12:56 |
| sean-k-mooney | i need to think about the nova patch a bit but i think if you do that the nova patch is fine as is | 12:57 |
| justas_napa | ack | 12:57 |
| sean-k-mooney | well it needs test but the core functionality is proably correct | 12:57 |
| dvo-plv | in our solution, socket name value is depends on the pci slot | 12:58 |
| dvo-plv | This value vhostuser_socket_name_scheme will be located at the neutron conf file | 12:58 |
| sean-k-mooney | yes used by the neutron_l2_agent | 12:59 |
| sean-k-mooney | it will need to get added to the agent report | 12:59 |
| sean-k-mooney | which will make it avaiable to the ml2 driver during binding | 12:59 |
| sean-k-mooney | like this https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L379-L380 | 13:00 |
| sean-k-mooney | its how we pass the per host vhostuser_socket_dir and datapath_type info today | 13:00 |
| sean-k-mooney | dvo-plv: looking at teh os-vif code i think that is also ok just needs tests | 13:01 |
| sean-k-mooney | justas_napa: dvo-plv my concern basically is if we enable this and we use vaniall ovs-dpdk will it still work | 13:02 |
| dvo-plv | So, instead of extending ovs with virtio-forwarder, you suggest to add new parameter ( socket scheme ) and we will create port with vhost user vif type, and based on a new parameter, it will affect socket path | 13:03 |
| justas_napa | as long as user does not try to setup qinq and advance qos, it will work | 13:03 |
| sean-k-mooney | dvo-plv: not quite | 13:03 |
| sean-k-mooney | dvo-plv: keep your ml2/ovs driver patch as it is using virtio-forwarder | 13:03 |
| sean-k-mooney | i think that is the correct vnic_type | 13:03 |
| sean-k-mooney | im suggesting not basing the format on if the pci_slot it set | 13:04 |
| sean-k-mooney | we shoudl either have a config option for it or base it on vnic_type virtio-forwarder | 13:04 |
| sean-k-mooney | im just checkign something | 13:04 |
| sean-k-mooney | we might not need to modify your patches at all | 13:05 |
| dvo-plv | I see, make this function agent_vhu_sockpath able to change the structure of socket's name if it is specified in the config file | 13:06 |
| sean-k-mooney | yep | 13:06 |
| sean-k-mooney | so im trying to make sure we dont break agilio_ovs in the process of enabling napatech | 13:07 |
| sean-k-mooney | im just checkign how we determin its agilio_ovs today in nova | 13:07 |
| sean-k-mooney | ok your current patch shoudl be ok as is | 13:08 |
| sean-k-mooney | they use a seperate vif_type | 13:08 |
| sean-k-mooney | justas_napa: dvo-plv: so based on the refactoring that you have already done following my intial feedback | 13:09 |
| sean-k-mooney | i think the current solution shoudl be generic enough to work as is | 13:09 |
| sean-k-mooney | we dont have any exsiting use of vif_type=ovs and virtio-forwarder | 13:09 |
| sean-k-mooney | we can add a comment that if we need a diffent nameing scheme in the futrue then a config option can be added at that point | 13:10 |
| justas_napa | I'm not sure I follow | 13:11 |
| justas_napa | do you think we need further updates | 13:11 |
| justas_napa | or are we going as-is? | 13:11 |
| sean-k-mooney | justas_napa: let me rephase. your code is fine as is it just need tests and docs | 13:11 |
| justas_napa | OK | 13:11 |
| sean-k-mooney | ill try and review the spec this week. if i have not done so by thrusday ping me | 13:12 |
| dvo-plv | We need to update spec file accodring this concept, I will ping you when it will be ready | 13:13 |
| sean-k-mooney | my general feedback is we need test to go along with the functional changes you have made and based on a quick review of the surrounding code and the questions you answered here i think the current approch is correct | 13:13 |
| sean-k-mooney | so the spec is pretty light on detail in general | 13:15 |
| sean-k-mooney | it would be good to update it with links to https://docs.openvswitch.org/en/latest/topics/dpdk/phy/#representors | 13:15 |
| sean-k-mooney | since that is really what you are tryign to enable | 13:15 |
| justas_napa | sure. will do | 13:16 |
| sean-k-mooney | i was hevially invovled in enabling dpdk supprot in openstack in general so most of the other core reviews dont have the same levle of context that i have | 13:16 |
| plibeau | bauzas: thx for the review, I have reply on your comment. https://review.opendev.org/c/openstack/nova/+/861172 | 13:21 |
| sean-k-mooney | justas_napa: dvo-plv: one general comment on the spec (this is hard to get right by the way) the spec is intended to capture all the info require so that if you could not complete the feature someone else with a familararity with nova could compelte it. given the code is already written and looks mostly correct what you shoudl really focus on is providing enouch context for | 13:22 |
| sean-k-mooney | nova reviews who dont really have famiariaty with ovs/dpdk/vf representors. basically add som short context paragraphs explaing what the technology is and how you are reusing/extendign the existing functionaly in nova/os-vif so that its simpler for other cores to review. | 13:22 |
| dvo-plv | yes, sure, we will process this comment | 13:24 |
| dvo-plv | I have some concenrs about this patch https://review.opendev.org/c/openstack/os-vif/+/859574/4/vif_plug_ovs/ovs.py How properly we should pass scheme to the os-vif, it hould be part of the vif in _plug_vf method? | 13:24 |
| jrosser | should HW_ARCH_* trait be automatically set on compute hosts? | 13:29 |
| sean-k-mooney | dvo-plv: we should be able to just pass the vhost-user socket path | 13:31 |
| sean-k-mooney | jrosser: ideally yes but i don tknow if the libvirt driver does that today | 13:32 |
| jrosser | my test suggests that for Z they're not there | 13:33 |
| sean-k-mooney | then that was likely not implemtned | 13:34 |
| *** d34dh0r5- is now known as d34dh0r53 | 13:45 | |
| opendevreview | sean mooney proposed openstack/nova stable/xena: Nova resize don't extend disk in one specific case https://review.opendev.org/c/openstack/nova/+/877260 | 13:47 |
| opendevreview | sean mooney proposed openstack/nova stable/wallaby: Nova resize don't extend disk in one specific case https://review.opendev.org/c/openstack/nova/+/877284 | 13:50 |
| dvo-plv | sean-k-mooney: does it will be flexible for another usage, if we pass socket path and parse it, getting vf_num for representor port | 13:55 |
| dvo-plv | I mean that we add additional parameter to the neutron conf to get abiltiy set scheme for socket name to add some flexibility | 13:56 |
| dvo-plv | https://review.opendev.org/c/openstack/os-vif/+/859574/4/vif_plug_ovs/ovs.py#307 | 13:57 |
| dvo-plv | here | 13:57 |
| bauzas | Uggla: sorry I said to you that we could discuss about your series at 2 pm CET, but I was doing another stuff, do you want to discuss this now ? | 14:11 |
| Uggla | bauzas, yes it is possible | 14:11 |
| bauzas | cool | 14:12 |
| bauzas | Uggla: (and other people wanting to discuss at https://review.opendev.org/c/openstack/nova/+/839401/24) meet.google.com/cah-soio-ard | 14:13 |
| bauzas | shit | 14:13 |
| bauzas | https://meet.google.com/cah-soio-ard | 14:13 |
| opendevreview | Dan Smith proposed openstack/nova-specs master: Add compute-object-ids spec for 2023.2 https://review.opendev.org/c/openstack/nova-specs/+/877291 | 15:11 |
| dansmith | bauzas: you ready for a 2023.2 specs directory patch? | 15:20 |
| bauzas | dansmith: we should already have it | 15:23 |
| bauzas | amirite ? | 15:23 |
| dansmith | is it proposed? | 15:23 |
| sean-k-mooney | https://github.com/openstack/nova-specs/tree/master/specs/2023.2 | 15:24 |
| sean-k-mooney | its merged | 15:24 |
| dansmith | wtf, I just fetched and had to create it myself | 15:24 |
| dansmith | hrm, okay | 15:25 |
| dansmith | must'n'tve worked or something | 15:25 |
| sean-k-mooney | i assume your working on the set service_id in compute node table spec | 15:25 |
| dansmith | yeah ^ | 15:26 |
| sean-k-mooney | cool | 15:26 |
| dansmith | I'm realizing maybe I should have tried harder to get this second phase into 2023.1 because of the SLURP rules, but oh well | 15:31 |
| tobias-urdin | sean-k-mooney: if you have some time over this week can you check the mdev naming fixes proposed to stable branches, starting with zed https://review.opendev.org/c/openstack/nova/+/866152 and the parent patch and cherry-picks w/ parents, ty! | 15:37 |
| bauzas | tobias-urdin: I think I said +2 for stable/zed, right? | 16:01 |
| bauzas | correct, so we need one stable core ^ | 16:01 |
| tobias-urdin | bauzas: yes! just need more, then moving on the the cherry-picks to older releases | 16:01 |
| bauzas | ++ | 16:10 |
| opendevreview | Dan Smith proposed openstack/nova-specs master: Add compute-object-ids spec for 2023.2 https://review.opendev.org/c/openstack/nova-specs/+/877291 | 16:12 |
| * bauzas ends his day now, see you tomorrow | 17:11 | |
| opendevreview | Merged openstack/nova master: Unbind port when offloading a shelved instance https://review.opendev.org/c/openstack/nova/+/853682 | 18:04 |
| gmann | elodilles: fixed your comment, please check https://review.opendev.org/q/I4e3e5732411639054baaa9211a29e2e2c8210ac0+status:open | 18:31 |
| elodilles | gmann: looking | 18:39 |
| gmann | thanks | 18:42 |
| elodilles | looks good, thanks! | 18:53 |
| opendevreview | Ghanshyam proposed openstack/nova master: DNM: testing 2023.1|2 unit tests job template https://review.opendev.org/c/openstack/nova/+/877320 | 19:09 |
| opendevreview | Ghanshyam proposed openstack/nova stable/2023.1: DNM: testing 2023.1|2 unit tests job template https://review.opendev.org/c/openstack/nova/+/877262 | 19:10 |
| opendevreview | Ghanshyam proposed openstack/nova stable/zed: DNM: testing 2023.1|2 unit tests job template https://review.opendev.org/c/openstack/nova/+/877263 | 19:10 |
| gibi | Uggla: what am I missing. I try to test your manial series I have an active nfs share in manila. I have a stopped VM in nova. When I associate the share with the VM the compute tries to mount the share but it seems it stuck. https://paste.opendev.org/show/bFyX8c5xjnPQdPk9YEiK/ I also tried to manually mount on the host but that also stucks | 19:10 |
| gibi | Uggla: btw after the API time outs the share remains in "inactive" state in nova side so I think nova thinks that the mount was successfully but it probably isn't: https://paste.opendev.org/show/bQlQVJaLOF1fhfuQR6ND/ | 19:15 |
| gibi | Uggla: then when I start the VM with openstack server start it happily starts up an uses the empty directory as the share where the nfs share should have been mounted | 19:17 |
| gibi | so it looks everything is OK but in the other hand the VM now has write access to a hypervisor directory without size limites | 19:18 |
| gibi | Uggla: I can also confirm my suspicion that if an active VM with an active share is being deleted then we leak the active share_mapping in the DB and therefore probably leaking the mount on the hypervisor too https://paste.opendev.org/show/bs44BjHHcFkICNNlqw9R/ | 19:22 |
| gibi | I cannot confirm the latter as I cannot mount the share in the first place | 19:22 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!