Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-01
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 mriedem it's a dependency for the api stuff it looks like
22:49:50 cfriesen or second
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 elbragstad support-level people to me == someone with the reader role on the system (`openstack role add --user bob --system reader`)
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:53 elbragstad ah
23:05:53 mriedem elbragstad: yeah ok
23:05:54 mriedem that
23:05:59 elbragstad right...
23:06:07 elbragstad so you could rework that policy to be more flexible
23:06:13 elbragstad by default, to allow for those cases
23:06:28 elbragstad (role:reader and system_scope:all) or rule:owner
23:06:31 elbragstad ^ should do it
23:06:35 mriedem ok, well let's not go crazy here. i have to run pickup the kid before i get snowed in
23:06:53 elbragstad fwiw - we just started documenting a bunch of this
23:06:54 elbragstad https://review.openstack.org/#/c/638563/
23:07:02 elbragstad ^ you know - in case you decide you want to read it over dinner
23:07:19 mriedem i just might
23:07:28 mriedem i talk shop at dinner and it just goes into the void
23:07:40 elbragstad lol
23:19:00 marst mriedem: Hey Matt! Just to confirm that fake nova driver works perfectly with minimal local.conf in stable/rocky devstack. Thanks a lot once again!
23:31:49 openstackgerrit Chris Friesen proposed openstack/nova master: Add emulated TPM support to Nova https://review.openstack.org/631363
#openstack-nova - 2019-03-02
00:08:00 efried o/
00:13:23 mriedem marst: cool good to know
00:29:20 mriedem easy docs bug for someone https://bugs.launchpad.net/nova/+bug/1818310
00:29:21 openstack Launchpad bug 1818310 in OpenStack Compute (nova) "api-ref: block_device_mapping_v2.volume_size does not mention when it's required" [Low,Triaged]
00:52:26 openstackgerrit Merged openstack/nova master: fix bug with XML matcher handling missing children https://review.openstack.org/640411
01:13:06 temka mriedem, for what it's worth, we can forget about NUMA LM in Stein: https://review.openstack.org/#/c/635669/
01:13:09 temka (last comment)
01:13:42 temka On the flip side, I'm happy folks are testing this, so let's make it the best we can between FF and release, and aim to land early in Train
01:18:35 mriedem temka: ok thanks for letting me know, do you want me to -2 the bottom change?

Earlier   Later