opendevreview | Nobuhiro MIKI proposed openstack/nova master: libvirt: fix typo in test_config https://review.opendev.org/c/openstack/nova/+/864641 | 02:34 |
---|---|---|
*** dasm|off is now known as Guest1634 | 03:20 | |
opendevreview | Ghanshyam proposed openstack/nova master: Add service role in nova policy https://review.opendev.org/c/openstack/nova/+/864594 | 03:44 |
opendevreview | Ghanshyam proposed openstack/nova master: api-ref update: Move the service APIs in a separate section https://review.opendev.org/c/openstack/nova/+/864655 | 04:49 |
opendevreview | Ghanshyam proposed openstack/nova master: api-ref update: Move the service APIs in a separate section https://review.opendev.org/c/openstack/nova/+/864655 | 05:38 |
opendevreview | Amit Uniyal proposed openstack/nova stable/train: Refactor volume connection cleanup out of _post_live_migration https://review.opendev.org/c/openstack/nova/+/864670 | 05:44 |
opendevreview | Amit Uniyal proposed openstack/nova stable/train: Move pre-3.44 Cinder post live migration test to test_compute_mgr https://review.opendev.org/c/openstack/nova/+/864671 | 05:44 |
opendevreview | Amit Uniyal proposed openstack/nova stable/train: functional: Change order of two classes https://review.opendev.org/c/openstack/nova/+/864672 | 05:44 |
opendevreview | Ghanshyam proposed openstack/nova master: DNM: test new defaults https://review.opendev.org/c/openstack/nova/+/864673 | 05:51 |
*** han-guangyu is now known as Guest1648 | 06:02 | |
*** Guest1648 is now known as han-guangyu | 06:02 | |
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:10 |
han-guangyu | Hello, I want to package ovn in openEuler(a OS had been supported by openstack ci)) | 06:13 |
han-guangyu | Could I can get a recommended version of ovn to Train and Wallaby | 06:14 |
han-guangyu | I see: | 06:14 |
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:14 |
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 |
han-guangyu | Do they have a capped version that supports | 06:16 |
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:17 |
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 |
han-guangyu | oh | 06:21 |
han-guangyu | I send to a incorret channel | 06:21 |
han-guangyu | I want to neutron , sorry | 06:21 |
opendevreview | Younghwan Yoo proposed openstack/nova master: Update return value to be a valid UUID https://review.opendev.org/c/openstack/nova/+/864674 | 06:37 |
opendevreview | Amit Uniyal proposed openstack/nova stable/train: functional: Change order of two classes https://review.opendev.org/c/openstack/nova/+/864672 | 06:42 |
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 | 07:56 |
*** han-guangyu__ is now known as han-guangyu | 08:36 | |
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:02 |
sahid | gibi, sean-k-mooney o/ if you can have a second look at ^ there is one point that I don't get | 09:03 |
gibi | sahid: looking... | 09:05 |
*** han-guangyu is now known as Guest1660 | 09:08 | |
*** han-guangyu_ is now known as han-guangyu | 09:08 | |
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:08 |
sean-k-mooney[m] | so if you upgrade the api and conductors but not the computes | 09:09 |
sean-k-mooney[m] | we would still reject the new microversion | 09:09 |
sean-k-mooney[m] | until you completed updating all the computes | 09:09 |
gibi | yepp | 09:10 |
gibi | I left a reply in the review too | 09:10 |
gibi | but it is what sean-k-mooney[m] described above | 09:11 |
sean-k-mooney[m] | we do this with a decorator on the api method | 09:11 |
sean-k-mooney[m] | https://github.com/openstack/nova/blob/bcdf5988f6ae902dba9b41144a7b4a60688b627c/nova/compute/api.py#L283 | 09:11 |
sean-k-mooney[m] | that is an example for vdpa | 09:11 |
sean-k-mooney[m] | you will need to reject the new microverion untill the requied min service version is reached | 09:12 |
sean-k-mooney[m] | you might want to do this eailer then that actully | 09:15 |
sean-k-mooney[m] | i dont think we have the microverion at that point | 09:15 |
opendevreview | Amit Uniyal proposed openstack/nova stable/train: functional: Unify '_wait_until_deleted' implementations https://review.opendev.org/c/openstack/nova/+/864712 | 09:16 |
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 |
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:16 |
sahid | gibi, sean-k-mooney[m] Ok I think I have your point | 09:17 |
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:20 |
sahid | fixed ^ | 09:21 |
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:42 |
zigo | I think that's possible, right? | 09:43 |
kashyap | Good question, I don't even know top off my head. Perhaps bauzas or gibi | 09:43 |
gibi | zigo: you cannot change the policy of the group | 09:43 |
zigo | gibi: What's the way to evacuate my node then? | 09:44 |
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 |
gibi | then the scheduler will not do any checks | 09:44 |
zigo | Oh, thanks! :) | 09:44 |
* zigo tries | 09:45 | |
gibi | force available until 2.67 | 09:45 |
zigo | I'm on Victoria on that cluster, so that's 2.87... :) | 09:46 |
zigo | openstack server migrate: error: unrecognized arguments: --force | 09:48 |
zigo | "The Force" isn't with me ... :/ | 09:50 |
gibi | hm , I don't see --force in openstack client | 09:51 |
zigo | Right, so how do I do force=true ? | 09:53 |
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:55 |
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 |
gibi | s/use/lose/ | 09:56 |
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:57 |
zigo | Ah, ok. | 09:58 |
gibi | we lack the capability to change a policy on a server group so affinity is very sticky | 09:58 |
gibi | (with a small DB hack you can change the affinity to soft-affinity on the group :D) | 10:01 |
opendevreview | Amit Uniyal proposed openstack/nova stable/train: functional: Rework '_delete_server' https://review.opendev.org/c/openstack/nova/+/864721 | 10:17 |
zigo | gibi: That's what I ended-up doing, yes ... | 11:00 |
zigo | I just had a few "Error monitoring migration: internal error: client socket is closed: libvirt.libvirtError: internal error: client socket is closed" | 11:00 |
zigo | What does this mean, and how to avoid it? | 11:01 |
sean-k-mooney | that sound like the qemu instance crashed or at least teh qemu monitor connection | 11:01 |
zigo | ok... | 11:15 |
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:17 |
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:31 |
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:40 |
Kirill_ | hope i covered all wishes) | 12: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:57 |
sean-k-mooney | iw we saved it in the nova db you could never change the vnc password on the ironic host | 12:58 |
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 |
Kirill_ | but as you said we need a db migration, so it is easier to make your realisation | 13:00 |
sean-k-mooney | you mean if you create a new console via the api | 13:00 |
sean-k-mooney | i guess it would update that way yes | 13:00 |
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:01 |
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:04 |
Kirill_ | with out storing password there will e more changes on ironic side | 13:05 |
Kirill_ | adding new request to ironic_cli. but i think that need to discuss it in ironic channak | 13:05 |
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:05 |
sean-k-mooney | we shoudl call out the depency on the ironic change and deatail the workflow that will be implmented | 13:06 |
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 |
sean-k-mooney | 2 the user connecct to the proxy with the token and the proxy looks up the password in ironic | 13:07 |
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:08 |
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 |
sean-k-mooney | nova does not use the cli by the way to the password need to be accesabel via the ironic api | 13:09 |
Kirill_ | oh, what do you use instead? | 13:10 |
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:11 |
sean-k-mooney | eventrually we want to drop the project client and move to the openstack sdk instead | 13:12 |
Kirill_ | ++ | 13:12 |
sean-k-mooney | if the info is already acceabel via the sdk you can just use that directly | 13:13 |
opendevreview | Alexey Stupnikov proposed openstack/nova stable/wallaby: Cleanup old resize instances dir before resize https://review.opendev.org/c/openstack/nova/+/864691 | 13:13 |
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:14 |
Kirill_ | i'd like to do smth like this:console = self.ironicclient.call('node.get_console', node_uuid = node_uuid) | 13:15 |
sean-k-mooney | but we do use the sdk in places | 13:15 |
sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/virt/ironic/driver.py#L378-L385 | 13:15 |
Kirill_ | get_console_> get_vnc_password | 13:16 |
sean-k-mooney | where is the vnc password stored | 13:17 |
sean-k-mooney | is it directly on the node | 13:17 |
Kirill_ | in ironic, idrac-info | 13:17 |
Kirill_ | on node | 13:17 |
Kirill_ | node show will return vnc_pasword:**** | 13:18 |
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:18 |
sean-k-mooney | so you should jsut be able to call that and do pwd = node.vnc_password | 13:19 |
Kirill_ | yep, sound good | 13:21 |
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:23 |
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:25 |
*** abhishekk is now known as akekane|home | 13:26 | |
Kirill_ | thanks, need to check it | 13:26 |
opendevreview | Alexey Stupnikov proposed openstack/nova stable/victoria: Cleanup old resize instances dir before resize https://review.opendev.org/c/openstack/nova/+/864730 | 13:40 |
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 |
opendevreview | Alexey Stupnikov proposed openstack/nova stable/ussuri: Cleanup old resize instances dir before resize https://review.opendev.org/c/openstack/nova/+/864732 | 13:48 |
*** Guest1634 is now known as dasm | 13:48 | |
opendevreview | Alexey Stupnikov proposed openstack/nova stable/train: Cleanup old resize instances dir before resize https://review.opendev.org/c/openstack/nova/+/864692 | 13:51 |
Uggla | bauzas, shit ! I have just encountered a "great python" ! ;) | 14:05 |
bauzas | sorry, was at the doc for a inflamed shoulder ;) | 14:17 |
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 |
sahid | so I have to add a check to here which verifies that the RPC version is supported | 14:40 |
sahid | https://review.opendev.org/c/openstack/nova/+/858384/19/nova/api/openstack/compute/evacuate.py#98 | 14:40 |
sahid | that is the point? I'm verify sorry I'm not so famialiar with the API/RPC part | 14:41 |
sean-k-mooney | so indie that if | 14:44 |
sean-k-mooney | *inside | 14:44 |
sean-k-mooney | you can get the min compute service verion | 14:45 |
sean-k-mooney | and raise an excption if it below the one required for your feature | 14:45 |
sahid | perfect, got it! | 14:45 |
sahid | thanks a lot | 14:45 |
sean-k-mooney | min_ver = objects.service.get_minimum_version_all_cells( | 14:46 |
sean-k-mooney | nova_context.get_admin_context(), ['nova-compute'] | 14:46 |
sean-k-mooney | ) | 14:46 |
sean-k-mooney | that will give you the min version | 14:46 |
sean-k-mooney | so just to if min_ver < X raise ... | 14:46 |
sahid | :-) | 14:47 |
sean-k-mooney | we normally do this latter but its similar to do it there | 14:47 |
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:14 |
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 |
bauzas | sean-k-mooney: but I wonder how we could let the operators *specify* it | 16:27 |
bauzas | a ListOpt doesn't really help | 16:27 |
bauzas | as we would need to guess which governor is the powersaving one and which one is the best performant | 16:27 |
bauzas | sean-k-mooney: and I feel a DictOpt is too much painful to add | 16:28 |
bauzas | sean-k-mooney: see my concern ? | 16:29 |
sean-k-mooney | well i was thinking of having the first be the low power and second high | 16:39 |
sean-k-mooney | but you could just add 2 config options | 16:39 |
sean-k-mooney | for high and low | 16:39 |
sean-k-mooney | dictopts are supporte by oslo but we dont currently use them in nova | 16:40 |
bauzas | correct hence me reluctant | 16:40 |
sean-k-mooney | bauzas: its really just the active/high-power one that we really care about | 16:40 |
sean-k-mooney | powersave runs the cpu at the lowest frequency it can without turning off | 16:40 |
sean-k-mooney | performance is the opicite | 16:41 |
sean-k-mooney | in general you would not want to hardcode perfromace if your trying to manage power | 16:41 |
sean-k-mooney | so if the high power one was configurable that woudl be enough | 16:41 |
sean-k-mooney | if you want to keep it simple howwever why not add two config options | 16:42 |
sean-k-mooney | cpu_high_power_govoner and cpu_low_power_govoner | 16:42 |
sean-k-mooney | just simple stings | 16:42 |
bauzas | yup, that's what I write now | 16:42 |
sean-k-mooney | works for me | 16:43 |
bauzas | we could bikeshed on the namings | 16:43 |
sean-k-mooney | gibi: ^ | 16:43 |
opendevreview | Sylvain Bauza proposed openstack/nova-specs master: Proposes cpu power managment in libvirt https://review.opendev.org/c/openstack/nova-specs/+/861591 | 16:43 |
bauzas | there you go | 16:43 |
opendevreview | Sylvain Bauza proposed openstack/nova master: Deprecate mdev creation and hardfail on reboot when missing. https://review.opendev.org/c/openstack/nova/+/864418 | 17:10 |
opendevreview | Sylvain Bauza proposed openstack/nova master: Reproducer for bug 1951656 https://review.opendev.org/c/openstack/nova/+/850673 | 17:10 |
opendevreview | Sylvain Bauza proposed openstack/nova master: Handle mdev devices in libvirt 7.7+ https://review.opendev.org/c/openstack/nova/+/838976 | 17:10 |
opendevreview | John Garbutt proposed openstack/nova master: Ironic nodes with instance reserved in placement https://review.opendev.org/c/openstack/nova/+/864773 | 17:25 |
johnthetubaguy | gibi: I think I may have found an "interesting" way to close that ironic scheduler race with automatic clean, but it feels a bit wrong, its a follow on from that patch you reviewed yesterday: https://review.opendev.org/c/openstack/nova/+/864773 | 17:28 |
gibi | johnthetubaguy: that is a clever one | 17:31 |
johnthetubaguy | it might be too clever, but it seems to work... funky right? | 17:32 |
gibi | I think we intentionally designed placement in a way that it allows reserving already allocated inventories | 17:33 |
gibi | but not allow allocating reserved ones | 17:33 |
gibi | so I think what you do is OK from placement perspective | 17:33 |
gibi | how likely that a big ironic deployment has no cleaning configured and the update_provider_tree periodic is set to a big value due to preformance reasons? | 17:36 |
johnthetubaguy | OK, neat. I remember some related discussions around increasing host reserved memory, and it sounded OK ish. | 17:36 |
johnthetubaguy | ... unsure, that is a very good question. Most large deployments I work on do automatic cleaning, but I know that far from representative | 17:37 |
johnthetubaguy | (I have to run I am afraid, I am told my dinner is going cold) | 17:37 |
gibi | johnthetubaguy: no worries. I will leave the feedback in the review | 17:37 |
gibi | have a nice dinner | 17:40 |
sean-k-mooney | o/ just saw the comment on ironic reivew | 17:45 |
sean-k-mooney | is the plan to proceed with https://review.opendev.org/c/openstack/nova/+/842478 anyway | 17:46 |
sean-k-mooney | if so i can review again tomorrow | 17:46 |
sean-k-mooney | i am mostly out of brain power today but i dont mind looking at it in the morning | 17:47 |
sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/864773 is the other one? to review with https://review.opendev.org/c/openstack/nova/+/842478 | 17:48 |
sean-k-mooney | and yes if you are over allcoated you cannot make new allcoations | 17:51 |
sean-k-mooney | but i think you are right that you can modify the reserve value | 17:52 |
sean-k-mooney | like you can go form reservice 0 cpus to 10 and if that would over allocate that is fine it will be resolved when a vm is delete/moved | 17:53 |
sean-k-mooney | i have not looked at johnthetubaguy clever solution but form context i assume it invovles setting the reserved value to 1 for the custom resoucs inventory that represnt the baremetal hosts | 17:54 |
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 | 18:03 |
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 | 22:02 |
*** dasm is now known as dasm|off | 23:11 | |
opendevreview | Younghwan Yoo proposed openstack/nova master: Update return value to be a valid UUID https://review.opendev.org/c/openstack/nova/+/864674 | 23:41 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!