Brief description of package
Names of core plans maintainers (The Habitat Maintainers [email protected] is usually sufficient)
This should state whether the package is a service package or a binary package.
A service package is something that will be run by the Habitat supervisor (i.e. core/postgresql). A service package must always have a run file or define pkg_svc_run in the plan.sh file.
Checkout the documentation for binary wrapper packages for more clarity on binary packages.
How would a user use this package? i.e. can a user simply call the package as a dependency of their application? Or is there more they need to do?
(This is only required for service packages, not binary wrapper packages))
How do other services that want to consume this service bind to it?
Checkout the core/postgresql README for a good example of this.
(This is only required for service packages, not binary wrapper packages)
What topologies does this plan support?
(This is only required for service packages, not binary wrapper packages)
Check out the Habitat docs on standalone for more details on what the standalone topology is and what it does.
If this plan can be used with the standalone topology, how do you do it?
Checkout the core/postgresql README for a good example of this.
(This is only required for service packages, not binary wrapper packages))
If this plan can be used with the leader/follower topology, how do you do it?
Check out the Habitat docs on Leader-Follower for more details on what the leader-follower topology is and what it does.
Checkout the core/postgresql README for a good example of this (look under the Clustering heading)
(This is only required for service packages, not binary wrapper packages))
What update strategies would work best for this plan?
Checkout the update strategy documentation for information on the strategies Habitat supports.
(This is only required for service packages, not binary wrapper packages))
Checkout the configuration update documentation for more information on what configuration updates are and how they are executed.
Link to the plan's default.toml file to list all the configurable values of the plan.
If your plan has configuration values that require a complete rebuild when updated, note those here.
(This is only required for service packages, not binary wrapper packages))
(Optional, but recommended)
How would a user scale this service?
(This is only required for service packages, not binary wrapper packages))
(Optional, but recommended)
How would a user monitor the health of this surface at the application layer?
(Optional)
Anything that does not fit in the above sections should go here - i.e. how does this fit into a user's development workflow?