Unit of translation should not be an individual config file

[eriknelson]

In master I'm seeing a series of funcs (fetch, decode, translate, dump, or FDTD) run per remote config file (master, node). I'd like to propose an alternative model because this doesn't sufficiently address the problem of configuring OCP4 features, like container runtimes, which require multiple input configuration files.

The unit of translation should be on an OCP4 feature basis, not on a remote config basis. Let's call the OCP4 features components. For example, there is an OAuth component, an SDN component, and a ContainerRuntime component.

Ideally, you should be able to define the FDTD functions for each "component", and I want to fetch/decode the N config files that are relevant to that component.

[gildub]

Putting OCP4 feature as the center of the component type is effectively good to handle N config files for 1 component.

[jmrodri]

@eriknelson agreed. OCP4 seems to be what dictates how the code is structured. Doing it by component will yield the best outcome, it will make OCP3 a bit more complicated because you might have to fetch the same file a few times to get the appropriate info.

[eriknelson]

@jmrodri, I expect a lot of components to share files. They should all probably ask some kind of FileManager type that either returns cached files or remote files.

[gildub]

@eriknelson, the io pkg provide a cache approach to sftp file retrieval.

[gildub]

The units are now OCP4 components such as OAuth, SDN, etc.