| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-19 | |||
| 20:34:34 | mriedem | we're less sure if we cast to the compute to delete it | |
| 20:34:39 | melwitt | yeah, it feels like a bit more thought should be put into it | |
| 20:35:41 | mriedem | removed my +2 | |
| 20:35:53 | mriedem | we could delete the reqspec if we are doing a local delete in the api, | |
| 20:36:10 | mriedem | we're going to need a periodic or nova-manage CLI to cleanup orphans from the api db for req spec and instance mappings, | |
| 20:36:28 | mriedem | so we could leave that to cleanup the req spec in the case of soft delete or when we cast to the compute to delete the req spec | |
| 20:36:40 | mriedem | i don't know where a periodic would run, we don't have periodics in the api or conductor, only scheduler | |
| 20:37:19 | mriedem | reqspecs are for scheduling so cleaning up orphans in a periodic task in the scheduler might be ok, but instance mappings don't fit that as nicely | |
| 20:38:56 | melwitt | I was just thinking, as long as the instance has disappeared from the user's perspective (deleted=1) then it's okay to delete the reqspec, since at that point they aren't able to do requests with it anyway (other than listing deleted instance I think) | |
| 20:40:00 | mriedem | but we don't deleted=1 until we're in the compute in most cases, | |
| 20:40:06 | melwitt | I just can't remember where that happens, if it's in compute/api in the case of a cast to compute, or if it's in compute. I guess for the cast it's in compute, which sucks | |
| 20:40:06 | mriedem | and deleted the reqspec there is an upcall, | |
| 20:40:08 | mriedem | which we want to avoid | |
| 20:40:17 | melwitt | yeah | |
| 20:44:44 | openstackgerrit | Eric Fried proposed openstack/nova master: Add service_token for nova-glance interaction https://review.openstack.org/419662 | |
| 20:45:24 | openstackgerrit | Eric Fried proposed openstack/nova master: DNM: Test service token in Glance https://review.openstack.org/419666 | |
| 21:08:08 | mriedem | mordred: what is flavor extra_info? do you mean extra_specs? | |
| 21:14:40 | mordred | mriedem: yes. sorry - was typing from memory | |
| 21:15:04 | mordred | mriedem: some clouds have hundreds of flavors - so it gets expensive :) | |
| 21:15:06 | mriedem | ok, not totally sure why you'd need extra specs, we don't expose those to non-admins by default | |
| 21:16:00 | mordred | I mean- the call works on all of the clouds ... but I was told it was important to have them at some point | |
| 21:16:59 | mriedem | hold the phone | |
| 21:17:00 | mriedem | https://github.com/openstack/nova/blob/master/nova/policies/flavor_extra_specs.py#L25 | |
| 21:17:06 | mriedem | create, update, delete are admin, | |
| 21:17:09 | mriedem | show is admin or owner | |
| 21:17:17 | mriedem | but...the admin is the owner of the flavor... | |
| 21:18:21 | mordred | yah - it quite happily returns a {} everywhereI run it | |
| 21:20:08 | mordred | mriedem: ah - I think we default to fetching them because they used to come in from OS-FLV-WITH-EXT-SPECS:extra_specs | |
| 21:21:24 | mriedem | hmm, johnthetubaguy or cfriesen might know more, | |
| 21:21:36 | mriedem | cfriesen has been looking at this for embedding the instance flavor in the server GET response body, | |
| 21:21:54 | mriedem | which has to hide the flavor extra specs if not an admin i think | |
| 21:22:11 | mriedem | johnthetubaguy would know why policy could be wonky here | |
| 21:23:29 | mordred | neat. I look forward to learning more! | |
| 21:24:30 | mordred | mriedem: so extra_specs are not intended to be useful to end-users | |
| 21:25:22 | mriedem | that's a question or statement? | |
| 21:26:34 | mordred | questoin... just confirming me learning things | |
| 21:26:45 | dansmith | some people expose them to users | |
| 21:27:16 | mordred | I have never gotten an error fetching them anywhere, fwiw | |
| 21:27:37 | dansmith | mordred: not once? like not one single time? | |
| 21:27:38 | melwitt | by default, defining flavors and extra_specs on flavors and matching metadata keys on host aggregates is an admin thing | |
| 21:27:38 | mriedem | flavor extra specs are usually duplicated with image meta | |
| 21:27:48 | mriedem | and users can see image meta | |
| 21:27:53 | mriedem | and assign image meta in horizon | |
| 21:27:57 | mriedem | i think anyway | |
| 21:28:06 | dansmith | mriedem: pretty sure that cburgess lets his user _see_ the extra specs because it matters for special types of instances | |
| 21:28:10 | mordred | dansmith: not one single time | |
| 21:28:12 | mriedem | like, i want the guest watchdog action to do x for this vm | |
| 21:28:16 | dansmith | mordred: daaayum. | |
| 21:28:26 | mordred | dansmith: yah. it's a pretty successful api | |
| 21:28:45 | mordred | dansmith: I mean, it's also pretty much always just empty | |
| 21:29:01 | mordred | oh. you know what - I might be TOTALLY lying | |
| 21:29:06 | melwitt | mriedem: yeah, I think that's right that image meta is the user controllable way to express things to the scheduler (other than hints) | |
| 21:31:00 | mriedem | dansmith: remember that cburgess encourages his users to do live migrations once a minute too :) | |
| 21:31:11 | mordred | nope. not lying. works fine at least with a quick check on vexxhost and citycloud | |
| 21:31:22 | dansmith | mriedem: not saying cburgess makes good decisions, I'm just saying he lets them see extra_specs :P | |
| 21:31:30 | mordred | I was thinking I just hadnt noticed because we also won't fail if the call fails and will return an empty {} | |
| 21:33:45 | mriedem | mgagne: do you expose flavor extra specs to non-admin users? | |
| 21:34:05 | mordred | also - fwiw, it works in devstack too: http://logs.openstack.org/72/464772/1/check/gate-shade-dsvm-functional-neutron/f9ee1f6/console.html#_2017-05-15_23_26_48_151366 | |
| 21:34:41 | mordred | that's operating as the demo user | |
| 21:35:11 | mordred | I'm mostly following up on this because if you think it's supposed to be not exposed and it is it might point to some sort of deeper problem | |
| 21:36:11 | mriedem | so, | |
| 21:36:22 | mriedem | i think it's because we don't target the flavor in the policy check | |
| 21:36:31 | mriedem | i remember something about this when reviewing johnthetubaguy spec on fixing policy scope checks | |
| 21:36:43 | mriedem | i.e. we're not scoping the admin or owner check to the flavor, | |
| 21:36:56 | mriedem | we're scoping it to the user's request context, and since they are the owner of the request, they have access | |
| 21:37:48 | mriedem | we don't have a project_id on flavors though to check against... | |
| 21:38:43 | mriedem | so yeah, the policy basically doesn't mean anything :) | |
| 21:38:47 | mriedem | unless you changed it to admin only | |
| 21:41:49 | openstackgerrit | Alex Szarka proposed openstack/nova master: [WIP] Transform instance.live_migration_rollback notification https://review.openstack.org/402124 | |
| 21:45:09 | melwitt | mriedem: I'm working on the backports for the caching thing | |
| 21:46:41 | mriedem | melwitt: cool | |
| 21:53:50 | openstackgerrit | Alex Szarka proposed openstack/nova master: Transform instance-live_migration_abort notification https://review.openstack.org/420453 | |
| 22:16:38 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Don't warn on expected network-vif-unplugged events https://review.openstack.org/465794 | |
| 22:17:24 | mordred | mriedem: ok. neat! so - I won't worry about it too much then | |
| 22:21:21 | mriedem | i might worry about it | |
| 22:21:31 | mriedem | well, i'll proxy that worry through johnthetubaguy | |
| 22:23:19 | mriedem | melwitt: did you also want to give a heads up to the ops/dev list about that caching patch? | |
| 22:23:22 | mriedem | and backport to newton | |
| 22:23:52 | melwitt | mriedem: yes to both. working on the newton backport right now and will compose an email for the MLs | |
| 22:23:58 | mriedem | thanks | |
| 22:24:07 | mordred | mriedem: I believe in johnthetubaguy's ability to worry about it | |
| 22:36:12 | cfriesen | mordred: mriedem: missed the earlier discussion about extra specs. I think the "admin_or_owner" policy for indexing extra specs means that a regular user is allowed to look at them, just not modify them. (at least that's the behaviour I see. | |
| 22:36:14 | openstackgerrit | Mike Perez proposed openstack/nova master: Remove cells topic configuration option https://review.openstack.org/463218 | |
| 22:36:54 | mriedem | cfriesen: yeah we sorted it out | |
| 22:37:02 | mriedem | it's actually a semi-busted/fake policy check | |
| 22:37:36 | cfriesen | I kind of like the behaviour, since it lets the user see the details of the flavors | |
| 22:37:50 | cfriesen | but our users tend to be pretty advanced and closely tied to the admins | |
| 22:46:26 | melwitt | mriedem: I assume we're going to be looking at releasing newton and ocata asap after the backports merge? (for the email) | |
| 22:51:29 | mriedem | melwitt: yeah | |
| 22:51:55 | mriedem | which is why i also wanted to get https://review.openstack.org/#/c/464088/ backported | |
| 22:53:04 | melwitt | mriedem: k. looks like you have a comment to address on that one? | |
| 22:53:32 | mriedem | i guess | |
| 22:53:37 | mriedem | sfinucan! | |
| 22:55:47 | mriedem | i don't really understand it though | |
| 22:55:54 | mriedem | if that's true about rstrip, how is the test not failing? | |
| 23:03:07 | mriedem | doing what is suggested doesn't work, | |
| 23:03:17 | mriedem | tests fail because stringifying the url encodes the special characters | |
| 23:03:18 | melwitt | I don't yet understand it either | |
| 23:05:41 | mriedem | https://github.com/zzzeek/sqlalchemy/blob/master/lib/sqlalchemy/engine/url.py#L66 | |
| 23:05:55 | mriedem | does linking to zzzeek code summon the zzzeek?! | |