| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-05-27 | |||
| 17:14:36 | melwitt | gmann: we don't unless you're admin admin | |
| 17:14:46 | gmann | yeah i mean for admin | |
| 17:14:51 | gmann | project admin i mean | |
| 17:14:53 | dansmith | gmann: but that's system admin | |
| 17:14:55 | dansmith | right now | |
| 17:14:58 | sean-k-mooney | gmann: host id is a hach of the host uuid and the porject id | |
| 17:15:12 | melwitt | yeah, I would agree the admin of today is a system admin, they can do literally everything | |
| 17:15:39 | melwitt | go across projects and all that | |
| 17:16:18 | sean-k-mooney | dansmith: are you realisticaly think of adding a project-host mapping table in the nova-api | |
| 17:16:26 | gmann | ah right, i thought it is SYSTEM+ Project scoped https://github.com/openstack/nova/blob/master/nova/policies/extended_server_attributes.py#L27 | |
| 17:16:29 | dansmith | melwitt: and administer the system at things like the aggregate level | |
| 17:16:36 | dansmith | sean-k-mooney: no | |
| 17:16:45 | sean-k-mooney | just using the uuid un hased | |
| 17:16:51 | sean-k-mooney | *hashed | |
| 17:17:06 | dansmith | yeah, I think that's a reasonable compromise | |
| 17:17:30 | sean-k-mooney | how would they discover it? | |
| 17:17:31 | dansmith | if not, then I think we have to calculate the hash on the fly when we're using a obfuscated directed boot | |
| 17:17:35 | melwitt | gmann: yeah that's what I was saying earlier is the root question that would guide what to do here. I do note though that if it were SYSTEM + limited to a project, the hostnames wouldn't be any better than the host uuids right? since you're silo'ed within a project | |
| 17:17:49 | dansmith | sean-k-mooney: they can see it in the hypervisors list, that's what the spec is proposing.. to expose that in part to project admins | |
| 17:18:10 | sean-k-mooney | right i was wondering if we were going to keep that | |
| 17:18:16 | gmann | melwitt: i see | |
| 17:18:22 | dansmith | sean-k-mooney: and I'm saying we should do that, but not expose the hostname, and then make the requested_destination take either | |
| 17:18:24 | sean-k-mooney | so we would be retrunign only a subset of the columns to them | |
| 17:18:36 | dansmith | sean-k-mooney: as we do for server detail | |
| 17:18:55 | sean-k-mooney | ok i think that can work | |
| 17:19:00 | melwitt | gmann: like I mean, if you're not allowed to migrate a server across a project boundary, I'm not sure what additional the real hostname gets you. or rather do you "need" to know it | |
| 17:19:03 | sean-k-mooney | is the uuid the only feild we should show them | |
| 17:19:14 | sean-k-mooney | im not sure they need to see uptrime ectra | |
| 17:19:17 | dansmith | sean-k-mooney: s/show/hide/ you mean? | |
| 17:19:43 | dansmith | sean-k-mooney: they need most of what hypervisors show them in terms of used/free memory to make a decision I think, but yeah we could hide more in there | |
| 17:19:58 | dansmith | sean-k-mooney: you should go review the spec :) | |
| 17:20:08 | gmann | dansmith: sean-k-mooney we can show with 'None or 'Unknown' value and keep response field consistent | |
| 17:20:17 | sean-k-mooney | its on my list but i was also going to finish up soon | |
| 17:20:36 | dansmith | gmann: unknown isn't right, but maybe "<hidden>" or something | |
| 17:20:39 | sean-k-mooney | gmann: am i would prefer to not have the filed there | |
| 17:20:41 | gmann | melwitt: yeah but for booting server we need real name | |
| 17:20:53 | dansmith | sean-k-mooney: agree, I'd rather just exclude that field | |
| 17:20:54 | gmann | yeah <hidden> work | |
| 17:21:09 | dansmith | gmann: we would need to make it take hostname or host-uuid | |
| 17:21:14 | melwitt | gmann: today you do but we're talking about adding the ability to use the uuid | |
| 17:21:25 | gmann | sean-k-mooney: but we return those field for system admin and not for project admin is difficult way to read it | |
| 17:21:41 | sean-k-mooney | i dont think thats hard | |
| 17:21:44 | gmann | melwitt: dansmith yeah i get the point of uuid | |
| 17:21:48 | sean-k-mooney | we now have 9 personas | |
| 17:21:51 | sean-k-mooney | instead of 2 | |
| 17:21:52 | gmann | and obfuscated uuid right | |
| 17:22:09 | dansmith | gmann: no, can't be obfuscated | |
| 17:22:17 | sean-k-mooney | so we should expect that for some api system admin will see more then project admin | |
| 17:22:18 | dansmith | gmann: it's opaque, but not scoped or obfuscated further | |
| 17:22:20 | gmann | sean-k-mooney: 7 for nova | |
| 17:23:02 | sean-k-mooney | 7? | |
| 17:23:13 | sean-k-mooney | i was expecting 6 or 9 | |
| 17:23:25 | sean-k-mooney | either domain has no menaing or it does | |
| 17:23:46 | gmann | actually 5. we do not have system member | |
| 17:23:55 | gmann | i counted the combination also | |
| 17:24:05 | sean-k-mooney | ideally nova itself woudl be runnign as system member but ok | |
| 17:24:33 | gmann | dansmith: and having mapping in DB? | |
| 17:24:52 | dansmith | gmann: no, no mapping. we'd have to map every project and every host | |
| 17:25:21 | sean-k-mooney | gmann: dansmith is suggesting just using the current uuid | |
| 17:25:32 | sean-k-mooney | which i think is an ok comprmise | |
| 17:25:35 | dansmith | gmann: using the uuid lets us look up t he host in O(1), which is what we want. It exposes a 1:1 identifier that the project admin can use, but without any details that are often embedded in hostnames | |
| 17:25:50 | sean-k-mooney | its slightly better then the hostname for the reason he gave above | |
| 17:26:03 | sean-k-mooney | but still allows effiecnt scheduling | |
| 17:26:25 | gmann | and with uuid non-admn or project admin cannot get host detail so make sense | |
| 17:26:34 | dansmith | right | |
| 17:26:48 | gmann | got it | |
| 17:26:59 | sean-k-mooney | ya we would reject a /hypervior/detail request with a project admin token | |
| 17:27:00 | dansmith | you're exposing a little more of the system to the project-admin, so they can direct servers, but not everything that a hostname might encode in it | |
| 17:27:12 | dansmith | sean-k-mooney: no, we have to support that | |
| 17:27:17 | gmann | btw why we do obfuscated hostID in GET API ? | |
| 17:27:19 | dansmith | sean-k-mooney: they want to be able to see some details of the hosts | |
| 17:27:20 | sean-k-mooney | well ok yes | |
| 17:27:23 | sean-k-mooney | but not all the fileds | |
| 17:27:33 | dansmith | gmann: so that users can't tell that they are on the same host across coke/pepsi | |
| 17:27:45 | gmann | ohk, | |
| 17:28:16 | openstackgerrit | Lee Yarwood proposed openstack/nova master: WIP libvirt: Do not destroy volume secrets during _hard_reboot https://review.opendev.org/c/openstack/nova/+/793463 | |
| 17:28:29 | dansmith | gmann: okay, so .. all good? | |
| 17:29:02 | gmann | one last one, on new policy | |
| 17:29:04 | sean-k-mooney | there is one other advantage | |
| 17:29:22 | gmann | this one https://review.opendev.org/c/openstack/nova-specs/+/793011/2/specs/xena/approved/allow-project-admin-list-hypervisors.rst#41 | |
| 17:29:24 | sean-k-mooney | if im not mistaken we do not support using the uuid with the old az hack | |
| 17:29:49 | gmann | any objection on adding new policy to let operator to list all hypervisors ? | |
| 17:29:49 | sean-k-mooney | so they can bypass the sculder with --availabit-zone <zone>:<hostname> | |
| 17:30:00 | sean-k-mooney | if we give the the uuid right | |
| 17:30:31 | dansmith | gmann: no, I think that makes sense if they want to allow that | |
| 17:30:58 | gmann | cool | |
| 17:31:04 | gmann | I will update the spec accordingly. | |
| 17:31:09 | gmann | thanks dansmith melwitt sean-k-mooney | |
| 17:31:19 | dansmith | gmann: cool, sorry for missing your reply earlier | |
| 17:31:22 | sean-k-mooney | oh to remove the aggreate metadtata requirement | |
| 17:31:37 | sean-k-mooney | form an end user perspecitv i would not be able to tell the diffrenece | |
| 17:31:38 | gmann | dansmith: np! I too missed to ask that day itself. | |
| 17:32:04 | sean-k-mooney | so that policy would not be an interop issue so i think its ok to add one yes | |
| 17:33:05 | sean-k-mooney | ok i am going to finish up for the day. ill see everyon on our new home on tuesday o/ | |
| 17:33:25 | dansmith | sean-k-mooney: enjoy o/ | |
| 17:33:26 | melwitt | have a good weekend o/ | |
| 17:35:21 | dansmith | wow | |
| 17:35:28 | dansmith | not used to seeing that :P | |
| 17:36:17 | melwitt | 😆 | |
| 17:39:21 | artom | He's been making big improvement in keeping a regular work schedule | |