15:00:07 <eglute> #startmeeting defcore
15:00:07 <openstack> Meeting started Wed Sep 30 15:00:07 2015 UTC and is due to finish in 60 minutes.  The chair is eglute. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:11 <openstack> The meeting name has been set to 'defcore'
15:00:16 <hogepodge> o/
15:00:27 <eglute> #link https://etherpad.openstack.org/p/DefCoreFlag.17
15:00:49 <eglute> hello everyone! Roll call, raise your hand if you are here for defcore meeting
15:00:53 <catherine_> o/
15:01:24 <GheRivero> o/
15:01:45 <dwalleck> o/
15:01:49 <eglute> #topic agenda
15:01:53 * dcarmon raise hand
15:01:57 <markvoelker> o/
15:02:05 <eglute> please review agenda and add or update as appropriate #link https://etherpad.openstack.org/p/DefCoreFlag.17
15:02:29 <eglute> #topic licensing language
15:02:49 <eglute> hogepodge can you speak about it?
15:03:05 <hogepodge> The current powered license states "Your product will be required to pass the current test on an annual basis, which will generally require you to be running either of the latest two software releases."
15:03:36 <hogepodge> The Foundation wanted clarification on two issues. The first is annual testing. Does the Defcore committee want annual testing of products?
15:03:55 <markvoelker> hogepodge: let's clarify one more thing first
15:03:57 <eglute> can you elaborate what you mean
15:04:23 <markvoelker> The license agreements are currently drawn up against a product (such as "Red Hat OpenStack Platform" or "VMware Integrated OpenStack")
15:04:28 <hogepodge> The second is in the requirement. We plan on changing it to "latest guidelines approved by the board and defcore committee", or somilar language.
15:04:40 <markvoelker> Not a specific version of a product (e.g. VMWare Integrated OpenStack 2.0)
15:05:11 <markvoelker> So if the annual testing requirement applies to a product and not a specific version, that seems reasonable.
15:06:16 <eglute> hogepodge are you saying foundation would like to change defcore testing against only one rather than two last guidelines?
15:06:46 <hogepodge> Would it be better to require testing for product updates? Defined as changing the version of shipped or deployed code.
15:07:26 <eglute> i am still confused what it is that you are asking... but it could be the lack of coffee
15:07:28 <dwalleck> hogepodge: Would that mean re-testing for every deployment of code for a public cloud?
15:07:28 <hogepodge> eglute:  no, we want to remove the language of running the latest two releases and let releases covered be defined by however many guidelines are board approved and currently active
15:07:46 <dwalleck> We update quite often
15:07:52 <markvoelker> hogepodge: So I'm personally not overly concerned about minor maintenance updates.  I'd much rather users of OpenStack products get updates faster and not have to wait on legal hoops to be jumped through.
15:07:58 <hogepodge> dwalleck: I would hope you test on redeployment :-D
15:08:01 <rockyg> good question.  I would think if a new major version of a product is released, it should be retested
15:08:06 <hogepodge> dwalleck: but that's a different issue
15:08:16 <markvoelker> And I also think the chances of vendors making major capability changes in maintenance updates is reasonably small.
15:08:39 <hogepodge> dwalleck: that's why I was thinking major version boundaries. the one year phrase I think is meant to catch public clouds who have rolling updates.
15:08:44 <eglute> hogepodge so if the last two guidelines are still active, nothing would change?
15:08:47 <dwalleck> hogepodge: I thought that was what you meant by requiring of testing updates
15:09:04 <hogepodge> eglute: it would change. The latest two guidelines cover three releases afaik
15:09:16 <rockyg> so, if the vendor rolls from juno to kilo...
15:09:21 <markvoelker> E.g. if there's an OSSA issued, I want products to be able to push that fix out immediately without worrying that they haven't gotten the Foundation's legal team to sign off on an agreement on the patch.
15:10:19 <hogepodge> markvoelker: dwalleck: to be clear, I'm not advocating testing on every update
15:10:52 <dwalleck> gotcha, thanks
15:10:54 <catherine_> regardless of the legal hoops, what if vendors want to test against every spec approved by DefCore to show their updated certification ?
15:11:14 <hogepodge> markvoelker: dwalleck: I just trying to define the conditions that require re-testing a product. Annual may be unfair to distributions, who value a stable and tested code base. By version is unfair to public providers, who update frequently.
15:11:19 <markvoelker> hogepodge: good. =)  So you're saying essentially when a vendor goes from 2.0->3.0 rather than 2.0->2.0.1?
15:11:49 <hogepodge> markvoelker: yes
15:11:51 <dwalleck> hogepodge: I see where you're coming from and that makes sense
15:12:00 <markvoelker> hogepodge: yeah, agree there may be some interesting challenges there.  Perhaps it's time we considered different models for public vs distro vs managed offerings.
15:12:24 <eglute> hogepodge can you give an example of against what and how often foundation would like to see testing happening?
15:12:29 <catherine_> currently data shown on refstack.net seems to be reference only... the version of spec shown on the OpenStack marketplace is what legally shown the version of spec that is certified against ..
15:12:32 <hogepodge> markvoelker: we capture that distinction in the trademark application.
15:13:09 <markvoelker> hogepodge: well, yes...but you still apply the same testing principals and schedules to them, no?
15:13:11 <hogepodge> markvoelker: One of my goals is to go back to our legal team with proposed language change that captures our intent.
15:13:55 <hogepodge> markvoelker: correct, I'm saying since we already ask about it we can easily identify the distinction and send the correct contract out if there are two cases
15:14:24 <markvoelker> hogepodge: gotcha, thanks
15:15:12 <eglute> hogepodge can you give an example of against what and how often foundation would like to see testing happening?
15:15:37 <markvoelker> eglute: I think the Foundation is asking us to tell them that. =)
15:15:55 <eglute> right now we do have that in our docs
15:16:02 <eglute> sounds to me like they want to change it
15:16:04 <hogepodge> I can give two examples. Linux distributor X releases a new version of OpenStack with every release. I would like to see that version tested against one of the active standards.
15:16:31 <eglute> ok
15:16:47 <markvoelker> So...here's a thought.
15:17:20 <hogepodge> Public cloud Y has rolling updates. I would like to know that continuous updates have not broken the api against the active standards after some time period of 'n' months.
15:17:39 <hogepodge> s/standards/guidelines/
15:17:54 <eglute> ok, that makes sense
15:18:34 <eglute> is the current way of once a year not working?
15:19:00 <markvoelker> eglute: well, it has problems
15:19:11 <catherine_> hogepodge: markvoelker: eglute:  regardless of legal hoops, what if vendors want to test their products against every approved DefCore specs?
15:19:13 <dwalleck> I'm actually working on continuous DefCore testing here at Rackspace to make sure we always know where we stand
15:19:47 <markvoelker> eglute: for example, if public clouds are pushing new updates all the time, they could break a capability tomorrow and not be required to retest/lose their logo unless they fix it for a full year.
15:20:01 <catherine_> dwalleck: you know where you stand but how do you communicate your result to your customer officially?
15:20:07 <hogepodge> catherine_: I would like to encourage continuous testing, and update agreements and marketplace pages based on latest results
15:20:17 <dwalleck> catherine_: Well, testing against every spec can be as simple as running the superset of those specs and then filtering the results by spec version
15:20:30 <markvoelker> catherine_: I think we should encourage that, and there is in fact a carrot for doing so: the MarketPLace
15:21:09 <eglute> I think defcore defines the minimum of once a year, so companies can test as often as they want. I am hesitant to impose more procedure for products that want to release things, but would have to worry about re-certifying
15:21:13 <catherine_> it is not a matter of testing ... it is a matter of communicate the  results publicly through officia channels ..
15:21:17 <markvoelker> The Marketplace doesn't just show whether you are OpenStack Powered(TM) or not, it also shows what Guideline you've tested against
15:21:46 <catherine_> Exactly, that is why we need a mechanism to update the marketplace
15:22:11 <dwalleck> catherine_: That's a next step I leave to folks like SamD. But it's a very legitimate question. I'm driving the feedback back into our internal dev teams at the moment
15:22:33 <markvoelker> catherine_: I'd also argue we need to get the Marketplace to show multiple product versions (for distros etc) and for it to show all Guidelines those versions adhere to, but maybe we're getting a little off in the weeds now. =)
15:22:57 <catherine_> markvoelker: yup ... that is what I am asking ...
15:23:16 <markvoelker> So back to the original thing about legal contracts:
15:23:28 <hogepodge> I can take all of those suggestions back to our marketplace team. They will most definitely not be implemented before the summit.
15:23:32 <eglute> there is an assumption that cloud offerings will start breaking guidelines they passed with subsequent releases. I doubt this would happen often. I think a better way would be to put in some language that says if product X breaks previous guideline that it passed that they must re-certify against another guideline
15:23:58 <markvoelker> hogepodge: yup, understood.
15:24:07 <rockyg> point of information..is everybody aware of the version identification change that is happening accross the projects?  away fro years and to x.y.z?
15:24:30 <markvoelker> rockyg: yes
15:24:33 <catherine_> hogepodge: thx
15:25:11 <markvoelker> So hogepodge: just to strawman here since I know you want to take something back to the legal team
15:26:16 <markvoelker> personally I'm fine with an annual testing requirement against the most recent 2 Guidelines as a starting point.  I think we can improve that standard though, and for that we need a little more discussion.
15:26:33 <eglute> markvoelker +1
15:26:46 <eglute> this could be a good discussion for tokyo
15:26:49 <markvoelker> And as far as the software versions: yes by all means drop that language entirely and let the Guidelines dictate the versions so there's no mismatch.
15:27:56 <markvoelker> eglute: +1 on discussion in Tokyo if we can get some space.  Anybody know if any of the Foundation legal staff/Marketplace staff will be there, or do we use Chris as a conduit?
15:28:13 <eglute> yes we have two sessions for working group
15:28:14 <hogepodge> markvoelker: that's our preference, for only specifying active guidelines (in case for some reason the board decides to increase or decrease the number away from 2)
15:28:30 <hogepodge> markvoelker: I'll be the conduit for that.
15:28:44 <markvoelker> hogepodge: good then (on both counts)
15:29:29 <eglute> we spent half of our meeting on this topic, so moving on to the next one
15:29:30 <markvoelker> So, eglute: I suggest we record an action to start a strawman proposal about how to handle recurring testing.  You can assign it to me if you like, since I started this to begin with. =p
15:29:49 <hogepodge> +1
15:30:09 <catherine_> +1
15:30:11 <eglute> #action markvoelker to start a strawman proposal about how to handle recurring testing.
15:30:31 <markvoelker> I'd also suggest we record an #agreed that we're ok with the Foundation requiring annual testing vs the two most recently approved guidelines for now until we figure out something better
15:30:33 <eglute> we will also add this discussion to tokyo agenda
15:30:54 <eglute> markvoelker i disagree
15:31:28 <eglute> right now products have to renew their agreements once a year, so it is already in place
15:32:16 <hogepodge> eglute: we do need to change the language in the contract to match the guidelines, so at least say something to the effect of "every year test against the current board-approved guidelines"
15:32:31 <markvoelker> eglute: it's in place, but requires the most recent guideline (not hte most recent two) and requires the most recent two software releases (which is not what the Guidelines require)
15:32:38 <markvoelker> So they need to change the language
15:32:49 <eglute> hogepodge ok, that makes sense. markvoelker oh ok, i was not aware there is a mismatch
15:33:26 <eglute> #action markvoelker hogepodge eglute will work with the foundation to get the agreement language for branding match the defcore documents
15:33:50 <markvoelker> eglute: Oh, that's actually a good point.  hogepodge, could you maybe ask legal to send over an example of the current contract to us?  Seems a lot of folks here haven't actually seen it.
15:34:12 <markvoelker> I have, but others may not have so it's hard to have a concrete conversation about it.
15:34:59 <eglute> ok, we really need to move to the next topic, we can continue this conversation later in defcore irc channel
15:35:07 <markvoelker> eglute: +1
15:35:09 <hogepodge> markvoelker: I can forward the copy I have to anyone who is interested.
15:35:13 <eglute> #topic finalize recommended capabilities
15:35:39 <eglute> lets start with neutron #link https://review.openstack.org/#/c/210080/
15:36:07 <eglute> we had a lot of discussion about it, any other opinions?
15:36:46 <hogepodge> I'm +2 on it. We had a lot of good discussion and it's a solid recommendation.
15:37:57 <hogepodge> I'm not a fan of requiring floating ip though. Too many cases where clouds aren't providing that, and are using a different mechanism.
15:38:25 * markvoelker nots again that this doesn't require floating IP's, it makes them advisory so we can solicit more feedback
15:38:32 <eglute> ok, then i will go ahead and merge it. I do agree with Rob that we can still update the 2016.01 guideline after we get more feedback, since tehre was not a consensus on floating IPs. hogepodge can you comment your objection on it as well?
15:38:44 <hogepodge> markvoelker: are you ok with merging as is?
15:38:47 <eglute> hogepodgei see you already have earlier
15:38:51 <markvoelker> hogepodge: yes
15:39:00 <rockyg> Yeah.  Floating IPs are really a field of landmines
15:39:06 <hogepodge> eglute: I didn't +1 workflow it.
15:39:14 <eglute> ok, merging now
15:39:45 <eglute> next keystone: #link https://review.openstack.org/#/c/213330/
15:40:29 <markvoelker> hmm, new comments on this one since we started the meeting
15:40:43 <eglute> there were some comments this morning on it, i guess it will need more time
15:41:34 <markvoelker> eglute: but we need to decide on it soon.  Technically we were supposed to have landed new advisory capabilities last week
15:41:47 <markvoelker> (per 2015A timelines)
15:41:54 <eglute> i think we were supposed to score them, not land them i thought
15:42:17 <eglute> but yes, i dont mean much more time, just give everyone a chance to respond.
15:42:33 <hogepodge> I'm ok with allowing more time as a procedural variation to adequately prepare the proposed standard for the board.
15:42:34 <markvoelker> I will address some of the comments made this morning
15:42:44 <eglute> markvoelker thank you
15:42:51 <markvoelker> move on?
15:42:55 <eglute> yup
15:43:06 <eglute> glance #link https://review.openstack.org/#/c/213353/
15:43:44 <hogepodge> I have no strong feelings regarding requiring v2 and v3 together or just v3. The outgoing PTL was strongly in favor of requiring both. I tend to think that by the time they switch from advisory to required v2 will be deprecated.
15:43:48 <eglute> i think after the latest update that looks good, besides the conflict
15:44:15 <hogepodge> eglute: I removed the create capability.
15:44:24 <eglute> hogepodge thank you, i saw it
15:44:35 <hogepodge> I also need to send a patch up to remove the test list
15:45:01 <rockyg> Wierd question....how can we require something that isn't even coded into the projects yet?
15:45:06 <eglute> ok, if it looks good to everyone else i can merge it today or tomorrow after hogepodge sends additional patches
15:45:13 <rockyg> Nova doesn't use v2 or v3
15:45:23 <rockyg> neithr dos cinder
15:45:24 <eglute> rockyg what does nova use
15:45:29 <rockyg> v1
15:45:35 <rockyg> with a proxy
15:45:48 * markvoelker notes that all that has been discussed in the review and on the ML recently
15:45:54 <eglute> rockyg are you talking about keystone or images
15:46:23 <rockyg> right, but we are supposed to be trailing, not leading, so no one is using v2 so it should not be part of the requirements
15:46:28 <rockyg> images
15:46:53 <eglute> rockyg can you please comment on the patch?
15:47:40 <rockyg> will do.  I'm just saying we can't require tests until they will work.  It might be where we want to head, but it can't be part of the testing
15:48:12 <markvoelker> rockyg: so in your comments, please state which Criteria nova using v1 falls afoul of.  I'd imagine that would be "used by clients"
15:48:32 <eglute> there is also a very long discussion on that patch
15:48:40 <rockyg> I'll comment today, but want to do a more thorough review of the individual scores.
15:48:44 <markvoelker> But on the other hand glanceclient and openstackclient both support v2 as has been discussed, so it's debatable whether it gets credit for tha criteria or not on those grounds
15:49:38 <rockyg> The person with the best info on this is dhellmann, so I'll circle back with him, too.
15:49:46 <markvoelker> rockyg: please also see https://review.openstack.org/#/c/213353/7/working_materials/scoring.txt for discussion of that criteria
15:50:24 <eglute> #action rockyg will review image scoring in the next couple days
15:50:34 <eglute> for the sake of time, lets move to the next.
15:50:42 <eglute> Cinder #link https://review.openstack.org/#/c/221631/
15:50:43 <markvoelker> rockyg: and this thread: http://lists.openstack.org/pipermail/openstack-dev/2015-September/075398.html
15:50:56 <markvoelker> eglute: +1
15:51:05 <eglute> the cinder one received little discussion
15:51:19 <eglute> i guess cinder is not controvertial?
15:51:37 <hogepodge> it's pretty stable
15:51:45 <eglute> :D
15:51:49 <markvoelker> Errr...did folks see the ML discussion yesterday? =)
15:52:01 <eglute> markvoelker which thread?
15:52:13 <hogepodge> the version deprecation thread
15:52:14 <markvoelker> #link http://lists.openstack.org/pipermail/openstack-dev/2015-September/075689.html
15:53:03 <eglute> right, but we already adding only v2 apis?
15:53:20 <hogepodge> the takeaway is that some users are depending on v1, but v2 is going to be the default gate-enabled api
15:53:24 <markvoelker> eglute: that's potentially the problem.  Most folks are still using v1 according to the voices on the operator's thread
15:53:26 <rockyg> fyi on glance:  see http://lists.openstack.org/pipermail/openstack-dev/2015-September/074360.html
15:53:40 <hogepodge> by the time cinder becomes required, this will be solved
15:53:52 <hogepodge> same with glance
15:53:54 <eglute> ah ok, i didnt read the full thread
15:53:57 <hogepodge> same with keystone (one would hope)
15:54:02 <hogepodge> (on all three)
15:54:11 <hogepodge> I think that defcore is helping to drive the urgency of that.
15:54:40 <eglute> are we ok with making it advisory for now and not making it required until most people have moved on?
15:54:44 <rockyg> So, most of these fixes are aimed for Mitaka.
15:54:58 <markvoelker> eglute: totally.  v2 should absolutely be made advisory in my mind
15:55:17 <markvoelker> eglute: it's maybe just a question of whether v1 should or not.  At this point I'm thinking no, but it's debatable.
15:55:44 <zehicle> o/
15:55:45 <markvoelker> especially now that cinder has apparently backed off of removing v1 from the codebase
15:55:50 <zehicle> sorry, my 9:30 got pushed to 10.
15:55:54 <eglute> i am not a fan of 2 versions in guidelines. I would rather see something be advisory for more than 6 months than have 2 versions
15:56:05 <rockyg> with v1, I'm with markvoelker, since it *will* be going in the next year, it's not the future....
15:56:35 <zehicle> what does adoption of v1 look like?  it is public?
15:56:36 <markvoelker> eglute: I'm a big fan of having multiple versions of API in a guideline because it creates transition time for end users.
15:56:42 <rockyg> v1 can be gone with O
15:57:03 <rockyg> but not before.  Same with Glance
15:57:06 <zehicle> aka, pubblic facing
15:57:10 <markvoelker> zehcile: see http://lists.openstack.org/pipermail/openstack-dev/2015-September/075689.html or to sum up: v1 adoption is pretty high
15:57:16 <zehicle> ok
15:57:23 <eglute> markvoelker but then that means companies must have both versions running
15:57:43 <markvoelker> eglute: And that is totally doable and a good thing for end users.
15:58:27 <markvoelker> anyway, we're almost out of time, so let's continue that discussion in #openstack-defcore
15:58:43 <eglute> markvoelker i agree that it is doable. yes, 1 min left
15:58:48 <markvoelker> I'm ok with the v2 patch going in
15:58:50 <eglute> any last words
15:59:00 <markvoelker> will gerrit-review it today
15:59:06 <eglute> markvoelker i will merge it after it is ready
15:59:20 <hogepodge> I won't be +2'in the patches I submitted, so that will fall on eglute and zehicle
15:59:42 <eglute> thanks everyone, we ran out of time. if there is anything urgent, i will be around in the defcore irc
15:59:51 <eglute> #endmeeting