Earlier  
Posted Nick Remark
#openstack-nova - 2022-01-24
19:25:10 gmann so single and multinode jobs as separate sounds good
19:25:28 ade_lee__ cool - sounds like a plan ! thanks ya'll
19:25:40 ade_lee__ go eat!
19:25:42 gmann thanks
19:25:44 gmann :)
19:26:39 sean-k-mooney o/
#openstack-nova - 2022-01-25
00:37:21 opendevreview Merged openstack/nova master: Add service version check workaround for FFU https://review.opendev.org/c/openstack/nova/+/826097
00:48:07 opendevreview Merged openstack/nova master: block_device: Ignore VolumeAttachmentNotFound during detach https://review.opendev.org/c/openstack/nova/+/812127
01:34:57 opendevreview Merged openstack/nova master: Add check job for FIPS https://review.opendev.org/c/openstack/nova/+/790519
08:39:41 plibeau hello, sean-k-mooney thx for the review, lyarwood if you have time to review: https://review.opendev.org/c/openstack/nova/+/820531
10:12:17 bauzas sean-k-mooney: gibi: when you're around, I'm about working on a specific implementation detail for https://specs.openstack.org/openstack/nova-specs/specs/yoga/approved/boot-vm-with-unaddressed-port.html
10:12:55 bauzas sean-k-mooney: gibi: in https://review.opendev.org/c/openstack/nova/+/669411/2/nova/network/neutron.py stephenfin said we should verify the l2 connectivity for the port binding
10:13:53 bauzas sean-k-mooney: gibi: I can do it in https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L3546
10:14:24 bauzas sean-k-mooney: gibi: but what kind of exception should I provide if it's not cool ?
10:14:38 bauzas exception.PortUpdateFailed I guess?
10:14:53 gibi hm,
10:15:34 gibi the faulty case is when a port has ip_allocation=none but when it is bound neutron sets connectivity to other than l2
10:15:46 gibi but this should be a neutron error, isn't it?
10:15:52 gibi I mean such port has no sense
10:16:27 bauzas gibi: this is correct iiuc
10:16:48 gibi could neutron detect this and fail the binding?
10:16:57 gibi that would be a cleaner approach
10:17:10 bauzas gibi: well, I don't know
10:17:16 gibi sean-k-mooney: ^^ ?
10:17:48 bauzas stephenfin: if you're around, I'd like to understand why you wanted to verify the l2 connectivity with https://review.opendev.org/c/openstack/nova/+/669411/2/nova/network/neutron.py
10:18:09 bauzas thanks
10:18:14 bauzas context : unaddressed ports
10:18:35 bauzas we haven't discussed it in the spec
10:22:31 stephenfin Ah, so ralonsoh is really the person to ask. He told me to do that :) If I were to guess, it's because deferred IP allocation obviously only makes sense for L2 ports (you must have an IP to operate at layer 3) but that's a guess
10:22:49 bauzas stephenfin: yeah, I understand why
10:23:05 bauzas I mean the "why we should verify"
10:23:21 bauzas but gibi had concerns with "where we should do it"
10:23:36 bauzas and I'm quite able with him
10:23:40 ralonsoh bauzas, there are some backends that don't allow to have IP-less ports
10:23:41 stephenfin ah, yes, I didn't read all the conversation
10:23:50 ralonsoh this is why we introduced this parameter
10:24:11 bauzas ralonsoh: sure, I understand but why it should be nova which should verify when binding ?
10:24:20 bauzas and why not neutron when creating the port ?
10:24:36 ralonsoh because the port creation is just a DB representation
10:24:45 ralonsoh this is not bound to any backend
10:24:55 bauzas until binding, I guess then ?
10:25:10 ralonsoh yes, that's the point
10:25:56 bauzas ralonsoh: ok, then why it should be nova which would verify it when binding and why not neutron ?
10:26:36 ralonsoh because this is how it was designed
10:26:43 ralonsoh we can change it back again
10:27:43 bauzas gibi: ^
10:28:10 gibi ack
10:28:14 bauzas ralonsoh: sorry, havn't seen it in https://specs.openstack.org/openstack/nova-specs/specs/yoga/approved/boot-vm-with-unaddressed-port.html
10:28:31 gibi I do belive that if the port binding does not make sense then such bindig should be rejected by neutron
10:28:42 gibi but I don't have deep understanding of the neutron side of this
10:29:26 bauzas oh my bad, this was somehow explained in the spec :
10:29:29 bauzas " The changes introduced as part of the “Port binding event extended information for Nova” 4 spec means neutron will now provide the type of back-end to which the port is bound, with the parameter connectivity, included now in binding:vif_details. Nova can determine whether a given driver back-end has “l2” connectivity and, if so, know that a port without an IP address can be assigned to a virtual machine."
10:30:25 bauzas I guess I'd appreciate sean-k-mooney's thoughts on this one
10:32:05 gibi if this was agreed before then I rest my case
10:35:07 bauzas gibi: well, yes and no
10:35:12 bauzas this was agreed in a neutron spec
10:35:23 bauzas this wasn't really discussed in the nova spec
10:35:57 bauzas except saying "look, we could have neutron backends that'd have problems, we should verify the connectivity"
10:36:04 bauzas but we accepted it as it's phrased
10:36:29 ralonsoh bauzas, this can be changed and we can make Neutron to decide this
10:36:58 ralonsoh if we have the port connectivity value and the backend one too, that's easy
10:37:08 bauzas ralonsoh: I think I'm personnally OK with moving on and doing this check in nova first but I'd somehow appreciate second thoughts for a neutron change too
10:38:08 ralonsoh bauzas, I'll propose this in a drivers meeting
10:38:19 ralonsoh if a new spec is needed, I'll push it
10:38:34 bauzas well, that'd mean a Z change
10:38:44 ralonsoh yes, in Z probably
10:38:53 bauzas that's why I'm saying I'm OK with checking this in nova first if gibi is OK
10:38:53 ralonsoh well, I'm not sure
10:39:12 bauzas (provided I'm able to write such thing :D )
10:39:49 ralonsoh bauzas, I'll raise this question this friday, at 1400UTC
10:40:02 ralonsoh drivers meeting. The change should be small in Neutron
10:45:04 ralonsoh bauzas, good news
10:45:07 ralonsoh https://review.opendev.org/c/openstack/neutron/+/678027
10:45:51 ralonsoh and that was merged in Train
10:45:51 ralonsoh Neutron will reject this port binding
10:45:51 ralonsoh (sorry, I didn't remember that part)
10:46:03 bauzas ralonsoh: ok, so no need for a check in nova
10:46:04 bauzas all good
10:46:10 bauzas I can remove stephenfin's WIP
10:46:20 bauzas and repropose it against Yoga nova
11:09:40 gibi bauzas, ralonsoh: https://review.opendev.org/c/openstack/neutron/+/678027 is the best outcome of this discussion :)
12:02:05 chateaulav sean-k-mooney: appreciate the os-traits review!
12:55:39 bkranendonk hi folks, is there a way to utilize multiple image backends (e.g. rbd for instance X and lvm for instance Y) on the same hypervisor?
12:55:58 bkranendonk cant find info on this
13:08:24 lyarwood bkranendonk: not with the libvirt driver, it's a single static choice in the compute config used by all instances hosted on it
13:09:08 lyarwood bkranendonk: if you want choice use volume types has always been our suggestion
13:09:40 bkranendonk lyrarwood: Boot from volume with a volume_type?
13:10:07 sean-k-mooney bkranendonk: yep
13:10:16 bkranendonk ok, thanks!
13:10:29 lyarwood bkranendonk: I think we proxy the type yeah, otherwise just create the volume directly in cinder with a given type and then use it in nova
13:10:46 sean-k-mooney the images type can be used to set a host wide default stoage backing and then you can suplement that with cinder volumes and volume types to select based on differnt perfromacne requiements
13:11:25 lyarwood yeah block_device_mapping_v2.volume_type is available from 2.67
13:30:11 elodilles bauzas: i'll add some update to meetings wiki if you are not doing that right now
13:46:38 bauzas elodilles: sure, please do
13:55:12 elodilles bauzas: thx, done
14:51:41 sean-k-mooney bauzas: you were asking previously about adressless port and why nova needs to check the connectivty?
14:51:49 sean-k-mooney did you get an answer
14:51:52 sean-k-mooney its a security issue
14:52:26 sean-k-mooney for backends like calico that provie l3 only connectivity its invlade to use l2 networking and it will not be fucntional
14:53:13 sean-k-mooney in general port with l2 connectivy and no ip will not work with security groups proerly

Earlier   Later