Open Stack

I will be very interested in this session as well.
Since this is a very problem my team is facing in my company's effort to
develop the next generation datacenter operation platform. We realized
leveraging and automating legacy CI (configuration item) is not a trivial
problem to solve.

will be glad to hear and share necessary information. :)

On 2015년 5월 8일 (금) 01:55 Clint Byrum <clint at fewbar.com> wrote:

> I added information about Assimilation Monitoring to the etherpad. It's
> not strictly a CMDB, but it can be used for what CMDB's often are used
> for, and is worth noting in the discussion.
>
> Excerpts from Shane Gibson's message of 2015-05-07 08:27:01 -0700:
> >
> > At Symantec we use YiDB for CMDB data - however - we find it to be
> lacking as it is NOT a GraphDB, but emulates GraphDB like behavior.  In
> addition, it requires MongoDB as a backing store - and that will eventually
> corrupt and lose your data...often silently (please direct your flame mail
> to /dev/null .... thank you).   We also have a project (the lead author)
> which is a complete rewrite of the Yahoo "libCrange" tool; called Range++.
> >
> > Range++ is a full GraphDB solution designed specifically to act as a CMS
> (config mgmt service - I dislike the term "cmdb").  In addition it can
> easily also support ENC (external node cllassifier) duties as well.
> Range++ is designed to allow you to describe your topology and environment
> with the idea of "environments" and with "clusters" and "clusters within
> clusters".  Range++ is in operation at LinkedIN, Yahoo, and Mozilla.
> Range++ is also integrated within the Saltstack tool for targetting via the
> "-R" (range cluster) syntax - as it's completely "libCrange" compatible.
> Conceptually - you can "describe" your environments and physical assets,
> then describe your application via a configuration file (say YAML), then
> via your config mgmt tooling, prescriptively build that "cluster" by
> populating your CM tools metadata, and assigning resources from
> physical/virtual assets.
> >
> > Our existing deployment (bare metal) framework dynamically auto
> discovers assets as they come online, and populates our CMS with the asset
> data and information.
> >
> > Note that Range++ is in active use and development, and is located on
> GITHUB:  https://github.com/jbeverly/rangexx
> >
> > I have updated the Etherpad with this info.
> >
> > ~~shane
> >
> >
> >
> > On Wed, May 6, 2015 at 10:36 PM, Allamaraju, Subbu <subbu at subbu.org
> <mailto:subbu at subbu.org>> wrote:
> > Hi Tom,
> >
> > Thanks for adding this slot.
> >
> > We do have a fairly full-fledged CMDB in house that keeps tracks of all
> our infra and apps. Unfortunately none of that team is going to be able to
> make it to the Summit, but I’m trying to have someone do a demo remotely
> and participate on EtherPad.
> >
> > Subbu
> >
> > > On May 6, 2015, at 3:04 AM, Tom Fifield <tom at openstack.org<mailto:
> tom at openstack.org>> wrote:
> > >
> > > Hi,
> > >
> > > Is anyone interested enough in CMDB to run a working session on it at
> > > the design summit?
> > >
> > >
> https://libertydesignsummit.sched.org/event/553947ceb7c1c223fa689da188abb9a9
> > >
> > > It was suggested on the planning etherpad, but so far we've found
> no-one
> > > interested in running it.
> > >
> > >
> > > Regards,
> > >
> > >
> > > Tom
> > >
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150511/ee76deff/attachment.html>