15:00:02 <hogepodge> #startmeeting defcore
15:00:03 <openstack> Meeting started Wed Oct 14 15:00:02 2015 UTC and is due to finish in 60 minutes.  The chair is hogepodge. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:08 <openstack> The meeting name has been set to 'defcore'
15:00:29 <hogepodge> Good morning everybody!
15:00:43 <markvoelker> o/
15:01:11 <zehicle> o/
15:01:13 <edmondsw> o/
15:01:22 <hogepodge> #chair zehicle
15:01:23 <openstack> Current chairs: hogepodge zehicle
15:02:01 <hogepodge> While we wait for roll call, please take a moment to review the agenda
15:02:13 <zehicle> #link https://etherpad.openstack.org/p/DefCoreFlag.19
15:02:14 <hogepodge> #link https://etherpad.openstack.org/p/DefCoreFlag.19
15:02:46 <zehicle> eglute, will miss today
15:04:15 <hogepodge> #topic Flag Removed Tests
15:04:22 <hogepodge> #link https://review.openstack.org/#/c/229177/
15:04:51 <catherine1> o/
15:05:01 <hogepodge> I'm still working on the script. I'll probably have it done in Tokyo. Lots to get done before the summit.
15:05:41 <markvoelker> So on this one, I think we'd basically talked about two ways to handle it: a script and an alias field.  The former is still useful even if the latter is used.
15:05:56 <markvoelker> #link https://review.openstack.org/#/c/232685/1 alias field
15:06:17 <markvoelker> The bigger question I think is just how to handle this for the current Guidelines, and for that the script is probably best.
15:06:38 <hogepodge> I think we should move quickly to add an alias field. My preference is that it be optional to make it easy to get it started.
15:06:49 <markvoelker> hogepodge: +1
15:06:52 <catherine1> can we add the alias to current guideline (2015.07)?
15:07:33 <markvoelker> catherine1: Hmm.  It would require a schema change to a Board-approved doc.  Not impossible I guess, but...
15:07:38 <hogepodge> catherine1: if it's optional, it should be an easy enough change. We might need board approval? We're not changing the content of the guideline, just the administration of it.
15:07:53 <catherine1> we can work on RefStack to handle it .. then we can lift the requirement of certain version of Tempest
15:08:07 <hogepodge> board approval could happen in a couple of weeks
15:08:07 <zehicle> we can ask for board votes on those
15:08:19 <zehicle> they are not substantive and easy  for the board to approve
15:08:21 <zehicle> even by email
15:08:32 * markvoelker will sign up to do the legwork of reformatting 2016.next in 1.4 schema FWIW
15:09:00 <zehicle> if we think schema tweaks are needed that don't change the contents of the doc then we should move ahead and ask for them
15:09:17 <catherine1> alias block should be optional just like flagged test block
15:09:18 <zehicle> do we want 1.4 for the 2016.01 spec?
15:09:33 <hogepodge> So, get a 1.4 schema merged then send to board via e-mail for application to 2015.07?
15:09:33 <zehicle> I was expecting to cut the 2016.01 draft after this meeting
15:10:00 <hogepodge> zehicle: I think 1.4 has important improvements that we want sooner rather than later.
15:10:02 <zehicle> for 2015.07, we can create a patch and then ask for board approval before we merge
15:10:17 <zehicle> if the patch is ready for the board meeting, we'll just add it to the agenda
15:10:23 <markvoelker> zehicle: if we don't use 1.4 for the 2016.01 draft, we don't get the target_approval field, have the 2-sources-of-truth problem for status, and don't get aliases.  I think we should do it.
15:10:46 <zehicle> +1
15:11:07 <catherine1> +1 for adding alias to all (2015.07 and future json ..)
15:11:08 <zehicle> to help w/ merge conflicts, I think we should resolve the new capabilities
15:11:13 <hogepodge> Ok, so what's the plan for getting it ready?
15:11:37 <markvoelker> I think the plan goes like this:
15:11:47 <hogepodge> zehicle: agreed, that's the next item on the agenda. Once we're good to merge I can start the process and do the reconciliation.
15:11:52 <zehicle> if the block is not required in the schema, then merges won't be a problem
15:12:03 <zehicle> kk
15:12:08 <markvoelker> First, we finalize schema 1.4 (see patch above plus https://review.openstack.org/#/c/224868/ )
15:12:16 <zehicle> I was hoping to close 2015B first
15:12:26 <markvoelker> At the same time we can finish up the existing patches for scoring (next agenda items)
15:12:28 <zehicle> I'm OK to merge it
15:12:44 <catherine1> the block is not require in the schema .. just require in the JSON
15:12:46 <markvoelker> Then once both of those are done I'll reformat 2016.next to 1.4 and submit that
15:13:01 <catherine1> just not require in the JSON
15:13:16 <zehicle> merged
15:15:21 <catherine1> markvoelker:  do you see my comment on the 1.4 patch?
15:16:01 <catherine1> about what should be put in the test vs alias areas ..
15:16:19 <hogepodge> Ok, so we've resolved the testing and alias field.
15:16:32 <markvoelker> catherine1: the one saying refstack could handle it if alias fields weren't included in all test blocks?  Yes, and that sounds great.
15:16:49 <hogepodge> And we're good on the process changes?
15:17:05 <hogepodge> markvoelker: catherine1: yes, it's going to make everyone's lives easier if alias is optional.
15:17:07 <zehicle> I tried to address the two outstanding
15:17:24 <zehicle> basically, we're saying that the Foundation will collect data but leaving it open about what that is
15:17:45 <zehicle> hogepodge, that's a new topic?
15:17:58 <hogepodge> #topic process changes
15:18:13 <hogepodge> #link https://review.openstack.org/#/c/207209/7
15:18:13 <zehicle> #link https://review.openstack.org/#/c/207209/
15:18:31 <zehicle> basically, we're saying that the Foundation will collect data but leaving it open about what that is
15:18:43 <hogepodge> I'm ok with the language on this, it's vague enough to give the Foundation some flexibility, but states that it's a requirement.
15:18:51 <zehicle> my understanding was that we could not agree on what would be required
15:19:05 <zehicle> since it's in hacking, we can tighten it as we learn more
15:19:06 <hogepodge> We'll be up front about what we want and why.
15:20:10 <hogepodge> And it will likely be reflected in the marketplace listings. It's something we need to work out with the marketing and web team, what system information we think is valable to show to consumers and users.
15:20:22 <hogepodge> markvoelker: I know you had concerns about scope and reasoning
15:20:56 <markvoelker> I kinda think we should just drop the HACKING change and leave the 2015B change.  HACKING seems like the wrong place for this to begin with and if we're punting to the Foundation to decide what they want and the format they want it in, we should just let them put that on the interop page.
15:21:13 <zehicle> the idea of putting those parts in hacking was to allow the committee to adjust
15:21:31 <zehicle> the key element right now is getting it into the process for board approval
15:21:51 <markvoelker> zehicle: that's why I think we should just keep the 2015B part of the change and drop the rest
15:22:20 <hogepodge> zehicle: I tend to agree with Mark that being overly specific at the beginning might bite us in the end. I'd prefer to take the list to the Foundation and make sure it's reflected on the Interop page.
15:22:21 <zehicle> could do - the hacking file now reads as a suggestion list only
15:22:30 <markvoelker> The 2015B change says the Foundation may require vendors to submit details and specify a format to submit them in, so the HACKING stuff seems unnecessary
15:22:53 <markvoelker> (and, FWIW, controversial since it still contains a lot of the stuff that was controversial in earlier patchsets)
15:23:06 <zehicle> I'm ok w/ that.  at this point the hacking stuff is noise w/o teeth
15:23:52 <zehicle> IMHO, less guidance is not more transparent.
15:24:05 <zehicle> but we can leave it to the foundation to work
15:24:16 <hogepodge> #action zehicle to update "hardware reporting" patch to drop HACKING requirements
15:24:18 * zehicle updates the patch
15:24:24 <markvoelker> Ok, so drop the HACKING change?  I'd also suggest a slight rewording of the 2015B change since the two additions say similar things
15:24:30 * markvoelker adds that to gerrit
15:24:35 <hogepodge> #action hogepodge to take hacking list to Foundation for review and update Interop page
15:26:09 <hogepodge> #link next process review https://review.openstack.org/#/c/207205/
15:26:28 <SamD> FWIW dwalleck and I should be able to happily submit configuration info on our next Rax certification run as long as we keep it general (I.E. ranges of nodes, etc...)...
15:27:04 <hogepodge> SamD: how about hypervisor? I think it's public information anyway
15:27:10 <markvoelker> hogepodge: on this one, can someone clarify what A5(3) means?  It's a bit confusing.
15:27:38 <SamD> Hypervisor should be fine as well but I'm not 100% certain. :-)
15:28:43 <SamD> Things like Hypervisor, node range, cinder backend etc, should be fine from our point of view...
15:28:45 <markvoelker> E.g. is it saying that if the Foundation recommends a component be included in Platform, we apply criteria based on the audience for the component?
15:29:16 * zehicle requests moving on
15:29:37 <markvoelker> I'm also not quite sure what the last sentence of A4(7) means..."components will be evaluated based on their use in the Platform".
15:30:10 <zehicle> sorry - I see we're on the second change
15:30:42 <hogepodge> SamD: we can meet at the Summit and talk over some of those issues. We have no interest in revealing too much special infra sauce, just helping figure out capabilities.
15:31:00 <hogepodge> zehicle: yeah, working on language clarification
15:31:40 <zehicle> markvoelker, this reflects a discussion from the midcycle where we wanted to make sure Components were scored based on a smaller "widely deployed" benchmark
15:32:18 <SamD> hogepodge: Yes. Sounds like a plan.
15:32:41 <markvoelker> zehicle: sure, but what does it mean that "Components will be evaluated based on their use in the PLatform"?
15:34:52 <zehicle> When we look at pulling a Component into the Platform, then we need to see how the COMPONENT is used
15:35:01 <zehicle> not just the capabilities
15:35:32 <scotticus> zehicle what does component mean?  example wise?
15:35:52 <zehicle> Component has a specific meeting for DefCore.
15:36:00 <zehicle> It's a collection of Capabilities
15:36:11 <hogepodge> zehicle: so maybe change to "deployed" or "in-field" usage?
15:36:28 <markvoelker> scotticus: http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/Lexicon.rst#n32
15:36:46 <scotticus> sweet, a glossary
15:37:03 <zehicle> deployed matches the vocabulary that markvoelker asked us to use
15:37:12 <hogepodge> markvoelker: what could we do to clarify that language?
15:37:13 <markvoelker> scotticus: see also http://www.openstack.org/brand/interop/....basically, the components we have today are Compute and Object Storage
15:37:48 <edmondsw> are other components being evaluated?
15:37:49 <markvoelker> hogepodge: I can suggest some wording in gerrit, but I wanted to understand what the intent was in case my perception was wrong
15:38:10 <zehicle> markvoelker, is the intent clear then?
15:38:26 <hogepodge> Components roughly correspond with marks. So storage with "OpenStack Powered Storage", compute with "OpenStack Powered Compute", and compute and storage with "OpenStack Powered Platform"
15:38:55 <hogepodge> one could image a database component that corresponded to "OpenStack Powered Database"
15:38:57 <markvoelker> zehicle: I think so...how about I propose a change in gerrit after the meeting and you can tell me if I understood it correctly? =)
15:39:01 <zehicle> they directly correspond
15:39:08 <zehicle> +1
15:39:18 <hogepodge> zehicle: it's not one to one is what I was hitting at. :-D
15:39:18 <markvoelker> Ok, 20m to go...suggest we move on
15:39:22 <zehicle> markvoelker, my question was if more discussion was needed
15:39:39 <hogepodge> #action markvoelker to suggest wording for policy change
15:39:54 <markvoelker> zehicle: I think it's sufficient to carry further conversation in gerrit at this point.  Thanks!
15:40:16 <hogepodge> What's our timeline for getting a final thumbs up/down?
15:40:28 <hogepodge> zehicle: when do you need it for the board?
15:40:37 <markvoelker> hogepodge: I can put my suggestion in today FWIW.
15:40:51 <zehicle> Friday
15:40:59 <zehicle> needs to have time for board review
15:41:22 <hogepodge> Ok, so let's plan to work the next two days to have all of the new reviews ready to go or drop.
15:41:23 <zehicle> We can still make patches to the 2015B draft after the merges
15:41:30 <hogepodge> Next topic
15:41:38 <hogepodge> #topic Finalize Advisory for Tokyo Board Meeting
15:41:53 <zehicle> you skipped 2016.01 create
15:42:07 <zehicle> related topic anyway
15:42:09 <hogepodge> #topic Plan for 2016.01 Creationroll
15:42:32 <hogepodge> zehicle: you have the stage
15:43:08 <zehicle> I'd like to create the 2016.01 Guideline ASAP so that we can collect comments on it
15:43:21 <zehicle> plan would be to use the .next file as is
15:43:34 <zehicle> then submit patches to remove non-consensus items
15:44:19 <markvoelker> zehicle: so to do that we need to finish the next three reviews on the agenda, yes?
15:44:19 <zehicle> ideally, that means we'd need to merge the items in process AND 1.4 schema changes
15:44:28 <hogepodge> I'd like to get the items from the three patches in the next topic in place.
15:44:50 <zehicle> markvoelker, yes HOWEVER, there's room to pass some items that are under discussion with the plan to remove them from 2016.01
15:45:14 <hogepodge> It looks like identity is stable. Some small changes to block storage, and name changes to images
15:45:38 <zehicle> so, I'd recommend that we can reduce some of the angst about hot items
15:45:51 <markvoelker> zehicle: sure.  Could you clarify one thing for me?  What are we presenting the Board in Tokyo exactly?  B/c the next Guideline isn't due for approval until 2016.01, right?
15:45:57 <zehicle> if we are taking them out of 2016.01 and allowing disucssion to continue on .NET
15:46:01 <hogepodge> I removed one cinder item because of the proposed one item rule, but think we should pull it back. I'll send it up directly after the meeting.
15:46:08 <zehicle> NEXT
15:46:20 <markvoelker> E.g. w're not asking them to approve it until January, just advising on what we're planning to ask for approval on?
15:46:44 <zehicle> yes
15:47:01 <zehicle> we can remove from now till then  but not add
15:47:16 <markvoelker> Ok, so essentially it's advisory until January.  That's fine.
15:47:18 <markvoelker> Thanks
15:47:31 <hogepodge> #link cinder/identity https://review.openstack.org/#/c/221631/
15:47:42 <hogepodge> #link glance/images https://review.openstack.org/#/c/213353/
15:47:47 <zehicle> the status would flip from "draft" to "preliminary" I believe
15:48:01 <hogepodge> #link keystone/identity https://review.openstack.org/#/c/213330/
15:48:18 * hogepodge notes error on first link, should read cinder/block storage
15:48:29 <zehicle> hogepodge, I'm done w/ that topic.  I just wanted everyone to know that we were not doing final versions
15:48:35 <zehicle> and state timeline
15:48:38 <hogepodge> zehicle: ok
15:48:51 <hogepodge> #topic Final advisory for .next
15:49:40 <hogepodge> Are we good to start merging those new advisory capabilities.
15:49:58 <hogepodge> I want to send one more patchset up for Cinder, pulling one capability back in.
15:50:20 <markvoelker> hogepodge: there have been a couple iterations recently on those, but they're mostly in good shape.  I'll peruse them one more time today, but I don't see why we couldn't land them before Friday.
15:50:25 <hogepodge> Once we're at consensus and zehicle and/or egle approves, I'd like to start merging and reconciling.
15:51:00 <hogepodge> With approval from chairs, I'd like authority to resolve conflicts once merging starts without +2 from chairs.
15:51:15 <zehicle> since we can continue to tweak after merge, I'd rather see if we can get agreement during the meeting
15:51:35 <zehicle> hogepodge, works for me.
15:52:22 * zehicle grants hogepodge approval
15:53:20 <hogepodge> The last change I want to make on cinder is to pull back copy-volume-to-image #link https://review.openstack.org/#/c/221631/11..12/2016.next.json,cm
15:53:54 <hogepodge> Aside from that I'm good to go. Anyone else have final comments on them?
15:53:59 <scotticus> you want it back in?
15:54:48 <scotticus> hogepodge ^?
15:55:03 <hogepodge> for now yes, it's not permanent, just advisory. If it goes out it's gone, but there is still open discussion on if it should be there or not. The other was dropped because it's an extension and not guaranteed to be there
15:55:04 <zehicle> we need to discuss apparently, but I would rather not see single test capabilities.  Can't we put it into another Cap?
15:55:26 <hogepodge> zehicle: Yes, I'll merge image-volume interactions into one capability
15:55:33 <zehicle> hogepodge, thank you
15:55:44 <hogepodge> Can we continue on gerrit? With five minutes left I want to be sure to hit the next item.
15:55:49 <zehicle> yy
15:55:55 <markvoelker> hogepodge: ++
15:55:55 <hogepodge> #topic Recurring Test Recommendation
15:55:58 <scotticus> i'm going to push back on the volume->image
15:57:03 <hogepodge> scotticus: understood. fwiw, I'm advocating for it now to keep discussion open, not to make it permanent. I also have reservations about the image<->volume caps
15:57:13 <hogepodge> markvoelker: you have the stage
15:57:13 <markvoelker> #link https://review.openstack.org/#/c/232128/ Recurring testing recommendations
15:57:38 <zehicle> this may be a topic for the summit.   I think the intent make sense
15:57:41 <markvoelker> So a couple weeks ago we realized there were some major inconsistencies between DefCore's language and what's actually in the Foundation legal contracts
15:57:57 <markvoelker> Chris is working on changes, one of which dealt with recurring testing
15:58:11 <markvoelker> He asked us to put together some recommendations to the Foundation about how to handle that.
15:58:27 <markvoelker> I volunteered to put together a strawman to start that discussion, which is the link above.
15:58:49 <hogepodge> I'm not a fan of the four week window
15:59:01 <dwalleck> markvoelker: I'm really interested in this one. I'll have a look and add some feedback
15:59:25 <hogepodge> I prefer allowing vendors to test early if they want, otherwise must pass current tests within a year.
15:59:28 <markvoelker> hogepodge: totally fine and not unexpected.  It's a conversation starter.  So, definitely make suggestions in gerrit. =)
15:59:39 <hogepodge> yup, just send. :-D
15:59:41 <markvoelker> (seeing as how we have 1 minute)
15:59:48 <markvoelker> hogepodge: ty
15:59:54 <zehicle> I
16:00:09 <dwalleck> I'm already working on continuous testingDefCore  for our cloud, but I'd be interesting in seeing what the concrete ask is
16:00:13 <zehicle> I'd like to get this on the summit discussion agenda.  I had a suggestion too (not enough time to discuss here)
16:00:22 <hogepodge> Ok, we're at time.
16:00:30 <hogepodge> Let's move to #defcore and free the room.
16:00:33 <hogepodge> Thanks everyone!
16:00:40 <hogepodge> #endmeeting