| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-19 | |||
| 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 | |
| 14:05:01 | gibi | let me read PS13 through, but I think I'm +2 on the spec | |
| 14:05:06 | efried | Thanks gibi | |
| 14:10:35 | artom | dansmith, dunno if you saw efried's adding of yourself to https://review.opendev.org/#/c/671471/, could I pester you some more for it? | |
| 14:11:02 | gibi | efried: does changing 'ensure' to 'additional' keeps the intended behavior idepmotent? I mean if I restart a compute serivce it won't try to re-create the inventory if already exists | |
| 14:11:13 | dansmith | artom: I did not | |
| 14:11:46 | dansmith | gibi: it's still idempotent language to me | |
| 14:11:50 | efried | gibi: yes, it's just a bikeshed of the word being used. I think I explained the rationale in the comment on PS12 | |
| 14:12:14 | efried | gibi: it's more than just "restart a compute service" -- this thing runs on every periodic | |
| 14:12:15 | gibi | dansmith: I more after the behavior. if that is idepmontent then I'm happy | |
| 14:12:33 | gibi | efried: OK. then I'm happy :) | |
| 14:12:37 | dansmith | gibi: same behavior, more descriptive (IMHO) wording | |
| 14:12:43 | efried | It makes me happy to make you happy, gibi | |
| 14:13:08 | gibi | dansmith: OK. I accept the language change blindly as I'm not a native speakre | |
| 14:13:22 | dansmith | heh | |
| 14:13:36 | gibi | ... and try to learn in the process | |
| 14:13:47 | efried | don't try to learn too much from s/ensure/additional/ | |
| 14:13:52 | efried | that way lies madness | |
| 14:14:18 | dansmith | efried: stop mocking me | |
| 14:14:20 | efried | you can learn things about Dan, but not about English | |
| 14:14:23 | efried | jinx | |
| 14:14:43 | efried | kisses | |
| 14:14:44 | gibi | :) | |
| 14:19:49 | gibi | I'm +2 on the provider config spec | |
| 14:20:24 | gibi | and I guess it is good time to inform you that I will disappeare for two weeks of vacation starting in an hour | |
| 14:22:52 | efried | phew, then I'm glad I nabbed you for that +2. Have a great vacation gibi! | |
| 14:23:02 | gibi | efried: thanks! | |
| 14:28:46 | cdent | enjoy your time off gibi | |
| 14:28:59 | gibi | cdent: thanks | |
| 14:31:51 | dansmith | artom: you have to fix your many typos anyway, so I think you should move the code to a single check to LOG.warning on startup and then I'd be +2 if not for needing some diversity on it | |
| 14:32:16 | artom | dansmith, in _init_host? | |