Root Path Config

[ambsw-technology]

Any thoughts on adding a root path configuration? For example, I may only want to extract /Prod/Service/<service>/ to a YAML for revision and then push it back up.

We've been storing non-secret client params (we dedicated instances for security reasons) in separate YAML files. I've been pulling my hair out trying to figure out how to get the client-level bulk edit experience on SSM, but this project is perfect -- i.e. keep doing it the same way.

For import (and ongoing management and not pulling unnecessary secrets to disk), I really prefer to work with a subset of the tree at once (a single client or service). It'd be nice if I could pull just that branch. FWIW it could also make sense to allow me to filter that branch on a particular tag.

[ambsw-technology]

Maybe this is what -p does, but a flag is really dangerous. If I init -p /path/ and plan -p /path/ but forget the flag and apply, won't I delete a bunch of keys?

[ambsw-technology]

OK I see why the current behavior exists:

• -p accepts multiple paths.
• To avoid key collisions, full paths must be retained.
  • If two of the -p paths had the same key, they would collide.
  • Keeping the parent key won't help either since -p a/b/c and -p b/c would also collide.

Even if you preserve the -p behavior, it would be OK to remove any paths shared by the two keys.

• Let's assume you add an environment variable ROOT_PATH=a/b.
• It would be valid to call -p a/b/c, returning a YAML with only the c key (and any nested values)
• It would be invalid (need to error) to call -p x/y/z since they are not contained in the ROOT_PATH
• It would also be valid to call -p a/b/c -p a/b/z/c. The resulting file would include c and z/c in the root (plus any nested values). It would exclude a key like a/b/z/d per the -p behavior.

So I guess I need to revise my proposal:

• Support an ENV variable (e.g. ROOT_PATH). These paths are excluded from the YAML file during generation and the YAML file is nested at this path during update.
  • For example, if the SSM structure can be represented by a dict like {a: b: c: {d: da, e: ea}}} and you init with ROOT_PATH=a/b/c, this would produce the YAML:

    d: da
    e: ea

• The -p flag is retained. It can still filter keys within the ROOT_PATH
  • If -p is not specified ROOT_PATH implicitly limits the search to the same path (i.e. like adding -p $ROOT_PATH)
  • If both are present, all values for the -p flag must be children of ROOT_PATH (or an error will be thrown)