Greg DeKoenigsberg wrote:
A big potential opportunity for func.
--g
I had wondered what happened with the OMC lists -- after a period of
inactivity I unsubscribed. Is there still a list? They tend to work
better than forums as lots of us are on a ton of lists ...
Anyhow, glad to see the topic brought up again. Sounds neat.
To address some of the points --- Func is of course GPLv2+ and is a very
simple (both in LOC and complexity) agent. The primary goals here being
that it needed to be secure, easy to extend from external packages, and
very easy to audit everything that goes on on both sides of the
transactions. We like to shun big software wherever it can be avoided
and aim for things to make admins and developers productive.
Another nice point about Func is that it can be used to distribute
certificates for any application, even if that application is not going
to use Func itself for XMLRPC. Another nice point is that it can be used
from a variety
of languages -- work on a Perl module to access Func over XMLRPC has
already been done. For something like the OMC effort, an application may
not want to use Func for transport, but it still needs a way to
provision trusted certs to managed nodes -- Func's certmaster seems like
a very good way to do this. So there should be lots of options.
If an app does want to use the API directly -- take a look at something
like Func-inventory to see what is possible. Func-inventory uses any
func module with an "inventory()" method to quickly build an inventory
of all aspects of the managed systems, and provides change tracking and
RSS feeds using git. It's just over 250 lines of code. So we think that
is pretty neat. We're also building a very light webapp at the moment
(Func-Web) that showcases some neat features of the API -- like being
able to autodiscover what minions are on the network and what
modules/methods they have available. Ultimately I'd like to see
something like a network version of the system-config-* tools built out
of this, allowing systems to be addressed not only over the network, but
in aggregate, such that changes could be made to all systems matching
certain naming patterns and so forth. Naturally this starts to drift
towards multinode config management territory a bit too -- where it
becomes interesting exploring how to address multinode relationships
between different systems -- for instance, how do you install one
application X here, and do tasks Y there, and manage failures in a sane
way? This might be very interesting for doing disaster recovery type
tasks, for instance.
If there are any specific questions, look over the project page and I'd
be glad to elaborate in any further detail where required.
We've already had some nice work done by some folks working towards BSD
and Debian ports, so we would definitely want to see that continue -- as
well as a community getting built up more around submitting useful
modules. Func modules just live in a directory, so an package can add
additional modules into Func without them needing to be a part of Func
-- though it would be great to see those accumulate in a common place so
other applications could build on them.
Helpful? Still confusing?
It definitely sounds like a good opportunity and I like the idea of
seeing more community applications built on Func, or at least using Func
in some ways (for cert distribution, etc) and starting to use more of it
over time. There is definitely a lot of places Func can go -- and no
doubt places where we can improve it -- though if anyone is interested
I'd invite them to join the list, submit some patches, and also stop by
on IRC -- we're #func on irc.freenode.net
--Michael
_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list
