Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-06-18
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
16:25:42 sean-k-mooney sangeet: right but thats becasue you have not added the private ca to the operating systsms cert store
16:27:29 sean-k-mooney you should be adding the ca cert in /usr/local/share/ca-certificates/ and then do sudo update-ca-certificates
17:50:22 sangeet sean-k-mooney .. sorry had to run for an appointment. Should the cert be in /usr/local/share/ca-certificates/ or /var/lib/openstack/lib/python3.6/site-packages/certifi/cacert.pem? certifi.where() shows later. Also name "ca.crt" is the correct name?
17:53:57 mordred do we not expose the keystoneauth session ssl options?
17:54:27 sean-k-mooney mordred: maybe but that would be documented in keystoneauth
17:54:32 sean-k-mooney not nova
17:54:53 sean-k-mooney sangeet: it should be in /usr/local/share/ca-certificates/
17:55:19 sean-k-mooney since they are your own addtional CA certs not one packaged by the distro
17:55:32 mordred sean-k-mooney: that won't necessarily work
17:55:45 mordred sean-k-mooney: python requests bundles a CA bundle and doesn;t' use system cas
17:55:49 mordred because MONKEYS
17:56:01 sean-k-mooney ...
17:56:07 mordred don't even get me started
17:56:35 sean-k-mooney ok so do we have docs for how to configure keystone with tls somehwere
17:56:40 mordred which is why it's important to be able to pass a path to a CA in config - I believe nova is doing a register_conf_options from ksa - so it should be possible to pass cafile in nova.conf ...
17:56:43 sean-k-mooney its not in the nova security docs
17:56:56 mordred well - that might be a bug - but let me see what I can find
17:57:00 sean-k-mooney mordred: ya i think we do
17:57:26 sean-k-mooney i guess it could be in the install docs i just did a google search and didnt find them
17:57:45 mordred register_ksa_opts
17:58:15 mordred that's in nova/conf/utils - and calls ks_loading.register_session_conf_options - which will register an option "cafile"
18:01:01 mordred it's going to be per-service - so I think it would be [identity]cafile=/etc/nova/certs/ca.crt - but really it would be best to put it in [networking]cafile= and [image]cafile and [placement]cafile= too ...

Earlier   Later