rfc-183 Missing Node approval

[bjhargrave]

Original bug ID: BZ#194
From: @juergen-albert
Reported version: unspecified

[bjhargrave]

Comment author: @juergen-albert

After a Node is attached announced its present in a cluster, it might be a good idea to have a mode in the cluster, where nodes need to be approved before they can join.

This can have e.g. Security reasons, so none can attache a evil node. Another reason could be, that a node might need to be configured in the right way before it can join.

[bjhargrave]

Comment author: @bjhargrave

*** Bug BZ#195 has been marked as a duplicate of this bug. ***

[bjhargrave]

Comment author: @tverbele

I don't think you can avoid someone to register a NodeStatus service in whichever system. I guess the client that is consuming the NodeStatus services is responsible for deciding whether or not to trust NodeStatus services in the system?

[bjhargrave]

Comment author: @maho7791

It is not about avoiding registering a NodeStatus service. Its is more about allowing a certain new node to participate in the cluster as a trusted member.

Sure, some member has to decide whether or not to trust a new node. As default you can use an auto-approve mode, that trusts all new nodes. We think there should be a more manually way to approve a new node (via user interaction like UI or command).

[bjhargrave]

Comment author: @juergen-albert

As discussed: The RFC utilizes remote services to provide the Framework Admin Serivce. Thus the Remote Service should provide a way to reject or accept participants. As David mentioned, there might be already a possibility to do something like that. @ David What was the name of the Service/Manager again that could do something like this?

[bjhargrave]

Comment author: @bosschaert

@ Jürgen - yes RSA defines an entity called 'Topoology Manager' (chapter 122.3) and every RSA implementation comes with a default one, but they should be replaceable.

The topology manager decides what remote services are published to a discovery mechanism and also decides what remote services are imported. The default one simply exports/imports everything available from the RemoteServiceAdmin service.

The Topology Manager itself generally works with Endpoint Event Listeners listeners, which are also used by the Discovery agents.

A special implementation of such Topology Manager could support an approval workflow of some sort. This would already be possible with the current RSA APIs, and it would be another operational policy of some sort. https://osgi.org/javadoc/r6/enterprise/org/osgi/service/remoteserviceadmin/namespace/TopologyNamespace.html already contains some 'example' policies for topology managers, but a topology manager could implement any other ones too.

[bjhargrave]

Comment author: Bradley <bradley2844maximus@gmx.com>

I think it will be best to stick to RFC. ,http://internetvergelijken.nl