| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-05-27 | |||
| 10:02:46 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/victoria: image_meta: Provide image_ref as the id when fetching from instance https://review.opendev.org/c/openstack/nova/+/793357 | |
| 10:26:10 | slaweq | lyarwood: hi, can You maybe check https://review.opendev.org/c/openstack/nova/+/787252 ? | |
| 10:26:12 | slaweq | thx in advance | |
| 10:49:09 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/ussuri: Add regression test for bug #1928063 https://review.opendev.org/c/openstack/nova/+/793372 | |
| 10:49:10 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/ussuri: libvirt: make cross cell resize spawn from snapshot image https://review.opendev.org/c/openstack/nova/+/793373 | |
| 10:49:11 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/ussuri: image_meta: Provide image_ref as the id when fetching from instance https://review.opendev.org/c/openstack/nova/+/793374 | |
| 10:49:15 | openstack | bug 1928063 in OpenStack Compute (nova) "SEV enabled instance unable to hard reboot" [Medium,In progress] https://launchpad.net/bugs/1928063 - Assigned to Lee Yarwood (lyarwood) | |
| 13:51:24 | bauzas | gibi: gentle reminder that all the Red Hat folks should be off tomorrow | |
| 13:52:07 | bauzas | and like every year, I have this PTO just for my lawn mower... | |
| 13:54:30 | gibi | bauzas: thanks for the reminder | |
| 13:54:36 | gibi | for all RH folks, have a nice day off! | |
| 14:02:12 | sean-k-mooney | :) actully im taking monday off too | |
| 14:02:25 | sean-k-mooney | but thank you none the less | |
| 15:20:53 | lyarwood | * lyarwood is off on both Friday and Monday FWIW | |
| 15:34:59 | melwitt | same for me | |
| 15:36:28 | melwitt | lyarwood: sorry if this has been mentioned before but are you familiar with this failure setting up ceph "Error EPERM: configuring pool size as 1 is disabled by default." this is on stable/victoria https://zuul.opendev.org/t/openstack/build/7de187da76af48aab23337c4f9d16f9c/log/job-output.txt#5403 | |
| 15:42:02 | gibi | * gibi prepares for the cricket noises for the next 4 days | |
| 15:42:54 | gibi | btw if the IRC cutover happens during the weekend then I will make sure privatly guide people to the other IRC server where our discussions will be logged | |
| 15:57:20 | melwitt | hm maybe that's not actually from setting up ceph | |
| 15:57:30 | openstackgerrit | Lee Yarwood proposed openstack/nova master: WIP libvirt: Do not destroy volume secrets during resume_state_on_host_boot https://review.opendev.org/c/openstack/nova/+/793463 | |
| 16:02:04 | melwitt | ok it looks like it's failing here https://github.com/openstack/nova/blob/stable/victoria/gate/live_migration/hooks/ceph.sh#L47 | |
| 16:13:01 | melwitt | looks like it's installing the pacific release... that doesn't seem right | |
| 16:13:13 | melwitt | it's using the train uca, which is right | |
| 16:19:20 | melwitt | "Monitors now have config option mon_allow_pool_size_one, which is disabled by default. However, if enabled, user now have to pass the --yes-i-really-mean-it flag to osd pool set size 1, if they are really sure of configuring pool size 1." https://docs.ceph.com/en/latest/releases/pacific/ | |
| 16:20:20 | melwitt | there we go. so I guess I first try a recheck and see if the installation of the pacific release was a spurious thing that isn't consistently happening | |
| 16:21:04 | melwitt | * melwitt checks other stable/victoria test runs first | |
| 16:25:48 | melwitt | last passing run was on May 21 and was installing the expected release nautilus | |
| 16:29:52 | melwitt | and I do find a few other failures of the same thing since May 25 | |
| 16:37:47 | melwitt | hm, the ceph version is yellow "version is not current" https://openstack-ci-reports.ubuntu.com/reports/cloud-archive/train_versions.html not sure what that means. the version listed there is the one we want (nautilus) so I don't know why we're getting pacific | |
| 16:48:11 | gmann | dansmith: did you see my reply on this does it make sense? https://review.opendev.org/c/openstack/nova-specs/+/793011/1/specs/xena/approved/allow-project-admin-list-hypervisors.rst#66 | |
| 16:48:36 | dansmith | gmann: I did not | |
| 16:48:42 | gmann | k | |
| 16:49:14 | gmann | gibi: stephenfin I replied to this comment if I understand it correctly. can you check this - https://review.opendev.org/c/openstack/nova-specs/+/793011/2/specs/xena/approved/allow-project-admin-list-hypervisors.rst#81 | |
| 16:52:49 | dansmith | gmann: replied | |
| 17:01:31 | melwitt | gmann, dansmith: I skimmed over that spec on tuesday and was thinking, it depends on how you're defining project-admin. if you're defining it as system-admin scoped down to only a project, then showing the hostnames makes sense. if it's not that, then the obfuscated names make sense. I'm curious what lbragstad would say was the intended meaning/use | |
| 17:02:17 | dansmith | melwitt: yeah, I thought it was more the latter (obviously). I'm not sure what the point of the former is in most cases | |
| 17:02:48 | dansmith | I thought the problem was that they wanted some people to be able to violate scheduling restraints and bust locks and reset instance state, but not muck with aggregates and system-level stuff | |
| 17:03:21 | melwitt | yeah, I'm not sure. I haven't acquired a solid understanding of what project-admin is supposed to be, from a secure rbac design perspective | |
| 17:04:35 | dansmith | I think if you take the public cloud case, we need to know if project-admin is supposed to be a low-level sysadmin on the cloud side, or a high-level power user on the customer side | |
| 17:04:41 | dansmith | I have been assuming the latter | |
| 17:05:22 | dansmith | I guess the former could be some customer-dedicated support person, but I would expect those cases to be pretty uncommon | |
| 17:07:13 | melwitt | yeah. one of the use cases that comes to mind first for me (bc a customer wanted this) was a role where some people could do live migrations but not be admin (live the global admin we have today) | |
| 17:07:31 | melwitt | *like the global admin | |
| 17:07:34 | dansmith | yeah exactly | |
| 17:07:51 | dansmith | that might be a role and not all-of-admin I would think, | |
| 17:08:07 | melwitt | so then you will ask, can that live migration person force to a specific host? | |
| 17:08:08 | dansmith | but I would guess you mostly want those people migrating to hosts symbolically and not having to know the hostname | |
| 17:08:48 | melwitt | I know this is whack but I was just thinking I wonder if it would be legit to use obfuscated host for target host | |
| 17:09:22 | dansmith | I don't think it is today, but I think that if we want to delegate live migration to a non-system-admin, that'd be the goal: let them use the obfuscated host | |
| 17:09:46 | melwitt | yeah I doubt it's possible today but I wonder if it would be legit to add it for this project-admin use case | |
| 17:09:51 | sean-k-mooney | melwitt: the issue with using the hashed host is reversing it | |
| 17:09:52 | dansmith | but, as noted in my follow up a few minutes ago, I think host uuid would be a good compromise.. not project-scoped like the hostid, but otherwise opaque | |
| 17:10:02 | dansmith | sean-k-mooney: right, hence using the uuid | |
| 17:10:11 | melwitt | ah yeah, that's even better | |
| 17:10:36 | dansmith | so assume project admins can be trusted with non-project-scoped host identifiers, but without needing to expose actual dns names to them | |
| 17:10:43 | sean-k-mooney | host uuid hum | |
| 17:11:07 | dansmith | they would be able to correlate their hostids to uuids, which regular users can't do, and that would let them collude with other project admins to determine *some* details, | |
| 17:11:07 | sean-k-mooney | is that any safer tehn hostname | |
| 17:11:14 | sean-k-mooney | marginally perhaps | |
| 17:11:31 | dansmith | sean-k-mooney: hostnames contain machine model numbers, deployment dates, network and topology details, etc | |
| 17:11:42 | sean-k-mooney | ya they can | |
| 17:11:55 | dansmith | host123-dl360g1-legacy.old-building.example.com | |
| 17:12:04 | sean-k-mooney | i was more thinink about targeting a host form a different project | |
| 17:12:18 | sean-k-mooney | to land something on the same host intionally | |
| 17:12:34 | dansmith | right, like I said, there's some possibility for collusion between project admins, | |
| 17:12:45 | dansmith | but only to co-locate a thing, not to know infra details | |
| 17:13:00 | dansmith | and if you're granting the user the ability to target hosts, then you're kinda opening that up a bit anyway | |
| 17:13:10 | dansmith | you could do it covertly withou the uuid by measuring latency or something | |
| 17:13:10 | sean-k-mooney | what about using a semtric key instad of a hash for the host id | |
| 17:13:24 | sean-k-mooney | well rather a reversable key | |
| 17:13:32 | dansmith | sean-k-mooney: how is that better? it's reversible, but we still have to calculate it on every query | |
| 17:13:35 | sean-k-mooney | it can be asmetic | |
| 17:13:49 | sean-k-mooney | we will just have to decyprt it | |
| 17:13:51 | dansmith | we could just hash all the things in their aggregate as quick as reversing | |
| 17:14:15 | gmann | do not we return host name in GET /servers today? | |
| 17:14:15 | sean-k-mooney | we could yes | |
| 17:14:16 | dansmith | I bet md5 or whatever we use is fast enough to just do it forwards for every host in their aggregate if we're going to go to that trouble | |
| 17:14:33 | gmann | hostID is obfuscated | |
| 17:14:34 | dansmith | gmann: no, we return a project-scoped hash of the hostname for non-admins | |
| 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 | |