I didn't know about this multi delete either, it must have been introduced for a reason? If you e.g. want to reduce "replicationFactor" from 5 to 3, it will not work to update collectionProp "replicationFactor", not even the individual num<type> props. That would be the natural way for this feature to work, update the collectionProperty of choice and Solr will adjust by deleting replicas. But I guess that is a tangent to this particular API, although it should be synced the other way too, deleting a replica across a collection should update the collectionProp for that replica type.
So I guess I perhaps prefer a "declarative" approach here? At least for the managed routing. For implicit routing it makes more sense to have a different number of replicas across shards for the same collection. Jan > 10. mai 2023 kl. 19:52 skrev Jason Gerlowski <gerlowsk...@gmail.com>: > > I didn't include the collection name in my abbreviated URL, but it is > a required parameter on DELETEREPLICA requests, yep. > > Historically, DELETEREPLICA is covered by the "collection-admin-edit" > predefined permission, which is usually given to admins. Which is > consistent with our other cluster-topology-modifying APIs. That > predefined permission isn't collection-scoped afaik, though users > should be able to define custom permissions that would be collection > scoped. > > Of course, authorization around this API is necessary but not > sufficient from a safety standpoint. It may or may not be a good idea > to let even authorized users nuke N replicas without specifying the > replica-type they want deleted, for instance. > > Best, > > Jason > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
