Although clevis cares deeply about this issue, we don't manage any network configuration. This is a dracut issue. The only thing that clevis does is declare that we need networking:

https://github.com/latchset/clevis/blob/master/src/dracut/module-setup.sh#L27

npmccallum per Comment #2

There does not appear to any way to hand in desired network configuration information
   none, static, dhcp
and the companion sub-parameters, as is done in anaconda va kernel line arguments

This appears to be a deficiency in clevis / tang's configuration file grammar specification

========

I may split this into a separate bug, but the Reporter's filing omits mentioning that seemingly different Hardware MAC addresses are being offered, as the DHCP address given to Clevis / tang is different from that which it assigned once the later DHCP settings are parsed ... I unders6tnad that it has been handed off to Dracut but this may be in your wheelhouse

To be honest I am a bit confused here and I don't know much about clevis.

I assume that you have an existing setup where network is set up by initramdisk. Then the configuration for it is probably stored on kernel cmdline in form of ip=...
 
But in this case dracut -f should not change anything since the ip line is stored in grub configuration which is not touched in this case.

Can you please elaborate what is your existing setup and what you need from dracut?

Install RHEL 7 minimal
Configure static ip on the only nic via the appropriate /etc/sysconfig/network-scripts/ifcfg-<nic> file

Reboot, and it uses the static ip.

Install and configure clevis and dracut-clevis

This will add rd.network = 1 to the initrd but will NOT copy the static ip into the initrd.

Reboot the machine, the initrd is now set to dhcp which (assuming there is a dhcp server) will pick up an ip for the initrd.  Once it pivots out of the initrd, whatever you have in /etc/sysconfig/network-scripts/ifcfg-<nic> will be replaced with a dhcp based config which says
# Generated by dracut initrd
NAME="ens3"
DEVICE="ens3"
ONBOOT=yes
NETBOOT=yes
UUID="ac4673cd-a521-4d2f-b10c-405711ac62c7"
IPV6INIT=yes
BOOTPROTO=dhcp
TYPE=Ethernet

I believe the culprit is in the 
/usr/lib/dracut/moduels/60clevis/module-setup.sh file with this stanza starting at line 49
cmdline() {
    echo "rd.neednet=1"
}

dracut documentation indicates w/o a static ip fed into the initrd, it will use dhcp, which is the behavior I am seeing.

I believe this should be modified to include the appropriate kernel cmdline arguements (extracted from the sysconfig files of course) to use the same ip for the initrd invocation.  I realized after I opened the bug that I used the 4.x kernel cmdline ip format instead of the 3.x kernel commands in my bug opening statement.

I have not tested this with multiple nics so I don't know if all of them have to be copied into the initrd, or just the one that is used to contact the tang server.

It also needs to account for changes from dhcp to static or vice versa, if not automatically, at least with a note in the config file and documentation.  

Also, what happens if I install a new kernel?  Or boot into an older kernel?  If it can't all be done automatically, then it would seem to need some documentation.

Thanks for detail explanation! So I don't think that there is any problem in dracut, the initrd does exactly what it was told, it starts the network and since it does not have any additional information it uses dhcp.

To be honest I don't think that there is an easy solution for this. We don't have any mechanism how to turn ifcfg files to ip= and it is not trivial task to do. Sure one device with static address is easy, but our customers often use bonds, bridges, vlans,....

I would compare this problem to a situation where you have installed your system on local disk and now you want to boot from network.

But generally, why do you unconditionally add rd.neednet=1? If this is not needed to mount / or /usr you can do everything after later and you don't need network in initrd.

(In reply to Lukáš Nykrýn from comment #6)
> But generally, why do you unconditionally add rd.neednet=1? If this is not
> needed to mount / or /usr you can do everything after later and you don't
> need network in initrd.

I believe it *is* needed to mount /, that's the whole point of the clevis-dracut integration.

Realistically, I see the following resolution:

1) We document it (on clevis side) that such scenario is either unsupported or limited (simple static addresses, ie. no VLANs, etc.) with a specific documented procedure, referencing dracut documentation

2) We file a RFE on dracut to support detection of static network configuration from ifcfg files (at some level, to some extent), so clevis can make use of it if/when it becomes available

Whether this bug 1497566 is used to track the decision / documentation effort of clevis or the RFE for dracut, or whether it is closed as NOTABUG (and two new bugs filed), I leave to the current reporter/assignee.

It's definitely not a bug in dracut.  It is an issue with dracut-clevis specifically, or perhaps the entire clevis/tang suite which needs to be documented and called out.

Currently this is included in the 7.4 release and the issue with static ip's is not documented anywhere (I found it as I was preparing a talk for Ohio Linux Fest...)

If we are talking about /, then this should be done in anaconda. This is basically the same case as network boot and they have tools to properly generate complex ifcfg files and ip=... line.

How is this a bug in clevis? We don't do networking... We only tell dracut that we *need* networking and expect dracut to bring it up for us.

(In reply to Jim Wildman from comment #8)
> It's definitely not a bug in dracut.  It is an issue with dracut-clevis
> specifically, or perhaps the entire clevis/tang suite which needs to be
> documented and called out.
> 
> Currently this is included in the 7.4 release and the issue with static ip's
> is not documented anywhere (I found it as I was preparing a talk for Ohio
> Linux Fest...)

(In reply to Nathaniel McCallum from comment #10)
> How is this a bug in clevis? We don't do networking... We only tell dracut
> that we *need* networking and expect dracut to bring it up for us.

It is a "bug" in clevis in that it is not documented that this combination doesn't work, not in the sense that clevis should provide an automated way to parse ifcfg files to configure kernel cmdline for dracut, that would be way out of scope of clevis or the NBDE project.

(In reply to Lukáš Nykrýn from comment #9)
> If we are talking about /, then this should be done in anaconda. This is
> basically the same case as network boot and they have tools to properly
> generate complex ifcfg files and ip=... line.

This setup can be, at any time, installed on an existing system with a LUKS encrypted drive (it uses another LUKS keyslot) - as such, it doesn't make much sense to do it in anaconda.

The RFE for dracut I mentioned would be similar to how mdadmconf=yes or lvmconf=yes work, ie. ifcfgconf=yes, which would make the initramfs generator include (some/all) ifcfg files in the initramfs, along with some logic utilizing them.
Whether such RFE is accepted or developed or whether the feature remains unsupported would be another thing.

Static IP configuration is documented for dracut. See for example:

https://wwoods.fedorapeople.org/doc/dracut-notes.html#networking
https://fedoraproject.org/wiki/Dracut/Options#Network

See also: man dracut.kernel

All of these bits of documentation clearly define how to configure static IP in dracut. So clevis should document that using static IPs with clients requires additional configuration and point to the dracut documentation.

Separately, we should file a bug with dracut to automatically import system static IP settings.

Is everyone cool with this plan?

That's fine with me.  I'll gladly open the bugs/rfe's.

I don't see a dracut-clevis component in the drop down (only dracut and clevis).

Which component does dracut-clevis belong with or what do you want me to tag in the new tickets?

I've confirmed that the right invocation of dracut on RHEL 7 appears to be 

dracut -f --kernel-cmdline "ip=192.168.122.16 netmask=255.255.255.0 gateway=192.168.122.1 nameserver=192.168.122.1"

This boots the box with the correct static ip (in this case 192.168.122.16) and other parameters.  It does still regenerate the ifcfg-ens3 file in /etc/sysconfig/netwwork-scripts, but it does so with the static config in place.  Note the "Generated by dracut" at the top of the file

# Generated by dracut initrd
NAME="ens3"
DEVICE="ens3"
ONBOOT=yes
NETBOOT=yes
UUID="e685031b-0697-46c1-9e3a-e3de15198f92"
IPV6INIT=yes
BOOTPROTO=none
IPADDR="192.168.122.16"
NETMASK="255.255.255.0"
GATEWAY="192.168.122.1"
TYPE=Ethernet
DNS1="192.168.122.1"


The dracut.cmdline man page appears to be copied from the latest Fedora and references the new (4.x?) kernel command line format which is in my original bug report.

Will open specific bugs as discussed with Nathaniel.

(In reply to  Jiri Jaburek from comment #11)
> The RFE for dracut I mentioned would be similar to how mdadmconf=yes or
> lvmconf=yes work, ie. ifcfgconf=yes, which would make the initramfs generator
> include (some/all) ifcfg files in the initramfs, along with some logic
> utilizing them.
> Whether such RFE is accepted or developed or whether the feature remains
> unsupported would be another thing.

(In reply to Jim Wildman from comment #15)
> Will open specific bugs as discussed with Nathaniel.

Have you opened those bugs, yet?

There is an analogous issue under Fedora when the Dracut systemd-networkd module is enabled. Currently, that module also doesn't include any network configuration into the initramfs (i.e. /etc/systemd/network/*).

Having it include the network config by default (unless something like networkdconf=no is set) would make a lot of sense.

See also: bug 1582941 systemd-networkd dracut module doesn't include /etc/systemd/network files