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
Description: Message signed with OpenPGP using GPGMail