| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-11-16 | |||
| 05:51:41 | opendevreview | Ghanshyam proposed openstack/nova master: DNM: test new defaults https://review.opendev.org/c/openstack/nova/+/864673 | |
| 06:10:48 | opendevreview | Younghwan Yoo proposed openstack/nova master: Update a return value of mdev_name2uuid function to be a valid UUID value https://review.opendev.org/c/openstack/nova/+/864674 | |
| 06:13:48 | han-guangyu | Hello, I want to package ovn in openEuler(a OS had been supported by openstack ci)) | |
| 06:14:13 | han-guangyu | Could I can get a recommended version of ovn to Train and Wallaby | |
| 06:14:37 | han-guangyu | I see: | |
| 06:14:49 | han-guangyu | > OpenStack doesn’t set explicit version requirements for OVN installation, but it’s recommended to follow at least the version that is used in upstream CI, in https://docs.openstack.org/neutron/latest/ovn/faq/index.html | |
| 06:16:06 | han-guangyu | But I am not sure, if I use the latest version of ovn, whether the neutron of train and wallaby both can be connected normally | |
| 06:16:22 | han-guangyu | Do they have a capped version that supports | |
| 06:17:27 | opendevreview | Younghwan Yoo proposed openstack/nova master: Update mdev_name2uuid function return value to be a valid UUID https://review.opendev.org/c/openstack/nova/+/864674 | |
| 06:21:13 | opendevreview | Younghwan Yoo proposed openstack/nova master: Update return value to be a valid UUID https://review.opendev.org/c/openstack/nova/+/864674 | |
| 06:21:22 | han-guangyu | oh | |
| 06:21:34 | han-guangyu | I send to a incorret channel | |
| 06:21:42 | han-guangyu | I want to neutron , sorry | |
| 06:37:31 | opendevreview | Younghwan Yoo proposed openstack/nova master: Update return value to be a valid UUID https://review.opendev.org/c/openstack/nova/+/864674 | |
| 06:42:59 | opendevreview | Amit Uniyal proposed openstack/nova stable/train: functional: Change order of two classes https://review.opendev.org/c/openstack/nova/+/864672 | |
| 07:56:32 | opendevreview | Amit Uniyal proposed openstack/nova stable/train: Add boot from volume functional test with a huge request https://review.opendev.org/c/openstack/nova/+/864679 | |
| 09:02:29 | opendevreview | Sahid Orentino Ferdjaoui proposed openstack/nova-specs master: spec: allowing target state for evacuate https://review.opendev.org/c/openstack/nova-specs/+/857838 | |
| 09:03:15 | sahid | gibi, sean-k-mooney o/ if you can have a second look at ^ there is one point that I don't get | |
| 09:05:09 | gibi | sahid: looking... | |
| 09:08:47 | sean-k-mooney[m] | sahid gibi is just asking that you bump the compute service version and add a min compute service version check in the api | |
| 09:09:13 | sean-k-mooney[m] | so if you upgrade the api and conductors but not the computes | |
| 09:09:26 | sean-k-mooney[m] | we would still reject the new microversion | |
| 09:09:36 | sean-k-mooney[m] | until you completed updating all the computes | |
| 09:10:48 | gibi | yepp | |
| 09:10:52 | gibi | I left a reply in the review too | |
| 09:11:01 | gibi | but it is what sean-k-mooney[m] described above | |
| 09:11:41 | sean-k-mooney[m] | we do this with a decorator on the api method | |
| 09:11:43 | sean-k-mooney[m] | https://github.com/openstack/nova/blob/bcdf5988f6ae902dba9b41144a7b4a60688b627c/nova/compute/api.py#L283 | |
| 09:11:49 | sean-k-mooney[m] | that is an example for vdpa | |
| 09:12:58 | sean-k-mooney[m] | you will need to reject the new microverion untill the requied min service version is reached | |
| 09:15:31 | sean-k-mooney[m] | you might want to do this eailer then that actully | |
| 09:15:41 | sean-k-mooney[m] | i dont think we have the microverion at that point | |
| 09:16:39 | opendevreview | Amit Uniyal proposed openstack/nova stable/train: functional: Unify '_wait_until_deleted' implementations https://review.opendev.org/c/openstack/nova/+/864712 | |
| 09:16:40 | opendevreview | Amit Uniyal proposed openstack/nova stable/train: functional: Unify '_build_minimal_create_server_request' implementations https://review.opendev.org/c/openstack/nova/+/864713 | |
| 09:16:49 | sean-k-mooney[m] | so it would be better to do it here https://github.com/openstack/nova/blob/bcdf5988f6ae902dba9b41144a7b4a60688b627c/nova/api/openstack/compute/evacuate.py instead | |
| 09:17:29 | sahid | gibi, sean-k-mooney[m] Ok I think I have your point | |
| 09:20:52 | opendevreview | Sahid Orentino Ferdjaoui proposed openstack/nova-specs master: spec: allowing target state for evacuate https://review.opendev.org/c/openstack/nova-specs/+/857838 | |
| 09:21:02 | sahid | fixed ^ | |
| 09:42:54 | zigo | Hi there! I have a compute node with 3 VMs that look like having an affinity server group, so I can't live-evacuate the node (for kernel upgrade). How do I force the affinity to become a soft-affinity in the nova scheduler ? | |
| 09:43:16 | zigo | I think that's possible, right? | |
| 09:43:31 | kashyap | Good question, I don't even know top off my head. Perhaps bauzas or gibi | |
| 09:43:44 | gibi | zigo: you cannot change the policy of the group | |
| 09:44:06 | zigo | gibi: What's the way to evacuate my node then? | |
| 09:44:35 | gibi | zigo: if you want to live migrate the VM then you can use old microversion to specify the target host with force=true | |
| 09:44:52 | gibi | then the scheduler will not do any checks | |
| 09:44:58 | zigo | Oh, thanks! :) | |
| 09:45:09 | gibi | force available until 2.67 | |
| 09:46:14 | zigo | I'm on Victoria on that cluster, so that's 2.87... :) | |
| 09:48:55 | zigo | openstack server migrate: error: unrecognized arguments: --force | |
| 09:50:18 | zigo | "The Force" isn't with me ... :/ | |
| 09:51:58 | gibi | hm , I don't see --force in openstack client | |
| 09:53:34 | zigo | Right, so how do I do force=true ? | |
| 09:55:28 | gibi | if you use microversion < 2.30 the --host will also mean force as well. but please note that nova will not check the target host if it is valid or not | |
| 09:56:04 | gibi | also if you have an instance with nested allocation like bandwith, vgpu then forcing a host will not work properly, you will probably use the nested allocations | |
| 09:56:25 | gibi | s/use/lose/ | |
| 09:57:33 | gibi | if you want to have safe live migration then you need to disable the server group filter in the scheduler temporarily and do the migration without --host and then restore the filter | |
| 09:58:00 | zigo | Ah, ok. | |
| 09:58:30 | gibi | we lack the capability to change a policy on a server group so affinity is very sticky | |
| 10:01:33 | gibi | (with a small DB hack you can change the affinity to soft-affinity on the group :D) | |
| 10:17:03 | opendevreview | Amit Uniyal proposed openstack/nova stable/train: functional: Rework '_delete_server' https://review.opendev.org/c/openstack/nova/+/864721 | |
| 11:00:43 | zigo | gibi: That's what I ended-up doing, yes ... | |
| 11:00:54 | zigo | I just had a few "Error monitoring migration: internal error: client socket is closed: libvirt.libvirtError: internal error: client socket is closed" | |
| 11:01:00 | zigo | What does this mean, and how to avoid it? | |
| 11:01:55 | sean-k-mooney | that sound like the qemu instance crashed or at least teh qemu monitor connection | |
| 11:15:04 | zigo | ok... | |
| 12:17:38 | opendevreview | Kirill proposed openstack/nova-specs master: new spec: support of vnc console for ironic https://review.opendev.org/c/openstack/nova-specs/+/863773 | |
| 12:31:39 | opendevreview | Sahid Orentino Ferdjaoui proposed openstack/nova-specs master: spec: allowing target state for evacuate https://review.opendev.org/c/openstack/nova-specs/+/857838 | |
| 12:40:01 | opendevreview | Kirill proposed openstack/nova-specs master: new spec: support of vnc console for ironic https://review.opendev.org/c/openstack/nova-specs/+/863773 | |
| 12:42:42 | Kirill_ | hope i covered all wishes) | |
| 12:57:42 | sean-k-mooney | Kirill_: one benifit of looking up the password wehn you connec tby the way is you can actully rotate teh vnc passworkd on the ironic side if that is required by your security policy | |
| 12:58:00 | sean-k-mooney | iw we saved it in the nova db you could never change the vnc password on the ironic host | |
| 13:00:00 | Kirill_ | its not actually true. i mean if we change password on ironic side we will get new password via get_vnc_console method. and it will be stored in nova db. in auth_tokens table we have records for each vnc request | |
| 13:00:39 | Kirill_ | but as you said we need a db migration, so it is easier to make your realisation | |
| 13:00:44 | sean-k-mooney | you mean if you create a new console via the api | |
| 13:00:55 | sean-k-mooney | i guess it would update that way yes | |
| 13:01:41 | sean-k-mooney | so i kind of expect other to ask for more detail in the spec as you have not really explianed how your going to impmletne this in the proxy | |
| 13:04:43 | Kirill_ | just to clarify: more details with realisation with storing password on Nova side? cause with out storing there is nothing to add. i mean only realisation new class which can work with rfb protocol and addifn get_vnc_console method to ironic virt driver. | |
| 13:05:08 | Kirill_ | with out storing password there will e more changes on ironic side | |
| 13:05:32 | Kirill_ | adding new request to ironic_cli. but i think that need to discuss it in ironic channak | |
| 13:05:45 | sean-k-mooney | so without storing the password it would be nice to hav emore then 1 line on the change to the novnc proxy | |
| 13:06:36 | sean-k-mooney | we shoudl call out the depency on the ironic change and deatail the workflow that will be implmented | |
| 13:07:09 | sean-k-mooney | 1 user create console that creaate a token whihc is used by the proxy to corraltate the proxy request to the instnace | |
| 13:07:28 | sean-k-mooney | 2 the user connecct to the proxy with the token and the proxy looks up the password in ironic | |
| 13:08:06 | sean-k-mooney | 3 if that succeed the proxy connect to the vnc console exposed by the bmc and stream the result to the user | |
| 13:09:14 | sean-k-mooney | in step too it woudl be good to call out which ironic endpoint in the api we will invoke to get the password | |
| 13:09:57 | sean-k-mooney | nova does not use the cli by the way to the password need to be accesabel via the ironic api | |
| 13:10:36 | Kirill_ | oh, what do you use instead? | |
| 13:11:49 | sean-k-mooney | inter service comunciation is directly to the rest api. we can use the ironnic-pythonclinet to provide python binding for the rest api but we do not invoke the cli in a subshell | |
| 13:12:14 | sean-k-mooney | eventrually we want to drop the project client and move to the openstack sdk instead | |
| 13:12:44 | Kirill_ | ++ | |
| 13:13:07 | sean-k-mooney | if the info is already acceabel via the sdk you can just use that directly | |
| 13:13:35 | opendevreview | Alexey Stupnikov proposed openstack/nova stable/wallaby: Cleanup old resize instances dir before resize https://review.opendev.org/c/openstack/nova/+/864691 | |
| 13:14:49 | sean-k-mooney | Kirill_: currently we are using the ironic client for most things realted to ironic https://github.com/openstack/nova/blob/master/nova/virt/ironic/client_wrapper.py#L57 | |
| 13:15:42 | Kirill_ | i'd like to do smth like this:console = self.ironicclient.call('node.get_console', node_uuid = node_uuid) | |
| 13:15:47 | sean-k-mooney | but we do use the sdk in places | |
| 13:15:48 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/virt/ironic/driver.py#L378-L385 | |
| 13:16:05 | Kirill_ | get_console_> get_vnc_password | |
| 13:17:07 | sean-k-mooney | where is the vnc password stored | |
| 13:17:18 | sean-k-mooney | is it directly on the node | |
| 13:17:19 | Kirill_ | in ironic, idrac-info | |