Cassandra Schema Management Tool (thread 2)

Jay Shaughnessy jshaughn at redhat.com
Fri May 31 15:14:40 UTC 2013


I think this seems reasonable.  Will the schema versions correspond to 
the RDB schema versions or be completely separate?  Meaning, will we 
have one overall schema version, or two?  One version may be more clear 
but separate versions may be OK  as long as it's easy for users to 
determine the version and report it to us.


On 5/28/2013 1:58 PM, Stefan Negrea wrote:
>
> ----- Original Message -----
>> From: "Jay Shaughnessy" <jshaughn at redhat.com>
>> To: rhq-devel at lists.fedorahosted.org
>> Sent: Tuesday, May 28, 2013 8:21:43 AM
>> Subject: Re: Cassandra Schema Management Tool (thread 2)
>>
>>
>> Can you give us an idea of how the schema management (an upgrade) will
>> play with the RHQ upgrade steps with which we are familiar? For example,
>> today basically an upgrade consists of installing the new version of RHQ
>> with the "keep" option (or something like that). Will there be a
>> separate step to apply changes to Cassandra?
>
> On every RHQ install the default would be to run the schema management tool for Cassandra. The tool will decide what needs to be done without any user intervention. The only caveat is that we will not support user modifications of the schema.
>
> Here is the logic:
> 1) If the version table is present in Cassandra:
>   a) read the information from the version table
>   b) apply updates from the last update
> 2) If the version table is not present in Cassandra:
>   a) bootstrap the schema ( which would include install version table)
>   b) apply all the updates from the very first update
>
>
> Any thoughts?
>
>
>>
>> On 5/24/2013 11:46 AM, Stefan Negrea wrote:
>>> Hello Everybody,
>>>
>>> Here are the design plans for the new Cassandra schema management tool:
>>>
>>> 1) A version table will keep track of the current schema version
>>> 2) The initial setup
>>>     a) Will create:
>>>       i)Initial RHQ admin user/password
>>>       ii) RHQ keyspace
>>>       iii) Schema versioning column family (=table)
>>>     b) Once the initial setup is done, it will never run again
>>> 3) Everything else will be installed/updated via incremental changes:
>>>    a) One change file per version change.
>>>    b) Multiple changes can be bundled in a change file.
>>>    c) The name of the change file will be used for database versioning
>>>    purposes.
>>>    d) If a change has already been applied it will not be applied again for
>>>    the lifetime of the installation.
>>>    e) If an incremental change fails, the upgrade process stops.
>>>    f) The upgrade files will be in XML format, with a very simplistic XML
>>>    Schema.
>>> 4) There will not be a single schema file for new installs.
>>>    a) All installs will follow this incremental upgrade process.
>>> 5) All schema modifications outside of the schema manager will not be
>>> supported and are at risk.
>>>
>>>
>>> Starting with a simple and minimalist tool is the best solution (minimal
>>> set features, more robust). I expect the tool to evolve over time but if
>>> we keep things simple, then it will be to easier to maintain over time.
>>>
>>>
>>> Anything that I might be missing?
>>>
>>>
>>>
>>> Thank you,
>>> Stefan Negrea
>>>
>>> Software Engineer
>>>
>>> _______________________________________________
>>> rhq-devel mailing list
>>> rhq-devel at lists.fedorahosted.org
>>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel



More information about the rhq-devel mailing list