14:02:17 <gtema> #startmeeting SDK/OSC
14:02:18 <openstack> Meeting started Thu Nov 19 14:02:17 2020 UTC and is due to finish in 60 minutes.  The chair is gtema. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:21 <openstack> The meeting name has been set to 'sdk_osc'
14:02:48 <diablo_rojo> o/
14:02:51 <amotoki> hi
14:03:02 <gtema> hey
14:03:09 <stephenfin> o/
14:03:18 <gtema> ping gouthamr
14:03:38 <gouthamr> o/
14:03:47 <gtema> do we want to use meetpad for voice meeting, or due to the time differences better in text ;-)
14:04:56 <gtema> no opinions?
14:05:47 <gtema> agenda for the meeting is under https://etherpad.opendev.org/p/openstacksdk-meeting-agenda
14:05:49 <amotoki> I have no strong preference on it, but most openstack projects use irc meetings and text meeting would be preferred in general.
14:05:59 <gtema> no problem
14:06:00 <diablo_rojo> Please just text lol
14:06:09 <gtema> oki, was thinking
14:06:27 <gtema> #topic Add Resolution of TC stance on the OpenStackClient Patch
14:06:35 <diablo_rojo> This way we have logs and don't need to take notes.
14:06:54 <gtema> I left my +1 (yet again)
14:07:20 <gtema> I am (not actually really wondering) - even this way there is some resistance from the community
14:08:08 <gtema> what is the plan of TC, to push on it or still try to get agreement from everyone
14:08:09 <gtema> ?
14:08:17 <gtema> https://review.opendev.org/#/c/759904/
14:08:29 <diablo_rojo> We are trying to get that merged as a way forward.
14:08:48 <diablo_rojo> I do think its close, people just want more detail than we originally wanted to provide.
14:09:17 <gtema> this is already expressed very "weak". Is there a plan to really have a harder control?
14:09:33 * gouthamr takes a note on reviewing ^
14:10:53 <gtema> ok, moving next, since there is actually no further action points
14:10:57 <gtema> #topic Gerrit Breach Audit
14:11:31 <gtema> I did audit immediately when it was announced, but most likely forgot to send info about that
14:11:46 <diablo_rojo> the resolution is more of a stepping stone towards the end goal. A diplomatic way of starting to make progress.
14:11:50 <gtema> I have updated the linked etherpad with the info as well
14:11:54 <diablo_rojo> Oh cool, so all good then?
14:11:56 <diablo_rojo> Perfect.
14:12:00 <diablo_rojo> Thanks gtema!
14:12:04 <gtema> welcome
14:12:30 <stephenfin> gtema: You mean force patches for OSC? Not beyond the TC proposal, no. We need to rely on soft power more than hard power. It's not possible to force things through without the approval of the team, so we need to work to win those people over
14:12:31 <amotoki> gtema: did you audit all repos under openstacksdk?
14:12:38 <gtema> I reviewed both from gerrit side and from the attached commits. But due to the amount of projects under the SDK team ;-) I might have missed something
14:12:56 <gtema> sdk, python-openstackclient, openstackclient, os-service-types
14:13:05 <gtema> cliff, osc-lib
14:13:06 <stephenfin> fwiw, I think only Glance have pushed back. Everyone else is onboard, though not everyone has allocated resources (my nova is purely spare time stuff)
14:13:19 <amotoki> gtema: https://governance.openstack.org/tc/reference/projects/openstacksdk.html#deliverables lists our repos
14:13:45 <gtema> oh yes. shade as well
14:13:53 <stephenfin> tja
14:14:00 <stephenfin> *that's effectively EOL though
14:14:04 <gtema> will again ensure requestsexceptions and js-openstack-lib are covered
14:14:18 <gtema> tja - sounds so "german"
14:14:45 <gtema> don't tell me you are located in germany :)
14:15:37 <gtema> #topic Manila SDK work in Wallaby
14:16:02 <gtema> as mentioned - I think we generally need to start merging Manila bits into SDK
14:16:05 <gouthamr> hey! this was me. i had an update to share, and a couple of questions
14:16:26 <gtema> I know from own experience it is extremely hard to both add new services (complete)
14:16:33 <gtema> and also reviewing is terrible
14:16:50 <gtema> thus suggestion - get small things with resource by resource
14:17:10 <gouthamr> i agree, i saw your comment on
14:17:19 <gouthamr> #link https://review.opendev.org/#/c/638782/ (WIP: Add support for shared file systems (manila))
14:17:45 <gouthamr> we'll break the patch down into individual resources
14:17:57 <gtema> I would suggest you have a look yourself whether what is already there is working or not
14:18:10 <gtema> if yes - remove WIP status and let the reviews start
14:18:33 <stephenfin> gouthamr: Are you planning to work on OSC integration in parallel?
14:18:45 <gouthamr> yeah, the WIP never fell off of it, because the original author has moved on; and we're trying to pick up the work this cycle
14:18:53 <gtema> he - interesting question, since manila has own client
14:19:08 <amotoki> gtema: will the OSC integration be implemented as a plugin, right?
14:19:23 <gtema> afaik it is already a plugin
14:19:24 <amotoki> no gtema. i would like to mention gouthamr
14:19:32 <gouthamr> stephenfin: yes, the OSC work is ongoing - we've about 50% parity with the python-manilaclient
14:19:35 <gtema> https://opendev.org/openstack/python-manilaclient
14:19:50 <gouthamr> and yes, the native client houses the plugin ^
14:19:59 <amotoki> thanks. it is nice
14:20:24 <stephenfin> gouthamr: okay, good to hear :)
14:20:52 <gtema> I guess once the SDK part lands they can start consuming it to hopefully generally reduce efforts
14:21:16 <gouthamr> +1
14:21:36 <gouthamr> great, my update is that we're working with a few new university contributors to submit the openstacksdk bits
14:21:37 <gtema> I see manila is really evolving on the API part
14:21:58 <gouthamr> hopefully, i'll have them here in the next meeting :)
14:22:00 <gtema> are there lots of changes planned for this cycle?
14:22:53 <gouthamr> gtema: yes, we do hope to finish the openstacksdk by X, so much of the user facing resources you see in https://review.opendev.org/#/c/638782/ are planned for wallaby
14:23:22 <gtema> I mean on manila itself
14:23:41 <gtema> when the change was initially started I know it was pretty close to cover all APIs
14:23:47 <gouthamr> i don't anticipate changes in manila, wdym?
14:23:51 <gtema> but since then lots of new APIs were added
14:23:56 <gouthamr> oh
14:24:09 <gtema> okay, I thought you might be knowing
14:24:11 <gouthamr> that'll not stop happening though :)
14:24:36 <gtema> okay then
14:24:39 <gtema> moving on
14:24:41 <amotoki> do we need functional test coverage in SDK in addition to unit test? it can be the next step though.
14:25:16 <gtema> I think better to add those as well, but no objections of doing this in a follow-up
14:25:24 <stephenfin> if we're doing functional tests, we need to think about how we do so
14:25:31 <gtema> tests are taking sometimes 70% of the change itself
14:25:31 <stephenfin> the functional tests in OSC are _very_ racy
14:25:52 <gtema> that's absolutely correct stephenfin
14:26:06 <gtema> mostly those racy tests are coming from nova ;-)
14:26:16 <stephenfin> unfortunately so :(
14:26:43 <gtema> for sure we would need to start using more projects not to really corrupt things
14:26:55 <stephenfin> yup
14:27:11 <stephenfin> work for the future though, once we've more gaps closed
14:27:37 <gtema> oki
14:27:45 <gouthamr> i had a couple of other questions
14:27:51 <gouthamr> and gtema answered one of them in the etherpad
14:28:18 <gtema> the remaining is about tracking, right?
14:28:27 <gouthamr> does openstacksdk work need a spec? we intend to write one to plan our work
14:28:42 <gtema> we do not use specs currenlty
14:28:45 <gouthamr> ah
14:28:57 <gtema> I do not know whether those were ever used in SDK/OSC
14:29:21 <amotoki> I don't think we need a spec. what we need is just to be aware of the effort as impls would be straight-forward.
14:29:37 <gtema> correct
14:29:57 <amotoki> this kind of meetings would really help it :)
14:30:06 <gtema> something like spec might be required for the discussion we had with stephenfin yesterday
14:30:17 <gouthamr> ack - thanks; i'll not bother you with it then; the spec was more for project planning and some designing - if we write one, we'll keep it in manila-specs
14:30:19 <gtema> about what is better in OSC
14:30:40 <gtema> 'openstack aggregate cache image __aggregate__ __image1__ __image2__ ...'
14:30:42 <gouthamr> (we did write a spec for our osc work too - we can argue endlessly about subcommand naming) :D
14:31:01 <gtema> or 'openstack aggregate cache image __aggregate__ --image __image1__ --image __image2__ ...'
14:31:17 <gouthamr> (^ and things like that)
14:31:24 <gtema> there are 2 types currently used in different areas
14:31:43 <gtema> and we might need to agree what is the standard
14:31:46 <stephenfin> yes, this is a place where we're missing a BDFL (Benevolent Dictator For Life) to settle things for us
14:32:03 <stephenfin> In the absence of dtroyer, we should probably put together a style guide?
14:32:08 <gtema> hehe, I am not the one - tell you right now
14:32:22 <amotoki> it is a topic on how our CLI command should be composed.  i think it can be discussed as a document change proposal in OSC
14:32:30 <stephenfin> Nonsense. All hail, gtema
14:32:31 <stephenfin> :P
14:32:47 <stephenfin> amotoki++ yeah, I think this would be a great addition to the docs
14:32:52 <gtema> amotoki - right. We should start perhaps one
14:33:07 * stephenfin can do put together a strawman proposal
14:33:09 <stephenfin> s/do //
14:33:23 <stephenfin> and then we can debate it on Gerrit
14:33:29 <diablo_rojo> I look forward to reviewing :)
14:33:30 <gtema> #action - start a style guide for osc
14:33:32 <amotoki> :)
14:34:13 <gouthamr> #link https://docs.openstack.org/python-openstackclient/latest/contributor/humaninterfaceguide.html
14:34:19 <gouthamr> ^ this one already exists, though
14:34:37 <gtema> right
14:34:47 <gtema> I new I was seeing this once, but completely forgot
14:34:55 <gouthamr> and specifically: https://docs.openstack.org/python-openstackclient/latest/contributor/command-options.html
14:35:55 <gtema> great, might need some extension
14:36:09 <amotoki> they are good starts. If there are something not covered, we can cover more cases.
14:36:17 <stephenfin> yes, good call. I didn't know that existed
14:36:31 <gouthamr> sometimes patterns there don't make sense in all situations; an optional parameter is really required: https://docs.openstack.org/python-openstackclient/latest/contributor/command-options.html#required-options
14:36:42 <gouthamr> "required options" :D
14:37:04 <stephenfin> bit on an oxymoron, yes /o\
14:37:49 <gtema> okay, moving next
14:37:56 <gtema> #topic Status OSC to use SDK for nova part
14:38:18 <gtema> I think we are progressing with stephenfin quite good on that
14:38:38 <gtema> of course there is still lot to cover
14:39:01 <gtema> I am explicitly afraid of starting changing 'server' operations - that would be a challenge
14:39:32 <gtema> stephenfin, do you know whether this cycle we get something new from nova?
14:40:08 <stephenfin> it shouldn't be _too_ bad - most server actions are implemented by POSTing a simply JSON body to the server actions API
14:40:29 <stephenfin> gtema: There were no API changes in Victoria. There are only minor changes (to the os-hypervisors API) planned for Wallaby so far
14:40:38 <gtema> yes, it is always _easy_, until you start working on it
14:40:44 <stephenfin> True :)
14:40:46 <gtema> oh, changes in hypervisor?
14:40:57 <gtema> just working on switching it
14:41:06 <stephenfin> Yes, but I'm doing that so I'll handle the SDK changes when I do it
14:41:23 <gtema> with few cool things: until 2.53 you use 1 API to search, after - another
14:41:43 <stephenfin> oh, there's also a spec proposed to remove the final references to 'tenant_id' from the API, in favour of 'project_id'. It's not approved yet but it will be I suspect
14:41:50 <gtema> and then https://opendev.org/openstack/python-openstackclient/src/branch/master/openstackclient/compute/v2/hypervisor.py#L124
14:42:09 <stephenfin> yeah, there's been a lot of that /o\
14:42:12 <gtema> I guess tenant_id/project_id is not a big deal at all
14:42:45 <gtema> wrt this mentioned renaming I am currently thinking to return DictColumn instead of this renaming
14:43:10 <gtema> I do not think it is really useful to do this renaming, especially that it requires hacking
14:43:28 <gtema> what do you think?
14:43:36 <gtema> I agree this is a "breaking" change
14:44:04 <gtema> but we anyway plan to bump a major release after this rework is done
14:44:04 <stephenfin> no issues from me
14:44:15 <gtema> okay, great
14:44:17 <stephenfin> so long as we signal it with a major version bump, yes
14:44:28 <gtema> I hope OSC part will arrive today
14:44:53 <amotoki> from POV of consumers, it would be nice if both of project_id and tenant_id can be used transparently.
14:45:18 <gtema> I guess since very long time those are everywhere translated to project_id
14:45:19 <amotoki> I am not sure what part is discussed, nova API interaction or SDK abstraction?
14:45:48 <gtema> well - more about switching OSC to use SDK for nova part
14:46:22 <gtema> on the other hand stephenfin has also some UX improvents in head while we touch those
14:47:09 <gtema> stephenfin - do you have ideas in which order we should touch remaining things?
14:47:20 <gtema> I was thinking to leave server to be last
14:47:23 <gtema> since it is huge
14:47:40 <gtema> but might be better other way around
14:47:41 <stephenfin> No ideas, no. Whatever suits, really
14:47:56 <stephenfin> I'm planning to continue closing gaps with OSC and novaclient
14:48:15 <gtema> okay. For server I will be definitely create smaller patches switching individual commands of the server or server action
14:48:33 <gtema> since otherwise we will immediately get into some sort of long lock
14:49:12 <stephenfin> Makes sense
14:49:32 <stephenfin> I'll keep using the novaclient library to implement the CLIs until the necessary SDK bits are there to switch over
14:49:42 <gtema> ok
14:49:55 <stephenfin> because I don't yet understand SDK well enough /o\
14:50:22 <gtema> I am not sure what is really better - do switch first and extend, or first extend and then switch to SDK
14:50:37 <gtema> SDK is a voodoo thanks to mordred ;-)
14:51:02 <stephenfin> extend and switch means we have a known baseline
14:51:10 <gtema> there are just few persons around the world probably who completely understand SDK
14:51:31 <gtema> agree on that, but
14:51:35 <stephenfin> i.e. I know novaclient works. I don't necessarily know new OSC changes works
14:51:53 <stephenfin> also, I'm adding missing options more so than missing commands
14:51:57 <gtema> before the switch I go to SDK and verify it can do everything what API provides
14:52:35 <gtema> so SDK should be supporting everything for OSC to be able to implement missing params
14:53:05 <gtema> okay
14:53:28 <gtema> diablo_rojo - do you have students already you were mentioning in PTG?
14:53:36 <gtema> the ones who can support this work
14:54:02 <diablo_rojo> Still working on the one from OSU.
14:54:17 <diablo_rojo> But the BU students are already working with gouthamr
14:54:32 <gtema> okay
14:55:06 <diablo_rojo> I just got the email calling for projects for NDSU students in the spring so I will start working on putting that together tomorrow probably.
14:55:20 <gtema> great
14:55:45 <gtema> I think we would be in time with the switch for nova command toward SDK this cycle - we are maybe 40% through currently
14:56:22 <gtema> maybe we can also start doing that for cinder as well, since I have a feeling those are now also a bit unhappy with OSC functionality
14:56:22 <openstackgerrit> Stephen Finucane proposed openstack/python-openstackclient master: Make use of comparable 'FormattableColumn' subclasses  https://review.opendev.org/761447
14:56:23 <openstackgerrit> Stephen Finucane proposed openstack/python-openstackclient master: compute: Fix 'server * -f yaml' output  https://review.opendev.org/761205
14:56:23 <openstackgerrit> Stephen Finucane proposed openstack/python-openstackclient master: compute: Fix 'usage * -f yaml' output  https://review.opendev.org/761595
14:56:24 <openstackgerrit> Stephen Finucane proposed openstack/python-openstackclient master: compute: Fix 'server group * -f yaml' output  https://review.opendev.org/761596
14:56:24 <openstackgerrit> Stephen Finucane proposed openstack/python-openstackclient master: compute: Fix 'hypervisor show -f yaml' output  https://review.opendev.org/763004
14:56:25 <openstackgerrit> Stephen Finucane proposed openstack/python-openstackclient master: compute: Add 'server group create --rule' option  https://review.opendev.org/761597
14:56:25 <openstackgerrit> Stephen Finucane proposed openstack/python-openstackclient master: compute: Add 'server show --topology' option  https://review.opendev.org/680928
14:56:26 <openstackgerrit> Stephen Finucane proposed openstack/python-openstackclient master: trivial: Use plural for appended parameters  https://review.opendev.org/761598
14:56:48 <gtema> come on stephenfin - you want you work to be logged in the meeting minutes ;-)?
14:56:57 <diablo_rojo> gtema, stephenfin if you want me to make the NDSU proposal geared toward Nova work I can do that, but I will need your help with the mentoring :)
14:57:20 <stephenfin> gtema: Gerrit reviews wait for no meeting :)
14:57:31 <gtema> :D
14:57:38 <gtema> oh yes, mentoring
14:57:50 <amotoki> hehe. it might be a good trick to raise your reviews :)
14:58:09 <gtema> I guess in next couple of month this might be hard with the time for real mentoring
14:58:10 <stephenfin> diablo_rojo: That's interesting and maybe possible, but I'd need to run it by folks internally first
14:58:35 <gtema> no problem explaining/onboarding, but not really deeper mentoring
14:59:15 <gtema> okay, let's see how it evolves
14:59:18 <diablo_rojo> stephenfin, I think I have till the 30th to put together the project proposal, but I can get an extension if need be (I have in the past).
15:00:26 <stephenfin> okay, I'll run it by people and see what they think. Should have an answer by EOW
15:00:41 <diablo_rojo> In the past is been 3-4 students for a semester and I usually met with them once a week for an hour.
15:00:47 <diablo_rojo> Perfect :)
15:01:09 <gtema> if we get students we can actually also run in parallel work for cinder part, and not really nova
15:01:39 <gtema> then we have 200% output in the cycle
15:02:13 <stephenfin> Sounds good
15:02:18 <stephenfin> gtema: I think we're at time?
15:02:24 <diablo_rojo> Good meeting :)
15:02:25 <gtema> yes, right
15:02:34 <diablo_rojo> Over by a couple min.
15:02:34 <gtema> sorry, long thinking
15:02:42 <diablo_rojo> gtema, no worries :)
15:02:47 <diablo_rojo> Thanks for hosting!
15:02:48 <gtema> any questions unanswered?
15:03:09 <gtema> #endmeeting