| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-05-26 | |||
| 18:50:55 | sean-k-mooney[m] | melwitt: am i think we can proceed but stephenfin was suggesting that if it does not work we can just delete the job | |
| 18:51:10 | sean-k-mooney[m] | it works so if it comes to it we can still delete the job next time it breaks | |
| 18:51:18 | melwitt | sean-k-mooney[m]: he just wants to delete everything | |
| 18:51:23 | melwitt | jk stephenfin :) | |
| 18:51:47 | sean-k-mooney[m] | im going to backport that to train later today if i can | |
| 18:52:00 | sean-k-mooney[m] | well or tommorow if it gets too late | |
| 19:17:11 | sean-k-mooney | ok it will be tomorow thank melwitt for looking at that | |
| 19:18:10 | melwitt | yw | |
| 20:24:54 | openstackgerrit | melanie witt proposed openstack/nova stable/victoria: Initialize global data separately and run_once in WSGI app init https://review.opendev.org/c/openstack/nova/+/785059 | |
| 20:41:32 | openstackgerrit | Merged openstack/os-vif stable/victoria: Resolve dependency issues https://review.opendev.org/c/openstack/os-vif/+/792840 | |
| #openstack-nova - 2021-05-27 | |||
| 01:15:27 | openstackgerrit | norman shen proposed openstack/nova-specs master: Speed up server details https://review.opendev.org/c/openstack/nova-specs/+/791620 | |
| 01:30:52 | openstackgerrit | Wenping Song proposed openstack/nova-specs master: Add no user token when get Cyborg client https://review.opendev.org/c/openstack/nova-specs/+/787178 | |
| 02:24:20 | openstackgerrit | Kevin Zhao proposed openstack/nova master: Support Cpu Compararion on Aarch64 Platform https://review.opendev.org/c/openstack/nova/+/763928 | |
| 07:53:10 | lyarwood | gibi: https://review.opendev.org/c/openstack/nova/+/790660 - I just W+'d this again after the rebase btw | |
| 07:53:25 | lyarwood | * lyarwood is getting bored of gate failures this week | |
| 07:53:44 | lyarwood | gibi: https://review.opendev.org/c/openstack/nova/+/793219/ can you take a look at this so ^ can land? | |
| 08:10:44 | bauzas | lyarwood: I can take a look | |
| 08:10:50 | lyarwood | thanks | |
| 08:23:11 | gibi | lyarwood: looking too | |
| 08:31:21 | openstackgerrit | Merged openstack/nova-specs master: QoS minimum guaranteed packet rate https://review.opendev.org/c/openstack/nova-specs/+/785014 | |
| 08:50:35 | bauzas | sean-k-mooney: sorry, I didn't wanted to hold the pps spec from gibi when I said 'I'll look at the spec' | |
| 08:50:49 | bauzas | sean-k-mooney: it was just for knowing what was your concern | |
| 08:51:05 | bauzas | anyway, merged now :) | |
| 08:57:09 | gibi | bauzas,sean-k-mooney: thanks | |
| 08:57:27 | gibi | I have feedback from Rodolfo on the neutron side so I will continue with that | |
| 09:54:45 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/wallaby: image_meta: Provide image_ref as the id when fetching from instance https://review.opendev.org/c/openstack/nova/+/793354 | |
| 10:02:45 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/victoria: libvirt: make cross cell resize spawn from snapshot image https://review.opendev.org/c/openstack/nova/+/793356 | |
| 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 | |