Hi,
On 12/16/19 4:48 PM, Igor Galić wrote:
Hi folks,
goneri's Pull Request to introduce a [FreeBSD renderer](https://github.com/canonical/cloud-init/pull/61) is also a
big inspiration.
I'm currently testing this patch, but it seems to be "write-only" so far.
I tried to change that, and ran into something that seemed eerily familiar: this pull request of mine, from a year
ago: https://code.launchpad.net/~i.galic/cloud-init/+git/cloud-init/+merge/358228
So, after taking a year break, and having hopefully learned something, I'd like
to get back to this.
Running this by the IRC channel, i got some responses.
OddBloke suggested we could prototype an OOP aproach, by rewriting one of the
functions for Linux to be loaded from a class.
The more i thought about this, the more the classes seemed like container; and
all methods would just be static.
But it does seem like the easiest way to isolate things in python, so why not?
If you have opinions, i invite you to share them here on the list.
If you have design suggestions; perhaps the best place would be this HackMD
Note: https://hackmd.io/3-
YBj1t9TAeKhmfLBQUjXQ (at least until our design gets… better :)
Having whacked at the network implementation for a couple of years now
off and on with the latest changes in [1] and still carrying 4 or 5
network related patches in the SUSE package I think that network
rendering should be tied to the distro rather than being independent.
Obviously the writing of the network config is distro dependent. While
RH based distros and SUSE distros both put their configs into
/etc/sysconfig the introduction of "flavor" in [1] clearly shows that
the very large underlying differences. Further [1] does not address
routing setup for SUSE, which is still carried in a patch in the SUSE
package.
I would favor a complete refactor, where clouinit.net is mostly dropped
and the implementation of the API moves to the distro classes. In the
end network rendering needs to know for which distro the config is being
rendered. Having to pass that information in creates extra complications
IMHO.
Later,
Robert
[1] https://github.com/canonical/cloud-init/pull/162
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
Distinguished Architect LINUX
Technical Team Lead Public Cloud
[email protected]
IRC: robjo
--
Mailing list: https://launchpad.net/~cloud-init
Post to : [email protected]
Unsubscribe : https://launchpad.net/~cloud-init
More help : https://help.launchpad.net/ListHelp