14:05:41 #startmeeting sdk_osc 14:05:42 Meeting started Thu Feb 18 14:05:41 2021 UTC and is due to finish in 60 minutes. The chair is gtema. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:05:43 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:05:45 The meeting name has been set to 'sdk_osc' 14:06:23 o/ 14:06:27 as I placed right now on the agenda we can discuss shifting meeting time to 15:00 or even 16:00 14:06:45 We picked this time to also give amotoki chance to participate 14:07:04 I am 100% cool with later lol 14:07:12 but he doesn't participate now, so perhaps we can move it to make diablo_rojo sleeping a bit longer 14:07:16 it was a struggle to get out of bed. 14:07:18 YESSSSS 14:07:28 +1, but 16:00 please 14:07:45 okay to 16:00. Objections? 14:07:53 diablo_rojo: it will get better in just a couple of weeks :) 14:08:13 Sounds good to me. 14:08:33 * stephenfin wanders in late 14:08:34 (or not, DST ends March 14th) 14:08:40 gtema, did you want to put up the patch? Or should I? 14:09:12 16:00 clashes with the nova meeting on #openstack-meeting-3 14:09:19 I can do so. It actually got broken in new year, since the schedule assumes every week%3, which moved this year 14:09:26 no issues from me but just be aware that I won't be 100% present 14:09:27 :) 14:09:37 gtema, gouthamr fixed that I think 14:09:39 so if you downloaded ICL you get entry for one week earlier 14:09:42 well, depending on what comes up in that meeting obv 14:09:56 Maybe we do 15 UTC then? 14:10:01 yeah the ical's fixed: https://review.opendev.org/c/opendev/irc-meetings/+/775933 14:10:05 Honestly, even one hour later would be wonderful. 14:10:08 diablo_rojo: clashes with the manila meeting 14:11:33 and the TC meeting, and the security-sig meeting 14:11:35 let's keep it for 16 then, when there is need we anyway can discuss separately 14:12:03 Yeah, 16:00 works. You can ping me if my attention is needed 14:12:13 agreed 14:12:23 sorry I didn't attend here every time. I am okay to move the time to what you prefer. 14:12:50 good 14:13:18 next 3 topics are all about students :) 14:13:56 \o/ 14:13:57 would be great if they also participate here, otherwise in 2 hours we have next meeting 14:14:20 I'm here! A BU Student :) 14:14:26 cool 14:14:32 hey there, ashrod98[m] and NicoleBU 14:14:44 Oh hey that's cool :) 14:14:50 hello! 14:15:05 I'm helping Mark set up with NickServ 14:15:11 so he'll be here monetarily 14:15:11 I had a another look to manila patches today 14:15:15 ashrod98[m], nice :) 14:15:30 great 14:15:43 first SDK batch is good to go (just perhaps need to drop version resource, since it doesn't really work at all 14:16:02 but adding new manila job is something worying me 14:16:16 markypharaoh: hello! 14:16:16 we have already lot of jobs and it take ages to get the status 14:16:38 aloha 14:16:50 so I think it make sense to try to reduce amount of jobs, but to pack more components there 14:16:53 * gouthamr markypharaoh[m] has a hawaii theme for irc too! 14:17:07 gtema: sure, i don't mind that at all 14:17:43 what sort of consolidation are we looking at? related services? all in one? 14:18:09 we have currently dedicated networking with lot's of networking services 14:18:30 others seem to be really more service oriented (few for ironic) 14:18:45 masakari 14:19:00 ... 14:19:23 perhaps we should leave networking (since it is already "heavy") and pack all others together 14:20:09 I guess it is hard to find proper balance 14:20:12 yeah, we'd surely consume lesser test nodes if we consolidated - although i expect devstack for manila to be really fast 14:21:00 i'm trying to use a fake backend driver for this functional test job and turn off other services 14:21:02 #link https://review.opendev.org/c/openstack/openstacksdk/+/776312 14:21:44 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 right 14:23:11 I suggest gouthamr you make it working and then we figure out where to squeeze it in 14:23:44 ack will do, failing currently because i'm missing an important devstack local.conf parameter :) 14:24:18 great 14:24:37 do we have student related (or from students) questions? 14:24:56 lemme formally introduce ashrod98[m] (Ashley Rodriguez), NicoleBU (Nicole Chen) and markypharaoh[m] (Mark Tony) 14:25:17 I for one am STOKED you are all on IRC. 14:25:21 Hello! Its nice to meet you guys :) 14:25:24 hello! Nice to meet you 14:25:31 Hi Team !!! 14:25:36 awesome, welcome 14:26:01 I guess you are all also half sleeping? 14:26:08 they've started working on adding follow up patches.. 14:26:11 No questions from my end.. nicole, ashley? 14:26:31 #link https://tree.taiga.io/project/ashrod98-openstacksdk-manila-support/kanban (the manila openstacksdk backlog) 14:26:53 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:16 * gouthamr yawns with diablo_rojo 14:27:18 US is too wide to keep all TZ in the head :) 14:27:27 Same here, I don't currently have any questions 14:27:28 o/ 14:27:30 but still better than RUS 14:27:31 Its the west coast that gets you. Three hours is a lot lol. 14:27:52 haha yeah 6 am is wayyyy early 14:28:29 what is the timeline for BU to participate? 14:28:56 gtema: they're graduating in may 14:29:06 ok, similar to NDSU 14:29:14 just 2 month to go 14:29:17 Correct. 14:29:22 we are nearly in spring already 14:29:28 Time flies. 14:29:36 sure 14:29:40 Except it does more so when we can lol. 14:29:40 * gouthamr hears pomp and circumstance in the background 14:30:06 deep, diablo_rojo 14:30:07 Yeah our class presentations are in April. We hope to have few more patches in by then 14:30:18 we should perhaps speed up then, not to waste precious time 14:30:45 i've got a couple of questions wrt the base patch that's out there: 14:30:52 gtema, +1 14:30:54 sure 14:30:54 #link https://review.opendev.org/c/openstack/openstacksdk/+/773556/ (Add shared file systems support) 14:31:23 so this Version resource question, gtema - https://review.opendev.org/c/openstack/openstacksdk/+/773556/4/openstack/shared_file_system/version.py 14:31:57 can we allow this to merge, and address it from all services at once? 14:32:16 I am not sure we can make it properly working that easy 14:32:17 or, can we add a versions proxy method? 14:32:28 we do not talk with unversioned endpoint at all 14:32:34 this is all delegated to KSA 14:32:48 I guess this exists historically, but I have never seen it working 14:33:23 versions method on proxy will not work, since you really need to send request to unversioned point 14:33:50 of course we can hack it, but this is not something I like 14:34:12 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 right 14:34:28 I am not sure we really query the unversioned URL 14:34:39 exactly - we do not 14:34:51 this is all done in KSA, we get back the versioned one already 14:35:05 we can, however, get list of supported versions from KSA 14:35:55 ^ 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 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 but, i thought we could prettify it a bit 14:36:16 can i take a stab at this, post this merging? 14:36:25 gouthamr, generally you don't mess with microversions at all 14:36:30 erm, why? 14:36:43 as a user you should be abstracted from that 14:36:50 we did lot to make this transparent 14:37:09 user doesn't need to know in which MV function was added 14:37:29 he just says - I want X, and SDK says, sorry, X is not supported in your case 14:37:49 i see, yes - that'd be the case for most users 14:37:51 OSC is in it's side also getting MV handling "dropped" 14:38:35 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 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 on the functions side you implement a check (or better to say: MV x.y is required for this to work) 14:39:21 (if it's unrelated I'll wait of course; that's a major pain point in "selling" OSC internally in cinder) 14:39:44 we move a bit into different direction, gimme a sec 14:40:34 https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/compute/v2/hypervisor.py#L90 14:41:03 OSC user just tells: I want this and that. SDK verifies with the server whether it is possible or not 14:41:55 for cinder our NDSU students will complete SDK part and we can move OSC to use SDK 14:42:08 with that MV handling will pretty much be offloaded from users completely 14:42:31 we are doing this currently for nova, albeit with no big progress in last month 14:44:03 another example of tricky MV implementation is https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/compute/v2/_proxy.py#L1807 14:44:21 this literally was dropped from OSC and handled in SDK 14:45:15 further questions about MV? 14:45:35 OSC user still needs to specify MV, right? 14:45:35 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 amotoki - user CAN, but he doesn't need 14:46:04 highest possible will be used 14:46:16 gtema: so does user need to specify the major version only? 14:46:30 (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 it depends on the service catalog - pretty much it "picks" major version for us 14:47:17 * gouthamr emerges from reading code 14:47:22 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 tosky, I know this pops up as a complain often 14:47:39 in the meanwhile, i'll submit a patch dropping the versions resource 14:47:45 from the manila implementation' 14:47:55 and we thought it make not much sense to continue convincing people, we just need to start doing things 14:48:42 I was hoping to complete together with stephenfin nova part this cycle to be a show case for other teams 14:48:54 not sure, however, we will be in time (busy times) 14:49:09 gtema: thanks. I will try to follow it up. 14:49:14 cool 14:49:47 summary: SDK negotiates it's own max version, max version supported by server and the one optionally selected by the user 14:49:53 and picks the highest possible 14:50:17 ^ thanks for that clarification 14:50:19 this gives user still possibility to fall back to the older one 14:50:44 one last thing regarding this $topic 14:50:55 #link https://review.opendev.org/c/openstack/keystoneauth/+/774042 (Specify manila microversion header) 14:51:08 ^ we need this to merge to get things to work for manila 14:51:25 so if there are keystoneauth reviewers in the room, i'd love some help :) 14:52:15 sadly nobody 14:52:17 * diablo_rojo hears crickets 14:52:19 Lol 14:52:23 haha :) 14:52:35 okay i'll ask in the keystone channel 14:52:38 gouthamr: You probably want to bring it up on #openstack-keystone 14:52:40 yeah 14:52:46 gouthamr: one question 14:52:50 I'm wondering there is nothing for cinder over there 14:53:04 gouthamr: don't we use OpenStack-API-Version: for such case? 14:53:14 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 rather than OpenStack-Compute-API-Version. I need to find the source on what we discussed so far though. 14:54:01 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 stephenfin: ack, will do :) 14:54:36 zimmerry, diablo_rojo: https://review.opendev.org/c/openstack/openstacksdk/+/745375 14:54:41 we've six minutes, and i'd like to say hi to other diablo_rojo prodigies :) 14:55:26 Thanks stephenfin! 14:55:50 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 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 good, do we have something else? 14:58:03 But I don't know thiago's irc nick so I don't know if they are here 14:59:04 So I guess I don't have much else atm. 14:59:11 then we are good to end the meeting 14:59:21 gtema, yep I believe so 14:59:25 thanks everybody for participation 14:59:26 thanks for running it! 14:59:36 was more than I was actually expecting ;-) 14:59:48 #endmeeting