| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-11-21 | |||
| 17:10:42 | efried | mriedem Which admins tend to do early on before they hand their cloud off to users, true? | |
| 17:10:58 | efried | mriedem So I guess we don't cover the case where they've got an existing cloud and they just decide to enable this thing. | |
| 17:11:58 | mriedem | i also wouldn't backport yours | |
| 17:12:14 | mriedem | because if i'm on stable and pick that up, and all of a sudden i start getting 500s, i'd be annoyed | |
| 17:14:29 | efried | mriedem Is backporting a consideration? The service user thing is experimental, right? | |
| 17:14:42 | mriedem | i don't consider it experimental | |
| 17:14:49 | mriedem | it's been in since ocata and we run with it enabled in our nova-next job | |
| 17:14:54 | mriedem | so yes i was going to backport | |
| 17:15:06 | mriedem | i've also marketed this feature during 2 summit project update talks | |
| 17:15:17 | efried | mriedem https://github.com/openstack/nova/blob/master/nova/conf/service_token.py#L43 | |
| 17:15:27 | efried | So I guess we oughtta take that line out ^ | |
| 17:15:37 | jaypipes | sean-k-mooney: that series touches both traits and shared resource providers | |
| 17:15:48 | jaypipes | sean-k-mooney: it's a combo of me, efried and gibi. | |
| 17:16:54 | mriedem | efried: yeah i'd be fine with that | |
| 17:16:58 | mriedem | i'd leave it disabled by default | |
| 17:21:17 | openstackgerrit | Eric Fried proposed openstack/nova master: Service token is not experimental https://review.openstack.org/521955 | |
| 17:21:19 | efried | mriedem ^ | |
| 17:23:13 | mriedem | wanna remove the 'this is disabled by default' line? | |
| 17:23:16 | mriedem | then i'm +2 | |
| 17:23:58 | dansmith | artom_: good comments, thanks for those | |
| 17:24:10 | dansmith | mriedem: you might want to look at those before you push up a rev and see if you have opinions | |
| 17:24:14 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Remove deprecated 'multi_instance_display_name_template' opt https://review.openstack.org/499612 | |
| 17:24:15 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Simplify instance name generation https://review.openstack.org/516573 | |
| 17:24:47 | artom_ | dansmith, yey, my brain works! | |
| 17:27:22 | sean-k-mooney | stephenfin: sorry had to step away for a minute. well what i was wondering is wether "is not none" is enough e.g. can self.cpu_pinning contain "shared" | |
| 17:29:46 | mriedem | efried: +2 on https://review.openstack.org/#/c/490057 - thanks for the quick updates | |
| 17:29:59 | stephenfin | sean-k-mooney: cpu_pinning contains a dict of host to guest CPU mappings | |
| 17:30:11 | efried | mriedem Thanks. | |
| 17:30:13 | stephenfin | You're thinking of 'cpu_policy', which would contain 'shared' or 'dedicated' | |
| 17:30:48 | openstackgerrit | Merged openstack/nova master: Merge flavor extensions controller code https://review.openstack.org/516104 | |
| 17:33:49 | sean-k-mooney | stephenfin: yes i just noticed self.cpu_pinning is a proxy field for cpu_pinning_raw whic is a dict of integers presumable the vCPU to pCPU mappings | |
| 17:34:06 | openstack | Launchpad bug 1733642 in OpenStack Compute (nova) "duplicate for #1724689 AttributeError: 'NoneType' object has no attribute 'get_token'" [Medium,In progress] - Assigned to Matt Riedemann (mriedem) | |
| 17:34:06 | efried | mriedem I dup'd my bug (https://bugs.launchpad.net/nova/+bug/1724689) to yours and abandoned my patch. | |
| 17:34:42 | mriedem | efried: ok, i was going to dupe my bug against yours but ok :) | |
| 17:34:47 | artom_ | I feel like naming it "policy" is confusing us | |
| 17:35:21 | artom_ | As I writing an internal email about it, I came up with "qualitative" (what we're calling policy) vs "quantitative" (ie, resources) | |
| 17:35:29 | artom_ | Does that work better? (Or at all?) | |
| 17:36:36 | openstackgerrit | Eric Fried proposed openstack/nova master: Service token is not experimental https://review.openstack.org/521955 | |
| 17:36:48 | efried | mriedem That's done ^ | |
| 17:37:06 | mriedem | +2 | |
| 17:38:14 | efried | sdague Service token-y stuff while you're in the mood: https://review.openstack.org/#/c/521947/ https://review.openstack.org/521955 | |
| 17:40:20 | dansmith | artom_: I don't really think that has much more meaning to me, but I'm obviously biased | |
| 17:40:29 | dansmith | artom_: I'll let mriedem make the call on what the name should be | |
| 17:40:44 | artom | Ugh, it'll be some obscure 80s rock band | |
| 17:41:01 | dansmith | fine by me :P | |
| 17:41:01 | mriedem | i agree it's confusing that _GroupAntiAffinityFilter is a policy filter but _GroupAffinityFilter isn't | |
| 17:41:36 | sdague | efried: looking | |
| 17:41:49 | mriedem | i mean, we could just call the damn thing RUN_FOR_REBUILD but that doesn't help a ton with the reasoning behind which filters should be run during rebuild or not | |
| 17:42:14 | dansmith | and I expect we need to re-use much of the logic for some other things where we need to check with the scheduler | |
| 17:42:40 | mriedem | example? | |
| 17:42:41 | dansmith | although I guess resize does need to check the resourcey things | |
| 17:42:44 | dansmith | I dunno | |
| 17:42:51 | dansmith | feels far too targeted to just say it's for resize | |
| 17:42:52 | mriedem | i think rebuild is just the odd duck | |
| 17:43:12 | mriedem | resize runs through the scheduler because it's going to do a claim on the chosen host | |
| 17:43:12 | dansmith | well, if that's really the case, then maybe we should just be specific until we have a counterexample | |
| 17:43:15 | dansmith | yeah | |
| 17:43:25 | mriedem | live migration doesn't do a claim | |
| 17:43:40 | mriedem | but live migration does allocate on the dest host | |
| 17:43:42 | sdague | efried: so, on https://review.openstack.org/#/c/490057/27/nova/api/openstack/compute/servers.py, while it's fine to pass context around, did you look into just pulling it from thread local storage? | |
| 17:43:42 | mriedem | using the same flavor | |
| 17:44:05 | sdague | efried: https://github.com/openstack/oslo.context/blob/18aa6ec496e54b2403c2cc65234ef6447021fdee/oslo_context/context.py#L490-L495 | |
| 17:44:07 | efried | sdague I didn't. | |
| 17:44:38 | efried | sdague tbh, mordred did the code-side work on that patch. I just did the test, and kept it up to date. | |
| 17:44:51 | sdague | ok, the long pass through of some of these variables gets a little spidery. It's probably fine here, but something to think about in the future | |
| 17:45:17 | mriedem | that's why i worried about something doing context.get_admin_context() and that eventually going through here | |
| 17:45:21 | mriedem | but apparently we don't do that with images | |
| 17:45:28 | efried | sdague Yeah, that would have made things a lot easier. Is that the same thing? | |
| 17:49:00 | sdague | mriedem: yeh, I could see that | |
| 17:49:20 | sdague | it's one of those things where context was written originally to not have to pass it around | |
| 17:49:29 | sdague | but that got forgotten at some point | |
| 17:49:38 | sdague | so, meh | |
| 17:50:05 | sdague | efried: +A on that patch, I'll look at the rest of the conversions on top once I get some lunch | |
| 17:50:24 | efried | sdague Thank you sir. | |
| 17:50:44 | efried | sdague (mriedem) Note that the cinder one might still be busted. But now that this one is going through, I'll get back to looking at that. | |
| 17:52:11 | mriedem | efried: it does remind me that someone had a patch to add some code for nova to auth with a service user to do things with cinder like we do for neutron | |
| 17:52:18 | mriedem | i think in one of the periodic tasks | |
| 17:52:34 | efried | mriedem Yeah, I couldn't remember if that was niraj_singh, but I don't think so. | |
| 17:52:59 | mriedem | efried: https://review.openstack.org/#/c/384799/ | |
| 17:53:07 | efried | mriedem Oh, actually I was thinking of someone who was trying to use service auth from *within* cinder. | |
| 17:53:29 | artom | dansmith, mriedem, I think we need to get stephenfin to look at the PCI and NUMA bits when he comes back tomorrow | |
| 17:53:50 | dansmith | okay I'm off tomorrow and mriedem is too I think | |
| 17:53:55 | mriedem | pci is extra specs only | |
| 17:54:01 | mriedem | i asked stephen about that yesterday | |
| 17:54:05 | mriedem | numa is definitely a resource thing | |
| 17:54:11 | mriedem | we do claims on numa limits in the resource tracker | |
| 17:54:13 | artom | mriedem, can an admin change them though? | |
| 17:54:50 | mriedem | an admin could change the pci passthrough settings in flavor extra specs, sure | |
| 17:54:58 | artom | For NUMA the cpu and thread policy can change, I dunno if that can give rise to the situation where the host can no longer accept them | |
| 17:55:22 | mriedem | changing extra specs on an existing flavor would be kind of a bad move i think | |
| 17:55:31 | mriedem | but we allow it | |
| 17:55:33 | dansmith | the flavor embedded in the instance will have the pci stuff then, which means we won't see the changed extra_specs from the top-level flavor in the rebuild | |
| 17:56:12 | dansmith | the cpu and thread policy change in the image meta might be a reason to do the rebuild though, | |
| 17:56:18 | dansmith | so I dunno what to say about that | |
| 17:57:54 | artom | dansmith, oh right, that's true, flavours stay with instances now | |
| 17:58:21 | artom | So anything involving flavor extra specs isn't policy then - ie, no need to check with it on rebuild, it hasn't changed for the actual instance | |
| 17:58:22 | dansmith | well, no | |
| 17:58:31 | dansmith | flavors stay with the instance, flavours are not a thing in nova :P | |
| 17:58:51 | artom | What do you mean not a thing? | |
| 17:59:02 | artom | Oh | |