[wildfly-dev] Subsystems changing their own configuration model

[Brian Stansberry]

> On Sep 13, 2016, at 5:46 AM, Tristan Tarrant <ttarrant at redhat.com> wrote:
> 
> We would like to allow a subsystem to modify its configuration model by 
> itself at runtime. The use case for this is that we would like to let a 
> remote Hot Rod client create a cache on an Infinispan server and making 
> that configuration persistent across restarts. I understand this is 
> creating management ops which are orthogonal to the server’s.
> 

There is nothing fundamental that says you can’t do this so long as you’re not trying to execute these ops as part of the start/stop of an MSC service. It doesn’t sound like that’s the case.

It does sound though like you want to expose management over the non-management interface. That’s a significant security hole.


> I guess that in standalone mode this wouldn't be too much of an issue, 
> with two caveats:
> - all nodes in a cluster should apply the changes to their own 
> configuration, leveraging the model rollback mechanism to handle 
> failures on other nodes

There is no multi-process model rollback mechanism with standalone servers.

> - new nodes joining the cluster (and therefore with a possibly outdated 
> configuration) would receive the configuration of caches already running 
> in the cluster and applying them locally
> 

How does this happen?

> The real tricky bit is obviously domain mode. The server receiving the 
> cache creation request would need to delegate it to the DC who would 
> then apply it across the profile. However this clashes with the fact 
> that, as far as I know, there is no way for a server to communicate with 
> its DC. Is this type of functionality planned ?
> 

Not actively. We looked into it a bit in the context of DOMAIN_PING but for that use case it became apparent that invoking a bunch of management ops against the DC was a non-scalable solution. This sounds different; a server would need to figure out what profile stores the infinispan subsystem config (it may not be the final one associated with the server group since profile x can include profile y) and then make a change to that profile. That’s scalable.

If we set up this kind of connection we’d need to ensure the caller’s security context propagates. Having an external request come in to a server and then get treated by the DC as if it were from a trusted caller like a slave HC or server would be bad.

> I have created a document which describes what we'd like to do at [1]
> 
> Tristan
> 
> 
> [1] https://github.com/infinispan/infinispan/wiki/Create-Cache-over-HotRod
> 
> -- 
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat