| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-05-20 | |||
| 14:16:46 | mordred | yeah - I mean, the testing of that combo is covered sdk side (it's just the natural behavior) ... BUT - I agree, making sure semantically we're testing that it makes sense in the nova context might get fun | |
| 14:17:04 | efried | I would like to be able to KISS. But I'm not sure if we can do that without removing capabilities. | |
| 14:17:09 | mordred | we could also just make a rule that you can't mix the two | |
| 14:17:39 | efried | so, you're not allowed to have [openstack]cloud=$str *and* [section]$ksa_opts | |
| 14:17:40 | mordred | like, if you list a default cloud, or a cloud entry for a service - you cannot also specify parameters directly in the nova.ini | |
| 14:17:42 | mordred | yeah | |
| 14:17:59 | efried | but you *can* have [openstack]cloud=$str and [section]cloud=$other_str | |
| 14:18:02 | mordred | yes | |
| 14:18:16 | efried | we still need a way to detect $ksa_opts are present | |
| 14:18:29 | efried | or just say that's unsupported and ignore them when cloud is specified. | |
| 14:18:36 | efried | yeah, that ^ | |
| 14:18:41 | mordred | yeah. | |
| 14:18:46 | efried | okay, this works. | |
| 14:19:06 | mordred | well - or we can detect that in the sdk method and throw an error/warning if we detect both | |
| 14:19:41 | mordred | *waves hands* | |
| 14:19:48 | efried | I was thinking I'd be taking different code paths into init'ing the Connection depending on whether 'cloud' is present' | |
| 14:20:04 | efried | one uses your new 'get oslo.config opts' method. The other just looks at clouds.yaml | |
| 14:20:07 | efried | they don't meet. | |
| 14:20:43 | mordred | ah. I mean - you could totally do that - but since the default cloud entry is also coming from oslo.config - if we put it in the sdk get_oslo_config method, then it would be really easy for other folks to adopt to | |
| 14:20:46 | mordred | but I'm fine either way | |
| 14:20:58 | efried | oh, I see. | |
| 14:21:23 | mordred | mostly thinking it woud be good if heat and similar folks adopt the same system and the deployer semantics are all the same | |
| 14:21:49 | efried | yeah, that makes sense to me. | |
| 14:22:08 | efried | we'll need a config gen entrypoint | |
| 14:22:42 | mordred | ooh! hey - what if we made a get_oslo_options method in sdk that | |
| 14:22:50 | mordred | gah | |
| 14:23:08 | mordred | that does get | |
| 14:23:18 | mordred | my god. what is happening to my IRC client. | |
| 14:23:31 | efried | I thought it was a magnetic <Enter> key | |
| 14:24:13 | mordred | anyway - that does the get_{auth,session,adapter}_config_opts - and also adds the [openstack]cloud and [service]cloud options - and takes a list of service-type to determine which services it should do the ksa opts loading for | |
| 14:24:30 | mordred | is that too one-stop-shop? | |
| 14:24:40 | efried | IMO yes | |
| 14:24:43 | mordred | kk | |
| 14:24:55 | efried | though... | |
| 14:24:55 | mordred | we can always add one later if we fine we're copy-pasta across services :) | |
| 14:25:05 | efried | well, yes, which is really what we have today. | |
| 14:25:51 | efried | I think it might be too complex anyway, considering we'll also have to have a flag to say "use auth from here or not" | |
| 14:30:22 | efried | I'm actually a little worried that operators will be worried that, if their clouds.yaml section contains auth, we'll use that auth instead of user token. But I guess we have that issue today with neutron anyway. | |
| 14:30:54 | efried | another wrinkle is service_auth. When we use a user token, we wrap it in a service auth token. We could conceivably get that service auth from clouds.yaml too... | |
| 14:32:53 | efried | You guys don't really use specs in sdk yet? | |
| 14:32:53 | efried | I'll have to sort out which bits will be on the sdk side and which bits on the nova side. | |
| 14:32:53 | efried | Well, I was hoping to be able to avoid writing a spec, but the text in https://blueprints.launchpad.net/nova/+spec/openstacksdk-in-nova is already long enough, and I'm going to need to explain what we've just talked about, so... I guess a spec is on the way. | |
| 14:33:18 | mordred | no - not really enough people to warrant it | |
| 14:33:19 | dtantsur | we're using design-in-production approach | |
| 14:33:23 | mordred | yeah | |
| 14:33:44 | mordred | but - I think we'd be happy for design of this to happen in the nova spec and treat the sdk parts of it as an sdk spec :) | |
| 14:34:44 | efried | okay, that wfm. I'll just have to put big notes for nova people to not stress about those sections :) | |
| 14:35:04 | mordred | ++ | |
| 14:35:15 | mordred | just a big note telling them to not stress in general | |
| 14:35:26 | efried | Put that on the front page of the docs. | |
| 14:35:28 | efried | DON'T PANIC | |
| 14:35:33 | efried | someone famous said that already | |
| 14:36:07 | efried | Thanks for the talk, mordred. I'll add y'all to that spec when it exists. o/ | |
| 14:36:20 | mordred | ++ ... we should maybe make sure to point out in nova operator docs that they can have a clouds.yaml and a secure.yaml too | |
| 14:36:33 | efried | o_0 | |
| 14:36:37 | efried | what's secure.yaml? | |
| 14:36:38 | mordred | so that if they want to put passwords in a more restricted file, they acn | |
| 14:36:50 | mordred | (people get twitchy about passwords) | |
| 14:37:54 | efried | I would think the nova docs would just point to the sdk docs | |
| 14:38:08 | mordred | efried: https://docs.openstack.org/openstacksdk/latest/user/config/configuration.html#splitting-secrets | |
| 14:38:17 | mordred | efried: good call | |
| 14:39:10 | efried | so why have a separate file? Would it have like different perms or something? | |
| 14:39:47 | mordred | yeah - or maybe to make config mgmt easier - just put the clouds.yaml directly in git, and then have a secure.yaml that's templated/written out ... | |
| 14:39:47 | efried | one of my colleagues actually brought up the idea of being able to encrypt the file with the passwords in it. | |
| 14:39:56 | efried | mm | |
| 14:40:00 | mordred | also might make things nicer for people using k8s - you can put the secure.yaml in a k8s secret | |
| 14:40:16 | efried | there's a mechanism to use certificates rather than passwords, right? | |
| 14:40:42 | mordred | I think? | |
| 14:40:42 | efried | oh, yeah, next section down. | |
| 14:40:44 | mordred | yeah | |
| 14:41:14 | mordred | so that's probably a better way to deal with service-to-service secrets | |
| 14:41:33 | mordred | many many options :) | |
| 14:42:03 | efried | shrug, up to the operator. Point is, all of the option availability and documentation is owned by sdk, single point of code & reference, which makes nova's life easier. | |
| 14:43:11 | efried | btw, staging-wise, I'm thinking nova's stage 1 is zero operator changes, just keep using ksa opts and we'll feed them to sdk under the covers (via your wip patch); and we can transition to clouds.yaml later on. | |
| 14:43:43 | efried | Probably when we've done away with all the clients | |
| 14:44:28 | efried | I would have to think through what it would mean to set up the Connection just to get the endpoint to pass to the client. Whether having clouds.yaml in the mix would even be possible in that scenario. | |
| 14:44:41 | efried | I guess I don't see why not. | |
| 14:45:48 | efried | okay, speculation has reached point of diminishing returns. I'll go off and try to crystallize this. Thanks again. | |
| 14:52:21 | mordred | efried: \o/ ... crystalization | |
| 18:16:37 | dustinc | 👍 | |
| 19:05:46 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: Remove deprecated volume commands and args https://review.opendev.org/612751 | |
| 23:50:32 | openstackgerrit | Dean Troyer proposed openstack/osc-lib master: Add FakeModule from OSC https://review.opendev.org/660230 | |
| #openstack-sdks - 2019-05-21 | |||
| 01:21:23 | openstackgerrit | Merged openstack/api-sig master: Update liaison for keystone https://review.opendev.org/659613 | |
| 07:16:39 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: WIP rework statistics reporting https://review.opendev.org/659841 | |
| 10:23:08 | ITD27M01 | gtema: Hope you have a fruitfull day! I have a question about this: https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/cloud/_dns.py#L169 | |
| 10:24:29 | ITD27M01 | gtema: If I understand this correctly there is no pagination logic and only one page will be returned regardless of recordsets in designate ? | |
| 10:25:56 | gtema | well, cloud/_dns is quite an old implementation | |
| 10:26:19 | gtema | so it really depends on the designate how it will treat absense of limit | |
| 10:26:38 | ITD27M01 | gtema: The default is 20 recordsets per page :( | |
| 10:28:02 | gtema | hmm, than yeah, something might be lost | |
| 10:29:48 | gtema | it would be a bug in Designate thou | |
| 10:30:31 | gtema | basically the cloud/_dns should be switched to use proxy | |
| 10:31:44 | gtema | ITD27M01: what I mean is that sometimes I have seen bugs, that services might return only i.e. default 20 results if `limit` is not passed | |
| 10:32:15 | gtema | this would be clearly a bug. If that is not the case - list_recordsets will return all results in one page | |
| 10:38:56 | ITD27M01 | gtema: We found a problem through ansible. The cloud.list_recordsets returns only one page. | |
| 10:39:53 | ITD27M01 | gtema: And there no way to specify the limit. We have increased the limit on server side from 20 to more. | |
| 10:40:31 | gtema | ok, than basically sdk use dns proxy in the cloud layer should resolve the situation | |
| 10:42:03 | ITD27M01 | gtema: Ok, Can you please explain me the logic of the "proxy" in sdk, I have heard from you many times, but did not understand. | |
| 10:43:53 | gtema | see example in https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/cloud/_image.py#L75 | |
| 10:44:30 | gtema | cloud/_dns.py:list_recordsets should use self.dns.recordsets function instead of doing request itself | |