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