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 > > >> > > >
