19:01:40 <catherineD> #startmeeting refstack
19:01:41 <openstack> Meeting started Tue May 17 19:01:40 2016 UTC and is due to finish in 60 minutes.  The chair is catherineD. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:45 <openstack> The meeting name has been set to 'refstack'
19:01:47 <rockyg> o/
19:01:50 <andrey-mp> o/
19:02:05 <luzC> o/
19:02:32 <pvaneck> o/
19:02:33 <catherineD> Hello I just end someone else meeting (murano) hope it is OK ... no activities for the last 10 mins
19:02:56 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-16-05-17
19:03:43 <catherineD> luzC: Welcome
19:03:56 <catherineD> to RefStack meeting ...
19:04:13 <luzC> thanks Catherine
19:04:20 <luzC> :D
19:04:27 <catherineD> Except for rockyg: I think we all have met luzC: at Austin
19:04:44 <rockyg> Oh, darn!
19:04:57 <rockyg> Next time!
19:04:59 <catherineD> luzC: is from Intel Brazil
19:05:18 <rockyg> kewl!
19:05:21 <luzC> intel us actually
19:05:31 <catherineD> hope the time is OK for luzC:
19:05:35 <catherineD> oh sorry
19:05:51 <catherineD> luzC: what time zone for you?
19:06:21 <catherineD> #topic Product registration
19:06:22 <luzC> central time... I'm in San Antonio, TX
19:07:17 <catherineD> andrey-mp: thx for https://review.openstack.org/#/c/315743/
19:07:44 <catherineD> #link everyone please review  https://review.openstack.org/#/c/315743/
19:08:23 <catherineD> #topic Vendor Guidelines
19:09:19 <catherineD> #action catherineD: will  submit patch for the REST API
19:09:28 <catherineD> and may table definition if needed
19:09:40 <andrey-mp> good :)
19:09:51 <pvaneck> i started separating vendor UI and product UI. will submit patches with andrey as co-author
19:09:57 <catherineD> pvaneck: Allow passing of a custom guideline URL in report page UI
19:10:02 <dwalleck> o/ sorry I'm late
19:10:17 <catherineD> dwalleck: thx for joinning
19:10:51 <catherineD> agenda https://etherpad.openstack.org/p/refstack-meeting-16-05-17
19:11:22 <catherineD> pvaneck: could you give an update on item 2.3
19:11:29 <pvaneck> so i worked on this to get a prototype, and the issue im running into with UI-only custom guidelines is CORS blocking js from accessing specified external files.
19:12:32 <pvaneck> apprently you can also use JSONP requests to bypass CORS, but the hosting server would have to support JSONP callbacks
19:13:47 <catherineD> andrey-mp: what do you think?
19:14:00 <pvaneck> so it seems like the refstack API server would have to be involved somehow
19:14:31 <catherineD> pvaneck: and that is what we do not want right?
19:15:28 <pvaneck> i dont know what we want. I'm just saying UI-only custom guideline passing isn't really feasible with CORS restrictions
19:16:40 <andrey-mp> catherineD: its not good to involve API server. but I don't have solutions right now...
19:17:24 <catherineD> pvaneck: what are our options .. since we have already decided to coloacte both API and UI
19:18:41 <andrey-mp> pvaneck: does refstack server support JSONP?
19:18:57 <catherineD> would it be the same issues when we allow custom guidelines?
19:19:27 <pvaneck> andrey-mp: don't believe so
19:19:30 <dwalleck> That should be a framework thing. I've enabled CORS for APIs before, but not with any Python framework
19:19:46 <andrey-mp> catherineD: no. custom guidelines will be handled by API server
19:19:57 <catherineD> andrey-mp: ic
19:21:25 <catherineD> If RefStack server does not support JSONP ... then there is no other alternative then?
19:21:44 <pvaneck> doesnt matter if refstack server supports JSONP
19:22:14 <andrey-mp> catherineD: it is a strange solution to ask API server to download something ))
19:22:22 <pvaneck> we just cant expect servers that host arbitrary guidelines to always support jsonp
19:22:57 <catherineD> pvaneck: agree
19:23:13 <andrey-mp> if we have problem that can't be solved at this 'layer' we should move one layer 'up'....
19:24:18 <andrey-mp> I mean that maybe we can discuss another way to view test results against custom guideline
19:24:34 <catherineD> May I suggest that we move on for now and revisit this topic later or in #refstack if we run out of time ...
19:24:42 <pvaneck> so ultimately, the refstack server will be the one making the external request to get the JSON?
19:24:52 <andrey-mp> for example: user registers own guideline and then views test results against it
19:25:30 <andrey-mp> pvaneck: yes. like it does for DefCore gudelines
19:25:55 <catherineD> I really want to doscuss topic 4 since both luzC: and dwalleck: are here
19:26:39 <andrey-mp> ok. lets move on
19:26:50 <catherineD> let me jump to topic #4
19:27:01 <catherineD> #topic refstack-client
19:27:42 <catherineD> dwalleck: and luzC: I think you have a list of things for refstack-client improvement
19:28:08 <catherineD> that we did not have a chance to discuss at the summit
19:28:15 <dwalleck> catherineD: I have some thoughts that I'm still fleshing out, but I can share
19:28:31 <catherineD> sure please
19:29:17 <dwalleck> slowrie and I were helping with the new 'tempest run' command during mitaka, and one of the things we noticed is that the new runner had some of the capabilities as refstack client
19:29:19 <catherineD> https://etherpad.openstack.org/p/refstack-newton-summit  line 112 -- 127
19:29:19 <andrey-mp> I have :) - refstack-client should have option to define cloud_id and send it to API server
19:29:56 <dwalleck> For example, the normalizing of test ids actually exists in os-testr already
19:30:25 <catherineD> dwalleck: one of the action item for us is to use ostestr
19:31:00 <dwalleck> And it was a bit of a pain point that I couldn't use my existing Tempest install with refstack. Essentially, we just ended up using the upload results functionality
19:31:36 <catherineD> dwalleck: reason?
19:31:56 <andrey-mp> dwalleck: you can. just make symbolic link to your tempest install directory
19:32:06 <andrey-mp> istead of '.tempest'
19:32:09 <dwalleck> catherineD: The plan (as I understand it) is that os-testr will go away
19:32:30 <catherineD> dwalleck:  really?
19:33:07 <andrey-mp> dwalleck: but another question - wich virtual env you want to use...
19:33:10 <dwalleck> catherineD, andrey-mp: Tempest isn't meant to be used anymore uninstalled. The command line experience now expects Tempest to be an installed package
19:33:15 <catherineD> Matt joined our refstack meeting last week and I thought using ostesr was the recommendation
19:34:08 <dwalleck> But is creating a virtualenv something refstack client should really be worried about? Right now it does a lot of work
19:35:00 <dwalleck> catherineD: ostestr would be a good short term solution until tempest run is done. They both use the same logic internally to handle test ids
19:35:10 <andrey-mp> dwalleck: refstack client runs 'run_tempest.sh' now. and this script creates virtual env
19:35:20 <catherineD> dwalleck: I run multiple version of refstack-client in one server .. using  virtual env allow me to do that
19:35:44 <catherineD> dwalleck: If it is short term we should stick to what we have now
19:36:53 <catherineD> dwalleck: when do we expect to have "tempest run" ready?
19:37:19 <dwalleck> catherineD: I asked slowrie. Someone else is on the task, but it's targeted for newton-2
19:37:51 <dwalleck> I think mtreinish put it at the top of the list of OpenStack QA priorities
19:37:52 <catherineD> dwalleck: in that case .. I do not see a reason for us to update to ostestr ?
19:38:17 <catherineD> dwalleck: thanks for the info
19:38:53 <catherineD> back to the topic of using existing tempest
19:39:21 <dwalleck> catherineD: The high level idea I had was to better align with the Tempest cli
19:39:37 <catherineD> dwalleck: I am all for that
19:39:48 <dwalleck> Integrating Tempest run and using Tempest workspaces
19:40:13 <catherineD> dwalleck: that is a goal after newton-2?
19:41:07 <dwalleck> catherineD: That was my suggestion. But yes, we couldn't finalize anything until the feature is done. I brought up the question now to see if there was any interest
19:41:22 <dwalleck> That way during the Tempest Run development, RefStack client could be kept in mind
19:41:57 <dwalleck> Or else find out if everyone thought if things are fine as is :-)
19:42:20 <catherineD> dwalleck: defintely is our interest to align with Tempest but still being able to keep refstack-client's funtions and feature
19:42:54 <andrey-mp> as mtreinish we must use ostestr
19:42:56 <catherineD> dwalleck: definitely a spec or prototype would help
19:43:22 <catherineD> andrey-mp: but if it is going away in newton-2 .. why should we upgrade for short term?
19:43:51 <dwalleck> catherineD: I totally agree with you with regards to functions and features
19:44:05 <andrey-mp> catherineD: I think that we should ask mtreinish why we should use tool that is going away...
19:44:20 <catherineD> andrey-mp: good idea .. will do that
19:44:36 <dwalleck> os-testr should be a drop in replacement for testr
19:44:53 <catherineD> dwalleck: we use run_tempest
19:45:06 <catherineD> which use testr of course
19:45:15 <dwalleck> But the point was that since os-testr/tempest run handles normalizing test ids, then that's a problem refstack shouldn't have to worry about
19:45:22 <andrey-mp> ostestr uses testr
19:45:43 <andrey-mp> (as I know)
19:46:11 <dwalleck> ostestr subprocesses out to testr. It just does some magic with test lists and other capabilities first
19:46:49 <catherineD> dwalleck: agree the upgrade for short term should hava a very compelling reason other than dedup
19:47:01 <andrey-mp> dwalleck: do you know why ostestr goes away? and what next tool for use?
19:48:04 <dwalleck> andrey-mp: I shouldn't say it's going away. I'm sure it will still exist. The built-in tempest run command is going to be the default way to run Tempest tests
19:48:58 <catherineD> dwalleck: OK we will check with mtreinish
19:49:01 <dwalleck> I don't want to eat up too much of the meeting time. Would it make sense for me to write up a short list of possible improvements (with justifications) and then discuss if they make sense?
19:50:02 <catherineD> dwalleck: sure a spec or prototype code (like what andrey-mp: did in https://review.openstack.org/#/c/281679/ for UI model) would really help
19:50:38 <catherineD> dwalleck:  align with Tempest is our goal too ... so thank for bring up the topic
19:50:50 <rockyg> dwalleck, ++
19:50:53 <dwalleck> catherineD: will do, thanks!
19:51:05 <catherineD> dwalleck: Thank  YOU!
19:51:21 <catherineD> moving on ..
19:51:25 <catherineD> #topic Vendor/Product related UI
19:51:39 <catherineD> pvaneck: any update?
19:51:57 <hogepodge> o/ sorry for being late.
19:51:59 <pvaneck> as stated earlier, i already began splitting it out. i will have patches up later
19:52:35 <rockyg> hi, hogepodge!
19:52:55 <catherineD> Hi hogepodge: we just discussed that os-testr is a short term solution ... we need to check
19:53:13 <catherineD> pvaneck: thank you
19:53:30 <hogepodge> Ok, I'll catch the backlog
19:54:10 <catherineD> hogepodge: we need to check with mtreinish ...
19:54:57 <catherineD> andrey-mp: regarding refstack-client to allow passing in cloud-id
19:55:16 <catherineD> I thought that we have that option already?
19:55:18 <hogepodge> oomichi is new ptl so him too
19:55:35 <catherineD> hogepodge: ok
19:56:02 <mtreinish> catherineD: are you asking if ostestr is going away?
19:56:03 <andrey-mp> catherineD: we don't have such option. we discussed to introduce this option.
19:56:17 <mtreinish> I can say ostestr isn't going anywhere
19:56:32 <catherineD> mtreinish: yes dwalleck: said that it will be replaced with tempest run
19:57:14 <mtreinish> we are working on a tempest run command which will be similar to ostestr but have tempest specific knowledge and be aware of tempest specifics
19:57:22 <mtreinish> but the ostestr workflow will always work
19:57:55 <mtreinish> catherineD: this is the in progress spec for that effort: https://review.openstack.org/269934
19:58:27 <rockyg> thanks, mtreinish!
19:59:40 <catherineD> dwalleck: indicate earlier in this meeting that we should upgrade to use  tempest run  when it is available in newton-2 ..
20:00:00 <mtreinish> catherineD: you can do that, and ight make certain things easier, but it's not a requirement to do that
20:00:08 <catherineD> I was wondering why should we upgrade not to ostestr and then again to tempest run
20:00:25 <catherineD> not --> now
20:00:44 <catherineD> we need to end this meeting
20:00:52 <catherineD> could we discuss a bit in #refstack
20:00:57 <catherineD> #endmeeting