[jira] Issue Comment Edited: (CASSANDRA-1906) Sanitize configuration code
[
https://issues.apache.org/jira/browse/CASSANDRA-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13004304#comment-13004304
]
Jon Hermes edited comment on CASSANDRA-1906 at 3/9/11 12:38 AM:
some notes:
CASSANDRA-2007 is the majority of the first part (drop deprecated yaml config).
Once that's completed, loadSchemaFromYaml() will be gutted,
RawKeyspace/ColumnFamily/ColumnDefinition and schematool removed. YAML is still
being used for the node config stuff, but there's much less magic there
(specifically the verbose snakeYAML descriptions of config relations). We don't
need schematool in trunk, but it will have to stay around in 0.7 for 0.6*
upgrades.
--
It doesn't look like Avro is leaving from the migration codepath, so CFMetaData
will likely still have to deal with both thrift and avro objects for now.
Builder pattern in CFMetaData helps gratuitously here to reduce code and
confusion, and DefsTest/DD/CFS will all have to use the new construction
pattern. There are two constructors: the standard one requires ks,name,type,and
comparators, and all other values defaulted, private one for system CFs that
set specific cfIDs, then a `CFMD foo( x ) {foo=x;return this}` for each prop
foo to set it other than default.
Currently CFMD is mutable (and KSMD is not), so it doesn't specifically need to
use a builder class to produce CFMDs. They're currently mutable because they
are held in multiple places and there's a race condition when migrations come
in. This should be simplified (either immutable and held in one place, or
mutable with atomic references), but not for this ticket.
--
For all per-node options:
- Permanent changes are only made by changing the YAML.
- StorageService has all the JMX calls that change DD at runtime.
- To make a permanent change without restarting, change the yaml and make the
temp change. The next time it starts up, it's permanent.
- No thrift involved in node state.
For all per-CF options:
- Permanent changes must be made via migration. Thrift system_* calls, or the
cli wrappers for such.
- Each KSMD sits on its respective Table, each CFMD sits on its respective CFS.
SST{R,W} also needs to be able to access the CFMD in a tight loop.
Exposing Table (read: Keyspace) changes the MBean hierarchy, and some changes
should be made there as well to make it look more like the actual relations:
{noformat}
o.a.c.db (tree root)
/ || |\
SS CM HHOM CL KEYSPACES
/ (I/OM) / | \
ConfigK1 K2 ...
| \ / \ ...
(D)EPS NodeOpts Table |
/ ColumnFamilies
KSOpts/ | \
CF1 CF2 ...
/ \ ...
CFS1 |
/CACHES
CFOpts | \
key row
{noformat}
- Temporary changes are made via JMX (nodetool, Table/CFS beans). They are
stronger changes than new migrations coming in, so a temporary will persist
until the node reboots, regardless of new migrations. To use the settings set
in the most recent migration, either reboot the node or call unsetFoo() (next
to getFoo() and setFoo()) for a given property.
was (Author: jhermes):
some notes:
CASSANDRA-2007 is the majority of the first part (drop deprecated yaml config).
Once that's completed, loadSchemaFromYaml() will be gutted,
RawKeyspace/ColumnFamily/ColumnDefinition and schematool removed. YAML is still
being used for the node config stuff, but there's much less magic there
(specifically the verbose snakeYAML descriptions of config relations). We don't
need schematool in trunk, but it will have to stay around in 0.7 for 0.6*
upgrades.
--
It doesn't look like Avro is leaving from the migration codepath, so CFMetaData
will likely still have to deal with both thrift and avro objects for now.
Builder pattern in CFMetaData helps gratuitously here to reduce code and
confusion, and DefsTest/DD/CFS will all have to use the new construction
pattern. There are two constructors: the standard one requires ks,name,type,and
comparators, and all other values defaulted, private one for system CFs that
set specific cfIDs, then a `CFMD foo(x) {foo=x;return this}` for each prop foo
to set it other than default.
Currently CFMD is mutable (and KSMD is not), so it doesn't specifically need to
use a builder class to produce CFMDs. They're currently mutable because they
are held in multiple places and there's a race condition when migrations come
in. This should be simplified (either immutable and held in one place, or
mutable with atomic references), but not for this ticket.
--
For all per-node options:
- Permanent changes are only made by changing the YAML.
- StorageService has all the JMX
[jira] Issue Comment Edited: (CASSANDRA-1906) Sanitize configuration code
[
https://issues.apache.org/jira/browse/CASSANDRA-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13004304#comment-13004304
]
Jon Hermes edited comment on CASSANDRA-1906 at 3/9/11 12:43 AM:
some notes:
CASSANDRA-2007 is the majority of the first part (drop deprecated yaml config).
Once that's completed, readTablesFromYaml() will be gutted,
RawKeyspace/ColumnFamily/ColumnDefinition and schematool removed. YAML is still
being used for the node config stuff, but there's much less magic there
(specifically the verbose snakeYAML descriptions of config relations). We don't
need schematool in trunk, but it will have to stay around in 0.7 for 0.6*
upgrades.
--
It doesn't look like Avro is leaving from the migration codepath, so CFMetaData
will likely still have to deal with both thrift and avro objects for now.
Builder pattern in CFMetaData helps gratuitously here to reduce code and
confusion, and DefsTest/DD/CFS will all have to use the new construction
pattern. There are two constructors: the standard one requires ks,name,type,and
comparators, and all other values defaulted, private one for system CFs that
set specific cfIDs, then a `CFMD foo( x ) {foo=x;return this}` for each prop
foo to set it other than default.
Currently CFMD is mutable (and KSMD is not), so it doesn't specifically need to
use a builder class to produce CFMDs. They're currently mutable because they
are held in multiple places and there's a race condition when migrations come
in. This should be simplified (either immutable and held in one place, or
mutable with atomic references), but not for this ticket.
--
For all per-node options:
- Permanent changes are only made by changing the YAML.
- StorageService has all the JMX calls that change DD at runtime.
- To make a permanent change without restarting, change the yaml and make the
temp change. The next time it starts up, it's permanent.
- No thrift involved in node state.
For all per-CF options:
- Permanent changes must be made via migration. Thrift system_* calls, or the
cli wrappers for such.
- Each KSMD sits on its respective Table, each CFMD sits on its respective CFS.
SST{R,W} also needs to be able to access the CFMD in a tight loop.
Exposing Table (read: Keyspace) changes the MBean hierarchy, and some changes
should be made there as well to make it look more like the actual relations:
{noformat}
o.a.c.db (tree root)
/ || |\
SS CM HHOM CL KEYSPACES
/ (I/OM) / | \
ConfigK1 K2 ...
| \ / \ ...
(D)EPS NodeOpts Table |
/ ColumnFamilies
KSOpts/ | \
CF1 CF2 ...
/ \ ...
CFS1 |
/CACHES
CFOpts | \
key row
{noformat}
- Temporary changes are made via JMX (nodetool, Table/CFS beans). They are
stronger changes than new migrations coming in, so a temporary will persist
until the node reboots, regardless of new migrations. To use the settings set
in the most recent migration, either reboot the node or call unsetFoo() (next
to getFoo() and setFoo()) for a given property.
was (Author: jhermes):
some notes:
CASSANDRA-2007 is the majority of the first part (drop deprecated yaml config).
Once that's completed, loadSchemaFromYaml() will be gutted,
RawKeyspace/ColumnFamily/ColumnDefinition and schematool removed. YAML is still
being used for the node config stuff, but there's much less magic there
(specifically the verbose snakeYAML descriptions of config relations). We don't
need schematool in trunk, but it will have to stay around in 0.7 for 0.6*
upgrades.
--
It doesn't look like Avro is leaving from the migration codepath, so CFMetaData
will likely still have to deal with both thrift and avro objects for now.
Builder pattern in CFMetaData helps gratuitously here to reduce code and
confusion, and DefsTest/DD/CFS will all have to use the new construction
pattern. There are two constructors: the standard one requires ks,name,type,and
comparators, and all other values defaulted, private one for system CFs that
set specific cfIDs, then a `CFMD foo( x ) {foo=x;return this}` for each prop
foo to set it other than default.
Currently CFMD is mutable (and KSMD is not), so it doesn't specifically need to
use a builder class to produce CFMDs. They're currently mutable because they
are held in multiple places and there's a race condition when migrations come
in. This should be simplified (either immutable and held in one place, or
mutable with atomic references), but not for this ticket.
--
For all per-node options:
- Permanent changes are only made by changing the YAML.
- StorageService has all the JMX
[jira] Issue Comment Edited: (CASSANDRA-1906) Sanitize configuration code
[
https://issues.apache.org/jira/browse/CASSANDRA-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12993855#comment-12993855
]
Stu Hood edited comment on CASSANDRA-1906 at 2/12/11 7:57 AM:
--
While you are at this, CFMetaData and co should probably be converted to the
builder pattern so that we can kill their ridiculously long constructors and
factories, which are far too easy to break. Since the object is already
immutable, we don't actually need a builder object per-say... just copy
methods to allow chaining like:
{noformat}CFMetaData newCf = CFMetaData.create(Keyspace, CF)
.replicationFactor(2)
.comparator(BytesType.class)
...
{noformat}
was (Author: stuhood):
While you are at this, CFMetaData and co should probably be converted to
the builder pattern so that we can kill their ridiculously long constructors
and factories, which are far too easy to break. Since the object is already
immutable, we don't actually need a builder object per-say... just copy
methods to allow chaining like:
{noformat}CFMetaData.create(Keyspace, CF)
.replicationFactor(2)
.comparator(BytesType.class)
...
{noformat}
Sanitize configuration code
---
Key: CASSANDRA-1906
URL: https://issues.apache.org/jira/browse/CASSANDRA-1906
Project: Cassandra
Issue Type: Improvement
Reporter: Jon Hermes
Assignee: Jon Hermes
Priority: Minor
Fix For: 0.8
Original Estimate: 24h
Remaining Estimate: 24h
Multipart:
- Drop deprecated YAML config. Only config allowed is via thrift/JMX. Make
this gratuitously easy to do with sane defaults and accepting changesets as
opposed to full definitions.
- Combine common code between KS/CF/ColumnDefs and between thrift/avro defs.
- Provide an obvious and clean interface for changing settings locally versus
globally (JMX vs. thrift). Dox here.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (CASSANDRA-1906) Sanitize configuration code
[ https://issues.apache.org/jira/browse/CASSANDRA-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12993670#comment-12993670 ] Jon Hermes edited comment on CASSANDRA-1906 at 2/11/11 8:08 PM: CFS has started to accumulate DefaultTs for settings that can be changed at runtime for per-node settings (min/max compaction threshold, and mem size/ops/time (soon row/key cache save period CASSANDRA-2100)). If we want to keep these ephemeral (non-migration) changes, then Tables (KSs) and StorageService (Global per-node settings) should follow in suit, and there should be one for every config option that doesn't impact the cluster (i.e. changing the max_hint_window ephemerally = Good, changing the partitioner or token ephemerally = Bad/impossible). This reduces it to three paths: - Read from cassandra.yaml for SS settings at boot time, - Read from the schema and accept migrations to the schema for permanent KS/CF settings, - Change any per-node value at runtime in SS/Table/CFS, ... and the first and third may well be combined for a scant two _code_ paths (compare to current 4+ code paths) separated by the permanent/non-permanent taxonomy. was (Author: jhermes): CFS has started to accumulate DefaultTs for settings that can be changed at runtime for per-node settings (min/max compaction threshold, and mem size/ops/time (soon row/key cache save period CASSANDRA-2100)). If we want to keep these ephemeral (non-migration) changes, then Tables (KSs) and StorageService (Global per-node settings) should follow in suit, and there should be one for every config option that doesn't impact the cluster (i.e. changing the saved_caches dir/ = Good, changing the partitioner or token ephemerally = bad). This reduces it to three paths: - Read from cassandra.yaml for SS settings at boot time, - Read from the schema and accept migrations to the schema for permanent KS/CF settings, - Change any per-node value at runtime in SS/Table/CFS, ... and the first and third may well be combined for a scant two _code_ paths (compare to current 4+ code paths) separated by the permanent/non-permanent taxonomy. Sanitize configuration code --- Key: CASSANDRA-1906 URL: https://issues.apache.org/jira/browse/CASSANDRA-1906 Project: Cassandra Issue Type: Improvement Reporter: Jon Hermes Assignee: Jon Hermes Priority: Minor Fix For: 0.8 Original Estimate: 24h Remaining Estimate: 24h Multipart: - Drop deprecated YAML config. Only config allowed is via thrift/JMX. Make this gratuitously easy to do with sane defaults and accepting changesets as opposed to full definitions. - Combine common code between KS/CF/ColumnDefs and between thrift/avro defs. - Provide an obvious and clean interface for changing settings locally versus globally (JMX vs. thrift). Dox here. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
