Bug 1839158
| Summary: | Cannot set any manual network interface device name in RHCOS4.3.z | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Pushpendra Chavan <pchavan> |
| Component: | RHCOS | Assignee: | Dusty Mabe <dustymabe> |
| Status: | CLOSED WONTFIX | QA Contact: | Michael Nguyen <mnguyen> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.3.z | CC: | bbreard, dornelas, imcleod, jligon, miabbott, nstielau, pawel.burzawa |
| Target Milestone: | --- | ||
| Target Release: | 4.6.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-07-17 18:03:12 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1186913 | ||
|
Description
Pushpendra Chavan
2020-05-22 15:27:06 UTC
Setting priority as medium and targeting for 4.6; we are currently working on fixing BZs for 4.5 and do not believe we will have the ability to address this for the 4.5 release. This bug has not been selected for work in the current sprint. Hey Pushpendra, Right now we don't persiste the `ifname=` information from the first boot's kargs for subsequent boots. I started a discussion upstream to see if this is something we should change: https://github.com/coreos/fedora-coreos-tracker/issues/553 Though right now you can just persist this information yourself by modifying the Ignition passed to the machine and creating a file like the following (in addition to the `ifname=` karg): ``` $ cat /etc/systemd/network/25-pushpendra.link [Match] MACAddress=52:54:00:91:10:fa [Link] Name=pushpendra ``` The `ifname=` karg will make sure the interface gets the right name during the initramfs (though probably not strictly required). The `25-pushpendra.link` will make sure it gets renamed properly for all subsequent boots of the machine. This is being worked on, but is currently awaiting more investigation or more information and won't be completed this sprint. Hi Pushpendra, have you had a chance to try out the workaround to see if that gets you unblocked? (In reply to Dusty Mabe from comment #9) > Hi Pushpendra, have you had a chance to try out the workaround to see if > that gets you unblocked? Dusty, Apologies for not responding earlier, I had this tested and it works perfectly fine for me. This was an additional details I have added in my ignition as follows and then appended rest information. "storage": { "files": [ { "filesystem": "root", "path": "/etc/systemd/network/25-pushpendra.link", "user": { "name": "root" }, "contents": { "source": "data:text/plain;charset=utf-8;base64,W01hdGNoXQpNQUNBZGRyZXNzPTUyOjU0OjAwOmJiOmQ5OjFiCltMaW5rXQpOYW1lPXB1c2hwZW5kcmE=", "verification": {} }, "mode": 384 }, The base64 encoding decodes to following for the file /etc/systemd/network/25-pushpendra.link [Match] MACAddress=52:54:00:bb:d9:1b [Link] Name=pushpendra And upon deployment, I had this interface name. [core@bootstrap ~]$ ifconfig -a pushpendra pushpendra: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255 inet6 fe80::cb02:7e3a:a16a:ecca prefixlen 64 scopeid 0x20<link> ether 52:54:00:bb:d9:1b txqueuelen 1000 (Ethernet) RX packets 3124 bytes 3847495 (3.6 MiB) RX errors 0 dropped 416 overruns 0 frame 0 TX packets 2503 bytes 232252 (226.8 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 12412 Thank you! So right now, we have this functionality, just ifname isn't available yet. No problem. I'm glad it worked for you.
> So right now, we have this functionality, just ifname isn't available yet.
When you say "just ifname isn't available yet." what are you referring to? An outstanding issue?
> When you say "just ifname isn't available yet." what are you referring to? > An outstanding issue? Dusty, I just read through the complete discussion at https://github.com/coreos/fedora-coreos-tracker/issues/553#issuecomment-658949868 So looks like we aren't going to implement ifname in anytime soon, is that correct? If that's the situation, then I think we can live with the solution provided by you as per #5 (In reply to Pushpendra Chavan from comment #12) > > When you say "just ifname isn't available yet." what are you referring to? > > An outstanding issue? > > Dusty, I just read through the complete discussion at > https://github.com/coreos/fedora-coreos-tracker/issues/553#issuecomment- > 658949868 > > So looks like we aren't going to implement ifname in anytime soon, is that > correct? If that's the situation, then I think we can live with the solution > provided by you as per #5 Hey Pushpendra. Thanks for following along the upstream discussion! Correct. Since there is an easy workaround of creating a file to do the renaming we've currently decided to wait and see if there is more demand for this feature. Thank you for confirming the workaround will suffice for now. I'm thinking that we will close this bug as WONTFIX for now and re-open if we get new information. Update: this has now been fixed upstream such that passing `ifname` on first boot (ignition boot) of the machine will propagate rules forward to the real root and subsequent boots will use that NIC name. See https://github.com/coreos/fedora-coreos-tracker/issues/553#issuecomment-1535341715 The code should make it into 4.14. |