[Infrastructures] Questions about isconf4...

[Steve Traugott]

Hi Juri,

On Tue, Dec 13, 2005 at 11:24:05PM +0100, Juri Rischel Jensen wrote:
> 1. The documentation says that I should keep the branch count down.
> I  can make sense of that, but what if I have 3 webservers in my
> domain, have them  share the same branch and then on hostA do a
> 
>      isconf lock "Enabling new_apache_vhost"
>      isconf snap new_apache_vhostfile.conf
>      isconf exec a2ensite new_apache_vhostfile.conf
>      isconf exec /etc/init.d/apache2 force-reload
>      isconf ci

In all likelihood, you don't actually want to snap
new_apache_vhostfile.conf -- you instead want to generate it from
whatever your current customer/vhost database says.  You use isconf to
manage the executables which do that generation; those executables
talk to the database (or flat files, or LDAP, etc.) to get the latest
and greatest data, rather than cause it to evolve as machines are
built.  If you have no database and just usually edit
new_apache_vhostfile.conf directly instead, then read on...  Also see
the section on environmental data in the man page.

What's missing in isconf4 right now is the native configuration file
management bits which were there in isconf versions 1-3.  In version 1
we used SUP, in 2 and 3 we used rsync; the former was good because it
gave us post-replication triggers (to handle e.g. the force-reload);
the latter was bad because rsync doesn't do triggers.  As Jordan
hinted a couple of days ago, isconf4 is going to sync config files
from the distributed cache rather than a central server, but otherwise
it's the same idea; sync the file, check for triggers, run them, go to
the next file.

The main reason isconf4 doesn't yet do this is because the people
paying for the lion's share of isconf development right now are
already managing these files using higher-layer systems like the
database I describe above, so I haven't yet prioritized writing the
isconf code which would do the job natively.  (Okay, just now created
ticket 62 to track this -- http://trac.t7a.org/isconf/ticket/62).

>    Then I have a history of what I've done on hostA, I have my newly
>    added vhosts config file in the isfs and can replay that journal
>    entry again  if needed in the future. But as I understand it, the
>    same journal entry gets  excuted on hostB and hostC because they
>    share the same branch as hostA. Please correct  me if I'm wrong
>    here.

You are correct.

> 2. I can see in the journal file that every entry gets an ID. Have
> you planned on implementing a "changelog" verb - eg. "isconf
> changelog" to see  the history?

Yes.  It's a lower priority 'cause, well, you did find the journal
file, didn't you?  ;-)   If you (or anyone) wanted to craft a
standalone tool, the isconf.fbp822 module is what parses the message
format that file uses.  If anyone does write this, feel free to post
the code in a ticket and I'll integrate it in as an isconf subcommand.  

> 3. In our shop we do system administration for several customers and
> need to keep some of the configuration separate (the stuff that's
> different).  If I should implement a solution based on isconf4, as I
> see it I would have  to manually build the whole configuration
> structure from the bottom by issuing  isconf commands in the right
> order. 

There's an ongoing dispute about the meaning of the word
"configuration" -- so I have to ask; do you mean executables, or
customer-specific configuration files?  The former are what isconf4 is
currently intended to handle; the latter fall into the same category
as new_apache_vhostfile.conf.

> I can't reuse some of the things from one  customer when
> starting up a new one, as I can't share branches between domains.
> I'm  looking for a tool where I can reuse as much of my work as
> possible when starting a  new site (domain in isconf lingo).

I'm not (yet) convinced you want to use different domains for this --
have you already read http://trac.t7a.org/isconf/wiki/DomainsVsBranches?
What you've said so far makes me think you might want to use a single,
neutrally-named domain.  Can you elaborate on why the different branches 
need to be in different domains?  Who has physical access to the 
hardware, who has root, etc?  

If they're all in the same domain, then you can merge and hack
branches simply by using your favorite editor/merge tool on the
journal files for the two branches, taking care to not "edit history".
If they are in different domains, then you'd need to copy over the
./block contents as well.

Steve
-- 
Stephen G. Traugott  (KG6HDQ)
UNIX/Linux Infrastructure Architect, TerraLuna LLC
stevegt@TerraLuna.Org 
http://www.stevegt.com -- http://Infrastructures.Org