15:00:52 <zehicle_home> #startmeeting DefCore 13
15:00:53 <openstack> Meeting started Wed Sep  2 15:00:52 2015 UTC and is due to finish in 60 minutes.  The chair is zehicle_home. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:57 <openstack> The meeting name has been set to 'defcore_13'
15:01:14 <zehicle_home> oh, dear.  this is the B meeting :/
15:01:35 <zehicle_home> I guess that's ok for :-B
15:01:49 <markvoelker> o/
15:01:49 <kbaikov_> Hello
15:01:50 <zehicle_home> o/
15:01:54 <dwalleck> o/
15:02:00 <kbaikov_> o/
15:02:16 <barrett1> o/
15:02:17 <zehicle_home> was expecting attendance to be light due to VMworld so I'm glad to see so many hands!
15:02:26 <hogepodge> o/
15:02:50 * markvoelker is at vmworld but hiding somewhere quiet-ish
15:02:51 <zehicle_home> #link https://etherpad.openstack.org/p/DefCoreFlag.13
15:03:03 <zehicle_home> please review the agenda
15:03:16 <zehicle_home> we may be able to put the swift fun tests back in
15:03:52 * zehicle_home feels like the new google logo is sticking it's tongue out at me w/ the e at the end
15:03:54 <markvoelker> Worth noting on that front: https://review.openstack.org/164865
15:05:14 <zehicle_home> #chair hogepodge
15:05:15 <openstack> Current chairs: hogepodge zehicle_home
15:05:22 <zehicle_home> #chair markvoelker
15:05:23 <openstack> Current chairs: hogepodge markvoelker zehicle_home
15:05:32 <markvoelker> Per last comment there, there's a prototype/POC in refstack now for folks to look at
15:05:40 <markvoelker> #link https://review.openstack.org/#/c/214571/
15:06:12 <hogepodge> markvoelker: we're going to have to finish that plugin ourselves, as the contract for that work has expired.
15:06:15 <zehicle_home> ok,let's start w/ that topic then
15:06:34 <zehicle_home> sorry, start w/ swift
15:06:36 <hogepodge> I volunteer to move it forward. I've been on travel for two weeks, and am woefully behind on committee work. Lots of catchup over the next two weeks for me.
15:06:54 <zehicle_home> unless there is other items on the agenda to prioritize?
15:07:02 <zehicle_home> moving Refstack up
15:07:25 <markvoelker> hogepodge: is someone working on pruining the test list for Swift?  Comments indicated there were some in there that required admin access...
15:07:53 <markvoelker> I think notmyname was going to look into that, but it was sort of on the tail end of a previous meeting so not sure if anyone has an AI
15:07:57 <zehicle_home> #topic Swift Functional tests
15:08:12 * zehicle_home tweaked the order in the agenda
15:08:19 <zehicle_home> let's start w/ the Swift topic
15:08:48 <zehicle_home> can someone provide background for the discussion?
15:09:26 * markvoelker can take a stab at it, but hogepodge is probably more on point for this
15:09:26 <hogepodge> markvoelker: I spoke with notmyname about it. Swift's definition of admin is different from Keystone, so it's unclear how much privilege an account needs.
15:09:53 <hogepodge> markvoelker: admin, from what I understand, means someone who can post to a swift account.
15:10:00 <zehicle_home> my understanding is the Swift has a lot of tests that are not part of tempest
15:10:18 <zehicle_home> so that's the top item.
15:10:19 <markvoelker> So, background:
15:10:21 <hogepodge> zehicle_home: that set of tests is part of the review markvoelker posted earlier.
15:10:44 <markvoelker> WE had a priority this cycle to be able to include non-Tempest tests in our Guidelines
15:10:46 <zehicle_home> I was looking at the reviews on it
15:11:00 <markvoelker> Swift is the first case for that b/c they have some in-tree functional tests
15:11:12 <markvoelker> The patch above submits those tests
15:11:27 <markvoelker> In order to accept them, we have to actually have a mechanism for folks to run them in refstack
15:11:35 <zehicle_home> markvoelker, my thinking was we had to decide if we would include them.  including them would be follow-up work
15:11:36 <markvoelker> And we need to make sure they comply with Guidelines, etc.
15:12:00 <markvoelker> So the refstack team has prototype code that would make this mechanically possible
15:12:04 <zehicle_home> +1 we had agreed in principle that all tests would need to work w/ refstack
15:12:18 <markvoelker> But there's still legwork that needs doing.
15:12:28 <markvoelker> <end background>
15:12:41 <zehicle_home> before we jump into background...
15:12:59 <zehicle_home> background -> implementation
15:13:07 <rockyg> o/
15:13:34 <zehicle_home> I want to make sure of two things:
15:13:52 <zehicle_home> 1) the tests in question are still outside of tempest / refstack
15:14:15 <zehicle_home> 2) we have a position to accept them as being outside of tempest.
15:14:27 <zehicle_home> if the are runnable from tempest, then it's a simpler discussion
15:14:52 <markvoelker> 1) Yes, these are in the Swift tree.  See https://review.openstack.org/#/c/164865/
15:15:04 <hogepodge> zehicle_home: regarding 1), the plugin allows the tests to be run within the tempest framework, but they remain in swift tree.
15:15:23 <zehicle_home> hogepodge, ok.  that's my confusion then
15:15:36 <zehicle_home> so, these tests work w/in the tools that we are using
15:15:57 <zehicle_home> we've been expecting lots of tests to move into the projects from tempest tree
15:16:01 <hogepodge> zehicle_home: 2) I'm torn on that one. at a minimum, an external test framework needs to be an accepted openstack project with diversity of contributions
15:16:37 <zehicle_home> I was thinking that we'd decided that 2) was not acceptable at this point
15:16:39 <markvoelker> zehicle_home: Well, they *will* work within our tools, if the POC is finished.  Refer to https://review.openstack.org/#/c/214571/
15:17:11 <markvoelker> zehicle_home: In Austin we discussed using the plugin approach and the Swift/Tempest folks seemed to think that was a reasonable middle ground.
15:17:20 <zehicle_home> so, if we take a position that tests must be runnable w/ the tools then there's a path forward
15:17:37 <zehicle_home> markvoelker, thanks.  that's what I'm trying to clarify
15:17:59 <zehicle_home> it keeps DefCore from having to make the larger policy decision
15:18:09 <zehicle_home> but creates some work
15:18:36 <zehicle_home> had that changed since midcycle?
15:18:40 <markvoelker> Sure.  For example, the current POC (IIRC) allows testr to find the tests, but running them is still hard due to configuration not being done yet.
15:18:46 * zehicle_home apologies for dragging up the history
15:18:56 <catherineD|2> o/
15:18:57 <markvoelker> No, it hasn't changed AFAIK
15:19:05 <rockyg> But the tests need to be in an accepted openstack project...
15:19:25 <markvoelker> rockyg: They're in the Swift tree.  I think Swift can safely call itself OpenStack. =)
15:19:28 <zehicle_home> +1 rockyg - that's part of the 2015A requirements
15:19:47 <rockyg> Right, but other, future proposed tests :-)
15:20:19 <zehicle_home> for now, I believe the official position is that all tests must be runnable by Tempest framework to be considered
15:20:30 <zehicle_home> and be part of the TC managed body of work
15:20:37 <rockyg> ++
15:20:39 <hogepodge> rockyg: My opinion is they must be in  an official project, with preference to tempest.
15:20:46 <markvoelker> rockyg: Yes see 2015A section A2 item 5: "Tests must be under OpenStack Technical Committee governance."
15:22:15 * markvoelker notes that we're 20 minutes in and suggests we move on from reviewing current status to how to move forward
15:22:39 <zehicle_home> since we've been pushing this agenda item, I wanted to make sure we can close it
15:22:42 <rockyg> markvoelker, +1
15:22:58 <markvoelker> So, hogepodge: you can help move the current POC forward since it's current authors can't continue to work on it?
15:23:08 <hogepodge> markvoelker: yes.
15:23:16 <markvoelker> And we need to determine the suitability of the tests in question, yes?
15:23:27 <markvoelker> Do you have that under control, or need some help?
15:23:34 <hogepodge> #action hogepodge to take over work of swift tempest plugin and test suitability
15:23:56 <hogepodge> markvoelker: Now that travel has settled down I have cycles to devote to it.
15:24:04 <markvoelker> hogepodge: awesome
15:24:16 <hogepodge> markvoelker: plus I'll be at qa meetup in two weeks, so can work with experts there
15:24:24 <rockyg> ++
15:24:40 <zehicle_home> ok, I think this is moving to an implementation problem not a policy issue
15:24:47 <markvoelker> hogepodge: double good.  Please shout if you need help.  Next couple of weeks are fairly bananas for me, but happy to help if I can.
15:25:24 <markvoelker> zehicle_home: agreed, I think we've already solved that
15:25:35 * zehicle_home cheers
15:25:58 <zehicle_home> #topic Refstack
15:26:32 <zehicle_home> hogepodge or catherineD|2 , you want to talk refstack and project change?
15:26:41 <catherineD|2> I sent an email to DefCore ML list asking for help on vendor registration help ...
15:27:25 <markvoelker> catherineD|2: I can take a first pass at drafting that next week if that will help get the ball rolling
15:27:27 <zehicle_home> I thought it made sense
15:27:45 <catherineD|2> RefStack is now a "Big Tent" project ... need to send patch tomove the repos next
15:27:56 <catherineD|2> markvoelker: thx
15:28:16 <zehicle_home> hogepodge, you have a plan to address developer changes?  do we need to find funds/people to help?
15:28:24 <markvoelker> #action markvoelker Create first draft of registration functional spec
15:28:59 <hogepodge> zehicle_home: I have none. We need to recruit and extoll the benefits of assigning a dev to interop efforts
15:29:09 <rockyg> Yeah.  The how of vendor ownership that is not totally tied to a specific individual key set is important
15:30:13 <rockyg> With a Chinese dev from IBM particpating, maybe I can get a Huawei dev on board.... I'll try.
15:30:16 * zehicle_home wish some company just landed a big boatload of venture funding for OpenStack work
15:30:30 <rockyg> hrm
15:30:50 <zehicle_home> ok, moving on.... last comments on Refstack>
15:31:00 <zehicle_home> I think catherineD|2 would appreciate some +1s to her email
15:31:06 <catherineD|2> we need to solve the dev problem
15:31:19 <catherineD|2> so it is not an IBM project
15:31:39 <catherineD|2> we just add one more person from IBM but that is just to make sure to get the work done ..
15:31:47 <rockyg> need the flow/auth/ for changing committer of texts without changing vendor ownership
15:32:13 <rockyg> s/texts/tests
15:32:28 <zehicle_home> #topic changing scoring weights?
15:32:41 <zehicle_home> markvoelker, did you experiment w/ this at all?
15:33:06 <zehicle_home> I want to track it for a topic but have not played with potential changes
15:33:25 <markvoelker> zehicle_home: not yet (no time due to VMworld), but it's quite simple to play with since the scoring script reads the weights directly from whatever .json guideline doc you feed it.
15:34:12 <zehicle_home> IMHO, the critical question is where the diversity in +/- scores is
15:34:29 <zehicle_home> if 50% of the columns are all the same, then they are not really adding much to the score
15:34:49 <zehicle_home> BUT they create a barrier to incomplete projects.  that was the original intent
15:34:56 <hogepodge> zehicle_home: future direction and widely deployed are where I'm seeing the biggest variance.
15:35:18 <markvoelker> zehicle_home: Sure.  I have a few thoughts kicking around on things that might be good candidates for higher/lower weighting.  But need to get time to play it out.
15:35:32 <zehicle_home> yy. expected that  - we did not want those to become "THE" criteria
15:35:50 <zehicle_home> or it would basically be back to fighting over future direction vs. adoption
15:36:42 <markvoelker> I suggest we table the topic for now...we'll be doing some scoring over the next couple of weeks, so that will be a good time to experiment a bit and come up with concrete suggestions.
15:36:55 <zehicle_home> I'd like to know if changes made a difference to outcomes
15:37:06 <markvoelker> sure
15:37:20 <catherineD|2> Do we require to have the project PTLs to review the scoring patches?
15:37:37 <markvoelker> catherineD|2: no, but we do encourage them to
15:37:38 <zehicle_home> so, this topic needs to wait till we have some data for proposals
15:37:45 <markvoelker> Or other members of the technical community
15:37:58 <markvoelker> zehicle_home: yes
15:38:20 <zehicle_home> #topic Xen patch 215263
15:38:48 <markvoelker> #link https://review.openstack.org/#/c/215263/
15:39:05 <zehicle_home> I merged that
15:39:05 <markvoelker> Oh, you just merged it...thanks. =)
15:39:20 <markvoelker> Ok, that should un-bottleneck at least two vendors that I'm aware of...
15:39:20 <zehicle_home> #topic vendor config reporting
15:39:36 <markvoelker> We also need this one, but less urgent: https://review.openstack.org/#/c/217337/
15:39:47 <markvoelker> Basically the 2015.07 spec contains schema violations
15:40:36 <zehicle_home> markvoelker, doing it now
15:40:55 <markvoelker> The latter patch there uncovered an issue with schema 1.3 that we'd overlooked
15:41:08 <markvoelker> We don't really need to solve it right now, but just so folks are aware:
15:41:31 <markvoelker> Schema 1.3 contains two places where a Capability's status is listed.  E.g. two sources of truth.
15:41:35 <zehicle_home> thinking of agenda... next meeting is 100% focused on scoring?
15:41:42 <zehicle_home> interactive session?
15:41:57 <markvoelker> It's probably easiest to visualize here: https://review.openstack.org/#/c/215263/3/2015.next.json
15:42:04 <rockyg> ++
15:42:33 <zehicle_home> #decision next meeting is 100% scoring and will be conference call (not IRC)
15:42:52 <hogepodge> +1
15:43:14 <zehicle_home> markvoelker, you are right.  could be worthwhile to address in a v1.4
15:43:32 <zehicle_home> patch for that would be OK
15:43:59 <zehicle_home> plenty of time tho.
15:44:24 <zehicle_home> vendor config discussion?
15:44:25 <markvoelker> zehicle_home: sure, it's not a big deal, just something we should eventually fix.  I can send up a patch for it later.
15:45:24 <markvoelker> zehicle_home: do we have more to discuss on the vendor patch?  Last week we'd suggested we keep the discussion on the ML to avoid further fragmentation, and there's been no further traffic
15:45:51 <zehicle_home> we can keep it on the ML.  I think there's fatigue w/ that one
15:46:00 <markvoelker> There have been no replies to the ML thread other than a few more folks adding -1's to the review
15:46:13 <zehicle_home> I'd like to hear from hogepodge if the Foundation wants to follect the info
15:46:46 <zehicle_home> it seems like most of the issue is on the requirements but not the intent to get info
15:47:17 <hogepodge> zehicle_home: they want it, but I'm not sure how to word it
15:47:27 <rockyg> Yes.  fine to collect info, not fine to require it as part of published descripion of vendor cloud or distro
15:47:51 <markvoelker> zehicle_home: I think it's very much about the goal we're trying to achieve.  Conensus seems to be the data proposed doesn't accomplish the goal
15:48:18 <rockyg> +1
15:48:33 <markvoelker> hogepodge: Could we actually have someone respond t the thread and say what the Foundation wants to accomplish?
15:48:43 <hogepodge> markvoelker: sure
15:49:15 <zehicle_home> let's do that.  I'm thinking of a patch that removes the details and let's vendor's decide for now
15:49:21 <hogepodge> markvoelker: I have an interop meeting this afternoon and will raise it there
15:49:24 <zehicle_home> we could add requirements in Hacking later
15:49:44 <zehicle_home> the 1st concern was 2015B
15:49:51 <catherineD|2> hogepodge: pls also raise the RefStack resource issues ...
15:49:53 <zehicle_home> then DefCore can iterates
15:50:09 <hogepodge> catherineD|2: ok
15:50:15 <catherineD|2> hogepodge: thx
15:50:16 <markvoelker> zehicle_home: Frankly, I'm of the opinion that consensus has gone against this patch for now and we should just abandon it, figure out what the Foundaiton is trying to accomplish, and then work on how to solve for that.
15:50:51 <zehicle_home> I'm ok w/ that.  I was proxy owner tying to capture Foundation request at the midcycle
15:51:13 <zehicle_home> however, I do believe that vendors should state what they are testing
15:51:32 <zehicle_home> I just don't know what to require
15:51:40 <markvoelker> I'm not against that at all, but that's explicitly not the intent of the current patch. =)
15:51:50 <markvoelker> Which is why I think we should reset with a clearer goal in mind.
15:51:53 * zehicle_home is more invested in this patch then he thought
15:52:19 <zehicle_home> #action hogepodge and zehicle_home to work on wording of intent
15:52:52 <zehicle_home> 5 minutes....
15:53:15 <zehicle_home> #topic last items - open
15:53:36 <zehicle_home> we need reviews on the Cap pages
15:53:41 <zehicle_home> next week should help w/ that
15:54:45 <kbaikov_> Cap pages?
15:55:11 <rockyg> capabilities
15:55:13 <markvoelker> kbaikov_: I think he meant "capability patches"
15:55:14 <zehicle_home> new capabilities for scoring
15:55:30 <zehicle_home> yes, thanks
15:55:40 <rockyg> Yeah, I had to refer to etherpad for a clue ;-)
15:55:55 <hogepodge> I have to update my end of that. Had a good conversation with thingee about how to break out cinder. Also need to add tests to my review.
15:56:18 <zehicle_home> at this point, if there's no patch for a new capability then it's not in
15:56:47 <hogepodge> zehicle_home: neutron was our target for the next release, and we're good there (thanks markvoelker)
15:56:50 <zehicle_home> we OK saying no new capabilities at this point?  or wait another week?
15:57:23 <zehicle_home> anyone aware of someone running up to next week with a list of additional capabilities for review?
15:57:27 <markvoelker> zehicle_home: the deadline for proposing them has expired, so I'd say stick with scoring the ones that have been proposed
15:57:34 <zehicle_home> +1
15:57:47 <rockyg> +1
15:57:48 <markvoelker> This is also one we should think a little about: https://review.openstack.org/#/c/214756/
15:57:55 <zehicle_home> sounds like the timeline was appropriate
15:58:03 <catherineD|2> so we will score Neutron next week or the Neutron patch is ready to merge?
15:58:07 <markvoelker> It's sort of interesting in that it prescribed API behavior as part of designated sections, whcih seems a little weird
15:58:33 <markvoelker> catherineD|2: for the neutron stuff we just need folks to review if they think the tests are the right ones in the right places
15:58:41 <hogepodge> markvoelker: it's an effort to explicitly promote interoperability and discovery
15:58:43 <zehicle_home> markvoelker, I think that makes sense.
15:58:44 <markvoelker> And I need to flesh out the designated sections bits if folks are ok with them
15:59:01 <markvoelker> Wouldn't the right place for that be with tests though?
15:59:11 <markvoelker> Need to think about that one a little.
15:59:17 <rockyg> We can approve the patch and see what feedback we get from vendors
15:59:35 <catherineD|2> markvoelker: the patches does not include tests though
16:00:00 <zehicle_home> wrapping up....
16:00:10 <zehicle_home> #endmeeting