openstack team mailing list archive

[Gabriel Hurley <Gabriel.Hurley@xxxxxxxxxx>]

+1. And I'd add that we need to do everything in our collective power to treat OpenStack as a coherent whole, not as a loosely federated set of projects that are released together.

We are still a young community, but doing things to build supporting tools, expose commonalities and overlaps, and further healthy competition are all tremendously valuable. Don't force the solutions, build the ecosystem in which projects can compete. Tend the garden so the plants can thrive.

The line between fragmentation and healthy competition lies mostly in the bounds set by the community and the leadership. Let's work on that.


-          Gabriel

From: Openstack [mailto:openstack-bounces+gabriel.hurley=nebula.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Matt Joyce
Sent: Friday, May 03, 2013 2:25 PM
To: Marton Kiss
Cc: Michael Bright; Thierry Carrez; <openstack@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Openstack] Related Projects

This is going to come off as a bit of a rant.  Pardon me.  I feel it needs saying.
There's a few ways to look at what OpenStack is.  It's an IaaS solution.  It's a cloud solution.  But at it's heart, core to the design principles of OpenStack development ideology it is a collection of tools designed specifically to support elastic design patterns.
The reason I bring this up is because of some thinking I've been doing about the future of OpenStack.  Where it's place  is in the world.  Where it's place will be in the world.  I've found that despite the crass nature of the puppies vs cattle explanation of elastic design, it really does get the most important selling point home to potential customers, and engineers who don't do ec2 already.  And that point is that OpenStack exists to further a design pattern.  It's not about clouds, or IaaS.  It's about a design pattern.  The pattern of horizontal scalability.  The pattern of ephemeral resources.  The pattern of share nothing.  These core design ethics allow us to build software in a fashion that makes it consumable, scalable, and fault tolerant beyond any existing pattern by far.  It makes development efforts become commodities that can be openly traded on a market free or otherwise.
We need to stop thinking of OpenStack as just an IaaS solution.  Or just a cloud.  It's a development platform.  It's a way of building software well.  Once we do that, we can look to the past and see where we need to go.  We want OpenStack to enjoy the some level of success as Java, or python as a collaborative development environment.  We want kids in colleges to be training to write the next 50 years of applications in our environment, following our design patterns.  But to do that, and to do it well, we'll need to solve a few things.

This thread points to a growing problem in our community.  One that was a primary focus of discussion in the last summit.  OpenStack deployments are growing up and they are growing apart.  We're building things too differently.  The reason we employed PEP-8 gate tests, and the reason python works as a language in general is in part because when you give developers too many options, you end up losing a common language, or methodology that allows us to easily come up to speed on each others work.  It makes collaboration hard.  Now, not to start a language war, but I love perl.  Nothing rips apart text like perl.  Nothing.  But, at the same time, I know that if I write perl code, it's going to be a pain in the ass for someone to come back to that code later and maintain it.  Python on the other hand, especially with PEP-8, restricts a developers aesthetic options.  It forces us to follow a common grammar.
My point here, is that when you ask people what languages work with a 100+ active developers working on the same project, you get responses like Java, C#, maybe python.  And you say, well why?  And one of the responses is that Java and C# have an extensive common library.  It allows developers to share a common method set.  We've already begun the task of creating oslo to solve part of that problem for us in development.  But in deployment, we're woefully behind the curve.  We want to support diversity in the market eco system, but we also want to ensure that an OpenStack environment is adherent to some sort of baseline or flavor set.  That is why folks have begun pushing things like refstack.
I look at this thread, and what I see is a further need to unify solutions into a community supported method set that trumps outliers and one offs.  A common set of tools.  A common library of solutions.  If OpenStack is to be the development environment of the next 75 years or more, we need to build this.  It's one part of the many things we need to and are doing.  But it's an important part.  I think we can't just say, this isn't part of openstack, or this is outside of scope.  It's part of the development environment that OpenStack is the runtime environment for ( forgive the analogy ).
Anyways,
    That's my rant.
-Matt

On Fri, May 3, 2013 at 1:27 PM, Marton Kiss <marton.kiss@xxxxxxxxx<mailto:marton.kiss@xxxxxxxxx>> wrote:
Michael, thanks for the feedback, I record it as a feature request as a different view of projects.

M.

2013/5/3 Michael Bright <mjbrightfr@xxxxxxxxx<mailto:mjbrightfr@xxxxxxxxx>>

I just discovered these different sites thanks to this mail thread.

I guess different people are looking for different types of info, judging by these exchanges.

Whatever you decide as to where the list is hosted, I just wanted to say that I appreciated the simple *but* informative format
of the related projects page https://wiki.openstack.org/wiki/RelatedProjects rather than the more dashboard like interfaces.

My 2 cts,
Mike.



On 3 May 2013 22:07, Marton Kiss <marton.kiss@xxxxxxxxx<mailto:marton.kiss@xxxxxxxxx>> wrote:
It is a good idea, it was the original plan with this project. If Harvard also like to use it we can refactor the current stackmeat distro into a common project distribution (like openatrium or openpublish) and OpenStack and Harvard distribution can inherit the commonly maintained codebase.

M.

2013/5/3 Stefano Maffulli <stefano@xxxxxxxxxxxxx<mailto:stefano@xxxxxxxxxxxxx>>
On Fri 03 May 2013 12:15:26 PM PDT, Marton Kiss wrote:
I'm taking care of stackmeat, and some feature upgrade is in the
queue. If somebody like to join and help in content management, any
help is welcome from my part.

I would vote to include stackmeat inside the OpenStack infrastructure so that others can contribute to it and the site can go on.

What do you guys think?

/stef

--
Ask and answer questions on https://ask.openstack.org


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp