How about introducing a new GEMFIRE_FILE_PREFIX attribute that will default
to "geode" while leaving GEMFIRE_PREFIX default to "gemfire"? Is this
something that will work?
On Thu, Oct 13, 2016 at 1:48 PM, Anthony Baker <aba...@pivotal.io> wrote:
> Hmmm, you would think it would be easier to change a file name :-)
>
> I don’t think we should be pushing destabilizing changes into a release
> branch. If the changes aren’t ready now we always pick them up for the
> next release.
>
> Anthony
>
> > On Oct 13, 2016, at 1:13 PM, Kirk Lund <kl...@apache.org> wrote:
> >
> > I'm currently working with Jared and we have spent a few days working
> > on GEODE-1466. We've been trying to get geode to the point where it can
> > automatically search for, find and use either geode.properties or
> > gemfire.properties (preferring geode.properties if both are found).
> >
> > We were intending to break this up into three subtasks with the hope of
> > including #1 in Geode 1.0.0 incubating:
> >
> > 1) locating geode.properties and gemfire.properties if user has not
> > specified a specific properties file
> >
> > 2) support specifying geode configuration properties with system
> properties
> > geode.<property-name> as well as gemfire.<property-name>
> >
> > ex: -Dgemfire.off-heap-memory-size=40g or -Dgeode.off-heap-memory-size=
> 40g
> >
> > 3) modify all other system properties in geode to support alias of
> gemfire
> > as well as geode where the name of the system property currently contains
> > gemfire
> >
> > ex: -Dgemfire.Query.VERBOSE=true or -Dgeode.Query.VERBOSE=true
> >
> > The community is planning to create the Geode 1.0.0 incubating RC
> tomorrow.
> > The work we have completed so far involves modifying geode to search for
> > both geode.properties and gemfire.properties to use whichever one is
> found.
> > This turns out to be too complex to complete by tomorrow (send me a email
> > directly if you want more detailed info which mostly involves
> > DistributionConfig and ConfigSource).
> >
> > In order to complete this in time, we need to use a different strategy.
> > Instead of looking for geode.properties first and then
> gemfire.properties,
> > we are proposing the following change to DistributionConfig:
> >
> > Change the GEMFIRE_PREFIX = "gemfire." constant to be configurable by a
> > system property and change the default to be "geode." This places a
> greater
> > burden on the user who is migrating from GemFire to Geode but doesn't
> want
> > to rename gemfire.properties or gemfire system properties. By default,
> > Geode would search for geode.properties unless the user specifies a new
> > system property with a different prefix ("gemfire."):
> >
> > String GEMFIRE_PREFIX = PropertiesPrefix.getGemfireOrGeodePrefix();
> >
> > Example of overriding this to be "gemfire.":
> >
> > -DgeodePropertiesPrefix="gemfire."
> > or
> > -DgeodePropertiesPrefix="gemfire"
> >
> > (we'll add the "." for you if you leave it out)
> >
> > Pivotal or other vendors could also alter this prefix as they see fit.
> >
> > There are 453 lines of production code that refer to this GEMFIRE_PREFIX
> > constant. For example, every system property that contains "gemfire." is
> > currently referring to the constant, so they would also be altered to be
> > "geode." by default. The JMX notifications also refer to GEMFIRE_PREFIX
> > such as: GEMFIRE_PREFIX + "distributedsystem.cache.client.joined".
> >
> > Does anyone know if anything referring to GEMFIRE_PREFIX is persisted in
> > some way that would break if we make this change? For example, if we
> > persist any strings built with this constant to a diskstore, then
> recovery
> > from that diskstore would be broken if the prefix value is "geode."
> during
> > recovery of an old diskstore.
> >
> > Also, a user could conceivably override the GEMFIRE_PREFIX in some
> members
> > of a cluster but not others which could break things in unexpected ways.
> >
> > One more note: While reviewing uses of GEMFIRE_PREFIX we noticed that
> > AgentUtil supports "GEMFIRE" (hardcoded) and GEMFIRE_PREFIX+".home" env
> > vars while all of the online docs specify setting GEMFIRE_HOME as an env
> > var. I suspect this is already broken (I will file a ticket), but I think
> > we will also be at risk of breaking additional things that may or may not
> > be immediately detected by precheckin tests. It's also used by
> DtdResolver
> > for the name of a dtd: new File(GEMFIRE_PREFIX + "dtd). We'll continue
> > looking for unusual or risky uses of the constant.
> >
> > Bottom line is making this change is higher risk than not making the
> > change, and there could be some fallout bugs that require fixes and
> > additional release candidates for 1.0.0.
> >
> > Does the community feel this change is desirable for 1.0.0? Or is it
> better
> > to leave it as "gemfire." and move GEODE-1466 to post-1.0.0?
> >
> > Thanks,
> > Kirk
>
>
