| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-08-07 | |||
| 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 | The kernel calls this feature arch_capabilities and RHEL/CentOS 7.* use | |
| 10:36:48 | kashyap | arch-facilities. Apparently some CPU test files were gathered with the | |
| 10:36:48 | kashyap | RHEL version of QEMU. Let's update the test files to avoid possible | |
| 10:36:48 | kashyap | confusion about the correct naming. | |
| 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 | |
| 13:53:08 | mnaser | based off the main 'admin' user | |
| 13:53:11 | mnaser | essentially its the same thing anyways | |
| 13:55:19 | sean-k-mooney | mnaser: that technical shoudl already work right | |
| 13:55:57 | sean-k-mooney | when you create app creds dont you get a new user name and passward you could use | |
| 13:56:06 | sean-k-mooney | or do you jsut get a bearer token | |
| 13:56:21 | sean-k-mooney | its been quite a while since i looked at them | |
| 13:57:43 | sean-k-mooney | but ya that would be quite nice if it coudl be made to work | |
| 13:58:50 | sean-k-mooney | mnaser: https://docs.openstack.org/keystoneauth/latest/authentication-plugins.html | |
| 13:59:05 | mnaser | sean-k-mooney: it actually should 100% work :) | |
| 13:59:11 | mnaser | keystoneauth does support it yeah | |
| 14:07:09 | openstackgerrit | Stephen Finucane proposed openstack/nova master: tests: Add reproducer for bug #1879878 https://review.opendev.org/744950 | |
| 14:07:09 | openstack | bug 1879878 in OpenStack Compute (nova) "VM become Error after confirming resize with Error info CPUUnpinningInvalid on source node " [Medium,In progress] https://launchpad.net/bugs/1879878 - Assigned to Stephen Finucane (stephenfinucane) | |
| 14:07:09 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Don't unset Instance.old_flavor, new_flavor until necessary https://review.opendev.org/744958 | |
| 14:07:09 | openstackgerrit | Stephen Finucane proposed openstack/nova master: compute: Add type hints for resize functions https://review.opendev.org/745341 | |
| 14:31:22 | lyarwood | elod: https://review.opendev.org/#/q/topic:bug/1889108+status:open - would you have anytime to look at this today | |
| 14:31:52 | lyarwood | elod: I'm including a number of func test refactors here as I'd like to keep things sane going back to stable/train | |
| 14:37:54 | openstackgerrit | Merged openstack/nova master: Add test coverage of tenant networks policies https://review.opendev.org/742765 | |
| 14:38:01 | openstackgerrit | Merged openstack/nova master: Introduce scope_types in tenant networks policy https://review.opendev.org/742766 | |
| 14:38:10 | openstackgerrit | Merged openstack/nova master: Add new default roles in tenant networks policies https://review.opendev.org/742771 | |
| 14:38:27 | openstackgerrit | Merged openstack/nova master: Add test coverage of security_groups policies https://review.opendev.org/742726 | |
| 14:38:34 | openstackgerrit | Merged openstack/nova master: Introduce scope_types in security_groups policy https://review.opendev.org/742757 | |
| 14:40:55 | elod | lyarwood: sure, looking! | |
| 14:41:14 | lyarwood | elod: thanks! :) | |
| 15:24:31 | gibi | I'm wrapping up my week now. I'll be on PTO during the next two weeks. See you around 24th! | |