17:00:03 <hogepodge> #startmeeting refstack
17:00:04 <openstack> Meeting started Tue May 15 17:00:03 2018 UTC and is due to finish in 60 minutes.  The chair is hogepodge. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:07 <openstack> The meeting name has been set to 'refstack'
17:00:20 <mguiney> o/
17:00:40 <hogepodge> #link https://etherpad.openstack.org/p/refstack-meeting-18-05-15  agenda
17:01:36 <hogepodge> going to give everyone a few minutes
17:02:31 <tosky> o/
17:03:42 <hogepodge> #chair tosky
17:03:43 <openstack> Current chairs: hogepodge tosky
17:03:55 <hogepodge> #topic python-tempestconf
17:04:30 <hogepodge> take it away tosky
17:04:57 <tosky> as you may noticed on the IRC channel, there was a lot of work
17:05:21 <tosky> the main goal being addressed is one of the stories coming from the PTG, namely
17:05:44 <tosky> #link https://storyboard.openstack.org/#!/story/2001696 Refactor tempestconf in order to integrate with refstack_client tool
17:06:03 <tosky> chandankumar is working on
17:06:06 <tosky> #link https://review.openstack.org/#/c/541273/ Generate tempest.conf automatically using refstack-client
17:06:13 <tosky> and other changes are related to it, for example:
17:06:19 <chandankumar> tosky: the above is ready, still depends on https://review.openstack.org/#/c/567820/ and https://review.openstack.org/#/c/562672/
17:06:26 <tosky> #link https://review.openstack.org/#/c/567798/ Make tempestconf easier to use as an library
17:06:32 <tosky> chandankumar: and also ^^
17:06:39 <tosky> chandankumar: because it will change the API a bit
17:07:03 <tosky> uhm, sorry, I messed up the review numbers
17:07:13 <chandankumar> tosky: the devstack zuul job is failing due to permission issue to write tempest.conf file in devstack job
17:07:25 <chandankumar> tosky: the code is ready for testing, if we pull the patches
17:07:58 <tosky> #undo
17:07:59 <openstack> Removing item from minutes: #link https://review.openstack.org/#/c/567798/
17:08:04 <tosky> #link https://review.openstack.org/#/c/562672/ Make tempestconf easier to use as an library
17:08:36 <tosky> the latter needs a rebase after other changes
17:08:53 <tosky> chandankumar: yes, and the other patches are not (totally) ready
17:08:53 <chandankumar> One help is needed here how to use pip3 here https://review.openstack.org/#/c/541273/42/tox.ini@14 when tox -e py35 is called
17:09:41 <chandankumar> hogepodge: there was one more confusion related --os-cloud flag
17:10:18 <chandankumar> so when refstack-client config --os-cloud <cloud name> will be used does, it needs to generate tempest account file?
17:10:37 <chandankumar> since we donot to set expose credentials in tempest.conf
17:10:42 <tosky> chandankumar: we can discuss about it later, are trying to install a package from git master?
17:10:55 <chandankumar> tosky: yup
17:11:01 <hogepodge> tempest will need to get the credential from somewhere
17:11:01 <luzC_> o/
17:11:11 <hogepodge> I think the choice is either tempest.conf or accounts.yaml
17:11:23 <hogepodge> accounts.yaml is what isolates the credentials from tempest.conf
17:12:44 <hogepodge> chandankumar: I'm not sure how to switch between pip and pip3, is there a variable that can be set to choose?
17:13:57 <chandankumar> when os-cloud is used, we are taking credentials from os-client-config and dumping it in tempest.conf using tempestconf, the question stays the same, do we need to create accounts.yaml or better not expose --os-cloud with refstack-client?
17:15:03 <tosky> I guess that we are talking about
17:15:17 <tosky> #link https://storyboard.openstack.org/#!/story/2001693 Generate accounts.yaml when --os-cloud is used with python-tempestconf
17:15:21 <tosky> ?
17:15:29 <chandankumar> hogepodge: that would be doable adding small script under command section to export pip3 when py3 is ised
17:15:31 <chandankumar> tosky: yes
17:16:12 <tosky> chandankumar: re pip3: I think that the release team would probably advise to release a version of tempestconf and depend on it
17:16:42 <chandankumar> tosky: that is also another option, I will check with them
17:16:46 <tosky> with the normal requirements.txt
17:16:52 <tosky> but yes, better check with them
17:16:57 <hogepodge> +1 to that
17:18:16 <luzC_> chandankumar: refstack requires 'test_accounts_file' to be set up on tempest.conf
17:18:51 <luzC_> in this case accounts.yaml must exist or refstack-client will throw an exception
17:19:04 <mguiney> fortunately, there's already tooling that generates that
17:19:19 <mguiney> so the generation hopefully won't be awful
17:19:22 <tosky> chandankumar: about --os-cloud: I think we may have discuss it already and I hope I'm not contradicting myself, but:
17:19:49 <tosky> why should not we create accounts.yaml? What do you mean by "expose --os-cloud"?
17:19:55 <tosky> what is the problem that you foresee?
17:20:27 <hogepodge> I don't see any problem. If an cloud file exists, we have the necessary information to populate both accounts.yaml with credentials and tempest.conf with endpoints.
17:21:08 <luzC_> I'm looking at refstack-client if there is no account.yaml it can work with 'username' and 'password' under 'identity' section at tempest.conf
17:23:06 <chandankumar> tosky: hogepodge we can create accounts.yaml from os-cloud, tosky last time we discussed on that but we were not able convince why we need accoints.yaml from os-cloud as tempest account-generaotr already does that
17:23:07 <hogepodge> yeah, refstack-client isn't enforcing this. it's all tempest
17:23:23 <chandankumar> that's why i wanted to confirm
17:24:37 <chandankumar> that's it from myside
17:24:55 <hogepodge> I'm confused as to why this is an issue. If we have tooling to generate the config we need it should all be fine. No need to reproduce what's already there.
17:25:11 <tosky> uhm, tempest account generator creates new users, so it does not work if you have no admin credentials
17:25:18 <tosky> at least checking https://docs.openstack.org/tempest/latest/account_generator.html
17:25:34 <hogepodge> Oh yeah, it's different use cases.
17:25:47 <chandankumar> tosky: yup it does not work with non-admin credentials
17:25:48 <hogepodge> With tempest the presumption is your credentials are non-admin.
17:25:54 <mguiney> right. i forgot you needed admin for that
17:26:14 <chandankumar> with case of os-cloud, we have already credentials
17:26:23 <hogepodge> So you should pull the credentials from the cloud config and populate accounts.yaml and tempest.conf with the correct values.
17:26:45 <tosky> chandankumar: we don't have necessarily admin credentials even with os-cloud
17:27:04 <tosky> the credentials available through --os-cloud may not be admin
17:27:06 <chandankumar> tosky: yes
17:28:19 <tosky> we could discuss if the tempest account generator can be used internally by tempestconf to replace the custom code which creates the account, but that's unrelated to the present discussion
17:29:42 <chandankumar> tosky: so, i think we need custom code to generate account.yaml from os-cloud in python-tempestconf
17:30:21 <hogepodge> I think we're all on the same page now. custom code needed to generate account.yaml and tempest.conf from a cloud config file
17:31:10 <tosky_> umpf, network
17:31:25 <tosky_> sorry for the possible duplicate
17:31:55 <tosky_> chandankumar: not just from os-cloud; from the information that tempestconf has; you could pass the credentials from the command line too
17:33:52 <hogepodge> ok, we good on this?
17:33:57 <tosky_> I would say yes
17:34:00 <chandankumar> tosky_: so if we are using os-cloud or sourcing keystonerc file, in both cases, if accounts.yaml is need we can create
17:34:06 <chandankumar> yes we are good
17:34:30 <tosky_> chandankumar: yes, the source is not really relevant
17:35:21 <hogepodge> #topic refstack
17:35:48 <chandankumar> thanks hogepodge tosky_ mguiney luzC_ for the inputs:-)
17:36:00 <hogepodge> chandankumar: of course :-)
17:36:06 <mguiney> o7
17:36:15 <hogepodge> some other refstack-clients patches in flight
17:36:47 <hogepodge> luzC_: do you want to cover these?
17:36:50 <hogepodge> #link https://review.openstack.org/#/c/564080/ Remove usage of tempest install_venv scripts
17:37:02 <hogepodge> #link https://review.openstack.org/#/c/562956/ Refstack-client should use stestr for tempest testing
17:37:58 <hogepodge> the first looks straight forward to me
17:39:45 <hogepodge> looks like the second needs a bit of testing, but also looks like it covers old and new cases
17:40:17 <hogepodge> I can try to test next week once my summit obligations are out of the way (need to finish writing my talk...)
17:40:39 <hogepodge> mguiney: if you have a chance to user test them that would be great.
17:41:01 <mguiney> can do!
17:42:08 <hogepodge> On RefStack, new guideline rendering merged
17:42:10 <hogepodge> #link https://review.openstack.org/#/c/547246/ New Capability Sources (merged)
17:42:59 <hogepodge> We should decide if we want to release now with that capability (and major version bump, since we changed an undocumented but still public API), or wait until the subunit patches land
17:43:09 <hogepodge> #link https://review.openstack.org/#/c/530681/ RefStack Subunit Upload API
17:43:19 <hogepodge> #link https://review.openstack.org/#/c/538786/ RefStack Client
17:43:23 <hogepodge> mguiney: any comments?
17:44:10 <mguiney> still in flight, working through a few issues
17:45:01 <mguiney> oh wait no, thats the other one
17:45:25 <mguiney> im considering just modifying the existing subunit handling, rather than building a whole new thing
17:45:38 <hogepodge> yeah?
17:45:42 <mguiney> it ocxurs to me that a full rebuold isnt neccesaary
17:46:06 <mguiney> i still need to finish teating that hypothesis, but we do have a subunit upload
17:46:28 <mguiney> *testing. apologies, tiny keyboard
17:47:32 <mguiney> but we already have a subunit upload, its just that it converts immediately to test result, which it shoulsnt newd to do, since we are switching over regardless
17:47:50 <mguiney> *shouldnt need
17:48:53 <hogepodge> ah, ok
17:50:03 <hogepodge> I thought refstack-client converted it client side. Where is the code to handle it server side?
17:50:59 <mguiney> its in the api utils
17:51:57 <mguiney> the core coversion utilities, that is
17:52:14 <mguiney> it makes more sense to convert it serverside, i think
17:52:40 <mguiney> otherwise youd have to send two separate payloads
17:54:22 <hogepodge> ok. can you send pointers to me?
17:54:29 <mguiney> plus, if we maintain the front facing part of the clientside util, there will be no appreciable change for end users
17:54:38 <mguiney> absolutely.
17:55:32 <hogepodge> just a few minutes left
17:55:56 <hogepodge> last items, npm update, still need to work out a strategy for getting our javascript house in order
17:56:08 <hogepodge> #link https://review.openstack.org/#/c/559459/
17:56:33 <hogepodge> Once all of these patches are in, we're probably going to put the server into maintenance mode unless there's a need for new features.
17:56:35 <mguiney> so the method suggested to me was to use webpack as well as one of its plugins
17:57:00 <hogepodge> Ok, cool on that.
17:57:15 <mguiney> it looks like that may not even be neccessary, i'm just hunting down a few JS errors that are causing rendering issues
17:57:16 <hogepodge> That seems like a common solution
17:57:57 <hogepodge> Last three minutes, who will be at the summit?
17:58:00 <mguiney> i can try and make it work, but i'm a little baffled by the use of so heavy a tool to (as far as i can tell) simply copy the files into a more appropriate location
17:58:07 <hogepodge> tosky_: chandankumar: luzC_ ?
17:58:33 <hogepodge> mguiney: because why do something simple when you can use a framework to obscure it! ;-)
17:58:35 <tosky> no summit for me
18:00:25 <mguiney> bummer
18:01:54 <hogepodge> ok, that's it. Thanks everyone!
18:01:56 <hogepodge> #endmeeting