| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-03-28 | |||
| 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 | |
| 15:57:30 | mordred | yeah | |
| 15:57:36 | mordred | very much so | |
| 16:07:45 | brtknr | mordred: please ship the updated version... just thought that the check should only be made if there a tag specified at all | |
| 16:11:57 | brtknr | gtema: to be fair, only 50 of 1664 open PRs are openstack related :P | |
| 16:12:42 | gtema | yes, but they are very long pending | |
| 16:12:57 | gtema | some of them are even mine | |
| 16:18:17 | brtknr | gtema: yes I was just looking at os_server_tags.. which another person also appears to have implemented... i wonder how many are dupes | |
| 16:18:36 | gtema | that's why we need to clean things up | |
| 16:18:56 | brtknr | gtema: what happens after shipit tag is applied? | |
| 16:18:58 | gtema | I would need to reimplement os_server_tags to support currently implemented SDK bindings | |
| 16:19:07 | gtema | there should be 2 shipits | |
| 16:19:20 | brtknr | gtema: oh okay | |
| 16:19:26 | gtema | and then it is automatically merged. But only special guys can apply shipit | |
| 16:20:29 | brtknr | gtema: gtema ok cool | |
| 17:10:08 | larsks | Whinge of the day: I wish that the output of the get_* functions in openstacksdk could be used as input to the set_* functions. I'm trying to migrate quotas between two environments, and I wish I could simply new.set_compute_quotas(old.get_compute_quotas()), but of course that doesn't work. | |
| 17:26:12 | dtroyer | larsks: ++ I've wanted to do that in some cases with OSC, the REST APIs themselves do not always work that way | |
| 17:42:36 | dtruong | mordred Can we get https://review.openstack.org/#/c/648334/ merged and then get a new openstacksdk release? | |