| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2021-02-18 | |||
| 14:30:52 | diablo_rojo | gtema, +1 | |
| 14:30:54 | gtema | sure | |
| 14:30:54 | gouthamr | #link https://review.opendev.org/c/openstack/openstacksdk/+/773556/ (Add shared file systems support) | |
| 14:31:23 | gouthamr | so this Version resource question, gtema - https://review.opendev.org/c/openstack/openstacksdk/+/773556/4/openstack/shared_file_system/version.py | |
| 14:31:57 | gouthamr | can we allow this to merge, and address it from all services at once? | |
| 14:32:16 | gtema | I am not sure we can make it properly working that easy | |
| 14:32:17 | gouthamr | or, can we add a versions proxy method? | |
| 14:32:28 | gtema | we do not talk with unversioned endpoint at all | |
| 14:32:34 | gtema | this is all delegated to KSA | |
| 14:32:48 | gtema | I guess this exists historically, but I have never seen it working | |
| 14:33:23 | gtema | versions method on proxy will not work, since you really need to send request to unversioned point | |
| 14:33:50 | gtema | of course we can hack it, but this is not something I like | |
| 14:34:12 | amotoki | I think the current sdk depends on KSA regarding version discovery and we assume clouds.yaml or other info provides the major version info, right? | |
| 14:34:22 | gtema | right | |
| 14:34:28 | amotoki | I am not sure we really query the unversioned URL | |
| 14:34:39 | gtema | exactly - we do not | |
| 14:34:51 | gtema | this is all done in KSA, we get back the versioned one already | |
| 14:35:05 | gtema | we can, however, get list of supported versions from KSA | |
| 14:35:55 | gouthamr | ^ i think my usecase of "what api versions are supported" is met with the get_all_version_data() method from teh connection object | |
| 14:36:00 | gtema | and for that we would not need individual service version resource, I would vote for making it general (if doing it at all) | |
| 14:36:06 | gouthamr | but, i thought we could prettify it a bit | |
| 14:36:16 | gouthamr | can i take a stab at this, post this merging? | |
| 14:36:25 | gtema | gouthamr, generally you don't mess with microversions at all | |
| 14:36:30 | gouthamr | erm, why? | |
| 14:36:43 | gtema | as a user you should be abstracted from that | |
| 14:36:50 | gtema | we did lot to make this transparent | |
| 14:37:09 | gtema | user doesn't need to know in which MV function was added | |
| 14:37:29 | gtema | he just says - I want X, and SDK says, sorry, X is not supported in your case | |
| 14:37:49 | gouthamr | i see, yes - that'd be the case for most users | |
| 14:37:51 | gtema | OSC is in it's side also getting MV handling "dropped" | |
| 14:38:35 | gtema | on the resource level you specify which MV it corresponds to and all operations on it automatically get this MV used (unless server doesn't support it) | |
| 14:38:59 | tosky | talking about that (sorry for jumping in)... can we move forward with this, or an equivalent solution? https://review.opendev.org/c/openstack/python-openstackclient/+/590807 | |
| 14:39:06 | gtema | on the functions side you implement a check (or better to say: MV x.y is required for this to work) | |
| 14:39:21 | tosky | (if it's unrelated I'll wait of course; that's a major pain point in "selling" OSC internally in cinder) | |
| 14:39:44 | gtema | we move a bit into different direction, gimme a sec | |
| 14:40:34 | gtema | https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/compute/v2/hypervisor.py#L90 | |
| 14:41:03 | gtema | OSC user just tells: I want this and that. SDK verifies with the server whether it is possible or not | |
| 14:41:55 | gtema | for cinder our NDSU students will complete SDK part and we can move OSC to use SDK | |
| 14:42:08 | gtema | with that MV handling will pretty much be offloaded from users completely | |
| 14:42:31 | gtema | we are doing this currently for nova, albeit with no big progress in last month | |
| 14:44:03 | gtema | another example of tricky MV implementation is https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/compute/v2/_proxy.py#L1807 | |
| 14:44:21 | gtema | this literally was dropped from OSC and handled in SDK | |
| 14:45:15 | gtema | further questions about MV? | |
| 14:45:35 | amotoki | OSC user still needs to specify MV, right? | |
| 14:45:35 | tosky | I understand that's an internal restructuring, but when it's time to go back to the cinder part of OSC, it would be better to advertise that in the cinder channels as well | |
| 14:45:50 | gtema | amotoki - user CAN, but he doesn't need | |
| 14:46:04 | gtema | highest possible will be used | |
| 14:46:16 | amotoki | gtema: so does user need to specify the major version only? | |
| 14:46:30 | tosky | (and see if anything can be fixed there: apart from this supposed "microversions are not supported" claims which pop up from time to time, another complain is about some choices in the parameters which may not match the expectations on the cinder side) | |
| 14:46:42 | gtema | it depends on the service catalog - pretty much it "picks" major version for us | |
| 14:47:22 | gouthamr | i don't fully understand the version negotiation aspect in https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/utils.py#L98 - i'll read up more | |
| 14:47:29 | gtema | tosky, I know this pops up as a complain often | |
| 14:47:39 | gouthamr | in the meanwhile, i'll submit a patch dropping the versions resource | |
| 14:47:45 | gouthamr | from the manila implementation' | |
| 14:47:55 | gtema | and we thought it make not much sense to continue convincing people, we just need to start doing things | |
| 14:48:42 | gtema | I was hoping to complete together with stephenfin nova part this cycle to be a show case for other teams | |
| 14:48:54 | gtema | not sure, however, we will be in time (busy times) | |
| 14:49:09 | amotoki | gtema: thanks. I will try to follow it up. | |
| 14:49:14 | gtema | cool | |
| 14:49:47 | gtema | summary: SDK negotiates it's own max version, max version supported by server and the one optionally selected by the user | |
| 14:49:53 | gtema | and picks the highest possible | |
| 14:50:17 | gouthamr | ^ thanks for that clarification | |
| 14:50:19 | gtema | this gives user still possibility to fall back to the older one | |
| 14:50:44 | gouthamr | one last thing regarding this $topic | |
| 14:50:55 | gouthamr | #link https://review.opendev.org/c/openstack/keystoneauth/+/774042 (Specify manila microversion header) | |
| 14:51:08 | gouthamr | ^ we need this to merge to get things to work for manila | |
| 14:51:25 | gouthamr | so if there are keystoneauth reviewers in the room, i'd love some help :) | |
| 14:52:15 | gtema | sadly nobody | |
| 14:52:19 | diablo_rojo | Lol | |
| 14:52:23 | gouthamr | haha :) | |
| 14:52:35 | gouthamr | okay i'll ask in the keystone channel | |
| 14:52:38 | stephenfin | gouthamr: You probably want to bring it up on #openstack-keystone | |
| 14:52:40 | stephenfin | yeah | |
| 14:52:46 | amotoki | gouthamr: one question | |
| 14:52:50 | gtema | I'm wondering there is nothing for cinder over there | |
| 14:53:04 | amotoki | gouthamr: don't we use OpenStack-API-Version: <service> <version> for such case? | |
| 14:53:14 | stephenfin | fwiw, I've got very little feedback on any of my keystone-related stuff lately, but if you keep prodding hopefully you'll get somewhere | |
| 14:54:01 | amotoki | rather than OpenStack-Compute-API-Version. I need to find the source on what we discussed so far though. | |
| 14:54:01 | gouthamr | amotoki: not with manila unfortunately, i can follow up right after this meeting - but, the gist is that we missed the boat on that standardization, and there's a lot of existing clouds out there to update now | |
| 14:54:14 | gouthamr | stephenfin: ack, will do :) | |
| 14:54:36 | stephenfin | zimmerry, diablo_rojo: https://review.opendev.org/c/openstack/openstacksdk/+/745375 | |
| 14:54:41 | gouthamr | we've six minutes, and i'd like to say hi to other diablo_rojo prodigies :) | |
| 14:55:26 | diablo_rojo | Thanks stephenfin! | |
| 14:55:50 | diablo_rojo | Oh I don't think all the NDSU students are here just wanted to make the logs aware that these other folks exist :) | |
| 14:56:56 | diablo_rojo | I saw someone from windriver starting to work on Cinder things and I wanted to make sure they are aware of what the NDSU students are doing | |
| 14:57:05 | gtema | good, do we have something else? | |
| 14:58:03 | diablo_rojo | But I don't know thiago's irc nick so I don't know if they are here | |
| 14:59:04 | diablo_rojo | So I guess I don't have much else atm. | |
| 14:59:11 | gtema | then we are good to end the meeting | |
| 14:59:21 | diablo_rojo | gtema, yep I believe so | |
| 14:59:25 | gtema | thanks everybody for participation | |
| 14:59:26 | diablo_rojo | thanks for running it! | |
| 14:59:36 | gtema | was more than I was actually expecting ;-) | |
| 14:59:48 | gtema | #endmeeting | |
| 14:59:50 | openstack | Meeting ended Thu Feb 18 14:59:48 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 14:59:51 | openstack | Minutes: http://eavesdrop.openstack.org/meetings/sdk_osc/2021/sdk_osc.2021-02-18-14.05.html | |
| 14:59:52 | openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/sdk_osc/2021/sdk_osc.2021-02-18-14.05.txt | |
| 14:59:53 | openstack | Log: http://eavesdrop.openstack.org/meetings/sdk_osc/2021/sdk_osc.2021-02-18-14.05.log.html | |
| 14:59:59 | markypharaoh[m] | cheers | |
| 15:00:20 | gouthamr | thanks everyone! | |