Open Stack

Hi Matt,

I mostly agree with your post, but from other side we are not living in an
ideal world, and just doing the first steps on a long road. OpenStack is a
very young platform, the wider ecosystem is forming, and a lot of things
for me or you seems to be evident, not even known for others. I think the
devops model / CI / Community is the real driver of the components, and
core / incubated projects are using those technologies and policies.
Related or "satellite" projects are more diverse, even from language
aspect, and some of them not so tightly coupled to OpenStack API-s as
others. This type of categorization works currently, and "satellite" is an
entrance to incubated or even core status, if the project owners have such
intentions. From my perspective refstack is  good initiative to provide a
common understanding and acceptance of basic principles, and forcing the
interoperability between stacks.

I feel we need to give time to forming policies, and common practices, and
of course need try to find a good consensus among the lot of interests
involved in the community, supporter companies and organizations.

I din't want to stir up too much emotions in this topic, and sorry for
that, if this was the outcome.

M.


2013/5/3 Matt Joyce <matt.joyce at cloudscaling.com>

> 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 at gmail.com> 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 at gmail.com>
>>
>>>
>>> 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 at gmail.com> 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 at openstack.org>
>>>>
>>>>> 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 at lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130504/b32e1fd1/attachment.html>