| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-11-16 | |||
| 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 | |
| 13:17:34 | Kirill_ | on node | |
| 13:18:13 | Kirill_ | node show will return vnc_pasword:**** | |
| 13:18:42 | sean-k-mooney | ok we alreay have a get node function https://github.com/openstack/nova/blob/master/nova/virt/ironic/driver.py#L215-L226 | |
| 13:19:20 | sean-k-mooney | so you should jsut be able to call that and do pwd = node.vnc_password | |
| 13:21:10 | Kirill_ | yep, sound good | |
| 13:23:09 | sean-k-mooney | i dont directly see it here https://github.com/openstack/openstacksdk/blob/master/openstack/baremetal/v1/node.py#L97-L246 but its proably there on a sub filed of one of those properties | |
| 13:25:54 | sean-k-mooney | its not directly in https://github.com/openstack/python-ironicclient/blob/master/ironicclient/v1/node.py either so im guessing its a subfield | |
| 13:26:58 | Kirill_ | thanks, need to check it | |
| 13:40:03 | opendevreview | Alexey Stupnikov proposed openstack/nova stable/victoria: Cleanup old resize instances dir before resize https://review.opendev.org/c/openstack/nova/+/864730 | |
| 13:41:52 | opendevreview | Alexey Stupnikov proposed openstack/nova stable/victoria: Cleanup old resize instances dir before resize https://review.opendev.org/c/openstack/nova/+/864730 | |
| 13:48:28 | opendevreview | Alexey Stupnikov proposed openstack/nova stable/ussuri: Cleanup old resize instances dir before resize https://review.opendev.org/c/openstack/nova/+/864732 | |
| 13:51:15 | opendevreview | Alexey Stupnikov proposed openstack/nova stable/train: Cleanup old resize instances dir before resize https://review.opendev.org/c/openstack/nova/+/864692 | |
| 14:05:58 | Uggla | bauzas, shit ! I have just encountered a "great python" ! ;) | |
| 14:17:15 | bauzas | sorry, was at the doc for a inflamed shoulder ;) | |
| 14:40:05 | sahid | o/ gibi,sean-k-mooney again me :-) About your point on the spec https://review.opendev.org/c/openstack/nova-specs/+/857838 | |
| 14:40:46 | sahid | so I have to add a check to here which verifies that the RPC version is supported | |
| 14:40:49 | sahid | https://review.opendev.org/c/openstack/nova/+/858384/19/nova/api/openstack/compute/evacuate.py#98 | |
| 14:41:34 | sahid | that is the point? I'm verify sorry I'm not so famialiar with the API/RPC part | |
| 14:44:46 | sean-k-mooney | so indie that if | |
| 14:44:51 | sean-k-mooney | *inside | |
| 14:45:01 | sean-k-mooney | you can get the min compute service verion | |
| 14:45:13 | sean-k-mooney | and raise an excption if it below the one required for your feature | |
| 14:45:29 | sahid | perfect, got it! | |
| 14:45:35 | sahid | thanks a lot | |
| 14:46:07 | sean-k-mooney | min_ver = objects.service.get_minimum_version_all_cells( | |
| 14:46:09 | sean-k-mooney | nova_context.get_admin_context(), ['nova-compute'] | |
| 14:46:11 | sean-k-mooney | ) | |
| 14:46:13 | sean-k-mooney | that will give you the min version | |
| 14:46:32 | sean-k-mooney | so just to if min_ver < X raise ... | |
| 14:47:05 | sahid | :-) | |
| 14:47:22 | sean-k-mooney | we normally do this latter but its similar to do it there | |
| 16:14:27 | opendevreview | Rafael Weingartner proposed openstack/nova master: Nova to honor "cross_az_attach" during server(VM) migrations https://review.opendev.org/c/openstack/nova/+/864760 | |
| 16:27:03 | bauzas | sean-k-mooney: I'm not opposed to the fact we don't hardly specific cpu governors in nova and we let the operator decide which ones they want https://review.opendev.org/c/openstack/nova-specs/+/861591/comments/6a5d4488_55cda4bd | |
| 16:27:17 | bauzas | sean-k-mooney: but I wonder how we could let the operators *specify* it | |
| 16:27:27 | bauzas | a ListOpt doesn't really help | |
| 16:27:51 | bauzas | as we would need to guess which governor is the powersaving one and which one is the best performant | |
| 16:28:41 | bauzas | sean-k-mooney: and I feel a DictOpt is too much painful to add | |
| 16:29:10 | bauzas | sean-k-mooney: see my concern ? | |
| 16:39:25 | sean-k-mooney | well i was thinking of having the first be the low power and second high | |
| 16:39:37 | sean-k-mooney | but you could just add 2 config options | |
| 16:39:43 | sean-k-mooney | for high and low | |
| 16:40:03 | sean-k-mooney | dictopts are supporte by oslo but we dont currently use them in nova | |
| 16:40:25 | bauzas | correct hence me reluctant | |
| 16:40:40 | sean-k-mooney | bauzas: its really just the active/high-power one that we really care about | |
| 16:40:59 | sean-k-mooney | powersave runs the cpu at the lowest frequency it can without turning off | |
| 16:41:10 | sean-k-mooney | performance is the opicite | |
| 16:41:31 | sean-k-mooney | in general you would not want to hardcode perfromace if your trying to manage power | |
| 16:41:58 | sean-k-mooney | so if the high power one was configurable that woudl be enough | |
| 16:42:15 | sean-k-mooney | if you want to keep it simple howwever why not add two config options | |
| 16:42:36 | sean-k-mooney | cpu_high_power_govoner and cpu_low_power_govoner | |
| 16:42:41 | sean-k-mooney | just simple stings | |
| 16:42:58 | bauzas | yup, that's what I write now | |
| 16:43:05 | sean-k-mooney | works for me | |
| 16:43:10 | bauzas | we could bikeshed on the namings | |