Jan, We are actually saying the same things, but differently. Today we have only 2 roles
- data - overseer We have set default values for them . A user who starts a 9.0 Solr will get the default behavior and it is the same exact behavior as we get in 8x. Imagine you introduce a new role "xyz" . As a dev building this feature, you may choose to not enable it by default if - The feature alters the default behavior of Solr - It's expensive (consumes disk,threads, memory etc) - or may require some local data which is not available in all nodes In that case the role writer will decide what should be a sensible default On Thu, Dec 9, 2021 at 1:55 AM Jan Høydahl <[email protected]> wrote: > > > > > My proposal is that ALL roles are always ALLOW if not specified > explicitly. > > > > As explained several times before, this is a problem for new roles > introduced in future. > > Those roles will get turned on on all nodes after an upgrade, whether a > user wants or not. > > But you're not hearing me. This is a constructed problem assuming that we > recommend users with huge clusters to start without explicitly specifying > roles. > Small custers with limited load will run happily without specifying roles. > Thus a 3-node cluster will have ALL features available on ANY node without > doing anything. Exactly like in 8.x > And large clusters with the need for specialized nodes will specify roles > on EVERY node. > > > A user explicitly mentions which roles his nodes want to assume, but > after an upgrade he/she sees that node performing a new role. This is > confusing. > > > You are misunderstanding. The premise for the roles feature from the > beginning was to embrace a transparent and super simple notion that once > you start specifying solr.node.roles=foo,bar explicitly, then the nodes > will ALLOW exactly that set of roles, nothing more, nothing less. > > So imagine a cluster running 9.0 with each node specifying roles > explicitly. And you upgrade to 9.1 which introduces a new role 'sql'. Then, > when planning the upgrade to 9.1 the user asks himself whether they need > the SQL feature or not. They can then go about the upgrade along three paths > A) No need for SQL, do nothing > B) Using SQL, but want all existing nodes to run sql: Add the 'sql' role > to all nodes during upgrade > C) Using SQL, wish 3 dedicated nodes for it: Add the 'sql' role to three > dedicated nodes during upgrade > > I think the extra complexity of "data:on", "data:off", "overseer:allow" > etc comes from your assumption that large clusters will run without > explicitly specifying roles, or that some of the nodes will not specify > roles. Or that newly added roles somehow should become active on a new > version even if you have explicitly specified roles on all nodes. > > I agree that some roles may need additional configuration, but I'm not > sure that forcing that configuration into something you have to parse from > the role-property itself is the best way to go. Perhpas each role can > decide its mode of operation depending on whatever factors and > configuration that that role needs. For the overseer, it may in the first > phase work as today, that it interprets solr.node.role=overseer as a > preference. And in some future version it may read an additional property > solr.overseer.priority=3 to give some priority to it, or it could read some > solr.overseer.strict=true to refuse to place overseer strictly on nodes > with the role. I think it is premature to tackle any future role needs in > the first version of the framework. > > Jan > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- ----------------------------------------------------- Noble Paul
