| 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:55 |
|---|---|---|
| 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. | 00:56 |
| holmanb | phunyguy: hrm, I'd need more info than that to debug further | 15:14 |
| 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:33 |
| 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:34 |
| phunyguy | day off today ☺ | 15:35 |
| 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:36 |
| 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:38 |
| phunyguy | palms get sweaty just thinking about it. | 15:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| phunyguy | This was in the early 90s I think, not sure if anything is the same. | 15:43 |
| holmanb | nice | 15:44 |
| 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" | 15:56 |
| phunyguy | holmanb: https://paste.ubuntu.com/p/BC4nrvJ3h7/ | 16:00 |
| phunyguy | I have a feeling those log entries are old though | 16:01 |
| 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:06 |
| phunyguy | Looking like the config is supplying "mac_address" and this is looking for "hwaddress"? | 16:07 |
| phunyguy | I guess I can test that in my own repo | 16:09 |
| 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:15 |
| 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:17 |
| phunyguy | ok | 16:18 |
| phunyguy | thanks for that | 16:18 |
| phunyguy | I was just doing `cloud-init clean` | 16:18 |
| holmanb | no problem, I'll add some more logging in _write_network() | 16:22 |
| 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:25 |
| holmanb | that log output should tell us whether the issues is in `translate_network()` (or earlier) or in _write_network() | 16:27 |
| phunyguy | holmanb: https://gist.github.com/phunyguy/a93cd17ce13a75490eb6e1afe6310d28 | 16:29 |
| phunyguy | looks like it's missing from the resultant eth0 line in that log | 16:30 |
| phunyguy | the hwaddress piece specifically. | 16:31 |
| 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:41 |
| 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. | 16:55 |
| phunyguy | Guys I'm learning python | 17:20 |
| holmanb | phunyguy: learning python -> \o/ | 19:27 |
| holmanb | seeing this now | 19:27 |
| 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:34 |
| 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:35 |
| 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:46 |
| holmanb | ^ relatable | 19:49 |
| phunyguy | This is going to be a mess when I get done with it, but it will be more functional. | 19:50 |
| 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:51 |
| 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:53 |
| phunyguy | list/tuple, still haven't figured out the difference | 19:55 |
| phunyguy | what the hell is a tuple | 19:56 |
| phunyguy | oh I think I got it. | 20:15 |
| phunyguy | blech: dns_nameservers = str(", ".join(dns_nameservers)).replace(",", "") | 20:15 |
| holmanb | confused, are you writing a new network config parser? | 20:32 |
| phunyguy | I am just modifying what's there to handle dns correctly. | 20:36 |
| phunyguy | the gentoo way | 20:36 |
| 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:37 |
| 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:49 |
| 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:50 |
| holmanb | so for this particular config entries["lo"]["dns-nameservers"] would get you a list of strings (where each string is an ip) | 20:52 |
| 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 | 20:54 |
| phunyguy | ok | 21:06 |
| phunyguy | yeah this is whacky anyway.. dns-nameservers being associated with lo is weird to begin with | 21:07 |
| phunyguy | Maybe that's why the original author was writing resolv.conf directly. | 21:08 |
| 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:09 |
| 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:10 |
| 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:12 |
| phunyguy | the (' and ') are a noop | 21:13 |
| holmanb | phunyguy: I'm trying to avoid rewriting this whole module. | 21:43 |
| sam_ | :D | 21:44 |
| holmanb | lol hi sam_ :) | 21:46 |
| 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:50 |
| holmanb | pushing a commit to your branch shortly | 21:51 |
| phunyguy | I don't know either. I've reverted all that. | 21:51 |
| phunyguy | It's not relevant if I'm not changing any of that. | 21:52 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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. | 21:59 |
| 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:00 |
| 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:01 | |
| 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:02 |
| 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:04 |
| 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:05 |
| 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:06 |
| holmanb | I don't think package managers are executed elsewhere without network - if so that's probably a bug | 22:07 |
| 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:09 |
| 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:10 |
| 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:11 |
| phunyguy | I await your commit | 22:12 |
| holmanb | oops, one sec | 22:12 |
| holmanb | phunyguy: pushed | 22:13 |
| phunyguy | \o/ | 22:13 |
| 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:15 |
| phunyguy | excellent | 22:16 |
| phunyguy | nothing-burger then | 22:16 |
| phunyguy | ok I think I got your changes merged with mine | 22:28 |
| phunyguy | holmanb: what to you out? I would assume soon? | 22:29 |
| phunyguy | what time you out* | 22:33 |
| phunyguy | sheeeeeeeeeeeeesh | 22:33 |
| holmanb | half hour left for me, mountain time | 22:35 |
| phunyguy | ok | 22:35 |
| * phunyguy wipes sweat | 22:35 | |
| 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:38 |
| holmanb | pretty sure the problem is in translate_network(), how exactly I'd need to read the code and understand both formats | 22:40 |
| 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:41 |
| holmanb | Not going to get to that today. Sounds good, I'll take a look at it Monday. | 22:44 |
| phunyguy | Yep, it's there for you | 22:45 |
| 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 | 22:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!