Looks best to file that as a Lucidworks support ticket.
But are you using the time-based sharding feature of Fusion? If that's the
case that might explain it as that creates collections for each time partition.
Erik
> On Dec 7, 2016, at 00:31, Nicole Bilić <nicole.bil...@gmail.com> wrote:
>
> Hi all,
>
>
> We are using Lucidworks Fusion on top of Solr and recently we’ve
> encountered an unexpected behavior. We’ve created bash scripts which we use
> to create collections in Solr using the Fusion API and upload the
> collection configuration (with bash $ZKCLIENT -cmd upconfig -confdir $path
> -confname $collection -z $HOST:$ZKPORT).
>
> We had issues that the index fields of our custom configurations were not
> available (ie. our custom field types and fields we’ve defined in
> managed-schema). So we checked in Solr admin and found out that the
> configuration folder for the collection was generated with
> <collectionname><id> instead of just <collectionname> (eg.
> https://drive.google.com/file/d/0B9Nu5vSE4ep8OUdyckZoV2FMdlE/view?usp=sharing).
>
>
> Our collection configurations are under the one with the id in the end. So
> the configuration set that was uploaded by our scripts was never used and
> therefore the index fields were not existing. Also, we did not manage to
> discover a pattern (or cause) for when does this happen (because sometimes
> the issue does not occur and sometimes it does and to us it seems pretty
> nondeterministic).
>
> Furthermore, in the screenshot above, it’s possible to see the same thing
> happened with system_metrics collection configs, which we do not create or
> modify with our scripts. Therefore, the scripts should not be the cause of
> this behavior.
>
> What we are trying to determine is if this issue is coming from Fusion,
> Solr or Zookeeper. Does someone know in which case the collection
> configuration folder is generated with the id in the end and how to avoid
> it? Thank you!
>
>
> Nicole
