| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-19 | |||
| 13:28:04 | efried | except that spec freeze is next week | |
| 13:28:12 | stephenfin | Yeah, I'd like to wait to see how cpu-resources goes before committing to anything | |
| 13:28:21 | stephenfin | I wanted to have that up this week but unit test coupling is killing me | |
| 13:28:27 | stephenfin | and I haven't even started on the reshape | |
| 13:28:37 | efried | as you well know, approving a spec for this release doesn't "commit" us to getting it in this release. | |
| 13:29:09 | stephenfin | Technically, no, but it does send the wrong message to people that aren't as involved in nova as we are | |
| 13:29:11 | stephenfin | (PMs) | |
| 13:29:22 | efried | It would be a better story for Alex et al if they could go back and tell their downstream "approved, but considerable risk due to deps" than "no chance in Train". | |
| 13:29:33 | efried | yeah, Alex and I can manage PM expectations :) | |
| 13:29:38 | stephenfin | Suggesting we think this can land when I, for example, have very little confidence that it will | |
| 13:29:47 | stephenfin | Oh, I'm worried about my PM :P | |
| 13:30:14 | efried | okay. Alex and I can't manage your PM. | |
| 13:30:24 | stephenfin | Not sure anyone can, heh | |
| 13:30:31 | stephenfin | Anyway, not really the point | |
| 13:31:22 | stephenfin | As above, I'm not confident about landing that feature, but if the ask is to just review the spec, I can do that | |
| 13:31:54 | stephenfin | Though not today. I want to keep chipping away at these unit tests and hopefully get the first few patches pushed | |
| 13:32:26 | efried | I think it would be a good step if we can get you & sean-k-mooney agreeing to the design itself, before spec freeze. | |
| 13:33:03 | stephenfin | Yeah, that makes sense | |
| 13:33:10 | efried | Then we can armwrestle over whether it makes sense to merge it for Train with the caveat of high risk, or merge it in backlog/ | |
| 13:33:33 | stephenfin | Okay, I can set aside time to do that early next week, maybe in person with sean-k-mooney | |
| 13:33:39 | efried | thank you sir | |
| 13:33:46 | efried | and with alex_xu | |
| 13:34:14 | sean-k-mooney | sorry was away form my laptop what was the context? | |
| 13:34:14 | stephenfin | In person might be tough there, but sure :) | |
| 13:34:23 | efried | easier for you than for me. | |
| 13:34:36 | sean-k-mooney | efried: i think he ment alex | |
| 13:34:46 | efried | sean-k-mooney: we're talking about the mixed PCPU/VCPU spec | |
| 13:34:57 | sean-k-mooney | oh ok | |
| 13:35:40 | efried | TLDR, stephenfin and I both agree it would be quite high risk for Train, and need to decide whether we want to merge it with that caveat or take a hard line and explicitly punt it. But in either case, I would like to see the design sorted before spec freeze, so we merge it either to train/ or backlog/. | |
| 13:35:52 | sean-k-mooney | for what its worth i think we could do that but im concerned with the scope. e.g. if we had completed teh rest fo the cpu stuff by m2 i would have been fine with it | |
| 13:36:30 | sean-k-mooney | efried: ok | |
| 13:36:35 | sean-k-mooney | ill look at it again | |
| 13:36:41 | efried | thanks | |
| 13:36:46 | sean-k-mooney | i think at most we only need 1 extraspec | |
| 13:37:18 | sean-k-mooney | not the two that are proposed. and i would prefer it to be a new one rather then messing with hw:cpu_policy | |
| 13:37:37 | sean-k-mooney | spec freeze is wednesday right? | |
| 13:37:49 | sean-k-mooney | or thrusday? next week in either case | |
| 13:38:01 | stephenfin | I'd rather we used 'resources:VCPU' and 'resources:PCPU' but I don't recall why that wasn't chosen again | |
| 13:38:04 | stephenfin | I need to look at it again | |
| 13:38:10 | stephenfin | next week though! | |
| 13:38:37 | sean-k-mooney | stephenfin: because we never want people ot use resocues: driectly and that does not provide a way to say which cpus are the pinned ones | |
| 13:39:10 | stephenfin | That's the one | |
| 13:39:33 | stephenfin | jaypipes will be turning over in his OpenStack grave though | |
| 13:41:38 | efried | FWIW at every turn I'm finding I prefer using non-Placement-isms in the flavor, that get translated internally to Placement-isms. | |
| 13:42:06 | efried | particularly since we have the request_filter framework now. | |
| 13:42:36 | sean-k-mooney | the main disadvandate to useing the placment stuff direcly is if the modeling in placment chagnes you have to chagne your flavors | |
| 13:42:43 | efried | that too | |
| 13:43:26 | efried | another big one is that you sometimes don't know enough at flavor time to construct all the proper placement-isms. | |
| 13:43:37 | sean-k-mooney | right | |
| 13:43:48 | efried | This will become more and more true as we start splitting out NUMA, devices, bandwidth, etc. | |
| 13:43:49 | sean-k-mooney | the image can enable pinning or numa | |
| 13:43:54 | efried | yup | |
| 13:44:11 | efried | we have pieces coming together from several places and there will need to be placement syntax tying them together (e.g. affinity) | |
| 13:44:23 | efried | but you can't know that until schedule time when all the pieces are assembled. | |
| 13:44:53 | efried | gibi: you still around? | |
| 13:50:36 | sean-k-mooney | needssleep: i like the name :) i woke up today thinking it was thursday so i can agree with that statement | |
| 13:51:15 | gibi | efried: yes | |
| 13:51:52 | efried | gibi: o/ | |
| 13:51:52 | efried | What further is needed to secure your +2 on the providers.yaml spec https://review.opendev.org/#/c/612497/ ? | |
| 13:53:05 | gibi | efried: the '$COMPUTE_NODE' templating seems too much. If we simply allow to identify an RP by name then we can spare the complexity of the templating | |
| 13:53:33 | sean-k-mooney | gibi: personally i would be fine with suppport both uuid and name | |
| 13:53:54 | gibi | efried: if the rest of the team feels ok with the templating I won't stop it | |
| 13:54:43 | sean-k-mooney | you would usee uuid if you want to reference non root providers, or create them in the future and name to reference the root provider or any other named one | |
| 13:54:53 | efried | gibi: I added `name` back to the `identification` | |
| 13:55:21 | sean-k-mooney | im not oppsed to the templating by the way just my 2cents | |
| 13:55:35 | efried | gibi: and `$COMPUTE_NODE` allows us to hit ironic nodes, which (as dansmith convinced me yesterday) you wouldn't want to try to identify by hostname because the nodes managed by this compute can change when the hashring reshuffles. | |
| 13:55:40 | gibi | efried: sorry I stuck with PS12. reading PS 12 now | |
| 13:56:03 | gibi | I mean 13 | |
| 13:56:12 | efried | cool, thanks. | |
| 13:56:16 | openstackgerrit | **** proposed openstack/nova master: Nova: node should be deleted when last service is deleted https://review.opendev.org/671731 | |
| 13:57:14 | sean-k-mooney | am ^ | |
| 13:57:30 | sean-k-mooney | no ...? | |
| 13:57:49 | dansmith | lol | |
| 13:58:06 | sean-k-mooney | apperently there is a bluepirnt but the link does not work | |
| 13:58:12 | gibi | efried: so we have more than one node under a compute service. the admin wants to configure some node specific thing via the yaml file. It works for a while but then the node is moved under another compute service where the yaml file has different config. How this allows the admin to specify config for a single ironic node properly? | |
| 13:59:35 | efried | gibi: If they want to have a config for "one specific ironic node no matter which compute service it's under" they could deploy the same config (a single file, that identifies that ironic node explicitly) to all compute hosts. | |
| 13:59:57 | dansmith | gibi: yep, if the admin has different files on different nodes, then a rebalance will change inventory, regardless of if they use $COMPUTE_NODE or not.. that'll need to be a ..node: warning probably regardless | |
| 14:00:17 | sean-k-mooney | dansmith: oh its just a bad commit title | |
| 14:00:35 | dansmith | sean-k-mooney: apparently the submitter is a secret agent | |
| 14:00:43 | dansmith | who cannot reveal their identity | |
| 14:00:45 | gibi | so the templating only helps if the config in the yaml file is not node specific but compute service specific | |
| 14:00:46 | sean-k-mooney | apparently so | |
| 14:01:11 | sean-k-mooney | too bad they didnt update there commit email or username | |
| 14:01:21 | dansmith | gibi: specific to all the nodes managed by that compute, but you have a good point: | |
| 14:01:46 | gibi | but _all_ node changes so it is not well defined | |
| 14:01:49 | dansmith | gibi: some people with different ironic node types would want to have a different selector but still apply one definition to multiple things | |
| 14:01:54 | efried | gibi: Yes. Or if you know you want all of your ironic nodes in your deployment to have some common characteristic, like a trait. You could effect that by deploying one section with $COMPUTE_NODE to each host instead of all N to each compute host. | |
| 14:02:35 | dansmith | the identification section presumably offers us the ability to identify nodes by means other than $COMPUTE_NODE or uuid, | |
| 14:02:54 | efried | dansmith: as of PS13 it allows you to identify by name | |
| 14:03:13 | efried | earlier revs had a whole panoply of identification mechanisms, but we trimmed it down to the bare bones. | |
| 14:03:13 | dansmith | so that we can say things like "any node managed by this service with inventory of CUSTOM_IRONIC_GOLD would be matched | |
| 14:03:14 | dansmith | efried: name isn't super helpful in this case, but ... yeah | |
| 14:03:29 | dansmith | and that's good for early revs I think | |
| 14:03:46 | gibi | OK, I think I see the use case of the templating now. | |
| 14:03:47 | efried | but yes, you make a good case for future expansion of the identification section. | |
| 14:03:54 | dansmith | I'm saying that's a good reason for having identification be a section and not a key | |
| 14:03:55 | dansmith | right | |
| 14:04:30 | gibi | we might need a warning for ironic admins about using the yaml for node specific config | |
| 14:04:44 | dansmith | like I said, a ..note: somewhere for sure | |
| 14:04:49 | gibi | OK | |