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
I'd love to see this module shift to using the puppet device model, for a couple of reasons:
In no sense are the resources exposed by this module part of the system on which the agent is running; the agent is acting as an API proxy, and that fact may as well be formalized through the use of puppet device (which really could be renamed puppet remote, but that's a separate issue).
Maintaining the environment variables that tell Puppet which region to manage, and what credentials to use, is awkward. Puppet already has a system for that kind of information in the form of device.conf, particularly when using the PDK-style HOCON configuration files.
As an extension of the above point, by switching to a puppet device model, it will be possible to manage resources in multiple regions with from a single Agent (it will still require multiple runs, but each region could a device target on a single agent, instead of each region requiring its own agent).
It'd cut out code duplication - code that is shared across every provider, relating to connecting to the AWS API, would be moved into device.rb.
I'd love to see this module shift to using the
puppet devicemodel, for a couple of reasons:puppet device(which really could be renamedpuppet remote, but that's a separate issue).device.conf, particularly when using the PDK-style HOCON configuration files.puppet devicemodel, it will be possible to manage resources in multiple regions with from a single Agent (it will still require multiple runs, but each region could a device target on a single agent, instead of each region requiring its own agent).device.rb.