You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Idea: A fuse filesystem that contains all the packs in a configuration file.
Use a toml file containing a datastructure as follows:
[hello_world]
parserV1=true
[hello_world.jobby]
message="Let's see"
register_consul_service = false
[hello_world.otherjobby]
message="I'll check this one too"
register_consul_service = true
consul_service_name = "otherjobby"
In this the only "magic" variable name is job_name, which is set to jobby and then otherjobby for each parse. By having multiple levels, the base settings for a pack (such as which registry it's in) can be set for the pack, and leave all variables open for the final job itself.
This way a pack can be rendered in multiple places intentionally, such as for different environments within the same cluster.
Idea: A fuse filesystem that describes all the packs in a file so you declaratively describe your environment in a single checked in file that can be easily distributed.
Why a fuse filesystem? This allows liveliness where you edit the toml file and get a file showing up immediately.
Why not just render to a directory? I need to track all my variables and var-files and keep them apart and be aware of all of them. My simple cluster now has a dozen var-files and I can't keep my invocations straight. I could fix that, sure, with more investment in the ecosystem.
Why do this? I can then pass a single file in a chat to someone and they can spin up nomad jobs on their cluster describing what I'm seeing. The knobs to tune their environment are right there, visible to them.
Why not an external command?
Annoyingly, the nomad-pack render option does not have machine safe options.
Why don't I do this myself? I got some basics working here https://github.com/Vaelatern/nomad-pack/tree/nomad-pack-fs but the UI layer in this code is tied very tightly to the generation and the API layer. I lack the context necessary to work with the system instead of against it. As a case in point, my code appears to block forever somewhere inside ProcessTemplates.
The text was updated successfully, but these errors were encountered:
Idea: A fuse filesystem that contains all the packs in a configuration file.
Use a toml file containing a datastructure as follows:
In this the only "magic" variable name is job_name, which is set to
jobby
and thenotherjobby
for each parse. By having multiple levels, the base settings for a pack (such as which registry it's in) can be set for the pack, and leave all variables open for the final job itself.This way a pack can be rendered in multiple places intentionally, such as for different environments within the same cluster.
Idea: A fuse filesystem that describes all the packs in a file so you declaratively describe your environment in a single checked in file that can be easily distributed.
Why a fuse filesystem? This allows liveliness where you edit the toml file and get a file showing up immediately.
Why not just render to a directory? I need to track all my variables and var-files and keep them apart and be aware of all of them. My simple cluster now has a dozen var-files and I can't keep my invocations straight. I could fix that, sure, with more investment in the ecosystem.
Why do this? I can then pass a single file in a chat to someone and they can spin up nomad jobs on their cluster describing what I'm seeing. The knobs to tune their environment are right there, visible to them.
Why not an external command?
Annoyingly, the nomad-pack render option does not have machine safe options.
Why don't I do this myself? I got some basics working here https://github.com/Vaelatern/nomad-pack/tree/nomad-pack-fs but the UI layer in this code is tied very tightly to the generation and the API layer. I lack the context necessary to work with the system instead of against it. As a case in point, my code appears to block forever somewhere inside
ProcessTemplates
.The text was updated successfully, but these errors were encountered: