Discussion: Given Akka Cluster Bootstrap, do we need ConstructR any longer

[hseeberger]

Have you seen Akka Cluster Bootstrap (part of Akka Management): https://github.com/akka/akka-management?

This allows for bootstrapping clusters without central coordination. Pretty cool IMHO. I have tried it with docker-compose: https://github.com/hseeberger/trial-cluster-bootstrap. Works fine.

Now I wonder whether we need ConstructR any longer. What do you think?

[nick-nachos]

I will have to disagree on ConstructR being rendered obsolete in the presence of Akka Cluster Bootstrap. I firmly believe it remains relevant for quite a few users for the time being, and perhaps even in the long run. The reason for this is quite straightforward: most software running today has been created way before Akka Cluster Bootstrap (and Akka itself for that matter); hence, as far as service discovery is concerned, existing systems probably already have adopted some specific approaches which do not stack up with (yet) another one. That is especially the case if a software stack contains components that kind of "impose" the way to go (e.g. Kafka and Zookeeper), and once a choice has been made, there are some very legitimate reasons to stick to it:

• The accumulated experience on a technical and operational level of an existing technology may outweigh the advantages of a new one
• The operational cost of introducing extra components into an already large stack may be prohibiting.
• The advantages of the new technology may be context specific (in this case more Kubernetes friendly/oriented), and thus may not necessarily apply in most cases (how many legacy systems can one realistically expect to be migrated into Kubernetes within the next couple of years?)

Given the above, I would say that one of the main advantages of ConstructR is the freedom it provides of choosing the coordination service backend, and I find that to be a "selling point" that should keep it in the game.

[ktoso]

I would say that one of the main advantages of ConstructR is the freedom it provides of choosing the coordination service backend

Which the bootstrap also allows (will allow), since the "discovery" part is just a trait where you can plug-in whatever discovery mechanism you like. If you have some external system handling these things, and want to remain using it, this will be possible.

The contact points "probing" though is still very valuable, as it allows us to introduce the actual nodes to themselfs and they can coordinate more advanced patterns using this, independently of what discovery is used.

This simply was not implemented yet, as the current impl was put together in 4 days and we wanted to present it quickly to the world ;-)

I don't think it currently renders ConstructR obsolete, but it eventually could if we added discovery using all the mechanisms that @hseeberger and contributors here have implemented. We're open to that and could happily collaborate on that I think :-) So rather than "obsolete", I'd call it a state "things can start to converge", since the commercial conductr has gone away, we're free to make nice useful things in this space.

[juanjovazquez]

For us, it would be essential to maintain support for Consul as coordinator. We would be more than willing to collaborate to make it possible in the context of akka-management taking advantage of the experience gained in the development of constructr-consul.

[ktoso]

Cool, thanks for chiming in! I'll be cleaning up things this week there and lay out a plan how to contribute alternative discovery impls then. Thanks in advance! I'll ping here once more info can be shared.

[hseeberger]

Great! Looking forward to converge ;-)

[hseeberger]

@juanjovazquez BTW, with the current approach/implementation there is no central coordination in Akka Cluster Bootstrap.

[juanjovazquez]

@hseeberger Thanks for bringing that up. I imagine that we'll be able to find the way to adapt the k8 version to Consul. I hope at least... ;-)

[hseeberger]

k8 was only used as an example. I have another example running in Docker. The only thing that is needed/used in the current version of Akka Cluster Bootstrap is DNS. It serves the purpose of etcd, Consul, etc. in ConstructR, but without the coordination aspects (no locks, just registration of node addresses).

So if you do not want to use DNS, you could easily implement a Consul "backend" – easily because your current backend already should do more than necessary for Akka Cluster Bootstrap.

[ktoso]

Yup, it's as Heiko explained. Putting the existing impls to use for Bootstrap should be rather simple.
Really looking forward to this. I'll work on it more tomorrow

[juanjovazquez]

Got it. It sounds great!. Please, ask for help if you need it.

[markusjura]

Also happy to contribute a zookeeper backend implementation to Akka Cluster Bootstrap. Could do that in the week before Christmas.

[nick-nachos]

@ktoso the suggestion to incorporate multiple strategies into the bootstrap extension does seem very promising indeed. However, after reviewing the source code of akka bootstrap, I can see one major limitation, which is that single node clusters are not supported. In fact, there is a note related to this issue in ClusterBootstrapSettings.scala:

val requiredContactPointsNr: Int = discoveryConfig.getInt("required-contact-point-nr")
    require(requiredContactPointsNr >= 2,
      "Number of contact points must be greater than 1. " +
      "For 'single node clusters' simply avoid using the seed bootstraping process, and issue a self-join manually.")

I am not sure whether this limitation (i.e. avoiding using a single contact point to retrieve seed nodes) is some hard rule in the context of the chosen algorithm, but - especially if it is - it's a limitation that it is very difficult for consumers to adapt to. The whole point of a discovery service is to eliminate the need of knowing a cluster's structure prior to run-time. As an example, we have a very common case where a single "special" node may have to form a cluster on its own, and start operating as a cluster node in a seamless manner (i.e. unaware of the fact that it is alone in the cluster) while other nodes may jump in much later (or not at all). The node must start working immediately despite the absence of the rest, and it is not acceptable if it cannot bootstrap until a second node tries to join as well. However, for the same cluster, it may be the case that this "special" node may not be required, thus the rest of the nodes will form the cluster on their own. The discovery service allows us to uniformly address these scenarios.

To your knowledge, is the single node cluster issue something that can be worked around by the bootstrap module, or is having more that one contact points a hard requirement?

[hseeberger]

I bet this is not a general limitation, but just the current state of affairs.

[ktoso]

That's a lot of text and serious wording for a small default requirement change @nick-nachos ;-)
It allows 1 node now in 0.7, while it's a terrible idea, it's allowed yeah.

All, please see https://github.com/akka/akka-management as 0.7 and the modularisation has been merged. Please do contribute modules to akka-discovery if you'd like to do so! The interface currently is very naive, and may change, but let's get this started like this. See the akka-discovery-dns for a simple example.

[eshepelyuk]

@hseeberger have you deleted docker compose example on a purpose ?
may you restore that repo or fix link in a first post ?