| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2020-11-19 | |||
| 14:20:52 | gtema | I guess once the SDK part lands they can start consuming it to hopefully generally reduce efforts | |
| 14:21:16 | gouthamr | +1 | |
| 14:21:36 | gouthamr | great, my update is that we're working with a few new university contributors to submit the openstacksdk bits | |
| 14:21:37 | gtema | I see manila is really evolving on the API part | |
| 14:21:58 | gouthamr | hopefully, i'll have them here in the next meeting :) | |
| 14:22:00 | gtema | are there lots of changes planned for this cycle? | |
| 14:22:53 | gouthamr | gtema: yes, we do hope to finish the openstacksdk by X, so much of the user facing resources you see in https://review.opendev.org/#/c/638782/ are planned for wallaby | |
| 14:23:22 | gtema | I mean on manila itself | |
| 14:23:41 | gtema | when the change was initially started I know it was pretty close to cover all APIs | |
| 14:23:47 | gouthamr | i don't anticipate changes in manila, wdym? | |
| 14:23:51 | gtema | but since then lots of new APIs were added | |
| 14:23:56 | gouthamr | oh | |
| 14:24:09 | gtema | okay, I thought you might be knowing | |
| 14:24:11 | gouthamr | that'll not stop happening though :) | |
| 14:24:36 | gtema | okay then | |
| 14:24:39 | gtema | moving on | |
| 14:24:41 | amotoki | do we need functional test coverage in SDK in addition to unit test? it can be the next step though. | |
| 14:25:16 | gtema | I think better to add those as well, but no objections of doing this in a follow-up | |
| 14:25:24 | stephenfin | if we're doing functional tests, we need to think about how we do so | |
| 14:25:31 | gtema | tests are taking sometimes 70% of the change itself | |
| 14:25:31 | stephenfin | the functional tests in OSC are _very_ racy | |
| 14:25:52 | gtema | that's absolutely correct stephenfin | |
| 14:26:06 | gtema | mostly those racy tests are coming from nova ;-) | |
| 14:26:16 | stephenfin | unfortunately so :( | |
| 14:26:43 | gtema | for sure we would need to start using more projects not to really corrupt things | |
| 14:26:55 | stephenfin | yup | |
| 14:27:11 | stephenfin | work for the future though, once we've more gaps closed | |
| 14:27:37 | gtema | oki | |
| 14:27:45 | gouthamr | i had a couple of other questions | |
| 14:27:51 | gouthamr | and gtema answered one of them in the etherpad | |
| 14:28:18 | gtema | the remaining is about tracking, right? | |
| 14:28:27 | gouthamr | does openstacksdk work need a spec? we intend to write one to plan our work | |
| 14:28:42 | gtema | we do not use specs currenlty | |
| 14:28:45 | gouthamr | ah | |
| 14:28:57 | gtema | I do not know whether those were ever used in SDK/OSC | |
| 14:29:21 | amotoki | I don't think we need a spec. what we need is just to be aware of the effort as impls would be straight-forward. | |
| 14:29:37 | gtema | correct | |
| 14:29:57 | amotoki | this kind of meetings would really help it :) | |
| 14:30:06 | gtema | something like spec might be required for the discussion we had with stephenfin yesterday | |
| 14:30:17 | gouthamr | ack - thanks; i'll not bother you with it then; the spec was more for project planning and some designing - if we write one, we'll keep it in manila-specs | |
| 14:30:19 | gtema | about what is better in OSC | |
| 14:30:40 | gtema | 'openstack aggregate cache image __aggregate__ __image1__ __image2__ ...' | |
| 14:30:42 | gouthamr | (we did write a spec for our osc work too - we can argue endlessly about subcommand naming) :D | |
| 14:31:01 | gtema | or 'openstack aggregate cache image __aggregate__ --image __image1__ --image __image2__ ...' | |
| 14:31:17 | gouthamr | (^ and things like that) | |
| 14:31:24 | gtema | there are 2 types currently used in different areas | |
| 14:31:43 | gtema | and we might need to agree what is the standard | |
| 14:31:46 | stephenfin | yes, this is a place where we're missing a BDFL (Benevolent Dictator For Life) to settle things for us | |
| 14:32:03 | stephenfin | In the absence of dtroyer, we should probably put together a style guide? | |
| 14:32:08 | gtema | hehe, I am not the one - tell you right now | |
| 14:32:22 | amotoki | it is a topic on how our CLI command should be composed. i think it can be discussed as a document change proposal in OSC | |
| 14:32:30 | stephenfin | Nonsense. All hail, gtema | |
| 14:32:31 | stephenfin | :P | |
| 14:32:47 | stephenfin | amotoki++ yeah, I think this would be a great addition to the docs | |
| 14:32:52 | gtema | amotoki - right. We should start perhaps one | |
| 14:33:09 | stephenfin | s/do // | |
| 14:33:23 | stephenfin | and then we can debate it on Gerrit | |
| 14:33:29 | diablo_rojo | I look forward to reviewing :) | |
| 14:33:30 | gtema | #action - start a style guide for osc | |
| 14:33:32 | amotoki | :) | |
| 14:34:13 | gouthamr | #link https://docs.openstack.org/python-openstackclient/latest/contributor/humaninterfaceguide.html | |
| 14:34:19 | gouthamr | ^ this one already exists, though | |
| 14:34:37 | gtema | right | |
| 14:34:47 | gtema | I new I was seeing this once, but completely forgot | |
| 14:34:55 | gouthamr | and specifically: https://docs.openstack.org/python-openstackclient/latest/contributor/command-options.html | |
| 14:35:55 | gtema | great, might need some extension | |
| 14:36:09 | amotoki | they are good starts. If there are something not covered, we can cover more cases. | |
| 14:36:17 | stephenfin | yes, good call. I didn't know that existed | |
| 14:36:31 | gouthamr | sometimes patterns there don't make sense in all situations; an optional parameter is really required: https://docs.openstack.org/python-openstackclient/latest/contributor/command-options.html#required-options | |
| 14:36:42 | gouthamr | "required options" :D | |
| 14:37:04 | stephenfin | bit on an oxymoron, yes /o\ | |
| 14:37:49 | gtema | okay, moving next | |
| 14:37:56 | gtema | #topic Status OSC to use SDK for nova part | |
| 14:38:18 | gtema | I think we are progressing with stephenfin quite good on that | |
| 14:38:38 | gtema | of course there is still lot to cover | |
| 14:39:01 | gtema | I am explicitly afraid of starting changing 'server' operations - that would be a challenge | |
| 14:39:32 | gtema | stephenfin, do you know whether this cycle we get something new from nova? | |
| 14:40:08 | stephenfin | it shouldn't be _too_ bad - most server actions are implemented by POSTing a simply JSON body to the server actions API | |
| 14:40:29 | stephenfin | gtema: There were no API changes in Victoria. There are only minor changes (to the os-hypervisors API) planned for Wallaby so far | |
| 14:40:38 | gtema | yes, it is always _easy_, until you start working on it | |
| 14:40:44 | stephenfin | True :) | |
| 14:40:46 | gtema | oh, changes in hypervisor? | |
| 14:40:57 | gtema | just working on switching it | |
| 14:41:06 | stephenfin | Yes, but I'm doing that so I'll handle the SDK changes when I do it | |
| 14:41:23 | gtema | with few cool things: until 2.53 you use 1 API to search, after - another | |
| 14:41:43 | stephenfin | oh, there's also a spec proposed to remove the final references to 'tenant_id' from the API, in favour of 'project_id'. It's not approved yet but it will be I suspect | |
| 14:41:50 | gtema | and then https://opendev.org/openstack/python-openstackclient/src/branch/master/openstackclient/compute/v2/hypervisor.py#L124 | |
| 14:42:09 | stephenfin | yeah, there's been a lot of that /o\ | |
| 14:42:12 | gtema | I guess tenant_id/project_id is not a big deal at all | |
| 14:42:45 | gtema | wrt this mentioned renaming I am currently thinking to return DictColumn instead of this renaming | |
| 14:43:10 | gtema | I do not think it is really useful to do this renaming, especially that it requires hacking | |
| 14:43:28 | gtema | what do you think? | |
| 14:43:36 | gtema | I agree this is a "breaking" change | |
| 14:44:04 | gtema | but we anyway plan to bump a major release after this rework is done | |
| 14:44:04 | stephenfin | no issues from me | |
| 14:44:15 | gtema | okay, great | |
| 14:44:17 | stephenfin | so long as we signal it with a major version bump, yes | |
| 14:44:28 | gtema | I hope OSC part will arrive today | |
| 14:44:53 | amotoki | from POV of consumers, it would be nice if both of project_id and tenant_id can be used transparently. | |
| 14:45:18 | gtema | I guess since very long time those are everywhere translated to project_id | |