On 18 August 2014 09:32, Clint Byrum <cl...@fewbar.com> wrote: I can see your perspective but I don't think its internally consistent...
> Here's why folk are questioning Ceilometer: > > Nova is a set of tools to abstract virtualization implementations. With a big chunk of local things - local image storage (now in glance), scheduling, rebalancing, ACLs and quotas. Other implementations that abstract over VM's at various layers already existed when Nova started - some bad ( some very bad!) and others actually quite ok. > Neutron is a set of tools to abstract SDN/NFV implementations. And implements a DHCP service, DNS service, overlay networking : its much more than an abstraction-over-other-implementations. > Cinder is a set of tools to abstract block-device implementations. > Trove is a set of tools to simplify consumption of existing databases. > Sahara is a set of tools to simplify Hadoop consumption. > Swift is a feature-complete implementation of object storage, none of > which existed when it was started. Swift was started in 2009; Eucalyptus goes back to 2007, with Walrus part of that - I haven't checked precise dates, but I'm pretty sure that it existed and was usable by the start of 2009. There may well be other object storage implementations too - I simply haven't checked. > Keystone supports all of the above, unifying their auth. And implementing an IdP (which I know they want to stop doing ;)). And in fact lots of OpenStack projects, for various reasons support *not* using Keystone (something that bugs me, but thats a different discussion). > Horizon supports all of the above, unifying their GUI. > > Ceilometer is a complete implementation of data collection and alerting. > There is no shortage of implementations that exist already. > > I'm also core on two projects that are getting some push back these > days: > > Heat is a complete implementation of orchestration. There are at least a > few of these already in existence, though not as many as their are data > collection and alerting systems. > > TripleO is an attempt to deploy OpenStack using tools that OpenStack > provides. There are already quite a few other tools that _can_ deploy > OpenStack, so it stands to reason that people will question why we > don't just use those. It is my hope we'll push more into the "unifying > the implementations" space and withdraw a bit from the "implementing > stuff" space. > > So, you see, people are happy to unify around a single abstraction, but > not so much around a brand new implementation of things that already > exist. If the other examples we had were a lot purer, this explanation would make sense. I think there's more to it than that though :). What exactly, I don't know, but its just too easy an answer, and one that doesn't stand up to non-trivial examination :(. I'd like to see more unification of implementations in TripleO - but I still believe our basic principle of using OpenStack technologies that already exist in preference to third party ones is still sound, and offers substantial dogfood and virtuous circle benefits. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
