Use a custom service name for Hyperbahn ringpop
Opened this issue · 1 comments
A ringpop application joined the Hyperbahn cluster. It used ringpop
as the service name for internal gossip, but due to lack of library support, it ended up talking to Hyperbahn's ringpop.
In this case, it only received one unknown request (destined for a stooge) which it declined, but this seems too dangerous. We should be using a service name like hyperbahn-ringpop
so that any bugs or misconfigurations in other applications don't affect Hyperbahn.
This should not happen.
Ringpop has a "app" name that it uses in the join() request.
Ringpop-node should reject ringpop-go membvers for foo-app to join.
I'd rather keep the canonical "ringpop" name and add some other kind of protection like changing the name of the ringpop "app" to a full gitolite remote.
To be able to do this extra defensive check we might need to extend ringpop to allow multiple apps during a deploy and use two deploys; one to add a gitolite remote based name and a second to remove the old hyperbahn app name.
cc @jwolski