[Dev] Multiple Database support
Brent Mills
bmills at alterpoint.com
Wed May 21 14:54:32 CDT 2008
I have a few questions on the multiple DB support and migration?
Is ZipTie now "officially" supporting MySQL and Postgres with the next release?
Will there be an upgrade/migration feature as well?
-----Original Message-----
From: dev-bounces at ziptie.org [mailto:dev-bounces at ziptie.org] On Behalf Of dev-request at ziptie.org
Sent: Wednesday, May 21, 2008 10:47 AM
To: dev at ziptie.org
Subject: Dev Digest, Vol 13, Issue 16
Send Dev mailing list submissions to
dev at ziptie.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.ziptie.org/listinfo/dev
or, via email, send a message with subject or body 'help' to
dev-request at ziptie.org
You can reach the person managing the list at
dev-owner at ziptie.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Dev digest..."
Today's Topics:
1. Key-Chain modelling.... (James Brunner)
2. "Tracking Objects" Modelling.... (James Brunner)
3. Multiple database support (Brett Wooldridge)
4. Re: Multiple database support (Brett Wooldridge)
----------------------------------------------------------------------
Message: 1
Date: Tue, 20 May 2008 12:48:56 -0500
From: James Brunner <jbrunner at alterpoint.com>
Subject: [Dev] Key-Chain modelling....
To: ZipTie Development List <dev at ziptie.org>
Message-ID:
<B48CB61665A101419E226D4D141D540E047A554888 at mail-server.inside.eclyptic.com>
Content-Type: text/plain; charset="us-ascii"
Hi all,
As you may have noticed the model and IOS code for HSRP/VRRP modelling is almost complete. But my model for comes short when either protocols use Key-Chains for authentication. Key-Chains can be used not only by HSRP/VRRP but also by VPN ISAKMP setup so are declared at the global config level.
I've thought about where to add them into the model and I had the idea of putting them under "services" as they are a service used by the device. But what to call the group? A guy with a load of keys is a "Jailer" or if you prefer "Jailor" - but let's use International English ;)
Does anyone see any problems with it looking like this:
<services>
<jailer>
<key-chain>
<key-chain-name>AChain</key-chain-name>
<a-key>
<key-ID>1</key-ID>
<key>012345678901</key>
</a-key>
<a-key>
.....
</a-key>
</key-chain>
<key-chain>
.....
</key-chain>
</jailer>
<ntp>
.....
</ntp>
</services>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ziptie.org/pipermail/dev/attachments/20080520/414f787a/attachment-0001.html
------------------------------
Message: 2
Date: Tue, 20 May 2008 13:01:11 -0500
From: James Brunner <jbrunner at alterpoint.com>
Subject: [Dev] "Tracking Objects" Modelling....
To: ZipTie Development List <dev at ziptie.org>
Message-ID:
<B48CB61665A101419E226D4D141D540E047A55488F at mail-server.inside.eclyptic.com>
Content-Type: text/plain; charset="us-ascii"
Following on from the key-chain modelling, we come to "tracking object" modelling.
VRRP and HSRP (12.4+) support the idea of tracking objects.
When declaring a failover protocol you normally tell the failover protocol to "track" another interface. Tracking Objects allow you to declare a more in-depth set of tracking rules at the global configuration level and then just tell the failover protocol to track the object.
For example.
Track 101 interface FastEthernet1/1 ip routing Track 102 interface FastEthernet1/2 line-protocol Track 103 ip route 10.100.10.0 255.255.255.0 metric threshold
These can then be used by both HSRP and VRRP objects on many interfaces.
I'd like to declare them somewhere like <services> as they are used by many things under <trackingObjects>.
Does anyone have a better idea?
JB.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ziptie.org/pipermail/dev/attachments/20080520/dc5f0747/attachment-0001.html
------------------------------
Message: 3
Date: Wed, 21 May 2008 09:53:24 -0500
From: Brett Wooldridge <bwooldridge at alterpoint.com>
Subject: [Dev] Multiple database support
To: ZipTie Development List <dev at ziptie.org>
Message-ID: <C45A6674.10B9C%bwooldridge at alterpoint.com>
Content-Type: text/plain; charset="iso-8859-1"
Team,
In 2008.04b we will finally be able to support databases other than the embedded Derby. I've finally worked the kinks out of MySQL/Bitronix, which was the last hold-out.
As good as Derby is, there are those who have preferred or even required databases (in a corporate environment) that are different. But I'm going to try very hard to avoid an explosion of supported databases. In fact, if we never add another one I'll be happy. I'd prefer NOT to support Microsoft SQL Server and Oracle. First and foremost, I can't easily run either in my environment and since I'm the one holding up the database support, those two databases are not supported. There is a cost, and not a small one, to supporting a new database. Every schema change or addition must be duplicated and tested. Migrations, particularly data migrations are very costly to implement and test. If a company is willing to run ZipTie (an open source product), they can almost certainly run MySQL. They may prefer something else, but I'm betting they'll suck it up. Don't like it? Don't run ZipTie. Or join the team and offer to add (and support!) your preferred database.
Which brings me to the meat of this email. There is a new utility called 'dbutil' (actually 'dbutil.pl') that ships with ZipTie. This utility can be used to reset (i.e. create or re-create) the database. The 'dbutil' utility is also now used by the 'dbreset' target in the build - you will notice no change in behavior. However, it is about 2 seconds slower for MySQL and PostgreSQL, and about 4 seconds slower for Derby due to "shelling out".
You can also run the utility from the Build project, but the 'dbreset' Ant target is more convenient because it supplies all of the command arguments necessary. However, if for example you are running against a remote MySQL, you will have to use the command-line utility. But note this wasn't even possible before. If running remotely, there is still a file to be tweaked in the installation. If someone wants to get very clever they can change dbutil to go tweak the file.
Under Linux or OS X you can run the utility like any script (./dbutil.pl), on Windows you have to invoke 'perl' directly (i.e. perl dbutil.pl). Doing so without arguments will yield this:
./dbutil.pl
Usage: dbutil [options] <action>
Options:
--db database (one of: derby, mysql, pgsql)
--user the user to connect to the database as (optional)
--pass the password to connect to the database with (optional)
--host the hostname of the database server (optional)
--port the port number of the database server (optional)
--dir the ZipTie installation directory (optional)
Actions:
reset reset ZipTie to it's original state
You can see that there is only one action at present (reset). An invocation from 'dist' (or the installation directory) looks like this:
./dbutil.pl -db=mysql reset
If you are running 'dbutil' from Build you must specify the '--dir' option with a value of "../dist/server". However, as mentioned, from Build just use the 'dbreset' Ant target.
So, we now have support for Derby, MySQL, and PostgreSQL. If you have any questions or problems with the utility, database setup, or ZipTie issues on a given database let me know.
-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ziptie.org/pipermail/dev/attachments/20080521/67493642/attachment-0001.html
------------------------------
Message: 4
Date: Wed, 21 May 2008 10:46:53 -0500
From: Brett Wooldridge <bwooldridge at alterpoint.com>
Subject: Re: [Dev] Multiple database support
To: ZipTie Development List <dev at ziptie.org>
Message-ID: <C45A72FD.10BA8%bwooldridge at alterpoint.com>
Content-Type: text/plain; charset="iso-8859-1"
I should have mentioned that the changes are on the 2008.04 branch. I am merging them but it will probably be tonight or in the wee hours (Austin-time) before they're done. You'll see a chunk of check-ins in the build notification, so I won't bother sending another email.
-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ziptie.org/pipermail/dev/attachments/20080521/0d677a96/attachment.html
------------------------------
_______________________________________________
Dev mailing list
Dev at ziptie.org
http://mailman.ziptie.org/listinfo/dev
End of Dev Digest, Vol 13, Issue 16
***********************************
More information about the Dev
mailing list