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 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
