RHEL 7 does not ship tgtadm or tgtd so they cannot be used in the
deploy ramdisk. This change separates the tgt-specific parts of
the ramdisk into their own element, and adds a new one that supports
targetcli instead.
For now, the tgt implementation can only be used with traditional
busybox ramdisks and the targetcli one can only be used with dracut.
This is because dracut is primarily used for RHEL right now so it
makes sense to keep the dependencies simple. If there is a future
desire to mix and match the implementations that could be done, but
it would require users to explicitly select between tgt and
targetcli.
Change-Id: I4f99c91016287e08d836095c2f2261de8b45abdc
Co-Authored-By: James Slagle <jslagle@redhat.com>
There is a wide variety of tracing options through the various shell
scripts. Some use "set -eux", others explicity set xtrace and others
do nothing. There is a "-x" option to bin/disk-image-create but it
doesn't flow down to the many scripts it calls.
This adds a global integer variable set by disk-image-create
DIB_DEBUG_TRACE. All scripts have a stanza added to detect this and
turn on tracing. Any other tracing methods are rolled into this. So
the standard header is
---
if [ "${DIB_DEBUG_TRACE:-0}" -gt 0 ]; then
set -x
fi
set -eu
set -o pipefail
---
Multiple -x options can be specified to dib-create-image, which
increases the value of DIB_DEBUG_TRACE. If script authors feel their
script should only trace at higher levels, they should modify the
"-gt" value. If they feel it should trace by default, they can modify
the default value also.
Changes to pachset 16 : scripts which currently trace themselves by
default have retained this behaviour with DIB_DEBUG_TRACE defaulting
to "1". This was done by running [1] on patch set 15. See the thread
beginning at [2]
dib-lint is also updated to look for the variable being matched.
[1] https://gist.github.com/ianw/71bbda9e6acc74ccd0fd
[2] http://lists.openstack.org/pipermail/openstack-dev/2014-November/051575.html
Change-Id: I6c5a962260741dcf6f89da9a33b96372a719b7b0
Depending on bootloader and configuration, ramdisks may receive
a ip= kernel parameter that is used for manual network bring up
in the ramdisk. This parameter contains the address of the boot
server. In the absence of ip=, we want the ramdisk to DHCP and
proceed as normal. However, in this case need to know the address
of the boot server. This falls back to a 'boot_server' parameter
for this address if it is not provided via kernel cmdline.
Change-Id: Id1ed15ba125d91fa0a13d8e19d1385082ee5d9e9
Closes-bug: #1401289
Related-bug: #1401298
Instead of hard-coding a list of binaries to include in the dracut
ramdisk, use the existing binary-deps.d functionality to provide a
list. This will allow other ramdisks (such as discovery) to add
the binaries they need.
Change-Id: Ib7ffa15e08db1cc45e93a8f2a5c01369772c93ff
In preparation for enabling Dracut-based ramdisks, this change
factors out functionality that is common to both busybox and Dracut
ramdisks. Said functionality is moved to a ramdisk-base element
which is added as a dependency of the ramdisk element. ramdisk now
only contains the functionality specific to building busybox-based
ramdisks.
bp tripleo-juno-dracut-ramdisks
Change-Id: Iad2907c8be491c88727d87ed5e5a720e5beb66c3
