| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-19 | |||
| 20:16:19 | melwitt | the second one links to a non existing bp | |
| 20:16:27 | mriedem | the 2nd one's bp is completed | |
| 20:16:30 | mriedem | the os-hosts removal thing, | |
| 20:16:34 | mriedem | i noted it after that bp was completed | |
| 20:16:42 | mriedem | the series itself is a precursor to move-nova-cmds-to-cliff in queens | |
| 20:16:55 | mriedem | sfinucan wants to deprecate as much as possible from nova-manage before moving the infra for it over to cliff | |
| 20:17:03 | mriedem | making the work he needs to do in queens smaller | |
| 20:17:20 | mriedem | i asked him to remove the bp links for that though since it's not approved for pike, so would have been confusing | |
| 20:19:14 | melwitt | oh, I see. thanks | |
| 20:22:23 | mriedem | another easy one https://review.openstack.org/#/c/463065/ | |
| 20:23:06 | mriedem | and https://review.openstack.org/#/c/391060/ | |
| 20:23:38 | mriedem | ^ is less easy i guess | |
| 20:26:25 | efried | johnthetubaguy mriedem Can I get a sense of the scope of remaining work for bp/use-service-tokens-pike? | |
| 20:26:54 | efried | It appears to be at least driving https://review.openstack.org/412634 to completion - but... is that it? | |
| 20:26:55 | mriedem | efried: i haven't looked | |
| 20:27:11 | mriedem | i think using it for glance is the big one | |
| 20:27:20 | efried | Okay, cause it looks like neutron & cinder are done. | |
| 20:27:25 | mriedem | yes those were done in ocata | |
| 20:27:55 | mriedem | efried: or just look at the spec :) https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/use-service-tokens.html | |
| 20:28:07 | mriedem | https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/use-service-tokens.html#work-items | |
| 20:28:09 | efried | mriedem Well, yeah, I did that | |
| 20:28:12 | mriedem | everything in there is done except for the glance one | |
| 20:28:29 | efried | Okay, just making sure I understood correctly. Thanks. | |
| 20:32:45 | melwitt | mriedem: hm, that reqspec delete one, the commit message points out that it's okay to delete it even if instance destroy fails. I'm thinking of a case where destroy fails, the user decides to just keep the instance around and then things will fail if they do a resize or something that will invoke the scheduler, right? | |
| 20:33:26 | melwitt | bc that reqspec will be gone | |
| 20:33:53 | mriedem | melwitt: did you see the comment i just put in there? | |
| 20:34:07 | melwitt | I just read it a few seconds after I typed in here heh | |
| 20:34:13 | mriedem | b/c i thought about that yesterday or something | |
| 20:34:19 | mriedem | but just remembered to point it out | |
| 20:34:28 | mriedem | we can be sure it's gone if we do a local delete, | |
| 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 | mriedem | and deleted the reqspec there is an upcall, | |
| 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: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 | mriedem | flavor extra specs are usually duplicated with image meta | |
| 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: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 | |