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 <cl...@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. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev