This version of oslo.policy includes fixes that ensure the Enforcer only
modifies copies of the rules, making it safer in environments that run
tests in parallel where the Enforcer is configured differently.
Change-Id: I8d7a06558cbf073487707fc33219e43beb5fc043
Indicate that idrac-redfish-virtual-media must be used instead,
otherwise a confusing failure will happen.
Change-Id: I3b6ced6dcf03580903f5ea7237fc057f372999f9
If 'agent_url' has been cleared from internal_info
it indicates that the node has been powered off.
Change-Id: Idba486c98e1e92d35fca2e2d156866566acb9e40
Story: 2008583
Task: 41736
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
instance_info is the input from an operator, we should not change that.
Use driver_internal_info instead.
Change-Id: I12b4bc0d4599ccf5ef6fdca91f54f4294b127f9d
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
In devstack/lib/ironic, IRONIC_DEPLOY_DRIVER is defined at line 341.
However variables which use IRONIC_DEPLOY_DRIVER in default value
(e.g. IRONIC_DEPLOY_RAMDISK, IRONIC_DEPLOY_KERNEL, IRONIC_DEPLOY_ISO
and IRONIC_EFIBOOT) are defined at line 276-282.
This will cause problem at line 295-296:
if [[ "$IRONIC_BUILD_DEPLOY_RAMDISK" == "False" && \
! (-e "$IRONIC_DEPLOY_RAMDISK" && -e "$IRONIC_DEPLOY_KERNEL")
So, this commit moves definition of IRONIC_DEPLOY_DRIVER before
its first use.
Change-Id: I74acb32714ce8830d4697fc796146b894aa7d8c9
Currently ilo5 based hardware does not support redfish
based firmware update. This patch fixes the issue by
making the change to to check whether sushy_task.messages
is present. It was also not calling prepare_ramdisk()
before rebooting the system to update the firmware which
has been fixed in this patch.
Change-Id: I9d70fed0de1829973748c06a1342d7a7af0f93d4
Story: #2008403
Task: #41339
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
When setting the boot settings on Supermicro BMCs, the
BootSourceOverrideEnabled must be set to the desired
value whenever the BootSourceOverrideTarget is set or
it will revert to the default value (Once). This is
different than what is currently implemented for other
BMCs in which the BootSourceOverrideEnabled is not set
if it matches the current setting.
This change uses the vendor setting to determine if it's
a Supermicro BMC.
Story: 2008547
Task: 41652
Change-Id: I1b1a6baafd4cc4daa2fbdb82f69ded6253b1fcbf
Get rid of the TODO in the code and prepare for more management
interfaces supporting detect_vendor(). Vendor detecting now runs
during transition to manageable and on power state sync (essentially
same as before but for all drivers not only IPMI).
Update the IPMI implementation to no longer hide exceptions since
they're not handled on the upper level. Simplify the regex and fix
the docstring.
Add the Redfish implementation as a foundation for future
vendor-specific changes.
Change-Id: Ie521cf2295613dde5842cbf9a053540a40be4b9c
The oslo.policy Enforcer() object knows what to do with instances of
oslo.context RequestContext() if you pass it one.
This makes it easier for people to perform policy enforcement since they
don't need to map important authorization information from the context
object into a dictionary (historically called `creds`). This practiced
didn't guarantee any consistency in `creds` implementations.
You also don't need to call context.to_policy_values() anymore. The
oslo.policy library will do that for you under the hood and map context
values into a set of policy attributes it understands.
This commit updates the calls to enforcement to pass in the context
object where applicable.
Change-Id: Ife4ba098303088023e4341354a1e3bc9f378ce93
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
This commit builds on an attempt to introduce a base class that we can
use for protection testing. I'm removing the majority of the fake tokens
and context objects, ultimately removing anything that
keystonemiddleware_authtoken middleware does.
Doing this allows us to set authorization headers directly in the test,
which makes the test case really clear from an input and outcome
perspective because we can see who is make the request and the intended
outcome.
It also removes any need to mock or understand keystonemiddleware
implementation details to implement protection testing in ironic.
Change-Id: I9a3eb62bb41e0623df9aa5c34fde6f343053dd76
This adds a skipped test for every documented path and method
to aid in getting test coverage of existing ACL behaviour, in
preparation for doing the same for secure-rbac.
When adding test coverage, the skip keys should be removed, and
specific test inputs and asserts should be added. The test can be
duplicated and renamed to get the required allow/deny test coverage.
Its possible we can delete some of these stubs as the path/method
shares a policy name with another path/method that has test coverage.
test_acl_existing.yaml was generated with the script
http://paste.openstack.org/show/801106/
Change-Id: Iee91d80cef3b9e6024507171352c6de9e89ce36e
Adds the `[DEFAULT]raw_image_growth_factor` configuration option which
is a scale factor used for estimating the size of a raw image converted
from compact image formats such as QCOW2. By default this is set to 2.0.
When clearing the cache to make space for a converted raw image, the full
virtual size is attempted first, and if not enough space is available a
second attempt is made with the (smaller) estimated size.
Story: 1750515
Task: 9791
Change-Id: Id86e7641329a95f71ac005ee448b0ff4d7d0bbcd
Two drivers already support turning secore boot on and off,
Redfish will follow soon. This patch adds ManagementInterface
calls to get and set the secure boot state.
Story: #2008270
Task: #41561
Change-Id: I96b2697163def52618b4c051a5c85adf7d1818a5
