This commit is a follow-up to Ie86ec57e428e2bb2efd099a839105e51a94824ab
Story: #2008571
Task: #42546
Change-Id: I6fa4658180772ff9c4ff00f95b28cf8a1b5d4223
Provide the fields in the BIOS setting API -
``/v1/nodes/{node}/bios/{setting}``, and in the BIOS setting list API
when details are requested - ``/v1/nodes/<node>/bios?detail=True``.
Story: #2008571
Task: #42483
Change-Id: Ie86ec57e428e2bb2efd099a839105e51a94824ab
Yes, project conundrum is a code-name for our transition to OFTC
as we do not want to put anything into freenode IRC which may abruptly
result in the channel being siezed or shutdown by the new
owners/operators of freenode
Change-Id: I45c07e0b2138f6643f865d58155c64317114fd02
See: http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022718.html
Adds a horribly written, just hacked together little tool to help
provide sizing insight into an ironic deployment's state and underlying
performance.
Key data:
* Queries the list of node from a pure python interface level with the
database and reports timeing for the list of nodes to be returned.
This information helps convey how long a periodic hits the database
just for the query.
* Requests *all* nodes using the query pattern/structure of the nova
resource tracker, and uses the marker to make any additional requsts.
The data is parsed, and collected, and counts identified vendors,
if any.
* Collects basic data on conductors in terms of running, conductor groups
as well as currently loaded drivers in the deployment.
All of this information provides operational insight into *what*
conditions exist within the deployment allowing developers to try
and identify solutions based on the unique circumstances of larger
deployments.
Also adds a utility to generate and semi-randomize data to allow us to
create a benchmark job in CI.
Change-Id: Iae660aea82db8f1c4567ee2982595ccfdf434fe3
Fixing another case of bios interface missing from the api-ref
documentation, this one for the validate API.
Change-Id: I8ae3212f04a8d150af8adde5f5f87e5a5451da14
Get the BIOS Registry from Sushy and store the fields in the Ironic
DB with the corresponding entry in the BIOS setting.
Story: #2008571
Task: #42484
Change-Id: I606c5de9077931707ebd15c3adf506badd95ea29
When the configdrive input is JSON (meta_data, etc), delay the rendering
until the ISO image is actually used. It has two benefits:
1) Avoid storing a large ISO image in instance_info,
2) Allow deploy steps to access the original user's input.
Fix configdrive masking to correctly mask dicts.
Story: #2008875
Task: #42419
Change-Id: I86d30bbb505b8c794bfa6412606f4516f8885aa9
We should only use prefixed driver_info parameters when they are either
unique to the driver or have different meanings for different drivers.
This is not the case for deploy_iso, but we use vendor prefixes for
historical reasons.
This change migrates the redfish-virtual-media boot interface and
creates helpers to fascilitate migration of other boot interfaces.
Change-Id: I698d1c90592e8de2cb24d6e2cf819e7f6ac3911f
Story: #2008880
Task: #42425
Secure RBAC, along with numerous periodics, and even some common API
access patterns heavily access the ironic database and sometimes cause
queries across multiple columns to match nodes to return.
None of this is bad, but what is bad is we didn't have indexes on these
columns.
This change adds docs, and the schema upgrade to create the column
indexes, and a release note to provide more visible documentation
for operators.
It must be stressed that this does *not* improve query times
when all records are asked for on a database connection.
Also adds an upgrade check in to raise a warning for operator
visibility.
Story: 2008863
Task: 42392
Change-Id: I76821c032180a58d0f99d31110fbe0f844c0cb3f
Currently handling of kernel_append_params is very inconsistent. This
change applies a straightforward process:
1. instance_info[kernel_append_params]
2. driver_info[kernel_append_params]
3. [$driver]kernel_append_params
Story: #2008902
Task: #42472
Change-Id: Ib83594743ae58ea26dbd9875c98ab169dd5ab009
Currently handling of kernel_append_params is very inconsistent. This
change applies a straightforward process:
1. instance_info[kernel_append_params]
2. driver_info[kernel_append_params]
3. [$driver]kernel_append_params
The existing ilo_kernel_append_params is declared but never implemented,
so it's removed without deprecation in favor of the new option.
Story: #2008902
Task: #42470
Task: #42471
Change-Id: I0fcd7c63a4bc41110eb7f4cd4031580ef98d9a19
Currently handling of kernel_append_params is very inconsistent. This
change applies a straightforward process:
1. instance_info[kernel_append_params]
2. driver_info[kernel_append_params]
3. [pxe]kernel_append_params (renamed from pxe_append_params).
Also adds a helper for subsequent fixes in other drivers.
Change-Id: I79bcf4d8ef1f0f55a82e0991dd5bb1685b3f7957
Story: #2008902
Task: #42469
This is a doc change to add bios_interface to the api reference. Its
included in the detailed node list and node show but wasn't shown
in the api-ref.
Change-Id: I8735d10db1644f8a2c872c75c156c75c06b79c0c
* Add optional Glance and Neutron integration.
* Migrate and expand the configdrive section from the install guide.
* Explain how to use cloud-init boot scripts.
* Explain allocations and mention metalsmith as an easy CLI.
* Use more realistic URLs and checksums in the examples.
* Remove a reference to local boot, it's the default nowadays.
* Replace the iLO note with a more generic one.
* Small fixes and clean ups.
Change-Id: I28ac60da6722b9ca2c2b571511070010145958f6
Setuptools v54.1.0 introduces a warning that the use of
dash-separated options in 'setup.cfg' will not be supported
in a future version [1].
Get ahead of the issue by replacing the dashes with underscores.
Without this, we see 'UserWarning' messages
like the following on new enough
versions of setuptools:
UserWarning: Usage of dash-separated 'description-file' will not be
supported in future versions. Please use the underscore name
'description_file' instead
[1] https://github.com/pypa/setuptools/commit/a2e9ae4cb
Change-Id: If07c53b62d32d2bc3d519b4f541f267995e522fe
Currently it only contains (outdated) explanations how Ironic works.
Move them one level deeper and migrate the content relevant to users:
* Preparing instance images from the installation guide
* Deploying nodes from the standalone guide
Compatibility shims are provided for migrated pages.
Change-Id: I8468da377b7878eb3d1a61e6a6bcd4ac8a5f06d7
The openstack Ussuri and Victoria versions no longer support the
Centos7 and pyrhon2 environment packages. Correct the missing
problems in the latest document
Change-Id: I60787243fdc6ed2741522355ec79970bdb912f41
If the agent accepts a command, but is unable to reply to Ironic (which
sporadically happens before of the eventlet's TLS implementation), we
currently retry the request and fail because the command is already
executing. Ironic now detects this situation by checking the list of
executing commands after receiving a connection error. If the requested
command is last one, we assume that the command request succeeded.
Ideally, we should pass a request ID to IPA and then compare it. Such
a change would affect the API contract between the agent and Ironic
and thus would not be backportable.
Change-Id: I2ea21c9ec440fa7ddf8578cf7b34d6d0ebbb5dc8
