| *** mhen_ is now known as mhen | 01:18 | |
| gibi | release liasions please check the pending nova stable releases we have an important security hardening bug in them | 09:42 |
|---|---|---|
| gibi | https://ironicbaremetal.org/blog/coming-soon-threading/ | 09:42 |
| gibi | https://review.opendev.org/c/openstack/releases/+/957951 | 09:42 |
| gibi | https://review.opendev.org/c/openstack/releases/+/958009 | 09:42 |
| gibi | https://review.opendev.org/c/openstack/releases/+/947847 | 09:42 |
| gibi | ahh I see Uggla was there already. | 09:45 |
| Uggla | @gibi, yes I think I have reviewed them, unless I miss one. | 09:46 |
| opendevreview | Kamil Sambor proposed openstack/nova master: [hacking] Improve N373 to catch also other primitives https://review.opendev.org/c/openstack/nova/+/958408 | 10:02 |
| elodilles | gibi: the release patches merged, things should be available on pypi and tarball.o.o, tags, etc., in some minutes | 10:09 |
| elodilles | Uggla: ^^^ | 10:09 |
| gibi | elodilles: thanks! | 10:13 |
| elodilles | np | 10:15 |
| *** sean-k-mooney1 is now known as sean-k-mooney | 12:54 | |
| opendevreview | Kamil Sambor proposed openstack/nova master: Switch nova-conductor to use ThreadPoolExecutor https://review.opendev.org/c/openstack/nova/+/957088 | 13:02 |
| hayashino | Could someone review this patch? https://review.opendev.org/c/openstack/nova/+/942167 | 13:13 |
| opendevreview | Kamil Sambor proposed openstack/nova master: Switch nova-conductor to use ThreadPoolExecutor https://review.opendev.org/c/openstack/nova/+/957088 | 13:52 |
| *** DHE_ is now known as DHE | 14:44 | |
| bryanfraschetti | Hello Nova team o/ | 16:01 |
| bryanfraschetti | Hope you're all doing well. I'm just wondering the current state of this bug: https://bugs.launchpad.net/nova/+bug/2039803, where live migration fails across similar hosts due to the compareHypervisorCPU check, and the associated topic: https://review.opendev.org/q/topic:%22bp/cpu-selection-with-hypervisor-consideration%22. I noticed that there was a recent comment | 16:01 |
| bryanfraschetti | https://bugs.launchpad.net/nova/+bug/2039803/comments/9, which mentioned that replacing the baselineCPU method is one of the remaining missing puzzle pieces but I don't have a lot of context on what's been done and what's needed. | 16:01 |
| bryanfraschetti | It might be worth mentioning that that we're seeing this on Ubuntu Jammy / Caracal, which contains the other two commits mentioned in that same comment. | 16:01 |
| sean-k-mooney | bryanfraschetti: ya so it depend on the specific cpu version you have | 16:32 |
| sean-k-mooney | the root cause si effectivly this | 16:32 |
| sean-k-mooney | for some cpus the diffent ebtween the capablities api and domcapabiltys api out can cause the migration check in nova to fail | 16:32 |
| sean-k-mooney | there is a workaroudn config option to disable the nova check in pre-migration and rely on the much later libvirt check | 16:33 |
| sean-k-mooney | that is much more costly to revert when it fails but ti will work in more cases | 16:33 |
| sean-k-mooney | the other alternitive is to use an explcit custom model instead of host-model or leaving the cpu_mode empty | 16:34 |
| sean-k-mooney | cpu_mode unset and host-model are almsot but not quite identical | 16:34 |
| sean-k-mooney | they are ment to select teh virtual cpu model that supprot hte largest subset of the host cpu features | 16:35 |
| sean-k-mooney | that should be the closest cpu model to the hsot i.e. the host-model | 16:35 |
| sean-k-mooney | for soem intel cpus in particalr but also newer amd cpus the odl and new api may differ. | 16:36 |
| sean-k-mooney | using the new api in all places coudl fix it | 16:36 |
| sean-k-mooney | the only concern then woudl be makeign sure the havior fo host-model and unset remains the same | 16:36 |
| sean-k-mooney | bryanfraschetti: given Feature Freeze for this cycle is on thrusday this is not currently a priorty for the core team however if someone has time to work on fixign it we wont boject | 16:37 |
| sean-k-mooney | but we likely wont have time to review for a week or two | 16:37 |
| *** melwitt_ is now known as jgwentworth | 16:43 | |
| *** jgwentworth is now known as melwitt | 16:44 | |
| bryanfraschetti | Thanks @sean-k-mooney for the explanation that clarifies things a lot actually. So the issue isn't so much the new approach of comparing hypervisors but rather that there's mixed usage of new and old approaches to check the capabilities, which can sometimes disagree - especially on new intel cpus. Consistently applying the new approach should resolve the discrepancies, which makes sense. | 16:56 |
| bryanfraschetti | Quick Q about the workaround options which skip the pre-migration check. What happens if these are enabled (eg. skip_cpu_check_on_start and skip_check_on_dest), but the hypervisors truly are incompatible and migration fails? Will this be caught by the libvirt check, and will the migration roll back - effectively not migrating, or will the migration be left in a broken state? | 16:56 |
| gmaan | sean-k-mooney: on service role, I was checking if neutron has documented that nova service user need 'service' role or not but I could not find. Cinder has documented it so that is good. | 16:58 |
| gmaan | sean-k-mooney: and I am now thinking many operator might have not have 'service' role and might have configured only admin role in neutron.conf | 16:59 |
| gmaan | and nova policy change to 'role:service' will break them. I am now re-thinking on keep allowing admin also for those service API at least for this cycle - https://review.opendev.org/c/openstack/nova/+/957578/comment/a097d558_fee01375/ | 17:00 |
| gmaan | and this cycle I can update neutron doc and release notes about requiring 'service' role to nova user | 17:00 |
| gmaan | when I objected on not allowing admin, I thought of only direct user usage of service APIs which should be blocked right away but did not know that neutron did not state about 'service' role for their service users | 17:02 |
| gmaan | and new default enable by default makes nova change to break such neutron deployment which has only admin role on nova user | 17:02 |
| gmaan | I know you are ok with admin-or-service role but just want to confirm that we are on same page as I spent lot of time on service token things in tempest, neutron, oslo.policy check side which I should not have if discussed with you in advance :( | 17:04 |
| sean-k-mooney | gmaan: so that why i orginlly propsoed doing `service or admin` last cycle | 17:04 |
| sean-k-mooney | for upgrades | 17:04 |
| sean-k-mooney | in our installer we alwasy create the users for service with both admin and service roles | 17:05 |
| gmaan | yeah, I know. I thought admin role given to service user was just in devstack because we implies those in our policy but agree now that operator can have same | 17:05 |
| sean-k-mooney | no that how kolla etcra all do it | 17:06 |
| gmaan | let me update my change and once that is merged I can update the spec document also to sync with implementation | 17:06 |
| sean-k-mooney | im not sure if kolla give both admin and serivice or just admin today | 17:06 |
| sean-k-mooney | i think it became more comment when we started requiring it for nova and cinder to talk to each other | 17:07 |
| sean-k-mooney | but i ahve not checked in a long time | 17:07 |
| gmaan | yeah, I am not sure if they have service role but maybe | 17:08 |
| sean-k-mooney | gmaan: the have supprote for at least ironci https://github.com/openstack/kolla-ansible/commit/600e912400ab8b52ca422f007f63da9d4fcc0a69 | 18:00 |
| sean-k-mooney | https://github.com/search?q=repo%3Aopenstack%2Fkolla-ansible++role%3A+%5C%22service%5C%22&type=code | 18:01 |
| sean-k-mooney | it looks like kolla at least does provide teh service role to several services but not to all | 18:02 |
| sean-k-mooney | ironic nova cidner | 18:02 |
| gmaan | yeah, and for neutron too so nova will be ok | 18:02 |
| JayF | sean-k-mooney: I am not certain Ironic documents to use a service scope/role user | 18:03 |
| JayF | sean-k-mooney: even if we permit and support it | 18:03 |
| sean-k-mooney | oh i missed neutron yes | 18:03 |
| JayF | sean-k-mooney: so we should ensure, if we're changing the shape of this, not only to ask what's possible, but ask what is likely and what path we've been asking folks to take | 18:03 |
| gmaan | yeah, that is what i am mainly checking because most of the place it is done like 'neutron need admin to talk to nova' which is ok but still add service role too | 18:04 |
| sean-k-mooney | JayF: right so orginally i propeose haveing the policy rule be admin_or_service for 1 slurp and then service_only | 18:04 |
| sean-k-mooney | but we are tryign to determin if that is actuly required or not | 18:05 |
| JayF | there's no doubt in my mind the answer is "yes" | 18:05 |
| sean-k-mooney | to be safe we proably shoudl but we dropted that form this release spec | 18:05 |
| sean-k-mooney | because we tought it was not required | 18:05 |
| gmaan | we could avoid it if we implemeted it before we switch to enable the global new defaults | 18:05 |
| sean-k-mooney | well we already did that no? | 18:06 |
| sean-k-mooney | i tougl we did that a release or two ago | 18:06 |
| sean-k-mooney | as part of phase 1 | 18:06 |
| gmaan | yes I mean if new defaults were disabled by default then admin was added via old default by oslo.policy | 18:06 |
| sean-k-mooney | oh | 18:06 |
| sean-k-mooney | ok well ya that bridge has sailed... /me bridges dont sail boats do.... | 18:07 |
| * sean-k-mooney or ships | 18:07 | |
| *** haleyb is now known as haleyb|out | 20:58 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!