Stephen John Smoogen wrote:
On Tue, Mar 4, 2008 at 12:37 PM, Michael DeHaan <mdehaan@xxxxxxxxxx> wrote:
We're getting close to releasing Func 0.18, which will be just like 0.17
with the addition of certmaster being moved out into a seperate package.
I see packaging and upgrading of Funcweb as a logical thing to do for a
Func 0.19, hopefully we can incorporate some
module/improvements/upgrades as well. That's probably where I plan to
spend most of my time.
Anything needing to be done to the core, perhaps usability wise with
respect to the func command line and client side modules?
Has anyone evaluated "func '*' check" to see if it validates
configurations sufficiently? (Does someone want to extend that to
look for expired certs, etc?)
Perhaps the EL3 backport?
The big things that would interest me is how to tie into the func API
with a higher level 'descriptive language'. I would like to be able to
have something where I can say "Make these systems look like this,
make sure that they stay that way (audit them) and tell me when they
change, and then make them the way I told you to do it." I am looking
at more of a declaritive/descriptive higher view so that I can do
something like (syntax not this but something like)
This is very much in line with some of the Multinode config management
features I would like to see in Func in the future.
Currently there are two big pseudo-obvious applications for Func on the
horizon:
(A) the Multinode config management solution -- aka "RRS" -- Remote
Rocket Surgery
(B) making FuncWeb become a web based multi-machine version of the
system-config-* tools, and for browsing/administering Func
Since it came up on IRC yesterday, the idea behind multinode is thus...
Often when you are installing a shiny new solution it will require
putting a database on one box, a web server on another, and so on.
This is where most config management tools break down -- they can't
express ordered relationships between "nodes". Func could
do this, while also providing some rather solid auditing about what it
did where in the process.
This would allow not only installing solutions in classical config
management "make it look that way and stay that way" kind of scenarios,
but would make it easier to express ordered tasks that are frequently
repeated.
WebClass::AppServers::EL4 -> install_soap
install_soap: {
package_add {zope, repoX}
config_manage {/etc/soap/our_configs}
}
audit_soap: {
package_check {zope,repoX}
config_check{/etc/soap/our_configs,/etc/passwd}
report{form_NIST_23231}
}
remove_soap: {
...
}
etc .. the reason is that having done a 5000 line
bash+awk+sed+perl+python script to make a system meet various auditing
requirements and then doing it in 1/10th of that in cfengine (and
probably less in puppet) makes it easier to understand what is going
on. Now a lot of those 5000 lines got pushed down to the 'func' level
but it was a whole lot easier to have a syntax that basically said
what I wanted the class of systems to be, and then did it.
Adrian and I have bounced this around on serveral occasions, and we're
inclined to think that we should not go the Puppet/cfengine route
if we do this -- and not invent yet another domain specific language.
Ideally we evolve the Python API to a level where we can express all
of the above with extremely minimal Python code, such that to newcomers
it barely even seems like Python. This still allows things to be
arbitrarily extensible while not having to spend /any/ time maintaining
a "language".
It's too early to explore what that syntax would be like now, though it
could be as simple as...
On("server1",[
Package("zope",...)
])
On("mailservers*",[
...
])
The main thing would be building the higher level objects to make that
behavior achievable.
In the meantime, I don't really see an immediate need to create yet
another config management tool, but in idea that multinode scripting is
important,
making a higher level API to make this accessible to non-python
programmers would be a good thing.
My main concern before doing this is that the library of Func modules
needs to get expanded and improved a lot first to make that possible.
So, right now, I'm looking at FuncWeb being evolved over the middle part
of this year, and hopefully after that starts to be self sufficient
we can concentrate on the next thing, that being Multinode scripting and
that higher level API.
This additional application would likely be another app written on top
of Func (like Func-Inventory), and possibly even a seperate package.
--Michael
_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list
