Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-05-09
09:44:47 ralonsoh so one compute is requesting its own secret id
09:45:00 ralonsoh and the other compute is asking for other
09:45:13 ralonsoh and I don't know it that should match the ceph.conf fsid
09:50:25 sean-k-mooney hum i could try and deploy this and see. but the devstack roles just copy the keyfiels and config to the compute https://github.com/openstack/devstack/blob/master/roles/sync-controller-ceph-conf-and-keys/tasks/main.yaml
09:50:54 sean-k-mooney then on the compute you set REMOTE_CEPH=True
09:51:05 ralonsoh sean-k-mooney, yes, that's set
09:51:31 sean-k-mooney https://github.com/openstack/devstack-plugin-ceph/blob/master/devstack/lib/ceph#L834-L841=
09:51:39 sean-k-mooney the secret config seams to be the same
09:52:49 sean-k-mooney https://github.com/openstack/devstack-plugin-ceph/blob/master/devstack/lib/ceph#L244-L259=
09:52:57 ralonsoh sean-k-mooney, yeah, it is. In any case, I'll deploy the second compute node again
09:53:18 sean-k-mooney ack
09:53:36 sean-k-mooney i think from lookign at that that the secure and keyfiles should be the same on all hosts
09:53:51 ralonsoh sean-k-mooney, one question
09:54:10 ralonsoh in the first node, the fsid is 37...
09:54:24 ralonsoh and the "sudo virsh secret-list " is d5...
09:54:27 ralonsoh this is wrong...
09:54:45 ralonsoh pffff
10:17:39 ralonsoh sean-k-mooney, sorry, I've re-deployed the first controller
10:18:18 ralonsoh and CEPH has changed the /etc/ceph/ceph.cong fsid number
10:18:36 ralonsoh that means the virsh secret and the fsid is different now
10:21:51 sean-k-mooney yes the it will change every time you stack
10:22:47 ralonsoh sean-k-mooney, but what ID should I use now?
10:23:02 sean-k-mooney ralonsoh: on a different topic has anyone raised support virtio-failover in neutron
10:23:07 sean-k-mooney ralonsoh: likely the one for the contoler
10:23:23 ralonsoh sorry what?
10:23:55 sean-k-mooney that basically answers my question :) virtio-failover is like a form of automatic bounding
10:24:14 ralonsoh ah no that I'm aware
10:24:26 sean-k-mooney you can declare one virtio device as a failover device if the primary losses connectivity
10:24:31 ralonsoh in any case, I'll check it later
10:24:45 ralonsoh nope, that is usually done inside the VM
10:24:47 sean-k-mooney no worries im 99% sure that its not supproted
10:24:59 ralonsoh sean-k-mooney, last q
10:25:07 ralonsoh about this fsid
10:25:13 sean-k-mooney ralonsoh: virtio failover allwos qemu to ask the guest virtio driver to do the failover automaticaly in the guest
10:25:20 sean-k-mooney ralonsoh: sure
10:25:29 ralonsoh if "virsh secret-list" is one number
10:25:36 ralonsoh and in ceph.conf I have another one
10:25:52 ralonsoh then which one should I use in the second comptue?
10:28:09 sean-k-mooney the secret uuid is the cinder_ceph_uuid
10:28:26 ralonsoh yes, and it's generated by devstack-ceph
10:28:27 ralonsoh CEPH_FSID=$(uuidgen)
10:28:37 sean-k-mooney yep so you coudl doble check the cidner config
10:28:48 sean-k-mooney and determin which is the correct uuid value
10:29:27 sean-k-mooney ill quickly deploy with ceph and see if we can compare
10:33:48 gibi Uggla: responded in the manila spec
10:38:53 sean-k-mooney gibi: im just going to grab coffee but we can chat about the pci spec when ever suits
10:39:06 sean-k-mooney ill be back in 10 mins
10:45:13 gibi I will grab lunch so I will ping you later
10:47:52 sean-k-mooney cool no rush.
11:33:02 gibi sean-k-mooney: OK, I'm back
11:38:04 gibi sean-k-mooney: so the first question is simple. Will nova create the custom resource class mentioned in the [pci]device_list or we expect the deployer to pre-create that
11:38:24 gibi https://review.opendev.org/c/openstack/nova-specs/+/791047/4/specs/zed/approved/pci-device-tracking-in-placement.rst#156
11:39:32 gibi I think in the vgpu case nova creates the custom RC
11:40:50 gibi as the config does not have a full RC but just some typename
11:40:55 gibi and nova generates the RC name from it
11:48:14 opendevreview Balazs Gibizer proposed openstack/nova master: DNM: log number of green(thread|let)s periodically https://review.opendev.org/c/openstack/nova/+/841040
11:50:59 sean-k-mooney gibi: o/ am yes i think nova should create the custom resouce classes in placement
11:51:28 sean-k-mooney the reason for this is we want to use CUSTOM_<VENDOR_ID>_<PRODUCT_ID>
11:51:47 sean-k-mooney when no RC has been specified in the device list
11:52:08 sean-k-mooney so i think it would be a better end user experince if those custom resouce classes were created automatically
11:52:09 gibi so resource_class=foobar is OK and nova will create CUSTOM_FOOBAR in placement
11:52:44 sean-k-mooney ah are you asking if nova should normalise and prepend the CUSTOM_
11:52:58 gibi yep, as a follow up :)
11:53:12 gibi follow up question
11:53:49 sean-k-mooney i think that woudl be workable. i would prefer to encurage them to set CUSTOM_<whatever>
11:54:07 sean-k-mooney but i think its fine to prepend and normalise automatically
11:54:26 gibi a bit more user friendly if we normalize and prepend
11:54:28 gibi so I will go with that
11:54:51 sean-k-mooney yep just so long as we are smart and only prepend when needed
11:55:07 gibi OK, I can make it smart to avoid double custom
11:55:34 gibi OK
11:55:50 gibi next one is future proofing the RC
11:55:52 gibi https://review.opendev.org/c/openstack/nova-specs/+/791047/4/specs/zed/approved/pci-device-tracking-in-placement.rst#169
11:56:41 gibi I think we support the case today when pci alias and neutorn sriov is configured in the same deployment
11:57:05 gibi also I think it is possible to consume the same type-VF either from alias or from port
11:57:44 gibi so for this case we need an RC name for the type-VF RP that is known before the scheduling for the sriov case
11:57:56 gibi SRIOV_NET_VF could be use for that
11:58:05 gibi as that already exists in os-traits
11:58:23 sean-k-mooney yes you can consume type-vf via alias
11:58:36 sean-k-mooney because VF and sriov have nothing to do with networking
11:58:48 sean-k-mooney you can have VFs for gpus or ssds
11:58:56 gibi true
11:59:02 sean-k-mooney the physical_network tag in the device list
11:59:14 sean-k-mooney is what marks it as a nic and is required for neutron consumtion
11:59:40 sean-k-mooney im not sure if we explictly prevent alaise form consuming device with physical_network set
11:59:51 sean-k-mooney but we could do that going forward i guess
11:59:55 gibi I think we did not prevent it today
12:00:03 sean-k-mooney ack
12:00:26 sean-k-mooney so for device with physical_network set
12:00:34 gibi we can simply say that resource_class will not be applicable if physical_network tag is present, and nova will use standard RC for these devices
12:00:46 sean-k-mooney i think its fine to mark them as SRIOV_NET_VF or SRIOV_NET_PF
12:00:49 gibi cool
12:01:01 sean-k-mooney we would likely track vdpa devices as SRIOV_NET_VF too
12:01:16 sean-k-mooney although i guess that could be SRIOV_NET_VDPA
12:01:33 sean-k-mooney that actully might make more sense not that i think of it
12:02:08 gibi yeah. but we don't have to decide it now, I just needed to make sure the that the current spec is future proof
12:02:10 sean-k-mooney so yes making RC and phsynet mutally exclsive i think is correct
12:02:22 sean-k-mooney yep
12:02:30 gibi OK
12:02:31 gibi next one

Earlier   Later