| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-10-05 | |||
| 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 ? | |
| 08:06:07 | bauzas | or any other folks wanting to discuss ? | |
| 08:07:27 | gibi | I can rant about the rainy weather | |
| 08:07:40 | gibi | ;) | |
| 08:08:42 | sean-k-mooney[m] | just looking at the patch submitted above by jingsheng zhang https://review.opendev.org/c/openstack/nova/+/812796 | |
| 08:08:54 | sean-k-mooney[m] | is that something we even support | |
| 08:09:01 | sean-k-mooney[m] | ipxe boot of nova vms | |
| 08:09:20 | bauzas | gibi: hah | |
| 08:09:28 | bauzas | we have a good weather here :) | |
| 08:09:29 | sean-k-mooney[m] | i dont know if they are here and could explain there motivation for that | |
| 08:09:45 | bauzas | sean-k-mooney: good question | |
| 08:10:25 | sean-k-mooney[m] | my understandign is the only way to use ipxe is to enable the qemu boot menu | |
| 08:10:33 | sean-k-mooney[m] | and manually select it | |