I think there are still open questions based on people comments in this
email thread and in SOLR-5955. Seems like the concept of mutable/immutable
ConfigSet should be supported but not forced. Then, what is an mutable
ConfigSet? one that can be edited via API calls? then, should those Config
APIs
but I think it would be better if the mutable part is placed under
/collections/x/..., otherwise /configs
it makes sense.
The problem we have is managedschema currently writes to the same
If we could change the managedschema behavior somehow it would have been better
On Fri, May 22, 2015 at
Makes sense Greg.
Just looking at it from the ZK perspective (APIs aside), the original
idea behind referencing a config set by name was so that you could
change it in one place and everyone relying on it would get the
changes.
If one wants collections to have separate independent config sets
TLDR: we should think about this as configset base vs per-collection diff,
not as immutable base vs per-collection mutable.
Makes sense, I was mostly thinking of it being immutable from the current
Config APIs. Editing a configset for multiple collection is a valid and
useful feature, the
I'm +1 on the general idea, but I'm not convinced about the
mutable/immutable separation.
Do we not think it is valid to modify a single config(set) that affects
multiple collections? I can imagine a case where my data with the same
config(set) is partitioned into many different collections,
I created https://issues.apache.org/jira/browse/SOLR-7570
On Fri, May 15, 2015 at 10:31 AM, Alan Woodward a...@flax.co.uk wrote:
+1
A nice way of doing it would be to make it part of the SolrResourceLoader
interface. The ZK resource loader could check in the collection-specific
zknode
I think this needs more discussion
When a collection is created we should have two things
an immutable part and a mutable part
for instance my collection name is x and it uses schemaless example conf
I must now have two conf dirs
configs/schemaless and
configs/x
all the mutable stuff goes to
+1 Tomas.
On Fri, May 15, 2015 at 12:40 PM Tomás Fernández Löbbe
tomasflo...@gmail.com wrote:
I agree about differentiating the mutable part (configoverlay, generated
schema, etc) and the immutable (the configset) , but I think it would be
better if the mutable part is placed under
I agree about differentiating the mutable part (configoverlay, generated
schema, etc) and the immutable (the configset) , but I think it would be
better if the mutable part is placed under /collections/x/..., otherwise
/configs would have a mix of ConfigSets and collection-specific
configuration.
+1
A nice way of doing it would be to make it part of the SolrResourceLoader
interface. The ZK resource loader could check in the collection-specific
zknode first, and then under configs/, and we could add a writeResource()
method that writes to the collection-specific node as well. Then all
I think this is fine.I don't think we need a new concept of config
templates, we just need to make it clear that the configset used to create
the collection is not modified by Solr, and that any change done via API
only affects the single collection where the config command is issued.
I guess the
I think the concept of ConfigSets has become a bit confusing with the
Config APIs (I'm thinking in SolrCloud mode here). Solr requires that a
configset is pushed to ZooKeeper before creating a collection that uses it.
It supports multiple collections using the same configset, which I think is
I agree with you on the point that it causes confusion.
My suggestion would be to have something called config templates and they
are immutable . So , we don't need a configset API
each collection have it's own conf folder .
So, when a collection is created we should go ahead and create a
13 matches
Mail list logo
