| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-12-19 | |||
| 13:57:57 | stephenfin | Cool | |
| 13:58:08 | stephenfin | The main issue I saw when I started looking at this was that there weren't an clear patterns around for microversioned APIs | |
| 13:58:32 | gtema | I would say it should be considered case by case | |
| 13:58:37 | stephenfin | we use decorators in novaclient but there doesn't seem to be an equivalent pattern for sdk | |
| 13:59:16 | gtema | in the image there is nothing like that. In the tagging of servers there is some first brief example for that, but it doesn't really enforce those | |
| 13:59:39 | stephenfin | so it sounds like we need to invent one? :) | |
| 13:59:59 | stephenfin | that's what I was hoping to drag mordred in for | |
| 14:00:05 | gtema | not really invent support, but perhaps invent pattern how to use it properly | |
| 14:00:11 | stephenfin | yeah, exactly | |
| 14:00:27 | gtema | actually AFAIK in the ironic world this should have been used a lot already | |
| 14:00:33 | stephenfin | I mean, I could just copy-paste the patterns from novaclient, but those aren't necessarily going to align with how everyone else is doing it | |
| 14:00:54 | stephenfin | I looked at baremetal, yeah. Support seemed pretty barebones still, unfortunately :( | |
| 14:01:01 | gtema | in SDK we have option just to specify specific microversion on the request level | |
| 14:01:06 | stephenfin | and wasn't consistent | |
| 14:01:21 | gtema | so I would say let's look to concrete cases | |
| 14:02:56 | stephenfin | Something as simple as migrating this https://github.com/openstack/python-novaclient/blob/eb98178ea88c77881f7c763b068408f769956eb2/novaclient/v2/servers.py#L217-L234 | |
| 14:03:45 | stephenfin | as an examples of an API that accepts different things or otherwise behaves differently depending on the microversion | |
| 14:04:32 | stephenfin | I'll give it some more thought though. You have a specific Gerrit tag for your image service rework, gtema? | |
| 14:04:33 | gtema | ok, so do you "need" to specify microversion in order to lock the server with the reason? | |
| 14:04:45 | gtema | osc-first | |
| 14:04:48 | stephenfin | You do, yeah | |
| 14:04:58 | gtema | https://review.opendev.org/#/c/650374/ | |
| 14:05:13 | stephenfin | If you make the request without the version, nova will default to version 2.1 and the schema check will fail | |
| 14:05:24 | gtema | ok | |
| 14:06:29 | gtema | for that there is no support in SDK currently completely. So I would suggest to try to implement it there, that if reason is set - include microversion (is supported) | |
| 14:06:55 | gtema | I would say this should be transparent to OSC, but a different approach might be used | |
| 14:06:59 | stephenfin | That makes sense | |
| 14:07:23 | gtema | https://review.opendev.org/#/c/697674/ | |
| 14:07:45 | gtema | so currently lot's of nova stuff in OSC requires you to specify microversion already there | |
| 14:08:02 | gtema | both has pros and cons | |
| 14:08:22 | stephenfin | ah, so version checks are handled from the OSC side rather than the SDK side | |
| 14:08:30 | gtema | currently yes | |
| 14:08:36 | stephenfin | and the SDK will dumbly pass whatever it gets to nova | |
| 14:08:37 | stephenfin | cool | |
| 14:08:52 | stephenfin | definitely easier, but not as nice for people using SDK for other things | |
| 14:09:10 | gtema | it enforces "user" to know which mv it needs (bad), but ensures early that it is possible at all | |
| 14:10:00 | stephenfin | fwiw, novaclient defaults to using the latest version and enforces users know the _older_ mv if they want old behavior | |
| 14:10:11 | gtema | lemme browse through dtantsur's code in baremetal and check with him ideas | |
| 14:10:13 | stephenfin | the rationale being that people will usually want the new shiny | |
| 14:10:28 | stephenfin | but osc hasn't been against that historically and I'm not wading into that battle :) | |
| 14:10:34 | stephenfin | gtema: That'd be great | |
| 14:10:54 | stephenfin | once I've a blueprint to work against, closing the gaps should be fairly rote | |
| 14:10:58 | gtema | they always want new and shiny, but it might be not available, and that's what you need to check in a frendly manner | |
| 14:11:04 | stephenfin | given novaclient is pretty complete | |
| 14:11:46 | gtema | great. Our first concept with bringing individual clients/sdk/OSC in sync didn't went well (not widely accepted). But glad you are on boat | |
| 14:12:20 | stephenfin | sure am | |
| 14:12:23 | stephenfin | and on that note | |
| 14:12:35 | gtema | enjoy | |
| 16:01:55 | elmiko | API SIG office hour now under way! | |
| 16:02:11 | gtema | under "not existing" way? | |
| 16:02:26 | gtema | or pretty-silent way | |
| 16:02:29 | elmiko | lol | |
| 16:02:36 | elmiko | i gotta at least make the announcement | |
| 16:02:44 | gtema | yey | |
| 16:03:57 | sshnaidm | is there anybody for meeting? | |
| 16:04:16 | gtema | it's just a few of us ... | |
| 16:04:30 | sshnaidm | can anybody run the bot? I can't :( | |
| 16:04:32 | elmiko | i'm not sure about the /other/ meeting | |
| 16:04:53 | sshnaidm | #startmeeting | |
| 16:04:54 | openstack | sshnaidm: Error: A meeting name is required, e.g., '#startmeeting Marketing Committee' | |
| 16:04:57 | sshnaidm | :) | |
| 16:05:03 | elmiko | you need to add api-sig | |
| 16:05:14 | gtema | #startmeeting api-sig | |
| 16:05:15 | openstack | Meeting started Thu Dec 19 16:05:14 2019 UTC and is due to finish in 60 minutes. The chair is gtema. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 16:05:16 | openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 16:05:18 | openstack | The meeting name has been set to 'api_sig' | |
| 16:05:20 | elmiko | \o/ | |
| 16:05:32 | gtema | cool, I could do this | |
| 16:05:35 | sshnaidm | gtema, thanks | |
| 16:05:42 | sshnaidm | #chair sshnaidm | |
| 16:05:47 | elmiko | i think sshnaidm could as well, just missed the name | |
| 16:05:57 | gtema | #chair sshnaidm | |
| 16:05:58 | openstack | Current chairs: gtema sshnaidm | |
| 16:06:08 | sshnaidm | oh, great | |
| 16:06:10 | gtema | #chair elmiko | |
| 16:06:10 | openstack | Current chairs: elmiko gtema sshnaidm | |
| 16:06:29 | gtema | it's fun to talk to bot | |
| 16:06:33 | sshnaidm | tbh, we have a few topics only | |
| 16:06:42 | elmiko | haha, it's more activity than we usually get gtema ;) | |
| 16:06:55 | gtema | yey, behold | |
| 16:07:03 | sshnaidm | #link https://etherpad.openstack.org/p/openstack-ansible-modules | |
| 16:07:24 | sshnaidm | I've sent a mail about movign modules http://lists.openstack.org/pipermail/openstack-discuss/2019-December/011597.html | |
| 16:07:24 | sshnaidm | Need to decide finally about the strategy | |
| 16:07:43 | sshnaidm | we've got the answer from mordred only | |
| 16:07:51 | gtema | well yeah. I thought we actually agreed on the strategy | |
| 16:08:00 | gtema | so I found nothing I could add | |
| 16:08:11 | gtema | except - yes, there would be changes | |
| 16:08:22 | gtema | I mean changes in modules | |
| 16:08:42 | sshnaidm | so nobody objected to that mail, I can assume everybody is agreed | |
| 16:08:45 | gtema | and yes - we must stay compatible and not break users | |
| 16:08:51 | sshnaidm | or just not present :) | |
| 16:09:30 | gtema | well, there is no question in the email. There are things we discussed and things to consider | |
| 16:09:34 | sshnaidm | so each module will be treated separately, some of them will be deprecated, some not | |
| 16:09:36 | gtema | I agree to them | |
| 16:10:05 | sshnaidm | for keeping them backward compatible we'll need good testing, just to remember | |
| 16:10:09 | gtema | yes, kinda. We do a rename and maintain backward-compatibility through botmeta | |
| 16:10:38 | gtema | ironic modules might be replaced (new + deprecation of old) completely | |
| 16:10:44 | sshnaidm | and good testing is not what we have currently, also to remember.. | |
| 16:11:02 | sshnaidm | gtema, yeah, I think so | |
| 16:11:09 | gtema | that is for sure. I am still thinking how we can enable testing in the new repo | |