| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2021-02-18 | |||
| 14:16:16 | ashrod98[m] | markypharaoh: hello! | |
| 14:16:38 | markypharaoh[m] | aloha | |
| 14:16:50 | gtema | so I think it make sense to try to reduce amount of jobs, but to pack more components there | |
| 14:17:07 | gouthamr | gtema: sure, i don't mind that at all | |
| 14:17:43 | gouthamr | what sort of consolidation are we looking at? related services? all in one? | |
| 14:18:09 | gtema | we have currently dedicated networking with lot's of networking services | |
| 14:18:30 | gtema | others seem to be really more service oriented (few for ironic) | |
| 14:18:45 | gtema | masakari | |
| 14:19:00 | gtema | ... | |
| 14:19:23 | gtema | perhaps we should leave networking (since it is already "heavy") and pack all others together | |
| 14:20:09 | gtema | I guess it is hard to find proper balance | |
| 14:20:12 | gouthamr | yeah, we'd surely consume lesser test nodes if we consolidated - although i expect devstack for manila to be really fast | |
| 14:21:00 | gouthamr | i'm trying to use a fake backend driver for this functional test job and turn off other services | |
| 14:21:02 | gouthamr | #link https://review.opendev.org/c/openstack/openstacksdk/+/776312 | |
| 14:21:44 | gouthamr | the fake backend driver is what we use for functional/api testing in other client projects - because we're not testing the data path - just the API | |
| 14:22:02 | gtema | right | |
| 14:23:11 | gtema | I suggest gouthamr you make it working and then we figure out where to squeeze it in | |
| 14:23:44 | gouthamr | ack will do, failing currently because i'm missing an important devstack local.conf parameter :) | |
| 14:24:18 | gtema | great | |
| 14:24:37 | gtema | do we have student related (or from students) questions? | |
| 14:24:56 | gouthamr | lemme formally introduce ashrod98[m] (Ashley Rodriguez), NicoleBU (Nicole Chen) and markypharaoh[m] (Mark Tony) | |
| 14:25:17 | diablo_rojo | I for one am STOKED you are all on IRC. | |
| 14:25:21 | NicoleBU | Hello! Its nice to meet you guys :) | |
| 14:25:24 | ashrod98[m] | hello! Nice to meet you | |
| 14:25:31 | markypharaoh[m] | Hi Team !!! | |
| 14:25:36 | gtema | awesome, welcome | |
| 14:26:01 | gtema | I guess you are all also half sleeping? | |
| 14:26:08 | gouthamr | they've started working on adding follow up patches.. | |
| 14:26:11 | markypharaoh[m] | No questions from my end.. nicole, ashley? | |
| 14:26:31 | gouthamr | #link https://tree.taiga.io/project/ashrod98-openstacksdk-manila-support/kanban (the manila openstacksdk backlog) | |
| 14:26:53 | ashrod98[m] | nah its 9 am around here so I'm awake. and no questions from me. Just working through some unit testing right now | |
| 14:27:18 | gtema | US is too wide to keep all TZ in the head :) | |
| 14:27:27 | NicoleBU | Same here, I don't currently have any questions | |
| 14:27:28 | stephenfin | o/ | |
| 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 | |