-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Transport configuration(s) #1
Comments
@dontlaugh I'd be open to accepting an LXD transport contribution. The thought that comes mind would be adding a new transport block.
I'd have to mock up what that actually looks like but could be a possible option. I might take a look at the Docker transport as a foundation while the LXD transport is being worked. |
Is there a chance you'll have to deal with transport configs that contain a little bit of nesting? Perhaps we should make the config portion a generic map? If the hashicorp code generator supports it. transport {
type = "native-ssh"
config = {
public_key = "..."
private_key = "..."
}
} Alternative: the more verbose and strongly-typed (but maybe easier on the business logic side) transport {
native_ssh {
public_key = "..."
private_key = "..."
}
} In your code we could enforce the invariant that only one transport could be configured by serializing the On my team, we already use the lxd builder for baking images, but we only use the "file" and "shell" and "shell-local" provisioners. |
I use Bolt's LXD transport https://puppet.com/docs/bolt/latest/bolt_transports_reference.html
It looks like this project only supports SSH and WinRM. Would you accept the LXD transport as a contribution?
There's also docker and podman, which I don't use but which might be nice.
Each of the configuration options of alternative transports might evolve on their own path, so we'd have to consider how to handle the config.
The text was updated successfully, but these errors were encountered: