20:04:46 <ttx> #startmeeting tc
20:04:47 <openstack> Meeting started Tue Sep  2 20:04:46 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:04:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:04:49 <ttx> Our agenda for today:
20:04:51 <openstack> The meeting name has been set to 'tc'
20:04:55 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:05:00 <ttx> #topic Final selection of our User Committee nominee
20:05:06 <ttx> This is in replacement of Ryan Lane.
20:05:13 <ttx> I got your suggestions and reached to them. The following people confirmed:
20:05:20 <ttx> Andrew Mitry, Beth Cohen, Chet Burgess, Jacob Walcik, Jonathan Proulx
20:05:27 <ttx> I set up a Condorcet poll so that we designate someone during this meeting
20:05:30 <ttx> Sending links now.
20:05:50 <dhellmann> do we have advocates who want to speak for these candidates? I don't actually know any of them.
20:05:58 <ttx> OK sent. Please vote before the end of the meeting !
20:06:12 <ttx> Yes, any quick support  ?
20:06:38 <sdague> yeh, these folks are largely unknown to me as well, might be nice to get some statements from folks about them to help with the decision, otherwise I feel it will basically be random
20:06:41 <annegent_> these are all great candidates, I'm happy to talk through support
20:06:47 <markmc> yeah, I'm a bit stuck too
20:06:56 <annegent_> and it's great we have more than before :)
20:07:00 <mikal> Chet is a nova dev, he's the only one I know
20:07:11 <ttx> Jon Proulx did some doc work
20:07:24 <annegent_> Beth worked on the Architecture Design Guide and has been operating OpenStack clouds since pre-grizzly.
20:07:31 <ttx> Andrew Mitry is the Comcast architect
20:07:42 <dhellmann> is the candidate meant to be a user, or just represent technical folks on the user council?
20:07:53 <annegent_> Jacob Walcik helped me write the diablo install guide, ha ha. He is a Rackspace private cloud engineer who supports a ton of private clouds
20:08:00 <mikal> Chet's stackalytics: http://stackalytics.com/?release=all&user_id=cfb-n
20:08:36 <sdague> so we have affiliateion for those besides Jacob and Andrew? Curious what the rest's roles are wherever they happen to work
20:08:37 <jeblair> sdague: ++ i don't feel i have enough information to make a recommendation
20:08:56 <jeblair> sdague: that was to your previous point about getting statements from these folks
20:08:57 <annegent_> Jonathan Proulx was an author on the Ops Guide and runs an OpenStack cloud at MIT and is very active on the operators mailing list. He tests upgrade instructions and most recently wrote a network troubleshooting section.
20:09:02 <mikal> Chet works for metacloud IIRC
20:09:23 <ttx> Andrew is Comcast, Jon Proulx is MIT
20:09:30 <annegent_> Beth works for verizon now, has worked for Cloud Technology Partners
20:09:40 <sdague> annegent_: cool, thanks
20:09:58 <annegent_> and to quantify "a ton" I think three digits?
20:10:19 <annegent_> really they're all great candidates and I'd love to find ways to get them all involved regardless of an "appointment"
20:10:47 <ttx> OK, we can close the vote tomorrow if you'd like time to research them more
20:10:52 <dhellmann> indeed, it hardly feels right to choose if we have volunteers willing to serve (how often does *that* problem come up?)
20:11:18 <ttx> they are a limited crew dut to the NDA on the user survey though
20:11:20 * russellb just joined, sorry for being late
20:11:21 <ttx> so we have to pick
20:11:22 <russellb> (plane, etc.)
20:11:25 <annegent_> right dhellmann my thoughts exactly
20:11:42 <markmc> yeah, the NDA thing makes this weird
20:11:45 <dhellmann> ttx: wow, ok, I didn't realize that was the constraint
20:11:52 <jeblair> i love that we have an nda
20:11:56 <markmc> also means that ideally you don't want to be changing the people very often
20:12:51 <ttx> ok, how about we let that vote open until tomorrow night
20:12:57 <dhellmann> sounds good
20:12:57 <annegent_> that works
20:13:09 <ttx> that gives you time to do reasearch. You can also vote all equal
20:13:17 <ttx> and defer to those with an opinion
20:13:32 <ttx> #topic Graduation review: Zaqar (ex-Marconi) (part 1)
20:13:40 <ttx> flaper87: o/
20:13:41 <ttx> At every end of cycle we look at currently-incubated projects, discuss progress
20:13:42 <jeblair> did those who nominated these people have statements with them?
20:13:44 <flaper87> o/
20:13:52 <ttx> and see if any are ready to be made a part of the next OpenStack integrated release development cycle
20:13:58 <ttx> jeblair: no, we nominated them :)
20:14:05 <ttx> We did Barbican two weeks ago. Today (and possibly next week) we'll do Zaqar
20:14:08 <jeblair> ttx: i mean, did "we" include statements as to why? :)
20:14:13 <ttx> Then we'll do Ironic next week (and possibly the next) when Deva is back from vacation
20:14:21 <ttx> jeblair: anne nominated like almost all of them :)
20:14:31 <dhellmann> jeblair: I saw names, but nothing very formal
20:14:39 <ttx> NB: kgriffs has recently moved to another position, so he designated flaper87 as his permanent delegate until the September election
20:14:49 <ttx> Let me summarize the last Marconi graduation episode...
20:14:59 <ttx> At the graduation review last cycle, I think the concerns fell into three broad categories
20:15:09 <ttx> 1. Pecan vs. Falcon, and more generally lack of alignment with the rest of OpenStack
20:15:14 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2014-March/030385.html
20:15:17 <jeblair> okay, so next time, we should ask for a narrative along with the nominating statement, because i have no basis for making the decision and have no avenues for any real research before tomorrow
20:15:25 <ttx> 2. Data-plane vs. Control-plane approach
20:15:29 <ttx> jeblair: +1
20:15:38 <ttx> 3. Questionable backends (MongoDB/AGPL issue, SQLA db-as-a-queue antipattern)
20:15:47 <ttx> both exposed in that thread:
20:15:55 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2014-March/030367.html
20:16:01 <ttx> Then the graduation request was withdrawn:
20:16:09 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2014-March/030638.html
20:16:17 <ttx> fast-forward to today
20:16:23 <ttx> flaper87: what would be your assessment of the current state of Zaqar in incubation?
20:17:09 <russellb> flaper87: and thanks for joining to represent the project
20:17:19 <flaper87> So, we've addressed the missing pieaces we had since last graduation evaluation. 2 points remain to be discussed. The point w.r.t pecan vs falcon and the one with data-plane vs control-plne
20:17:25 <flaper87> russellb: my pleasure :)
20:17:47 <russellb> the data-plane vs control-plane thing is incredibly unfortunate, IMO, as it has been completely clear to me what zaqar was trying to be from the beginning
20:17:50 <flaper87> As for #3, we've added (thanks to one very helpful GSoC mentee) a redis driver
20:17:56 <russellb> as in, SQS like data API
20:18:06 <flaper87> russellb: +1
20:18:14 <jeblair> russellb: i'm not sure i follow what you're saying
20:18:22 <russellb> i'm saying it's unfortunate that the debate came up
20:18:29 <jeblair> russellb: thanks, that clarifies
20:18:30 <russellb> it doesn't make sense to me
20:18:34 <flaper87> What we've done for that matetr is to communicate and share as much as possible the project's goals
20:18:34 <russellb> cool
20:18:44 <markmc> #link https://wiki.openstack.org/wiki/Zaqar/Frequently_asked_questions#Is_Zaqar_a_provisioning_service_or_a_data_API.3F
20:19:02 * markmc likes that summary of the data-orientated position of the team
20:19:15 <markmc> the API requirements, particularly
20:19:52 <russellb> i guess we should go over each of the concerns ttx mentioned
20:19:54 <jeblair> russellb: i think, if i'm understanding it correctly, the relevance here though is not that it is implementing SQS, but rather that it is doing it from scratch rather than re-using existing queuing technologies
20:19:56 <russellb> and we've sort of already started on #2
20:20:10 <jeblair> (whew, i'm still on topic :)
20:20:14 <russellb> jeblair: :)
20:20:25 <russellb> jeblair: perhaps, though that wasn't the context of the debate as i understood it
20:20:34 <flaper87> that wasn't the context
20:20:36 <russellb> more that folks fundamentally disagreed with an SQS like API in the first place
20:20:44 <markmc> jeblair, I don't think I've ever seen a plausible description of how you'd implement a multi-tenant SQS-like REST API using existing queuing technologies
20:20:46 <flaper87> the context was why the project is not providing, say, rabbitmq as a service
20:21:04 <russellb> right, i think i've seen some pretty good analysis on that from zaqar, and they felt it didn't make sense
20:21:05 <markmc> jeblair, e.g. using RabbitMQ as a backing for something like that seems bizarre to me
20:21:08 <sdague> so where I remain conflicted is whether SQS is essential infrastructure to OpenStack, vs. being a useful part of the ecosystem.
20:21:18 <russellb> doesn't mean the backends they have are the best approach, of course
20:21:49 <stevebaker> fwiw heat will be using zaqar as an option regardless of integrated status, since it solves a real problem for us
20:21:50 <jeblair> okay, so i guess there's two levels of potential objection -- that it does not use (eg) rabbit internally to back its api, and that it does not simply provision/expose (eg) rabbit
20:22:01 <jeblair> it sounds like the data/control plane debate mostly focused on the second
20:22:08 <markmc> yeah, exactly
20:22:46 <russellb> the first debate is really more about #3 in ttx's list
20:22:55 <russellb> err
20:22:56 <vishy> there is also the issue that if it really is just the second it shouldn’t be a service
20:22:57 <sdague> flaper87: are any openstack integrated projects besides heat looking at zaqar to fill some need?
20:23:01 <mikal> jeblair: its certainly my recollection that people were upset / confused that rabbit was being reimplemented in mysql
20:23:05 <russellb> i mean, should it use rabbitmq, or something else other than what it has today
20:23:08 <flaper87> sdague: Trove and Swift
20:23:10 <russellb> mikal: but it's not rabbit at all
20:23:13 <flaper87> and horizon
20:23:15 <russellb> it's very different
20:23:15 <flaper87> sdague: ^
20:23:22 <sdague> flaper87: interesting, what's the swift use case?
20:23:26 <mikal> russellb: sure, but that's what people were saying last cycle
20:23:34 <russellb> i know, and i think that's silly :)
20:23:37 <sdague> flaper87: or are those up there anywhere
20:23:58 <flaper87> sdague: I still have to write swift's ones down because they came up in a quick chat with notmyname
20:24:07 <sdague> flaper87: ok
20:24:57 <annegent_> mikal: yeah people are hearing queues and thinking amqp
20:25:09 <annegent_> flaper87: it wasn't so much a swift use case as a heat use case?
20:25:13 <annegent_> flaper87: iirc?
20:25:43 <flaper87> annegent_: there are 4 projects that I've talked to and they've shared ideas and needs for zaqar: Horizon, Heat, Trove and swift
20:26:15 <flaper87> I've started putting those use cases here: https://etherpad.openstack.org/p/zaqar-integrated-projects-use-cases
20:26:21 <sdague> flaper87: great
20:26:33 <flaper87> since mose of them happened on informal chats and talks at the ATL summit and during Juno
20:26:36 * mikal looks
20:26:39 <flaper87> s/mose/most/
20:27:02 <flaper87> Trove's use case is to communicate with guest-agents
20:27:15 <ttx> The data-plane vs. control-plane discussion is somethign Zaqar has little leverage about -- if we decide we don't want to add data-plane stuff anymore, there is littlethey can do on their side
20:27:23 <ttx> What about the other 2 concerns ?
20:27:39 <mikal> flaper87: how does ironic talk to its guest agent? Is that a use case as well?
20:27:53 <ttx> I think the addiiton of Redis solves #3
20:28:08 <flaper87> mikal: I don't know how they do it but I think it might make sense for Ironic too
20:28:10 <ttx> we are no longer implementing a queue on top of SQL or AGPL
20:28:22 <gokrokve> Murano is using MQ based agent too
20:28:22 <ttx> It's a bit toung though
20:28:23 <flaper87> ttx: yup
20:28:33 <ttx> flaper87: is it landed yet ? the redis support?
20:28:34 <ekarlso> sahara too no ?
20:28:39 <flaper87> ttx: yup, yday
20:28:43 <ttx> ok
20:28:43 <ekarlso> probably other projects as well just to budge in :p
20:28:44 <flaper87> (phew)
20:29:00 <dhellmann> which driver runs in the gate now?
20:29:07 <sdague> dhellmann: mongo
20:29:10 <ttx> what about #1, alignment with the rest of openstack?
20:29:24 <dhellmann> sdague: thanks
20:29:24 <russellb> dhellmann: any comments on oslo integration?
20:29:40 <flaper87> We've been adopting oslo libraries as they're released
20:29:47 <ttx> i suspect it's tied to dataplane/controlpane discussion too, i.e. falcon justification is mostly that it's more dataplane-oriented than pecan
20:29:54 <flaper87> and keeping the files coming from the incubator updated
20:30:13 <dhellmann> it looks like they have several of the low level libraries in their requirements file.
20:30:19 <dhellmann> flaper87: are you the liaison, or is someone else doing that?
20:30:21 <russellb> i don't think i've seen a whole lot of falcon discussion since the last round
20:30:23 * mikal needs to drop off now for a flight, laters
20:30:24 <flaper87> dhellmann: I am
20:30:26 <russellb> was there that i've forgotten?
20:30:27 <jroll> mikal: not to derail, but ironic doesn't have a guest agent
20:30:37 <dhellmann> russellb: it hasn't come up again
20:30:39 <flaper87> russellb: there hasn't been
20:30:58 <russellb> ok, so a concern ... but i'd really hate for *that* to be the only blocker
20:31:06 <russellb> i probably wouldn't block if that was the only thing personally
20:31:20 <russellb> that's still fixable, if the project commits to re-starting work there
20:31:41 <flaper87> TBH, we focused on making v1.1 consistent and cleaning it up
20:31:57 <flaper87> I think a better time to discuss a migration to Pecan would be v2 when it comes
20:32:27 <annegent_> russellb: yes, seems like our gap-analysis-style workflow would work for any sort of pecan<>flask work
20:32:50 <markmc> flaper87, I saw that v2 is when you're planning on removing the lookup-message-by-ID thing?
20:32:59 <markmc> flaper87, when do you think that work will happen?
20:33:02 <ttx> flaper87: anything worty of note in https://wiki.openstack.org/wiki/Zaqar/Incubation/Graduation ?
20:33:17 <sdague> so from a deployment perspective if zaqar is in, that means operators have to deploy and maintain a nosql infrastructure
20:33:27 <russellb> sdague: required?
20:33:31 <russellb> it's all optional now right?
20:33:40 <flaper87> markmc: We're planning to start discussing it at the Kilo summit and we'll probably decide there if it makes sense to give the community a chance to digest v1.1 before start working on v2 or if we should probably just go for it
20:33:42 <sdague> russellb: there is no real sqla backend
20:33:44 <russellb> as in, only if you want zaqar for your tenants
20:33:53 <sdague> and we're talking about heat and other services requiring it
20:33:54 <russellb> right, because we determined that was an anti-pattern, right?
20:34:08 <russellb> i think other services using it should be optional, that's a scope jump
20:34:11 <russellb> should discuss that more
20:34:18 <russellb> because originally this was a "tenant only" service in my view
20:34:27 <russellb> not infrastructure
20:34:30 <annegent_> my sense is this project has a tenant only scope
20:34:33 <flaper87> ttx: we've put lots of efforts on integrating with the whole OpenStack ecosystem and also on having a complete documentation for users and developers
20:34:36 <dhellmann> the heat use case is to communicate with tenants, though, right?
20:34:43 <sdague> annegent_: stevebaker just said heat was going to use it
20:34:54 <sdague> whether or not zaqar is integrated
20:35:16 <russellb> stevebaker: could use some more detail on that i think
20:35:20 <russellb> out of meeting perhaps
20:35:37 <stevebaker> It would be our prefered method for heat/server interaction, with a fallback to swift TempURLs if not available
20:35:40 <jeblair> the faq says it's very much over-cloud, so we're getting mixed messages here
20:35:41 <ekarlso> heat is gonna use what? sorry for not cathcing that
20:35:42 <sdague> putting zaqar in definitely has some implications for what infrastructure is expected to be maintained
20:36:22 <annegent_> sdague: heat also was going to rely solely on keystone v3 when it wasn't widely deployed :)
20:36:50 <annegent_> stevebaker: ah there's the tie-in I was trying to recall, you have a method and a fallback
20:37:04 <stevebaker> we still support v2. This is different though, since the template author chooses what transport method they will use
20:37:19 <annegent_> stevebaker: ok, that's a good point
20:37:32 <stevebaker> there is no magic, an explicit choice is always made
20:38:39 <sdague> it's really unfortunate that we're in a state where projects are only considered successful if they are granted integrated status, because to me zaqar feels like a solid part of the ecosystem, but I'm not sure I believe SQS is essential infrastructure.
20:38:47 <russellb> ok, so if it's an optional tenant initiated thing, that seems reasonable to me
20:38:55 <ttx> So at this point I hear "operational infratsructure extra burden (due to NoSQL deploy)" and "should we really reinvent a queue system rather than piggyback on one"
20:39:07 <ttx> anything else ?
20:39:16 <russellb> ttx: and "API stability" i think, since they're already planning v2 things
20:39:26 <markmcclain> russellb: +1
20:39:29 <ttx> russellb: ++
20:40:00 <sdague> do we have information from deployers beyond rax? Is this seeing adoption in the community already?
20:40:01 <notmyname> FYI I'd like scalable, durable, ha queues for internal swift (ie to more efficiently implement swift features
20:40:21 <flaper87> russellb: not really planing v2, we want to give the community and ourselves enough time to use the existing API, which we consider stable
20:40:37 <russellb> notmyname: it's probably worth exploring that in more detail ... as it sounds like it's in conflict with what other projects use for "infrastructure" queues
20:40:43 <ttx> I'm fine with keeping them in incubation over Api stability and freshness of Redis driver... but i don't want to keep them incubating if we don't believe deploying NoSQL is acceptable, or if we prefer control-plabe to data-plane. Because there is little short of rewriting all that they can fix that
20:40:55 <russellb> as in, if what you're talking about isn't optional tenant initiated features, then i think it's out of the scope i had in mind
20:40:56 <sdague> notmyname: do you see zaraq providing that better than an amqp bus?
20:41:02 <flaper87> sdague: catalyst will (is?) use zaqar too
20:41:08 <russellb> ttx: yeah that makes sense
20:41:11 <markmc> ttx, agree
20:41:19 <annegent_> My sense is that it's super useful for cloud tenants and would be great for our cloud providers to have it at the ready. And other integrated projects want this ability. They did a great job of writing docs too for multiple audiences.
20:41:44 <ttx> so in all cases we need to make up our minds on those (is deploying NoSQL acceptable, is inventing our own queue acceptable, is data-plane acceptable)
20:41:55 <flaper87> FWIW, I think v1.1 is a stable API. It has things that some folks don't like but I wouldn't consider it unstable because of that
20:42:07 <ttx> becasue if we answer no, there is no need to keep them on the wire
20:42:10 <annegent_> so from a docs perspective I won't cry "too heavy integration burden" - this team has done well.
20:42:13 <russellb> flaper87: maybe a detailed response to each identified concerns before next week would assist
20:42:22 <flaper87> russellb: +1
20:42:26 <markmc> ttx, agree - they're the key questions; and sound more like incubation questions ... not that we can't revisit, though
20:43:14 <ttx> markmc: I agree it would be unfortunate to reject on those architectural grounds, but if we don't believe that is accepatble, i prefer we reject late than we accept
20:43:15 <annegent_> markmc: agreed
20:43:15 <russellb> definitely need to resolve them, it's no fair to keep them on the wire
20:43:15 <jroll> if no projects *require* zaqar, than why would deploying nosql be acceptable?
20:43:37 <russellb> jroll: did you mean not acceptable?
20:43:52 <markmc> ttx, they're not so much architectural concerns as scope concerns, but yeah
20:43:54 <jroll> russellb: yes, sorry
20:43:56 <ttx> I know mordred has a strong opinion on the dataplane vs. controlplane thing
20:44:09 <ttx> he should be coming back really soon now
20:44:09 <russellb> jroll: i tend to agree with that, fwiw, though the increased burden should still not be taken lightly
20:44:23 <ttx> I have a strong opinion that we should piggyback on domain specialists where we can
20:44:30 <ttx> i.e. not reinvent queues
20:44:37 <jeblair> i believe we can expect mordred and devanand1 back for next weeks meeting
20:44:41 <ttx> unless we really really can't work with the existing ones
20:44:42 <russellb> but can we in this case?  more than they've done with redis?
20:44:45 <jroll> russellb: I'm always skeptical about deploying more services :)
20:44:52 <russellb> rabbit isn't the answer, imo
20:44:56 <russellb> far from it
20:45:18 <flaper87> re backing zaqar with rabbit: http://blog.flaper87.com/post/marconi-amqp-see-you-later/
20:45:22 <notmyname> zaqar isn't reinventing queues. as in, it's offering things that don't currently existing with stuff like amqp. one example is that zaqar's queues are durable.
20:45:26 <markmc> agree, I think we've chased that rabbit down the wrong hole
20:45:26 <vkmc> IMO it's a different service, we shouldn't compare with Rabbit or AMQP
20:45:33 <russellb> markmc: ++
20:45:46 <notmyname> vkmc: ++
20:45:47 <vkmc> we are covering the cases that Amazon SQS/SNS cover
20:46:14 <ttx> notmyname, vkmc: good point
20:46:42 <ekarlso> kinda like magneto db, would you call it that they are offering something that a layer ontop of cassandra has vs trying to cover features of say a google compute service or aws ?
20:46:44 <annegent_> right, that's my thinking as well
20:47:14 <ttx> flaper87: I think that's enough for this meeting, we'll continue next week. Anything we can discuss on the mailing-list between now and then will help clarify
20:47:30 <ttx> flaper87: you got the list of "concerns" ?
20:47:32 <annegent_> thanks flaper87 for taking up the ptl role
20:47:49 <flaper87> ttx: It'd be nice if we can summarize it now before you change topic
20:47:55 <flaper87> annegent_: my pleasure!
20:47:57 <ttx> ok, let me try
20:48:01 <flaper87> ttx: just to make sure we're on the same page
20:48:31 <ttx> #info concern on operational burden of requiring NoSQL deploy expertise to the mix of openstack operational skills
20:48:58 <ttx> #info concern on should we really reinvent a queue system rather than piggyback on one
20:49:10 <ttx> (that one can be debunked by explaining the SQS case, durable queues, etc)
20:49:37 <ttx> #info concern on dataplane vs. controlplane, should we add more dataplane things in the integrated release
20:49:49 <ttx> #info concern on API v2 being already planned
20:50:14 <markmc> that's an odd summary of the conversation, fwiw
20:50:18 <ttx> #info concern on the maturity of the NoQSL not AGPL backend (Redis)
20:50:20 <markmc> makes it sound like all concern, no support
20:50:34 <jeblair> markmc: it's not a summary of conversation, it's a summary of concerns :)
20:50:39 <ttx> markmc: i'm trying to list the concerns for flaper87 to consume
20:50:57 <flaper87> I'll put those concerns in an etherpad and answer them before next week
20:50:58 <markmc> I honestly think they've addressed many of these
20:51:07 <flaper87> markmc: +1
20:51:09 <ttx> markmc: i'm not saying they didn't
20:51:09 * flaper87 hides
20:51:11 <flaper87> :D
20:51:12 <markmc> and we're not doing a very good job of explaining why they're still a concern
20:51:22 <markmc> it's like, "here guys, have another go on the merry-go-round"
20:51:43 <ttx> I'm just trying to summarize what points are the potential pain points
20:51:47 <markmc> sure
20:52:14 <ttx> flaper87: does that work ? May I switch topic ?
20:52:29 <flaper87> ttx: go ahead, I got the list and I'll work on those before next week
20:52:35 <flaper87> thanks everyone!
20:52:36 <russellb> flaper87: thanks!
20:52:39 <ttx> flaper87: you might want to push a governance change to support your graduation, too
20:52:51 <ttx> flaper87: contact me if you have doubts on how to do that
20:52:52 <ttx> #topic Other governance changes
20:52:53 <flaper87> ttx: it will be my pleasure :)
20:52:57 <ttx> * Propose guidelines for adopting new official projects (https://review.openstack.org/116727)
20:53:03 <ttx> Discussion is still on-going on this one.
20:53:11 <ttx> I wonder if we can really adopt those before we discuss the future of Programs though
20:53:21 <ttx> like whether the current program team really takes responsibility over the adopted project or not
20:53:34 <ttx> * Add reference to neutronincubator project (https://review.openstack.org/117000)
20:53:41 <ttx> On this one there is clear disagreement from Infra on the approach chosen in Neutron
20:53:46 <ttx> jeblair started a thread at:
20:53:49 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2014-August/044125.html
20:53:57 <ttx> Not really sure it went anywhere though, and we need to make progress fast here
20:54:15 <ttx> jeblair: how is that discussion going ?
20:54:21 <markmcclain> ttx: so we're tweaking the incubator proposal
20:54:46 <ttx> markmcclain: to something that would work better for infra?
20:54:53 <markmcclain> items targeted for spinout will go into separate repo and items targeted to merge back into the main tree will look at feature branch
20:55:07 <ttx> ok
20:55:09 <anteaya> usually a patch to governance to add a repo doesn't happen until after the repo exists
20:55:14 <markmcclain> that should align and address jeblair's concerns
20:55:20 <ttx> jeblair: remove your -1 when you're convinced
20:55:22 <jeblair> markmcclain, ttx: i think those two directions are good
20:55:42 <ttx> * Add a Mission Statement for Orchestration (Heat) (https://review.openstack.org/116703)
20:55:44 <markmcclain> anteaya: wanted to discuss concept w/TC before adding workload to infra :)
20:55:44 <annegent_> I'm trying to run through the guidelines for say, the training project
20:55:51 <ttx> This one is still ongoing
20:56:03 <ttx> * Add oslo.log to the Oslo program (https://review.openstack.org/116994)
20:56:11 <ttx> This one is a no-brainer, will approve post-meeting unless someone objects
20:56:16 <ttx> * Add oslo.concurrency to the Oslo program (https://review.openstack.org/117345)
20:56:18 <anteaya> markmcclain: kk, for the benefit of anyone wondering where the repo is
20:56:20 <ttx> Same for this one
20:56:25 <ttx> * The Oslo program is adopting pylockfile (https://review.openstack.org/117622)
20:56:34 <ttx> There is some discussion over this one, like *why* we are doing this
20:56:59 <ttx> so i'll let it cook until next week
20:57:08 <ttx> #topic Open discussion
20:57:20 <ttx> jogo: want to mention your thread ?
20:57:44 <ttx> Anything else, anyone?
20:57:49 <jogo> ttx: sure
20:58:11 <jogo> thread: http://lists.openstack.org/pipermail/openstack-tc/2014-September/000777.html
20:58:35 <sdague> I think jogo's idea was a pretty interesting one. I think if people came up with top 5 items that would be pretty interesting, and provide some feedback into what the cross project sessions should be
20:58:45 <jeblair> jogo: ++
20:59:11 <jogo> sdague: yeah, right now I am more interested to see what the different lists are then figuring out what do do with the results
20:59:16 <jogo> as I am not sure what to expect
20:59:23 <jeblair> we've talked about the desirability of this, and jogo's suggestion gives us some concrete structure for how to get started
20:59:37 <dhellmann> should we hold that discussion on the -dev list, or the tc list?
20:59:40 <ttx> ok, post them on the -dev list
20:59:41 <russellb> i think it's a useful exercise
20:59:54 <russellb> i think it's also worth making sure we all agree on what problem we're trying to solve with the exercise
21:00:02 <dhellmann> jogo, maybe you can start a thread on the -dev list then for us to reply to?
21:00:03 <ttx> dhellman_: I wanted us to agree that it was a good idea first, but yes, the posts themselves should be on -dev
21:00:19 <russellb> increased focus is definitely good, though i think the bigger pain (that leads to people thinking about focus) is just our review bottleneck problems
21:00:22 <ttx> jogo: sounds like the go-ahead you've been waiting for
21:00:23 <dhellmann> ttx: makes sense
21:00:25 <russellb> overall project throughput
21:00:45 <jogo> ttx dhellmann: great I will start a -dev ML thread for folks to respond to
21:00:50 <russellb> and also talk about what the expected consumption of this list would be in the end
21:00:53 <dhellmann> russellb: perhaps we should be thinking about ways to train more reviewers, then
21:00:55 <jogo> I will focus the thread on TC memebers but leave it open for anyone to respond to
21:01:07 <russellb> as in, is it just a sync exercise?  or is it intended to go into saying "no" more?  or?
21:01:22 <anteaya> also I think it will be good as a focusing excerise for the driver writers to recognize what *is* important to the community as a whole
21:01:27 <dhellmann> russellb: I would like for us to pick 1-2 items from the list and put together a "task force" or whatever to actually work on them
21:01:34 * russellb nods
21:01:37 <russellb> yeah that's all good stuff
21:01:41 <anteaya> they might be surprised that it isn't *their* plugin
21:01:46 <jeblair> to provide ptls/core teams some coverage in setting individual project priorities
21:01:48 <dhellmann> russellb: the example I gave in another thread was sdague's log standardization, and notification standardization would be another
21:01:48 <jogo> russellb: I was envisioning this as just an exercise to see where we stand
21:01:53 <annegent_> review bottleneck and scope widening are hand-in-hand from my view
21:01:56 <sdague> honestly, right now, I'm mostly interested in figuring out how my view of the world with what I think is critical aligns with other people in the community
21:01:59 <ttx> ok, time is up
21:02:09 <jogo> sdague: ++ thats the idea
21:02:09 <russellb> cool, yeah, that sounds useful
21:02:12 <ttx> Thanks everyone
21:02:14 <russellb> thanks everyone!
21:02:15 <ttx> #endmeeting