| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-01 | |||
| 21:29:03 | mnaser | and then eventually caches enough so the request doesnt timeout | |
| 21:29:38 | openstackgerrit | Merged openstack/nova master: Add "links" in the response of "nova show" for a down-cell instance https://review.openstack.org/640302 | |
| 21:31:04 | mriedem | well i see this has come up before https://review.openstack.org/#/q/I3b9f60a2c4aea904f39d6914c8f35c4d682a6b3a | |
| 21:32:16 | mriedem | followed by https://review.openstack.org/#/q/I53d5284907d44ae8b5546993f8fd461b385c39e6 | |
| 21:32:20 | mriedem | we can't seem to make up our mind | |
| 21:40:03 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Force refresh nw info cache if cache is empty but ports attached https://review.openstack.org/640516 | |
| 21:41:24 | mriedem | melwitt: well i'm kind of stuck on how to proceed with your counting quotas from placement stuff | |
| 21:44:44 | openstackgerrit | Tim Rozet proposed openstack/nova master: Fixes race condition with privsep utime https://review.openstack.org/625741 | |
| 21:49:53 | mriedem | stephenfin: in case you didn't notice it looks like mikal would like you to remove the -2 from https://review.openstack.org/#/c/554438/ | |
| 21:56:48 | openstackgerrit | Merged openstack/nova master: conf: Deprecate 'disable_libvirt_livesnapshot' option https://review.openstack.org/626932 | |
| 21:57:12 | openstackgerrit | Merged openstack/nova master: Stop using "nova" in API samples when creating a server https://review.openstack.org/639874 | |
| 21:57:29 | openstackgerrit | Merged openstack/nova master: Make Claim._claim_test handle SchedulerLimits object https://review.openstack.org/636410 | |
| 22:16:50 | mriedem | is InstanceNUMACell.id a db primary key or something from the actual host...? | |
| 22:17:49 | mriedem | i guess the latter | |
| 22:32:15 | melwitt | mriedem: reading through your comments | |
| 22:37:22 | melwitt | mriedem: why stuck? do you and dansmith think the quota counting should try to parse user_id out of request specs? I assumed not | |
| 22:37:40 | mriedem | you mean the InstanceMapping._from_db_object? | |
| 22:37:52 | mriedem | stuck on whether or not InstanceMapping.user_id should be nullable, yes | |
| 22:39:00 | melwitt | oh | |
| 22:39:25 | melwitt | so the desire is to get it from the request spec json blob in _from_db_object | |
| 22:40:19 | mriedem | well we have 3 places to look | |
| 22:40:27 | mriedem | request spec, build request, instance in the cell | |
| 22:40:39 | mriedem | if the cell is down, the last one is going to blow up | |
| 22:40:40 | melwitt | build request doesn't have it, AFAICT | |
| 22:40:46 | mriedem | BuildRequest.instance.user_id | |
| 22:40:52 | mriedem | BuildRequest.instance is a json blob | |
| 22:40:58 | melwitt | oh, ok | |
| 22:41:11 | melwitt | I didn't know that was persisted in the db | |
| 22:41:39 | mriedem | yup | |
| 22:42:23 | mriedem | https://github.com/openstack/nova/blob/master/nova/compute/api.py#L934 | |
| 22:44:10 | mriedem | elbragstad: i waxed policy rule names just for you https://review.openstack.org/#/c/621476/33/nova/policies/server_topology.py@20 | |
| 22:46:14 | cfriesen | any chance either one of you could take a quick look at https://review.openstack.org/#/c/620706/ ? It's on a runway and nobody has looked at it since Matt and Alex on the 27th. | |
| 22:46:35 | mriedem | cfriesen: i'll be honest i'm avoiding that one | |
| 22:46:39 | cfriesen | heh | |
| 22:46:50 | cfriesen | good to know | |
| 22:46:59 | mriedem | it's just low priority for me | |
| 22:47:42 | mriedem | can the hardware stuff be split out of that? | |
| 22:47:52 | mriedem | you windriver folk seem to enjoy the larger single patches... | |
| 22:49:11 | mriedem | that would drop 1/3 of the size (and context to load) for the api part of it | |
| 22:49:36 | cfriesen | yeah, I can break out the hardware bit. you're thinking do that part first? | |
| 22:49:50 | cfriesen | or second | |
| 22:49:50 | mriedem | it's a dependency for the api stuff it looks like | |
| 22:49:56 | mriedem | idk honestly | |
| 22:50:15 | cfriesen | I think it could go either way, a bunch of the api stuff is just calling existing checks | |
| 22:50:27 | mriedem | the new hardware stuff is "Added the following validations to _validate_flavor_image(): cpu_policy and cpu_thread_policy values, serial ports, realtime mask, cpu topology." right? | |
| 22:51:07 | cfriesen | no, much less than that | |
| 22:51:41 | mriedem | oh i see https://review.openstack.org/#/c/620706/27/nova/compute/api.py@628 | |
| 22:52:31 | cfriesen | those are all existing functions | |
| 22:52:35 | mriedem | so leakypipes and bauzas approved that spec but haven't reviewed the code at all yet... | |
| 22:53:05 | mriedem | this just seems like something i'd have to fine-toothed-comb through | |
| 22:53:21 | mriedem | and i'm already at mental capacity for lots of other blueprints i'm reviewing right now | |
| 22:53:48 | mriedem | plus it's fucking snowing again and i'm about to lose it | |
| 22:54:37 | mriedem | https://www.kimt.com/content/news/February-has-been-a-record-breaking-month-for-snow-and-it-looks-like-March-will-start-with--506431011.html | |
| 22:54:41 | elbragstad | mriedem mmm - interesting | |
| 22:55:09 | mriedem | elbragstad: not really, but if that floats your boat :) | |
| 22:55:13 | mriedem | i think it might | |
| 22:55:19 | elbragstad | oh - you know it | |
| 22:55:39 | elbragstad | what does host-info do? | |
| 22:55:48 | elbragstad | lemme guess, gets information about the host? | |
| 22:55:57 | mriedem | shows admin-sensitive details | |
| 22:56:19 | cfriesen | mriedem: I get where you're coming from...but from my end it's frustrating since being on a runway is supposed to mean it gets reviews... | |
| 22:56:20 | mriedem | the api returns stuff that is admin-or-owner and if you're admin you get some extra juicy bits | |
| 22:56:33 | mriedem | cfriesen: yup, i know | |
| 22:56:34 | elbragstad | mmm | |
| 22:56:51 | elbragstad | ideally - it would be nice if the policies for those types of things went away | |
| 22:57:09 | mriedem | elbragstad: what replaces them? | |
| 22:57:30 | mriedem | different route? | |
| 22:57:34 | elbragstad | well - i'm not sure if this will work based on the two minutes i've known about this functionality | |
| 22:57:37 | elbragstad | but | |
| 22:58:04 | elbragstad | you could populate those bits if the request was made with a system-scoped token + a certain role | |
| 22:58:55 | mriedem | i knew you'd say something about system scoped tokens | |
| 22:59:01 | elbragstad | mmmm | |
| 22:59:12 | mriedem | does your wife tell you to stop talking about those at dinner? | |
| 22:59:28 | elbragstad | we don't talk about policy at dinner | |
| 22:59:44 | mriedem | just baby stuff | |
| 23:00:11 | elbragstad | i usually just fall asleep staring at a plate | |
| 23:00:24 | mriedem | alright, anyway, not urgent, just mentioned it since i know it's a thing | |
| 23:00:36 | mriedem | not sure if the host_info is a subaction or attribute based on the policy naming doc | |
| 23:00:40 | mriedem | seems like an 'attribute' | |
| 23:00:50 | elbragstad | yeah - i suppose you could think of it that way, too | |
| 23:01:17 | elbragstad | sinec it's a collection of attributes that only system users get to see, right? | |
| 23:01:33 | mriedem | yeah this is definitely system scope stuff, not project admin | |
| 23:01:38 | mriedem | b/c it's about the physical infra | |
| 23:01:42 | elbragstad | sure | |
| 23:01:49 | openstackgerrit | ya.wang proposed openstack/nova master: Select cpu model from a list of cpu models https://review.openstack.org/637834 | |
| 23:01:59 | elbragstad | ok - so i guess it depends on if you want to maintain two policies for the "same" API | |
| 23:02:11 | mriedem | we have some of that in other places | |
| 23:02:20 | elbragstad | or if you want to just implement a little filtering in the service and have a single policy to protect a single API | |
| 23:02:28 | mriedem | based on scope type... | |
| 23:02:32 | elbragstad | yes | |
| 23:02:39 | mriedem | so rule is admin-or-owner, and you get the extras with a system scope token | |
| 23:03:01 | elbragstad | the rule would be something like.. | |
| 23:03:27 | elbragstad | (role:admin and system_scope:all) or rule:owner | |
| 23:04:22 | mriedem | ok, which can still be overridden yeah? | |
| 23:04:45 | mriedem | if you want non-system scope but support-level people to be able to see stuff | |
| 23:04:49 | elbragstad | operators can override - if that's the check string | |
| 23:05:07 | elbragstad | support-level people? | |
| 23:05:40 | melwitt | mriedem: replied to your comment. I'll push another PS soon. thanks for raising the unresolved bit that I had missed | |
| 23:05:41 | mriedem | people that aren't operators, they don't have the keys to the hardware, but they need some kind of admin-y level auth to see things | |
| 23:05:41 | elbragstad | support-level people to me == someone with the reader role on the system (`openstack role add --user bob --system reader`) | |