continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wendy Smoak" <wsm...@gmail.com>
Subject Re: First Part of Distributed Builds
Date Wed, 14 Jan 2009 22:24:23 GMT
On Wed, Jan 14, 2009 at 12:18 AM, Napoleon Esmundo C. Ramirez
<napoleonesmundocarpioramirez@gmail.com> wrote:

> Having lots of data aggregated from different Continuum instances into one
> will need some kind of an importer tool.  I'm thinking this should only
> support data from Continuum instances of the same model version, while data
> from different versions will have to be handled by a separate db migration
> and conversion tool.  I'd like to point out that distinction and combining
> the two is an option, but let's take things bit by bit first.

It is the db migration tool that is blocking a release of 1.3 right
now, so the first thing I'm looking for is a way to upgrade a single
instance of 1.2.x to 1.3.1-SNAPSHOT.

The importer tool to consolidate multiple existing instances would be
nice to have, but so far I'm the only one asking. :)

> Briefly:
> 1.  The Backup functionality should be available in the Continuum web ui.
> The core functionality is available, making it accessible in the Continuum
> web ui will ease the generation of data to import.

Not sure if you have these in any sort of order, but this is low
priority for me.  I'd get it working at the command line before
worrying about adding it to the webapp.

> 2.  Create the Import functionality.
> 2.a  This accepts the backup files as input.
> 2.b  All the data in the backup file will be appended to the existing data
> of the Continuum instance it is imported to.

I think there needs to be an option to import and overwrite -- there
is always some data in a Continuum instance, even a brand new one (the
default project group, default schedule, etc.)   If you always append,
there will be no way to restore from a backup and get back to the same
state.

> A basic rule is: no duplicates.  In case of duplicates, either a new

Was there more on this thought?

> The complications are:
> 1.  The keys of the entities in the imported data may have duplicates in the
> Continuum instance it is imported to.  To address this, the keys of the
> imported data will have to be adjusted, shifting the values to next
> available values but giving preference to the existing data (latest key
> value + 1 ??).
> 2.  Since the keys will be adjusted, the relationships between the entities
> of the imported data will have adjust as well.

What about the build output, which is stored in numbered directories?
I don't think it is included in the xml backup, you're just expected
to have them in the right place on disk.  Those directories would
either have to be re-numbered along with the records in the database,
or we'll have to document that we don't support keeping build output
when you consolidate server config.

Or maybe we just leave out build results altogether for the first pass
at this, and say we only support consolidating the
projects/schedules/installations/etc -- the configuration and not the
historical data.

Thanks,
-- 
Wendy

Mime
View raw message