16:01:01 <markvoel_> #startmeeting defcore
16:01:01 <openstack> Log:            http://eavesdrop.openstack.org/meetings/monasca/2016/monasca.2016-06-22-15.01.log.html
16:01:03 <openstack> Meeting started Wed Jun 22 16:01:01 2016 UTC and is due to finish in 60 minutes.  The chair is markvoel_. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:07 <openstack> The meeting name has been set to 'defcore'
16:01:21 <markvoel_> #chair hogepodge
16:01:22 <openstack> Current chairs: hogepodge markvoel_
16:01:48 <hogepodge> o/
16:01:50 * markvoel_ notices his IRC nic and wonders what the heck happened there...but figures maybe that'll make rockyg happy
16:02:09 * notmorgan slips into the back of the room and lurks.
16:02:10 <luzC> o/
16:02:10 <catherineD|2> o/
16:02:13 <markvoel_> #link https://etherpad.openstack.org/p/DefCoreLunar.8 Today's agenda
16:02:31 <VanL_> o/
16:02:36 <hogepodge> markvoel_: "There are only two hard things in Computer Science: cache invalidation and naming things."
16:02:40 <hogepodge> and off by one errors
16:02:45 <markvoel_> heh
16:02:51 <gema> o/
16:03:00 <markvoel_> #topic Midcycle Planning
16:03:02 <notmorgan> markvoel_: the uhm... etherpad is erroring for me?
16:03:20 <markvoel_> notmorgan: hmm...working for me.  Anyone else having problems?
16:03:37 <notmorgan> markvoel_: TypeError: null is not an object (evaluating 'pad.collabClient.setChannelState') in https://etherpad.openstack.org/javascripts/lib/ep_etherpad-lite/static/js/pad.js?callback=require.define at line 266'
16:03:53 <notmorgan> and now it's back
16:03:55 <notmorgan> nvm
16:04:00 <markvoel_> notmorgan: ok, cool
16:04:16 <markvoel_> #link https://etherpad.openstack.org/p/DefCoreSummer2016Sprint Etherpad for midcycle planning
16:04:59 <markvoel_> Last week we asked folks to denote what venues work best for them.  Looking at the results, it looks like San Antonio and Palo Alto are pretty close
16:05:17 <markvoel_> San Antonio looks like it works best for folks assuming everyone doesn't mind holding it in Texas again
16:05:40 <gema> it's summer, will we survive?
16:05:43 <markvoel_> Any objections to selecting San Antonio at this point?
16:06:02 <gema> nah, sounds good
16:06:17 <VanL> We'll try to import some cooler weather, but no guarantees.
16:06:32 <markvoel_> Ok then, sounds like we have a venue.
16:06:32 <gema> VanL: as long as you get us water, we'll be fine :D
16:06:43 <hogepodge> lgtm
16:06:51 <brunssen> Fine with me
16:07:05 <markvoel_> As for the date, we'd picked the week of August 1 and one or two folks has noted a preference for "don't start on Monday"
16:07:52 <brunssen> August 2 - 4?
16:08:10 <markvoel_> We also need to set a length.  It sort of feels like we have 2-3 days worth of work here, so I'm thinking Tues-Thur.
16:08:22 <markvoel_> brunssen: yes, that. =)
16:08:23 <Rockyg> o/
16:08:24 <gema> sounds great, we can be home for the weekend
16:08:48 <luzC> +1
16:08:57 <markvoel_> VanL: (since RAX is hosting) does that work ok?
16:09:13 <VanL> All right, I'll get the hamsters moving. It should, but let me confirm.
16:09:28 <VanL> How many should I plan for? 25ish?
16:09:45 <Rockyg> I can hear those hamster wheels squeaking now
16:10:04 <VanL> We have a couple different venues, depending on how many we expect.
16:10:05 <hogepodge> We need to update the community sprint page once confirmed
16:10:09 <hogepodge> #link https://wiki.openstack.org/wiki/Sprints
16:10:37 <markvoel_> VanL: feels about right
16:10:47 <VanL> I'll ask for 30
16:10:58 <markvoel_> VanL: We can set up an Eventbrite or something to get actually attendance confirmed of course.
16:11:09 <Rockyg> sounds good
16:11:10 <hogepodge> VanL: QA hasn't set a date yet, maybe I could check with them to see if we could have a joint meeting?
16:11:19 <markvoel_> hogepodge: yep, already on my to-do list pending the outcome of today's meeting =p
16:11:29 <gema> hogepodge: they are looking at infra/qa together and they want to do Sept 19-21
16:11:39 <hogepodge> gema: ah, thanks
16:11:46 <gema> np, that's what oomichi told me
16:12:01 <Rockyg> gema, ++
16:12:04 <gema> but they were stilll planning
16:12:07 <hogepodge> It's listed in the sprint page too, hidden by the infra prefix :-D
16:12:24 <VanL> hogepodge: How would that affect the number of people I should ask for?
16:12:43 <gema> hogepodge: maybe we should try to ask for presence from them
16:12:46 <gema> that'd be neat
16:12:55 <gema> even if we don't manage a full double sprint
16:13:07 <hogepodge> VanL: QA sprints are usually 13, but it looks like they're covered with infra
16:14:22 * markvoel_ notes that we can also set up dialin/video call too per the usual if QA folks can't be there
16:15:01 <markvoel_> Ok, speaking of things we want to get done and people we want to talk to during the midcycle:
16:15:10 <markvoel_> We have a list of tenative agenda items in the etherpad
16:15:53 <markvoel_> If we have tentative agreement on the dates and venue, I'll start drafting an official agenda with eglute and send it out for comments
16:16:15 <markvoel_> So this is your last, last, last opportunity to add topics to the list if you haven't already. =p
16:16:21 <VanL> Ok, hamsters are scurrying. I'll see how fast they come back.
16:16:54 <hogepodge> markvoel_: what's the cutoff time for agenda items?
16:16:55 <markvoel_> Let's record a few things for the meeting notes:
16:17:41 <markvoel_> hogepodge: Let's say Friday
16:17:49 <markvoel_> #agreed DefCore Committee Midcycle will be August 2 - 4 at Rackspace in San Antonio (pending VanL getting approval)
16:18:04 <markvoel_> #action VanL to check on/confirm venue
16:18:24 <markvoel_> #action everyone make final additions to the topics list by Friday
16:18:50 <markvoel_> #action markvoelker Begin drafting official agenda from topic list
16:19:37 <markvoel_> #action markvoelker to add info to the Sprints page once venue confirmed
16:21:23 <markvoel_> #action markvoelker to work with VanL to set up event registration ensuring we get all the necessary info RAX needs
16:21:29 <markvoel_> Ok, anything I missed?
16:22:01 * markvoel_ hears none
16:22:09 <markvoel_> Ok, anything else to discuss on the midcycle topic?
16:22:40 <markvoel_> Ok, moving on then...
16:22:55 <markvoel_> #topic Proposals and recommendations for the board meeting
16:23:28 <markvoel_> We talked some about this last week and I'm drafting up some materials for the Baord this week with Egle.
16:23:40 <markvoel_> #link https://etherpad.openstack.org/p/DefCoreLunar.7 last week's notes on Board meeting stuff
16:25:39 <markvoel_> Was there stuff in the pad today that folks wanted to discuss now?
16:25:58 * markvoel_ is not sure who added the "possible questions to put before the board" bits here
16:26:37 <VanL> I added that
16:26:44 <Rockyg> So where are we on the name change.
16:26:53 <VanL> (Sorry, was briefly afk)
16:27:12 <markvoel_> Ah, thanks VanL.  Did you want to discuss that now?
16:28:00 <hogepodge> We need to send our agenda to the board before the meeting, so they have time to think about the items we could be bringing to them.
16:28:25 <VanL> Sure. I put some of my thougths in the etherpad.
16:29:00 <markvoel_> hogepodge: right, Egle and I are already working on it
16:29:23 <Rockyg> I think this board meeting is a little too close for the more contentious but still fuzzy issues.  I think we need to write up the alternatives, like hogepodge  did but for the board
16:29:39 <VanL> The biggest thing is the questions about the specification - and that has a direct bearing on the extra properties issue.
16:30:02 <Rockyg> The extension thing is close, but *we* need a position before we ask the board what they think
16:30:26 <catherineD|2> Rockyg: Close means no extension?
16:30:39 <VanL> We want to have a clear sense of where we stand on the various issues, or at least we need to set out the questions and positions.
16:30:47 <Rockyg> We have a general position, but we need to get more details down
16:31:00 <markvoel_> Rockyg: Actually I'd think the Board's thoughts on the topic might influence our decision. =)  So, two-way street.
16:31:23 <Rockyg> That's why the various alternatives need to be mapped out.
16:31:28 <markvoel_> ++
16:31:59 <Rockyg> And, yes direction from them, but we need to provide the least biased analysis we can.
16:32:50 <markvoel_> So, hogepodge: last week we discussed having an official proposal drawn up so we could collaborate and vote on it via gerrit...if that's approaching readiness it might be useful to highlight as one of the options on the table
16:33:11 <Rockyg> ++
16:33:13 <hogepodge> markvoel_: yeah, I can send it up today
16:34:05 <Rockyg> thanks, hogepodge
16:34:26 <markvoel_> hogepodge: OK, great.  I'll have a draft of the Board packet document ready later this week (probably tomorrow), so I'll add it once I get the link
16:35:04 <markvoel_> VanL: I'll also try to incorporate some the questions you've posted to the pad here (and the ones that have come up over the course of the debate).
16:35:30 <VanL> markvoel_: That is about the same thing that I wanted to discuss, so I don't have any more at this point. Where would discussion of the board packet take place once it is shared?
16:36:40 <markvoel_> VanL: we usually do it as a Google doc, so I'll send out a link to the ML once Egle and I have hashed through it a bit and solicit comments from
16:36:43 <Rockyg> I'd like to throw out something to the group: "OpenStack Compatible"
16:37:16 <markvoel_> Rockyg: You mean this thing? http://www.openstack.org/brand/openstack-compatible/
16:37:25 <Rockyg> It is a mark that the foundation provides but it really doesn't have a fixed, immutable definition
16:37:41 <Rockyg> Yup.  Some focus is needed on that.
16:37:55 <VanL> markvoel_: Thanks.
16:37:57 <Rockyg> But isit us, another wg, or what
16:38:09 <Rockyg> It
16:38:29 <Rockyg> is pretty much "if it's in our tree and it's a driver, it's compatible"
16:38:42 <Rockyg> But that has lots of gaps and gotchas
16:39:16 <Rockyg> We, as defcore, need to get the board focused on getting that better defined
16:39:31 <Rockyg> Or a process around getting it or something
16:40:44 <markvoel_> hogepodge: not sure if you have any enlightenment to offer on how the Foundation administers the Compatible logo program? =)
16:41:25 <hogepodge> markvoel_: Rockyg: this is the place to start http://www.openstack.org/brand/openstack-compatible/
16:42:03 <Rockyg> Yeah. Currently the requirement is "demonstrate compatibility"  and that'
16:42:06 <Rockyg> s it.
16:42:20 <hogepodge> where upstream testing is available (block storage and bare metal drivers), we require it
16:42:27 <Rockyg> Elsewhere on the pages, there is a statement that if it's "in tree"
16:42:38 <Rockyg> That statement mostly refers to drivers.
16:42:56 <hogepodge> it's mostly based on trust, because all products don't fall into a strict category
16:43:24 <Rockyg> hogepodge, right.  But all the drivers are mixed together.  Maybe we should at least highlight which ones have stricter testing?
16:43:28 <hogepodge> Storage is easy, networking should be easy (and we're working upstream to define how to test network drivers), but applications are much more fuzzy.
16:43:31 <Rockyg> Or maybe the board should.
16:43:42 <Rockyg> Hypervisors are, too.
16:44:26 <Rockyg> The storage drivers, I think would be a good place to put some sort of statement if they are ok.
16:44:46 <Rockyg> They've got the best vetting from the dev community
16:45:12 <hogepodge> Rockyg: for storage drivers this is stated on the interop page
16:45:17 <Rockyg> And you're right, networking is closer, but the whole stadium thing has clouded it.
16:45:19 <hogepodge> http://www.openstack.org/brand/interop/
16:45:36 <markvoel_> Rockyg: OK, so I'd suggest that you add this to the list in today's etherpad and I'll see if we've got time to work it into the meeting.
16:45:52 <hogepodge> Rockyg: the networking team has not been successful in defining and enforcing test standards, compared to the storage driver team.
16:46:50 <Rockyg> hogepodge, yup.  Maybe if we can put a star or something next to the releases the storage products have certified against, the networking folks who are interested will get more serious;-)
16:47:39 <hogepodge> Rockyg: these discussions are ongoing, we've been working on it for a while, and bad behavior lead the networking team to not want to try and police testing
16:48:14 <hogepodge> Rockyg: we are actively working on it, but we can only go so far as upstream helps us with
16:48:52 <Rockyg> Yup.  Networking is notorious because they come from the "standards" way of doing things rather than the "open source" process
16:49:44 * markvoel_ glances at the clock and suggests moving on to our last topic unless there's something more you want to discuss
16:49:59 <Rockyg> please...let's move on.
16:50:16 <markvoel_> #topic outstanding reviews
16:50:35 <markvoel_> Last week we had an AI to review this one:
16:50:42 <markvoel_> #link https://review.openstack.org/#/c/329727/ Update documentation
16:51:12 <markvoel_> hogepodge: quick question: was the new RST generated by the jsonToRst.py script?
16:51:30 <hogepodge> markvoel_: yes
16:51:43 <hogepodge> markvoel_: some of it, some of it was hand written
16:52:06 <markvoel_> Ok, thought that might be the case...wanted to see if that script needed some love to continue to be useful
16:52:22 <hogepodge> markvoel_: I used the output of the script unmodified
16:52:38 <hogepodge> for 2016.01.rst and next.rst
16:53:01 <markvoel_> nifty
16:53:04 <hogepodge> index and 1.5 are my work, and 1.5.rst needs an update based on catherineD|2's comment
16:53:26 <catherineD|2> I reviewed it and think that we should preserve the history/comment from the schema to the doc
16:53:36 <catherineD|2> hogepodge: thx
16:53:41 <markvoel_> I'm ok with that
16:53:56 <Rockyg> +1
16:53:59 <markvoel_> Ok then:
16:54:12 <markvoel_> #action hogepodge address catherineDl2's comment
16:54:24 <markvoel_> #action everyone review hogpodge's forthcoming patchset and we'll get this landed
16:54:40 <Rockyg> ++
16:54:43 <markvoel_> Moving on to the test spec?
16:54:57 <markvoel_> #link https://review.openstack.org/#/c/317531/ Test spec
16:55:01 <markvoel_> gema: take it away
16:55:20 <gema> I have not much to say
16:55:26 <gema> other than the reviews went silent
16:55:31 <gema> and I am not sure how to finish it
16:55:34 <hogepodge> I have more to add to the review
16:55:34 * Rockyg slinks into a dark corner hoping to avoid notice
16:55:44 <gema> hogepodge: cool, please do
16:55:54 <VanL> gema: Me too, been occupied with ... other things
16:55:56 <gema> Rockyg: you too
16:56:06 <Rockyg> Darn, you saw me...
16:56:07 <gema> VanL: perfect, please do :D
16:56:12 <gema> ok, so it'll keep going
16:56:20 <gema> markvoel_: nothing else from me
16:56:23 <catherineD|2> If I understand correctly seems like VanL: suggested us to add the extra properties info to the spec
16:56:44 <hogepodge> tl;dr because openstack has many ways to accomplish a capability, it's possible for a test to require access to multiple api's to exercise a capability. this will be more true as the new image upload functionality lands in glance this cycle
16:57:36 <markvoel_> Ok, we're down to the last couple of minutes here, so, allow me to suggest that we get those comments in gerrit rather than try to tackle them here today
16:57:45 <gema> sounds good
16:57:58 <markvoel_> #action everyone please add your comments to https://review.openstack.org/#/c/317531/
16:58:12 <VanL> catherineD|2: Part of what I think should be added is that defcore is a foundation of agreed-upon funcitonality (MUSTs), and does not include any MUST NOTS
16:58:13 <hogepodge> In the last minutes, can people with an opinion on this respond to the thread I started here? http://lists.openstack.org/pipermail/defcore-committee/2016-June/001123.html
16:58:39 <hogepodge> in meeting time it's hard to nail down thoughts
16:58:40 <catherineD|2> VanL: ++
16:59:00 <markvoel_> #action everyone please add thoughts to http://lists.openstack.org/pipermail/defcore-committee/2016-June/001123.html
16:59:05 <VanL> Ok, I must drop.
16:59:12 <markvoel_> Aaaaand we're out of time.  Thanks folks!
16:59:17 <gema> thanks!
16:59:25 <markvoel_> #endmeeting