<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 5, 2013 at 2:54 PM, Gabriel Hurley <span dir="ltr"><<a href="mailto:Gabriel.Hurley@nebula.com" target="_blank">Gabriel.Hurley@nebula.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm glad to hear other folks are less concerned by these issues than I am.</blockquote><div> </div><div class="gmail_default" style="font-family:'courier new',monospace">
I have concerns (and have voiced them) but I'm not sure I have a better answer than the path we're on. I'm also not sure it's the right approach. I do have concerns that proliferation can result in a watered down version of OpenStack. I also think that things will and do suffer in terms of quality, manageability and the desire that some have for compat across public clouds.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">I know there are arguments that more projects/programs will help compat, but I disagree. I think more projects/programs offers more opportunities for cusomization, but that's a completely different topic. :)</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I do have to say that I didn't hear anyone mention the IaaS+ discussion during the Moniker discussion, and the question of "why are we considering this project" *was* raised. Personally I too prefer to draw the line at "fabric services that I as a user/developer would find useful", but we still haven't had any strong definition around that as a project or committee.<br>
</blockquote><div><br></div><div class="gmail_default" style="font-family:'courier new',monospace">It's a very unpopular view it seems but personally I still like the IaaS model as being a core component.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As to the Program proliferation, it just struck me as "Queue" being an exceptionally specific program compared to many of the existing ones and wondered if we'd accomplished anything by changing from Projects to Programs. </blockquote>
<div><br></div><div class="gmail_default" style="font-family:'courier new',monospace">Yeah, I agree with you here. I think I need to go back and study what we were planning there and what it gets us.</div><div class="gmail_default" style="font-family:'courier new',monospace">
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">One of the goals of that was to try and slow the explosive increase in management overhead, right? If no one else cares, I don't either. I was on the side of "more projects isn't an issue" when that debate happened before; I just wanted to raise the issue for discussion because previously folks seemed to care a lot.<br>
</blockquote><div><br></div><div class="gmail_default" style="font-family:'courier new',monospace">I was on the other side of the "more" projects debate and I still think it's a concern. At the same time I don't pretend to believe that myself or even the TC in general should be able to make decisions about what the community works on or doesn't. One thing that I think would be useful however is to come up with some more stringent and well defined criteria for graduation from incubation. This would include things like diversity and consistency in contributors.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
- Gabriel<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> -----Original Message-----<br>
> From: Monty Taylor [mailto:<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>]<br>
> Sent: Thursday, September 05, 2013 9:42 AM<br>
> To: <a href="mailto:openstack-tc@lists.openstack.org">openstack-tc@lists.openstack.org</a><br>
> Subject: Re: [openstack-tc] Savanna incubation request<br>
><br>
><br>
><br>
> On 09/05/2013 04:57 AM, Thierry Carrez wrote:<br>
> > Gabriel Hurley wrote:<br>
> >> I think we have two fundamental questions to answer:<br>
> >><br>
> >> 1. Is "Amazon has it, so OpenStack should too" sufficient to grant<br>
> incubation and ultimately integration (provided all technical bars are met)?<br>
> ><br>
> > Personally I don't really consider the "does Amazon have it" angle,<br>
> > but rather "is it a critical component of an IaaS+ solution". I define<br>
> > "IaaS+" as pure infrastructure as a service + slightly more advanced<br>
> > services that act as basic building blocks for application builders<br>
> > (things like queues or databases).<br>
> ><br>
> > Now Amazon has most components of a decent IaaS+ solution, so there is<br>
> > definitely some overlap.<br>
><br>
> I agree with Thierry. I don't consider Amazon at all. I actually, for the record,<br>
> don't care about IaaS or IaaS+ or any of those acronyms.<br>
><br>
> What I think about is myself. As a person who runs a very large distributed<br>
> application across two different public clouds, what things do I want those<br>
> clouds to have, and what things do I want those clouds to be compatible on.<br>
><br>
> As a person who runs a very large distributed application across two different<br>
> public clouds, I can tell you that the answer is NEVER "I want them to be<br>
> compatible less" or "to have less shared features". In EVERY case where<br>
> Rackspace and HP diverge because some narcissistic product manager thinks<br>
> too highly of themselves, it causes me pain, and makes whatever the feature<br>
> is effectively unusable.<br>
><br>
> So when I think about what OpenStack should be offering, I think about that<br>
> things would make it easier and more robust to run OpenStack's Infra<br>
> systems across multiple clouds.<br>
><br>
> The main arguments I hear on the other side are:<br>
><br>
> - What about differentiation?<br>
> - What about ability to innovate?<br>
><br>
> To those I answer:<br>
><br>
> - differentiation:<br>
><br>
> It's there, even when they are compatible. HP's cloud is faster.<br>
> Rackspace's cloud has servers that behave like real servers. To that end, we<br>
> run most of the build farm in HP and we run most of our long-lived things in<br>
> Rackspace - but we don't have to use divergent code to do so.<br>
><br>
> - innovation<br>
><br>
> OpenStack is ludicrously open. Come innovate here. I do not care, will not<br>
> care, should not care about your ability to go innovate in a corner without<br>
> participating.<br>
><br>
> >> 2. If the answer to #1 is "yes" then should we grant each one a program<br>
> like we're looking at with Marconi (making the proliferation based on<br>
> Projects that we were trying to avoid happen all over again), or should there<br>
> be a program for higher-level services that provide AWS parity (not the IaaS<br>
> stuff) that things like Marconi, Savanna, etc. go under as projects within that<br>
> program.<br>
> ><br>
> > Programs are all about teams. People working together toward a common<br>
> > goal (their mission statement). They elect a PTL who is responsible<br>
> > for the whole program. I don't really want to artificially group<br>
> > separate teams under an "umbrella" just because they may belong in the<br>
> > same category of projects. What would be the benefit of doing that ? I<br>
> > can certainly see a lot of drawbacks, like creating groups with no<br>
> > unity and competing subgroups.<br>
> ><br>
> > Why not grant each separate team its own program ?<br>
><br>
> I think this should be a case-by-case judgement, not a policy. There's a<br>
> reason we have an elected body here (us) Sometimes it makes sense to<br>
> lump together (I see no reason for tuskar and tripleo to be part of separate<br>
> programs, for instance, they both want to work on openstack<br>
> deployment) sometimes it does not (savanna, marconi and trove are all<br>
> higher-level, but all also quite different)<br>
><br>
> That said - I could imagine the opposite arguments for both - tuskar and<br>
> tripleo have different teams and slightly different approaches, and savanna<br>
> could really be using the trove engine and approach on the impl, so could<br>
> really be plugins or extra features to trove by another way of looking at<br>
> things.<br>
><br>
> So I'd think we'd have an interesting debate on either and it might change<br>
> depending on arguments people make.<br>
><br>
> _______________________________________________<br>
> OpenStack-TC mailing list<br>
> <a href="mailto:OpenStack-TC@lists.openstack.org">OpenStack-TC@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc</a><br>
<br>
_______________________________________________<br>
OpenStack-TC mailing list<br>
<a href="mailto:OpenStack-TC@lists.openstack.org">OpenStack-TC@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc</a><br>
</div></div></blockquote></div><br></div></div>