I am dhcpcd maintainer and okay, dhcpcd is not bad choice. But its
maintenance might fall into our team in RHEL.
I am interested why two DHCP clients are required inside a single tool.
Why it could not use NetworkManager in both times, but with some
different settings? Maybe alternative service? If there is missing
ability to change behaviour, it may make sense to fix just that. Instead
of keeping another client maintained. Do we support any kind of images,
which would not have Network Manager present?
Was it already evaluated by someone from Network Manager maintainers,
whether it would be possible reuse NM both times? If changes would be
required, how significant? Maybe it were already ruled out for a good
reason. I haven't found any discussion about that topic on cloud-init
upstream.
On 06. 02. 24 21:04, Major Hayden wrote:
On Tue, Feb 6, 2024, at 13:56, Petr Menšík wrote:
I think this is stupid anyway. Why does cloud-init need 2 separate DHCP
clients anyway? Can we gather what exactly they use it for and why
alternative dhcp client is required?
It looks like a small, basic, DHCP client is needed during the early boot just
to get on the network to reach the metadata service. That would be before
NetworkManager gets involved.
Yes, I understand that. But I don't understand why. I don't work with
cloud instances, so forgive my naivety. NetworkManager can obtain
address and configure interface to a working state. It seems we want to:
- prevent dispatches from running during metadata configuration phase
- not reaching network.target
- not using NetworkManager.service, but stripped down alternative
Is it different, because DBus is not yet running at that time? Could be
just alternative configuration used to not trigger unwanted parts?
If we had just NetworkManager-metadata.service, using alternate state
directory as well, couldn't it provide similar functionality as
additional dhcpcd/dhclient? Just with few configuration files in
addition, instead of additional compiled package(s)?
Stephen Gallagher pointed out that ELN doesn't have busybox, but it does have
dhcpcd, and that should work fine. I've reverted the switch to udhcpcd and I'm
waiting on upstream cloud-init to have a new release with the recently added
dhcpcd support.
Are there simple steps, where I can as a dhcpcd maintainer try, how
exactly is dhcpcd used during instance configuration process? Can I
prepare VM image using mentioned metadata? Do we have any documentation
on this topic for Fedora or RHEL at least? Can you point me to some
documentation, how to test it?
Best Regards, Petr
--
Petr Menšík
Software Engineer, RHEL
Red Hat,http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
