20:01:48 <ttx> #startmeeting tc
20:01:48 <annegentle> here!
20:01:48 <openstack> Meeting started Tue Aug 26 20:01:48 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:51 <openstack> The meeting name has been set to 'tc'
20:02:01 <ttx> Our agenda for today:
20:02:11 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:02:20 <ttx> devananda is proxied by jeblair
20:02:32 <ttx> #topic A program for Rally (part 2)
20:02:41 <zehicle_at_dell> o/
20:02:43 <ttx> #link https://review.openstack.org/108502
20:02:53 <ttx> So this is the continuation of the discussion we started on August 5
20:03:09 <ttx> We paused for a couple of weeks to see if a middle ground was possible where the QA program would adopt Rally, but those efforts were not very successful
20:03:22 <ttx> At this point I think it's fair to conclude that Rally won't be adopted by the QA program
20:03:31 <ttx> Which leaves two options:
20:03:47 <ttx> A/ consider that benchmarking is essential to the completion of the OpenStack project mission, and accept a Benchmarking (or SLA management, or...) program
20:03:59 <ttx> B/ consider that Rally would be more successful as a product built on top of OpenStack for the time being
20:04:11 <ttx> which basically translates into accepting the abovementioned review (or some variant of it) or rejecting it
20:04:22 <ttx> There are a number of -1s on that review, but they don't all mean the same thing
20:04:33 <russellb> seems collaboration has been pretty bumpy, which makes me worry about accepting the program
20:04:33 <ttx> some of them are about exploring the QA option (jeblair, markmcclain, russellb)
20:04:39 <russellb> so i'm leaning toward B at this point
20:04:42 <ttx> some are discussing program names (markmc, devananda)
20:05:00 <boris-42> russellb btw why?
20:05:23 <markmc> yeah, I'm disappointed how the thread went
20:05:25 <boris-42> russellb in such case I am not sure that we will have same ability to help projects like QA
20:05:28 <ttx> jeblair, markmcclain: Now that the QA option is out of the table, would you mind clarifying where you stand (on the A/B choice above) ?
20:05:35 <markmc> was hopeful some concrete plan for collaboration would come out of it
20:05:37 <boris-42> russellb e.g. blocking adding rally gates
20:05:40 <russellb> markmc: right
20:06:12 <boris-42> russellb markmc  actually to be fair we tempest & rally are resolving quite different use cases
20:06:23 <boris-42> russellb markmc  and it's okay that there are 2 tools for 2 different things
20:06:23 <russellb> it's not even just that part
20:06:31 <boris-42> russellb ?
20:06:31 <ttx> I'm leaning like Russell... if that can't work within QA at this point I tend to lean towards (B), at least for the time being
20:06:32 <russellb> even small things like the proposal for the nova job
20:06:54 <russellb> but anyway, i'm not sure what we get by accepting the program right now, you can still keep doing what you're doing
20:07:12 <markmcclain> ttx: I'm leaning towards B
20:07:12 <boris-42> russellb yep but I will get every time -1 from QA guys
20:07:13 <ttx> I think it's one of those areas that could benefit from us not blessing a particular solution today
20:07:14 <russellb> would rather accept it when it's more obvious how integrated rally is to the way we work
20:07:20 <jeblair> i feel strongly enough that much of the work rally is doing should be done in QA and in tempest
20:07:20 <boris-42> russellb when I will try to do something useful for projects
20:07:29 <jeblair> i agree 100% with sdague's email here: http://lists.openstack.org/pipermail/openstack-dev/2014-August/041818.html
20:07:32 <boris-42> russellb but it's already integrated..
20:07:43 <boris-42> jeblair I am not sure about this
20:07:54 <boris-42> jeblair the reason is the different view of how things should be done
20:07:59 <boris-42> jeblair ti's from the begging
20:08:10 <ttx> jeblair: tl;dr: is that A or B?
20:08:10 <boris-42> jeblair functional testing != benchmarking
20:08:28 <jeblair> ttx: B
20:08:34 <ttx> jeblair: thx :)
20:08:36 <boris-42> russellb jeblair as well I really don't see any issues with integration in gates rally..
20:08:56 <russellb> is anyone on A ?
20:08:58 <ttx> any TC member wanting to defend the A option at this point ?
20:09:07 <russellb> jinx.
20:09:20 <ttx> where is jaypipes when we need someone to play devil's advocate
20:09:30 <boris-42> ttx jaypipes is against
20:09:33 <boris-42> ttx I mean B
20:09:36 <sdague> I'm on B, I think that hopefully clear from stuff I put on the list
20:09:38 <boris-42> ttx I can be proxy
20:09:47 <dhellmann> I would have liked to see an operators tools group started, but I'm not sure the current rally team is the right team to do it.
20:09:48 <ttx> boris-42: he could still play devil's advocate and defend A for us
20:09:59 <boris-42> ttx nope he won't do that believe me
20:10:01 <markmcclain> dhellmann: +1
20:10:07 <ttx> dhellmann: frankly at this point not imposing structure sounds like a better outcome
20:10:18 <ttx> maybe i'm infected by Jay
20:10:21 <zaneb> is there agreement that any new program would be to host performance benchmarking *as a service* (to operators)?
20:10:22 <markmcclain> I know at the operators meetup there was a working session to discuss ops tooling
20:10:53 <dhellmann> ttx: yeah, I don't agree with Jay on the need to drop programs, but the collaboration issues we've had with this team make me hesitate at this point.
20:11:03 <ttx> markmcclain: nothing prevents to work on good tooling
20:11:22 <boris-42> dhellmann really guys we Rally team tried to do best..
20:11:23 <dhellmann> zaneb: I don't know what means
20:11:29 <boris-42> dhellmann we even integrated tempest in rally..
20:11:33 <ttx> in fact I expect Rally to be more successful as it stands than into some program where we would force it to change
20:11:34 <markmcclain> ttx: right just saying I think there is a need for ops tooling not sure that this is vehicle for it at this time
20:11:43 <sdague> right, we need to stop thinking only good tools come out of programs. Good tools come out of people writing good tools.
20:11:51 <markmcclain> sdague: +1
20:11:58 <dhellmann> boris-42: the problem has been with compromising with existing teams to fit in to a new niche
20:12:08 <zaneb> dhellmann: i.e. it's something that runs in the cloud, not something you run in the gates or from your laptop
20:12:36 <dhellmann> zaneb: ok, I don't think that's what rally does
20:12:45 <boris-42> dhellmann zaneb  rally does both..
20:12:55 <zaneb> dhellmann: I think that's boris-42's vision for it though
20:12:59 <boris-42> dhellmann zaneb  it's easy to use + it's easy to integrated
20:13:10 <boris-42> so you can easily repeat locally experiment
20:13:14 <boris-42> that was actually idea
20:13:21 <boris-42> Ops guys can share their experiments
20:13:24 <dhellmann> boris-42: "I've wrapped up your tool and reproduced parts of it" is not the same thing as integration
20:13:29 <boris-42> and a lot of them can be adopted for gates
20:13:30 <boris-42> and fixed
20:14:08 <boris-42> dhellmann hm okay then I don't know what is integration...
20:14:15 <zaneb> it seems to me that now is the time to implement the architectural changes that sdague suggested. Once that is done it would be time to decide if we need a program to make that "as a Service"
20:14:41 <dhellmann> boris-42: it is as much about the community as about the code. the rally and qa teams have been unable to work out any way to work together so far.
20:14:58 <boris-42> dhellmann is this my fault?
20:15:09 <boris-42> dhellmann I tried since the begging
20:15:16 <boris-42> dhellmann they said my approach is bad..
20:15:19 <boris-42> dhellmann and so what know?
20:15:29 <dhellmann> we really don't have time to argue about rally's architecture again in this meeting
20:15:38 <boris-42> dhellmann it's not about architecture
20:15:44 <boris-42> dhellmann it's about not allowing different approach
20:15:55 <markmc> agree, we don't have time to resolve this here now
20:15:56 <boris-42> dhellmann which is NO competion => no quality
20:16:02 <markmc> there's clearly overlap that needs to be resolved
20:16:21 <markmc> AFAICT the tempest team have been quite patient and tenacious about trying to figure out a plan
20:16:27 <markmc> it doesn't appear to be happening
20:16:36 <boris-42> markmc I have a full roadmap
20:16:39 <boris-42> markmc about collabartion
20:16:41 <markmc> with that resolved, I could imagine revisiting the rally program question
20:16:42 <boris-42> markmc nobody replied
20:16:48 <russellb> boris-42: but there's clearly no consensus on it
20:16:55 <ttx> if no TC member wants to get behind the A option at this point, there is little point in continuing that discussion.
20:17:06 <boris-42> okay guys sorry for taking too much of your time
20:18:21 <ttx> #topic Other governance changes
20:18:38 <ttx> Final decision on Manila:
20:18:39 <markmc> boris-42, I think many of us are genuinely disappointed because we think what you're doing actually has a lot of promise
20:18:46 <dhellmann> markmc: +1
20:18:49 <markmc> boris-42, so, no waste of our time IMO
20:18:54 <ttx> #undo
20:18:55 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x287cc50>
20:19:15 <boris-42> markmc dhellmann someday I hope It will be clear why we chose this hard way..
20:19:15 * ttx waits for the discussion to complete
20:19:27 <boris-42> but seems it's not today =(
20:19:30 <russellb> agree with that sentiment, i think it still does have promise
20:19:41 <boris-42> russellb could you at least +1 infra job
20:19:43 <russellb> just would like to see some ongoing effort on integration and collaboration
20:19:46 <boris-42> russellb and at least try to use it?)
20:20:00 <ttx> and not being a program doesn't prevent it from being used or succeeding
20:20:21 <russellb> ttx: absolutely
20:20:22 <dhellmann> I certainly hope not. It sounds like there are already quite a few adopters.
20:20:23 <boris-42> ttx you should say that to mailing list=) cause people is afraid to use stuff from stackfroge=)
20:20:32 <russellb> boris-42: i just want to see the integration with the nova repo sorted out, that seems pretty reasonable to me
20:20:40 <russellb> enabling the job right now would do nothing
20:20:55 <boris-42> russellb so you can keep all benchmarks in nova repo
20:21:01 <russellb> but that's not really a topic for this meeting
20:21:01 <boris-42> russellb if that makes sense for you
20:21:07 <boris-42> russellb yep sure
20:21:54 <ttx> boris-42: we need to fix that (people afraid from using stackforge)
20:21:59 * markmcclain wonders why more folks don't realize that they're already running many quality components from stackforge
20:22:01 <boris-42> ttx ya deff
20:22:14 <boris-42> markmc and not only from stackforge*
20:22:28 <ttx> i'm not sure giving every good thing a stackforge an openstack program is the solution to that problem though
20:22:41 <ttx> some advocate the solution is actually the other way around
20:22:54 <rmk> Is the thinking here that by effectively not supporting Rally, people will go and contribute to other OpenStack projects?  Because that's not realistic at all.
20:23:04 <ttx> keeping some good components in stackforge to fight the "premature" reputation
20:23:24 <rmk> We run dozens of production clouds.  We're already using Rally on them.  I wouldn't even consider running Tempest on them for a second.
20:23:31 <zaneb> rmk: I agree that's not realistic, but I don't think that's the thinking
20:23:45 <rmk> I can't understand the rationale at all here.
20:23:52 <rmk> You want Rally to go away, why?
20:24:02 <russellb> nobody said that.
20:24:04 <rmk> There's no equivilent.  Tempest is not.
20:24:07 <zaneb> nobody wants it to go away
20:24:09 <dhellmann> rmk: we do not want rally to go away. we want rally to agree to work together with other programs
20:24:14 <russellb> we said we'd like to see a better collaboration plan
20:24:35 <ttx> no, we just don't consider Rally to be essential to our mission at this point
20:24:42 <russellb> not just a plan, but successful progress that everyone is happy with
20:24:52 <markmc> rmk, but ... that is great input
20:25:01 <russellb> i'm not speaking for everyone, but that was part of it anyway
20:25:03 <rmk> How is everyone else validating their production environments?
20:25:05 <boris-42> russellb ttx  hm but there is areldy collaboration btw
20:25:16 <boris-42> russellb ttx  with other programs..
20:25:23 <rmk> I'd really like to know which current OpenStack tool is being used for this.  Or maybe I am doing it wrong.
20:25:41 <russellb> rmk: i don't think not making it an official program precludes you from continuing?
20:25:43 <markmc> rmk, unlikely the TC has great insight into that, but we'd love to hear from more operators about the tools they use
20:25:52 <rmk> Alright, I'll take this offline into emai.
20:25:56 <russellb> curious what you perceive the importance of the program is?
20:26:13 <ttx> rmk: why are people thinking only openstack tools should be used to validate openstack tools
20:26:14 <boris-42> russellb I have actually
20:26:21 <boris-42> russellb e.g. I would like to know my scope
20:26:27 <boris-42> russellb and to have tempest scope
20:26:37 <boris-42> russellb so rally will work in own scope and me in my
20:26:40 <rmk> ttx: OpenStack is complex and specialized enough to need its own tool for validating/benchmarking itself.
20:26:44 <boris-42> russellb and everything just fine..
20:26:52 <boris-42> russellb and we can help each other
20:27:01 <boris-42> russellb whcihs is trying to do rally team already
20:27:04 <rmk> Anyway, I'm told I am derailing the meeting which I didn't intend to do.  So I can take this to another more appropriate forum.
20:27:37 <ttx> rmk: under the current definition, programs are to cover the integrated release, or some efforts that are considered essential to the production of the integrated release. Everything else can be in our ecosystem
20:28:20 <ttx> The current ruling just says that at this point, Rally is not targeted for the release itself, and is not essential to the PRODUCTION of that release
20:28:52 <ttx> If we change that definition to include stuff that is useful to SUPPOT that release in production envs, then it would be an easier sell
20:28:57 <ttx> SUPPORT*
20:29:18 <rmk> ttx: I would argue that having a toolset for validating what you've deployed, dedicated to that job, is vital for production.  Otherwise, you're inevitibly going to have dozens of different home-grown tools built to validate OpenStack environments.
20:29:58 <boris-42> ttx russellb  markmc btw what about asking more ops what they think?
20:29:58 <vishy> rmk: what about rally makes it better for “validation” then the tempest tests?
20:30:14 <rmk> vishy: Tempest doesn't sufficiently clean up after itself.  It barely does any cleanup.
20:30:14 <markmc> rmk, sharing your insights on why tempest doesn't suffice would be great - genuinely useful input from operators
20:30:35 <dhellmann> and it was easier to build a completely new tool than to work with the tempest team to fix that?
20:30:39 <markmc> rmk, likely the approach the TC and QA program would advocate is that those issues with tempest should be addressed
20:30:45 <markmc> dhellmann, right :)
20:30:47 <boris-42> dhellmann it's not the only reason...
20:30:54 <vishy> rmk: considering the tempest tests are the requirement for the trademark it seems like it should be fixed
20:31:02 <dhellmann> indeed
20:31:03 <boris-42> dhellmann there is so much and first of them is that they are using unit test framework
20:31:06 <rmk> If I were to run Tempest in our environments, I'd end up with stranded resources all over the place.  Tenants which aren't cleaned up, networks which are associated to deleted projects, etc.
20:31:33 <jeblair> yeah, so let's fix those
20:31:34 <rmk> I see Tempest as more of a functional testing framework for development than I do a production validation and benchmarking suite.
20:31:37 <jeblair> let's also fix the openstack bugs that cause those
20:31:47 <jeblair> because i see those things all the time in production :)
20:31:53 <markmcclain> jeblair: +1
20:31:54 <rmk> jeblair: Some of the openstack bugs in that case are architectural issues.  Major ones.
20:31:58 <rmk> I obviously agree with fixing those.
20:32:02 <jeblair> rmk: tell me about it :)
20:32:18 <ttx> OK, I think we need to move on. There is still no TC member ready to support option A, so we are far from being able to reconsider our position
20:32:41 <rmk> Thanks for hearing me.  I'll provide more thoughts on this outside the meeting.
20:32:57 <ttx> rmk: thanks for voicing your concerns
20:33:10 <ttx> #topic Other governance changes
20:33:21 <ttx> So, Manila...
20:33:25 <ttx> * Propose Shared File Systems program: (https://review.openstack.org/111149)
20:33:28 <ttx> * Propose Manila for incubation (https://review.openstack.org/113583)
20:33:43 <ttx> Both now have majority approvals, so unless someone complains I'll approve them now
20:33:50 <russellb> +1
20:34:02 <bswartz> thanks all for the +1 votes
20:34:39 <russellb> bswartz: thanks, just keep in mind the concerns we discussed last time, we'll be checking in on those for sure.  keep up the good work :)
20:34:47 <ttx> bswartz: congrats!
20:35:00 <markmcclain> ttx: should we assign TC mentor now or later?
20:35:06 <bswartz> yay
20:35:12 <ttx> markmcclain: we'll assign one on the Kilo TC
20:35:19 <markmcclain> ttx: makes sense
20:35:27 <ttx> * Renewing ATC exceptions for Horizon (https://review.openstack.org/115697)
20:35:38 <ttx> This is renewing extra-atc status for Horizon UX contributors
20:35:52 <jeblair> who are awesome
20:36:05 <ttx> It also has 7 YES, so unless someone screams now, I'll approve too
20:36:19 <markmc> +1 added
20:36:25 <markmc> surprising we aren't seeing more of these
20:36:30 * anteaya notes status update
20:36:32 <markmc> like, dozens more
20:36:53 <anteaya> it is up to the ptl to offer the extra-atcs for consideration
20:37:02 <dhellmann> markmc: is there anyone specific you have in mind?
20:37:06 <russellb> markmc: indeed, might be worth reminding everyone about
20:37:17 <annegentle> yeah how are people under the radar? can we tune our radar further?
20:37:18 <jeblair> yeah, i'm not above nudging people in case there's just been an oversight
20:37:19 <russellb> annegentle: maybe something for the blog update (reminding that special ATC consideration is available)
20:37:22 <markmc> yeah, I just thought of one in particular
20:37:24 <ttx> but but but, it's written in the charter!
20:37:26 <annegentle> (hm, tune, radar, not sure about that)
20:37:28 <markmc> will follow up, don't want to mention here
20:37:28 <ttx> everyone reads it, right
20:37:31 <annegentle> russellb: good one
20:37:39 <jeblair> i have it under my pillow
20:37:41 <dhellmann> ttx: every night before I go to bed
20:37:50 <annegentle> as a sleeping aid
20:38:05 <ttx> annegentle: remember you're up for the TC activity next blogpost
20:38:12 <annegentle> ayup, got a draft started
20:38:15 <anteaya> ttx you and I read the charter, and folks posting to the ml
20:38:17 <annegentle> publish this week I guess?
20:38:33 <annegentle> since we were awaiting manila?
20:38:33 <ttx> annegentle: sure, I think we have enough material now
20:38:37 <annegentle> ok
20:38:40 <ttx> * Add repository glance.store to glance (https://review.openstack.org/107585)
20:38:46 <ttx> This one is still blocked by markwash's standing -1
20:39:00 <ttx> hmm, no longer
20:39:15 <ttx> so I guess it's good to go too
20:39:20 <markmc> wow, you're like over 12 hours out of date there ttx
20:39:22 <vishy> btw I have an extra item for open discussion if there is time
20:39:24 <markmc> unprecedented
20:39:29 <annegentle> heh
20:39:35 * markmc teases
20:40:02 <ttx> I blame markwash's skipping the 1:1 sync today
20:40:12 <jeblair> nice redirect
20:40:13 <russellb> he did what?!
20:40:14 <dhellmann> nice delegation of responsibility there :-)
20:40:15 * russellb changes to -1
20:40:47 <ttx> jeblair: I'm 303.
20:41:05 <ttx> #topic Open discussion
20:41:14 <ttx> There will be a TC/Defcore call on Thursday at 1800 UTC
20:41:37 <zaneb> bring popcorn
20:41:43 <ttx> where TC members are invited to give their individual feedback to the proposed designated sections
20:42:16 <ttx> zehicle: a short word on that?
20:42:38 <russellb> zehicle_at_dell is who announced himself as present earlier, but that zehicle just dropped
20:42:40 <markmc> vishy, your item?
20:43:05 <ttx> The "Requirements for new projects added to existing programs" thread resulted in a governance review being posted, so we can continue the discussion there:
20:43:10 <ttx> https://review.openstack.org/#/c/116727/
20:43:37 <ttx> Since we have some time left, we could discuss the issues with programs, unless someone has something more urgent
20:43:57 <markmcclain> ttx: also have this which is related for new Neutron repo: https://review.openstack.org/#/c/117000/
20:44:03 <markmc> <vishy> btw I have an extra item for open discussion if there is time
20:44:07 * markmc intrigued :)
20:44:10 <ttx> ok, let's do that first, since you snatched a round number
20:44:11 <russellb> hehe
20:44:13 * russellb stares at vishy
20:44:17 <vishy> ah
20:44:32 <jeblair> markmcclain: i've been reading https://wiki.openstack.org/wiki/Network/Incubator and i have some concerns
20:44:33 <vishy> so this is a general topic I would like the tc to think about
20:44:49 <jeblair> markmcclain: maybe it should be a thread or meeting topic?
20:45:10 <markmcclain> jeblair: sure would also be happy to catch up with you offline too
20:45:12 <ttx> markmcclain: will be discussed next meeting, not aged enough
20:45:15 <vishy> http://www.trinimbus.com/wp-content/uploads/2014/04/image001.png
20:45:22 <vishy> i will just introduce it here
20:45:26 <markmcclain> ttx: right just wanted to make everyone aware it was there
20:45:35 <vishy> and maybe we can have a discussion about it in a futrue meeting
20:45:46 <vishy> so the above link shows the aws services
20:45:59 <ttx> some of them, at least
20:46:01 <vishy> in general I think openstack is directing too much energy in the wrong direction
20:46:11 <vishy> trying to make Everything-As-A-Service
20:46:24 <zehicle> ttx, sorry, back again
20:46:32 <vishy> IMO aaS model only works at large scale i.e. production clouds
20:46:56 <vishy> and I think a lot of our time would be better spent on focusing on how to build solid reusable components
20:47:01 <zaneb> vishy: I think you're indulging in a conservation-of-energy fallacy
20:47:10 <vishy> which is much more appropriate for small private clouds
20:47:17 <zehicle> #link https://etherpad.openstack.org/p/DefCoreLighthouse.6
20:47:35 <vishy> zaneb: our incentive structure is totally built on new aaS offerings
20:47:48 <annegentle> zaneb: I believe in abundance but I think vishy is pointing out the public/private motivations
20:47:50 <vishy> in other words the only way to get recognition in our community is to build an as a service
20:48:03 <vishy> which has lead to a number of problems which we have discussed recently
20:48:08 <vishy> 1) Marconi
20:48:10 <vishy> 2) Rally
20:48:12 <anteaya> vishy has a point after listening to jogo's assessment of mesos
20:48:33 <zaneb> vishy: I tend to agree, but I don't agree that all those people would e.g. go fix Neutron bugs if we had different incentives
20:48:34 <jogo> I think sdague summed it up well in: https://dague.net/2014/08/26/openstack-as-layers/
20:48:34 <ttx> vishy: so what's the right direction?
20:48:36 <vishy> we don’t have a decent way for people to collaborate on components
20:48:44 <sdague> vishy: so, interestingly enough, I wrote up something maybe similar this morning https://dague.net/2014/08/26/openstack-as-layers/
20:48:48 <vishy> zaneb, ttx: that is true
20:48:49 <markmc> vishy, the only way to get recognition is to start a new program? that's an odd statement
20:48:51 <sdague> oh, jogo beat me to it
20:49:01 <jogo> sdague: sorry for stealing your thunder
20:49:06 <vishy> but if we had a way for people to build a queuing component instead of a service
20:49:10 <vishy> maybe it would be more valuable
20:49:34 <russellb> oslo.messaging?
20:49:38 <russellb> i'm honestly not sure what you're saying
20:49:43 <zehicle> jogo
20:49:47 <markmc> yeah, what's a queueing component?
20:49:48 <ttx> vishy: i'm not sure I get the distinction between component and service
20:49:49 <russellb> is it just "we have too many projects" ?
20:49:55 <vishy> my layers are a little different
20:50:00 <markmc> does it have a REST API?
20:50:02 <vishy> but yeah that is roughly the idea
20:50:10 <vishy> markmc: that is the point it does not
20:50:14 <vishy> rest api is for a service
20:50:36 <vishy> i.e. people could collaborate on heat templates for example
20:50:47 <zaneb> vishy: so these components... you'd spin them up on Nova servers, right?
20:51:03 <vishy> i worry that people are essentially going to jump ship and go to the docker ecosystem for this part of the stack
20:51:10 <vishy> zaneb: potentially
20:51:16 <markmc> so, heat templates for provisioning VMs to run RabbitMQ is the preferable solution to those building applications in private clouds?
20:51:24 <markmc> (honestly trying to summarize)
20:51:27 <vishy> markmc: I believe so
20:51:41 <markmc> vishy, on what basis?
20:51:50 <markmc> vishy, that we can't build a good enough service?
20:51:51 <vishy> markmc: the point is that every private cloud company can’t have a person or people to manage an as a service offering
20:52:02 <vishy> markmc: not if we are building 100s of them
20:52:10 <zaneb> vishy: as I mentioned on the list, that scales at very coarse granularity
20:52:18 <markmc> ah, ok - so insufficient return on the investment in operating that service
20:52:20 <markmc> interesting
20:52:35 <vishy> markmc: this is just food for thought at the moment
20:52:45 <markmc> versus, it's fine to have each application operator essentially operate their own queue
20:52:52 * ttx likes the markmc direct translation
20:52:52 <vishy> i don’t really have answers but it occurs to me that we are all racing to match amazon’s services
20:52:54 <markmc> vishy, sure, I'm just trying to tease it out
20:52:57 <vishy> when that may not be the best option
20:52:57 <zaneb> OpenStack is not just for private clouds though. It's for private *and* public clouds, and moving workloads between them
20:53:11 <jeblair> yes, but i'm not sure it's okay to have each public operator _create_ their own queue
20:53:13 <russellb> noting that a VM running rabbit is far from the same thing as a simple queue rest API
20:53:19 <vishy> markmc: it boils down to who is responsible for mgmt of the component/service
20:53:39 <vishy> i would argue in a small deploy it is the application that is using the queue that needs to manage it
20:53:43 <vishy> i.e. their team
20:53:53 <markmc> vishy, if there's lots of apps needing queueing, hard to see that its not worthwhile operating infrastructure for them all to share
20:53:56 <ttx> I still think some key IaaS+ services (like DBaaS) still make sense, but could belong to Sean's layer 4 alright
20:53:57 <vishy> because Joe Company can’t have a queue service management team
20:54:13 <russellb> we obviously target large deploys too, though
20:54:23 <jogo> vishy: I take offense to that :)
20:54:27 <ttx> vishy: so you're advocating both for a smaller core and diversification at the workload level
20:54:27 <vishy> russellb: yes I think the services should still be done
20:54:34 <vishy> for hp rax etc.
20:54:35 <russellb> vishy: ah, ok
20:54:57 <jeblair> vishy: so is within the openstack project an appropriate place for public operators to collaborate on those services?
20:54:59 <vishy> but on the other hand if they only apply to a subset of the community I’m not sure that they need to be “official” openstack
20:55:09 <ttx> vishy: but should clearly be out of the ahem. core?
20:55:11 <annegentle> or integrated openstack?
20:55:13 <vishy> they could be openstack-adden-services
20:55:17 <vishy> *addon
20:55:43 <russellb> of course, the reason we brought them in is because wanted to encourage collaboration
20:55:46 <zaneb> for the record, I want queues so that *openstack* services (like Heat) can depend on them to interact with the user
20:55:51 <russellb> and an official program/project seemed like the way to do that
20:55:55 <russellb> i'd not want to lose sight of that goal
20:56:00 <jeblair> vishy: we didn't really get them to collaborate until they became official in some manner.  i think retaining that feature is useful
20:56:11 <russellb> jeblair: ++
20:56:15 <vishy> sure sure
20:56:20 <jeblair> though i'm otherwise very inclined to agree that running a queue service is not something every (private) cloud needs to do :)
20:56:23 <vishy> I don’t think a wholehearted change is required
20:56:43 <vishy> but encouraging collaboration around components and not doing everything as a service could be valuable too
20:56:59 <sdague> jeblair: so I think that was true a couple years ago. But I actually think we're seeing tons of collaboration now outside of just "official" openstack projects
20:57:02 <vishy> so mostly I just wanted to bring it up for people to think about
20:57:44 <ttx> vishy: I'm with you that it shoul dbe limited to building blocks, like databases or queues. It took me a while to consider MapReduce (Sahara) a basic building block tbh
20:58:02 <ttx> I think we were crossing the line there
20:58:17 <anteaya> I think it is good to have the conversation
20:58:21 <jogo> I see this as the: 'big tent/big ecosystem' debate
20:58:31 <zaneb> sdague: IMO incubation is the biggest lever we have to convince people to develop stuff as open source rather than proprietary
20:58:32 <ttx> jogo: with a vishy twist on it though
20:58:46 <ttx> It's definitely our next big debate
20:58:52 <sdague> zaneb: honestly, I think the playing field has changed
20:58:55 <jeblair> ttx: it was also our last big debate
20:59:06 <sdague> with docker, cloudfoundry, mesos, kubernertes
20:59:08 <anteaya> zaneb: sometimes forcing people to develop open source can create its own dragons
20:59:24 <ttx> jeblair: we did have a few debates about other things, didn't we?
20:59:41 <markmcclain> zaneb: that's a bit concerning if we have to classify something for incubation to get folks to develop in the open
21:00:01 <ttx> ooook, I think we can continue that discussion on other forums
21:00:06 <annegentle> zaneb: but that statement just sounds like we're trying to get them to use our system which is as lock-in-ish as proprietary
21:00:11 <ttx> but yes, there is a debate about the size of the tent
21:00:33 <ttx> our time for today is up
21:00:38 <ttx> thanks vishy!
21:00:40 <david-lyle> but they're using OpenStack too, for a commitment of support
21:00:46 <vishy> np
21:00:48 <ttx> #endmeeting