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