| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-05-20 | |||
| 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 | |
| 10:45:36 | gtema | unfortunately I do not have today to fix this. But all of the functions in the cloud/_dns should use methods defined in openstack/dns/v2/_proxy.py instead of manual requests | |
| 10:45:55 | gtema | this is however also a "bigger" change with respect to adapting tests properly | |
| 10:51:10 | ITD27M01 | gtema: Ok, I will create bug request for it so we don't lose it. | |
| 10:52:24 | gtema | great | |
| 11:29:43 | brtknr | Hello | |
| 11:29:59 | brtknr | Whats the protocol for backporting changes in ansible | |
| 11:30:23 | brtknr | I have these two backports from dev branch to 2.8 and 2.7: https://github.com/ansible/ansible/pull/56708 https://github.com/ansible/ansible/pull/56709 | |
| 11:30:49 | gtema | brtknr: https://docs.ansible.com/ansible/latest/community/development_process.html | |
| 11:36:55 | brtknr | I have followed the protocol here: | |
| 11:36:57 | brtknr | https://github.com/ansible/ansible/pull/56710 | |
| 11:40:16 | brtknr | And here: https://github.com/ansible/ansible/pull/56711 | |
| 13:42:08 | mordred | gtema: I look forward to getting that "use proxy layer in cloud layer" project done | |
| 13:42:19 | mordred | having proper pagination support everywhere will be nice | |
| 13:42:39 | gtema | hehehe | |
| 13:42:50 | gtema | can be done soon | |
| 13:43:16 | gtema | would appreciate your thoughts on vendor_hook and rework of stat reporting | |
| 13:43:33 | gtema | and then can go for "use proxy" | |
| 13:43:34 | mordred | yes! they are on my review-today list | |
| 13:43:41 | gtema | great | |
| 15:04:45 | ITD27M01 | gtema: https://storyboard.openstack.org/#!/story/2005749 | |
| 15:06:10 | gtema | ITD27M01: taken. | |
| 15:06:17 | gtema | thanks | |
| 15:20:44 | ITD27M01 | gtema: I have also another proposal for you today. What do you think about filtering feature in Ansible openstack inventory plugin? | |
| 15:20:56 | ITD27M01 | gtema: https://github.com/ansible/ansible/pull/51401 | |
| 15:21:11 | ITD27M01 | thousands of instances. And a lot of users works with such a project. | |
| 15:21:11 | ITD27M01 | In some cases, the host patterns cannot help to split infrastructure into small pieces. For example when openstack project/tenant contains | |
| 15:21:33 | ITD27M01 | The aws inventory plugin is an example of such filtering: | |
| 15:21:43 | ITD27M01 | https://docs.ansible.com/ansible/latest/plugins/inventory/aws_ec2.html | |
| 15:21:47 | ITD27M01 | In the case of server-side filtering, we can get a significant performance gain. | |
| 17:28:40 | openstackgerrit | sean mooney proposed openstack/python-openstackclient master: add openstack server resurrect command https://review.opendev.org/643578 | |