Open Stack

> On 11 Mar 2017, at 08:19, Clint Byrum <clint at fewbar.com> wrote:
> 
> Excerpts from Christopher Aedo's message of 2017-03-10 19:30:18 -0800:
>> On Fri, Mar 10, 2017 at 6:20 PM, Clint Byrum <clint at fewbar.com> wrote:
>>> Excerpts from Fox, Kevin M's message of 2017-03-10 23:45:06 +0000:
>>>> So, this is the kind of thinking I'm talking about... OpenStack today is
>>>> more then just IaaS in the tent. Trove (DBaaS), Sahara (Hadoop,Spark,etc
>>>> aaS), Zaqar (Messaging aaS) and many more services. But they seem to be
>>>> treated as second class citizens, as they are not "IaaS".
>>>> 
>>> 
>>> It's not that they're second class citizens. It's that their community
>>> is smaller by count of users, operators, and developers. This should not
>>> come as a surprise, because the lowest common denominator in any user
>>> base will always receive more attention.
>>> 
>>>>> Why should it strive to be anything except an excellent building block
>>>> for other technologies?
>>>> 
>>>> You misinterpret my statement. I'm in full agreement with you. The
>>>> above services should be excellent building blocks too, but are suffering
>>>> from lack of support from the IaaS layer. They deserve the ability to
>>>> be excellent too, but need support/vision from the greater community
>>>> that hasn't been forthcoming.
>>>> 
>>> 
>>> You say it like there's some over arching plan to suppress parts of the
>>> community and there's a pack of disgruntled developers who just can't
>>> seem to get OpenStack to work for Trove/Sahara/AppCatalog/etc.
>>> 
>>> We all have different reasons for contributing in the way we do.  Clearly,
>>> not as many people contribute to the Trove story as do the pure VM-on-nova
>>> story.
>>> 
>>>> I agree with you, we should embrace the container folks and not treat
>>>> them as separate. I think thats critical if we want to allow things
>>>> like Sahara or Trove to really fulfil their potential. This is the path
>>>> towards being an OpenSource AWS competitor, not just for being able to
>>>> request vm's in a cloudy way.
>>>> 
>>>> I think that looks something like:
>>>> OpenStack Advanced Service (trove, sahara, etc) -> Kubernetes ->
>>>> Nova VM or Ironic Bare Metal.
>>>> 
>>> 
>>> That's a great idea. However, AFAICT, Nova is _not_ standing in Trove,
>>> Sahara, or anyone else's way from doing this. Seriously, try it. I'm sure
>>> it will work.  And in so doing, you will undoubtedly run into friction
>>> from the APIs. But unless you can describe that _now_, you have to go try
>>> it and tell us what broke first. And then you can likely submit feature
>>> work to nova/neutron/cinder to make it better. I don't see anything in
>>> the current trajectory of OpenStack that makes this hard. Why not just do
>>> it? The way you ask, it's like you have a team of developers just sitting
>>> around shaving yaks waiting for an important OpenStack development task.
>>> 
>>> The real question is why aren't Murano, Trove and Sahara in most current
>>> deployments? My guess is that it's because most of our current users
>>> don't feel they need it. Until they do, Trove and Sahara will not be
>>> priorities. If you want them to be priorities _pay somebody to make them
>>> a priority_.
>> 
>> This particular point really caught my attention.  You imply that
>> these additional services are not widely deployed because _users_
>> don't want them.  The fact is most users are completely unaware of
>> them because these services require the operator of the cloud to
>> support them.  In fact they often require the operator of the cloud to
>> support them from the initial deployment, as these services (and
>> *most* OpenStack services) are frighteningly difficult to add to an
>> already deployed cloud without downtime and high risk of associated
>> issues.
>> 
>> I think it's unfair to claim these services are unpopular because
>> users aren't asking for them when it's likely users aren't even aware
>> of them (do OVH, Vexxhost, Dreamhost, Raskspace or others provide a
>> user-facing list of potential OpenStack services with a voting option?
>> Not that I've ever seen!)
>> 
>> I bring this up to point out how much more popular ALL of these
>> services would be if the _users_ were able to enable them without
>> requiring operator intervention and support.
>> 
>> Based on our current architecture, it's nearly impossible for a new
>> project to be deployed on a cloud without cloud-level admin
>> privileges.  Additionally almost none of the projects could even work
>> this way (with Rally being a notable exception).  I guess I'm kicking
>> this dead horse because for a long time I've argued we need to back
>> away from the tightly coupled nature of all the projects, but
>> (speaking of horses) it seems that horse is already out of the barn.
>> (I really wish I could work in one more proverb dealing with horses
>> but it's getting late on a Friday so I'll stop now.)
>> 
> 
> I see your point, and believe it is valid.
> 
> However, we do have something like a voting system in the market
> economy. The users may not say "I want Trove". But they may very well say
> "I don't buy your cloud because it doesn't have a robust DBaaS service."
> 
> One would expect that whether private cloud or public cloud, the operators
> would seek to deploy Trove if it made economic sense.
> 
> But what I think most users in this situation are doing is just layering
> things like databases on top of VMs/Baremetals/etc. Same for the other
> bits that are controvertial in this thread.
> 

There is also a critical mass problem with respect to operator deployments where I do not see an easy solution.

Deploying new projects is great to support new use cases but withdrawing them later (if the project is not sustainable) is a very difficult discussion with the end users who rely on the functions being offered.

Thus, for an private cloud operator, it is a complex balance between deploying a new project or showing users how to do it with tools like Puppet. This does not help the OpenStack project to expand and thus adoption remains limited.

I assume the distributions have similar reflections and are also therefore cautious in what to include.

Tim

> __________________________________________________________________________
> 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