<baude>
because NM will not work with a network interface where carrier signal and device cannot be identified
<baude>
tap is one of those cases
<walters>
The default DHCP-on-ethernet connection won't, but NM can be configured to ignore carrier AFAIK
<walters>
See ignore-carrier in man NetworkManager.conf
<baude>
walters, so what do i do if this is the default network connection and i am actually trying to use fcos
<baude>
although, if you like, i could also explain why im in this rabbit hole in the first place
<baude>
i dont think NM will ignore the missing device bit however.
<dustymabe>
baude: we (in FCOS) have disallowed ifcfg-rh old style network configuration since the beginning
<dustymabe>
which is why that file doesn't exist
<baude>
well today i get a missing library notification to let me know that ... at this point, it does not matter
<walters>
Hm yeah, looks like NM will allow ignoring carrier but only for static IPs? As far as figuring out the broader problem, umm...looking around it seems like one can force enable carrier on tap devices
<dustymabe>
but it's all NetworkManager underneath, so i'm not sure that having that plugin would help you
<baude>
i think we are talking around each other?
<dustymabe>
baude: care to restate from the top ?
<baude>
ok, hyperv usermode networking uses vsock between host and guest. on the host, the listen side is down with gvproxy; on the guest, a small app is used to connect to the vsock and then configure a tap interface ... from there the program basically adds ethernet packets and acts a buffer copy (for lack of a more verbose description)
<dustymabe>
got it
<baude>
if I have the small app create an interface of eth0, nm will error complaining that it cannot work with an interface where the device (under tap) is not established/known
<baude>
so, from this, i tried to use ifcgf scripts, bc this is what is documented as well as documented in the NM pages and conf files
<baude>
when doing so, i find out it errors out because shtuff is missing
<baude>
walters, dustymabe so I would be happy to go back to NM and play along, but this does not seem reasonable; I would also be happy to have ignition configure ifcfg script but not supported.
<dustymabe>
baude: just lay down an nmconnection file
<dustymabe>
first link TL;DR == use new format, old format probably deprecated at some point in future
<dustymabe>
or maybe never deprecated, but NM devs definitely prefer you use the new format
<baude>
well it has been forceable deprecated
<dustymabe>
baude: yes, for FCOS - that is correct
<baude>
and yet, the nm conf file on fcos says it can be used
<dustymabe>
sorry about that
<baude>
on the second link, you are aware offensive language use? did you folks decide to not change things bc that is what it is "upstream" from you ?
<dustymabe>
baude: yeah, I mean those are the settings in the NM configs
<dustymabe>
and those are the terms bonding uses :(
<baude>
yup
<dustymabe>
i'd personally like to see openshift change all their primary branch names, but that hasn't happened either.
<baude>
so this is done with butane and not ignition?
<baude>
so i have noticed that too
<dustymabe>
baude: the examples are just in butane because that's the easiest to see/read and we do recommend our users use it
<dustymabe>
for you it's easy enough to figure out how to generate the corresponding Ignition, rigth?
<baude>
it is? i dont know this stuff dude ... i write container code
<dustymabe>
ha - well I mean you're already passing an ignition config that drops down files for your PoC?
<bgilbert>
sorry, I had lost track of that last one
<baude>
i am waiting on your write code so i can use it to finish, i have everything queued up with address review comments
<bgilbert>
wouldn't hurt to push what you have fwiw
<baude>
you want me to push a unknowingly incomplete PR? I mean, i sure can ...
<baude>
dustymabe, fwiw, i have this setup now but I see zero evidence that the nm connection is actually firing on boot
<baude>
or that the timing is correct. i.e. app that creates tun device and nm tht tries to configure it
<baude>
rereading the docs to see if i missed something
<bgilbert>
baude: well, it's no more incomplete than the last draft, right?
<baude>
dustymabe, i do know it was read bc i had incorrect permissions in there
<baude>
no it is less incomplete
<bgilbert>
+1
<dustymabe>
baude: what do the logs say? what does `nmcli c show` say?
<baude>
nmcli shows it but nmcli connection up vsock0 fails .... just like i said before . NM does not work with an ethernet device where it cannot show the device type, which is the case with tun
<baude>
so i am guessing nothing i have done has changed that bc NM is still being used
<baude>
which is why i tried to use the cfg method
<baude>
bgilbert, just double checking; i can push my pr but I am waiting on you to bless your write pr?
<bgilbert>
I think the write PR won't land as-is
<bgilbert>
I realized that actually the provider already controls the Ignition config that it returns
<bgilbert>
so it can just paste some extra files into that config
<bgilbert>
now, in order to do that 100% correctly, we might need a helper function that does the merging properly
<bgilbert>
but you could probably go ahead and start implementing
<baude>
im not sure i understand what you are meaning
<bgilbert>
the goal is to write some additional files into /var, right?
<bgilbert>
so the hyperv fetchConfig() function can just modify the types.Config before returning it
<bgilbert>
to add some files to the storage.files section
<baude>
ok, do i understand that means I do not need to wait for your PR correct?
<bgilbert>
correct
<dustymabe>
baude: right. It's all NetworkManager under the hood. If there's a fundamental problem there then we'd need to take it up with that team. That is unless you want to run `ip add` commands yourself.
<baude>
dustymabe, well, i am really trying to keep things as you folks have set for fcos ... leave the ip stuff to the ip stuff
<baude>
dustymabe, i am currently looking at /usr/lib/udev/rules.d/085-nm-unmanaged.rules to see if that can help us
<baude>
or that the timing is correct. i.e. app that creates tun device and nm tht tries to configure it:q!
<dustymabe>
baude: makes sense
<dustymabe>
similarly, we leave the NM stuff to the NM team
<dustymabe>
we'll try to make it work, but that's where the ultimate responsibility lies
<baude>
unless you have yanked the approved solution out of coreos :)
<dustymabe>
baude: if you show me a ifcfg-rh style file that will work with NM then I'll figure out and fix the problem on our end
<dustymabe>
I don't think it exists
<dustymabe>
it's still networkmanager under the hood
<dustymabe>
the ifcfg-rh files don't change what network management code gets used
<dustymabe>
if you'd like to prove me wrong I'll provide you with a build of FCOS that doesn't have that plugin removed
jpn has joined #fedora-coreos
<baude>
dustymabe, i can also do that, ty though ... i'll keep at it
<dustymabe>
good luck
<baude>
i just keep sliding down the bar to next patron who will listen to me
<dustymabe>
baude: :)
jpn has quit [Ping timeout: 265 seconds]
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 255 seconds]
<dustymabe>
so /buffer qa
daMaestro has joined #fedora-coreos
nalind has quit [Quit: bye for now]
sentenza has joined #fedora-coreos
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 265 seconds]
mheon has quit [Ping timeout: 246 seconds]
<adamw>
dustymabe: ahoy, are we all set up for f38 release for coreos?
<adamw>
go/no-go is thursday and as of rn there are no blockers