| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-06-18 | |||
| 15:00:27 | artom | stephenfin, did the flavor extra spec validation spec ever go anywhere? | |
| 15:00:38 | stephenfin | artom: it landed last cycle | |
| 15:00:47 | stephenfin | API microversion 2.84, I think? | |
| 15:01:43 | artom | stephenfin, 2.86, but yeah, thanks for the pointer | |
| 15:01:56 | artom | So we could use that for the cpu_dedicated_mask, right? | |
| 15:02:08 | efried | Deprecate: https://review.opendev.org/#/c/692227/ (merged) | |
| 15:02:08 | efried | I don't see a patch (at least owned by me) proposing removing it. | |
| 15:02:09 | artom | Context is my latest comment on https://review.opendev.org/#/c/468203/15 | |
| 15:03:19 | efried | Comments in above patch contain ML links mordred | |
| 15:03:45 | efried | and also refers to some people who wanted to keep it. | |
| 15:04:04 | stephenfin | artom: fair comment. In the middle of something at the moment but I'll get a reply to it | |
| 15:04:30 | stephenfin | we can't rely on the validation though, mind you, since it's an API change | |
| 15:04:30 | artom | stephenfin, no rush. Today's my "upstream day", trying to do some reviews where I can :) | |
| 15:04:42 | stephenfin | *in an API microversion | |
| 15:07:55 | mordred | efried: ooh! so it is deprecated! | |
| 15:08:42 | mordred | efried: how many releases do we have to wait to remove a deprecated thing? can we remove that now in victoria? or do we have to wait until w? | |
| 15:09:25 | dansmith | mordred: should probably ask the ptl | |
| 15:10:15 | stephenfin | mordred: it's six months or one release, whatever is greater | |
| 15:10:29 | stephenfin | though that's obviously tempered by impact | |
| 15:10:35 | dansmith | I thought it was two releases for config options | |
| 15:10:49 | dansmith | you can't remove it in the N+1 release, but you can in the N+2, | |
| 15:10:59 | dansmith | else we'd break N->N+1 config compatibility | |
| 15:11:05 | mordred | gotcha. so we can remove in W | |
| 15:11:11 | mordred | but not today | |
| 15:12:16 | stephenfin | you deprecate in N, and remove in N+1 | |
| 15:12:45 | stephenfin | if you removed in N, you'd be breaking N-1 -> N compatibility | |
| 15:13:22 | stephenfin | that gives people the duration of N to get off $deprecatedthing | |
| 15:13:34 | dansmith | isn't N-1->N+1 the same thing I said, but with N->N+2? | |
| 15:14:45 | dansmith | oh, you're saying we deprecated it in U so people in U should know to get off of it so it can be gone in V? I guess technically that's right, but I really thought it was supposed to be two releases | |
| 15:15:03 | stephenfin | yes :) you had me confused there | |
| 15:15:19 | stephenfin | docs say the same https://docs.openstack.org/nova/latest/contributor/process#smooth-upgrades | |
| 15:15:25 | stephenfin | i.e. continue to support and test features for at least one release before they are removed | |
| 15:16:10 | sean-k-mooney | ya so 1 release is the miniume we usuall take 2-3 to remove it | |
| 15:16:16 | stephenfin | definitely not black and white | |
| 15:16:18 | sean-k-mooney | depeneing on how much of a pain it is | |
| 15:16:24 | stephenfin | sean-k-mooney: if we ever remove it :) | |
| 15:16:31 | dansmith | given it could break people's glance setup without warning, | |
| 15:16:34 | dansmith | I'd say it's pretty high impact | |
| 15:16:46 | stephenfin | "will be removed in a future release" <-- my boilerplate | |
| 15:16:52 | sean-k-mooney | we would need a nova-status check at a minium right | |
| 15:17:26 | stephenfin | I wouldn't say without warning, since we do have a big "this thing is deprecated" warning | |
| 15:17:27 | sean-k-mooney | also ooo would have to be modified proably | |
| 15:17:59 | dansmith | sean-k-mooney: for something like this, yeah I'd think so | |
| 15:18:00 | stephenfin | I guess it comes down to how difficult the migration is | |
| 15:18:14 | stephenfin | from $old_way to $new_way | |
| 15:18:30 | stephenfin | I don't know about that so I'll defer to others | |
| 15:25:37 | sean-k-mooney | old way is template a config option. new way is either add the service to a load blancer or deploy a new loadbalncer and add it to that | |
| 15:26:47 | sean-k-mooney | i think the only thing we use this for in ooo wa rabbitmq but i could be wrong about that | |
| 15:27:01 | sean-k-mooney | i think in ooo we go to glance vai haproxy | |
| 15:27:27 | sean-k-mooney | but in general people could have been using this for any of the api endpoint? | |
| 15:47:31 | gibi | nova weekly meeting will start in 12 minutes on #openstack-meeting-3 | |
| 15:49:04 | mordred | sean-k-mooney: well - we wouldnt' be removing this for rabbit | |
| 15:49:13 | mordred | sean-k-mooney: this is only about talkig to openstack api services | |
| 15:49:48 | mordred | it's possible we've not been properly clear about that | |
| 15:50:21 | sean-k-mooney | mordred: why would we remove it for one and not the other | |
| 15:50:34 | sean-k-mooney | its equally bad in both cases | |
| 15:50:48 | sean-k-mooney | or good depending on your view | |
| 15:50:49 | mordred | sean-k-mooney: "use services from the keystone catalog and via the normal api consumption channels" is the driver | |
| 15:51:14 | mordred | rabbit doesn't get configured via the catalog nor consumed using a standard set of connection information | |
| 15:53:38 | sean-k-mooney | mordred: have you tought about a keystone feature to allow the same behavior :P | |
| 15:54:30 | mordred | yes - it was _strongly_ opposed by the keystone team - becaues they did not want to build a bad load balancer | |
| 15:54:32 | sean-k-mooney | but ok if its the openstack services only im not sure if that changes the edge configuration | |
| 15:54:50 | mordred | yeah - and really, it's ONLY glance | |
| 15:54:59 | mordred | that's the only place this option exists | |
| 15:55:27 | mordred | so it's not even that there is a generalized mechanism for talking to api services with a list of endpoits in nova -- it's _just_ for glance | |
| 15:55:50 | mordred | and I'm pretty sure the reason it's special is that way back in the day glance wasn't considered user-facing, so why would you have it in your load balancer | |
| 15:56:40 | sean-k-mooney | well in the edge configurtion you want your edge site to use a local glance api | |
| 15:56:55 | sean-k-mooney | and leavge the glance multistore feature | |
| 15:57:21 | sean-k-mooney | now i dont know if that needs this | |
| 15:57:54 | sean-k-mooney | or can we configure the glance store seperatly and have multiple endpoints in keystone | |
| 15:58:15 | sean-k-mooney | but i feel like we would need the later? | |
| 15:59:07 | sean-k-mooney | you dont want just one endpoint as you would have to do anycast routing tricks if you wanted to hit the local api | |
| 16:10:27 | mordred | sean-k-mooney: well - for those you can totally still use endpoint override | |
| 16:10:55 | mordred | I think the thing is that in general for a consumer the idea is that an openstack service has "an endpoint" - and that concept is pretty baked in to many things | |
| 16:11:19 | mordred | but it's always possible for a consumer to override "the endpoint" that keystone tells it | |
| 16:11:48 | sean-k-mooney | isnt that what the config option is for | |
| 16:11:50 | mordred | if we wanted to do a thing like your second case - it's obviously possible - but it would really take a coordinated design and implementation in a few places | |
| 16:11:58 | sean-k-mooney | i know it can do the loadbalncing tooo | |
| 16:12:07 | mordred | no - the config option that we want to remove is for giving a _list_ of overrides | |
| 16:12:09 | openstackgerrit | Merged openstack/nova master: Remove hacking rules for python 2/3 compatibility https://review.opendev.org/733987 | |
| 16:12:25 | mordred | and that concept exists in one and only one place - inside of nova for overriding glance | |
| 16:12:47 | sean-k-mooney | right but do we have a way to locally override without that | |
| 16:12:52 | mordred | yes | |
| 16:12:53 | sean-k-mooney | for glance | |
| 16:12:55 | sean-k-mooney | ok | |
| 16:12:59 | mordred | that doesn't go away | |
| 16:13:14 | sean-k-mooney | right i just was not sure if we had two way for glance | |
| 16:13:20 | mordred | that just gets to use the normal mechanism and nova can remove a pile of special case code and we can go through and simplify several things | |
| 16:13:25 | sean-k-mooney | on that supports a list and another that is a single url | |
| 16:13:31 | mordred | yup. that's what you have currently | |
| 16:19:57 | sangeet | I have SSL enabled for keystone. My compute service fails to come up due to SSL 'certificate verify failed'. I am not sure if I am placing the certifcate at the correct place. Where should the certifciate go? I tried to palce it in /etc/nova/certs/ca.crt. it did not work. Then I set CA_CERTS, it still did not work. Any help will be highly apprecaited. I am running Stein | |
| 16:20:45 | sean-k-mooney | sangeet: you need to add it to the openerating systems certificat store | |
| 16:21:10 | sean-k-mooney | i dont think we support passing a ca directly to nova since now does not realy know anything about tls | |
| 16:21:55 | sangeet | nova-api is working fine for me. I placed the certs in /etc/nova/certs folder | |
| 16:22:46 | sean-k-mooney | is the api runnign on the host that generated teh cert | |
| 16:23:03 | sangeet | No | |
| 16:23:53 | sangeet | But I converted api to wsgi | |
| 16:23:55 | sean-k-mooney | the only ca config option i see are related to rabbitmq and we dont mention this in https://docs.openstack.org/nova/latest/admin/security.html | |
| 16:24:31 | sean-k-mooney | actully we have options for vendor data too | |
| 16:24:43 | sangeet | Issue is compuet is trying to get token from keystone and since keystone supports SSL it faile | |