| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-12-19 | |||
| 12:40:55 | openstackgerrit | Bence Romsics proposed openstack/openstacksdk master: Handle HTTP errors in add/remove router interface calls https://review.opendev.org/687304 | |
| 13:47:56 | elmiko | dtantsur: i'm thinking about cancelling the next 2 api sig office hours, do you have any feelings about the matter? | |
| 13:54:30 | stephenfin | mordred: I want to do some work on closing the gap between novaclient and openstackclient next year, and I'm thinking I'll use openstacksdk to do that which has many of its own gaps that need closing | |
| 13:54:51 | stephenfin | mordred: Would it be a huge ask for you to provide a sample patch for one of nova's microversioned APIs that I can use as a blueprint? | |
| 13:55:06 | stephenfin | You or someone else involved with openstacksdk (I only know of you :)) | |
| 13:55:32 | gtema | stephenfin - welcome on board. I'm currently working on "repairing" image support in the OSC | |
| 13:55:43 | gtema | and was thinking also to go next for compute | |
| 13:55:53 | gtema | so let's work on this together | |
| 13:56:11 | stephenfin | Great! | |
| 13:56:58 | gtema | I recently made a patch for managing server tags in OSC using SDK, and the next step might be to switch server set/unset operations to use only SDK | |
| 13:57:21 | gtema | with that we can slowly switch parts of the compute, which make it easier | |
| 13:57:32 | stephenfin | gtema: I assume you're doing these repairs using openstacksdk, or are you using glanceclient? | |
| 13:57:46 | gtema | I am replacing glanceclient with SDK | |
| 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 | openstack | Current chairs: elmiko gtema sshnaidm | |
| 16:06:10 | gtema | #chair elmiko | |
| 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 | Need to decide finally about the strategy | |
| 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: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 | |