[jira] [Commented] (SOLR-14843) Define strongly-typed cluster configuration API
[
https://issues.apache.org/jira/browse/SOLR-14843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201732#comment-17201732
]
Ilan Ginzburg commented on SOLR-14843:
--
I think we need to think the hierarchy carefully... Node props being overridden
by cluster props might work, but I can easily think of use cases where the
opposite makes sense as well, for example configuring a one off node in an
otherwise homogeneous cluster, but then system properties and environment
variables (which really are node props) override all the rest...
I believe a proposal needs to also have another dimension of where these
configurations come from. For system properties and environment variables it's
pretty simple, but cluster and node props can be in some central place (ZK) or
can be defined within the Solr distribution (file) and as such can end up being
different on each node (nothing prevents deploying slightly different images on
the nodes, or changing the node config after deploy).
What I really need short term is a way to do what {{solr.xml}} allows me doing
(define default config, let the user change them before deploy if he so
wishes). We do not currently have a replacement for this.
> Define strongly-typed cluster configuration API
> ---
>
> Key: SOLR-14843
> URL: https://issues.apache.org/jira/browse/SOLR-14843
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Priority: Major
> Labels: clean-api
> Fix For: master (9.0)
>
>
> Current cluster-level configuration uses a hodgepodge of traditional Solr
> config sources (solr.xml, system properties) and the new somewhat arbitrary
> config files kept in ZK ({{/clusterprops.json, /security.json,
> /packages.json, /autoscaling.json}} etc...). There's no uniform
> strongly-typed API to access and manage these configs - currently each config
> source has its own CRUD, often relying on direct access to Zookeeper. There's
> also no uniform method for monitoring changes to these config sources.
> This issue proposes a uniform config API facade with the following
> characteristics:
> * Using a single hierarchical (or at least key-based) facade for accessing
> any global config.
> * Using strongly-typed sub-system configs instead of opaque Map-s:
> components would no longer deal with JSON parsing/writing, instead they would
> use properly annotated Java objects for config CRUD. Config objects would
> include versioning information (eg. lastModified timestamp).
> * Isolating access to the underlying config persistence layer: components
> would no longer directly interact with Zookeeper or files. Most likely the
> default implementation would continue using different ZK files per-subsystem
> in order to limit the complexity of file formats and to reduce the cost of
> notifications for unmodified parts of the configs.
> * Providing uniform way to register listeners for monitoring changes in
> specific configs: components would no longer need to interact with ZK
> watches, they would instead be notified about modified configs that they are
> interested in.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14843) Define strongly-typed cluster configuration API
[
https://issues.apache.org/jira/browse/SOLR-14843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201668#comment-17201668
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14843:
--
I don’t know what Andrzej was thinking when he created this Jira, but what
thought when I saw it was something like:
The “consumer” side (our code, components, etc) could look something like:
{code:java}
int myInt = Config.getInteger(“some.configurable.thing”, default: 30);
String myStr = Config.getString(“some.configurable.string”, default: “foo”);
MyObject myStr = Config.get(“some.configurable.obj”, new SomeSortOfFactory());
{code}
Maybe even be able to support attach an onChange event, like
{code:java}
int myInt = Config.getInteger(“some.configurable.thing”, default: 30, onChange:
(v) -> { setMyInt(v); refresh()});
{code}
or something.
Then, this {{Config}} class could load the configuration from a predictable
hierarchy, something like:
{noformat}
system props > env > cluster props > node props
{noformat}
(don’t know if that’s the right order, and again, there could be more than one
hierarchy), so that a property can be set in the node configuration, but could
be overriden by collection level properties, etc.
One extra nice thing of an approach like this is that we could have an API to
show exactly the current configuration and where each config is coming from,
something like:
{code}
some.configurable.string: {
value: “bar”,
source: “collection property”
}
some.configurable.thing: {
value: 30,
source: “default”
}
{code}
Maybe even a timestamp of the change or something.
> Define strongly-typed cluster configuration API
> ---
>
> Key: SOLR-14843
> URL: https://issues.apache.org/jira/browse/SOLR-14843
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Priority: Major
> Labels: clean-api
> Fix For: master (9.0)
>
>
> Current cluster-level configuration uses a hodgepodge of traditional Solr
> config sources (solr.xml, system properties) and the new somewhat arbitrary
> config files kept in ZK ({{/clusterprops.json, /security.json,
> /packages.json, /autoscaling.json}} etc...). There's no uniform
> strongly-typed API to access and manage these configs - currently each config
> source has its own CRUD, often relying on direct access to Zookeeper. There's
> also no uniform method for monitoring changes to these config sources.
> This issue proposes a uniform config API facade with the following
> characteristics:
> * Using a single hierarchical (or at least key-based) facade for accessing
> any global config.
> * Using strongly-typed sub-system configs instead of opaque Map-s:
> components would no longer deal with JSON parsing/writing, instead they would
> use properly annotated Java objects for config CRUD. Config objects would
> include versioning information (eg. lastModified timestamp).
> * Isolating access to the underlying config persistence layer: components
> would no longer directly interact with Zookeeper or files. Most likely the
> default implementation would continue using different ZK files per-subsystem
> in order to limit the complexity of file formats and to reduce the cost of
> notifications for unmodified parts of the configs.
> * Providing uniform way to register listeners for monitoring changes in
> specific configs: components would no longer need to interact with ZK
> watches, they would instead be notified about modified configs that they are
> interested in.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14843) Define strongly-typed cluster configuration API
[
https://issues.apache.org/jira/browse/SOLR-14843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201427#comment-17201427
]
Ilan Ginzburg commented on SOLR-14843:
--
Would an initial step in this Jira be the ability to define a way to "prime"
the Zookeeper based configuration with something coming from a file?
Motivation:
The plugin based replica placement code is in master, but the default placement
strategy is {{LEGACY}}. To use the new placement strategy a specific config
must be set on a running SolrCloud cluster using a {{curl}} command to the
config API.
To make plugin placement the default strategy now or later (now would be good
so it gets some baking time...) yet be able to switch back a cluster to
{{LEGACY}} if needed (by removing that configuration), a configuration needs to
somehow be automatically pushed to {{/clusterprops.json}}, but there's no
support for doing that.
I believe priming a ZK config with content from a file is not easy (handle new
configs or changes to default configs coming with a new release, deal with
existing configuration in ZK to not overwrite it etc.) and is not my preferred
way of dealing with this types of configs, but we do need something.
> Define strongly-typed cluster configuration API
> ---
>
> Key: SOLR-14843
> URL: https://issues.apache.org/jira/browse/SOLR-14843
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Priority: Major
> Labels: clean-api
> Fix For: master (9.0)
>
>
> Current cluster-level configuration uses a hodgepodge of traditional Solr
> config sources (solr.xml, system properties) and the new somewhat arbitrary
> config files kept in ZK ({{/clusterprops.json, /security.json,
> /packages.json, /autoscaling.json}} etc...). There's no uniform
> strongly-typed API to access and manage these configs - currently each config
> source has its own CRUD, often relying on direct access to Zookeeper. There's
> also no uniform method for monitoring changes to these config sources.
> This issue proposes a uniform config API facade with the following
> characteristics:
> * Using a single hierarchical (or at least key-based) facade for accessing
> any global config.
> * Using strongly-typed sub-system configs instead of opaque Map-s:
> components would no longer deal with JSON parsing/writing, instead they would
> use properly annotated Java objects for config CRUD. Config objects would
> include versioning information (eg. lastModified timestamp).
> * Isolating access to the underlying config persistence layer: components
> would no longer directly interact with Zookeeper or files. Most likely the
> default implementation would continue using different ZK files per-subsystem
> in order to limit the complexity of file formats and to reduce the cost of
> notifications for unmodified parts of the configs.
> * Providing uniform way to register listeners for monitoring changes in
> specific configs: components would no longer need to interact with ZK
> watches, they would instead be notified about modified configs that they are
> interested in.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14843) Define strongly-typed cluster configuration API
[
https://issues.apache.org/jira/browse/SOLR-14843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17192855#comment-17192855
]
Jan Høydahl commented on SOLR-14843:
[~dsmiley] Feel free to adapt the SIP page instructinos to fit our needs. It
should probably mention that a VOTE is optional but should be held if the
dev-list discussion is clearly not conclusive. IMO a [VOTE] thread is
light-weight, and a successful VOTE is a good foundation to start a huge work
effort from, and likewise a failed VOTE will get you back to the design phase
instead of wasting days of effort which ends up in a -1 on a Jira or worse a
revert further down the road.
> Define strongly-typed cluster configuration API
> ---
>
> Key: SOLR-14843
> URL: https://issues.apache.org/jira/browse/SOLR-14843
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Priority: Major
> Labels: clean-api
> Fix For: master (9.0)
>
>
> Current cluster-level configuration uses a hodgepodge of traditional Solr
> config sources (solr.xml, system properties) and the new somewhat arbitrary
> config files kept in ZK ({{/clusterprops.json, /security.json,
> /packages.json, /autoscaling.json}} etc...). There's no uniform
> strongly-typed API to access and manage these configs - currently each config
> source has its own CRUD, often relying on direct access to Zookeeper. There's
> also no uniform method for monitoring changes to these config sources.
> This issue proposes a uniform config API facade with the following
> characteristics:
> * Using a single hierarchical (or at least key-based) facade for accessing
> any global config.
> * Using strongly-typed sub-system configs instead of opaque Map-s:
> components would no longer deal with JSON parsing/writing, instead they would
> use properly annotated Java objects for config CRUD. Config objects would
> include versioning information (eg. lastModified timestamp).
> * Isolating access to the underlying config persistence layer: components
> would no longer directly interact with Zookeeper or files. Most likely the
> default implementation would continue using different ZK files per-subsystem
> in order to limit the complexity of file formats and to reduce the cost of
> notifications for unmodified parts of the configs.
> * Providing uniform way to register listeners for monitoring changes in
> specific configs: components would no longer need to interact with ZK
> watches, they would instead be notified about modified configs that they are
> interested in.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14843) Define strongly-typed cluster configuration API
[
https://issues.apache.org/jira/browse/SOLR-14843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17192801#comment-17192801
]
Andrzej Bialecki commented on SOLR-14843:
-
{quote}This is not a user facing api
{quote}
Correct, the purpose of this Jira is to define an internal API. Although in
order to be useful as a read-write facade we will likely need a user-facing
CRUD API too.
I created SIP-11 to have a place where we outline the proposal in greater
detail.
> Define strongly-typed cluster configuration API
> ---
>
> Key: SOLR-14843
> URL: https://issues.apache.org/jira/browse/SOLR-14843
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Priority: Major
> Labels: clean-api
> Fix For: master (9.0)
>
>
> Current cluster-level configuration uses a hodgepodge of traditional Solr
> config sources (solr.xml, system properties) and the new somewhat arbitrary
> config files kept in ZK ({{/clusterprops.json, /security.json,
> /packages.json, /autoscaling.json}} etc...). There's no uniform
> strongly-typed API to access and manage these configs - currently each config
> source has its own CRUD, often relying on direct access to Zookeeper. There's
> also no uniform method for monitoring changes to these config sources.
> This issue proposes a uniform config API facade with the following
> characteristics:
> * Using a single hierarchical (or at least key-based) facade for accessing
> any global config.
> * Using strongly-typed sub-system configs instead of opaque Map-s:
> components would no longer deal with JSON parsing/writing, instead they would
> use properly annotated Java objects for config CRUD. Config objects would
> include versioning information (eg. lastModified timestamp).
> * Isolating access to the underlying config persistence layer: components
> would no longer directly interact with Zookeeper or files. Most likely the
> default implementation would continue using different ZK files per-subsystem
> in order to limit the complexity of file formats and to reduce the cost of
> notifications for unmodified parts of the configs.
> * Providing uniform way to register listeners for monitoring changes in
> specific configs: components would no longer need to interact with ZK
> watches, they would instead be notified about modified configs that they are
> interested in.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14843) Define strongly-typed cluster configuration API
[
https://issues.apache.org/jira/browse/SOLR-14843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17192618#comment-17192618
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14843:
--
Thanks for starting this work Andrzej, I was thinking about this same thing the
other day. I think Solr developers and users will both benefit from having a
consistent way to get and set configuration.
bq. Using a single hierarchical (or at least key-based) facade for accessing
any global config.
You are thinking in something like "cluster configuration > node configuration
> code defaults..." or something like that? I think that makes sense. The one
tricky part is that sometimes hierarchy may need fo follow a physical path
(cluster config -> node config -> default) and sometimes a logical path
(cluster config -> collection properties -> configset). Unless you are talking
about a completely different thing.
bq. I would suggest this new system allows setting default configuration at dev
time or pre deploy time (before ZK is even started) that are reflected in
deployed clusters.
+1. I think it's important to be able to configure the cluster before starting
the cluster.
bq. Ilan Ginzburg Code/config evolution is a general issue that is not specific
to this proposal. I
I think what Ilan is talking about is similar to what I mentioned in the config
discussion in the dev list (please correct me if I'm wrong, Ilan)? If a new
version of a component that needs to be deployed requires a new set of
configurations, it's easier if those configurations can be deployed together
with the code (in the dev list discussion, this is one of my points in favor of
a node configuration)
> Define strongly-typed cluster configuration API
> ---
>
> Key: SOLR-14843
> URL: https://issues.apache.org/jira/browse/SOLR-14843
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Priority: Major
> Labels: clean-api
> Fix For: master (9.0)
>
>
> Current cluster-level configuration uses a hodgepodge of traditional Solr
> config sources (solr.xml, system properties) and the new somewhat arbitrary
> config files kept in ZK ({{/clusterprops.json, /security.json,
> /packages.json, /autoscaling.json}} etc...). There's no uniform
> strongly-typed API to access and manage these configs - currently each config
> source has its own CRUD, often relying on direct access to Zookeeper. There's
> also no uniform method for monitoring changes to these config sources.
> This issue proposes a uniform config API facade with the following
> characteristics:
> * Using a single hierarchical (or at least key-based) facade for accessing
> any global config.
> * Using strongly-typed sub-system configs instead of opaque Map-s:
> components would no longer deal with JSON parsing/writing, instead they would
> use properly annotated Java objects for config CRUD. Config objects would
> include versioning information (eg. lastModified timestamp).
> * Isolating access to the underlying config persistence layer: components
> would no longer directly interact with Zookeeper or files. Most likely the
> default implementation would continue using different ZK files per-subsystem
> in order to limit the complexity of file formats and to reduce the cost of
> notifications for unmodified parts of the configs.
> * Providing uniform way to register listeners for monitoring changes in
> specific configs: components would no longer need to interact with ZK
> watches, they would instead be notified about modified configs that they are
> interested in.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14843) Define strongly-typed cluster configuration API
[
https://issues.apache.org/jira/browse/SOLR-14843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17192524#comment-17192524
]
Ishan Chattopadhyaya commented on SOLR-14843:
-
I think I misunderstood the intent of this jira. This is not a user facing api,
as I originally thought, but rather a refactoring of internal code with respect
to how various components access configuration pieces of Solr (via this
proposed api). If that is the correct understanding, please go ahead as soon as
possible without SIP and this is something which is important and needed and
voting on this seems unnecessary.
> Define strongly-typed cluster configuration API
> ---
>
> Key: SOLR-14843
> URL: https://issues.apache.org/jira/browse/SOLR-14843
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Priority: Major
> Labels: clean-api
> Fix For: master (9.0)
>
>
> Current cluster-level configuration uses a hodgepodge of traditional Solr
> config sources (solr.xml, system properties) and the new somewhat arbitrary
> config files kept in ZK ({{/clusterprops.json, /security.json,
> /packages.json, /autoscaling.json}} etc...). There's no uniform
> strongly-typed API to access and manage these configs - currently each config
> source has its own CRUD, often relying on direct access to Zookeeper. There's
> also no uniform method for monitoring changes to these config sources.
> This issue proposes a uniform config API facade with the following
> characteristics:
> * Using a single hierarchical (or at least key-based) facade for accessing
> any global config.
> * Using strongly-typed sub-system configs instead of opaque Map-s:
> components would no longer deal with JSON parsing/writing, instead they would
> use properly annotated Java objects for config CRUD. Config objects would
> include versioning information (eg. lastModified timestamp).
> * Isolating access to the underlying config persistence layer: components
> would no longer directly interact with Zookeeper or files. Most likely the
> default implementation would continue using different ZK files per-subsystem
> in order to limit the complexity of file formats and to reduce the cost of
> notifications for unmodified parts of the configs.
> * Providing uniform way to register listeners for monitoring changes in
> specific configs: components would no longer need to interact with ZK
> watches, they would instead be notified about modified configs that they are
> interested in.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14843) Define strongly-typed cluster configuration API
[
https://issues.apache.org/jira/browse/SOLR-14843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17192425#comment-17192425
]
David Smiley commented on SOLR-14843:
-
Yeah a SIP. Lets look at this in a light-weight way... copy-paste to a
Confluence doc, and start a dev list discussion pointing to it, perhaps with
the same text in the email as well. The dev list discussion enhances
visibility about SIP-worthy matters. The SIP part I'm more dubious on is
voting, but it could be very lazy-consensus -- at some point say what you plan
to do and just start doing it unless you get a veto. CC [~janhoy]
[~ilan] Code/config evolution is a general issue that is not specific to this
proposal. I've seen the first option you list (code2 reads config1) used most
often. It's basically the writer of the code in question to deal with this,
not the platform. It's not clear to me how this proposal would be modified to
handle this concern in the platform itself... and I'm a little skeptical about
wether it should.
> Define strongly-typed cluster configuration API
> ---
>
> Key: SOLR-14843
> URL: https://issues.apache.org/jira/browse/SOLR-14843
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Priority: Major
> Labels: clean-api
> Fix For: master (9.0)
>
>
> Current cluster-level configuration uses a hodgepodge of traditional Solr
> config sources (solr.xml, system properties) and the new somewhat arbitrary
> config files kept in ZK ({{/clusterprops.json, /security.json,
> /packages.json, /autoscaling.json}} etc...). There's no uniform
> strongly-typed API to access and manage these configs - currently each config
> source has its own CRUD, often relying on direct access to Zookeeper. There's
> also no uniform method for monitoring changes to these config sources.
> This issue proposes a uniform config API facade with the following
> characteristics:
> * Using a single hierarchical (or at least key-based) facade for accessing
> any global config.
> * Using strongly-typed sub-system configs instead of opaque Map-s:
> components would no longer deal with JSON parsing/writing, instead they would
> use properly annotated Java objects for config CRUD. Config objects would
> include versioning information (eg. lastModified timestamp).
> * Isolating access to the underlying config persistence layer: components
> would no longer directly interact with Zookeeper or files. Most likely the
> default implementation would continue using different ZK files per-subsystem
> in order to limit the complexity of file formats and to reduce the cost of
> notifications for unmodified parts of the configs.
> * Providing uniform way to register listeners for monitoring changes in
> specific configs: components would no longer need to interact with ZK
> watches, they would instead be notified about modified configs that they are
> interested in.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14843) Define strongly-typed cluster configuration API
[
https://issues.apache.org/jira/browse/SOLR-14843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17192104#comment-17192104
]
Ilan Ginzburg commented on SOLR-14843:
--
I would suggest this new system allows setting default configuration at dev
time or pre deploy time (before ZK is even started) that are reflected in
deployed clusters. Otherwise defaults will live in Java code which is less
convenient to change.
Also would be useful to provide standardized "override using system properties"
as is possible for configuration values defined in {{solr.xml}}.
Finally, cases in which code and configuration need to be deployed atomically
can't be ignored. Old code1 needs config1, new code2 version needs config2. How
do we mange this? Here's a few options (non exhaustive list):
* Updating to code2 while still keeping config1 (assumes code2 knows how to
read and act upon config1) then updating the config to config2 when no more
copies of code1 are running,
* Creating some indirection to have both config1 and config2 present at the
same time, with code1 reading config1 and code2 reading config2,
* Coding such breaking changes (between code1 and code2) as new different code
using totally new config (similar to previous item but implemented by
considering code1 and code2 as totally different rather than two versions of
the same thing).
> Define strongly-typed cluster configuration API
> ---
>
> Key: SOLR-14843
> URL: https://issues.apache.org/jira/browse/SOLR-14843
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Priority: Major
> Labels: clean-api
> Fix For: master (9.0)
>
>
> Current cluster-level configuration uses a hodgepodge of traditional Solr
> config sources (solr.xml, system properties) and the new somewhat arbitrary
> config files kept in ZK ({{/clusterprops.json, /security.json,
> /packages.json, /autoscaling.json}} etc...). There's no uniform
> strongly-typed API to access and manage these configs - currently each config
> source has its own CRUD, often relying on direct access to Zookeeper. There's
> also no uniform method for monitoring changes to these config sources.
> This issue proposes a uniform config API facade with the following
> characteristics:
> * Using a single hierarchical (or at least key-based) facade for accessing
> any global config.
> * Using strongly-typed sub-system configs instead of opaque Map-s:
> components would no longer deal with JSON parsing/writing, instead they would
> use properly annotated Java objects for config CRUD. Config objects would
> include versioning information (eg. lastModified timestamp).
> * Isolating access to the underlying config persistence layer: components
> would no longer directly interact with Zookeeper or files. Most likely the
> default implementation would continue using different ZK files per-subsystem
> in order to limit the complexity of file formats and to reduce the cost of
> notifications for unmodified parts of the configs.
> * Providing uniform way to register listeners for monitoring changes in
> specific configs: components would no longer need to interact with ZK
> watches, they would instead be notified about modified configs that they are
> interested in.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14843) Define strongly-typed cluster configuration API
[
https://issues.apache.org/jira/browse/SOLR-14843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17192099#comment-17192099
]
Ishan Chattopadhyaya commented on SOLR-14843:
-
This warrants a SIP, imho.
> Define strongly-typed cluster configuration API
> ---
>
> Key: SOLR-14843
> URL: https://issues.apache.org/jira/browse/SOLR-14843
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Priority: Major
> Labels: clean-api
> Fix For: master (9.0)
>
>
> Current cluster-level configuration uses a hodgepodge of traditional Solr
> config sources (solr.xml, system properties) and the new somewhat arbitrary
> config files kept in ZK ({{/clusterprops.json, /security.json,
> /packages.json, /autoscaling.json}} etc...). There's no uniform
> strongly-typed API to access and manage these configs - currently each config
> source has its own CRUD, often relying on direct access to Zookeeper. There's
> also no uniform method for monitoring changes to these config sources.
> This issue proposes a uniform config API facade with the following
> characteristics:
> * Using a single hierarchical (or at least key-based) facade for accessing
> any global config.
> * Using strongly-typed sub-system configs instead of opaque Map-s:
> components would no longer deal with JSON parsing/writing, instead they would
> use properly annotated Java objects for config CRUD. Config objects would
> include versioning information (eg. lastModified timestamp).
> * Isolating access to the underlying config persistence layer: components
> would no longer directly interact with Zookeeper or files. Most likely the
> default implementation would continue using different ZK files per-subsystem
> in order to limit the complexity of file formats and to reduce the cost of
> notifications for unmodified parts of the configs.
> * Providing uniform way to register listeners for monitoring changes in
> specific configs: components would no longer need to interact with ZK
> watches, they would instead be notified about modified configs that they are
> interested in.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
