Adds a new argument disable_ramdisk to the manual cleaning API.
Only steps that are marked with requires_ramdisk=False can be
run in this mode. Cleaning prepare/tear down is not done.
Some steps (like redfish BIOS) currently require IPA to detect
a successful reboot. They are not marked with requires_ramdisk
just yet.
Change-Id: Icacac871603bd48536188813647bc669c574de2a
Story: #2008491
Task: #41540
Split the monolithic guide into several pages: configuration, enrollment
and deployment. Merge duplicating docs into the common locations.
Use code-block for nicer highlighting.
Change-Id: Iaeef9e0cf8deba20a125d3cfacd4ca8ca2f52e84
Chances are much higher the users will find it there. Also correct some
wording (node interfaces -> hardware interfaces), use double ticks for
field names and mention the Wallaby release.
Story: #2008652
Task: #42015
Change-Id: I33956976a9420ade836ab8d37a9488b9a207cef0
This change allows instance_info values to override node interface
definitions, so non-admins can make temporary changes to various
interfaces.
Story: #2008652
Task: #41918
Change-Id: I6c3dc74705bde02bd02882d14838f184f8d4a5e3
This reverts commit b0df0960e2c53a4fe6673ba0a1ed546ffd156dc7.
Reason for revert: Need to split in separate patches and backport virtual media boot part.
Change-Id: Ib182ee6f2894fcdcea369a60dc5bd922a16434e2
This patch adds project scoped access, as part of the work
to delineate system and project scope access.
Adds policies:
* baremetal:volume:list_all
* baremetal:volume:list
* baremetal:volume:view_target_properties
Change-Id: I898310b515195b7065a3b1c7998ef3f29f5e8747
This patch implements the project scoped rbac policies for a
system and project scoped deployment of ironic. Because of the
nature of Ports and Portgroups, along with the subcontroller
resources, this change was a little more invasive than was
originally anticipated. In that process, along with some
discussion in the #openstack-ironic IRC channel, that it
would be most security concious to respond only with 404s if
the user simply does not have access to the underlying node
object.
In essence, their view of the universe has been restricted as
they have less acess rights, and we appropriately enforce that.
Not expecting that, or not conciously being aware of that, can
quickly lead to confusion though. Possibly a day or more of
Julia's life as well, but it comes down to perceptions and
awareness.
Change-Id: I68c5f2bae76ca313ba77285747dc6b1bc8b623b9
* Adds additional policies:
* baremetal:node_get:last_error
* baremetal:node:get:reservation
* baremetal:node:get:driver_internal_info
* baremetal:node:get:driver_info
* baremetal:node:update:driver_info
* baremetal:node:update:properties
* baremetal:node:update:chassis_uuid
* baremetal:node:update:instance_uuid
* baremetal:node:update:lessee
* baremetal:node:update:driver_interfaces
* baremetal:node:update:network_data
* baremetal:node:update:conductor_group
* baremetal:node:update:name
* With new policies, responses of filtering and posted data is
performed. Testing has been added to the RBAC testing files
to align with this and the defaults where pertinant.
* Adds another variation of the common policy check method
which may be useful in the long term. This is too soon to
tell, but the overall purpose is to allow similar logic
patterns to the authorize behavior. This is because the
standard policies are, at present, also used to control
behavior of response, and node response sanitization needs
to be carefully navigated.
This change excludes linked resources such as /nodes/<uuid>/ports,
portgroups, volumes/[targets|connectors]. Those will be in later
changes, as the node itself is quite a bit.
Special note:
* The indicator endpoint code in the API appears to be broken
and given that should be fixed in a separate patch.
Change-Id: I2869bf21f761cfc543798cf1f7d97c5500cd3681
This change adds support for utilising NVMe specific cleaning tools
on supported devices. This will remove the neccessity of using shred to
securely delete the contents of a NVMe drive and enable using nvme-cli
tools instead, improving cleaning performance and reducing wear on the device.
(this specific change adds extra documentation to the earlier set of
patches implementing this).
Story: 2008290
Task: 41168
Change-Id: Ia6d34b31680967a0d14687e5a54d68a1f1644308
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
