cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <bhais...@apache.org>
Subject Re: Merge 4.1-new-db-schema.sql to db/db/schema-40to410.sql
Date Wed, 27 Mar 2013 08:59:30 GMT
On Tue, Feb 19, 2013 at 7:12 PM, Chip Childers
<chip.childers@sungard.com> wrote:
> On Tue, Feb 19, 2013 at 04:16:12PM +0530, Rohit Yadav wrote:
>> On Mon, Feb 18, 2013 at 2:30 PM, Koushik Das <koushik.das@citrix.com> wrote:
>> > Rohit,
>> >
>> > Currently I see that there are 2 sql files related to upgrade from version A
to B, for e.g. schema-40to410.sql and schema-40to410-cleanup.sql.
>> > 1. What all should go in the normal one and what all in the -cleanup one? For
e.g. should deleting table metadata go in cleanup script, should deleting table data go in
cleanup script?
>>
>> In the schema one you should keep rules like add columns, add tables,
>> copying data (like copying to uuid column from id) etc. In the cleanup
>> script you should do things like removing columns or data. Think in
>> this way, when multiple mgmt servers are running and not all of them
>> are on same version, we want the first step of database upgrade to be
>> backward compatible to the old one which means you're not removing any
>> column, after you've upgraded all mgmt server you are free to cleanup
>> and remove any column, copy any data from those columns to maybe new
>> ones.
>>
>> > 2. What is the order in which the scripts will be executed? Upgrade followed
by corresponding cleanup for each version? OR is it like call all upgrades for all versions
followed by all cleanup scripts?
>>
>> At present, all create schemas are called first and cleanup is done
>> only at the end. We'll have the same way for 4.1 but starting 4.2,
>> once we will have the DatabaseCreator tool, it would much easier and
>> sysadmins could decide how they want to upgrade. Alex can comment on
>> it.
>>
>> > 3. If the ordering is based on former case (in 2 above) then it is better to
combine them into one single sql script. If it is the latter then I would like to understand
the reason behind that?
>>
>> Read explanation in 1. In case of clustered mgmt servers, if an old
>> mgmt server is running they will die if you remove any column of some
>> table it can access. While one may argue why not bring down the whole
>> cloud and then do upgrades, which is fine (and will be possible with
>> dbcreator/4.2) but not possible as only mgmt server upgrades the db
>> now.
>
> Rohit,
>
> Can you put a wiki page together on this?

In case I did not communicate, wiki:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Database+Creator

Mime
View raw message