16:06:35 <markvoelker> #startmeeting interopwg
16:06:36 <openstack> Meeting started Wed Jan  4 16:06:35 2017 UTC and is due to finish in 60 minutes.  The chair is markvoelker. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:06:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:06:40 <openstack> The meeting name has been set to 'interopwg'
16:06:43 <markvoelker> #chair eglute hogepodge
16:06:44 <openstack> Current chairs: eglute hogepodge markvoelker
16:06:47 <hogepodge> o/
16:06:50 <eglute> o/
16:06:51 <markvoelker> Happy New Year folks!
16:06:56 <shamail> HNY
16:06:58 <catherineD_> o/
16:07:02 <markvoelker> #link https://etherpad.openstack.org/p/DefCoreRoble.7 Today's agenda
16:07:03 <eglute> Happy New Year everyone!!
16:07:32 <markvoelker> We have a fairly short agenda today, so I'd like to take some time to hammer out the final changes for 2017.01.
16:07:40 <markvoelker> But first...
16:07:45 <markvoelker> #topic User Survey
16:08:12 <markvoelker> Apparently we have a window (which closes in five days) to submit a question to the user survey
16:08:22 <eglute> we have opportunity to add one question!
16:08:52 <eglute> any suggestions on what we want to ask?
16:08:54 <markvoelker> So we need to brainstorm fairly quickly on account of everyone being away for the holiday
16:08:59 <markvoelker> (s)
16:09:13 <markvoelker> Let's use the etherpad for this
16:09:37 <markvoelker> eglute: do we know if there's a particular format or formats we have to adhere to?
16:09:47 <eglute> markvoelker good idea
16:09:48 <markvoelker> E.g. can we have open-ended, multiple choice, etc?
16:09:51 <eglute> we can determine format
16:10:21 * shamail is in etherpad now
16:10:42 <shamail> Usually the format can be multiple choice or a text box
16:13:11 <eglute> right, different forms of multiple choice or text.
16:16:39 <eglute> catherineD_ were you asked to provide a question to user survey as well?
16:16:42 <shamail> catherineD_: Does RefStack also get to choice a question?
16:16:44 <eglute> for refstack?
16:16:45 <shamail> jinx!
16:17:12 <eglute> shamail heheh
16:17:13 <hogepodge> we have a question to request test resukts
16:17:44 <shamail> Do you recall how it’s phrased?  Will it help us identify why people may not be submitting as well?
16:19:04 * catherineD_ on the bus to work .. connection is not good ..sorry
16:19:20 <eglute> catherineD_ no worries
16:19:24 <markvoelker> Ok, looks like the pad is getting quieter and we have 5 or so suggestions.
16:19:43 <shamail> +1
16:19:46 <eglute> right, lets narrow down
16:19:47 <hogepodge> I don't
16:20:18 <eglute> we can ask only 1 question. so what is most important?
16:20:33 <eglute> I like this one: What barriers to interoperability are important to you?
16:20:44 <eglute> but we would need good answers to present
16:20:58 <markvoelker> eglute: we could probably take some of those from the issues report
16:21:07 <eglute> markvoelker agreed
16:21:12 <eglute> was just thinking that
16:21:47 <eglute> "can offer up to six answer options. Use "other" as one of your answer options if you would like to offer an "other" text box."
16:22:02 <eglute> I like the interop cases question as well
16:22:38 <eglute> i think we could use our own section in the user survey :)
16:22:57 <markvoelker> Yeah, I'm wondering if we can sort of already have some clues about that one though
16:23:02 <shamail> I like the barriers to interop question… it lends itself well to this type of format
16:23:26 <markvoelker> The survey already asks some questions about why people are choosing OpenStack, and that question had a lot of those options IIRC
16:23:37 <markvoelker> E.g. avoiding vendor lock-in, etc
16:23:50 <eglute> markvoelker good point
16:23:59 <eglute> need to look at all the other questions
16:24:00 <shamail> I also think the question about whether “certification results” are used by customers is important info (e.g. is the Carrot/Stick working beyond vendors) but it is less crucial than the barriers one.
16:24:42 * markvoelker notes that even though he wrote it, he does not like the phrasing of the barriers question and will want to work on that a bit
16:25:26 <eglute> how about we continue thinking about the questions, and then send some options to the mailing list, since we still have a few other things to cover in this meeting?
16:25:45 <markvoelker> eglute: I was about to suggest the same. =)  Let me record a couple of AI's.
16:25:52 <eglute> thanks markvoelker
16:26:20 <markvoelker> #action markvoelker to finalize wording of options and send doodle/email-asking-folks-to-vote-on-pad/etc this evening
16:26:40 <markvoelker> #action markvoelker to close poll and finalize results by...Friday?
16:27:10 <markvoelker> This seems like it should be a quick and easy thing for folks to vote on by the end of the week...any objections?
16:27:46 * markvoelker hears none
16:27:59 <eglute> nope
16:28:02 <eglute> sounds good to me
16:28:02 <markvoelker> Ok then, let's move on and you can look for an email from me tonight.
16:28:17 <eglute> thank you markvoelker
16:28:29 <markvoelker> #topic Finishing Up 2017.01
16:28:58 <markvoelker> We're a bit tardy finalizing a few things, so we need to hammer out the last couple of changes in the queue and create the doc for the BoD to review
16:29:14 <markvoelker> The BoD meeting is January 24.
16:29:25 <markvoelker> eglute: can you confirm if we're on the agenda?  Or has that been set yet?
16:29:46 <eglute> not set yet, but i will make sure we are!
16:30:09 <markvoelker> ok, thanks
16:30:17 <markvoelker> So, I think we just have a few changes left to land...
16:30:30 <markvoelker> #link https://review.openstack.org/#/c/408427/ Cinder change
16:31:09 <markvoelker> My only real question on this one was whether or not should include the list-api-versions capability as advisory since there's no test for it
16:31:17 <shamail> I made the changes to the notes in scoring.txt and also added a note about transition in the description for each capability
16:31:35 <markvoelker> If we knew that was being worked on (or even if there was a bug filed/assigned?) I'd be a bit more comfortable...
16:31:48 <eglute> i agree
16:32:01 <shamail> It’s another one of those markvoelker that highlight the transiition nature
16:32:34 <markvoelker> Well, listing api versions should work regardless of whether you're on v2 or v3 (or support both), right?
16:32:53 <markvoelker> So, it's not really dependent on the major version transition, it's just that there's no test?
16:34:49 <markvoelker> Those tests are generally pretty easy to write (having written at least two of them myself)...
16:35:02 <hogepodge> I'd rather qualify the advisory as versionless, as tests should work for both v2 and v3
16:35:26 <hogepodge> I see no reason to ever drop v2 support, and the distinction is as confusing as everything else about microversions is
16:35:34 <markvoelker> hogepodge: right, the intent here as I interpret it is basically testing GET /
16:36:19 <hogepodge> This is kind of a side issue, in the addition of cinder-v3-* tests as advisory. I'd like to drop the v2 name (I can leave a comment in the review)
16:36:25 <hogepodge> drop the v3 name that is
16:36:29 <hogepodge> so cinder-*
16:37:09 <eglute> +1
16:38:05 <markvoelker> The last few times we'd discussed this we'd decided to duplicate the names to be clear that we require v3 going forward (see note on line 231 of scoring.txt)
16:38:29 <shamail> eglute: +1
16:38:36 <markvoelker> E.g. we require microversion support going forward
16:38:42 <eglute> markvoelker good point
16:38:46 <hogepodge> that's exactly what I don't want to do, though. If v2 and v3 are interoperable, we should capture that and not penalize or confuse anyone who's on v2
16:39:02 <markvoelker> They're separate endpoints though
16:39:43 <garloff> hogepodge: +1
16:40:13 <hogepodge> then we'll have an inflection point where we drop a bunch of interoperable products because they haven't updated fast enough, but not because they're not interoperable
16:40:27 <hogepodge> because the v2/v3 is the only difference, and is highly discoverable
16:40:39 <garloff> At some point the API will start to evolve -- then this is the right time to mandate v3, no?
16:41:03 * markvoelker notes that they'd be more discoverable if we had a test for listing api versions per above, but yes
16:41:04 <hogepodge> only if we require capabilities from later microversions
16:41:23 <garloff> sure
16:41:37 <hogepodge> which will certainly run into loads of scoring issues
16:42:13 <markvoelker> yeah, I think that was part of the reason we'd decided to duplicate the names.  At some point we may actually want to drop v2 from being required.
16:42:20 <markvoelker> If we list both explicitly, that's pretty easy to do
16:42:34 <markvoelker> If we don't, we may develop some implicit dependencies on v32
16:42:36 <markvoelker> *v3
16:42:58 <hogepodge> I'm willing to be wrong on this, I just want to acknowledge that the strategy for cinder v2 -> v3 was carefully considered by that team to preserve interoperability, and I don't want to ignore the semantics of that effort because of syntax
16:43:03 <markvoelker> We don't necessary have to drop v2 when we make v3 required, either...they can coexist as long as necessary
16:43:40 <hogepodge> what does happen is we require vendors to provide both endpoints then
16:43:56 <shamail> hogepodge: +1
16:44:17 <eglute> if the cinder team worked hard to preserve interop, then we should drop v2/v3 at some point
16:44:23 <markvoelker> hogepodge: ack.  Is that not desirable?  E.g. are tools not told "here's an endpoint, go interact with it"?
16:44:27 <hogepodge> I don't want v3 to exclude v2 unnecessarily, that's my main point
16:44:28 <eglute> until we need to introduce verstions again
16:44:58 <eglute> +1 hogepodge
16:45:06 * markvoelker also notes that the Cinder PTL +1'd this plan on line 233 of scoring.txt
16:45:33 <hogepodge> so we don't start telling a bunch of clouds that they're no longer openstack overnight because they're running a perfectly fine endpoint they haven't upgraded yet because business reasons
16:46:30 <markvoelker> Would that really happen considering the Powered program allows for older versions?  v3 couldn't even become required until it's in 3 releases.
16:46:32 <catherineD> hogepodge: what is the different if they are not upgrade but still have to support v3 if we require both v2/v3
16:48:21 <hogepodge> if it's the same tests, I guess it doesn't matter as long as version isn't explicitly tested
16:48:37 <eglute> is the version being tested anywhere?
16:48:53 <hogepodge> for the time being, I would strongly -1 any endpoint version tests that didn't allow both v2 and v3, because they're compatible with one another
16:49:03 <catherineD> In tempest config  user have the options to enable both v2 and v3
16:49:10 <eglute> right now looks like same tests
16:49:13 <catherineD> or either v2 or v3
16:50:01 <markvoelker> They are the same tests.  If you use a v2 endpoint, you don't get microversion headers (which the current tests don't rely on).
16:50:18 <catherineD> test may be the same but path (FQN) maybe different
16:50:29 <markvoelker> At some point it seems like we're going to want clouds to support the headers though
16:50:48 <catherineD> and the guideline is based on FQN so they are treated as different tests
16:50:49 <markvoelker> Because tools will be written to use them/change their behavior based on what versions are supported
16:51:09 <markvoelker> v2 is certainly not going to be "future direction" forever (though it may be supported for a long time)
16:51:29 <markvoelker> So I've no problem at all with the same tests being used or requiring v2 and v3 for some amount of time
16:51:48 <hogepodge> require v2 or v3
16:51:52 <markvoelker> If the day comes when we no longer require v2 though, I'd like that to be explicit to users
16:52:08 <hogepodge> the and vs or is a big difference, and I want a long lead time to let the transition happen in a reasonable way
16:52:55 <eglute> since the tests are the same for now, how about we keep both versions?
16:52:56 <hogepodge> cutting off all v2 because they don't have v3, or cutting off all v3 because they don't run v2, is counter to the goal of guaranteeing interoperability between clouds.
16:53:33 <hogepodge> I agree it can't last forever, and v2 should be dropped at some point, but I want that point pushed out as long as the two work together, or the v2 endpoint is removed from service in covered releases
16:54:18 <garloff> +1
16:54:24 <markvoelker> hogepodge: point taken.  What are cinder's plans for removing v2?
16:56:00 <hogepodge> v2 is listed as supported, I can check with thingee and sean about the team plans
16:57:56 <eglute> we are almost out of time.
16:58:14 <eglute> so for now we agree to remove versions for cinder?
16:58:28 <eglute> or did i misread that
16:58:30 <hogepodge> I don't think there's agreement. :-D
16:58:49 <eglute> ok... so there is still nova and swift left. everyone, please review those
16:58:50 <markvoelker> I think we still want to make it clear that v3 is the way forward, we just need to figure out how to do it...can folks continue on #openstack-interop?  I've got a couple ideas...
16:58:54 <shamail> I think keeping both for now (v2/v3) is important to highlight transition
16:58:58 <hogepodge> I'm just arguing strongly, but this is a group decision lead by eglute and markvoelker
16:59:02 <eglute> and we can carry cinder discussion to our interop channel
16:59:20 <eglute> hogepodge and markvoelker have both valid points
16:59:23 <markvoelker> Ok, let's take the discussion there then (I can hang around for a bit)
16:59:47 <eglute> me too
16:59:47 <markvoelker> #action everyone finish reviews of the outstanding 2017.01 patches
16:59:54 <markvoelker> And with that we'll have to close
17:00:06 <eglute> thanks!
17:00:08 <markvoelker> #endmeeting