16:00:47 <markvoelker> #startmeeting defcore
16:00:48 <openstack> Meeting started Wed Mar 16 16:00:47 2016 UTC and is due to finish in 60 minutes.  The chair is markvoelker. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:51 <openstack> The meeting name has been set to 'defcore'
16:00:53 <eglute> o/
16:00:57 <hogepodge> o/
16:00:58 <catherineD> o/
16:01:03 <gema> o/
16:01:09 <tgraichen> bye
16:01:14 <markvoelker> #link https://etherpad.openstack.org/p/DefCoreRing.15 Today's agenda
16:01:16 <shinya_kwbt> bye
16:01:21 <markvoelker> #topic agenda
16:01:44 <markvoelker> Please have a look at today's agenda and note any late additions
16:02:03 <markvoelker> Glad to see you all made it in spite of the DST change here in the US. =)
16:02:25 <luzC> hello
16:02:31 <eglute> I like DST, i just dont like the switching!
16:02:36 <eglute> hello luzC!
16:02:42 <markvoelker> #topic Midcycle recap
16:02:54 <brunssen> Hello everyone.
16:03:03 <markvoelker> #link  https://etherpad.openstack.org/p/DefCoreSpring2016MidCycle Etherpad from DefCore midcycle meetup
16:03:26 <markvoelker> Thanks to everyone who came down to Texas, and special thanks to Vince and IBM for hosting us
16:03:26 <dwalleck> o/
16:03:45 <markvoelker> If you took action items from the sessions, they should hopefully be reflected in the Etherpad
16:03:59 <markvoelker> I know I have several. =)
16:04:20 <eglute> should we review who has what and decide on timelines?
16:04:52 <markvoelker> eglute: We could, but that could take a while...it's a long list.  Maybe we should just ask first if anyone is unclear on their AI's or timelines?
16:05:04 <eglute> that sounds like a good idea
16:05:05 <brunssen> @markvoelker, you are welcome
16:05:16 <brunssen> It was our pleasure to host.
16:05:41 <markvoelker> On my end, I think the first thing I owe is a 2016.07 draft.  I should get that pushed up for review later tonight.
16:05:50 <markvoelker> That should u
16:05:52 <eglute> thanks markvoelker
16:05:55 <markvoelker> nblock a few other things
16:06:12 <markvoelker> Does anyone else need clarification on AI's or timing?
16:07:21 <eglute> i am good for now
16:07:33 <markvoelker> Ok, hearing nothing then...the next big thing for several folks is scoring, which is due soon.  And is the next topic on our agenda today, as luck would have it.
16:07:34 <markvoelker> =)
16:07:46 <markvoelker> #topic Scoring
16:08:21 <markvoelker> We need to get scoring patches submitted ASAP.  Our deadline is only about a week and a half away now, so the sooner the better.
16:08:33 <markvoelker> #info Scoring patches due March 27
16:09:03 <markvoelker> Hopefully each of you have had a chance by now to reach out to PTL's and others to solicit input...if you need help on that front, please let us know!
16:09:12 <catherineD> Let me know when it is time for me to discuss Heat scoring
16:10:40 <markvoelker> Any other scoring stuff before we get to Heat?
16:11:10 <markvoelker> Ok then: catherineD, let's talk about Heat.  The floor is yours. =)
16:11:24 <catherineD> Thx markvoelker:
16:11:42 <catherineD> So I have discussed scoring with the Heat team
16:12:14 <catherineD> basically, they have not implemented tempest plugin interface for their in-tree test yet
16:12:28 <catherineD> as a result of the discussion , a BP was created
16:13:01 * markvoelker sees that as a positive
16:13:14 <catherineD> #link Heat BP for tempest plugin https://blueprints.launchpad.net/heat/+spec/tempest-plugin-support .. target for Newton
16:13:44 <markvoelker> So I guess the question is: if that isn't going to land until Newton, where does that leave us for this coming Guideline?
16:13:57 <catherineD> question: does it make sense to request for scoring Heat now or should wait for the BP implemation?
16:13:57 <markvoelker> E.g., are there tests in Tempest today that are reasonable in the interim?
16:13:58 <eglute> we cant add those tests to defcore until the patch lands
16:14:36 <catherineD> markvoelker: They do not think what are in Tempest today is a good representative of Heat features
16:15:06 <catherineD> I was planning to have a face-2-face working session with them at the Austin summit
16:15:23 <markvoelker> catherineD: Ok.  I personally haven't looked through the ones in Tempest lately so I'll trust their judgement.  Kinda disappointing not to have anything for this Guideline though.
16:15:23 <catherineD> to at least get the in-tree test list and capabilities
16:16:32 <dmellado> catherineD: besides this exact case for Heat, how're you dealing with the test split in tempest? I mean that when it comes from the tempest plugins in other repos and moved tests
16:16:33 <catherineD> we do have the capabilities in https://review.openstack.org/#/c/216983/
16:16:34 <dmellado> ?
16:17:48 <catherineD> dmellado: if the in-tree tests are implemented with tempest plugin... testr list test will give a complete test list including the test in tempest and those with plugin
16:17:57 <catherineD> so from testing we should be OK
16:18:10 <dmellado> catherineD: I know, but my question is about the projects who lacks tempest plugin
16:18:18 <dmellado> and tests have been already moved
16:18:29 <dmellado> i.e. neutron api tests
16:19:29 <catherineD> I belieev DefCore's stand is DefCore test must be able to initiate test byTtempest.  Right? markvoelker: eglute:
16:19:35 <hogepodge> dmellado: moved? into or out of tempest?
16:19:51 <dmellado> hogepodge: some neutron tempest tests were moved out of tempest to the neutron repo
16:19:52 <eglute> catherineD is correct. dmellado are you talking about current defcore tests that were already moved?
16:19:55 <markvoelker> catherineD: yes.  Mechanically that's the easiest way to pick those up today.
16:20:11 <eglute> dmellado can you provide examples? this is news to us
16:20:24 <dmellado> eglute: not current in defcore, but for the future
16:20:29 <dmellado> sorry if I was alarming ;)
16:20:48 <eglute> dmellado ah in that case it is ok!
16:21:03 <dmellado> I'm currently working, or trying to, in the neutron tempest plugin
16:21:14 <dmellado> and thus was interested ;)
16:21:29 <eglute> are you planning on moving current defcore tests into the plugin?
16:21:44 <eglute> or all of the neutron tests into the plugin?
16:21:55 <dmellado> eglute: neutron moved quite some tests to their own repo
16:22:07 <dmellado> basically I need the plugin to run them from tempest
16:22:28 <eglute> do you already have a working plugin? if not, how far away are you?
16:22:49 <dmellado> i.e. https://github.com/openstack/neutron/blob/master/neutron/tests/api/test_networks.py
16:23:12 <dmellado> I'm working on it and probably not too far, but most probably won't be landing in mitaka
16:23:23 <dmellado> (just too many things xD)
16:23:42 <catherineD> dmellado: I think the project needs to be aware that if the tests are targeted as DefCore plugin then they needed to be able to run from Tempest
16:24:10 <catherineD> DefCore plugin --> DefCore tests :-)
16:24:17 <dmellado> I'm not sure about defcore, pretty new to it
16:24:21 <hogepodge> qa has indicated that they would like defcore tests to stick around in tempest where possible
16:24:24 <dmellado> so sorry if I ask too many maybe known things
16:24:48 <catherineD> hogepodge: thx
16:24:51 <dmellado> at any case as of today they run just fine, just was thinking about the next movements
16:25:00 <dmellado> thanks hogepodge for pointing that out
16:25:03 <eglute> dmellado you are at the right place! and we definitely want to know about this as early as possible
16:25:15 <catherineD> markvoelker: eglute: hogepodge: back to Heat scoring ...
16:25:22 <hogepodge> plugin is a compromise, but if those tests could move back (I know), that's a course to consider
16:25:50 <catherineD> do we still want to work with the test they have in Tempest today or wait?
16:25:53 <eglute> we do need to consider the plugin route though
16:26:31 <markvoelker> catherineD: I think that I'd need to look into what's in Tempest for Heat today before I can really have an opinion.
16:26:41 <eglute> catherineD i think if they suggest not using the tempest tests, we should not use them.
16:26:53 <markvoelker> catherineD: That said, if the Heat folks feel those are so insufficient that they'd rather have nothing for this Guideline...
16:28:04 <catherineD> markvoelker: seems like so .. because without the plugin ... we can not run the tests ..
16:28:40 <markvoelker> catherineD: In your conversations with the Heat folks, did they understand that without a plugin we have to use the in-Tempest tests or nothing this time around?
16:29:13 <catherineD> markvoelker: they do so they would like to implement the plugin in Newton
16:29:29 <catherineD> by defining BP and owner
16:29:30 <markvoelker> Ok.  So they're ok with not having anything in the next Guideline then?
16:30:33 <catherineD> markvoelker: Let me double check with them on the fact that whether they are OK witj not having anything in the next Guideline
16:30:49 <eglute> thanks catherineD
16:31:13 <markvoelker> Ok.  If they're willing to wait another six months I have no real problem with that.  It's fine to continue working on identifying candidate capabilities, but obviously no pressure on the March 27 date.
16:31:35 <markvoelker> Any work you do now will simply help ensure adequate test coverage exists and make scoring easier down the line. =)
16:32:01 <catherineD> markvoelker: +1
16:32:15 <markvoelker> Ok, anything else on scoring before we move on?
16:33:32 <markvoelker> ok, moving on then
16:33:36 <markvoelker> #topic RefStack
16:33:44 * markvoelker turns the floor back over to catherineD
16:33:56 <catherineD> openstack: Thx
16:34:09 <catherineD> for     https://review.openstack.org/#/c/290689/
16:34:51 <catherineD> it was updated with patch#2 to add the tests instead of renaming ...
16:35:27 <catherineD> but I think we need to think of the long term solution because the test lists are dynamic
16:35:45 <eglute> catherineD what do you propose?
16:35:54 <catherineD> Out plan is to provide a REST API in RefStack to let user download the test list
16:36:20 <catherineD> The REST API would reconstruct the list everytime the user requests
16:36:57 <catherineD> so it is a live test list with many options that the user can choose (list only required, or with alias , or advisory ...)
16:37:17 <catherineD> we will also provide a link at the RefStack server UI
16:37:34 <dmellado> would that also affect the tempest tag that the refstack client will be downloading?
16:38:08 <catherineD> dmellado: the test list is constructed from the guideline JSON files
16:38:24 <catherineD> and not from testr test list of tempest
16:38:34 <dmellado> catherineD: I see, thanks for the clarification
16:39:06 <catherineD> but the guideline files do change overtime due to flagged tests etc ...
16:39:12 <catherineD> so it is dynamic
16:39:13 <hogepodge> this only gets more difficult once out of tree tests are admitted
16:40:21 <dmellado> so how does the guideline JSON files get built? from the scoring that mentioned before?
16:40:50 <markvoelker> dmellado: yep.  I'll dig up an example patch review for you to peruse if you like
16:40:59 <dmellado> that'd be great markvoelker, thanks!
16:41:36 <luzC> please count me in for the example as well please
16:42:04 <catherineD> but for the immediate issue, https://review.openstack.org/#/c/290689/ should be merged
16:42:16 <markvoelker> dmellado: luzC: here's the patch that added networking capabilities...I'll use it as an example since I wrote it and since it got a lot of discussion =) https://review.openstack.org/#/c/210080/
16:42:32 <markvoelker> catherineD: makes sense
16:42:44 <dmellado> thanks markvoelker ;)
16:43:38 <markvoelker> catherineD: anything further?
16:44:09 <catherineD> not for this topic ...
16:44:27 <catherineD> could we discuss the next RefStack topic
16:44:36 <markvoelker> catherineD: absolutely, go for it
16:45:14 <catherineD> I am really sorry that this is the third times we discuss the "List RefStack Users" topic
16:45:23 <catherineD> #link http://lists.openstack.org/pipermail/defcore-committee/2016-March/001066.html
16:46:40 <catherineD> during the RefStack meeting , it was suggested that I send the email
16:46:53 <eglute> I think ONLY foundation members should be able to list users in refstack
16:47:11 <markvoelker> Ok, so we've been over this a few times but I think we're getting new info as we unravel the ball of yarn a bit so it's fine to bring it back up.
16:48:16 <hogepodge> I'm torn on this issue
16:48:20 <markvoelker> One thing that it might be useful to clarify: it feels like part of the resistance here is that not allowing normal users to list user data is that doing so creates extra work/complexity for you guys. =)  And that's a valid concern.  Is that true?
16:48:46 <hogepodge> On one hand we're open and all this information is available anyway. On the other, I don't want to give someone a simple API to generate a spam list.
16:49:55 <catherineD> markvoelker: I think we need to look at the principal ... how we implement should not affect the principal
16:50:55 <catherineD> hogepodge: We get the user infor for openstackid  which own by Foundation
16:50:56 <gema> catherineD: +1
16:52:11 <markvoelker> catherineD: I don't disagree, but what I'm sort of meandering toward is kind of what hogepodge is getting at: if it's really burdensome to do it this way and 90% of that info is available already anyway...maybe I could be convinced the costs outweigh the benefits.  But if it's not a ton of extra work, I'd prefer we stick to the original intent, which is to disclose the least info necessary to do the job.
16:53:01 <hogepodge> markvoelker: +1
16:53:02 <markvoelker> catherineD: That's why I'm curious how much work this adds up to.
16:53:10 <eglute> markvoelker +1
16:53:32 <gema> less than the amount of time we've spent discussing this, for sure
16:53:44 <gema> specially for catherineD  :)
16:53:55 <catherineD> markvoelker: how much work is depending on individual opinion,s
16:54:01 <catherineD> gema: haha
16:54:51 <markvoelker> catherineD: I think probably the RefStack team is best situated to figure out a reasonable level of effort estimate...unfortunately we're probably not.
16:54:55 <markvoelker> So what I'd suggest...
16:54:55 <catherineD> My concern is once the data is exposed we can not get it back ... I hate to see RefStack being the one who does that ...
16:55:29 <markvoelker> Is that we once again re-iterate our assertion that our preference is to disclose the least amount of information necessary to perform the required tasks.  That's our guiding recommendation.
16:55:30 <eglute> Unless there is a really good reason to list ALL registered users for any logged in user, Refstack should not be displaying it
16:55:55 <markvoelker> If RefStack decides to go a different route because the effort is too much...I'm probably ok with that call.
16:56:14 <markvoelker> We can give the guidance, but the implementation is ultimately up to those who are writing the code, really.
16:56:47 <markvoelker> Does that sound reasonable to folks?
16:56:51 <catherineD> eglute: markvoelker: hogepodge: gema: I would appreciate if you all can response to the email http://lists.openstack.org/pipermail/defcore-committee/2016-March/001066.html
16:57:06 <eglute> will do, sorry haven't yet!
16:57:16 <markvoelker> catherineD: can do.
16:57:20 <gema> catherineD: will do
16:57:28 <catherineD> eglute: no problem at all ....
16:57:59 <catherineD> thank you all... I hope this would be the last time I bring this issue here :-)
16:58:09 <dmellado> it's an interesting topic, though
16:58:18 <dmellado> if we assume this is all 'open', then yeah
16:58:26 <dmellado> anyway, I'll try to find some time to reply ;)
16:58:40 <catherineD> dmellado: thank you!
16:58:40 <eglute> catherineD, please do bring things up as they come up
16:59:11 <catherineD> eglute: thank you
16:59:25 <markvoelker> #action all please respond to http://lists.openstack.org/pipermail/defcore-committee/2016-March/001066.html
16:59:40 <markvoelker> Anything further?  We're about out of time
17:00:02 <catherineD> nope from me
17:00:06 <markvoelker> Ok then, thanks folks!
17:00:13 <markvoelker> #endmeeting