I’m a the middle of an experimentation process where my end goal is a tiny nomad cluster using consul and fabio for service discovery and routing where I can deploy using waypoint.
Everything else seems to fit together except I can’t find any resources on how to describe a nomad service stanza in waypoint, or anything like the release stanza that is afforded to kubernetes. My expectation is once the waypoint configuration is converted into a job it would automatically register my new service with consul and have the new route available with fabio(or HAProxy)
Am I missing something? If so could someone point me to the right resources? And if not. Is it a planned feature? And when does it become available?
It seems like the intentions behind these changes are centered around product adoption. Mainly for users who are currently using “pre-existing deployment tooling” as mentioned in Mutable Deployment Support · Issue #1235 · hashicorp/waypoint · GitHub. I think this is a smart move.
However, for users who do follow the opinionated workflow it feels like a step in a different direction. Take the current topic for example. Enabling service discovery with consul on deploy/release seems like reasonable behavior. This is further compounded given the already symbiotic relationship between the two hashicorp products. Having to “drop back” to using a full fledged nomad jobspec seems less than ideal. Especially considering that users of the waypoint model most likely wouldn’t have a pre-existing jobspec. This also eliminates the abstraction waypoint provides.
Waypoint users should want to avoid having to use the underlying resource like the plague. To be fair having to write a nomad job in general is not bad. If this was a k8s resource file we were talking about though…
In summary, having the ability to use a nomad jobspec is definitely a nice introduction for new adopters. However, I think there is still a need to support this functionality outside of that feature for users who have adopted the waypoint model.
Hey @dgparker! Your read on this is exactly right, including the tensions.
One of the significant points of friction we found with early Waypoint adopters was (1) they had to rewrite things into “the Waypoint way” and/or (2) they wanted feature support that the opinionated way didn’t support yet.
For WP 0.4 (unreleased at time of this post but coming soon), we introduced the concept of “mutable deployments” which enabled us to write plugins such as the nomad-jobspec plugin you referenced. This solves both (1) and (2) for many users: they can adopt Waypoint quickly, see some quick value, and then iterate from there.
The idea is that there will always be certain features in Waypoint that mutable deployments cannot support. For example, mutable deployments can get a per-deploy URL (cause that requires immutable deployments by definition).
There are a couple things you call out:
Opinionated plugins: There is now a tension between pawning off features to the manual way vs the opinionated way. We need to be careful with this line. We want to continue supporting opinionated directions, we aren’t entirely sure yet how to draw the line of what goes in one vs. the other (or both).
Service discovery specifically: There is another reason we didn’t add the service stanza to the Nomad opinionated plugin: we want more time to determine if we support service discovery more generally, i.e. a generic Consul plugin that Waypoint manages externally. Nomad is unique in that it has native support, but almost every other platform does not. It’d be great to be able to register things like Lambda as well. So, we want to consider that.
I hope this shares some of our viewpoints and would love to hear any feedback.
