*** brinzhang has joined #openstack-manila | 01:52 | |
*** brinzhang_ has joined #openstack-manila | 02:27 | |
*** brinzhang has quit IRC | 02:30 | |
*** brinzhang has joined #openstack-manila | 02:31 | |
*** brinzhang_ has quit IRC | 02:32 | |
*** brinzhang has quit IRC | 02:33 | |
*** brinzhang has joined #openstack-manila | 02:34 | |
*** brinzhang_ has joined #openstack-manila | 05:05 | |
*** brinzhang has quit IRC | 05:08 | |
*** brinzhang has joined #openstack-manila | 05:53 | |
*** brinzhang_ has quit IRC | 05:56 | |
*** lpetrut has joined #openstack-manila | 06:08 | |
*** lpetrut has quit IRC | 06:09 | |
*** lpetrut has joined #openstack-manila | 06:10 | |
*** brinzhang_ has joined #openstack-manila | 06:26 | |
*** brinzhang has quit IRC | 06:28 | |
*** gregwork has quit IRC | 06:42 | |
*** brinzhang has joined #openstack-manila | 06:54 | |
*** brinzhang_ has quit IRC | 06:58 | |
*** brinzhang_ has joined #openstack-manila | 07:04 | |
*** brinzhang has quit IRC | 07:07 | |
*** brinzhang has joined #openstack-manila | 07:08 | |
*** brinzhang_ has quit IRC | 07:09 | |
*** brinzhang has quit IRC | 07:10 | |
*** brinzhang has joined #openstack-manila | 07:10 | |
*** pcaruana has joined #openstack-manila | 07:53 | |
*** tosky has joined #openstack-manila | 08:12 | |
*** brinzhang_ has joined #openstack-manila | 08:29 | |
*** brinzhang has quit IRC | 08:33 | |
*** pcaruana has quit IRC | 08:46 | |
*** pcaruana has joined #openstack-manila | 08:53 | |
*** brinzhang has joined #openstack-manila | 10:35 | |
*** brinzhang_ has quit IRC | 11:50 | |
*** brinzhang_ has joined #openstack-manila | 11:50 | |
*** enriquetaso has joined #openstack-manila | 12:04 | |
*** enriquetaso has quit IRC | 12:05 | |
*** brinzhang_ has quit IRC | 12:11 | |
*** brinzhang_ has joined #openstack-manila | 12:11 | |
*** enriquetaso has joined #openstack-manila | 12:33 | |
*** pcaruana has quit IRC | 12:34 | |
*** pcaruana has joined #openstack-manila | 12:38 | |
*** trident has quit IRC | 13:13 | |
*** trident has joined #openstack-manila | 13:15 | |
*** vhari has joined #openstack-manila | 13:31 | |
*** theintern_ has joined #openstack-manila | 14:58 | |
*** theintern_ has quit IRC | 15:08 | |
*** eharney has joined #openstack-manila | 15:17 | |
*** theintern_ has joined #openstack-manila | 15:19 | |
maaritamm | Hi 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 |
---|---|---|
vkmc | maaritamm++ | 15:25 |
maaritamm | more 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 |
vkmc | I'll look right away | 15:25 |
*** josecastroleon has joined #openstack-manila | 15:25 | |
maaritamm | for 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/False | 15:25 |
maaritamm | there are different variations for order of the fields, capitalized field names etc for different commands | 15:26 |
maaritamm | I don’t mind trying to mach all of those details but just wanted to make sure it’s necessary :) | 15:26 |
vkmc | josecastroleon, o/ https://review.opendev.org/#/c/701229/ | 15:26 |
vkmc | lseki, also <3 | 15:26 |
maaritamm | at 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 output | 15:26 |
josecastroleon | hi | 15:26 |
tbarron | maaritamm: vkmc without looking in detail yet, my inclination is to say that if the old manila client is displaying this information in inconsistent ways then | 15:28 |
tbarron | there's nothing wrong with having the OSC client version display it in a more consistent fashion | 15:28 |
tbarron | the old manila behavior willl still be preserved when using it, or would that change? | 15:28 |
vkmc | tbarron, our worry was... what happens if the output of the client was being consumed in an automatized way | 15:29 |
tbarron | vkmc: so the old manila client behavior will change and that's the worry? | 15:29 |
vkmc | behavior is the same, output different | 15:29 |
tbarron | ok, but output is arguably behavior and that's the concer :) | 15:30 |
tbarron | conocern :) | 15:30 |
vkmc | yeah | 15:30 |
tbarron | I can't spell | 15:30 |
tbarron | How 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 |
maaritamm | but the old manila behaviour is still untouched and manila commands can be used as before in parallel, if that’s what you meant tbarron | 15:31 |
tbarron | maaritamm: and the old manila command will still work the same way, "untouched"? | 15:32 |
tbarron | If so, then I have no worries about having OSC output be more consistent, no one is using that yet. | 15:32 |
vkmc | that's true, osc manila is brand new and therefore transition from manilaclient to osc manila could be done in an ordered way | 15:33 |
maaritamm | vkmc, please correct me if im wrong | 15:33 |
vkmc | is not that we are breaking anything | 15:33 |
tbarron | OSC client isn't going to be 100% backwards-consistent with the old manila client anyways. | 15:33 |
vkmc | maaritamm, you are right | 15:34 |
tbarron | If 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 |
vkmc | yeah, I think it's a valid | 15:34 |
vkmc | thinking | 15:34 |
tbarron | In 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 |
vkmc | maaritamm, so we are fine, we can format the output as we consider :) make things look more consistent | 15:35 |
vkmc | tbarron, didn't know that osc has json/yaml capabilities | 15:35 |
tbarron | vkmc: maaritamm maybe take a look at how OSC represents fields like "is public" for other components. | 15:35 |
josecastroleon | i agree with tbarron, better to use json or yaml | 15:35 |
josecastroleon | for automation | 15:36 |
tbarron | I think there are public and private glance images for example. | 15:36 |
tosky | vkmc: the unified, multi-format output of osc is one of the selling points | 15:36 |
tbarron | just for least surprise. | 15:36 |
vkmc | tosky, hah, nice :) | 15:36 |
vkmc | tosky, they had me on "one client to rule them all" | 15:36 |
tosky | when I discovered that I could consistently use openstack <something> show <id> -f value -c <column> and print a single value... | 15:37 |
tosky | I could clean up a lot of scripts | 15:37 |
tosky | of course things can be improved, but... | 15:37 |
tbarron | tosky: yeah, it's awesome not to have to do " | awk '{print $N}' " and try too figure out the right value of $N everywhere | 15:41 |
tosky | as part of this effort, are you writing some functional tests? There is a class in tempest that can be used for this | 15:42 |
tbarron | tosky: great idea, but are there functional tests for osc cinder for example? | 15:43 |
tosky | cinder 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 |
tosky | and sahara uses it for its unified client: https://opendev.org/openstack/sahara-tests/src/branch/master/sahara_tempest_plugin/tests/cli | 15:43 |
tosky | tbarron: you want to be better than cinder, I guess | 15:43 |
tbarron | tosky: oh i'm just trying to determine the various heights of the high jump bar | 15:44 |
tbarron | vkmc: 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 stage | 15:45 |
vkmc | tbarron, sounds good | 15:46 |
tosky | tbarron: if you want to switch, you want to be sure that the new client is working properly | 15:46 |
vkmc | we are also looking into generating the correct docs | 15:47 |
tosky | it will definitely save time when some poor quality engineer will have to test it :P | 15:47 |
tbarron | tosky: agree and it should be part of Definition of Done for this work | 15:47 |
maaritamm | tbarron, sure, will do | 15:47 |
vkmc | already in a convo about that in #openstack-sdks | 15:47 |
vkmc | maaritamm, if you wanna join, openstackclient stuff is discussed in #openstack-sdks | 15:48 |
vkmc | so there is people that knows about the openstackclient *itself* | 15:48 |
tbarron | vkmc: 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 in | 15:49 |
tbarron | https://review.opendev.org/#/c/698848/ and do a functional test pass on stuff in followup reviews | 15:49 |
tbarron | tosky: thanks much for the functional test pointers! I've never been delighted with the current functional test approach taken in manila and the | 15:51 |
tbarron | sahara examples look cleaner | 15:51 |
tbarron | vhari: ^^^ :) | 15:54 |
maaritamm | tbarron, cool, I’ll start getting more familiar with the functional testing | 15:58 |
maaritamm | for 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 comments | 15:59 |
maaritamm | plus 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 correctly | 16:01 |
vhari | tbarron, nice approach and a time saver :) | 16:01 |
vhari | tosky, if I read this correctly, if we transition to osc ^^ , will require manila plugin updates | 16:05 |
vkmc | maaritamm, I think it's a good design decision, I see other services followed the same approach | 16:07 |
tosky | vhari: uh, which kind of updates? | 16:07 |
vhari | tosky, any change (updates. additions) resulted from manilaclient to osc manila transition | 16:09 |
tosky | vhari: then the other question is: which plugin? Tempest plugin? | 16:10 |
vhari | tosky, yes ex: manila-tempest-plugin | 16:11 |
tosky | so, this is a bit unrelated to osc or the old client | 16:12 |
tbarron | vhari: tempest willl use the api rather than manila or osc clients to interact with manila, so no impact there | 16:12 |
tosky | oh, that thing | 16:12 |
tosky | sorry, completely forgot about that: tempest clients are independent code, for good reasons | 16:13 |
vhari | tbarron, agreed, api tests should not be affected... however Liron was working on some scripts which used the cli.. | 16:14 |
vhari | tbarron, will share this info with him as a heads up | 16:15 |
tosky | vhari: 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 |
tosky | and 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 |
tosky | I'd strongly recommend using that class and not implementing custom tests | 16:19 |
*** dviroel has joined #openstack-manila | 16:24 | |
*** lpetrut has quit IRC | 16:52 | |
*** brinzhang has quit IRC | 17:13 | |
*** pcaruana has quit IRC | 18:09 | |
*** theintern_ has quit IRC | 18:09 | |
*** brinzhang has joined #openstack-manila | 18:25 | |
*** brinzhang_ has quit IRC | 18:28 | |
*** eharney has quit IRC | 18:54 | |
*** pcaruana has joined #openstack-manila | 18:57 | |
*** lpetrut has joined #openstack-manila | 19:30 | |
*** eharney has joined #openstack-manila | 19:52 | |
*** openstackgerrit has joined #openstack-manila | 20:44 | |
openstackgerrit | Victoria Martinez de la Cruz proposed openstack/python-manilaclient master: Update stestr.conf to pick functional/osc tests https://review.opendev.org/702038 | 20:44 |
*** enriquetaso has quit IRC | 20:58 | |
*** vhari has quit IRC | 21:18 | |
dviroel | Yey, the "V" release is officially Victoria | 22:10 |
vkmc | :D :D :D :D :D | 23:02 |
*** pcaruana has quit IRC | 23:35 | |
lseki | \o/ | 23:39 |
lseki | vkmc, maaritamm will take a look at the patch next week | 23:51 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!