16:00:10 <eglute> #startmeeting defcore
16:00:10 <openstack> Meeting started Wed Nov  4 16:00:10 2015 UTC and is due to finish in 60 minutes.  The chair is eglute. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:14 <openstack> The meeting name has been set to 'defcore'
16:00:19 <hogepodge> o/
16:00:23 <eglute> #topic rollcall
16:00:39 <eglute> hi everyone! let us know if you are here to attend the defcore meeting
16:00:54 <eglute> #link https://etherpad.openstack.org/p/DefCoreRing.1
16:01:36 <markvoelker> o/
16:01:46 <zehicle> o/
16:01:53 <VanL> o/
16:01:59 <eglute> #topic agenda
16:02:15 <hogepodge> I see all the usual suspects are here. :-D
16:02:19 <zehicle> #link https://etherpad.openstack.org/p/DefCoreRing.1
16:02:47 <eglute> please take a look at the agenda. we didnt have enough time in tokyo to make plans for this cycle, i think it would be good to do so today
16:03:32 <zehicle> +1
16:03:35 <eglute> #topic schema 1.4
16:03:58 <markvoelker> There are two patches out moving 2016.01, next, and 2015.07 to 1.4 (links in pad)
16:04:08 <eglute> if you have not reviewed the patches, please do so... they look good to me
16:04:15 <eglute> i would like to get them merged this week
16:04:27 <eglute> #link https://review.openstack.org/#/c/240939/
16:04:30 <markvoelker> Migrating the older Guidelines is a bit more involved as we're moving them from 1.2, so much bigger change.  Will hopefully post them later this week.
16:04:36 <markvoelker> (but they're a bit less urgent anyway)
16:04:39 <eglute> #link https://review.openstack.org/#/c/240942/
16:04:52 <eglute> do we also need to migrate 2015.5?
16:05:19 <markvoelker> eglute: we discussed in Tokyo that we would, but see above. =)
16:05:40 <eglute> ah, sorry markvoelker, missed that part.
16:06:07 <eglute> hogepodge do you think you will get a lot of people wanting to certify against 2015.5 between now and january?
16:06:29 <hogepodge> eglute: yes, it's a slightly easier standard to meet
16:06:46 <eglute> is it going to cause issues if it is using the old schema
16:06:58 <hogepodge> eglute: I have one in the pipeline that is trying to get over the line
16:07:10 <eglute> though, sounds like markvoelker is working on it as well
16:07:13 <markvoelker> It's not going to be terrifically hard to do, just requires a bit more elbow grease than I could apply in the cramped quarters of the plane ride home.
16:07:38 <eglute> i tried to sleep on the way back, so really appreciate you working on the schema stuff :)
16:07:51 <markvoelker> Happy to help
16:08:17 <eglute> ok, so looks like schema migration is going well. next topic
16:08:36 <eglute> #topic capabilities should have more than one test
16:08:56 <eglute> #link https://review.openstack.org/#/c/233814/
16:09:20 <eglute> hogepodge have you had a chance to take a look at it
16:09:57 <zehicle> it should be simple enough to apply rule to next and 2016.01 for the patch
16:09:58 <hogepodge> I have.
16:10:02 <markvoelker> I think where we left off with this one was that we were waiting for the patch to be ammended to show how the current capabilities would be regrouped?
16:10:25 <hogepodge> 2016.01 and next would need some capability regrouping, which I think is ok
16:11:00 <eglute> who wants to take on the regrouping?
16:11:06 <VanL> Is this because the capabilities are too granular?
16:11:23 <hogepodge> wrt keystone tests, we might be able to rewrite the existing test to be more tests? There are lots of parts of the token we're checking, and can make those checks independent. That may be silly, though. I'm not sure how to exactly deal with that
16:11:28 <VanL> OR are we grouping less-related things simply due to the rule?
16:11:36 <eglute> VanL yes, and not enough tests too
16:12:09 <hogepodge> VanL: creating a crud capability for example, rather than have get and put and delete and list capabilities
16:12:21 <markvoelker> VanL: I don't think we know because nobody has actually shown what the new grouping would look like. =)  Hence my request for the ammended patchset.
16:12:21 <VanL> I'm ok with the rule - but I don't think grouping for the sake of grouping is a good way to go about it.
16:12:34 <eglute> ideally, we would get more tests, but i dont think that is realistic before 2016.1
16:13:15 <zehicle> VanL, yes.  I think we over did the subdivision
16:13:25 <VanL> Maybe that should be the focus - on getting more tests.
16:13:52 <VanL> The reason is that we have already been bitten once by having too-broad capabilities.
16:13:52 <zehicle> IMHO, single test capabilities become discussions about the TEST not the capability
16:14:19 <zehicle> VanL, I think there's a balance.
16:14:43 <VanL> Of course.
16:14:44 <zehicle> CRUD actions are really a single capability.  there's no need to split them
16:15:10 <zehicle> there are places where we have a single capability without sufficient tests too.
16:15:17 <hogepodge> But what about the single test keystone capabilities, as pointed out by markvoelker?
16:15:20 <markvoelker> Well...CRUD ops aren't always a single capability
16:15:24 <VanL> Are they? IIRC, one of the issues we had before was with Create not being supported in some places, but list was
16:15:31 <zehicle> markvoelker, I think we need 1.4 to merge before regrouping
16:15:34 <VanL> oh. and Delete too
16:16:02 <markvoelker> Particularly in cases whre tehre's more than one way to do something, so scores shift for achievements like "atomic" for, say, the "R" in CRUD.
16:16:21 <VanL> so if you have a library of - say, images - and you only want to support Read
16:16:29 <VanL> Then is CRUD a single capability?
16:16:40 <eglute> ok, so for 2016.1, would we be ok with not having a single test capability and regrouping for the next one?
16:17:30 <markvoelker> eglute: I don't think we can approve the rule until we actually see how this would impact what's required.  So the patch needs to propose a change to next.json at least.
16:17:53 <zehicle> markvoelker, it's not changing any requirements - we're just moving tests around
16:17:55 <hogepodge> I don't mind single test capabilities, fwiw.
16:18:15 <markvoelker> zehicle: yes, and that's what I want demonstrated: how would you actually move those tests around?
16:18:27 <eglute> hogepodge but if there is an issue with that single test, then the whole capability is flagged
16:18:42 <VanL> +1 hogepodge, with the caveat that single-test capabilities should be flagged to the appropriate parties as needing more tests.
16:19:11 <VanL> I think the problem is with the tests, not with the capability.
16:19:17 <hogepodge> eglute: Yeah, that's better than being artificially and overly broad. But I see both sides. I'm not too strong on either side.
16:19:19 <zehicle> the point of the rule is to highlight capabilities that don't have enough tests
16:19:55 <zehicle> I don't mind grouping items
16:20:05 <zehicle> no tests will be added or removed in the process, just moved
16:20:22 <zehicle> can we merge 1.4 schema then?
16:20:25 <hogepodge> How many tests does getting a token need? It's a really simple operation that either works or doesn't.
16:20:39 <eglute> #action zehicle will propose new groupings for capabilities with 1 test
16:20:41 <hogepodge> To demand more tests feels artificial.
16:21:02 <eglute> hogepodge: at least 2. one positive test and one negative :D
16:21:44 <eglute> ok, lets see what the new groupings will look like, and lets move forward to the next topic
16:22:04 <VanL> Call me crazy, but if we can only think of one test, we are being insufficiently creative about how things can break.
16:22:07 <VanL> :)
16:22:15 <eglute> VanL agree!
16:22:33 <eglute> #topic things that should stay or go
16:22:38 <eglute> #link https://review.openstack.org/#/c/239830/
16:22:47 <eglute> this is a generic patch for discussion
16:23:18 <markvoelker> eglute: FWIW, this patch was highlighted in a couple of sessions as a place where folks could provide feedback on the 2016.01 guideline.
16:23:27 <eglute> so far, without removing floating ips, we have not had other patches submitted
16:23:45 <markvoelker> So, hopefully will see some discussion over the coming weeks/months as folks start to test with 2016.01
16:23:48 <eglute> i am planning on sending email to dev/ops mailing list and asking for feedback
16:24:15 <eglute> any other suggestions on how to get more feedback?
16:24:25 <hogepodge> I've heard that there may be an objection to some cinder capabilities (volume resize)
16:24:54 <eglute> yeah, i heard some verbal objections to things as well, and asked people to submit comments/patches
16:25:00 <hogepodge> the dev and ops mailing list is good. Maybe the TC and cross project meetings too?
16:25:02 <markvoelker> eglute: IIRC there was some sentiment that a blog on superuser might be useful and that the superuser folks were interested in having such
16:25:26 <eglute> ok, will work on superuser blog as well
16:25:37 <eglute> can never have too much blogs
16:26:08 <eglute> #topic plans for this cycle
16:26:22 <eglute> so we didnt get a chance to prioritize in tokyo
16:27:00 <eglute> there is a list in etherpad, please add +1 on items that you think are most important
16:27:24 <eglute> i think one of the major things we need to figure out is the whole networking and IP
16:27:29 <zehicle> #link
16:27:44 <zehicle> #link https://etherpad.openstack.org/p/DefCoreFlagTokyo
16:28:01 <markvoelker> eglute: can you elaborate on that a bit?  With floating IP's shot down I'm not sure what we can do at this point.
16:28:12 <eglute> zehicle i added that list to todays ehterpad as well
16:28:33 <eglute> i think we need networking/ips for interop
16:29:06 <markvoelker> Well, we have L2 and L3 operations.  We do not have a means of external connectivity, because floating IP's was removed from 2016.01.
16:29:27 <eglute> can we get proposals from tc/operators for external connectivity? do we need external connectivity?
16:30:12 <markvoelker> We do need it, IMHO.  But floating IP's was probably the only thing that had a shot of meeting criteria, and we removed it.  There was some momentum around the "get me a network" change in Neutron...
16:30:18 <hogepodge> eglute: supposedly a "get me an ip" api is due for mitaka
16:30:19 <markvoelker> ...but that code hasn't even been written yet.
16:30:34 <markvoelker> So, 18+ months before we can consider it even if it lands soonish.
16:30:45 <eglute> ok... so i guess that part is out
16:31:30 <hogepodge> We should address that in our blog and mailing list posts?
16:31:47 <eglute> yes... we definitely should.
16:31:55 <VanL> hogepodge: YEs
16:31:56 <hogepodge> It's kind of important, and we need to highlight the urgency of that api existing to the dev community
16:31:59 <VanL> *yes
16:32:34 <markvoelker> I think the more important thing is to make sure that what Neutron is planning to implement is actually something people will adopt
16:32:39 <eglute> what other things do we want to tackle this cycle? in terms of priority
16:32:51 <markvoelker> Otherwise, it's moot because in 18 months it still won't be widely deployed and will still fail to meet criteria.
16:33:04 <hogepodge> On a positive note, some tests require public network access, so some form of it is implicitly required by the current guideline.
16:33:31 <eglute> true, sort of like auth tests
16:33:39 <markvoelker> (and by "people" here, I mean deployers, products, and toolkits/clients)
16:34:03 <eglute> we know people implement networking in some form, but what is the interop way would be good to know
16:34:03 <hogepodge> My concern with requiring floating ips would be that we set a standard the community doesn't want, and then we will face an upgrade problem once we get an api they do want.
16:34:09 <zehicle> I'd like to discuss the validation disparity between public and distros
16:34:30 <eglute> zehicle that keeps coming up, and i would like it resolved as well
16:34:49 <zehicle> hogepodge, what's the alternative now?
16:34:51 <markvoelker> hogepodge: Right, so the question is now whether the "get me a network" thing is what the community actually wants.  Right now there's a lot of hope being pinned on code that hasn't been written.
16:35:19 <markvoelker> Personally I'm not convinced it's sufficient...
16:35:24 <zehicle> my understanding was that we'd do harm if floating IP was required because it's not widely implemented
16:35:42 <eglute> right, thats why we removed floating ip
16:35:50 <zehicle> is this a case where there's no conventional approach?
16:36:06 <zehicle> seems like the capability is required to run openstack
16:36:15 <zehicle> we just don't have consensus
16:36:28 <zehicle> so, are we in a position to force it
16:36:29 <zehicle> ?
16:36:36 <markvoelker> Yes.  There are multiple ways to get external connectivity.  No clear consensus on how to do it among ops today.  Floating IP's is probably more widely used than anything else, but it was deemed not wide enough.
16:36:49 <markvoelker> I don't think we can force it.
16:37:23 <zehicle> in practical terms, we've got 6 months to resolve it
16:37:26 <eglute> i dont think we can force it at this point. we need to highlight the issue and ask for consensus, new APIs, ways to make networks interop
16:37:34 <VanL> +1 eglute
16:37:47 <markvoelker> To be frank, I don't see any chance of resolving it in 6 months.
16:38:03 <zehicle> since there's nothing in the guideline, we don't create issues for a long time when we pick a way
16:38:21 <eglute> but hopefully we can be on the right path
16:38:37 <zehicle> markvoelker, that is distressing
16:39:13 <eglute> well, we might need a separate blog post just on this topic
16:39:17 <markvoelker> To resolve it in 6 months we'd have to get a lot of operators and products to rally around one method of getting external connectivity.  An existing one, not one that hasn't been written yet. That's just not going to happen.
16:39:33 <markvoelker> Especially when public clouds/managed products are involved.
16:39:40 <eglute> not in a guideline in 6months, but at least be on the right path
16:39:51 <zehicle> they will have time to react - the process is slow
16:40:23 <hogepodge> Does anyone have the link to mordred's public cloud shade matrix?
16:40:33 <eglute> no
16:40:42 <eglute> never heard of it
16:40:53 <hogepodge> It would give us insight into the network deployment schemes currently in place.
16:41:25 <markvoelker> hogepodge: only on the public cloud side.  That's fine data, but only ~15 products represented.
16:42:01 <markvoelker> hogepodge: he left a comment with some of that data in the patch: https://review.openstack.org/#/c/210080/
16:42:05 <eglute> which brings us to the next issue. public clouds vs private vs distros
16:43:40 <eglute> i think we need to resolve defcore for public clouds
16:44:21 <markvoelker> eglute: can you elaborate a bit on that?  E.g. what are we trying to resolve?
16:44:25 <hogepodge> eglute: what do you mean?
16:44:45 <markvoelker> Is this about recurring testing timetables? E.g. https://review.openstack.org/#/c/232128/ ?
16:45:34 <eglute> certification frequency
16:45:35 <eglute> yes
16:46:15 <zehicle> I also believe that we've created unequal certification challenges
16:46:32 <zehicle> public clouds are testing against their actual implementation.
16:46:49 <zehicle> distros just need to setup a lab environment (field deploys may vary widely)
16:46:51 <eglute> zehicle +1
16:47:24 <eglute> i agree. same for private clouds, they are somewhere between distros and public clouds
16:47:25 <markvoelker> So, could folks comment on that patch then?  There's quite a healthy discussion ongoing in there, but only Chris and I have commented on the DefCore side...
16:47:28 <zehicle> ideally, private clouds would also self-certify.
16:47:57 <eglute> markvoelker yes, will comment. it is really hard to follow the discussion when everything is in the comments
16:48:01 <zehicle> my original hope would be that the distros would upload results from every customer as part of install validation
16:48:02 <eglute> on hte code
16:48:22 <eglute> zehicle that might be a bit much too ask
16:49:04 <markvoelker> Hmmm....what purpose would that serve?
16:49:04 <zehicle> maybe.  without that, customers really don't know if they interop
16:49:05 <VanL> zehicle: Many of the customers would probably object to that too.
16:49:37 <VanL> I have talked to people who consider their actual deployment a trade secret.
16:49:40 <zehicle> maybe  - it would be like user survey now.  but easier
16:50:03 <zehicle> the APIs they've implmented are a trade secrete???
16:50:09 <eglute> also, remember that we are trying to prioritize work for this cycle, not actually solve everything
16:50:20 <zehicle> I can see the size & capability of the cloud.  but not which APIs
16:50:23 <eglute> so, i would like us to tackle this issue this cycle
16:50:23 <hogepodge> Better testing and tooling would help with verifying installations.
16:50:45 <hogepodge> But I don't think we can mandate private installs be tested. Feels like over reaching to me.
16:50:55 <eglute> hogepodge +1
16:51:20 <hogepodge> refstack is moving in a direction to run tests, and a private refstack installation (or even rally) could provide a way to easily check
16:51:28 <eglute> reference architectures, yes. i think most distros should have them, no?
16:52:21 <markvoelker> Most distros have several reference architectures.  Some purpose specific.  E.g. your reference arch for an NFV-focussed deployment is very different than for a general compute deployment.
16:52:58 <eglute> so, we could ask to certify different reference architectures?
16:53:13 <markvoelker> Anyway, back to eglute's point: we don't have to solve this in the next 8 minutes, we just need to say "yes, resolving this is a priority for this cycle" or "no, it isn't"
16:53:20 <markvoelker> eglute: I
16:53:22 <eglute> thanks markvoelker
16:53:32 <hogepodge> I'll say it, yes, resolving this is a priority for this cycle.
16:53:38 <markvoelker> 'm not sure what the point would be, but let's take that up later in the cycle if folks want to talk about it.
16:53:48 <eglute> so, right now we have 2 pretty big issues to resolve this cycle
16:53:48 <VanL> I'm +1 on making this a priority
16:54:22 <eglute> any other major issues?
16:54:45 <markvoelker> The additional communication one is important to me.
16:54:56 <hogepodge> It will help give guidance to folks who want to test with more frequency (CI), and also give us guidance on ways to allow for continuous maintenance of license agreements (which I think would be rally valuable to our community, and aligns with our values)
16:55:07 <markvoelker> I'm totally signing myself up to work on TC/UC reports and project liaisons.
16:55:18 <eglute> markvoelker yes, it is. and that one we can start addressing immediately
16:55:44 <markvoelker> (FWIW, the Glance folks seemed receptive to the liaison idea during our session in Tokyo)
16:55:47 <eglute> #action markvoelker will be a liaison between projects/TC
16:56:20 <eglute> #action eglute will start a blog post on defcore, will ask for help from everyone here
16:56:32 <hogepodge> revisiting an older topic, it appears that more public clouds use floating ip than provider network with fixed
16:56:39 <hogepodge> #link http://docs.openstack.org/developer/os-client-config/vendor-support.html
16:56:45 <eglute> #action eglute will send email to ops/dev mailing lists asking for feedback on 2016.1
16:56:56 <eglute> thanks hogepodge
16:57:42 <markvoelker> eglute: when you send that mail, may I suggest you direct people to https://review.openstack.org/#/c/239830/ directly to supply feedback?  That will help focus discussion rather than have it all over the place.
16:57:46 <eglute> ok, 2 min left- start planning for midcycle?
16:57:57 <hogepodge> :-D
16:58:02 <eglute> markvoelker yes that is the plan
16:58:07 <markvoelker> excellent
16:58:13 <hogepodge> share ops mid-cycle in england?
16:58:16 <hogepodge> :-P
16:58:27 <eglute> england in January?
16:58:42 <zehicle> I'd suggest that we plan to combine w/ the board meeting again
16:58:50 <eglute> zehicle that would work
16:59:01 <eglute> do we know when next board meeting will be?
16:59:06 <zehicle> or we should plan Boulder in January
16:59:14 <zehicle> eglute, no
16:59:20 <VanL> Has there been a decision on the board mtg location?
16:59:26 <eglute> VanL not yet
16:59:40 <eglute> but a tropical destination would be nice
16:59:43 <zehicle> I suspect Austin again
16:59:45 <VanL> Good, I hadn't seen it. Guess that explains why. :)
16:59:54 <markvoelker> ok, so since <1m left, table until Board knows where tehy're meeting, then discuss?
16:59:58 <eglute> Austin is almost tropical
17:00:10 <eglute> yep, table until we know more
17:00:15 <eglute> thanks everyone!
17:00:22 <eglute> #endmeeting