Variables in default.toml - hab config apply in run hook

Habitat Help
1

Hi all a few weeks back I posted some stuff in slack regarding the need to do a hab config apply in run hook to gather some information or allow variable information in the default.toml.

First Use Case

Variables in toml

My case comes from a situation of an unknown fqdn. We currently have multiple domain suffixes and based on the model we make no assumptions where the hab package will be used. Currently we can only return a host name from the habitat help information and not the fqdn for the host. if we were able to source hostname -f or some equivalent inside the default.toml. That would allow us to gather the fqdn from the bind to setup connections. Currently connecting haproxy to an ip vs a hostname - which poses it own issues because 127.0.0.1 Issue.

Second Case

hab config apply in hook

This one is related to a service that is brand new and has no prior configuration. We use an app that secures all communication with a certificate and shares that cert with the members of it service group. The current method is - stand up the servers and app with no cert present for the app. Wait for leader election to occur. Once a leader is elected the leader generates a cert and writes it to a toml file and uses that toml as the input to a config apply for the service group. This scenario also satisfies the first case where we seed an empty field in the toml and when the server stands up with fill in the fqdn. And source that as a bind export.

I believe there are some more cases and hopefully that gives a enough of a rough idea with what we are looking for.

2

For the first use case, can you go into a bit more detail? Is the idea that you want to include the fqdn in the pkg_exports data so that it's communicated across service groups? How is that fqdn being used? Presumably the two service groups are aware of each other, so when you say

I'm assuming you're talking about connections outside of habitized services. Otherwise, it seems like using the binding mechanism directly would suffice.

3

I don’t specifically want it across service groups - meaning I don’t need service1.default to know about it I need hab svc load myorigin/service2 --bind server:service1.default to know about the fqdn for service1.default. - They could possibly live in separate domains and have no knowledge of other domains that exist.