Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-11-08
20:04:24 sean-k-mooney other are really things that are important to the admin and schduler only
20:06:36 gmann that is little complex to handle but anyways let's leave them as it is then if it get updated in future
20:07:32 sean-k-mooney gmann: well that would not be implemeted as a policy it would likely need to be a new api microverions
20:07:45 sean-k-mooney or at least a code change that would implement the filtering
20:08:15 gmann sean-k-mooney: but you said that should be configurable right not hard-coded is_admin check?
20:08:25 sean-k-mooney right now if operator use extra specs for filtering and want to hide that form user there only option is to hide all the extra specs which is an interoperatty issue
20:09:15 sean-k-mooney gmann: good quetion i assuem configurble jsut for interop but admin only for some might make sense. anyway in the context of dans patch we shoudl nto change anythign form what we have today
20:09:57 sean-k-mooney gmann: i just dont really think the exsitg policy fully solve that use case but operators are not complaing so lets not change it for now
20:10:28 gmann sean-k-mooney: or they are not even know it :) as it is allow to show extra specs to everyone as default
20:10:51 gmann but yes if someone has overridden the policy then it make sense
20:11:05 gmann let's leave those as it is.
20:11:40 gmann dansmith: sean-k-mooney so in that case, we can leave it as single policy itself instead of granular i suggested earlier
20:12:22 gmann making them granular for flavor and servers response might confuse and make things complex
20:12:28 dansmith gmann: still need a different one for server/flavor but yep
20:12:38 dansmith oh, no we definitely need those two,
20:12:39 gmann dansmith: because of default ?
20:12:42 dansmith because of the scope_types
20:13:47 sean-k-mooney i can see where scope_types come into other issue by why is it relevent here? you want to not check scope types on the server endpoint?
20:14:10 gmann and with flavor one default as system-project-reader and server one as project-reader ?
20:14:25 dansmith flavor one is project,system but the embedded one is just project
20:14:43 gmann embedded in server reposne right?
20:14:55 sean-k-mooney isned the embeded on contole by the server detail policy
20:15:06 sean-k-mooney e.g. its only expose via server detail
20:15:13 gmann sean-k-mooney: no, as separate policy after detail policy
20:15:14 sean-k-mooney not /server/uuid/extra_specs right
20:15:30 dansmith sure, we could rely on that, but all these tests are disabling the parent check to obsess over the child one being right,
20:15:41 dansmith which would imply that they need to be different
20:16:11 gmann yeah, like if operator want to show server detail to their owner but not extra-specs
20:16:14 dansmith the test will thus assert that system:reader can view the embedded one, but it can't actually
20:16:43 sean-k-mooney gmann: right but if they showed the falavor name you could look it up or at least what it is now
20:17:00 sean-k-mooney you could not compare embeeded to currnt but not sure how much that is relevent
20:17:54 gmann as long as we allow project for both flavor or embedded it is ok i think
20:17:58 sean-k-mooney dansmith: i have not looked at the test so ill trust your judgement if you think havign two woudl be useful but im not sure when it would make sense to have tehm set differently
20:19:03 gmann sean-k-mooney: like we will not add system scope for embedded one as system cannot GET /servers/server-id anyways
20:19:21 dansmith getting the two to work is also making me hate life, so maybe a note in the test would be better
20:20:33 gmann so any extra things to show in sevrer reponse has to be moved to project=scoped only as parent policy is project-scoped only
20:20:35 dansmith these tests are hard to debug sometimes, figuring out which context can do a thing that shouldn't be allowed
20:22:45 gmann dansmith: I tried too be more optimize there may be. instead those can be simple/readable with more separate tests for allowed and not-allowed
20:24:01 dansmith gmann: they're very obsessive which is good, they're just hard to debug, but more infra around them can make it easier
20:25:30 gmann sure
20:34:51 opendevreview Alexey Stupnikov proposed openstack/nova master: Test aborting queued live migration https://review.opendev.org/c/openstack/nova/+/776250
20:46:25 opendevreview Alexey Stupnikov proposed openstack/nova master: Test aborting queued live migration https://review.opendev.org/c/openstack/nova/+/776250
20:53:47 dansmith gmann: why does this not include other_project_* and legacy_admin ? https://github.com/openstack/nova/blob/171138146a648d22474b7021ac730e26f03455f8/nova/tests/unit/policies/test_flavor_extra_specs.py#L399
20:54:18 dansmith gmann: is it because we're not passing a context to the index check so we're not *actually* preventing those users from doing the flavor extra specs index on servers, because the server rule should have stopped them?
20:56:38 dansmith gmann: by the way, this is what I'm trying to get the tests to (only showing the context setup): https://pastebin.com/UKcd62Th
20:56:51 dansmith which I think is a lot easier to read, especially with the comments
23:10:31 gmann dansmith: RE: other_project_* and legacy_admin - yes as server rule will take care of accessing server
23:11:18 dansmith gmann: ack
23:11:43 gmann and in flavor, as there is no project_id there so anyone can access
23:12:44 dansmith gmann: well, right but in the server tests, I think the casual reader (and definitely the policy-editing operator) would expect that to be the server's project_id
23:13:23 dansmith meaning, when accessing the flavor on a server
23:14:13 dansmith i.e. here https://github.com/openstack/nova/blob/171138146a648d22474b7021ac730e26f03455f8/nova/tests/unit/policies/test_flavor_extra_specs.py#L327
23:14:41 dansmith so I will put a note in there, but that's probably another reason to have the rules eventually be separate and to pass a target with the proper project_id in it
23:16:46 gmann dansmith: yeah, we can put project_id in current rule too for safer side (if server can be seen by anyone but extra specs not) here - https://github.com/openstack/nova/blob/171138146a648d22474b7021ac730e26f03455f8/nova/api/openstack/compute/views/servers.py#L236
23:17:13 dansmith yeah
23:17:22 dansmith anyway, note added
23:17:38 dansmith I will try to finish this up tomorrow and get another version posted with more of it cleaned up
23:18:31 gmann dansmith: and on this: https://pastebin.com/UKcd62Th
23:19:28 gmann in ScoptType: self.admin_authorized_contexts need to include project_admin also right?
23:20:24 dansmith gmann: no? system-only for creating flavors right?
23:20:35 gmann or you can name self.system_admin_authorized_contexts and self.project_admin_authorized_contexts
23:20:53 dansmith well, flavor extra_specs anyway
23:20:54 gmann dansmith: ohk, so only for flavor or generically ?
23:21:40 dansmith I guess in the new way, project admin should be able to do that for project-private flavors, since admin==operator
23:21:48 dansmith I didn't change the policy on create/update (yet) so that's why it's sytem-only there
23:22:22 gmann ohk
23:22:36 dansmith I left it that way because I haven't done flavor yet, only flavor extra_specs because the servers change broke those tests,
23:22:41 dansmith so I'm a little out of order,
23:22:44 gmann got it
23:22:45 dansmith so I just didn't tweak that yet
23:23:35 gmann i can take those. this way it will be more clear on who access what.
23:24:00 gmann and I am almost done with listing all rule in wiki table, might be ready by tonight or tomorrow
23:24:29 dansmith okay, I will try to get this cleaned up and updated in gerrit tomorrow so maybe we can use it as a pattern going forward
23:24:41 gmann +1, thanks
23:41:35 clarkb nova should consider removing nova-live-migration-ceph from the gate queue as the job is non voting
23:54:05 opendevreview Merged openstack/nova master: Add autopep8 to tox and pre-commit https://review.opendev.org/c/openstack/nova/+/806182
#openstack-nova - 2021-11-09
04:36:53 opendevreview Merged openstack/nova master: Ignore plug_vifs on the ironic driver https://review.opendev.org/c/openstack/nova/+/813263
08:02:51 gibi lyarwood: I saw elodilles explained the setuptools pin question. thanks elodilles
08:10:09 bauzas hola folks
08:10:42 bauzas gibi: I'm asked to present some PTG updates in a company session today at the same time of the upstream meeting
08:10:58 gibi bauzas: o/
08:10:59 bauzas gibi: it would be a 2 min presentation about Nova
08:11:18 bauzas gibi: could you help me by chairing the meeting when I'm asked to discuss ?
08:11:27 gibi bauzas: sure
08:11:37 bauzas I could run the meeting, then passing it to you for 5 mins
08:11:49 bauzas and then, either you continue or me :)
08:12:57 gibi ok
08:13:11 gibi I will handle it when you need to switch
08:18:01 bauzas gibi: thanks
08:18:10 bauzas appreciated
08:22:25 gibi no worries
08:54:13 gibi lyarwood, elodilles: I'm seeing multiple guest kernel panics in stable/victoria volume related tests
08:55:53 gibi 1) https://zuul.opendev.org/t/openstack/build/67c89daf17e3475cb1d632f87beeb60d/log/controller/logs/tempest_log.txt#5950
08:56:28 lyarwood Just jumping on a call but I wonder if we were still using cirros 0.4.0 back then?
08:57:13 lyarwood /opt/stack/devstack/files/cirros-0.5.1-x86_64-disk.img
08:57:15 lyarwood maybe not
08:57:32 lyarwood however I also see image.http_image = http://download.cirros-cloud.net/0.3.1/cirros-0.3.1-x86_64-uec.tar.gz
08:57:32 gibi 2) https://1a59031cf12ee85b5b8a-5c947c8d22eb7769ff9d2de46bec4cc9.ssl.cf5.rackcdn.com/810915/2/gate/nova-grenade-multinode/ebc944c/testr_results.html
08:58:13 lyarwood anyway I'll take a look after this call
08:58:36 gibi ack, I see both 0.3.1 and 0.5.1 in the logs

Earlier   Later