| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-09 | |||
| 17:09:47 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Migrate nova-grenade-multinode job to zuulv3 native https://review.opendev.org/742056 | |
| 17:13:12 | openstackgerrit | Lee Yarwood proposed openstack/nova master: Add os-volume_attachments reference docs https://review.opendev.org/760971 | |
| 17:24:18 | openstackgerrit | Merged openstack/nova stable/victoria: [doc]: Fix glance image_metadata link https://review.opendev.org/761423 | |
| 17:27:41 | openstackgerrit | Dat Le proposed openstack/nova master: Fix unplugging VIF when migrate/resize VM https://review.opendev.org/751642 | |
| 17:44:38 | openstackgerrit | sean mooney proposed openstack/nova master: libvirt: delegate ovs plug to os-vif https://review.opendev.org/602432 | |
| 17:45:08 | sean-k-mooney | stephenfin: lyarwood can you re +w https://review.opendev.org/751642 | |
| 17:45:15 | sean-k-mooney | it was rebased | |
| 17:45:37 | stephenfin | done | |
| 17:45:42 | sean-k-mooney | thanks | |
| 18:07:12 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: DNM: Testing system scope in tempest https://review.opendev.org/740124 | |
| 18:20:16 | openstackgerrit | Elod Illes proposed openstack/nova stable/ussuri: [doc]: Fix glance image_metadata link https://review.opendev.org/761977 | |
| 18:23:06 | mnaser | sean-k-mooney: have you done some investigation by any chance on any potential ways of speeding up nova startup time in environments with compute nodes that have a large port count | |
| 18:23:28 | mnaser | in this case, it takes almost 5-6 minutes for the agent to go up in an env with ~150-160 ports | |
| 18:23:40 | mnaser | using osv | |
| 18:23:52 | mnaser | i havent tried migrating to the native ovsdb driver, maybe that might help, but a whole lot of plugging happens | |
| 18:26:42 | sean-k-mooney | am not really. we have seen that usign native does indeed help form your previous issues but in general we do need to ensure that all network interfacs are plugged for all vms when the compute agent starts | |
| 18:27:40 | sean-k-mooney | it also depend on the release i know we fixed some issue with ip adress checking on newer release | |
| 18:27:51 | mnaser | sean-k-mooney: wonder if it might make sense to make this happen in a threadpool or something, as it seems to be happening one-by-one | |
| 18:28:07 | sean-k-mooney | not really | |
| 18:28:23 | mnaser | because right now in some of those bigger vms, nova-compute reports down as it goes through the restart that takes ~6m | |
| 18:28:27 | sean-k-mooney | we could but we have to wait for them all to complete | |
| 18:29:09 | sean-k-mooney | so if we dispatch them to a tread pool we will get more paralium but we will the fill the pool and have to wait for it to complete | |
| 18:29:33 | sean-k-mooney | plugging form a nova side shoudl not take that long in general | |
| 18:29:45 | sean-k-mooney | with the native driver its much much faster | |
| 18:30:17 | mnaser | ok i guess thats' probably going to be my next step to see how that improves it | |
| 18:30:19 | sean-k-mooney | as its not spawnting multiple shells via privsep in that process | |
| 18:31:32 | mnaser | sean-k-mooney: seems valid, i'll check it out and report and let you know what sort of improvement i see :) | |
| 18:31:34 | sean-k-mooney | putting it in a tread pool would basically just increase the batch size at the cost of memroy during start up. | |
| 18:32:17 | sean-k-mooney | cool there would be a speed up form a thread pool but not as much as using the native driver | |
| 18:50:33 | openstackgerrit | Merged openstack/nova master: virt: Remove 'get_per_instance_usage' API https://review.opendev.org/749318 | |
| 18:51:22 | lyarwood | \o/ | |
| 18:59:50 | sean-k-mooney | lyarwood: was that for the removal ^ | |
| 19:00:10 | sean-k-mooney | oh because something finally merged in the gate :P | |
| 19:00:21 | sean-k-mooney | both are good | |
| 19:36:21 | dansmith | hmm, on focal the ceph devstack plugin tells me I'm on an unsupported distro | |
| 19:36:30 | dansmith | lyarwood: any idea about that? | |
| 19:37:52 | lyarwood | dansmith: no idea, I thought it was there? | |
| 19:37:55 | lyarwood | # git grep f32 | |
| 19:37:57 | lyarwood | devstack/lib/ceph: if [[ ! ${DISTRO} =~ (focal|bionic|xenial|f31|f32) ]]; then | |
| 19:38:27 | dansmith | hmm, I nuked opt/stack but maybe I've got residue somewhere | |
| 19:38:33 | dansmith | it's checking against a list that doesn't include focal | |
| 19:38:53 | dansmith | heh, doh | |
| 19:38:54 | dansmith | enable_plugin devstack-plugin-ceph /home/dan/devstack-plugin-ceph | |
| 19:59:32 | sean-k-mooney | oh your using your local copy | |
| 19:59:44 | sean-k-mooney | got an old version checked out | |
| 19:59:49 | dansmith | yeah, I nuked /opt/stack and then it cloned it right back there for me :P | |
| 20:00:17 | sean-k-mooney | yep i do that intentionally for the most part and put all my repos in /opt/repos | |
| 20:00:32 | sean-k-mooney | just so it does not clone over itself | |
| 20:05:21 | sean-k-mooney | gmann:is there a spec or something covering the use of token scopes with nova. i dont see anythin after the ussuri spec https://specs.openstack.org/openstack/nova-specs/specs/ussuri/implemented/policy-defaults-refresh.html | |
| 20:05:44 | sean-k-mooney | that does nto cover the domains | |
| 20:06:06 | sean-k-mooney | the 4 scopes in https://specs.openstack.org/openstack/nova-specs/specs/ussuri/implemented/policy-defaults-refresh.html#use-cases make sense to me | |
| 20:06:41 | sean-k-mooney | but i dont see a defeintion for system_member, project_admin, domain_(reader, member or admin) | |
| 20:07:36 | sean-k-mooney | we have some interset down stream in supporting a 3*3 matix (reader, memeber, admin) *( project, domain, system) | |
| 20:08:38 | sean-k-mooney | but i dont recall ever disscuing domains or proejct admin and system memebr in the context of nova upstream | |
| 20:09:52 | sean-k-mooney | https://review.opendev.org/#/c/698397/14/etc/rbac-persona-accounts.yaml.sample has entries for all 9 roles | |
| 20:10:31 | sean-k-mooney | but given we have not had any specs or cross project session on this im having a hard time relateing that to how we would support this in nova | |
| 20:10:50 | sean-k-mooney | gmann: i know there was a pop up team but any pointers on where this might have been discussed | |
| 20:12:55 | sean-k-mooney | melwitt: johnthetubaguy any input on ^ | |
| 20:16:21 | gmann | sean-k-mooney: we have project_admin in nova for case like creating server with host specify but system_member is not there as not needed from current policy rules | |
| 20:16:41 | gmann | also domain scope (it's three pesona) | |
| 20:16:56 | sean-k-mooney | do you have docs for this | |
| 20:17:06 | sean-k-mooney | there were only 4 included in the spec | |
| 20:17:12 | sean-k-mooney | project_admin was not one of them | |
| 20:17:17 | gmann | yeah, I updated policy doc for that | |
| 20:18:04 | sean-k-mooney | ok because form a spec point of vew we only ever approved system_admin, project_memeber system_reader and project_reader | |
| 20:18:32 | gmann | sean-k-mooney: this does not include what all combination nova support but give an idea on new policy - https://docs.openstack.org/nova/latest/configuration/policy-concepts.html | |
| 20:18:33 | sean-k-mooney | so since this is an api cahnge im kind of confused why we dont have a spec for supporting other scopes and ropels in nova | |
| 20:19:23 | melwitt | yeah, that ^ is the doc I was searching for wrt the support in nova | |
| 20:19:24 | gmann | sean-k-mooney: project_admin came up during implementation only and that is for create server with specific request (like force host, zero disk flavor etc) on;y | |
| 20:19:45 | sean-k-mooney | ok but are we actully using it in code | |
| 20:20:10 | sean-k-mooney | https://specs.openstack.org/openstack/nova-specs/specs/ussuri/implemented/policy-defaults-refresh.html is the only spec that exist for this so really without a spec to add it we should not be useing in the api right | |
| 20:20:58 | gmann | as part of policy defaults yes but we do not change token in nova right? whatever token is used for API access will be validated against the policy values | |
| 20:21:45 | sean-k-mooney | my concern is really for domains im concerend that a domain member may not have a project | |
| 20:21:56 | gmann | sean-k-mooney: I am not sure about supporting other scopes. if we want domain scope control in nova then we need to see what all nova API operations are domain level and system level. | |
| 20:22:01 | sean-k-mooney | maybe they do but if they dont then that will break our api assumtions | |
| 20:22:11 | gmann | i never thought of domain in nova. | |
| 20:22:28 | sean-k-mooney | its come up downstream my responce is right now we dont support it | |
| 20:22:38 | gmann | and they use domain member user to access nova API ? | |
| 20:22:49 | sean-k-mooney | well its not a thing yet | |
| 20:23:06 | sean-k-mooney | we have a request to supprot RBAC for osp 17 which will be based on wallaby | |
| 20:23:15 | melwitt | yeah, my understanding is that we now have the code needed to handle scoped tokens in nova, so the way that they get used is someone (a user) has to request scoped tokens and use them when they call nova and then policy can validate the token against the policy | |
| 20:23:18 | gmann | ok, in that case they can assign admin/member/reader role on required project | |
| 20:23:27 | sean-k-mooney | but since domain was never discussed upstream i wanted to push back to just the 4 roles we intended to support | |
| 20:24:17 | sean-k-mooney | melwitt: right but we need to agree what scopes and roles are required for each endpoint | |
| 20:24:32 | sean-k-mooney | and what each scope/roles allows you to do | |
| 20:24:40 | gmann | sean-k-mooney: these are combination we support currently - https://github.com/openstack/nova/blob/master/nova/policies/base.py#L48-L54 | |
| 20:25:00 | gmann | sean-k-mooney: i can add these in policy doc so that we do not need to point these to code | |
| 20:25:20 | sean-k-mooney | project admin is the only one im not expecting since we nver approved that in a spect | |
| 20:25:46 | sean-k-mooney | the rest make sense to me | |
| 20:26:33 | sean-k-mooney | for example we discussed in the ptg that prject admisn shoudl not be aware of the hosts vms run on | |
| 20:26:41 | gmann | sean-k-mooney: also html policy doc mention the scope of each policy/API as part of oplicy documentation - https://docs.openstack.org/nova/latest/configuration/policy.html | |
| 20:26:45 | sean-k-mooney | but you mentioned that one of the usecase was allowing them to boot on a host | |
| 20:26:53 | gmann | yeah | |
| 20:27:10 | sean-k-mooney | have we released with project_admin yet | |
| 20:27:15 | gmann | you remember in PTG we discuss about it | |
| 20:27:35 | sean-k-mooney | i rememebr the one two weeks ago | |
| 20:29:18 | gmann | my initial thought while adding PROJECT_ADMIN was that this is temp and TODO will remove this - https://github.com/openstack/nova/blob/45e8fa3ade54313754fbea245ad546097150486d/nova/policies/servers.py#L179 | |
| 20:29:35 | sean-k-mooney | i kind of which there was a spec for projecft admin because i really ame not sure that the current usaged in the api are valid | |
| 20:29:59 | gmann | but as we discussed in PTG, I think it make sense to keep it and ask users to assign appropriate role to let users to boot on specific host | |
| 20:29:59 | sean-k-mooney | gmann: we cant remove it | |