Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-10-05
19:02:27 sean-k-mooney dansmith: i agree that operators can certly change policy and alter behavior and that does not affect the microversion today
19:02:33 gmann yeah "system-scope plus project id" is completely different new thing
19:02:41 sean-k-mooney but im not really sure where the line is
19:03:31 sean-k-mooney gmann: i might be missing something but im not really convicned it is
19:03:34 dansmith gmann: that's my concern over deciding the fate of this event api, FWIW
19:03:45 sean-k-mooney what makes that different then changing an api form project member to say project admin
19:03:47 dansmith sean-k-mooney: it is definitely a different thing to me
19:04:03 dansmith sean-k-mooney: it requires you know that the thing be new enough *and* that you need a different client behavior to make it work
19:04:08 dansmith neither of which are discoverable from the outside
19:04:24 dansmith sean-k-mooney: because of the client behavior change required
19:04:57 gmann sean-k-mooney: project member to say project admin, operator can always change it back via policy.yaml
19:04:57 sean-k-mooney is there not a client behaivor change requried with enabling scope enforce too
19:04:59 lbragstad https://review.opendev.org/c/openstack/nova/+/812601/1/nova/policies/server_external_events.py would be example of how to expose this to project users
19:05:31 lbragstad but https://review.opendev.org/c/openstack/nova/+/812602/1/nova/policies/server_external_events.py would be using project id pass-through
19:05:57 dansmith sean-k-mooney: yep, that's definitely a change in line with the one described above, but less concerning than just a single policy change to use a different role I think
19:06:05 sean-k-mooney lbragstad: thats assuming we standardise an new service role? or does that already exist
19:06:27 lbragstad it's not standardized - just an example
19:07:10 dansmith lbragstad: yeah, the second is my preference
19:07:13 sean-k-mooney the resaond i was asking is the idea of a service role is a new construct to me adn would have to be standarised i think if we were to use it in code
19:07:39 gmann dansmith: added sysmte+project-id case in PTG etherpad L227
19:07:41 dansmith lbragstad: and then perhaps we limit it per event, so to say "we know neutron uses system scope, so we're limiting network-* events to system scoped contexts to avoid users being able to send those"
19:07:46 dansmith gmann: thanks
19:07:58 sean-k-mooney the second i think is just the system_amdin_or_owner policy right
19:08:09 dansmith sean-k-mooney: no
19:08:20 dansmith sean-k-mooney: it's system scope WITH a project override, or a regular project token
19:08:26 gmann yeah
19:08:35 sean-k-mooney sorry not admin or owner
19:08:47 sean-k-mooney ok
19:08:49 lbragstad dansmith yeah - if nova can pack that as target data - you could do something like role:service and networking:%(event_type)s
19:08:52 dansmith also, lbragstad I'm fine with the policy not allowing regular users to hit the API until/unless we have a human-oriented event
19:08:52 sean-k-mooney ya i see the differnce
19:08:59 dansmith lbragstad: because it's just a default
19:09:11 dansmith lbragstad: oh we could do that too I guess
19:09:27 dansmith lbragstad: I don't think we apply the policy like that today, but we could
19:09:43 gmann but that need policies per event
19:09:44 dansmith lbragstad: I was thinking more like hard-coded python to check the scope after we look at the event type
19:09:53 dansmith gmann: right, I like it less, but it's an option
19:10:09 lbragstad o.p should generalize the target data
19:10:20 lbragstad s/should generalize/generalizes/
19:10:43 lbragstad i'm not sure if it supports regular expressions though
19:10:53 dansmith I dunno what your point is
19:10:58 gmann dansmith: lbragstad oh or we can make check_str with OR-per-event and like what lbragstad mentioned
19:11:02 dansmith I'm saying I think there's something to be said for it not being in the actual rule
19:11:16 frickler sean-k-mooney: https://paste.opendev.org/show/809803/ , I can also give you or others access to the held nodes if you want to have a look yourselves
19:11:34 gmann so single policy, check str with event_x AND project OR event_y AND system
19:11:41 dansmith tbh, I think some of these overly complex policy rules are asking for admins to get confused, write a policy wrong and break or expose something they don't expect
19:11:46 lbragstad yeah - i was just throwing it out there as an option if you wanted a way to restrict some users from posting networking events
19:11:54 dansmith which makes me wonder if putting this in the policy rule is the right thing, but.. it's an option and I don't totally hate it
19:12:04 dansmith lbragstad: ack
19:12:29 lbragstad otherwise - if you consider it business logic, putting it in the service itself makes sense
19:12:42 sean-k-mooney frickler: so in both cases the nova generated xml is more or less identical as we woudl expect meanign any delta in behavior is a libvirt bug
19:12:46 dansmith yeah, "unless the admin could/would need to change it, put it in code"
19:13:23 sean-k-mooney frickler: we are simplely setting the memory with <memory>262144</memory> we are not speficying any of the advance memory backing config
19:13:45 dansmith lbragstad: another question: would it be rude for me to say I'm officially burned out on policy stuff for like at least 24 hours?
19:13:57 lbragstad join the club
19:14:01 dansmith haha
19:14:02 lbragstad :)
19:14:20 lbragstad it's only tuesday, too
19:14:35 dansmith I know, I was going to say "for the week" but realized there's a lot of week left :/
19:15:02 sean-k-mooney well i for one am planning on not thining about this until the ptg
19:15:16 dansmith sean-k-mooney: I think you are a LIAR
19:15:19 sean-k-mooney lbragstad: that said im going to try and re review the latest version of your ooo changes
19:16:03 lbragstad every time i try *not* thinking about policy, i think about policy
19:16:19 sean-k-mooney dansmith: :) i still find our approch to policy to be very very non intuitive
19:16:35 dansmith sean-k-mooney: you just proved me right!
19:18:23 lbragstad going out on a limb here, but if a sub-system takes 5 years to change, it's probably more than just non-intuitive :)
19:20:29 dansmith heh
19:21:02 sean-k-mooney isnt the replacemnt for it ment to be simpler and more intunitieve to show forward progress :)
21:08:04 opendevreview Merged openstack/nova stable/ussuri: [stable-only] Pin virtualenv and setuptools https://review.opendev.org/c/openstack/nova/+/810461
21:30:05 opendevreview melanie witt proposed openstack/nova stable/train: [stable-only] Pin virtualenv and setuptools https://review.opendev.org/c/openstack/nova/+/812553
21:34:23 opendevreview melanie witt proposed openstack/nova stable/train: [stable-only] Pin virtualenv and setuptools https://review.opendev.org/c/openstack/nova/+/812553
21:40:15 opendevreview melanie witt proposed openstack/nova stable/train: [stable-only] Pin virtualenv and setuptools https://review.opendev.org/c/openstack/nova/+/812553
21:51:51 opendevreview Dmitrii Shcherbakov proposed openstack/nova master: [yoga] Add PCI VPD Capability Handling https://review.opendev.org/c/openstack/nova/+/808199
21:51:52 opendevreview Dmitrii Shcherbakov proposed openstack/nova master: [yoga] Support remote-managed SmartNIC DPU ports https://review.opendev.org/c/openstack/nova/+/812111
23:41:52 opendevreview melanie witt proposed openstack/nova master: Enforce api and db limits https://review.opendev.org/c/openstack/nova/+/712142
23:41:52 opendevreview melanie witt proposed openstack/nova master: Add logic to enforce local api and db limits https://review.opendev.org/c/openstack/nova/+/712139
23:41:53 opendevreview melanie witt proposed openstack/nova master: Update limit APIs https://review.opendev.org/c/openstack/nova/+/712707
23:41:53 opendevreview melanie witt proposed openstack/nova master: Update quota_class APIs for db and api limits https://review.opendev.org/c/openstack/nova/+/712143
23:41:54 opendevreview melanie witt proposed openstack/nova master: Tell oslo.limit how to count nova resources https://review.opendev.org/c/openstack/nova/+/713301
23:41:54 opendevreview melanie witt proposed openstack/nova master: Update quota sets APIs https://review.opendev.org/c/openstack/nova/+/712749
23:41:55 opendevreview melanie witt proposed openstack/nova master: Enforce resource limits using oslo.limit https://review.opendev.org/c/openstack/nova/+/615180
23:41:56 opendevreview melanie witt proposed openstack/nova master: Update quota apis with keystone limits and usage https://review.opendev.org/c/openstack/nova/+/713499
23:41:56 opendevreview melanie witt proposed openstack/nova master: Add legacy limits and usage to placement unified limits https://review.opendev.org/c/openstack/nova/+/713498
23:41:58 opendevreview melanie witt proposed openstack/nova master: Add reno for unified limits https://review.opendev.org/c/openstack/nova/+/715271
#openstack-nova - 2021-10-07
06:26:01 opendevreview Jinsheng Zhang proposed openstack/nova master: Nova support live-migrate instance between different ipxe efi rom https://review.opendev.org/c/openstack/nova/+/812796
08:00:55 gibi o/
08:03:20 gibi bauzas: do we have a meeting this morning?
08:03:33 bauzas dang
08:03:49 bauzas gibi: remind me the meeting name ?
08:04:14 gibi nova_extra
08:04:23 gibi I always have to look that up from https://meetings.opendev.org/#Nova_Monthly_Asia_Friendly_Team_Meeting
08:04:33 opendevmeet The meeting name has been set to 'nova_extra'
08:04:33 opendevmeet Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:04:33 opendevmeet Meeting started Thu Oct 7 08:04:33 2021 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:04:33 bauzas #startmeeting nova_extra
08:04:44 bauzas good moning folks, I have forgotten to open it :)
08:04:53 bauzas sorry for having it delayed
08:05:05 bauzas I don't have agenda for this meeting
08:05:20 bauzas it's more something like "if you want to discuss with us, let us know"
08:05:34 bauzas do we have Asian contributors here ?

Earlier   Later