My point is: we can't keep "mending" the wrong behavior, otherwise we can not move forward.
On Fri, Apr 27, 2018 at 2:22 PM, Jinmei Liao <jil...@pivotal.io> wrote: > So the current behavior is, when a customer starts a server with cache.xml > that has a region defined, and then later on issues a gfsh command `create > index` on that region, the command output would be something like: > >create index ..... > Member | Status > ---------------------------- > server-1 | Index successfully created. > > Cluster configuration for "cluster" is not updated > Region XYZ does not exist in the cluster configuration (or something to > this effect). > > The command result would tell user exactly what happened and what not > happened. The point is, a server's own cache.xml is NOT meant to be a > "cluster" wide configuration. If customer is in the habit of starting up > server with cache.xml but yet still want to have consistent region/index > defined in the cluster, export a server's config and use that to start > another server. > > > > On Fri, Apr 27, 2018 at 2:03 PM, Diane Hardman <dhard...@pivotal.io> > wrote: > >> I talked with Barbara and understand the long term effort to deprecate >> cache.xml in favor of cluster config and I heartily agree. >> I think a good step in that direction is to provide a migration tool for >> users that reads all cache.xml files for current members and store them in >> cluster config, throwing exceptions and logging errors when region >> definitions conflict (for the same region name) on different servers in >> the >> same cluster. >> We might then consider removing the cache.xml files and rely on gfsh and >> (in the future, hopefully) Java API's to keep cluster config up-to-date. >> >> Thanks! >> >> On Fri, Apr 27, 2018 at 12:56 PM, Jinmei Liao <jil...@pivotal.io> wrote: >> >> > The decision is to go with the new behavior (I believe :-)). The region >> > does not exist in the cluster configuration to begin with since it's not >> > created using gfsh, so we have no way of checking unless we make an >> extra >> > trip to the region to find out what kind of region it is, but again >> > different server might have different opinion about what it is. >> > >> > On Fri, Apr 27, 2018 at 12:49 PM, Diane Hardman <dhard...@pivotal.io> >> > wrote: >> > >> > > Since we are working on enhancing Lucene support to allow adding a >> Lucene >> > > index to an existing region containing data, I am very interested in >> the >> > > decision here. >> > > Like Mike, I also prefer keeping the original behavior of updating >> > cluster >> > > config with both the region and the index if it was not there before. >> > > Is there something preventing you from checking cluster config for a >> > region >> > > of the same name but different properties and, if so, throwing an >> > exception >> > > (or warning) >> > > that cluster config could not be updated due to this collision? >> > > >> > > On Thu, Apr 19, 2018 at 3:35 PM, Michael Stolz <mst...@pivotal.io> >> > wrote: >> > > >> > > > Ok. Yes we do have to take the leap :) >> > > > Let's keep thinking that way. >> > > > >> > > > -- >> > > > Mike Stolz >> > > > Principal Engineer, GemFire Product Lead >> > > > Mobile: +1-631-835-4771 >> > > > Download the GemFire book here. >> > > > <https://content.pivotal.io/ebooks/scaling-data-services- >> > > > with-pivotal-gemfire> >> > > > >> > > > On Thu, Apr 19, 2018 at 6:29 PM, Jinmei Liao <jil...@pivotal.io> >> > wrote: >> > > > >> > > > > but this proposed change is one of the effort toward "deprecating >> > > > > cache.xml". I think we've got to take the leap at one point..... >> > > > > >> > > > > On Thu, Apr 19, 2018 at 3:14 PM, Michael Stolz <mst...@pivotal.io >> > >> > > > wrote: >> > > > > >> > > > > > Hmmm...I think I liked the old behavior better. It was a kind of >> > > bridge >> > > > > to >> > > > > > cluster config. >> > > > > > >> > > > > > I still think we need to be putting much more effort into >> > deprecating >> > > > > > cache.xml and much less effort into fixing the (possibly) >> hundreds >> > of >> > > > > bugs >> > > > > > related to using both cache.xml and cluster configuration at the >> > same >> > > > > time. >> > > > > > If we can make cluster config complete enough, and deprecate >> > > cache.xml, >> > > > > > people will stop using cache.xml. >> > > > > > >> > > > > > >> > > > > > >> > > > > > -- >> > > > > > Mike Stolz >> > > > > > Principal Engineer, GemFire Product Lead >> > > > > > Mobile: +1-631-835-4771 >> > > > > > Download the GemFire book here. >> > > > > > <https://content.pivotal.io/ebooks/scaling-data-services- >> > > > > > with-pivotal-gemfire> >> > > > > > >> > > > > > On Thu, Apr 19, 2018 at 5:58 PM, Jinmei Liao <jil...@pivotal.io >> > >> > > > wrote: >> > > > > > >> > > > > > > Scenario: >> > > > > > > a locator with cluster configuration enabled and a server >> started >> > > > with >> > > > > a >> > > > > > > cache.xml that has /regionA defined and connected to this >> > locator. >> > > So >> > > > > the >> > > > > > > initial state is the locator has an empty cluster >> configuration >> > for >> > > > the >> > > > > > > cluster, but the server has a region defined in it's cache. >> > > > > > > >> > > > > > > Old behavior: >> > > > > > > when user execute "create index --region=/regionA ...." >> command >> > > using >> > > > > > gfsh, >> > > > > > > the index creation is successful on the server, and the server >> > > > returns >> > > > > a >> > > > > > > xml section that contains both <region> and <index> elements, >> CC >> > is >> > > > > > updated >> > > > > > > with this xml, so the end result is: both region and index >> end up >> > > in >> > > > > the >> > > > > > > cluster configuration. >> > > > > > > >> > > > > > > Problem with old behavior: >> > > > > > > Not sure if the region is a cluster wide configuration. What >> if a >> > > > > region >> > > > > > > with the same name, but different type exists on different >> > servers? >> > > > the >> > > > > > xml >> > > > > > > returned by different server might be different. >> > > > > > > >> > > > > > > New behavior: >> > > > > > > when user execute "create index --region=/regionA ...." >> command >> > > using >> > > > > > gfsh, >> > > > > > > the index creation is successful on the server. We failed to >> find >> > > the >> > > > > > > region in the existing cluster configuration, so cluster >> > > > configuration >> > > > > > will >> > > > > > > NOT be updated. >> > > > > > > >> > > > > > > I would also suggest that this would not apply to index alone, >> > any >> > > > > > element >> > > > > > > inside region would have the same behavior change if we >> approve >> > > this. >> > > > > > > >> > > > > > > Thanks! >> > > > > > > >> > > > > > > -- >> > > > > > > Cheers >> > > > > > > >> > > > > > > Jinmei >> > > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > > -- >> > > > > Cheers >> > > > > >> > > > > Jinmei >> > > > > >> > > > >> > > >> > >> > >> > >> > -- >> > Cheers >> > >> > Jinmei >> > >> > > > > -- > Cheers > > Jinmei > -- Cheers Jinmei
