Friday, 2020-01-10

*** brinzhang has joined #openstack-manila01:52
*** brinzhang_ has joined #openstack-manila02:27
*** brinzhang has quit IRC02:30
*** brinzhang has joined #openstack-manila02:31
*** brinzhang_ has quit IRC02:32
*** brinzhang has quit IRC02:33
*** brinzhang has joined #openstack-manila02:34
*** brinzhang_ has joined #openstack-manila05:05
*** brinzhang has quit IRC05:08
*** brinzhang has joined #openstack-manila05:53
*** brinzhang_ has quit IRC05:56
*** lpetrut has joined #openstack-manila06:08
*** lpetrut has quit IRC06:09
*** lpetrut has joined #openstack-manila06:10
*** brinzhang_ has joined #openstack-manila06:26
*** brinzhang has quit IRC06:28
*** gregwork has quit IRC06:42
*** brinzhang has joined #openstack-manila06:54
*** brinzhang_ has quit IRC06:58
*** brinzhang_ has joined #openstack-manila07:04
*** brinzhang has quit IRC07:07
*** brinzhang has joined #openstack-manila07:08
*** brinzhang_ has quit IRC07:09
*** brinzhang has quit IRC07:10
*** brinzhang has joined #openstack-manila07:10
*** pcaruana has joined #openstack-manila07:53
*** tosky has joined #openstack-manila08:12
*** brinzhang_ has joined #openstack-manila08:29
*** brinzhang has quit IRC08:33
*** pcaruana has quit IRC08:46
*** pcaruana has joined #openstack-manila08:53
*** brinzhang has joined #openstack-manila10:35
*** brinzhang_ has quit IRC11:50
*** brinzhang_ has joined #openstack-manila11:50
*** enriquetaso has joined #openstack-manila12:04
*** enriquetaso has quit IRC12:05
*** brinzhang_ has quit IRC12:11
*** brinzhang_ has joined #openstack-manila12:11
*** enriquetaso has joined #openstack-manila12:33
*** pcaruana has quit IRC12:34
*** pcaruana has joined #openstack-manila12:38
*** trident has quit IRC13:13
*** trident has joined #openstack-manila13:15
*** vhari has joined #openstack-manila13:31
*** theintern_ has joined #openstack-manila14:58
*** theintern_ has quit IRC15:08
*** eharney has joined #openstack-manila15:17
*** theintern_ has joined #openstack-manila15:19
maaritammHi there! vkmc, tbarron, gouthamr &/or anyone who could share their thoughts. I would like to get some input on this batch (osc commands for share types) : https://review.opendev.org/#/c/701229/15:24
vkmcmaaritamm++15:25
maaritammmore specifically about formatting the outputs, like mentioned yesterday. I understand that it would be best to match manila clients’ for backwards compatibility but I’m interested to know what level in detail I should follow for this.15:25
vkmcI'll look right away15:25
*** josecastroleon has joined #openstack-manila15:25
maaritammfor example the value for ‘is_default’ in manila type-create output is +/- , in manila type-show is YES/NO and without any formatting it would be True/False15:25
maaritammthere are different variations for order of the fields, capitalized field names etc for different commands15:26
maaritammI don’t mind trying to mach all of those details but just wanted to make sure it’s necessary :)15:26
vkmcjosecastroleon, o/ https://review.opendev.org/#/c/701229/15:26
vkmclseki, also <315:26
maaritammat the moment I have only implemented to replace share_type_access:is_public with visibility and splitting extra specs to required and optional extra specs. Since those changes were consistent in create, list and show output15:26
josecastroleonhi15:26
tbarronmaaritamm: vkmc without looking in detail yet, my inclination is to say that if the old manila client  is displaying this information in inconsistent ways then15:28
tbarronthere's nothing wrong with having the OSC client version display it in a more consistent fashion15:28
tbarronthe old manila behavior willl still be preserved when using it, or would that change?15:28
vkmctbarron, our worry was... what happens if the output of the client was being consumed in an automatized way15:29
tbarronvkmc: so the old manila client behavior will change and that's the worry?15:29
vkmcbehavior is the same, output different15:29
tbarronok, but output is arguably behavior and that's the concer :)15:30
tbarronconocern :)15:30
vkmcyeah15:30
tbarronI can't spell15:30
tbarronHow hard is it to make the tabular output match the old inconsistent output and have the yaml and json output with the osc client be nice and consistent?15:31
maaritammbut the old manila behaviour is still untouched and manila commands can be used as before in parallel, if that’s what you meant tbarron15:31
tbarronmaaritamm: and the old manila command will still work the same way, "untouched"?15:32
tbarronIf so, then I have no worries about having OSC output be more consistent, no one is using that yet.15:32
vkmcthat's true, osc manila is brand new and therefore transition from manilaclient to osc manila could be done in an ordered way15:33
maaritammvkmc, please correct me if im wrong15:33
vkmcis not that we are breaking anything15:33
tbarronOSC client isn't going to be 100% backwards-consistent with the old manila client anyways.15:33
vkmcmaaritamm, you are right15:34
tbarronIf someone is going to rewrite a script to use osc instead of manila then I think it's fair to have them look at the output and adjust.15:34
vkmcyeah, I think it's a valid15:34
vkmcthinking15:34
tbarronIn fact, they should take advantage of  the json or yaml output capabilities that osc client has and that manila client lacks, b/c that's better for automation.15:35
vkmcmaaritamm, so we are fine, we can format the output as we consider :) make things look more consistent15:35
vkmctbarron, didn't know that osc has json/yaml capabilities15:35
tbarronvkmc: maaritamm maybe take a look at how OSC represents fields like "is public" for other components.15:35
josecastroleoni agree with tbarron, better to use json or yaml15:35
josecastroleonfor automation15:36
tbarronI think there are public and private glance images for example.15:36
toskyvkmc: the unified, multi-format output of osc is one of the selling points15:36
tbarronjust for least surprise.15:36
vkmctosky, hah, nice :)15:36
vkmctosky, they had me on "one client to rule them all"15:36
toskywhen I discovered that I could consistently use openstack <something> show <id> -f value -c <column> and print a single value...15:37
toskyI could clean up a lot of scripts15:37
toskyof course things can be improved, but...15:37
tbarrontosky: yeah, it's awesome not to have to do " | awk '{print $N}' " and try too figure out the right value of $N everywhere15:41
toskyas part of this effort, are you writing some functional tests? There is a class in tempest that can be used for this15:42
tbarrontosky: great idea, but are there functional tests for osc cinder for example?15:43
toskycinder use it for its non-unified client (https://opendev.org/openstack/python-cinderclient/src/branch/master/cinderclient/tests/functional/test_readonly_cli.py)15:43
toskyand sahara uses it for its unified client: https://opendev.org/openstack/sahara-tests/src/branch/master/sahara_tempest_plugin/tests/cli15:43
toskytbarron: you want to be better than cinder, I guess15:43
tbarrontosky: oh i'm just trying to determine the various heights of the high jump bar15:44
tbarronvkmc: maaritamm my suggestion would be to add such functional testing to the work plan but don't let it slow down your momentum at this stage15:45
vkmctbarron, sounds good15:46
toskytbarron: if you want to switch, you want to be sure that the new client is working properly15:46
vkmcwe are also looking into generating the correct docs15:47
toskyit will definitely save time when some poor quality engineer will have to test it :P15:47
tbarrontosky: agree and it should be part of Definition of Done for this work15:47
maaritammtbarron, sure, will do15:47
vkmcalready in a convo about that in #openstack-sdks15:47
vkmcmaaritamm, if you wanna join, openstackclient stuff is discussed in #openstack-sdks15:48
vkmcso there is people that knows about the openstackclient *itself*15:48
tbarronvkmc: maaritamm tosky doing this work via TDD would be a very nice approach but it's also OK to do unit tests as you are doing in15:49
tbarronhttps://review.opendev.org/#/c/698848/ and do a functional test pass on stuff in followup reviews15:49
tbarrontosky: thanks much for the functional test pointers!  I've never been delighted with the current functional test approach taken in manila and the15:51
tbarronsahara examples look cleaner15:51
tbarronvhari: ^^^ :)15:54
maaritammtbarron, cool, I’ll start getting more familiar with the functional testing15:58
maaritammfor the output formatting, I will try to push out some changes today/monday to finish the batch and then will make changes according to the comments15:59
maaritammplus one more thing... manila type-update was not mentioned here : https://specs.openstack.org/openstack/manila-specs/specs/train/manila-support-openstackclient.html#share-types so I took the liberty of adding the possibility to update name, description and visibility under share type set. Just wanted to mention that for reviewers to be extra critical of that bit :), not sure I was supposed to do that or if I implemented it correctly16:01
vharitbarron, nice approach and a time saver :)16:01
vharitosky, if I read this correctly, if we transition to osc ^^ , will require manila plugin updates16:05
vkmcmaaritamm, I think it's a good design decision, I see other services followed the same approach16:07
toskyvhari: uh, which kind of updates?16:07
vharitosky, any change (updates. additions) resulted from manilaclient to osc manila transition16:09
toskyvhari: then the other question is: which plugin? Tempest plugin?16:10
vharitosky,  yes ex: manila-tempest-plugin16:11
toskyso, this is a bit unrelated to osc or the old client16:12
tbarronvhari: tempest willl use the api rather than manila or osc clients to interact with manila, so no impact there16:12
toskyoh, that thing16:12
toskysorry, completely forgot about that: tempest clients are independent code, for good reasons16:13
vharitbarron, agreed, api tests should not be affected... however Liron was working on some scripts which used the cli..16:14
vharitbarron, will share this info with him as a heads up16:15
toskyvhari: he can definitely use tempest.lib.cli; the tests which use that class can be called directly using stestr (see the cinderclient example) or as part of a tempest plugin (as sahara-tests does)16:17
toskyand tempest.lib.cli supports both many of the project-specific clients ("cinder foo", not specifically manila but that's not a problem, there are some generic methods) and the osc client ("openstack foo bar")16:18
toskyI'd strongly recommend using that class and not implementing custom tests16:19
*** dviroel has joined #openstack-manila16:24
*** lpetrut has quit IRC16:52
*** brinzhang has quit IRC17:13
*** pcaruana has quit IRC18:09
*** theintern_ has quit IRC18:09
*** brinzhang has joined #openstack-manila18:25
*** brinzhang_ has quit IRC18:28
*** eharney has quit IRC18:54
*** pcaruana has joined #openstack-manila18:57
*** lpetrut has joined #openstack-manila19:30
*** eharney has joined #openstack-manila19:52
*** openstackgerrit has joined #openstack-manila20:44
openstackgerritVictoria Martinez de la Cruz proposed openstack/python-manilaclient master: Update stestr.conf to pick functional/osc tests  https://review.opendev.org/70203820:44
*** enriquetaso has quit IRC20:58
*** vhari has quit IRC21:18
dviroelYey, the "V" release is officially Victoria22:10
vkmc:D :D :D :D :D23:02
*** pcaruana has quit IRC23:35
lseki\o/23:39
lsekivkmc, maaritamm will take a look at the patch next week23:51

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!