Automatically generate a suitably high incarnation number for `hab config apply`, `hab file upload`

[christophermaier]

The hab config apply and hab file upload commands currently require you to explicitly provide an incarnation number, because these commands inject rumors directly into the Habitat network.

This is a large point of confusion for many people. In fact, we commonly advise people to use the idiom:

hab config apply my-app.default $(date +%s) /path/to/the/file

since the date invocation will generate a monotonically increasing number. Rumors are accepted as "new" if they have a higher incarnation number than any currently-circulating rumors of the same type, so a number based on the current time will be bigger than any existing incarnation numbers (provided, of course, you've been using this idiom from the beginning).

This requirement is a direct result of the underlying implementation, and the number doesn't serve any other purpose for the user.

These commands should basically do this on behalf of the user. We could accept an explicit number as an option if we really wanted to, but it's difficult to see where that would be useful.

[adamhjk]

It’s not really. Clocks get out of sync, the number you have might not be the highest in the network. When this fails, will it be even more mysterious?

If we switch to using seconds since the epoch by default, you must provide an escape hatch. Also, time zones will now be in play.

[christophermaier]

@adamhjk It seems like you'd run into the same problems whether you typed $(date +%s) or if hab config apply "typed" it for you. My concern here is that we're (in my opinion) needlessly exposing a rather arcane bit of implementation details to users, who should need to know it. If a user is invoking hab config apply, they are, by virtue of typing that command, signaling their intent that the configuration they're supplying should become the active configuration rumor. Having to also know what the current number happens to be seems like unnecessary overhead, particularly since we don't really provide a good way to discover what that number actually is. In any event, whether we take care of ensuring that the config we're given "wins", or the user is completely responsible, our current UX still isn't providing anything in the way of actionable feedback. You ultimately notice that your config didn't "take", and you end up re-running hab config apply with an even bigger number until it works.

I don't necessarily mean that we literally execute the equivalent of date +%s for the user (because clocks do get out of sync, time zones are a thing, etc., as you point out). My chief concern is from a UX perspective; if we can make hab config apply "just work", that feels like a cleaner, more understandable experience. However we end up implementing that is a less important concern to me.

[jeremymv2]

Ideally the new UX will still allow the old style incantation to work. Otherwise, people will need to change places like here and there

[christophermaier]

@jeremymv2 Yup, I'm all for escape hatches and backwards compatibility wherever we can do that! It may mean that we'd dole out the implementation in chunks to smooth the migration process, rather than doing it all at once and making life needlessly rough for downstream users of the CLI.

Feature flags are another mechanism by which we could roll things out. There's a number of ways we could do it.

Thanks for pointing those usecases out @jeremymv2 ; it's very helpful 👍

[stale[bot]]

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.

[christophermaier]

This is still a big issue.

[themightychris]

This falls into the bucket of "things that make you cringe when you're walking a first-time user through an introductory workflow and have to explain why they have to do something extra to make it work as they'd expect"

[stale[bot]]

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.