If it had some more intelligence it would not be a bad feature. The alternative for users working with very large systems is complicated scripting.
On Thu, May 11, 2023 at 4:09 AM Jan Høydahl <jan....@cominvent.com> wrote: > 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 > > -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
