[Dev] Multiple Database support
Leo Bayer
lbayer at alterpoint.com
Wed May 21 17:31:06 CDT 2008
Brett,
You are the one who has to spend the time to support them, so I
really have no opinion on official support. If we actually had a
prospective (for pay) customer I say we should absolutely officially
support their choice of DB. Assuming their choice is black (where
black is PostgreSQL or MySQL or whatever DB we as developers feel
comfortable supporting).
- Leo
On May 21, 2008, at 5:27 PM, Brett Wooldridge wrote:
> I think we have to “officially” support MySQL (and Derby, of
> course). I’d like to officially support all, does the team have an
> opinion. I know we have one user interested in PostgreSQL, but one
> user doesn’t justify full support. However, given that MySQL XA
> transaction support is a hack, PostgreSQL is in theory a better
> production database for ZipTie. There is no upgrade/migration from
> one DB to another. Theoretically a Derby dump (which generates a
> SQL file) could be piped into MySQL import, but I’m steering far
> clear of that one.
>
> -Brett
>
> On 5/22/08 4:54 AM, "Brent Mills" <bmills at alterpoint.com> wrote:
>
> 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
> ***********************************
>
> _______________________________________________
> Dev mailing list
> Dev at ziptie.org
> http://mailman.ziptie.org/listinfo/dev
>
>
> <ATT00001.txt>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ziptie.org/pipermail/dev/attachments/20080521/778fa1af/attachment-0001.html
More information about the Dev
mailing list