| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-06-18 | |||
| 18:06:22 | mordred | efried: isn't there docs somewhere about the ksa conf options | |
| 18:06:24 | mordred | ? | |
| 18:06:52 | efried | ... | |
| 18:07:32 | mordred | efried: like - now that you can configure session adapter stuff via service-types-authority names and the ksa options ... do we have docs about that in the nova docs? | |
| 18:08:00 | efried | I think I understand the question, I'm just trying to swap that back in from tape. | |
| 18:09:00 | efried | mordred: https://docs.openstack.org/nova/latest/configuration/config.html | |
| 18:09:21 | efried | If you search for e.g. `cafile` you'll find an entry for each $service that uses ksa. | |
| 18:09:51 | efried | six entries for `endpoint_override` | |
| 18:09:51 | mordred | efried: ah - oh, that's probably generated from ksa by sphinx | |
| 18:09:58 | efried | exactly | |
| 18:10:00 | mordred | so a git grep wasn't finding it - that makes sense | |
| 18:10:02 | mordred | efried: thanks! | |
| 18:10:04 | efried | yw | |
| 18:10:39 | efried | not sure about 'sphinx', but generated by doc build, yes. | |
| 18:11:31 | efried | ...and I think it comes in by virtue of the `list_opts()` methods in conf/*, e.g. https://github.com/openstack/nova/blob/master/nova/conf/glance.py#L173 | |
| 18:11:49 | efried | ...which as you can see uses ksa's methods for generating those | |
| 18:13:07 | mordred | efried: yah. \o/ yay | |
| 18:19:34 | sangeet | ten thousand thansk modred .. it worked. I am so exicted. QQ Do I need to put it under idenity also or neutron, glance and placement is enough? | |
| 18:19:53 | sangeet | Sorry *mordred ^^ | |
| 18:21:12 | sean-k-mooney | mordred: i was expecting to find it here https://docs.openstack.org/nova/latest/admin/security.html | |
| 18:21:37 | sean-k-mooney | mordred: although the install guide would make sense | |
| 18:22:15 | sean-k-mooney | efried: mordred i dont think the config guide is really helpful in this case | |
| 18:22:47 | sean-k-mooney | that is where i started but i did not find it mainly because i was looking for ca_ | |
| 18:22:55 | sean-k-mooney | but it was not obvious | |
| 18:23:25 | efried | I don't think we should describe the optinos in depth in the security guide, but it would be sane to refer to the config docs from there. | |
| 18:24:42 | sean-k-mooney | yep that is what i was thinking too altough i think having a secting in the install guide would make sense | |
| 18:24:49 | sean-k-mooney | e.g. how to isntall with tls? | |
| 18:27:07 | sangeet | I agree .. that would be an excellent idea | |
| 18:28:56 | mordred | sangeet: you'll likely need to put it in for each service you're using | |
| 18:29:24 | mordred | sangeet: so - yeah - I'd do identity I think | |
| 18:38:41 | sangeet | Thank you mordred | |
| 19:12:44 | sangeet | mordred .. oops now my nova-conductor is not liking it when I try to create a server. I have set cafiles as we discussed above. "OSError: Could not find a suitable TLS CA certificate bundle, invalid path: /etc/nova/certs/ca.crt" | |
| 19:13:21 | sangeet | It seems conductor is expecting the CA file to be at some other location | |
| 19:17:38 | mordred | sangeet: are those on the same machine? | |
| 19:17:50 | sangeet | differnt pods | |
| 19:18:06 | sangeet | the file exist | |
| 19:18:45 | mordred | hrm. I'm not sure about that one - maybe someone else will know | |
| 19:19:34 | sangeet | sean-k-mooney efried .. please help ^^ | |
| 19:20:31 | efried | I'm no expert here, so this is just a guess: | |
| 19:20:49 | efried | If you put this in [identity], it means all the nova services will try to use it when talking to keystone. | |
| 19:20:50 | sangeet | I am up for trying anything | |
| 19:21:05 | efried | So you need it on every node that's running any nova service (conductor, compute, scheduler, whatever) | |
| 19:21:15 | efried | it == the crt fil. | |
| 19:21:16 | efried | file | |
| 19:21:41 | sangeet | so put cafile=/etc/nova/certs/ca.crt under identity | |
| 19:21:53 | efried | eh? I thought that's what you did, and it didn't work | |
| 19:22:00 | efried | Let's back up. | |
| 19:22:06 | efried | What change did you make that's leading to this error? | |
| 19:22:07 | sangeet | I ut it in compute and not in conductore | |
| 19:22:30 | sangeet | Let me try to put it under identity also | |
| 19:22:39 | efried | waitwait | |
| 19:22:52 | efried | I haven't been following this conversation, so I don't want to lead you down a rabbit hole. | |
| 19:22:59 | efried | What exactly have you changed so far? | |
| 19:25:52 | sangeet | I have Keystone deployed with SSL. In my nova.conf I set cafile=/etc/nova/certs/ca.crt for [neutron], [glance], [keystone_authtoken], [placement] | |
| 19:26:53 | efried | Hm, okay, I'm not sure about [keystone_authtoken] -- that's to set up the server side of the keystone service. | |
| 19:27:29 | efried | But nova talks to some of those services from multiple places -- conductor, scheduler, compute. | |
| 19:27:40 | efried | I don't remember offhand which ones talk to which ones from where. | |
| 19:29:09 | efried | Also note that conductor and compute use different config files by default (unless that's changed, or unless you're on an old release), so if you're running both, you'll want to set up both files. | |
| 19:29:46 | efried | But honestly, beyond that, I'm really out of my depth. sean-k-mooney would probably be a better resource. He is EU, so maybe try again "tomorrow". | |
| 19:30:22 | sangeet | I am using stein and I do have different configs as they are running on a different pods | |
| 19:31:44 | sean-k-mooney | efried: is that a hint i should go get dinner because it should be just cooked :) | |
| 19:32:12 | efried | sean-k-mooney: yes, you should not be working right now. | |
| 19:32:52 | efried | sangeet: TL;DR: I suspect you need the crt file available/accessible on the same file system as the nova.conf file you're editing. | |
| 19:33:03 | efried | same file system in the same container etc. | |
| 19:33:13 | sean-k-mooney | efried: hehe if i had started at 11 like i normally do i would argue but since i started at 8am today, night all o/ | |
| 19:33:32 | efried | But I'm also really not sure what mucking with [keystone_authtoken] did for you. | |
| 20:08:25 | sangeet | efried .. yes cafile needed to be set in identity section on conductor. It works now. | |
| 20:08:36 | efried | \o/ | |
| 20:09:05 | efried | Not to confuse things, but is it possible it's *only* required in [identity]? | |
| 20:10:13 | efried | I don't know whether/where we talk to keystone as an actual client; we may just be using it to set up the connection to the other services. But... I really don't know how that all works. | |
| 20:17:34 | mordred | efried: yeah - I'm gonna try to do an audit through of that | |
| 20:17:47 | efried | cool | |
| 20:17:49 | mordred | efried: cause right now I think it's ... well, if you don't know and I don't know - then likely nobody knows | |
| 20:18:11 | efried | lbragstad might :P | |
| 20:18:26 | efried | or cmurphy. Or other people who are no longer stacking. | |
| 20:24:13 | lbragstad | i actually didn't realize nova had an identity section *and* a keystone_authtoken section | |
| 20:24:58 | efried | IIUC, the former is for talking to keystone as a client, and the latter is for setting nova up as a server. | |
| 20:24:59 | lbragstad | (the keystone_authtoken section comes from keystonemiddleware) | |
| 20:25:50 | efried | tbh, I'm not sure where we're actually using the former from nova. But we must be, or sangeet's change wouldn't have fixed the problem... | |
| 20:27:08 | lbragstad | yeah - iirc (and i'm probably dated here) [keystone_authtoken] is only invoked by keystonemiddleware to fetch information about tokens out of keystone | |
| 20:31:24 | lbragstad | ahh - it looks like the [identity] section is used to validate project IDs | |
| 20:31:39 | efried | "used" -- by nova? | |
| 20:32:07 | efried | or by, like, everyone who has one? | |
| 20:32:20 | lbragstad | https://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/identity.py | |
| 20:33:18 | efried | Interesting. | |
| 20:33:35 | lbragstad | maybe? i might not be following this properly | |
| 20:34:35 | lbragstad | i think this is what i was looking at https://docs.openstack.org/nova/latest/configuration/config.html#keystone | |
| 20:34:37 | efried | Oh, that's for sure a place where we're using the [identity] section to create a ksa adapter that talks as a client to the keystone service's API. | |
| 20:35:07 | lbragstad | https://docs.openstack.org/nova/latest/configuration/config.html#keystone-authtoken is the keystonemiddleware section | |
| 20:35:11 | efried | Yeah, some layer of this translates $service_name to $project_name or vice versa | |
| 20:35:12 | efried | yes. | |
| 20:35:54 | lbragstad | i don't actually see an [identity] section | |
| 20:35:58 | lbragstad | in the configuration reference | |
| 20:36:06 | lbragstad | i see [keystone] and [keystone_authtoken] | |
| 20:36:19 | efried | I believe you're allowed to use either [identity] or [keystone] for anything we load up via get_{sdk|ksa}_adapter. | |
| 20:36:36 | efried | I mean, [$service] or [$project] | |
| 20:36:37 | lbragstad | oh - so service types and service names are interchangable? | |
| 20:36:48 | lbragstad | interchangeable* | |
| 20:36:54 | efried | only if we're using get_{sdk|ksa}_adapter. | |
| 20:37:02 | efried | Which I think we are for everything except cinder at this point. | |