14:05:41 <gtema> #startmeeting sdk_osc
14:05:42 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:05:45 <openstack> The meeting name has been set to 'sdk_osc'
14:06:23 <diablo_rojo> o/
14:06:27 <gtema> as I placed right now on the agenda we can discuss shifting meeting time to 15:00 or even 16:00
14:06:45 <gtema> We picked this time to also give amotoki chance to participate
14:07:04 <diablo_rojo> I am 100% cool with later lol
14:07:12 <gtema> but he doesn't participate now, so perhaps we can move it to make diablo_rojo sleeping a bit longer
14:07:16 <diablo_rojo> it was a struggle to get out of bed.
14:07:18 <diablo_rojo> YESSSSS
14:07:28 <gouthamr> +1, but 16:00 please
14:07:45 <gtema> okay to 16:00. Objections?
14:07:53 <gouthamr> diablo_rojo: it will get better in just a couple of weeks :)
14:08:13 <diablo_rojo> Sounds good to me.
14:08:33 * stephenfin wanders in late
14:08:34 <gouthamr> (or not, DST ends March 14th)
14:08:40 <diablo_rojo> gtema, did you want to put up the patch? Or should I?
14:09:12 <stephenfin> 16:00 clashes with the nova meeting on #openstack-meeting-3
14:09:19 <gtema> 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 <stephenfin> no issues from me but just be aware that I won't be 100% present
14:09:27 <stephenfin> :)
14:09:37 <diablo_rojo> gtema, gouthamr fixed that I think
14:09:39 <gtema> so if you downloaded ICL you get entry for one week earlier
14:09:42 <stephenfin> well, depending on what comes up in that meeting obv
14:09:56 <diablo_rojo> Maybe we do 15 UTC then?
14:10:01 <gouthamr> yeah the ical's fixed: https://review.opendev.org/c/opendev/irc-meetings/+/775933
14:10:05 <diablo_rojo> Honestly, even one hour later would be wonderful.
14:10:08 <gouthamr> diablo_rojo: clashes with the manila meeting
14:11:33 <gouthamr> and the TC meeting, and the security-sig meeting
14:11:35 <gtema> let's keep it for 16 then, when there is need we anyway can discuss separately
14:12:03 <stephenfin> Yeah, 16:00 works. You can ping me if my attention is needed
14:12:13 <gtema> agreed
14:12:23 <amotoki> sorry I didn't attend here every time. I am okay to move the time to what you prefer.
14:12:50 <gtema> good
14:13:18 <gtema> next 3 topics are all about students :)
14:13:56 <gouthamr> \o/
14:13:57 <gtema> would be great if they also participate here, otherwise in 2 hours we have next meeting
14:14:20 <ashrod98[m]> I'm here! A BU Student :)
14:14:26 <gtema> cool
14:14:32 <gouthamr> hey there, ashrod98[m] and NicoleBU
14:14:44 <diablo_rojo> Oh hey that's cool :)
14:14:50 <NicoleBU> hello!
14:15:05 <ashrod98[m]> I'm helping Mark set up with NickServ
14:15:11 <ashrod98[m]> so he'll be here monetarily
14:15:11 <gtema> I had a another look to manila patches today
14:15:15 <diablo_rojo> ashrod98[m], nice :)
14:15:30 <gouthamr> great
14:15:43 <gtema> 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 <gtema> but adding new manila job is something worying me
14:16:16 <ashrod98[m]> markypharaoh: hello!
14:16:16 <gtema> we have already lot of jobs and it take ages to get the status
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:16:53 * gouthamr markypharaoh[m] has a hawaii theme for irc too!
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:16 * gouthamr yawns with diablo_rojo
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:29:40 * gouthamr hears pomp and circumstance in the background
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 <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:17 * gouthamr emerges from reading code
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:17 * diablo_rojo hears crickets
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