Not Easy Finding the "First Peer" without DNS

[fujin]

It would be dope if I could say this by name and let it figure out the IP address. Should I be adding DNS for it? Something like skydns2/Consul-based DNS to "find" leaders?

Please close if invalid, I may not have figured out the correct way to do this.

Observed: all/current

hab start -t leader core/redis --peer 172.17.0.4

Expected:

hab start -t leader core/redis --friends

[adamhjk]

We haven't really decided what to do here. One thing we've thought is that you should have a few, static supervisors with persistence turned on. Then you can use those for the bootstrapping.

One idea we had was that we should build a simple service that handles taking configuration out of source control and managing the revisions in the ring - and that could be the central "core" peer.

Certainly you could put that in an round robin DNS. Happy to hear other thoughts.

[spheromak]

@adamhjk CoreOS did a simple bootstrapping service for etcd where you would register to that, and then it could reflect to your registered supervisors. So some sort of simple external/bootstrap service registry. You could also add support for consul/etcd/ZK directly for that role for folks that might already have service disco laying around.

[janeczku]

One option would be to use mDNS to auto-discover peers for bootstrapping.

[adamhjk]

I don't actually understand what the upside of adding a consul/etcd/zk support would be here - you would have to specify those peers in order to figure out the peers from them. It's the same problem, just pushed to another layer of infrastructure.

mDNS is a good idea.

Our wire protocol is pretty simple - another choice would be to do a sweep of each interfaces address space, sending a small UDP packet. Extend the protocol inside habitat to let it be a discovery ping, with an ack(peer) on reply.

[smurawski]

We definitely need to tackle this problem, but for the time being having a few static peers or DNS entry that points to one (or more) long lived peers gets us going. After there's a bit more stuff out running in a supervisor, we might have a better idea of where to put the effort into solving the "first peer" problem.

[moretea]

This would be an issue in a kubernetes deployment as well.

[bdangit]

Agree with @moretea. I had posted this on the forum to get some ideas on how to alleviate this pain. https://forums.habitat.sh/t/kubernetes-and-habitats-service-discovery/165

[moretea]

I solved this for kubernetes in: https://github.com/ContainerSolutions/bootstrap-habitat-supervisors-on-k8s

[jamessewell]

Any progress here?

[christophermaier]

I believe this is handled in Kubernetes with the Habitat Operator and the --peer-watch-file option, but we haven't yet done anything for "pure Habitat" along these lines just yet (e.g. mDNS, etc.)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.

[stale]

This issue has been automatically closed after being stale for 400 days. We still value your input and contribution. Please re-open the issue if desired and leave a comment with details.