[openstack-dev] [tc][appcat] The future of the App Catalog
Tim.Bell at cern.ch
Sun Mar 12 14:41:33 UTC 2017
> 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
>>>> 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
>> 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.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev