yeah, not documenting the alter command was a consciuous decision we took (i remember in Mike's office) as a not so advanced user may inadvertently change parameters that would slow down the system. Exposing these could mean introducing too many knobs. One quick point to add is that somehow I've always found the 'alter' command being hidden from the typical end-users. It was never part of the installation documentation (with managix):
https://ci.apache.org/projects/asterixdb/install.html#Section4ManagingTheLifecycleOfAnAsterixDBInstance So basically if one goal of separation is letting end users modify a portion of config at least they need to be aware of that. Pouria On Wed, Jun 29, 2016 at 10:53 AM, Ian Maxon <[email protected]> wrote: > You can modify some things in the asterix-configuration.xml that you really > shouldn't once you've created a cluster (page size for one), so its not > total, but in general yes the cluster.xml contains most of the "immutable" > stuff. > > On Wed, Jun 29, 2016 at 8:36 AM, Till Westmann <[email protected]> wrote: > > > Is there a conceptual or lifecycle reason to put a parameter in one or > the > > other file? I really would like to understand why we have 2 files and > what > > the difference is. I think that one hint might be what Ian just > mentioned, > > that the parameters in asterix-configuration.xml can be modified (with a > > restart?) and the other ones cannot. Is that right? > > > > On 29 Jun 2016, at 7:56, Ian Maxon wrote: > > > > > Managix sort of splices the cluster.xml with the existing > > > asterix-configuration.xml to produce a new asterix-configuration.xml > that > > > then gets put into the asterix-app jar inside of asterix-server. The > user > > > has to know about the base asterix-configuration.xml because that is > > where > > > you change some important memory parameters. You can also edit it > without > > > deleting the cluster itself (managix alter). > > > > > > On Wed, Jun 29, 2016 at 1:05 AM, Chris Hillery <[email protected]> > > > wrote: > > > > > >> My understanding of how Managix-based deployment currently works is as > > >> follows: > > >> > > >> - User composes a cluster.xml > > >> > > >> - Managix consumes this and produces an asterix-configuration.xml, > > which > > >> contains some of the same data as cluster.xml as well as some things > > >> derived from that data (such as composing the <iodevices> directories > > with > > >> the <store> subdirectory name to produce <storeDirs>) > > >> > > >> - Managix places both the original cluster.xml and the generated > > >> asterix-configuration.xml onto the CLASSPATH of the NCs and CCs > > >> > > >> - The user is never directly aware of asterix-configuration.xml, and > > >> certainly does not edit it in the normal course of operation > > >> > > >> Is this an accurate summary? > > >> > > >> Ceej > > >> aka Chris Hillery > > >> > > >
