Earlier  
Posted Nick Remark
#openstack-nova - 2020-08-07
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
13:51:39 sean-k-mooney so what i was suggesting with service_user was
13:51:54 sean-k-mooney if you did not set any other admin auth tokens
13:52:11 sean-k-mooney im not sure if setting service_user config options would be enough
13:52:20 sean-k-mooney if you use the same admin user for all services that is
13:52:38 sean-k-mooney i have never really checked if that would work.
13:53:04 mnaser sean-k-mooney: im actually hoping for a world where we deploy services using app credentials

Earlier   Later