Some of the early test changes for the RBAC work have merged
which is awesome, but a couple minor follow-up items should be
addressed. They are so minor it doesn't really make sense to merge
in with one of the patches in the chain.
Change-Id: I85de4d953237f240c3c220f6a57169c633fb295f
Testing every combination of role, endpoint and policy rule would
result in a huge test count, so to make testing the existing policy
rules complete and practical, the following guidelines are suggested:
- Only the default policy is tested, so inactive rules such as
is_node_owner, is_node_lessee are ignored.
- Each rule is tested completely on one endpoint which uses it.
- A rule (such as baremetal:node:list) which inherits a parent rule
(baremetal:node:get) is considered covered by the parent test.
- All endpoints need at least one test, but other endpoints which share
a fully tested rule only need one denied test which shows that they
are covered by some policy.
Also adds the initial pass of contributor documentation on how the
rbac testing works to try and express the mechanics and what to
expect to aid in reviewing/updating/editing the rules.
Co-Authored-By: Julia Kreger <juliaashleykreger@gmail.com>
Change-Id: I1cd88210e40e42f86464e6a817354620f5ab1d9c
Indicate that idrac-redfish-virtual-media must be used instead,
otherwise a confusing failure will happen.
Change-Id: I3b6ced6dcf03580903f5ea7237fc057f372999f9
All capabilities, except for boot_mode, are read from instance_info.
This change makes instance_info.capabilities[boot_mode] work as well
and deprecates instance_info.deploy_boot_mode.
Note that the special handling of properties.capabilities[boot_mode]
is kept in this patch.
Change-Id: Ic2e7fd4c71b7a7bc2950d17f7e1bbdad73bbb8a7
For some (likely historical) reasons we only use it for PXE and iPXE,
but the same logic applies to any boot interface (since it depends
on how the management interface and the BMC work, not on the boot
method). This change moves its handling to conductor utils.
Change-Id: I948beb4053034d3c1b4c5b7c64100e41f6022739
One of the biggest frustrations larger operators have is when they
trigger a massive number of concurrent deployments. As one would
expect, the memory utilization of the conductor goes up. Except,
even with the default number of worker threads, if we're requested
to convert 80 images at the same time, or to perform the write-out
to the remote node at the same time, we will consume a large amount
of system RAM. Or more specifically, qemu-img will consume a large
amount of memory.
If the amount of memory goes too low, the system can trigger
OOMKiller which will slay processes using ram. Ideally, we do not
want this to happen to our conductor process, much less the work
that is being performed, so we need to add some guard rails to help
keep us from entering into situations where we may compromise the
conductor by taking on too much work.
Adds a guard in the conductor to prevent multiple parallel
deployment operations from running the conductor out of memory.
With the defaults, the conductor will attempt to throttle back
automatically and hold worker threads which will slow down the
amount of work also proceeding through the conductor, as we are
in a memory condition where we should be careful about the work.
The defaults allow this to occur for a total of 15 seconds between
re-check of available RAM, for a total number of six retries.
The minimum default is 1024 (MB), as this is the amount of memory
qemu-img allocates when trying to write images. This quite literally
means no additional qemu-img process can spawn until the default
memory situation has resolved itself.
Change-Id: I69db0169c564c5b22abd0cb1b890f409c13b0ac2
For historical reasons we always base64+gzip configdrives, even
when accessing them via a URL. This change allows binary images
to work for the redfish-virtual-media case.
Change-Id: If19144de800b67275e3f8fb297f0a5c4a54b2981
1) Do not issue a warning if the boot interface supports configdrive
2) Implement missing support for Swift URLs in configdrives
Change-Id: I4b06478a14ab514d785f8e3972e5afbd79f8d3b5
We use maintenance mode to signal that hardware needs additional
intervention, because of potential damage or stuck long-running
processes. This is not the case for PXE booting or invalid requested
manual clean steps, so don't set maintenance if no clean step is
running when the failure occurs.
Change-Id: I8a7ce072359660fc6640e5f20ec2d3c452033557
Adds the status upgrade check for the JSON to YAML migration
effort and updates the documentation where it seems appropriate
to move from "policy.json" to "policy.yaml"
Mostly shamelessly copied from https://review.opendev.org/#/c/748059/
however is in-line with ironic's configuration and patching methods.
Related Blueprint: policy-json-to-yaml
Change-Id: I1d5b3892451579ebfd4d75a0f7185e0ef3c984c8
Add a simple sample about configuring bonding via configdrive,
and it can make user to use port group more easily.
Story: 2008474
Task: 41514
Signed-off-by: huth <428437106@qq.com>
Change-Id: Ic425ecb35bfa173adf72b0ee104d28c6b79cb4b1
When using Redfish virtual media, it's possible to connect a configdrive
via a free USB slot when the ramdisk deploy is used.
Using Swift as configdrive storage is not supported in this case yet.
Story: #2008380
Task: #41302
Change-Id: Ib847dbfe96072cfe4137388ba88ef133bd7ab186
I could not make the ramdisk side work on a variety of distributions,
the same problem has been confirmed by another contributor. Until we
get a working procedure for building a ramdisk, add an ugly warning
to the documentation.
Change-Id: I12100539b9987fcb47ba81c75ec96ed501d50c82
The current documentation is basically unreadable and contains a few
factual errors. Rewrite it for simplicity and move to a separate file
since at least 2 hardware types claim its support.
The patch does not concern the current status of the feature, an
easily revertable follow-up will be posted for that.
Change-Id: I3404378333316b0736ce07610a1dbbd7847bac00
Fix the command to submit new releases and adds command reference
for the intermediate bugfix branches.
Change-Id: I79a039a6effcf8bd13e5c3ab5a231d5b515c8297
Supermicro machines, when in UEFI mode, have a different
device number, in binary, to represent the hard disk from
other vendors such as Fujitsu which actually has somewhat
similar code in their driver.
This means we need to be somewhat cognizent of the vendor of
the BMC and possibly update the device mapping based upon that
vendor.
This may ultimately fix a number of IPMI related problems, because
there is a reliance upon the text output of ipmitool, which only
reads the bytes retured by the BMC, which may not be reality after
the next reset, espescialy if ipmitool doesn't know of the UEFI
operating difference.
Change-Id: Ie19db9e0cf1eafdfc9bb46248f4d457337821f94
Story: 2008241
Task: 41085