Open Stack

> On 24 May 2016, at 2:04 PM, Clint Byrum <clint at fewbar.com> wrote:
> 
> Excerpts from Geoff O'Callaghan's message of 2016-05-24 10:59:13 +1000:
>> Surely openstack is defined by it’s capabilities and interfaces rather than it’s internals.  Given the simplistic view that openstack is a collection of micro services connected by well defined api’s does it really matter what code is used inside that micro service (or macro service )?   If there is a community willing to bring and support code in language ‘x’,  isn’t that better than worrying about the off chance of existing developers wishing to move projects and not knowing the target language?    Is there a fear that we’ll end up with a fork of nova (or others) written in rust ?
>> If we’re not open to evolving then we’ll die.
>> 
>> Just throwing in a different perspective.
> 
> Thanks Geoff. Your perspective is one that has been considered many
> times. That is an engineering perspective though, and ignores the people
> and businesses that are the users of OpenStack. We don't just shove the
> code out the door and say "good luck!”.

Hey Clint,  That is exactly what I wasn’t saying.   Businesses and people out there want the platform to have the features they want and work.  They could care less about what it’s written in.   You tend to care when it doesn’t work and / or it doesn’t have the features you want.   So I can understand for operators now they have a vested interest in making sure they can debug what is given to them as we don’t meet Geoff’s rule # 1 - the code must work and it must do what I want.

I also never said, ship the source code and say ‘good luck’.   What I did imply  was, due to a relaxing of coding platform requirements we might be able to deliver a function at this performance point that  we may not have been able to do otherwise.   We should always provide support and the code,  but as to what language it’s written it i’m personally not fussed and I have to deal with a variety of languages already so maybe that’s why I don’t see it as a big problem.

I understand there will be integration challenges and I agree with cohesiveness being a good thing, but I also believe we must deliver value more than cohesiveness.   The value is what operators want,  the cohesiveness is what the developers may or may not want.

> 
> So, each new aspect of the internals that the people and business must
> evaluate is another hurdle to adoption at some level. If OpenStack is
> the fastest open source cloud platform ever, but only gets adopted by
> the 5 largest cloud users on the planet, and smaller organizations are
> forced to invest their money in closed source appliance based clouds,
> then we'll all suffer, as neither of those options will stand a chance
> against the large scale efforts of the established players like Amazon,
> Google, and Microsoft.
> 
> Likewise, if OpenStack is adopted by the bulk of small/medium businesses
> needing clouds, but nobody can run it at scale, we will also be crushed
> as users develop elastic workloads that need to be moved onto a large
> scale cloud.
> 
> And if there are simply two, one for big clouds, and one for small,
> they'll never be fully compatible. It will be like POSIX... moderately
> useful for a limited set of applications, but most things will have to
> be optimized for each different implementation, wasting everyone's time
> porting when they should be developing.
> 
> So, while this doesn't mean we should just force everything onto Python,
> it does mean that we should remain as cohesive as we can when making
> choices like this. So the question "What is OpenStack" needs to be
> asked, so we can evaluate what should be kept close together, and what
> might be better off as an independent component.

I thought that had already been asked and answered.  The question becomes :- is what openstack is written in a core part of openstack?

Thanks for the reply.
Geoff


> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev