asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raman Grover <ramangrove...@gmail.com>
Subject Re: Cluster XML files
Date Wed, 29 Jun 2016 18:43:20 GMT
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 <imaxon@uci.edu> 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 <tillw@apache.org> 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 <chillery@hillery.land>
> > > 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
> > >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message