Generally, what is the process? As far as I can tell its not really documented anywhere as to: when, why, how, one would go about getting a project merged into the core set of plans (of course it’s been one of those weeks so I may have just missed it and cm comes to link me to the page). Maybe this deserves an RFC? (I read the RFC for RFCs, I love it, it’s perfectly meta… so that’s why a tentative maybe…)
Specifically, if I had a consul-client plan that I wanted to pull into core… How would I go about that? I might “Shameless plug for my own blog warining” show how it could be useful (i.e. leveraging Consul’s service config notation to register services… and being able to more easily “lift and shift” by integrating existing tools with new ones)
Because sometimes I just need a versioned KV store, or a DNS lookup of a service… and the habitat supervisor is just not convenient enough. Since habitat makes it SO EASY! to build a consul cluster and clients, I figure it’s a good counterpart to the existing consul cookbook.
Finally, I have some selfish reasons for wanting to get it pulled in, but would prefer not to broadcast that here. (happy to discuss in slack/zoom/etc)
Plans are accepting into the core origin after a community member submits a pull request to the core-plans repository. This generally follows a few simples rules though:
Plans are kept generic (simple / standard configs you would see form any other package manager
Plans are packaging non-edge software (no pre-release software)
I think you could take a look at the consul plan already in core-plans, as that may serve your needs. If you want to extend this by providing more use-case specific configuration, that would more than likely belong in a configuration plan. These are plans that include a dependency to include the binary, and ship their own (more specific / custom) configuration.
Examples of this can be found in a number of places, but here is one that ships a web application, and does a configuration plan approach, wrapping nginx, and shipping its own configuration: https://github.com/predominant/slacker-ui/tree/master/habitat
First of all, I think I meet those two criteria!!! but, where would I find that if not for you? and perhaps there should be more stringent requirements…? IDK, maybe not…
To your point, I’ve considered it at length… [1][2][3] and I’m certainly open to suggestions. But there’s a few things that make having “server” and “client” habitat package (even though it’s the same binary with different attributes/configs) facilitate. Namely, bindings. (need to bind to a service locally? bind to service:hostname. so if I need service 1, then service 2, start them as hab svc start me/service1 --group $HOSTNAME; hab svc start me/service2 --bind=service1:$HOSTNAME)
Also, there’s a segregation of duties with Consul, unlike habitat where every “supervisor” participates in gossip (and really I’d like someone to draw me a diagram one day…) Consul delineates between server and agent in that the agents only participate in gossip between the “servers” it’s closer to a hub a spoke model… so again, I think the case is there for two different packages.
Finally, I am a contributor, to the core/consul plan, so I think it’s fair to say that core/consul does not meet my needs.
With regard to keeping config simple, similar to other package managers, I don’t think there is an RFC for that as yet, but similar conversations have been had: https://github.com/habitat-sh/core-plans/pull/585
@reset makes some great comments here about moving towards more of a binary-only plan, which is where I think consul belongs too.
so that’s why a tentative maybe…)