| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-12-19 | |||
| 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 | |
| 16:11:11 | sshnaidm | they are out of sync.. | |
| 16:11:31 | sshnaidm | gtema, we have pep and old ci job there in patches | |
| 16:11:44 | sshnaidm | later we'll need to work on that more of course | |
| 16:12:10 | sshnaidm | I think we agreed also not to change anything in 2.9 | |
| 16:12:25 | sshnaidm | for not to sync them manually | |
| 16:12:38 | gtema | well, 2.9 is out in the wild anyway, so we can't change anything there | |
| 16:12:57 | sshnaidm | gtema, I mean via github PRs to ansible upstream | |
| 16:13:05 | sshnaidm | or via backports | |
| 16:13:17 | gtema | yes | |
| 16:13:34 | sshnaidm | next: Should we move modules with keeping history? | |
| 16:13:44 | gtema | there is anyway currently nobody watching for PRs (while I see there are discussions from the PR-contributors) | |
| 16:14:09 | sshnaidm | gtema, well, I submitted a few patches in last months | |
| 16:14:15 | gtema | I, personally, see no need in that, but also not object in keeping history | |
| 16:14:24 | gtema | I know | |
| 16:14:29 | sshnaidm | I'd like to keep the history tbh is possible | |
| 16:14:36 | sshnaidm | s/is/if/ | |
| 16:14:54 | sshnaidm | it helps to understand the logic of changes | |
| 16:14:58 | gtema | yeah, this is nice "if" | |
| 16:15:19 | gtema | but anyway for history you can always refer to Ansible itself | |
| 16:15:27 | sshnaidm | gtema, right | |
| 16:15:41 | sshnaidm | - Should we move now and not to wait till Jan? | |
| 16:15:56 | sshnaidm | I think it's obvious we need to wait | |
| 16:16:00 | gtema | hmm, | |
| 16:16:15 | gtema | from what I see there are currently nobody except us here now | |