cloud-init-dev team mailing list archive

[Joshua Harlow <harlowja@xxxxxxxxx>]

The other way to handle this is to use the import mechanism, instead of hard coding a reference to an actual class, you would have config say use 'X' class for this distro. The 'generic' class would then create that instance for '/etc/hostname' modification (which itself might be specific to a distro). This would let the 'generic' top level class avoid having to know about the specifics while still being generic. In fact with all these common classes we should probably do this same thing so that people can alter them (without having to inherit/subclass a new distro just for this). The other benefit is that u can test common code a lot easier when its isolated (feed it a text blob, then check add/del/set...)

Do u want to try that here? It might make the distro class more component based instead of having many different functions that do lots of varying things. The importer module should help in loading a given class for this purpose (its used for all the other importing/finding as well).
-- 
https://code.launchpad.net/~gholms/cloud-init/hostname-refactor/+merge/125869
Your team cloud init development team is requested to review the proposed merge of lp:~gholms/cloud-init/hostname-refactor into lp:cloud-init.