16:01:01 <markvoelker> #startmeeting defcore
16:01:02 <openstack> Meeting started Wed Jun  8 16:01:01 2016 UTC and is due to finish in 60 minutes.  The chair is markvoelker. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:06 <openstack> The meeting name has been set to 'defcore'
16:01:09 <markvoelker> o/
16:01:17 <shamail> hi everyone
16:01:26 <catherineD|2> o/
16:01:45 <Brunssen> O/
16:01:54 * markvoelker notes that the crowed may be a little thin today as hogepodge is at OpenStack Day Prague and eglute is out of the office
16:02:13 <markvoelker> #link https://etherpad.openstack.org/p/DefCoreLunar.6 today's agenda
16:02:36 <markvoelker> Without further ado, let's jump in...
16:02:44 <dwalleck> o/
16:02:55 <markvoelker> #topic Many patches landed last week! Please continue to keep an eye on the queue
16:03:15 <markvoelker> Last week we managed to land a lot of patches that have been waiting for a while
16:03:45 <markvoelker> I also cleaned out a few stale ones that have been languishing with no new patchsets for months, so the queue should be in better shape
16:04:04 <markvoelker> There are definitely a few that could still use some action though
16:04:13 <markvoelker> I highlighted three in the etherpad:
16:04:38 <markvoelker> #link https://review.openstack.org/#/c/310582/ < mostly markvoelker and hogepodge talking here, could use some more eyeballs
16:04:50 <Rockyg> o/
16:04:59 <catherineD|2> markvoelker: I just add one more to the three for question
16:05:00 <markvoelker> #link https://review.openstack.org/#/c/324892/ < has been discussed a few times, needs a few actual reviews to move forward
16:05:28 <markvoelker> #link https://review.openstack.org/#/c/310621/ < fairly large change to schema, needs input (particularly from refstack-savvy folks)
16:05:56 <markvoelker> Any questions on those before we get to catherineDl2's patch?
16:06:48 <markvoelker> hearing none....
16:06:57 <markvoelker> #action everyone please review patches in the queue
16:07:11 <shamail> will do.
16:07:13 <markvoelker> And now to catherineDl2's patch:
16:07:19 <markvoelker> #link https://review.openstack.org/#/c/300608/
16:07:25 <markvoelker> catherineDl2, the floow is yours
16:07:29 <markvoelker> *floor
16:07:29 <catherineD|2> thx
16:08:05 <catherineD|2> question is do we want to flag test in advisory or just required section?
16:08:45 <gema> o/
16:09:19 <markvoelker> I think we discussed last week about signaling intent...e.g. it would be good to flag in advisory to let folks know there's an issue with the tests.
16:09:38 <catherineD|2> markvoelker: ok thx
16:09:58 <markvoelker> Hmm...oh, this is the one about extended port attributes, right?
16:10:03 <Rockyg> If we flag it in advisory, it broadcasts that the test needs to be refactored to make it into an approved guideline
16:10:24 <markvoelker> E.g. the one where the problem isn't the test, but the basic fact that those capabilities are only typically exposd to admins
16:10:32 <Rockyg> Then, any vendor who thinks that test is important might put resources on fixing it.
16:11:11 <markvoelker> Rockyg: yeah, I think it's fine to add flags for tests that need refactoring even if those Capabilities are advisory
16:11:16 <markvoelker> But this case is a little different
16:11:27 <catherineD|2> actually tests themself can not be in advisory of required ... it is the capability that are in advisory or required
16:11:37 <Rockyg> yup.  saw that when you pointed out which one it is.
16:12:34 <markvoelker> Ok.  So since this is already a Board-approved doc, let's do flags since that doesn't require another round-trip to the Board.  I think we already removed these in next.json, right?
16:12:51 <Rockyg> cool.  good call
16:13:37 * markvoelker looks
16:13:44 <catherineD|2> markvoelker: yes
16:14:22 <markvoelker> Ah, yes...or rather, there's a patch open for that: https://review.openstack.org/#/c/324892/
16:15:00 <markvoelker> I'm already +2 on both of those, so if the rest of you fine folks could give them a look, I think we can move those through fairly quickly.
16:15:35 <markvoelker> Ok, anything else on these patches?
16:15:53 <catherineD|2> markvoelker: I am good... thx
16:16:08 <markvoelker> Ok then, moving right along...
16:16:19 <markvoelker> #topic Rename Working Group
16:16:46 <markvoelker> We've discussed this one a couple of times after the last Board meeting and I had an AI to generate an initial patchset so we could see the scope of the changes and confirm a name
16:16:58 <markvoelker> I posted a first pass at that:
16:17:03 <markvoelker> #link https://review.openstack.org/#/c/327086/ First pass at rename
16:17:31 <markvoelker> There are probably a few things missing from that yet, but should give you a general feel for doc changes
16:17:37 <dwalleck> sounds reasonable
16:17:43 <markvoelker> I also listed out a few other things we need to do in the commit message
16:18:28 <markvoelker> So if folks could have a look, we'll continue to iterate
16:18:42 <markvoelker> (although: if you have limited review bandwidth this week, the other patches are probably more imporant)
16:19:26 <gema> markvoelker: that's a pretty good AI, are you sure humans weren't involved?
16:19:29 <gema> :D
16:19:35 <Rockyg> gotten through the commit message so far....
16:19:35 <catherineD|2> markvoelker: will review
16:19:37 <markvoelker> One of the questions that came up when we discussed the name "Interoperability Working Group" was whether that might cause some confusion with the UC-governed WG's
16:19:42 <markvoelker> gema: =p
16:19:51 <shamail> Hi markvoelker, there was some confusion on my part at the last meeting.  I thought we were intending to move to being an actual WG (non-board appointed/governed) rather just renaming ourselves to include WG in the name.  I agree that in the latter case, we do not need to take any steps that would put this WG under UC governance.
16:20:27 <markvoelker> shamail: cool.  Is anyone concerned that calling it a WG might cause confusion?
16:20:30 <VanL> I don't think that we can divorce ourselves from the board, and I don't think we should.
16:21:09 <shamail> Historically, board governed entities have included committee vs WG in the name… however there is no hard and fast rule here to my knowledge (API WG falls under TC, Product WG falls under UC, etc.)
16:21:11 <Rockyg> VanL, ++
16:21:12 <VanL> 1) Per the original bylaws, trademark is a board/foundation responsibility. Defcore (by whatever name) is the way by which the trademark is administered
16:21:16 <markvoelker> VanL: +1.  And this rename won't do that, but since other WG's are governed by the UC there was a small concern that we might generate some confusion.
16:21:52 <shamail> VanL: +1
16:21:56 <markvoelker> (personally I don't think this is much of a problem, but I'm open to hearing concerns about it)
16:22:10 <Rockyg> Yeah.  I'm not sure wg is quite right.  It does have a slightly different meaning/focus
16:22:20 <VanL> markvoelker: I think the fact that it opened up to the questions indicates there is latent ambiguity.
16:22:36 <catherineD|2> It is confusing if the term WG can be under TC or UC
16:23:08 <Rockyg> also WG is often not permanent, but to fix specific issue(s)
16:23:17 <VanL> I don't actually mind focusing on "interop" vs "defcore". But the full name should reflect the fact that this is a board committee.
16:23:24 <shamail> VanL: +1
16:23:46 <shamail> Was “WG” a part of the name change recommendation or would Interoperability Committee also suffice?
16:23:56 <VanL> Finally, I think there are bigger issues than what color the bikeshed should be named^H^H^H^H^H^H painted
16:23:58 <Rockyg> yeah.  committee or "program"
16:24:17 <shamail> VanL: rofl
16:24:27 <VanL> I understand this is being responsive to discussions at the board meeting.
16:24:46 <VanL> I still think it is pretty far down the priority list
16:24:59 <markvoelker> VanL: =) Correct, this really came up because of the discussion from the Board meeting in Austin.
16:25:28 <markvoelker> The patchset was pretty easy to put together to foster discussion, but there's no particular urgency here (hence my note above about the rest of the queue)
16:26:24 <markvoelker> shamail: WG was suggested at the Board meeting and came up in the very informal straw poll we took later, so I used that in the initial patchset to generate discussion...which we're now having. =)
16:26:53 <Rockyg> So, I think we all agree on the interoperability and we can mull the rest.  Might be worthwhile posting a question/discussion starter on the board ml.
16:27:08 <shamail> markvoelker: got it, thanks.  I know in the past the board asked Diversity to use WG instead of committee specifcially because they didn’t feel it had to be led by a board member.
16:27:11 <shamail> Rockyg: +1
16:27:20 <shamail> I think we all agree with the name in general.
16:27:51 <markvoelker> Ok, so if folks have feelings about the name, I'll suggest that they make some comments on the patchset in gerrit and we can take the discussion there for now
16:28:24 <markvoelker> There is a Board meeting coming up at the end of the month, and we can give them a heads-up about the ongoing discussion then if folks would like.
16:29:01 <markvoelker> Ok, anything else on this?  Ready to move on?
16:29:38 <markvoelker> #topic Midcycle Meetup
16:30:14 <markvoelker> It's about that time again...last year we did a midcycle in July, so if we potentially want to do one again we need to get the ball rolling on planning
16:30:38 <markvoelker> So, quick straw poll: anyone interested in an in-person meetup (probably next month)?
16:31:21 <gema> definitely (are we being shy?)
16:31:41 * nikhil would like join at least remote
16:31:43 <dwalleck> o/
16:32:02 <dwalleck> Just not out of country :-)
16:32:05 <shamail> o/
16:32:07 <Rockyg> If we do, I'd like to focus on test specs, test standrds, gap analysis, etc.
16:32:13 <gema> dwalleck: shame, I was going to suggest uk
16:32:14 <catherineD|2> need to get travel approval
16:32:14 <gema> :D
16:32:15 <shamail> (as long as it doesn’t conflict with my vacation)
16:32:18 <markvoelker> VanL: catherineDl2: how about you guys?
16:32:20 <gema> catherineD|2: me too
16:32:30 <VanL> Yes
16:32:33 <dwalleck> gema: I think QA is doing Germany :D
16:32:43 <shamail> catherineD|2: I need approval to get the approval. :P
16:32:44 <Rockyg> Might have to go to OS China Day
16:32:48 <gema> dwalleck: sounds great
16:32:54 <dwalleck> Though I'd love to travel to the UK!
16:33:19 <markvoelker> OK.  So sounds like tentative interest.  So now we need a date and place.
16:33:56 <markvoelker> I'll send out a note to the ML this week to gauge interest in hosting and prospective dates.
16:33:56 <Rockyg> I bet Huawei would host if it were out here.
16:34:21 <markvoelker> If folks are interested in having their companies host, please check into arrangements and let me know
16:34:29 <markvoelker> (and I'll add a note to that effect to the ML message)
16:34:29 <gema> markvoelker: will do
16:34:47 <Rockyg> how many were at the last one?
16:34:53 <VanL> 30ish?
16:35:05 <Rockyg> Thanks!
16:35:53 <Rockyg> Two days enough or more?
16:36:07 <markvoelker> #action markvoelker send message to ML about midcycle planning
16:36:36 <markvoelker> Rockyg: my gut feel is 2 days is probably sufficient, but it really depends on what we want to cover.
16:36:42 <markvoelker> I'll start up an etherpad for that too
16:37:18 <markvoelker> Ok, anything further on midcycle planning for now?
16:37:43 <Rockyg> gema, I haven't gotten to review your spec yet :(
16:37:47 * dwalleck has to duck out
16:37:54 <markvoelker> Moving on then...
16:37:59 <markvoelker> #topic Test spec
16:38:10 <markvoelker> #link https://review.openstack.org/#/c/317531/ Test spec draft
16:38:22 <markvoelker> gema posted a new revision this morning, so please have a look and continue to comment
16:38:36 <markvoelker> gema: welcome back. =)  Anything in particular you want to discuss on this today?
16:38:56 <gema> nothing, just let's keep the review going
16:39:04 <gema> see if we can get it there soonish :D
16:39:10 <gema> I still feel it's too short
16:39:12 <gema> :)
16:39:22 <gema> but maybe less is more in this case
16:39:25 <markvoelker> Concise isn't necessarily bad. =)
16:39:39 <VanL> I had two ideas to bring up in relation to the spec.
16:39:44 <markvoelker> VanL: go for it
16:40:01 <Rockyg> Well, the age old question testers ask each other: What am I missing?
16:40:38 <VanL> 1) Performance testing: I agree that it is out of bounds for now, but I think that it is an area that could be useful in the future. If an API works but takes 12 hrs to return, that is "broken" from the user/interop perspective.
16:41:04 <VanL> We don't have any tests about this now, and this is a wish list item for me.
16:41:22 <VanL> But we have this on the explicit "not tested" list.
16:41:27 <VanL> First set of questions:
16:42:06 <VanL> a) Do people agree about possible, eventual (1-2 years down the road) performance testing as something that is valuable?
16:42:11 <gema> we could set a time limit in which the whole test suite needs to run
16:42:18 <gema> and make that part of the passing criteria
16:42:35 <VanL> b) Is this worth bringing up now - we could evaluate and change spec later
16:42:39 <gema> generous but less than 12 hours kind of boundary
16:42:54 <shamail> VanL: I agree… it’s not a performance test to benchmark relative performance but test against an absolute upper-bound to ensure responses arrive within a normal window of expectation.
16:43:01 <VanL> (but answering myself on b), I think that we don't want to change expectations)
16:43:15 <markvoelker> VanL: I think it's certainly worth discussing down the road.
16:43:48 <VanL> So should line 30 be removed?
16:44:15 <gema> VanL: no
16:44:22 <gema> VanL: we can remove it when we actually cover that
16:44:26 <markvoelker> VanL: I don't have a particularly strong opinion on removing line 30 just because I think that perf testing is far enough out that we'll have time to broadcast that change and adjust the spec accordingly
16:44:33 <gema> VanL: I did put it there intentionally to make sure we revisit the spec
16:44:34 <VanL> Or even more explicitly, placed in a "not tested now but we may test at some point in the future"
16:44:45 <Rockyg> Well, those of us in at the beginning thought we would eventually get to some of the "ilities", especially performance minimums
16:44:46 <VanL> I would strongly prefer not to set a base expectation
16:45:03 <Rockyg> But whole test suite is too coarse.
16:45:25 <VanL> That we are reasonably* likely to change within a product lifetime
16:45:38 <VanL> *reasonably = 10% chance or greater?
16:46:13 <markvoelker> I think there are a lot of things that could potentially be in scope later down the road, and I'm not sure we really want to try to list them all now.
16:46:20 <gema> I still think it is asking for trouble to add performance targets to the interop spec
16:46:27 <gema> because performance is HW dependant
16:46:34 <catherineD|2> gema: ++
16:46:35 <Rockyg> gema, ++
16:46:47 <catherineD|2> to me performance is the differentiator of the clouds
16:46:57 <markvoelker> gema: yeah, if we go there it's going to need some careful thought, which is why it may be a ways out
16:47:13 <gema> catherineD|2: absolutely
16:47:30 <nikhil> I have a question to ask on this topic.
16:47:31 <VanL> gema: True. But there are concrete deployments and recommended minimum standards. Put openstack on a pentium pro, it may not perform how you would like.
16:47:39 <Rockyg> catherineD|2, but there have been clouds where it would take 1.5 to 2hrs to spin up a VM and the user was chareged as if it was up...
16:47:39 <markvoelker> I wouldn't mind seeing a note to the effect of: "this specification may change over time" or "will be reviewed periodically" though
16:47:45 <gema> VanL: so what?
16:47:52 <gema> VanL: nobody is going to go to production on that
16:48:06 <gema> VanL: and if they do, they'll have a bad cloud
16:48:17 <shamail> markvoelker: +1, an overall disclaimer seems appropriate.
16:48:29 <gema> markvoelker: +1 will add that
16:48:31 <VanL> +1 on disclaimer
16:48:32 <markvoelker> nikhil: sure, what's your ask?
16:48:32 <gema> it's a life document
16:48:36 <gema> live
16:48:38 <gema> x)
16:49:07 <nikhil> What is the scope or rather 'purpose' of this spec?
16:49:09 <VanL> In general I am not suggesting we solve the perf testing issues now. Thats a ways off, if it ever lands at all.
16:49:21 <nikhil> Specifically, I do not see a mention of the word 'branding'.
16:49:23 <catherineD|2> VanL: In my mind if an API works that means it interops... but if it takes 12 hours to come back it is still inerop (because it comes back) but it is the users' choice to select or not select this cloud
16:49:41 <gema> nikhil: we are trying to define what the tests that we use should look like to be used for interoperability
16:49:48 <markvoelker> nikhil: essentially this is DefCore laying down it's thoughts about what makes a good interoperability test
16:49:49 <gema> nikhil: some tests are just not good enough
16:50:22 <markvoelker> nikhil: it helps to be able to point to something concrete when we, for example, go to QA and say "we really need to refactor this test and take out the admin credentials"
16:50:22 <Rockyg> catherineD|2, if it takes 12 hrs to come back, most apps would have errored out already
16:50:35 <VanL> nikhil: The brand is meant as a guarantee of interoperability. If the tests don't test that, then we need a change
16:50:55 <Rockyg> automation assumes a certain level of performance, so it is interop, really
16:51:06 <VanL> This is meant to have changes be principled
16:51:12 <catherineD|2> Rockyg: time to spin up an VM depending a lot on not just the env ... it would depending on the image itself .. it the image would rely on external entiries for initialization process is one of the example .. it really have too many factors
16:51:16 <nikhil> VanL gema: markvoelker : thanks for clarifying that, I did see a lot of statements on interoperability. Looks like interop branding is implicit but it would be good to start it explicitly (my 2 cents)
16:51:33 <nikhil> s/start/state/
16:51:37 <gema> nikhil: what would that mean for the doc, what kind of sentence?
16:51:47 <markvoelker> nikhil: sure, your comments on the patch would be welcome
16:51:55 <gema> yep, please add to the patch
16:51:59 <shamail> VanL brought up to the topic of performance testing to gauge whether this might be something we are interested in revisiting for broader discussion in the future and it seems that there is interest in doing so.  We should document the different points being raised right now and discuss them in depth later (when its time to revisit performance testing).
16:51:59 <gema> I will update
16:52:13 <nikhil> thanks, let me take that on the patch then. just wanted to get some clarification on the intent of this spec.
16:52:14 <Rockyg> nikhil, the branding is the carrot to get folks to meet interop
16:52:18 <VanL> +1 Nikhil; It may be a good idea to say "The purpose of all defcore tests is to put meaning behind the brand promise of openstack interoperability."
16:52:25 * shamail senses a midcycle topic
16:52:29 <Rockyg> So, they are separate but sort of related.
16:52:44 <gema> I thought the purpose is to validate compliance
16:52:51 <Rockyg> gema, ++
16:53:14 <VanL> Compliance with what? => Compliance with the minimum interoperability guidlines
16:53:19 <VanL> *guidelines
16:53:20 <gema> with the guidelines
16:53:48 <Rockyg> Compliance with the interop of stated capabilities
16:53:48 <gema> VanL: sorry I was lost in the "put meaning behind the brand promise"
16:53:53 <gema> didn't understand that bit :D
16:54:06 <VanL> gema: Sorry, marketing/branding speak
16:54:11 * markvoelker glances at the clock and notes we're down to a few minutes remaining
16:54:13 <gema> VanL: no worries, I see what you mean
16:54:20 <gema> VanL: please add a quick comment to gerrit
16:54:20 <VanL> Ok, issue #2:
16:54:22 <gema> will fix
16:54:30 <Rockyg> I think VanL's statement is for the branding/TM side, not the Defcore side of this.
16:54:59 <Rockyg> Keep marketing out of the spec, my thoughts
16:55:04 <gema> Rockyg: ++
16:55:45 <Rockyg> moving on?
16:55:53 <VanL> I think we should add to the spec something like: "Defcore is for ensuring a minimum foundation of interoperable functionality, and is not intended to place a ceiling on what additional functionality is provided by a vendor."
16:56:06 <VanL> Thoughts?
16:56:32 <gema> VanL: it is meant to ensure interoperability between clouds
16:56:36 <Rockyg> Not at all convinced.
16:56:41 <gema> VanL: not convinced either
16:57:03 <gema> VanL: depending on what the vendor adds, it may break compatibility
16:57:14 <gema> VanL: or get people locked in
16:57:22 <catherineD|2> VanL: agree here ... to me that is the "core" part of "DefCore"
16:57:37 <nikhil> I thought defcore was also about increasing specific type of adoption to maintain the standard way of adopting a functionality?
16:57:44 <gema> nikhil: ++
16:57:50 <Rockyg> To me, that is part of the board/foundation provenance.
16:58:08 <VanL> The point is not to say that people can only move at the speed of defcore, and an addition that explicitly breaks a foundational capability would be a no-no
16:58:14 <markvoelker> VanL: So, the idea of the spec is to help define what we think makes a good interop test.  What would the practical effect of that statement be when we're evaluating a test to see if it measures up to the spec?
16:58:22 <Rockyg> The board could tomorrow decide they want to use a third party test org for the branding part.
16:58:38 <Rockyg> But, Defcore would still have lots of value to the communities.
16:59:06 <Rockyg> But, Defcore would still have lots of value to the communities.a way for anyone to validate the cloud they are using.
16:59:12 <VanL> It basically says that tests (in RFC language) are limited to MUSTs, and tests that enforce MUST NOT are suspect
16:59:32 <nikhil> Rockyg: that is strange. how can we think of coming up with standards when the way you devlop standards is not standard itself?
16:59:40 <catherineD|2> VanL: ++
16:59:42 <markvoelker> I think we're out of time...let's take this over to gerrit please
16:59:50 <gema> markvoelker: ++
16:59:55 <shamail> Thanks markvoelker, great talking with everyone!
17:00:01 <gema> thank you all!
17:00:02 <Rockyg> We *aren't* coming up with standards.
17:00:07 <markvoelker> #endmeeting