* Move liberty -> approved
* Move completed liberty specs to liberty-implemented
* Move kilo -> kilo-implemented
* Move juno -> juno-implemented
* Move kilo-archive -> backlog (moving these to approved causes test
failures because the template changed since kilo)
* Reword the header for the index page
* Update unit tests to look at the new "approved" folder
** NOTE **
This patch does not create placeholders in the previous locations
for each spec. This will be done in the following patch so that the
history is preserved. Both patches must be landed together so that web
links are not broken for long.
Change-Id: I61f02731150ea944eafaa8c6ea702210364b3478
Implements: blueprint feature-based-releases
This commit updates the neutron integration spec to
say that netboot would still be possible with virtual
media drivers when provisioning/tenant networks are
isolated.
Change-Id: Ieb50308820ec25aeba427aae1e97ab1a283457b6
This commit removes the CONF variables
CONF.raid.share_physical_disks, CONF.raid.disk_type and
CONF.raid.interface_type. This is because in heterogenous
hardware environments, it is not possible to provide a single
disk_type and interface_type as the default value as that will
lead to cleaning failures (when it is unable to find suitable
devices). If operator wants to use specific type of disks for a
bare metal node, they should rather set it in node's target
raid config. It also removes CONF.raid.share_physical_disks as it
is not common to share physical disks across RAID disks (and if
required can again be set to False in the node's target_raid_config).
Change-Id: Ia5e2c2774c71d68506742edd15f68a37f1131761
This improves the problem description, fixes config options to use "_"
rather than "-", and adds another reference as to why metrics are
useful to operators.
blueprint add-pluggable-metrics-backend-for-ironic-and-ipa
Change-Id: I647fc1ab265eccf79591f0a4e4dc6b25d0e13fa8
Add support for running destructive and long running tasks from
MANAGED state, such as configuring RAID or doing burn in.
The changes since Kilo is the addition of caching of clean/zap
steps to make the get_clean_steps or get_zap_steps API faster.
Also adds support for those APIs to wait for interfaces that must
take asynchronous steps to get the steps (like IPA).
This will require allowing APIs to return an empty response
and header that indicates when to check back.
blueprint: implement-zapping-states
Previously-approved: Kilo
Change-Id: I09491472d713fd7930f5592ae168cad3f92a16c2
This spec proposes how Ironic can provide the requisite
connectivity information to Neutron to allow drivers to
provision the top-of-rack switch for the baremetal server.
Implements: blueprint ironic-ml2-integration
Change-Id: I7841599c9bf42a8442e679eeed05cb5d00eae4b3
Make ilo drivers standalone in ironic by
removing swift dependency. This spec also proposes
to deprecate the config variables `http_url` and
`http_root` under `[pxe]` and move them under
`[deploy]` section as `http_server_url` and
`http_server_root`.
Change-Id: I86393ae121c49e10d2a69ec72c3f2754df944ec4
This blueprint proposes the addition of metric data reporting features
to Ironic, and Ironic Python Agent (IPA). Initially, this will include a
statsd reference implementation, but will be sufficiently generic to
permit the creation of alternative backends.
Blueprint: add-pluggable-metrics-backend-for-ironic-and-ipa
Change-Id: Ie5d7a83780252259c099ed6e2dfd6e4cd7fe453b
This commit changes the proposed generic RAID interface
to use two database fields for storing raid_config and
target_raid_config and adds REST APIs to read/write values
into the fields.
Change-Id: I54178cfdf56b855f1c07eca38518cf3175fad6f9
Futurist is a new Oslo library providing tools for writing asynchronous code.
This spec suggests switching our periodic task implementation to Futurist to
solve some long-standing problems.
https://github.com/openstack/futurist
Change-Id: Ia23fbf595001247b6e4436429caa1ed7842695b7
This spec describes introduction of ``enroll`` state, which we previously
agreed to introduce in the new state machine spec.
Spec for blueprint enroll-node-state
Change-Id: I2b39f265e864c58ec70a1a06efcc65e5d5d5b115
This blueprint adds support for generating Swift temporary URLs for the
deploy and image's ramdisk(s) and kernel(s) when booting with iPXE.
This blueprint depends on the blueprint ipxe-dymic-config that makes
the iPXE configuration files to be dynamically generated.
Change-Id: Ibae6e6401fa0458b8ecc74b47a213d587f4974a5
This commit moves the spec for generic RAID
configuration interface from kilo to liberty.
It also changes location of the current and target
RAID configuration in the DB to their own respective
fields.
Change-Id: Id7b64ccaaf327b9e1c6e6702ba79c9b86a982c19
This blueprint adds support for dynamically generating iPXE configuration
files when booting a node.
Change-Id: I443d969638ce56beb5bc9b8484b65fdac4bc469a
Implement client-side version caching to the ironicclient so that
each conversation between ironic and the client need not
renegotiate which version to use.
Change-Id: Icb29fdc92ecd54e388b7c16899070572458308da
This provides a trusted boot solution, to determine the node
is trusted or not after deployed with Ironic, leveraging
Intel TXT to measure BIOS, Option ROM and Kernel/Ramdisk.
Talk and Demo:
https://www.openstack.org/summit/openstack-paris-summit-2014/
session-videos/presentation/trusted-bare-metal-what-and-39-s-that
Co-Authored-By: Bhandaru, Malini K <malini.k.bhandaru@intel.com>
Co-Authored-By: Villalovos, John L <john.l.villalovos@intel.com>
Change-Id: I046030cc42f943435ec6fc078c31228c1b22bd99
This commit proposes to add new boot interface
in Ironic and refactor the current upstream
deploy drivers to follow this logic.
Change-Id: Ie7321b925397e3185dde654b21660a63eed0fd9f
Fix a typo in tempate.rst. This has caused us the same recurrent
typos in past drafts of some specs.
Change-Id: Iff6f5eaffe99e096626a5deb92c88533b4c9673d
This adds a 'Client (CLI) impact' section to the specification template.
The place to capture this information was in 'Other end user impact' but
that isn't explicit enough for people to know to put that information
there or for the reviewers to look there for that information.
Having an explicit section will also make it easier later, to check
that the feature proposed in the specification has been completely
implemented.
Change-Id: If8bec359034d35b4edf32f473645c1c87a9fe479