20:01:21 #startmeeting tc 20:01:21 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:24 The meeting name has been set to 'tc' 20:01:31 Hi everyone! 20:01:32 o/ 20:01:35 Here is our agenda for today: 20:01:39 o/ 20:01:43 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:02:04 #topic Adds the Poppy CDN project to the Governance Repository 20:02:11 #link https://review.openstack.org/273756 20:02:24 Poppy has been around for some time, including some presence in past summits 20:02:52 They hold regular meetings on IRC and sometimes used the ML for discussion 20:02:59 flaper87: you raise two points 20:03:01 the only part of this that worried me was not finding anything about a ptl election, did they have one? 20:03:12 o/ 20:03:12 dhellmann: ++, and flaper87 raised that in the review 20:03:15 We don't mandate that they had an election for the initial ptl tbh 20:03:34 ok, that's fair, I just wasn't sure how the current ptl was selected at all 20:03:41 dhellmann: I seem to remember they did but I could be wrong. FWIW, I think they know the "openstack way" 20:03:45 once in they are included in the election runs, but they can announce a ptl for the initial cycle 20:03:48 o/ 20:03:59 for new projects it mostly is by aclaimation even if they do go through the motions 20:04:19 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 as far as the tag goes, it should really be applied by us 20:04:38 ttx: happy to do it myself 20:04:50 would be the occasion to refresh all of them 20:05:02 so in summary i wouldn't block on those issues 20:05:21 * dims_ lurks 20:05:31 agreed 20:05:41 ++ 20:05:45 happy to remove my -1 20:06:07 any other objection / remark ? 20:06:10 Also agreed, and commented as such in the review 20:06:17 It certainly is a small project 20:06:32 but it feels integrated enough, using Designate for stuff 20:07:16 are there any open source cdns poppy could interface with? 20:07:29 jeblair: hm, none I can think of 20:07:33 jeblair: good question, I don't think there is such a thing ? 20:07:39 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 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 dhellmann: can you elaborate? 20:08:24 oh, just that they were using oslo, relying on designate, etc. 20:08:28 ah gotcha 20:08:33 they were trying to focus their layer and work with the other existing projects 20:08:36 not reinvent things 20:08:42 ++ 20:08:48 hmm, they seem to have a pretty weird directory layout 20:09:00 see the requirements directory 20:09:06 let's have them not make a separate client and plug into osc :) 20:09:22 they would still need a lib for that 20:09:27 annegentle : ++ 20:09:28 jeblair: that is my concern as well. 20:09:33 I wonder how they can gate with such a setup 20:09:38 annegentle: that's their plan already 20:09:43 hi, @lca so can't really pay attention here 20:09:44 dtroyer: flaper87: cool 20:09:47 we can have them make that explicit in the review 20:09:54 I believe they've talked w/ dtroyer already 20:09:58 oh, just a very specific tox.ini 20:10:09 yeah, I wonder if their dist has good metadata 20:10:14 we might need to work with them on that 20:10:24 yup 20:10:52 * edleafe wanders in late 20:11:00 mmh, not sure if they're syncing with upstream g-requirements given their requirements structure 20:11:04 hmm, I wonder about the licenses of those deps 20:11:18 flaper87 : no, they aren't 20:11:23 amitgandhinz: around ? 20:11:32 flaper87: hi 20:11:33 It'd be cool if you could help us clarify some things 20:11:36 amitgandhinz: ^ 20:11:40 backlog :D 20:12:06 amitgandhinz: basically, we noticed you folks are not syncing with global requirements 20:12:27 ttx: we should be able to clear a lot of that up by converting the separate files to extras 20:12:38 and there might be some dependencies that don't have a license that works well with OpenStack 20:12:41 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 amitgandhinz: are you folks working on getting there? 20:12:46 Abstaining until I can check the licenses on deps 20:13:06 dhellmann: sure, but maybe we should wait until that's clarified before approving ? 20:13:34 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 amitgandhinz: is there an open source cdn system that poppy could integrate with? 20:13:50 ttx: maybe 20:14:11 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 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 looking forward to clarify the requirements bit, otherwise it looks good 20:14:41 im pretty sure everything is apache licensed but would need to confirm it 20:14:51 amitgandhinz: happy to help with guidance on that front if necessary 20:14:59 amitgandhinz: requirements, tox, etc. 20:15:08 amitgandhinz: without an open source solution there's not really a reference implementation to verify things work from a testing perspective. 20:15:24 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 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 certifi is ISC, but we might need to add that to the mix anyway 20:17:16 FYI - mimic is just used in the docker support, but the tests are independent of mimic 20:17:33 malini: oh, that's good input. 20:17:49 ah, neat 20:17:50 OK, we have enough votes to pass this 20:17:53 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 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 jeblair: +1000 20:18:18 sdague: i think we just said very similar things 20:18:29 jeblair: yeah, agree 20:18:43 just wanted to note that, for better or worse 20:18:47 sdague, jeblair: yes, that's a good point. 20:18:51 jeblair: yes 20:19:00 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 i'm -1 for that reason honestly, I just don't think we want that to be our pattern 20:19:08 i recognize the complexity introduced by not having a viable open source implementation of a thing though. thus the struggle. 20:19:33 yeah, this isn't a case of a project ignoring an open source option 20:19:33 openstack doesn't have to be the home for all software 20:19:33 I propose we think a bit more about it over the week and make a final call next week 20:19:37 jeblair: yeah... it's such a physical thing too, these networks and geographies 20:20:05 would be interesting to have a discussion about the "no open core" principle and where that leads us wrt: Poppy 20:20:11 ttx: Seems reasonable 20:20:14 ttx: +1 20:20:32 ttx: ++ 20:20:45 to both points of waiting and open core discussion 20:20:49 The brokering-to-commercial-serviuces aspect was also hitting some nerves on my side 20:21:22 the struggle is that it provides a better user story 20:21:26 Alright, let's put it back on agenda next week, and have interesting discussion in the mean time 20:21:28 but yeah, I get it. it's a struggle 20:21:38 annegentle: agreed 20:21:39 #topic Rescheduling bug-smash event 20:21:50 annegentle: if i had to use a cdn, i'd like to do so with an openstack api :) 20:21:52 annegentle: it's not an easy call, otherwise we'd had made it already 20:21:56 jeblair: ++ 20:22:12 it's neither completely wrong nor completely fine. 20:22:18 #link http://lists.openstack.org/pipermail/openstack-dev/2016-January/085196.html 20:22:20 dhellmann: care to introduce this topic ? 20:22:29 sure 20:22:52 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 in the past these have resulted in some new contributors, and obviously new contributions 20:23:33 in principle I like the idea, but they have picked dates that correspond exactly with our feature freeze deadline this cycle 20:23:38 so, I have asked them to reschedule it 20:23:43 which is basically the worst possible date 20:23:58 it was a pretty bad date already last cycle iirc 20:24:00 this has also happened the last two cycles in similar ways 20:24:00 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 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 what's the offset? 20:24:30 Well, my view on it is that if they want some attendance to that event they should definitely avoid that week 20:24:39 a week? 20:24:41 apparently the "marketing folks" picked these days, and I'm not sure how to communicate with them 20:24:41 yes, i think it should be rescheduled. 20:24:44 annegentle : yes, one week later 20:24:52 Definitely needs to be rescheduled 20:24:57 do folks know we have a release schedule? http://docs.openstack.org/releases/mitaka/schedule.html 20:24:59 i can't imagine why anyone would disagree with that 20:25:00 that's still not ideal for finding a bunch of mentors, but it's better than FF date 20:25:05 I'd probably recommend rescheduling it the week after or even 2 weeks after 20:25:08 #link http://docs.openstack.org/releases/mitaka/schedule.html 20:25:15 flaper87 : 2 weeks puts us close to RC1 20:25:15 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 anteaya: The folks scheduling these types of things apparently don't, we need to advertise that better I think 20:25:29 right but 1 week is still a bit hard for other folks to attend 20:25:32 mestery: I can support that 20:25:37 mmh 20:25:52 well, my understanding is feedback was given during the early discussions, but it was not taken 20:26:02 sdague: :( 20:26:07 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 sdague: any reference for that? 20:26:18 dhellmann: +1 20:26:19 last week of feb. would be better? 20:26:25 flaper87 : shane's email to me indicated they were aware fo the issue 20:26:28 dhellmann: ++ 20:26:28 i think the date you suggested is the less worse 20:26:34 annegentle: not really 20:26:46 dhellmann: oh, ok. 20:26:49 annegentle : after the next summit is the best time, frankly 20:26:57 dhellmann: ++ 20:27:10 can the tc schedule global bug smash days? and the companies can then market it? 20:27:11 http://docs.openstack.org/releases/mitaka/schedule.html 20:27:14 I'm curious why getting a bunch of folks together to work on bugs would be bad during RC time 20:27:19 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 R-7 is an option, otherwise R-4 20:27:25 isn't that when we should be really focused on hammering out bug fixes? 20:27:31 but these bug fixes, are they more for stable releases? 20:27:45 jroll: because it is being advertised as a great way to onboard new folks during that window 20:27:45 jroll: it's not optimal. But better than hitting FF week 20:27:49 I mean, honestly, onboarding more stable fixers would be a nice goal. 20:28:03 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 when teams are getting to a very narrow view of what needs to be solved 20:28:16 jroll : also what sdague said 20:28:24 and the extra load on people :) 20:28:31 jeblair : yes 20:28:31 jeblair: ++ 20:28:32 fair enough 20:28:35 it's not necessarily bad for OpenStack but for ppl getting onboard 20:28:37 b 57 20:28:39 oops 20:28:52 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 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 doesn't help with the sunsetting of public cloud infra was using 20:29:00 amrith: m1 20:29:08 anteaya, thx 20:29:09 amrith : between summit and M1 20:29:10 resources are in an all time low 20:29:14 amrith: excellent question!! 20:29:18 amrith : never *on* a deadline week 20:29:27 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 dhellmann, amen to that ;) 20:29:32 and as early in the cycle as possible 20:29:35 I'd add 20:29:37 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 jroll: maybe discouraged if you don't really have something merged for first timers? 20:29:58 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 So, N1 or before ... 20:30:12 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 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 jroll: well, it's more about setting expectations. If you are coming in as an expert you can land whenever 20:30:19 Also first part of the cycle is a great time to push backports to the recent release 20:30:20 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 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 I do have empathy for procuring physical space. It's a scramble sometimes. 20:30:28 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 david-lyle: because we were asked :) 20:30:41 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 david-lyle: because they asked for 20:30:42 however, bootstrapping new folks, that's just not a great time 20:30:47 I'd still like bug fixes and doc fixes :) 20:30:49 david-lyle: we don't, they asked 20:30:49 any week 20:30:55 ok, missed the asking, thanks 20:31:14 david-lyle: gate load 20:31:18 actually, as release managment PTL, I raised the issue 20:31:27 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 All in agreement with suggesting R-4 or next cycle ? 20:31:38 yes 20:31:44 ++ 20:31:47 ++ 20:31:48 ttx: ++ 20:31:52 yeh, next cycle even better 20:32:04 ++ 20:32:14 #agreed Suggest that they use R-4 week, or just defer to early next cycle 20:32:15 In pricipal I like the idea of bugsmashing event between FF and RC1 or right after RC1 20:32:44 ok, next topic 20:32:46 #topic Follow-up on last weeks applications 20:32:48 ok, thanks everyone, I'll email shane back and we can move on 20:32:53 I wanted to get next actions on the projects that were considered last week 20:32:55 dhellmann: thanks for raising this 20:33:00 * EC2API (https://review.openstack.org/268774) 20:33:04 Alexandre did post a small wording update, hoping that matches what you expected 20:33:14 We now have 4 +1 20:33:21 I just added my +1 20:33:30 that team has been doing a pretty solid job 20:33:35 so if you would consider reposting yours we can probably pass that one today 20:33:51 * flaper87 does that 20:33:56 * Add new Repo(shovel) to the Governance Repository (https://review.openstack.org/269417) 20:34:02 Unless there is an objection I will abandon this one as "needs to start existing first" 20:34:03 oh, mine is there already 20:34:09 * Adding SaltStack to OpenStack (https://review.openstack.org/269556) 20:34:14 Same here, I propose to abandon this one until the project team gets some mileage 20:34:21 ++ 20:34:23 ++ 20:34:32 We've done that before and we've agreed abandoning is the way to go 20:34:37 ok, we have 8 now on ec2api 20:34:42 I'll proceed with approving 20:34:59 it's in! 20:35:18 #topic Open discussion 20:35:26 There were a few topics I wanted to discuss... 20:35:35 * Service type vs. project name for use in headers, and about the role of the API WG 20:35:39 #link http://lists.openstack.org/pipermail/openstack-dev/2016-January/085145.html 20:35:45 This thread has a few interesting insights and questions 20:35:51 One of them being how directive we should be wrt. API guidelines 20:36:07 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 But with our increased focus on end user experience I think it might make sense to push for more API consistency 20:36:27 and therefore give the guidelines a bit more teeth 20:36:34 (or at least some of them= 20:36:36 ) 20:36:43 what is your take on that ? 20:36:59 well, the API WG was also forward looking, as to the way things should become 20:37:28 sdague: yeah, but what about new projects forming? 20:37:39 yeah, maybe there is a split between the desired end state and a few low-hanging-fruit UX targets 20:38:03 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 For new work, going against the WG standards should be a negative factor. We can't do much about existing APIs 20:38:38 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 so if teeth=consideration and authority I'm good with it 20:39:04 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 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 I think it would be productive to collect that information. 20:39:20 lots of the work to date has been "what do we have here" 20:39:21 thingee: it 20:39:22 do we need an assert:complies-with-api-guidelines tag? 20:39:23 or "this is how you should do it if you start a new one" ? 20:39:34 thingee: it's also because the APIs are already in use 20:39:37 jeblair: ++ 20:39:48 dhellmann: probably 20:39:49 edleafe: people like to wave hands about micro versioning nowadays 20:40:01 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 I've worked with this group and they are super considerate and user-thinkers. 20:40:23 annegentle: how nice 20:40:26 thingee: well, they are doing a *little* more than just hand-waving :) 20:40:26 dhellmann: i like that idea 20:40:37 I'm sure all of the guidelines are fine, I just wonder how we "enforce" it 20:40:40 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 jeblair: ++ 20:40:50 dhellmann: yeah, and that tag could cover "beyond defcore" that we run into all the time 20:40:51 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 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 thingee: which breaks *everything* :) 20:40:55 well, I actually don't like the experimental guideline at all. :) 20:40:57 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 dtroyer: ++ 20:41:25 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 nova isn't the only one - some other services followed nova's lead already 20:41:48 devananda: yep 20:42:01 thingee: there are no magic pills that will cure all ills. But adding microversions will at least allow for sane growth 20:42:03 and as jroll said, changing the header name for an existing service breaks things badly. {micro}versions don't help 20:42:15 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 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 jeblair: ++ 20:42:38 devananda: true - that's where parallel headers will be needed if we want to change 20:42:38 jeblair: ++ 20:42:39 jeblair: i like horse and barn analogies 20:42:43 or perhaps the api wg wouldn't mind informing the tc of the state new applications' current apis 20:42:45 thingee: I saw the API WG formation as helping the TC with API design -- offloading and spreading the detailed work. 20:42:53 annegentle: +1 :D 20:42:55 annegentle : ++ 20:43:07 thingee: Ideally we would not police, if we go the assertion route, it would be the project opting in, into compliance 20:43:08 annegentle: yes! 20:43:09 that's pretty much exactly how we think of it (within the group) 20:43:16 cdent: yep 20:43:22 and likely the API WG telling us about projects not living up to their tags 20:43:45 cdent: heh do we imagine becoming a tagging force tho? 20:43:51 ttx: it seems like the API WG should manage the tag application 20:44:07 ttx: teams that want the tag can ask them to add it? 20:44:11 dhellmann: then it would be some tag maintained by the WG, not a project assertion about themselves 20:44:13 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 which triggers a review of the api 20:44:24 ttx: exactly 20:44:26 o/ 20:44:28 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 dhellmann: I'm fine with that 20:44:32 ttx: so a different name? 20:44:39 existing projects, it would be great if we can understand the problem space. 20:44:49 api-wg:complies-with-guidelines 20:44:52 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 otherwise it's just looked at as an impossible problem 20:45:06 dhellmann: yeah, same as vulnerability:managed or release:managed 20:45:12 as far as guidelines for new projects, I think what's being discussed here is great 20:45:13 ttx: right 20:45:14 dhellmann: +1 20:45:18 dhellmann: some guidelines? all guidelines? which? that gets messy 20:45:28 devananda: so support both headers, deprecate. 20:45:33 devananda: right, and I think that's going to be nova's plan, just add the additional headers 20:45:40 sdague: +1 20:45:41 dtroyer : I don't think we want one tag per guideline, but I see your point. 20:45:44 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 me either 20:45:52 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 thingee: the deprecate is weird, you kind of have to keep them all forever 20:45:59 dtroyer: they should probably have a pack of minimal requirements that they would tie to the tag 20:46:09 sdague: sure, just don't document it anymore then 20:46:16 people will forget, but yeah that seems fair 20:46:23 thingee: you have to 20:46:28 there are liberty clouds 20:46:32 that only work with it 20:46:37 fair 20:46:37 ttx: right, or if they can be categorized in some useful ways maybe a small number of more descriptive tags 20:46:37 thingee: people may forget, but exiting tools won't 20:46:51 edleafe: how active are these tools then? 20:46:56 ok so we should recommen 20:47:07 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 d the API wg comes up with their own tag or set of tags to describe levels of compliance 20:47:11 thingee: no one really knows. 20:47:23 They don't all self-identify 20:47:36 tag:has-awful-mulitple-POST-request-bodies 20:47:39 sdague: exactly. keep both headers indefinitely is the only path that makes sense to me here 20:47:46 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 annegentle : +2 20:47:54 thingee: when I was at Rackspace I had a hell of a time getting usage metrics for the SDKs 20:48:07 generous in what you accept and strict in what you send 20:48:10 anyway, is there a particular ask here? 20:48:11 devananda, edleafe, thingee, sdague : I don't think we need or want to solve the specific issue in this meeting 20:48:26 thingee: to answer your question ideally we would look at this before approving new service projects 20:48:38 dhellmann: yeh, I was trying to regroup about what the ask or concern is for us to address 20:48:39 dhellmann: sure, but it is helpful to air the concerns of the different approaches 20:48:47 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 sdague : you hit enter before I did :-) 20:48:53 was that even a sentence? 20:48:55 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 edleafe : the API WG can deal with the details 20:49:16 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 thingee: it's also about not regressing in existing projects 20:49:48 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 the issue, from the standpoint of the group is how to have some teeth 20:50:20 an "official tag" is probably the hammer we have at the moment 20:50:25 OK, let's continue on that thread, I had a few other points to touch on 20:50:35 * Competition vs. user experience 20:50:40 #link http://lists.openstack.org/pipermail/openstack-dev/2016-January/085041.html 20:50:50 Jay raises a number of interesting points about how allowing competition without any restriction resulted in a crappy user experience 20:51:01 I'd like us to think about ways to fix that 20:51:55 now? 20:52:00 oh no :) 20:52:02 cdent: honestly, I expect teeth are less likely to drive consistency than helping hands 20:52:03 :-) 20:52:12 I think it's a great topic though 20:52:25 sdague: I think a combination is useful 20:52:30 sdague: I think it depends a great deal on where in a project's lifecycle any project is 20:52:36 and wouldn't mind a temperature read from the room on it 20:52:48 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 ttx: user experience is important 20:52:54 I think it's a good one 20:53:13 I'm fine with competition as long as it doesn't result in unnecessary duplication of effort, and crappy user experience 20:53:13 we should add it for next week's meeting. Hopefully Jay will be around 20:53:14 * annegentle ponders 20:53:21 yeah I'd like some think time on that 20:53:25 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 thingee: helping hands as in hands helping get the code in line 20:53:29 flaper87: sorry, I am around now... 20:53:30 I spoke with jay about this topic some over the weekend 20:53:34 in London at hotel... 20:53:41 ah there he is now 20:53:46 ttx: right, so the backups service type issue is a real issue 20:53:50 dhellmann: no I agree it's a tricky balance 20:54:03 sdague: the /alarms example is pretty appalling too 20:54:06 sdague: sure. I don't think know if the api wg liaisons help organize that for their respected projects. 20:54:07 we kind of need a registered namespace 20:54:28 we have this problem in other areas too, and we have to… sdague, yes, that 20:54:52 is this something for a new group to manage? or the api-wg? 20:55:13 this, honestly, starts really getting into the service catalog space 20:55:14 dhellmann: I think the API-WG is the correct group for this 20:55:15 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 ttx: ++ 20:55:32 which could be api-wg, or not. But our own ianal is going to be important 20:55:35 sdague: I think it is definitely a service catalog issue 20:55:36 that being said... 20:55:40 ttx: +1 20:55:52 cdent: so we're already working on reserved names in the service catalog 20:55:53 ttx: fwiw, that's exactly what I've been pushing for since we started talking about the big tent. +1 20:55:53 we don't freak out about .../action 20:55:55 the easy way to do that is to allow competition, but that opens a whole can of UX worms 20:55:59 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 annegentle++ 20:56:01 cdent: with extra data if you really need it as a provider 20:56:17 but the actual resources, I have to think on that. Endpoint+resource. 20:56:41 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 sdague: /action is under a sub-resource, not a top-level resource endpoints overlap. 20:56:43 jaypipes , sdague : who owns the service catalog registry? 20:56:53 ttx: or mmh, probably I misread you :P 20:56:55 dhellmann: that's a very good question 20:57:02 thingee : I suspect we'll also end up adding a new project requirement that they have their endpoint registered 20:57:16 it could be either the api-wg or the tc directly 20:57:19 we do? or we delegate a group? 20:57:24 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 jeblair : ultimately we own it, but who's going to actually do the work? 20:57:32 we can put a yaml file in governance 20:58:03 so, something to consider, we have service types 20:58:08 which is already a namespace 20:58:08 jeblair: that's what we have for service catalog 20:58:09 I think it's a hard problem, and we definitely won't solve it in the next 2 min. 20:58:15 right:) 20:58:24 and that I think we can have a real register for (we don't quite yet) 20:58:24 heh, tru nuf 20:58:28 sdague: good point. so all URLs need to start with the servide type? 20:58:41 But we should definitely think and talk about it more over the coming weeks 20:58:43 dhellmann: they would if they were on the same web server 20:59:00 Last topic I wanted to quickly mention, the mission statement situation 20:59:02 sdague : might as well always do it 20:59:07 russellb started a thread on the foundation ML, which turned a bit into bikeshedding as expected 20:59:12 indeed 20:59:14 #link http://lists.openstack.org/pipermail/foundation/2016-February/002263.html 20:59:17 dhellmann: that breaks 100% of our ecosystem ... 20:59:18 Please chime in if you care. 20:59:27 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 ttx: if endpoint registration becomes the new blessing of officialdom, then the TC ends up where we were pre-big-tent 20:59:34 russellb: ++ 20:59:35 sdague : all in? :-) 20:59:37 russellb: heh nice 20:59:47 devananda: yeah, I'm not sold on that solution either 21:00:09 devananda: to get a service type? I don't see how that's incompatible with the big tent 21:00:41 sdague: at the very least you would get some first mover advantage 21:01:04 anyway, we are past time 21:01:12 Thanks everyone! 21:01:20 #endmeeting