> On 11 Mar 2017, at 08:19, Clint Byrum <cl...@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 <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. >
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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ 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
