3:40 p.m.
On Sep 13, 2016, at 5:46 AM, Tristan Tarrant
<ttarrant(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat