-1 for including any of this in the 1.0 release. Let's get that release out
the door!
-Dan
On Thu, Oct 13, 2016 at 2:26 PM, Udo Kohlmeyer <ukohlme...@pivotal.io>
wrote:
> If such a change is to be introduced.. maybe we call it `SYSTEM_PREFIX` or
> something more generic that we could use within the Geode.
>
> Then we could hopefully cover many to most `gemfire` vs `geode` renaming.
>
> But I agree with @Anthony, if we aren't 100% certain about a change then
> we should hold off until the next release. There is always tomorrow. :D
>
> --Udo
>
>
>
> On 14/10/16 8:05 am, Swapnil Bawaskar wrote:
>
>> 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
>>>>
>>>
>>>
>
