19:00:21 <catherineD> #startmeeting refstack
19:00:22 <openstack> Meeting started Tue May 10 19:00:21 2016 UTC and is due to finish in 60 minutes.  The chair is catherineD. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:25 <openstack> The meeting name has been set to 'refstack'
19:00:33 <hogepodge> o/
19:00:37 <sslypushenko> o/
19:00:38 <docaedo> o/
19:00:40 <GheRivero> o/
19:00:59 <catherineD> hello everyone
19:01:15 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-16-05-10
19:01:20 <pvaneck> o/
19:01:51 <rockyg> o/
19:01:55 <andrey-mp> o/
19:02:32 <catherineD> Agenda https://etherpad.openstack.org/p/refstack-meeting-16-05-10
19:02:46 <catherineD> #topic     Product registration
19:03:07 <catherineD> so the spec had merged ..
19:03:22 <catherineD> andrey-mp: ready for implementation ..
19:03:48 <andrey-mp> 1.2. I've started to extract code from my big review but I did't do it today
19:04:09 <andrey-mp> I think that I will do it this week
19:04:22 <catherineD> andrey-mp: np  at all ... thanks!
19:04:23 <catherineD> moving on
19:04:29 <andrey-mp> ok
19:04:34 <catherineD> #topic Vendor/Product related UI
19:04:49 <catherineD> #topic Prototype: http://52.49.129.72:8000/#/
19:05:39 <catherineD> UI implementations should be done after product registration ..
19:06:06 <catherineD> andrey-mp: for UI implementatuon .. may I suggest that we implement it in 2 phases
19:06:22 <andrey-mp> sure
19:06:23 <catherineD> phase 1: UI for vendor/product
19:06:41 <catherineD> phase 2: Guideline related ...
19:07:11 <hogepodge> The guideline stuff is confusing, and way outside the mission statement of the project.
19:07:12 <andrey-mp> yeah, it would be good
19:07:35 <andrey-mp> and we don't have needed REST API for that guideline UI
19:07:42 <catherineD> hogepodge: agree
19:07:58 <catherineD> #link RefStack mission statement https://github.com/openstack/governance/blob/edb403330e8adf5e9a37dcade4c6058934965db2/reference/projects.yaml#L3577
19:08:28 <andrey-mp> catherineD: I thought that someone can get code from my big review ( https://review.openstack.org/#/c/281679/ ) and make patchset for UI
19:09:02 <catherineD> based on the stated mission statement ... we may need to consult with TC on advise going forward
19:09:08 <catherineD> andrey-mp: we can do that
19:09:18 <andrey-mp> great!
19:09:50 <andrey-mp> I will update this review after right changes for product REST API
19:10:05 <catherineD> any other thoughts on this subject ..
19:10:35 <catherineD> moving on ...
19:10:45 <catherineD> #topic Vendor Guidelines
19:12:20 <catherineD> hogepodge: just to clarify ... RefStack will allow users to create own private Guidelines ... whether the private Guidelines will be visible to the public or not needs further discussion
19:12:52 <hogepodge> Right now, based on the prototype, it's a mess. There's no differentiation between vendor guidelines and DefCore guidelines.
19:12:53 <catherineD> Do we need a new DB table to store private Guideline releated info?
19:13:06 <hogepodge> It's exactly the problem I was concerned about in Austin.
19:13:45 <sslypushenko> hogepodge:  We will hide nonDefcore guidelines by defalt
19:13:56 <hogepodge> Plus, there's been a lot of discussion lately about community managed data. It's been a mess. The wiki is often out of date and filled with bad data or spam, driverlog is also hopelessly out of date (except for cinder drivers)
19:14:14 <hogepodge> Curation is a real problem with these sorts of things.
19:14:29 <catherineD> hogepodge: we discuss about that we may not have an other Prototype but for sure we will review with you before any merge ..
19:14:32 <hogepodge> sslypushenko: I see code to make is visible, though, which is a huge problem
19:14:46 <hogepodge> s/make is/make it/
19:15:19 <sslypushenko> hogepodge:  Code is not a data
19:15:20 <hogepodge> meanwhile there are real UI issues for vendors and products while this additional guideline work is being pushed through
19:15:35 <catherineD> hogepodge: it won't be until we reach agreement with all parties ... this is also the reason I want to have the UI implemented in 2 phases
19:16:35 <catherineD> hogepodge: no vendor/product UI code will be merged without your review ...
19:17:04 <pvaneck> I think we can at least implement the idea of passing in a custom guideline url in the report page ui without having to worry about server stuff
19:17:10 <hogepodge> and defcore working group guidance please, from markvoelker and eglute
19:17:23 <catherineD> hogepodge: yes we will
19:17:40 <catherineD> pvaneck: thx for remidning us on this
19:18:04 <catherineD> pvaneck: could you add that topic to the agenda .
19:18:24 <pvaneck> for today?
19:18:25 <sslypushenko> hogepodge: I think we should implement extra guidelines in the way, which does not cause user confusion and does not require curation
19:19:06 <catherineD> hogepodge: as pvaneck: indicate passing in a custom guideline will help  ... plus user can use that to view the DefCor next.json file
19:19:22 <catherineD> pvaneck: yes please
19:20:13 <sslypushenko> hogepodge:  But from my point of view, we definitely need something like extra guidelines to involve community in DefCore processes
19:20:16 <andrey-mp> catherineD: but this will complicate RefStack UI...
19:20:18 <catherineD> back to the technical side ... do we need a db table for third party guideline ?
19:20:46 <sslypushenko> catherineD:  I don't think so
19:21:06 <catherineD> andrey-mp: I don't think so ... perhaps let pvaneck: put in something for us to discuss next week?
19:21:36 <andrey-mp> catherineD: this is two ideas - let UI do something with results and privided URL and store third party guidelines
19:21:48 <catherineD> sslypushenko: you don't think we need db table right?
19:22:34 <andrey-mp> catherineD: I think that API server needs additional table where we can store information
19:22:40 <sslypushenko> we should keep all guidelines in the single db table
19:22:49 <catherineD> andrey-mp: yea the result page will have a text box foruser input Guideline which is not persisted in RefStack
19:22:56 <hogepodge> sslypushenko: sure, but it's early in the game to make it a central feature. Get the stuff in the mission right.
19:23:03 <catherineD> sslypushenko: that means that we need a table
19:23:32 <andrey-mp> because right now we don't have tables for guidelines
19:23:33 <hogepodge> sslypushenko: I like the idea of external guidelines to help project leaders guide us on what they see as the most important interoperable features. Could be very powerful in helping DefCore working group on building out future guidelines
19:23:43 <sslypushenko> hogepodge:  agreed, but we should thing at least on one step ahead
19:24:12 <sslypushenko> catherineD:  yeap, we should have a table for guidlines
19:24:15 <hogepodge> sslypushenko: code is being written one step ahead though
19:24:47 <catherineD> sslypushenko: ok
19:25:14 <sslypushenko> hogepodge: I'd say, not even on one)
19:25:15 <andrey-mp> hodepodge: code and prototype is a thing for discussion
19:25:23 <catherineD> if we have a table we will need REST API to access the data ...
19:26:04 <andrey-mp> catherineD: in my big review you can find table definition and suggested REST API
19:26:30 <catherineD> OK I will write spec to add a table and REST API for Guidelines
19:27:06 <andrey-mp> yeah, please let me know in review (or email) if any quiestions you will have
19:27:32 <catherineD> #action All REST Guidelines related REST API and UI patches should be reviewd by the DefCore team
19:27:38 <sslypushenko> catherineD:  It is pretty simple peace of data... we need only store a url on guideline with some meta info
19:27:42 <catherineD> andrey-mp: I will thanks
19:28:04 <sslypushenko> exactly like andrey-mp did in  https://review.openstack.org/#/c/281679/21/refstack/db/sqlalchemy/models.py
19:28:05 <catherineD> sslypushenko: I think so
19:28:48 <catherineD> anything else ...
19:29:10 <catherineD> next topic
19:29:23 <catherineD> #topic RefStack client
19:29:37 <andrey-mp> new scheme definition? or it is a DefCore meeting related?
19:29:56 <catherineD> andrey-mp: that is DefCore
19:29:59 <andrey-mp> ok
19:30:20 <catherineD> there will be a DefCore meeting tomorrow
19:31:14 <hogepodge> DefCore meetings will be low action for the next two weeks. Mark and Egle are both PTL right now.
19:31:59 <catherineD> Daryl added a wish list of refstack-client improvement during Austin meeting ... but he can not attend today ... so we will revisit this topic next week
19:32:58 <hogepodge> #link refstack-client patch to match defcore removal of generated test lists https://review.openstack.org/#/c/314648/
19:33:55 <andrey-mp> hogepodge: is it right that guideline will not contain these flags?
19:34:35 <hogepodge> andrey-mp: guidlines have flags built in to them. The URL has options that choose whether to generate a list with our without the flagged tests
19:34:42 <catherineD> yea I had tested and https://review.openstack.org/#/c/314648/ looks good to me ... RefStack core please review and merge
19:35:15 <andrey-mp> I mean that RefStack API server takes these flags from guideline.json
19:35:25 <hogepodge> andrey-mp: defcore doesn't want to maintain a static list that gets out of date, and the refstack server does a good job of dynamically generating the same lists (accurate to within a day)
19:35:37 <andrey-mp> and if guideline.json will not have such flags that this link will not work
19:35:53 <hogepodge> andrey-mp: I don't follow.
19:36:06 <hogepodge> andrey-mp: if a guideline has no flags you'll get all of the tests
19:36:58 <andrey-mp> i mean that this guideline https://github.com/openstack/defcore/blob/master/2016.01.json has flagged attribute
19:37:38 <andrey-mp> hogepodge: is it built from deleted files in your review?
19:37:52 <catherineD> andrey-mp: no it is not
19:37:53 <hogepodge> andrey-mp: no
19:38:00 <andrey-mp> ok.
19:38:37 <hogepodge> andrey-mp: those defcore repository files are statically generated, and the refstack server takes on that job dynamically. It's a much better solution, letting computers automate things that humans forget about
19:38:41 <andrey-mp> (but for my understanding - from which source 'flagged' is coming to guideline? )
19:38:44 <catherineD> od back to refstack-client
19:39:25 <catherineD> we need to investigate replacing run_tempst.sh with ostestr
19:39:29 <andrey-mp> hogepodge: I've got it. removed files are generated from guideline...
19:39:44 <hogepodge> andrey-mp: from the guideline itself. This is what we're getting rid of: https://github.com/openstack/defcore/blob/master/2016.01/2016.01.flagged.txt
19:40:12 <hogepodge> andrey-mp: yeah
19:40:21 <rockyg> so, regenerating that file on the fly, essentially, instead of archiving it
19:40:25 <andrey-mp> catherineD: why we need it?
19:40:44 <hogepodge> rockyg: correct. if I understand correctly refstack server re-caches the guideline nightly
19:40:45 <catherineD> andrey-mp: why we need ostestr? or flag?
19:40:52 <andrey-mp> ostestr
19:41:01 <andrey-mp> I moved to next topic )
19:41:02 <pvaneck> hogepodge: every 12 hours
19:42:16 <hogepodge> andrey-mp: I think refstack client is using the run tempest script?
19:42:27 <hogepodge> andrey-mp: qa team would like us to stop doing that
19:43:00 <andrey-mp> catherineD, hogepodge: yeah. so may be its better to run tempest via tox?
19:43:35 <sslypushenko> andrey-mp:  ostestr looks like a preferable way to do it
19:43:36 <catherineD> hogepodge: do you know the time frame?  I plan to see what Daryl suggests on refstack improvemens and update it then ..
19:43:38 <andrey-mp> in any case we need to run tempest, right?
19:43:49 <hogepodge> andrey-mp: there's a better wrapper that lets you use a whitelist file, which we can use with idempotent id to do a better and more reliable job of running tests
19:44:17 <hogepodge> catherineD: I think mtreinish would really like us to stop using run_tempest asap :-D
19:44:40 <mtreinish> ++
19:44:46 <mtreinish> there is no reason to use it
19:44:58 <catherineD> hogepodge: ok  in that case we may need to update without waiting for Daryl
19:44:58 <sslypushenko> aslo ostestr has a python interface
19:45:06 <andrey-mp> mtreinish: whats better - tox os ostestr directly?
19:45:07 <rockyg> mtreinish, could you post the doc link so the team can test with ostestr?
19:45:19 <catherineD> hogepodge: mtreinish: got it .. Thanks!
19:45:20 <mtreinish> andrey-mp: just use ostestr directly
19:45:34 <rockyg> simple replace?
19:45:37 <mtreinish> rockyg: http://docs.openstack.org/developer/os-testr/ostestr.html
19:45:50 <rockyg> Thanks!
19:46:13 <hogepodge> I will admit to being the person who started using run_tempest and have responsibility for it being there right now
19:46:15 <mtreinish> rockyg: the only thing that trips people up is there is not a default selection logic. So it's not a drop in replacement for testr
19:46:17 <catherineD> #action update refstack-client to use ostestr
19:46:43 <rockyg> Ah.  So, testing to get the calling structure correct...
19:47:05 <mtreinish> fwiw, this cycle 1 of my personal goals is to get tempest run in a useable place (instead of just wip patches)
19:47:13 <rockyg> mtreinish, good info to speed the work
19:47:17 <andrey-mp> mtreinish - so we need to build virtualenv by refstack-client and run ostestr, right?
19:47:42 <mtreinish> andrey-mp: yeah, that's normally how I recommend people use it
19:48:42 <andrey-mp> mtreinish: and this virtualenv should contain installed tempest? )
19:48:47 <catherineD> andrey-mp: refstack-client operates in .virtualenv
19:48:53 <sslypushenko> andrey-mp:  ostestr can be called as python module
19:48:53 <andrey-mp> with all needed plugins
19:49:29 <sslypushenko> so there is no point to run it in subprocess like we do now with run_tempest sript
19:49:31 <andrey-mp> sslypushenko: i'm trying to understand environment for this )
19:49:43 <mtreinish> andrey-mp: it should, the test runner needs to be able to access the python code it's executing. It all depends on how you're installing things
19:50:08 <andrey-mp> mtreinish: ok, thanks
19:50:24 <catherineD> moving on ...
19:50:38 <hogepodge> thanks mtreinish
19:50:39 <catherineD> #topic RefStack can now creates branches
19:51:59 <catherineD> Let's discuss in more details on branching  next week
19:52:13 <catherineD> I will put this topic to the top of the list
19:52:26 <catherineD> #topic DefCore changes
19:52:45 <catherineD> hogepodge: I think we have discussed this earlier ...
19:52:56 <andrey-mp> sslypushenko: (previous topic) this way needs to propagate some environment variable - we need to think how to do it better...
19:53:33 <sslypushenko> andrey-mp:  agreed
19:54:07 <andrey-mp> catherineD: what you want to discuss about branches? ) I though that discussed it on summit )
19:54:50 <catherineD> andrey-mp: discussion on what are the branches that we will support and for what purposes ..
19:55:03 <andrey-mp> ah, ok
19:55:12 <catherineD> the details
19:55:26 <catherineD> moving on ..
19:55:37 <catherineD> #topic Open discussion
19:55:45 <andrey-mp> I think that model from OpenStack components can be suitable for us...
19:56:14 <andrey-mp> I have no topic for open discussion )
19:56:30 <sslypushenko> andrey-mp:  I don't think so
19:56:49 <andrey-mp> sslypushenko:  why?
19:57:26 <sslypushenko> Because OS components are not sowtware-as-a-service
19:57:47 <sslypushenko> I'd be better to follow OS documentation model
19:58:21 <andrey-mp> hm, are there a link to this model?
19:58:22 <sslypushenko> at least they also maintain a web portal
19:58:52 <catherineD> sslypushenko: andrey-mp: Yup this is the reason I want to give us more time on this topic next week ...
19:58:54 <andrey-mp> we should finish in one minute...
19:59:08 <andrey-mp> ok. let's discuss it next week
19:59:08 <catherineD> everyone let's give it some thoughts ...
19:59:23 <sslypushenko> andrey-mp:  I'll ping you in mail
19:59:30 <andrey-mp> but it wuold be good to read both models before )
19:59:33 <catherineD> Thank you all  for a productive meeting !!!
19:59:35 <andrey-mp> (for me)
19:59:49 <andrey-mp> Thank you!
20:00:01 <rockyg> Thanks!
20:00:04 <catherineD> andrey-mp: ++ let's do some home work before next meeting
20:00:06 <catherineD> bye
20:00:11 <andrey-mp> bye
20:00:15 <catherineD> #endmeeting