16:26:38 <eglute> #startmeeting defcore
16:26:39 <openstack> Meeting started Wed Apr 13 16:26:38 2016 UTC and is due to finish in 60 minutes.  The chair is eglute. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:26:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:26:43 <openstack> The meeting name has been set to 'defcore'
16:26:57 <eglute> well, at least some official logs :)
16:27:08 <eglute> #topic Flag multi-tenant tests
16:27:15 <eglute> #link https://review.openstack.org/#/c/253138/3
16:28:09 <eglute> i am ok with flagging multi-tenant tests
16:28:39 <eglute> especially since the new patch
16:28:50 <markvoelker> hogepodge: needs a D404 proposal though (see comment from March 31)
16:29:07 <eglute> it was part of different PR right?
16:29:23 <hogepodge> yes
16:29:59 <hogepodge> no rush on this one (as opposed to the previous), I can rework it.
16:30:37 <eglute> ok, in that case will give more time for others to review it?
16:30:58 <markvoelker> and for the D404 to be removed =)
16:31:33 <eglute> in that case, next topic?
16:31:37 <markvoelker> ++
16:31:44 <eglute> #topic
16:31:44 <eglute> Preference for using direct API calls for image
16:31:45 <catherineD> hogepodge: I put a -1 on https://review.openstack.org/#/c/289071/  so that we can discuss testless capbility
16:31:49 <eglute> #topic Preference for using direct API calls for image
16:32:07 <eglute> #link http://lists.openstack.org/pipermail/openstack-dev/2016-April/091466.html
16:32:08 <catherineD> hogepodge: I will remove it now that we will have some action
16:32:36 <hogepodge> still needs a -1 for 404 :-D New change set will be forthcoming
16:33:11 <eglute> thanks hogepodge
16:33:12 <hogepodge> For this topic, longer term thinking
16:33:29 <hogepodge> It sounds like the TC and community want to stop using nova proxies.
16:33:33 <markvoelker> Yup.  Good to see this being discussed.
16:33:53 <markvoelker> I will be interested to know what action comes out of it. =)
16:34:03 <eglute> +1
16:34:09 <hogepodge> So, we need to think about changing up compute capabilities to match that thinking. Which we're already doing.
16:34:35 <markvoelker> hogepodge: well, the question is whose thinking actually prevails I think.
16:35:09 <hogepodge> markvoelker: how much contention is there over the issue of proxies?
16:36:15 <markvoelker> hogepodge: I'm not sure.  Nova has said they're not going to remove the API.
16:36:25 <eglute> http://lists.openstack.org/pipermail/openstack-dev/2016-April/091479.html
16:36:43 <hogepodge> markvoelker: nova won't remove it because microversions, afaik, but they want to discourage it heavily
16:36:45 <markvoelker> If external tools, SDK's, and users are still using it and it isn't going away...
16:37:05 <eglute> sounds like it will be a while at least
16:37:25 <hogepodge> it causes headaches (all the flags because of glance v1 image proxy, for example)
16:37:25 <catherineD> eglute: I think so too
16:37:27 <markvoelker> Right, that's what kind of what I'm getting at: if they don't want people using it, how is that message going to get out and what practical effect will it have on getting people (and SDK's, and tools, etc) to move to the Glance API's?
16:39:14 <eglute> so, is this one of those topics that we can think about but do nothing about?
16:39:51 <hogepodge> we can communicate our current state to the community to help guide discussions and decisions
16:40:13 <markvoelker> Sure.  And we can also make sure we're scoring the glance image capabilities appropriately too.
16:40:21 <hogepodge> right now we require the proxies in some way, but should be not be requiring them in favor of the other apis?
16:40:51 <catherineD> hogepodge: I think so
16:41:10 <catherineD> at least remove/flag those from the must-pass tests
16:41:15 <markvoelker> hogepodge: if the nova API's meet all the criteria, I have basically zero problem with them being in the Guideline.  I also have zero problem with the Glance API's being in the Guideline if they meet all the criteria.
16:42:07 <markvoelker> Basically there's nothing forcing us to pick one or the other if they both meet criteria.  I do want to be mindful of the outcome of the conversation though, as it may indicate that scoring changes
16:42:12 <catherineD> markvoelker: then people will have not reason to move to Glance API ?
16:42:45 <hogepodge> catherineD: they have a real reason right now. v2 is not supported by nova
16:42:54 <markvoelker> E.g. if nova takes definitive steps to remove support for the nova image API or document it as "do not use this" then I wouldn't want to score it 1 for "future direction" for instance
16:43:07 <eglute> markvoelker +1. we need to remember that defcore is trailing, not leading when it comes to new features. Yes, we look at the technical direction, and we have in the past. But it also sounds like glance v2 still has a lot of work that needs to happen
16:43:55 <eglute> i suggest for the sake of time we table this discussion for a later time?
16:44:09 <hogepodge> eglute: +1 to closing discussion and moving on
16:44:21 <eglute> #topic Certifying Mitaka clouds
16:44:28 <markvoelker> Basically I want Nova and Glance to convince the ecosystem what the best way of doing things is (or reduce the number of ways to do it, gracefully) rather than us dictating that.
16:44:31 <markvoelker> eglute: +1
16:44:53 <eglute> markvoelker i agree with you there!
16:44:57 <catherineD> which guideline should be used to certify Mitaka clouds?
16:45:24 <hogepodge> we need a policy for new releases
16:45:37 <eglute> i was thinking about this, and it seems like we have some pacing issues when it comes to guidelines
16:45:56 <eglute> i would say new releases can be certified under the current guideline
16:46:01 <eglute> how does that sound?
16:46:16 <hogepodge> maybe we need to change supported released to say "x or newer", where x is release name
16:46:29 <eglute> hogepodge +1
16:46:31 <cjvolzka> eglute: +1
16:46:36 <luzC> eglute +1
16:46:42 <markvoelker> hogepodge: for products with existing license agreements in place, are tehy currently covered with their existing agreements?
16:46:50 <markvoelker> I can't recall the legalese in the contract
16:46:53 <hogepodge> this line http://git.openstack.org/cgit/openstack/defcore/tree/2016.01.json#n9
16:47:12 <hogepodge> markvoelker: let me look at the contract
16:47:46 <eglute> hogepodge right, i think we need to change it.
16:47:48 <markvoelker> hogepodge: ok.  Still wouldn't help new products being introduced for the first time, but curious what the language says now
16:48:12 <eglute> if we make a change to the guideline, we need to ask for the board's approval during the next meeting
16:48:27 <eglute> should not be a problem, just part of the process
16:48:39 <catherineD> eglute:  if that is the case , how do user interpret  line 9 in https://github.com/openstack/defcore/blob/master/2016.01.json means -->   "releases": ["juno", "kilo", "liberty"],
16:48:59 <catherineD> if we can use 2016.01 to certify Mitaka clouds
16:49:06 <markvoelker> I think it's a reasonable thing to propose.  Out of curiosity, do we actually have someone trying to certify a Mitaka product already that sparked this?
16:49:12 <docaedo> catherineD: good question, I was about to ask the same thing
16:49:19 <catherineD> markvoelker: yes
16:49:27 <eglute> we could add "mitaka", or say, "newer release" and point to openstack releases page
16:49:35 <catherineD> eglute: that works
16:49:36 <cjvolzka> markvoelker: We are - PowerVC
16:49:42 <markvoelker> good to know =)
16:49:47 <eglute> #link http://releases.openstack.org/
16:50:02 <docaedo> markvoelker: yes, also I think we need to encourage people to use the new release as soon as possible :) so looks good when we can certify clouds on the newest release
16:50:06 <markvoelker> So, changing the Guideline doc still requires Board approval.  However it's ultimately up to the Foundation to grant license agreements.
16:50:46 <markvoelker> That means that irrespective of what the Guideline doc says today they could technically still grant an exception and grant a license.
16:50:57 <markvoelker> (until we get the Board to vote on changing the doc)
16:51:00 <eglute> right, the board meeting is on the 4/24, so if have a patch that everyone agrees on, we can ask for boards approval then
16:51:10 <markvoelker> Don't know if that's a helpful escape valve for you. =)
16:51:22 <catherineD> eglute: +1
16:51:47 <eglute> +1 on exceptions, especially if we agree now that this will be the direction: newer releases can use current guideline
16:52:07 <markvoelker> Who's got the AI to propose the change?
16:52:10 <catherineD> eglute: Need to document somewhere
16:52:19 <hogepodge> a foundation all writs act (he kids)
16:52:36 <eglute> #action hogepodge to propose a change to current guideline include newer releases
16:53:21 <cjvolzka> markvoelker: We actually have a test left to finish before we're ready to certify so waiting for board approval won't be an issue depending on their turnaround.
16:53:23 <eglute> catherineD agree, was thinking after the PR is in place of sending an email to let people know
16:53:47 <catherineD> eglute: thanks
16:53:50 <eglute> cjvolzka if approved, it would be immediate, on 4/24
16:54:07 <cjvolzka> That would be fine then
16:54:19 <hogepodge> foundation won't hold up license agreement for mitaka, unless board or working group objects
16:54:35 <markvoelker> Ok, cool.  While that patch is getting written, I'd like to think over some of the corner cases...e.g. what happens if something gets deprecated or broken in between when a Guideline is written and when the next release comes out
16:54:59 <markvoelker> (imagine we'd handle that with flags, but there are probably some other cases to think through)
16:55:25 <markvoelker> Almost out of time...move on?
16:55:34 <eglute> well, i think flags would cover it. bigger concern is whether we allow 2 last guidelines to be used or not
16:55:59 <eglute> yes, lets move on and keep thinking about this
16:56:04 <cjvolzka> eglute: I thought it was just the current last one guideline?
16:56:37 <eglute> cjvolzka currently you can certify against 2 last guidelines, but each guideline specifies releases
16:57:05 <cjvolzka> ahh ok
16:57:21 <eglute> we will run out of time for other topics, but i will be in defcore IRC after
16:57:27 <eglute> #topic Austin Summit
16:57:52 <eglute> please start adding topics for a working session: #link https://etherpad.openstack.org/p/DefCoreRing.AustinSummit2016
16:58:19 <eglute> and for refstack session: #link https://etherpad.openstack.org/p/refstack-newton-summit
16:58:38 <Rocky_g> cool
16:59:06 <catherineD> eglute: Dies it make sense to alert DefCore/RefStack sessions via defcore mailing list?
16:59:22 <catherineD> I am sure people can search too
16:59:39 <eglute> catherineD yes, i will send out calendar invites to those :)
16:59:47 <catherineD> eglute: thanks
17:00:10 <catherineD> right now seems like DefCore abd RefStack sessions are not overlapping
17:00:11 <eglute> we are almost out of time. stay for scoring cinder/swift in defcore IRC?
17:00:35 <catherineD> and Heat scoring
17:00:45 <markvoelker> I can stick around for a couple of minutes, but have to run shortly
17:00:45 <hogepodge> I have a call, but can try to multi-task
17:00:53 <eglute> ok, i will be around
17:00:58 <eglute> thanks everyone!
17:01:00 <eglute> #endmeeting