| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2021-02-18 | |||
| 14:27:30 | gtema | but still better than RUS | |
| 14:27:31 | diablo_rojo | Its the west coast that gets you. Three hours is a lot lol. | |
| 14:27:52 | ashrod98[m] | haha yeah 6 am is wayyyy early | |
| 14:28:29 | gtema | what is the timeline for BU to participate? | |
| 14:28:56 | gouthamr | gtema: they're graduating in may | |
| 14:29:06 | gtema | ok, similar to NDSU | |
| 14:29:14 | gtema | just 2 month to go | |
| 14:29:17 | diablo_rojo | Correct. | |
| 14:29:22 | gtema | we are nearly in spring already | |
| 14:29:28 | diablo_rojo | Time flies. | |
| 14:29:36 | gtema | sure | |
| 14:29:40 | diablo_rojo | Except it does more so when we can lol. | |
| 14:30:06 | gouthamr | deep, diablo_rojo | |
| 14:30:07 | ashrod98[m] | Yeah our class presentations are in April. We hope to have few more patches in by then | |
| 14:30:18 | gtema | we should perhaps speed up then, not to waste precious time | |
| 14:30:45 | gouthamr | i've got a couple of questions wrt the base patch that's out there: | |
| 14:30:52 | diablo_rojo | gtema, +1 | |
| 14:30:54 | gouthamr | #link https://review.opendev.org/c/openstack/openstacksdk/+/773556/ (Add shared file systems support) | |
| 14:30:54 | gtema | sure | |
| 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 | 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:35 | amotoki | OSC user still needs to specify MV, right? | |
| 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 | 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:01 | amotoki | rather than OpenStack-Compute-API-Version. I need to find the source on what we discussed so far though. | |
| 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 :) | |