Using `user.toml` to reconfigure an existing service

Habitat Help
1

We have a use-case where we need to reconfigure a host running Habitat services rather than re-provisioning it. We are currently doing this using the following procedure:

hab svc unload <svc>
# update /hab/svc/<svc_name>/user.toml
hab svc load <svc>

The issue we see is that, even though user.toml has been updated, our reloaded service doesn’t pick up the new config values, and we have to do a hab config apply as well.

While not a deal-breaker, we’d rather only inject configs with a single mechanism.

cc @bixu

2

Configuration from hab config apply layers “on top” of anything from a user.toml file, just as a user.toml layers on top of a package’s default.toml.

If you want to configure using only user.toml, you’ll probably want to “reset” your gossip-layer configuration. Running something like echo "" | hab config apply <service.group> $(date +%s) will do that for you.

First, however, you should try putting your user.toml file in /hab/user/<svc_name>/config/user.toml, instead; that’s the “proper” location for it (hab/svc/<svc_name>/user.toml is the older location, and it is not subject to the file-watching mechanism).

1 Like
3

Heya,

You mentioned you are doing a process like:

hab svc unload <svc>
# update /hab/svc/<svc_name>/user.toml
hab svc load <svc>

Is this an automated process that might be happening very quickly?

One thing to note is that unload and load are still async. Because of the way they work, if you quickly unload and then load a service but without any changes that would result in a change to the spec file, then it is possible hab sup won’t do anything at all to your service. See https://github.com/habitat-sh/habitat/issues/4807

That bug, in combination with the fact that you are using a user.toml location that isn’t subject to the file-watcher might be another reason you aren’t seeing a change.

Cheers,

Steven