| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-03-10 | |||
| 18:16:02 | sean-k-mooney | no i think we dont care about the casing but not sure | |
| 18:16:15 | sean-k-mooney | if you have that version of qemu i think it will be able to boot | |
| 18:17:19 | sean-k-mooney | my guess is you dont have the request filter enabled? | |
| 18:17:56 | sean-k-mooney | do you have teh transform_image_metadata prefilter enabled | |
| 18:18:31 | sean-k-mooney | [scheduler]image_metadata_prefilter | |
| 18:18:40 | sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#scheduler.image_metadata_prefilter | |
| 18:18:55 | sean-k-mooney | that is what enforce the host selection | |
| 18:20:45 | sean-k-mooney | as far as i am aware emulation is enabeld by default if you have the binary avaiable | |
| 18:21:36 | sean-k-mooney | at least without enable the prefilter | |
| 18:21:49 | sean-k-mooney | we should turn that prefilter on by default | |
| 18:21:52 | jrosser | ok i will look at the prefilter | |
| 18:21:57 | sean-k-mooney | but we dont currently | |
| 18:22:06 | jrosser | i want it to not schdule at all to x86 when i have real arm nodes | |
| 22:03:09 | opendevreview | Tyler Stachecki proposed openstack/nova master: nova-scheduler: Encourage weighers to spread https://review.opendev.org/c/openstack/nova/+/876289 | |
| #openstack-nova - 2023-03-11 | |||
| 01:02:02 | gmann | artom: commented on bug as well in gerrit, this is API backward incompatible change and cannot be done without microversion. lock APi already fixed this in 2.73 and we cannot fix it for older microversion due to backward compatibility https://review.opendev.org/c/openstack/nova/+/875653 | |
| 01:06:05 | opendevreview | Ghanshyam proposed openstack/osc-placement stable/zed: Use pypi released version of placement in functional tests https://review.opendev.org/c/openstack/osc-placement/+/869753 | |
| 01:10:35 | opendevreview | Ghanshyam proposed openstack/osc-placement stable/yoga: Use pypi released version of placement in functional tests https://review.opendev.org/c/openstack/osc-placement/+/869754 | |
| 01:11:20 | opendevreview | Ghanshyam proposed openstack/osc-placement stable/xena: Use pypi released version of placement in functional tests https://review.opendev.org/c/openstack/osc-placement/+/869768 | |
| 03:59:20 | __ministry | hellu, I using nova version yoga. but when I do resize an instances. I had met error like: "Exception during message handling: nova.exception.CPUUnpinningInvalid: CPU set to unpin [2, 76, 46, 50, 28, 94] must be a subset of pinned CPU set [0, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 30, 32, 34, 36, 38, 40, 42, 44, 48, 52, 54, 56, 58, 62, 66, 68, 70, 72, 74, 78, 80, 82, 84, 86, 88, 92]". Anyone else had met this problem? Whether this is opens | |
| 10:02:40 | sean-k-mooney[m] | that almost always means you either modifed the vcpu_pin_set/cpu_dedicated_set in the past or you live migrated pinned instances in a release where it was not supported | |
| 14:45:09 | opendevreview | Merged openstack/nova stable/yoga: ignore deleted server groups in validation https://review.opendev.org/c/openstack/nova/+/867989 | |
| #openstack-nova - 2023-03-13 | |||
| 02:22:49 | __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? | |
| 08:34:03 | 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:39:21 | 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 | |
| 09:03:41 | 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:09:10 | Uggla | gibi, hello, ouch you gave me a lot of homework. :) | |
| 09:12:55 | bauzas | Uggla: fwiw, starting to review your series again :) | |
| 09:13:56 | Uggla | bauzas, cool thanks. So I will wait for your comments before changing anything. | |
| 09:14:05 | bauzas | ack | |
| 09:51:57 | bauzas | Uggla: so, I have like the same concerns than gibi here | |
| 09:52:21 | bauzas | the first patch is only getting a soft -1 because I'd want you to test some deletion behaviour | |
| 09:52:32 | bauzas | apart from this, I'm OK | |
| 09:52:51 | bauzas | now, I have more concerns for the objects patc | |
| 09:52:54 | bauzas | patch | |
| 09:53:15 | bauzas | it looks to me that we should discuss how to use this object between the services | |
| 09:53:18 | bauzas | and what it could do | |
| 10:27:26 | Uggla | bauzas, ok | |
| 10:28:40 | bauzas | Uggla: I need to get my daughter in 10 mins but we can discuss that in the afternoon if you want | |
| 10:28:55 | Uggla | ok sounds good | |
| 10:29:08 | bauzas | I'll ping you later around 2pm CET | |
| 10:47:07 | opendevreview | Rajesh Tailor proposed openstack/nova master: Fix duplicate cell creation with same name https://review.opendev.org/c/openstack/nova/+/876940 | |
| 12:05:15 | dvo-plv | @sean-k-mooney, are you here ? | |
| 12:10:28 | sean-k-mooney | o/ | |
| 12:11:59 | sean-k-mooney | dvo-plv: hi yes i am | |
| 12:15:02 | 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:52 | dvo-plv | btw, I can not figure out, how to mention user here? | |
| 12:16:37 | sean-k-mooney | as in to ping people | |
| 12:16:41 | sean-k-mooney | on irc | |
| 12:16:44 | sean-k-mooney | or something else | |
| 12:19:19 | dvo-plv | yes, how to ping pople here. How do you do it with me? | |
| 12:19:39 | sean-k-mooney | just dvo-plv or dvo-plv: | |
| 12:19:47 | sean-k-mooney | dvo-plv: so like this | |
| 12:19:54 | sean-k-mooney | does that highlight for you | |
| 12:20:18 | sean-k-mooney | basicaly most client auto highlight on the nic you are connected with and you can configure others | |
| 12:20:20 | dvo-plv | i see, thank you | |
| 12:21:00 | sean-k-mooney | the : at the end generally gets added if you tab complete but it shoudl not be required | |
| 12:21:14 | dvo-plv | so ,if you have a time, I would like to discuss solution how to support our nic propperly | |
| 12:21:16 | sean-k-mooney | my client will match on my nic regardless or prefix or sufix | |
| 12:21:34 | sean-k-mooney | dvo-plv: so im in two minds | |
| 12:22:00 | 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:18 | sean-k-mooney | if you plan to maintain a fork then your orginal approch is fine | |
| 12:23: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:53 | sean-k-mooney | in your specific case i see there are some special requriements around the name of the vhost-user socket | |
| 12:24:20 | sean-k-mooney | i suspect that is specific to your vswith implmation | |
| 12:25:36 | dvo-plv | yes, we have our own dpdk driver what requires some specific moments | |
| 12:26:13 | sean-k-mooney | as currently written i think your patch might break the exiting virtio-forwarder code | |
| 12:26:44 | dvo-plv | when you are talking about original approach. You mean separate driver or implementation support with openvswitch | |
| 12:27: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:40 | sean-k-mooney | and i was asking if that was what you were trying to enable | |
| 12:27:55 | sean-k-mooney | the answer to the second quetion is no | |
| 12:28:04 | sean-k-mooney | you are not trying to enabel to upstream ovs feature | |
| 12:28:15 | sean-k-mooney | your are trying to enable your vendor specific version | |
| 12:28:26 | sean-k-mooney | in which case usign an out of tree ml2 dirver is appropreiate | |
| 12:28:56 | sean-k-mooney | that way you do not need to worry about compatiablity with netonomes implamation of virtio forward | |
| 12:29:38 | 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:32:35 | sean-k-mooney | dvo-plv: have dpdk removed or raised the limit on dpdk type ports above 32 yet | |
| 12:37:19 | sean-k-mooney | dvo-plv: what i would suggest is adding a VIF_DETAILS_VHOSTUSER_NAPATECH_PLUG | |
| 12:37:49 | sean-k-mooney | so in the port binding details set a flag to indicate taht its napatech | |
| 12:38:34 | sean-k-mooney | continue to use vnic_type=vritio-forwarder | |
| 12:39:29 | justas_napa | Hi. To answer the question regarding ovs support - it really depends on the end user requirements | |
| 12:39:38 | sean-k-mooney | in nova check for both and in a new if in os_vif_util implement the logic you require | |
| 12:40:13 | justas_napa | we maintain our own OvS to support features like QinQ and some special QoS schemes | |
| 12:40:18 | sean-k-mooney | justas_napa: the in tree ml2/ovs and ml2/ovn dirver are only ment to supprot ovs form openvsiwtch.org | |
| 12:41:04 | 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:12 | justas_napa | I think we are OK to limit ourselves to vanilla ovs | |
| 12:41:53 | justas_napa | unless adding support for our own OVS is trivial | |
| 12:42:52 | sean-k-mooney | well vaniall ovs has two ways to enabel vhost-user but the proposal is not using either of them | |
| 12:42:59 | sean-k-mooney | https://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/ | |
| 12:43:17 | sean-k-mooney | instead you are created dpdk vdevs https://docs.openvswitch.org/en/latest/topics/dpdk/vdev/ | |
| 12:44:58 | sean-k-mooney | there is supprot for dpdk representor prots | |
| 12:45:27 | justas_napa | so then it's custom ml2 and os_vif driver | |
| 12:45:57 | sean-k-mooney | https://docs.openvswitch.org/en/latest/topics/dpdk/phy/#representors | |
| 12:46:02 | sean-k-mooney | am i think so. | |
| 12:46:26 | justas_napa | yes, we are heavy users of representors | |
| 12:46:26 | 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:46 | sean-k-mooney | so ok maybe we need to level set | |
| 12:47:07 | sean-k-mooney | justas_napa: the dpdk type port that you are creating for use with virio-forward | |
| 12:47:14 | sean-k-mooney | is that a vf representor | |
| 12:47:21 | sean-k-mooney | as descirbed here https://docs.openvswitch.org/en/latest/topics/dpdk/phy/#representors | |
| 12:47:32 | justas_napa | yes | |