[
https://issues.apache.org/jira/browse/SOLR-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14556994#comment-14556994
]
Gregory Chanan commented on SOLR-5955:
--------------------------------------
Some thoughts on this and SOLR-7570:
1) The motivation here is really about having some immutability around
configsets. This is important in a couple of scenarios:
a) you want built-in immutable templates that people can use to get started
quickly. This should be immutable so no one else accidently screws it up.
b) in a secure setup, you don't want end-users to write directly to zookeeper
or to disk. We've seen security complaints when we've allowed that sort of
thing in the past. Providing an immutable template that end-users can build on
and modify via Config APIs is much more sensible. Again, you want to make this
immutable so no one accidently or maliciously screws up the template.
2) A template is really just an immutable configset where instantiating creates
a mutable copy
>From a complexity POV, It seems not worth it to maintain a separate "template"
>concept if mutability is the only difference from configsets. I.e. templates
>are stored in a different location in ZK, have different zkcli commands that
>need to be maintained, would need to have separate handling from ConfigSets in
>a UI, require a different paramter in the CollectionsAPI for instantiation
>("configTemplate" above). If ConfigSets could be marked as mutable vs
>immutable, a ConfigSet API could have reasonable semantics here, like copying
>an immutable configset makes a mutable copy (since making an immutable copy
>seems pointless), or that copy is disallowed on immutable ConfigSets, instead
>you have to call a different command like "instantiate" instead. Anshum's
>idea above (/collections/collection_name/config/xxx could be implemented in
>this setup, by just creating a collection-specific mutable diff as described
>in SOLR-7570. From an engineering complexity perspective, maintaining
>mutable-vs-immutable seems a lot simpler than having templates.
That said, from the end-user-perspective referring to immutable configsets as
"templates" is great -- I think most users would immediately understand what
that means and why it is important rather than "immutable configsets." Perhaps
the correct way to go here is to allow (do we already?) configs in
subdirectories, e.g. we put all "immutable configsets" under /configs/templates
and we can refer to them as "templates" in the documentation, but they don't
need any special handling in the code compared to ConfigSets (i.e. you could
create a collection in one step via
&collection.configName=template/secureTemplate.
So, TLDR: we should have the concept of immutable ConfigSets, we don't need a
separate concept of templates. Thoughts?
> Add config templates to SolrCloud.
> ----------------------------------
>
> Key: SOLR-5955
> URL: https://issues.apache.org/jira/browse/SOLR-5955
> Project: Solr
> Issue Type: New Feature
> Reporter: Mark Miller
> Attachments: SOLR-5955.patch
>
>
> You should be able to upload config sets to a templates location and then
> specify a template as your starting config when creating new collections via
> REST API. We can have a default template that we ship with.
> This will let you create collections from scratch via REST API, and then you
> can use things like the schema REST API to customize the template config to
> your needs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
