| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-12 | |||
| 15:04:12 | openstackgerrit | Merged openstack/nova stable/train: [stable-only] gate: Pin CEPH_RELEASE to nautilus in LM hook https://review.opendev.org/c/openstack/nova/+/780014 | |
| 15:17:20 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/stein: [stable-only] gate: Pin CEPH_RELEASE to nautilus in LM hook https://review.opendev.org/c/openstack/nova/+/780277 | |
| 15:17:52 | elod | gibi lyarwood : i've uploaded the release patches: https://review.opendev.org/q/project:openstack/releases+status:open+intopic:nova | |
| 15:18:06 | gibi | will check soon | |
| 15:19:09 | elod | thx o/ let me know if you disagree with the minor version bump | |
| 15:33:36 | lbragstad | dansmith opened up a bug against nova to document what we found https://bugs.launchpad.net/nova/+bug/1918945 | |
| 15:33:38 | openstack | Launchpad bug 1918945 in OpenStack Compute (nova) "Nova API fails with 500s when called with non-project-scoped keystone tokens" [Undecided,New] | |
| 15:33:47 | dansmith | lbragstad: sweet | |
| 15:37:09 | sean-k-mooney | lbragstad: that is kind fo expected depending on what you are calling | |
| 15:37:21 | sean-k-mooney | lbragstad: server create for example should not work wit | |
| 15:37:31 | sean-k-mooney | domain or system tokens | |
| 15:37:35 | lbragstad | sean-k-mooney yeah - i don't expect it to work | |
| 15:37:40 | lbragstad | i just didn't expect a 500 | |
| 15:37:55 | dansmith | sean-k-mooney: it's failing in object field validation, | |
| 15:37:58 | sean-k-mooney | it should be a 400 or 403 | |
| 15:37:59 | dansmith | which is...not the right place :) | |
| 15:38:13 | sean-k-mooney | yep agreed | |
| 15:38:39 | sean-k-mooney | we should be handeling it in the policy check level or similar in the api | |
| 15:39:04 | dansmith | yeah I think we probably need a decorator on anything that might create resources to @require_project or something | |
| 15:39:25 | dansmith | because I think even with something like instance shutdown, we might go to write an instance action record and fail if we have no project :( | |
| 15:39:56 | dansmith | I haven't looked at that yet, but.. there's likely a lot of potential for those types of things | |
| 15:50:39 | gibi | stephenfin: I have couple of things in the func test for the vdpa https://review.opendev.org/c/openstack/nova/+/780112 | |
| 15:50:54 | stephenfin | good timing - I was just fixing the test failure | |
| 15:51:34 | gibi | ohh, I only run the vdpa test locally not the whole suite | |
| 15:51:53 | gibi | good that we have the CI :) | |
| 15:52:09 | stephenfin | yeah, me too /o\ | |
| 15:52:55 | gibi | sean-k-mooney: I will look at the ops blocking patch before I go to bed today. Now I have to step out before the curfew | |
| 15:53:26 | sean-k-mooney | gibi: im still working on it so it may or may not be ready but hopefully will | |
| 15:53:56 | sean-k-mooney | ill push what i have before the end of the day but might need more time to actully get test for all of them | |
| 15:54:44 | sean-k-mooney | dansmith: we proably should be blcoking all isntace actions | |
| 15:54:52 | sean-k-mooney | at least for now | |
| 15:54:58 | dansmith | sean-k-mooney: agreed | |
| 15:55:30 | dansmith | sean-k-mooney: kinda makes me wonder what the point of system-admin is in a lot of cases, if they can't shutdown or migrate instances | |
| 15:55:31 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Bump the Compute RPC API to version 6.0 https://review.opendev.org/c/openstack/nova/+/761452 | |
| 15:55:31 | sean-k-mooney | if we actully add support for isntace been own by a domain or somethin later then cool but for now even our logging assuems user and project id | |
| 15:55:35 | dansmith | I guess it's useful for aggregate type things | |
| 15:55:47 | bauzas | dansmith: just provided a new rev for your nits | |
| 15:56:05 | bauzas | and will work on a new rev for trying to only accept >=5.12 on Monday | |
| 15:56:08 | sean-k-mooney | dansmith: we might be able to support some of them but things like volumn attach might be weried | |
| 15:56:36 | dansmith | bauzas: yeah, was replying when I noticed... | |
| 15:56:44 | gibi | sean-k-mooney: ack | |
| 15:56:50 | sean-k-mooney | well actully not volumn atach snap shot is a better example | |
| 15:56:57 | dansmith | sean-k-mooney: yeah, I mean all of neutron would have to support this as well | |
| 15:57:05 | sean-k-mooney | if a system-admin creates a snapshot who would own it | |
| 15:57:22 | dansmith | sean-k-mooney: yep | |
| 15:57:37 | dansmith | sean-k-mooney: the slop becomes slippery quite fast | |
| 15:57:39 | dansmith | *slope | |
| 15:59:14 | sean-k-mooney | do we have a topic for the ptg for outstanding RBAC tasks | |
| 15:59:42 | sean-k-mooney | or do you think we will punt on domain users other thne fixing where it fails in Xena | |
| 15:59:54 | sean-k-mooney | or system for that mater | |
| 16:01:02 | dansmith | I dunno, I got the impression from lbragstad that domain users are not so widely used and maybe don't have a bright future | |
| 16:01:08 | sean-k-mooney | we would obviously need a spec to alter the api to support them but not sure we coudl do that without collaberating with other peoject too to line everything up | |
| 16:01:40 | sean-k-mooney | dansmith: i think only keystone has support for them today | |
| 16:01:41 | dansmith | yeah I kinda .. don't want to do that | |
| 16:02:01 | dansmith | coming up with a strategy for what to do if a sysadmin does an instance migrate is one thing, | |
| 16:02:04 | sean-k-mooney | but no one else | |
| 16:02:08 | gmann | yah domain is in keystone noly afaik | |
| 16:02:10 | lbragstad | keystone uses them - but it's unclear if other projects will fully adopt them | |
| 16:02:12 | dansmith | but making sysadmin able to create and snapshot instances, not so much | |
| 16:03:49 | sean-k-mooney | if i was to summerise. operation that create/consume reousces proably are not easy/desireable to support but other operations that change state of exising resouce may be ok | |
| 16:04:09 | sean-k-mooney | for system admin that is | |
| 16:04:49 | dansmith | sean-k-mooney: as a future goal, yeah.. as a short-term bug, probably need to just validate and reject anything related to instances | |
| 16:05:08 | dansmith | aggregates are fine, service actions are okay, etc | |
| 16:05:50 | sean-k-mooney | gmann:lbragstad: any of that ^ shocking or concerning to you ? | |
| 16:06:11 | sean-k-mooney | or was that also what ye were expecting. its more or less where my mind is at too | |
| 16:06:22 | lbragstad | sorry - catching up | |
| 16:06:30 | sean-k-mooney | not that i have spent that much time thinking about it | |
| 16:06:45 | lbragstad | ok - so domains | |
| 16:07:12 | lbragstad | since domains are containers of projects, i can see a case where calling GET /v2.0/servers with domain-scoped token would yield all servers across all projects within that domain... but, | |
| 16:07:39 | dansmith | sure | |
| 16:07:43 | lbragstad | you can also tell keystone to inherit a domain role assignment to all containing projects | |
| 16:07:45 | gmann | but system admin can also do same right? | |
| 16:07:49 | lbragstad | in which case, you do that and it works today | |
| 16:08:42 | lbragstad | and then nova doesn't have to fetch a hierarchy of projects from keystone - at least not right now | |
| 16:09:19 | dansmith | not sure how that will yield nova showing you all instances in your sub-projects, | |
| 16:09:24 | dansmith | because we would have to filter for multiples | |
| 16:09:41 | dansmith | we could do it (hence the sure) but I think we'd need the hierarchy | |
| 16:09:55 | lbragstad | right - i think so, too | |
| 16:10:01 | lbragstad | which nova doesn't support today | |
| 16:10:04 | lbragstad | afaict | |
| 16:10:05 | dansmith | right | |
| 16:10:14 | lbragstad | and that might just seem like a lot of extra processing | |
| 16:10:17 | dansmith | you said "works today" so wanted to clarify | |
| 16:10:19 | dansmith | yes | |
| 16:10:34 | sean-k-mooney | did we talk about keystone midelware portentaly being able to provide us with the set of projects | |
| 16:10:47 | lbragstad | what i meant there was that that same domain-admin could have an inherited role assignment on all containing project (this works today in keystone) | |
| 16:11:00 | lbragstad | allowing them to get project-scoped tokens for each project within their domain | |
| 16:11:01 | dansmith | domain admin is really a side thing though, right? unrelated to system_admin and no current focus on supporting it | |
| 16:11:39 | lbragstad | dansmith correct - imho domain-support is on the back-back-burner | |
| 16:11:50 | sean-k-mooney | so with keystone domains today you can have full admin on a subset of a cloud right and create falvors and such | |
| 16:11:52 | dansmith | ack, so back to sean-k-mooney's question about how to handle system admin | |
| 16:12:00 | gmann | yeah, i am also not so clear on use case of it | |
| 16:12:26 | lbragstad | so - so for system-scope, here are my thoughts | |
| 16:13:13 | lbragstad | i was open to leaving it up to the service to determine if they allow system-users to create resources within projects - but it would absolutely require an alternative method for supplying the project_id | |
| 16:13:24 | lbragstad | (e.g., like what glance does with the owner property in the request body) | |
| 16:13:53 | dansmith | I just don't think providing a project_id for every operation is reasonable | |
| 16:14:05 | dansmith | an *alternate* project_id I mean | |
| 16:14:13 | sean-k-mooney | neutorn added suport for project_id for networks and some other reseouce i htink | |
| 16:14:19 | lbragstad | my firm opinion is that i think it would be a bad idea if nova, for example, started using fake project ids to continue allowing system-administrators to create servers on behalf of other users | |
| 16:15:34 | gmann | yeah, we required that for create server on specific host use case but that could be achieving by opening the policy for get hypervisors and project admin or so do it | |