| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-03-28 | |||
| 16:24:04 | elmiko | ricolin: looking at https://etherpad.openstack.org/p/community-goals i am really not feeling that our group's activity merit an entry there | |
| 16:24:26 | openstackgerrit | Merged openstack/openstacksdk master: Add image.service_info resources https://review.openstack.org/638227 | |
| 16:25:01 | elmiko | i feel like our community goal is "make sure everyone knows where the api guidelines are at and how to get help" does not seem to fit the same level of completion that the others have | |
| 16:25:41 | ricolin | elmiko, That's fine if we don't think any of API SIG goal match community goal (request #3) | |
| 16:26:55 | elmiko | ricolin: i will read through the "help most needed" list to see if we have an addition to propose | |
| 16:27:45 | elmiko | edleafe: you are going to reply with the info from item 1 ? | |
| 16:28:03 | edleafe | elmiko: typing it up as we speak | |
| 16:28:09 | elmiko | edleafe++ | |
| 16:30:53 | edleafe | Sent! | |
| 16:31:05 | edleafe | ...and we're only halfway through the office hour! :) | |
| 16:31:27 | elmiko | so productive! | |
| 16:31:30 | ricolin | edleafe, that's quick:) | |
| 16:32:12 | cdent | api-sig, can you guys help me automate translating the placement api to graphql or grpc? this http rest-like stuff is too old | |
| 16:32:17 | edleafe | Hey, we don't mess around!! | |
| 16:32:37 | cdent | or soap | |
| 16:32:49 | elmiko | whoo-boy, that's a big ask cdent | |
| 16:33:05 | mordred | cdent: grpc ftw | |
| 16:33:17 | elmiko | might i propose a binary socket with completely custom message types? have you considered that approach? | |
| 16:33:21 | cdent | I only want it if I can automate | |
| 16:33:25 | dustinc | so I have been working on moving Nova-Ironic interaction from using the ironicclient to using the SDK and have found a lot of funkiness in field mapping between client/SDK/API | |
| 16:33:28 | edleafe | cdent: first print it out onto punched cards... | |
| 16:33:44 | mordred | dustinc: you can blame me for a lot of that | |
| 16:34:01 | dustinc | good to know, but not here to lay blame :) | |
| 16:34:05 | mordred | dustinc: :) | |
| 16:34:10 | elmiko | cdent: i do have a project for arbritrary code generation from openapi specs | |
| 16:34:19 | dustinc | just hoping to get some insight on how best to solve this | |
| 16:34:56 | dustinc | http://paste.openstack.org/show/bKnExS60mZXtsBAFgSgJ/ | |
| 16:34:59 | dustinc | those are my notes | |
| 16:35:54 | elmiko | what are the issues you are having trouble with? | |
| 16:35:56 | dustinc | my main concern is that currently we pass kwargs off to the client with any keys we didn't pick up, which means that somewhere there may be existing code using the key names in client that would cause issues if we dropped in SDK without some sort of wrapper or something to fix the key names | |
| 16:36:14 | mordred | dustinc: for things where the sdk is missing something, it's easy - we should add the things that are missing | |
| 16:37:01 | dustinc | there are basically 2 or 3 things missing from SDK, but the issue I am seeing is the mismatched key names | |
| 16:37:05 | dustinc | *biggest | |
| 16:37:07 | mordred | for things where the names are different ... that's a bit trickier and we should probably think about the best way to handle it | |
| 16:37:10 | dtantsur | edleafe: sorry, has to run to the post office to fetch the lost delivery | |
| 16:37:14 | dustinc | https://www.irccloud.com/pastebin/M8AuozRG/ | |
| 16:37:26 | mordred | but basically dtantsur can solve all of the problems just by being magical | |
| 16:37:32 | elmiko | good luck dtantsur ! | |
| 16:38:31 | dustinc | I *could* just put use a map to convert them, but that's obviously not ideal | |
| 16:38:38 | dustinc | and really shouldn't make it through code review ;) | |
| 16:39:14 | mordred | yeah - it's a thing where I'd love to be able to capture things appropriately if it's a general problem | |
| 16:39:44 | dtantsur | Things like instance_id vs instance_uuid and maintanance vs is_maintenance are by design.. | |
| 16:39:51 | mordred | in general, the sdk already knows how to map the server-side names of things to the sdk property name (has to be able to do a bi-directional mapping to be able to deal with the server json) | |
| 16:39:52 | dustinc | are they? | |
| 16:39:56 | mordred | yes | |
| 16:40:31 | dtantsur | I mean, it sucks that ironic uses uuid where many services use id.. but it's a bit too late to change. | |
| 16:40:33 | dtantsur | "a bit" | |
| 16:40:48 | dtantsur | and SDK-level consistency is the very reason openstacksdk exists and we're migrating to it | |
| 16:40:52 | dustinc | ok that is good to know...I am pretty new to stack and didn't even realize those were different | |
| 16:40:57 | mordred | the sdk strives for consistent parameter names across the sdk vs. being consistent with the remote json names - so for instance booleans start with verbs - and then the ironic id vs. uuid thing | |
| 16:41:02 | mordred | yeah. what dtantsur said in less words | |
| 16:41:12 | dustinc | ok I see | |
| 16:41:21 | edleafe | dtantsur: you could be like nova that uses both a uuid and an id :) | |
| 16:41:46 | mordred | but - since I think the sdk already knows how to deal with remote server-side names, if you're dealing with **kwargs things we shold PROBABLY be able to figure out some way to have the sdk understand what you're wanting to do | |
| 16:41:52 | dtantsur | edleafe: does it? O_o | |
| 16:42:06 | mordred | edleafe: you're purposefully trying to hurt our brains :) | |
| 16:42:42 | edleafe | Unfortunately, that got carried into placement as well. :( | |
| 16:43:31 | dtantsur | \o/ | |
| 16:44:01 | mordred | dustinc: we may not be helping a ton here | |
| 16:45:30 | dtantsur | I'm not sure it really blocks the migration, but I do agree it can be confusing | |
| 17:00:44 | elmiko | catch ya later folks, have a good weekend =) | |
| 17:03:01 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Cleanup split of openstackcloud https://review.openstack.org/648435 | |
| 17:26:45 | openstackgerrit | Ian Y. Choi proposed openstack/openstacksdk master: DNM - Start building pdfs of docs https://review.openstack.org/601659 | |
| 17:54:15 | openstackgerrit | Merged openstack/openstacksdk master: Make PATCH a first class operation and support it for baremetal https://review.openstack.org/647730 | |
| 18:30:09 | elmiko | edleafe++ i like your response to the email | |
| 18:30:41 | edleafe | elmiko: well sure, because I spelled your nick correctly. :) | |
| 18:34:56 | elmiko | LOL | |
| 20:23:12 | dustinc | ubnt 8-port | |
| 20:23:41 | dustinc | love browser-base clients...sorry | |
| #openstack-sdks - 2019-03-29 | |||
| 05:35:32 | openstackgerrit | Ian Y. Choi proposed openstack/openstacksdk master: DNM - Start building pdfs of docs https://review.openstack.org/601659 | |
| 08:26:21 | ITD27M01 | mordred: If you have a second can you review a small change https://review.openstack.org/#/c/648117/ it is very important for us | |
| 09:07:42 | mordred | ITD27M01: wow, it's a field that takes a stringified-json? I suppose I shouldn't ask why it's not just actually a dict type in the mistral server-side | |
| 10:03:56 | ITD27M01 | mordred: Generally, I have no answer to this question. All attributes on mistral api side are strings. This also applies to input [1]. There comment about this from briancurtin [2] | |
| 10:04:04 | ITD27M01 | mordred: Special method to_dict() has created for convertation [3] | |
| 10:04:11 | ITD27M01 | mordred: [1] https://docs.openstack.org/mistral/latest/api/v2.html#executions | |
| 10:04:19 | ITD27M01 | mordred: [2] https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/workflow/v2/execution.py#L44 | |
| 10:04:26 | ITD27M01 | mordred: [3] https://github.com/openstack/mistral/blob/master/mistral/api/controllers/resource.py#L27 | |
| 10:29:23 | openstackgerrit | Merged openstack/openstacksdk master: Adds missing "params" attribute for creating a Mistral workflow execution https://review.openstack.org/648117 | |
| 14:36:04 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Allow replacing service implementation https://review.openstack.org/648704 | |
| 14:43:19 | brtknr | hello, how do i check openstacksdk version? | |
| 14:45:03 | brtknr | `python -m openstack version` is great but i'd like to get the value from code | |
| 14:49:47 | dtantsur | brtknr: maybe query pbr, like in https://github.com/openstack/ironic/blob/master/ironic/version.py#L16-L18 ? | |
| 14:49:51 | brtknr | wait, sdk.version.__version__ seems to cut it... is there a "proper" way? | |
| 14:56:09 | gtema | brtknr: print(openstack.version.__version__) works for me | |
| 14:56:37 | gtema | the only possible problem with it, that for openstacksdk==0.10.0 this does not work | |
| 14:56:47 | brtknr | gtema: works for me too! im just wondering if there is a proper way.. | |
| 14:56:54 | brtknr | or this is good enough | |
| 14:57:11 | gtema | well, this is good enough and used also in Ansible to detect sdk version | |
| 14:57:59 | gtema | if you look to openstack.version.py - you will see this is just a short-cut to a longer "proper" way | |
| 15:14:44 | brtknr | gtema: you're right :D | |
| 15:33:55 | brtknr | gtema: I cant find any examples where a comparison is made against openstacksdk version within Ansible openstack modules | |
| 15:34:22 | gtema | brtknr: https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/openstack.py#L121 | |
| 15:35:56 | brtknr | gtema: I decided to only look inside `ansible/lib/ansible/modules/cloud/openstack` | |
| 15:36:31 | gtema | happend | |
| 15:36:39 | gtema | s/happend/happens/ | |
| 15:52:37 | brtknr | Does this look okay: https://github.com/ansible/ansible/pull/53757 | |
| 15:55:07 | mordred | brtknr: yeah. that looks good on a quick look (conferencing today) - I assume the tags= parameter will just be silently ignored so we don't have to be fancy with avoiding sending it on earlier sdks? | |
| 15:55:56 | brtknr | Yes earlier sdks still accept tags, but do nothing | |
| 15:56:39 | mordred | cool - then yeah, that looks good to me | |
| 15:57:03 | gtema | oh mordred, we need to speed up clearing ansible PRs | |