Open Stack

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.