Distinguish net config approaches

[devopsbob]

Draft variations to configure a given network

[learmj]

Hi Bob. Thanks for this. I appreciate you taking the time to write it up. In all likelihood I'm not going to get time to review it in detail this side of Christmas. From a very quick glance:

• I would drop the first person references everywhere.
• I'd be reticent to do anything that messes with what systemd might do (eg with resolv.conf).
• If the example is intended to show selecting between different network configurations, it may be helpful to have different layers selected for each configuration (eg via config file).

[devopsbob]

Hi Matthew, wanted to give a little back for your help. I did expect it needed cleanup. I'll look to make these suggested update before Christmas. That is my target to have my new box online! It is also likely a year-end crunch time for whatever you may be working on.

I'll leave this in draft. I'll update or close it by EOY. Any and all comments to this PR are welcome from any/all to help along the tidying.

[devopsbob]

@learmj I've updated the example networks texts. The etc directories show the target file(s) as examples. The layer names are made unique by having one with a meta example, and one as a non-meta/non-dynamic/static file assignment.

Looking for any suggestions and feedback prior to moving from draft to PR-ready.

[learmj]

Hi @devopsbob I was contemplating creating a contrib dir in the tree where user contributions could be located.
This would open it up to not just build-able examples, but configurations, layers, etc. Seems a more general approach and maybe something that would be more usful to a wider user base.
Not sure what you or anyone else thinks about that?

While I'm totally open to user contributions, I currently feel that the examples dir should be tightly maintained and at the moment, I see its contents coming from requests and/or uses of rpi-image-gen here at RPi.

[devopsbob]

Hi @learmj ,

I can appreciate splitting the directory to a 'contrib' folder that originates or hosts samples provided from outside RPi. It would allow for reasonable controls and ownership of regression or impacts of changes from outside the RPi team -- ie. contrib folder is 'less' verified as buildable and could show variations and examples which may/may-not be fully buildable. (build automation and coverage metrics might be able to exclude contrib versus team owned examples)

If you want, go ahead with a 'contrib' folder and 'readme' or 'contrib.md' base setup and I will move this 'example-networks' as a child to the contrib folder owned as one of the RPi committers. Additionally it would be a good place for https://github.com/devopsbob/ke-net-screen/tree/feature/genericize example that is in-flight for another contrib.

Let me know.

[learmj]

Hi @devopsbob
I added the contrib dir in c3899ad
Please feel free to submit a new/updated PR

[devopsbob]

Hi @learmj
I appreciate your kind mentions in recent messages. I had to travel out of town after holidays for extenuating personal circumstances. I will be back to my home office in March and intend to revisit this re-branch/re-post/PR by mid-April.

[devopsbob]

@learmj I'm 161 commits behind. I just had a look through the commits. I got my rig back on and finding where I left off. Hope to update my fork and do the contrib stuff...very soon..I want do a build, update the fork, see the build work, then port for a contrib setup. Thanks for leaving this open. I'll close it with the contrib pr redo.