| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-08-07 | |||
| 09:59:29 | kashyap | (The above is when migrating only from source hardware that supports 'arch-facilities' CPU feature.) | |
| 10:01:57 | lyarwood | urgh we need to fix this in Nova tbh | |
| 10:02:14 | lyarwood | we can check on the dest if arch-capabilities is set | |
| 10:02:26 | lyarwood | if it is, use it in the migration xml we send there | |
| 10:03:05 | lyarwood | if it isn't but arch-facilities is set on the src, remove that from the migration xml | |
| 10:03:12 | lyarwood | does that sound right? | |
| 10:05:40 | kashyap | lyarwood: Reading the scroll | |
| 10:05:49 | lyarwood | brb coffee | |
| 10:06:15 | kashyap | lyarwood: Right, that does sound correct. I'm gonna file a bug for it | |
| 10:06:43 | kashyap | lyarwood: Oh, but note: 'arch-facilties' is marked as *non-migratable* | |
| 10:10:35 | lyarwood | /o\ | |
| 10:10:42 | lyarwood | so should we always remove it? | |
| 10:12:50 | kashyap | lyarwood: I'd change the plan to this: just drop 'arch-facilities' and let libvirt handle it — this works, Jiri from libvirt confirms | |
| 10:13:44 | lyarwood | kashyap: ack that's simple enough then | |
| 10:15:58 | lyarwood | kashyap: as you're out on PTO next week I'd be happy to handle that once you've written up the bug | |
| 10:22:17 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Follow up for Ibf8dca4bd57b3bddb39955b53cc03564506f5754 https://review.opendev.org/745095 | |
| 10:25:37 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Pass context, instance to '_create_guest' https://review.opendev.org/741286 | |
| 10:25:37 | openstackgerrit | Stephen Finucane proposed openstack/nova master: tests: Add helpers for suspend, resume and reboot of server https://review.opendev.org/741285 | |
| 10:25:38 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Add emulated TPM support to Nova https://review.opendev.org/631363 | |
| 10:25:38 | openstackgerrit | Stephen Finucane proposed openstack/nova master: api: Reject non-spawn operations for vTPM https://review.opendev.org/741500 | |
| 10:25:39 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add type hints to 'nova.compute.manager' https://review.opendev.org/742863 | |
| 10:25:39 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Add docs for vTPM support https://review.opendev.org/739213 | |
| 10:25:40 | openstackgerrit | Stephen Finucane proposed openstack/nova master: privsep: Add support for recursive chown, move_tree operations https://review.opendev.org/742864 | |
| 10:25:40 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Don't unset Instance.old_flavor, new_flavor until necessary https://review.opendev.org/741995 | |
| 10:25:41 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add support for resize and cold migration of emulated TPM files https://review.opendev.org/639934 | |
| 10:25:41 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add type hints to 'nova.virt.libvirt.utils' https://review.opendev.org/742865 | |
| 10:30:58 | kashyap | lyarwood: A quick one, without checking the code, the migrate XML - is it the one we send to _compare_cpu() method or to libvirt's migrate API? | |
| 10:31:27 | kashyap | lyarwood: I'll let you know once I've got the bug up... | |
| 10:32:58 | lyarwood | kashyap: libvirt's migrate API | |
| 10:33:05 | lyarwood | kashyap: is this failing in _compare_cpu? | |
| 10:33:25 | kashyap | lyarwood: Yep, the failure is indeed from _compare_cpu() | |
| 10:34:25 | kashyap | This whole thing needs replacing; see my earlier-mentinoned spec on newer APIs. I've got a draft patch branch for it somewhere (https://opendev.org/openstack/nova-specs/commit/70811da221035044e27) | |
| 10:34:43 | kashyap | But the "full replacing" can wait. One step at a time | |
| 10:35:22 | kashyap | lyarwood: Oh, sigh; 'arch-facilities' is a EL-only thing :-( | |
| 10:35:46 | lyarwood | \o/ | |
| 10:35:47 | kashyap | lyarwood: So, I don't think it makes sense for upstream; perhaps a EL-8 downstream-specific patch is needed | |
| 10:35:51 | lyarwood | ggwp libvirt | |
| 10:36:42 | kashyap | lyarwood: Yeah, annoying: | |
| 10:36:47 | kashyap | [quote] | |
| 10:36:48 | kashyap | confusion about the correct naming. | |
| 10:36:48 | kashyap | RHEL version of QEMU. Let's update the test files to avoid possible | |
| 10:36:48 | kashyap | arch-facilities. Apparently some CPU test files were gathered with the | |
| 10:36:48 | kashyap | The kernel calls this feature arch_capabilities and RHEL/CentOS 7.* use | |
| 10:36:50 | kashyap | [/quote] | |
| 10:36:54 | kashyap | From here: https://libvirt.org/git/?p=libvirt.git;a=commit;h=511df17aec | |
| 10:36:58 | kashyap | Err, wrong link | |
| 10:37:13 | kashyap | No, that's correct. (Self, slow down) | |
| 11:52:41 | sean-k-mooney | kashyap: we do cache the host capablities i belive too. i think i added that | |
| 11:53:02 | sean-k-mooney | kashyap: but this is a downstream only bug anyway so not really an issue with caching | |
| 11:54:10 | sean-k-mooney | well i think we cache the domain caps | |
| 11:54:31 | sean-k-mooney | which is slitghly different | |
| 11:56:46 | sean-k-mooney | we cache both https://github.com/openstack/nova/blob/stable/train/nova/virt/libvirt/host.py#L693-L843 | |
| 11:57:16 | kashyap | Yeah, domain caps is different from host capabilities | |
| 11:57:29 | kashyap | 'virsh capabilities' vs. 'virsh domcapabilities' | |
| 11:57:32 | kashyap | Confusing | |
| 11:57:33 | sean-k-mooney | yep | |
| 11:57:35 | sean-k-mooney | i know | |
| 11:57:37 | sean-k-mooney | we cache both | |
| 11:59:09 | sean-k-mooney | looks like we have cached the host capabilities since danpb added the function | |
| 11:59:43 | sean-k-mooney | libvirt caches the data too in the drivers so its not going to chagne without restart the libvirt deamon anyway | |
| 12:05:44 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add new default roles in FIP policies https://review.opendev.org/742030 | |
| 12:06:36 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Pass the actual target in FIP policy https://review.opendev.org/742570 | |
| 12:33:35 | gibi | and now I clogged the gate with all the open, and now approved, policy patches | |
| 12:33:38 | gibi | happy Friday :D | |
| 12:34:16 | sean-k-mooney | :) | |
| 13:36:46 | mnaser | i'm trying to clean up our configs and start using the service catalog for auto discovery of services in nova | |
| 13:36:53 | mnaser | (to stop using glance api_servers) | |
| 13:37:11 | mnaser | "NOTE: The preferred mechanism for endpoint discovery is via keystoneauth1 loading options. Only use api_servers if you need multiple endpoints and are unable to use a load balancer for some reason." | |
| 13:37:17 | mnaser | does this mean i would fill this up like the neutron section? | |
| 13:37:24 | mnaser | or is there a common section? the docs don't seem clera there | |
| 13:40:23 | sean-k-mooney | are you using haproxy infront of glance api | |
| 13:40:39 | sean-k-mooney | or are you listing multiple glance api_servers | |
| 13:41:35 | sean-k-mooney | mnaser: you will have to fill it in if you are using nova as a loadbalncer for the glance api but ideally you would not use that and instead just deploy haproxy | |
| 13:41:57 | sean-k-mooney | wicch you proably are already doing for other services | |
| 13:43:53 | mnaser | sean-k-mooney: we already have haproxy :) i mainly just dont wanna hardcode the api_servers value and let nova do service discovery | |
| 13:45:06 | mnaser | so pretty much just want nova to use the value inside the service catalog | |
| 13:45:27 | sean-k-mooney | mnaser: yep that is what we woudl prefer peopel to do too. some want to remove that config option but other find it useful in small edge deployments | |
| 13:45:28 | gmann | thanks gibi or all the reviews on policy work and updating FIP one. | |
| 13:45:46 | gibi | gmann: thanks for proposing these patches | |
| 13:46:41 | sean-k-mooney | mnaser: the vaule in the service catalog will have to point to the ha proxy ip | |
| 13:46:43 | gmann | gibi: I will do the audit of some TODO/cleanup if there us any by Monday/Tuesday and then we can mark that BP complete. | |
| 13:47:08 | mnaser | sean-k-mooney: so i guess i just have to put in credentials in there the same way that the [neutron] section is filled out with a username/pw/etc? | |
| 13:47:09 | sean-k-mooney | mnaser: you cant list the mupltile api service in the catalonge and get teh same loadbalncing behavior | |
| 13:47:13 | gibi | gmann: cool. thanks | |
| 13:47:40 | mnaser | sean-k-mooney: right, but in my case, we use k8s and the internal api endpoint will always forward to one of the three pods running glance (serviceip) | |
| 13:48:02 | sean-k-mooney | ah ok ya that works | |
| 13:48:22 | mnaser | it would be nice if we can have one section that nova uses for all services | |
| 13:48:37 | mnaser | for those deployments where it makes sense | |
| 13:48:38 | sean-k-mooney | then i think ya you just need to set the auth values but not set the api url | |
| 13:49:00 | mnaser | what's interesting is my current glance section actually has no credentials, only api_servers | |
| 13:49:04 | sean-k-mooney | you might be able to abuse service user for that | |
| 13:49:08 | mnaser | so i wonder where the credentials is being used | |
| 13:49:42 | sean-k-mooney | most of the time it would use the users token and not need them | |
| 13:49:53 | sean-k-mooney | for neutron we do some admin only api calls which need it | |
| 13:50:04 | mnaser | oh yes you're right, i forgot about that | |
| 13:50:21 | sean-k-mooney | for glance i did not think we did but maybe we do for multiple locations | |
| 13:50:46 | mnaser | i think that uses the service_user codebase, | |
| 13:51:02 | sean-k-mooney | i think the rbd direct url/ multi location stuff is either admin only or configurable | |
| 13:51:13 | mnaser | you can configure glance to expose the url | |
| 13:51:18 | mnaser | so i think its not necessarily | |