Re: Is Puppet similar to Capistrano?

On 10/8/07, Adam Jacob <adam@xxxxxxxxxxxxxxxx> wrote:
> On 10/8/07, Brandorr <brandorr@xxxxxxxxxxxxxxx> wrote:
> > I discovered Capistrano while I was trying to figure out what I
> > wanted. See attached notes.
> > http://www.genunix.org/wiki/index.php/GNOSIS/Kraken
> >
> > Puppet seems promising.
>
> I just read your wiki entry.  You should consider contributing to
> Factor, for your system inventory needs.  Puppet is a significant part
> of an open source data center management tool, and is a much better
> integration choice than cfengine (imnsho.)

Factor? (A quick Google search did not help).

> Having written two or three systems like the one you are describing in
> the past (including iClassify today) I suggest you do a few things:
>
> 1. You need to keep the schema flexible, since you never know what
> sort of thing people need to track.  If you find yourself writing a
> new class for each entity you need to track in your datacenter
> (server, router, switch, rack, pdu, et al) then you're off track.

What about new subclasses, that can be dynamically defined by the
user? Can you talk about this more?

> 2. You need to allow for the expression of relationships between
> entities.  For example, a server is in a rack.  This is best done
> fairly loosely.  iClassify doesn't do this at all right now, although
> I have some ideas about how it might.

I have thought about this. Any idea which Object it will be a property
of? IE: Is the server a property of the rack, or is the rack location,
a property of the server? Or is it something different altogether?
(Maybe, both)

> 3. Use a full text search engine like Xapian, Solr, Ferret or Lucene.
> One of these models used Xapian entirely, and had no relational
> database engine at all.  Thus far, it remains my favorite of my
> implementations of this problem for flexibility. In the end, you can't
> beat saying "tags:database AND mysql-master:true", or
> "ipaddress:[192.168.1.0-192.168.10.0]".

I think I'd want both.. (search index for speed, actual data in database.)

> 4. As much as possible, entities need to be responsible for reporting
> in to the management system. They should push data to it, it should
> not be polling the entities for updates. (Where possible.  Sometimes,
> you have to poll.)

Yes, I agree, but for the initial implementation, I thought it would
be easier to implement a polling based systems. (And we are going to
need it anyway for initialization).

> I could go on. :)
>
> There is lots of work going on in this space right now in the puppet
> community at large, and if would be excellent if it would include the
> work you are already planning for.

No need to reinvent the wheel. If there is a system close enough to
what I want, then contributing to it, seems the wiser choice.

> Regards,
> Adam
> --
> HJK Solutions - We Launch Startups - http://www.hjksolutions.com
> Adam Jacob, Senior Partner
> T: (206) 508-4759 E: adam@xxxxxxxxxxxxxxxx
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@xxxxxxxxxxx
> https://mail.madstop.com/mailman/listinfo/puppet-users
>


-- 
- Brian Gupta

http://opensolaris.org/os/project/nycosug/