[
https://issues.apache.org/jira/browse/SOLR-12224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16441281#comment-16441281
]
Jason Gerlowski edited comment on SOLR-12224 at 4/17/18 6:09 PM:
-----------------------------------------------------------------
Small +1 to including the collection props in CLUSTERSTATUS. I get your point
Shawn, that CLUSTERSTATUS is supposed to be about the cluster, not the
collection. But "holding the line" on that distinction seems like a lost
battle: we already allow filtering CLUSTERSTATUS by the collection(s)/shard(s)
you care about, and the API includes many other bits of collection state in the
response (shard hash ranges, replica/shard state, leadership, etc.). I'm not
sure what's more intuitive in general, but speaking only for myself,
CLUSTERSTATUS is usually the API I think to hit when I want to see the overview
for a collection (which in my mind includes any properties). I don't care
strongly, just my 2 cents.
I'm curious too whether anyone cares how this is exposed in the v2 API. That's
the "future" I guess, so worth some discussion. Would we expose this under
{{GET v2/c/collection-name}} (which lines up pretty well with
{{action=CLUSTERSTATUS&collection=collection-name}}), or does it deserve its
own collection subpath, like {{GET v2/c/collection-name/properties}}?
was (Author: gerlowskija):
Small +1 to including the collection props in CLUSTERSTATUS. I get your point
Shawn, that CLUSTERSTATUS is supposed to be about the cluster, not the
collection. But "holding the line" on that distinction seems like a lost
battle: we already allow filtering CLUSTERSTATUS by the collection(s)/shard(s)
you care about, and the API includes many other bits of collection state in the
response (shard hash ranges, replica/shard state, leadership, etc.). I'm not
sure what's more intuitive in general, but speaking only for myself,
CLUSTERSTATUS is usually the API I think to hit when I want to see the overview
for a collection. I don't care strongly, just my 2 cents.
I'm curious too whether anyone cares how this is exposed in the v2 API. That's
the "future" I guess, so worth some discussion. Would we expose this under
{{GET v2/c/collection-name}} (which lines up pretty well with
{{action=CLUSTERSTATUS&collection=collection-name}}), or does it deserve its
own collection subpath, like {{GET v2/c/collection-name/properties}}?
> there is no API to read collection properties
> ---------------------------------------------
>
> Key: SOLR-12224
> URL: https://issues.apache.org/jira/browse/SOLR-12224
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
> Affects Versions: 7.3
> Reporter: Hendrik Haddorp
> Priority: Major
>
> Solr 7.3 added the COLLECTIONPROP API call
> (https://lucene.apache.org/solr/guide/7_3/collections-api.html#collectionprop)
> that allows to set arbitrary properties on a collection. There is however no
> API call that returns the data. The only option is to manually read out the
> collectionprops.json file in ZK below the collection.
> Options could be that the COLLECTIONPROP command has an option to retrieve
> properties, have a special command to list the properties and/or to have the
> properties listed in the clusterstatus output for a collection.
> Would be great if SolrJ would also be supported.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
