[00:55] <phunyguy> holmanb: ok, that got /etc/conf.d/net.eth0 to come back.  It's still not parsing the mac address from the clouddrive config file.  mac_eth0="None"
[00:56] <phunyguy> I feel like that should be something really easy to fix.  And then the last thing is starting the network service "net.eth0"
[00:56] <phunyguy> Oh it's missing the nameserver and domain name settings too.
[15:14] <holmanb> phunyguy: hrm, I'd need more info than that to debug further
[15:33] <phunyguy> holmanb: I'll do a once over, dump some logs, and try to give some pointers as to what I think the problems are from a gentoo perspective.  
[15:33] <phunyguy> I am not good with python, so probably can't fix
[15:34] <phunyguy> but I can direct you at potential areas/line numbers
[15:34] <holmanb> phunyguy: sure no problem - thanks that would be helpful
[15:34] <phunyguy> first, coffee
[15:35] <phunyguy> day off today ☺
[15:36] <holmanb> Nice! I'm working today, I can maybe help a little as time allows, but then I'm off hiking in the mountains over the weekend, so I'll be far away from a network connection until Monday :)
[15:36] <phunyguy> I better get moving then
[15:36] <phunyguy> lol
[15:38] <phunyguy> also that sounds like my nightmare.  Not a heights guy, and I have vague memories of being a kid hiking with my parents in Maine and being scared to death walking along foot-wide cliffs hanging on to bars.
[15:38] <phunyguy> looking down at teeny tiny trees
[15:39] <phunyguy> palms get sweaty just thinking about it.
[15:40] <holmanb> phunyguy: Maine has a via ferrata? Never been on one of those myself. I'm more into either climbing (class 5) or hiking. This one should be pretty tame, nothing technical.
[15:41] <phunyguy> I have no idea what that is.  It was sections of the hike that would hang off the side of the mountain with bars to hold on to.  I was scared to death
[15:41] <phunyguy> Acadia
[15:42] <holmanb> via ferrata is the metal bars (literally "iron path")
[15:42] <phunyguy> well there ya go.
[15:42] <phunyguy> yes I guess I did that
[15:43] <phunyguy> This was in the early 90s I think, not sure if anything is the same.
[15:44] <holmanb> nice
[15:56] <phunyguy> OK, so once I got rid of the mac address problem, by commenting it out in the generated config, the system boots with network.
[15:56] <phunyguy> so that's good.
[15:56] <phunyguy> But I think it would be better to figure out why the mac config generation is putting "none"
[16:00] <phunyguy> holmanb: https://paste.ubuntu.com/p/BC4nrvJ3h7/
[16:01] <phunyguy> I have a feeling those log entries are old though
[16:06] <phunyguy> holmanb: ok so https://github.com/phunyguy/cloud-init/blob/main/cloudinit/distros/gentoo.py#L95
[16:06] <phunyguy> that is returning "None" for a value
[16:07] <phunyguy> Looking like the config is supplying "mac_address" and this is looking for "hwaddress"?
[16:09] <phunyguy> I guess I can test that in my own repo
[16:15] <phunyguy> oh sidenote, it had networking on boot because I left behind the net.eth0 service init.d file.
[16:15] <phunyguy> and that got started as a wants/needs
[16:17] <holmanb> re: old log entries fyi -> cloud-init clean --logs --reboot will re-init the system w/cloud-init and remove old logs
[16:17] <holmanb> When I'm testing changes in cloud-init I run that a lot ^^
[16:18] <phunyguy> ok
[16:18] <phunyguy> thanks for that
[16:18] <phunyguy> I was just doing `cloud-init clean`
[16:22] <holmanb> no problem, I'll add some more logging in _write_network()
[16:25] <holmanb> actually some interesting bits are already logged
[16:25] <phunyguy> oh goody, it did create the network init.d file, so that's good.  
[16:25] <holmanb> phunyguy: "Translated ubuntu style network settings" should be in the log -> what's that say?
[16:27] <holmanb> that log output should tell us whether the issues is in `translate_network()` (or earlier) or in _write_network()
[16:29] <phunyguy> holmanb: https://gist.github.com/phunyguy/a93cd17ce13a75490eb6e1afe6310d28
[16:30] <phunyguy> looks like it's missing from the resultant eth0 line in that log
[16:31] <phunyguy> the hwaddress piece specifically.
[16:41] <phunyguy> Meh, maybe that part can just go away.  I am not even really sure of a good reason to include the mac in the config.
[16:55] <phunyguy> Man this could really use some work, and I am actually willing to try and situate the DNS portion of this that is really hacked together.  openrc can actually handle creation of a dynamic resolv.conf, as long as the proper things are in /etc/conf.d/net{.*}. 
[16:55] <phunyguy> currently this writes a rudimentary /etc/resolv.conf, and is missing suffix search, etc.
[17:20] <phunyguy> Guys I'm learning python
[19:27] <holmanb> phunyguy: learning python -> \o/
[19:27] <holmanb> seeing this now
[19:34] <holmanb> phunyguy: In practice I dunno why anyone would want to spoof macs in the cloud, but it's pretty common these days on mobile devices I think (for whatever EUI48 addresses are called on mobile devices).
[19:35] <holmanb> Either way, if it's an expected configurable input, we should try to do the right thing rather than silently not do what users expect.
[19:35] <holmanb> based on that gist, it looks like translate_network() isn't translating everything correctly
[19:46] <phunyguy> ok
[19:46] <phunyguy> in the mean time, I am attempting to get the dns configuration working correctly.
[19:46] <phunyguy> holmanb: I'm struggling a little bit but I'll get there.
[19:49] <holmanb> ^ relatable
[19:50] <phunyguy> This is going to be a mess when I get done with it, but it will be more functional.
[19:51] <phunyguy> Once I get done with this part, probably over the weekend, I'll send a PR to your repo/branch
[19:51] <phunyguy> ...which I haven't really done before, so we'll see!
[19:53] <phunyguy> holmanb: what I am ending up with for dns_servers_lo is "['192.168.0.1']"...  How do I get rid of the [' ']
[19:53] <phunyguy> the end result should be a space separated list of what the list is
[19:55] <phunyguy> list/tuple, still haven't figured out the difference
[19:56] <phunyguy> what the hell is a tuple
[20:15] <phunyguy> oh I think I got it.
[20:15] <phunyguy> blech: dns_nameservers = str(", ".join(dns_nameservers)).replace(",", "")
[20:32] <holmanb> confused, are you writing a new network config parser? 
[20:36] <phunyguy> I am just modifying what's there to handle dns correctly.
[20:36] <phunyguy> the gentoo way
[20:37] <phunyguy> currently it's only manually creating resolv.conf with the list of dns servers
[20:37] <phunyguy> netifrc has the ability to parse /etc/conf.d/net to gather suffix and dns-servers list to dynamically create resolv.conf with what's there
[20:49] <holmanb> phunyguy: oh I see. I don't think you should need to parse that data out. Looks like it gets cast to a string on line 81, just grab the data structures before the cast
[20:50] <holmanb> from the gist you shared previously, the value in "entries" is a dict: {'lo': {'ipv6': {}, 'dns-nameservers': ['192.168.0.1'], 'dns-search': ['neverserio.us'], 'auto': True}, 'eth0': {'ipv6': {}, 'bootproto': 'static', 'address': '192.168.0.249', 'gateway': '192.168.0.1', 'netmask': '255.255.255.0', 'broadcast': '192.168.0.255', 'auto': True}}
[20:52] <holmanb> so for this particular config entries["lo"]["dns-nameservers"] would get you a list of strings (where each string is an ip)
[20:54] <holmanb> kinda just guessing based on your variable names here ^^
[20:54] <holmanb> - but I'm pretty sure you shouldn't need to actually parse anything from a string
[21:06] <phunyguy> ok
[21:07] <phunyguy> yeah this is whacky anyway..  dns-nameservers being associated with lo is weird to begin with
[21:08] <phunyguy> Maybe that's why the original author was writing resolv.conf directly.
[21:09] <phunyguy> It's making it really difficult to do this with netifrc the way I want.  I don't think it's going to work.  So I'll just get the original code to drop the right stuff in /etc/resolv.conf and call it a day.
[21:10] <holmanb> gotcha +1, sounds good
[21:10] <phunyguy> The last thing to figure out then is the hwaddress problem, which is where I would really need help.
[21:12] <phunyguy> holmanb: regarding your "cast to a string on line 81", that's exactly the line I was modifying, because originally the output was "('192.168.0.1')"
[21:13] <phunyguy> the (' and ') are a noop
[21:43] <holmanb> phunyguy: I'm trying to avoid rewriting this whole module.
[21:44] <sam_> :D
[21:46] <holmanb> lol hi sam_ :)
[21:50] <phunyguy> holmanb: yeah I feel that
[21:50] <holmanb> phunyguy: pretty sure that ugly cast/replace line can just be a " ".join(dns_nameservers). I'm not sure why you would want to depend on tuple.__repr__ for just inserting spaces between items in a list.
[21:51] <holmanb> pushing a commit to your branch shortly
[21:51] <phunyguy> I don't know either.  I've reverted all that.
[21:52] <phunyguy> It's not relevant if I'm not changing any of that.
[21:54] <phunyguy> Hey I wrote something that worked!
[21:54] <holmanb> congrats :D
[21:54] <phunyguy> OK I have another question before I lose you for the weekend
[21:54] <sam_> holmanb: hi! 
[21:55] <holmanb> o/
[21:55] <holmanb> phunyguy: go for it
[21:55] <phunyguy> the system update stuff... this is NOT a good idea in the gentoo world.... so I am changing "emerge" to "true" to completely eliminate all that for now.
[21:55] <phunyguy> I hope that's OK
[21:56] <phunyguy> if you have a better way to disable that, I am all ears
[21:56] <sam_> what's this?
[21:56] <phunyguy> sam_: noooooottttthinnngg.....
[21:57] <holmanb> sam_: tl;dr phunyguy is working on some brokenness in the network stack they identified (mac and dns aren't passed through correctly)
[21:58] <holmanb> phunyguy: disabling update is a change I would run by a gentoo maintainer
[21:58] <phunyguy> well that's the thing, it's completely broken.
[21:59] <phunyguy> when the images are built, portage is completely stripped out to make the image smaller, so there is no profile, tree, or anything.
[21:59] <holmanb> which images?
[21:59] <phunyguy> running emerge in that case to try and update the system is completely hosed up.
[21:59] <phunyguy> sorry, this is being used with diskimage-builder in my case, the openstack project.
[22:00] <holmanb> cloud-init isn't responsible for image build so I'd argue that's not a cloud-init problem.
[22:00] <phunyguy> nor is it a diskimage-builder problem.
[22:00] <phunyguy> lol
[22:01] <phunyguy> the primary for the gentoo portion of that project is so vehemently against cloud-init vs simple-init it's hilarious.
[22:01] <holmanb> diskimage-builder strips portage but it's not diskimage-builder's problem?
[22:01] <phunyguy> I was being sarcastic
[22:01] <holmanb> I see
[22:01]  * phunyguy holds up the sarcasm sign
[22:02] <phunyguy> interestingly enough, the person that wrote this gentoo.py is the same person I am mentioning
[22:02] <phunyguy> it seems we are the only two people doing things like this with gentoo, and we disagree on many things.
[22:04] <phunyguy> Also it should be noted, that before I changed it to "true" to get rid of the emerge command, network setup was also failing.
[22:04] <phunyguy> so something is definitely wonky there.
[22:04] <holmanb> huh, I'm going to attempt to continue staying out of those sorts of turf wars, but happy to help making the project better :)
[22:05] <sam_> yes, tell me if you need me to tie-break or something phunyguy 
[22:05] <phunyguy> sam_: possibly.
[22:05] <phunyguy> however I don't necessarily disagree with stripping out portage to keep the images smaller
[22:06] <phunyguy> but if that's causing problems, then maybe it should stay unstripped.
[22:06] <phunyguy> But I am still concerned that emerge is running before the network is up.
[22:06] <phunyguy> so that's still a cloud-init problem if so.
[22:07] <holmanb> I don't think package managers are executed elsewhere without network - if so that's probably a bug
[22:09] <phunyguy> I think networking isn't started until default runlevel, which comes after all this.
[22:09] <phunyguy> ahh scratch that, I see where it's supposed to
[22:10] <phunyguy> yeah you are right, this is 100% a DIB issue
[22:10] <phunyguy> it's the mac issue that causes it to not come up initially, but still tries to update
[22:11] <phunyguy> I guess I should ask, if the packages fail to update, would that affect anything else in the CI process?
[22:11] <phunyguy> if not, then I say leave it.
[22:12] <phunyguy> I await your commit
[22:12] <holmanb> oops, one sec
[22:13] <holmanb> phunyguy: pushed
[22:13] <phunyguy> \o/
[22:15] <holmanb> I don't think package install failure will cause cloud-init to stop as a whole. Those invocations should be limited to config modules, which are later in boot process. You'll see lots of noise in logs and any module depending on package update/install will exit early, but the rest of the process will continue.
[22:16] <phunyguy> excellent
[22:16] <phunyguy> nothing-burger then
[22:28] <phunyguy> ok I think I got your changes merged with mine
[22:29] <phunyguy> holmanb: what to you out? I would assume soon?
[22:33] <phunyguy> what time you out*
[22:33] <phunyguy> sheeeeeeeeeeeeesh
[22:35] <holmanb> half hour left for me, mountain time
[22:35] <phunyguy> ok
[22:35]  * phunyguy wipes sweat
[22:38] <phunyguy> the last thing I want to do is keep you from your trail fun
[22:38] <phunyguy> any thoughts on the missing mac?
[22:40] <holmanb> pretty sure the problem is in translate_network(), how exactly I'd need to read the code and understand both formats
[22:41] <phunyguy> ok so definitely not a today thing.
[22:41] <phunyguy> I'm going to send you a pr for what I have, for your review, and you can do what you want with it.  We can approach the other problem later.
[22:44] <holmanb> Not going to get to that today. Sounds good, I'll take a look at it Monday.
[22:45] <phunyguy> Yep, it's there for you
[22:46] <phunyguy> enjoy your weekend and THANK YOU for the help here.
[22:46] <holmanb> phunyguy: thanks for putting in the legwork on it - it helps :D