| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-15 | |||
| 09:05:49 | lyarwood | Morning, I guess we need to leave the gate alone to allow the vDPA and secure-boot stuff to land right? | |
| 09:06:11 | gibi | lyarwood: hi! do you have a plan to disturb the gate somehow? :) | |
| 09:08:05 | lyarwood | gibi: I mean just in terms of load etc | |
| 09:08:12 | lyarwood | gibi: approving additional things | |
| 09:08:34 | lyarwood | like https://review.opendev.org/q/topic:bug/1552042 ;) | |
| 09:09:12 | gibi | I think bugfixes should go. I don't see how that can effectively slow down the vdpa and secure boot landing | |
| 09:09:33 | lyarwood | kk | |
| 09:19:26 | lyarwood | bauzas: https://review.opendev.org/c/openstack/nova/+/780286 - would you mind hitting this today to unblock stable/rocky? | |
| 09:22:13 | bauzas | lyarwood: sure, looking | |
| 09:23:26 | kashyap | lyarwood: gibi: I think it's not worth to backport anything that is _not_ a CVE fix for stable/train, is it? | |
| 09:23:37 | kashyap | Morning, BTW | |
| 09:24:38 | kashyap | lyarwood: gibi: What I have in mind is the "allow disabling CPU flags" feature -- it can potentially save people from lots of tricky positions. But, stable/train goes EOL in a couple of months | |
| 09:26:04 | gibi | kashyap: you called that a feature, that categorization already prevents backporting | |
| 09:26:05 | kashyap | So I'm ambivalent for upstream. If downstreams need it; they should maintain the backport on their own. | |
| 09:26:17 | kashyap | gibi: Fair enough :-) | |
| 09:28:44 | kashyap | gibi: For an imaginary case: you wouldn't object backporting a small "feature" (not a big one) to a long-term stable branch if it can potentially save a lot of future misery, would you? | |
| 09:29:27 | lyarwood | kashyap: https://docs.openstack.org/project-team-guide/stable-branches.html sets out the upstream policy | |
| 09:29:35 | kashyap | ("I would object" is a valid answer, though :-)) | |
| 09:31:33 | kashyap | lyarwood: I'm not going to backport it to stable/train, but for discussion's sake: the backport fits all criteria: it's small and self-contained; not invasive at all; not user-visible, but still can save your rear ... and so on | |
| 09:31:53 | kashyap | Thanks for the link. I'll stop theoretical discussions here :-) | |
| 09:32:25 | gibi | kashyap: allowing feature backports is a slippery slope | |
| 09:33:58 | kashyap | gibi: I fully agree; but the devil is in the details, right? If it's a tiny, targetted "feature", but can facilitate a security mitigation (which is a real possibility, BTW), then what? | |
| 09:34:24 | kashyap | The concrete example is: there can be a future CVE which can be mitigated only disabling a CPU flag fo rthe guest. | |
| 09:35:11 | kashyap | gibi: That said, I agree with you for the rest of the 98% of cases, it is a slippery slope. | |
| 09:35:42 | kashyap | Missing word earlier: s/only/only by/ | |
| 09:38:07 | gibi | when we have such CVE to mitigate then we have to decide how to mitigate that. | |
| 09:38:35 | gibi | if the only obvious way is to backport you change then we can consider that | |
| 09:39:44 | lucasagomes | sean-k-mooney, morning, if u have sometime mind taking a look at https://review.opendev.org/c/openstack/nova/+/776934, https://review.opendev.org/c/openstack/nova/+/776419 and https://review.opendev.org/c/openstack/nova/+/776944 ? Simple patches, all with +2's already | |
| 09:40:01 | lucasagomes | ops... last one has a merge conflict. Lemme fix it | |
| 09:40:13 | kashyap | gibi: Yep; fun fact: that's what we did when we introduced the config option :-) | |
| 09:40:43 | kashyap | (It helped mitigate a flaw at that time by _enabling_ two CPU flags) | |
| 09:43:08 | openstackgerrit | Lucas Alvares Gomes proposed openstack/nova master: [OVN] Adapt the live-migration job scripts to work with OVN https://review.opendev.org/c/openstack/nova/+/776419 | |
| 09:43:09 | openstackgerrit | Lucas Alvares Gomes proposed openstack/nova master: [OVN] Explicitly set grenade job to ML2/OVS https://review.opendev.org/c/openstack/nova/+/776934 | |
| 09:43:09 | openstackgerrit | Lucas Alvares Gomes proposed openstack/nova master: [OVN] Explicitly set nova-next job to ML2/OVS https://review.opendev.org/c/openstack/nova/+/776944 | |
| 09:44:26 | openstackgerrit | Merged openstack/nova master: fakelibvirt: make kB_mem default not laughable https://review.opendev.org/c/openstack/nova/+/779559 | |
| 09:46:48 | gibi | kashyap: I vaguely rememeber | |
| 09:47:23 | gibi | anyhow we have a national holiday today here in Hungary so I will be going on and off during the day | |
| 09:47:41 | kashyap | gibi: /me wrote documentation for it here :-) -- https://docs.openstack.org/nova/latest/admin/mitigation-for-Intel-MDS-security-flaws.html | |
| 09:47:43 | gibi | sean-k-mooney: I've found ony problem with the vdpa ops blcoking patch | |
| 09:47:53 | kashyap | gibi: Ah, enjoy the day. It is even sunny here today | |
| 09:48:01 | gibi | it is not bad here either | |
| 10:08:24 | brinzhang | bauzas: good morning^ | |
| 10:08:45 | brinzhang | bauzas: you comment in https://review.opendev.org/c/openstack/nova/+/778440 with bug 1917592 | |
| 10:08:47 | openstack | bug 1917592 in OpenStack Compute (nova) "Missed 'accel_uuids' when we the 'shelved_offload_time' time out in shelving instance periodic task" [Medium,In progress] https://launchpad.net/bugs/1917592 - Assigned to Brin Zhang (zhangbailin) | |
| 10:09:03 | bauzas | brinzhang: good afternoon | |
| 10:09:13 | bauzas | (I have to leave in 5 mins for getting my children from school) | |
| 10:10:00 | brinzhang | bauzas: ack, dont worry | |
| 10:10:34 | brinzhang | about your concern, does it need to add an cyborg get multiple arqs apis? | |
| 10:15:13 | bauzas | brinzhang: well, the point is that we call the Cyborg API for each of the instance | |
| 10:15:49 | bauzas | but my -1 was more about the L9480 | |
| 10:17:35 | brinzhang | bauzas: ack, not in a hurry, thanks | |
| 10:18:50 | brinzhang | gibi: do you have some suggestion? bauzas's concern is the cyborgclient may get many times if there are some bound accel:device_profile instance | |
| 10:19:16 | brinzhang | s/some/any/ | |
| 13:17:25 | lyarwood | elod / bauzas / melwitt ; https://review.opendev.org/c/openstack/nova/+/780287 - final stable/queens ceph fix should be good to go btw | |
| 13:47:18 | sean-k-mooney | gibi: hi yep its an issue ill fix that and convert it to using the info cache quickly otherwise are you ok with the approch | |
| 13:48:21 | sean-k-mooney | im technically off this week but im going to intermitenly check the status of the vdpa patches until they are all merged but expect delays since i will only be checking evey few hours | |
| 13:49:32 | gibi | sean-k-mooney: I'm OK with the approach | |
| 14:27:00 | openstackgerrit | Takashi Kajinami proposed openstack/osc-placement master: Add openstackclient-plugin-jobs https://review.opendev.org/c/openstack/osc-placement/+/780598 | |
| 14:30:15 | bauzas | dansmith: I got hit by Zuul when changing the pre-live-migration method, so I'll try to not accept 5.0 | |
| 14:32:36 | k-s-dean | Hi would someone be able to help me. | |
| 14:32:51 | k-s-dean | How does nova notify neutron / designate of VM details ? | |
| 14:38:44 | sean-k-mooney | via a port update. for neutron it updates teh device_id with the instance uuid in port binding prodmently and designate reads the info from the neutron port | |
| 14:39:01 | sean-k-mooney | nova does not directly interact with designate | |
| 14:43:13 | k-s-dean | sean thanks for answering I'm getting ignore in all the other channels, I'm hitting an issue where the fixed IPs are being put in DNS. I've been asking around but cant get to the bottom of it. It worked in stein. | |
| 14:43:52 | sean-k-mooney | i think that is expected | |
| 14:44:41 | sean-k-mooney | when using designate the fixed ips set on the neutron port are registred in dns so that vms can directlly ssh to other vms via there host/dns name | |
| 14:44:42 | k-s-dean | In the neutron documentation it says that the VMs name gets appended on to the dns domain on port update events. | |
| 14:44:56 | k-s-dean | specifically for floating IPs | |
| 14:45:40 | k-s-dean | something has obviously changed since I last installed openstack. | |
| 14:46:19 | sean-k-mooney | i was always under the impression that both fix and floating ips were always regeistred | |
| 14:46:30 | sean-k-mooney | though the dns name might be different for each | |
| 14:46:50 | k-s-dean | The floating IP is being registered but like so | |
| 14:47:05 | k-s-dean | 10-30-0-205.os.example.com. | A | 10.30.0.205 | |
| 14:47:27 | k-s-dean | I swear that in stein the VMs name was added to that DNS name | |
| 14:47:49 | k-s-dean | https://docs.openstack.org/ocata/networking-guide/config-dns-int.html#config-dns-int-dns-resolution | |
| 14:47:54 | k-s-dean | these docs are wrong then. | |
| 14:49:42 | sean-k-mooney | i have 172-20-5-191.cloud.seanmooney.info. cyborg-1.cloud.seanmooney.info. cyborg-1.sean.cloud.seanmooney.info. | |
| 14:49:46 | sean-k-mooney | all for the same vm | |
| 14:50:08 | k-s-dean | are those assigned to the floating IP or fixed IP | |
| 14:50:13 | sean-k-mooney | fixed | |
| 14:50:38 | k-s-dean | is that for internal DNS resolution then ? | |
| 14:50:44 | k-s-dean | not external | |
| 14:51:02 | k-s-dean | because I thought dns mask needed to be setup for that | |
| 14:51:16 | sean-k-mooney | well this is my home cloud and all the ips in my neturon subnet allocation pool are routable | |
| 14:51:32 | sean-k-mooney | my vms only get public ipv6 address | |
| 14:51:45 | k-s-dean | Yeah, so thats where I think there has been a major change. | |
| 14:52:02 | k-s-dean | in the neutron docs. Use case 2: Floating IPs are published with associated port DNS attributes | |
| 14:52:26 | k-s-dean | you can see at the end the floating IP is assigned the VMS name. | |
| 14:52:42 | k-s-dean | I can work around this by using a flat provider network, | |
| 14:52:55 | k-s-dean | and attach the VMs directly to the network. | |
| 14:52:58 | sean-k-mooney | well floating ips are named by the enduser when you create them | |
| 14:53:08 | sean-k-mooney | nova does not create floating ips fro you | |
| 14:53:47 | k-s-dean | ok i thought that when you attach a floating IP to an instance, neutron would notify nova of the port update and nova would notify designate of the VMS name | |
| 14:54:00 | sean-k-mooney | no | |
| 14:54:36 | sean-k-mooney | to attach a floating ip you call the nova api but we do not call designate. | |
| 14:54:49 | sean-k-mooney | its possible that designate is listing to nova notifcation bus | |
| 14:55:06 | k-s-dean | it is. | |
| 14:55:22 | sean-k-mooney | im not sure it does any more | |
| 14:55:22 | k-s-dean | the way this works has obviously changed, since stein | |
| 14:55:24 | sean-k-mooney | it used too | |