20:01:21 <ttx> #startmeeting tc
20:01:21 <openstack> Meeting started Tue Feb  2 20:01:21 2016 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:24 <openstack> The meeting name has been set to 'tc'
20:01:31 <ttx> Hi everyone!
20:01:32 <annegentle> o/
20:01:35 <ttx> Here is our agenda for today:
20:01:39 <devananda> o/
20:01:43 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:02:04 <ttx> #topic Adds the Poppy CDN project to the Governance Repository
20:02:11 <ttx> #link https://review.openstack.org/273756
20:02:24 <ttx> Poppy has been around for some time, including some presence in past summits
20:02:52 <ttx> They hold regular meetings on IRC and sometimes used the ML for discussion
20:02:59 <ttx> flaper87: you raise two points
20:03:01 <dhellmann> the only part of this that worried me was not finding anything about a ptl election, did they have one?
20:03:12 <jaypipes> o/
20:03:12 <mestery> dhellmann: ++, and flaper87 raised that in the review
20:03:15 <ttx> We don't mandate that they had an election for the initial ptl tbh
20:03:34 <dhellmann> ok, that's fair, I just wasn't sure how the current ptl was selected at all
20:03:41 <flaper87> dhellmann: I seem to remember they did but I could be wrong. FWIW, I think they know the "openstack way"
20:03:45 <ttx> once in they are included in the election runs, but they can announce a ptl for the initial cycle
20:03:48 <dtroyer> o/
20:03:59 <anteaya> for new projects it mostly is by aclaimation even if they do go through the motions
20:04:19 <flaper87> Most (all) of them used to be part of Zaqar in the past and I'm confident they won't have issues adopting elections and other tools they perhaps haven't used enough
20:04:25 <ttx> as far as the tag goes, it should really be applied by us
20:04:38 <flaper87> ttx: happy to do it myself
20:04:50 <ttx> would be the occasion to refresh all of them
20:05:02 <ttx> so in summary i wouldn't block on those issues
20:05:21 * dims_ lurks
20:05:31 <dhellmann> agreed
20:05:41 <flaper87> ++
20:05:45 <flaper87> happy to remove my -1
20:06:07 <ttx> any other objection / remark ?
20:06:10 <mestery> Also agreed, and commented as such in the review
20:06:17 <ttx> It certainly is a small project
20:06:32 <ttx> but it feels integrated enough, using Designate for stuff
20:07:16 <jeblair> are there any open source cdns poppy could interface with?
20:07:29 <annegentle> jeblair: hm, none I can think of
20:07:33 <ttx> jeblair: good question, I don't think there is such a thing ?
20:07:39 <dhellmann> yeah, their presentation to our meetup group a while back was quite impressive in terms of the amount of upstream integration they had and were planning
20:07:52 * ttx looks at deps
20:07:58 <jeblair> i'm wondering if this is a case of a project that we can not fully test because it exists solely to interface with proprietary services
20:08:09 <jeblair> dhellmann: can you elaborate?
20:08:24 <dhellmann> oh, just that they were using oslo, relying on designate, etc.
20:08:28 <jeblair> ah gotcha
20:08:33 <dhellmann> they were trying to focus their layer and work with the other existing projects
20:08:36 <dhellmann> not reinvent things
20:08:42 <flaper87> ++
20:08:48 <ttx> hmm, they seem to have a pretty weird directory layout
20:09:00 <ttx> see the requirements directory
20:09:06 <annegentle> let's have them not make a separate client and plug into osc :)
20:09:22 <dtroyer> they would still need a lib for that
20:09:27 <dhellmann> annegentle : ++
20:09:28 <jaypipes> jeblair: that is my concern as well.
20:09:33 <ttx> I wonder how they can gate with such a setup
20:09:38 <flaper87> annegentle: that's their plan already
20:09:43 <lifeless> hi, @lca so can't really pay attention here
20:09:44 <annegentle> dtroyer: flaper87: cool
20:09:47 <flaper87> we can have them make that explicit in the review
20:09:54 <flaper87> I believe they've talked w/ dtroyer already
20:09:58 <ttx> oh, just a very specific tox.ini
20:10:09 <dhellmann> yeah, I wonder if their dist has good metadata
20:10:14 <dhellmann> we might need to work with them on that
20:10:24 <flaper87> yup
20:10:52 * edleafe wanders in late
20:11:00 <flaper87> mmh, not sure if they're syncing with upstream g-requirements given their requirements structure
20:11:04 <ttx> hmm, I wonder about the licenses of those deps
20:11:18 <dhellmann> flaper87 : no, they aren't
20:11:23 <flaper87> amitgandhinz: around ?
20:11:32 <amitgandhinz> flaper87: hi
20:11:33 <flaper87> It'd be cool if you could help us clarify some things
20:11:36 <flaper87> amitgandhinz: ^
20:11:40 <flaper87> backlog :D
20:12:06 <flaper87> amitgandhinz: basically, we noticed you folks are not syncing with global requirements
20:12:27 <dhellmann> ttx: we should be able to clear a lot of that up by converting the separate files to extras
20:12:38 <flaper87> and there might be some dependencies that don't have a license that works well with OpenStack
20:12:41 <amitgandhinz> not currently.  we in general have tried to follow the general requirements but have not enforced it.  i think there are a few that arent
20:12:46 <flaper87> amitgandhinz: are you folks working on getting there?
20:12:46 <ttx> Abstaining until I can check the licenses on deps
20:13:06 <ttx> dhellmann: sure, but maybe we should wait until that's clarified before approving ?
20:13:34 <amitgandhinz> we can.  it hasnt been a priority right now to remove the stuff that is not part of general reqs but we can prioritize that if needed
20:13:46 <jeblair> amitgandhinz: is there an open source cdn system that poppy could integrate with?
20:13:50 <dhellmann> ttx: maybe
20:14:11 <amitgandhinz> jeblair: nothing that is active.  there have been a few that fizzled like OpenCDN etc, but nothing that has stayed and matured
20:14:15 <dhellmann> amitgandhinz : we need it to be clear that you're meeting the requirement "Project must have no library dependencies which effectively restrict how the project may be distributed or deployed"
20:14:23 * flaper87 abstains as well...
20:14:39 <flaper87> looking forward to clarify the requirements bit, otherwise it looks good
20:14:41 <amitgandhinz> im pretty sure everything is apache licensed but would need to confirm it
20:14:51 <flaper87> amitgandhinz: happy to help with guidance on that front if necessary
20:14:59 <flaper87> amitgandhinz: requirements, tox, etc.
20:15:08 <thingee> amitgandhinz: without an open source solution there's not really a reference implementation to verify things work from a testing perspective.
20:15:24 <ttx> I couldn't spot any blatant issue with the licensing in the deps
20:15:43 * jroll notices the tests use mimic to mock CDN provider APIs
20:16:53 <thingee> amitgandhinz: recommend reading the discussion on where mimic has been going in the openstack community http://lists.openstack.org/pipermail/openstack-dev/2016-January/083510.html
20:16:59 <ttx> certifi is ISC, but we might need to add that to the mix anyway
20:17:16 <malini> FYI - mimic is just used in the docker support, but the tests are independent of mimic
20:17:33 <flaper87> malini: oh, that's good input.
20:17:49 <jroll> ah, neat
20:17:50 <ttx> OK, we have enough votes to pass this
20:17:53 <jeblair> jroll: yeah, it's probably as good as can practically be in this case.  i'm struggling with it because when i talk about our stance on open core, i say we leave the door open for plugins for proprietary systems but our open-source implementations are first-class.
20:17:57 <sdague> I guess it's just whether an orchestrator for commercial services that has no open implementation is really openstack. Seems a little odd to me personally. Especially given that no open core issue.
20:18:05 <thingee> jeblair: +1000
20:18:18 <jeblair> sdague: i think we just said very similar things
20:18:29 <jroll> jeblair: yeah, agree
20:18:43 <jroll> just wanted to note that, for better or worse
20:18:47 <ttx> sdague, jeblair: yes, that's a good point.
20:18:51 <sdague> jeblair: yes
20:19:00 <thingee> jeblair: however like I spoke to you about open core and openstack, I don't think it's exactly accurate stance we currently have.
20:19:07 <sdague> i'm -1 for that reason honestly, I just don't think we want that to be our pattern
20:19:08 <jeblair> i recognize the complexity introduced by not having a viable open source implementation of a thing though.  thus the struggle.
20:19:33 <dhellmann> yeah, this isn't a case of a project ignoring an open source option
20:19:33 <sdague> openstack doesn't have to be the home for all software
20:19:33 <ttx> I propose we think a bit more about it over the week and make a final call next week
20:19:37 <annegentle> jeblair: yeah... it's such a physical thing too, these networks and geographies
20:20:05 <ttx> would be interesting to have a discussion about the "no open core" principle and where that leads us wrt: Poppy
20:20:11 <mestery> ttx: Seems reasonable
20:20:14 <thingee> ttx: +1
20:20:32 <flaper87> ttx: ++
20:20:45 <thingee> to both points of waiting and open core discussion
20:20:49 <ttx> The brokering-to-commercial-serviuces aspect was also hitting some nerves on my side
20:21:22 <annegentle> the struggle is that it provides a better user story
20:21:26 <ttx> Alright, let's put it back on agenda next week, and have interesting discussion in the mean time
20:21:28 <annegentle> but yeah, I get it. it's a struggle
20:21:38 <jeblair> annegentle: agreed
20:21:39 <ttx> #topic Rescheduling bug-smash event
20:21:50 <jeblair> annegentle: if i had to use a cdn, i'd like to do so with an openstack api :)
20:21:52 <ttx> annegentle: it's not an easy call, otherwise we'd had made it already
20:21:56 <annegentle> jeblair: ++
20:22:12 <ttx> it's neither completely wrong nor completely fine.
20:22:18 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2016-January/085196.html
20:22:20 <ttx> dhellmann: care to introduce this topic ?
20:22:29 <dhellmann> sure
20:22:52 <dhellmann> some folks from intel, ibm, and a bunch of other companies are trying to organize an even to encourage working on bugs
20:23:12 <dhellmann> in the past these have resulted in some new contributors, and obviously new contributions
20:23:33 <dhellmann> in principle I like the idea, but they have picked dates that correspond exactly with our feature freeze deadline this cycle
20:23:38 <dhellmann> so, I have asked them to reschedule it
20:23:43 <ttx> which is basically the worst possible date
20:23:58 <ttx> it was a pretty bad date already last cycle iirc
20:24:00 <sdague> this has also happened the last two cycles in similar ways
20:24:00 <dhellmann> no one has said "no", but shane wang, who seems to be the main organizer, has asked the TC to weigh in
20:24:24 <dhellmann> after we get this one moved, as sdague says, we keep having this problem so I would like to brainstorm ideas for addressing that separately
20:24:28 <annegentle> what's the offset?
20:24:30 <ttx> Well, my view on it is that if they want some attendance to that event they should definitely avoid that week
20:24:39 <annegentle> a week?
20:24:41 <dhellmann> apparently the "marketing folks" picked these days, and I'm not sure how to communicate with them
20:24:41 <russellb> yes, i think it should be rescheduled.
20:24:44 <dhellmann> annegentle : yes, one week later
20:24:52 <mestery> Definitely needs to be rescheduled
20:24:57 <anteaya> do folks know we have a release schedule? http://docs.openstack.org/releases/mitaka/schedule.html
20:24:59 <russellb> i can't imagine why anyone would disagree with that
20:25:00 <dhellmann> that's still not ideal for finding a bunch of mentors, but it's better than FF date
20:25:05 <flaper87> I'd probably recommend rescheduling it the week after or even 2 weeks after
20:25:08 <jeblair> #link http://docs.openstack.org/releases/mitaka/schedule.html
20:25:15 <dhellmann> flaper87 : 2 weeks puts us close to RC1
20:25:15 <ttx> and in general move that in the first tier of the cycle if they want more attendance, like sdague suggested on thread
20:25:22 <mestery> anteaya: The folks scheduling these types of things apparently don't, we need to advertise that better I think
20:25:29 <flaper87> right but 1 week is still a bit hard for other folks to attend
20:25:32 <anteaya> mestery: I can support that
20:25:37 <flaper87> mmh
20:25:52 <sdague> well, my understanding is feedback was given during the early discussions, but it was not taken
20:26:02 <anteaya> sdague: :(
20:26:07 <dhellmann> flaper87 : my argument for moving it from the FF date is that it jeopardizes landing features in the release. doing it on the RC1 date would have the same effect.
20:26:11 <flaper87> sdague: any reference for that?
20:26:18 <ttx> dhellmann: +1
20:26:19 <annegentle> last week of feb. would be better?
20:26:25 <dhellmann> flaper87 : shane's email to me indicated they were aware fo the issue
20:26:28 <flaper87> dhellmann: ++
20:26:28 <ttx> i think the date you suggested is the less worse
20:26:34 <ttx> annegentle: not really
20:26:46 <flaper87> dhellmann: oh, ok.
20:26:49 <dhellmann> annegentle : after the next summit is the best time, frankly
20:26:57 <sdague> dhellmann: ++
20:27:10 <anteaya> can the tc schedule global bug smash days? and the companies can then market it?
20:27:11 <ttx> http://docs.openstack.org/releases/mitaka/schedule.html
20:27:14 <jroll> I'm curious why getting a bunch of folks together to work on bugs would be bad during RC time
20:27:19 <flaper87> dhellmann: ++ to that as well. I wonder if it'd be better, as bad as it sounds given the time some folks have put into this, to just do it in N-1
20:27:20 <ttx> R-7 is an option, otherwise R-4
20:27:25 <jroll> isn't that when we should be really focused on hammering out bug fixes?
20:27:31 <annegentle> but these bug fixes, are they more for stable releases?
20:27:45 <sdague> jroll: because it is being advertised as a great way to onboard new folks during that window
20:27:45 <ttx> jroll: it's not optimal. But better than hitting FF week
20:27:49 <annegentle> I mean, honestly, onboarding more stable fixers would be a nice goal.
20:28:03 <dhellmann> jroll : doing it on the day we're trying to spin the release means a fix you want might not get in because of the extra load on the gate
20:28:08 <sdague> when teams are getting to a very narrow view of what needs to be solved
20:28:16 <dhellmann> jroll : also what sdague said
20:28:24 <jeblair> and the extra load on people :)
20:28:31 <dhellmann> jeblair : yes
20:28:31 <sdague> jeblair: ++
20:28:32 <jroll> fair enough
20:28:35 <flaper87> it's not necessarily bad for OpenStack but for ppl getting onboard
20:28:37 <jroll> b 57
20:28:39 <jroll> oops
20:28:52 <amrith> as a general matter, what time in the release schedule does the TC feel would be good for such a bug smash day?
20:28:53 <dhellmann> basically, we're all focused on things other than the goal of this, which will either distract us or fail because of lack of support from the rest of the community
20:29:00 <thingee> doesn't help with the sunsetting of public cloud infra was using
20:29:00 <anteaya> amrith: m1
20:29:08 <amrith> anteaya, thx
20:29:09 <dhellmann> amrith : between summit and M1
20:29:10 <thingee> resources are in an all time low
20:29:14 <barrett1> amrith: excellent question!!
20:29:18 <dhellmann> amrith : never *on* a deadline week
20:29:27 <jroll> I do find it odd that we're opposed to new contributors joining or people fixing bugs at any point in the cycle, but I do understand the points here
20:29:29 <amrith> dhellmann, amen to that ;)
20:29:32 <flaper87> and as early in the cycle as possible
20:29:35 <flaper87> I'd add
20:29:37 <ttx> dhellmann: I would just go with your suggestion that R-4 (the week after the one originally planned) is at this stage the less worse place to make it happen, otherwise next cycle
20:29:49 <thingee> jroll: maybe discouraged if you don't really have something merged for first timers?
20:29:58 <amrith> I was looking to direct the conversation towards anteaya's point of the TC proposing a date and then companies marketing that for the coming cycle.
20:30:02 <amrith> So, N1 or before ...
20:30:12 <dhellmann> jroll : to be clear, I'd love to have a bunch of bugs fixed. My issue is the expectations of the organizers with respect to new contributors does not mesh with that week, and that week is not a good time to introduce a *lot* of changes all at once.
20:30:12 <mestery> jroll: I think it's more of a timing thing, and the results of crushing the system from new contributors during a critical release week.
20:30:18 <sdague> jroll: well, it's more about setting expectations. If you are coming in as an expert you can land whenever
20:30:19 <ttx> Also first part of the cycle is a great time to push backports to the recent release
20:30:20 <jeblair> jroll: for me, i'm not opposed, it's just that i think it will not be nearly as good an experience for all involved compared to the alternative times
20:30:25 <barrett1> amrith: Agree - suggest that we reframe the "future" discussion to be more about identifying optimal times for these activities and then recruiting people/companies/geos/verticals to run them and work with TC to define focus areas.
20:30:28 <annegentle> I do have empathy for procuring physical space. It's a scramble sometimes.
20:30:28 <david-lyle> just throwing this out, but why does/should the TC have a say in when people in the community want to fix bugs at all?
20:30:40 <jeblair> david-lyle: because we were asked :)
20:30:41 <dhellmann> ttx: ok. I'm not sure how to make that clear to Shane. Maybe we can vote? or use #agreed to put it in the minutes at least?
20:30:42 <flaper87> david-lyle: because they asked for
20:30:42 <sdague> however, bootstrapping new folks, that's just not a great time
20:30:47 <annegentle> I'd still like bug fixes and doc fixes :)
20:30:49 <ttx> david-lyle: we don't, they asked
20:30:49 <annegentle> any week
20:30:55 <david-lyle> ok, missed the asking, thanks
20:31:14 <anteaya> david-lyle: gate load
20:31:18 <dhellmann> actually, as release managment PTL, I raised the issue
20:31:27 <amrith> I would also like it if there were some support to actively dissuade this event (at the time proposed). it will be bad for two reasons. one as indicated is the load on the infrastructure and 2 the bad impression that a newbie may get ...
20:31:31 <ttx> All in agreement with suggesting R-4 or next cycle ?
20:31:38 <dhellmann> yes
20:31:44 <flaper87> ++
20:31:47 <dtroyer> ++
20:31:48 <jeblair> ttx: ++
20:31:52 <sdague> yeh, next cycle even better
20:32:04 <mestery> ++
20:32:14 <ttx> #agreed Suggest that they use R-4 week, or just defer to early next cycle
20:32:15 <jokke_> In pricipal I like the idea of bugsmashing event between FF and RC1 or right after RC1
20:32:44 <ttx> ok, next topic
20:32:46 <ttx> #topic Follow-up on last weeks applications
20:32:48 <dhellmann> ok, thanks everyone, I'll email shane back and we can move on
20:32:53 <ttx> I wanted to get next actions on the projects that were considered last week
20:32:55 <flaper87> dhellmann: thanks for raising this
20:33:00 <ttx> * EC2API (https://review.openstack.org/268774)
20:33:04 <ttx> Alexandre did post a small wording update, hoping that matches what you expected
20:33:14 <ttx> We now have 4 +1
20:33:21 <sdague> I just added my +1
20:33:30 <sdague> that team has been doing a pretty solid job
20:33:35 <ttx> so if you would consider reposting yours we can probably pass that one today
20:33:51 * flaper87 does that
20:33:56 <ttx> * Add new Repo(shovel) to the Governance Repository (https://review.openstack.org/269417)
20:34:02 <ttx> Unless there is an objection I will abandon this one as "needs to start existing first"
20:34:03 <flaper87> oh, mine is there already
20:34:09 <ttx> * Adding SaltStack to OpenStack (https://review.openstack.org/269556)
20:34:14 <ttx> Same here, I propose to abandon this one until the project team gets some mileage
20:34:21 <flaper87> ++
20:34:23 <dhellmann> ++
20:34:32 <flaper87> We've done that before and we've agreed abandoning is the way to go
20:34:37 <ttx> ok, we have 8 now on ec2api
20:34:42 <ttx> I'll proceed with approving
20:34:59 <ttx> it's in!
20:35:18 <ttx> #topic Open discussion
20:35:26 <ttx> There were a few topics I wanted to discuss...
20:35:35 <ttx> * Service type vs. project name for use in headers, and about the role of the API WG
20:35:39 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2016-January/085145.html
20:35:45 <ttx> This thread has a few interesting insights and questions
20:35:51 <ttx> One of them being how directive we should be wrt. API guidelines
20:36:07 <ttx> Traditionally we have considered that the API WG guidelines were mostly informative
20:36:08 * cdent is here for that
20:36:15 * devananda lurks with increased interest for this topic
20:36:19 <ttx> But with our increased focus on end user experience I think it might make sense to push for more API consistency
20:36:27 <ttx> and therefore give the guidelines a bit more teeth
20:36:34 <ttx> (or at least some of them=
20:36:36 <ttx> )
20:36:43 <ttx> what is your take on that ?
20:36:59 <sdague> well, the API WG was also forward looking, as to the way things should become
20:37:28 <thingee> sdague: yeah, but what about new projects forming?
20:37:39 <ttx> yeah, maybe there is a split between the desired end state and a few low-hanging-fruit UX targets
20:38:03 <sdague> in this specific case, nova is one of the offenders, mostly because we did a thing before anyone else here, and just been trying to sort the right moment to bring things back to compliance without ruining the world
20:38:05 <edleafe> For new work, going against the WG standards should be a negative factor. We can't do much about existing APIs
20:38:38 <annegentle> part of the user experience consideration is of course what's already in the field. but yes, the API WG should have enough authority to say "this is how it's done"
20:39:00 <annegentle> so if teeth=consideration and authority I'm good with it
20:39:04 <thingee> edleafe: so that's the point I made in the thread. We look at this impossible for existing because we don't have a grasp of who are the offenders and what are they.
20:39:09 <jeblair> this looks like the sort of thing where there is very little value in project differentiation aside from making it hard and confusing for developer-users.  it seems like the tc putting some teeth behind the recomendation may prevent bikeshedding and make things just a little less terrible for folks that use multiple openstack services.
20:39:12 <thingee> I think it would be productive to collect that information.
20:39:20 <annegentle> lots of the work to date has been "what do we have here"
20:39:21 <edleafe> thingee: it
20:39:22 <dhellmann> do we need an assert:complies-with-api-guidelines tag?
20:39:23 <ttx> or "this is how you should do it if you start a new one" ?
20:39:34 <edleafe> thingee: it's also because the APIs are already in use
20:39:37 <annegentle> jeblair: ++
20:39:48 <sdague> dhellmann: probably
20:39:49 <thingee> edleafe: people like to wave hands about micro versioning nowadays
20:40:01 <jeblair> it's also seemingly non-critical enough that if we say "this is the way" and nova takes 3 years to get there, we'll survive.
20:40:14 <annegentle> I've worked with this group and they are super considerate and user-thinkers.
20:40:23 <anteaya> annegentle: how nice
20:40:26 <edleafe> thingee: well, they are doing a *little* more than just hand-waving :)
20:40:26 <jbryce> dhellmann: i like that idea
20:40:37 <dhellmann> I'm sure all of the guidelines are fine, I just wonder how we "enforce" it
20:40:40 <jroll> thingee: well, this thread has a good example of where microversioning doesn't help, because it aims to change the headers used for those versions
20:40:40 <edleafe> jeblair: ++
20:40:50 <annegentle> dhellmann: yeah, and that tag could cover "beyond defcore" that we run into all the time
20:40:51 <thingee> edleafe: I say that to avoid people attacking me on that being the end all solution for us to evolve in having consistent apis
20:40:54 <ttx> yeah, I don't mind slow progress as long as it's going in the right direction. Creating a new API from scratch that deliberately ignores guidelines would be the opposite of progress.
20:40:55 <jroll> thingee: which breaks *everything* :)
20:40:55 <sdague> well, I actually don't like the experimental guideline at all. :)
20:40:57 <dtroyer> nova being different because it was first is really a non-issue.  things were learned and that knowledge being formed for further use is the important part
20:41:24 <jeblair> dtroyer: ++
20:41:25 <markmcclain> rights seems like we should formally grant exceptions to existing code, but push a requirement and expectation that new APIs be compliant
20:41:35 <devananda> nova isn't the only one - some other services followed nova's lead already
20:41:48 <jroll> devananda: yep
20:42:01 <edleafe> thingee: there are no magic pills that will cure all ills. But adding microversions will at least allow for sane growth
20:42:03 <devananda> and as jroll said, changing the header name for an existing service breaks things badly. {micro}versions don't help
20:42:15 <thingee> ttx: if the TC was to police this, we're going back to involving the TC having to dig deep into api design, which I think was part of the benefits of big tent
20:42:17 <jeblair> it will take a long time to get horses back into the barn, but in the mean time, maybe close the door so any more don't get out.
20:42:37 <flaper87> jeblair: ++
20:42:38 <edleafe> devananda: true - that's where parallel headers will be needed if we want to change
20:42:38 <markmcclain> jeblair: ++
20:42:39 <jbryce> jeblair: i like horse and barn analogies
20:42:43 <thingee> or perhaps the api wg wouldn't mind informing the tc of the state new applications' current apis
20:42:45 <annegentle> thingee: I saw the API WG formation as helping the TC with API design -- offloading and spreading the detailed work.
20:42:53 <thingee> annegentle: +1 :D
20:42:55 <dhellmann> annegentle : ++
20:43:07 <ttx> thingee: Ideally we would not police, if we go the assertion route, it would be the project opting in,  into compliance
20:43:08 <edleafe> annegentle: yes!
20:43:09 <cdent> that's pretty much exactly how we think of it (within the group)
20:43:16 <annegentle> cdent: yep
20:43:22 <ttx> and likely the API WG telling us about projects not living up to their tags
20:43:45 <annegentle> cdent: heh do we imagine becoming a tagging force tho?
20:43:51 <dhellmann> ttx: it seems like the API WG should manage the tag application
20:44:07 <dhellmann> ttx: teams that want the tag can ask them to add it?
20:44:11 <ttx> dhellmann: then it would be some tag maintained by the WG, not a project assertion about themselves
20:44:13 <cdent> annegentle: elmiko and I discussed at summit about being able to come up with a compliance test, and had some ideas, but didn't make a lot of progress
20:44:22 <dhellmann> which triggers a review of the api
20:44:24 <dhellmann> ttx: exactly
20:44:26 <elmiko> o/
20:44:28 <thingee> Ok, so as I said in the thread, it would be great if TC could take a stance on this with new applications. And yes, use the api wg for being informed on new projects.
20:44:31 <ttx> dhellmann: I'm fine with that
20:44:32 <dhellmann> ttx: so a different name?
20:44:39 <thingee> existing projects, it would be great if we can understand the problem space.
20:44:49 <dhellmann> api-wg:complies-with-guidelines
20:44:52 <devananda> edleafe, thingee: any service that would be asked to change the header name will need to carry both headers until such time as they are willing to completely drop support for today's client libraries.
20:44:53 <thingee> otherwise it's just looked at as an impossible problem
20:45:06 <ttx> dhellmann: yeah, same as vulnerability:managed or release:managed
20:45:12 <devananda> as far as guidelines for new projects, I think what's being discussed here is great
20:45:13 <dhellmann> ttx: right
20:45:14 <ttx> dhellmann: +1
20:45:18 <dtroyer> dhellmann: some guidelines?  all guidelines?  which?  that gets messy
20:45:28 <thingee> devananda: so support both headers, deprecate.
20:45:33 <sdague> devananda: right, and I think that's going to be nova's plan, just add the additional headers
20:45:40 <thingee> sdague: +1
20:45:41 <dhellmann> dtroyer : I don't think we want one tag per guideline, but I see your point.
20:45:44 <elmiko> cdent: (assuming you are referring to the example project stuff) i have setup a github repo for the example project and started creating an impl locally
20:45:50 <dtroyer> me either
20:45:52 <edleafe> devananda: a service might *want* to change its header. The old one may be dropped in the future, or it may hang around forever
20:45:58 <sdague> thingee: the deprecate is weird, you kind of have to keep them all forever
20:45:59 <ttx> dtroyer: they should probably have a pack of minimal requirements that they would tie to the tag
20:46:09 <thingee> sdague: sure, just don't document it anymore then
20:46:16 <thingee> people will forget, but yeah that seems fair
20:46:23 <sdague> thingee: you have to
20:46:28 <sdague> there are liberty clouds
20:46:32 <sdague> that only work with it
20:46:37 <thingee> fair
20:46:37 <dhellmann> ttx: right, or if they can be categorized in some useful ways maybe a small number of more descriptive tags
20:46:37 <edleafe> thingee: people may forget, but exiting tools won't
20:46:51 <thingee> edleafe: how active are these tools then?
20:46:56 <ttx> ok so we should recommen
20:47:07 <sdague> but not only that, there are deployed public clouds. We need the API to work with any cloud, that was kind of the point :)
20:47:09 <ttx> d the API wg comes up with their own tag or set of tags to describe levels of compliance
20:47:11 <edleafe> thingee: no one really knows.
20:47:23 <edleafe> They don't all self-identify
20:47:36 <annegentle> tag:has-awful-mulitple-POST-request-bodies
20:47:39 <devananda> sdague: exactly. keep both headers indefinitely is the only path that makes sense to me here
20:47:46 <sdague> deciding to break that for the sake of consistency isn't a valid trade off, just when we are making gains on interop
20:47:48 <dhellmann> annegentle : +2
20:47:54 <edleafe> thingee: when I was at Rackspace I had a hell of a time getting usage metrics for the SDKs
20:48:07 <jeblair> generous in what you accept and strict in what you send
20:48:10 <sdague> anyway, is there a particular ask here?
20:48:11 <dhellmann> devananda, edleafe, thingee, sdague : I don't think we need or want to solve the specific issue in this meeting
20:48:26 <ttx> thingee: to answer your question ideally we would look at this before approving new service projects
20:48:38 <sdague> dhellmann: yeh, I was trying to regroup about what the ask or concern is for us to address
20:48:39 <edleafe> dhellmann: sure, but it is helpful to air the concerns of the different approaches
20:48:47 <annegentle> dhellmann: yeah. I think the ask is of the API WG if they see tags as a decent way to measure/apply standards adherence
20:48:48 <dhellmann> sdague : you hit enter before I did :-)
20:48:53 <annegentle> was that even a sentence?
20:48:55 <thingee> dhellmann: you're right. I only cared about this being something the TC takes a stance on going from recommending to enforcing. If it's just new projects, sure that's a great step
20:49:03 <dhellmann> edleafe : the API WG can deal with the details
20:49:16 <ttx> but it's really easier for the API WG to keep track of their set of rules and judge how far a project is
20:49:45 <ttx> thingee: it's also about not regressing in existing projects
20:49:48 <dhellmann> right, we have people looking at this already, and we have a system for tracking the results in the governance repo. let's use them.
20:50:05 <cdent> the issue, from the standpoint of the group is how to have some teeth
20:50:20 <cdent> an "official tag" is probably the hammer we have at the moment
20:50:25 <ttx> OK, let's continue on that thread, I had a few other points to touch on
20:50:35 <ttx> * Competition vs. user experience
20:50:40 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2016-January/085041.html
20:50:50 <ttx> Jay raises a number of interesting points about how allowing competition without any restriction resulted in a crappy user experience
20:51:01 <ttx> I'd like us to think about ways to fix that
20:51:55 <dhellmann> now?
20:52:00 <ttx> oh no :)
20:52:02 <sdague> cdent: honestly, I expect teeth are less likely to drive consistency than helping hands
20:52:03 <dhellmann> :-)
20:52:12 <ttx> I think it's a great topic though
20:52:25 <anteaya> sdague: I think a combination is useful
20:52:30 <cdent> sdague: I think it depends a great deal on where in a project's lifecycle any project is
20:52:36 <ttx> and wouldn't mind a temperature read from the room on it
20:52:48 <thingee> sdague: would you agree the guidelines the api wg have created are helping hands? Is it working?
20:52:49 * flaper87 replied to that thread
20:52:53 <anteaya> ttx: user experience is important
20:52:54 <flaper87> I think it's a good one
20:53:13 <ttx> I'm fine with competition as long as it doesn't result in unnecessary duplication of effort, and crappy user experience
20:53:13 <flaper87> we should add it for next week's meeting. Hopefully Jay will be around
20:53:14 * annegentle ponders
20:53:21 <annegentle> yeah I'd like some think time on that
20:53:25 <dhellmann> ttx: I've been struggling to find a way to say that projects have to have completely unique APIs that don't include their project name in them. As soon as we drop to generic terms, we get back into the "who owns $feature_space" question
20:53:25 <sdague> thingee: helping hands as in hands helping get the code in line
20:53:29 <jaypipes> flaper87: sorry, I am around now...
20:53:30 <cdent> I spoke with jay about this topic some over the weekend
20:53:34 <jaypipes> in London at hotel...
20:53:41 <cdent> ah there he is now
20:53:46 <sdague> ttx: right, so the backups service type issue is a real issue
20:53:50 <ttx> dhellmann: no I agree it's a tricky balance
20:54:03 <ttx> sdague: the /alarms example is pretty appalling too
20:54:06 <thingee> sdague: sure. I don't think know if the api wg liaisons help organize that for their respected projects.
20:54:07 <sdague> we kind of need a registered namespace
20:54:28 <dtroyer> we have this problem in other areas too, and we have to… sdague, yes, that
20:54:52 <dhellmann> is this something for a new group to manage? or the api-wg?
20:55:13 <sdague> this, honestly, starts really getting into the service catalog space
20:55:14 <jaypipes> dhellmann: I think the API-WG is the correct group for this
20:55:15 <ttx> I don't think we need competition that much. I think we need ways to replace projects with better alternatives over the long run
20:55:29 <devananda> ttx: ++
20:55:32 <sdague> which could be api-wg, or not. But our own ianal is going to be important
20:55:35 <cdent> sdague: I think it is definitely a service catalog issue
20:55:36 <sdague> that being said...
20:55:40 <barrett1> ttx: +1
20:55:52 <annegentle> cdent: so we're already working on reserved names in the service catalog
20:55:53 <flaper87> ttx: fwiw, that's exactly what I've been pushing for since we started talking about the big tent. +1
20:55:53 <sdague> we don't freak out about .../action
20:55:55 <ttx> the easy way to do that is to allow competition, but that opens a whole can of UX worms
20:55:59 <thingee> dhellmann: +1 very similar to the cross-project spec liaisons. They may not be the person to do the work, but they work with their respected group to prioritize things
20:55:59 <cdent> annegentle++
20:56:01 <annegentle> cdent: with extra data if you really need it as a provider
20:56:17 <annegentle> but the actual resources, I have to think on that. Endpoint+resource.
20:56:41 <thingee> dhellmann: I don't know if this works though. cp-spec liaison is so new, and getting volunteers for cross-project efforts is , well..
20:56:41 <jaypipes> sdague: /action is under a sub-resource, not a top-level resource endpoints overlap.
20:56:43 <dhellmann> jaypipes , sdague : who owns the service catalog registry?
20:56:53 <flaper87> ttx: or mmh, probably I misread you :P
20:56:55 <sdague> dhellmann: that's a very good question
20:57:02 <dhellmann> thingee : I suspect we'll also end up adding a new project requirement that they have their endpoint registered
20:57:16 <sdague> it could be either the api-wg or the tc directly
20:57:19 <jeblair> we do?  or we delegate a group?
20:57:24 <annegentle> how do we enable an ecosystem if the experience sucks, I get it. but who gets to "keep" generic resources like alarms, meters, backups, archives, and so on
20:57:31 <dhellmann> jeblair : ultimately we own it, but who's going to actually do the work?
20:57:32 <jeblair> we can put a yaml file in governance
20:58:03 <sdague> so, something to consider, we have service types
20:58:08 <sdague> which is already a namespace
20:58:08 <annegentle> jeblair: that's what we have for service catalog
20:58:09 <ttx> I think it's a hard problem, and we definitely won't solve it in the next 2 min.
20:58:15 <annegentle> right:)
20:58:24 <sdague> and that I think we can have a real register for (we don't quite yet)
20:58:24 <jaypipes> heh, tru nuf
20:58:28 <dhellmann> sdague: good point. so all URLs need to start with the servide type?
20:58:41 <ttx> But we should definitely think and talk about it more over the coming weeks
20:58:43 <sdague> dhellmann: they would if they were on the same web server
20:59:00 <ttx> Last topic I wanted to quickly mention, the mission statement situation
20:59:02 <dhellmann> sdague : might as well always do it
20:59:07 <ttx> russellb started a thread on the foundation ML, which turned a bit into bikeshedding as expected
20:59:12 <russellb> indeed
20:59:14 <ttx> #link http://lists.openstack.org/pipermail/foundation/2016-February/002263.html
20:59:17 <sdague> dhellmann: that breaks 100% of our ecosystem ...
20:59:18 <ttx> Please chime in if you care.
20:59:27 <russellb> we did say in the board meeting that if we can't decide on anything, we'll just approve what the TC already proposed
20:59:30 * russellb shrugs
20:59:31 <devananda> ttx: if endpoint registration becomes the new blessing of officialdom, then the TC ends up where we were pre-big-tent
20:59:34 <flaper87> russellb: ++
20:59:35 <dhellmann> sdague : all in? :-)
20:59:37 <annegentle> russellb: heh nice
20:59:47 <ttx> devananda: yeah, I'm not sold on that solution either
21:00:09 <sdague> devananda: to get a service type? I don't see how that's incompatible with the big tent
21:00:41 <ttx> sdague: at the very least you would get some first mover advantage
21:01:04 <ttx> anyway, we are past time
21:01:12 <ttx> Thanks everyone!
21:01:20 <ttx> #endmeeting