16:00:23 <eglute> #startmeeting defcore
16:00:26 <zehicle_> o.
16:00:26 <openstack> Meeting started Wed Jan  6 16:00:23 2016 UTC and is due to finish in 60 minutes.  The chair is eglute. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:29 <openstack> The meeting name has been set to 'defcore'
16:00:30 <zehicle_> o/
16:00:37 <rosmaita> o/
16:00:44 <eglute> #link agenda https://etherpad.openstack.org/p/DefCoreRing.7
16:00:51 <eglute> #topic agenda
16:00:53 <markvoelker> o/
16:01:01 <hogepodge> o/
16:01:03 <eglute> Hello Everyone! Happy New Year!
16:01:06 <AlanClark> o/
16:01:12 <gema> o/
16:01:18 <hogepodge> Happy New Year!
16:01:41 <zehicle_> :)
16:01:48 <eglute> Please review the agenda, and add things as needed! https://etherpad.openstack.org/p/DefCoreRing.7
16:02:00 <eglute> #topic midcycle
16:02:38 <eglute> do not want to spend too much time on this, but how does everyone feel about holding a midcycle
16:02:50 <eglute> #chair zehicle_
16:02:50 <openstack> Current chairs: eglute zehicle_
16:03:06 <markvoelker> I'm game.  They've been productive in the past.
16:03:14 <zehicle_> looking at the agenda items, it makes sense to me
16:03:28 <zehicle_> timing will be painful
16:03:31 <eglute> ok, then we will need to send a poll regarding times and locations...
16:04:00 <eglute> #action eglute send out poll for midcycle times + locations
16:05:07 <eglute> let me and Rob know if you have any suggestions regarding locations
16:05:37 <eglute> We can start a separate etherpad for work that needs to be done during midcycle
16:05:40 <hogepodge> I'm always up for Austin, fwiw
16:05:45 * zehicle_ we have a bias towards central Texas.
16:06:05 <eglute> i am ok with Austin, despite its traffic
16:06:29 <eglute> zehicle_ did you wanted to talk about standalone tests, or leave that for later?
16:07:05 <zehicle_> I can introduce - not sure we're ready for a discussion at this point
16:07:28 <zehicle_> basically, the recent VM vs Zone discussion brought up that it would be helpful for DefCore to had dedicated interop tests
16:07:30 <eglute> maybe a quick intro so people can start thinking about it :)
16:07:46 <zehicle_> that were not also trying to test the function of the code base (aka gate)
16:07:57 <zehicle_> that dual purpose was making it harder to add/maintain tests.
16:08:16 <zehicle_> so we could split out the tests that we are using (effectively fork)
16:08:37 <zehicle_> then it would be easier for community to add interop tests
16:08:43 <markvoelker> It was also discussed, though, that having interop tests in the gate was important so interop features don't get broken
16:08:55 <zehicle_> but it means that DefCore has to maintain them
16:09:09 <zehicle_> markvoelker, that has been my strong preference for not forking
16:09:39 <purp> o/
16:09:41 <zehicle_> markvoelker, do you see people creating interop tests?
16:09:43 <brunssen> o/
16:09:56 <SammyD> +1 on not forking. What about a dedicated package inside the standard tempest? I.E. an InterOp package that contains only interop tests, but lives with the rest of tempest tests...
16:10:01 <eglute> would it be worthwhile to have a mailing list discussion on this?
16:10:21 <zehicle_> SammyD, that's a good middle ground.
16:10:31 <gema> probably, it'd be useful to see what exactly makes a test "interop"
16:10:37 * purp is mostly lurking from a plane waiting for a gate.
16:10:53 <zehicle_> any dedicated DefCore tests require resources
16:11:23 <eglute> i like SammyD suggestion
16:11:26 <zehicle_> this was a complex enough topic, that we thought it would be for the Midcycle (instead of regular agenda)
16:11:44 <hogepodge> We can tag tests, although that has not been successful in the past (smoke, gate)
16:11:44 <brunssen> +1 on SammyD's suggestion
16:11:48 <markvoelker> sure, thanks for teeing it up though
16:11:58 <zehicle_> however, if there's strong interst.  it makes sense to bring people to the Midcycle who can help build the framework to start it
16:12:20 <eglute> how about this- lets start a mailing list discussion and hopefully work on it during midcycle?
16:12:22 <markvoelker> I'm not seeing strong interest in the scrollback. =)
16:12:37 <hogepodge> starting from scatch is a bad idea, it would take lots of work
16:12:53 * eglute agrees
16:13:07 <hogepodge> appropriating (and expanding or modifying) existing tests and identifying holes to fill is better
16:13:17 <purp> +1 SammyD's separate pkg, +11 on mid cycle topic
16:13:29 <eglute> #action zehicle_ and eglute start a mailing list discussion regarding defcore tests
16:13:31 <SammyD> +1 mid cycle
16:14:01 <purp> And +aLot to mid cycle not in Austin, as we'll all be there in May.
16:14:22 <eglute> #topic Austin Summit DefCore submissions
16:14:31 <purp> HPE would be happy to host in Fort Collins. =]
16:14:45 <eglute> thanks purp will add it to the list!
16:14:59 * zehicle_ Ft Collins in mid-Feb actually may work very well for me
16:15:01 * markvoelker wouldn't mind being back in his old stomping grounds in Ft. Collins personally
16:15:08 <eglute> #info purp HPE would be happy to host in Fort Collins. =]
16:15:16 <purp> eglute: could also likely manage Houston
16:15:36 <eglute> cool, lest talk on that later in defcore irc channel
16:15:37 <purp> Sorry, didn't mean to hijack.
16:16:05 <eglute> Austin summit submissions are now open
16:16:15 <eglute> so please share ideas and submissions!
16:16:53 <markvoelker> On that note, please remember that only 3 submissions per person (including panels) are allowed under the new submission process.
16:17:04 <eglute> I think the sessions went well in Tokyo, there is definitely a lot of interest in defcore
16:17:33 <eglute> markvoelker is right! and we want to have defcore submissions
16:17:33 * zehicle_ thinks they've disallowed unicorns and rainbows from titles
16:17:35 <markvoelker> #link http://superuser.openstack.org/articles/how-to-land-a-successful-openstack-summit-talk details about new submission rules
16:18:13 <eglute> next topic!
16:18:23 * purp waves at kebray
16:18:23 <eglute> #topic remove tests for image import
16:18:40 <eglute> rosmaita are you around?
16:18:45 <rosmaita> hi
16:19:09 <rosmaita> might be best to read the comments on the patch, mark's response, and my response to him
16:19:14 <eglute> you had some great comments on #link https://review.openstack.org/#/c/239830/
16:19:25 <eglute> would you mind summarizing?
16:19:29 <rosmaita> sure
16:19:45 <rosmaita> basically, glance is working on a new image import workflow for Mitaka
16:19:52 <rosmaita> spec was approved last week
16:20:00 <eglute> everyone, please read the last 3 comments on the patch :)
16:20:15 <rosmaita> so it's kind of early to include image-import as an advisory capability
16:20:22 <hogepodge> The TC is pretty strongly opposed to this, if I understand the patch right https://review.openstack.org/#/c/256438/
16:20:52 <hogepodge> As the technical leaders of the community, they've taken a stance that image upload is required for interoperability
16:20:58 <eglute> hogepodge which part is TC opposing?
16:21:10 <rockyg> o/
16:21:17 <rosmaita> hogepodge: not image upload, but image import
16:21:45 <rockyg> "bring your own image"
16:22:06 <hogepodge> “To give up on interoperable image uploads simply because a vendor would like to do one thing that a little bit different isn't just wrong, it would be giving up the ENTIRE effort.”
16:22:19 <zehicle_> if this is new function, is it something that Defcore can absorb?
16:24:30 <eglute> so if i understand correctly, import and upload are two different capabilities?
16:24:33 <hogepodge> I'm just repeating the TC resolution that's been in the works for weeks, fwiw
16:24:55 <rosmaita> eglute: yes, import is end-user facing
16:25:07 <rosmaita> it allows a deployer to validate the image
16:25:20 <rosmaita> "upload" is what we currently have, just sticks the image in the glance backend
16:25:20 <eglute> ok
16:26:01 <SammyD> import could also potentially give a public cloud provider less heartburn since there is some validation of the image if I understand correctly
16:26:15 <rosmaita> SammyD: +1
16:26:52 <zehicle_> is this current or planned function?
16:27:03 <rosmaita> i think this explained in the "background" section of the import spec: http://specs.openstack.org/openstack/glance-specs/specs/mitaka/approved/image-import/image-import-refactor.html
16:27:19 <rosmaita> zehicle_: it's planned for Mitaka
16:27:20 <eglute> hogepodge did TC elaborate between the differences of upload and import?
16:27:37 <zehicle_> I understand it helps address topics raised lately and in TC position
16:28:22 <hogepodge> The text of the resolution should speak for itself. https://review.openstack.org/#/c/256438/6/resolutions/20151211-bring-your-own-kernel.rst
16:28:49 <hogepodge> I'd encourage members of the TC to clarify with respect to the defcore patch in question.
16:29:34 <hogepodge> We're not bound by TC resolutions, as we are a board committee, but we do have feedback from the TC as part of our underlying governance principles.
16:29:49 <zehicle_> should have start w/ that patch then?  I feel like we're discussing features that are not really ready for DefCore to add to guidelines
16:30:10 <rockyg> and the tc will be bringing it to the board for their support
16:30:11 <rosmaita> zehicle_: +1
16:30:47 <markvoelker> zehicle_: I'm not sure that's the case.  The API's being tested have been around for quite some time
16:30:53 <eglute> right, but then we still have existing tests that rosmaita is suggesting to have removed for reasons listed on the patch
16:30:53 <purp> One question, which rosmaita posed in the review and wasn't answered: does DefCore include admin capabilities?
16:31:04 <rosmaita> the issue is, if openstack requires direct end-user image upload, it needs to provide a responsible way to do this
16:31:10 <eglute> DefCore does not currently cover admin capabilities
16:31:11 <rosmaita> the current glance upload doesn't do this
16:31:17 <zehicle_> purp, no
16:31:32 <purp> By intention, or circumstance?
16:31:43 <markvoelker> purp: intent
16:31:44 <zehicle_> early on we omitted admin APIs because they are not exposed on public clouds
16:32:00 <zehicle_> plan was go eventually have a "flavor" of DefCore that would have admin APIs for public
16:32:12 <zehicle_> since there are ecosystems that would leverage them
16:32:13 <hogepodge> rosmaita: from the Foundation's perspective, making a feature available after vetting of a customer is still in the spirit of interoperability. This is based on experience running a public cloud and the amount of fraud public clouds experience
16:32:45 <purp> markvoelker eglute zehicle_: thanks for clarifying.
16:32:47 <eglute> hogepodge can you elaborate on the fraud part
16:33:46 <hogepodge> eglute: spammers using stolen credit cards to set up bots, for example
16:34:04 <eglute> ah, that kind of fraud
16:34:47 <purp> ... Or getting access and looking to hack/exploit their way into the infrastructure supporting the cloud.
16:35:00 <hogepodge> Having a feature available by request still provides interoperability, as long as the feature is actually reasonably available
16:35:14 <eglute> so, reading the TC resolution: it does not say that user should allow uploads, but cloud. which could mean admin access, would apply to some other parts of the resolution as well
16:36:09 <purp> As written I'm +1 of rosmaita's notion: add import (immediately) after Mitaka lands.
16:36:19 <purp> Would also favor clarifying this with TC.
16:36:38 <rosmaita> purp: +1 on clarification
16:36:55 <eglute> I am in favor of clarifying
16:37:00 <SammyD> +1 purp
16:37:18 <eglute> we also need to be careful not to force a technical direction for the wrong way to upload/import images
16:37:29 <eglute> especially when there are changes in place
16:37:39 <eglute> rather, happening
16:37:47 <rosmaita> eglute: +1
16:37:50 <markvoelker> "Cloud MUST allow end user Image Uploads" < So what you're asking for clarificaftion on is whether the new BP meets that bar?  Or...?
16:37:51 <zehicle_> seems like building the capability to include in the guideline would be a mid-cycle topic
16:38:19 <rosmaita> markvoelker: the new bp will definitely meet that bar
16:38:29 <purp> I'd suggest we propose it as: if it's upload, not import, then it breaks current model of not defcoring admin functions. If it's import, we need to land it first. We'd like guidance on their preference.
16:38:33 <rosmaita> but the current tests don't use that functionality (that doesn't exist yet)
16:38:41 <zehicle_> I'm trying to bring us back to the process where we have TESTS and ESTABLISHED FEATURE (sorry for yelling) before we add requirements
16:38:43 <SammyD> +1 purp
16:38:47 * eglute +1 purp
16:39:06 <rosmaita> zehicle_: +1
16:39:20 <SammyD> +1 zehicle. :-)
16:39:24 <eglute> zehicle_ agree... the current question is about removing capabilities that would require admin access
16:39:44 <zehicle_> we have caps that require admin?
16:39:46 <markvoelker> rosmaita: right, I guess that's why I'm asking what we're asking for clarification about. =)  Given a look at the clock, I'd suggest that someone take an AI to frame up an actual question to send to the TC and we move on to the next item in the agenda.
16:39:52 <eglute> removing them from 2016.01 so that do not become advisory
16:39:58 <zehicle_> directly or indirectly?
16:40:04 <purp> About to reach a gate, so will be more lucky than not for rest of meeting, likely. Was supposed to have deplaned just before this meeting; sorry for the wacky logistical pains.
16:40:08 <rockyg> zehicle_, +1 on scoring thresholds
16:40:16 <catherineD> I don't think we have caps that require admin for testing
16:40:22 <purp> I'll take the AI.
16:40:42 <eglute> #action hogepodge rosmaita purp to clarify with TC regarding image import/upload
16:40:48 <zehicle_> if they are directly requiring admin, then yes.
16:41:03 <zehicle_> if they are indirectly requiring it then we need to go back to the tests
16:41:42 <hogepodge> some tests assume existing resources, which may need admin access to get there. Networks come to mind.
16:41:44 <catherineD> zehicle_: The tests are not directly requireing admin....
16:41:46 <zehicle_> we need effort to improve/resolve test issues.
16:41:59 <catherineD> hogepodge: agree ...
16:42:02 <eglute> zehicle_ from rosmaita comment "we're dealing with a capability that the community has decided does not need to be exposed to end-users, and hence isn't appropriate for inclusion in DefCore "
16:42:22 <eglute> zehicle_ +100 on resolving test issues
16:42:45 <hogepodge> no test directly needs admin access. qa is very good at identifying tests that require admin access, so we ignore them (they use a specific class that contains admin credentials, so tests that don't use that class don't need admin)
16:42:45 <eglute> this takes us to the next topic
16:42:55 <eglute> #topic Finalizing 2016.01 guideline
16:43:26 <eglute> we have rosmaita comments on the current patch, and also the Oracle patch pending
16:44:02 <eglute> flags are not time sensitive, so we can deal with them later if needed
16:44:27 <zehicle_> now I'm confused
16:44:40 <zehicle_> are we talking about individual tests or the whole capability?
16:45:01 <rosmaita> zehicle_: sort of both
16:45:12 <zehicle_> I can see that this capability may not be widely deployed or have issues for public clouds
16:45:14 <rosmaita> "image import" doesn't exist yet
16:45:23 <rosmaita> and the current tests test somethighn else
16:45:24 <eglute> yeah, the whole import/upload naming is confusing
16:45:59 <zehicle_> so the request here is to remove the capability because of security and control concerns?
16:46:41 <zehicle_> it also seems like the "future" score may be in question too
16:46:46 <rosmaita> zehicle_: yes, plus something to satisfy the capability will be introduced in mitaka glance
16:46:53 <markvoelker> At the risk of curtailing discussion by suggesting again that we move on to other agenda items, it might be useful for folks to review the patch that added those tests/capability and then discuss, if you haven't alredy.
16:47:12 <markvoelker> That's in: https://review.openstack.org/#/c/213353/
16:47:48 <eglute> thanks markvoelker
16:48:08 <eglute> besides this issue, are there other items that we need to finalize for 2016.01?
16:49:24 <eglute> #action everyone reviews 2016.01
16:49:43 <eglute> #topic Recurring Testing
16:50:00 <eglute> #link https://review.openstack.org/#/c/232128/
16:50:19 <hogepodge> I have a conversation with the foundation staff last month, and we're meeting with the lawyers this week about the powered license agreement.
16:50:20 <eglute> hogepodge can you respond to the comments?
16:50:32 <markvoelker> I've started working up a new patchset on this incorporating hogepodge's most recent comments, but I noted that eglute had some questions, so haven't finished. =)
16:50:52 <hogepodge> We want to be careful about how we require retesting to not make the contract difficult to sign
16:50:53 <eglute> markvoelker that sounds good
16:51:14 <eglute> hogepodge that makes sense to me!
16:51:44 <dwalleck> Just a question, but why is the foundation the one to administer re-testing for public clouds?
16:52:24 <hogepodge> Products that don't change get to keep their status. This allows for long term support of a distro. The license would renew annually with an option to terminate with 30 days notice (this was the previous license, which then became a fixed one year term license, and we want to go back to the previous model)
16:52:39 <hogepodge> dwalleck: we don't want to administer the testing
16:52:55 <hogepodge> dwalleck: terrible wording on my part
16:52:59 <dwalleck> hogepodge: Ahh, maybe I mis-read your last comment
16:53:12 <eglute> hogepodge for products that dont change, they will be timeboxed by defcore anyways, no?
16:53:13 <dwalleck> gotcha. thanks!
16:53:23 <hogepodge> dwalleck: we want to accept test results and inform companies that they need to submit new results or face license termination
16:53:58 <zehicle_> can we quickly close on the Flag validations tests as OS specific https://review.openstack.org/#/c/244782/ ?
16:54:13 <hogepodge> We're thinking two legal agreements, one for distros and one for public, to capture the subtleties.
16:54:34 <eglute> hogepodge can you work with markvoelker on the new patch to address all the comments?
16:54:40 <eglute> zehicle_ +1
16:54:59 <zehicle_> hogepodge, I think that makes sense BTW (two agreements)
16:55:06 <hogepodge> Also, api or version updated will need new testing for the new products. But if say a company like Canonical or SuSE wants to have an Long Term Supported version, we wouldn't yank the license, just advertise that they pass a much older standard
16:55:19 <eglute> #action hogepodge and markvoelker will work on a new patch for retesting
16:55:23 <markvoelker> eglute: Sure, I'll draft up a new patchset based on what hogepodge said and this discussion, he can take first crack at reviewing/suggesting edits. =)
16:55:24 <eglute> hogepodge that makes sense
16:55:31 <hogepodge> markvoelker: can do
16:55:39 <eglute> zehicle_ the floor is yours
16:55:46 <zehicle_> my expectation was that distros would have admin tests required - as mentioned earlier.  future topic FWIW
16:55:47 <eglute> #topic Flag validation tests as being OS specific
16:55:48 <markvoelker> hogepodge:I should have something for you to look at late today.
16:55:55 * markvoelker looks at calendar
16:55:59 <markvoelker> Err...maybe tomorrow. =)
16:56:06 <hogepodge> hopefully none of that is controversial, but we want to make it reasonable for vendors and the foundation to implement and also capture the intent of the committee
16:56:21 <eglute> thanks markvoelker and hogepodge!
16:56:27 <zehicle_> considering community discussion (esp from TC) - we're not going to move forward on that patch
16:56:41 <eglute> #link https://review.openstack.org/#/c/244782/
16:56:41 <zehicle_> should be pretty clear by now
16:56:44 <eglute> right
16:57:02 <zehicle_> I don't want to loose the discussion - I know it will come up again
16:57:05 <markvoelker> zehicle_: I'd suggest that DefCore Committee members record their final votes as a matter of record and ask the patch to be abandoned.
16:57:12 <zehicle_> however, I'm ready to workflow -1 on it
16:57:26 <zehicle_> markvoelker, that was my thinking
16:57:29 <rockyg> workflow -1 works for me
16:57:49 <eglute> #action DefCore committee members record final comments and votes on https://review.openstack.org/#/c/244782/
16:58:01 * zehicle_ add process note that flags are made to approved guidelines, not pending ones
16:58:17 <eglute> right
16:58:30 <eglute> we are almost out of time, sorry we didnt get to rockyg issue
16:58:45 <eglute> we can discuss it in defcore irc channel or wait for next week
16:58:47 <hogepodge> rockyg: had an observation about tests changing over the last few months, I'd like her to send something to the mailing list to expand so we can discuss next week https://etherpad.openstack.org/p/novav2extensionstestchanges
16:59:03 <eglute> ML discussion would also work
16:59:22 <eglute> thanks everyone! I will be around in the defcore IRC
16:59:24 <markvoelker> Oh, we actually discussed this issue
16:59:30 <eglute> #endmeeting