ironic-10.1.1/0000775000175100017510000000000013243617733013112 5ustar zuulzuul00000000000000ironic-10.1.1/tools/0000775000175100017510000000000013243617733014252 5ustar zuulzuul00000000000000ironic-10.1.1/tools/check-releasenotes.py0000777000175100017510000000274213243617464020403 0ustar zuulzuul00000000000000#!/usr/bin/python -tt # Copyright (c) 2017 Intel Corporation # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. from __future__ import print_function import os import re import sys RELEASE_NOTES_DIR = "releasenotes/notes/" IGNORE_FILES = ( 'releasenotes/notes/fix-get-deploy-info-port.yaml', # Newton 6.0.0 'releasenotes/notes/fix-mitaka-ipa-iscsi.yaml', # Newton 6.0.0 ) def main(): return_code = 0 for filename in os.listdir(RELEASE_NOTES_DIR): file_path = os.path.join(RELEASE_NOTES_DIR, filename) if not os.path.isfile(file_path): continue if not file_path.endswith('.yaml'): continue if file_path in IGNORE_FILES: continue if not re.search(r'.*-[0-9a-f]{16}\.yaml', file_path): return_code = 1 print("Error: Release notes file: {!r} was not created with " "'reno new'".format(file_path)) return return_code if '__main__' == __name__: sys.exit(main()) ironic-10.1.1/tools/run_bashate.sh0000777000175100017510000000205413243617464017110 0ustar zuulzuul00000000000000#!/bin/bash # # Licensed under the Apache License, Version 2.0 (the "License"); you may # not use this file except in compliance with the License. You may obtain # a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, WITHOUT # WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the # License for the specific language governing permissions and limitations # under the License. find "$@" -not \( -type d -name .?\* -prune \) \ -type f \ \( \ -wholename \*/devstack/lib/ironic -or \ -name \*.sh \ \) \ -print0 | xargs -0 bashate -v -iE006 -eE005,E042 ironic-10.1.1/tools/policy/0000775000175100017510000000000013243617733015551 5ustar zuulzuul00000000000000ironic-10.1.1/tools/policy/ironic-policy-generator.conf0000666000175100017510000000011513243617464023164 0ustar zuulzuul00000000000000[DEFAULT] output_file = etc/ironic/policy.json.sample namespace = ironic.api ironic-10.1.1/tools/flake8wrap.sh0000777000175100017510000000073513243617464016665 0ustar zuulzuul00000000000000#!/bin/bash # # A simple wrapper around flake8 which makes it possible # to ask it to only verify files changed in the current # git HEAD patch. # # Intended to be invoked via tox: # # tox -epep8 -- -HEAD # if test "x$1" = "x-HEAD" ; then shift files=$(git diff --name-only HEAD~1 | tr '\n' ' ') echo "Running flake8 on ${files}" diff -u --from-file /dev/null ${files} | flake8 --diff "$@" else echo "Running flake8 on all files" exec flake8 "$@" fi ironic-10.1.1/tools/config/0000775000175100017510000000000013243617733015517 5ustar zuulzuul00000000000000ironic-10.1.1/tools/config/ironic-config-generator.conf0000666000175100017510000000111213243617464023076 0ustar zuulzuul00000000000000[DEFAULT] output_file = etc/ironic/ironic.conf.sample wrap_width = 62 namespace = ironic namespace = ironic_lib.disk_utils namespace = ironic_lib.disk_partitioner namespace = ironic_lib.metrics namespace = ironic_lib.metrics_statsd namespace = ironic_lib.utils namespace = oslo.db namespace = oslo.messaging namespace = oslo.middleware.cors namespace = oslo.concurrency namespace = oslo.policy namespace = oslo.log namespace = oslo.service.service namespace = oslo.service.periodic_task namespace = oslo.service.sslutils namespace = osprofiler namespace = keystonemiddleware.auth_token ironic-10.1.1/tools/config/check_uptodate.sh0000777000175100017510000000154113243617464021044 0ustar zuulzuul00000000000000#!/usr/bin/env bash PROJECT_NAME=${PROJECT_NAME:-ironic} CFGFILE_NAME=${PROJECT_NAME}.conf.sample OSLO_CFGFILE_OPTION=${OSLO_CFGFILE_OPTION:-tools/config/ironic-config-generator.conf} if [ -e etc/${PROJECT_NAME}/${CFGFILE_NAME} ]; then CFGFILE=etc/${PROJECT_NAME}/${CFGFILE_NAME} elif [ -e etc/${CFGFILE_NAME} ]; then CFGFILE=etc/${CFGFILE_NAME} else echo "${0##*/}: can not find config file" exit 1 fi TEMPDIR=`mktemp -d /tmp/${PROJECT_NAME}.XXXXXX` trap "rm -rf $TEMPDIR" EXIT oslo-config-generator --config-file=${OSLO_CFGFILE_OPTION} --output-file ${TEMPDIR}/${CFGFILE_NAME} if [ $? != 0 ]; then exit 1 fi if ! diff -u ${TEMPDIR}/${CFGFILE_NAME} ${CFGFILE}; then echo "${0##*/}: ${PROJECT_NAME}.conf.sample is not up to date." echo "${0##*/}: Please run oslo-config-generator --config-file=${OSLO_CFGFILE_OPTION}" exit 1 fi ironic-10.1.1/tools/__init__.py0000666000175100017510000000000013243617464016354 0ustar zuulzuul00000000000000ironic-10.1.1/tools/states_to_dot.py0000777000175100017510000001103213243617464017502 0ustar zuulzuul00000000000000#!/usr/bin/env python # Copyright (C) 2014 Yahoo! Inc. All Rights Reserved. # # Licensed under the Apache License, Version 2.0 (the "License"); you may # not use this file except in compliance with the License. You may obtain # a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, WITHOUT # WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the # License for the specific language governing permissions and limitations # under the License. import optparse import os import sys from automaton.converters import pydot from ironic.common import states top_dir = os.path.abspath(os.path.join(os.path.dirname(__file__), os.pardir)) sys.path.insert(0, top_dir) def print_header(text): print("*" * len(text)) print(text) print("*" * len(text)) def map_color(text, key='fontcolor'): """Map the text to a color. The text is mapped to a color. :param text: string of text to be mapped to a color. 'error' and 'fail' in the text will map to 'red'. :param key: in returned dictionary, the key to use that corresponds to the color :returns: A dictionary with one entry, key = color. If no color is associated with the text, an empty dictionary. """ # If the text contains 'error'/'fail' then we'll return red... if 'error' in text or 'fail' in text: return {key: 'red'} else: return {} def main(): parser = optparse.OptionParser() parser.add_option("-f", "--file", dest="filename", help="write output to FILE", metavar="FILE") parser.add_option("-T", "--format", dest="format", help="output in given format (default: png)", default='png') parser.add_option("--no-labels", dest="labels", help="do not include labels", action='store_false', default=True) (options, args) = parser.parse_args() if options.filename is None: options.filename = 'states.%s' % options.format def node_attrs(state): """Attributes used for drawing the nodes (states). The user can perform actions on stable states (and in a few other cases), so we distinguish the stable states from the other states by highlighting the node. Non-stable states are labelled with gray. This is a callback method used by pydot.convert(). :param state: name of state :returns: A dictionary with graphic attributes used for displaying the state. """ attrs = map_color(state) if source.is_stable(state): attrs['penwidth'] = 1.7 else: if 'fontcolor' not in attrs: attrs['fontcolor'] = 'gray' return attrs def edge_attrs(start_state, event, end_state): """Attributes used for drawing the edges (transitions). There are two types of transitions; the ones that the user can initiate and the ones that are done internally by the conductor. The user-initiated ones are shown with '(via API'); the others are in gray. This is a callback method used by pydot.convert(). :param start_state: name of the start state :param event: the event, a string :param end_state: name of the end state (unused) :returns: A dictionary with graphic attributes used for displaying the transition. """ if not options.labels: return {} translations = {'delete': 'deleted', 'deploy': 'active'} attrs = {} attrs['fontsize'] = 12 attrs['label'] = translations.get(event, event) if (source.is_stable(start_state) or 'fail' in start_state or event in ('abort', 'delete')): attrs['label'] += " (via API)" else: attrs['fontcolor'] = 'gray' return attrs source = states.machine graph_name = '"Ironic states"' graph_attrs = {'size': 0} g = pydot.convert(source, graph_name, graph_attrs=graph_attrs, node_attrs_cb=node_attrs, edge_attrs_cb=edge_attrs) print_header(graph_name) print(g.to_string().strip()) g.write(options.filename, format=options.format) print_header("Created %s at '%s'" % (options.format, options.filename)) if __name__ == '__main__': main() ironic-10.1.1/tools/test-setup.sh0000777000175100017510000000370713243617464016740 0ustar zuulzuul00000000000000#!/bin/bash -xe # This script will be run by OpenStack CI before unit tests are run, # it sets up the test system as needed. # Developers should setup their test systems in a similar way. # This setup needs to be run as a user that can run sudo. # The root password for the MySQL database; pass it in via # MYSQL_ROOT_PW. DB_ROOT_PW=${MYSQL_ROOT_PW:-insecure_slave} # This user and its password are used by the tests, if you change it, # your tests might fail. DB_USER=openstack_citest DB_PW=openstack_citest sudo -H mysqladmin -u root password $DB_ROOT_PW # It's best practice to remove anonymous users from the database. If # a anonymous user exists, then it matches first for connections and # other connections from that host will not work. sudo -H mysql -u root -p$DB_ROOT_PW -h localhost -e " DELETE FROM mysql.user WHERE User=''; FLUSH PRIVILEGES; GRANT ALL PRIVILEGES ON *.* TO '$DB_USER'@'%' identified by '$DB_PW' WITH GRANT OPTION;" # Now create our database. mysql -u $DB_USER -p$DB_PW -h 127.0.0.1 -e " SET default_storage_engine=MYISAM; DROP DATABASE IF EXISTS openstack_citest; CREATE DATABASE openstack_citest CHARACTER SET utf8;" # Same for PostgreSQL # The root password for the PostgreSQL database; pass it in via # POSTGRES_ROOT_PW. DB_ROOT_PW=${POSTGRES_ROOT_PW:-insecure_slave} # Setup user root_roles=$(sudo -H -u postgres psql -t -c " SELECT 'HERE' from pg_roles where rolname='$DB_USER'") if [[ ${root_roles} == *HERE ]];then sudo -H -u postgres psql -c "ALTER ROLE $DB_USER WITH SUPERUSER LOGIN PASSWORD '$DB_PW'" else sudo -H -u postgres psql -c "CREATE ROLE $DB_USER WITH SUPERUSER LOGIN PASSWORD '$DB_PW'" fi # Store password for tests cat << EOF > $HOME/.pgpass *:*:*:$DB_USER:$DB_PW EOF chmod 0600 $HOME/.pgpass # Now create our database psql -h 127.0.0.1 -U $DB_USER -d template1 -c "DROP DATABASE IF EXISTS openstack_citest" createdb -h 127.0.0.1 -U $DB_USER -l C -T template0 -E utf8 openstack_citest ironic-10.1.1/tools/with_venv.sh0000777000175100017510000000033213243617464016623 0ustar zuulzuul00000000000000#!/bin/bash tools_path=${tools_path:-$(dirname $0)} venv_path=${venv_path:-${tools_path}} venv_dir=${venv_name:-/../.venv} TOOLS=${tools_path} VENV=${venv:-${venv_path}/${venv_dir}} source ${VENV}/bin/activate && "$@" ironic-10.1.1/setup.py0000666000175100017510000000200613243617464014625 0ustar zuulzuul00000000000000# Copyright (c) 2013 Hewlett-Packard Development Company, L.P. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or # implied. # See the License for the specific language governing permissions and # limitations under the License. # THIS FILE IS MANAGED BY THE GLOBAL REQUIREMENTS REPO - DO NOT EDIT import setuptools # In python < 2.7.4, a lazy loading of package `pbr` will break # setuptools if some other modules registered functions in `atexit`. # solution from: http://bugs.python.org/issue15881#msg170215 try: import multiprocessing # noqa except ImportError: pass setuptools.setup( setup_requires=['pbr>=2.0.0'], pbr=True) ironic-10.1.1/etc/0000775000175100017510000000000013243617733013665 5ustar zuulzuul00000000000000ironic-10.1.1/etc/apache2/0000775000175100017510000000000013243617733015170 5ustar zuulzuul00000000000000ironic-10.1.1/etc/apache2/ironic0000666000175100017510000000257113243617463016405 0ustar zuulzuul00000000000000# Licensed under the Apache License, Version 2.0 (the "License"); you may # not use this file except in compliance with the License. You may obtain # a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, WITHOUT # WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the # License for the specific language governing permissions and limitations # under the License. # This is an example Apache2 configuration file for using the # Ironic API through mod_wsgi. This version assumes you are # running devstack to configure the software, and PBR has generated # and installed the ironic-api-wsgi script while installing ironic. Listen 6385 WSGIDaemonProcess ironic user=stack group=stack threads=10 display-name=%{GROUP} WSGIScriptAlias / /usr/local/bin/ironic-api-wsgi SetEnv APACHE_RUN_USER stack SetEnv APACHE_RUN_GROUP stack WSGIProcessGroup ironic ErrorLog /var/log/apache2/ironic_error.log LogLevel info CustomLog /var/log/apache2/ironic_access.log combined WSGIProcessGroup ironic WSGIApplicationGroup %{GLOBAL} AllowOverride All Require all granted ironic-10.1.1/etc/ironic/0000775000175100017510000000000013243617733015150 5ustar zuulzuul00000000000000ironic-10.1.1/etc/ironic/README-policy.yaml.txt0000666000175100017510000000040413243617463021104 0ustar zuulzuul00000000000000To generate the sample policy.yaml file, run the following command from the top level of the repo: tox -egenpolicy For a pre-generated example of the latest policy.yaml, see: https://docs.openstack.org/ironic/latest/configuration/sample-policy.html ironic-10.1.1/etc/ironic/rootwrap.conf0000666000175100017510000000165013243617463017700 0ustar zuulzuul00000000000000# Configuration for ironic-rootwrap # This file should be owned by (and only writable by) the root user [DEFAULT] # List of directories to load filter definitions from (separated by ','). # These directories MUST all be only writable by root ! filters_path=/etc/ironic/rootwrap.d,/usr/share/ironic/rootwrap # List of directories to search executables in, in case filters do not # explicitly specify a full path (separated by ',') # If not specified, defaults to system PATH environment variable. # These directories MUST all be only writable by root ! exec_dirs=/sbin,/usr/sbin,/bin,/usr/bin # Enable logging to syslog # Default value is False use_syslog=False # Which syslog facility to use. # Valid values include auth, authpriv, syslog, user0, user1... # Default value is 'syslog' syslog_log_facility=syslog # Which messages to log. # INFO means log all usage # ERROR means only log unsuccessful attempts syslog_log_level=ERROR ironic-10.1.1/etc/ironic/api_audit_map.conf.sample0000666000175100017510000000134313243617463022076 0ustar zuulzuul00000000000000[DEFAULT] # default target endpoint type # should match the endpoint type defined in service catalog target_endpoint_type = None # possible end path of API requests # path of api requests for CADF target typeURI # Just need to include top resource path to identify class # of resources. Ex: Log audit event for API requests # path containing "nodes" keyword and node uuid. [path_keywords] nodes = node drivers = driver chassis = chassis ports = port states = state power = None provision = None maintenance = None validate = None boot_device = None supported = None console = None vendor_passthru = vendor_passthru # map endpoint type defined in service catalog to CADF typeURI [service_endpoints] baremetal = service/compute/baremetal ironic-10.1.1/etc/ironic/README-ironic.conf.txt0000666000175100017510000000040413243617463021053 0ustar zuulzuul00000000000000To generate the sample ironic.conf file, run the following command from the top level of the repo: tox -egenconfig For a pre-generated example of the latest ironic.conf, see: https://docs.openstack.org/ironic/latest/configuration/sample-config.html ironic-10.1.1/etc/ironic/rootwrap.d/0000775000175100017510000000000013243617733017247 5ustar zuulzuul00000000000000ironic-10.1.1/etc/ironic/rootwrap.d/ironic-images.filters0000666000175100017510000000032413243617463023370 0ustar zuulzuul00000000000000# ironic-rootwrap command filters to manipulate images # This file should be owned by (and only-writable by) the root user [Filters] # ironic/common/images.py: 'qemu-img' qemu-img: CommandFilter, qemu-img, root ironic-10.1.1/etc/ironic/rootwrap.d/ironic-utils.filters0000666000175100017510000000047013243617463023265 0ustar zuulzuul00000000000000# ironic-rootwrap command filters for disk manipulation # This file should be owned by (and only-writable by) the root user [Filters] # ironic/drivers/modules/deploy_utils.py iscsiadm: CommandFilter, iscsiadm, root # ironic/common/utils.py mount: CommandFilter, mount, root umount: CommandFilter, umount, root ironic-10.1.1/etc/ironic/rootwrap.d/ironic-lib.filters0000666000175100017510000000174013243617463022674 0ustar zuulzuul00000000000000# An ironic-lib.filters to be used with rootwrap command. # The following commands should be used in filters for disk manipulation. # This file should be owned by (and only-writable by) the root user. # NOTE: this file is a copy of ironic-lib.filters from the ironic-lib # repository that should ultimately be remove. At this point, we still # need it to avoid gate breakage and preserve compatibily with existing # installation. [Filters] # ironic_lib/disk_utils.py blkid: CommandFilter, blkid, root blockdev: CommandFilter, blockdev, root hexdump: CommandFilter, hexdump, root lsblk: CommandFilter, lsblk, root qemu-img: CommandFilter, qemu-img, root wipefs: CommandFilter, wipefs, root sgdisk: CommandFilter, sgdisk, root partprobe: CommandFilter, partprobe, root # ironic_lib/utils.py mkswap: CommandFilter, mkswap, root mkfs: CommandFilter, mkfs, root dd: CommandFilter, dd, root # ironic_lib/disk_partitioner.py fuser: CommandFilter, fuser, root parted: CommandFilter, parted, root ironic-10.1.1/README.rst0000666000175100017510000000251113243617463014602 0ustar zuulzuul00000000000000======================== Team and repository tags ======================== .. image:: https://governance.openstack.org/badges/ironic.svg :target: https://governance.openstack.org/reference/tags/index.html .. Change things from this point on ====== Ironic ====== Ironic consists of an API and plug-ins for managing and provisioning physical machines in a security-aware and fault-tolerant manner. It can be used with nova as a hypervisor driver, or standalone service using bifrost. By default, it will use PXE and IPMI to interact with bare metal machines. Ironic also supports vendor-specific plug-ins which may implement additional functionality. Ironic is distributed under the terms of the Apache License, Version 2.0. The full terms and conditions of this license are detailed in the LICENSE file. Project resources ~~~~~~~~~~~~~~~~~ * Documentation: https://docs.openstack.org/ironic/latest * Source: https://git.openstack.org/cgit/openstack/ironic * Bugs: https://bugs.launchpad.net/ironic * Wiki: https://wiki.openstack.org/wiki/Ironic * APIs: https://developer.openstack.org/api-ref/baremetal/index.html Project status, bugs, and requests for feature enhancements (RFEs) are tracked on Launchpad: https://launchpad.net/ironic For information on how to contribute to ironic, see https://docs.openstack.org/ironic/latest/contributor ironic-10.1.1/vagrant.yaml0000666000175100017510000001267513243617464015456 0ustar zuulzuul00000000000000--- ############################################################################### # This ansible playbook installs all supporting software necessary to run the # ironic service locally into the vagrant VM attached. Its intent is to provide # a quickstart development environment that doesn't pollute an engineer's own # machine. # # The vagrant vm's IP address is assumed to be 192.168.99.11 # # https://docs.openstack.org/ironic/latest/contributor/dev-quickstart.html#exercising-the-services-locally # - hosts: ironic sudo: yes tasks: ############################################################################ # APT Updates ############################################################################ # Make sure our VM's software is ~@Latest - name: Apt Update apt: update_cache=yes upgrade=dist cache_valid_time=86400 # Reboot if required. - name: Reboot system if required command: shutdown -r now 'Rebooting to complete system upgrade' removes=/var/run/reboot-required register: rebooted - name: Wait for VM Reboot. sudo: no local_action: wait_for port=22 host="{{ip}}" search_regex=OpenSSH delay=10 timeout=900 when: rebooted.changed ############################################################################ # Install all the needed packages in one go. ############################################################################ - name: Install Required Packages apt: name={{item}} state=present with_items: - rabbitmq-server - python-mysqldb - mysql-server - mysql-client ############################################################################ # Configure rabbitmq. ############################################################################ - name: Ensure rabbitmq is running service: name=rabbitmq-server state=started enabled=yes - name: Add ironic RabbitMQ user rabbitmq_user: user=ironic password=ironic vhost=/ configure_priv=.* read_priv=.* write_priv=.* state=present ############################################################################ # Configure mysql. ############################################################################ - name: Configure MySQL lineinfile: dest=/etc/mysql/my.cnf line="bind-address={{ip}}" regexp="^bind\-address" notify: Restart MySQL - name: Create MySQL Database mysql_db: name=ironic state=present - name: Create ironic MySQL user mysql_user: name=ironic password=ironic host={{item}} priv=ironic.*:ALL state=present with_items: - localhost - "%" - name: Ensure mysql is running service: name=mysql state=started enabled=yes ############################################################################ # Create ironic.conf.local configuration. ############################################################################ - name: Update local configuration with vagrant parameters. sudo: no local_action: ini_file dest=etc/ironic/ironic.conf.local section="{{item.section}}" option="{{item.option}}" value="{{item.value}}" with_items: - { section: 'glance', option: 'auth_strategy', value: 'noauth' } - { section: 'neutron', option: 'auth_strategy', value: 'noauth' } - { section: 'database', option: 'connection', value: "mysql+pymysql://ironic:ironic@{{ip}}/ironic" } - { section: 'DEFAULT', option: 'auth_strategy', value: 'noauth' } - { section: 'DEFAULT', option: 'enabled_drivers', value: 'pxe_ipmitool, agent_ipmitool, fake' # All other testing drivers require add'l packages # and should be enabled locally, if desired } - { section: 'DEFAULT', option: 'pecan_debug', value: 'true' } - { section: 'DEFAULT', option: 'verbose', value: 'true' } - { section: 'DEFAULT', option: 'debug', value: 'true' } - { section: 'oslo_messaging_rabbit', option: 'rabbit_host', value: "{{ip}}" } - { section: 'oslo_messaging_rabbit', option: 'rabbit_userid', value: "ironic" } - { section: 'oslo_messaging_rabbit', option: 'rabbit_password', value: "ironic" } - { # CORS Domain For Ironic-Webclient's dev server. section: 'cors', option: 'allowed_origin', value: "http://localhost:8000" } ############################################################################# # Handlers ############################################################################# handlers: - name: Restart MySQL service: name=mysql state=restarted enabled=yes ironic-10.1.1/doc/0000775000175100017510000000000013243617733013657 5ustar zuulzuul00000000000000ironic-10.1.1/doc/source/0000775000175100017510000000000013243617733015157 5ustar zuulzuul00000000000000ironic-10.1.1/doc/source/images/0000775000175100017510000000000013243617733016424 5ustar zuulzuul00000000000000ironic-10.1.1/doc/source/images/logical_architecture.png0000666000175100017510000011230513243617463023312 0ustar zuulzuul00000000000000PNG  IHDRMsRGBgAMA a pHYs+ZIDATx^o]}'G3ƥLIlj.[MGjXāJ$p)v@P\yQ}Q21!~a3(ȃ[.2v@IGkἸQ2Z{u9ph|Zϟom|Ⱦ/ @ @ z @ @!ޅ@ @)a @ @!5@ @)a @ @!5@ @)a @ @!5@ @)a @ @!5@ @)a @ @!5@ @)a @ @!5@ @)a @ @!5@ @)a @ @!5@ @)a @ @!5@ @)a @ @!5@ @)a @ @!5@ @)a @ @!5@ @)a @ @!5@ @)a @ @!5@ @)a^ :x;v>mnqdBɓ +ݺx o*Fʌc e#w* @B|~I=y~~}_ e{Yhغ}Ζ6UX= Y_WC?`v;- lkyYms6~z.ҟtBَ,nv0]㭳>Vob?LhMe}fun9L @ B``!~v}gl3g'[_og7綘7?_7&vV~}rO_5F*#kA}g sfȞx"riOv_s nWIԧo>`Km ΅Cl)9ŇuyVUp @Mn%/etxO=^8+(GmrfA~.7[.7'koIs S(=hgՖF׌ _v8Xlct6]K4 @ V+o$7WO]Wߚ=Ȯxjt0SYئJ @@#[Ϟt>yJ|g}zn|,'  @6n%~to:Z-3YZ @ ЖC|[%@ @ l;}Z'@ @m mj @4( 7) @ Цߦ  @ @@B|"@ @m mj @4( 7) @ Цߦ  @ @@B|"@ @m mj @4( 7) @ Цߦ  @ @@B|"@ @m mj @4( 7) @ Цߦ  @ @@B|"@ @m mj @4( 7) @ Цߦ  @ @@B|"@ @m mj @4( 7) @ Цߦ  @ @@B|"@ @m mj @4( 7) @ Цߦ  @ @@B|S!E @}U99 o|#$@ @ XoXnUe| @ @``B|-5M @ -kpͱ- W @ B*0tM @ @@B|ũ44G @  D NIS @ P1 M4C @ F LU @ У_Ͱf5t @A@EN%@ @].4 @@@G 4N!@ @-q }%  @ @!~ Bt c؂̡ @ Р_3XJ9 @K cS J @ @@ 7o<}'^XG篆sӟGjZ @ 5Ia;1Fv @)]J8&J1p @D į(Bӡ7O?m//~Ĥ|v~_ZXdsצ! @ @t_p<~!u+_u%7=v @K@G!>7'{Yw}${(^g&}-AMviu{w @) t L|Ų> ي}ë'ڇnugy}Ȟ~ow 46u4 @, gBO»zȶ2}ǧ!+J/S~gs2J|WS>M @ s~Wn/Uo/gB};o2O?_́mCss< @J| wɏT/vV܋必?v/slwtZ'@ @mF?pkE~c  @ (WKos%gT @.0?0;W8 @* Vy  @Mw/ۿPA @Fֽ^~@ @/6۽XM @͗F @ @@, iKUy+G @ @OAxtKf @ @@ hK]u;g @ @ Ax!%ð @ Ж`B%²9K- @ @IAxKbMH @ɇxa%l۳2 @$L9 @ @ E!ӛ;Qw @ 0CMEO%ȧdE` @!pFU| _sk/#@ @!$rWc @ Ю߮uad] @ @`B|E7i @* @ @_vq-U @ R[o%@ @GuA @ -zZ&  @ @ B!lZmy @HH@oXUV| @ @ R!lz]ٮR#@ @Ⱦ5f;WmFe @p.7 98}{sYwMT;bno9lSlj{vn49ƦjTj|ަy%d /+b?;!JAh 'w+:(»? ;#j w . wX!Cl] Љ@ N и' N<f @`X~VM͆ on)1jbDZV. @ _A* @V@[o uO B?b*GUnM\@OOC~~J`[!~[1 @ @uK§T-c%@@uI+!+i @ @B|M@ @ @CDlOpMWsuC @ uO @:;  @+ t> @H@Z7 @ @_W @&?q qŨ ?) @" @ @0  @ @ @ @0  @ @ @ ^B8u@8pT0 - fG,=߷'ƴ(u_q~Q.jZw̮9T⫹9HM'ng,؟h'npwJ\ey^a'fJsșg/U?ٙ* ķʫq/kh@i;z6uF1>r*tᔭ]+'I=·Y9…-u}l8ZGsF\@w @xpa "8~'|grlJSs[h½ƅ٪t bN-o럞wlg+.3v}VPnw>Ock{)cjkҭ3G|lعpBjwnOvmq=L~??ƪ3@ΧGg3'2 /$|}N½Y;Ymv[=[緍wv}pjzѳob:م1LyYg&lxb^~EvS s>yr~uc.yuiT+9pb}Z? 痶 yPl/xv`w[݄dz>:; Ź-1]xbvqŭWu5r;(,YuѢ8\çcۊ?Y1Evǧ[g*<1ydX׍y1 ue :_`gRGDm{,m_~4l;k| IWK~[}fN j5-;7fok|R[aȅD~Z-ֿS_0q,o1cئ%@`BX+o @`L;:ּE~w'Cwb~fVWXOC_;=.{h%o.Awbo=n;+͓CQ0ڹL0얉wKԪ6![eyP7"X1:c(s9q 㪷 @ ϶g_xXlK?zna,+ mY_>^ o,ϖk?;ާ;o}ѕˬ:L3}V~:97{$ïygݘak<' 0t!~6? @`"pU=6h~elupol]wguh [/2s?tm^1=N/Lv6=s K]uϽשբ>nuư l׍O3 䵗Ǡω?w'#(2?nUV-' `%>"" @.yۥl' ohNr+  @ -g~6U=w~K~Vɓ#@  !|0 [s @ bǵ8TM @ @@B|E7< @ @@D>bb,|Gwl $N*)s}ar/} @ 5 M8j:C>jqosbV ! /=ۛ9t! WT1 9bNc:BۍOxk|}C- @&-5SEBȖE)\{ Z%oha~ @n)"AdqvXj%2%o6r _E9 @Y!~ &ֆp[E֏Gxo^|z @n³PPZ]/\!\qj(IvFNp|knۜ媖TeSa @-!~P`zqҮvS)8WE*W2koTٞyw]7aTDZoT @`?'4?ye^~Of1AJ@Ϥj^f~nj&no%[UA50C S}[߯  @c}s $i]G!: @`lnoH۶fbj, 6{R?F @@[ ˉK[/fUfnE] @:хxpA @]FF`o}uO1: @F]TΩԣ+z NNl @FvcW\CP& @ oQ'hB8k֩ x3% WZ2Z @@vir, @%0v )M6uk[ڳ2 @@wl @4)0$ @ @@V86M+q ?hx|`xL'?}<f?6  @#tY-M@C'tЏ.b8쥘X÷?xx %0o%udzpZ6cǗVӜQ @HQ`!>b3\ 7L~p%a)pϤ[<6WcN럙=yJuďb87W?q<D.NuB_mzo/~)_ _艝~~;|-%_?ݟΩJxr6CC!|gdӐ'σpiP7}7 i{XܣG?/f};_)~6ق ܯ~ṛ[Wm9hs  @XYuӏI y?b5P';dW^ gA>W'}7oo,;w3A/UZ>;ɓ簦o\Zq}O?d[i @ ZA)^]_X~z$ЁcU΂΂4OyUt#p}䃳;]̭.0h]?~lbX/V]  ]Ow%X? ojNVIPl?Oo;}eI' @\|w~''/>-M{}5:9.]G!j?ܟ?ܹoeo-]}4%V \=,<{ ɏO~U<R46[~zscm_7s|+`%_hZJ|Ӣ#МߜZr ͛ݢ]IF@I!IMmhV`P酠f/ @ @@\Z⻻7om4[v_ 1pg=+|:+qh @`Zň?6:{B}' @O!O}} 0*VQᬘ79{CdVOG@O͔#VCК*_N{9'G @Ws3&WؽYh7ܳᡧ'Nxxd:3&- )_+WnχoM~8_FEt% w% d+gLGw?`ojcRxݹ':_)oCso,of|ߺ6`xBV@4F#c_ }^ g?Vϯ϶go,p8,nXY;1kbX#[Rm^)v eGf]/wͳS/LͮKggIׁ  @E!+o}q'|b@?6 5?kiC \N`_$`\6K0pܡᥥc9tN~L`tSW۹h0|x3$Ws#Y0߄ٳ(^`'@F( ķPv(+V?/<0zxb8Lۿν4\VI[c* i>] ['ڕp1[YW].[1`)互.G/, y"(L}ūG rw߄?gzlp]o1 wmۦǼ?m: 4'p7i}i;Bok5hzxgZ^<7'7IK`s; PEXq/Ӱ ;X|S|v @Q *ǰowx5[Yσ|^f}xzsFqd4Wasm_=hk!qe+_<#hw9b~1+lW90ESV}tؑpjr @ *wdb+_dY5w}|}?<\ fI &?~2^sWxeﴛ'} ewtU^sT2SY`y ; =g➅B<c#@b8p#mPuƓ?Ԫϯg: '˞<@}>'vohWNVFfox|k!^uYeW) Ͻx_{.k`U@Lߔ>c9_q:N#0(+ sg+>m~>>Bn5E |>b77?qsx͏?+f>"~C!@,l+}xcﻳW~nV[ªpQ&YP  @B|WDavEs>{Xk[S L?SJ|L @ : n)+{~7^b/2{⻺b=Uxzr6aXFb@C ~*Ic%6' @l]" @ @ !>B& @d k;Zeݝu=_$@╖ @N~3 hU@oW @ @9xYHx6Y5e;fuufD @x3'@/7k @D`!~+b}\Pɾ?{= @Q`!>Fpc"@`7.=>ə @@V2]g5q4~Ծ @|Ĝk@"@ @`nd_c Scfs(V{OnpܾJƫz8X+n|1!]VɃyMdG(g){ M \ B}$(9UZ|UZwI5 @I@SuG@w1 @ bՌ_ @( H @@sB|sZ\@@G @F!~# @ @?  @)8'*fݬ'mPk @tN]@BG* X+c\B]YV"@ 0z!~Ԍ @ A * @ $ Ļ$# &B @>BKc h @l]" ɗ @() ėrX|u1a yҰ&d6 @7 c̟hKmj@}!z{@% @ s< @CRɑCIM @B #>R( @- -jYYO @ fF5j~T6Y @.cp @t, w |y+G @ 0!~uNn|r%3` @:;@vv^&@ @`<BxjL$d @Ν>1ttk7 + Dr)i @Q'!_C3 @ @}!}c=l]" @(' ėsuԪZi;cX*a @ ķ\"nȫtm^oSc @@@e|:z] j @-æ[n' 0'ɦ~z^HM 0j!W U`J+ ĪT=o&H 0H!j8D-.˾(C4>hb  Ѝq *B| l)|Iv֓$f @ χP;EË,񮪾yUĹ  @`B|ER #Xo=IDJ б1Vw|-ўk`G k @Q&!WF4[OR @# >\k;O=a̽|,8fH (pF<7z`idot!~>Ƹ5 {H?fu8{:S$@ bG\C/U޷>o0| @c_V5J\ߴj$׼>zDaS_~O`S7h[J|'P]@`fШ0R 0KA+|-}M((:B|= Ѕ߅>Tp3pl1̵V .)7Ub#w]_CV滾ߟ  @@[Vd>pV_FбC} u^X @f^XXOֈnCa3 @ чx+l/M.yW6.6]+]>6.mE Y`!/u[7m|9bc} uCf́ ؅UQmGx>$0?k\ @) .wӛrC;goE|5C{ʯsJC$01?> yp/CjN @8FȱT[QT+g @CMJb C75G @Fq=Kۜ*ɩ @ >űLتZoW^y9 @`;AxLow1l{4m;^Ռ[57g @llG7q&lCmeH~>^޵l @@ CbdK @EAxE&@7fgslQ+ @ hޏ{e< @` Xr߯  @M xJS!мB|4d󧏇õ;߻u~8_ }G @ bB|[N -2ܞ? @ 1pZcǗV[7V~y?-jgߞ?g @! U WֲGoL{&ݚ䱹w]tT^8l5ug['|}>:ٺ_+קAn/ſ$8>o49Mm(p­\Z|x-lcOi@c-ސ1N @B Ӌ^W~rj,O|w%vdw}|p4|;~Yiux<+V?&_>?Jj|.ax7NEu'_Yp{̓W/O gJyvVM/ھ7g__ c_B}O0"U?6o?9*t},ԿD4I;j|N, 6yn%~qE8`G540ijbe|cF Z>N5+oʯ/Ue\B_*8~Çj5tdyo7S*n܁HN wrtL#-L˃*oH "P^ $@z)|7N?= @I_^>zx8ܞ D!`Kw?eޞUlkY޼ƶg3X/ t} =w>z!@o>⮏HM@4:<9{P|ql#{|VU7m_K8vzYu{{;g++x xJ.S6Fmj Y`A|!ayl`?O[>y|WM޼xha._DH[n뗢wb_ ze:N]׋a}C- 03mU1YUcYȝ+vf"zŭC&/2}==HlewTR7;t+U{szGq/;UD @ ^!i~h~[<.ۗg}}lZ \9w~wy˵~ˍQ/ (]C>یN-Z,,D`Ʉ4B}> Bm,ntW`˹b|D?<$M87,lI6U`!~R=: WbxnSvkW·g+ON?L,[æ~zś7C0  x#b3mT&0˾ϯlU}}//x=?R14]qf4Zk7N`F?ʚ d)yhniM @@d$ C !VsW+ ]]KCӨXuڴj{n5gjV[mq6Ti5gU|fKM7tk[k d>_ @,F@ E!>Ū3f MA>͓1J|EY?$20#GVp%@ u|52 c໯:H uݳege7yի٪k~c+_oi4jMv^cwHUJ|3nx~nxTz:_"@_ު#c?^q qŨD# oWmVo9oWG @ |*vI`lImH[AczXƤ8-ƯFou~{ rj $[8+1mMM^jKe[ V)-hT@oSc-MPDU}P _"R @@ZɆxa" MҨQ:{uXCg 5C@LTB NdC|FE`y`#([bS/;geG @@zIxA" N}Oэ1ӛl_w>J7z!@!>Ut&0l)|W>- (]?'@`ɇ.j|c[_zy՘)kijI W ?ҙ9xL|xc$@ A>*S[2hvDѬgJ CW |Jlc`83sOӰV -0+ ڕu >nb]pi.]"eV盺R w|[n?s7MNs^\O<`<0\\(so2śl[A~2CCvϦ=<ٹO<8w0 SٶlK?BIо;TsJ8 ] W/09G^W'o  W]DDz7 ypH:hul]t/03 \LqC/nn1Wc[4oߝi}=׮OCb{i/Pӽ6= |5RbLlۿ0}Cnon :?wឝd{WW&ATv?} ?m$RLϋXWbWA̳ݘ : ]|{Z&@K>_~=<-m~|fԽ@-]-~vKY^Zpǭ ~G_ 륫׌~f *0?кش:_v)7?qsxfA~nƗ_ z'qqG=soݬT eǭ{#GEq.3| 0^71L?f7[*ϝ>Q{uye輁__rMu',!dJupD>vy!۹7<&p䡑óOk)̺;gi=h2߂?=O?nK i U`4!>/ _2j@jM!W5aOOӚM1C̣МZ}ޏS_ WO>8dJ{fcw|QM#v<ةr_}zFfoX̌F^wl 4 ??+UM K0W/>!_᎛><@ri%`>2}~gXܗw}r} *SO>/a % :{g*XӜgNG~u6o\\~#pFa<|c3ݻwy7 @&}DZUOϝx =]|^i0cyμv%\,ݕU1Տq$%0WJP]}rIul\~ǣ5FRU;~m+OfwK썀l+}1+?DW`—q= z;k>m£+oe--}C5b_7fѯc!0w -~k]wJ{帟WrowC?k]} K~c|z\elh;=7McS-_U~_y[G @ !~JeUz,LibȷT6U\u+}SXngd=uor)U<mqn~æ tpY'A´؝Zi k5!-ן@lX:3Gf!ο|pJ!Т7:Z4`- 5Yyߢ%@`"PFM!t|쳩hwG`M/ϨG“IO|ofOоzxgss';dYGi_ٛwt fxnietҏy%XAlV#m~j [ x m`EyS^Ny[ȡ(Pf=UÇ>6 ]wdG|~4p價 1ٖGS1y;gIkRX?v mn;IE@4|40QPWSg8Hmn/xHdu{;O.NN~x^xaq;p~vJdzбl|nol9~q9F( B@oU>lLS$$PVR;<_<.;qswnw?鹭{W7,/Y msdmWDoVa$@{%߳_Yr_ɶ{_Onpkϝ椝^/^xerxRlϟx?_?v!i XO~FOF֭+uVd,+ jdbE>̏k&>o(Pv=b~sӘc8쥱L< $' 'W2&@@uxH]I@Vz㭐[##C- -j  jՔ zp5Lg @I!IMm @gM/j3  й7U:'!$$fH}]- W@p_VGm+xD Pf;-ƿn>+Ŋp!b{O?wD(z'@`xʊ{7 )a @:;'! %7w # C arN"@`* Ļ U /Gv1 {+&p穧' [!yV{v}XiLv^g*׆{⻽F`!~-ǎ^J`/&ؗqc yՖ*Z4XʦqB|U!w{6B6Z@}PI(ߏ)W*|ޖpukPIWݑ{[B *B|5 Z@%7^T/ħ:9-v\[5!ķ @U!'cx_FӺ!6EZK=ۼC|:u:z@ ]ORJpo2W~E:bJz5Y5hW.#^aW )|B)}?nʼQ @$`%~L6׉@}]l.NXu~f{{ԽU:n^sVYO1V}sb^Ū}(NʼQ}WQ^ 0L+ìY- 5*U/2atȡJ|Eu 6բߖlz5ЌV]@0)_cUB|^}wՂҕt{M4c~ |c |Zp_mmo#6US$뭞D=?g +xW`}e/lO/+U!fPMdg +㨳Y[ q X.FUC@x݋g{/ v _ `{ڲ_U.ު(Ķ8*B|5D- į.؃˶{pMbP_-xmWT_Bvuv4.lR[_ '+>ζ-FI^o!?4m]j,`%~j|0)o^=UZ%ܶrzYʥ_Ǝ"Ї߇>˓5 寁6%!šm6S(Œq!\S~j(}}Q~{Ρy}ڷuF!>@?S$m]cnW___/B_{o_I5 k֙]>_w'c1UHB`Xl7zj6|rպͳ˼f&@?Cjrl6Bk(xʒo,aeǬz"I, ď =U䘙cscZMl^L7bV2i:!b . 8M<Խ:~+)o}Ig @] h:XXu/Afmi ƹ'z5xGR1'Vr\V7 % } =nP&kU|UGBb'02aBpcZM7}- u_{F, @ v!> ߎbTYpW,~%A_#01ϽM-pF5nOELLe.. me]7b+ _*ﵴ6j#r T+7q |nŽK7jbkLȽS% U!#)So2s, @`WvzWCV+S~yoUX:uS?wTϺ{޹n  0F!~UOl|7T(MB|{lL@=k4-`;}Ӣ#0<#) x@W@_ OfOnd\m s){vS{Q׮G(' ėsr@tf; 듭|Gg/0)ߥ۽mݛ c'0>}y} gl*{7o do a}ͅ{;vzfW @66T@-ܕx/wj|`V܇10*~7?]OB0~w @@!c-0Y^}W?>;gqEJX^Z+~ߝvWt$P_*|}C- @ esO<|c'0h7A`d'_X^g1u!j YJkn `S @ A X 2E+ Ļ* 0b2~ @ ѕĀ Џm c  0 2 @! &AzV9 Еߕ~ Ua(P xQ_) Y|Fy~*|"@9 HJf @!@ F?b* 0H!~e5)l(}-AJ@JZ?Y*|= @!DM'jٮk{?]Zv1 @`H^*|%4 @D@w! @`dVGVp%@% Ü֕w]#P @!g @{a) @5!5Z  @ .㪇 @UԜӹ-ݐsƹ^w% @@wB|wz"@@ouVϝ>۸uL ( Ļ"JnuV @!g @7: Z @+xFRV)v\jG%_ @@B|z @@gwF# ZP]^K\@OcUfγYϘZ>j  @!Gt, x6αXZ K% Оߞ  ЛUuLhU@oWm XE˯_lg KMx @G[aL\VGnR9*|*2N @BfΈL@ ݮ Jh)B ЌߌVzLS9js}JJ?J`"6  Еt% ۛ9#bA5ZV'  @ z!> ܨo{ Vc @qJDy`ZaхP7 9 @@"B|"2>tϰ n팜 k뼓8k Gs* @ q!>fڱw0#lV=͆ ýcc_E\M @"#-a#0UΫ VZ?wDhFN?f!Xi.+y @8qݬ3pcwUkhE ЖߖvH)4d.j>2 @!!!Hͤ/s@ylW>Hkd @@~X\,HpJ @`Bl]W]ƙ] XJZ? @4ȾQSSOm=WzX~{{)CzU^ PC̳T- -jub xSRfeRo31N?*# HJfUAd& Cl^M͈ PU@*<$`uK%@ @@@M @! ďfI@"V)a @z{-<5A I@$Az@% @ !>"" ?! @ ! Em @A bj* yRD@B|z @Zs @J9 @, \ 0n㮿 @s<HavNhhƚ!@+ t>05A?""  @- ďfO@V#(! @)a 0N-̈́ еߵ @ @@E!" PE*|5 @Bk-a}uf&  @#GVp%@}2a=ٝyRhz @(% ėbr zp6 @Ⱦ0Qs$@`8wzjɼqѭϩzªS>_?wDUHPX-av]eMSoUԆuNk`ճ%c6 @Vs< TYeoj@Mm>S [^wFl @ e+)W D`~)1ۥh|}]/{\|34" @m!ma @c$jblX~L˟DX}Jdн  @܌ .D@jMu>ϹO .S3#!@ VƸ P@Mc_Vd>(SEbq@ku gŘR ilU49- @e2J!@|ʗɨN,sϨ g @ !>B 9/תЮZs2{PEs |Niy(+#+D& GV!0bV*_) Y"@6 |ʪ>jןת.w?*#sޟႲ@Ep7g @GkCsx_-?y#-_}vdz<ݘ n|2I7z!PE@~CO ,s6*fc~L6W--jq< Xs6hJ@oJR;F( /P|RB?N|Z#@ ۊ9PjԶٶge N@w} `8jq794- 7-=H[57g/ _##$@a êhU@˯_ٳʲRǼ9K- @MB&!'@ 1#7Il[_@oXUG NsO90"@ .J 4\=YX?wew|^Mv᧳O|p~~}N\1͆6Ԙkc4 @@|B||51"8|cy]v+퇎'yI~<;ھO@&FD` /cÉ3~{/?ޯ7}`ϼM~4޹ wk: @@B|Z#@`;-™oVaOKsᅅm o; @hW.N@jUx[gu3=ݶOnpe+ xZ5Ϻmw}ZȷӻE`M!`%S _lt?`-S#@H@Z7$'"@ G@4UG3k=~u!j 0$!~H4 @? Z @4% 7% @ в2  @ @@SB|S!0=Uܗk/߿~ִZFKHQ@OjL Y_ < MO>}uWƒdKi~>|Íg_t_ PI@$C\4#>}c+8qÁ/:L"@` NsȌLpL-p~믄'U<ς?nc4Vmt++ _;ig?+V2ܣG?/f};Jm~W}_4ݪj;yEs'h @@!c/.O)4ObK|(V~b?uɱ^^h@[vތ4?9iG“]>;ɓ|u07e?ӭwihJ!R⹧m~]Gg'AJxS!;O.N~^xarN^U,k7?= "@& C z^o̷׿j߷f+fA>'gy~~wl#ޙ\۳l$_,q%|{eྞkק!~WnqW_z1|=o"{ r@B-sC6?f+Gݧ~e/ӟeS8Y>O{v~w2W&ATv?%H(AdO2B}Snm/gvC~'s7w>r'׬7{ oLkn/V_5t @ J!>ʲ nqssWl|Krqq'TJl5t)'n=,|pwc;ڴt/pF}z$@ F[UnUOy?õWi}m'?W|_+pKNtg? @ H@P1M@]uϿ  @cPes$@ @A(I_ f+e @) )W  @ @`TBm^ B/ @88`p~Jw @RS @ @hі  @K;>0<3w|{}?pED* GZ"Ч;ގ'?ׯ~~h 7gD @c!cp @y*yjVC;ܕA V.i @`Bn s/9>{lð޿ь@';93#x @[x%.nztӏy̑.㸧bt @@B|: @ ?)HY@OzNem7÷NG{a;?rxxhӖt&n @@!S @@Sy0ݸq D-Eܣ Wk j@B|:# AJc\c-ۺ_Vq㮏э[@w͞-߯ 4) 7- x]Z#@gg?z-h\@oT @`_!Ak-)} )UX  @mmO A^oL7X] 0XAҲmV @` @A ͖{Z#'bq?K/ x6Sco4 PGs.F 0 /^}# @@B|#@ @l4 @ еߵ @ @@E!" @ @@B|#@ @pN#@ 0TI| g] @] @ @ !>B&/y @   @ H  @ @ H } ;}"//} @{~_) Y"@ @{x @HD@OPI>lS_NVD_Uy @ @c!cp @ UVθ  PN*|9'G[@'@@B|B2Tl! oP= =@ @7Ⱦ? 0fs}s'@`hcVq%@@kSSX@CB|C!@XʏM@NrM`* Ļ @¼1!otc"л{ c6mlY6hMm}ocWMm+iۧEu^˺U6˚5h [8 @ @R>b @ @@B|50 @ PJ@/  @ п  @K19 @/ _# @ @RL"@ @  @ @@)! @ @@B|50 @ PJ@/  @ п  @K19 @/ _# @ @RL"@ @  @ @@)! @ @@B|50 @ PJ@/  @ п  @K19 @/ _# @ @RL"@ @  @ @@)! @ @@B|50 @ PJ@/  @ п  @K19 @/ _# @ @RL"@ @  @ @@)! @ @@B|50 @ PJ@/  @ п  @K19 @/ _# @ @RL"@ @  @ @@)! @ @@B|50 @ PJ@/  @ п  @K19 @/ _# @ @RL"@ @  @ @@)! @ @@B|50 @ PJ@/  @ п  @K19 @/ _# @ @RL"@ @  @ @@)! @ @@B|50 @ PJ@/  @ п  @K19 @/ _# @ @RL"@ @  @ @@)! @ @@B|50 @ PJ@/  @ п  @K19 @/ _# @ @RL"@ @  @ @@)ej}|IENDB`ironic-10.1.1/doc/source/images/conceptual_architecture.png0000666000175100017510000013765613243617463024055 0ustar zuulzuul00000000000000PNG  IHDR[AsRGBgAMA a pHYs+CIDATx^|U'd'72d*ZE(ԪEت:JZwu2D =Sا-v4=ɪ?# IH@H`\#11Wˤzmw18 "5`}_Gƞ+o[f}@b+U2K_z}yg12{/ʕSeϾ y)r#Oݷ_rrrƕ"Oɖbq$XXM,_V}Yb%}Ͽ8qqR>lM5Wn!CfO/smi٫u7I w ?LGSE4j`n]N @@6LZ&_̤Khl# x$cF~4ɯ9$2E!<"P?Vy?R}v={ɃZ{EIINUucHOY.-9  bd#ѯx [Y-'2KǗU5+❂4}YVrUe{|}~@0~{Yr}%$<|w3_Ni&guTI,6m+^Jߵ[TR@()a9nɡﾘe{i:1WǷn,%ya+9aS@/#ľhaHr:;FYYc,;>#G{iOfv]XGgV.\Wbiu_FY8^]5Hڵ+lɮl,rԏRޏ+Cb%Zڵi)/=iNs?}.C㞐^0^@+`dKKJ\Rzt 5GbwI~( *e֯JequetcA}J%D~Y[\O {M~\e̓,OڔkFKm؅hɜ?JFΩs$!>^f}@^ys<55;䞇8S6/Ͻl+,EΤi B@B(`dˏQ$&]j˿+~O0iX=ޙ"K 'JޏFՓZZGb]yt9Y]ztnҘֱz|i~]"]}8:gi ߲Vd|޾AW.&ָK5s"mj['(˹UX]^:G Ҭ<$55E{MdW[qҨA=] ^sB=8ҁN#OV{J\׮طtM;UY2VX|3EEk-}Fn_t41->e͂x.;jha)4[և\Ew do],cuI߳5OEͱa[v>i?[x+9W˹_̖ 5hļ[-̚|4 |Z᧜n1q 2gxb$y;7s̰A7Ng/z@ 8*_Jޠr/y):i ɊF tֲE/&8ۇRTNK+1|3GorrՓ&|``S?or# + u9R ..l۸WsZY)v1<QYzHA@ɓ~O6Nڛ  opv 3`< fJ> y<|t5WdӐpz68avPN}WG7nhql]Yf%=REGY| cyTYvG_0.u\=IN*ZlBi(=ect@@jFE]ŷm]f$;n1_z?lt´&:hU/ŪYͬt.+҇?\d;(zz78䭧ŲTW쀒-r>YwEy}KzY l E m6*9TaDn݅kK|\^ K>r8D{@ ٲv3nmmP=2OS   n'['.++ K}2:@@!e  sXFX,#, pV͙   @HB-L   $[Qv   0#  @T lEe4  Zd+ԏ  Q)@ag   jP S?  DVTA#  @HB-L   $[Qv,KK˰@$[C+i-l )ak@ H@|ɕR4a! ٲol vuILLLۥ T  @1-.@@bJe\".HZSRҪlT ɖcD@ 4l^&N@c٨U5@  x Erdrpo:0-M< 8Wd˹ @3]$PM(uA Cb}cE@ :H#ΌjK>{{XD@d$[\ d˟$\@"Aa@@@W   R%   @5  @d+T  lq   ! *U"  $[\   @HBJ      R%   @5  @d+T  lq   ! *U"  $[\   @HBJ      R%   @5  @d+T  lq   ! *U"  $[\   @HBJ      R%   @5  @d+T  x   @p '!(!xf;ürI @IV۷֭[&Gd+<δ ppq9HeذaRn]_*Y͞=[ 9%)/b@眀`5녵KÆ &Gd+<δ p_,l޼Yk_P h-G#X~Y7zh1W3f/]TF%Ç1cƘƎ+͚5Ν;o}+FСC%''|33gmڴ'x¼Gi+Voٱc\{%K.]k׮裏pN93r@   @8ƍ1b MZ,x=<ܹs=qqqW_}su_SNCyliժÞ3gFOEy㱒!ϼyh³fO?֭>|ᇞkƴm%t+93m-k4im޽syyc%r+y3='M[ `f+Ԕ@!.YYY'T鬔wJ䦛n4pРAjmϥRtϖ5j駟.L:U7o.V&K,+9KvdΜ9r}ٵw}!mf͚b%ib%vfVKgmV켊 W@ɖAo@h۶Ix߁O>-[JrrqUCjժ^Jf5MtB̚%3ɛ~Y3S2p@iݺ,_\ԩch^իW5fѣts*^TA"Q&@eg ʕ+-R=mJ~䣏>2 O4;=wb-?oYnٸq/,/[f+77לVf͒/\?KV=Y @Ǝ+͚5Ν;o}BkO<~Ϟ=Í̟?_?{EgôB2Bz6ȈK@yGo>{-@6g/q e +@g vlI AaK_$'4n9lm 3XF̸k@KvS]ٗY5=5, H?zD.^ݱ),ҷHZ%>F@ l9$}ܳ}T=>$S) ;HWFD@톧٭`Lڿsj\!Ύ|72@ 0Uqèaƌҿ-E\ÇƗ[t@*[{ ԨSD-@$[7̙#^ziԌ7q7o^4 F@-e|#YVӥ۽i*8@H&Xbt99: &w>wkǦ/]UY8@$- 6l ͚5xtu˖-0=EOsjK"4C@t-yLM8}}1eDe{ޙPҝ !D@$[&@; TX2(svKg*55p H, nisړ~: 3@J @p@Mޭ{K=b~mNj @H%I= Н n(+caZ:/   $ ZvVd.jm [غt@y$[΋=F(@\|TYOl[_l݁PgS*VNA@t-@Qv=els=]@-@lQC@brqл3@XVIJb>1|)((pɖBF@*"PAsؽM/܁ZxfddHLLԬY5l0ٲeK ՔxY+8{|3 'f͚IϞ=_6 :T͛#8pX1vXc=&[޽{˚5k|Ǿ{Ҿ}{iӦ[.39rtYtM v ٲC @XyZ;%:E).9s&ꪫ$33S^|Eիu]&Izwdܹ2|߫WO?]}MթS'%֭3eƌO˂ ̱{zHMf&M$~L>ݜI&{$|#,@ x$[&@ UwPo)SɓeժU&[L'u&7tԩSeҲeKIHHAɄ k1HitךE8=Og4 ͷ͛ˢEdɒ%ҪU+ĵkN̙#wɻk?0zQ)@awzSy_[N [! +Ə/?7Zj{ӦMRN5 Hǎ>'u]WkΫRp͛7Kbb䘯;Ot &e˗/7hտ3@pɖ3D/.?)Z\}.فoa:r "3K `٢K/CY/))P-zə 0@3o63i7n4t`/^VC@&?vA%nTm۶5ZJ}.On9]t1j92Ů]JdʕrK>}'};SeEg@1sh*..)9x]VZhjB[vĺD?D֢]}f+)K/zmFs6XkGjz#wlllCUr @ AU~} JrrLsU?EgիgR@;l! 郝~&[dD->>|ؗlo8i1[5e&_ٸqciԨܹ'u.Oygi-4 >{?K/仩<җi G@!2`(RGz)_D[t&A[N΂=fViIwa2IKgɴhm҆&V/_͌/2bv4  ZR{}YWʕ}-z]23W*U27dk믋-%'zUYOn?iC38loСC!z@@H lEH^,\Mלzt!_:i]v 2U4Q&2k]r[ݩJީNj,>bɒ?mx.5cG@|@_9cn3XtOO|Wz_lv!zGh߾}f_2 V;zJynSN1qyɒGK/ 9ta|Fz|9oӧ,\pW)vK|tYǓ{j1ޗ\ߡ|#v_P⌺I'ݔA֬Y#\uU2ݥ\}N.tajĈon6,}o|?`wg8z錫n?(Nu3lw:x_=‘m;%o=D7ޡo,D-%--MY6(!kyݼ|ryM%c:hoB׭!fk֮=z֣<د6vmηf|mL8ѼfmnPUk uĚTVc%H5R fJ̱f<kfc"d}2Z*."uaJu٠h3Z5:3e%=E7V,FZZ=No]Uo̲a .˳֭{³f͚ pBCa2yYt_$[anɖ. ai%vohkm۶5޽{hvl.~IcE-AaIx_BqI\r{ iSL1p89 d' ř< ֲZLmڴG [~ uT7u0ѢErE%@; ݛ V];k74,{8 pjGo[\g{0^w@( 96} 0c#{gviN2Q YT {xFvr'G߲qP7 l߾<0aÆˈGU\gQn`Iw20ܑM 8  Dc+uV^9g2BgǏ#  MHl   rv=  Td˦[   l-gǏ#  MHl   rv=  Td˦[   l-gǏ#  MHl   rv=  Td˦c$;;ێ]O t@@-. 5k&6lxtƵQF0=E@ @ ٥;w.ݡAXvh|)   k袋d̙g4Pڻwh:cF@B&Jjb##n`ޱcmV,Y"mڴ!.Y.]ȷ~+-[tɨ; |W!8#pp3[nbP^=_*#FCU @^^ƕD+ԍ (VdOv-Ǐg+ O-Md٢MRB/σЋ}zcZpJ'b3[yq%0}t8pqɓ'O?Ķ6:t{wӌ3Y:x饗h3c +i׮祗^X J, E]T8п P#<"V7" L`jR dݰbK=|תUߛ6m:u*ؠAر|g2qDΚU*v^*U7o,c;<%Y3VM_hSRR|~u@?ȧ~jo+֌$''qjE=|Ќ @$H"N @$l/ӂf=WIIIfh{.Fg5  Xd+T  )20ĝi0 W 끮q۱c1)Ž3rel} Wv)`]Ϸy;Z7ӭԪ!\: CLxsM޽YOiٰVԭ 5KRB'<3]+g*IiV+ұsTǹu6?IkT@<>lu݆ /4֩JpȜH +Gm:JChu`AnLgw6mjjgr.Ow>|ŽW1e{DcLA@ $[PM[ y?W}X _eTtFk yZ5"͚ͬX}>{رҬY3ܹ۾!zϞ=̓w!C &M.u=ޓۛkiRR7ph򤿔Xl1Cy8pYn~sn&={X}>hgOR8.]*FǢ1cJ%Xvifb1XS@>gZ+mڃ&kyi~}zƐ'777hmP}-v큰vσ_~өS'ϡC<[ljcxukYJSIn߾c%qJ۲rp챒(a5)((}9ƍX 9zQFbX966NS\\W_X+vc5}_"@E*s {zKv=jժrÝM!a=ZNI+١? 4H'u]WꅢEuYfɓ2S h5s   6m9BO>Znb?:bt/]wkׯ ҄?33Xeeen-3Ff͒K.$a 0@exr7-"7ntSIjEgު$1EљgyƌZx>kF4s   6m9F74}g:.+f塽{6\kNz!wuT\Yz%Ҷm[.3%/x]v5;pf}XRZֽTfN4iӥstS/3`:5No}k9@p 0h\0 o0Jq>TX2`E٤Wh:۸[EKIZ'Y6M-EY.5ꫯߥ7R1׊"'2r=e' p99z;V>ӭodCzڟ+2Hn}#{ $WXU%AMZU0*R?x󠬰vO?ԨQ<8<%R1Xi30h}_:3' CҤX Ͷn MDuoWڇFo}{qg)A?.R1@0 :$T,:/يθ{Ԛh}ٲD܈69qaF&!qu77nDո @$[ =;3Zdn+~"g  )@U&x-]:HqpڟA1@@$[6SapSX?7 L@@H6∣ ŝ[wFQ! @$H"ﰶu{w;>-VOჅU~NvyڮtvU%>.F=ٝQysTn~ @ $[=P)vS`^߰k,Wfwd>:({sVwTʩt+8\K$UB6# $[\;MٺWÙCO䐭q5JK8~$Y2WI6MM( Zd+2$yZ2#e[/I!OdvG(/>~ok^Wkoٝ#k\.2c~!jLy.#ֿ!7_Zyvn]?]-?w|1C2d!b#׃f alE%ѽm%Vݴ.vĞq" يth\1֯ ][,b uQĦRlھI#Gˏ+u?};wtڎksWϐqco0G왇GȜɞ[rcYBbއ]&,~ 8)p[6U?3+Pfo3 %ݢ   2mDn;/%Eކ~o^gjeɪoHuȕhfbm ׃O`ʛ4aV@t/=Wer۲v֍Sl?: N-w5*F,nOҭxE˦_0طK^z/19$@|U}d-JS 9~ok׹Ԩ]ߺ*ںWXK􏖴5S;[H̫G2+*8Q@ZuYAd=+YSJ+ jUMc%z@p X?I0\FY;ߛfg-|mzfjn`6x_ie'IRzblHY}R)77 !7k[4q{&UZ3^OYDf~'׎|ļze[x1{PwJSig"{߃/Eu1)Y]u3 ܣσ_v`ܹrٳo߾n}c|\gC{Aqli3yC|LO*&MYVԚ*]qU?|_7$͟dht4yLbKsM],M_vO]/ p灓"`4h >\x y.skx_Yt^,#θjԧutv^1~KL{9y_oc%EJ޿UF]>!Q[fOdY <.…裏_~cIjL/7 ~ @(XFJݣue. Yu-+Q4hZ,!zt }Vu%66ĪuRŕl&/Ou^iи$%Ո2-*+H :$V+W>l%7vә/M̾ eHBK]V$O^؆Y7DKzgJjСCM3B;qO߸@F2@8@:坱:Y/K3uX X-dž#h彇kĈ tR! @4Ѻ+=Xeh7M9E(Mdk@b}֋/=Ze ;ålp@ *K#N@D'Zj:.A%2@ jH6 p-]:زeː {BJ @ lE]0 \M:訽piFr  Z@p&ZVyw t:å-|r $[\ (:5(f%I= @ lE_1 ( ût0܉.3fpEVi@ fG`xw)> Wdk@ _ p+q @t lEw= `KHl/#Fc8R( ^/YQ1-r觗 gTA:W@kVHǿYmMt>uЗh/םsSC6HE/zy{p>o]:?Ќ۟] &o.Fc?a<@.$[v(Q`ҭkF q** +3Z+בMɌ5Ⱥ}O:}`zd,\P%R4 Rsi\OerSyJ˓z7(9\kguHʩR%]Bˊ G.@eEq8$ru$?Ͽߞ;,:)8RTF<c `WuIlL%)fVP DKgv^x&8YƋ2TC2םx\ pzYٜl[֟׊Z/;V;`y7ЄsƌŎښ)֮EwHNAT^]N@ C+m ِi1Fr sh*'H* $5>՜x$?GزL[ q W^-[&q:Gt]GHaKftk[7Jxߤ&LX{DzYu7;zw븇K[x^/$0~^nXȈzÚ՗LV0.)ԄkgVLY^>ٴUrIiҢJf9d!48_w_okG)~gVo_VJ&iދ> [PN;}< ,@j 8:^f2B]BhfK>Kg׋e^=f[2Z3Q=hR~[Lz:=byH|}6Xl+*5;n<%zڴi2qLruIqRJ(Z4Il @wWsuX$[,.\!6|K`y7ǨT)FԬ[[tk VƪJ Վm+-I\),Y{8rܿS7TM"IfyD},>ZJ8S5֗|y7(u-<0#٪"ILɖl>X|[rނc Tuނ㒭:/M [ɖn}sOY_E[PTNJ\ܤYN趒i=-3CV'gׯgH/#iIۥ pEOCw[zm&Ѫ#5&V5? <ke,-kVb̌.6͹'_6NCߙ[>Y\E']& ӬI=DHJ|u\ҢVvn۠YOլq[VlX_xV y3}]XfR@k)aabh]hw&Z-9NmҺUT6İ~$;gɊ{17vh<Ӻ'SI$~xqm8o-.[ ˶R~e9My~S9S߶])V!LO$$JJc[Ϟ\C>}9W,MIo/@ $[ԧm@RK K!VpM2E&O,V2 -b֭tM&SNK˖-%!!VB8=Og4 {h}͛7Eɒ%KUV&k׮̙3G>˓w}w q &3\$Z'FI7]yѣZj{ӦMRN5]4h ;v>L&N(]w]o^*Uo޼Y%''|wyK5)[|9GB".@@ xgt#R"*5گ_?PgQ^r%B.uh{赢_wyWTP c et̞\<]+pؙGKծm)?͒m +M \σ͊G]tjժU2?vCt _鿝YFÆ %99y:[EtիW,5W*"uV=̖scG@pc M HwiRH-~O:>כ6mPR pW . tP5-̙rAg@[ l*t@P>ػtW^!Cӝ>F7,( lq DKa0gtFK̙B9_`BL( 8E$}W0-' "Yl;V.\hcꫥE?OҤIML.]Pw|G}-=YYz>'k{oFkmG);waÆɊ+1" 5-!@ {g^0⿀nϮ;j23\s|C+IRwO?/R}]Yv2e#<"/ܹSk6m4i9f[xMFK5G" 3 P@YR}3Z駟.gy٪Q҄KyfYIa:cٶmItvzZO-SN5;곸!KvdΜ9fLzIɖB@(ϦE-f&?v[tU;fҩS'xC:vh?]5-z>/+''|wy2p@pRNp߿❧@ $[!@J@xgtd'Vc;^~?YwnjѤKg DV 0]gn/,/[Νkft"ɖ"B@*$}6͈+:ȌV:Y'wKaiLSO=%vԫWlѻwoiР$$$出P7С\$k}'|NN/C cp4mR ̞\<]+pؙGKծm)?͒m.m1>!^w{*WkXg40X~xx[ҝ>ƍtӌL9|lR4袋mPnqzVѢ3]RÊޗ\rql+@@{K nAK%66֗hit }Mgtkw}n&^ݻTRDKU4ъ"@lEK' p1x3Z:h aÆ9]r{-/N ܌3@$pi5)$Z6.܃l5@-8@p}+kCG@@(@Ĩg@z_-\ƌczOHfͤgϞ/׆*bb Sرc=nZz-k֬{IM6n-pȑҹsgY6 YdelQ/KfΜ)Iz*̔_|Qz%wuIy;w̟?իO_$Y:u]n:~[f̘!O?,Xw^y衇dڴikҤI͹diM¢>H  kH\ZȔ)Sdɲj*pr-[nrM7IZZL:U,-[4hL0AH錔&L^{[4tfK /|Kk޼,ZH,Y"Z2I\vdΜ9r}I^^ 8vaCZ =ݰbK=|CU7m$u]!UAұcGdĉru#۾}{TbyfILLuy.AԤlM !`  $[Q| ,5lѥ\R,-~IIIfh{Zv^&:U~}Z7hذ$'';OgtyhљzꙥX<\xGm#Z.S`?ˈy\}lQ+I,: f34) $ XDKphM6D@Kd+h@@@ L$[a@@.7E6zO@pɖ(A`޼yfHݝ+dh@Vȉi >|X>Ѥ YdelQ!0tbeŊf@f͚IϞ=CGK{g…W_}hBƎ+ӟI&a4{Ҿ}{|-mG>yȑҹsg6lEgv郐qҥ2j(>|3&* @@}$[)#2O?]}3j}VֲeˤSNfywdܹի}:4m޼-[Gr=,=y/"G޽{ӦM3_&M?POntɞ&K$hHƏ/5k֔)SLyE|]wEYD. Ed-dQ+p5Ȍ3̬&=^{yԩSe9X 2h 0a_NyffFfKN;$hZ>CkѢEdiժIڵk's̑^'md}֭tMW9@ɖ"BPAұcGdĉruי6m$uզOAAA۷=}hVjbi•(9993[n-˗/7jտd}UV Kd^7K@gtɞ>,qp̙f+;;[f͚e]ʧɎ~_-]~o0`Yr3^rlܸQ}a/,_Y/]zXZ)@@; l1* 4%}NzT۶m&ҽ{wuvtJ[t9.ڵtAV\){>}'};SK>C@(㱊;>2,~%{|T::hM3tƫ~%֩3Ru-W{:gsVѢ3]3K )eџ:r (7m:@e g2 /-J}% pEuVtƝQG&B%ZPDKϭR |he1P@@E$[. &CA@@l'@@\$@`2@@ɖ}bAOpf9t@V#@   J-WA!  @H"G@@W l2 @@"-@>  Rd˕aeP   iHG@@@$[ +B@@H lE:   reX  DZd+}@@pɖ+ʠ@@@ $[#  +H\V   يth@@\)@ʰ2(@@V#@   J-WA!  @H"G@@W l2 @@"-@>  Rd˕aeP   i G`ŊcǎRk}GAn@|+*7:Do""2"4@ l95_,k׮-V?nײe Ju `G>/ `Wd+޵jՒk^uAFaZ SO=d+T]ҪU+m&ժU akTvk??ңGIlڴIԩ&NlAұcGdĉrukuֲ|rs&\/ՃRRR|Ɗ㑲oIޗԧmCd+q~7M ~{[zP~RC]zx%u6K&%%~mUZx}f n`-eRKx_Zn_3_) |'zgնm[iӦ}Z `OhLg1|I۷;.rzKyYgjޗ~[ Z 4#eӁm^9)Gs"%?@bl&H8gz͞\<]H۰SGKծԥb},ئp! cmU vK XQ+(1Hl׸TY;ltfD4qFW$Z}/ZoY'g~8 ֶGr$ۚݣW ZrfWX'9IWI,= CjC>N(.dK;vr9ʬZKΨIJC#٪`pUIՑe_Hb} 6غ%s$&*I;dˡL)Lڰ 5EmP_ٙ8vid.o?"P˶$Zy[ۙ[>d1t(Py.r[7h9<%k,dgj$o<Hg4њ~l:xD+8-ذIM]( KtFp1f˯ Mzdr8e#_-|:uF!oB*|A `$[z.K@gvgsנM-t*|EhAt+0pvWT % D$0AН挭 n=Z!h& fܣU!B۞C D$])<ЍJwS`?:Hqlsvgd"lw dvUt{w;@v~srE7PW}B?jyOOVNF \;՜-iuMwo_W?y}7B /?OroȽ}.%k27/ fԅ8Jdp}9wοˁ7]V*+V|,WBB m\z 6E"5{(]իH59Տ?lsx |;<}͒!##\v˭r`y{eVq H8/7O{<ڣ2dԵ OIdEY/جCëcɢ$rxsZ8<{2﷎wp۵s[+ Ͽ-lQ&_gy㱗Eg*:U`_$%>Ś٪zZYK{xg=ߑ^g; S1ˤK}=?by\3_&y{p*v@Nv5a_ gs^%GҬCqRGuZ3 ΗG >ؽ迥7ƌ/gΔdž_#c|ز]{+Ryd^[صK^r+ˇ?g;zb! HkǦm QJZٻG0>?Oλl꯾-)//_[BX />M#Ix7cs4ƿdl)FnN{1b+Itϙ+҄lͪtU' -$]vp0Ue7ߖX'_̞+[앚i˟>) WdoR%[oֱ̼YsWяGWJٕq@46*B PkטjZҡgb2T8YF<:j5aך{RҬ_ 9Ǜ0-yy򃕨}9s/=]֭\),2W󷏔-w'O&s~KÆdMݽuLϋV}:TG"@UqۆߌժWKb*ֿƞzу [˸O^K|˛X\6Դ~kߕS-Ƃd`ѻ5y7Mٴy>߱{v얋+( P]?m;I e}Aֽ[$!hY;[|%IS͡wx3s+66~IuִڰYآ^k2Yd6-[+1@ b6k6hnCZu4KoE|8M{-s+v|֡Cr[o?>+ |U+͟V|!5՗/T5o.;~mXZO*l.Dil%v_oo-bx4Q)@U$ o<%ziyZkz{Y7vy4iLRK5c2vq}F^fRRo-_MAyGdrd_vl_rER2nf |fvh+ k֐Jgs6-%MbOLkI׿y+7Գt{IZ5#~̼S'@0NZ3H޲ZI/MxJ*O=UnY|=fKF-WN3|+lC g.I{(reTˬs:_ W|س[^/rGGS25˗:@b o cӬ0S:5[$!j[^I].UkV+=Ȟ%-s䮧,<5^:Y:Xuo>Rɺ_ ~b5k\*7 ɭzMȿ|dZkjʊfrg.8M93bLKެf3Pߣ9͈< ;9bdx)>>sCa.id%U:'+?'n4[7vx~I.\"7yvpײz?p>/lzi-;G Ru#ݏ\tu\|?[A]a}a{hm-{o=֗.KM~t7w*ԑ|nf,jյ?L}y /}RtxݽvfVJs>9/$<\xu2W|1m4>TGEKov݋"k˔.3} O~݀/"L:t祷k jכx8(X9%dΖFKڟyyqSxU/ٚ/###]/ԫ+yMg)c .@H#ӄgJ-1L}ɹr{ .9{$95YV.^._Yd=khh,qyٷdkSfZr3${`<[tiwJuOOi=leSZb+U+{cgIMeJurĺgK8J`mԕvc Nt .  ٪^Y;9RCPήoShe}*σ=;IϔI~^[WJ7!)Vpx"HU!l@C(N ;bluUrE]d+䱩NH6_ZZxJ[:@?L>!*:Ĥ8Ypi!J xpKd]d4   `-n   HOF  6 ٲI   Kd]d4   `-n   HOF  6 ٲI   Kd]d4   `-n   HOF  6 ٲI   Kd]d4   `-n   HOF  6 ٲI   Kd]d4   `-n   HOF  6 ٲI   Kd]d4   `-n   HOF  6 ٲI   Kd]d4   `-n   HOF  6 ٲI   Kd]d4   `-n   HOFQ&#'Fp@pɖ3D/@R$+3&}8WRV!,@g x9/`8?[SIzN rr;D@ɲ{ǡw x{3ZUHM @ lEq:8_^*s!+p`A?5@ $[n"c@R=IkրOUBfgJM $[F.h߭lZOvn;0H I3G Ndu!e@ m:q9e[RVv Tdt;[cR9"q. @-.@59CGd5drPrA|=#yf&ow3I,MRAZ>@ bh+_GKծC܊{=xH;q;ሯncٷ+zWds]¥ρRn41ߝePM8"9 #F֋?Iq`t3 s'_zQN!NZLUq2kùL@U1?ζ>xWyxvf}^v<: +Kzͦ"IR)6&8*G-o<8S"%7Rhdq t,# T@".3[mzr-Lxί'lrDe-/)V @XHL# \WHV-fje 7K44ߏ㟼Pŀz@J_ @W&![T6nƣKΦ.@)@̸k@Zwmfn0hP'@"&@1zF.)M06kd`@ @8@PFu @$H"O AR-I @")@I}Fn )̭7F Dd@z@H lER@@@$[ -C@@H lER@@@$[ -C@@H lER@@@$[ -C@@H lER@@@$[ -C@@H lER@@@$[ -C@@H lER@@@$[ -C@@H lER@@@$[ -C@@H lER@@@$[ -C@@H lER@@@$[ -C@@H lER@"'=SdZC9OVPڢL#@HI vH "X4Mٌ`.@( ي 3D@ɩ&yNjF3U_nɮ퇤AӪvƇ `3- O}RRٙi*kYXؽA*,@* @U' Q#@5f %qiKJFTs! -Hl: Pͪ;Y,,# Gd+8Ԃ `ظJҸEuӓTkš*۠Wt@ ZH5p@V5:vo2,@l9%R@/7}KZ~A Jd+Tԋ 1/>^i@@*pV chuthqq' i׋Cm8"6dȾ݇%9nx.}Gԭ? b݃uTj5HH6`93#"MӨ8:fx@T-_Ynٷ0qۿ'K6W|^ts@" $[FQ$?񯒾 ]A*{3MEe@@$$[\ @|6̍Ѻ˕KpɖG@[{89D@gt)(@$[ B*apcvPImSٶl``@8-. @ tA;v -! e w >΁1*@$[."C@9Ze 9ֹ ~-ǘ"  @H"N   ~-ǘ"  @H"N   ~-ǘ"  @H"N   ~-ǘ"  @H"N   ~-ǘ"  @H"N   ~-ǘ"  @H"N   ~-#q0@@ يx;rI)qȾi@@ ي;fɩ r`_cKG@@P- T,w}? _`s咡ss_I˦ é  z@FUdCW`ApZٴʼn v ٲ{Td| @ -eؓeד#IZJ@ يθ;n՗Mkmw:.{lZyO oXe[-"_ž/wrR1.XZX>ABV#@~ $4_lVKA>[A@`s,dӖuNJƝpզ'ֱ:L[mef8+zl P @XHL#Y7Uι8" &;6ÇrxW0 se~w^dr; W Y_eۗұw?Fmε]C@XB壥j!n%׭wl9 veYʑyI~z|PFid*^+L}fIi2o<6.YhUjr4@o2="園%f6g֫Q10 ĸg00d+ .jE,a( ?|ֱdppAL| mؓd+Lq! ;!rg\ 6ݲZ1X=m讄ǵ@ *H" p/ N9Sf\$=ew؍ZHSsn6tӌ;Ch2cD$h &SEf䪑>doÍcۿݘbs6 @lEI& &÷`׽aTpMZjx.o]t@AF04KPmTek 2l"Gv 266;a wƵQ1UG@@!@U4NA@@ *K#   *   e l%@@@rlS@@@H   @9Hʁ)   @Y$[e }@@@$[@@@@,>   Prq    PVYB|@@(V98@@(Kd,!  Cdh8M !1i]~ [?8 Vi@jp7I{aHh@ P@8p@I5]GJub  ي:m"ahtJu s4M@(V98p@ZDӰӺMY7UN @$[6 B-j/BN=FuEGd%A\ )RQ FC6Ĥ` Hl S@="Naux0CSƨZdiҲtLՔD+4ԊU cHe'd,-UF^brA7k/PłwW[vN!_d1f #֝ȱ̌76|K֦?Dɖ=B@g{⪴Krʭ 3OLCVP9 @ ٻ%(Im9\*%(|bR{|;o $[F8^ 6 IVAWq2@ l9/f@@ @ E@@pɖbF@@@$[]D@@ l9/f@@ @ E@@pɖbF@@@$[]D@@ l9/f@@ @ E@@pɖbF@@@$[]D@@ l9/f@@ @ E@@pɖbF@@@$[]D@@ l9/f@@ @ E@@pɖbF@@@$[]D@@ l9/f@@ @ E@@pɖbF@@@$[]D@@ l9/f@@ @ E@@pɖbF@@@$[]D@@ l9/f@@ @ E@@pɖbF@@@$[]D@@ l9/f@@ @ E@@pɖbF@@@$[]D@@ l9/f@@ @ E@@pɖbF@@@$[]D@@ l9/f@@ @ E@@pɖbF@@@$[]D@@ l9/f@@ @ E@@pɖbF@@@$[]D@@ l9/f@@ 㱊.f,-Uv|^goxqs g}$&-Ánc=#qE_B݉XCRI|kI@LLcw x63[N}F@!Tu?rd"ɳ-'&ZZ75F[ΥrW%s[=h يH3N@,?e ̭\0j.`RW4lEC# ?)i2>EԉkH\Z @=ZDҥOd?'B@t3 -1 s^+Kd/&B@@tA;vs` l*@vޝN#{90F@HBJ Dۻ -# VM@@-.@@@ $[!@J@@@dk@@VP@@ @@@B @TD@@H@@@l*@~~jD@VP#5k} 6Ll_q'k@@ $[7 ڵK#钕%ƍ h_C%   ي=-H ..Nt6jٲetR5j >\ƌcFOHfͤgϞ/׆*) 8PVXa>vXc=&[޽{˚5k|Ǿ{Ҿ}{iӦ[.39rtYt[   (p+bpM8ƬYd̙ꫯ窫LyW^r]w$wޑs^ZN?tyMׯ_oN:Gbd_~m1c<Ӳ`s޽{塇iӦI&ɇ~(ӧO]ިI&{$,&WDp3 Td+ H*R? -DL"'OUV[n1]֭tM&SNK˖-%!!A $&Lk$R:# ӵ^kOZL̖&a^x[k޼,ZH,Y"Z2I\vdΜ9r}I^^=?<)D@ =ݍ5 Z}T0ĪRb5h"a矗=zU7m$u]!UAұcGdĉruיcdIdپ}{TbyfILLuy.AԤlMnC?pA@t`dތ,/뽾_38pTt Do'DVbD CK4aG~Y*]zx%l.KJJ23TZIǖU=`z&gz.C2`9p|f&mƍflrwcu+77׎$Q'>~lV'Y׵ySdڝa{Wso.Cs_@޽;J.@t+Nr3~nC7 ܶkB{ڶmk6HMM}jz_!ZU{cstbrie]v:ʕ+/>}ȓO>)}5_wy#;AxlVi$)rl)M.]H5ENMIT{(DK{OMh <9,yKIݚMN%|1kcѢ3\3_AVNmY[|YV#?ج{u /D;hWgtFKw Ǹx",VNFZ;M?H<+qpJS\/NTI|Y8*5yкde:7Ӥ[& rמL}4ْ`ֲBMwn"7҂~5k{kYwR,_lo9ݚz|G~ˬzudnkZO:t)&vZיG1wJKAŢ<͖Veֲn56ԖO3XMklivML=3Dm5KO?-ovdK;n8sO>?R7nҳgOOKbH;Aev}p/gy9><(?c?|ɈDo2D(yrYXGnyC.LL}]OPz9d :5Rdŏere%ZȐ?#SNm^K^I^۸[_D$.ӢuotU7q=ϒS_*$MK:K^6IJ uavԭ6|~w+ ҁX7~,sfu|QvF&zj,/$OiND%zNԣG9묳D/R@^hP|w!\4}v&]|4iD.Ӗ~OoT%W_}m|T"eOZ_q`ře԰hэ+ο.A<=W쓄Xiި$nӮ v1Zt#2L7(O)3sʺwY~DA ي3 VNoj׮-'NlQ~믅;`TN*6ɗnۄ ̡ݺunD+ѥ2p@|\%iۢgDk;KNZF VЫWI.HVuOH]J3]DK_Y2dC+ov ѲK4G$H"OۮН>T4iYJG0F*}@.C<=_6m:uzs}$@-{ k"kFDh ي3 @7xC^y5rHywf͚ɑ&dh-[׶Vү_?9s3;;,CKS '0͛voZ(>~ ,@ @8Rt aÊ}W [je6hӦ_ڵ+ѺnݺRJ1bDz s֫h<#`FN@JQ\ ,6$ P@zzI]*ͪ\5\~.PC"` 2‚F Cgh$V@\@OקM|ϋD1L@@ $[ԥn@@Z =G@@P lR@@@ jH6 @@B)@J]F@@ ي3p@@V(u@@Vd+jC@@@ $[ԥn@@Z =G@@P lR@@@ jH6 @ ĥrj(?;Lda 8A 6I!P)F9Sd+:Ψ@@lJOMi l9,`t@'*ÏNU}1S8S0jC@@lr:t PsDNM"6"D-'F># &Kj)]G@cl?r X @@ ÒPTOa-Mb+EA$[#@@Y;$w ?Mw&a nhtоg ٲw|  8T{8   ٲw|  8Tdˡ   `o-{LJ!  CH8   ٲw|  8Tdˡ   `o-{LJ!  CH8   ٲw|  8Tdˡ   `o-{LJ!  CH8   ٲw|  8Tdˡ   `o-{LJ!  CH8   ٲw|  8Tdˡ   `o-{LJ!  CH8   ٲw|  8Tdˡ   `o-{LJ!  CH8   ٲw|  8Tdˡ   `o-{LJ!  CH8  h*~ IENDB`ironic-10.1.1/doc/source/images/sample_trace_details.svg0000666000175100017510000024445513243617463023331 0ustar zuulzuul00000000000000 image/svg+xml ironic-10.1.1/doc/source/images/states.svg0000666000175100017510000011265713243617463020466 0ustar zuulzuul00000000000000 Ironic states enroll enroll verifying verifying enroll->verifying manage (via API) verifying->enroll fail manageable manageable verifying->manageable done cleaning cleaning manageable->cleaning provide (via API) manageable->cleaning clean (via API) inspecting inspecting manageable->inspecting inspect (via API) adopting adopting manageable->adopting adopt (via API) cleaning->manageable manage available available cleaning->available done clean failed clean failed cleaning->clean failed fail clean wait clean wait cleaning->clean wait wait inspecting->manageable done inspect failed inspect failed inspecting->inspect failed fail active active adopting->active done adopt failed adopt failed adopting->adopt failed fail available->manageable manage (via API) deploying deploying available->deploying active (via API) deploying->active done deploy failed deploy failed deploying->deploy failed fail wait call-back wait call-back deploying->wait call-back wait active->deploying rebuild (via API) deleting deleting active->deleting deleted (via API) rescuing rescuing active->rescuing rescue (via API) deleting->cleaning clean error error deleting->error error rescue rescue rescuing->rescue done rescue wait rescue wait rescuing->rescue wait wait rescue failed rescue failed rescuing->rescue failed fail error->deploying rebuild (via API) error->deleting deleted (via API) rescue->deleting deleted (via API) rescue->rescuing rescue (via API) unrescuing unrescuing rescue->unrescuing unrescue (via API) unrescuing->active done unrescue failed unrescue failed unrescuing->unrescue failed fail deploy failed->deploying rebuild (via API) deploy failed->deploying active (via API) deploy failed->deleting deleted (via API) wait call-back->deploying resume wait call-back->deleting deleted (via API) wait call-back->deploy failed fail clean failed->manageable manage (via API) clean wait->cleaning resume clean wait->clean failed fail clean wait->clean failed abort (via API) inspect failed->manageable manage (via API) inspect failed->inspecting inspect (via API) adopt failed->manageable manage (via API) adopt failed->adopting adopt (via API) rescue wait->deleting deleted (via API) rescue wait->rescuing resume rescue wait->rescue failed fail rescue wait->rescue failed abort (via API) rescue failed->deleting deleted (via API) rescue failed->rescuing rescue (via API) rescue failed->unrescuing unrescue (via API) unrescue failed->deleting deleted (via API) unrescue failed->rescuing rescue (via API) unrescue failed->unrescuing unrescue (via API) ironic-10.1.1/doc/source/images/sample_trace.svg0000666000175100017510000016123313243617463021614 0ustar zuulzuul00000000000000 image/svg+xml ironic-10.1.1/doc/source/images/deployment_architecture_2.png0000666000175100017510000011255413243617463024307 0ustar zuulzuul00000000000000PNG  IHDR1 AiCCPICC ProfileH wTSϽ7" %z ;HQIP&vDF)VdTG"cE b PQDE݌k 5ޚYg}׺PtX4X\XffGD=HƳ.d,P&s"7C$ E6<~&S2)212 "įl+ɘ&Y4Pޚ%ᣌ\%g|eTI(L0_&l2E9r9hxgIbטifSb1+MxL 0oE%YmhYh~S=zU&ϞAYl/$ZUm@O ޜl^ ' lsk.+7oʿ9V;?#I3eE妧KD d9i,UQ h A1vjpԁzN6p\W p G@ K0ށiABZyCAP8C@&*CP=#t] 4}a ٰ;GDxJ>,_“@FXDBX$!k"EHqaYbVabJ0՘cVL6f3bձX'?v 6-V``[a;p~\2n5׌ &x*sb|! ߏƿ' Zk! $l$T4QOt"y\b)AI&NI$R$)TIj"]&=&!:dGrY@^O$ _%?P(&OJEBN9J@y@yCR nXZOD}J}/G3ɭk{%Oחw_.'_!JQ@SVF=IEbbbb5Q%O@%!BӥyҸM:e0G7ӓ e%e[(R0`3R46i^)*n*|"fLUo՝mO0j&jajj.ϧwϝ_4갺zj=U45nɚ4ǴhZ ZZ^0Tf%9->ݫ=cXgN].[7A\SwBOK/X/_Q>QG[ `Aaac#*Z;8cq>[&IIMST`ϴ kh&45ǢYYF֠9<|y+ =X_,,S-,Y)YXmĚk]c}džjcΦ浭-v};]N"&1=xtv(}'{'IߝY) Σ -rqr.d._xpUەZM׍vm=+KGǔ ^WWbj>:>>>v}/avO8 FV> 2 u/_$\BCv< 5 ]s.,4&yUx~xw-bEDCĻHGKwFGEGME{EEKX,YFZ ={$vrK .3\rϮ_Yq*©L_wד+]eD]cIIIOAu_䩔)3ѩiB%a+]3='/40CiU@ёL(sYfLH$%Y jgGeQn~5f5wugv5k֮\۹Nw]m mHFˍenQQ`hBBQ-[lllfjۗ"^bO%ܒY}WwvwXbY^Ю]WVa[q`id2JjGէ{׿m>PkAma꺿g_DHGGu;776ƱqoC{P38!9 ҝˁ^r۽Ug9];}}_~imp㭎}]/}.{^=}^?z8hc' O*?f`ϳgC/Oϩ+FFGGόzˌㅿ)ѫ~wgbk?Jި9mdwi獵ޫ?cǑOO?w| x&mf2:Y~ pHYs+iTXtXML:com.adobe.xmp 5 2 1 2@IDATxUWy !(`5 ̴ T-0~f ܷooք`$3D} ^|m X Z iBL"F!ښI Y39>wgzwmV۠IB @bK`Tl-p@ @@s#@ @ 1@̇ @{ @1'yb> @ @9D};!@  @@ cށ@ D= @bNQ|@   @ sw C @Q=C`Ν裏 ĒXZÇ塇X) KO}|)=F֬Y#c>T@r ؼy3Ã]@AQ~ CMU BQ F I}z@MQuM@7K!@>TT7BIQ~u@ %ة4nq1 >]Mk oB (D}x)}ZV^-ǏBn)@Uz_]VTرCԛO h B?'^}Knj`ܻW!>QWdo>AЧ^ SNb^tvvڇǠ|@26Ba|B~pthWe͚5xcO_kQy}ԇI B gk2'8r5~0 WaO @W7񚌾 g5B9IV;wZoibS4ֆx 96l Byg]sm8&a {n&δ5֭['=h ZGQ_f~xߨKeg)>ʷKػ)|iM[G@HOC A@0O}_s_juobBu.IBi942'NȔ)SFXGA/P7-*Bzg_?[J P+D}RZ)/q.05ery۵[ c?۶UٳYN B-OM}L`芳0S* Dŧj L_^1SRu,K[[X`x*8f̘a יHHh0a2z![ٵS^4_5B=˨Q짆"ZQ+ Bث:v+{VΉ{i Pes)UO 32 R^VN.9k8*vF Y]g#i@NQ_7ǿ!wK.YY3/ ~}*"// ~nWѮ^?G.7\ow=~9D 9]La_̃o 4OQ_Krygǯ˘K Fvqk^@r,}Y, @A*~On^E֛/?㭯S + @u@ԗҟzbsf1K9AoD[_ j&!@BQ_NC]$蝸[_`-m}v~̩Z}M@@8üg/[?7'/>Y0",td 9@s'@ D}z/,/x8:=e`C]n@qw{)?O @!@M@{yuƛ>78 y߳p<,Gy҂'Cz|Y/\PM8@ǡ =>)xuƛsz靸|֗kiy{I{FN+]C23{ ӈg񏰯7 @H(D}cy鯹V\|?oro}&vj_,zEtuu9bPU1Oҗi6E.xcy@hDz7K_֛x=0=1SӮQõLio7ǏTB2!c] @h)D?K52-:MXsy;lClg?k ֕o{j ĉ>[E^ 1:7KW@^kH_{<\hHE#Mm 8H楿\,}^z絷W]_BqL}4>O}t>7#)KxKW};p>T,V (H(xu^'Vgzw/^ryƼ2Xf@[t;O!NȻ,>xt-p><9)#m3t :zr<̵=}풱zP1{-fAU@|U 2T^+~W^?և|#V 3nHa/#&śuMXW^ӟ._ }>/g[";{a>l*ӯM0ӾP $@EmY#N_Yr'_N La_4F[̧ZE2U8_ xm˼ꖌObt}Ք5AUm8'!@@R+yL1]䋨r&No=#[tS~><å*5 r* ,2}X ͼ |sB~Q|zi< 󐱽/[hCFڛj5}Ky(iv| H߼N[olDE>߿_~̜~̔;_22llքIv`3TchIsUaǦg%k:#WP.t;kVgpi̓R3T`aCť bJ ^jKG.1W/ZO39t}"$652 mR73Mڻ`Y3HO5x֛݆f1oBm͸ D;*l!@D0//yMcYik>ukp*Ⳬ%NȚAی(7FCЭWڂe(=nFOJ@ '9/K5x zS{ETm71"]U R7_M|{"hjG5\⫗ցv{o6;Nꆟ53ᘩp/f3<;}eJ!8%G U~]1c*k#-mK#fjR[V/)<7{Roܽ k Ր^3WG̔-"e7WmHOڇT!7 N6cH !mF}M67ߔӧO?]K5xecCS= +WqUބ jWRcCL]\Nu~3W_rYWwǏwv z>^)7`_WwLװ3FBQ!PMЗ!@RJ UǣF /P.b}'yݿ lx֣u P}= @H7)MAE{vy;)]vL8׏7><v[,vhNgVqqEIˇ^kF+QTV u{:1fo-(v@@S^=:xUC`ԃ1AxFp9֫ 6"{6VtlhNY1~7G$i43h2zYF̈D!=*җ{ xoo-fd13UL4j %2s:A  zR;*J*^*,JZ9Q,F`ˉ܊. hklɗ>SfJL hJv6 N^nV4!W{uYQ̊yA5w̬"۳!ę4ԜP`@@2F {袋: zիnܧ?S~mLA#c|U]5y##Ċ#iEĮ"?kλ 7v5bݶZ B7j @F u^a8Ϲl $AW93eG>Ɗ嶫V/UE{VEq1{wL@vzDCuۋtn܃JssWoMl8@R)GB?੷5}flޟ] ^Qߕ5y:ԙ5^y[*:rPNaP@@ _TWzԽo4uk.]37# iTݹfi| ͇td{w_YW?ӆu77RwݺbityBv4l ;B T(Eշ3vFwֵa旜Vn TXkH )q46Vq/i3 %)&_jg>SwgeY*\Qm>i= @^vEeةѕ /|ɇJ?Nt,,GϚ3e!27[2TWϘql2˝*=C@(uŽ{Lv黨G~@@<vxtVE c4 d'qo}CIA"(q$$C `w.Mk 0رcӭi(B t$@^yM4IN:t & ꛀǥ[kSNǏ{`{PE u9AZ!ѣ "ISH@AI :}KCzuיi(=3Z-|e/`R J+Eɮ]vńރz/ @u!b!2>׾G}pf6{+m8Z)赅7pWNSp:P{Ϟ=x'9@EYRt̂QYQl+{1FՂ^y7k֬?ixiOLlڴ zM  vAmtdy=fU67lt豥;>O יu`o>cEOG\[w͚<}vZgG1]|yï77GMERLi9 ^jSVvbLV3/Gi~ϴ',v̲ Yy/۳L2.5eݟgl^ϿlмjL_7]=CQ6ڑt=]9#( zmzw!+WdzKа˗ƍԪss&yQoCoڻfeƣݗW}[tٓFw\ڻn69<상lףSuƏ~8o\on>OGǽ=ywb7w9l1oË&]ӦU\uvvÇaz^S9sB!@>Kݣ9֑1"^0n_/l[BbFτo^wȗ*YfYڵk%;ذa{,\зr)#iQ֢!.a4FkI[<&>4֫&'!3&\Y)qW,6{LNx$vb@kz5GٳeղsNw:[orܹP>Z7B6ӦM'NݻЇT@`$_ޅ[Or3k4\velhH| ځy{ խvtÉǠaכ7 c4!;f AWohh>)q㭧СCruفA.+QFɸq .ѣGѺN;N²U)Sd߾}~zb?6"Dx#d@%4\E/?q8nH=gϞ~| |ߕ/| Oʅ^XTR%:BL5ost}y٭~'A@ DS z 9s=̏>Phj֛c.t.Ǐ+sε!5:s֭[=)iN{ T@ԧil'*uD݆u;{¶!t`~tm&'O_ڵzg̘! E`tZOA|A`O#?Rta6}@2U@!.y)뚿nxPv" @wzߑR  ,BpF+Z>]r 7#]kRe^a=T@h D}KS) (k>#w__ZM wrʴ5B4D} ^#y׋+bGUNj:^\ݻEgAǎ$.eC3ߒ[l_|7;vرa(@ D}P)@ ôD}z {!d:6T؟>}) j'9!@*,Y"@| D}H@PJgToٲEtZ #55AH4͛7#42D}{ r~O9f_'AfTd Zx@-$o C?Ry">}̟?_h9 D}x @_^-ZOUX@UFb PW9 L&c V}dTDRNQC>h”@@Q]DHvKF!FDžj"  (xWȧZxٻW\=~ ׅfϞmCqNj@b ӕ4#PkK—n{x,\@da T{}c `wC \}r<'=W!I3 4u'zsm%cTۣ^{@hiDo)_ꌚe%`@sj@ xW~rUΘNyeqD-XB9ܹse2k֬P@I#OZ@ø*'M$8v 6C @HtF@H7 ͛?|paz@ @7K 𛚶'QH#< pB&8A!OLW$@g7,lS+,#55AO>@ 1Jps eaF{PW؟:uJ446B(KQ_ !@ T:t=}d28|')B~Pywu]{=/xP\9P~zʗV?~|Y}zz!V`Vҧn@'{#ňAsd_SeNڵ o};  -CS]w+Pv>"|1'~ʹk#}x h=<,"}BcZl.N'cϒ >-=M;!3S?#篼"?b|~i*T8p@?.+WSCQ% '0vXٱcT{n @ ie$x鍯&j¾!l\Ĕ>H?*5axb[>OМ4Lkiy @ԧi1Gc '>'}Ό6aZ?!hF*w-:a_!X`XwCCU_?,a6olΪׁ*I@O}z6@ W2&U ~ҤIx+0 OxVC@MR@ #}gg -EQ1 P͓#G^@ r(. $zkIvwM׻n+1Rmmm#e| d2k }r"l.A(KQ_ !f81sN9tЈE91o믿.'O,LC9>d 6_,G굈ٳgŋ\> JQ*n*@:H>l߾]zZO|Bz.i*֥uD,L~y쵣F!)C8P@R8 06ǷB@28Aoș3gS?d40ߊo|f+_\tE2fA'Uڵc?ud4V@'O|@K@EѨW_KM717>oK/ {P"M6oc!*@a~0:.*pNs=rQ1mжhŽtm{?G`ժUmg9~8X D1" @ lH\x~V>+WArw6imE>+V,nV<#< JVҧn$[-P5hGE {wsmSi MWZ$@'WiZLyUkQa㺒gݻWǍg1%\b\ǡ+w!fj0 D}@`)i'P*<$콂~2a+Xg^_D@'iJQמnD1W<^ k<رcZZD`JDt#@t s_~Yt8Їd…jĞ={ !7<Hu[(轱rJ<Ц@VZIh@-`d6F& D_Ot8ĒfL,-h@ 67[:Kxgy{+[n]ji->萮.y/LwP$>]K - {]U^w]<Ѻu"kާI Vݷa@ 7A|=AϽ(Ç7omfGQ>E.O|e&M|#6^O6@@ :X|*:}%H'GZJ~{U8p}`+۷: - @aP@"ZGWN@@=*ϟoKC"  GDD@ h}cMOo B@GB<_~@)a{}S]u@ @SMb@O {ca5"?}Zjk@Li5%Pts̩Y#. eɒ%h"d25\A@U_vrGN>*`|%{Yq.R?~L0n?ZuPik(Ack.D} NQ_OdϾ '' ,ZO>Y*=GME<>Y})!@MJ:fB ܹsryD~믿^>я5QO?M }D޿:%8Q l@r0P69}IK H hpws\Q؎\tE6ǽ H$4ic^THۋq@<੏G?a%RO`$ {kR=>L^j͛#o/B&v`] >|Xv)ﷵ!E[Vk䫯껱*IgYl̚5~?hNs~ҤIF!r `  'B~ڵ6\Cc]o{+z<_^|2n8+pouSN[ni=,-}l!)Huƴ{q*М7PgmJ/~ ;VőcNJK.$z ˖-;u@ؗ!@.p9i4fʕV;|ژxoa={6 /b~̘1 Uիz.}H %OhҬ S/+֑YE5ϟR?t*5.bf gfYpaUQv WGO;vo\HQ#L iY5K׭&7]ebk 2pƍ an*w a_7:.@j SnܹsmbBJoU4S:Uz H @d,7:}>2]!C[ /^,6lhj.^"AFO}5:K$ɓ'[/$A *M&<"5:(3=اi)!z\;O=L>zbg<džN)ٳ'66cht ^iؠ%A(GQ_ K`޽`ĶE.`k׮%&ҁXw%C 0Rp 4Ggggz L& &@ F'M4  qW  } ~PaI=c̆ %>HD}ոzf,ii$r}bA)qqh,f6B("^gϞm=:>O!@ nNBq1H̆O>@@VXaD؇M = Aj&!hDw/k%ÇΝ;e֌Ǐ~H"V` pa:ed֬YEyz %6r~ wk$ G-ge+uuбL\/ T!8*Uȯ]bteQMi{N߶mׯ[n%Lh}Q{d<,VB]'N(8\tqaMS^{:[&E˻ |&/{v/x6I HQ?K,T- Pq*l½S 4T$gYreꅽ a'ޟ~iuc*Ub0FA~CIcad޼yơ]@{BPD?*G%W^}~C&Uﰊwݪ]=*p'NhU̧!EۯN&e+ q[.ʆ,d'@^zY5?˗/5k… kL(G ^wUݻ׆QN\~G(3+'}Y`~GDQ֦ -U  W:EƍPbuH:^i׮]mq*F]y]`l 胑}p {4n/x6IoQ?w\*WM: h|}gg:t?u#{1֥q{GB^E NmZR5C@^'}RηzkfZD}{"২{LvQ d@tqƉJ@34B7o i&y衇xdfn:uoFoWpUV`caSOИV 9W$4K@:SW)ot}P!}=:Ygv;pvZ?5QJTAE:@ h Ƹ ( {}Ё з*3t[R X:x1鬘o$E+[-T@Xm_r7IKߪt$W'g&~#AO*U\ӊ+6}O |ui[ٳgU8}+Oo()(MiֶUxY&a.S[qz׭[cC,{ ~~5_l9w`Mc^gv҇ b#~T1O&L_J.NEHS @ >P} Lz$J+|Ϙ @&w}ٺm۶" lݺB)a4 H0. ~,ԳR ӏ&bٲev= ^Rd2M4;s~*rD+nj;5/1W9z@ڵk*U ҤgQ?އ;R:x[現[R͆7O ,aǎamܸcJ^stD}hVI#Rtɒ%V%+? ˖-;@q&a{;ﾻ&::SogtjT׏b h1 q3PرQ[:y}TSOŭ !Ǐ3jABWWTG@Soj'EhL/_jzY:"l!^V}5fVl$iT 3UU޿NT~R, jiO]8+\?sl%7_?>~84lB= ^S1B Z:7轤Q6HW+UUqCɞ={-~ʩL@?c^Em6L̻6p8SKDW9EgА 'vvvvʡCv 6e!kշNía@Gŋ˂ (<ވw^;㚆_zJ檥Z?~UƎ7DcI.>n8 7ee-շSRI|6WqO?pBStC~\OQ_?31~|*g֋T7]شig*E\̋8?}:IŽRT_wu6TDn(ݪyYf*McrpL8`~Qꀰ}%8M41aވ Nk7*TO W:CY&*n$3$eWѮ G^n{ kDǏrHMf`7I$E`ʕVDj`#ޏё℮ |2SNmUN2%QjK^z%;@GۢmRFLζ:D}u>M~|(I#04'"oz' ~hF;L[ԫ_}Gz]ro9ݪ8qPC‡\^I.E]TIJӪ~lUX/>MǏrf̘a$^ &믿d5R {?~GBcZӎ8c=c^D}{ &׏Ri^6 cC{66 4"'C@*P .@IDAT h\'iD]A%}c ` J TPa:~WA `~ WJ(^QeD3fE[;%&e2;ےN}v`JKR\ 5QFic]pE7mkܼ wTꝟ7o8qŠ}=dHAmN'#X~|(Ǐ2@vaٹsg x:uG.0lٲB|= P@ +@-BLE@? ?_v]FSϚ&O* sbm69uꔬ_^nT2эH=+WSH]e1S]k G9~M]}ɒ%V̫@sX?ʦdPQ*Ҷl½uQ a)+~N#X~|(Ǐ2E6-S1<͖#իWsjq~j[ctnN_` B%BL;v*U1:x.\F"@'>yˣG9~( АB&%u׹7n r8VDE)cS|Q+N :/X^~eJ3#Gaܹ6TB=$I@;;;СCM;.ʊVFF|-w,>rNsYn>wApmׁ֋/ 6W %C0x!@ hhjP?<~H_jEUaO@4 gڴi3Y2OU'Џ< , z5< I熞>}:>7@H;v}p޳gOH5R   RE@UڵkWm޽{eCC iT  P N%Nj Hci,Ocχf~#A@8pаuIOOOD, $L,}Zhʶ^P0㉍[ )x+]X ҷ#\swV~* S4r$:뭸2erGmG* 3eg*;$]c{tgdsae-譃;6-ii @@1?bF;z]vd q9y5rMwI`tgf̡wo4 @@_OF]rzUwdd@g<_F$Umiب W>T@ԧi, @J@\g6Q/j8Nkyس՟%]C3__0ӼU/3ov+bz4@@W=}tWr  @,2Kdp(6Z n+l9\I2}ޗ1/zF6&AmX~Srp[BJ[Lͼbl T6mLkM?V(?a-nxeӏ&<#<P12g8@'95&>H @ "OPgҔ,ZHv^@ NA$;yd9yFR+[Qg#l&ߒяA#(K?˻Zmx*P!n:驐 @ <xcMM #3fȁdҤIuލVY7.H te kҏ#X!h8[eY|9sWGv.vunFJ}LnG! =cmEl@&}wԩ.$7 D}S8̙#z\25(,"-M1)fˋ_fɮJez[%ݺN_UM0ׯ~L}r~pzĤ03CZb+VyE=V{. |WJG>[o$]݈Vٳ;v͛ k2M@bСCO[qsΰ͠>>u]N j*6ѹsʆ "EeFeI}KMLYAnoX^'YZoiQW-Y>1*{@Iq7@ ̊nA''NiӦڵk婧_CX#7(KƟn5 lOAu{K`?_oϘ+= u/p:g=zO /o #Wz})"zߓA|Jy?tMlfxza>̌Q]T79m;2**;}iOIT;ﴞ{R]g+#sx3&(DrC;zEtuƳ\vvt{31C_]ڶ7̞ⶎhİ ؞!dkҷP&\Gk>v-P q.ؖH}xb5k P>ŝO! &$kgőTM=XK&̢0SH㉠7KW{V2fut xwn3fjFRIlPf+ cAEug̔3C,xC`7gC+ pEgŸ|᭪dMa8LX'_uR?C6jƍbc̆@<X 0m'+<Z$+SLײR9:edu9+ԷwKf+ 35 qL3ҡgHt;`o%|-SP!n:1T @hfq-$3f5u6 S?J;~SPo-[dɜ>}J!@ ouꄀ9s[o+Wz @j'9!+VȼyD  @ OfҪp+ivmrw b}GJUpU)3%6ӋxX}ĉ2m4YvЯN:U!@H<)l/Ν;UՄ}C!x–?ctQE{O/^,;vZ~|kD&p2p$c#7 ,@ԋi&ѣUCtj. Ė>]i&{ާm >w?x`av :ulذ!vm`@!@L?)={twwXzxaYd8p@&MTbN@Go>L`QT1:>:}%zǏo7Y{}@RBO}J:fƟ4;c ٽ{;_jos|&?џctQT%cO>-7n,+1UO]D*J1E/,#J?F N_` иyN;vl5J $)-Jz=$OJ&Hdt&~SN@C @ YOZtKBs"$ @ 6@ctǏ7v1WAzF p L-D}$!F S4D}:S 4E)/!m6Yl @ $~h@u@N*7p1Ki>Gz꩔>S hQ[>)'ЈD3f̐ΆCT\R:&uK,[oU/^VƧixWX _~˖-|r(x H{y`Ba,8L&S<M@ȍ?AnBG30a3g#A/*ήZ[*rN z-Hxk<}w=ehTBZOHG K`Ŋ2oLG"G^hr"(_ P3[4w\ٹsgj54n8};Lԗ!ą@#1mիWm&wygiC*[ځx諒Htk-5~"N{$b׿n7ëj&!=~zm1LjLAJ_?E?CCЂJD} KԻvL_ڵK3C@9:&CZp!r8 =zGdӦMQ9u:ꋡ *DoYf cLjtfBE}:8o:bhǎn ֧: N@q%5G@߼[{ѣGo%9Q  }b9{l;Zc`5 5KrT+7G:=u]WO]E}ޤKoII%oa9QMP. sKq,SH@E }n_^UWϾiJ*5Fѱ/>񐟬;Q5)#OY\L;vL.b,Gu$k, <:P\57X*tRϻϳ>k'=Pb^k&n}ڬf r=ZHQBZnܴ>?*8`ÈO@SPq/R(Ul]zKq~ uzu넺9sPߵ g>L2ڧn@ԧiq8&lذ`o>[>Yv=~zj$z]ro9ݪ\&*Ľ u=aCew #!#^#15@1c޽ IC D}HA ʧPOיn\*OJ=.[@/Q5!@ h,}e GO}x (^&I"F@JO}U< @@ GX@ Up @'~a! @@WI@ D>} @JQ_'!@ }B @*D}U< @@ GX@ Up @'~a! @@WI@ D>}6mT w  d@'iE <#裏VmÇjNB <m&%Y#S;&cǎ lkk?sm&+VHȱ-ݶ=zMQzojҭۯ C@Fמ@+ ̚5K.\(s_~)[na7ah:B^?O/>)tT85SNɌ32}t+Txj idݢ'ջyNٟ˂o^=~E2ҙ-xp/ʅ^(\p>B@ MOSo4itww[o1GxbJϟgoaK8Ÿ~]sq KyR'j*A;wu?~=tPu'Ϝ1n?1N->˘1c zc|a: iHwA`8${k׮u։zI'[oPO= %@M|)Pפzޓ'bUGEwR\2&A@pǖ!(ٳ΄㦸 „ONBWA+˹oŚ@P}|xm.)-{ Do()(teGꫯ}% .6:;d\r[d{>~Ld· iO PD}mcNݑ޾l[R1>܉PMRyxozr ѸoȻ] + ]GxafD} 0DQ?Ăp^=Ĝ+'MmI>Vur?4FE~Ǝ(7MKh\i!v$qS< T%@٪x8N'Rt"msL yUԫ^ }ӱqlꗇAk׾*2xiZ+_#A@xᱦpybiR~ڥ: b;Is}Ov?Wrզ{7$@Hoэ4''1⺳RS"{\TG=91{'?ܚB^m~/ʿ9/O?Mj߲n)k2aܯzuǟ~R>rײsk䢱;@PSQ8a<ڧ*.=wm9ڠ69wfK䊫ʻ>_\?sX O=r[*׿1wGX^8ke^H <|иפ$wc|z]=,sTm&~'}Ư1s[}w[w- KQ.oj jx_rTS*tg2z1?T;O}݊6$74T1If JK%/Ez^QVՉ6zoL ?V{gUqoWG d @ǥ"l^0|>Y&!'Ia>Ê`qswog/?h/>(w/T:A$@ 5L$H /_~ӽGRͬso6>s:Bmmmy3h @ǧ 'TkJ>B SM {헧d;EE@[_ۍ /qȩ"3ېQNO'_M5O,φJ"@/*W z;}^'*b[[DFЛps|?L%׷~J/ EIFKEo1VBfKoNWqVݶllW7a7x>mio=cz蛲6¾]B@J Sqlz\ TDZUѰ篝Η㴼ۖWPsfЧKo11by6cc >@ 8A… <1ca:9\80 _zRF?ɘ3˨_ț?a6ĺQeԯL؄-?|Tl' ć>>}zKss)-X+}w[w<.[+MXț?\M&m,{2'Fk22by3w;_1^ENka? EQii@AoMqUMmUrǽy"g ..c~?eW7h("Ai OC/'NiK56䦔ۆlRM̙3r1N6]r @i. G86[3or1v[k 4<)0 ȥ;fn[ =>eNsB 2U@P:+ƅl~!sl)zO @>P$tK-XeBh쨈ϛ yk~o3K~siy_Q }˥l%ñM`snI pV |) 3ϡH2kW)ZH8]28𢴽ʒM[Q_a.wsJJ+ GQ[JB ^lt1Q`QF]UR敎FL@Xd$Xya-1v[(쫠׏[LE}0(iuvn AHD}B qi+s;YٕWx.yW$@h D}kS>@Qk%OY;oec=#븹3}w[wܳ?\v!$>ݚFYJ+Tx-;^%m91XٕWxFQMSsc鶮dmHox#mwSvU:nl(t"6@i%Ok'ݱRX3}w[w}w1-^z +ǯqݜwo" L Fߤf!ys>UWtW#Kh=. 1/<gKM~ce+ zqǫב+]cuxkp_120EeȥaҀ2ynAڮ*dLIO}TN}6#VuBu4[@SC\ \=xLlϔ{bH6}KyO9_Շ5暬|uyWaO.GwȲ=r6LȲۏȧ7U/-Tg;LWo͍y 옺UejSvW:% @S_?3rNFYtKִ90/ʍ%y6;+|<ϵˍ e0ۻ iwˍqLf eHK.-=澏tNG+3&5_7ӈ;3=Q|8~෇QZ:79+W;M2knK>  2uB S[5pX9c.WϬsiXvpghvyaw.06ͫg xޝV\G|^f:AqkʫtY*˺;k>{~/K}5#Ҧa߱^kod=?7<s\zn^G wٖ᭯|o_67nvr͟g@a & KpE!/W+LͷYdwVn3 /Pg"*"jRÔH9:vbˊk%\u̔~Jϝ̚w4ytu J 9!=_Usd2 dIפyP]:֘DI(~[\=JMζ6o@e(ɥo#GSj<$@`Rz9hXF߼MveZ\\_-ie17K0oU7˻_oWp-d_+LFQ%p\YzγߵO}w[ ~׈ҷx-}O3P?]z92pQ(V"r*|&^$Ǒ̐Bλf-kW+KYIN^ B^ 9duP8e}?H'Ccň!H,켿sfHYsNnzj##R*X, fO* @DB}DLJWre[ťV+ߍdxw@>vǙnRw.i׷աzW.y\[k!Zv|?r{dKߺs[zߍzۅr{{:F!OG% ?i,/$;$%؇i{cb(211!~Ȉ'% @w~WjMAbe#]A罖BW&ɅKp"u|ߒw~{[~Rk۷yګʽ;vSol[~iӪC8CMyKw֥ \1ZiyԐ:R#̫op/ -F%K]L?L-+ C'37ޕz >=N_s,]7ZΟ\Ο6˽~l[F?qujg)9+x}NEgi{PďM/jҖ  @]@ʔ.`R:Şi,u+m{˝>ꐍzGN!@ivRjv7ޏ?{x>8Si.Rj=]卯/xrO vzD'@-5wY]r}]}fV@omL۽ ;m}|ieXג @ti--YZi5ۺ=e7neg:moN;$Guԋ Y3٣G;駇'һ[s?s^=ugWڽ :mw/e?ަ\Ep ` ߹jX ɤ46v.7:Zols0@R ԧL`@6kX|z?LuhBEn[ɗb/@! @B}D^ʙW#v[i3]ib;%b ԤT#1rl*$/"gͳRv~/2B.@`p\)">2 }\-IN/  D GĤt ({ZX3RZ^|x=lY7A]rRcɍۨ|}ֳyQ 0羼J?5/,2K+3x!?77 da]8ڜ~UPv znHmE?0yzo7e:!`C̩"@_ [.kOJ"}}͇w?Nz23SO]fB]""2uUfj+n~Dr]ˈᩩoچCz@P)h7~O'`Vnrr4NŢn&P̜pt>9گRI ~t^^Gw!>{ tCP ULE 1J܈z&Mu]LLL gF-iDO^D?wZkk&^zO@_PV1[i rYT 0]K :bkkqQ3s]ϓCWkF>itrCAP5 E k:FG굴@5YN;;}4UP^*SFJr4Rvs'V@gSug}Y@NP?p]?̀l4K+f[pT> r{ee-Wvp./?l7 td7Ny dKPl@K_Pvm#Ҫ!i/EB9IL7F*R[G[ROɣd ;dwvF'_j> }ոyu;:^׵혈2BT]~nUk_Cy{Zhe2_F5J}oM[.Я5y2ʛ3{?}rn]k6J?~!g;Co=NJBU~әoycKj\]j{rR^¡|𧽺ƒ\Coߔk/Ю!\mTݶYa-kڲ4+@!;F /[ +.nlM9e~\d8/2?|E?i9= n\)YX(5]D9FGRZr#r#K4,~ˇm gNp-[o޺B{-۟@ gA`F*G.My!;2?Qъ xMq&05» h>UDÍj(c;Ҳ)5h<{[->!}I9,0o!^,|Z[ymw<@!@F?p+kh{8Q {r{*37\\>ߚAeG[Crkm 750궞~dQ;!k}wT]j\?x"17eyXhy ^<䈼i> ϖj ~p4r~!|$=\/>=5p7F5ZCpW=-exm ]Ig2~,C*L?gJ~bZrŒ}ٻn;!G2<yU6ޖhw5ćAF_/L@@&AswO>O?$#7kR/Fȹ=+-[aXk/Y&;:'꺞^᥯ޞ/IT yaLڑ %z Rwo )xW}ԏ]wЪmky~&y/pjޟ՘{ZZԂ>M] @'uڃdTWy$ˮ2+|Xf {[ O Z&|.]i{O/-:MNNJZ^G7dխ=5m>*K˴L^2T %+\N.lMRYwt^ vs R\IVPK[o䓣OIK@ zR[=G_@Mk=7!ܜa> 5$F ~4*z4IDATէ}5١ё}}䗟nc?,JC?PLy= x'`fנMYfYE@\BDUg# ?^GoMv,1Uky 0¼v!zW:Ziia^C|#7}nAF`ߪpk¹YXj ajYc@.&@Ge@t`5g:c" SytF䷾*gF-ki3,[ϳ؂u^Cl!J{M0kpo[KkO۲PoJۮعٱZէ<@!@H X0z4"?׏e~zJ&˲~uTJ<†4o{0{mT^}8kge˝KK w+= 򶏕ZҺ0rcezن @ ?bq6}L&WdyTVGeHŅY)OLɵqSW9诺nmu?"AƜn-]wTǻ+6[ҖDp{pel]lC@nRgt [:Ҫ_ޖ5ܔ]H+}pT!YJeBNrqX1)M]/Qa) 5nnn;ؕJEmɢDMnLhy}(y[0\yMf,tUSx=<󶅯 @h ;;;틑Z#u}nWDv*9Y;Q5''E9yYO2? ƅ5 suڌtG#6׺Ԍm@@/1W"`5ȇ-Zi^˺.$ GbuF-[OzאΓ^+mJ@@ r|&Vjpק[V:zoEh𶧆r v 6ƦՄ#6*u¬# @LB}LMJExXT--[i-[CK av ܭA>  @BPa@g}]ou0[HmapVX=  @Zi' -8-!]m2  >Mmں2 Nkapm(@@ _<"  I{*@@H_P9-"  UP@@H_P9-"  UP@@H_P9-"  UP@@H_P9-"  UP@@H_P9-"  UP@@H_P9-"  UP@@H_P9-"  UP@@H_P9-"  UP@@H_P9-"  UP@@H_P9-"  UP@@H_P9-"  UP@@H_P9-"  UP@@H_P9-"  UP@@H_P9-"  UP@@H_P9-"  UP@@H_P9-"  UP@@H_P9-"  UP@@H_P9-"  UP@@H_P9-"  UP@@H_P9-"  UP@@H_P9-"  UP@@H_P9-"  UP@@H_P9-"  UP@@H_P9-"  UP@@H_P9-"  UP@@H_P9-"  U~`jZIENDB`ironic-10.1.1/doc/source/user/0000775000175100017510000000000013243617733016135 5ustar zuulzuul00000000000000ironic-10.1.1/doc/source/user/index.rst0000666000175100017510000004747713243617463020023 0ustar zuulzuul00000000000000.. _user-guide: ============================= Bare Metal Service User Guide ============================= Ironic is an OpenStack project which provisions bare metal (as opposed to virtual) machines. It may be used independently or as part of an OpenStack Cloud, and integrates with the OpenStack Identity (keystone), Compute (nova), Network (neutron), Image (glance) and Object (swift) services. When the Bare Metal service is appropriately configured with the Compute and Network services, it is possible to provision both virtual and physical machines through the Compute service's API. However, the set of instance actions is limited, arising from the different characteristics of physical servers and switch hardware. For example, live migration can not be performed on a bare metal instance. The community maintains reference drivers that leverage open-source technologies (eg. PXE and IPMI) to cover a wide range of hardware. Ironic's pluggable driver architecture also allows hardware vendors to write and contribute drivers that may improve performance or add functionality not provided by the community drivers. .. TODO: the remainder of this file needs to be cleaned up still Why Provision Bare Metal ======================== Here are a few use-cases for bare metal (physical server) provisioning in cloud; there are doubtless many more interesting ones: - High-performance computing clusters - Computing tasks that require access to hardware devices which can't be virtualized - Database hosting (some databases run poorly in a hypervisor) - Single tenant, dedicated hardware for performance, security, dependability and other regulatory requirements - Or, rapidly deploying a cloud infrastructure Conceptual Architecture ======================= The following diagram shows the relationships and how all services come into play during the provisioning of a physical server. (Note that Ceilometer and Swift can be used with Ironic, but are missing from this diagram.) .. figure:: ../images/conceptual_architecture.png :alt: ConceptualArchitecture Logical Architecture ==================== The diagram below shows the logical architecture. It shows the basic components that form the Ironic service, the relation of Ironic service with other OpenStack services and the logical flow of a boot instance request resulting in the provisioning of a physical server. .. figure:: ../images/logical_architecture.png :alt: Logical Architecture The Ironic service is composed of the following components: #. a RESTful API service, by which operators and other services may interact with the managed bare metal servers. #. a Conductor service, which does the bulk of the work. Functionality is exposed via the API service. The Conductor and API services communicate via RPC. #. various Drivers that support heterogeneous hardware #. a Message Queue #. a Database for storing information about the resources. Among other things, this includes the state of the conductors, nodes (physical servers), and drivers. As in Figure 1.2. Logical Architecture, a user request to boot an instance is passed to the Nova Compute service via Nova API and Nova Scheduler. The Compute service hands over this request to the Ironic service, where the request passes from the Ironic API, to the Conductor, to a Driver to successfully provision a physical server for the user. Just as the Nova Compute service talks to various OpenStack services like Glance, Neutron, Swift etc to provision a virtual machine instance, here the Ironic service talks to the same OpenStack services for image, network and other resource needs to provision a bare metal instance. Key Technologies for Bare Metal Hosting ======================================= Preboot Execution Environment (PXE) ----------------------------------- PXE is part of the Wired for Management (WfM) specification developed by Intel and Microsoft. The PXE enables system's BIOS and network interface card (NIC) to bootstrap a computer from the network in place of a disk. Bootstrapping is the process by which a system loads the OS into local memory so that it can be executed by the processor. This capability of allowing a system to boot over a network simplifies server deployment and server management for administrators. Dynamic Host Configuration Protocol (DHCP) ------------------------------------------ DHCP is a standardized networking protocol used on Internet Protocol (IP) networks for dynamically distributing network configuration parameters, such as IP addresses for interfaces and services. Using PXE, the BIOS uses DHCP to obtain an IP address for the network interface and to locate the server that stores the network bootstrap program (NBP). Network Bootstrap Program (NBP) ------------------------------- NBP is equivalent to GRUB (GRand Unified Bootloader) or LILO (LInux LOader) - loaders which are traditionally used in local booting. Like the boot program in a hard drive environment, the NBP is responsible for loading the OS kernel into memory so that the OS can be bootstrapped over a network. Trivial File Transfer Protocol (TFTP) ------------------------------------- TFTP is a simple file transfer protocol that is generally used for automated transfer of configuration or boot files between machines in a local environment. In a PXE environment, TFTP is used to download NBP over the network using information from the DHCP server. Intelligent Platform Management Interface (IPMI) ------------------------------------------------ IPMI is a standardized computer system interface used by system administrators for out-of-band management of computer systems and monitoring of their operation. It is a method to manage systems that may be unresponsive or powered off by using only a network connection to the hardware rather than to an operating system. Ironic Deployment Architecture ============================== The Ironic RESTful API service is used to enroll hardware that Ironic will manage. A cloud administrator usually registers the hardware, specifying their attributes such as MAC addresses and IPMI credentials. There can be multiple instances of the API service. The Ironic conductor service does the bulk of the work. For security reasons, it is advisable to place the conductor service on an isolated host, since it is the only service that requires access to both the data plane and IPMI control plane. There can be multiple instances of the conductor service to support various class of drivers and also to manage fail over. Instances of the conductor service should be on separate nodes. Each conductor can itself run many drivers to operate heterogeneous hardware. This is depicted in the following figure. The API exposes a list of supported drivers and the names of conductor hosts servicing them. .. figure:: ../images/deployment_architecture_2.png :alt: Deployment Architecture 2 Understanding Bare Metal Deployment =================================== What happens when a boot instance request comes in? The below diagram walks through the steps involved during the provisioning of a bare metal instance. These pre-requisites must be met before the deployment process: * Dependent packages to be configured on the Bare Metal service node(s) where ironic-conductor is running like tftp-server, ipmi, syslinux etc for bare metal provisioning. * Nova must be configured to make use of the bare metal service endpoint and compute driver should be configured to use ironic driver on the Nova compute node(s). * Flavors to be created for the available hardware. Nova must know the flavor to boot from. * Images to be made available in Glance. Listed below are some image types required for successful bare metal deployment: - bm-deploy-kernel - bm-deploy-ramdisk - user-image - user-image-vmlinuz - user-image-initrd * Hardware to be enrolled via Ironic RESTful API service. Deploy Process -------------- This describes a typical ironic node deployment using PXE and the Ironic Python Agent (IPA). Depending on the ironic driver interfaces used, some of the steps might be marginally different, however the majority of them will remain the same. #. A boot instance request comes in via the Nova API, through the message queue to the Nova scheduler. #. Nova scheduler applies filters and finds the eligible hypervisor. The nova scheduler also uses the flavor's ``extra_specs``, such as ``cpu_arch``, to match the target physical node. #. Nova compute manager claims the resources of the selected hypervisor. #. Nova compute manager creates (unbound) tenant virtual interfaces (VIFs) in the Networking service according to the network interfaces requested in the nova boot request. A caveat here is, the MACs of the ports are going to be randomly generated, and will be updated when the VIF is attached to some node to correspond to the node network interface card's (or bond's) MAC. #. A spawn task is created by the nova compute which contains all the information such as which image to boot from etc. It invokes the ``driver.spawn`` from the virt layer of Nova compute. During the spawn process, the virt driver does the following: #. Updates the target ironic node with the information about deploy image, instance UUID, requested capabilities and various flavor properties. #. Validates node's power and deploy interfaces, by calling the ironic API. #. Attaches the previously created VIFs to the node. Each neutron port can be attached to any ironic port or port group, with port groups having higher priority than ports. On ironic side, this work is done by the network interface. Attachment here means saving the VIF identifier into ironic port or port group and updating VIF MAC to match the port's or port group's MAC, as described in bullet point 4. #. Generates config drive, if requested. #. Nova's ironic virt driver issues a deploy request via the Ironic API to the Ironic conductor servicing the bare metal node. #. Virtual interfaces are plugged in and Neutron API updates DHCP port to set PXE/TFTP options. In case of using ``neutron`` network interface, ironic creates separate provisioning ports in the Networking service, while in case of ``flat`` network interface, the ports created by nova are used both for provisioning and for deployed instance networking. #. The ironic node's boot interface prepares (i)PXE configuration and caches deploy kernel and ramdisk. #. The ironic node's management interface issues commands to enable network boot of a node. #. The ironic node's deploy interface caches the instance image (in case of ``iscsi`` deploy interface or most ``pxe_*`` classic drivers), and kernel and ramdisk if needed (it is needed in case of netboot for example). #. The ironic node's power interface instructs the node to power on. #. The node boots the deploy ramdisk. #. Depending on the exact driver used, either the conductor copies the image over iSCSI to the physical node (:ref:`iscsi-deploy`) or the deploy ramdisk downloads the image from a temporary URL (:ref:`direct-deploy`). The temporary URL can be generated by Swift API-compatible object stores, for example Swift itself or RadosGW. The image deployment is done. #. The node's boot interface switches pxe config to refer to instance images (or, in case of local boot, sets boot device to disk), and asks the ramdisk agent to soft power off the node. If the soft power off by the ramdisk agent fails, the bare metal node is powered off via IPMI/BMC call. #. The deploy interface triggers the network interface to remove provisioning ports if they were created, and binds the tenant ports to the node if not already bound. Then the node is powered on. .. note:: There are 2 power cycles during bare metal deployment; the first time the node is powered-on when ramdisk is booted, the second time after the image is deployed. #. The bare metal node's provisioning state is updated to ``active``. Below is the diagram that describes the above process. .. graphviz:: digraph "Deployment Steps" { node [shape=box, style=rounded, fontsize=10]; edge [fontsize=10]; /* cylinder shape works only in graphviz 2.39+ */ { rank=same; node [shape=cylinder]; "Nova DB"; "Ironic DB"; } { rank=same; "Nova API"; "Ironic API"; } { rank=same; "Nova Message Queue"; "Ironic Message Queue"; } { rank=same; "Ironic Conductor"; "TFTP Server"; } { rank=same; "Deploy Interface"; "Boot Interface"; "Power Interface"; "Management Interface"; } { rank=same; "Glance"; "Neutron"; } "Bare Metal Nodes" [shape=box3d]; "Nova API" -> "Nova Message Queue" [label=" 1"]; "Nova Message Queue" -> "Nova Conductor" [dir=both]; "Nova Message Queue" -> "Nova Scheduler" [label=" 2"]; "Nova Conductor" -> "Nova DB" [dir=both, label=" 3"]; "Nova Message Queue" -> "Nova Compute" [dir=both]; "Nova Compute" -> "Neutron" [label=" 4"]; "Nova Compute" -> "Nova Ironic Virt Driver" [label=5]; "Nova Ironic Virt Driver" -> "Ironic API" [label=6]; "Ironic API" -> "Ironic Message Queue"; "Ironic Message Queue" -> "Ironic Conductor" [dir=both]; "Ironic API" -> "Ironic DB" [dir=both]; "Ironic Conductor" -> "Ironic DB" [dir=both, label=16]; "Ironic Conductor" -> "Boot Interface" [label="8, 14"]; "Ironic Conductor" -> "Management Interface" [label=" 9"]; "Ironic Conductor" -> "Deploy Interface" [label=10]; "Deploy Interface" -> "Network Interface" [label="7, 15"]; "Ironic Conductor" -> "Power Interface" [label=11]; "Ironic Conductor" -> "Glance"; "Network Interface" -> "Neutron"; "Power Interface" -> "Bare Metal Nodes"; "Management Interface" -> "Bare Metal Nodes"; "TFTP Server" -> "Bare Metal Nodes" [label=12]; "Ironic Conductor" -> "Bare Metal Nodes" [style=dotted, label=13]; "Boot Interface" -> "TFTP Server"; } The following two examples describe what ironic is doing in more detail, leaving out the actions performed by nova and some of the more advanced options. .. _iscsi-deploy-example: Example 1: PXE Boot and iSCSI Deploy Process -------------------------------------------- This process is how :ref:`iscsi-deploy` works. .. seqdiag:: :scale: 75 :alt: pxe_ipmi diagram { Nova; API; Conductor; Neutron; HTTPStore; "TFTP/HTTPd"; Node; activation = none; span_height = 1; edge_length = 250; default_note_color = white; default_fontsize = 14; Nova -> API [label = "Set instance_info\n(image_source,\nroot_gb, etc.)"]; Nova -> API [label = "Validate power and deploy\ninterfaces"]; Nova -> API [label = "Plug VIFs to the node"]; Nova -> API [label = "Set provision_state,\noptionally pass configdrive"]; API -> Conductor [label = "do_node_deploy()"]; Conductor -> Conductor [label = "Validate power and deploy interfaces"]; Conductor -> HTTPStore [label = "Store configdrive if configdrive_use_swift \noption is set"]; Conductor -> Node [label = "POWER OFF"]; Conductor -> Neutron [label = "Attach provisioning network to port(s)"]; Conductor -> Neutron [label = "Update DHCP boot options"]; Conductor -> Conductor [label = "Prepare PXE\nenvironment for\ndeployment"]; Conductor -> Node [label = "Set PXE boot device \nthrough the BMC"]; Conductor -> Conductor [label = "Cache deploy\nkernel, ramdisk,\ninstance images"]; Conductor -> Node [label = "REBOOT"]; Node -> Neutron [label = "DHCP request"]; Neutron -> Node [label = "next-server = Conductor"]; Node -> Node [label = "Runs agent\nramdisk"]; Node -> API [label = "lookup()"]; API -> Node [label = "Pass UUID"]; Node -> API [label = "Heartbeat (UUID)"]; API -> Conductor [label = "Heartbeat"]; Conductor -> Node [label = "Send IPA a command to expose disks via iSCSI"]; Conductor -> Node [label = "iSCSI attach"]; Conductor -> Node [label = "Copies user image and configdrive, if present"]; Conductor -> Node [label = "iSCSI detach"]; Conductor -> Conductor [label = "Delete instance\nimage from cache"]; Conductor -> Node [label = "Install boot loader, if requested"]; Conductor -> Neutron [label = "Update DHCP boot options"]; Conductor -> Conductor [label = "Prepare PXE\nenvironment for\ninstance image"]; Conductor -> Node [label = "Set boot device either to PXE or to disk"]; Conductor -> Node [label = "Collect ramdisk logs"]; Conductor -> Node [label = "POWER OFF"]; Conductor -> Neutron [label = "Detach provisioning network\nfrom port(s)"]; Conductor -> Neutron [label = "Bind tenant port"]; Conductor -> Node [label = "POWER ON"]; Conductor -> Conductor [label = "Mark node as\nACTIVE"]; } (From a `talk`_ and `slides`_) .. _direct-deploy-example: Example 2: PXE Boot and Direct Deploy Process --------------------------------------------- This process is how :ref:`direct-deploy` works. .. seqdiag:: :scale: 75 :alt: pxe_ipmi_agent diagram { Nova; API; Conductor; Neutron; HTTPStore; "TFTP/HTTPd"; Node; activation = none; edge_length = 250; span_height = 1; default_note_color = white; default_fontsize = 14; Nova -> API [label = "Set instance_info\n(image_source,\nroot_gb, etc.)"]; Nova -> API [label = "Validate power and deploy\ninterfaces"]; Nova -> API [label = "Plug VIFs to the node"]; Nova -> API [label = "Set provision_state,\noptionally pass configdrive"]; API -> Conductor [label = "do_node_deploy()"]; Conductor -> Conductor [label = "Validate power and deploy interfaces"]; Conductor -> HTTPStore [label = "Store configdrive if configdrive_use_swift \noption is set"]; Conductor -> Node [label = "POWER OFF"]; Conductor -> Neutron [label = "Attach provisioning network to port(s)"]; Conductor -> Neutron [label = "Update DHCP boot options"]; Conductor -> Conductor [label = "Prepare PXE\nenvironment for\ndeployment"]; Conductor -> Node [label = "Set PXE boot device \nthrough the BMC"]; Conductor -> Conductor [label = "Cache deploy\nand instance\nkernel and ramdisk"]; Conductor -> Node [label = "REBOOT"]; Node -> Neutron [label = "DHCP request"]; Neutron -> Node [label = "next-server = Conductor"]; Node -> Node [label = "Runs agent\nramdisk"]; Node -> API [label = "lookup()"]; API -> Node [label = "Pass UUID"]; Node -> API [label = "Heartbeat (UUID)"]; API -> Conductor [label = "Heartbeat"]; Conductor -> Node [label = "Continue deploy asynchronously: Pass image, disk info"]; Node -> HTTPStore [label = "Downloads image, writes to disk, \nwrites configdrive if present"]; === Heartbeat periodically === Conductor -> Node [label = "Is deploy done?"]; Node -> Conductor [label = "Still working..."]; === ... === Node -> Conductor [label = "Deploy is done"]; Conductor -> Node [label = "Install boot loader, if requested"]; Conductor -> Neutron [label = "Update DHCP boot options"]; Conductor -> Conductor [label = "Prepare PXE\nenvironment for\ninstance image\nif needed"]; Conductor -> Node [label = "Set boot device either to PXE or to disk"]; Conductor -> Node [label = "Collect ramdisk logs"]; Conductor -> Node [label = "POWER OFF"]; Conductor -> Neutron [label = "Detach provisioning network\nfrom port(s)"]; Conductor -> Neutron [label = "Bind tenant port"]; Conductor -> Node [label = "POWER ON"]; Conductor -> Conductor [label = "Mark node as\nACTIVE"]; } (From a `talk`_ and `slides`_) .. _talk: https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/isn-and-039t-it-ironic-the-bare-metal-cloud .. _slides: http://www.slideshare.net/devananda1/isnt-it-ironic-managing-a-bare-metal-cloud-osl-tes-2015 ironic-10.1.1/doc/source/admin/0000775000175100017510000000000013243617733016247 5ustar zuulzuul00000000000000ironic-10.1.1/doc/source/admin/drivers.rst0000666000175100017510000000224513243617463020464 0ustar zuulzuul00000000000000=============================================== Drivers, Hardware Types and Hardware Interfaces =============================================== Generic Interfaces ------------------ .. toctree:: :maxdepth: 2 interfaces/boot interfaces/deploy Hardware Types -------------- .. toctree:: :maxdepth: 1 drivers/cimc drivers/idrac drivers/ilo drivers/ipmitool drivers/irmc drivers/oneview drivers/redfish drivers/snmp drivers/ucs Unsupported drivers ------------------- The following drivers were declared as unsupported in ironic Newton release and as of Ocata release they are removed from ironic: - AMT driver - available as part of ironic-staging-drivers_ - iBoot driver - available as part of ironic-staging-drivers_ - Wake-On-Lan driver - available as part of ironic-staging-drivers_ - Virtualbox drivers - SeaMicro drivers - MSFT OCS drivers The SSH drivers were removed in the Pike release. Similar functionality can be achieved either with VirtualBMC_ or using libvirt drivers from ironic-staging-drivers_. .. _ironic-staging-drivers: http://ironic-staging-drivers.readthedocs.io .. _VirtualBMC: https://git.openstack.org/cgit/openstack/virtualbmc ironic-10.1.1/doc/source/admin/boot-from-volume.rst0000666000175100017510000001157713243617463022227 0ustar zuulzuul00000000000000.. _boot-from-volume: ================ Boot From Volume ================ Overview ======== The Bare Metal service supports booting from a Cinder iSCSI volume as of the Pike release. This guide will primarily deal with this use case, but will be updated as more paths for booting from a volume, such as FCoE, are introduced. Prerequisites ============= Currently booting from a volume requires: - Bare Metal service version 9.0.0 - Bare Metal API microversion 1.33 or later - A driver that utilizes the :doc:`PXE boot mechanism `. Currently booting from a volume is supported by the reference drivers that utilize PXE boot mechanisms when iPXE is enabled. - iPXE is an explicit requirement, as it provides the mechanism that attaches and initiates booting from an iSCSI volume. Conductor Configuration ======================= In ironic.conf, you can specify a list of enabled storage interfaces. Check ``[DEFAULT]enabled_storage_interfaces`` in your ironic.conf to ensure that your desired interface is enabled. For example, to enable the ``cinder`` and ``noop`` storage interfaces:: [DEFAULT] enabled_storage_interfaces = cinder,noop If you want to specify a default storage interface rather than setting the storage interface on a per node basis, set ``[DEFAULT]default_storage_interface`` in ironic.conf. The ``default_storage_interface`` will be used for any node that doesn't have a storage interface defined. Node Configuration ================== Storage Interface ----------------- You will need to specify what storage interface the node will use to handle storage operations. For example, to set the storage interface to ``cinder`` on an existing node:: openstack --os-baremetal-api-version 1.33 baremetal node set \ --storage-interface cinder $NODE_UUID A default storage interface can be specified in ironic.conf. See the `Conductor Configuration`_ section for details. iSCSI Configuration ------------------- In order for a bare metal node to boot from an iSCSI volume, the ``iscsi_boot`` capability for the node must be set to ``True``. For example, if you want to update an existing node to boot from volume:: openstack --os-baremetal-api-version 1.33 baremetal node set \ --property capabilities=iscsi_boot:True $NODE_UUID You will also need to create a volume connector for the node, so the storage interface will know how to communicate with the node for storage operation. In the case of iSCSI, you will need to provide an iSCSI Qualifying Name (IQN) that is unique to your SAN. For example, to create a volume connector for iSCSI:: openstack --os-baremetal-api-version 1.33 baremetal volume connector create \ --node $NODE_UUID --type iqn --connector-id iqn.2017-08.org.openstack.$NODE_UUID Advanced Topics =============== Use without the Compute Service ------------------------------- As discussed in other sections, the Bare Metal service has a concept of a `connector` that is used to represent an interface that is intended to be utilized to attach the remote volume. In addition to the connectors, we have a concept of a `target` that can be defined via the API. While a user of this feature through the Compute service would automatically have a new target record created for them, it is not explicitly required, and can be performed manually. A target record can be created using a command similar to the example below:: openstack --os-baremetal-api-version 1.33 baremetal volume target create \ --node $NODE_UUID --type iscsi --boot-index 0 --volume $VOLUME_UUID .. Note:: A ``boot-index`` value of ``0`` represents the boot volume for a node. As the ``boot-index`` is per-node in sequential order, only one boot volume is permitted for each node. Cinder Multi-attach ------------------- Volume multi-attach is a function that is commonly performed in computing clusters where dedicated storage subsystems are utilized. For some time now, the Block Storage service has supported the concept of multi-attach. However, the Compute service, as of the Pike release, does not yet have support to leverage multi-attach. Concurrently, multi-attach requires the backend volume driver running as part of the Block Storage service to contain support for multi-attach volumes. When support for storage interfaces was added to the Bare Metal service, specifically for the ``cinder`` storage interface, the concept of volume multi-attach was accounted for, however has not been fully tested, and is unlikely to be fully tested until there is Compute service integration as well as volume driver support. The data model for storage of volume targets in the Bare Metal service has no constraints on the same target volume from being utilized. When interacting with the Block Storage service, the Bare Metal service will prevent the use of volumes that are being reported as ``in-use`` if they do not explicitly support multi-attach. ironic-10.1.1/doc/source/admin/upgrade-to-hardware-types.rst0000666000175100017510000002566213243617463024022 0ustar zuulzuul00000000000000Upgrading to Hardware Types =========================== In the future, the Bare Metal service will stop supporting *classic drivers* and will only support *hardware types*. Please see :doc:`/install/enabling-drivers` for the detailed explanation of the difference between these two types of drivers. Planning the upgrade -------------------- It is necessary to figure out which hardware types and hardware interfaces correspond to which classic drivers used in your deployment. The following table lists the classic drivers with their corresponding hardware types and the boot, deploy, inspect, management, and power hardware interfaces: ===================== ==================== ==================== ============== ========== ========== ========= Classic Driver Hardware Type Boot Deploy Inspect Management Power ===================== ==================== ==================== ============== ========== ========== ========= agent_ilo ilo ilo-virtual-media direct ilo ilo ilo agent_ipmitool ipmi pxe direct inspector ipmitool ipmitool agent_ipmitool_socat ipmi pxe direct inspector ipmitool ipmitool agent_irmc irmc irmc-virtual-media direct irmc irmc irmc agent_pxe_oneview oneview pxe oneview-direct oneview oneview oneview agent_ucs cisco-ucs-managed pxe direct inspector ucsm ucsm iscsi_ilo ilo ilo-virtual-media iscsi ilo ilo ilo iscsi_irmc irmc irmc-virtual-media iscsi irmc irmc irmc iscsi_pxe_oneview oneview pxe oneview-iscsi oneview oneview oneview pxe_agent_cimc cisco-ucs-standalone pxe direct inspector cimc cimc pxe_drac idrac pxe iscsi idrac idrac idrac pxe_drac_inspector idrac pxe iscsi inspector idrac idrac pxe_ilo ilo ilo-pxe iscsi ilo ilo ilo pxe_ipmitool ipmi pxe iscsi inspector ipmitool ipmitool pxe_ipmitool_socat ipmi pxe iscsi inspector ipmitool ipmitool pxe_iscsi_cimc cisco-ucs-standalone pxe iscsi inspector cimc cimc pxe_irmc irmc irmc-pxe iscsi irmc irmc irmc pxe_snmp snmp pxe iscsi no-inspect fake snmp pxe_ucs cisco-ucs-managed pxe iscsi inspector ucsm ucsm ===================== ==================== ==================== ============== ========== ========== ========= .. note:: The ``inspector`` *inspect* interface was only used if explicitly enabled in the configuration. Otherwise, ``no-inspect`` was used. .. note:: ``pxe_ipmitool_socat`` and ``agent_ipmitool_socat`` use ``ipmitool-socat`` *console* interface (the default for the ``ipmi`` hardware type), while ``pxe_ipmitool`` and ``agent_ipmitool`` use ``ipmitool-shellinabox``. See Console_ for details. For out-of-tree drivers you may need to reach out to their maintainers or figure out the appropriate interfaces by researching the source code. Configuration ------------- You will need to enable hardware types and interfaces that correspond to your currently enabled classic drivers. For example, if you have the following configuration in your ``ironic.conf``: .. code-block:: ini [DEFAULT] enabled_drivers = pxe_ipmitool,agent_ipmitool You will have to add this configuration as well: .. code-block:: ini [DEFAULT] enabled_hardware_types = ipmi enabled_boot_interfaces = pxe enabled_deploy_interfaces = iscsi,direct enabled_management_interfaces = ipmitool enabled_power_interfaces = ipmitool .. note:: For every interface type there is an option ``default__interface``, where ```` is the interface type name. For example, one can make all nodes use the ``direct`` deploy method by default by setting: .. code-block:: ini [DEFAULT] default_deploy_interface = direct Migrating nodes --------------- After the required items are enabled in the configuration, each node's ``driver`` field has to be updated to a new value. You may need to also set new values for some or all interfaces: .. code-block:: console export OS_BAREMETAL_API_VERSION=1.31 for uuid in $(openstack baremetal node list --driver pxe_ipmitool -f value -c UUID); do openstack baremetal node set $uuid --driver ipmi --deploy-interface iscsi done for uuid in $(openstack baremetal node list --driver agent_ipmitool -f value -c UUID); do openstack baremetal node set $uuid --driver ipmi --deploy-interface direct done See :doc:`/install/enrollment` for more details on setting hardware types and interfaces. .. warning:: It is not recommended to change the interfaces for ``active`` nodes. If absolutely needed, the nodes have to be put in the maintenance mode first: .. code-block:: console openstack baremetal node maintenance set $UUID \ --reason "Changing driver and/or hardware interfaces" # do the update, validate its correctness openstack baremetal node maintenance unset $UUID Other interfaces ---------------- Care has to be taken to migrate from classic drivers using non-default interfaces. This chapter covers a few of the most commonly used. Ironic Inspector ~~~~~~~~~~~~~~~~ Some classic drivers, notably ``pxe_ipmitool``, ``agent_ipmitool`` and ``pxe_drac_inspector``, use ironic-inspector_ for their *inspect* interface. The same functionality is available for all hardware types, but the appropriate ``inspect`` interface has to be enabled in the Bare Metal service configuration file, for example: .. code-block:: ini [DEFAULT] enabled_inspect_interfaces = inspector,no-inspect See :doc:`/install/enabling-drivers` for more details. .. note:: The configuration option ``[inspector]enabled`` does not affect hardware types. Then you can tell your nodes to use this interface, for example: .. code-block:: console export OS_BAREMETAL_API_VERSION=1.31 for uuid in $(openstack baremetal node list --driver ipmi -f value -c UUID); do openstack baremetal node set $uuid --inspect-interface inspector done .. note:: A node configured with the IPMI hardware type, will use the inspector inspection implementation automatically if it is enabled. This is not the case for the most of the vendor drivers. .. _ironic-inspector: https://docs.openstack.org/ironic-inspector/ Console ~~~~~~~ Several classic drivers, notably ``pxe_ipmitool_socat`` and ``agent_ipmitool_socat``, use socat-based serial console implementation. For the ``ipmi`` hardware type it is used by default, if enabled in the configuration file: .. code-block:: ini [DEFAULT] enabled_console_interfaces = ipmitool-socat,no-console If you want to use the ``shellinabox`` implementation instead, it has to be enabled as well: .. code-block:: ini [DEFAULT] enabled_console_interfaces = ipmitool-shellinabox,no-console Then you need to update some or all nodes to use it explicitly. For example, to update all nodes use: .. code-block:: console export OS_BAREMETAL_API_VERSION=1.31 for uuid in $(openstack baremetal node list --driver ipmi -f value -c UUID); do openstack baremetal node set $uuid --console-interface ipmitool-shellinabox done RAID ~~~~ Many classic drivers, including ``pxe_ipmitool`` and ``agent_ipmitool`` use the IPA-based in-band RAID implementation by default. For the hardware types it is not used by default. To use it, you need to enable it in the configuration first: .. code-block:: ini [DEFAULT] enabled_raid_interfaces = agent,no-raid Then you can update those nodes that support in-band RAID to use the ``agent`` RAID interface. For example, to update all nodes use: .. code-block:: console export OS_BAREMETAL_API_VERSION=1.31 for uuid in $(openstack baremetal node list --driver ipmi -f value -c UUID); do openstack baremetal node set $uuid --raid-interface agent done .. note:: The ability of a node to use the ``agent`` RAID interface depends on the ramdisk (more specifically, a `hardware manager`_ used in it), not on the driver. .. _hardware manager: https://docs.openstack.org/ironic-python-agent/latest/contributor/hardware_managers.html Network and storage ~~~~~~~~~~~~~~~~~~~ The network and storage interfaces have always been dynamic, and thus do not require any special treatment during upgrade. Vendor ~~~~~~ Classic drivers are allowed to use the ``VendorMixin`` functionality to combine and expose several node or driver vendor passthru methods from different vendor interface implementations in one driver. **This is no longer possible with hardware types.** With hardware types, a vendor interface can only have a single active implementation from the list of vendor interfaces supported by a given hardware type. Ironic no longer has in-tree drivers (both classic and hardware types) that rely on this ``VendorMixin`` functionality support. However if you are using an out-of-tree classic driver that depends on it, you'll need to do the following in order to use vendor passthru methods from different vendor passthru implementations: #. While creating a new hardware type to replace your classic driver, specify all vendor interface implementations your classic driver was using to build its ``VendorMixin`` as supported vendor interfaces (property ``supported_vendor_interfaces`` of the Python class that defines your hardware type). #. Ensure all required vendor interfaces are enabled in the ironic configuration file under the ``[DEFAULT]enabled_vendor_interfaces`` option. You should also consider setting the ``[DEFAULT]default_vendor_interface`` option to specify the vendor interface for nodes that do not have one set explicitly. #. Before invoking a specific vendor passthru method, make sure that the node's vendor interface is set to the interface with the desired vendor passthru method. For example, if you want to invoke the vendor passthru method ``vendor_method_foo()`` from ``vendor_foo`` vendor interface: .. code-block:: shell # set the vendor interface to 'vendor_foo` openstack --os-baremetal-api-version 1.31 baremetal node set --vendor-interface vendor_foo # invoke the vendor passthru method openstack baremetal node passthru call vendor_method_foo ironic-10.1.1/doc/source/admin/adoption.rst0000666000175100017510000002002213243617463020614 0ustar zuulzuul00000000000000.. _adoption: ============= Node adoption ============= Overview ======== As part of hardware inventory lifecycle management, it is not an unreasonable need to have the capability to be able to add hardware that should be considered "in-use" by the Bare Metal service, that may have been deployed by another Bare Metal service installation or deployed via other means. As such, the node adoption feature allows a user to define a node as ``active`` while skipping the ``available`` and ``deploying`` states, which will prevent the node from being seen by the Compute service as ready for use. This feature is leveraged as part of the state machine workflow, where a node in ``manageable`` can be moved to ``active`` state via the provision_state verb ``adopt``. To view the state transition capabilities, please see :ref:`states`. How it works ============ A node initially enrolled begins in the ``enroll`` state. An operator must then move the node to ``manageable`` state, which causes the node's ``power`` interface to be validated. Once in ``manageable`` state, an operator can then explicitly choose to adopt a node. Adoption of a node results in the validation of its ``boot`` interface, and upon success the process leverages what is referred to as the "takeover" logic. The takeover process is intended for conductors to take over the management of nodes for a conductor that has failed. The takeover process involves the deploy interface's ``prepare`` and ``take_over`` methods being called. These steps take specific actions such as downloading and staging the deployment kernel and ramdisk, ISO image, any required boot image, or boot ISO image and then places any PXE or virtual media configuration necessary for the node should it be required. The adoption process makes no changes to the physical node, with the exception of operator supplied configurations where virtual media is used to boot the node under normal circumstances. An operator should ensure that any supplied configuration defining the node is sufficient for the continued operation of the node moving forward. Such as, if the node is configured to network boot via instance_info/boot_option="netboot", then appropriate driver specific node configuration should be set to support this capability. Possible Risk ============= The main risk with this feature is that supplied configuration may ultimately be incorrect or invalid which could result in potential operational issues: * ``rebuild`` verb - Rebuild is intended to allow a user to re-deploy the node to a fresh state. The risk with adoption is that the image defined when an operator adopts the node may not be the valid image for the pre-existing configuration. If this feature is utilized for a migration from one deployment to another, and pristine original images are loaded and provided, then ultimately the risk is the same with any normal use of the ``rebuild`` feature, the server is effectively wiped. * When deleting a node, the deletion or cleaning processes may fail if the incorrect deployment image is supplied in the configuration as the node may NOT have been deployed with the supplied image and driver or compatibility issues may exist as a result. Operators will need to be cognizant of that possibility and should plan accordingly to ensure that deployment images are known to be compatible with the hardware in their environment. * Networking - Adoption will assert no new networking configuration to the newly adopted node as that would be considered modifying the node. Operators will need to plan accordingly and have network configuration such that the nodes will be able to network boot. How to use ========== .. NOTE:: The power state that the ironic-conductor observes upon the first successful power state check, as part of the transition to the ``manageable`` state will be enforced with a node that has been adopted. This means a node that is in ``power off`` state will, by default, have the power state enforced as ``power off`` moving forward, unless an administrator actively changes the power state using the Bare Metal service. Requirements ------------ Requirements for use are essentially the same as to deploy a node: * Sufficient driver information to allow for a successful power management validation. * Sufficient instance_info to pass deploy interface preparation. Each driver may have additional requirements dependent upon the configuration that is supplied. An example of this would be defining a node to always boot from the network, which will cause the conductor to attempt to retrieve the pertinent files. Inability to do so will result in the adoption failing, and the node being placed in the ``adopt failed`` state. Example ------- This is an example to create a new node, named ``testnode``, with sufficient information to pass basic validation in order to be taken from the ``manageable`` state to ``active`` state:: # Explicitly set the client API version environment variable to # 1.17, which introduces the adoption capability. export OS_BAREMETAL_API_VERSION=1.17 openstack baremetal node create --name testnode \ --driver ipmi \ --driver-info ipmi_address= \ --driver-info ipmi_username= \ --driver-info ipmi_password= \ --driver-info deploy_kernel= \ --driver-info deploy_ramdisk= openstack baremetal port create --node openstack baremetal node set testnode \ --instance-info image_source="http://localhost:8080/blankimage" \ --instance-info capabilities="{\"boot_option\": \"local\"}" openstack baremetal node manage testnode --wait openstack baremetal node adopt testnode --wait .. NOTE:: In the above example, the image_source setting must reference a valid image or file, however that image or file can ultimately be empty. .. NOTE:: The above example utilizes a capability that defines the boot operation to be local. It is recommended to define the node as such unless network booting is desired. .. NOTE:: The above example will fail a re-deployment as a fake image is defined and no instance_info/image_checksum value is defined. As such any actual attempt to write the image out will fail as the image_checksum value is only validated at time of an actual deployment operation. .. NOTE:: A user may wish to assign an instance_uuid to a node, which could be used to match an instance in the Compute service. Doing so is not required for the proper operation of the Bare Metal service. openstack baremetal node set --instance-uuid .. NOTE:: In Newton, coupled with API version 1.20, the concept of a network_interface was introduced. A user of this feature may wish to add new nodes with a network_interface of ``noop`` and then change the interface at a later point and time. Troubleshooting =============== Should an adoption operation fail for a node, the error that caused the failure will be logged in the node's ``last_error`` field when viewing the node. This error, in the case of node adoption, will largely be due to failure of a validation step. Validation steps are dependent upon what driver is selected for the node. Any node that is in the ``adopt failed`` state can have the ``adopt`` verb re-attempted. Example:: openstack baremetal node adopt If a user wishes to abort their attempt at adopting, they can then move the node back to ``manageable`` from ``adopt failed`` state by issuing the ``manage`` verb. Example:: openstack baremetal node manage If all else fails the hardware node can be removed from the Bare Metal service. The ``node delete`` command, which is **not** the same as setting the provision state to ``deleted``, can be used while the node is in ``adopt failed`` state. This will delete the node without cleaning occurring to preserve the node's current state. Example:: openstack baremetal node delete ironic-10.1.1/doc/source/admin/inspection.rst0000666000175100017510000000746113243617463021166 0ustar zuulzuul00000000000000.. _inspection: =================== Hardware Inspection =================== Overview -------- Inspection allows Bare Metal service to discover required node properties once required ``driver_info`` fields (for example, IPMI credentials) are set by an operator. Inspection will also create the Bare Metal service ports for the discovered ethernet MACs. Operators will have to manually delete the Bare Metal service ports for which physical media is not connected. This is required due to the `bug 1405131 `_. There are two kinds of inspection supported by Bare Metal service: #. Out-of-band inspection is currently implemented by several hardware types, including ``ilo``, ``idrac`` and ``irmc``. #. `In-band inspection`_ by utilizing the ironic-inspector_ project. The node should be in the ``manageable`` state before inspection is initiated. If it is in the ``enroll`` or ``available`` state, move it to ``manageable`` first:: openstack baremetal node manage Then inspection can be initiated using the following command:: openstack baremetal node inspect .. _capabilities-discovery: Capabilities discovery ---------------------- This is an incomplete list of capabilities we want to discover during inspection. The exact support is hardware and hardware type specific though, the most complete list is provided by the iLO :ref:`ilo-inspection`. ``secure_boot`` (``true`` or ``false``) whether secure boot is supported for the node ``boot_mode`` (``bios`` or ``uefi``) the boot mode the node is using ``cpu_vt`` (``true`` or ``false``) whether the CPU virtualization is enabled ``cpu_aes`` (``true`` or ``false``) whether the AES CPU extensions are enabled ``max_raid_level`` (integer, 0-10) maximum RAID level supported by the node ``pci_gpu_devices`` (non-negative integer) number of GPU devices on the node The operator can specify these capabilities in nova flavor for node to be selected for scheduling:: nova flavor-key my-baremetal-flavor set capabilities:pci_gpu_devices="> 0" nova flavor-key my-baremetal-flavor set capabilities:secure_boot="true" Please see a specific :doc:`hardware type page ` for the exact list of capabilities this hardware type can discover. In-band inspection ------------------ In-band inspection involves booting a ramdisk on the target node and fetching information directly from it. This process is more fragile and time-consuming than the out-of-band inspection, but it is not vendor-specific and works across a wide range of hardware. In-band inspection is using the ironic-inspector_ project. It is supported by all hardware types, and used by default, if enabled, by the ``ipmi`` hardware type. The ``inspector`` *inspect* interface has to be enabled to use it: .. code-block:: ini [DEFAULT] enabled_inspect_interfaces = inspector,no-inspect If using classic drivers supporting in-band inspection, like ``pxe_ipmitool``, another option has to be set as well: .. code-block:: ini [inspector] enabled = True You must additionally install python-ironic-inspector-client_ to use this functionality. If the ironic-inspector service is not registered in the service catalog, set the following option: .. code-block:: ini [inspector] endpoint-override = http://inspector.example.com:5050 In order to ensure that ports in Bare Metal service are synchronized with NIC ports on the node, the following settings in the ironic-inspector configuration file must be set:: [processing] add_ports = all keep_ports = present .. _ironic-inspector: https://pypi.python.org/pypi/ironic-inspector .. _python-ironic-inspector-client: https://pypi.python.org/pypi/python-ironic-inspector-client .. _python-ironicclient: https://pypi.python.org/pypi/python-ironicclient ironic-10.1.1/doc/source/admin/upgrade-guide.rst0000666000175100017510000004605613243617463021540 0ustar zuulzuul00000000000000.. _upgrade-guide: ================================ Bare Metal Service Upgrade Guide ================================ This document outlines various steps and notes for operators to consider when upgrading their ironic-driven clouds from previous versions of OpenStack. The Bare Metal (ironic) service is tightly coupled with the ironic driver that is shipped with the Compute (nova) service. Some special considerations must be taken into account when upgrading your cloud. Both offline and rolling upgrades are supported. Plan your upgrade ================= * Rolling upgrades are available starting with the Pike release; that is, when upgrading from Ocata. This means that it is possible to do an upgrade with minimal to no downtime of the Bare Metal API. * Upgrades are only supported between two consecutive named releases. This means that you cannot upgrade Ocata directly into Queens; you need to upgrade into Pike first. * The `release notes `_ should always be read carefully when upgrading the Bare Metal service. Specific upgrade steps and considerations are documented there. * The Bare Metal service should always be upgraded before the Compute service. .. note:: The ironic virt driver in nova always uses a specific version of the ironic REST API. This API version may be one that was introduced in the same development cycle, so upgrading nova first may result in nova being unable to use the Bare Metal API. * Make a backup of your database. Ironic does not support downgrading of the database. Hence, in case of upgrade failure, restoring the database from a backup is the only choice. * Before starting your upgrade, it is best to ensure that all nodes have reached, or are in, a stable ``provision_state``. Nodes in states with long running processes such as deploying or cleaning, may fail, and may require manual intervention to return them to the available hardware pool. This is most likely in cases where a timeout has occurred or a service was terminated abruptly. For a visual diagram detailing states and possible state transitions, please see :ref:`states`. Offline upgrades ================ In an offline (or cold) upgrade, the Bare Metal service is not available during the upgrade, because all the services have to be taken down. When upgrading the Bare Metal service, the following steps should always be taken in this order: #. upgrade the ironic-python-agent image #. update ironic code, without restarting services #. run database schema migrations via ``ironic-dbsync upgrade`` #. restart ironic-conductor and ironic-api services Once the above is done, do the following: * update any applicable configuration options to stop using any deprecated features or options, and perform any required work to transition to alternatives. All the deprecated features and options will be supported for one release cycle, so should be removed before your next upgrade is performed. * upgrade python-ironicclient along with any other services connecting to the Bare Metal service as a client, such as nova-compute * run the ``ironic-dbsync online_data_migrations`` command to make sure that data migrations are applied. The command lets you limit the impact of the data migrations with the ``--max-count`` option, which limits the number of migrations executed in one run. You should complete all of the migrations as soon as possible after the upgrade. .. warning:: You will not be able to start an upgrade to the release after this one, until this has been completed for the current release. For example, as part of upgrading from Ocata to Pike, you need to complete Pike's data migrations. If this not done, you will not be able to upgrade to Queens -- it will not be possible to execute Queens' database schema updates. Rolling upgrades ================ To Reduce downtime, the services can be upgraded in a rolling fashion, meaning to upgrade one or a few services at a time to minimize impact. Rolling upgrades are available starting with the Pike release. This feature makes it possible to upgrade between releases, such as Ocata to Pike, with minimal to no downtime of the Bare Metal API. Requirements ------------ To facilitate an upgrade in a rolling fashion, you need to have a highly-available deployment consisting of at least two ironic-api and two ironic-conductor services. Use of a load balancer to balance requests across the ironic-api services is recommended, as it allows for a minimal impact to end users. Concepts -------- There are four aspects of the rolling upgrade process to keep in mind: * API and RPC version pinning, and versioned object backports * online data migrations * graceful service shutdown * API load balancer draining API & RPC version pinning and versioned object backports ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Through careful RPC versioning, newer services are able to talk to older services (and vice-versa). The ``[DEFAULT]/pin_release_version`` configuration option is used for this. It should be set (pinned) to the release version that the older services are using. The newer services will backport RPC calls and objects to their appropriate versions from the pinned release. If the ``IncompatibleObjectVersion`` exception occurs, it is most likely due to an incorrect or unspecified ``[DEFAULT]/pin_release_version`` configuration value. For example, when ``[DEFAULT]/pin_release_version`` is not set to the older release version, no conversion will happen during the upgrade. For the ironic-api service, the API version is pinned via the same ``[DEFAULT]/pin_release_version`` configuration option as above. When pinned, the new ironic-api services will not service any API requests with Bare Metal API versions that are higher than what the old ironic-api services support. HTTP status code 406 is returned for such requests. This prevents new features (available in new API versions) from being used until after the upgrade has been completed. Online data migrations ~~~~~~~~~~~~~~~~~~~~~~ To make database schema migrations less painful to execute, we have implemented process changes to facilitate upgrades. * All data migrations are banned from schema migration scripts. * Schema migration scripts only update the database schema. * Data migrations must be done at the end of the rolling upgrade process, after the schema migration and after the services have been upgraded to the latest release. All data migrations are performed using the ``ironic-dbsync online_data_migrations`` command. It can be run as a background process so that it does not interrupt running services; however it must be run to completion for a cold upgrade if the intent is to make use of new features immediately. (You would also execute the same command with services turned off if you are doing a cold upgrade). This data migration must be completed. If not, you will not be able to upgrade to future releases. For example, if you had upgraded from Ocata to Pike but did not do the data migrations, you will not be able to upgrade from Pike to Queens. (More precisely, you will not be able to apply Queens' schema migrations.) Graceful conductor service shutdown ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The ironic-conductor service is a Python process listening for messages on a message queue. When the operator sends the SIGTERM signal to the process, the service stops consuming messages from the queue, so that no additional work is picked up. It completes any outstanding work and then terminates. During this process, messages can be left on the queue and will be processed after the Python process starts back up. This gives us a way to shutdown a service using older code, and start up a service using newer code with minimal impact. .. note:: This was tested with RabbitMQ messaging backend and may vary with other backends. Nodes that are being acted upon by an ironic-conductor process, which are not in a stable state, may encounter failures. Node failures that occur during an upgrade are likely due to timeouts, resulting from delays involving messages being processed and acted upon by a conductor during long running, multi-step processes such as deployment or cleaning. API load balancer draining ~~~~~~~~~~~~~~~~~~~~~~~~~~ If you are using a load balancer for the ironic-api services, we recommend that you redirect requests to the new API services and drain off of the ironic-api services that have not yet been upgraded. Rolling upgrade process ----------------------- Before maintenance window ~~~~~~~~~~~~~~~~~~~~~~~~~ * Upgrade the ironic-python-agent image * Using the new release (ironic code), execute the required database schema updates by running the database upgrade command: ``ironic-dbsync upgrade``. These schema change operations should have minimal or no effect on performance, and should not cause any operations to fail (but please check the release notes). You can: * install the new release on an existing system * install the new release in a new virtualenv or a container At this point, new columns and tables may exist in the database. These database schema changes are done in a way that both the old and new (N and N+1) releases can perform operations against the same schema. .. note:: Ironic bases its API, RPC and object storage format versions on the ``[DEFAULT]/pin_release_version`` configuration option. It is advisable to automate the deployment of changes in configuration files to make the process less error prone and repeatable. During maintenance window ~~~~~~~~~~~~~~~~~~~~~~~~~ #. All ironic-conductor services should be upgraded first. Ensure that at least one ironic-conductor service is running at all times. For every ironic-conductor, either one by one or a few at a time: * shut down the service. Messages from the ironic-api services to the conductors are load-balanced by the message queue and a hash-ring, so the only thing you need to worry about is to shut the service down gracefully (using ``SIGTERM`` signal) to make sure it will finish all the requests being processed before shutting down. * upgrade the installed version of ironic and dependencies * set the ``[DEFAULT]/pin_release_version`` configuration option value to the version you are upgrading from (that is, the old version). Based on this setting, the new ironic-conductor services will downgrade any RPC communication and data objects to conform to the old service. For example, if you are upgrading from Ocata to Pike, set this value to ``ocata``. * start the service #. The next service to upgrade is ironic-api. Ensure that at least one ironic-api service is running at all times. You may want to start another temporary instance of the older ironic-api to handle the load while you are upgrading the original ironic-api services. For every ironic-api service, either one by one or a few at a time: * in HA deployment you are typically running them behind a load balancer (for example HAProxy), so you need to take the service instance out of the balancer * shut it down * upgrade the installed version of ironic and dependencies * set the ``[DEFAULT]/pin_release_version`` configuration option value to the version you are upgrading from (that is, the old version). Based on this setting, the new ironic-api services will downgrade any RPC communication and data objects to conform to the old service. In addition, the new services will return HTTP status code 406 for any requests with newer API versions that the old services did not support. This prevents new features (available in new API versions) from being used until after the upgrade has been completed. For example, if you are upgrading from Ocata to Pike, set this value to ``ocata``. * restart the service * add it back into the load balancer After upgrading all the ironic-api services, the Bare Metal service is running in the new version but with downgraded RPC communication and database object storage formats. New features (in new API versions) are not supported, because they could fail when objects are in the downgraded object formats and some internal RPC API functions may still not be available. #. For all the ironic-conductor services, one at a time: * remove the ``[DEFAULT]/pin_release_version`` configuration option setting * restart the ironic-conductor service #. For all the ironic-api services, one at a time: * remove the ``[DEFAULT]/pin_release_version`` configuration option setting * restart the ironic-api service After maintenance window ~~~~~~~~~~~~~~~~~~~~~~~~ Now that all the services are upgraded, the system is able to use the latest version of the RPC protocol and able to access all the features of the new release. * Update any applicable configuration options to stop using any deprecated features or options, and perform any required work to transition to alternatives. All the deprecated features and options will be supported for one release cycle, so should be removed before your next upgrade is performed. * Upgrade ``python-ironicclient`` along with other services connecting to the Bare Metal service as a client, such as ``nova-compute``. * Run the ``ironic-dbsync online_data_migrations`` command to make sure that data migrations are applied. The command lets you limit the impact of the data migrations with the ``--max-count`` option, which limits the number of migrations executed in one run. You should complete all of the migrations as soon as possible after the upgrade. .. warning:: Note that you will not be able to start an upgrade to the next release after this one, until this has been completed for the current release. For example, as part of upgrading from Ocata to Pike, you need to complete Pike's data migrations. If this not done, you will not be able to upgrade to Queens -- it will not be possible to execute Queens' database schema updates. Upgrading from Ocata to Pike ============================ #. Use the ``ironic-dbsync online_data_migrations`` command from the 9.1.1 (or newer) release. The one from older (9.0.0 - 9.1.0) releases could cause a a port's physical_network information to be deleted from the database. #. It is required to set the ``resource_class`` field for nodes registered with the Bare Metal service *before* using the Pike version of the Compute service. See :ref:`enrollment` for details. #. It is recommended to move from old-style classic drivers to the new hardware types after the upgrade to Pike. We expect the classic drivers to be deprecated in the Queens release and removed in the Rocky release. See :doc:`upgrade-to-hardware-types` for the details on the migration. Other upgrade instructions are in the `Pike release notes `_. .. toctree:: :maxdepth: 1 upgrade-to-hardware-types.rst Upgrading from Newton to Ocata ============================== There are no specific upgrade instructions other than the `Ocata release notes `_. Upgrading from Mitaka to Newton =============================== There are no specific upgrade instructions other than the `Newton release notes `_. Upgrading from Liberty to Mitaka ================================ There are no specific upgrade instructions other than the `Mitaka release notes `_. Upgrading from Kilo to Liberty ============================== In-band Inspection ------------------ If you used in-band inspection with **ironic-discoverd**, it is highly recommended that you switch to using **ironic-inspector**, which is a newer (and compatible on API level) version of the same service. You have to install **python-ironic-inspector-client** during the upgrade. This package contains a client module for the in-band inspection service, which was previously part of the **ironic-discoverd** package. Ironic Liberty supports the **ironic-discoverd** service, but does not support its in-tree client module. Please refer to `ironic-inspector version support matrix `_ for details on which ironic versions are compatible with which **ironic-inspector**/**ironic-discoverd** versions. The discoverd to inspector upgrade procedure is as follows: * Install **ironic-inspector** on the machine where you have **ironic-discoverd** (usually the same as conductor). * Update the **ironic-inspector** configuration file to stop using deprecated configuration options, as marked by the comments in the `example.conf `_. It is recommended you move the configuration file to ``/etc/ironic-inspector/inspector.conf``. * Shutdown **ironic-discoverd**, and start **ironic-inspector**. * During upgrade of each conductor instance: #. Shutdown the conductor. #. Uninstall **ironic-discoverd**, install **python-ironic-inspector-client**. #. Update the conductor. #. Update ``ironic.conf`` to use ``[inspector]`` section instead of ``[discoverd]`` (option names are the same). #. Start the conductor. Upgrading from Juno to Kilo =========================== When upgrading a cloud from Juno to Kilo, users must ensure the nova service is upgraded prior to upgrading the ironic service. Additionally, users need to set a special config flag in nova prior to upgrading to ensure the newer version of nova is not attempting to take advantage of new ironic features until the ironic service has been upgraded. The steps for upgrading your nova and ironic services are as follows: - Edit nova.conf and ensure force_config_drive=False is set in the [DEFAULT] group. Restart nova-compute if necessary. - Install new nova code, run database migrations. - Install new python-ironicclient code. - Restart nova services. - Install new ironic code, run database migrations, restart ironic services. - Edit nova.conf and set force_config_drive to your liking, restarting nova-compute if necessary. Note that during the period between nova's upgrade and ironic's upgrades, instances can still be provisioned to nodes. However, any attempt by users to specify a config drive for an instance will cause an error until ironic's upgrade has completed. Cleaning -------- A new feature starting from Kilo cycle is support for the automated cleaning of nodes between workloads to ensure the node is ready for another workload. This can include erasing the hard drives, updating firmware, and other steps. For more information, see :ref:`automated_cleaning`. If ironic is configured with automated cleaning enabled (defaults to True) and neutron is set as the DHCP provider (also the default), you will need to set the `cleaning_network_uuid` option in the ironic configuration file before starting the ironic service. See :ref:`configure-cleaning` for information on how to set up the cleaning network for ironic. ironic-10.1.1/doc/source/admin/interfaces/0000775000175100017510000000000013243617733020372 5ustar zuulzuul00000000000000ironic-10.1.1/doc/source/admin/interfaces/deploy.rst0000666000175100017510000000707613243617463022434 0ustar zuulzuul00000000000000================= Deploy Interfaces ================= A *deploy* interface plays a critical role in the provisioning process. It orchestrates the whole deployment and defines how the image gets transferred to the target disk. .. _iscsi-deploy: iSCSI deploy ============ With ``iscsi`` deploy interface (and also ``oneview-iscsi``, specific to the ``oneview`` hardware type) the deploy ramdisk publishes the node's hard drive as an iSCSI_ share. The ironic-conductor then copies the image to this share. See :ref:`iSCSI deploy diagram ` for a detailed explanation of how this deploy interface works. This interface is used by default, if enabled (see :ref:`enable-hardware-interfaces`). You can specify it explicitly when creating or updating a node:: openstack baremetal node create --driver ipmi --deploy-interface iscsi openstack baremetal node set --deploy-interface iscsi The ``iscsi`` deploy interface is also used in all of the *classic drivers* with names starting with ``pxe_`` (except for ``pxe_agent_cimc``) and ``iscsi_``. .. _iSCSI: https://en.wikipedia.org/wiki/ISCSI .. _direct-deploy: Direct deploy ============= With ``direct`` deploy interface (and also ``oneview-direct``, specific to the ``oneview`` hardware type), the deploy ramdisk fetches the image from an HTTP location. It can be an object storage (swift or RadosGW) temporary URL or a user-provided HTTP URL. The deploy ramdisk then copies the image to the target disk. See :ref:`direct deploy diagram ` for a detailed explanation of how this deploy interface works. You can specify this deploy interface when creating or updating a node:: openstack baremetal node create --driver ipmi --deploy-interface direct openstack baremetal node set --deploy-interface direct The ``direct`` deploy interface is also used in all *classic drivers* whose names include ``agent``. .. note:: For historical reasons the ``direct`` deploy interface is sometimes called ``agent``, and some *classic drivers* using it are called ``agent_*``. This is because before the Kilo release **ironic-python-agent** used to only support this deploy interface. .. _ansible-deploy: Ansible deploy ============== This interface is similar to ``direct`` in the sense that the image is downloaded by the ramdisk directly from the image store (not from ironic-conductor host), but the logic of provisioning the node is held in a set of Ansible playbooks that are applied by the ``ironic-conductor`` service handling the node. While somewhat more complex to set up, this deploy interface provides greater flexibility in terms of advanced node preparation during provisioning. This interface is supported by most but not all hardware types declared in ironic (for example, ``oneview`` hardware type does not support it). However this deploy interface is not enabled by default. To enable it, add ``ansible`` to the list of enabled deploy interfaces in ``enabled_deploy_interfaces`` option in the ``[DEFAULT]`` section of ironic's configuration file: .. code-block:: ini [DEFAULT] ... enabled_deploy_interfaces = iscsi,direct,ansible ... Once enabled, you can specify this deploy interface when creating or updating a node: .. code-block:: shell openstack baremetal node create --driver ipmi --deploy-interface ansible openstack baremetal node set --deploy-interface ansible For more information about this deploy interface, its features and how to use it, see :doc:`Ansible deploy interface <../drivers/ansible>`. .. toctree:: :hidden: ../drivers/ansible ironic-10.1.1/doc/source/admin/interfaces/boot.rst0000666000175100017510000000533413243617463022076 0ustar zuulzuul00000000000000=============== Boot interfaces =============== The boot interface manages booting of both the deploy ramdisk and the user instances on the bare metal node. The `PXE boot`_ interface is generic and works with all hardware that supports booting from network. Alternatively, several vendors provide *virtual media* implementations of the boot interface. They work by pushing an ISO image to the node's `management controller`_, and do not require either PXE or iPXE. Check your driver documentation at :doc:`../drivers` for details. .. _pxe-boot: PXE boot -------- The ``pxe`` boot interface uses PXE_ or iPXE_ to deliver the target kernel/ramdisk pair. PXE uses relatively slow and unreliable TFTP protocol for transfer, while iPXE uses HTTP. The downside of iPXE is that it's less common, and usually requires bootstrapping using PXE first. The ``pxe`` boot interface works by preparing a PXE/iPXE environment for a node on the file system, then instructing the DHCP provider (for example, the Networking service) to boot the node from it. See :ref:`iscsi-deploy-example` and :ref:`direct-deploy-example` for a better understanding of the whole deployment process. .. note:: Both PXE and iPXE are configured differently, when UEFI boot is used instead of conventional BIOS boot. This is particularly important for CPU architectures that do not have BIOS support at all. The ``pxe`` boot interface is used by default for many hardware types, including ``ipmi``, and for all classic drivers with names starting with ``pxe_``. Some hardware types, notably ``ilo`` and ``irmc`` have their specific implementations of the PXE boot interface. Additional configuration is required for this boot interface - see :doc:`/install/configure-pxe` for details. Enable persistent boot device for deploy/clean operation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ironic uses non-persistent boot for cleaning/deploying phases as default, in PXE interface. For some drivers, a persistent change is far more costly than a non-persistent one, so this can bring performance improvements. Set the flag ``force_persistent_boot_device`` to ``True`` in the node's ``driver_info``:: $ openstack baremetal node set --driver-info force_persistent_boot_device=True .. note:: It's recommended to check if the node's state has not changed as there is no way of locking the node between these commands. Once the flag is present, the next cleaning and deploy steps will be done with persistent boot for that node. .. _PXE: https://en.wikipedia.org/wiki/Preboot_Execution_Environment .. _iPXE: https://en.wikipedia.org/wiki/IPXE .. _management controller: https://en.wikipedia.org/wiki/Out-of-band_management .. toctree:: :hidden: ../drivers/pxe ironic-10.1.1/doc/source/admin/radosgw.rst0000666000175100017510000000501713243617463020454 0ustar zuulzuul00000000000000.. _radosgw support: =========================== Ceph Object Gateway support =========================== Overview ======== Ceph project is a powerful distributed storage system. It contains object store and provides a RADOS Gateway Swift API which is compatible with OpenStack Swift API. These two APIs use different formats for their temporary URLs. Ironic added support for RADOS Gateway temporary URL in the Mitaka release. Configure Ironic and Glance with RADOS Gateway ============================================== #. Install Ceph storage with RADOS Gateway. See `Ceph documentation `_. #. Create RADOS Gateway credentials for Glance by executing the following commands on the RADOS Gateway admin host:: sudo radosgw-admin user create --uid="GLANCE_USERNAME" --display-name="User for Glance" sudo radosgw-admin subuser create --uid=GLANCE_USERNAME --subuser=GLANCE_USERNAME:swift --access=full sudo radosgw-admin key create --subuser=GLANCE_USERNAME:swift --key-type=swift --secret=STORE_KEY sudo radosgw-admin user modify --uid=GLANCE_USERNAME --temp-url-key=TEMP_URL_KEY Replace GLANCE_USERNAME with a user name for Glance access, and replace STORE_KEY and TEMP_URL_KEY with suitable keys. Note: Do not use "--gen-secret" CLI parameter because it will cause the "radosgw-admin" utility to generate keys with slash symbols which do not work with Glance. #. Configure Glance API service for RADOS Swift API as backend. Edit the configuration file for the Glance API service (is typically located at ``/etc/glance/glance-api.conf``). Replace RADOS_IP and PORT with the IP/port of the RADOS Gateway API service:: [glance_store] stores = file, http, swift default_store = swift swift_store_auth_version = 1 swift_store_auth_address = http://RADOS_IP:PORT/auth/1.0 swift_store_user = GLANCE_USERNAME:swift swift_store_key = STORE_KEY swift_store_container = glance swift_store_create_container_on_put = True Note: RADOS Gateway uses FastCGI protocol for interacting with HTTP server. Read your HTTP server documentation if you want to enable HTTPS support. #. Restart Glance API service and upload all needed images. #. Change Ironic configuration file on the conductor host(s) as follows:: [glance] swift_container = glance swift_api_version = v1 swift_endpoint_url = http://RADOS_IP:PORT swift_temp_url_key = TEMP_URL_KEY [deploy] object_store_endpoint_type = radosgw #. Restart Ironic conductor service(s). ironic-10.1.1/doc/source/admin/raid.rst0000666000175100017510000003046413243617463017731 0ustar zuulzuul00000000000000.. _raid: ================== RAID Configuration ================== Overview ======== Ironic supports RAID configuration for bare metal nodes. It allows operators to specify the desired RAID configuration via the OpenStackClient CLI or REST API. The desired RAID configuration is applied on the bare metal during manual cleaning. The examples described here use the OpenStackClient CLI; please see the `REST API reference `_ for their corresponding REST API requests. Prerequisites ============= The bare metal node needs to use a hardware type that supports RAID configuration. RAID interfaces may implement RAID configuration either in-band or out-of-band. In-band RAID configuration is done using the Ironic Python Agent ramdisk. For in-band RAID configuration using agent ramdisk, a hardware manager which supports RAID should be bundled with the ramdisk. Whether a node supports RAID configuration could be found using the CLI command ``openstack baremetal node validate ``. Build agent ramdisk which supports RAID configuration ===================================================== For doing in-band RAID configuration, Ironic needs an agent ramdisk bundled with a hardware manager which supports RAID configuration for your hardware. For example, the :ref:`DIB_raid_support` should be used for HPE Proliant Servers. RAID configuration JSON format ============================== The desired RAID configuration and current RAID configuration are represented in JSON format. Target RAID configuration ------------------------- This is the desired RAID configuration on the bare metal node. Using the OpenStackClient CLI (or REST API), the operator sets ``target_raid_config`` field of the node. The target RAID configuration will be applied during manual cleaning. Target RAID configuration is a dictionary having ``logical_disks`` as the key. The value for the ``logical_disks`` is a list of JSON dictionaries. It looks like:: { "logical_disks": [ {}, {}, . . . ] } If the ``target_raid_config`` is an empty dictionary, it unsets the value of ``target_raid_config`` if the value was set with previous RAID configuration done on the node. Each dictionary of logical disk contains the desired properties of logical disk supported by the hardware type or classic driver. These properties are discoverable by:: openstack baremetal --os-baremetal-api-version 1.15 driver raid property list The RAID feature is available in ironic API version 1.15 and above. If ``--os-baremetal-api-version`` is not used in the CLI, it will error out with the following message:: No API version was specified and the requested operation was not supported by the client's negotiated API version 1.9. Supported version range is: 1.1 to ... where the "..." in above error message would be the maximum version supported by the service. The RAID properties can be split into 4 different types: #. Mandatory properties. These properties must be specified for each logical disk and have no default values. - ``size_gb`` - Size (Integer) of the logical disk to be created in GiB. ``MAX`` may be specified if the logical disk should use all of the remaining space available. This can be used only when backing physical disks are specified (see below). - ``raid_level`` - RAID level for the logical disk. Ironic supports the following RAID levels: 0, 1, 2, 5, 6, 1+0, 5+0, 6+0. #. Optional properties. These properties have default values and they may be overridden in the specification of any logical disk. - ``volume_name`` - Name of the volume. Should be unique within the Node. If not specified, volume name will be auto-generated. - ``is_root_volume`` - Set to ``true`` if this is the root volume. At most one logical disk can have this set to ``true``; the other logical disks must have this set to ``false``. The ``root device hint`` will be saved, if the RAID interface is capable of retrieving it. This is ``false`` by default. #. Backing physical disk hints. These hints are specified for each logical disk to let Ironic find the desired disks for RAID configuration. This is machine-independent information. This serves the use-case where the operator doesn't want to provide individual details for each bare metal node. - ``share_physical_disks`` - Set to ``true`` if this logical disk can share physical disks with other logical disks. The default value is ``false``. - ``disk_type`` - ``hdd`` or ``ssd``. If this is not specified, disk type will not be a criterion to find backing physical disks. - ``interface_type`` - ``sata`` or ``scsi`` or ``sas``. If this is not specified, interface type will not be a criterion to find backing physical disks. - ``number_of_physical_disks`` - Integer, number of disks to use for the logical disk. Defaults to minimum number of disks required for the particular RAID level. #. Backing physical disks. These are the actual machine-dependent information. This is suitable for environments where the operator wants to automate the selection of physical disks with a 3rd-party tool based on a wider range of attributes (eg. S.M.A.R.T. status, physical location). The values for these properties are hardware dependent. - ``controller`` - The name of the controller as read by the RAID interface. - ``physical_disks`` - A list of physical disks to use as read by the RAID interface. .. note:: If properties from both "Backing physical disk hints" or "Backing physical disks" are specified, they should be consistent with each other. If they are not consistent, then the RAID configuration will fail (because the appropriate backing physical disks could not be found). Examples for ``target_raid_config`` ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ *Example 1*. Single RAID disk of RAID level 5 with all of the space available. Make this the root volume to which Ironic deploys the image:: { "logical_disks": [ { "size_gb": "MAX", "raid_level": "5", "is_root_volume": true } ] } *Example 2*. Two RAID disks. One with RAID level 5 of 100 GiB and make it root volume and use SSD. Another with RAID level 1 of 500 GiB and use HDD:: { "logical_disks": [ { "size_gb": 100, "raid_level": "5", "is_root_volume": true, "disk_type": "ssd" }, { "size_gb": 500, "raid_level": "1", "disk_type": "hdd" } ] } *Example 3*. Single RAID disk. I know which disks and controller to use:: { "logical_disks": [ { "size_gb": 100, "raid_level": "5", "controller": "Smart Array P822 in Slot 3", "physical_disks": ["6I:1:5", "6I:1:6", "6I:1:7"], "is_root_volume": true } ] } *Example 4*. Using backing physical disks:: { "logical_disks": [ { "size_gb": 50, "raid_level": "1+0", "controller": "RAID.Integrated.1-1", "volume_name": "root_volume", "is_root_volume": true, "physical_disks": [ "Disk.Bay.0:Encl.Int.0-1:RAID.Integrated.1-1", "Disk.Bay.1:Encl.Int.0-1:RAID.Integrated.1-1" ] }, { "size_gb": 100, "raid_level": "5", "controller": "RAID.Integrated.1-1", "volume_name": "data_volume", "physical_disks": [ "Disk.Bay.2:Encl.Int.0-1:RAID.Integrated.1-1", "Disk.Bay.3:Encl.Int.0-1:RAID.Integrated.1-1", "Disk.Bay.4:Encl.Int.0-1:RAID.Integrated.1-1" ] } ] } Current RAID configuration -------------------------- After target RAID configuration is applied on the bare metal node, Ironic populates the current RAID configuration. This is populated in the ``raid_config`` field in the Ironic node. This contains the details about every logical disk after they were created on the bare metal node. It contains details like RAID controller used, the backing physical disks used, WWN of each logical disk, etc. It also contains information about each physical disk found on the bare metal node. To get the current RAID configuration:: openstack baremetal --os-baremetal-api-version 1.15 node show Workflow ======== * Operator configures the bare metal node with a hardware type that has a ``RAIDInterface`` other than ``no-raid`` (``None`` for classic drivers). * For in-band RAID configuration, operator builds an agent ramdisk which supports RAID configuration by bundling the hardware manager with the ramdisk. See `Build agent ramdisk which supports RAID configuration`_ for more information. * Operator prepares the desired target RAID configuration as mentioned in `Target RAID configuration`_. The target RAID configuration is set on the Ironic node:: openstack baremetal --os-baremetal-api-version 1.15 node set \ --target-raid-config The CLI command can accept the input from standard input also: openstack baremetal --os-baremetal-api-version 1.15 node set \ --target-raid-config - * Create a JSON file with the RAID clean steps for manual cleaning. Add other clean steps as desired:: [{ "interface": "raid", "step": "delete_configuration" }, { "interface": "raid", "step": "create_configuration" }] .. note:: 'create_configuration' doesn't remove existing disks. It is recommended to add 'delete_configuration' before 'create_configuration' to make sure that only the desired logical disks exist in the system after manual cleaning. * Bring the node to ``manageable`` state and do a ``clean`` action to start cleaning on the node:: openstack baremetal --os-baremetal-api-version 1.15 node clean \ --clean-steps * After manual cleaning is complete, the current RAID configuration can be viewed using:: openstack baremetal --os-baremetal-api-version 1.15 node show Using RAID in nova flavor for scheduling ======================================== The operator can specify the `raid_level` capability in nova flavor for node to be selected for scheduling:: nova flavor-key my-baremetal-flavor set capabilities:raid_level="1+0" Developer documentation ======================= In-band RAID configuration is done using IPA ramdisk. IPA ramdisk has support for pluggable hardware managers which can be used to extend the functionality offered by IPA ramdisk using stevedore plugins. For more information, see Ironic Python Agent `Hardware Manager`_ documentation. .. _`Hardware Manager`: https://docs.openstack.org/ironic-python-agent/latest/install/index.html#hardware-managers The hardware manager that supports RAID configuration should do the following: #. Implement a method named ``create_configuration``. This method creates the RAID configuration as given in ``target_raid_config``. After successful RAID configuration, it returns the current RAID configuration information which ironic uses to set ``node.raid_config``. #. Implement a method named ``delete_configuration``. This method deletes all the RAID disks on the bare metal. #. Return these two clean steps in ``get_clean_steps`` method with priority as 0. Example:: return [{'step': 'create_configuration', 'interface': 'raid', 'priority': 0}, {'step': 'delete_configuration', 'interface': 'raid', 'priority': 0}] ironic-10.1.1/doc/source/admin/metrics.rst0000666000175100017510000001026113243617463020451 0ustar zuulzuul00000000000000.. _metrics: ========================= Emitting Software Metrics ========================= Beginning with the Newton (6.1.0) release, the ironic services support emitting internal performance data to `statsd `_. This allows operators to graph and understand performance bottlenecks in their system. This guide assumes you have a statsd server setup. For information on using and configuring statsd, please see the `statsd `_ README and documentation. These performance measurements, herein referred to as "metrics", can be emitted from the Bare Metal service, including ironic-api, ironic-conductor, and ironic-python-agent. By default, none of the services will emit metrics. Configuring the Bare Metal Service to Enable Metrics ==================================================== Enabling metrics in ironic-api and ironic-conductor --------------------------------------------------- The ironic-api and ironic-conductor services can be configured to emit metrics to statsd by adding the following to the ironic configuration file, usually located at ``/etc/ironic/ironic.conf``:: [metrics] backend = statsd If a statsd daemon is installed and configured on every host running an ironic service, listening on the default UDP port (8125), no further configuration is needed. If you are using a remote statsd server, you must also supply connection information in the ironic configuration file:: [metrics_statsd] # Point this at your environments' statsd host statsd_host = 192.0.2.1 statsd_port = 8125 Enabling metrics in ironic-python-agent --------------------------------------- The ironic-python-agent process receives its configuration in the response from the initial lookup request to the ironic-api service. This means to configure ironic-python-agent to emit metrics, you must enable the agent metrics backend in your ironic configuration file on all ironic-conductor hosts:: [metrics] agent_backend = statsd In order to reliably emit metrics from the ironic-python-agent, you must provide a statsd server that is reachable from both the configured provisioning and cleaning networks. The agent statsd connection information is configured in the ironic configuration file as well:: [metrics_statsd] # Point this at a statsd host reachable from the provisioning and cleaning nets agent_statsd_host = 198.51.100.2 agent_statsd_port = 8125 Types of Metrics Emitted ======================== The Bare Metal service emits timing metrics for every API method, as well as for most driver methods. These metrics measure how long a given method takes to execute. A deployer with metrics enabled should expect between 100 and 500 distinctly named data points to be emitted from the Bare Metal service. This will increase if the metrics.preserve_host option is set to true or if multiple drivers are used in the Bare Metal deployment. This estimate may be used to determine if a deployer needs to scale their metrics backend to handle the additional load before enabling metrics. To see which metrics have changed names or have been removed between releases, refer to the `ironic release notes `_. .. note:: With the default statsd configuration, each timing metric may create additional metrics due to how statsd handles timing metrics. For more information, see statds documentation on `metric types `_. The ironic-python-agent ramdisk emits timing metrics for every API method. Deployers who use custom HardwareManagers can emit custom metrics for their hardware. For more information on custom HardwareManagers, and emitting metrics from them, please see the `ironic-python-agent documentation `_. Adding New Metrics ================== If you're a developer, and would like to add additional metrics to ironic, please see the `ironic-lib developer documentation `_ for details on how to use the metrics library. A release note should also be created each time a metric is changed or removed to alert deployers of the change. ironic-10.1.1/doc/source/admin/troubleshooting.rst0000666000175100017510000003400613243617463022235 0ustar zuulzuul00000000000000.. _troubleshooting: ====================== Troubleshooting Ironic ====================== Nova returns "No valid host was found" Error ============================================ Sometimes Nova Conductor log file "nova-conductor.log" or a message returned from Nova API contains the following error:: NoValidHost: No valid host was found. There are not enough hosts available. "No valid host was found" means that the Nova Scheduler could not find a bare metal node suitable for booting the new instance. This in turn usually means some mismatch between resources that Nova expects to find and resources that Ironic advertised to Nova. A few things should be checked in this case: #. Make sure that enough nodes are in ``available`` state, not in maintenance mode and not already used by an existing instance. Check with the following command:: openstack baremetal node list --provision-state available --no-maintenance --unassociated If this command does not show enough nodes, use generic ``openstack baremetal node list`` to check other nodes. For example, nodes in ``manageable`` state should be made available:: openstack baremetal node provide The Bare metal service automatically puts a node in maintenance mode if there are issues with accessing its management interface. Check the power credentials (e.g. ``ipmi_address``, ``ipmi_username`` and ``ipmi_password``) and then move the node out of maintenance mode:: openstack baremetal node maintenance unset The ``node validate`` command can be used to verify that all required fields are present. The following command should not return anything:: openstack baremetal node validate | grep -E '(power|management)\W*False' Maintenance mode will be also set on a node if automated cleaning has failed for it previously. #. Make sure that you have Compute services running and enabled:: $ openstack compute service list --service nova-compute +----+--------------+-------------+------+---------+-------+----------------------------+ | ID | Binary | Host | Zone | Status | State | Updated At | +----+--------------+-------------+------+---------+-------+----------------------------+ | 7 | nova-compute | example.com | nova | enabled | up | 2017-09-04T13:14:03.000000 | +----+--------------+-------------+------+---------+-------+----------------------------+ By default, a Compute service is disabled after 10 consecutive build failures on it. This is to ensure that new build requests are not routed to a broken Compute service. If it is the case, make sure to fix the source of the failures, then re-enable it:: openstack compute service set --enable nova-compute #. Starting with the Pike release, check that all your nodes have the ``resource_class`` field set using the following command:: openstack --os-baremetal-api-version 1.21 baremetal node list --fields uuid name resource_class Then check that the flavor(s) are configured to request these resource classes via their properties:: openstack flavor show -f value -c properties For example, if your node has resource class ``baremetal-large``, it will be matched by a flavor with property ``resources:CUSTOM_BAREMETAL_LARGE`` set to ``1``. See :doc:`/install/configure-nova-flavors` for more details on the correct configuration. #. If you do not use scheduling based on resource classes, then the node's properties must have been set either manually or via inspection. For each node with ``available`` state check that the ``properties`` JSON field has valid values for the keys ``cpus``, ``cpu_arch``, ``memory_mb`` and ``local_gb``. Example of valid properties:: $ openstack baremetal node show --fields properties +------------+------------------------------------------------------------------------------------+ | Property | Value | +------------+------------------------------------------------------------------------------------+ | properties | {u'memory_mb': u'8192', u'cpu_arch': u'x86_64', u'local_gb': u'41', u'cpus': u'4'} | +------------+------------------------------------------------------------------------------------+ .. warning:: If you're using exact match filters in the Nova Scheduler, make sure the flavor and the node properties match exactly. #. The Nova flavor that you are using does not match any properties of the available Ironic nodes. Use :: openstack flavor show to compare. The extra specs in your flavor starting with ``capability:`` should match ones in ``node.properties['capabilities']``. .. note:: The format of capabilities is different in Nova and Ironic. E.g. in Nova flavor:: $ openstack flavor show -c properties +------------+----------------------------------+ | Field | Value | +------------+----------------------------------+ | properties | capabilities:boot_option='local' | +------------+----------------------------------+ But in Ironic node:: $ openstack baremetal node show --fields properties +------------+-----------------------------------------+ | Property | Value | +------------+-----------------------------------------+ | properties | {u'capabilities': u'boot_option:local'} | +------------+-----------------------------------------+ #. After making changes to nodes in Ironic, it takes time for those changes to propagate from Ironic to Nova. Check that :: openstack hypervisor stats show correctly shows total amount of resources in your system. You can also check ``openstack hypervisor show `` to see the status of individual Ironic nodes as reported to Nova. .. TODO(dtantsur): explain inspecting the placement API #. Figure out which Nova Scheduler filter ruled out your nodes. Check the ``nova-scheduler`` logs for lines containing something like:: Filter ComputeCapabilitiesFilter returned 0 hosts The name of the filter that removed the last hosts may give some hints on what exactly was not matched. See `Nova filters documentation `_ for more details. #. If none of the above helped, check Ironic conductor log carefully to see if there are any conductor-related errors which are the root cause for "No valid host was found". If there are any "Error in deploy of node : [Errno 28] ..." error messages in Ironic conductor log, it means the conductor run into a special error during deployment. So you can check the log carefully to fix or work around and then try again. Patching the Deploy Ramdisk =========================== When debugging a problem with deployment and/or inspection you may want to quickly apply a change to the ramdisk to see if it helps. Of course you can inject your code and/or SSH keys during the ramdisk build (depends on how exactly you've built your ramdisk). But it's also possible to quickly modify an already built ramdisk. Create an empty directory and unpack the ramdisk content there:: mkdir unpack cd unpack gzip -dc /path/to/the/ramdisk | cpio -id The last command will result in the whole Linux file system tree unpacked in the current directory. Now you can modify any files you want. The actual location of the files will depend on the way you've built the ramdisk. After you've done the modifications, pack the whole content of the current directory back:: find . | cpio -H newc -o | gzip -c > /path/to/the/new/ramdisk .. note:: You don't need to modify the kernel (e.g. ``tinyipa-master.vmlinuz``), only the ramdisk part. .. note:: For CoreOS-based ramdisk you also need to unpack and pack back the squashfs archive inside the unpacked ramdisk. API Errors ========== The `debug_tracebacks_in_api` config option may be set to return tracebacks in the API response for all 4xx and 5xx errors. .. _retrieve_deploy_ramdisk_logs: Retrieving logs from the deploy ramdisk ======================================= When troubleshooting deployments (specially in case of a deploy failure) it's important to have access to the deploy ramdisk logs to be able to identify the source of the problem. By default, Ironic will retrieve the logs from the deploy ramdisk when the deployment fails and save it on the local filesystem at ``/var/log/ironic/deploy``. To change this behavior, operators can make the following changes to ``/etc/ironic/ironic.conf`` under the ``[agent]`` group: * ``deploy_logs_collect``: Whether Ironic should collect the deployment logs on deployment. Valid values for this option are: * ``on_failure`` (**default**): Retrieve the deployment logs upon a deployment failure. * ``always``: Always retrieve the deployment logs, even if the deployment succeed. * ``never``: Disable retrieving the deployment logs. * ``deploy_logs_storage_backend``: The name of the storage backend where the logs will be stored. Valid values for this option are: * ``local`` (**default**): Store the logs in the local filesystem. * ``swift``: Store the logs in Swift. * ``deploy_logs_local_path``: The path to the directory where the logs should be stored, used when the ``deploy_logs_storage_backend`` is configured to ``local``. By default logs will be stored at **/var/log/ironic/deploy**. * ``deploy_logs_swift_container``: The name of the Swift container to store the logs, used when the deploy_logs_storage_backend is configured to "swift". By default **ironic_deploy_logs_container**. * ``deploy_logs_swift_days_to_expire``: Number of days before a log object is marked as expired in Swift. If None, the logs will be kept forever or until manually deleted. Used when the deploy_logs_storage_backend is configured to "swift". By default **30** days. When the logs are collected, Ironic will store a *tar.gz* file containing all the logs according to the ``deploy_logs_storage_backend`` configuration option. All log objects will be named with the following pattern:: [_]_.tar.gz .. note:: The *instance_uuid* field is not required for deploying a node when Ironic is configured to be used in standalone mode. If present it will be appended to the name. Accessing the log data ---------------------- When storing in the local filesystem ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When storing the logs in the local filesystem, the log files can be found at the path configured in the ``deploy_logs_local_path`` configuration option. For example, to find the logs from the node ``5e9258c4-cfda-40b6-86e2-e192f523d668``: .. code-block:: bash $ ls /var/log/ironic/deploy | grep 5e9258c4-cfda-40b6-86e2-e192f523d668 5e9258c4-cfda-40b6-86e2-e192f523d668_88595d8a-6725-4471-8cd5-c0f3106b6898_2016-08-08-13:52:12.tar.gz 5e9258c4-cfda-40b6-86e2-e192f523d668_db87f2c5-7a9a-48c2-9a76-604287257c1b_2016-08-08-14:07:25.tar.gz .. note:: When saving the logs to the filesystem, operators may want to enable some form of rotation for the logs to avoid disk space problems. When storing in Swift ~~~~~~~~~~~~~~~~~~~~~ When using Swift, operators can associate the objects in the container with the nodes in Ironic and search for the logs for the node ``5e9258c4-cfda-40b6-86e2-e192f523d668`` using the **prefix** parameter. For example: .. code-block:: bash $ swift list ironic_deploy_logs_container -p 5e9258c4-cfda-40b6-86e2-e192f523d668 5e9258c4-cfda-40b6-86e2-e192f523d668_88595d8a-6725-4471-8cd5-c0f3106b6898_2016-08-08-13:52:12.tar.gz 5e9258c4-cfda-40b6-86e2-e192f523d668_db87f2c5-7a9a-48c2-9a76-604287257c1b_2016-08-08-14:07:25.tar.gz To download a specific log from Swift, do: .. code-block:: bash $ swift download ironic_deploy_logs_container "5e9258c4-cfda-40b6-86e2-e192f523d668_db87f2c5-7a9a-48c2-9a76-604287257c1b_2016-08-08-14:07:25.tar.gz" 5e9258c4-cfda-40b6-86e2-e192f523d668_db87f2c5-7a9a-48c2-9a76-604287257c1b_2016-08-08-14:07:25.tar.gz [auth 0.341s, headers 0.391s, total 0.391s, 0.531 MB/s] The contents of the log file ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The log is just a ``.tar.gz`` file that can be extracted as: .. code-block:: bash $ tar xvf The contents of the file may differ slightly depending on the distribution that the deploy ramdisk is using: * For distributions using ``systemd`` there will be a file called **journal** which contains all the system logs collected via the ``journalctl`` command. * For other distributions, the ramdisk will collect all the contents of the ``/var/log`` directory. For all distributions, the log file will also contain the output of the following commands (if present): ``ps``, ``df``, ``ip addr`` and ``iptables``. Here's one example when extracting the content of a log file for a distribution that uses ``systemd``: .. code-block:: bash $ tar xvf 5e9258c4-cfda-40b6-86e2-e192f523d668_88595d8a-6725-4471-8cd5-c0f3106b6898_2016-08-08-13:52:12.tar.gz df ps journal ip_addr iptables DHCP during PXE or iPXE is inconsistent or unreliable ===================================================== This can be caused by the spanning tree protocol delay on some switches. The delay prevents the switch port moving to forwarding mode during the nodes attempts to PXE, so the packets never make it to the DHCP server. To resolve this issue you should set the switch port that connects to your baremetal nodes as an edge or PortFast type port. Configured in this way the switch port will move to forwarding mode as soon as the link is established. An example on how to do that for a Cisco Nexus switch is: .. code-block:: bash $ config terminal $ (config) interface eth1/11 $ (config-if) spanning-tree port type edge ironic-10.1.1/doc/source/admin/index.rst0000666000175100017510000000226613243617463020120 0ustar zuulzuul00000000000000Administrator's Guide ===================== If you are a system administrator running Ironic, this section contains information that may help you understand how to operate and upgrade the services. .. toctree:: :maxdepth: 1 Drivers, Hardware Types and Hardware Interfaces Ironic Python Agent Node Hardware Inspection Node Cleaning Node Adoption RAID Configuration Configuring to boot from volume Multi-tenant Networking Port Groups Configuring Web or Serial Console Enabling Notifications Ceph Object Gateway Emitting Software Metrics Auditing API Traffic Service State Reporting Upgrade Guide Security Troubleshooting FAQ Dashboard Integration --------------------- A plugin for the OpenStack Dashboard (horizon) service is under development. Documentation for that can be found within the ironic-ui project. .. toctree:: :maxdepth: 1 Dashboard (horizon) plugin ironic-10.1.1/doc/source/admin/drivers/0000775000175100017510000000000013243617733017725 5ustar zuulzuul00000000000000ironic-10.1.1/doc/source/admin/drivers/ipa.rst0000666000175100017510000001273713243617463021244 0ustar zuulzuul00000000000000=================== Ironic Python Agent =================== Overview ======== *Ironic Python Agent* (also often called *IPA* or just *agent*) is a Python-based agent which handles *ironic* bare metal nodes in a variety of actions such as inspect, configure, clean and deploy images. IPA is distributed over nodes and runs, inside of a ramdisk, the process of booting this ramdisk on the node. For more information see the `ironic-python-agent documentation `_. Drivers ======= Starting with the Kilo release all deploy interfaces (except for fake ones) are using IPA. There are two types of them: * For nodes using the :ref:`iscsi-deploy` interface, IPA exposes the root hard drive as an iSCSI share and calls back to the ironic conductor. The conductor mounts the share and copies an image there. It then signals back to IPA for post-installation actions like setting up a bootloader for local boot support. * For nodes using the :ref:`direct-deploy` interface, the conductor prepares a swift temporary URL for an image. IPA then handles the whole deployment process: downloading an image from swift, putting it on the machine and doing any post-deploy actions. Which one to choose depends on your environment. :ref:`iscsi-deploy` puts higher load on conductors, :ref:`direct-deploy` currently requires the whole image to fit in the node's memory, except when using raw images. It also requires :doc:`/install/configure-glance-swift`. .. todo: other differences? Requirements ------------ Using IPA requires it to be present and configured on the deploy ramdisk, see :ref:`deploy-ramdisk` Using proxies for image download ================================ Overview -------- When using the :ref:`direct-deploy`, IPA supports using proxies for downloading the user image. For example, this could be used to speed up download by using a caching proxy. Steps to enable proxies ----------------------- #. Configure the proxy server of your choice (for example `Squid `_, `Apache Traffic Server `_). This will probably require you to configure the proxy server to cache the content even if the requested URL contains a query, and to raise the maximum cached file size as images can be pretty big. If you have HTTPS enabled in swift (see `swift deployment guide `_), it is possible to configure the proxy server to talk to swift via HTTPS to download the image, store it in the cache unencrypted and return it to the node via HTTPS again. Because the image will be stored unencrypted in the cache, this approach is recommended for images that do not contain sensitive information. Refer to your proxy server's documentation to complete this step. #. Set ``[glance]swift_temp_url_cache_enabled`` in the ironic conductor config file to ``True``. The conductor will reuse the cached swift temporary URLs instead of generating new ones each time an image is requested, so that the proxy server does not create new cache entries for the same image, based on the query part of the URL (as it contains some query parameters that change each time it is regenerated). #. Set ``[glance]swift_temp_url_expected_download_start_delay`` option in the ironic conductor config file to the value appropriate for your hardware. This is the delay (in seconds) from the time of the deploy request (when the swift temporary URL is generated) to when the URL is used for the image download. You can think of it as roughly the time needed for IPA ramdisk to startup and begin download. This value is used to check if the swift temporary URL duration is large enough to let the image download begin. Also if temporary URL caching is enabled, this will determine if a cached entry will still be valid when the download starts. It is used only if ``[glance]swift_temp_url_cache_enabled`` is ``True``. #. Increase ``[glance]swift_temp_url_duration`` option in the ironic conductor config file, as only non-expired links to images will be returned from the swift temporary URLs cache. This means that if ``swift_temp_url_duration=1200`` then after 20 minutes a new image will be cached by the proxy server as the query in its URL will change. The value of this option must be greater than or equal to ``[glance]swift_temp_url_expected_download_start_delay``. #. Add one or more of ``image_http_proxy``, ``image_https_proxy``, ``image_no_proxy`` to driver_info properties in each node that will use the proxy. Advanced configuration ====================== Out-of-band vs. in-band power off on deploy ------------------------------------------- After deploying an image onto the node's hard disk, Ironic will reboot the machine into the new image. By default this power action happens ``in-band``, meaning that the ironic-conductor will instruct the IPA ramdisk to power itself off. Some hardware may have a problem with the default approach and would require Ironic to talk directly to the management controller to switch the power off and on again. In order to tell Ironic to do that, you have to update the node's ``driver_info`` field and set the ``deploy_forces_oob_reboot`` parameter with the value of **True**. For example, the below command sets this configuration in a specific node:: openstack baremetal node set --driver-info deploy_forces_oob_reboot=True ironic-10.1.1/doc/source/admin/drivers/idrac.rst0000666000175100017510000000314713243617471021547 0ustar zuulzuul00000000000000============= iDRAC drivers ============= Overview ======== iDRAC_ hardware is supported by the ``idrac`` hardware type and the following classic drivers: * ``pxe_drac`` (using out-of-band inspection) * ``pxe_drac_inspector`` (using in-band inspection via **ironic-inspector**) It is also supported by the standard ``ipmi`` hardware type, though with a smaller feature set. .. TODO(dtantsur): supported hardware Enabling ======== All iDRAC drivers require the ``python-dracclient`` library to be installed, for example:: sudo pip install 'python-dracclient>=1.3.0' To enable the ``idrac`` hardware type, add the following to your ``/etc/ironic/ironic.conf``: .. code-block:: ini [DEFAULT] enabled_hardware_types=idrac enabled_management_interfaces=idrac enabled_power_interfaces=idrac To enable all optional features (inspection, RAID and vendor passthru), use the following configuration: .. code-block:: ini [DEFAULT] enabled_hardware_types=idrac enabled_inspect_interfaces=idrac enabled_management_interfaces=idrac enabled_power_interfaces=idrac enabled_raid_interfaces=idrac enabled_vendor_interfaces=idrac Enrolling ========= The following command will enroll a bare metal node with the ``idrac`` hardware type:: openstack baremetal node create --driver idrac \ --driver-info drac_address=http://drac.host \ --driver-info drac_username=user \ --driver-info drac_password=pa$$w0rd .. TODO(dtantsur): describe RAID support and inspection .. _iDRAC: http://www.dell.com/learn/us/en/15/solutions/integrated-dell-remote-access-controller-idrac ironic-10.1.1/doc/source/admin/drivers/redfish.rst0000666000175100017510000000657713243617463022124 0ustar zuulzuul00000000000000============== Redfish driver ============== Overview ======== The ``redfish`` driver enables managing servers compliant with the Redfish_ protocol. Prerequisites ============= * The Sushy_ library should be installed on the ironic conductor node(s). For example, it can be installed with ``pip``:: sudo pip install sushy Enabling the Redfish driver =========================== #. Add ``redfish`` to the list of ``enabled_hardware_types``, ``enabled_power_interfaces`` and ``enabled_management_interfaces`` in ``/etc/ironic/ironic.conf``. For example:: [DEFAULT] ... enabled_hardware_types = ipmi,redfish enabled_power_interfaces = ipmitool,redfish enabled_management_interfaces = ipmitool,redfish #. Restart the ironic conductor service:: sudo service ironic-conductor restart # Or, for RDO: sudo systemctl restart openstack-ironic-conductor Registering a node with the Redfish driver =========================================== Nodes configured to use the driver should have the ``driver`` property set to ``redfish``. The following properties are specified in the node's ``driver_info`` field: - ``redfish_address``: The URL address to the Redfish controller. It must include the authority portion of the URL, and can optionally include the scheme. If the scheme is missing, https is assumed. For example: https://mgmt.vendor.com. This is required. - ``redfish_system_id``: The canonical path to the System resource that the driver will interact with. It should include the root service, version and the unique resource path to the System. For example: /redfish/v1/Systems/1. This is required. - ``redfish_username``: User account with admin/server-profile access privilege. Although not required, it is highly recommended. - ``redfish_password``: User account password. Although not required, it is highly recommended. - ``redfish_verify_ca``: If redfish_address has the **https** scheme, the driver will use a secure (TLS_) connection when talking to the Redfish controller. By default (if this is not set or set to True), the driver will try to verify the host certificates. This can be set to the path of a certificate file or directory with trusted certificates that the driver will use for verification. To disable verifying TLS_, set this to False. This is optional. The ``openstack baremetal node create`` command can be used to enroll a node with the ``redfish`` driver. For example: .. code-block:: bash openstack baremetal node create --driver redfish --driver-info \ redfish_address=https://example.com --driver-info \ redfish_system_id=/redfish/v1/Systems/CX34R87 --driver-info \ redfish_username=admin --driver-info redfish_password=password For more information about enrolling nodes see :ref:`enrollment` in the install guide. .. _Redfish: http://redfish.dmtf.org/ .. _Sushy: https://git.openstack.org/cgit/openstack/sushy .. _TLS: https://en.wikipedia.org/wiki/Transport_Layer_Security ironic-10.1.1/doc/source/admin/drivers/oneview.rst0000666000175100017510000003613313243617463022143 0ustar zuulzuul00000000000000.. _oneview: =============== OneView drivers =============== Overview ======== HP OneView [1]_ is a single integrated platform, packaged as an appliance that implements a software-defined approach to managing physical infrastructure. The appliance supports scenarios such as deploying bare metal servers, for instance. In this context, the ``HP OneView driver`` for ironic enables the users of OneView to use ironic as a bare metal provider to their managed physical hardware. HPE OneView hardware is supported by the ``oneview`` hardware type and the following classic drivers: * ``iscsi_pxe_oneview`` * ``agent_pxe_oneview`` Classic Drivers =============== The ``iscsi_pxe_oneview`` and ``agent_pxe_oneview`` drivers implement the core interfaces of an ironic Driver [2]_, and use the ``hpOneView`` [3]_ library to provide communication between ironic and OneView through OneView's REST API. .. note:: Classic drivers will be deprecated in favor of Hardware Types. To provide a bare metal instance there are four components involved in the process: * The ironic service * The ironic-inspector service (if using hardware inspection) * The ironic driver for OneView, which can be: * `iscsi_pxe_oneview` or * `agent_pxe_oneview` * The hpOneView library * The OneView appliance The role of ironic is to serve as a bare metal provider to OneView's managed physical hardware and to provide communication with other necessary OpenStack services such as Nova and Glance. When ironic receives a boot request, it works together with the ironic OneView driver to access a machine in OneView, the ``hpOneView`` being responsible for the communication with the OneView appliance. From the Newton release on, OneView drivers enables a new feature called **dynamic allocation** of nodes [6]_. In this model, the driver allocates resources in OneView only at boot time, allowing idle resources in ironic to be used by OneView users, enabling actual resource sharing among ironic and OneView users. Since OneView can claim nodes in ``available`` state at any time, a set of tasks runs periodically to detect nodes in use by OneView. A node in use by OneView is placed in ``manageable`` state and has maintenance mode set. Once the node is no longer in use, these tasks will make place them back in ``available`` state and clear maintenance mode. Prerequisites ============= The following requirements apply for both ``iscsi_pxe_oneview`` and ``agent_pxe_oneview`` drivers: * ``OneView appliance`` is the HP physical infrastructure manager to be integrated with the OneView drivers. Minimum version supported is 2.0. * ``hpOneView`` is a python package containing a client to manage the communication between ironic and OneView. Install the ``hpOneView`` module to enable the communication. Minimum version required is 4.4.0 but it is recommended to install the most up-to-date version:: $ pip install "hpOneView>=4.4.0" * ``ironic-inspector`` if using hardware inspection. Tested platforms ================ * The OneView appliance used for testing was the OneView 2.0. * The Enclosure used for testing was the ``BladeSystem c7000 Enclosure G2``. * The drivers should work on HP Proliant Gen8 and Gen9 Servers supported by OneView 2.0 and above, or any hardware whose network can be managed by OneView's ServerProfile. It has been tested with the following servers: - Proliant BL460c Gen8 - Proliant BL460c Gen9 - Proliant BL465c Gen8 - Proliant DL360 Gen9 Notice that for the driver to work correctly with Gen8 and Gen9 DL servers in general, the hardware also needs to run version 4.2.3 of iLO, with Redfish enabled. Hardware Interfaces =================== The ``oneview`` hardware type supports the following hardware interfaces: * boot Supports only ``pxe``. It can be enabled by using the ``[DEFAULT]enabled_boot_interfaces`` option in ``ironic.conf`` as given below: .. code-block:: ini [DEFAULT] enabled_hardware_types = oneview enabled_boot_interfaces = pxe * console Supports only ``no-console``. It can be enabled by using the ``[DEFAULT]enabled_console_interfaces`` option in ``ironic.conf`` as given below: .. code-block:: ini [DEFAULT] enabled_hardware_types = oneview enabled_console_interfaces = no-console * deploy Supports ``oneview-direct`` and ``oneview-iscsi``. The default is ``oneview-iscsi``. They can be enabled by using the ``[DEFAULT]enabled_deploy_interfaces`` option in ``ironic.conf`` as given below: .. code-block:: ini [DEFAULT] enabled_hardware_types = oneview enabled_deploy_interfaces = oneview-iscsi,oneview-direct * inspect Supports ``oneview`` and ``no-inspect``. The default is ``oneview``. They can be enabled by using the ``[DEFAULT]enabled_inspect_interfaces`` option in ``ironic.conf`` as given below: .. code-block:: ini [DEFAULT] enabled_hardware_types = oneview enabled_inspect_interfaces = oneview,no-inspect * management Supports only ``oneview``. It can be enabled by using the ``[DEFAULT]enabled_management_interfaces`` option in ``ironic.conf`` as given below: .. code-block:: ini [DEFAULT] enabled_hardware_types = oneview enabled_management_interfaces = oneview * power Supports only ``oneview``. It can be enabled by using the ``[DEFAULT]enabled_power_interfaces`` option in ``ironic.conf`` as given below: .. code-block:: ini [DEFAULT] enabled_hardware_types = oneview enabled_power_interfaces = oneview The ``oneview`` hardware type also supports the standard *network* and *storage* interfaces. To enable the same feature set as provided by all oneview classic drivers, apply the following configuration: .. code-block:: ini [DEFAULT] enabled_hardware_types = oneview enabled_deploy_interfaces = oneview-direct,oneview-iscsi enabled_inspect_interfaces = oneview enabled_power_interfaces = oneview enabled_management_interfaces = oneview The following commands can be used to enroll a node with the same feature set as one of the classic drivers, but using the ``oneview`` hardware type: * ``oneview-direct``: .. code-block:: console openstack baremetal node create --os-baremetal-api-version=1.31 \ --driver oneview \ --deploy-interface oneview-direct * ``oneview-iscsi``: .. code-block:: console openstack baremetal node create --os-baremetal-api-version=1.31 \ --driver oneview \ --deploy-interface oneview-iscsi Drivers ======= iscsi_pxe_oneview driver ^^^^^^^^^^^^^^^^^^^^^^^^ Overview ~~~~~~~~ ``iscsi_pxe_oneview`` driver uses PXEBoot for boot and ISCSIDeploy for deploy. Configuring and enabling the driver ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Add ``iscsi_pxe_oneview`` to the list of ``enabled_drivers`` in your ``ironic.conf`` file. For example:: enabled_drivers = iscsi_pxe_oneview 2. Update the [oneview] section of your ``ironic.conf`` file with your OneView credentials and CA certificate files information. .. note:: An operator can set the ``periodic_check_interval`` option in the [oneview] section to set the interval between running the periodic check. The default value is 300 seconds (5 minutes). A lower value will reduce the likelihood of races between ironic and OneView at the cost of being more resource intensive. 3. Restart the ironic conductor service. For Ubuntu users, do:: $ sudo service ironic-conductor restart See :doc:`/install/index` for more information. Deploy process ~~~~~~~~~~~~~~ Here is an overview of the deploy process for this driver: 1. Admin configures the Proliant baremetal node to use ``iscsi_pxe_oneview`` driver. 2. ironic gets a request to deploy a Glance image on the baremetal node. 3. Driver sets the boot device to PXE. 4. Driver powers on the baremetal node. 5. ironic downloads the deploy and user images from a TFTP server. 6. Driver reboots the baremetal node. 7. User image is now deployed. 8. Driver powers off the machine. 9. Driver sets boot device to Disk. 10. Driver powers on the machine. 11. Baremetal node is active and ready to be used. agent_pxe_oneview driver ^^^^^^^^^^^^^^^^^^^^^^^^ Overview ~~~~~~~~ ``agent_pxe_oneview`` driver uses PXEBoot for boot and AgentDeploy for deploy. Configuring and enabling the driver ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Add ``agent_pxe_oneview`` to the list of ``enabled_drivers`` in your ``ironic.conf``. For example:: enabled_drivers = fake,pxe_ipmitool,agent_pxe_oneview 2. Update the [oneview] section of your ``ironic.conf`` file with your OneView credentials and CA certificate files information. .. note:: An operator can set the ``periodic_check_interval`` option in the [oneview] section to set the interval between running the periodic check. The default value is 300 seconds (5 minutes). A lower value will reduce the likelihood of races between ironic and OneView at the cost of being more resource intensive. 3. Restart the ironic conductor service. For Ubuntu users, do:: $ service ironic-conductor restart See :doc:`/install/index` for more information. Deploy process ~~~~~~~~~~~~~~ Here is an overview of the deploy process for this driver: 1. Admin configures the Proliant baremetal node to use ``agent_pxe_oneview`` driver. 2. ironic gets a request to deploy a Glance image on the baremetal node. 3. Driver sets the boot device to PXE. 4. Driver powers on the baremetal node. 5. Node downloads the agent deploy images. 6. Agent downloads the user images and writes it to disk. 7. Driver reboots the baremetal node. 8. User image is now deployed. 9. Driver powers off the machine. 10. Driver sets boot device to Disk. 11. Driver powers on the machine. 12. Baremetal node is active and ready to be used. Hardware inspection =================== OneView drivers for ironic have the ability to do hardware inspection. Hardware inspection is the process of discovering hardware properties like memory size, CPU cores, processor architecture and disk size, of a given hardware. OneView drivers do in-band inspection, that involves booting a ramdisk on the hardware and fetching information directly from it. For that, your cloud controller needs to have the ``ironic-inspector`` component [9]_ running and properly enabled in ironic's configuration file. See [10]_ for more information on how to install and configure ``ironic-inspector``. Registering a OneView node in ironic ==================================== Nodes configured to use any of the OneView drivers should have the ``driver`` property set to ``iscsi_pxe_oneview`` or ``agent_pxe_oneview``. Considering our context, a node is the representation of a ``Server Hardware`` in OneView, and should be consistent with all its properties and related components, such as ``Server Hardware Type``, ``Server Profile Template``, ``Enclosure Group``, etc. In this case, to be enrolled, the node must have the following parameters: * In ``driver_info`` - ``server_hardware_uri``: URI of the ``Server Hardware`` on OneView. * In ``properties/capabilities`` - ``server_hardware_type_uri``: URI of the ``Server Hardware Type`` of the ``Server Hardware``. - ``server_profile_template_uri``: URI of the ``Server Profile Template`` used to create the ``Server Profile`` of the ``Server Hardware``. - ``enclosure_group_uri`` (optional): URI of the ``Enclosure Group`` of the ``Server Hardware``. To enroll a node with any of the OneView drivers, do:: $ openstack baremetal node create --driver $DRIVER_NAME To update the ``driver_info`` field of a newly enrolled OneView node, do:: $ openstack baremetal node set $NODE_UUID --driver-info server_hardware_uri=$SH_URI To update the ``properties/capabilities`` namespace of a newly enrolled OneView node, do:: $ openstack baremetal node set $NODE_UUID \ --property capabilities=server_hardware_type_uri:$SHT_URI,enclosure_group_uri:$EG_URI,server_profile_template_uri=$SPT_URI In order to deploy, ironic will create and apply, at boot time, a ``Server Profile`` based on the ``Server Profile Template`` specified on the node to the ``Server Hardware`` it represents on OneView. The URI of such ``Server Profile`` will be stored in ``driver_info.applied_server_profile_uri`` field while the Server is allocated to ironic. The ``Server Profile Templates`` and, therefore, the ``Server Profiles`` derived from them MUST comply with the following requirements: * The option `MAC Address` in the `Advanced` section of ``Server Profile``/``Server Profile Template`` should be set to `Physical` option; * Their first `Connection` interface should be: * Connected to ironic's provisioning network and; * The `Boot` option should be set to primary. Node ports should be created considering the **MAC address of the first Interface** of the given ``Server Hardware``. To tell ironic which NIC should be connected to the provisioning network, do:: $ openstack baremetal port create --node $NODE_UUID $MAC_ADDRESS For more information on the enrollment process of an ironic node, see :ref:`enrollment`. For more information on the definitions of ``Server Hardware``, ``Server Profile``, ``Server Profile Template`` and other OneView entities, refer to [1]_ or browse Help in your OneView appliance menu. .. note:: Ironic manages OneView machines either when they have a Server Profile applied by the driver or when they don't have any Server Profile. Trying to change the power state of the machine in OneView without first assigning a Server Profile will lead to allowing Ironic to revert the power state change. Ironic will NOT change the power state of machines which the Server Profile was applied by another OneView user. 3rd Party Tools =============== In order to ease user manual tasks, which are often time-consuming, we provide useful tools that work nicely with the OneView drivers. ironic-oneview-cli ^^^^^^^^^^^^^^^^^^ The ``ironic-oneView`` CLI is a command line interface for management tasks involving OneView nodes. Its features include a facility to create of ironic nodes with all required parameters for OneView nodes, creation of Nova flavors for OneView nodes. For more details on how Ironic-OneView CLI works and how to set it up, see [8]_. ironic-oneviewd ^^^^^^^^^^^^^^^ The ``ironic-oneviewd`` daemon monitors the ironic inventory of resources and provides facilities to operators managing OneView driver deployments. For more details on how Ironic-OneViewd works and how to set it up, see [7]_. References ========== .. [1] HP OneView - https://www.hpe.com/us/en/integrated-systems/software.html .. [2] :ref:`architecture_drivers` .. [3] hpOneView - https://pypi.python.org/pypi/hpOneView .. [6] Dynamic Allocation in OneView drivers - http://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/oneview-drivers-dynamic-allocation.html .. [7] ironic-oneviewd - https://pypi.python.org/pypi/ironic-oneviewd/ .. [8] ironic-oneview-cli - https://pypi.python.org/pypi/ironic-oneview-cli/ .. [9] ironic-inspector - https://docs.openstack.org/ironic-inspector/latest/ .. [10] ironic-inspector install - https://docs.openstack.org/ironic-inspector/latest/install/index.html ironic-10.1.1/doc/source/admin/drivers/ansible.rst0000666000175100017510000004206213243617463022102 0ustar zuulzuul00000000000000======================== Ansible deploy interface ======================== `Ansible`_ is a mature and popular automation tool, written in Python and requiring no agents running on the node being configured. All communications with the node are by default performed over secure SSH transport. The ``ansible`` deploy interface uses Ansible playbooks to define the deployment logic. It is not based on `Ironic Python Agent`_ (IPA) and does not generally need IPA to be running in the deploy ramdisk. Overview ======== The main advantage of this deploy interface is extended flexibility in regards to changing and adapting node deployment logic for specific use cases, via Ansible tooling that is already familiar to operators. It can be used to shorten the usual feature development cycle of * implementing logic in ironic, * implementing logic in IPA, * rebuilding deploy ramdisk, * uploading deploy ramdisk to Glance/HTTP storage, * reassigning deploy ramdisk to nodes, * restarting ironic-conductor service(s) and * running a test deployment by using a "stable" deploy ramdisk and not requiring ironic-conductor restarts (see `Extending playbooks`_). The main disadvantage of this deploy interface is the synchronous manner of performing deployment/cleaning tasks. A separate ``ansible-playbook`` process is spawned for each node being provisioned or cleaned, which consumes one thread from the thread pool available to the ``ironic-conductor`` process and blocks this thread until the node provisioning or cleaning step is finished or fails. This has to be taken into account when planning an ironic deployment that enables this deploy interface. Each action (deploy, clean) is described by a single playbook with roles, which is run whole during deployment, or tag-wise during cleaning. Control of cleaning steps is through tags and auxiliary clean steps file. The playbooks for actions can be set per-node, as can the clean steps file. Features -------- Similar to deploy interfaces relying on `Ironic Python Agent`_, this deploy interface also depends on the deploy ramdisk calling back to ironic API's ``heartbeat`` endpoint. However, the driver is currently synchronous, so only the first heartbeat is processed and is used as a signal to start ``ansible-playbook`` process. User images ~~~~~~~~~~~ Supports whole-disk images and partition images: - compressed images are downloaded to RAM and converted to disk device; - raw images are streamed to disk directly. For partition images the driver will create root partition, and, if requested, ephemeral and swap partitions as set in node's ``instance_info`` by the Compute service or operator. The create partition table will be of ``msdos`` type by default, the node's ``disk_label`` capability is honored if set in node's ``instance_info`` (see also :ref:`choosing_the_disk_label`). Configdrive partition ~~~~~~~~~~~~~~~~~~~~~ Creating a configdrive partition is supported for both whole disk and partition images, on both ``msdos`` and ``GPT`` labeled disks. Root device hints ~~~~~~~~~~~~~~~~~ Root device hints are currently supported in their basic form only, with exact matches (see :ref:`root-device-hints` for more details). If no root device hint is provided for the node, the first device returned as part of ``ansible_devices`` fact is used as root device to create partitions on or write the whole disk image to. Node cleaning ~~~~~~~~~~~~~ Cleaning is supported, both automated and manual. The driver has two default clean steps: - wiping device metadata - disk shredding Their priority can be overridden via ``[deploy]\erase_devices_metadata_priority`` and ``[deploy]\erase_devices_priority`` options, respectively, in the ironic configuration file. As in the case of this driver all cleaning steps are known to the ironic-conductor service, booting the deploy ramdisk is completely skipped when there are no cleaning steps to perform. .. note:: Aborting cleaning steps is not supported. Logging ~~~~~~~ Logging is implemented as custom Ansible callback module, that makes use of ``oslo.log`` and ``oslo.config`` libraries and can re-use logging configuration defined in the main ironic configuration file to set logging for Ansible events, or use a separate file for this purpose. It works best when ``journald`` support for logging is enabled. Requirements ============ Ansible Tested with, and targets, Ansible 2.4.x Bootstrap image requirements ---------------------------- - password-less sudo permissions for the user used by Ansible - python 2.7.x - openssh-server - GNU coreutils - utils-linux - parted - gdisk - qemu-utils - python-requests (for ironic callback and streaming image download) - python-netifaces (for ironic callback) A set of scripts to build a suitable deploy ramdisk based on TinyCore Linux and ``tinyipa`` ramdisk, and an element for ``diskimage-builder`` can be found in ironic-staging-drivers_ project but will be eventually migrated to the new ironic-python-agent-builder_ project. Setting up your environment =========================== #. Install ironic (either as part of OpenStack or standalone) - If using ironic as part of OpenStack, ensure that the Image service is configured to use the Object Storage service as backend, and the Bare Metal service is configured accordingly, see :doc:`Configure the Image service for temporary URLs <../../install/configure-glance-swift>`. #. Install Ansible version as specified in ``ironic/driver-requirements.txt`` file #. Edit ironic configuration file A. Add ``ansible`` to the list of deploy interfaces defined in ``[DEFAULT]\enabled_deploy_interfaces`` option. B. Ensure that a hardware type supporting ``ansible`` deploy interface is enabled in ``[DEFAULT]\enabled_hardware_types`` option. C. Modify options in the ``[ansible]`` section of ironic's configuration file if needed (see `Configuration file`_). #. (Re)start ironic-conductor service #. Build suitable deploy kernel and ramdisk images #. Upload them to Glance or put in your HTTP storage #. Create new or update existing nodes to use the enabled driver of your choice and populate `Driver properties for the Node`_ when different from defaults. #. Deploy the node as usual. Ansible-deploy options ---------------------- Configuration file ~~~~~~~~~~~~~~~~~~~ Driver options are configured in ``[ansible]`` section of ironic configuration file, for their descriptions and default values please see `configuration file sample <../../configuration/config.html#ansible>`_. Driver properties for the Node ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Set them per-node via ``openstack baremetal node set`` command, for example: .. code-block:: shell openstack baremetal node set \ --deploy-interface ansible \ --driver-info ansible_username=stack \ --driver-info ansible_key_file=/etc/ironic/id_rsa ansible_username User name to use for Ansible to access the node. Default is taken from ``[ansible]/default_username`` option of the ironic configuration file (defaults to ``ansible``). ansible_key_file Private SSH key used to access the node. Default is taken from ``[ansible]/default_key_file`` option of the ironic configuration file. If neither is set, the default private SSH keys of the user running the ``ironic-conductor`` process will be used. ansible_deploy_playbook Playbook to use when deploying this node. Default is taken from ``[ansible]/default_deploy_playbook`` option of the ironic configuration file (defaults to ``deploy.yaml``). ansible_shutdown_playbook Playbook to use to gracefully shutdown the node in-band. Default is taken from ``[ansible]/default_shutdown_playbook`` option of the ironic configuration file (defaults to ``shutdown.yaml``). ansible_clean_playbook Playbook to use when cleaning the node. Default is taken from ``[ansible]/default_clean_playbook`` option of the ironic configuration file (defaults to ``clean.yaml``). ansible_clean_steps_config Auxiliary YAML file that holds description of cleaning steps used by this node, and defines playbook tags in ``ansible_clean_playbook`` file corresponding to each cleaning step. Default is taken from ``[ansible]/default_clean_steps_config`` option of the ironic configuration file (defaults to ``clean_steps.yaml``). Customizing the deployment logic ================================ Expected playbooks directory layout ----------------------------------- The ``[ansible]\playbooks_path`` option in the ironic configuration file is expected to have a standard layout for an Ansible project with some additions:: | \_ inventory \_ add-ironic-nodes.yaml \_ roles \_ role1 \_ role2 \_ ... | \_callback_plugins \_ ... | \_ library \_ ... The extra files relied by this driver are: inventory Ansible inventory file containing a single entry of ``conductor ansible_connection=local``. This basically defines an alias to ``localhost``. Its purpose is to make logging for tasks performed by Ansible locally and referencing the localhost in playbooks more intuitive. This also suppresses warnings produced by Ansible about ``hosts`` file being empty. add-ironic-nodes.yaml This file contains an Ansible play that populates in-memory Ansible inventory with access information received from the ansible-deploy interface, as well as some per-node variables. Include it in all your custom playbooks as the first play. The default ``deploy.yaml`` playbook is using several smaller roles that correspond to particular stages of deployment process: - ``discover`` - e.g. set root device and image target - ``prepare`` - if needed, prepare system, for example create partitions - ``deploy`` - download/convert/write user image and configdrive - ``configure`` - post-deployment steps, e.g. installing the bootloader Some more included roles are: - ``shutdown`` - used to gracefully power the node off in-band - ``clean`` - defines cleaning procedure, with each clean step defined as separate playbook tag. Extending playbooks ------------------- Most probably you'd start experimenting like this: #. Create a copy of ``deploy.yaml`` playbook *in the same folder*, name it distinctively. #. Create Ansible roles with your customized logic in ``roles`` folder. A. In your custom deploy playbook, replace the ``prepare`` role with your own one that defines steps to be run *before* image download/writing. This is a good place to set facts overriding those provided/omitted by the driver, like ``ironic_partitions`` or ``ironic_root_device``, and create custom partitions or (software) RAIDs. B. In your custom deploy playbook, replace the ``configure`` role with your own one that defines steps to be run *after* image is written to disk. This is a good place for example to configure the bootloader and add kernel options to avoid additional reboots. C. Use those new roles in your new playbook. #. Assign the custom deploy playbook you've created to the node's ``driver_info/ansible_deploy_playbook`` field. #. Run deployment. A. No ironic-conductor restart is necessary. B. A new deploy ramdisk must be built and assigned to nodes only when you want to use a command/script/package not present in the current deploy ramdisk and you can not or do not want to install those at runtime. Variables you have access to ---------------------------- This driver will pass the single JSON-ified extra var argument to Ansible (as in ``ansible-playbook -e ..``). Those values are then accessible in your plays as well (some of them are optional and might not be defined): .. code-block:: yaml ironic: nodes: - ip: "" name: "" user: "" extra: "" image: url: "" disk_format: "" container_format: "" checksum: "" mem_req: "" tags: "" properties: "" configdrive: type: "" location: "" partition_info: label: "" preserve_ephemeral: "" ephemeral_format: "" partitions: "" ``ironic.nodes`` List of dictionaries (currently of only one element) that will be used by ``add-ironic-nodes.yaml`` play to populate in-memory inventory. It also contains a copy of node's ``extra`` field so you can access it in the playbooks. The Ansible's host is set to node's UUID. ``ironic.image`` All fields of node's ``instance_info`` that start with ``image_`` are passed inside this variable. Some extra notes and fields: - ``mem_req`` is calculated from image size (if available) and config option ``[ansible]extra_memory``. - if ``checksum`` is not in the form ``:``, hashing algorithm is assumed to be ``md5`` (default in Glance). - ``validate_certs`` - boolean (``yes/no``) flag that turns validating image store SSL certificate on or off (default is 'yes'). Governed by ``[ansible]image_store_insecure`` option in ironic configuration file. - ``cafile`` - custom CA bundle to use for validating image store SSL certificate. Takes value of ``[ansible]image_store_cafile`` if that is defined. Currently is not used by default playbooks, as Ansible has no way to specify the custom CA bundle to use for single HTTPS actions, however you can use this value in your custom playbooks to for example upload and register this CA in the ramdisk at deploy time. - ``client_cert`` - cert file for client-side SSL authentication. Takes value of ``[ansible]image_store_certfile`` option if defined. Currently is not used by default playbooks, however you can use this value in your custom playbooks. - ``client_key`` - private key file for client-side SSL authentication. Takes value of ``[ansible]image_store_keyfile`` option if defined. Currently is not used by default playbooks, however you can use this value in your custom playbooks. ``ironic.partition_info.partitions`` Optional. List of dictionaries defining partitions to create on the node in the form: .. code-block:: yaml partitions: - name: "" unit: "" size: "" type: "" align: "" format: "" flags: flag_name: "" The driver will populate this list from ``root_gb``, ``swap_mb`` and ``ephemeral_gb`` fields of ``instance_info``. The driver will also prepend the ``bios_grub``-labeled partition when deploying on GPT-labeled disk, and pre-create a 64 MiB partition for configdrive if it is set in ``instance_info``. Please read the documentation included in the ``ironic_parted`` module's source for more info on the module and its arguments. ``ironic.partition_info.ephemeral_format`` Optional. Taken from ``instance_info``, it defines file system to be created on the ephemeral partition. Defaults to the value of ``[pxe]\default_ephemeral_format`` option in ironic configuration file. ``ironic.partition_info.preserve_ephemeral`` Optional. Taken from the ``instance_info``, it specifies if the ephemeral partition must be preserved or rebuilt. Defaults to ``no``. As usual for Ansible playbooks, you also have access to standard Ansible facts discovered by ``setup`` module. Included custom Ansible modules ------------------------------- The provided ``playbooks_path/library`` folder includes several custom Ansible modules used by default implementation of ``deploy`` and ``prepare`` roles. You can use these modules in your playbooks as well. ``stream_url`` Streaming download from HTTP(S) source to the disk device directly, tries to be compatible with Ansible's ``get_url`` module in terms of module arguments. Due to the low level of such operation it is not idempotent. ``ironic_parted`` creates partition tables and partitions with ``parted`` utility. Due to the low level of such operation it is not idempotent. Please read the documentation included in the module's source for more information about this module and its arguments. The name is chosen so that the ``parted`` module included in Ansible is not shadowed. .. _Ansible: http://docs.ansible.com/ansible/latest/index.html .. _Ironic Python Agent: http://docs.openstack.org/developer/ironic-python-agent .. _ironic-staging-drivers: http://git.openstack.org/cgit/openstack/ironic-staging-drivers/tree/imagebuild?h=stable/pike .. _ironic-python-agent-builder: http://git.openstack.org/cgit/openstack/ironic-python-agent-builder ironic-10.1.1/doc/source/admin/drivers/ipmitool.rst0000666000175100017510000001432313243617463022320 0ustar zuulzuul00000000000000=============== IPMITool driver =============== Overview ======== The IPMI_ (Intelligent Platform Management Interface) drivers manage nodes by using IPMI protocol versions 2.0 or 1.5. They use the IPMItool_ utility which is an open-source command-line interface (CLI) for controlling IPMI-enabled devices. The following hardware types and classic drivers use IPMItool for power and management: * hardware types: * ``ipmi`` * classic drivers: * ``agent_ipmitool`` * ``pxe_ipmitool`` * ``agent_ipmitool_socat`` * ``pxe_ipmitool_socat`` Glossary ======== * IPMI_ - Intelligent Platform Management Interface. * IPMB - Intelligent Platform Management Bus/Bridge. * BMC_ - Baseboard Management Controller. * RMCP - Remote Management Control Protocol. Enabling the IPMItool driver(s) =============================== Please see :doc:`/install/configure-ipmi` for the required dependencies. #. The ``ipmi`` hardware type is enabled by default starting with the Ocata release. To enable it explicitly, add the following to your ``ironic.conf``: .. code-block:: ini [DEFAULT] enabled_hardware_types = ipmi #. Restart the Ironic conductor service. Please see :doc:`/install/enabling-drivers` for more details. Registering a node with the IPMItool driver =========================================== Nodes configured to use the IPMItool drivers should have the ``driver`` field set to ``ipmi`` (hardware type) or to the name of one of the classic drivers that support IPMItool. The following configuration value is required and has to be added to the node's ``driver_info`` field: - ``ipmi_address``: The IP address or hostname of the BMC. Other options may be needed to match the configuration of the BMC, the following options are optional, but in most cases, it's considered a good practice to have them set: - ``ipmi_username``: The username to access the BMC; defaults to *NULL* user. - ``ipmi_password``: The password to access the BMC; defaults to *NULL*. - ``ipmi_port``: The remote IPMI RMCP port. By default ipmitool will use the port *623*. .. note:: It is highly recommend that you setup a username and password for your BMC. The ``openstack baremetal node create`` command can be used to enroll a node with an IPMItool-based driver. For example:: openstack baremetal node create --driver ipmi \ --driver-info ipmi_address=
\ --driver-info ipmi_username= \ --driver-info ipmi_password= Advanced configuration ====================== When a simple configuration such as providing the ``address``, ``username`` and ``password`` is not enough, the IPMItool driver contains many other options that can be used to address special usages. Single/Double bridging functionality ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. note:: A version of IPMItool higher or equal to 1.8.12 is required to use the bridging functionality. There are two different bridging functionalities supported by the IPMItool-based drivers: *single* bridge and *dual* bridge. The following configuration values need to be added to the node's ``driver_info`` field so bridging can be used: - ``ipmi_bridging``: The bridging type; default is *no*; other supported values are *single* for single bridge or *dual* for double bridge. - ``ipmi_local_address``: The local IPMB address for bridged requests. Required only if ``ipmi_bridging`` is set to *single* or *dual*. This configuration is optional, if not specified it will be auto discovered by IPMItool. - ``ipmi_target_address``: The destination address for bridged requests. Required only if ``ipmi_bridging`` is set to *single* or *dual*. - ``ipmi_target_channel``: The destination channel for bridged requests. Required only if ``ipmi_bridging`` is set to *single* or *dual*. Double bridge specific options: - ``ipmi_transit_address``: The transit address for bridged requests. Required only if ``ipmi_bridging`` is set to *dual*. - ``ipmi_transit_channel``: The transit channel for bridged requests. Required only if ``ipmi_bridging`` is set to *dual*. The parameter ``ipmi_bridging`` should specify the type of bridging required: *single* or *dual* to access the bare metal node. If the parameter is not specified, the default value will be set to *no*. The ``openstack baremetal node set`` command can be used to set the required bridging information to the Ironic node enrolled with the IPMItool driver. For example: * Single Bridging:: openstack baremetal node set \ --driver-info ipmi_local_address=
\ --driver-info ipmi_bridging=single \ --driver-info ipmi_target_channel= \ --driver-info ipmi_target_address= * Double Bridging:: openstack baremetal node set \ --driver-info ipmi_local_address=
\ --driver-info ipmi_bridging=dual \ --driver-info ipmi_transit_channel= \ --driver-info ipmi_transit_address= \ --driver-info ipmi_target_channel= \ --driver-info ipmi_target_address= Changing the version of the IPMI protocol ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The IPMItool-based drivers works with the versions *2.0* and *1.5* of the IPMI protocol. By default, the version *2.0* is used. In order to change the IPMI protocol version in the bare metal node, the following option needs to be set to the node's ``driver_info`` field: - ``ipmi_protocol_version``: The version of the IPMI protocol; default is *2.0*. Supported values are *1.5* or *2.0*. The ``openstack baremetal node set`` command can be used to set the desired protocol version:: openstack baremetal node set --driver-info ipmi_protocol_version= .. warning:: Version *1.5* of the IPMI protocol does not support encryption. Therefore, it is highly recommended that version 2.0 is used. .. TODO(lucasagomes): Write about privilege level .. TODO(lucasagomes): Write about force boot device .. _IPMItool: https://sourceforge.net/projects/ipmitool/ .. _IPMI: https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface .. _BMC: https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface#Baseboard_management_controller ironic-10.1.1/doc/source/admin/drivers/ucs.rst0000666000175100017510000000674113243617463021263 0ustar zuulzuul00000000000000.. _UCS: =========== UCS drivers =========== Overview ======== The UCS driver is targeted for UCS Manager managed Cisco UCS B/C series servers. The pxe_ucs, agent_ucs drivers enables you to take advantage of UCS Manager by using the python SDK. ``pxe_ucs`` driver uses PXE/iSCSI (just like ``pxe_ipmitool`` driver) to deploy the image and uses UCS to do all management operations on the baremetal node (instead of using IPMI). ``agent_ucs`` driver uses IPA ramdisk (just like ``agent_ipmitool`` and ``agent_ipminative`` drivers.) to deploy the image and uses UCS to do all management operations on the baremetal node (instead of using IPMI). The UCS drivers can use the Ironic Inspector service for in-band inspection of equipment. For more information see the `Ironic Inspector documentation `_. Prerequisites ============= * ``UcsSdk`` is a python package version of XML API sdk available to manage Cisco UCS Managed B/C-series servers. Install ``UcsSdk`` [1]_ module on the Ironic conductor node. Required version is 0.8.2.2:: $ pip install "UcsSdk==0.8.2.2" Tested Platforms ~~~~~~~~~~~~~~~~ This driver works on Cisco UCS Manager Managed B/C-series servers. It has been tested with the following servers: UCS Manager version: 2.2(1b), 2.2(3d). * UCS B22M, B200M3 * UCS C220M3. All the Cisco UCS B/C-series servers managed by UCSM 2.1 or later are supported by this driver. Configuring and Enabling the driver ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Add ``pxe_ucs`` and/or ``agent_ucs`` to the list of ``enabled_drivers`` in ``/etc/ironic/ironic.conf``. For example:: enabled_drivers = pxe_ipmitool,pxe_ucs,agent_ucs 2. Restart the Ironic conductor service:: service ironic-conductor restart Registering UCS node in Ironic ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Nodes configured for UCS driver should have the ``driver`` property set to ``pxe_ucs/agent_ucs``. The following configuration values are also required in ``driver_info``: - ``ucs_address``: IP address or hostname of the UCS Manager - ``ucs_username``: UCS Manager login user name with administrator or server_profile privileges. - ``ucs_password``: UCS Manager login password for the above UCS Manager user. - ``deploy_kernel``: The Glance UUID of the deployment kernel. - ``deploy_ramdisk``: The Glance UUID of the deployment ramdisk. - ``ucs_service_profile``: Distinguished name(DN) of service_profile being enrolled. The following sequence of commands can be used to enroll a UCS node. * Create Node:: openstack baremetal node create --driver \ --driver-info ucs_address= \ --driver-info ucs_username= \ --driver-info ucs_password= \ --driver-info ucs_service_profile= \ --driver-info deploy_kernel= \ --driver-info deploy_ramdisk= \ --property cpus= \ --property memory_mb= \ --property local_gb= \ --property cpu_arch= The above command 'openstack baremetal node create' will return UUID of the node, which is the value of $NODE in the following command. * Associate port with the node created:: openstack baremetal port create --node $NODE References ========== .. [1] UcsSdk - https://pypi.python.org/pypi/UcsSdk ironic-10.1.1/doc/source/admin/drivers/snmp.rst0000666000175100017510000001353313243617463021443 0ustar zuulzuul00000000000000=========== SNMP driver =========== The SNMP hardware type enables control of power distribution units of the type frequently found in data centre racks. PDUs frequently have a management ethernet interface and SNMP support enabling control of the power outlets. The SNMP power interface works with the :ref:`pxe-boot` interface for network deployment and network-configured boot. .. note:: Unlike most of the other power interfaces, the SNMP power interface does not have a corresponding management interface. The SNMP hardware type uses the ``fake`` management interface instead. List of supported devices ========================= This is a non-exhaustive list of supported devices. Any device not listed in this table could possibly work using a similar driver. Please report any device status. ============== ========== ========== ===================== Manufacturer Model Supported? Driver name ============== ========== ========== ===================== APC AP7920 Yes apc_masterswitch APC AP9606 Yes apc_masterswitch APC AP9225 Yes apc_masterswitchplus APC AP7155 Yes apc_rackpdu APC AP7900 Yes apc_rackpdu APC AP7901 Yes apc_rackpdu APC AP7902 Yes apc_rackpdu APC AP7911a Yes apc_rackpdu APC AP7921 Yes apc_rackpdu APC AP7922 Yes apc_rackpdu APC AP7930 Yes apc_rackpdu APC AP7931 Yes apc_rackpdu APC AP7932 Yes apc_rackpdu APC AP7940 Yes apc_rackpdu APC AP7941 Yes apc_rackpdu APC AP7951 Yes apc_rackpdu APC AP7960 Yes apc_rackpdu APC AP7990 Yes apc_rackpdu APC AP7998 Yes apc_rackpdu APC AP8941 Yes apc_rackpdu APC AP8953 Yes apc_rackpdu APC AP8959 Yes apc_rackpdu APC AP8961 Yes apc_rackpdu APC AP8965 Yes apc_rackpdu Aten all? Yes aten CyberPower all? Untested cyberpower EatonPower all? Untested eatonpower Teltronix all? Yes teltronix ============== ========== ========== ===================== Software Requirements ===================== - The PySNMP package must be installed, variously referred to as ``pysnmp`` or ``python-pysnmp`` Enabling the SNMP Hardware Type =============================== #. Add ``snmp`` to the list of ``enabled_hardware_types`` in ``ironic.conf``. Also update ``enabled_management_interfaces`` and ``enabled_power_interfaces`` in ``ironic.conf`` as shown below: .. code-block:: ini [DEFAULT] enabled_hardware_types = snmp enabled_management_interfaces = fake enabled_power_interfaces = snmp #. To set the default boot option, update ``default_boot_option`` in ``ironic.conf``: .. code-block:: ini [DEFAULT] default_boot_option = netboot .. note:: Currently the default value of ``default_boot_option`` is ``netboot`` but it will be changed to ``local`` in the future. It is recommended to set an explicit value for this option. .. note:: It is important to set ``boot_option`` to ``netboot`` as SNMP hardware type does not support setting of boot devices. One can also configure a node to boot using ``netboot`` by setting its ``capabilities`` and updating Nova flavor as described below: .. code-block:: console openstack baremetal node set --property capabilities="boot_option:netboot" openstack flavor set --property "capabilities:boot_option"="netboot" ironic-flavor #. Restart the Ironic conductor service. .. code-block:: bash service ironic-conductor restart Ironic Node Configuration ========================= Nodes configured to use the SNMP hardware type should have the ``driver`` field set to the hardware type ``snmp``. The following property values have to be added to the node's ``driver_info`` field: - ``snmp_driver``: PDU manufacturer driver - ``snmp_address``: the IPv4 address of the PDU controlling this node. - ``snmp_port``: (optional) A non-standard UDP port to use for SNMP operations. If not specified, the default port (161) is used. - ``snmp_outlet``: The power outlet on the PDU (1-based indexing). - ``snmp_version``: (optional) SNMP protocol version (permitted values ``1``, ``2c`` or ``3``). If not specified, SNMPv1 is chosen. - ``snmp_community``: (Required for SNMPv1 and SNMPv2c) SNMP community parameter for reads and writes to the PDU. - ``snmp_security``: (Required for SNMPv3) SNMPv3 User-based Security Model (USM) user name. The following command can be used to enroll a node with the ``snmp`` hardware type: .. code-block:: bash openstack baremetal node create --os-baremetal-api-version=1.31 \ --driver snmp --driver-info snmp_driver= \ --driver-info snmp_address= \ --driver-info snmp_outlet= \ --driver-info snmp_community= \ --properties capabilities=boot_option:netboot PDU Configuration ================= This version of the SNMP power interface does not support SNMPv3 authentication or encryption features. When using SNMPv3, the SNMPv3 agent at the PDU must be configured in ``noAuthNoPriv`` mode. Also, the ``snmp_security`` parameter is used to configure SNMP USM user name to the SNMP manager at the power interface. The same USM user name must be configured to the target SNMP agent. ironic-10.1.1/doc/source/admin/drivers/cimc.rst0000666000175100017510000000674013243617463021403 0ustar zuulzuul00000000000000.. _CIMC: ============ CIMC drivers ============ Overview ======== The CIMC drivers are targeted for standalone Cisco UCS C series servers. These drivers enable you to take advantage of CIMC by using the python SDK. ``pxe_iscsi_cimc`` driver uses PXE boot + iSCSI deploy (just like ``pxe_ipmitool`` driver) to deploy the image and uses CIMC to do all management operations on the baremetal node (instead of using IPMI). ``pxe_agent_cimc`` driver uses PXE boot + Agent deploy (just like ``agent_ipmitool`` and ``agent_ipminative`` drivers.) to deploy the image and uses CIMC to do all management operations on the baremetal node (instead of using IPMI). Unlike with iSCSI deploy in Agent deploy, the ramdisk is responsible for writing the image to the disk, instead of the conductor. The CIMC drivers can use the Ironic Inspector service for in-band inspection of equipment. For more information see the `Ironic Inspector documentation `_. Prerequisites ============= * ``ImcSdk`` is a python SDK for the CIMC HTTP/HTTPS XML API used to control CIMC. Install the ``ImcSdk`` module ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. note:: Install the ``ImcSdk`` module on the Ironic conductor node. Required version is 0.7.2. #. Install it:: $ pip install "ImcSdk>=0.7.2" Tested Platforms ~~~~~~~~~~~~~~~~ This driver works with UCS C-Series servers and has been tested with: * UCS C240M3S Configuring and Enabling the driver ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Add ``pxe_iscsi_cimc`` and/or ``pxe_agent_cimc`` to the list of ``enabled_drivers`` in ``/etc/ironic/ironic.conf``. For example:: enabled_drivers = pxe_ipmitool,pxe_iscsi_cimc,pxe_agent_cimc 2. Restart the Ironic conductor service: For Ubuntu/Debian systems:: $ sudo service ironic-conductor restart or for RHEL/CentOS/Fedora:: $ sudo systemctl restart openstack-ironic-conductor Registering CIMC Managed UCS node in Ironic ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Nodes configured for CIMC driver should have the ``driver`` property set to ``pxe_iscsi_cimc`` or ``pxe_agent_cimc``. The following configuration values are also required in ``driver_info``: - ``cimc_address``: IP address or hostname for CIMC - ``cimc_username``: CIMC login user name - ``cimc_password``: CIMC login password for the above CIMC user. - ``deploy_kernel``: Identifier for the deployment kernel e.g. a Glance UUID - ``deploy_ramdisk``: Identifier for the deployment ramdisk e.g. a Glance UUID The following sequence of commands can be used to enroll a UCS Standalone node. * Create Node:: openstack baremetal node create --driver \ --driver-info cimc_address= \ --driver-info cimc_username= \ --driver-info cimc_password= \ --driver-info deploy_kernel= \ --driver-info deploy_ramdisk= \ --property cpus= \ --property memory_mb= \ --property local_gb= \ --property cpu_arch= The above command 'openstack baremetal node create' will return UUID of the node, which is the value of $NODE in the following command. * Associate port with the node created:: openstack baremetal port create --node $NODE For more information about enrolling nodes see :ref:`enrollment` in the install guide. ironic-10.1.1/doc/source/admin/drivers/pxe.rst0000666000175100017510000000002513243617463021252 0ustar zuulzuul00000000000000See :ref:`pxe-boot`. ironic-10.1.1/doc/source/admin/drivers/irmc.rst0000666000175100017510000006455413243617463021431 0ustar zuulzuul00000000000000.. _irmc: ============ iRMC drivers ============ Overview ======== The iRMC driver enables control FUJITSU PRIMERGY via ServerView Common Command Interface (SCCI). Support for FUJITSU PRIMERGY servers consists of the ``irmc`` hardware type and a few hardware interfaces specific for that hardware type. Prerequisites ============= * Install `python-scciclient `_ and `pysnmp `_ packages:: $ pip install "python-scciclient>=0.6.0" pysnmp Hardware Type ============= The ``irmc`` hardware type is available for FUJITSU PRIMERGY servers. For information on how to enable the ``irmc`` hardware type, see :ref:`enable-hardware-types`. Hardware interfaces ^^^^^^^^^^^^^^^^^^^ The ``irmc`` hardware type overrides the selection of the following hardware interfaces: * boot Supports ``irmc-virtual-media``, ``irmc-pxe``, and ``pxe``. The default is ``irmc-virtual-media``. The ``irmc-virtual-media`` boot interface enables the virtual media based deploy with IPA (Ironic Python Agent). .. warning:: We deprecated the ``pxe`` boot interface when used with ``irmc`` hardware type. Support for this interface will be removed in the future. Instead, use ``irmc-pxe``. ``irmc-pxe`` boot interface was introduced in Pike. * console Supports ``ipmitool-socat``, ``ipmitool-shellinabox``, and ``no-console``. The default is ``ipmitool-socat``. * inspect Supports ``irmc``, ``inspector``, and ``no-inspect``. The default is ``irmc``. .. note:: `Ironic Inspector `_ needs to be present and configured to use ``inspector`` as the inspect interface. * management Supports only ``irmc``. * power Supports only ``irmc``, which enables power control via ServerView Common Command Interface (SCCI). For other hardware interfaces, ``irmc`` hardware type supports the Bare Metal reference interfaces. For more details about the hardware interfaces and how to enable the desired ones, see :ref:`enable-hardware-interfaces`. Here is a complete configuration example with most of the supported hardware interfaces enabled for ``irmc`` hardware type. .. code-block:: ini [DEFAULT] enabled_hardware_types = irmc enabled_boot_interfaces = irmc-virtual-media,irmc-pxe enabled_console_interfaces = ipmitool-socat,ipmitool-shellinabox,no-console enabled_deploy_interfaces = iscsi,direct enabled_inspect_interfaces = irmc,inspector,no-inspect enabled_management_interfaces = irmc enabled_network_interfaces = flat,neutron enabled_power_interfaces = irmc enabled_raid_interfaces = no-raid enabled_storage_interfaces = noop,cinder enabled_vendor_interfaces = no-vendor,ipmitool Here is a command example to enroll a node with ``irmc`` hardware type. .. code-block:: console openstack baremetal node create --os-baremetal-api-version=1.31 \ --driver irmc \ --boot-interface irmc-pxe \ --deploy-interface direct \ --inspect-interface irmc Node configuration ^^^^^^^^^^^^^^^^^^ * Each node is configured for ``irmc`` hardware type by setting the following ironic node object’s properties: - ``driver_info/irmc_address`` property to be ``IP address`` or ``hostname`` of the iRMC. - ``driver_info/irmc_username`` property to be ``username`` for the iRMC with administrator privileges. - ``driver_info/irmc_password`` property to be ``password`` for irmc_username. - ``properties/capabilities`` property to be ``boot_mode:uefi`` if UEFI boot is required. - ``properties/capabilities`` property to be ``secure_boot:true`` if UEFI Secure Boot is required. Please refer to `UEFI Secure Boot Support`_ for more information. * The following properties are also required if ``irmc-virtual-media`` boot interface is used: - ``driver_info/irmc_deploy_iso`` property to be either deploy iso file name, Glance UUID, or Image Service URL. - ``instance info/irmc_boot_iso`` property to be either boot iso file name, Glance UUID, or Image Service URL. This is optional property when ``boot_option`` is set to ``netboot``. * All of the nodes are configured by setting the following configuration options in the ``[irmc]`` section of ``/etc/ironic/ironic.conf``: - ``port``: Port to be used for iRMC operations; either 80 or 443. The default value is 443. Optional. - ``auth_method``: Authentication method for iRMC operations; either ``basic`` or ``digest``. The default value is ``basic``. Optional. - ``client_timeout``: Timeout (in seconds) for iRMC operations. The default value is 60. Optional. - ``sensor_method``: Sensor data retrieval method; either ``ipmitool`` or ``scci``. The default value is ``ipmitool``. Optional. * The following options are required if ``irmc-virtual-media`` boot interface is enabled: - ``remote_image_share_root``: Ironic conductor node's ``NFS`` or ``CIFS`` root path. The default value is ``/remote_image_share_root``. - ``remote_image_server``: IP of remote image server. - ``remote_image_share_type``: Share type of virtual media, either ``NFS`` or ``CIFS``. The default is ``CIFS``. - ``remote_image_share_name``: share name of ``remote_image_server``. The default value is ``share``. - ``remote_image_user_name``: User name of ``remote_image_server``. - ``remote_image_user_password``: Password of ``remote_image_user_name``. - ``remote_image_user_domain``: Domain name of ``remote_image_user_name``. * The following options are required if ``irmc`` inspect interface is enabled: - ``snmp_version``: SNMP protocol version; either ``v1``, ``v2c`` or ``v3``. The default value is ``v2c``. Optional. - ``snmp_port``: SNMP port. The default value is ``161``. Optional. - ``snmp_community``: SNMP community required for versions ``v1`` and ``v2c``. The default value is ``public``. Optional. - ``snmp_security``: SNMP security name required for version ``v3``. Optional. * Each node can be further configured by setting the following ironic node object’s properties which override the parameter values in ``[irmc]`` section of ``/etc/ironic/ironic.conf``: - ``driver_info/irmc_port`` property overrides ``port``. - ``driver_info/irmc_auth_method`` property overrides ``auth_method``. - ``driver_info/irmc_client_timeout`` property overrides ``client_timeout``. - ``driver_info/irmc_sensor_method`` property overrides ``sensor_method``. - ``driver_info/irmc_snmp_version`` property overrides ``snmp_version``. - ``driver_info/irmc_snmp_port`` property overrides ``snmp_port``. - ``driver_info/irmc_snmp_community`` property overrides ``snmp_community``. - ``driver_info/irmc_snmp_security`` property overrides ``snmp_security``. Upgrading to ``irmc`` hardware type ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ When upgrading from a classic driver to the ``irmc`` hardware type, make sure you specify the hardware interfaces that are used by the classic driver. :doc:`/admin/upgrade-to-hardware-types` has more information, including the hardware interfaces corresponding to the classic drivers. Classic Drivers (Deprecated) ============================ These are the classic drivers (deprecated) for FUJITSU PRIMERGY servers. * ``pxe_irmc`` * ``iscsi_irmc`` * ``agent_irmc`` .. warning:: The classic drivers are deprecated in the Queens release and will be removed in the Rocky release. The ``irmc`` hardware type should be used instead of the classic drivers. pxe_irmc driver ^^^^^^^^^^^^^^^ This driver enables PXE deploy and power control via ServerView Common Command Interface (SCCI). Enabling the driver ~~~~~~~~~~~~~~~~~~~ - Add ``pxe_irmc`` to the list of ``enabled_drivers`` in ``[DEFAULT]`` section of ``/etc/ironic/ironic.conf``. - Ironic Conductor must be restarted for the new driver to be loaded. Node configuration ~~~~~~~~~~~~~~~~~~ * Each node is configured for iRMC with PXE deploy by setting the following ironic node object’s properties: - ``driver`` property to be ``pxe_irmc`` - ``driver_info/irmc_address`` property to be ``IP address`` or ``hostname`` of the iRMC. - ``driver_info/irmc_username`` property to be ``username`` for the iRMC with administrator privileges. - ``driver_info/irmc_password`` property to be ``password`` for irmc_username. - ``properties/capabilities`` property to be ``boot_mode:uefi`` if UEFI boot is required. - ``properties/capabilities`` property to be ``secure_boot:true`` if UEFI Secure Boot is required. Please refer to `UEFI Secure Boot Support`_ for more information. * All of nodes are configured by setting the following configuration options in ``[irmc]`` section of ``/etc/ironic/ironic.conf``: - ``port``: Port to be used for iRMC operations; either 80 or 443. The default value is 443. Optional. - ``auth_method``: Authentication method for iRMC operations; either ``basic`` or ``digest``. The default value is ``basic``. Optional. - ``client_timeout``: Timeout (in seconds) for iRMC operations. The default value is 60. Optional. - ``sensor_method``: Sensor data retrieval method; either ``ipmitool`` or ``scci``. The default value is ``ipmitool``. Optional. * The following options are only required for inspection: - ``snmp_version``: SNMP protocol version; either ``v1``, ``v2c`` or ``v3``. The default value is ``v2c``. Optional. - ``snmp_port``: SNMP port. The default value is ``161``. Optional. - ``snmp_community``: SNMP community required for versions ``v1`` and ``v2c``. The default value is ``public``. Optional. - ``snmp_security``: SNMP security name required for version ``v3``. Optional. * Each node can be further configured by setting the following ironic node object’s properties which override the parameter values in ``[irmc]`` section of ``/etc/ironic/ironic.conf``: - ``driver_info/irmc_port`` property overrides ``port``. - ``driver_info/irmc_auth_method`` property overrides ``auth_method``. - ``driver_info/irmc_client_timeout`` property overrides ``client_timeout``. - ``driver_info/irmc_sensor_method`` property overrides ``sensor_method``. - ``driver_info/irmc_snmp_version`` property overrides ``snmp_version``. - ``driver_info/irmc_snmp_port`` property overrides ``snmp_port``. - ``driver_info/irmc_snmp_community`` property overrides ``snmp_community``. - ``driver_info/irmc_snmp_security`` property overrides ``snmp_security``. iscsi_irmc driver ^^^^^^^^^^^^^^^^^ This driver enables Virtual Media deploy with image build from Diskimage Builder and power control via ServerView Common Command Interface (SCCI). Enabling the driver ~~~~~~~~~~~~~~~~~~~ - Add ``iscsi_irmc`` to the list of ``enabled_drivers`` in ``[DEFAULT]`` section of ``/etc/ironic/ironic.conf``. - Ironic Conductor must be restarted for the new driver to be loaded. Node configuration ~~~~~~~~~~~~~~~~~~ * Each node is configured for iRMC with PXE deploy by setting the followings ironic node object’s properties: - ``driver`` property to be ``iscsi_irmc`` - ``driver_info/irmc_address`` property to be ``IP address`` or ``hostname`` of the iRMC. - ``driver_info/irmc_username`` property to be ``username`` for the iRMC with administrator privileges. - ``driver_info/irmc_password`` property to be ``password`` for irmc_username. - ``properties/capabilities`` property to be ``boot_mode:uefi`` if UEFI boot is required. - ``properties/capabilities`` property to be ``secure_boot:true`` if Secure Boot is required. Please refer to `UEFI Secure Boot Support`_ for more information. - ``driver_info/irmc_deploy_iso`` property to be either deploy iso file name, Glance UUID, or Image Service URL. - ``instance info/irmc_boot_iso`` property to be either boot iso file name, Glance UUID, or Image Service URL. This is optional property when ``boot_option`` is set to ``netboot``. * All of nodes are configured by setting the following configuration options in ``[irmc]`` section of ``/etc/ironic/ironic.conf``: - ``port``: Port to be used for iRMC operations; either ``80`` or ``443``. The default value is ``443``. Optional. - ``auth_method``: Authentication method for iRMC operations; either ``basic`` or ``digest``. The default value is ``basic``. Optional. - ``client_timeout``: Timeout (in seconds) for iRMC operations. The default value is 60. Optional. - ``sensor_method``: Sensor data retrieval method; either ``ipmitool`` or ``scci``. The default value is ``ipmitool``. Optional. - ``remote_image_share_root``: Ironic conductor node's ``NFS`` or ``CIFS`` root path. The default value is ``/remote_image_share_root``. - ``remote_image_server``: IP of remote image server. - ``remote_image_share_type``: Share type of virtual media, either ``NFS`` or ``CIFS``. The default is ``CIFS``. - ``remote_image_share_name``: share name of ``remote_image_server``. The default value is ``share``. - ``remote_image_user_name``: User name of ``remote_image_server``. - ``remote_image_user_password``: Password of ``remote_image_user_name``. - ``remote_image_user_domain``: Domain name of ``remote_image_user_name``. * The following options are only required for inspection: - ``snmp_version``: SNMP protocol version; either ``v1``, ``v2c`` or ``v3``. The default value is ``v2c``. Optional. - ``snmp_port``: SNMP port. The default value is ``161``. Optional. - ``snmp_community``: SNMP community required for versions ``v1`` and ``v2c``. The default value is ``public``. Optional. - ``snmp_security``: SNMP security name required for version ``v3``. Optional. * Each node can be further configured by setting the following ironic node object’s properties which override the parameter values in ``[irmc]`` section of ``/etc/ironic/ironic.conf``: - ``driver_info/irmc_port`` property overrides ``port``. - ``driver_info/irmc_auth_method`` property overrides ``auth_method``. - ``driver_info/irmc_client_timeout`` property overrides ``client_timeout``. - ``driver_info/irmc_sensor_method`` property overrides ``sensor_method``. - ``driver_info/irmc_snmp_version`` property overrides ``snmp_version``. - ``driver_info/irmc_snmp_port`` property overrides ``snmp_port``. - ``driver_info/irmc_snmp_community`` property overrides ``snmp_community``. - ``driver_info/irmc_snmp_security`` property overrides ``snmp_security``. agent_irmc driver ^^^^^^^^^^^^^^^^^ This driver enables Virtual Media deploy with IPA (Ironic Python Agent) and power control via ServerView Common Command Interface (SCCI). Enabling the driver ~~~~~~~~~~~~~~~~~~~ - Add ``agent_irmc`` to the list of ``enabled_drivers`` in ``[DEFAULT]`` section of ``/etc/ironic/ironic.conf``. - Ironic Conductor must be restarted for the new driver to be loaded. Node configuration ~~~~~~~~~~~~~~~~~~ * Each node is configured for iRMC with PXE deploy by setting the followings ironic node object’s properties: - ``driver`` property to be ``agent_irmc`` - ``driver_info/irmc_address`` property to be ``IP address`` or ``hostname`` of the iRMC. - ``driver_info/irmc_username`` property to be ``username`` for the iRMC with administrator privileges. - ``driver_info/irmc_password`` property to be ``password`` for irmc_username. - ``properties/capabilities`` property to be ``boot_mode:uefi`` if UEFI boot is required. - ``properties/capabilities`` property to be ``secure_boot:true`` if Secure Boot is required. Please refer to `UEFI Secure Boot Support`_ for more information. - ``driver_info/irmc_deploy_iso`` property to be either deploy iso file name, Glance UUID, or Image Service URL. - ``instance info/irmc_boot_iso`` property to be either boot iso file name, Glance UUID, or Image Service URL. This is optional property when ``boot_option`` is set to ``netboot``. * All of nodes are configured by setting the following configuration options in ``[irmc]`` section of ``/etc/ironic/ironic.conf``: - ``port``: Port to be used for iRMC operations; either 80 or 443. The default value is 443. Optional. - ``auth_method``: Authentication method for iRMC operations; either ``basic`` or ``digest``. The default value is ``basic``. Optional. - ``client_timeout``: Timeout (in seconds) for iRMC operations. The default value is 60. Optional. - ``sensor_method``: Sensor data retrieval method; either ``ipmitool`` or ``scci``. The default value is ``ipmitool``. Optional. - ``remote_image_share_root``: Ironic conductor node's ``NFS`` or ``CIFS`` root path. The default value is ``/remote_image_share_root``. - ``remote_image_server``: IP of remote image server. - ``remote_image_share_type``: Share type of virtual media, either ``NFS`` or ``CIFS``. The default is ``CIFS``. - ``remote_image_share_name``: share name of ``remote_image_server``. The default value is ``share``. - ``remote_image_user_name``: User name of ``remote_image_server``. - ``remote_image_user_password``: Password of ``remote_image_user_name``. - ``remote_image_user_domain``: Domain name of ``remote_image_user_name``. * The following options are only required for inspection: - ``snmp_version``: SNMP protocol version; either ``v1``, ``v2c`` or ``v3``. The default value is ``v2c``. Optional. - ``snmp_port``: SNMP port. The default value is ``161``. Optional. - ``snmp_community``: SNMP community required for versions ``v1`` and ``v2c``. The default value is ``public``. Optional. - ``snmp_security``: SNMP security name required for version ``v3``. Optional. * Each node can be further configured by setting the following ironic node object’s properties which override the parameter values in ``[irmc]`` section of ``/etc/ironic/ironic.conf``: - ``driver_info/irmc_port`` property overrides ``port``. - ``driver_info/irmc_auth_method`` property overrides ``auth_method``. - ``driver_info/irmc_client_timeout`` property overrides ``client_timeout``. - ``driver_info/irmc_sensor_method`` property overrides ``sensor_method``. - ``driver_info/irmc_snmp_version`` property overrides ``snmp_version``. - ``driver_info/irmc_snmp_port`` property overrides ``snmp_port``. - ``driver_info/irmc_snmp_community`` property overrides ``snmp_community``. - ``driver_info/irmc_snmp_security`` property overrides ``snmp_security``. Optional functionalities for the ``irmc`` hardware type ======================================================= UEFI Secure Boot Support ^^^^^^^^^^^^^^^^^^^^^^^^ The hardware type ``irmc`` (and all iRMC classic drivers) supports secure boot deploy. .. warning:: Secure boot feature is not supported with ``pxe`` boot interface. The UEFI secure boot can be configured by adding ``secure_boot`` parameter, which is a boolean value. Enabling the secure boot is different when Bare Metal service is used with Compute service or without Compute service. The following sections describes both methods: * Enabling secure boot with Compute service: To enable secure boot we need to set a capability on the bare metal node and the bare metal flavor, for example:: openstack baremetal node set --property capabilities='secure_boot:true' openstack flavor set FLAVOR-NAME --property capabilities:secure_boot="true" * Enabling secure boot without Compute service: Since adding capabilities to the node's properties is only used by the nova scheduler to perform more advanced scheduling of instances, we need to enable secure boot without nova, for example:: openstack baremetal node set --instance-info capabilities='{"secure_boot": "true"}' .. _irmc_node_cleaning: Node Cleaning Support ^^^^^^^^^^^^^^^^^^^^^ The ``irmc`` hardware type (and all iRMC classic drivers) supports node cleaning. For more information on node cleaning, see :ref:`cleaning`. Supported **Automated** Cleaning Operations ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The automated cleaning operations supported are: * ``restore_irmc_bios_config``: Restores BIOS settings on a baremetal node from backup data. If this clean step is enabled, the BIOS settings of a baremetal node will be backed up automatically before the deployment. By default, this clean step is disabled with priority ``0``. Set its priority to a positive integer to enable it. The recommended value is ``10``. .. warning:: ``pxe`` boot interface, when used with ``irmc`` hardware type, does not support this clean step. If uses ``irmc`` hardware type, it is required to select ``irmc-pxe`` or ``irmc-virtual-media`` as the boot interface in order to make this clean step work. Configuration options for the automated cleaning steps are listed under ``[irmc]`` section in ironic.conf :: clean_priority_restore_irmc_bios_config = 0 For more information on node automated cleaning, see :ref:`automated_cleaning` Boot from Remote Volume ^^^^^^^^^^^^^^^^^^^^^^^ The ``irmc`` hardware type (and ``pxe_irmc`` classic driver) supports the generic iPXE-based remote volume booting when using the following boot interfaces: * ``irmc-pxe`` * ``pxe`` In addition, the ``irmc`` hardware type supports remote volume booting without iPXE. This is available when using the ``irmc-virtual-media`` boot interface (and ``iscsi_irmc`` and ``agent_irmc`` classic drivers). This feature configures a node to boot from a remote volume by using the API of iRMC. It supports iSCSI and FibreChannel. Configuration ~~~~~~~~~~~~~ In addition to the configuration for generic drivers to :ref:`remote volume boot `, the iRMC drivers require the following configuration: * It is necessary to set physical port IDs to network ports and volume connectors. All cards including those not used for volume boot should be registered. The format of a physical port ID is: ``-`` where: - ````: could be ``LAN``, ``FC`` or ``CNA`` - ````: 0 indicates onboard slot. Use 1 to 9 for add-on slots. - ````: A port number starting from 1. These IDs are specified in a node's ``driver_info[irmc_pci_physical_ids]``. This value is a dictionary. The key is the UUID of a resource (Port or Volume Connector) and its value is the physical port ID. For example:: { "1ecd14ee-c191-4007-8413-16bb5d5a73a2":"LAN0-1", "87f6c778-e60e-4df2-bdad-2605d53e6fc0":"CNA1-1" } It can be set with the following command:: openstack baremetal node set $NODE_UUID \ --driver-info irmc_pci_physical_ids={} \ --driver-info irmc_pci_physical_ids/$PORT_UUID=LAN0-1 \ --driver-info irmc_pci_physical_ids/$VOLUME_CONNECTOR_UUID=CNA1-1 * For iSCSI boot, volume connectors with both types ``iqn`` and ``ip`` are required. The configuration with DHCP is not supported yet. * For iSCSI, the size of the storage network is needed. This value should be specified in a node's ``driver_info[irmc_storage_network_size]``. It must be a positive integer < 32. For example, if the storage network is 10.2.0.0/22, use the following command:: openstack baremetal node set $NODE_UUID --driver-info irmc_storage_network_size=22 Supported hardware ~~~~~~~~~~~~~~~~~~ The drivers support the PCI controllers, Fibrechannel Cards, Converged Network Adapters supported by `Fujitsu ServerView Virtual-IO Manager `_. Hardware Inspection Support ^^^^^^^^^^^^^^^^^^^^^^^^^^^ The ``irmc`` hardware type (and all iRMC classic drivers) provides the iRMC-specific hardware inspection with ``irmc`` inspect interface. .. note:: SNMP requires being enabled in ServerView® iRMC S4 Web Server(Network Settings\SNMP section). Configuration ~~~~~~~~~~~~~ The Hardware Inspection Support in the iRMC drivers requires the following configuration: * It is necessary to set ironic configuration with ``gpu_ids`` option in ``[irmc]`` section. ``gpu_ids`` is a list of ``/`` where: - ````: 4 hexadecimal digits starts with '0x'. - ````: 4 hexadecimal digits starts with '0x'. Here is a sample value for gpu_ids:: gpu_ids = 0x1000/0x0079,0x2100/0x0080 * The python-scciclient package requires pyghmi version >= 1.0.22 and pysnmp version >= 4.2.3. They are used by the conductor service on the conductor. The latest version of pyghmi can be downloaded from `here `__ and pysnmp can be downloaded from `here `__. Supported properties ~~~~~~~~~~~~~~~~~~~~ The inspection process will discover the following essential properties (properties required for scheduling deployment): * ``memory_mb``: memory size * ``cpus``: number of cpus * ``cpu_arch``: cpu architecture * ``local_gb``: disk size Inspection can also discover the following extra capabilities for iRMC drivers: * ``irmc_firmware_version``: iRMC firmware version * ``rom_firmware_version``: ROM firmware version * ``trusted_boot``: The flag whether TPM(Trusted Platform Module) is supported by the server. The possible values are 'True' or 'False'. * ``server_model``: server model * ``pci_gpu_devices``: number of gpu devices connected to the bare metal. .. note:: * The disk size is returned only when eLCM License for FUJITSU PRIMERGY servers is activated. If the license is not activated, then Hardware Inspection will fail to get this value. * Before inspecting, if the server is power-off, it will be turned on automatically. System will wait for a few second before start inspecting. After inspection, power status will be restored to the previous state. The operator can specify these capabilities in compute service flavor, for example:: openstack flavor set baremetal-flavor-name --property capabilities:irmc_firmware_version="iRMC S4-8.64F" openstack flavor set baremetal-flavor-name --property capabilities:server_model="TX2540M1F5" openstack flavor set baremetal-flavor-name --property capabilities:pci_gpu_devices="1" See :ref:`capabilities-discovery` for more details and examples. Supported platforms =================== This driver supports FUJITSU PRIMERGY BX S4 or RX S8 servers and above. - PRIMERGY BX920 S4 - PRIMERGY BX924 S4 - PRIMERGY RX300 S8 Soft Reboot (Graceful Reset) and Soft Power Off (Graceful Power Off) are only available if `ServerView agents `_ are installed. See `iRMC S4 Manual `_ for more details. ironic-10.1.1/doc/source/admin/drivers/ilo.rst0000666000175100017510000024216113243617463021252 0ustar zuulzuul00000000000000.. _ilo: =========== iLO drivers =========== Overview ======== iLO drivers enable to take advantage of features of iLO management engine in HPE ProLiant servers. iLO drivers are targeted for HPE ProLiant Gen8 and Gen9 systems which have `iLO 4 management engine`_. From **Pike** release iLO drivers start supporting ProLiant Gen10 systems which have `iLO 5 management engine`_. iLO5 conforms to `Redfish`_ API and hence hardware type ``redfish`` (see :doc:`redfish`) is also an option for this kind of hardware but it will lack the iLO specific features. For more details and for up-to-date information (like tested platforms, known issues, etc), please check the `iLO driver wiki page `_. For enabling Gen10 systems and getting detailed information on Gen10 feature support in Ironic please check this `Gen10 wiki section`_. ProLiant hardware is supported by the ``ilo`` hardware type and the following classic drivers: * ``iscsi_ilo`` * ``agent_ilo`` * ``pxe_ilo`` .. note:: All HPE ProLiant servers support reference hardware type ``ipmi`` (see :doc:`ipmitool`). HPE ProLiant Gen10 servers also support hardware type ``redfish`` (see :doc:`redfish`). The ``iscsi_ilo`` and ``agent_ilo`` drivers provide security enhanced PXE-less deployment by using iLO virtual media to boot up the bare metal node. These drivers send management info through the management channel and separate it from the data channel which is used for deployment. ``iscsi_ilo`` and ``agent_ilo`` drivers use deployment ramdisk built from ``diskimage-builder``. The ``iscsi_ilo`` driver deploys from ironic conductor and supports both net-boot and local-boot of instance. ``agent_ilo`` deploys from bare metal node and supports both net-boot and local-boot of instance. ``pxe_ilo`` driver uses PXE/iSCSI for deployment (just like normal PXE driver) and deploys from ironic conductor. Additionally it supports automatic setting of requested boot mode from nova. This driver doesn't require iLO Advanced license. The hardware type ``ilo`` and iLO-based classic drivers support HPE server features like: * UEFI secure boot * Certificate based validation of iLO * Hardware based secure disk erase using Smart Storage Administrator (SSA) CLI * Out-of-band discovery of server attributes through hardware inspection * In-band RAID configuration * Firmware configuration and secure firmware update * `Firmware based UEFI iSCSI boot from volume support`_ Hardware Interfaces ^^^^^^^^^^^^^^^^^^^ The ``ilo`` hardware type supports following hardware interfaces: * boot Supports ``ilo-virtual-media`` and ``ilo-pxe``. The default is ``ilo-virtual-media``. They can be enabled by using the ``[DEFAULT]enabled_boot_interfaces`` option in ``ironic.conf`` as given below: .. code-block:: ini [DEFAULT] enabled_hardware_types = ilo enabled_boot_interfaces = ilo-virtual-media,ilo-pxe * console Supports ``ilo`` and ``no-console``. The default is ``ilo``. They can be enabled by using the ``[DEFAULT]enabled_console_interfaces`` option in ``ironic.conf`` as given below: .. code-block:: ini [DEFAULT] enabled_hardware_types = ilo enabled_console_interfaces = ilo,no-console * inspect Supports ``ilo`` and ``inspector``. The default is ``ilo``. They can be enabled by using the ``[DEFAULT]enabled_inspect_interfaces`` option in ``ironic.conf`` as given below: .. code-block:: ini [DEFAULT] enabled_hardware_types = ilo enabled_inspect_interfaces = ilo,inspector .. note:: `Ironic Inspector `_ needs to be configured to use ``inspector`` as the inspect interface. * management Supports only ``ilo``. It can be enabled by using the ``[DEFAULT]enabled_management_interfaces`` option in ``ironic.conf`` as given below: .. code-block:: ini [DEFAULT] enabled_hardware_types = ilo enabled_management_interfaces = ilo * power Supports only ``ilo``. It can be enabled by using the ``[DEFAULT]enabled_power_interfaces`` option in ``ironic.conf`` as given below: .. code-block:: ini [DEFAULT] enabled_hardware_types = ilo enabled_power_interfaces = ilo * raid Supports ``agent`` and ``no-raid``. The default is ``no-raid``. They can be enabled by using the ``[DEFAULT]enabled_raid_interfaces`` option in ``ironic.conf`` as given below: .. code-block:: ini [DEFAULT] enabled_hardware_types = ilo enabled_raid_interfaces = agent,no-raid * storage Supports ``cinder`` and ``noop``. The default is ``noop``. They can be enabled by using the ``[DEFAULT]enabled_storage_interfaces`` option in ``ironic.conf`` as given below: .. code-block:: ini [DEFAULT] enabled_hardware_types = ilo enabled_storage_interfaces = cinder,noop .. note:: The storage interface ``cinder`` is supported only when corresponding boot interface of the ``ilo`` hardware type based node is ``ilo-pxe``. Please refer to :doc:`/admin/boot-from-volume` for configuring ``cinder`` as a storage interface. ``ilo`` hardware type supports all standard ``deploy`` and ``network`` interface implementations, see :ref:`enable-hardware-interfaces` for details. The following command can be used to enroll a ProLiant node with ``ilo`` hardware type: .. code-block:: console openstack baremetal node create --os-baremetal-api-version=1.31 \ --driver ilo \ --deploy-interface direct \ --raid-interface agent \ --driver-info ilo_address= \ --driver-info ilo_username= \ --driver-info ilo_password= \ --driver-info ilo_deploy_iso= Please refer to :doc:`/install/enabling-drivers` for detailed explanation of hardware type. To enable the same feature set as provided by all iLO classic drivers, apply the following configuration: .. code-block:: ini [DEFAULT] enabled_hardware_types = ilo enabled_boot_interfaces = ilo-virtual-media,ilo-pxe enabled_power_interfaces = ilo enabled_console_interfaces = ilo enabled_raid_interfaces = agent enabled_management_interfaces = ilo enabled_inspect_interfaces = ilo The following commands can be used to enroll a node with the same feature set as one of the classic drivers, but using the ``ilo`` hardware type: * ``iscsi_ilo``: .. code-block:: console openstack baremetal node create --os-baremetal-api-version=1.31 \ --driver ilo \ --deploy-interface iscsi \ --boot-interface ilo-virtual-media \ --driver-info ilo_address= \ --driver-info ilo_username= \ --driver-info ilo_password= \ --driver-info ilo_deploy_iso= * ``pxe_ilo``: .. code-block:: console openstack baremetal node create --os-baremetal-api-version=1.31 \ --driver ilo \ --deploy-interface iscsi \ --boot-interface ilo-pxe \ --driver-info ilo_address= \ --driver-info ilo_username= \ --driver-info ilo_password= \ --driver-info deploy_kernel= \ --driver-info deploy_ramdisk= * ``agent_ilo``: .. code-block:: console openstack baremetal node create --os-baremetal-api-version=1.31 \ --driver ilo \ --deploy-interface direct \ --boot-interface ilo-virtual-media \ --driver-info ilo_address= \ --driver-info ilo_username= \ --driver-info ilo_password= \ --driver-info ilo_deploy_iso= Prerequisites ============= * `proliantutils `_ is a python package which contains a set of modules for managing HPE ProLiant hardware. Install ``proliantutils`` module on the ironic conductor node. Minimum version required is 2.5.0:: $ pip install "proliantutils>=2.5.0" * ``ipmitool`` command must be present on the service node(s) where ``ironic-conductor`` is running. On most distros, this is provided as part of the ``ipmitool`` package. Please refer to `Hardware Inspection Support`_ for more information on recommended version. Different Configuration for ilo drivers ======================================= Glance Configuration ^^^^^^^^^^^^^^^^^^^^ 1. `Configure Glance image service with its storage backend as Swift `_. 2. Set a temp-url key for Glance user in Swift. For example, if you have configured Glance with user ``glance-swift`` and tenant as ``service``, then run the below command:: swift --os-username=service:glance-swift post -m temp-url-key:mysecretkeyforglance 3. Fill the required parameters in the ``[glance]`` section in ``/etc/ironic/ironic.conf``. Normally you would be required to fill in the following details:: [glance] swift_temp_url_key=mysecretkeyforglance swift_endpoint_url=https://10.10.1.10:8080 swift_api_version=v1 swift_account=AUTH_51ea2fb400c34c9eb005ca945c0dc9e1 swift_container=glance The details can be retrieved by running the below command: .. code-block:: bash $ swift --os-username=service:glance-swift stat -v | grep -i url StorageURL: http://10.10.1.10:8080/v1/AUTH_51ea2fb400c34c9eb005ca945c0dc9e1 Meta Temp-Url-Key: mysecretkeyforglance 4. Swift must be accessible with the same admin credentials configured in Ironic. For example, if Ironic is configured with the below credentials in ``/etc/ironic/ironic.conf``:: [keystone_authtoken] admin_password = password admin_user = ironic admin_tenant_name = service Ensure ``auth_version`` in ``keystone_authtoken`` to 2. Then, the below command should work.: .. code-block:: bash $ swift --os-username ironic --os-password password --os-tenant-name service --auth-version 2 stat Account: AUTH_22af34365a104e4689c46400297f00cb Containers: 2 Objects: 18 Bytes: 1728346241 Objects in policy "policy-0": 18 Bytes in policy "policy-0": 1728346241 Meta Temp-Url-Key: mysecretkeyforglance X-Timestamp: 1409763763.84427 X-Trans-Id: tx51de96a28f27401eb2833-005433924b Content-Type: text/plain; charset=utf-8 Accept-Ranges: bytes 5. Restart the Ironic conductor service:: $ service ironic-conductor restart Web server configuration on conductor ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * The HTTP(S) web server can be configured in many ways. For apache web server on Ubuntu, refer `here `_ * Following config variables need to be set in ``/etc/ironic/ironic.conf``: * ``use_web_server_for_images`` in ``[ilo]`` section:: [ilo] use_web_server_for_images = True * ``http_url`` and ``http_root`` in ``[deploy]`` section:: [deploy] # Ironic compute node's http root path. (string value) http_root=/httpboot # Ironic compute node's HTTP server URL. Example: # http://192.1.2.3:8080 (string value) http_url=http://192.168.0.2:8080 ``use_web_server_for_images``: If the variable is set to ``false``, ``iscsi_ilo`` and ``agent_ilo`` uses swift containers to host the intermediate floppy image and the boot ISO. If the variable is set to ``true``, these drivers use the local web server for hosting the intermediate files. The default value for ``use_web_server_for_images`` is False. ``http_url``: The value for this variable is prefixed with the generated intermediate files to generate a URL which is attached in the virtual media. ``http_root``: It is the directory location to which ironic conductor copies the intermediate floppy image and the boot ISO. .. note:: HTTPS is strongly recommended over HTTP web server configuration for security enhancement. The ``iscsi_ilo`` and ``agent_ilo`` will send the instance's configdrive over an encrypted channel if web server is HTTPS enabled. Enable driver ============= 1. Build a deploy ISO (and kernel and ramdisk) image, see :ref:`deploy-ramdisk` 2. See `Glance Configuration`_ for configuring glance image service with its storage backend as ``swift``. 3. Upload this image to Glance:: glance image-create --name deploy-ramdisk.iso --disk-format iso --container-format bare < deploy-ramdisk.iso 4. Add the driver name to the list of ``enabled_drivers`` in ``/etc/ironic/ironic.conf``. For example, for `iscsi_ilo` driver:: enabled_drivers = fake,pxe_ipmitool,iscsi_ilo Similarly it can be added for ``agent_ilo`` and ``pxe_ilo`` drivers. 5. Restart the ironic conductor service:: $ service ironic-conductor restart Drivers ======= iscsi_ilo driver ^^^^^^^^^^^^^^^^ Overview ~~~~~~~~ ``iscsi_ilo`` driver was introduced as an alternative to ``pxe_ipmitool`` and ``pxe_ipminative`` drivers for HPE ProLiant servers. ``iscsi_ilo`` uses virtual media feature in iLO to boot up the bare metal node instead of using PXE or iPXE. Target Users ~~~~~~~~~~~~ * Users who do not want to use PXE/TFTP protocol in their data centers. * Users who have concerns with PXE protocol's security issues and want to have a security enhanced PXE-less deployment mechanism. The PXE driver passes management information in clear-text to the bare metal node. However, if swift proxy server and glance have HTTPS endpoints (See :ref:`EnableHTTPSinSwift`, :ref:`EnableHTTPSinGlance` for more information), the ``iscsi_ilo`` driver provides enhanced security by exchanging management information with swift and glance endpoints over HTTPS. The management information, deploy ramdisk and boot images for the instance will be retrieved over encrypted management network via iLO virtual media. Tested Platforms ~~~~~~~~~~~~~~~~ This driver should work on HPE ProLiant Gen7 servers with iLO 3, Gen8 and Gen9 servers with iLO 4 and Gen10 servers with iLO 5. It has been tested with the following servers: * ProLiant DL380 G7 * ProLiant DL380e Gen8 * ProLiant DL580 Gen8 UEFI * ProLiant DL180 Gen9 UEFI * ProLiant DL360 Gen9 UEFI * ProLiant DL380 Gen9 UEFI * ProLiant XL450 Gen9 UEFI * ProLiant DL360 Gen10 For more up-to-date information on server platform support info, refer `iLO driver wiki page `_. Features ~~~~~~~~ * PXE-less deploy with virtual media. * Automatic detection of current boot mode. * Automatic setting of the required boot mode, if UEFI boot mode is requested by the nova flavor's extra spec. * Supports booting the instance from virtual media (netboot) as well as booting locally from disk. By default, the instance will always boot from virtual media for partition images. * UEFI Boot Support * UEFI Secure Boot Support * Passing management information via secure, encrypted management network (virtual media) if swift proxy server and glance have HTTPS endpoints. See :ref:`EnableHTTPSinSwift`, :ref:`EnableHTTPSinGlance` for more information. User image provisioning is done using iSCSI over data network, so this driver has the benefit of security enhancement with the same performance. It segregates management info from data channel. * Supports both out-of-band and in-band cleaning operations. For more details, see :ref:`InbandvsOutOfBandCleaning`. * Remote Console * HW Sensors * Works well for machines with resource constraints (lesser amount of memory). * Support for out-of-band hardware inspection. * Swiftless deploy for intermediate images * HTTP(S) Based Deploy. * iLO drivers with standalone ironic. Requirements ~~~~~~~~~~~~ * **iLO 4** or **iLO 5 Advanced License** needs to be installed on iLO to enable Virtual Media Boot feature. * **Swift Object Storage Service** - iLO driver uses swift to store temporary FAT images as well as boot ISO images. * **Glance Image Service with swift configured as its backend** - When using ``iscsi_ilo`` driver, the image containing the deploy ramdisk is retrieved from swift directly by the iLO. Deploy Process ~~~~~~~~~~~~~~ Please refer to `Netboot with glance and swift`_ and `Localboot with glance and swift for partition images`_ for the deploy process of partition image and `Localboot with glance and swift`_ for the deploy process of whole disk image. Configuring and Enabling the driver ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Please refer to `Glance Configuration`_ and `Enable driver`_. Registering ProLiant node in ironic ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Nodes configured for iLO driver should have the ``driver`` property set to ``iscsi_ilo``. The following configuration values are also required in ``driver_info``: - ``ilo_address``: IP address or hostname of the iLO. - ``ilo_username``: Username for the iLO with administrator privileges. - ``ilo_password``: Password for the above iLO user. - ``ilo_deploy_iso``: The glance UUID of the deploy ramdisk ISO image. - ``ca_file``: (optional) CA certificate file to validate iLO. - ``client_port``: (optional) Port to be used for iLO operations if you are using a custom port on the iLO. Default port used is 443. - ``client_timeout``: (optional) Timeout for iLO operations. Default timeout is 60 seconds. - ``console_port``: (optional) Node's UDP port for console access. Any unused port on the ironic conductor node may be used. .. note:: To update SSL certificates into iLO, you can refer to `HPE Integrated Lights-Out Security Technology Brief `_. You can use iLO hostname or IP address as a 'Common Name (CN)' while generating Certificate Signing Request (CSR). Use the same value as `ilo_address` while enrolling node to Bare Metal service to avoid SSL certificate validation errors related to hostname mismatch. .. note:: If configuration values for ``ca_file``, ``client_port`` and ``client_timeout`` are not provided in the ``driver_info`` of the node, the corresponding config variables defined under ``[ilo]`` section in ironic.conf will be used. For example, you could run a similar command like below to enroll the ProLiant node:: openstack baremetal node create --driver iscsi_ilo \ --driver-info ilo_address= \ --driver-info ilo_username= \ --driver-info ilo_password= \ --driver-info ilo_deploy_iso= Boot modes ~~~~~~~~~~ Please refer to `Boot mode support`_ for more information. UEFI Secure Boot ~~~~~~~~~~~~~~~~ Please refer to `UEFI Secure Boot Support`_ for more information. Node cleaning ~~~~~~~~~~~~~ Please refer to `Node Cleaning Support`_ for more information. Hardware Inspection ~~~~~~~~~~~~~~~~~~~ Please refer to `Hardware Inspection Support`_ for more information. Swiftless deploy for intermediate deploy and boot images ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Please refer to `Swiftless deploy for intermediate images`_ for more information. HTTP(S) Based Deploy ~~~~~~~~~~~~~~~~~~~~ Please refer to `HTTP(S) Based Deploy Support`_ for more information. iLO drivers with standalone ironic ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Please refer to `Support for iLO drivers with Standalone Ironic`_ for more information. RAID Configuration ~~~~~~~~~~~~~~~~~~ Please refer to `RAID Support`_ for more information. agent_ilo driver ^^^^^^^^^^^^^^^^ Overview ~~~~~~~~ ``agent_ilo`` driver was introduced as an alternative to ``agent_ipmitool`` and ``agent_ipminative`` drivers for HPE ProLiant servers. ``agent_ilo`` driver uses virtual media feature in HPE ProLiant bare metal servers to boot up the Ironic Python Agent (IPA) on the bare metal node instead of using PXE. For more information on IPA, refer https://wiki.openstack.org/wiki/Ironic-python-agent. Target Users ~~~~~~~~~~~~ * Users who do not want to use PXE/TFTP protocol on their data centres. * Users who have concerns on PXE based agent driver's security and want to have a security enhanced PXE-less deployment mechanism. The PXE based agent drivers pass management information in clear-text to the bare metal node. However, if swift proxy server and glance have HTTPS endpoints (See :ref:`EnableHTTPSinSwift`, :ref:`EnableHTTPSinGlance` for more information), the ``agent_ilo`` driver provides enhanced security by exchanging authtoken and management information with swift and glance endpoints over HTTPS. The management information and deploy ramdisk will be retrieved over encrypted management network via iLO. Tested Platforms ~~~~~~~~~~~~~~~~ This driver should work on HPE ProLiant Gen7 servers with iLO 3, Gen8 and Gen9 servers with iLO 4 and Gen10 servers with iLO 5. It has been tested with the following servers: * ProLiant DL380 G7 * ProLiant DL380e Gen8 * ProLiant DL580e Gen8 * ProLiant DL360 Gen9 UEFI * ProLiant DL380 Gen9 UEFI * ProLiant DL180 Gen9 UEFI * ProLiant XL450 Gen9 UEFI * ProLiant DL360 Gen10 For more up-to-date information, check the `iLO driver wiki page `_. Features ~~~~~~~~ * PXE-less deploy with virtual media using Ironic Python Agent(IPA). * Support for out-of-band cleaning operations. * Remote Console * HW Sensors * IPA runs on the bare metal node and pulls the image directly from swift. * Supports booting the instance from virtual media (netboot) as well as booting locally from disk. By default, the instance will always boot from virtual media for partition images. * Segregates management info from data channel. * UEFI Boot Support * UEFI Secure Boot Support * Support to use default in-band cleaning operations supported by Ironic Python Agent. For more details, see :ref:`InbandvsOutOfBandCleaning`. * Support for out-of-band hardware inspection. * Swiftless deploy for intermediate images. * HTTP(S) Based Deploy. * iLO drivers with standalone ironic. * Supports tenant network isolation for node instances provisioned for vlan type networks. Requirements ~~~~~~~~~~~~ * **iLO 4** or **iLO 5 Advanced License** needs to be installed on iLO to enable Virtual Media Boot feature. * **Swift Object Storage Service** - iLO driver uses swift to store temporary FAT images as well as boot ISO images. * **Glance Image Service with swift configured as its backend** - When using ``agent_ilo`` driver, the image containing the agent is retrieved from swift directly by the iLO. Deploy Process ~~~~~~~~~~~~~~ Please refer to `Netboot with glance and swift`_ and `Localboot with glance and swift for partition images`_ for the deploy process of partition image and `Localboot with glance and swift`_ for the deploy process of whole disk image. Configuring and Enabling the driver ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Please refer to `Glance Configuration`_ and `Enable driver`_. Registering ProLiant node in ironic ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Nodes configured for iLO driver should have the ``driver`` property set to ``agent_ilo``. The following configuration values are also required in ``driver_info``: - ``ilo_address``: IP address or hostname of the iLO. - ``ilo_username``: Username for the iLO with administrator privileges. - ``ilo_password``: Password for the above iLO user. - ``ilo_deploy_iso``: The glance UUID of the deploy ramdisk ISO image. - ``ca_file``: (optional) CA certificate file to validate iLO. - ``client_port``: (optional) Port to be used for iLO operations if you are using a custom port on the iLO. Default port used is 443. - ``client_timeout``: (optional) Timeout for iLO operations. Default timeout is 60 seconds. - ``console_port``: (optional) Node's UDP port for console access. Any unused port on the ironic conductor node may be used. .. note:: To update SSL certificates into iLO, you can refer to `HPE Integrated Lights-Out Security Technology Brief `_. You can use iLO hostname or IP address as a 'Common Name (CN)' while generating Certificate Signing Request (CSR). Use the same value as `ilo_address` while enrolling node to Bare Metal service to avoid SSL certificate validation errors related to hostname mismatch. .. note:: If configuration values for ``ca_file``, ``client_port`` and ``client_timeout`` are not provided in the ``driver_info`` of the node, the corresponding config variables defined under ``[ilo]`` section in ironic.conf will be used. For example, you could run a similar command like below to enroll the ProLiant node:: openstack baremetal node create --driver agent_ilo \ --driver-info ilo_address= \ --driver-info ilo_username= \ --driver-info ilo_password= \ --driver-info ilo_deploy_iso= Boot modes ~~~~~~~~~~ Please refer to `Boot mode support`_ for more information. UEFI Secure Boot ~~~~~~~~~~~~~~~~ Please refer to `UEFI Secure Boot Support`_ for more information. Node Cleaning ~~~~~~~~~~~~~ Please refer to `Node Cleaning Support`_ for more information. Hardware Inspection ~~~~~~~~~~~~~~~~~~~ Please refer to `Hardware Inspection Support`_ for more information. Swiftless deploy for intermediate deploy and boot images ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Please refer to `Swiftless deploy for intermediate images`_ for more information. HTTP(S) Based Deploy ~~~~~~~~~~~~~~~~~~~~ Please refer to `HTTP(S) Based Deploy Support`_ for more information. iLO drivers with standalone ironic ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Please refer to `Support for iLO drivers with Standalone Ironic`_ for more information. RAID Configuration ~~~~~~~~~~~~~~~~~~ Please refer to `RAID Support`_ for more information. pxe_ilo driver ^^^^^^^^^^^^^^ Overview ~~~~~~~~ ``pxe_ilo`` driver uses PXE/iSCSI (just like ``pxe_ipmitool`` driver) to deploy the image and uses iLO to do power and management operations on the bare metal node(instead of using IPMI). Target Users ~~~~~~~~~~~~ * Users who want to use PXE/iSCSI for deployment in their environment or who don't have Advanced License in their iLO. * Users who don't want to configure boot mode manually on the bare metal node. Tested Platforms ~~~~~~~~~~~~~~~~ This driver should work on HPE ProLiant Gen7 servers with iLO 3, Gen8 and Gen9 servers with iLO 4 and Gen10 servers with iLO 5. It has been tested with the following servers: * ProLiant DL380 G7 * ProLiant DL380e Gen8 * ProLiant DL380e Gen8 * ProLiant DL580 Gen8 (BIOS/UEFI) * ProLiant DL360 Gen9 UEFI * ProLiant DL380 Gen9 UEFI * ProLiant XL450 Gen9 UEFI * ProLiant DL360 Gen10 For more up-to-date information, check the `iLO driver wiki page `_. Features ~~~~~~~~ * Automatic detection of current boot mode. * Automatic setting of the required boot mode, if UEFI boot mode is requested by the nova flavor's extra spec. * Supports both out-of-band and in-band cleaning operations. For more details, see :ref:`InbandvsOutOfBandCleaning`. * Support for out-of-band hardware inspection. * Supports UEFI Boot mode * Supports UEFI Secure Boot * HTTP(S) Based Deploy. Requirements ~~~~~~~~~~~~ None. Configuring and Enabling the driver ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Build a deploy image, see :ref:`deploy-ramdisk` 2. Upload this image to glance:: glance image-create --name deploy-ramdisk.kernel --disk-format aki --container-format aki < deploy-ramdisk.kernel glance image-create --name deploy-ramdisk.initramfs --disk-format ari --container-format ari < deploy-ramdisk.initramfs 3. Add ``pxe_ilo`` to the list of ``enabled_drivers`` in ``/etc/ironic/ironic.conf``. For example::: enabled_drivers = fake,pxe_ipmitool,pxe_ilo 4. Restart the ironic conductor service:: service ironic-conductor restart Registering ProLiant node in ironic ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Nodes configured for iLO driver should have the ``driver`` property set to ``pxe_ilo``. The following configuration values are also required in ``driver_info``: - ``ilo_address``: IP address or hostname of the iLO. - ``ilo_username``: Username for the iLO with administrator privileges. - ``ilo_password``: Password for the above iLO user. - ``deploy_kernel``: The glance UUID of the deployment kernel. - ``deploy_ramdisk``: The glance UUID of the deployment ramdisk. - ``ca_file``: (optional) CA certificate file to validate iLO. - ``client_port``: (optional) Port to be used for iLO operations if you are using a custom port on the iLO. Default port used is 443. - ``client_timeout``: (optional) Timeout for iLO operations. Default timeout is 60 seconds. - ``console_port``: (optional) Node's UDP port for console access. Any unused port on the ironic conductor node may be used. .. note:: To update SSL certificates into iLO, you can refer to `HPE Integrated Lights-Out Security Technology Brief `_. You can use iLO hostname or IP address as a 'Common Name (CN)' while generating Certificate Signing Request (CSR). Use the same value as `ilo_address` while enrolling node to Bare Metal service to avoid SSL certificate validation errors related to hostname mismatch. .. note:: If configuration values for ``ca_file``, ``client_port`` and ``client_timeout`` are not provided in the ``driver_info`` of the node, the corresponding config variables defined under ``[ilo]`` section in ironic.conf will be used. For example, you could run a similar command like below to enroll the ProLiant node:: openstack baremetal node create --driver pxe_ilo \ --driver-info ilo_address= \ --driver-info ilo_username= \ --driver-info ilo_password= \ --driver-info deploy_kernel= \ --driver-info deploy_ramdisk= Boot modes ~~~~~~~~~~ Please refer to `Boot mode support`_ for more information. UEFI Secure Boot ~~~~~~~~~~~~~~~~ Please refer to `UEFI Secure Boot Support`_ for more information. Node Cleaning ~~~~~~~~~~~~~ Please refer to `Node Cleaning Support`_ for more information. Hardware Inspection ~~~~~~~~~~~~~~~~~~~ Please refer to `Hardware Inspection Support`_ for more information. HTTP(S) Based Deploy ~~~~~~~~~~~~~~~~~~~~ Please refer to `HTTP(S) Based Deploy Support`_ for more information. iLO drivers with standalone ironic ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Please refer to `Support for iLO drivers with Standalone Ironic`_ for more information. RAID Configuration ~~~~~~~~~~~~~~~~~~ Please refer to `RAID Support`_ for more information. Functionalities across drivers ============================== Boot mode support ^^^^^^^^^^^^^^^^^ The hardware type ``ilo`` and iLO-based classic drivers support automatic detection and setting of boot mode (Legacy BIOS or UEFI). * When boot mode capability is not configured: - If config variable ``default_boot_mode`` in ``[ilo]`` section of ironic configuration file is set to either 'bios' or 'uefi', then iLO drivers use that boot mode for provisioning the baremetal ProLiant servers. - If the pending boot mode is set on the node then iLO drivers use that boot mode for provisioning the baremetal ProLiant servers. - If the pending boot mode is not set on the node then iLO drivers use 'uefi' boot mode for UEFI capable servers and "bios" when UEFI is not supported. * When boot mode capability is configured, the driver sets the pending boot mode to the configured value. * Only one boot mode (either ``uefi`` or ``bios``) can be configured for the node. * If the operator wants a node to boot always in ``uefi`` mode or ``bios`` mode, then they may use ``capabilities`` parameter within ``properties`` field of an ironic node. To configure a node in ``uefi`` mode, then set ``capabilities`` as below:: openstack baremetal node set --property capabilities='boot_mode:uefi' Nodes having ``boot_mode`` set to ``uefi`` may be requested by adding an ``extra_spec`` to the nova flavor:: nova flavor-key ironic-test-3 set capabilities:boot_mode="uefi" nova boot --flavor ironic-test-3 --image test-image instance-1 If ``capabilities`` is used in ``extra_spec`` as above, nova scheduler (``ComputeCapabilitiesFilter``) will match only ironic nodes which have the ``boot_mode`` set appropriately in ``properties/capabilities``. It will filter out rest of the nodes. The above facility for matching in nova can be used in heterogeneous environments where there is a mix of ``uefi`` and ``bios`` machines, and operator wants to provide a choice to the user regarding boot modes. If the flavor doesn't contain ``boot_mode`` then nova scheduler will not consider boot mode as a placement criteria, hence user may get either a BIOS or UEFI machine that matches with user specified flavors. The automatic boot ISO creation for UEFI boot mode has been enabled in Kilo. The manual creation of boot ISO for UEFI boot mode is also supported. For the latter, the boot ISO for the deploy image needs to be built separately and the deploy image's ``boot_iso`` property in glance should contain the glance UUID of the boot ISO. For building boot ISO, add ``iso`` element to the diskimage-builder command to build the image. For example:: disk-image-create ubuntu baremetal iso .. _`iLO UEFI Secure Boot Support`: UEFI Secure Boot Support ^^^^^^^^^^^^^^^^^^^^^^^^ The hardware type ``ilo`` and iLO-based classic drivers support secure boot deploy. The UEFI secure boot can be configured in ironic by adding ``secure_boot`` parameter in the ``capabilities`` parameter within ``properties`` field of an ironic node. ``secure_boot`` is a boolean parameter and takes value as ``true`` or ``false``. To enable ``secure_boot`` on a node add it to ``capabilities`` as below:: openstack baremetal node set --property capabilities='secure_boot:true' Alternatively see `Hardware Inspection Support`_ to know how to automatically populate the secure boot capability. Nodes having ``secure_boot`` set to ``true`` may be requested by adding an ``extra_spec`` to the nova flavor:: nova flavor-key ironic-test-3 set capabilities:secure_boot="true" nova boot --flavor ironic-test-3 --image test-image instance-1 If ``capabilities`` is used in ``extra_spec`` as above, nova scheduler (``ComputeCapabilitiesFilter``) will match only ironic nodes which have the ``secure_boot`` set appropriately in ``properties/capabilities``. It will filter out rest of the nodes. The above facility for matching in nova can be used in heterogeneous environments where there is a mix of machines supporting and not supporting UEFI secure boot, and operator wants to provide a choice to the user regarding secure boot. If the flavor doesn't contain ``secure_boot`` then nova scheduler will not consider secure boot mode as a placement criteria, hence user may get a secure boot capable machine that matches with user specified flavors but deployment would not use its secure boot capability. Secure boot deploy would happen only when it is explicitly specified through flavor. Use element ``ubuntu-signed`` or ``fedora`` to build signed deploy iso and user images from `diskimage-builder `_. Please refer to :ref:`deploy-ramdisk` for more information on building deploy ramdisk. The below command creates files named cloud-image-boot.iso, cloud-image.initrd, cloud-image.vmlinuz and cloud-image.qcow2 in the current working directory:: cd ./bin/disk-image-create -o cloud-image ubuntu-signed baremetal iso .. note:: In UEFI secure boot, digitally signed bootloader should be able to validate digital signatures of kernel during boot process. This requires that the bootloader contains the digital signatures of the kernel. For ``iscsi_ilo`` driver, it is recommended that ``boot_iso`` property for user image contains the glance UUID of the boot ISO. If ``boot_iso`` property is not updated in glance for the user image, it would create the ``boot_iso`` using bootloader from the deploy iso. This ``boot_iso`` will be able to boot the user image in UEFI secure boot environment only if the bootloader is signed and can validate digital signatures of user image kernel. Ensure the public key of the signed image is loaded into bare metal to deploy signed images. For HPE ProLiant Gen9 servers, one can enroll public key using iLO System Utilities UI. Please refer to section ``Accessing Secure Boot options`` in `HP UEFI System Utilities User Guide `_. One can also refer to white paper on `Secure Boot for Linux on HP ProLiant servers `_ for additional details. For more up-to-date information, refer `iLO driver wiki page `_ .. _ilo_node_cleaning: Node Cleaning Support ^^^^^^^^^^^^^^^^^^^^^ The hardware type ``ilo`` and iLO-based classic drivers support node cleaning. For more information on node cleaning, see :ref:`cleaning` Supported **Automated** Cleaning Operations ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * The automated cleaning operations supported are: * ``reset_bios_to_default``: Resets system ROM settings to default. By default, enabled with priority 10. This clean step is supported only on Gen9 and above servers. * ``reset_secure_boot_keys_to_default``: Resets secure boot keys to manufacturer's defaults. This step is supported only on Gen9 and above servers. By default, enabled with priority 20 . * ``reset_ilo_credential``: Resets the iLO password, if ``ilo_change_password`` is specified as part of node's driver_info. By default, enabled with priority 30. * ``clear_secure_boot_keys``: Clears all secure boot keys. This step is supported only on Gen9 and above servers. By default, this step is disabled. * ``reset_ilo``: Resets the iLO. By default, this step is disabled. * ``erase_devices``: An inband clean step that performs disk erase on all the disks including the disks visible to OS as well as the raw disks visible to Smart Storage Administrator (SSA). This step supports erasing of the raw disks visible to SSA in Proliant servers only with the ramdisk created using diskimage-builder from Ocata release. By default, this step is disabled. See `Disk Erase Support`_ for more details. * For in-band cleaning operations supported by ``agent_ilo`` driver, see :ref:`InbandvsOutOfBandCleaning`. * All the automated cleaning steps have an explicit configuration option for priority. In order to disable or change the priority of the automated clean steps, respective configuration option for priority should be updated in ironic.conf. * Updating clean step priority to 0, will disable that particular clean step and will not run during automated cleaning. * Configuration Options for the automated clean steps are listed under ``[ilo]`` and ``[deploy]`` section in ironic.conf :: [ilo] clean_priority_reset_ilo=0 clean_priority_reset_bios_to_default=10 clean_priority_reset_secure_boot_keys_to_default=20 clean_priority_clear_secure_boot_keys=0 clean_priority_reset_ilo_credential=30 [deploy] erase_devices_priority=0 For more information on node automated cleaning, see :ref:`automated_cleaning` Supported **Manual** Cleaning Operations ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * The manual cleaning operations supported are: ``activate_license``: Activates the iLO Advanced license. This is an out-of-band manual cleaning step associated with the ``management`` interface. See `Activating iLO Advanced license as manual clean step`_ for user guidance on usage. Please note that this operation cannot be performed using virtual media based drivers like ``iscsi_ilo`` and ``agent_ilo`` as they need this type of advanced license already active to use virtual media to boot into to start cleaning operation. Virtual media is an advanced feature. If an advanced license is already active and the user wants to overwrite the current license key, for example in case of a multi-server activation key delivered with a flexible-quantity kit or after completing an Activation Key Agreement (AKA), then these drivers can still be used for executing this cleaning step. ``update_firmware``: Updates the firmware of the devices. Also an out-of-band step associated with the ``management`` interface. See `Initiating firmware update as manual clean step`_ for user guidance on usage. The supported devices for firmware update are: ``ilo``, ``cpld``, ``power_pic``, ``bios`` and ``chassis``. Please refer to below table for their commonly used descriptions. .. csv-table:: :header: "Device", "Description" :widths: 30, 80 "``ilo``", "BMC for HPE ProLiant servers" "``cpld``", "System programmable logic device" "``power_pic``", "Power management controller" "``bios``", "HPE ProLiant System ROM" "``chassis``", "System chassis device" Some devices firmware cannot be updated via this method, such as: storage controllers, host bus adapters, disk drive firmware, network interfaces and Onboard Administrator (OA). ``update_firmware_sum``: Updates all or list of user specified firmware components on the node using Smart Update Manager (SUM). It is an inband step associated with the ``management`` interface. See `Smart Update Manager (SUM) based firmware update`_ for more information on usage. * iLO with firmware version 1.5 is minimally required to support all the operations. For more information on node manual cleaning, see :ref:`manual_cleaning` .. _ilo-inspection: Hardware Inspection Support ^^^^^^^^^^^^^^^^^^^^^^^^^^^ The hardware type ``ilo`` and iLO-based classic drivers support hardware inspection. .. note:: * The disk size is returned by RIBCL/RIS only when RAID is preconfigured on the storage. If the storage is Direct Attached Storage, then RIBCL/RIS fails to get the disk size. * The SNMPv3 inspection gets disk size for all types of storages. If RIBCL/RIS is unable to get disk size and SNMPv3 inspection is requested, the proliantutils does SNMPv3 inspection to get the disk size. If proliantutils is unable to get the disk size, it raises an error. This feature is available in proliantutils release version >= 2.2.0. * The iLO must be updated with SNMPv3 authentication details. Pleae refer to the section `SNMPv3 Authentication` in `HPE iLO4 User Guide`_ for setting up authentication details on iLO. The following parameters are mandatory to be given in driver_info for SNMPv3 inspection: * ``snmp_auth_user`` : The SNMPv3 user. * ``snmp_auth_prot_password`` : The auth protocol pass phrase. * ``snmp_auth_priv_password`` : The privacy protocol pass phrase. The following parameters are optional for SNMPv3 inspection: * ``snmp_auth_protocol`` : The Auth Protocol. The valid values are "MD5" and "SHA". The iLO default value is "MD5". * ``snmp_auth_priv_protocol`` : The Privacy protocol. The valid values are "AES" and "DES". The iLO default value is "DES". The inspection process will discover the following essential properties (properties required for scheduling deployment): * ``memory_mb``: memory size * ``cpus``: number of cpus * ``cpu_arch``: cpu architecture * ``local_gb``: disk size Inspection can also discover the following extra capabilities for iLO drivers: * ``ilo_firmware_version``: iLO firmware version * ``rom_firmware_version``: ROM firmware version * ``secure_boot``: secure boot is supported or not. The possible values are 'true' or 'false'. The value is returned as 'true' if secure boot is supported by the server. * ``server_model``: server model * ``pci_gpu_devices``: number of gpu devices connected to the bare metal. * ``nic_capacity``: the max speed of the embedded NIC adapter. * ``sriov_enabled``: true, if server has the SRIOV supporting NIC. * ``has_rotational``: true, if server has HDD disk. * ``has_ssd``: true, if server has SSD disk. * ``has_nvme_ssd``: true, if server has NVME SSD disk. * ``cpu_vt``: true, if server supports cpu virtualization. * ``hardware_supports_raid``: true, if RAID can be configured on the server using RAID controller. * ``nvdimm_n``: true, if server has NVDIMM_N type of persistent memory. * ``persistent_memory``: true, if server has persistent memory. * ``logical_nvdimm_n``: true, if server has logical NVDIMM_N configured. * ``rotational_drive__rpm``: The capabilities ``rotational_drive_4800_rpm``, ``rotational_drive_5400_rpm``, ``rotational_drive_7200_rpm``, ``rotational_drive_10000_rpm`` and ``rotational_drive_15000_rpm`` are set to true if the server has HDD drives with speed of 4800, 5400, 7200, 10000 and 15000 rpm respectively. * ``logical_raid_level_``: The capabilities ``logical_raid_level_0``, ``logical_raid_level_1``, ``logical_raid_level_2``, ``logical_raid_level_5``, ``logical_raid_level_6``, ``logical_raid_level_10``, ``logical_raid_level_50`` and ``logical_raid_level_60`` are set to true if any of the raid levels among 0, 1, 2, 5, 6, 10, 50 and 60 are configured on the system. .. note:: * The capability ``nic_capacity`` can only be discovered if ipmitool version >= 1.8.15 is used on the conductor. The latest version can be downloaded from `here `__. * The iLO firmware version needs to be 2.10 or above for nic_capacity to be discovered. The operator can specify these capabilities in nova flavor for node to be selected for scheduling:: nova flavor-key my-baremetal-flavor set capabilities:server_model=" Gen8" nova flavor-key my-baremetal-flavor set capabilities:nic_capacity="10Gb" nova flavor-key my-baremetal-flavor set capabilities:ilo_firmware_version=" 2.10" nova flavor-key my-baremetal-flavor set capabilities:has_ssd="true" See :ref:`capabilities-discovery` for more details and examples. Swiftless deploy for intermediate images ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The hardware type ``ilo`` with ``ilo-virtual-media`` as boot interface and virtual media based classical drivers (``iscsi_ilo`` and ``agent_ilo``) can deploy and boot the server with and without ``swift`` being used for hosting the intermediate temporary floppy image (holding metadata for deploy kernel and ramdisk) and the boot ISO. A local HTTP(S) web server on each conductor node needs to be configured. Please refer to `Web server configuration on conductor`_ for more information. The HTTPS web server needs to be enabled (instead of HTTP web server) in order to send management information and images in encrypted channel over HTTPS. .. note:: This feature assumes that the user inputs are on Glance which uses swift as backend. If swift dependency has to be eliminated, please refer to `HTTP(S) Based Deploy Support`_ also. Deploy Process ~~~~~~~~~~~~~~ Please refer to `Netboot in swiftless deploy for intermediate images`_ for partition image support and `Localboot in swiftless deploy for intermediate images`_ for whole disk image support. HTTP(S) Based Deploy Support ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The user input for the images given in ``driver_info`` like ``ilo_deploy_iso``, ``deploy_kernel`` and ``deploy_ramdisk`` and in ``instance_info`` like ``image_source``, ``kernel``, ``ramdisk`` and ``ilo_boot_iso`` may also be given as HTTP(S) URLs. The HTTP(S) web server can be configured in many ways. For the Apache web server on Ubuntu, refer `here `_. The web server may reside on a different system than the conductor nodes, but its URL must be reachable by the conductor and the bare metal nodes. Deploy Process ~~~~~~~~~~~~~~ Please refer to `Netboot with HTTP(S) based deploy`_ for partition image boot and `Localboot with HTTP(S) based deploy`_ for whole disk image boot. Support for iLO drivers with Standalone Ironic ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ It is possible to use ironic as standalone services without other OpenStack services. The ``ilo`` hardware type and the iLO-based classic drivers can be used in standalone ironic. This feature is referred to as ``iLO drivers with standalone ironic`` in this document. Configuration ~~~~~~~~~~~~~ The HTTP(S) web server needs to be configured as described in `HTTP(S) Based Deploy Support`_ and `Web server configuration on conductor`_ needs to be configured for hosting intermediate images on conductor as described in `Swiftless deploy for intermediate images`_. Deploy Process ~~~~~~~~~~~~~~ ``iscsi_ilo`` and ``agent_ilo`` supports both netboot and localboot. Please refer to `Netboot in standalone ironic`_ and `Localboot in standalone ironic`_ for details of deploy process for netboot and localboot respectively. For ``pxe_ilo``, the deploy process is same as native ``pxe_ipmitool`` driver. Deploy Process ============== Netboot with glance and swift ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. seqdiag:: :scale: 80 diagram { Glance; Conductor; Baremetal; Swift; IPA; iLO; activation = none; span_height = 1; edge_length = 250; default_note_color = white; default_fontsize = 14; Conductor -> iLO [label = "Powers off the node"]; Conductor -> Glance [label = "Download user image"]; Conductor -> Glance [label = "Get the metadata for deploy ISO"]; Conductor -> Conductor [label = "Generates swift tempURL for deploy ISO"]; Conductor -> Conductor [label = "Creates the FAT32 image containing Ironic API URL and driver name"]; Conductor -> Swift [label = "Uploads the FAT32 image"]; Conductor -> Conductor [label = "Generates swift tempURL for FAT32 image"]; Conductor -> iLO [label = "Attaches the FAT32 image swift tempURL as virtual media floppy"]; Conductor -> iLO [label = "Attaches the deploy ISO swift tempURL as virtual media CDROM"]; Conductor -> iLO [label = "Sets one time boot to CDROM"]; Conductor -> iLO [label = "Reboot the node"]; iLO -> Swift [label = "Downloads deploy ISO"]; Baremetal -> iLO [label = "Boots deploy kernel/ramdisk from iLO virtual media CDROM"]; IPA -> Conductor [label = "Lookup node"]; Conductor -> IPA [label = "Provides node UUID"]; IPA -> Conductor [label = "Heartbeat"]; Conductor -> IPA [label = "Exposes the disk over iSCSI"]; Conductor -> Conductor [label = "Connects to bare metal's disk over iSCSI and writes image"]; Conductor -> Conductor [label = "Generates the boot ISO"]; Conductor -> Swift [label = "Uploads the boot ISO"]; Conductor -> Conductor [label = "Generates swift tempURL for boot ISO"]; Conductor -> iLO [label = "Attaches boot ISO swift tempURL as virtual media CDROM"]; Conductor -> iLO [label = "Sets boot device to CDROM"]; Conductor -> IPA [label = "Power off the node"]; Conductor -> iLO [label = "Power on the node"]; iLO -> Swift [label = "Downloads boot ISO"]; iLO -> Baremetal [label = "Boots the instance kernel/ramdisk from iLO virtual media CDROM"]; Baremetal -> Baremetal [label = "Instance kernel finds root partition and continues booting from disk"]; } Localboot with glance and swift for partition images ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. seqdiag:: :scale: 80 diagram { Glance; Conductor; Baremetal; Swift; IPA; iLO; activation = none; span_height = 1; edge_length = 250; default_note_color = white; default_fontsize = 14; Conductor -> iLO [label = "Powers off the node"]; Conductor -> Glance [label = "Get the metadata for deploy ISO"]; Glance -> Conductor [label = "Returns the metadata for deploy ISO"]; Conductor -> Conductor [label = "Generates swift tempURL for deploy ISO"]; Conductor -> Conductor [label = "Creates the FAT32 image containing ironic API URL and driver name"]; Conductor -> Swift [label = "Uploads the FAT32 image"]; Conductor -> Conductor [label = "Generates swift tempURL for FAT32 image"]; Conductor -> iLO [label = "Attaches the FAT32 image swift tempURL as virtual media floppy"]; Conductor -> iLO [label = "Attaches the deploy ISO swift tempURL as virtual media CDROM"]; Conductor -> iLO [label = "Sets one time boot to CDROM"]; Conductor -> iLO [label = "Reboot the node"]; iLO -> Swift [label = "Downloads deploy ISO"]; Baremetal -> iLO [label = "Boots deploy kernel/ramdisk from iLO virtual media CDROM"]; IPA -> Conductor [label = "Lookup node"]; Conductor -> IPA [label = "Provides node UUID"]; IPA -> Conductor [label = "Heartbeat"]; Conductor -> IPA [label = "Sends the user image HTTP(S) URL"]; IPA -> Swift [label = "Retrieves the user image on bare metal"]; IPA -> IPA [label = "Writes user image to root partition"]; IPA -> IPA [label = "Installs boot loader"]; IPA -> Conductor [label = "Heartbeat"]; Conductor -> Baremetal [label = "Sets boot device to disk"]; Conductor -> IPA [label = "Power off the node"]; Conductor -> iLO [label = "Power on the node"]; Baremetal -> Baremetal [label = "Boot user image from disk"]; } Localboot with glance and swift ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. seqdiag:: :scale: 80 diagram { Glance; Conductor; Baremetal; Swift; IPA; iLO; activation = none; span_height = 1; edge_length = 250; default_note_color = white; default_fontsize = 14; Conductor -> iLO [label = "Powers off the node"]; Conductor -> Glance [label = "Get the metadata for deploy ISO"]; Glance -> Conductor [label = "Returns the metadata for deploy ISO"]; Conductor -> Conductor [label = "Generates swift tempURL for deploy ISO"]; Conductor -> Conductor [label = "Creates the FAT32 image containing ironic API URL and driver name"]; Conductor -> Swift [label = "Uploads the FAT32 image"]; Conductor -> Conductor [label = "Generates swift tempURL for FAT32 image"]; Conductor -> iLO [label = "Attaches the FAT32 image swift tempURL as virtual media floppy"]; Conductor -> iLO [label = "Attaches the deploy ISO swift tempURL as virtual media CDROM"]; Conductor -> iLO [label = "Sets one time boot to CDROM"]; Conductor -> iLO [label = "Reboot the node"]; iLO -> Swift [label = "Downloads deploy ISO"]; Baremetal -> iLO [label = "Boots deploy kernel/ramdisk from iLO virtual media CDROM"]; IPA -> Conductor [label = "Lookup node"]; Conductor -> IPA [label = "Provides node UUID"]; IPA -> Conductor [label = "Heartbeat"]; Conductor -> IPA [label = "Sends the user image HTTP(S) URL"]; IPA -> Swift [label = "Retrieves the user image on bare metal"]; IPA -> IPA [label = "Writes user image to disk"]; IPA -> Conductor [label = "Heartbeat"]; Conductor -> Baremetal [label = "Sets boot device to disk"]; Conductor -> IPA [label = "Power off the node"]; Conductor -> iLO [label = "Power on the node"]; Baremetal -> Baremetal [label = "Boot user image from disk"]; } Netboot in swiftless deploy for intermediate images ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. seqdiag:: :scale: 80 diagram { Glance; Conductor; Baremetal; ConductorWebserver; IPA; iLO; activation = none; span_height = 1; edge_length = 250; default_note_color = white; default_fontsize = 14; Conductor -> iLO [label = "Powers off the node"]; Conductor -> Glance [label = "Download user image"]; Conductor -> Glance [label = "Get the metadata for deploy ISO"]; Conductor -> Conductor [label = "Generates swift tempURL for deploy ISO"]; Conductor -> Conductor [label = "Creates the FAT32 image containing Ironic API URL and driver name"]; Conductor -> ConductorWebserver [label = "Uploads the FAT32 image"]; Conductor -> iLO [label = "Attaches the FAT32 image URL as virtual media floppy"]; Conductor -> iLO [label = "Attaches the deploy ISO swift tempURL as virtual media CDROM"]; Conductor -> iLO [label = "Sets one time boot to CDROM"]; Conductor -> iLO [label = "Reboot the node"]; iLO -> Swift [label = "Downloads deploy ISO"]; Baremetal -> iLO [label = "Boots deploy kernel/ramdisk from iLO virtual media CDROM"]; IPA -> Conductor [label = "Lookup node"]; Conductor -> IPA [label = "Provides node UUID"]; IPA -> Conductor [label = "Heartbeat"]; Conductor -> IPA [label = "Exposes the disk over iSCSI"]; Conductor -> Conductor [label = "Connects to bare metal's disk over iSCSI and writes image"]; Conductor -> Conductor [label = "Generates the boot ISO"]; Conductor -> ConductorWebserver [label = "Uploads the boot ISO"]; Conductor -> iLO [label = "Attaches boot ISO URL as virtual media CDROM"]; Conductor -> iLO [label = "Sets boot device to CDROM"]; Conductor -> IPA [label = "Power off the node"]; Conductor -> iLO [label = "Power on the node"]; iLO -> ConductorWebserver [label = "Downloads boot ISO"]; iLO -> Baremetal [label = "Boots the instance kernel/ramdisk from iLO virtual media CDROM"]; Baremetal -> Baremetal [label = "Instance kernel finds root partition and continues booting from disk"]; } Localboot in swiftless deploy for intermediate images ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. seqdiag:: :scale: 80 diagram { Glance; Conductor; Baremetal; ConductorWebserver; IPA; iLO; activation = none; span_height = 1; edge_length = 250; default_note_color = white; default_fontsize = 14; Conductor -> iLO [label = "Powers off the node"]; Conductor -> Glance [label = "Get the metadata for deploy ISO"]; Glance -> Conductor [label = "Returns the metadata for deploy ISO"]; Conductor -> Conductor [label = "Generates swift tempURL for deploy ISO"]; Conductor -> Conductor [label = "Creates the FAT32 image containing Ironic API URL and driver name"]; Conductor -> ConductorWebserver [label = "Uploads the FAT32 image"]; Conductor -> iLO [label = "Attaches the FAT32 image URL as virtual media floppy"]; Conductor -> iLO [label = "Attaches the deploy ISO swift tempURL as virtual media CDROM"]; Conductor -> iLO [label = "Sets one time boot to CDROM"]; Conductor -> iLO [label = "Reboot the node"]; iLO -> Swift [label = "Downloads deploy ISO"]; Baremetal -> iLO [label = "Boots deploy kernel/ramdisk from iLO virtual media CDROM"]; IPA -> Conductor [label = "Lookup node"]; Conductor -> IPA [label = "Provides node UUID"]; IPA -> Conductor [label = "Heartbeat"]; Conductor -> IPA [label = "Sends the user image HTTP(S) URL"]; IPA -> Swift [label = "Retrieves the user image on bare metal"]; IPA -> IPA [label = "Writes user image to disk"]; IPA -> Conductor [label = "Heartbeat"]; Conductor -> Baremetal [label = "Sets boot device to disk"]; Conductor -> IPA [label = "Power off the node"]; Conductor -> Baremetal [label = "Power on the node"]; Baremetal -> Baremetal [label = "Boot user image from disk"]; } Netboot with HTTP(S) based deploy ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. seqdiag:: :scale: 80 diagram { Webserver; Conductor; Baremetal; Swift; IPA; iLO; activation = none; span_height = 1; edge_length = 250; default_note_color = white; default_fontsize = 14; Conductor -> iLO [label = "Powers off the node"]; Conductor -> Webserver [label = "Download user image"]; Conductor -> Conductor [label = "Creates the FAT32 image containing Ironic API URL and driver name"]; Conductor -> Swift [label = "Uploads the FAT32 image"]; Conductor -> Conductor [label = "Generates swift tempURL for FAT32 image"]; Conductor -> iLO [label = "Attaches the FAT32 image swift tempURL as virtual media floppy"]; Conductor -> iLO [label = "Attaches the deploy ISO URL as virtual media CDROM"]; Conductor -> iLO [label = "Sets one time boot to CDROM"]; Conductor -> iLO [label = "Reboot the node"]; iLO -> Webserver [label = "Downloads deploy ISO"]; Baremetal -> iLO [label = "Boots deploy kernel/ramdisk from iLO virtual media CDROM"]; IPA -> Conductor [label = "Lookup node"]; Conductor -> IPA [label = "Provides node UUID"]; IPA -> Conductor [label = "Heartbeat"]; Conductor -> IPA [label = "Exposes the disk over iSCSI"]; Conductor -> Conductor [label = "Connects to bare metal's disk over iSCSI and writes image"]; Conductor -> Conductor [label = "Generates the boot ISO"]; Conductor -> Swift [label = "Uploads the boot ISO"]; Conductor -> Conductor [label = "Generates swift tempURL for boot ISO"]; Conductor -> iLO [label = "Attaches boot ISO swift tempURL as virtual media CDROM"]; Conductor -> iLO [label = "Sets boot device to CDROM"]; Conductor -> IPA [label = "Power off the node"]; Conductor -> iLO [label = "Power on the node"]; iLO -> Swift [label = "Downloads boot ISO"]; iLO -> Baremetal [label = "Boots the instance kernel/ramdisk from iLO virtual media CDROM"]; Baremetal -> Baremetal [label = "Instance kernel finds root partition and continues booting from disk"]; } Localboot with HTTP(S) based deploy ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. seqdiag:: :scale: 80 diagram { Webserver; Conductor; Baremetal; Swift; IPA; iLO; activation = none; span_height = 1; edge_length = 250; default_note_color = white; default_fontsize = 14; Conductor -> iLO [label = "Powers off the node"]; Conductor -> Conductor [label = "Creates the FAT32 image containing ironic API URL and driver name"]; Conductor -> Swift [label = "Uploads the FAT32 image"]; Conductor -> Conductor [label = "Generates swift tempURL for FAT32 image"]; Conductor -> iLO [label = "Attaches the FAT32 image swift tempURL as virtual media floppy"]; Conductor -> iLO [label = "Attaches the deploy ISO URL as virtual media CDROM"]; Conductor -> iLO [label = "Sets one time boot to CDROM"]; Conductor -> iLO [label = "Reboot the node"]; iLO -> Webserver [label = "Downloads deploy ISO"]; Baremetal -> iLO [label = "Boots deploy kernel/ramdisk from iLO virtual media CDROM"]; IPA -> Conductor [label = "Lookup node"]; Conductor -> IPA [label = "Provides node UUID"]; IPA -> Conductor [label = "Heartbeat"]; Conductor -> IPA [label = "Sends the user image HTTP(S) URL"]; IPA -> Webserver [label = "Retrieves the user image on bare metal"]; IPA -> IPA [label = "Writes user image to disk"]; IPA -> Conductor [label = "Heartbeat"]; Conductor -> Baremetal [label = "Sets boot device to disk"]; Conductor -> IPA [label = "Power off the node"]; Conductor -> Baremetal [label = "Power on the node"]; Baremetal -> Baremetal [label = "Boot user image from disk"]; } Netboot in standalone ironic ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. seqdiag:: :scale: 80 diagram { Webserver; Conductor; Baremetal; ConductorWebserver; IPA; iLO; activation = none; span_height = 1; edge_length = 250; default_note_color = white; default_fontsize = 14; Conductor -> iLO [label = "Powers off the node"]; Conductor -> Webserver [label = "Download user image"]; Conductor -> Conductor [label = "Creates the FAT32 image containing Ironic API URL and driver name"]; Conductor -> ConductorWebserver[label = "Uploads the FAT32 image"]; Conductor -> iLO [label = "Attaches the FAT32 image URL as virtual media floppy"]; Conductor -> iLO [label = "Attaches the deploy ISO URL as virtual media CDROM"]; Conductor -> iLO [label = "Sets one time boot to CDROM"]; Conductor -> iLO [label = "Reboot the node"]; iLO -> Webserver [label = "Downloads deploy ISO"]; Baremetal -> iLO [label = "Boots deploy kernel/ramdisk from iLO virtual media CDROM"]; IPA -> Conductor [label = "Lookup node"]; Conductor -> IPA [label = "Provides node UUID"]; IPA -> Conductor [label = "Heartbeat"]; Conductor -> IPA [label = "Exposes the disk over iSCSI"]; Conductor -> Conductor [label = "Connects to bare metal's disk over iSCSI and writes image"]; Conductor -> Conductor [label = "Generates the boot ISO"]; Conductor -> ConductorWebserver [label = "Uploads the boot ISO"]; Conductor -> iLO [label = "Attaches boot ISO URL as virtual media CDROM"]; Conductor -> iLO [label = "Sets boot device to CDROM"]; Conductor -> IPA [label = "Power off the node"]; Conductor -> iLO [label = "Power on the node"]; iLO -> ConductorWebserver [label = "Downloads boot ISO"]; iLO -> Baremetal [label = "Boots the instance kernel/ramdisk from iLO virtual media CDROM"]; Baremetal -> Baremetal [label = "Instance kernel finds root partition and continues booting from disk"]; } Localboot in standalone ironic ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. seqdiag:: :scale: 80 diagram { Webserver; Conductor; Baremetal; ConductorWebserver; IPA; iLO; activation = none; span_height = 1; edge_length = 250; default_note_color = white; default_fontsize = 14; Conductor -> iLO [label = "Powers off the node"]; Conductor -> Conductor [label = "Creates the FAT32 image containing Ironic API URL and driver name"]; Conductor -> ConductorWebserver [label = "Uploads the FAT32 image"]; Conductor -> Conductor [label = "Generates URL for FAT32 image"]; Conductor -> iLO [label = "Attaches the FAT32 image URL as virtual media floppy"]; Conductor -> iLO [label = "Attaches the deploy ISO URL as virtual media CDROM"]; Conductor -> iLO [label = "Sets one time boot to CDROM"]; Conductor -> iLO [label = "Reboot the node"]; iLO -> Webserver [label = "Downloads deploy ISO"]; Baremetal -> iLO [label = "Boots deploy kernel/ramdisk from iLO virtual media CDROM"]; IPA -> Conductor [label = "Lookup node"]; Conductor -> IPA [label = "Provides node UUID"]; IPA -> Conductor [label = "Heartbeat"]; Conductor -> IPA [label = "Sends the user image HTTP(S) URL"]; IPA -> Webserver [label = "Retrieves the user image on bare metal"]; IPA -> IPA [label = "Writes user image to disk"]; IPA -> Conductor [label = "Heartbeat"]; Conductor -> Baremetal [label = "Sets boot device to disk"]; Conductor -> IPA [label = "Power off the node"]; Conductor -> Baremetal [label = "Power on the node"]; Baremetal -> Baremetal [label = "Boot user image from disk"]; } Activating iLO Advanced license as manual clean step ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ iLO drivers can activate the iLO Advanced license key as a manual cleaning step. Any manual cleaning step can only be initiated when a node is in the ``manageable`` state. Once the manual cleaning is finished, the node will be put in the ``manageable`` state again. User can follow steps from :ref:`manual_cleaning` to initiate manual cleaning operation on a node. An example of a manual clean step with ``activate_license`` as the only clean step could be:: "clean_steps": [{ "interface": "management", "step": "activate_license", "args": { "ilo_license_key": "ABC12-XXXXX-XXXXX-XXXXX-YZ345" } }] The different attributes of ``activate_license`` clean step are as follows: .. csv-table:: :header: "Attribute", "Description" :widths: 30, 120 "``interface``", "Interface of clean step, here ``management``" "``step``", "Name of clean step, here ``activate_license``" "``args``", "Keyword-argument entry (: ) being passed to clean step" "``args.ilo_license_key``", "iLO Advanced license key to activate enterprise features. This is mandatory." Initiating firmware update as manual clean step ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ iLO drivers can invoke secure firmware update as a manual cleaning step. Any manual cleaning step can only be initiated when a node is in the ``manageable`` state. Once the manual cleaning is finished, the node will be put in the ``manageable`` state again. A user can follow steps from :ref:`manual_cleaning` to initiate manual cleaning operation on a node. An example of a manual clean step with ``update_firmware`` as the only clean step could be:: "clean_steps": [{ "interface": "management", "step": "update_firmware", "args": { "firmware_update_mode": "ilo", "firmware_images":[ { "url": "file:///firmware_images/ilo/1.5/CP024444.scexe", "checksum": "a94e683ea16d9ae44768f0a65942234d", "component": "ilo" }, { "url": "swift://firmware_container/cpld2.3.rpm", "checksum": "", "component": "cpld" }, { "url": "http://my_address:port/firmwares/bios_vLatest.scexe", "checksum": "", "component": "bios" }, { "url": "https://my_secure_address_url/firmwares/chassis_vLatest.scexe", "checksum": "", "component": "chassis" }, { "url": "file:///home/ubuntu/firmware_images/power_pic/pmc_v3.0.bin", "checksum": "", "component": "power_pic" } ] } }] The different attributes of ``update_firmware`` clean step are as follows: .. csv-table:: :header: "Attribute", "Description" :widths: 30, 120 "``interface``", "Interface of clean step, here ``management``" "``step``", "Name of clean step, here ``update_firmware``" "``args``", "Keyword-argument entry (: ) being passed to clean step" "``args.firmware_update_mode``", "Mode (or mechanism) of out-of-band firmware update. Supported value is ``ilo``. This is mandatory." "``args.firmware_images``", "Ordered list of dictionaries of images to be flashed. This is mandatory." Each firmware image block is represented by a dictionary (JSON), in the form:: { "url": "", "checksum": "", "component": "" } All the fields in the firmware image block are mandatory. * The different types of firmware url schemes supported are: ``file``, ``http``, ``https`` and ``swift``. .. note:: This feature assumes that while using ``file`` url scheme the file path is on the conductor controlling the node. .. note:: The ``swift`` url scheme assumes the swift account of the ``service`` project. The ``service`` project (tenant) is a special project created in the Keystone system designed for the use of the core OpenStack services. When Ironic makes use of Swift for storage purpose, the account is generally ``service`` and the container is generally ``ironic`` and ``ilo`` drivers use a container named ``ironic_ilo_container`` for their own purpose. .. note:: While using firmware files with a ``.rpm`` extension, make sure the commands ``rpm2cpio`` and ``cpio`` are present on the conductor, as they are utilized to extract the firmware image from the package. * The firmware components that can be updated are: ``ilo``, ``cpld``, ``power_pic``, ``bios`` and ``chassis``. * The firmware images will be updated in the order given by the operator. If there is any error during processing of any of the given firmware images provided in the list, none of the firmware updates will occur. The processing error could happen during image download, image checksum verification or image extraction. The logic is to process each of the firmware files and update them on the devices only if all the files are processed successfully. If, during the update (uploading and flashing) process, an update fails, then the remaining updates, if any, in the list will be aborted. But it is recommended to triage and fix the failure and re-attempt the manual clean step ``update_firmware`` for the aborted ``firmware_images``. The devices for which the firmwares have been updated successfully would start functioning using their newly updated firmware. * As a troubleshooting guidance on the complete process, check Ironic conductor logs carefully to see if there are any firmware processing or update related errors which may help in root causing or gain an understanding of where things were left off or where things failed. You can then fix or work around and then try again. A common cause of update failure is HPE Secure Digital Signature check failure for the firmware image file. * To compute ``md5`` checksum for your image file, you can use the following command:: $ md5sum image.rpm 66cdb090c80b71daa21a67f06ecd3f33 image.rpm Smart Update Manager (SUM) based firmware update ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The firmware update based on `SUM`_ is an inband clean step supported by iLO drivers. The firmware update is performed on all or list of user specified firmware components on the node. Refer to `SUM User Guide`_ to get more information on SUM based firmware update. ``update_firmware_sum`` clean step requires the agent ramdisk with ``Proliant Hardware Manager`` from the proliantutils version 2.5.0 or higher. See `DIB support for Proliant Hardware Manager`_ to create the agent ramdisk with ``Proliant Hardware Manager``. The attributes of ``update_firmware_sum`` clean step are as follows: .. csv-table:: :header: "Attribute", "Description" :widths: 30, 120 "``interface``", "Interface of the clean step, here ``management``" "``step``", "Name of the clean step, here ``update_firmware_sum``" "``args``", "Keyword-argument entry (: ) being passed to the clean step" The keyword arguments used for the clean step are as follows: * ``url``: URL of SPP (Service Pack for Proliant) ISO. It is mandatory. The URL schemes supported are ``http``, ``https`` and ``swift``. * ``checksum``: MD5 checksum of SPP ISO to verify the image. It is mandatory. * ``components``: List of filenames of the firmware components to be flashed. It is optional. If not provided, the firmware update is performed on all the firmware components. The clean step performs an update on all or a list of firmware components and returns the SUM log files. The log files include ``hpsum_log.txt`` and ``hpsum_detail_log.txt`` which holds the information about firmware components, firmware version for each component and their update status. The log object will be named with the following pattern:: [_]_update_firmware_sum_.tar.gz Refer to :ref:`retrieve_deploy_ramdisk_logs` for more information on enabling and viewing the logs returned from the ramdisk. An example of ``update_firmware_sum`` clean step: .. code-block:: json { "interface": "management", "step": "update_firmware_sum", "args": { "url": "http://my_address:port/SPP.iso", "checksum": "abcdefxyz", "components": ["CP024356.scexe", "CP008097.exe"] } } The clean step fails if there is any error in the processing of clean step arguments. The processing error could happen during validation of components' file extension, image download, image checksum verification or image extraction. In case of a failure, check Ironic conductor logs carefully to see if there are any validation or firmware processing related errors which may help in root cause analysis or gaining an understanding of where things were left off or where things failed. You can then fix or work around and then try again. .. warning:: This feature is officially supported only with RHEL and SUSE based IPA ramdisk. Refer to `SUM`_ for supported OS versions for specific SUM version. .. note:: Refer `Guidelines for SPP ISO`_ for steps to get SPP (Service Pack for ProLiant) ISO. RAID Support ^^^^^^^^^^^^ The inband RAID functionality is supported by iLO drivers. See :ref:`raid` for more information. Bare Metal service update node with following information after successful configuration of RAID: * Node ``properties/local_gb`` is set to the size of root volume. * Node ``properties/root_device`` is filled with ``wwn`` details of root volume. It is used by iLO drivers as root device hint during provisioning. * The value of raid level of root volume is added as ``raid_level`` capability to the node's ``capabilities`` parameter within ``properties`` field. The operator can specify the ``raid_level`` capability in nova flavor for node to be selected for scheduling:: nova flavor-key ironic-test set capabilities:raid_level="1+0" nova boot --flavor ironic-test --image test-image instance-1 .. _DIB_raid_support: DIB support for Proliant Hardware Manager ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ To create an agent ramdisk with ``Proliant Hardware Manager``, use the ``proliant-tools`` element in DIB:: disk-image-create -o proliant-agent-ramdisk ironic-agent fedora proliant-tools Disk Erase Support ^^^^^^^^^^^^^^^^^^ ``erase_devices`` is an inband clean step supported by iLO drives. It performs erase on all the disks including the disks visible to OS as well as the raw disks visible to the Smart Storage Administrator (SSA). This inband clean step requires ``ssacli`` utility starting from version ``2.60-19.0`` to perform the erase on physical disks. See the `ssacli documentation`_ for more information on ssacli utility and different erase methods supported by SSA. The disk erasure via ``shred`` is used to erase disks visible to the OS and its implementation is available in Ironic Python Agent. The raw disks connected to the Smart Storage Controller are erased using Sanitize erase which is a ssacli supported erase method. If Sanitize erase is not supported on the Smart Storage Controller the disks are erased using One-pass erase (overwrite with zeros). This clean step is supported when the agent ramdisk contains the ``Proliant Hardware Manager`` from the proliantutils version 2.3.0 or higher. This clean step is performed as part of automated cleaning and it is disabled by default. See :ref:`InbandvsOutOfBandCleaning` for more information on enabling/disabling a clean step. To create an agent ramdisk with ``Proliant Hardware Manager``, use the ``proliant-tools`` element in DIB:: disk-image-create -o proliant-agent-ramdisk ironic-agent fedora proliant-tools See the `proliant-tools`_ for more information on creating agent ramdisk with ``proliant-tools`` element in DIB. Firmware based UEFI iSCSI boot from volume support ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ With Gen9 (UEFI firmware version 1.40 or higher) and Gen10 HPE Proliant servers, the driver supports firmware based UEFI boot of an iSCSI cinder volume. This feature requires the node to be configured to boot in ``UEFI`` boot mode, as well as user image should be ``UEFI`` bootable image, and ``PortFast`` needs to be enabled in switch configuration for immediate spanning tree forwarding state so it wouldn't take much time setting the iSCSI target as persistent device. The driver does not support this functionality when in ``bios`` boot mode. In case the node is configured with ``ilo-pxe`` boot interface and the boot mode configured on the bare metal is ``bios``, the iscsi boot from volume is performed using ``ipxe``. See :doc:`/admin/boot-from-volume` for more details. To use this feature, configure the boot mode of the bare metal to ``uefi`` and configure the corresponding ironic node using the steps given in :doc:`/admin/boot-from-volume`. In a cloud environment with nodes configured to boot from ``bios`` and ``uefi`` boot modes, the virtual media driver only supports uefi boot mode, and that attempting to use iscsi boot at the same time with a bios volume will result in an error. .. _`ssacli documentation`: http://h20566.www2.hpe.com/hpsc/doc/public/display?docId=c03909334 .. _`proliant-tools`: https://docs.openstack.org/diskimage-builder/latest/elements/proliant-tools/README.html .. _`HPE iLO4 User Guide`: http://h20566.www2.hpe.com/hpsc/doc/public/display?docId=c03334051 .. _`iLO 4 management engine`: https://www.hpe.com/us/en/servers/integrated-lights-out-ilo.html .. _`iLO 5 management engine`: https://www.hpe.com/us/en/servers/integrated-lights-out-ilo.html#innovations .. _`Redfish`: https://www.dmtf.org/standards/redfish .. _`Gen10 wiki section`: https://wiki.openstack.org/wiki/Ironic/Drivers/iLODrivers/master#Enabling_ProLiant_Gen10_systems_in_Ironic .. _`Guidelines for SPP ISO`: http://h17007.www1.hpe.com/us/en/enterprise/servers/products/service_pack/spp .. _`SUM`: http://h17007.www1.hpe.com/us/en/enterprise/servers/products/service_pack/hpsum/index.aspx .. _`SUM User Guide`: http://h20565.www2.hpe.com/hpsc/doc/public/display?docId=c05210448 ironic-10.1.1/doc/source/admin/notifications.rst0000666000175100017510000006333213243617463021663 0ustar zuulzuul00000000000000.. _deploy-notifications: ============= Notifications ============= Ironic, when configured to do so, will emit notifications over a message bus that indicate different events that occur within the service. These can be consumed by any external service. Examples may include a billing or usage system, a monitoring data store, or other OpenStack services. This page describes how to enable notifications and the different kinds of notifications that ironic may emit. The external consumer will see notifications emitted by ironic as JSON objects structured in the following manner:: { "priority": , "event_type": , "timestamp": , "publisher_id": , "message_id": , "payload": } Configuration ============= To enable notifications with ironic, there are two configuration options in ironic.conf that must be adjusted. The first option is the ``notification_level`` option in the ``[DEFAULT]`` section of the configuration file. This can be set to "debug", "info", "warning", "error", or "critical", and determines the minimum priority level for which notifications are emitted. For example, if the option is set to "warning", all notifications with priority level "warning", "error", or "critical" are emitted, but not notifications with priority level "debug" or "info". For information about the semantics of each log level, see the OpenStack logging standards [1]_. If this option is unset, no notifications will be emitted. The priority level of each available notification is documented below. The second option is the ``transport_url`` option in the ``[oslo_messaging_notifications]`` section of the configuration. This determines the message bus used when sending notifications. If this is unset, the default transport used for RPC is used. All notifications are emitted on the "ironic_versioned_notifications" topic in the message bus. Generally, each type of message that traverses the message bus is associated with a topic describing what the message is about. For more information, see the documentation of your chosen message bus, such as the RabbitMQ documentation [2]_. Note that notifications may be lossy, and there's no guarantee that a notification will make it across the message bus to a consumer. Versioning ========== Each notification has an associated version in the "ironic_object.version" field of the payload. Consumers are guaranteed that microversion bumps will add new fields, while macroversion bumps are backwards-incompatible and may have fields removed. Available notifications ======================= .. TODO(mariojv) Add some form of tabular formatting below The notifications that ironic emits are described here. They are listed (alphabetically) by service first, then by event_type. All examples below show payloads before serialization to JSON. ------------------------ ironic-api notifications ------------------------ Resources CRUD notifications ---------------------------- These notifications are emitted from API service when ironic resources are modified as part of create, update, or delete (CRUD) [3]_ procedures. All CRUD notifications are emitted at INFO level, except for "error" status that is emitted at ERROR level. List of CRUD notifications for chassis: * ``baremetal.chassis.create.start`` * ``baremetal.chassis.create.end`` * ``baremetal.chassis.create.error`` * ``baremetal.chassis.update.start`` * ``baremetal.chassis.update.end`` * ``baremetal.chassis.update.error`` * ``baremetal.chassis.delete.start`` * ``baremetal.chassis.delete.end`` * ``baremetal.chassis.delete.error`` Example of chassis CRUD notification:: { "priority": "info", "payload":{ "ironic_object.namespace":"ironic", "ironic_object.name":"ChassisCRUDPayload", "ironic_object.version":"1.0", "ironic_object.data":{ "created_at": "2016-04-10T10:13:03+00:00", "description": "bare 28", "extra": {}, "updated_at": "2016-04-27T21:11:03+00:00", "uuid": "1910f669-ce8b-43c2-b1d8-cf3d65be815e" } }, "event_type":"baremetal.chassis.update.end", "publisher_id":"ironic-api.hostname02" } List of CRUD notifications for node: * ``baremetal.node.create.start`` * ``baremetal.node.create.end`` * ``baremetal.node.create.error`` * ``baremetal.node.update.start`` * ``baremetal.node.update.end`` * ``baremetal.node.update.error`` * ``baremetal.node.delete.start`` * ``baremetal.node.delete.end`` * ``baremetal.node.delete.error`` Example of node CRUD notification:: { "priority": "info", "payload":{ "ironic_object.namespace":"ironic", "ironic_object.name":"NodeCRUDPayload", "ironic_object.version":"1.4", "ironic_object.data":{ "chassis_uuid": "db0eef9d-45b2-4dc0-94a8-fc283c01171f", "clean_step": None, "console_enabled": False, "created_at": "2016-01-26T20:41:03+00:00", "driver": "ipmi", "driver_info": { "ipmi_address": "192.168.0.111", "ipmi_username": "root"}, "extra": {}, "inspection_finished_at": None, "inspection_started_at": None, "instance_info": {}, "instance_uuid": None, "last_error": None, "maintenance": False, "maintenance_reason": None, "boot_interface": "pxe", "console_interface": "no-console", "deploy_interface": "iscsi", "inspect_interface": "no-inspect", "management_interface": "ipmitool", "network_interface": "flat", "power_interface": "ipmitool", "raid_interface": "no-raid", "rescue_interface": "no-rescue", "storage_interface": "noop", "vendor_interface": "no-vendor", "name": None, "power_state": "power off", "properties": { "memory_mb": 4096, "cpu_arch": "x86_64", "local_gb": 10, "cpus": 8}, "provision_state": "deploying", "provision_updated_at": "2016-01-27T20:41:03+00:00", "resource_class": None, "target_power_state": None, "target_provision_state": "active", "traits": [ "CUSTOM_TRAIT1", "HW_CPU_X86_VMX"], "updated_at": "2016-01-27T20:41:03+00:00", "uuid": "1be26c0b-03f2-4d2e-ae87-c02d7f33c123" } }, "event_type":"baremetal.node.update.end", "publisher_id":"ironic-api.hostname02" } List of CRUD notifications for port: * ``baremetal.port.create.start`` * ``baremetal.port.create.end`` * ``baremetal.port.create.error`` * ``baremetal.port.update.start`` * ``baremetal.port.update.end`` * ``baremetal.port.update.error`` * ``baremetal.port.delete.start`` * ``baremetal.port.delete.end`` * ``baremetal.port.delete.error`` Example of port CRUD notification:: { "priority": "info", "payload":{ "ironic_object.namespace":"ironic", "ironic_object.name":"PortCRUDPayload", "ironic_object.version":"1.2", "ironic_object.data":{ "address": "77:66:23:34:11:b7", "created_at": "2016-02-11T15:23:03+00:00", "node_uuid": "5b236cab-ad4e-4220-b57c-e827e858745a", "extra": {}, "local_link_connection": {}, "physical_network": "physnet1", "portgroup_uuid": "bd2f385e-c51c-4752-82d1-7a9ec2c25f24", "pxe_enabled": True, "updated_at": "2016-03-27T20:41:03+00:00", "uuid": "1be26c0b-03f2-4d2e-ae87-c02d7f33c123" } }, "event_type":"baremetal.port.update.end", "publisher_id":"ironic-api.hostname02" } List of CRUD notifications for port group: * ``baremetal.portgroup.create.start`` * ``baremetal.portgroup.create.end`` * ``baremetal.portgroup.create.error`` * ``baremetal.portgroup.update.start`` * ``baremetal.portgroup.update.end`` * ``baremetal.portgroup.update.error`` * ``baremetal.portgroup.delete.start`` * ``baremetal.portgroup.delete.end`` * ``baremetal.portgroup.delete.error`` Example of portgroup CRUD notification:: { "priority": "info", "payload":{ "ironic_object.namespace":"ironic", "ironic_object.name":"PortgroupCRUDPayload", "ironic_object.version":"1.0", "ironic_object.data":{ "address": "11:44:32:87:61:e5", "created_at": "2017-01-11T11:33:03+00:00", "node_uuid": "5b236cab-ad4e-4220-b57c-e827e858745a", "extra": {}, "mode": "7", "name": "portgroup-node-18", "properties": {}, "standalone_ports_supported": True, "updated_at": "2017-01-31T11:41:07+00:00", "uuid": "db033a40-bfed-4c84-815a-3db26bb268bb", } }, "event_type":"baremetal.portgroup.update.end", "publisher_id":"ironic-api.hostname02" } List of CRUD notifications for volume connector: * ``baremetal.volumeconnector.create.start`` * ``baremetal.volumeconnector.create.end`` * ``baremetal.volumeconnector.create.error`` * ``baremetal.volumeconnector.update.start`` * ``baremetal.volumeconnector.update.end`` * ``baremetal.volumeconnector.update.error`` * ``baremetal.volumeconnector.delete.start`` * ``baremetal.volumeconnector.delete.end`` * ``baremetal.volumeconnector.delete.error`` Example of volume connector CRUD notification:: { "priority": "info", "payload": { "ironic_object.namespace": "ironic", "ironic_object.name": "VolumeConnectorCRUDPayload", "ironic_object.version": "1.0", "ironic_object.data": { "connector_id": "iqn.2017-05.org.openstack:01:d9a51732c3f", "created_at": "2017-05-11T05:57:36+00:00", "extra": {}, "node_uuid": "4dbb4e69-99a8-4e13-b6e8-dd2ad4a20caf", "type": "iqn", "updated_at": "2017-05-11T08:28:58+00:00", "uuid": "19b9f3ab-4754-4725-a7a4-c43ea7e57360" } }, "event_type": "baremetal.volumeconnector.update.end", "publisher_id":"ironic-api.hostname02" } List of CRUD notifications for volume target: * ``baremetal.volumetarget.create.start`` * ``baremetal.volumetarget.create.end`` * ``baremetal.volumetarget.create.error`` * ``baremetal.volumetarget.update.start`` * ``baremetal.volumetarget.update.end`` * ``baremetal.volumetarget.update.error`` * ``baremetal.volumetarget.delete.start`` * ``baremetal.volumetarget.delete.end`` * ``baremetal.volumetarget.delete.error`` Example of volume target CRUD notification:: { "priority": "info", "payload": { "ironic_object.namespace": "ironic", "ironic_object.version": "1.0", "ironic_object.name": "VolumeTargetCRUDPayload" "ironic_object.data": { "boot_index": 0, "created_at": "2017-05-11T09:38:59+00:00", "extra": {}, "node_uuid": "4dbb4e69-99a8-4e13-b6e8-dd2ad4a20caf", "properties": { "access_mode": "rw", "auth_method": "CHAP" "auth_password": "***", "auth_username": "urxhQCzAKr4sjyE8DivY", "encrypted": false, "qos_specs": null, "target_discovered": false, "target_iqn": "iqn.2010-10.org.openstack:volume-f0d9b0e6-b242-9105-91d4-a20331693ad8", "target_lun": 1, "target_portal": "192.168.12.34:3260", "volume_id": "f0d9b0e6-b042-4105-91d4-a20331693ad8", }, "updated_at": "2017-05-11T09:52:04+00:00", "uuid": "82a45833-9c58-4ec1-943c-2091ab10e47b", "volume_id": "f0d9b0e6-b242-9105-91d4-a20331693ad8", "volume_type": "iscsi" } }, "event_type": "baremetal.volumetarget.update.end", "publisher_id":"ironic-api.hostname02" } Node maintenance notifications ------------------------------ These notifications are emitted from API service when maintenance mode is changed via API service. List of maintenance notifications for a node: * ``baremetal.node.maintenance_set.start`` * ``baremetal.node.maintenance_set.end`` * ``baremetal.node.maintenance_set.error`` "start" and "end" notifications have INFO level, "error" has ERROR. Example of node maintenance notification:: { "priority": "info", "payload":{ "ironic_object.namespace":"ironic", "ironic_object.name":"NodePayload", "ironic_object.version":"1.6", "ironic_object.data":{ "clean_step": None, "console_enabled": False, "created_at": "2016-01-26T20:41:03+00:00", "driver": "ipmi", "extra": {}, "inspection_finished_at": None, "inspection_started_at": None, "instance_info": {}, "instance_uuid": None, "last_error": None, "maintenance": True, "maintenance_reason": "hw upgrade", "boot_interface": "pxe", "console_interface": "no-console", "deploy_interface": "iscsi", "inspect_interface": "no-inspect", "management_interface": "ipmitool", "network_interface": "flat", "power_interface": "ipmitool", "raid_interface": "no-raid", "rescue_interface": "no-rescue", "storage_interface": "noop", "vendor_interface": "no-vendor", "name": None, "power_state": "power off", "properties": { "memory_mb": 4096, "cpu_arch": "x86_64", "local_gb": 10, "cpus": 8}, "provision_state": "available", "provision_updated_at": "2016-01-27T20:41:03+00:00", "resource_class": None, "target_power_state": None, "target_provision_state": None, "traits": [ "CUSTOM_TRAIT1", "HW_CPU_X86_VMX"], "updated_at": "2016-01-27T20:41:03+00:00", "uuid": "1be26c0b-03f2-4d2e-ae87-c02d7f33c123" } }, "event_type":"baremetal.node.maintenance_set.start", "publisher_id":"ironic-api.hostname02" } ------------------------------ ironic-conductor notifications ------------------------------ Node console notifications ------------------------------ These notifications are emitted by the ironic-conductor service when conductor service starts or stops console for the node. The notification event types for a node console are: * ``baremetal.node.console_set.start`` * ``baremetal.node.console_set.end`` * ``baremetal.node.console_set.error`` * ``baremetal.node.console_restore.start`` * ``baremetal.node.console_restore.end`` * ``baremetal.node.console_restore.error`` ``console_set`` action is used when start or stop console is initiated via API request. The ``console_restore`` action is used when the console was already enabled, but a driver must restart the console because an ironic-conductor was restarted. This may also be sent when an ironic-conductor takes over a node that was being managed by another ironic-conductor. "start" and "end" notifications have INFO level, "error" has ERROR. Example of node console notification:: { "priority": "info", "payload":{ "ironic_object.namespace":"ironic", "ironic_object.name":"NodePayload", "ironic_object.version":"1.6", "ironic_object.data":{ "clean_step": None, "console_enabled": True, "created_at": "2016-01-26T20:41:03+00:00", "driver": "ipmi", "extra": {}, "inspection_finished_at": None, "inspection_started_at": None, "instance_info": {}, "instance_uuid": None, "last_error": None, "maintenance": False, "maintenance_reason": None, "boot_interface": "pxe", "console_interface": "no-console", "deploy_interface": "iscsi", "inspect_interface": "no-inspect", "management_interface": "ipmitool", "network_interface": "flat", "power_interface": "ipmitool", "raid_interface": "no-raid", "rescue_interface": "no-rescue", "storage_interface": "noop", "vendor_interface": "no-vendor", "name": None, "power_state": "power off", "properties": { "memory_mb": 4096, "cpu_arch": "x86_64", "local_gb": 10, "cpus": 8}, "provision_state": "available", "provision_updated_at": "2016-01-27T20:41:03+00:00", "resource_class": None, "target_power_state": None, "target_provision_state": None, "traits": [ "CUSTOM_TRAIT1", "HW_CPU_X86_VMX"], "updated_at": "2016-01-27T20:41:03+00:00", "uuid": "1be26c0b-03f2-4d2e-ae87-c02d7f33c123" } }, "event_type":"baremetal.node.console_set.end", "publisher_id":"ironic-conductor.hostname01" } baremetal.node.power_set ------------------------ * ``baremetal.node.power_set.start`` is emitted by the ironic-conductor service when it begins a power state change. It has notification level "info". * ``baremetal.node.power_set.end`` is emitted when ironic-conductor successfully completes a power state change task. It has notification level "info". * ``baremetal.node.power_set.error`` is emitted by ironic-conductor when it fails to set a node's power state. It has notification level "error". This can occur when ironic fails to retrieve the old power state prior to setting the new one on the node, or when it fails to set the power state if a change is requested. Here is an example payload for a notification with this event type. The "to_power" payload field indicates the power state to which the ironic-conductor is attempting to change the node:: { "priority": "info", "payload":{ "ironic_object.namespace":"ironic", "ironic_object.name":"NodeSetPowerStatePayload", "ironic_object.version":"1.6", "ironic_object.data":{ "clean_step": None, "console_enabled": False, "created_at": "2016-01-26T20:41:03+00:00", "driver": "ipmi", "extra": {}, "inspection_finished_at": None, "inspection_started_at": None, "instance_uuid": "d6ea00c1-1f94-4e95-90b3-3462d7031678", "last_error": None, "maintenance": False, "maintenance_reason": None, "boot_interface": "pxe", "console_interface": "no-console", "deploy_interface": "iscsi", "inspect_interface": "no-inspect", "management_interface": "ipmitool", "network_interface": "flat", "power_interface": "ipmitool", "raid_interface": "no-raid", "rescue_interface": "no-rescue", "storage_interface": "noop", "vendor_interface": "no-vendor", "name": None, "power_state": "power off", "properties": { "memory_mb": 4096, "cpu_arch": "x86_64", "local_gb": 10, "cpus": 8}, "provision_state": "available", "provision_updated_at": "2016-01-27T20:41:03+00:00", "resource_class": None, "target_power_state": None, "target_provision_state": None, "traits": [ "CUSTOM_TRAIT1", "HW_CPU_X86_VMX"], "updated_at": "2016-01-27T20:41:03+00:00", "uuid": "1be26c0b-03f2-4d2e-ae87-c02d7f33c123", "to_power": "power on" } }, "event_type":"baremetal.node.power_set.start", "publisher_id":"ironic-conductor.hostname01" } baremetal.node.power_state_corrected ------------------------------------ * ``baremetal.node.power_state_corrected.success`` is emitted by ironic-conductor when the power state on the baremetal hardware is different from the previous known power state of the node and the database is corrected to reflect this new power state. It has notification level "info". Here is an example payload for a notification with this event_type. The "from_power" payload field indicates the previous power state on the node, prior to the correction:: { "priority": "info", "payload":{ "ironic_object.namespace":"ironic", "ironic_object.name":"NodeCorrectedPowerStatePayload", "ironic_object.version":"1.6", "ironic_object.data":{ "clean_step": None, "console_enabled": False, "created_at": "2016-01-26T20:41:03+00:00", "driver": "ipmi", "extra": {}, "inspection_finished_at": None, "inspection_started_at": None, "instance_uuid": "d6ea00c1-1f94-4e95-90b3-3462d7031678", "last_error": None, "maintenance": False, "maintenance_reason": None, "boot_interface": "pxe", "console_interface": "no-console", "deploy_interface": "iscsi", "inspect_interface": "no-inspect", "management_interface": "ipmitool", "network_interface": "flat", "power_interface": "ipmitool", "raid_interface": "no-raid", "rescue_interface": "no-rescue", "storage_interface": "noop", "vendor_interface": "no-vendor", "name": None, "power_state": "power off", "properties": { "memory_mb": 4096, "cpu_arch": "x86_64", "local_gb": 10, "cpus": 8}, "provision_state": "available", "provision_updated_at": "2016-01-27T20:41:03+00:00", "resource_class": None, "target_power_state": None, "target_provision_state": None, "traits": [ "CUSTOM_TRAIT1", "HW_CPU_X86_VMX"], "updated_at": "2016-01-27T20:41:03+00:00", "uuid": "1be26c0b-03f2-4d2e-ae87-c02d7f33c123", "from_power": "power on" } }, "event_type":"baremetal.node.power_state_corrected.success", "publisher_id":"ironic-conductor.cond-hostname02" } baremetal.node.provision_set ---------------------------- * ``baremetal.node.provision_set.start`` is emitted by the ironic-conductor service when it begins a provision state transition. It has notification level INFO. * ``baremetal.node.provision_set.end`` is emitted when ironic-conductor successfully completes a provision state transition. It has notification level INFO. * ``baremetal.node.provision_set.success`` is emitted when ironic-conductor successfully changes provision state instantly, without any intermediate work required (example is AVAILABLE to MANAGEABLE). It has notification level INFO. * ``baremetal.node.provision_set.error`` is emitted by ironic-conductor when it changes provision state as result of error event processing. It has notification level ERROR. Here is an example payload for a notification with this event type. The "previous_provision_state" and "previous_target_provision_state" payload fields indicate a node's provision states before state change, "event" is the FSM (finite state machine) event that triggered the state change:: { "priority": "info", "payload":{ "ironic_object.namespace":"ironic", "ironic_object.name":"NodeSetProvisionStatePayload", "ironic_object.version":"1.6", "ironic_object.data":{ "clean_step": None, "console_enabled": False, "created_at": "2016-01-26T20:41:03+00:00", "driver": "ipmi", "extra": {}, "inspection_finished_at": None, "inspection_started_at": None, "instance_info": {}, "instance_uuid": None, "last_error": None, "maintenance": False, "maintenance_reason": None, "boot_interface": "pxe", "console_interface": "no-console", "deploy_interface": "iscsi", "inspect_interface": "no-inspect", "management_interface": "ipmitool", "network_interface": "flat", "power_interface": "ipmitool", "raid_interface": "no-raid", "rescue_interface": "no-rescue", "storage_interface": "noop", "vendor_interface": "no-vendor", "name": None, "power_state": "power off", "properties": { "memory_mb": 4096, "cpu_arch": "x86_64", "local_gb": 10, "cpus": 8}, "provision_state": "deploying", "provision_updated_at": "2016-01-27T20:41:03+00:00", "resource_class": None, "target_power_state": None, "target_provision_state": "active", "traits": [ "CUSTOM_TRAIT1", "HW_CPU_X86_VMX"], "updated_at": "2016-01-27T20:41:03+00:00", "uuid": "1be26c0b-03f2-4d2e-ae87-c02d7f33c123", "previous_provision_state": "available", "previous_target_provision_state": None, "event": "deploy" } }, "event_type":"baremetal.node.provision_set.start", "publisher_id":"ironic-conductor.hostname01" } .. [1] https://wiki.openstack.org/wiki/LoggingStandards#Log_level_definitions .. [2] https://www.rabbitmq.com/documentation.html .. [3] https://en.wikipedia.org/wiki/Create,_read,_update_and_delete ironic-10.1.1/doc/source/admin/cleaning.rst0000666000175100017510000003044213243617463020566 0ustar zuulzuul00000000000000.. _cleaning: ============= Node cleaning ============= Overview ======== Ironic provides two modes for node cleaning: ``automated`` and ``manual``. ``Automated cleaning`` is automatically performed before the first workload has been assigned to a node and when hardware is recycled from one workload to another. ``Manual cleaning`` must be invoked by the operator. .. _automated_cleaning: Automated cleaning ================== When hardware is recycled from one workload to another, ironic performs automated cleaning on the node to ensure it's ready for another workload. This ensures the tenant will get a consistent bare metal node deployed every time. Ironic implements automated cleaning by collecting a list of cleaning steps to perform on a node from the Power, Deploy, Management, and RAID interfaces of the driver assigned to the node. These steps are then ordered by priority and executed on the node when the node is moved to ``cleaning`` state, if automated cleaning is enabled. With automated cleaning, nodes move to ``cleaning`` state when moving from ``active`` -> ``available`` state (when the hardware is recycled from one workload to another). Nodes also traverse cleaning when going from ``manageable`` -> ``available`` state (before the first workload is assigned to the nodes). For a full understanding of all state transitions into cleaning, please see :ref:`states`. Ironic added support for automated cleaning in the Kilo release. .. _enabling-cleaning: Enabling automated cleaning --------------------------- To enable automated cleaning, ensure that your ironic.conf is set as follows: .. code-block:: ini [conductor] automated_clean=true This will enable the default set of cleaning steps, based on your hardware and ironic hardware types used for nodes. This includes, by default, erasing all of the previous tenant's data. You may also need to configure a `Cleaning Network`_. Cleaning steps -------------- Cleaning steps used for automated cleaning are ordered from higher to lower priority, where a larger integer is a higher priority. In case of a conflict between priorities across interfaces, the following resolution order is used: Power, Management, Deploy, and RAID interfaces. You can skip a cleaning step by setting the priority for that cleaning step to zero or 'None'. You can reorder the cleaning steps by modifying the integer priorities of the cleaning steps. See `How do I change the priority of a cleaning step?`_ for more information. .. _manual_cleaning: Manual cleaning =============== ``Manual cleaning`` is typically used to handle long running, manual, or destructive tasks that an operator wishes to perform either before the first workload has been assigned to a node or between workloads. When initiating a manual clean, the operator specifies the cleaning steps to be performed. Manual cleaning can only be performed when a node is in the ``manageable`` state. Once the manual cleaning is finished, the node will be put in the ``manageable`` state again. Ironic added support for manual cleaning in the 4.4 (Mitaka series) release. Setup ----- In order for manual cleaning to work, you may need to configure a `Cleaning Network`_. Starting manual cleaning via API -------------------------------- Manual cleaning can only be performed when a node is in the ``manageable`` state. The REST API request to initiate it is available in API version 1.15 and higher:: PUT /v1/nodes//states/provision (Additional information is available `here `_.) This API will allow operators to put a node directly into ``cleaning`` provision state from ``manageable`` state via 'target': 'clean'. The PUT will also require the argument 'clean_steps' to be specified. This is an ordered list of cleaning steps. A cleaning step is represented by a dictionary (JSON), in the form:: { "interface": "", "step": "", "args": {"": "", ..., "": } } The 'interface' and 'step' keys are required for all steps. If a cleaning step method takes keyword arguments, the 'args' key may be specified. It is a dictionary of keyword variable arguments, with each keyword-argument entry being : . If any step is missing a required keyword argument, manual cleaning will not be performed and the node will be put in ``clean failed`` provision state with an appropriate error message. If, during the cleaning process, a cleaning step determines that it has incorrect keyword arguments, all earlier steps will be performed and then the node will be put in ``clean failed`` provision state with an appropriate error message. An example of the request body for this API:: { "target":"clean", "clean_steps": [{ "interface": "raid", "step": "create_configuration", "args": {"create_nonroot_volumes": false} }, { "interface": "deploy", "step": "erase_devices" }] } In the above example, the node's RAID interface would configure hardware RAID without non-root volumes, and then all devices would be erased (in that order). Starting manual cleaning via "openstack baremetal" CLI ------------------------------------------------------ Manual cleaning is available via the ``openstack baremetal node clean`` command, starting with Bare Metal API version 1.15. The argument ``--clean-steps`` must be specified. Its value is one of: - a JSON string - path to a JSON file whose contents are passed to the API - '-', to read from stdin. This allows piping in the clean steps. Using '-' to signify stdin is common in Unix utilities. The following examples assume that the Bare Metal API version was set via the ``OS_BAREMETAL_API_VERSION`` environment variable. (The alternative is to add ``--os-baremetal-api-version 1.15`` to the command.):: export OS_BAREMETAL_API_VERSION=1.15 Examples of doing this with a JSON string:: openstack baremetal node clean \ --clean-steps '[{"interface": "deploy", "step": "erase_devices_metadata"}]' openstack baremetal node clean \ --clean-steps '[{"interface": "deploy", "step": "erase_devices"}]' Or with a file:: openstack baremetal node clean \ --clean-steps my-clean-steps.txt Or with stdin:: cat my-clean-steps.txt | openstack baremetal node clean \ --clean-steps - Cleaning Network ================ If you are using the Neutron DHCP provider (the default) you will also need to ensure you have configured a cleaning network. This network will be used to boot the ramdisk for in-band cleaning. You can use the same network as your tenant network. For steps to set up the cleaning network, please see :ref:`configure-cleaning`. .. _InbandvsOutOfBandCleaning: In-band vs out-of-band ====================== Ironic uses two main methods to perform actions on a node: in-band and out-of-band. Ironic supports using both methods to clean a node. In-band ------- In-band steps are performed by ironic making API calls to a ramdisk running on the node using a deploy interface. Currently, all the deploy interfaces support in-band cleaning. By default, ironic-python-agent ships with a minimal cleaning configuration, only erasing disks. However, you can add your own cleaning steps and/or override default cleaning steps with a custom Hardware Manager. Out-of-band ----------- Out-of-band are actions performed by your management controller, such as IPMI, iLO, or DRAC. Out-of-band steps will be performed by ironic using a power or management interface. Which steps are performed depends on the hardware type and hardware itself. For Out-of-Band cleaning operations supported by iLO hardware types, refer to :ref:`ilo_node_cleaning`. FAQ === How are cleaning steps ordered? ------------------------------- For automated cleaning, cleaning steps are ordered by integer priority, where a larger integer is a higher priority. In case of a conflict between priorities across hardware interfaces, the following resolution order is used: #. Power interface #. Management interface #. Deploy interface #. RAID interface For manual cleaning, the cleaning steps should be specified in the desired order. How do I skip a cleaning step? ------------------------------ For automated cleaning, cleaning steps with a priority of 0 or None are skipped. How do I change the priority of a cleaning step? ------------------------------------------------ For manual cleaning, specify the cleaning steps in the desired order. For automated cleaning, it depends on whether the cleaning steps are out-of-band or in-band. Most out-of-band cleaning steps have an explicit configuration option for priority. Changing the priority of an in-band (ironic-python-agent) cleaning step requires use of a custom HardwareManager. The only exception is ``erase_devices``, which can have its priority set in ironic.conf. For instance, to disable erase_devices, you'd set the following configuration option:: [deploy] erase_devices_priority=0 To enable/disable the in-band disk erase using ``ilo`` hardware type, use the following configuration option:: [ilo] clean_priority_erase_devices=0 The generic hardware manager first tries to perform ATA disk erase by using ``hdparm`` utility. If ATA disk erase is not supported, it performs software based disk erase using ``shred`` utility. By default, the number of iterations performed by ``shred`` for software based disk erase is 1. To configure the number of iterations, use the following configuration option:: [deploy] erase_devices_iterations=1 What cleaning step is running? ------------------------------ To check what cleaning step the node is performing or attempted to perform and failed, run the following command; it will return the value in the node's ``driver_internal_info`` field:: openstack baremetal node show $node_ident -f value -c driver_internal_info The ``clean_steps`` field will contain a list of all remaining steps with their priorities, and the first one listed is the step currently in progress or that the node failed before going into ``clean failed`` state. Should I disable automated cleaning? ------------------------------------ Automated cleaning is recommended for ironic deployments, however, there are some tradeoffs to having it enabled. For instance, ironic cannot deploy a new instance to a node that is currently cleaning, and cleaning can be a time consuming process. To mitigate this, we suggest using disks with support for cryptographic ATA Security Erase, as typically the erase_devices step in the deploy interface takes the longest time to complete of all cleaning steps. Why can't I power on/off a node while it's cleaning? ---------------------------------------------------- During cleaning, nodes may be performing actions that shouldn't be interrupted, such as BIOS or Firmware updates. As a result, operators are forbidden from changing power state via the ironic API while a node is cleaning. Troubleshooting =============== If cleaning fails on a node, the node will be put into ``clean failed`` state and placed in maintenance mode, to prevent ironic from taking actions on the node. Nodes in ``clean failed`` will not be powered off, as the node might be in a state such that powering it off could damage the node or remove useful information about the nature of the cleaning failure. A ``clean failed`` node can be moved to ``manageable`` state, where it cannot be scheduled by nova and you can safely attempt to fix the node. To move a node from ``clean failed`` to ``manageable``:: openstack baremetal node manage $node_ident You can now take actions on the node, such as replacing a bad disk drive. Strategies for determining why a cleaning step failed include checking the ironic conductor logs, viewing logs on the still-running ironic-python-agent (if an in-band step failed), or performing general hardware troubleshooting on the node. When the node is repaired, you can move the node back to ``available`` state, to allow it to be scheduled by nova. :: # First, move it out of maintenance mode openstack baremetal node maintenance unset $node_ident # Now, make the node available for scheduling by nova openstack baremetal node provide $node_ident The node will begin automated cleaning from the start, and move to ``available`` state when complete. ironic-10.1.1/doc/source/admin/report.txt0000666000175100017510000004551113243617463020333 0ustar zuulzuul00000000000000/usr/local/lib/python2.7/dist-packages/pecan/__init__.py:122: RuntimeWarning: `static_root` is only used when `debug` is True, ignoring RuntimeWarning ======================================================================== ==== Guru Meditation ==== ======================================================================== |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| ======================================================================== ==== Package ==== ======================================================================== product = None vendor = None version = None ======================================================================== ==== Threads ==== ======================================================================== ------ Thread #140512155997952 ------ /usr/local/lib/python2.7/dist-packages/eventlet/hubs/hub.py:346 in run `self.wait(sleep_time)` /usr/local/lib/python2.7/dist-packages/eventlet/hubs/poll.py:82 in wait `sleep(seconds)` ======================================================================== ==== Green Threads ==== ======================================================================== ------ Green Thread ------ /usr/local/bin/ironic-api:10 in `sys.exit(main())` /opt/stack/ironic/ironic/cmd/api.py:48 in main `launcher.wait()` /usr/local/lib/python2.7/dist-packages/oslo_service/service.py:586 in wait `self._respawn_children()` /usr/local/lib/python2.7/dist-packages/oslo_service/service.py:570 in _respawn_children `eventlet.greenthread.sleep(self.wait_interval)` /usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py:34 in sleep `hub.switch()` /usr/local/lib/python2.7/dist-packages/eventlet/hubs/hub.py:294 in switch `return self.greenlet.switch()` ------ Green Thread ------ No Traceback! ======================================================================== ==== Processes ==== ======================================================================== Process 124840 (under 48114) [ run by: ubuntu (1000), state: running ] Process 124849 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124850 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124851 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124852 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124853 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124854 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124855 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124856 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124857 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124858 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124859 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124860 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124861 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124862 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124863 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124864 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124865 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124866 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124867 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124868 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124869 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124870 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124871 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124872 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124873 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124874 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124875 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124876 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124877 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124878 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124879 (under 124840) [ run by: ubuntu (1000), state: sleeping ] Process 124880 (under 124840) [ run by: ubuntu (1000), state: sleeping ] ======================================================================== ==== Configuration ==== ======================================================================== agent: agent_api_version = v1 deploy_logs_collect = always deploy_logs_local_path = /home/ubuntu/ironic-bm-logs/deploy_logs deploy_logs_storage_backend = local deploy_logs_swift_container = ironic_deploy_logs_container deploy_logs_swift_days_to_expire = 30 manage_agent_boot = True memory_consumed_by_agent = 0 post_deploy_get_power_state_retries = 6 post_deploy_get_power_state_retry_interval = 5 stream_raw_images = True api: api_workers = None enable_ssl_api = False host_ip = 0.0.0.0 max_limit = 1000 port = 6385 public_endpoint = None ramdisk_heartbeat_timeout = 30 restrict_lookup = True audit: audit_map_file = /etc/ironic/api_audit_map.conf enabled = False ignore_req_list = namespace = openstack audit_middleware_notifications: driver = None topics = None transport_url = *** cimc: action_interval = 10 max_retry = 6 cisco_ucs: action_interval = 5 max_retry = 6 conductor: api_url = http://10.223.197.220:6385 automated_clean = True check_provision_state_interval = 60 clean_callback_timeout = 1800 configdrive_swift_container = ironic_configdrive_container configdrive_use_swift = False deploy_callback_timeout = 1800 force_power_state_during_sync = True heartbeat_interval = 10 heartbeat_timeout = 60 inspect_timeout = 1800 node_locked_retry_attempts = 3 node_locked_retry_interval = 1 periodic_max_workers = 8 power_state_sync_max_retries = 3 send_sensor_data = False send_sensor_data_interval = 600 send_sensor_data_types = ALL sync_local_state_interval = 180 sync_power_state_interval = 60 workers_pool_size = 100 console: subprocess_checking_interval = 1 subprocess_timeout = 10 terminal = shellinaboxd terminal_cert_dir = None terminal_pid_dir = None cors: allow_credentials = True allow_headers = allow_methods = DELETE GET HEAD OPTIONS PATCH POST PUT TRACE allowed_origin = None expose_headers = max_age = 3600 cors.subdomain: allow_credentials = True allow_headers = allow_methods = DELETE GET HEAD OPTIONS PATCH POST PUT TRACE allowed_origin = None expose_headers = max_age = 3600 database: backend = sqlalchemy connection = *** connection_debug = 0 connection_trace = False db_inc_retry_interval = True db_max_retries = 20 db_max_retry_interval = 10 db_retry_interval = 1 idle_timeout = 3600 max_overflow = 50 max_pool_size = 5 max_retries = 10 min_pool_size = 1 mysql_engine = InnoDB mysql_sql_mode = TRADITIONAL pool_timeout = None retry_interval = 10 slave_connection = *** sqlite_synchronous = True use_db_reconnect = False default: api_paste_config = api-paste.ini auth_strategy = keystone bindir = /opt/stack/ironic/ironic/bin client_socket_timeout = 900 config-dir = config-file = /etc/ironic/ironic.conf control_exchange = ironic debug = True debug_tracebacks_in_api = False default_boot_interface = None default_console_interface = None default_deploy_interface = None default_inspect_interface = None default_log_levels = amqp=WARNING amqplib=WARNING eventlet.wsgi.server=INFO glanceclient=WARNING iso8601=WARNING keystoneauth.session=INFO keystonemiddleware.auth_token=INFO neutronclient=WARNING oslo_messaging=INFO paramiko=WARNING qpid.messaging=INFO requests=WARNING sqlalchemy=WARNING stevedore=INFO urllib3.connectionpool=WARNING default_management_interface = None default_network_interface = None default_portgroup_mode = active-backup default_power_interface = None default_raid_interface = None default_vendor_interface = None enabled_boot_interfaces = pxe enabled_console_interfaces = no-console enabled_deploy_interfaces = direct iscsi enabled_drivers = agent_ipmitool fake pxe_ipmitool enabled_hardware_types = ipmi redfish enabled_inspect_interfaces = no-inspect enabled_management_interfaces = ipmitool redfish enabled_network_interfaces = flat noop enabled_power_interfaces = ipmitool redfish enabled_raid_interfaces = agent no-raid enabled_vendor_interfaces = no-vendor fatal_exception_format_errors = False force_raw_images = True graceful_shutdown_timeout = 60 grub_config_template = /opt/stack/ironic/ironic/common/grub_conf.template hash_distribution_replicas = 1 hash_partition_exponent = 5 hash_ring_reset_interval = 180 host = ubuntu instance_format = [instance: %(uuid)s] instance_uuid_format = [instance: %(uuid)s] isolinux_bin = /usr/lib/syslinux/isolinux.bin isolinux_config_template = /opt/stack/ironic/ironic/common/isolinux_config.template log-config-append = None log-date-format = %Y-%m-%d %H:%M:%S log-dir = None log-file = None log_options = True logging_context_format_string = %(asctime)s.%(msecs)03d %(color)s%(levelname)s %(name)s [%(request_id)s %(project_name)s %(user_name)s%(color)s] %(instance)s%(color)s%(message)s logging_debug_format_suffix = from (pid=%(process)d) %(funcName)s %(pathname)s:%(lineno)d logging_default_format_string = %(asctime)s.%(msecs)03d %(color)s%(levelname)s %(name)s [-%(color)s] %(instance)s%(color)s%(message)s logging_exception_prefix = %(color)s%(asctime)s.%(msecs)03d TRACE %(name)s %(instance)s logging_user_identity_format = %(user)s %(tenant)s %(domain)s %(user_domain)s %(project_domain)s max_header_line = 16384 my_ip = 10.223.197.220 notification_level = None parallel_image_downloads = False pecan_debug = False publish_errors = False pybasedir = /opt/stack/ironic/ironic rate_limit_burst = 0 rate_limit_except_level = CRITICAL rate_limit_interval = 0 rootwrap_config = /etc/ironic/rootwrap.conf rpc_backend = rabbit rpc_response_timeout = 60 state_path = /var/lib/ironic syslog-log-facility = LOG_USER tcp_keepidle = 600 tempdir = /tmp transport_url = *** use-journal = False use-syslog = False use_stderr = False watch-log-file = False wsgi_default_pool_size = 100 wsgi_keep_alive = True wsgi_log_format = %(client_ip)s "%(request_line)s" status: %(status_code)s len: %(body_length)s time: %(wall_seconds).7f deploy: continue_if_disk_secure_erase_fails = False default_boot_option = netboot erase_devices_metadata_priority = None erase_devices_priority = 0 http_root = /opt/stack/data/ironic/httpboot http_url = http://10.223.197.220:3928 power_off_after_deploy_failure = True shred_final_overwrite_with_zeros = True shred_random_overwrite_iterations = 1 dhcp: dhcp_provider = neutron disk_partitioner: check_device_interval = 1 check_device_max_retries = 20 disk_utils: bios_boot_partition_size = 1 dd_block_size = 1M efi_system_partition_size = 200 iscsi_verify_attempts = 3 drac: query_raid_config_job_status_interval = 120 glance: allowed_direct_url_schemes = auth_section = None auth_strategy = keystone auth_type = password cafile = /opt/stack/data/ca-bundle.pem certfile = None glance_api_insecure = False glance_api_servers = None glance_cafile = None glance_num_retries = 0 insecure = False keyfile = None swift_account = AUTH_cb13c4492d124b01b4659a97d627955c swift_api_version = v1 swift_container = glance swift_endpoint_url = http://10.223.197.220:8080 swift_store_multiple_containers_seed = 0 swift_temp_url_cache_enabled = False swift_temp_url_duration = 3600 swift_temp_url_expected_download_start_delay = 0 swift_temp_url_key = *** temp_url_endpoint_type = swift timeout = None ilo: ca_file = None clean_priority_clear_secure_boot_keys = 0 clean_priority_erase_devices = None clean_priority_reset_bios_to_default = 10 clean_priority_reset_ilo = 0 clean_priority_reset_ilo_credential = 30 clean_priority_reset_secure_boot_keys_to_default = 20 client_port = 443 client_timeout = 60 default_boot_mode = auto power_retry = 6 power_wait = 2 swift_ilo_container = ironic_ilo_container swift_object_expiry_timeout = 900 use_web_server_for_images = False inspector: auth_section = None auth_type = password cafile = /opt/stack/data/ca-bundle.pem certfile = None enabled = False insecure = False keyfile = None service_url = None status_check_period = 60 timeout = None ipmi: min_command_interval = 5 retry_timeout = 60 irmc: auth_method = basic client_timeout = 60 port = 443 remote_image_server = None remote_image_share_name = share remote_image_share_root = /remote_image_share_root remote_image_share_type = CIFS remote_image_user_domain = remote_image_user_name = None remote_image_user_password = *** sensor_method = ipmitool snmp_community = public snmp_port = 161 snmp_security = None snmp_version = v2c ironic_lib: fatal_exception_format_errors = False root_helper = sudo ironic-rootwrap /etc/ironic/rootwrap.conf iscsi: portal_port = 3260 keystone: region_name = RegionOne keystone_authtoken: admin_password = *** admin_tenant_name = admin admin_token = *** admin_user = None auth-url = http://10.223.197.220/identity_admin auth_admin_prefix = auth_host = 127.0.0.1 auth_port = 35357 auth_protocol = https auth_section = None auth_type = password auth_uri = http://10.223.197.220/identity auth_version = None cache = None cafile = /opt/stack/data/ca-bundle.pem certfile = None check_revocations_for_cached = False default-domain-id = None default-domain-name = None delay_auth_decision = False domain-id = None domain-name = None enforce_token_bind = permissive hash_algorithms = md5 http_connect_timeout = None http_request_max_retries = 3 identity_uri = None include_service_catalog = True insecure = False keyfile = None memcache_pool_conn_get_timeout = 10 memcache_pool_dead_retry = 300 memcache_pool_maxsize = 10 memcache_pool_socket_timeout = 3 memcache_pool_unused_timeout = 60 memcache_secret_key = *** memcache_security_strategy = None memcache_use_advanced_pool = False memcached_servers = 10.223.197.220:11211 password = *** project-domain-id = None project-domain-name = Default project-id = None project-name = service region_name = None revocation_cache_time = 10 service_token_roles = service service_token_roles_required = False signing_dir = /var/cache/ironic/api token_cache_time = 300 trust-id = None user-domain-id = None user-domain-name = Default user-id = None username = ironic metrics: agent_backend = noop agent_global_prefix = None agent_prepend_host = False agent_prepend_host_reverse = True agent_prepend_uuid = False backend = noop global_prefix = None prepend_host = False prepend_host_reverse = True metrics_statsd: agent_statsd_host = localhost agent_statsd_port = 8125 statsd_host = localhost statsd_port = 8125 neutron: auth_section = None auth_strategy = keystone auth_type = password cafile = /opt/stack/data/ca-bundle.pem certfile = None cleaning_network = private cleaning_network_security_groups = insecure = False keyfile = None port_setup_delay = 15 provisioning_network = None provisioning_network_security_groups = retries = 3 timeout = None url = None url_timeout = 30 oneview: allow_insecure_connections = False enable_periodic_tasks = True manager_url = None max_polling_attempts = 12 password = *** periodic_check_interval = 300 tls_cacert_file = None username = None oslo_concurrency: disable_process_locking = False lock_path = None oslo_messaging_notifications: driver = topics = notifications transport_url = *** oslo_messaging_rabbit: amqp_auto_delete = False amqp_durable_queues = False conn_pool_min_size = 2 conn_pool_ttl = 1200 fake_rabbit = False heartbeat_rate = 2 heartbeat_timeout_threshold = 60 kombu_compression = None kombu_failover_strategy = round-robin kombu_missing_consumer_retry_timeout = 60 kombu_reconnect_delay = 1.0 rabbit_ha_queues = False rabbit_host = localhost rabbit_hosts = localhost:5672 rabbit_interval_max = 30 rabbit_login_method = AMQPLAIN rabbit_max_retries = 0 rabbit_password = *** rabbit_port = 5672 rabbit_qos_prefetch_count = 0 rabbit_retry_backoff = 2 rabbit_retry_interval = 1 rabbit_transient_queues_ttl = 1800 rabbit_userid = guest rabbit_virtual_host = / rpc_conn_pool_size = 30 ssl = False ssl_ca_file = ssl_cert_file = ssl_key_file = ssl_version = oslo_versionedobjects: fatal_exception_format_errors = False pxe: default_ephemeral_format = ext4 image_cache_size = 20480 image_cache_ttl = 10080 images_path = /var/lib/ironic/images/ instance_master_path = /var/lib/ironic/master_images ip_version = 4 ipxe_boot_script = /opt/stack/ironic/ironic/drivers/modules/boot.ipxe ipxe_enabled = True ipxe_timeout = 0 ipxe_use_swift = False pxe_append_params = nofb nomodeset vga=normal console=ttyS0 systemd.journald.forward_to_console=yes pxe_bootfile_name = undionly.kpxe pxe_bootfile_name_by_arch: pxe_config_template = /opt/stack/ironic/ironic/drivers/modules/ipxe_config.template pxe_config_template_by_arch: tftp_master_path = /opt/stack/data/ironic/tftpboot/master_images tftp_root = /opt/stack/data/ironic/tftpboot tftp_server = 10.223.197.220 uefi_pxe_bootfile_name = ipxe.efi uefi_pxe_config_template = /opt/stack/ironic/ironic/drivers/modules/ipxe_config.template seamicro: action_timeout = 10 max_retry = 3 service_catalog: auth_section = None auth_type = password cafile = /opt/stack/data/ca-bundle.pem certfile = None insecure = False keyfile = None timeout = None snmp: power_timeout = 10 reboot_delay = 0 swift: auth_section = None auth_type = password cafile = /opt/stack/data/ca-bundle.pem certfile = None insecure = False keyfile = None swift_max_retries = 2 timeout = None virtualbox: port = 18083 ironic-10.1.1/doc/source/admin/api-audit-support.rst0000666000175100017510000000724213243617463022377 0ustar zuulzuul00000000000000.. _api-audit-support: ================= API Audit Logging ================= Audit middleware supports delivery of CADF audit events via Oslo messaging notifier capability. Based on `notification_driver` configuration, audit events can be routed to messaging infrastructure (notification_driver = messagingv2) or can be routed to a log file (`[oslo_messaging_notifications]/driver = log`). Audit middleware creates two events per REST API interaction. First event has information extracted from request data and the second one has request outcome (response). Enabling API Audit Logging ========================== Audit middleware is available as part of `keystonemiddleware` (>= 1.6) library. For information regarding how audit middleware functions refer `here. `_ Auditing can be enabled for the Bare Metal service by making the following changes to ``/etc/ironic/ironic.conf``. #. To enable audit logging of API requests:: [audit] ... enabled=true #. To customize auditing API requests, the audit middleware requires the audit_map_file setting to be defined. Update the value of configuration setting 'audit_map_file' to set its location. Audit map file configuration options for the Bare Metal service are included in the etc/ironic/ironic_api_audit_map.conf.sample file. To understand CADF format specified in ironic_api_audit_map.conf file refer to `CADF Format. `_:: [audit] ... audit_map_file=/etc/ironic/api_audit_map.conf #. Comma separated list of Ironic REST API HTTP methods to be ignored during audit. It is used only when API audit is enabled. For example:: [audit] ... ignore_req_list=GET,POST Sample Audit Event ================== Following is the sample of audit event for ironic node list request. .. code-block:: json { "event_type":"audit.http.request", "timestamp":"2016-06-15 06:04:30.904397", "payload":{ "typeURI":"http://schemas.dmtf.org/cloud/audit/1.0/event", "eventTime":"2016-06-15T06:04:30.903071+0000", "target":{ "id":"ironic", "typeURI":"unknown", "addresses":[ { "url":"http://{ironic_admin_host}:6385", "name":"admin" }, { "url":"http://{ironic_internal_host}:6385", "name":"private" }, { "url":"http://{ironic_public_host}:6385", "name":"public" } ], "name":"ironic" }, "observer":{ "id":"target" }, "tags":[ "correlation_id?value=685f1abb-620e-5d5d-b74a-b4135fb32373" ], "eventType":"activity", "initiator":{ "typeURI":"service/security/account/user", "name":"admin", "credential":{ "token":"***", "identity_status":"Confirmed" }, "host":{ "agent":"python-ironicclient", "address":"10.1.200.129" }, "project_id":"d8f52dd7d9e1475dbbf3ba47a4a83313", "id":"8c1a948bad3948929aa5d5b50627a174" }, "action":"read", "outcome":"pending", "id":"061b7aa7-5879-5225-a331-c002cf23cb6c", "requestPath":"/v1/nodes/?associated=True" }, "priority":"INFO", "publisher_id":"ironic-api", "message_id":"2f61ebaa-2d3e-4023-afba-f9fca6f21fc2" } ironic-10.1.1/doc/source/admin/security.rst0000666000175100017510000001244413243617463020657 0ustar zuulzuul00000000000000.. _security: ================= Security Overview ================= While the Bare Metal service is intended to be a secure application, it is important to understand what it does and does not cover today. Deployers must properly evaluate their use case and take the appropriate actions to secure their environment(s). This document is intended to provide an overview of what risks an operator of the Bare Metal service should be aware of. It is not intended as a How-To guide for securing a data center or an OpenStack deployment. .. TODO: add "Security Considerations for Network Boot" section .. TODO: add "Credential Storage and Management" section .. TODO: add "Multi-tenancy Considerations" section REST API: user roles and policy settings ======================================== Beginning with the Newton (6.1.0) release, the Bare Metal service allows operators significant control over API access: * Access may be restricted to each method (GET, PUT, etc) for each REST resource. Defaults are provided with the release and defined in code. * Access may be divided between an "administrative" role with full access and "observer" role with read-only access. By default, these roles are assigned the names ``baremetal_admin`` and ``baremetal_observer``, respectively. * As before, passwords may be hidden in ``driver_info``. Prior to the Newton (6.1.0) release, the Bare Metal service only supported two policy options: * API access may be secured by a simple policy rule: users with administrative privileges may access all API resources, whereas users without administrative privileges may only access public API resources. * Passwords contained in the ``driver_info`` field may be hidden from all API responses with the ``show_password`` policy setting. This defaults to always hide passwords, regardless of the user's role. Multi-tenancy ============= There are two aspects of multitenancy to consider when evaluating a deployment of the Bare Metal Service: interactions between tenants on the network, and actions one tenant can take on a machine that will affect the next tenant. Network Interactions -------------------- Interactions between tenants' workloads running simultaneously on separate servers include, but are not limited to: IP spoofing, packet sniffing, and network man-in-the-middle attacks. By default, the Bare Metal service provisions all nodes on a "flat" network, and does not take any precautions to avoid or prevent interaction between tenants. This can be addressed by integration with the OpenStack Identity, Compute, and Networking services, so as to provide tenant-network isolation. Additional documentation on `network multi-tenancy `_ is available. Lingering Effects ----------------- Interactions between tenants placed sequentially on the same server include, but are not limited to: changes in BIOS settings, modifications to firmware, or files left on disk or peripheral storage devices (if these devices are not erased between uses). By default, the Bare Metal service will erase (clean) the local disk drives during the "cleaning" phase, after deleting an instance. It *does not* reset BIOS or reflash firmware or peripheral devices. This can be addressed through customizing the utility ramdisk used during the "cleaning" phase. See details in the `Firmware security`_ section. Firmware security ================= When the Bare Metal service deploys an operating system image to a server, that image is run natively on the server without virtualization. Any user with administrative access to the deployed instance has administrative access to the underlying hardware. Most servers' default settings do not prevent a privileged local user from gaining direct access to hardware devices. Such a user could modify device or firmware settings, and potentially flash new firmware to the device, before deleting their instance and allowing the server to be allocated to another user. If the ``[conductor]/automated_clean`` configuration option is enabled (and the ``[deploy]/erase_devices_priority`` configuration option is not zero), the Bare Metal service will securely erase all local disk devices within a machine during instance deletion. However, the service does not ship with any code that will validate the integrity of, or make any modifications to, system or device firmware or firmware settings. Operators are encouraged to write their own hardware manager plugins for the ``ironic-python-agent`` ramdisk. This should include custom ``clean steps`` that would be run during the :ref:`cleaning` process, as part of Node de-provisioning. The ``clean steps`` would perform the specific actions necessary within that environment to ensure the integrity of each server's firmware. Ideally, an operator would work with their hardware vendor to ensure that proper firmware security measures are put in place ahead of time. This could include: - installing signed firmware for BIOS and peripheral devices - using a TPM (Trusted Platform Module) to validate signatures at boot time - booting machines in :ref:`iLO UEFI Secure Boot Support`, rather than BIOS mode, to validate kernel signatures - disabling local (in-band) access from the host OS to the management controller (BMC) - disabling modifications to boot settings from the host OS Additional references: - :ref:`cleaning` - :ref:`trusted-boot` ironic-10.1.1/doc/source/admin/console.rst0000666000175100017510000001763213243617463020456 0ustar zuulzuul00000000000000.. _console: ================================= Configuring Web or Serial Console ================================= Overview -------- There are two types of console which are available in Bare Metal service, one is web console (`Node web console`_) which is available directly from web browser, another is serial console (`Node serial console`_). Node web console ---------------- The web console can be configured in Bare Metal service in the following way: * Install shellinabox in ironic conductor node. For RHEL/CentOS, shellinabox package is not present in base repositories, user must enable EPEL repository, you can find more from `FedoraProject page`_. Installation example:: Ubuntu: sudo apt-get install shellinabox Fedora 21/RHEL7/CentOS7: sudo yum install shellinabox Fedora 22 or higher: sudo dnf install shellinabox You can find more about shellinabox on the `shellinabox page`_. You can optionally use the SSL certificate in shellinabox. If you want to use the SSL certificate in shellinabox, you should install openssl and generate the SSL certificate. 1. Install openssl, for example:: Ubuntu: sudo apt-get install openssl Fedora 21/RHEL7/CentOS7: sudo yum install openssl Fedora 22 or higher: sudo dnf install openssl 2. Generate the SSL certificate, here is an example, you can find more about openssl on the `openssl page`_:: cd /tmp/ca openssl genrsa -des3 -out my.key 1024 openssl req -new -key my.key -out my.csr cp my.key my.key.org openssl rsa -in my.key.org -out my.key openssl x509 -req -days 3650 -in my.csr -signkey my.key -out my.crt cat my.crt my.key > certificate.pem * Customize the console section in the Bare Metal service configuration file (/etc/ironic/ironic.conf), if you want to use SSL certificate in shellinabox, you should specify ``terminal_cert_dir``. for example:: [console] # # Options defined in ironic.drivers.modules.console_utils # # Path to serial console terminal program. Used only by Shell # In A Box console. (string value) #terminal=shellinaboxd # Directory containing the terminal SSL cert (PEM) for serial # console access. Used only by Shell In A Box console. (string # value) terminal_cert_dir=/tmp/ca # Directory for holding terminal pid files. If not specified, # the temporary directory will be used. (string value) #terminal_pid_dir= # Time interval (in seconds) for checking the status of # console subprocess. (integer value) #subprocess_checking_interval=1 # Time (in seconds) to wait for the console subprocess to # start. (integer value) #subprocess_timeout=10 * Append console parameters for bare metal PXE boot in the Bare Metal service configuration file (/etc/ironic/ironic.conf). See the reference for configuration in :ref:`kernel-boot-parameters`. * Enable the ``ipmitool-shellinabox`` console interface, for example: .. code-block:: ini [DEFAULT] enabled_console_interfaces = ipmitool-shellinabox,no-console * Configure node web console. If the node uses a hardware type, for example ``ipmi``, set the node's console interface to ``ipmitool-shellinabox``:: openstack --os-baremetal-api-version 1.31 baremetal node set \ --console-interface ipmitool-shellinabox Enable the web console, for example:: openstack baremetal node set \ --driver-info = openstack baremetal node console enable Check whether the console is enabled, for example:: openstack baremetal node validate Disable the web console, for example:: openstack baremetal node console disable openstack baremetal node unset --driver-info The ```` is driver dependent. The actual name of this field can be checked in driver properties, for example:: openstack baremetal driver property list For the ``ipmi`` hardware type, this option is ``ipmi_terminal_port``. Give a customized port number to ````, for example ``8023``, this customized port is used in web console url. Get web console information for a node as follows:: openstack baremetal node console show +-----------------+----------------------------------------------------------------------+ | Property | Value | +-----------------+----------------------------------------------------------------------+ | console_enabled | True | | console_info | {u'url': u'http://:', u'type': u'shellinabox'} | +-----------------+----------------------------------------------------------------------+ You can open web console using above ``url`` through web browser. If ``console_enabled`` is ``false``, ``console_info`` is ``None``, web console is disabled. If you want to launch web console, see the ``Configure node web console`` part. .. _`shellinabox page`: https://code.google.com/p/shellinabox/ .. _`openssl page`: https://www.openssl.org/ .. _`FedoraProject page`: https://fedoraproject.org/wiki/Infrastructure/Mirroring Node serial console ------------------- Serial consoles for nodes are implemented using `socat`_. It is supported by the ``ipmi`` and ``irmc`` hardware types. Serial consoles can be configured in the Bare Metal service as follows: * Install socat on the ironic conductor node. Also, ``socat`` needs to be in the $PATH environment variable that the ironic-conductor service uses. Installation example:: Ubuntu: sudo apt-get install socat Fedora 21/RHEL7/CentOS7: sudo yum install socat Fedora 22 or higher: sudo dnf install socat * Append console parameters for bare metal PXE boot in the Bare Metal service configuration file. See the reference on how to configure them in :ref:`kernel-boot-parameters`. * Enable the ``ipmitool-socat`` console interface, for example: .. code-block:: ini [DEFAULT] enabled_console_interfaces = ipmitool-socat,no-console * Configure node console. If the node uses a hardware type, for example ``ipmi``, set the node's console interface to ``ipmitool-socat``:: openstack --os-baremetal-api-version 1.31 baremetal node set \ --console-interface ipmitool-socat Enable the serial console, for example:: openstack baremetal node set --driver-info ipmi_terminal_port= openstack baremetal node console enable Check whether the serial console is enabled, for example:: openstack baremetal node validate Disable the serial console, for example:: openstack baremetal node console disable openstack baremetal node unset --driver-info Serial console information is available from the Bare Metal service. Get serial console information for a node from the Bare Metal service as follows:: openstack baremetal node console show +-----------------+----------------------------------------------------------------------+ | Property | Value | +-----------------+----------------------------------------------------------------------+ | console_enabled | True | | console_info | {u'url': u'tcp://:', u'type': u'socat'} | +-----------------+----------------------------------------------------------------------+ If ``console_enabled`` is ``false`` or ``console_info`` is ``None`` then the serial console is disabled. If you want to launch serial console, see the ``Configure node console``. .. _`socat`: http://www.dest-unreach.org/socat ironic-10.1.1/doc/source/admin/multitenancy.rst0000666000175100017510000002023713243617463021523 0ustar zuulzuul00000000000000.. _multitenancy: ======================================= Multi-tenancy in the Bare Metal service ======================================= Overview ======== It is possible to use dedicated tenant networks for provisioned nodes, which extends the current Bare Metal service capabilities of providing flat networks. This works in conjunction with the Networking service to allow provisioning of nodes in a separate provisioning network. The result of this is that multiple tenants can use nodes in an isolated fashion. However, this configuration does not support trunk ports belonging to multiple networks. Concepts ======== Network interfaces ------------------ Network interface is one of the driver interfaces that manages network switching for nodes. There are 3 network interfaces available in the Bare Metal service: - ``noop`` interface is used for standalone deployments, and does not perform any network switching; - ``flat`` interface places all nodes into a single provider network that is pre-configured on the Networking service and physical equipment. Nodes remain physically connected to this network during their entire life cycle. - ``neutron`` interface provides tenant-defined networking through the Networking service, separating tenant networks from each other and from the provisioning and cleaning provider networks. Nodes will move between these networks during their life cycle. This interface requires Networking service support for the switches attached to the baremetal servers so they can be programmed. Local link connection --------------------- The Bare Metal service allows ``local_link_connection`` information to be associated with Bare Metal ports. This information is provided to the Networking service's ML2 driver when a Virtual Interface (VIF) is attached. The ML2 driver uses the information to plug the specified port to the tenant network. .. list-table:: ``local_link_connection`` fields :header-rows: 1 * - Field - Description * - ``switch_id`` - Required. Identifies a switch and can be a MAC address or an OpenFlow-based ``datapath_id``. * - ``port_id`` - Required. Port ID on the switch, for example, Gig0/1. * - ``switch_info`` - Optional. Used to distinguish different switch models or other vendor-specific identifier. Some ML2 plugins may require this field. .. _multitenancy-physnets: Physical networks ----------------- A Bare Metal port may be associated with a physical network using its ``physical_network`` field. The Bare Metal service uses this information when mapping between virtual ports in the Networking service and physical ports and port groups in the Bare Metal service. A port's physical network field is optional, and if not set then any virtual port may be mapped to that port, provided that no free Bare Metal port with a suitable physical network assignment exists. The physical network of a port group is defined by the physical network of its constituent ports. The Bare Metal service ensures that all ports in a port group have the same value in their physical network field. When attaching a virtual interface (VIF) to a node, the following ordered criteria are used to select a suitable unattached port or port group: * Require ports or port groups to not have a physical network or to have a physical network that matches one of the VIF's allowed physical networks. * Prefer ports and port groups that have a physical network to ports and port groups that do not have a physical network. * Prefer port groups to ports. Prefer ports with PXE enabled. Configuring the Bare Metal service ================================== See the :ref:`configure-tenant-networks` section in the installation guide for the Bare Metal service. Configuring nodes ================= #. Ensure that your python-ironicclient version and requested API version are sufficient for your requirements. * Multi-tenancy support was added in API version 1.20, and is supported by python-ironicclient version 1.5.0 or higher. * Physical network support for ironic ports was added in API version 1.34, and is supported by python-ironicclient version 1.15.0 or higher. The following examples assume you are using python-ironicclient version 1.15.0 or higher. Export the following variable:: export OS_BAREMETAL_API_VERSION= #. The node's ``network_interface`` field should be set to a valid network interface. Valid interfaces are listed in the ``[DEFAULT]/enabled_network_interfaces`` configuration option in the ironic-conductor's configuration file. Set it to ``neutron`` to use the Networking service's ML2 driver:: openstack baremetal node create --network-interface neutron --driver ipmi .. note:: If the ``[DEFAULT]/default_network_interface`` configuration option is set, the ``--network-interface`` option does not need to be specified when creating the node. #. To update an existing node's network interface to ``neutron``, use the following commands:: openstack baremetal node set $NODE_UUID_OR_NAME \ --network-interface neutron #. Create a port as follows:: openstack baremetal port create $HW_MAC_ADDRESS --node $NODE_UUID \ --local-link-connection switch_id=$SWITCH_MAC_ADDRESS \ --local-link-connection switch_info=$SWITCH_HOSTNAME \ --local-link-connection port_id=$SWITCH_PORT \ --pxe-enabled true \ --physical-network physnet1 #. Check the port configuration:: openstack baremetal port show $PORT_UUID After these steps, the provisioning of the created node will happen in the provisioning network, and then the node will be moved to the tenant network that was requested. Configuring the Networking service ================================== In addition to configuring the Bare Metal service some additional configuration of the Networking service is required to ensure ports for bare metal servers are correctly programmed. This configuration will be determined by the Bare Metal service network interfaces you have enabled and which top of rack switches you have in your environment. ``flat`` network interface -------------------------- In order for Networking service ports to correctly operate with the Bare Metal service ``flat`` network interface the ``baremetal`` ML2 mechanism driver from `networking-baremetal `_ needs to be loaded into the Networking service configuration. This driver understands that the switch should be already configured by the admin, and will mark the networking service ports as successfully bound as nothing else needs to be done. #. Install the ``networking-baremetal`` library .. code-block:: console $ pip install networking-baremetal #. Enable the ``baremetal`` driver in the Networking service ML2 configuration file .. code-block:: ini [ml2] mechanism_drivers = ovs,baremetal ``neutron`` network interface ----------------------------- The ``neutron`` network interface allows the Networking service to program the physical top of rack switches for the bare metal servers. To do this an ML2 mechanism driver which supports the ``baremetal`` VNIC type for the make and model of top of rack switch in the environment must be installed and enabled. This is a list of known top of rack ML2 mechanism drivers which work with the ``neutron`` network interface: Cisco Nexus 9000 series To install and configure this ML2 mechanism driver see `Nexus Mechanism Driver Installation Guide `_. FUJITSU CFX2000 ``networking-fujitsu`` ML2 driver supports this switch. The documentation is available `here `_. Networking Generic Switch This is an ML2 mechanism driver built for testing against virtual bare metal environments and some switches that are not covered by hardware specific ML2 mechanism drivers. More information is available in the project's `README `_. ironic-10.1.1/doc/source/admin/gmr.rst0000666000175100017510000000366013243617463017575 0ustar zuulzuul00000000000000Bare Metal Service state report (via Guru Meditation Reports) ============================================================= The Bare Metal service contains a mechanism whereby developers and system administrators can generate a report about the state of running Bare Metal executables (ironic-api and ironic-conductor). This report is called a Guru Meditation Report (GMR for short). GMR provides useful debugging information that can be used to obtain an accurate view on the current live state of the system. For example, what threads are running, what configuration parameters are in effect, and more. The eventlet backdoor facility provides an interactive shell interface for any eventlet based process, allowing an administrator to telnet to a pre-defined port and execute a variety of commands. Generating a GMR ---------------- A *GMR* can be generated by sending the *USR2* signal to any Bare Metal process that supports it. The *GMR* will then be output to stderr for that particular process. For example: Suppose that ``ironic-api`` has process ID ``6385``, and was run with ``2>/var/log/ironic/ironic-api-err.log``. Then, sending the *USR* signal:: kill -USR2 6385 will trigger the Guru Meditation report to be printed to ``/var/log/ironic/ironic-api-err.log``. Structure of a GMR ------------------ The *GMR* consists of the following sections: Package Shows information about the package to which this process belongs, including version information. Threads Shows stack traces and thread IDs for each of the threads within this process. Green Threads Shows stack traces for each of the green threads within this process (green threads don't have thread IDs). Configuration Lists all the configuration options currently accessible via the CONF object for the current process. Sample GMR Report ----------------- Below is a sample GMR report generated for ``ironic-api`` service: .. include:: report.txt :literal: ironic-10.1.1/doc/source/admin/portgroups.rst0000666000175100017510000001252213243617463021231 0ustar zuulzuul00000000000000=================== Port groups support =================== The Bare Metal service supports static configuration of port groups (bonds) in the instances via configdrive. See `kernel documentation on bonding`_ to see why it may be useful and how it is setup in linux. The sections below describe how to make use of them in the Bare Metal service. Switch-side configuration ------------------------- If port groups are desired in the ironic deployment, they need to be configured on the switches. It needs to be done manually, and the mode and properties configured on the switch have to correspond to the mode and properties that will be configured on the ironic side, as bonding mode and properties may be named differently on your switch, or have possible values different from the ones described in `kernel documentation on bonding`_. Please refer to your switch configuration documentation for more details. Provisioning and cleaning cannot make use of port groups if they need to boot the deployment ramdisk via (i)PXE. If your switches or desired port group configuration do not support port group fallback, which will allow port group members to be used by themselves, you need to set port group's ``standalone_ports_supported`` value to be ``False`` in ironic, as it is ``True`` by default. Physical networks ----------------- If any port in a port group has a physical network, then all ports in that port group must have the same physical network. In order to change the physical network of the ports in a port group, all ports must first be removed from the port group, before changing their physical networks (to the same value), then adding them back to the port group. See :ref:`physical networks ` for further information on using physical networks in the Bare Metal service. Port groups configuration in the Bare Metal service --------------------------------------------------- Port group configuration is supported in ironic API microversions 1.26, the CLI commands below specify it for completeness. #. When creating a port group, the node to which it belongs must be specified, along with, optionally, its name, address, mode, properties, and if it supports fallback to standalone ports:: openstack --os-baremetal-api-version 1.26 baremetal port group create \ --node $NODE_UUID --name test --address fa:ab:25:48:fd:ba --mode 802.3ad \ --property miimon=100 --property xmit_hash_policy="layer2+3" \ --support-standalone-ports A port group can also be updated with ``openstack baremetal port group set`` command, see its help for more details. If an address is not specified, the port group address on the deployed instance will be the same as the address of the neutron port that is attached to the port group. If the neutron port is not attached, the port group will not be configured. .. note:: In standalone mode, port groups have to be configured manually. It can be done either statically inside the image, or by generating the configdrive and adding it to the node's ``instance_info``. For more information on how to configure bonding via configdrive, refer to `cloud-init documentation `_ and `code `_. cloud-init version 0.7.7 or later is required for bonding configuration to work. If the port group's address is not explicitly set in standalone mode, it will be set automatically by the process described in `kernel documentation on bonding`_. During interface attachment, port groups have higher priority than ports, so they will be used first. (It is not yet possible to specify which one is desired, a port group or a port, in an interface attachment request). Port groups that don't have any ports will be ignored. The mode and properties values are described in the `kernel documentation on bonding`_. The default port group mode is ``active-backup``, and this default can be changed by setting the ``[DEFAULT]default_portgroup_mode`` configuration option in the ironic API service configuration file. #. Associate ports with the created port group. It can be done on port creation:: openstack --os-baremetal-api-version 1.26 baremetal port create \ --node $NODE_UUID --address fa:ab:25:48:fd:ba --port-group test Or by updating an existing port:: openstack --os-baremetal-api-version 1.26 baremetal port set \ $PORT_UUID --port-group $PORT_GROUP_UUID When updating a port, the node associated with the port has to be in ``enroll``, ``manageable``, or ``inspecting`` states. A port group can have the same or different address as individual ports. #. Boot an instance (or node directly, in case of using standalone ironic) providing an image that has cloud-init version 0.7.7 or later and supports bonding. When the deployment is done, you can check that the port group is set up properly by running the following command in the instance:: cat /proc/net/bonding/bondX where ``X`` is a number autogenerated by cloud-init for each configured port group, in no particular order. It starts with 0 and increments by 1 for every configured port group. .. _`kernel documentation on bonding`: https://www.kernel.org/doc/Documentation/networking/bonding.txt ironic-10.1.1/doc/source/configuration/0000775000175100017510000000000013243617733020026 5ustar zuulzuul00000000000000ironic-10.1.1/doc/source/configuration/config.rst0000666000175100017510000000044013243617463022025 0ustar zuulzuul00000000000000===================== Configuration Options ===================== The following is an overview of all available configuration options in Ironic. For a sample configuration file, refer to :doc:`sample-config`. .. show-options:: :config-file: tools/config/ironic-config-generator.conf ironic-10.1.1/doc/source/configuration/policy.rst0000666000175100017510000000035413243617463022063 0ustar zuulzuul00000000000000======== Policies ======== The following is an overview of all available policies in Ironic. For a sample configuration file, refer to :doc:`sample-policy`. .. show-policy:: :config-file: tools/policy/ironic-policy-generator.conf ironic-10.1.1/doc/source/configuration/sample-config.rst0000666000175100017510000000111613243617463023305 0ustar zuulzuul00000000000000========================= Sample Configuration File ========================= The following is a sample Ironic configuration for adaptation and use. For a detailed overview of all available configuration options, refer to :doc:`config`. The sample configuration can also be viewed in :download:`file form `. .. important:: The sample configuration file is auto-generated from Ironic when this documentation is built. You must ensure your version of Ironic matches the version of this documentation. .. literalinclude:: /_static/ironic.conf.sample ironic-10.1.1/doc/source/configuration/index.rst0000666000175100017510000000067013243617463021674 0ustar zuulzuul00000000000000======================= Configuration Reference ======================= Many aspects of the Bare Metal service are specific to the environment it is deployed in. The following pages describe configuration options that can be used to adjust the service to your particular situation. .. toctree:: :maxdepth: 1 Configuration Options Sample Config File Policies Sample Policy File ironic-10.1.1/doc/source/configuration/sample-policy.rst0000666000175100017510000000062613243617463023344 0ustar zuulzuul00000000000000============= Ironic Policy ============= The following is a sample Ironic policy file, autogenerated from Ironic when this documentation is built. To prevent conflicts, ensure your version of Ironic aligns with the version of this documentation. The sample policy can also be downloaded as a :download:`file `. .. literalinclude:: /_static/ironic.policy.yaml.sample ironic-10.1.1/doc/source/install/0000775000175100017510000000000013243617733016625 5ustar zuulzuul00000000000000ironic-10.1.1/doc/source/install/configure-networking.rst0000666000175100017510000001236213243617463023533 0ustar zuulzuul00000000000000.. _configure-networking: Configure the Networking service for bare metal provisioning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ You need to configure Networking so that the bare metal server can communicate with the Networking service for DHCP, PXE boot and other requirements. This section covers configuring Networking for a single flat network for bare metal provisioning. It is recommended to use the baremetal ML2 mechanism driver and L2 agent for proper integration with the Networking service. Documentation regarding installation and configuration of the baremetal mechanism driver and L2 agent is available `here `_. For use with `routed networks `_ the baremetal ML2 components are required. .. Note:: When the baremetal ML2 components are *not* used, ports in the Networking service will have status: ``DOWN``, and binding_vif_type: ``binding_failed``. This was always the status for Bare Metal service ``flat`` network interface ports prior to the introduction of the baremetal ML2 integration. For a non-routed network, bare metal servers can still be deployed and are functional, despite this port binding state in the Networking service. You will also need to provide Bare Metal service with the MAC address(es) of each node that it is provisioning; Bare Metal service in turn will pass this information to Networking service for DHCP and PXE boot configuration. An example of this is shown in the :ref:`enrollment` section. #. Install the networking-baremetal ML2 mechanism driver and L2 agent in the Networking service. #. Edit ``/etc/neutron/plugins/ml2/ml2_conf.ini`` and modify these: .. code-block:: ini [ml2] type_drivers = flat tenant_network_types = flat mechanism_drivers = openvswitch,baremetal [ml2_type_flat] flat_networks = physnet1 [securitygroup] firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver enable_security_group = True [ovs] bridge_mappings = physnet1:br-eth2 # Replace eth2 with the interface on the neutron node which you # are using to connect to the bare metal server #. Restart the ``neutron-server`` service, to load the new configuration. #. Create and edit ``/etc/neutron/plugins/ml2/ironic_neutron_agent.ini`` and add the required configuration. For example: .. code-block:: ini [ironic] project_domain_name = Default project_name = service user_domain_name = Default password = password username = ironic auth_url = http://identity-server.example.com/identity auth_type = password region_name = RegionOne #. Make sure the ``ironic-neutron-agent`` service is started. #. If neutron-openvswitch-agent runs with ``ovs_neutron_plugin.ini`` as the input config-file, edit ``ovs_neutron_plugin.ini`` to configure the bridge mappings by adding the [ovs] section described in the previous step, and restart the neutron-openvswitch-agent. #. Add the integration bridge to Open vSwitch: .. code-block:: console $ ovs-vsctl add-br br-int #. Create the br-eth2 network bridge to handle communication between the OpenStack services (and the Bare Metal services) and the bare metal nodes using eth2. Replace eth2 with the interface on the network node which you are using to connect to the Bare Metal service: .. code-block:: console $ ovs-vsctl add-br br-eth2 $ ovs-vsctl add-port br-eth2 eth2 #. Restart the Open vSwitch agent: .. code-block:: console # service neutron-plugin-openvswitch-agent restart #. On restarting the Networking service Open vSwitch agent, the veth pair between the bridges br-int and br-eth2 is automatically created. Your Open vSwitch bridges should look something like this after following the above steps: .. code-block:: console $ ovs-vsctl show Bridge br-int fail_mode: secure Port "int-br-eth2" Interface "int-br-eth2" type: patch options: {peer="phy-br-eth2"} Port br-int Interface br-int type: internal Bridge "br-eth2" Port "phy-br-eth2" Interface "phy-br-eth2" type: patch options: {peer="int-br-eth2"} Port "eth2" Interface "eth2" Port "br-eth2" Interface "br-eth2" type: internal ovs_version: "2.3.0" #. Create the flat network on which you are going to launch the instances: .. code-block:: console $ neutron net-create --tenant-id $TENANT_ID sharednet1 --shared \ --provider:network_type flat --provider:physical_network physnet1 #. Create the subnet on the newly created network: .. code-block:: console $ neutron subnet-create sharednet1 $NETWORK_CIDR --name $SUBNET_NAME \ --ip-version=4 --gateway=$GATEWAY_IP --allocation-pool \ start=$START_IP,end=$END_IP --enable-dhcp ironic-10.1.1/doc/source/install/configure-iscsi.rst0000666000175100017510000000025013243617463022447 0ustar zuulzuul00000000000000Configuring iSCSI-based drivers ------------------------------- Ensure that the ``qemu-img`` and ``iscsiadm`` tools are installed on the **ironic-conductor** host(s). ironic-10.1.1/doc/source/install/configure-identity.rst0000666000175100017510000000763013243617463023177 0ustar zuulzuul00000000000000Configure the Identity service for the Bare Metal service ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #. Create the Bare Metal service user (for example, ``ironic``). The service uses this to authenticate with the Identity service. Use the ``service`` tenant and give the user the ``admin`` role: .. code-block:: console $ openstack user create --password IRONIC_PASSWORD \ --email ironic@example.com ironic $ openstack role add --project service --user ironic admin #. You must register the Bare Metal service with the Identity service so that other OpenStack services can locate it. To register the service: .. code-block:: console $ openstack service create --name ironic --description \ "Ironic baremetal provisioning service" baremetal #. Use the ``id`` property that is returned from the Identity service when registering the service (above), to create the endpoint, and replace ``IRONIC_NODE`` with your Bare Metal service's API node: .. code-block:: console $ openstack endpoint create --region RegionOne \ baremetal admin http://$IRONIC_NODE:6385 $ openstack endpoint create --region RegionOne \ baremetal public http://$IRONIC_NODE:6385 $ openstack endpoint create --region RegionOne \ baremetal internal http://$IRONIC_NODE:6385 If only keystone v2 API is available, use this command instead: .. code-block:: console $ openstack endpoint create --region RegionOne \ --publicurl http://$IRONIC_NODE:6385 \ --internalurl http://$IRONIC_NODE:6385 \ --adminurl http://$IRONIC_NODE:6385 \ baremetal #. You may delegate limited privileges related to the Bare Metal service to your Users by creating Roles with the OpenStack Identity service. By default, the Bare Metal service expects the "baremetal_admin" and "baremetal_observer" Roles to exist, in addition to the default "admin" Role. There is no negative consequence if you choose not to create these Roles. They can be created with the following commands: .. code-block:: console $ openstack role create baremetal_admin $ openstack role create baremetal_observer If you choose to customize the names of Roles used with the Bare Metal service, do so by changing the "is_member", "is_observer", and "is_admin" policy settings in ``/etc/ironic/policy.json``. More complete documentation on managing Users and Roles within your OpenStack deployment are outside the scope of this document, but may be found here_. #. You can further restrict access to the Bare Metal service by creating a separate "baremetal" Project, so that Bare Metal resources (Nodes, Ports, etc) are only accessible to members of this Project: .. code-block:: console $ openstack project create baremetal At this point, you may grant read-only access to the Bare Metal service API without granting any other access by issuing the following commands: .. code-block:: console $ openstack user create \ --domain default --project-domain default --project baremetal \ --password PASSWORD USERNAME $ openstack role add \ --user-domain default --project-domain default --project baremetal \ --user USERNAME baremetal_observer #. Further documentation is available elsewhere for the ``openstack`` `command-line client`_ and the Identity_ service. A :doc:`policy.json.sample ` file, which enumerates the service's default policies, is provided for your convenience with the Bare Metal Service. .. _Identity: https://docs.openstack.org/keystone/latest/admin/cli-manage-projects-users-and-roles.html .. _`command-line client`: https://docs.openstack.org/python-openstackclient/latest/cli/authentication.html .. _here: https://docs.openstack.org/keystone/latest/admin/identity-concepts.html#user-management ironic-10.1.1/doc/source/install/configure-tenant-networks.rst0000666000175100017510000001545313243617463024513 0ustar zuulzuul00000000000000.. _configure-tenant-networks: Configure tenant networks ========================= Below is an example flow of how to set up the Bare Metal service so that node provisioning will happen in a multi-tenant environment (which means using the ``neutron`` network interface as stated above): #. Network interfaces can be enabled on ironic-conductor by adding them to the ``enabled_network_interfaces`` configuration option under the ``default`` section of the configuration file:: [DEFAULT] ... enabled_network_interfaces=noop,flat,neutron Keep in mind that, ideally, all ironic-conductors should have the same list of enabled network interfaces, but it may not be the case during ironic-conductor upgrades. This may cause problems if one of the ironic-conductors dies and some node that is taken over is mapped to an ironic-conductor that does not support the node's network interface. Any actions that involve calling the node's driver will fail until that network interface is installed and enabled on that ironic-conductor. #. It is recommended to set the default network interface via the ``default_network_interface`` configuration option under the ``default`` section of the configuration file:: [DEFAULT] ... default_network_interface=neutron This default value will be used for all nodes that don't have a network interface explicitly specified in the creation request. If this configuration option is not set, the default network interface is determined by looking at the ``[dhcp]dhcp_provider`` configuration option value. If it is ``neutron``, then ``flat`` network interface becomes the default, otherwise ``noop`` is the default. #. Define a provider network in the Networking service, which we shall refer to as the "provisioning" network. Using the ``neutron`` network interface requires that ``provisioning_network`` and ``cleaning_network`` configuration options are set to valid identifiers (UUID or name) of networks in the Networking service. If these options are not set correctly, cleaning or provisioning will fail to start. There are two ways to set these values: - Under the ``neutron`` section of ironic configuration file: .. code-block:: ini [neutron] cleaning_network = $CLEAN_UUID_OR_NAME provisioning_network = $PROVISION_UUID_OR_NAME - Under ``provisioning_network`` and ``cleaning_network`` keys of the node's ``driver_info`` field as ``driver_info['provisioning_network']`` and ``driver_info['cleaning_network']`` respectively. .. note:: If these ``provisioning_network`` and ``cleaning_network`` values are not specified in node's `driver_info` then ironic falls back to the configuration in the ``neutron`` section. Please refer to :doc:`configure-cleaning` for more information about cleaning. .. warning:: Please make sure that the Bare Metal service has exclusive access to the provisioning and cleaning networks. Spawning instances by non-admin users in these networks and getting access to the Bare Metal service's control plane is a security risk. For this reason, the provisioning and cleaning networks should be configured as non-shared networks in the ``admin`` tenant. .. note:: Spawning a bare metal instance onto the provisioning network is impossible, the deployment will fail. The node should be deployed onto a different network than the provisioning network. When you boot a bare metal instance from the Compute service, you should choose a different network in the Networking service for your instance. .. note:: The "provisioning" and "cleaning" networks may be the same network or distinct networks. To ensure that communication between the Bare Metal service and the deploy ramdisk works, it is important to ensure that security groups are disabled for these networks, *or* that the default security groups allow: * DHCP * TFTP * egress port used for the Bare Metal service (6385 by default) * ingress port used for ironic-python-agent (9999 by default) * if using :ref:`iscsi-deploy`, the ingress port used for iSCSI (3260 by default) * if using :ref:`direct-deploy`, the egress port used for the Object Storage service (typically 80 or 443) * if using iPXE, the egress port used for the HTTP server running on the ironic-conductor nodes (typically 80). #. This step is optional and applicable only if you want to use security groups during provisioning and/or cleaning of the nodes. If not specified, default security groups are used. #. Define security groups in the Networking service, to be used for provisioning and/or cleaning networks. #. Add the list of these security group UUIDs under the ``neutron`` section of ironic-conductor's configuration file as shown below:: [neutron] ... cleaning_network=$CLEAN_UUID_OR_NAME cleaning_network_security_groups=[$LIST_OF_CLEAN_SECURITY_GROUPS] provisioning_network=$PROVISION_UUID_OR_NAME provisioning_network_security_groups=[$LIST_OF_PROVISION_SECURITY_GROUPS] Multiple security groups may be applied to a given network, hence, they are specified as a list. The same security group(s) could be used for both provisioning and cleaning networks. .. warning:: If security groups are configured as described above, do not set the "port_security_enabled" flag to False for the corresponding Networking service's network or port. This will cause the deploy to fail. For example: if ``provisioning_network_security_groups`` configuration option is used, ensure that "port_security_enabled" flag for the provisioning network is set to True. This flag is set to True by default; make sure not to override it by manually setting it to False. #. Install and configure a compatible ML2 mechanism driver which supports bare metal provisioning for your switch. See `ML2 plugin configuration manual `_ for details. #. Restart the ironic-conductor and ironic-api services after the modifications: - Fedora/RHEL7/CentOS7:: sudo systemctl restart openstack-ironic-api sudo systemctl restart openstack-ironic-conductor - Ubuntu:: sudo service ironic-api restart sudo service ironic-conductor restart #. Make sure that the ironic-conductor is reachable over the provisioning network by trying to download a file from a TFTP server on it, from some non-control-plane server in that network:: tftp $TFTP_IP -c get $FILENAME where FILENAME is the file located at the TFTP server. See :ref:`multitenancy` for required node configuration. ironic-10.1.1/doc/source/install/enrollment.rst0000666000175100017510000010455413243617463021551 0ustar zuulzuul00000000000000.. _enrollment: Enrollment ========== After all the services have been properly configured, you should enroll your hardware with the Bare Metal service, and confirm that the Compute service sees the available hardware. The nodes will be visible to the Compute service once they are in the ``available`` provision state. .. note:: After enrolling nodes with the Bare Metal service, the Compute service will not be immediately notified of the new resources. The Compute service's resource tracker syncs periodically, and so any changes made directly to the Bare Metal service's resources will become visible in the Compute service only after the next run of that periodic task. More information is in the :ref:`troubleshooting-install` section. .. note:: Any bare metal node that is visible to the Compute service may have a workload scheduled to it, if both the ``power`` and ``deploy`` interfaces pass the ``validate`` check. If you wish to exclude a node from the Compute service's scheduler, for instance so that you can perform maintenance on it, you can set the node to "maintenance" mode. For more information see the :ref:`maintenance_mode` section. Choosing a driver ----------------- When enrolling a node, the most important information to supply is *driver*. See :doc:`enabling-drivers` for a detailed explanation of bare metal drivers, hardware types and interfaces. Starting with the Pike release, we recommend the use of *hardware types* instead of *classic drivers*, since classic drivers may be deprecated in the near future. The ``driver list`` command can be used to list all drivers enabled on all hosts: .. code-block:: console openstack baremetal driver list +---------------------+-----------------------+ | Supported driver(s) | Active host(s) | +---------------------+-----------------------+ | ipmi | localhost.localdomain | | pxe_ipmitool | localhost.localdomain | +---------------------+-----------------------+ Starting with API version 1.31 (and ``python-ironicclient`` 1.13), you can also list only classic drivers or only hardware types via the ``--type`` argument: .. code-block:: console openstack baremetal --os-baremetal-api-version 1.31 driver list --type dynamic +---------------------+-----------------------+ | Supported driver(s) | Active host(s) | +---------------------+-----------------------+ | ipmi | localhost.localdomain | +---------------------+-----------------------+ The specific driver to use should be picked based on actual hardware capabilities and expected features. See :doc:`/admin/drivers` for more hints on that. Each driver has a list of *driver properties* that need to be specified via the node's ``driver_info`` field, in order for the driver to operate on node. This list consists of the properties of the hardware interfaces that the driver uses. These driver properties are available with the ``driver property list`` command: .. code-block:: console $ openstack baremetal driver property list ipmi +----------------------+-------------------------------------------------------------------------------------------------------------+ | Property | Description | +----------------------+-------------------------------------------------------------------------------------------------------------+ | ipmi_address | IP address or hostname of the node. Required. | | ipmi_password | password. Optional. | | ipmi_username | username; default is NULL user. Optional. | | ... | ... | | deploy_kernel | UUID (from Glance) of the deployment kernel. Required. | | deploy_ramdisk | UUID (from Glance) of the ramdisk that is mounted at boot time. Required. | +----------------------+-------------------------------------------------------------------------------------------------------------+ The properties marked as required must be supplied either during node creation or shortly after. Some properties may only be required for certain features. Note on API versions -------------------- Starting with API version 1.11, the Bare Metal service added a new initial provision state of ``enroll`` to its state machine. When this or later API version is used, new nodes get this state instead of ``available``. Existing automation tooling that use an API version lower than 1.11 are not affected, since the initial provision state is still ``available``. However, using API version 1.11 or above may break existing automation tooling with respect to node creation. The default API version used by (the most recent) python-ironicclient is 1.9, but it may change in the future and should not be relied on. In the examples below we will use version 1.11 of the Bare metal API. This gives us the following advantages: * Explicit power credentials validation before leaving the ``enroll`` state. * Running node cleaning before entering the ``available`` state. * Not exposing half-configured nodes to the scheduler. To set the API version for all commands, you can set the environment variable ``IRONIC_API_VERSION``. For the OpenStackClient baremetal plugin, set the ``OS_BAREMETAL_API_VERSION`` variable to the same value. For example: .. code-block:: console $ export IRONIC_API_VERSION=1.11 $ export OS_BAREMETAL_API_VERSION=1.11 Enrollment process ------------------ Creating a node ~~~~~~~~~~~~~~~ This section describes the main steps to enroll a node and make it available for provisioning. Some steps are shown separately for illustration purposes, and may be combined if desired. #. Create a node in the Bare Metal service with the ``node create`` command. At a minimum, you must specify the driver name (for example, ``ipmi``). This command returns the node UUID along with other information about the node. The node's provision state will be ``enroll``: .. code-block:: console $ export OS_BAREMETAL_API_VERSION=1.11 $ openstack baremetal node create --driver ipmi +--------------+--------------------------------------+ | Property | Value | +--------------+--------------------------------------+ | uuid | dfc6189f-ad83-4261-9bda-b27258eb1987 | | driver_info | {} | | extra | {} | | driver | ipmi | | chassis_uuid | | | properties | {} | | name | None | +--------------+--------------------------------------+ $ openstack baremetal node show dfc6189f-ad83-4261-9bda-b27258eb1987 +------------------------+--------------------------------------+ | Property | Value | +------------------------+--------------------------------------+ | target_power_state | None | | extra | {} | | last_error | None | | maintenance_reason | None | | provision_state | enroll | | uuid | dfc6189f-ad83-4261-9bda-b27258eb1987 | | console_enabled | False | | target_provision_state | None | | provision_updated_at | None | | maintenance | False | | power_state | None | | driver | ipmi | | properties | {} | | instance_uuid | None | | name | None | | driver_info | {} | | ... | ... | +------------------------+--------------------------------------+ A node may also be referred to by a logical name as well as its UUID. A name can be assigned to the node during its creation by adding the ``-n`` option to the ``node create`` command or by updating an existing node with the ``node set`` command. See `Logical Names`_ for examples. #. Starting with API version 1.31 (and ``python-ironicclient`` 1.13), you can pick which hardware interface to use with nodes that use hardware types. Each interface is represented by a node field called ``_interface`` where ```` in the interface type, e.g. ``boot``. See :doc:`enabling-drivers` for details on hardware interfaces and :doc:`/admin/upgrade-to-hardware-types` for the matching between classic drivers and hardware types. An interface can be set either separately: .. code-block:: console $ openstack baremetal --os-baremetal-api-version 1.31 node set $NODE_UUID \ --deploy-interface direct \ --raid-interface agent or set during node creation: .. code-block:: console $ openstack baremetal --os-baremetal-api-version 1.31 node create --driver ipmi \ --deploy-interface direct \ --raid-interface agent If no value is provided for some interfaces, `Defaults for hardware interfaces`_ are used instead. It's an error to try changing this field for a node with a *classic driver*, and setting node's driver to classic one causes these fields to be set to ``None`` automatically. #. Update the node ``driver_info`` with the required driver properties, so that the Bare Metal service can manage the node: .. code-block:: console $ openstack baremetal node set $NODE_UUID \ --driver-info ipmi_username=$USER \ --driver-info ipmi_password=$PASS \ --driver-info ipmi_address=$ADDRESS .. note:: If IPMI is running on a port other than 623 (the default). The port must be added to ``driver_info`` by specifying the ``ipmi_port`` value. Example: .. code-block:: console $ openstack baremetal node set $NODE_UUID --driver-info ipmi_port=$PORT_NUMBER You may also specify all ``driver_info`` parameters during node creation by passing the **--driver-info** option multiple times: .. code-block:: console $ openstack baremetal node create --driver ipmi \ --driver-info ipmi_username=$USER \ --driver-info ipmi_password=$PASS \ --driver-info ipmi_address=$ADDRESS See `Choosing a driver`_ above for details on driver properties. #. Specify a deploy kernel and ramdisk compatible with the node's driver, for example: .. code-block:: console $ openstack baremetal node set $NODE_UUID \ --driver-info deploy_kernel=$DEPLOY_VMLINUZ_UUID \ --driver-info deploy_ramdisk=$DEPLOY_INITRD_UUID See :doc:`configure-glance-images` for details. #. Optionally you can specify the provisioning and/or cleaning network UUID or name in the node's ``driver_info``. The ``neutron`` network interface requires both ``provisioning_network`` and ``cleaning_network``, while the ``flat`` network interface requires the ``cleaning_network`` to be set either in the configuration or on the nodes. For example: .. code-block:: console $ openstack baremetal node set $NODE_UUID \ --driver-info cleaning_network=$CLEAN_UUID_OR_NAME \ --driver-info provisioning_network=$PROVISION_UUID_OR_NAME See :doc:`configure-tenant-networks` for details. #. You must also inform the Bare Metal service of the network interface cards which are part of the node by creating a port with each NIC's MAC address. These MAC addresses are passed to the Networking service during instance provisioning and used to configure the network appropriately: .. code-block:: console $ openstack baremetal port create $MAC_ADDRESS --node $NODE_UUID .. _enrollment-scheduling: Adding scheduling information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #. Assign a *resource class* to the node. A *resource class* should represent a class of hardware in your data center, that corresponds to a Compute flavor. For example, let's split hardware into these three groups: #. nodes with a lot of RAM and powerful CPU for computational tasks, #. nodes with powerful GPU for OpenCL computing, #. smaller nodes for development and testing. We can define three resource classes to reflect these hardware groups, named ``large-cpu``, ``large-gpu`` and ``small`` respectively. Then, for each node in each of the hardware groups, we'll set their ``resource_class`` appropriately via: .. code-block:: console $ openstack --os-baremetal-api-version 1.21 baremetal node set $NODE_UUID \ --resource-class $CLASS_NAME The ``--resource-class`` argument can also be used when creating a node: .. code-block:: console $ openstack --os-baremetal-api-version 1.21 baremetal node create \ --driver $DRIVER --resource-class $CLASS_NAME To use resource classes for scheduling you need to update your flavors as described in :doc:`configure-nova-flavors`. .. warning:: Scheduling based on resource classes will replace scheduling based on properties in the Queens release. .. note:: This is not required for standalone deployments, only for those using the Compute service for provisioning bare metal instances. #. Update the node's properties to match the actual hardware of the node: .. code-block:: console $ openstack baremetal node set $NODE_UUID \ --property cpus=$CPU_COUNT \ --property memory_mb=$RAM_MB \ --property local_gb=$DISK_GB \ --property cpu_arch=$ARCH As above, these can also be specified at node creation by passing the **--property** option to ``node create`` multiple times: .. code-block:: console $ openstack baremetal node create --driver ipmi \ --driver-info ipmi_username=$USER \ --driver-info ipmi_password=$PASS \ --driver-info ipmi_address=$ADDRESS \ --property cpus=$CPU_COUNT \ --property memory_mb=$RAM_MB \ --property local_gb=$DISK_GB \ --property cpu_arch=$ARCH These values can also be discovered during `Hardware Inspection`_. .. warning:: If scheduling based on resource classes is not used, the three properties ``cpus``, ``memory_mb`` and ``local_gb`` must match ones defined on the flavor created when :doc:`configure-nova-flavors`. .. warning:: The value provided for the ``local_gb`` property must match the size of the root device you're going to deploy on. By default **ironic-python-agent** picks the smallest disk which is not smaller than 4 GiB. If you override this logic by using root device hints (see :ref:`root-device-hints`), the ``local_gb`` value should match the size of picked target disk. #. If you wish to perform more advanced scheduling of the instances based on hardware capabilities, you may add metadata to each node that will be exposed to the Compute scheduler (see: `ComputeCapabilitiesFilter`_). A full explanation of this is outside of the scope of this document. It can be done through the special ``capabilities`` member of node properties: .. code-block:: console $ openstack baremetal node set $NODE_UUID \ --property capabilities=key1:val1,key2:val2 Some capabilities can also be discovered during `Hardware Inspection`_. #. If you wish to perform advanced scheduling of instances based on qualitative attributes of bare metal nodes, you may add traits to each bare metal node that will be exposed to the Compute scheduler (see: :ref:`scheduling-traits` for a more in-depth discussion of traits in the Bare Metal service). For example, to add the standard trait ``HW_CPU_X86_VMX`` and a custom trait ``CUSTOM_TRAIT1`` to a node: .. code-block:: console $ openstack baremetal node add trait $NODE_UUID \ CUSTOM_TRAIT1 HW_CPU_X86_VMX Validating node information ~~~~~~~~~~~~~~~~~~~~~~~~~~~ #. To check if Bare Metal service has the minimum information necessary for a node's driver to be functional, you may ``validate`` it: .. code-block:: console $ openstack baremetal node validate $NODE_UUID +------------+--------+--------+ | Interface | Result | Reason | +------------+--------+--------+ | boot | True | | | console | True | | | deploy | True | | | inspect | True | | | management | True | | | network | True | | | power | True | | | raid | True | | | storage | True | | +------------+--------+--------+ If the node fails validation, each driver interface will return information as to why it failed: .. code-block:: console $ openstack baremetal node validate $NODE_UUID +------------+--------+-------------------------------------------------------------------------------------------------------------------------------------+ | Interface | Result | Reason | +------------+--------+-------------------------------------------------------------------------------------------------------------------------------------+ | boot | True | | | console | None | not supported | | deploy | False | Cannot validate iSCSI deploy. Some parameters were missing in node's instance_info. Missing are: ['root_gb', 'image_source'] | | inspect | True | | | management | False | Missing the following IPMI credentials in node's driver_info: ['ipmi_address']. | | network | True | | | power | False | Missing the following IPMI credentials in node's driver_info: ['ipmi_address']. | | raid | None | not supported | | storage | True | | +------------+--------+-------------------------------------------------------------------------------------------------------------------------------------+ When using the Compute Service with the Bare Metal service, it is safe to ignore the deploy interface's validation error due to lack of image information. You may continue the enrollment process. This information will be set by the Compute Service just before deploying, when an instance is requested: .. code-block:: console $ openstack baremetal node validate $NODE_UUID +------------+--------+------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Interface | Result | Reason | +------------+--------+------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | boot | False | Cannot validate image information for node because one or more parameters are missing from its instance_info. Missing are: ['ramdisk', 'kernel', 'image_source'] | | console | True | | | deploy | False | Cannot validate image information for node because one or more parameters are missing from its instance_info. Missing are: ['ramdisk', 'kernel', 'image_source'] | | inspect | True | | | management | True | | | network | True | | | power | True | | | raid | None | not supported | | storage | True | | +------------+--------+------------------------------------------------------------------------------------------------------------------------------------------------------------------+ Making node available for deployment ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In order for nodes to be available for deploying workloads on them, nodes must be in the ``available`` provision state. To do this, nodes created with API version 1.11 and above must be moved from the ``enroll`` state to the ``manageable`` state and then to the ``available`` state. This section can be safely skipped, if API version 1.10 or earlier is used (which is the case by default). After creating a node and before moving it from its initial provision state of ``enroll``, basic power and port information needs to be configured on the node. The Bare Metal service needs this information because it verifies that it is capable of controlling the node when transitioning the node from ``enroll`` to ``manageable`` state. To move a node from ``enroll`` to ``manageable`` provision state: .. code-block:: console $ openstack baremetal --os-baremetal-api-version 1.11 node manage $NODE_UUID $ openstack baremetal node show $NODE_UUID +------------------------+--------------------------------------------------------------------+ | Property | Value | +------------------------+--------------------------------------------------------------------+ | ... | ... | | provision_state | manageable | <- verify correct state | uuid | 0eb013bb-1e4b-4f4c-94b5-2e7468242611 | | ... | ... | +------------------------+--------------------------------------------------------------------+ .. note:: Since it is an asynchronous call, the response for ``openstack baremetal node manage`` will not indicate whether the transition succeeded or not. You can check the status of the operation via ``openstack baremetal node show``. If it was successful, ``provision_state`` will be in the desired state. If it failed, there will be information in the node's ``last_error``. When a node is moved from the ``manageable`` to ``available`` provision state, the node will go through automated cleaning if configured to do so (see :ref:`configure-cleaning`). To move a node from ``manageable`` to ``available`` provision state: .. code-block:: console $ openstack baremetal --os-baremetal-api-version 1.11 node provide $NODE_UUID $ openstack baremetal node show $NODE_UUID +------------------------+--------------------------------------------------------------------+ | Property | Value | +------------------------+--------------------------------------------------------------------+ | ... | ... | | provision_state | available | < - verify correct state | uuid | 0eb013bb-1e4b-4f4c-94b5-2e7468242611 | | ... | ... | +------------------------+--------------------------------------------------------------------+ For more details on the Bare Metal service's state machine, see the :doc:`/contributor/states` documentation. .. _ComputeCapabilitiesFilter: https://docs.openstack.org/nova/latest/user/filter-scheduler.html Mapping nodes to Compute cells ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If the Compute service is used for scheduling, and the ``discover_hosts_in_cells_interval`` was not set as described in :doc:`configure-compute`, then log into any controller node and run the following command to map the new node(s) to Compute cells:: nova-manage cell_v2 discover_hosts Logical names ------------- A node may also be referred to by a logical name as well as its UUID. Names can be assigned either during its creation by adding the ``-n`` option to the ``node create`` command or by updating an existing node with the ``node set`` command. Node names must be unique, and conform to: - rfc952_ - rfc1123_ - wiki_hostname_ The node is named 'example' in the following examples: .. code-block:: console $ openstack baremetal node create --driver ipmi --name example or .. code-block:: console $ openstack baremetal node set $NODE_UUID --name example Once assigned a logical name, a node can then be referred to by name or UUID interchangeably: .. code-block:: console $ openstack baremetal node create --driver ipmi --name example +--------------+--------------------------------------+ | Property | Value | +--------------+--------------------------------------+ | uuid | 71e01002-8662-434d-aafd-f068f69bb85e | | driver_info | {} | | extra | {} | | driver | ipmi | | chassis_uuid | | | properties | {} | | name | example | +--------------+--------------------------------------+ $ openstack baremetal node show example +------------------------+--------------------------------------+ | Property | Value | +------------------------+--------------------------------------+ | target_power_state | None | | extra | {} | | last_error | None | | updated_at | 2015-04-24T16:23:46+00:00 | | ... | ... | | instance_info | {} | +------------------------+--------------------------------------+ .. _rfc952: https://tools.ietf.org/html/rfc952 .. _rfc1123: https://tools.ietf.org/html/rfc1123 .. _wiki_hostname: https://en.wikipedia.org/wiki/Hostname .. _hardware_interfaces_defaults: Defaults for hardware interfaces -------------------------------- For *classic drivers* all hardware interface implementations (except for the *network interface*) are hardcoded and cannot be changed. For *hardware types*, users can request one of enabled implementations when creating or updating a node as explained in `Creating a node`_. When no value is provided for a certain interface when creating a node, or changing a node's hardware type, the default value is used. You can use the driver details command to list the current enabled and default interfaces for a hardware type (for your deployment): .. code-block:: console $ openstack baremetal --os-baremetal-api-version 1.31 driver show ipmi +-------------------------------+----------------+ | Field | Value | +-------------------------------+----------------+ | default_boot_interface | pxe | | default_console_interface | no-console | | default_deploy_interface | iscsi | | default_inspect_interface | no-inspect | | default_management_interface | ipmitool | | default_network_interface | flat | | default_power_interface | ipmitool | | default_raid_interface | no-raid | | default_vendor_interface | no-vendor | | enabled_boot_interfaces | pxe | | enabled_console_interfaces | no-console | | enabled_deploy_interfaces | iscsi, direct | | enabled_inspect_interfaces | no-inspect | | enabled_management_interfaces | ipmitool | | enabled_network_interfaces | flat, noop | | enabled_power_interfaces | ipmitool | | enabled_raid_interfaces | no-raid, agent | | enabled_vendor_interfaces | no-vendor | | hosts | ironic-host-1 | | name | ipmi | | type | dynamic | +-------------------------------+----------------+ The defaults are calculated as follows: #. If the ``default__interface`` configuration option (where ```` is the interface name) is set, its value is used as the default. If this implementation is not compatible with the node's hardware type, an error is returned to a user. An explicit value has to be provided for the node's ``_interface`` field in this case. #. Otherwise, the first supported implementation that is enabled by an operator is used as the default. A list of supported implementations is calculated by taking the intersection between the implementations supported by the node's hardware type and implementations enabled by the ``enabled__interfaces`` option (where ```` is the interface name). The calculation preserves the order of items, as provided by the hardware type. If the list of supported implementations is not empty, the first one is used. Otherwise, an error is returned to a user. In this case, an explicit value has to be provided for the ``_interface`` field. See :doc:`enabling-drivers` for more details on configuration. Example ~~~~~~~ Consider the following configuration (shortened for simplicity): .. code-block:: ini [DEFAULT] enabled_hardware_types = ipmi,redfish enabled_console_interfaces = no-console,ipmitool-shellinabox enabled_deploy_interfaces = iscsi,direct enabled_management_interfaces = ipmitool,redfish enabled_power_interfaces = ipmitool,redfish default_deploy_interface = direct A new node is created with the ``ipmi`` driver and no interfaces specified: .. code-block:: console $ export OS_BAREMETAL_API_VERSION=1.31 $ openstack baremetal node create --driver ipmi +--------------+--------------------------------------+ | Property | Value | +--------------+--------------------------------------+ | uuid | dfc6189f-ad83-4261-9bda-b27258eb1987 | | driver_info | {} | | extra | {} | | driver | ipmi | | chassis_uuid | | | properties | {} | | name | None | +--------------+--------------------------------------+ Then the defaults for the interfaces that will be used by the node in this example are calculated as follows: deploy An explicit value of ``direct`` is provided for ``default_deploy_interface``, so it is used. power No default is configured. The ``ipmi`` hardware type supports only ``ipmitool`` power. The intersection between supported power interfaces and values provided in the ``enabled_power_interfaces`` option has only one item: ``ipmitool``. It is used. console No default is configured. The ``ipmi`` hardware type supports the following console interfaces: ``ipmitool-socat``, ``ipmitool-shellinabox`` and ``no-console`` (in this order). Of these three, only two are enabled: ``no-console`` and ``ipmitool-shellinabox`` (order does not matter). The intersection contains ``ipmitool-shellinabox`` and ``no-console``. The first item is used, and it is ``ipmitool-shellinabox``. management Following the same calculation as *power*, the ``ipmitool`` management interface is used. Hardware Inspection ------------------- The Bare Metal service supports hardware inspection that simplifies enrolling nodes - please see :doc:`/admin/inspection` for details. Tenant Networks and Port Groups ------------------------------- See :doc:`/admin/multitenancy` and :doc:`/admin/portgroups`. ironic-10.1.1/doc/source/install/install.rst0000666000175100017510000000054313243617463021031 0ustar zuulzuul00000000000000.. _install: Install and configure the Bare Metal service ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This section describes how to install and configure the Bare Metal service, code-named ironic. Note that installation and configuration vary by distribution. .. toctree:: :maxdepth: 2 install-rdo.rst install-ubuntu.rst install-obs.rst ironic-10.1.1/doc/source/install/enabling-drivers.rst0000666000175100017510000002654213243617463022625 0ustar zuulzuul00000000000000Enabling drivers and hardware types =================================== Introduction ------------ The Bare Metal service delegates actual hardware management to **drivers**. Starting with the Ocata release, two types of drivers are supported: *classic drivers* (for example, ``pxe_ipmitool``, ``agent_ilo``, etc.) and the newer *hardware types* (for example, generic ``redfish`` and ``ipmi`` or vendor-specific ``ilo`` and ``irmc``). Drivers, in turn, consist of *hardware interfaces*: sets of functionality dealing with some aspect of bare metal provisioning in a vendor-specific way. *Classic drivers* have all *hardware interfaces* hardcoded, while *hardware types* only declare which *hardware interfaces* they are compatible with. Please refer to the `driver composition reform specification`_ for technical details behind *hardware types*. .. TODO(dtantsur): write devdocs on the driver composition and stop linking to the specification. From API user's point of view, both *classic drivers* and *hardware types* can be assigned to the ``driver`` field of a node. However, they are configured differently. .. _enable-hardware-types: Enabling hardware types ----------------------- Hardware types are enabled in the configuration file of the **ironic-conductor** service by setting the ``enabled_hardware_types`` configuration option, for example: .. code-block:: ini [DEFAULT] enabled_hardware_types = ipmi,redfish Due to the driver's dynamic nature, they also require configuring enabled hardware interfaces. .. note:: All available hardware types and interfaces are listed in setup.cfg_ file in the source code tree. .. _enable-hardware-interfaces: Enabling hardware interfaces ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There are several types of hardware interfaces: boot manages booting of both the deploy ramdisk and the user instances on the bare metal node. See :doc:`/admin/interfaces/boot` for details. Boot interface implementations are often vendor specific, and can be enabled via the ``enabled_boot_interfaces`` option: .. code-block:: ini [DEFAULT] enabled_hardware_types = ipmi,ilo enabled_boot_interfaces = pxe,ilo-virtual-media Boot interfaces with ``pxe`` in their name require :doc:`configure-pxe`. There are also a few hardware-specific boot interfaces - see :doc:`/admin/drivers` for their required configuration. console manages access to the serial console of a bare metal node. See :doc:`/admin/console` for details. deploy defines how the image gets transferred to the target disk. See :doc:`/admin/interfaces/deploy` for an explanation of the difference between supported deploy interfaces ``direct`` and ``iscsi``. The deploy interfaces can be enabled as follows: .. code-block:: ini [DEFAULT] enabled_hardware_types = ipmi,redfish enabled_deploy_interfaces = iscsi,direct Additionally, * the ``iscsi`` deploy interface requires :doc:`configure-iscsi` * the ``direct`` deploy interface requires the Object Storage service or an HTTP service inspect implements fetching hardware information from nodes. Can be implemented out-of-band (via contacting the node's BMC) or in-band (via booting a ramdisk on a node). The latter implementation is called ``inspector`` and uses a separate service called ironic-inspector_. Example: .. code-block:: ini [DEFAULT] enabled_hardware_types = ipmi,ilo,irmc enabled_inspect_interfaces = ilo,irmc,inspector See :doc:`/admin/inspection` for more details. management provides additional hardware management actions, like getting or setting boot devices. This interface is usually vendor-specific, and its name often matches the name of the hardware type (with ``ipmitool`` being a notable exception). For example: .. code-block:: ini [DEFAULT] enabled_hardware_types = ipmi,redfish,ilo,irmc enabled_management_interfaces = ipmitool,redfish,ilo,irmc Using ``ipmitool`` requires :doc:`configure-ipmi`. See :doc:`/admin/drivers` for the required configuration of each driver. network connects/disconnects bare metal nodes to/from virtual networks. This is the only interface that is also pluggable for classic drivers. See :doc:`configure-tenant-networks` for more details. power runs power actions on nodes. Similar to the management interface, it is usually vendor-specific, and its name often matches the name of the hardware type (with ``ipmitool`` being again an exception). For example: .. code-block:: ini [DEFAULT] enabled_hardware_types = ipmi,redfish,ilo,irmc enabled_power_interfaces = ipmitool,redfish,ilo,irmc Using ``ipmitool`` requires :doc:`configure-ipmi`. See :doc:`/admin/drivers` for the required configuration of each driver. raid manages building and tearing down RAID on nodes. Similar to inspection, it can be implemented either out-of-band or in-band (via ``agent`` implementation). See :doc:`/admin/raid` for details. For example: .. code-block:: ini [DEFAULT] enabled_hardware_types = ipmi,redfish,ilo,irmc enabled_raid_interfaces = agent,no-raid storage manages the interaction with a remote storage subsystem, such as the Block Storage service, and helps facilitate booting from a remote volume. This interface ensures that volume target and connector information is updated during the lifetime of a deployed instance. See :doc:`/admin/boot-from-volume` for more details. This interface defaults to a ``noop`` driver as it is considered an "opt-in" interface which requires additional configuration by the operator to be usable. For example: .. code-block:: ini [DEFAULT] enabled_hardware_types = ipmi,irmc enabled_storage_interfaces = cinder,noop vendor is a place for vendor extensions to be exposed in API. See :doc:`/contributor/vendor-passthru` for details. .. code-block:: ini [DEFAULT] enabled_hardware_types = ipmi,redfish,ilo,irmc enabled_vendor_interfaces = ipmitool,no-vendor Here is a complete configuration example, enabling two generic protocols, IPMI and Redfish, with a few additional features: .. code-block:: ini [DEFAULT] enabled_hardware_types = ipmi,redfish enabled_boot_interfaces = pxe enabled_console_interfaces = ipmitool-socat,no-console enabled_deploy_interfaces = iscsi,direct enabled_inspect_interfaces = inspector enabled_management_interfaces = ipmitool,redfish enabled_network_interfaces = flat,neutron enabled_power_interfaces = ipmitool,redfish enabled_raid_interfaces = agent enabled_storage_interfaces = cinder,noop enabled_vendor_interfaces = ipmitool,no-vendor Note that some interfaces have implementations named ``no-`` where ```` is the interface type. These implementations do nothing and return errors when used from API. Hardware interfaces in multi-conductor environments ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When enabling hardware types and their interfaces, make sure that for every enabled hardware type, the whole set of enabled interfaces matches for all conductors. However, different conductors can have different hardware types enabled. For example, you can have two conductors with the following configuration respectively: .. code-block:: ini [DEFAULT] enabled_hardware_types = ipmi enabled_deploy_interfaces = direct enabled_power_interfaces = ipmitool enabled_management_interfaces = ipmitool .. code-block:: ini [DEFAULT] enabled_hardware_types = redfish enabled_deploy_interfaces = iscsi enabled_power_interfaces = redfish enabled_management_interfaces = redfish But you cannot have two conductors with the following configuration respectively: .. code-block:: ini [DEFAULT] enabled_hardware_types = ipmi,redfish enabled_deploy_interfaces = direct enabled_power_interfaces = ipmitool,redfish enabled_management_interfaces = ipmitool,redfish .. code-block:: ini [DEFAULT] enabled_hardware_types = redfish enabled_deploy_interfaces = iscsi enabled_power_interfaces = redfish enabled_management_interfaces = redfish This is because the ``redfish`` hardware type will have different enabled *deploy* interfaces on these conductors. It would have been fine, if the second conductor had ``enabled_deploy_interfaces = direct`` instead of ``iscsi``. This situation is not detected by the Bare Metal service, but it can cause inconsistent behavior in the API, when node functionality will depend on which conductor it gets assigned to. .. note:: We don't treat this as an error, because such *temporary* inconsistency is inevitable during a rolling upgrade or a configuration update. Configuring interface defaults ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When an operator does not provide an explicit value for one of the interfaces (when creating a node or updating its driver), the default value is calculated as described in :ref:`hardware_interfaces_defaults`. It is also possible to override the defaults for any interfaces by setting one of the options named ``default__interface``, where ```` is the interface name. For example: .. code-block:: ini [DEFAULT] default_deploy_interface = direct default_network_interface = neutron This configuration forces the default *deploy* interface to be ``direct`` and the default *network* interface to be ``neutron`` for all hardware types. The defaults are calculated and set on a node when creating it or updating its hardware type. Thus, changing these configuration options has no effect on existing nodes. .. warning:: The default interface implementation must be configured the same way across all conductors in the cloud, except maybe for a short period of time during an upgrade or configuration update. Otherwise the default implementation will depend on which conductor handles which node, and this mapping is not predictable or even persistent. .. warning:: These options should be used with care. If a hardware type does not support the provided default implementation, its users will have to always provide an explicit value for this interface when creating a node. Enabling classic drivers ------------------------ Classic drivers are enabled in the configuration file of the **ironic-conductor** service by setting the ``enabled_drivers`` configuration option, for example: .. code-block:: ini [DEFAULT] enabled_drivers = pxe_ipmitool,pxe_ilo,pxe_drac The names in this comma-separated list are entry point names of the drivers. They have to be available at conductor start-up, and all dependencies must be installed locally. For example, * drivers starting with ``pxe`` and some drivers starting with ``agent`` require :doc:`configure-pxe`, * drivers starting with ``pxe`` or having ``iscsi`` in their name require :doc:`configure-iscsi`, * drivers ending with ``ipmitool`` require :doc:`configure-ipmi`. See :doc:`/admin/drivers` for the required configuration of each driver. .. _driver composition reform specification: https://specs.openstack.org/openstack/ironic-specs/specs/approved/driver-composition-reform.html .. _setup.cfg: https://git.openstack.org/cgit/openstack/ironic/tree/setup.cfg .. _ironic-inspector: https://docs.openstack.org/ironic-inspector/latest/ ironic-10.1.1/doc/source/install/configure-pxe.rst0000666000175100017510000003233013243617463022135 0ustar zuulzuul00000000000000Configuring PXE and iPXE ======================== PXE setup --------- If you will be using PXE, it needs to be set up on the Bare Metal service node(s) where ``ironic-conductor`` is running. #. Make sure the tftp root directory exist and can be written to by the user the ``ironic-conductor`` is running as. For example:: sudo mkdir -p /tftpboot sudo chown -R ironic /tftpboot #. Install tftp server and the syslinux package with the PXE boot images: Ubuntu (Up to and including 14.04):: sudo apt-get install xinetd tftpd-hpa syslinux-common syslinux Ubuntu (14.10 and after):: sudo apt-get install xinetd tftpd-hpa syslinux-common pxelinux Fedora 21/RHEL7/CentOS7:: sudo yum install tftp-server syslinux-tftpboot xinetd Fedora 22 or higher:: sudo dnf install tftp-server syslinux-tftpboot xinetd SUSE:: sudo zypper install tftp syslinux xinetd #. Using xinetd to provide a tftp server setup to serve ``/tftpboot``. Create or edit ``/etc/xinetd.d/tftp`` as below:: service tftp { protocol = udp port = 69 socket_type = dgram wait = yes user = root server = /usr/sbin/in.tftpd server_args = -v -v -v -v -v --map-file /tftpboot/map-file /tftpboot disable = no # This is a workaround for Fedora, where TFTP will listen only on # IPv6 endpoint, if IPv4 flag is not used. flags = IPv4 } and restart the ``xinetd`` service: Ubuntu:: sudo service xinetd restart Fedora/RHEL7/CentOS7/SUSE:: sudo systemctl restart xinetd #. Copy the PXE image to ``/tftpboot``. The PXE image might be found at [1]_: Ubuntu (Up to and including 14.04):: sudo cp /usr/lib/syslinux/pxelinux.0 /tftpboot Ubuntu (14.10 and after):: sudo cp /usr/lib/PXELINUX/pxelinux.0 /tftpboot RHEL7/CentOS7/SUSE:: sudo cp /usr/share/syslinux/pxelinux.0 /tftpboot #. If whole disk images need to be deployed via PXE-netboot, copy the chain.c32 image to ``/tftpboot`` to support it: Ubuntu (Up to and including 14.04):: sudo cp /usr/lib/syslinux/chain.c32 /tftpboot Ubuntu (14.10 and after):: sudo cp /usr/lib/syslinux/modules/bios/chain.c32 /tftpboot Fedora:: sudo cp /boot/extlinux/chain.c32 /tftpboot RHEL7/CentOS7/SUSE:: sudo cp /usr/share/syslinux/chain.c32 /tftpboot/ #. If the version of syslinux is **greater than** 4 we also need to make sure that we copy the library modules into the ``/tftpboot`` directory [2]_ [1]_. For example, for Ubuntu run:: sudo cp /usr/lib/syslinux/modules/*/ldlinux.* /tftpboot #. Create a map file in the tftp boot directory (``/tftpboot``):: echo 're ^(/tftpboot/) /tftpboot/\2' > /tftpboot/map-file echo 're ^/tftpboot/ /tftpboot/' >> /tftpboot/map-file echo 're ^(^/) /tftpboot/\1' >> /tftpboot/map-file echo 're ^([^/]) /tftpboot/\1' >> /tftpboot/map-file .. [1] On **Fedora/RHEL** the ``syslinux-tftpboot`` package already install the library modules and PXE image at ``/tftpboot``. If the TFTP server is configured to listen to a different directory you should copy the contents of ``/tftpboot`` to the configured directory .. [2] http://www.syslinux.org/wiki/index.php/Library_modules PXE UEFI setup -------------- If you want to deploy on a UEFI supported bare metal, perform these additional steps on the ironic conductor node to configure the PXE UEFI environment. #. Install Grub2 and shim packages: Ubuntu (14.04LTS and later):: sudo apt-get install grub-efi-amd64-signed shim-signed Fedora 21/RHEL7/CentOS7:: sudo yum install grub2-efi shim Fedora 22 or higher:: sudo dnf install grub2-efi shim SUSE:: sudo zypper install grub2-x86_64-efi shim #. Copy grub and shim boot loader images to ``/tftpboot`` directory: Ubuntu (14.04LTS and later):: sudo cp /usr/lib/shim/shim.efi.signed /tftpboot/bootx64.efi sudo cp /usr/lib/grub/x86_64-efi-signed/grubnetx64.efi.signed /tftpboot/grubx64.efi Fedora: (21 and later):: sudo cp /boot/efi/EFI/fedora/shim.efi /tftpboot/bootx64.efi sudo cp /boot/efi/EFI/fedora/grubx64.efi /tftpboot/grubx64.efi RHEL7/CentOS7:: sudo cp /boot/efi/EFI/centos/shim.efi /tftpboot/bootx64.efi sudo cp /boot/efi/EFI/centos/grubx64.efi /tftpboot/grubx64.efi SUSE:: sudo cp /usr/lib64/efi/shim.efi /tftpboot/bootx64.efi sudo cp /usr/lib/grub2/x86_64-efi/grub.efi /tftpboot/grubx64.efi #. Create master grub.cfg: Ubuntu: Create grub.cfg under ``/tftpboot/grub`` directory:: GRUB_DIR=/tftpboot/grub Fedora: Create grub.cfg under ``/tftpboot/EFI/fedora`` directory:: GRUB_DIR=/tftpboot/EFI/fedora RHEL7/CentOS7: Create grub.cfg under ``/tftpboot/EFI/centos`` directory:: GRUB_DIR=/tftpboot/EFI/centos SUSE: Create grub.cfg under ``/tftpboot/boot/grub`` directory:: GRUB_DIR=/tftpboot/boot/grub Create directory ``GRUB_DIR``:: sudo mkdir -p $GRUB_DIR This file is used to redirect grub to baremetal node specific config file. It redirects it to specific grub config file based on DHCP IP assigned to baremetal node. .. literalinclude:: ../../../ironic/drivers/modules/master_grub_cfg.txt Change the permission of grub.cfg:: sudo chmod 644 $GRUB_DIR/grub.cfg #. Update the bare metal node with ``boot_mode`` capability in node's properties field:: openstack baremetal node set --property capabilities='boot_mode:uefi' #. Make sure that bare metal node is configured to boot in UEFI boot mode and boot device is set to network/pxe. .. note:: Some drivers, e.g. ``ilo`` and ``irmc``, support automatic setting of the boot mode during deployment. This step is not required for them. Please check :doc:`../admin/drivers` for information on whether your driver requires manual UEFI configuration. .. note:: For more information on configuring boot modes, see :ref:`boot_mode_support`. iPXE setup ---------- If you will be using iPXE to boot instead of PXE, iPXE needs to be set up on the Bare Metal service node(s) where ``ironic-conductor`` is running. #. Make sure these directories exist and can be written to by the user the ``ironic-conductor`` is running as. For example:: sudo mkdir -p /tftpboot sudo mkdir -p /httpboot sudo chown -R ironic /tftpboot sudo chown -R ironic /httpboot #. Create a map file in the tftp boot directory (``/tftpboot``):: echo 'r ^([^/]) /tftpboot/\1' > /tftpboot/map-file echo 'r ^(/tftpboot/) /tftpboot/\2' >> /tftpboot/map-file .. _HTTP server: #. Set up TFTP and HTTP servers. These servers should be running and configured to use the local /tftpboot and /httpboot directories respectively, as their root directories. (Setting up these servers is outside the scope of this install guide.) These root directories need to be mounted locally to the ``ironic-conductor`` services, so that the services can access them. The Bare Metal service's configuration file (/etc/ironic/ironic.conf) should be edited accordingly to specify the TFTP and HTTP root directories and server addresses. For example: .. code-block:: ini [pxe] # Ironic compute node's tftp root path. (string value) tftp_root=/tftpboot # IP address of Ironic compute node's tftp server. (string # value) tftp_server=192.168.0.2 [deploy] # Ironic compute node's http root path. (string value) http_root=/httpboot # Ironic compute node's HTTP server URL. Example: # http://192.1.2.3:8080 (string value) http_url=http://192.168.0.2:8080 #. Install the iPXE package with the boot images: Ubuntu:: apt-get install ipxe Fedora 21/RHEL7/CentOS7:: yum install ipxe-bootimgs Fedora 22 or higher:: dnf install ipxe-bootimgs .. note:: SUSE does not provide a package containing iPXE boot images. If you are using SUSE or if the packaged version of the iPXE boot image doesn't work, you can download a prebuilt one from http://boot.ipxe.org or build one image from source, see http://ipxe.org/download for more information. #. Copy the iPXE boot image (``undionly.kpxe`` for **BIOS** and ``ipxe.efi`` for **UEFI**) to ``/tftpboot``. The binary might be found at: Ubuntu:: cp /usr/lib/ipxe/{undionly.kpxe,ipxe.efi} /tftpboot Fedora/RHEL7/CentOS7:: cp /usr/share/ipxe/{undionly.kpxe,ipxe.efi} /tftpboot #. Enable/Configure iPXE in the Bare Metal Service's configuration file (/etc/ironic/ironic.conf): .. code-block:: ini [pxe] # Enable iPXE boot. (boolean value) ipxe_enabled=True # Neutron bootfile DHCP parameter. (string value) pxe_bootfile_name=undionly.kpxe # Bootfile DHCP parameter for UEFI boot mode. (string value) uefi_pxe_bootfile_name=ipxe.efi # Template file for PXE configuration. (string value) pxe_config_template=$pybasedir/drivers/modules/ipxe_config.template # Template file for PXE configuration for UEFI boot loader. # (string value) uefi_pxe_config_template=$pybasedir/drivers/modules/ipxe_config.template #. It is possible to configure the Bare Metal service in such a way that nodes will boot into the deploy image directly from Object Storage. Doing this avoids having to cache the images on the ironic-conductor host and serving them via the ironic-conductor's `HTTP server`_. This can be done if: #. the Image Service is used for image storage; #. the images in the Image Service are internally stored in Object Storage; #. the Object Storage supports generating temporary URLs for accessing objects stored in it. Both the OpenStack Swift and RADOS Gateway provide support for this. * See :doc:`/admin/radosgw` on how to configure the Bare Metal Service with RADOS Gateway as the Object Storage. Configure this by setting the ``[pxe]/ipxe_use_swift`` configuration option to ``True`` as follows: .. code-block:: ini [pxe] # Download deploy images directly from swift using temporary # URLs. If set to false (default), images are downloaded to # the ironic-conductor node and served over its local HTTP # server. Applicable only when 'ipxe_enabled' option is set to # true. (boolean value) ipxe_use_swift=True Although the `HTTP server`_ still has to be deployed and configured (as it will serve iPXE boot script and boot configuration files for nodes), such configuration will shift some load from ironic-conductor hosts to the Object Storage service which can be scaled horizontally. Note that when SSL is enabled on the Object Storage service you have to ensure that iPXE firmware on the nodes can indeed boot from generated temporary URLs that use HTTPS protocol. #. Restart the ``ironic-conductor`` process: Fedora/RHEL7/CentOS7/SUSE:: sudo systemctl restart openstack-ironic-conductor Ubuntu:: sudo service ironic-conductor restart PXE multi-architecture setup ---------------------------- It is possible to deploy servers of different architecture by one conductor. To use this feature, architecture-specific boot and template files must be configured using the configuration options ``[pxe]pxe_bootfile_name_by_arch`` and ``[pxe]pxe_config_template_by_arch`` respectively, in the Bare Metal service's configuration file (/etc/ironic/ironic.conf). These two options are dictionary values; the key is the architecture and the value is the boot (or config template) file. A node's ``cpu_arch`` property is used as the key to get the appropriate boot file and template file. If the node's ``cpu_arch`` is not in the dictionary, the configuration options (in [pxe] group) ``pxe_bootfile_name``, ``pxe_config_template``, ``uefi_pxe_bootfile_name`` and ``uefi_pxe_config_template`` will be used instead. In the following example, since 'x86' and 'x86_64' keys are not in the ``pxe_bootfile_name_by_arch`` or ``pxe_config_template_by_arch`` options, x86 and x86_64 nodes will be deployed by 'pxelinux.0' or 'bootx64.efi', depending on the node's ``boot_mode`` capability ('bios' or 'uefi'). However, aarch64 nodes will be deployed by 'grubaa64.efi', and ppc64 nodes by 'bootppc64':: [pxe] # Bootfile DHCP parameter. (string value) pxe_bootfile_name=pxelinux.0 # On ironic-conductor node, template file for PXE # configuration. (string value) pxe_config_template = $pybasedir/drivers/modules/pxe_config.template # Bootfile DHCP parameter for UEFI boot mode. (string value) uefi_pxe_bootfile_name=bootx64.efi # On ironic-conductor node, template file for PXE # configuration for UEFI boot loader. (string value) uefi_pxe_config_template=$pybasedir/drivers/modules/pxe_grub_config.template # Bootfile DHCP parameter per node architecture. (dict value) pxe_bootfile_name_by_arch=aarch64:grubaa64.efi,ppc64:bootppc64 # On ironic-conductor node, template file for PXE # configuration per node architecture. For example: # aarch64:/opt/share/grubaa64_pxe_config.template (dict value) pxe_config_template_by_arch=aarch64:pxe_grubaa64_config.template,ppc64:pxe_ppc64_config.template ironic-10.1.1/doc/source/install/include/0000775000175100017510000000000013243617733020250 5ustar zuulzuul00000000000000ironic-10.1.1/doc/source/install/include/common-prerequisites.inc0000666000175100017510000000220213243617463025133 0ustar zuulzuul00000000000000Install and configure prerequisites ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Bare Metal service is a collection of components that provides support to manage and provision physical machines. You can configure these components to run on separate nodes or the same node. In this guide, the components run on one node, typically the Compute Service's compute node. It assumes that the Identity, Image, Compute, and Networking services have already been set up. Set up the database for Bare Metal ---------------------------------- The Bare Metal service stores information in a database. This guide uses the MySQL database that is used by other OpenStack services. #. In MySQL, create an ``ironic`` database that is accessible by the ``ironic`` user. Replace ``IRONIC_DBPASSWORD`` with a suitable password: .. code-block:: console # mysql -u root -p mysql> CREATE DATABASE ironic CHARACTER SET utf8; mysql> GRANT ALL PRIVILEGES ON ironic.* TO 'ironic'@'localhost' \ IDENTIFIED BY 'IRONIC_DBPASSWORD'; mysql> GRANT ALL PRIVILEGES ON ironic.* TO 'ironic'@'%' \ IDENTIFIED BY 'IRONIC_DBPASSWORD'; ironic-10.1.1/doc/source/install/include/configure-ironic-conductor.inc0000666000175100017510000001467113243617463026216 0ustar zuulzuul00000000000000Configuring ironic-conductor service ------------------------------------ #. Replace ``HOST_IP`` with IP of the conductor host. .. code-block:: ini [DEFAULT] # IP address of this host. If unset, will determine the IP # programmatically. If unable to do so, will use "127.0.0.1". # (string value) my_ip=HOST_IP .. note:: If a conductor host has multiple IPs, ``my_ip`` should be set to the IP which is on the same network as the bare metal nodes. #. Configure the location of the database. Ironic-conductor should use the same configuration as ironic-api. Replace ``IRONIC_DBPASSWORD`` with the password of your ``ironic`` user, and replace DB_IP with the IP address where the DB server is located: .. code-block:: ini [database] # The SQLAlchemy connection string to use to connect to the # database. (string value) connection=mysql+pymysql://ironic:IRONIC_DBPASSWORD@DB_IP/ironic?charset=utf8 #. Configure the ironic-conductor service to use the RabbitMQ message broker by setting the following option. Ironic-conductor should use the same configuration as ironic-api. Replace ``RPC_*`` with appropriate address details and credentials of RabbitMQ server: .. code-block:: ini [DEFAULT] # A URL representing the messaging driver to use and its full # configuration. (string value) transport_url = rabbit://RPC_USER:RPC_PASSWORD@RPC_HOST:RPC_PORT/ #. Configure credentials for accessing other OpenStack services. In order to communicate with other OpenStack services, the Bare Metal service needs to use service users to authenticate to the OpenStack Identity service when making requests to other services. These users' credentials have to be configured in each configuration file section related to the corresponding service: * ``[neutron]`` - to access the OpenStack Networking service * ``[glance]`` - to access the OpenStack Image service * ``[swift]`` - to access the OpenStack Object Storage service * ``[inspector]`` - to access the OpenStack Bare Metal Introspection service * ``[service_catalog]`` - a special section holding credentials the Bare Metal service will use to discover its own API URL endpoint as registered in the OpenStack Identity service catalog. For simplicity, you can use the same service user for all services. For backward compatibility, this should be the same user configured in the ``[keystone_authtoken]`` section for the ironic-api service (see "Configuring ironic-api service"). However, this is not necessary, and you can create and configure separate service users for each service. Under the hood, Bare Metal service uses ``keystoneauth`` library together with ``Authentication plugin``, ``Session`` and ``Adapter`` concepts provided by it to instantiate service clients. Please refer to `Keystoneauth documentation`_ for supported plugins, their available options as well as Session- and Adapter-related options for authentication, connection and endpoint discovery respectively. In the example below, authentication information for user to access the OpenStack Networking service is configured to use: * Networking service is deployed in the Identity service region named ``RegionTwo``, with only its ``public`` endpoint interface registered in the service catalog. * HTTPS connection with specific CA SSL certificate when making requests * the same service user as configured for ironic-api service * dynamic ``password`` authentication plugin that will discover appropriate version of Identity service API based on other provided options - replace ``IDENTITY_IP`` with the IP of the Identity server, and replace ``IRONIC_PASSWORD`` with the password you chose for the ``ironic`` user in the Identity service .. code-block:: ini [neutron] # Authentication type to load (string value) auth_type = password # Authentication URL (string value) auth_url=https://IDENTITY_IP:5000/ # Username (string value) username=ironic # User's password (string value) password=IRONIC_PASSWORD # Project name to scope to (string value) project_name=service # Domain ID containing project (string value) project_domain_id=default # User's domain id (string value) user_domain_id=default # PEM encoded Certificate Authority to use when verifying # HTTPs connections. (string value) cafile=/opt/stack/data/ca-bundle.pem # The default region_name for endpoint URL discovery. (string # value) region_name = RegionTwo # List of interfaces, in order of preference, for endpoint # URL. (list value) valid_interfaces=public By default, in order to communicate with another service, the Bare Metal service will attempt to discover an appropriate endpoint for that service via the Identity service's service catalog. The relevant configuration options from that service group in the Bare Metal service configuration file are used for this purpose. If you want to use a different endpoint for a particular service, specify this via the ``endpoint_override`` configuration option of that service group, in the Bare Metal service's configuration file. Taking the previous Networking service example, this would be .. code-block:: ini [neutron] ... endpoint_override = (Replace `` with actual address of a specific Networking service endpoint.) #. Configure enabled drivers and hardware types as described in :doc:`/install/enabling-drivers`. A. If you enabled any driver that uses :ref:`direct-deploy`, Swift backend for the Image service must be installed and configured, see :ref:`image-store`. Ceph Object Gateway (RADOS Gateway) is also supported as the Image service's backend, see :ref:`radosgw support`. #. Configure the network for ironic-conductor service to perform node cleaning, see :ref:`cleaning` from the admin guide. #. Restart the ironic-conductor service: .. TODO(mmitchell): Split this based on operating system .. code-block:: console Fedora/RHEL7/CentOS7/SUSE: sudo systemctl restart openstack-ironic-conductor Ubuntu: sudo service ironic-conductor restart .. _Keystoneauth documentation: https://docs.openstack.org/keystoneauth/latest/ ironic-10.1.1/doc/source/install/include/console.inc0000666000175100017510000000021413243617463022404 0ustar zuulzuul00000000000000Configuring node web console ---------------------------- See :ref:`console`. .. TODO(dtantsur): move the installation documentation here ironic-10.1.1/doc/source/install/include/trusted-boot.inc0000666000175100017510000000554413243617463023410 0ustar zuulzuul00000000000000.. _trusted-boot: Trusted boot with partition image --------------------------------- The Bare metal service supports trusted boot with partition images. This means at the end of the deployment process, when the node is rebooted with the new user image, ``trusted boot`` will be performed. It will measure the node's BIOS, boot loader, Option ROM and the Kernel/Ramdisk, to determine whether a bare metal node deployed by Ironic should be trusted. It's important to note that in order for this to work the node being deployed **must** have Intel `TXT`_ hardware support. The image being deployed with Ironic must have ``oat-client`` installed within it. The following will describe how to enable ``trusted boot`` and boot with PXE and Nova: #. Create a customized user image with ``oat-client`` installed:: disk-image-create -u fedora baremetal oat-client -o $TRUST_IMG For more information on creating customized images, see :ref:`image-requirements`. #. Enable VT-x, VT-d, TXT and TPM on the node. This can be done manually through the BIOS. Depending on the platform, several reboots may be needed. #. Enroll the node and update the node capability value:: openstack baremetal node create --driver ipmi openstack baremetal node set $NODE_UUID --property capabilities={'trusted_boot':true} #. Create a special flavor:: nova flavor-key $TRUST_FLAVOR_UUID set 'capabilities:trusted_boot'=true #. Prepare `tboot`_ and mboot.c32 and put them into tftp_root or http_root directory on all nodes with the ironic-conductor processes:: Ubuntu: cp /usr/lib/syslinux/mboot.c32 /tftpboot/ Fedora: cp /usr/share/syslinux/mboot.c32 /tftpboot/ *Note: The actual location of mboot.c32 varies among different distribution versions.* tboot can be downloaded from https://sourceforge.net/projects/tboot/files/latest/download #. Install an OAT Server. An `OAT Server`_ should be running and configured correctly. #. Boot an instance with Nova:: nova boot --flavor $TRUST_FLAVOR_UUID --image $TRUST_IMG --user-data $TRUST_SCRIPT trusted_instance *Note* that the node will be measured during ``trusted boot`` and the hash values saved into `TPM`_. An example of TRUST_SCRIPT can be found in `trust script example`_. #. Verify the result via OAT Server. This is outside the scope of Ironic. At the moment, users can manually verify the result by following the `manual verify steps`_. .. _`TXT`: http://en.wikipedia.org/wiki/Trusted_Execution_Technology .. _`tboot`: https://sourceforge.net/projects/tboot .. _`TPM`: http://en.wikipedia.org/wiki/Trusted_Platform_Module .. _`OAT Server`: https://github.com/OpenAttestation/OpenAttestation/wiki .. _`trust script example`: https://wiki.openstack.org/wiki/Bare-metal-trust#Trust_Script_Example .. _`manual verify steps`: https://wiki.openstack.org/wiki/Bare-metal-trust#Manual_verify_result ironic-10.1.1/doc/source/install/include/root-device-hints.inc0000666000175100017510000000702513243617463024314 0ustar zuulzuul00000000000000.. _root-device-hints: Specifying the disk for deployment (root device hints) ------------------------------------------------------ The Bare Metal service supports passing hints to the deploy ramdisk about which disk it should pick for the deployment. The list of supported hints is: * model (STRING): device identifier * vendor (STRING): device vendor * serial (STRING): disk serial number * size (INT): size of the device in GiB .. note:: A node's 'local_gb' property is often set to a value 1 GiB less than the actual disk size to account for partitioning (this is how DevStack, TripleO and Ironic Inspector work, to name a few). However, in this case ``size`` should be the actual size. For example, for a 128 GiB disk ``local_gb`` will be 127, but size hint will be 128. * wwn (STRING): unique storage identifier * wwn_with_extension (STRING): unique storage identifier with the vendor extension appended * wwn_vendor_extension (STRING): unique vendor storage identifier * rotational (BOOLEAN): whether it's a rotational device or not. This hint makes it easier to distinguish HDDs (rotational) and SSDs (not rotational) when choosing which disk Ironic should deploy the image onto. * hctl (STRING): the SCSI address (Host, Channel, Target and Lun), e.g '1:0:0:0' * name (STRING): the device name, e.g /dev/md0 .. warning:: The root device hint name should only be used for devices with constant names (e.g RAID volumes). For SATA, SCSI and IDE disk controllers this hint is not recommended because the order in which the device nodes are added in Linux is arbitrary, resulting in devices like /dev/sda and /dev/sdb `switching around at boot time `_. To associate one or more hints with a node, update the node's properties with a ``root_device`` key, for example:: openstack baremetal node set --property root_device='{"wwn": "0x4000cca77fc4dba1"}' That will guarantee that Bare Metal service will pick the disk device that has the ``wwn`` equal to the specified wwn value, or fail the deployment if it can not be found. The hints can have an operator at the beginning of the value string. If no operator is specified the default is ``==`` (for numerical values) and ``s==`` (for string values). The supported operators are: * For numerical values: * ``=`` equal to or greater than. This is equivalent to ``>=`` and is supported for `legacy reasons `_ * ``==`` equal to * ``!=`` not equal to * ``>=`` greater than or equal to * ``>`` greater than * ``<=`` less than or equal to * ``<`` less than * For strings (as python comparisons): * ``s==`` equal to * ``s!=`` not equal to * ``s>=`` greater than or equal to * ``s>`` greater than * ``s<=`` less than or equal to * ``s<`` less than * ```` substring * For collections: * ```` all elements contained in collection * ```` find one of these Examples are: * Finding a disk larger or equal to 60 GiB and non-rotational (SSD):: openstack baremetal node set --property root_device='{"size": ">= 60", "rotational": false}' * Finding a disk whose vendor is ``samsung`` or ``winsys``:: openstack baremetal node set --property root_device='{"vendor": " samsung winsys"}' .. note:: If multiple hints are specified, a device must satisfy all the hints. ironic-10.1.1/doc/source/install/include/configure-ironic-api.inc0000666000175100017510000000545013243617463024762 0ustar zuulzuul00000000000000Configuring ironic-api service ------------------------------ #. The Bare Metal service stores information in a database. This guide uses the MySQL database that is used by other OpenStack services. Configure the location of the database via the ``connection`` option. In the following, replace ``IRONIC_DBPASSWORD`` with the password of your ``ironic`` user, and replace ``DB_IP`` with the IP address where the DB server is located: .. code-block:: ini [database] # The SQLAlchemy connection string used to connect to the # database (string value) connection=mysql+pymysql://ironic:IRONIC_DBPASSWORD@DB_IP/ironic?charset=utf8 #. Configure the ironic-api service to use the RabbitMQ message broker by setting the following option. Replace ``RPC_*`` with appropriate address details and credentials of RabbitMQ server: .. code-block:: ini [DEFAULT] # A URL representing the messaging driver to use and its full # configuration. (string value) transport_url = rabbit://RPC_USER:RPC_PASSWORD@RPC_HOST:RPC_PORT/ #. Configure the ironic-api service to use these credentials with the Identity service. Replace ``PUBLIC_IDENTITY_IP`` with the public IP of the Identity server, ``PRIVATE_IDENTITY_IP`` with the private IP of the Identity server and replace ``IRONIC_PASSWORD`` with the password you chose for the ``ironic`` user in the Identity service: .. code-block:: ini [DEFAULT] # Authentication strategy used by ironic-api: one of # "keystone" or "noauth". "noauth" should not be used in a # production environment because all authentication will be # disabled. (string value) auth_strategy=keystone [keystone_authtoken] # Authentication type to load (string value) auth_type=password # Complete public Identity API endpoint (string value) auth_uri=http://PUBLIC_IDENTITY_IP:5000 # Complete admin Identity API endpoint. (string value) auth_url=http://PRIVATE_IDENTITY_IP:35357 # Service username. (string value) username=ironic # Service account password. (string value) password=IRONIC_PASSWORD # Service tenant name. (string value) project_name=service # Domain name containing project (string value) project_domain_name=Default # User's domain name (string value) user_domain_name=Default #. Create the Bare Metal service database tables: .. code-block:: bash $ ironic-dbsync --config-file /etc/ironic/ironic.conf create_schema #. Restart the ironic-api service: .. TODO(mmitchell): Split this based on operating system .. code-block:: console Fedora/RHEL7/CentOS7/SUSE: sudo systemctl restart openstack-ironic-api Ubuntu: sudo service ironic-api restart ironic-10.1.1/doc/source/install/include/kernel-boot-parameters.inc0000666000175100017510000000740613243617463025336 0ustar zuulzuul00000000000000.. _kernel-boot-parameters: Appending kernel parameters to boot instances --------------------------------------------- The Bare Metal service supports passing custom kernel parameters to boot instances to fit users' requirements. The way to append the kernel parameters is depending on how to boot instances. Network boot ~~~~~~~~~~~~ Currently, the Bare Metal service supports assigning unified kernel parameters to PXE booted instances by: * Modifying the ``[pxe]/pxe_append_params`` configuration option, for example:: [pxe] pxe_append_params = quiet splash * Copying a template from shipped templates to another place, for example:: https://git.openstack.org/cgit/openstack/ironic/tree/ironic/drivers/modules/pxe_config.template Making the modifications and pointing to the custom template via the configuration options: ``[pxe]/pxe_config_template`` and ``[pxe]/uefi_pxe_config_template``. Local boot ~~~~~~~~~~ For local boot instances, users can make use of configuration drive (see :ref:`configdrive`) to pass a custom script to append kernel parameters when creating an instance. This is more flexible and can vary per instance. Here is an example for grub2 with ubuntu, users can customize it to fit their use case: .. code:: python #!/usr/bin/env python import os # Default grub2 config file in Ubuntu grub_file = '/etc/default/grub' # Add parameters here to pass to instance. kernel_parameters = ['quiet', 'splash'] grub_cmd = 'GRUB_CMDLINE_LINUX' old_grub_file = grub_file+'~' os.rename(grub_file, old_grub_file) cmdline_existed = False with open(grub_file, 'w') as writer, \ open(old_grub_file, 'r') as reader: for line in reader: key = line.split('=')[0] if key == grub_cmd: #If there is already some value: if line.strip()[-1] == '"': line = line.strip()[:-1] + ' ' + ' '.join(kernel_parameters) + '"' cmdline_existed = True writer.write(line) if not cmdline_existed: line = grub_cmd + '=' + '"' + ' '.join(kernel_parameters) + '"' writer.write(line) os.remove(old_grub_file) os.system('update-grub') os.system('reboot') Console ~~~~~~~ In order to change default console configuration in the Bare Metal service configuration file (``[pxe]`` section in ``/etc/ironic/ironic.conf``), include the serial port terminal and serial speed. Serial speed must be the same as the serial configuration in the BIOS settings, so that the operating system boot process can be seen in the serial console or web console. Following examples represent possible parameters for serial and web console respectively. * Node serial console. The console parameter ``console=ttyS0,115200n8`` uses ``ttyS0`` for console output at ``115200bps, 8bit, non-parity``, e.g.:: [pxe] # Additional append parameters for baremetal PXE boot. pxe_append_params = nofb nomodeset vga=normal console=ttyS0,115200n8 * For node web console configuration is similar with the addition of ``ttyX`` parameter, see example:: [pxe] # Additional append parameters for baremetal PXE boot. pxe_append_params = nofb nomodeset vga=normal console=tty0 console=ttyS0,115200n8 For detailed information on how to add consoles see the reference documents `kernel params`_ and `serial console`_. In case of local boot the Bare Metal service is not able to control kernel boot parameters. To configure console locally, follow 'Local boot' section above. .. _`kernel params`: https://www.kernel.org/doc/Documentation/kernel-parameters.txt .. _`serial console`: https://www.kernel.org/doc/Documentation/serial-console.txt ironic-10.1.1/doc/source/install/include/notifications.inc0000666000175100017510000000144413243617463023621 0ustar zuulzuul00000000000000Notifications ------------- The Bare Metal service supports the emission of notifications, which are messages sent on a message broker (like RabbitMQ or anything else supported by the `oslo messaging library `_) that indicate various events which occur, such as when a node changes power states. These can be consumed by an external service reading from the message bus. For example, `Searchlight `_ is an OpenStack service that uses notifications to index (and make searchable) resources from the Bare Metal service. Notifications are disabled by default. For a complete list of available notifications and instructions for how to enable them, see the :doc:`/admin/notifications`. ironic-10.1.1/doc/source/install/include/configure-ironic-api-mod_wsgi.inc0000666000175100017510000000413313243617463026565 0ustar zuulzuul00000000000000Configuring ironic-api behind mod_wsgi -------------------------------------- Bare Metal service comes with an example file for configuring the ``ironic-api`` service to run behind Apache with mod_wsgi. #. Install the apache service: .. TODO(mmitchell): Split this based on operating system .. code-block:: console Fedora 21/RHEL7/CentOS7: sudo yum install httpd Fedora 22 (or higher): sudo dnf install httpd Debian/Ubuntu: apt-get install apache2 SUSE: zypper install apache2 #. Copy the ``etc/apache2/ironic`` file under the apache sites: .. TODO(mmitchell): Split this based on operating system .. code-block:: console Fedora/RHEL7/CentOS7: sudo cp etc/apache2/ironic /etc/httpd/conf.d/ironic.conf Debian/Ubuntu: sudo cp etc/apache2/ironic /etc/apache2/sites-available/ironic.conf SUSE sudo cp etc/apache2/ironic /etc/apache2/vhosts.d/ironic.conf #. Edit the recently copied ``/ironic.conf``: #. Modify the ``WSGIDaemonProcess``, ``APACHE_RUN_USER`` and ``APACHE_RUN_GROUP`` directives to set the user and group values to an appropriate user on your server. #. Modify the ``WSGIScriptAlias`` directive to point to the automatically generated ``ironic-api-wsgi`` script that is located in `IRONIC_BIN` directory. #. Modify the ``Directory`` directive to set the path to the Ironic API code. #. Modify the ``ErrorLog`` and ``CustomLog`` to redirect the logs to the right directory (on Red Hat systems this is usually under /var/log/httpd). #. Enable the apache ``ironic`` in site and reload: .. TODO(mmitchell): Split this based on operating system .. code-block:: console Fedora/RHEL7/CentOS7: sudo systemctl reload httpd Debian/Ubuntu: sudo a2ensite ironic sudo service apache2 reload SUSE: sudo systemctl reload apache2 .. note:: The file ``ironic-api-wsgi`` is automatically generated by pbr and is available in `IRONIC_BIN` directory. It should not be modified. ironic-10.1.1/doc/source/install/include/disk-label.inc0000666000175100017510000000477513243617463022771 0ustar zuulzuul00000000000000.. _choosing_the_disk_label: Choosing the disk label ----------------------- .. note:: The term ``disk label`` is historically used in Ironic and was taken from `parted `_. Apparently everyone seems to have a different word for ``disk label`` - these are all the same thing: disk type, partition table, partition map and so on... Ironic allows operators to choose which disk label they want their bare metal node to be deployed with when Ironic is responsible for partitioning the disk; therefore choosing the disk label does not apply when the image being deployed is a ``whole disk image``. There are some edge cases where someone may want to choose a specific disk label for the images being deployed, including but not limited to: * For machines in ``bios`` boot mode with disks larger than 2 terabytes it's recommended to use a ``gpt`` disk label. That's because a capacity beyond 2 terabytes is not addressable by using the MBR partitioning type. But, although GPT claims to be backward compatible with legacy BIOS systems `that's not always the case `_. * Operators may want to force the partitioning to be always MBR (even if the machine is deployed with boot mode ``uefi``) to avoid breakage of applications and tools running on those instances. The disk label can be configured in two ways; when Ironic is used with the Compute service or in standalone mode. The following bullet points and sections will describe both methods: * When no disk label is provided Ironic will configure it according to the boot mode (see :ref:`boot_mode_support`); ``bios`` boot mode will use ``msdos`` and ``uefi`` boot mode will use ``gpt``. * Only one disk label - either ``msdos`` or ``gpt`` - can be configured for the node. When used with Compute service ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When Ironic is used with the Compute service the disk label should be set to node's ``properties/capabilities`` field and also to the flavor which will request such capability, for example:: openstack baremetal node set --property capabilities='disk_label:gpt' As for the flavor:: nova flavor-key baremetal set capabilities:disk_label="gpt" When used in standalone mode ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When used without the Compute service, the disk label should be set directly to the node's ``instance_info`` field, as below:: openstack baremetal node set --instance-info capabilities='{"disk_label": "gpt"}' ironic-10.1.1/doc/source/install/include/local-boot-partition-images.inc0000666000175100017510000000410713243617463026254 0ustar zuulzuul00000000000000.. _local-boot-partition-images: Local boot with partition images -------------------------------- The Bare Metal service supports local boot with partition images, meaning that after the deployment the node's subsequent reboots won't happen via PXE or Virtual Media. Instead, it will boot from a local boot loader installed on the disk. .. note:: Whole disk images, on the contrary, support only local boot, and use it by default. It's important to note that in order for this to work the image being deployed with Bare Metal service **must** contain ``grub2`` installed within it. Enabling the local boot is different when Bare Metal service is used with Compute service and without it. The following sections will describe both methods. .. _ironic-python-agent: https://docs.openstack.org/ironic-python-agent/latest/ Enabling local boot with Compute service ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To enable local boot we need to set a capability on the bare metal node, for example:: openstack baremetal node set --property capabilities="boot_option:local" Nodes having ``boot_option`` set to ``local`` may be requested by adding an ``extra_spec`` to the Compute service flavor, for example:: nova flavor-key baremetal set capabilities:boot_option="local" .. note:: If the node is configured to use ``UEFI``, Bare Metal service will create an ``EFI partition`` on the disk and switch the partition table format to ``gpt``. The ``EFI partition`` will be used later by the boot loader (which is installed from the deploy ramdisk). .. _local-boot-without-compute: Enabling local boot without Compute ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Since adding ``capabilities`` to the node's properties is only used by the nova scheduler to perform more advanced scheduling of instances, we need a way to enable local boot when Compute is not present. To do that we can simply specify the capability via the ``instance_info`` attribute of the node, for example:: openstack baremetal node set --instance-info capabilities='{"boot_option": "local"}' ironic-10.1.1/doc/source/install/include/common-configure.inc0000666000175100017510000000122113243617463024210 0ustar zuulzuul00000000000000The Bare Metal service is configured via its configuration file. This file is typically located at ``/etc/ironic/ironic.conf``. Although some configuration options are mentioned here, it is recommended that you review all the :doc:`/configuration/sample-config` so that the Bare Metal service is configured for your needs. It is possible to set up an ironic-api and an ironic-conductor services on the same host or different hosts. Users also can add new ironic-conductor hosts to deal with an increasing number of bare metal nodes. But the additional ironic-conductor services should be at the same version as that of existing ironic-conductor services. ironic-10.1.1/doc/source/install/include/boot-mode.inc0000666000175100017510000000346313243617463022640 0ustar zuulzuul00000000000000.. _boot_mode_support: Boot mode support ----------------- Most of the bare metal drivers (including the generic ``ipmi`` hardware type) support setting of boot mode (Legacy BIOS or UEFI). The boot modes can be configured in the Bare Metal service in the following way: * When no boot mode setting is provided, these drivers default the boot_mode to Legacy BIOS. * Only one boot mode (either ``uefi`` or ``bios``) can be configured for the node. * If the operator wants a node to boot always in ``uefi`` mode or ``bios`` mode, then they may use ``capabilities`` parameter within ``properties`` field of an bare metal node. The operator must manually set the appropriate boot mode on the bare metal node. To configure a node in ``uefi`` mode, then set ``capabilities`` as below:: openstack baremetal node set --property capabilities='boot_mode:uefi' Nodes having ``boot_mode`` set to ``uefi`` may be requested by adding an ``extra_spec`` to the Compute service flavor:: nova flavor-key ironic-test-3 set capabilities:boot_mode="uefi" nova boot --flavor ironic-test-3 --image test-image instance-1 If ``capabilities`` is used in ``extra_spec`` as above, nova scheduler (``ComputeCapabilitiesFilter``) will match only bare metal nodes which have the ``boot_mode`` set appropriately in ``properties/capabilities``. It will filter out rest of the nodes. The above facility for matching in the Compute service can be used in heterogeneous environments where there is a mix of ``uefi`` and ``bios`` machines, and operator wants to provide a choice to the user regarding boot modes. If the flavor doesn't contain ``boot_mode`` and ``boot_mode`` is configured for bare metal nodes, then nova scheduler will consider all nodes and user may get either ``bios`` or ``uefi`` machine. ironic-10.1.1/doc/source/install/configure-glance-swift.rst0000666000175100017510000000610613243617463023726 0ustar zuulzuul00000000000000.. _image-store: Configure the Image service for temporary URLs ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Some drivers of the Baremetal service (in particular, any drivers using :ref:`direct-deploy` or :ref:`ansible-deploy` interfaces, and some virtual media drivers) require target user images to be available over clean HTTP(S) URL with no authentication involved (neither username/password-based, nor token-based). When using the Baremetal service integrated in OpenStack, this can be achieved by specific configuration of the Image service and Object Storage service as described below. #. Configure the Image service to have object storage as a backend for storing images. For more details, please refer to the Image service configuration guide. .. note:: When using Ceph+RadosGW for Object Storage service, images stored in Image service must be available over Object Storage service as well. #. Enable TempURLs for the Object Storage account used by the Image service for storing images in the Object Storage service. #. Check if TempURLs are enabled: .. code-block:: shell # executed under credentials of the user used by Image service # to access Object Storage service $ openstack object store account show +------------+---------------------------------------+ | Field | Value | +------------+---------------------------------------+ | Account | AUTH_bc39f1d9dcf9486899088007789ae643 | | Bytes | 536661727 | | Containers | 1 | | Objects | 19 | | properties | Temp-Url-Key='secret' | +------------+---------------------------------------+ #. If property ``Temp-Url-Key`` is set, note its value. #. If property ``Temp-Url-Key`` is not set, you have to configure it (``secret`` is used in the example below for the value): .. code-block:: shell $ openstack object store account set --property Temp-Url-Key=secret #. Optionally, configure the ironic-conductor service. The default configuration assumes that: #. the Object Storage service is implemented by swift_, #. the Object Storage service URL is available from the service catalog, #. the project, used by the Image service to access the Object Storage, is the same as the project, used by the Bare Metal service to access it, #. the container, used by the Image service, is called ``glance``. If any of these assumptions do not hold, you may want to change your configuration file (typically located at ``/etc/ironic/ironic.conf``), for example: .. code-block:: ini [glance] temp_url_endpoint_type = swift swift_endpoint_url = http://openstack/swift swift_account = AUTH_bc39f1d9dcf9486899088007789ae643 swift_container = glance swift_temp_url_key = secret #. (Re)start the ironic-conductor service. .. _swift: https://docs.openstack.org/swift/latest/ ironic-10.1.1/doc/source/install/enabling-https.rst0000666000175100017510000000650213243617463022303 0ustar zuulzuul00000000000000.. _enabling-https: Enabling HTTPS -------------- .. _EnableHTTPSinSwift: Enabling HTTPS in Swift ======================= The drivers using virtual media use swift for storing boot images and node configuration information (contains sensitive information for Ironic conductor to provision bare metal hardware). By default, HTTPS is not enabled in swift. HTTPS is required to encrypt all communication between swift and Ironic conductor and swift and bare metal (via virtual media). It can be enabled in one of the following ways: * `Using an SSL termination proxy `_ * `Using native SSL support in swift `_ (recommended only for testing purpose by swift). .. _EnableHTTPSinGlance: Enabling HTTPS in Image service =============================== Ironic drivers usually use Image service during node provisioning. By default, image service does not use HTTPS, but it is required for secure communication. It can be enabled by making the following changes to ``/etc/glance/glance-api.conf``: #. `Configuring SSL support `_ #. Restart the glance-api service:: Fedora/RHEL7/CentOS7/SUSE: sudo systemctl restart openstack-glance-api Debian/Ubuntu: sudo service glance-api restart See the `Glance `_ documentation, for more details on the Image service. Enabling HTTPS communication between Image service and Object storage ===================================================================== This section describes the steps needed to enable secure HTTPS communication between Image service and Object storage when Object storage is used as the Backend. To enable secure HTTPS communication between Image service and Object storage follow these steps: #. :ref:`EnableHTTPSinSwift` #. `Configure Swift Storage Backend `_ #. :ref:`EnableHTTPSinGlance` Enabling HTTPS communication between Image service and Bare Metal service ========================================================================= This section describes the steps needed to enable secure HTTPS communication between Image service and Bare Metal service. To enable secure HTTPS communication between Bare Metal service and Image service follow these steps: #. Edit ``/etc/ironic/ironic.conf``:: [glance] ... glance_cafile=/path/to/certfile .. note:: 'glance_cafile' is a optional path to a CA certificate bundle to be used to validate the SSL certificate served by Image service. #. If not using the keystone service catalog for the Image service API endpoint discovery, also edit the ``endpoint_override`` option to point to HTTPS URL of image service (replace ```` with hostname[:port][path] of the Image service endpoint):: [glance] ... endpoint_override = https:// #. Restart ironic-conductor service:: Fedora/RHEL7/CentOS7/SUSE: sudo systemctl restart openstack-ironic-conductor Debian/Ubuntu: sudo service ironic-conductor restart ironic-10.1.1/doc/source/install/refarch/0000775000175100017510000000000013243617733020237 5ustar zuulzuul00000000000000ironic-10.1.1/doc/source/install/refarch/common.rst0000666000175100017510000003226213243617463022270 0ustar zuulzuul00000000000000Common Considerations ===================== This section covers considerations that are equally important to all described architectures. .. contents:: :local: Components ---------- As explained in :doc:`../get_started`, the Bare Metal service has three components. * The Bare Metal API service (``ironic-api``) should be deployed in a similar way as the control plane API services. The exact location will depend on the architecture used. * The Bare Metal conductor service (``ironic-conductor``) is where most of the provisioning logic lives. The following considerations are the most important when deciding on the way to deploy it: * The conductor manages a certain proportion of nodes, distributed to it via a hash ring. This includes constantly polling these nodes for their current power state and hardware sensor data (if enabled and supported by hardware, see :ref:`ipmi-sensor-data` for an example). * The conductor needs access to the `management controller`_ of each node it manages. * The conductor co-exists with TFTP (for PXE) and/or HTTP (for iPXE) services that provide the kernel and ramdisk to boot the nodes. The conductor manages them by writing files to their root directories. * If serial console is used, the conductor launches console processes locally. If the ``nova-serialproxy`` service (part of the Compute service) is used, it has to be able to reach the conductors. Otherwise, they have to be directly accessible by the users. * There must be mutual connectivity between the conductor and the nodes being deployed or cleaned. See Networking_ for details. * The provisioning ramdisk which runs the ``ironic-python-agent`` service on start up. .. warning:: The ``ironic-python-agent`` service is not intended to be used or executed anywhere other than a provisioning/cleaning ramdisk. Hardware and drivers -------------------- The Bare Metal service strives to provide the best support possible for a variety of hardware. However, not all hardware is supported equally well. It depends on both the capabilities of hardware itself and the available drivers. This section covers various considerations related to the hardware interfaces. See :doc:`/install/enabling-drivers` for a detailed introduction into hardware types and interfaces before proceeding. Power and management interfaces ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The minimum set of capabilities that the hardware has to provide and the driver has to support is as follows: #. getting and setting the power state of the machine #. getting and setting the current boot device #. booting an image provided by the Bare Metal service (in the simplest case, support booting using PXE_ and/or iPXE_) .. note:: Strictly speaking, it is possible to make the Bare Metal service provision nodes without some of these capabilities via some manual steps. It is not the recommended way of deployment, and thus it is not covered in this guide. Once you make sure that the hardware supports these capabilities, you need to find a suitable driver. Most of enterprise-grade hardware has support for IPMI_ and thus can utilize :doc:`/admin/drivers/ipmitool`. Some newer hardware also supports :doc:`/admin/drivers/redfish`. Several vendors provide more specific drivers that usually provide additional capabilities. Check :doc:`/admin/drivers` to find the most suitable one. Boot interface ~~~~~~~~~~~~~~ The boot interface of a node manages booting of both the deploy ramdisk and the user instances on the bare metal node. The deploy interface orchestrates the deployment and defines how the image gets transferred to the target disk. The main alternatives are to use PXE/iPXE or virtual media - see :doc:`/admin/interfaces/boot` for a detailed explanation. If a virtual media implementation is available for the hardware, it is recommended using it for better scalability and security. Otherwise, it is recommended to use iPXE, when it is supported by target hardware. Deploy interface ~~~~~~~~~~~~~~~~ There are two deploy interfaces in-tree, ``iscsi`` and ``direct``. See :doc:`../../admin/interfaces/deploy` for explanation of the difference. With the ``iscsi`` deploy method, most of the deployment operations happen on the conductor. If the Object Storage service (swift) or RadosGW is present in the environment, it is recommended to use the ``direct`` deploy method for better scalability and reliability. .. TODO(dtantsur): say something about the ansible deploy, when it's in Hardware specifications ~~~~~~~~~~~~~~~~~~~~~~~ The Bare Metal services does not impose too many restrictions on the characteristics of hardware itself. However, keep in mind that * By default, the Bare Metal service will pick the smallest hard drive that is larger than 4 GiB for deployment. Another hard drive can be used, but it requires setting :ref:`root device hints `. .. note:: This device does not have to match the boot device set in BIOS (or similar firmware). * The machines should have enough RAM to fit the deployment/cleaning ramdisk to run. The minimum varies greatly depending on the way the ramdisk was built. For example, *tinyipa*, the TinyCoreLinux-based ramdisk used in the CI, only needs 400 MiB of RAM, while ramdisks built by *diskimage-builder* may require 3 GiB or more. Image types ----------- The Bare Metal service can deploy two types of images: * *Whole-disk* images that contain a complete partitioning table with all necessary partitions and a bootloader. Such images are the most universal, but may be harder to build. * *Partition images* that contain only the root partition. The Bare Metal service will create the necessary partitions and install a boot loader, if needed. .. warning:: Partition images are only supported with GNU/Linux operating systems. .. warning:: If you plan on using local boot, your partition images must contain GRUB2 bootloader tools to enable ironic to set up the bootloader during deploy. Local vs network boot --------------------- The Bare Metal service supports booting user instances either using a local bootloader or using the driver's boot interface (e.g. via PXE_ or iPXE_ protocol in case of the ``pxe`` interface). Network boot cannot be used with certain architectures (for example, when no tenant networks have access to the control plane). Additional considerations are related to the ``pxe`` boot interface, and other boot interfaces based on it: * Local boot makes node's boot process independent of the Bare Metal conductor managing it. Thus, nodes are able to reboot correctly, even if the Bare Metal TFTP or HTTP service is down. * Network boot (and iPXE) must be used when booting nodes from remote volumes, if the driver does not support attaching volumes out-of-band. The default boot option for the cloud can be changed via the Bare Metal service configuration file, for example: .. code-block:: ini [deploy] default_boot_option = local This default can be overriden by setting the ``boot_option`` capability on a node. See :ref:`local-boot-partition-images` for details. .. note:: Currently, network boot is used by default. However, we plan on changing it in the future, so it's safer to set the ``default_boot_option`` explicitly. Networking ---------- There are several recommended network topologies to be used with the Bare Metal service. They are explained in depth in specific architecture documentation. However, several considerations are common for all of them: * There has to be a *provisioning* network, which is used by nodes during the deployment process. If allowed by the architecture, this network should not be accessible by end users, and should not have access to the internet. * There has to be a *cleaning* network, which is used by nodes during the cleaning process. In the majority of cases, the same network should be used for cleaning and provisioning for simplicity. Unless noted otherwise, everything in these sections apply to both networks. * The baremetal nodes must have access to the Bare Metal API while connected to the provisioning/cleaning network. .. note:: Only two endpoints need to be exposed there:: GET /v1/lookup POST /v1/heartbeat/[a-z0-9\-]+ You may want to limit access from this network to only these endpoints, and make these endpoint not accessible from other networks. * If the ``pxe`` boot interface (or any boot interface based on it) is used, then the baremetal nodes should have untagged (access mode) connectivity to the provisioning/cleaning networks. It allows PXE firmware, which does not support VLANs, to communicate with the services required for provisioning. .. note:: It depends on the *network interface* whether the Bare Metal service will handle it automatically. Check the networking documentation for the specific architecture. * The Baremetal nodes need to have access to any services required for provisioning/cleaning, while connected to the provisioning/cleaning network. This may include: * a TFTP server for PXE boot and also an HTTP server when iPXE is enabled * either an HTTP server or the Object Storage service in case of the ``direct`` deploy interface and some virtual media boot interfaces * The Baremetal Conductors need to have access to the booted baremetal nodes during provisioning/cleaning. A conductor communicates with an internal API, provided by **ironic-python-agent**, to conduct actions on nodes. HA and Scalability ------------------ ironic-api ~~~~~~~~~~ The Bare Metal API service is stateless, and thus can be easily scaled horizontally. It is recommended to deploy it as a WSGI application behind e.g. Apache or another WSGI container. .. note:: This service accesses the ironic database for reading entities (e.g. in response to ``GET /v1/nodes`` request) and in rare cases for writing. ironic-conductor ~~~~~~~~~~~~~~~~ High availability ^^^^^^^^^^^^^^^^^ The Bare Metal conductor service utilizes the active/active HA model. Every conductor manages a certain subset of nodes. The nodes are organized in a hash ring that tries to keep the load spread more or less uniformly across the conductors. When a conductor is considered offline, its nodes are taken over by other conductors. As a result of this, you need at least 2 conductor hosts for an HA deployment. Performance ^^^^^^^^^^^ Conductors can be resource intensive, so it is recommended (but not required) to keep all conductors separate from other services in the cloud. The minimum required number of conductors in a deployment depends on several factors: * the performance of the hardware where the conductors will be running, * the speed and reliability of the `management controller`_ of the bare metal nodes (for example, handling slower controllers may require having less nodes per conductor), * the frequency, at which the management controllers are polled by the Bare Metal service (see the ``sync_power_state_interval`` option), * the bare metal driver used for nodes (see `Hardware and drivers`_ above), * the network performance, * the maximum number of bare metal nodes that are provisioned simultaneously (see the ``max_concurrent_builds`` option for the Compute service). We recommend a target of **100** bare metal nodes per conductor for maximum reliability and performance. There is some tolerance for a larger number per conductor. However, it was reported [1]_ [2]_ that reliability degrades when handling approximately 300 bare metal nodes per conductor. Disk space ^^^^^^^^^^ Each conductor needs enough free disk space to cache images it uses. Depending on the combination of the deploy interface and the boot option, the space requirements are different: * The deployment kernel and ramdisk are always cached during the deployment. * The ``iscsi`` deploy method requires caching of the whole instance image locally during the deployment. The image has to be converted to the raw format, which may increase the required amount of disk space, as well as the CPU load. .. note:: This is not a concern for the ``direct`` deploy interface, as in this case the deployment ramdisk downloads the image and either streams it to the disk or caches it in memory. * When network boot is used, the instance image kernel and ramdisk are cached locally while the instance is active. .. note:: All images may be stored for some time after they are no longer needed. This is done to speed up simultaneous deployments of many similar images. The caching can be configured via the ``image_cache_size`` and ``image_cache_ttl`` configuration options in the ``pxe`` group. .. [1] http://lists.openstack.org/pipermail/openstack-dev/2017-June/118033.html .. [2] http://lists.openstack.org/pipermail/openstack-dev/2017-June/118327.html Other services ~~~~~~~~~~~~~~ When integrating with other OpenStack services, more considerations may need to be applied. This is covered in other parts of this guide. .. _PXE: https://en.wikipedia.org/wiki/Preboot_Execution_Environment .. _iPXE: https://en.wikipedia.org/wiki/IPXE .. _IPMI: https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface .. _management controller: https://en.wikipedia.org/wiki/Out-of-band_management ironic-10.1.1/doc/source/install/refarch/index.rst0000666000175100017510000000060413243617463022102 0ustar zuulzuul00000000000000Reference Deploy Architectures ============================== This section covers the way we recommend the Bare Metal service to be deployed and managed. It is assumed that a reader has already gone through :doc:`/user/index`. It may be also useful to try :ref:`deploy_devstack` first to get better familiar with the concepts used in this guide. .. toctree:: :maxdepth: 2 common ironic-10.1.1/doc/source/install/configure-nova-flavors.rst0000666000175100017510000001221113243617463023752 0ustar zuulzuul00000000000000.. _flavor-creation: Create flavors for use with the Bare Metal service ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Scheduling based on properties ============================== You'll need to create a special bare metal flavor in the Compute service. The flavor is mapped to the bare metal node through the hardware specifications. #. Change these to match your hardware: .. code-block:: console $ RAM_MB=1024 $ CPU=2 $ DISK_GB=100 $ ARCH={i686|x86_64} #. Create the bare metal flavor by executing the following command: .. code-block:: console $ nova flavor-create my-baremetal-flavor auto $RAM_MB $DISK_GB $CPU .. note:: You can replace ``auto`` with your own flavor id. #. Set the architecture as extra_specs information of the flavor. This will be used to match against the properties of bare metal nodes: .. code-block:: console $ nova flavor-key my-baremetal-flavor set cpu_arch=$ARCH .. _scheduling-resource-classes: Scheduling based on resource classes ==================================== As of the Pike release, a Compute service flavor is able to use the node's ``resource_class`` field (available starting with Bare Metal API version 1.21) for scheduling, instead of the CPU, RAM, and disk properties defined in the flavor. A flavor can request *exactly one* instance of a bare metal resource class. Start with creating the flavor in the same way as described in `Scheduling based on properties`_. The ``CPU``, ``RAM_MB`` and ``DISK_GB`` values are not going to be used for scheduling, but the ``DISK_GB`` value will still be used to determine the root partition size. After creation, associate each flavor with one custom resource class. The name of a custom resource class that corresponds to a node's resource class (in the Bare Metal service) is: * the bare metal node's resource class all upper-cased * prefixed with ``CUSTOM_`` * all punctuation replaced with an underscore For example, if the resource class is named ``baremetal-small``, associate the flavor with this custom resource class via: .. code-block:: console $ nova flavor-key my-baremetal-flavor set resources:CUSTOM_BAREMETAL_SMALL=1 Another set of flavor properties should be used to disable scheduling based on standard properties for a bare metal flavor: .. code-block:: console $ nova flavor-key my-baremetal-flavor set resources:VCPU=0 $ nova flavor-key my-baremetal-flavor set resources:MEMORY_MB=0 $ nova flavor-key my-baremetal-flavor set resources:DISK_GB=0 .. warning:: The last step will be mandatory in the Queens release, as the Compute service will stop providing standard resources for bare metal nodes. Example ------- If you want to define a class of nodes called ``baremetal.with-GPU``, start with tagging some nodes with it: .. code-block:: console $ openstack --os-baremetal-api-version 1.21 baremetal node set $NODE_UUID \ --resource-class baremetal.with-GPU .. warning:: It is possible to **add** a resource class to ``active`` nodes, but it is not possible to **replace** an existing resource class on them. Then you can update your flavor to request the resource class instead of the standard properties: .. code-block:: console $ nova flavor-key my-baremetal-flavor set resources:CUSTOM_BAREMETAL_WITH_GPU=1 $ nova flavor-key my-baremetal-flavor set resources:VCPU=0 $ nova flavor-key my-baremetal-flavor set resources:MEMORY_MB=0 $ nova flavor-key my-baremetal-flavor set resources:DISK_GB=0 Note how ``baremetal.with-GPU`` in the node's ``resource_class`` field becomes ``CUSTOM_BAREMETAL_WITH_GPU`` in the flavor's properties. .. _scheduling-traits: Scheduling based on traits -------------------------- Starting with the Queens release, the Compute service supports scheduling based on qualitative attributes using traits. Starting with Bare Metal REST API version 1.37, it is possible to assign a list of traits to each bare metal node. Traits assigned to a bare metal node will be assigned to the corresponding resource provider in the Compute service placement API. When creating a flavor in the Compute service, required traits may be specified via flavor properties. The Compute service will then schedule instances only to bare metal nodes with all of the required traits. Traits can be either standard or custom. Standard traits are listed in the `os_traits library `_. Custom traits must meet the following requirements: * prefixed with ``CUSTOM_`` * contain only upper case characters A to Z, digits 0 to 9, or underscores * no longer than 255 characters in length A bare metal node can have a maximum of 50 traits. Example ^^^^^^^ To add the standard trait ``HW_CPU_X86_VMX`` and a custom trait ``CUSTOM_TRAIT1`` to a node: .. code-block:: console $ openstack --os-baremetal-api-version 1.37 baremetal node add trait \ $NODE_UUID CUSTOM_TRAIT1 HW_CPU_X86_VMX Then, update the flavor to require these traits: .. code-block:: console $ nova flavor-key my-baremetal-flavor set trait:CUSTOM_TRAIT1=required $ nova flavor-key my-baremetal-flavor set trait:HW_CPU_X86_VMX=required ironic-10.1.1/doc/source/install/troubleshooting.rst0000666000175100017510000002001213243617463022603 0ustar zuulzuul00000000000000.. _troubleshooting-install: =============== Troubleshooting =============== Once all the services are running and configured properly, and a node has been enrolled with the Bare Metal service and is in the ``available`` provision state, the Compute service should detect the node as an available resource and expose it to the scheduler. .. note:: There is a delay, and it may take up to a minute (one periodic task cycle) for the Compute service to recognize any changes in the Bare Metal service's resources (both additions and deletions). In addition to watching ``nova-compute`` log files, you can see the available resources by looking at the list of Compute hypervisors. The resources reported therein should match the bare metal node properties, and the Compute service flavor. Here is an example set of commands to compare the resources in Compute service and Bare Metal service:: $ openstack baremetal node list +--------------------------------------+---------------+-------------+--------------------+-------------+ | UUID | Instance UUID | Power State | Provisioning State | Maintenance | +--------------------------------------+---------------+-------------+--------------------+-------------+ | 86a2b1bb-8b29-4964-a817-f90031debddb | None | power off | available | False | +--------------------------------------+---------------+-------------+--------------------+-------------+ $ openstack baremetal node show 86a2b1bb-8b29-4964-a817-f90031debddb +------------------------+----------------------------------------------------------------------+ | Property | Value | +------------------------+----------------------------------------------------------------------+ | instance_uuid | None | | properties | {u'memory_mb': u'1024', u'cpu_arch': u'x86_64', u'local_gb': u'10', | | | u'cpus': u'1'} | | maintenance | False | | driver_info | { [SNIP] } | | extra | {} | | last_error | None | | created_at | 2014-11-20T23:57:03+00:00 | | target_provision_state | None | | driver | ipmi | | updated_at | 2014-11-21T00:47:34+00:00 | | instance_info | {} | | chassis_uuid | 7b49bbc5-2eb7-4269-b6ea-3f1a51448a59 | | provision_state | available | | reservation | None | | power_state | power off | | console_enabled | False | | uuid | 86a2b1bb-8b29-4964-a817-f90031debddb | +------------------------+----------------------------------------------------------------------+ $ nova hypervisor-list +--------------------------------------+--------------------------------------+-------+---------+ | ID | Hypervisor hostname | State | Status | +--------------------------------------+--------------------------------------+-------+---------+ | 584cfdc8-9afd-4fbb-82ef-9ff25e1ad3f3 | 86a2b1bb-8b29-4964-a817-f90031debddb | up | enabled | +--------------------------------------+--------------------------------------+-------+---------+ $ nova hypervisor-show 584cfdc8-9afd-4fbb-82ef-9ff25e1ad3f3 +-------------------------+--------------------------------------+ | Property | Value | +-------------------------+--------------------------------------+ | cpu_info | baremetal cpu | | current_workload | 0 | | disk_available_least | - | | free_disk_gb | 10 | | free_ram_mb | 1024 | | host_ip | [ SNIP ] | | hypervisor_hostname | 86a2b1bb-8b29-4964-a817-f90031debddb | | hypervisor_type | ironic | | hypervisor_version | 1 | | id | 1 | | local_gb | 10 | | local_gb_used | 0 | | memory_mb | 1024 | | memory_mb_used | 0 | | running_vms | 0 | | service_disabled_reason | - | | service_host | my-test-host | | service_id | 6 | | state | up | | status | enabled | | vcpus | 1 | | vcpus_used | 0 | +-------------------------+--------------------------------------+ .. _maintenance_mode: Maintenance mode ---------------- Maintenance mode may be used if you need to take a node out of the resource pool. Putting a node in maintenance mode will prevent Bare Metal service from executing periodic tasks associated with the node. This will also prevent Compute service from placing a tenant instance on the node by not exposing the node to the nova scheduler. Nodes can be placed into maintenance mode with the following command. :: $ openstack baremetal node maintenance set $NODE_UUID A maintenance reason may be included with the optional ``--reason`` command line option. This is a free form text field that will be displayed in the ``maintenance_reason`` section of the ``node show`` command. :: $ openstack baremetal node maintenance set $UUID --reason "Need to add ram." $ openstack baremetal node show $UUID +------------------------+--------------------------------------+ | Property | Value | +------------------------+--------------------------------------+ | target_power_state | None | | extra | {} | | last_error | None | | updated_at | 2015-04-27T15:43:58+00:00 | | maintenance_reason | Need to add ram. | | ... | ... | | maintenance | True | | ... | ... | +------------------------+--------------------------------------+ To remove maintenance mode and clear any ``maintenance_reason`` use the following command. :: $ openstack baremetal node maintenance unset $NODE_UUID .. _ironic-python-agent: https://docs.openstack.org/ironic-python-agent/latest/ ironic-10.1.1/doc/source/install/index.rst0000666000175100017510000000124713243617463020474 0ustar zuulzuul00000000000000===================================== Bare Metal Service Installation Guide ===================================== The Bare Metal service is a collection of components that provides support to manage and provision physical machines. This chapter assumes a working setup of OpenStack following the `OpenStack Installation Guides `_. It contains the following sections: .. toctree:: :maxdepth: 2 get_started.rst refarch/index install.rst configure-integration.rst deploy-ramdisk.rst setup-drivers.rst enrollment.rst standalone.rst configdrive.rst advanced.rst troubleshooting.rst next-steps.rst ironic-10.1.1/doc/source/install/advanced.rst0000666000175100017510000000060013243617463021122 0ustar zuulzuul00000000000000.. _advanced: Advanced features ================= .. include:: include/local-boot-partition-images.inc .. include:: include/root-device-hints.inc .. include:: include/kernel-boot-parameters.inc .. include:: include/boot-mode.inc .. include:: include/disk-label.inc .. include:: include/trusted-boot.inc .. include:: include/notifications.inc .. include:: include/console.inc ironic-10.1.1/doc/source/install/get_started.rst0000666000175100017510000000701513243617463021671 0ustar zuulzuul00000000000000=========================== Bare Metal service overview =========================== The Bare Metal service is a collection of components that provides support to manage and provision physical machines. Also known as the ``ironic`` project, the Bare Metal service may, depending upon configuration, interact with several other OpenStack services. This includes: - the OpenStack Telemetry module (``ceilometer``) for consuming the IPMI metrics - the OpenStack Identity service (``keystone``) for request authentication and to locate other OpenStack services - the OpenStack Image service (``glance``) from which to retrieve images and image meta-data - the OpenStack Networking service (``neutron``) for DHCP and network configuration - the OpenStack Compute service (``nova``) works with the Bare Metal service and acts as a user-facing API for instance management, while the Bare Metal service provides the admin/operator API for hardware management. The OpenStack Compute service also provides scheduling facilities (matching flavors <-> images <-> hardware), tenant quotas, IP assignment, and other services which the Bare Metal service does not, in and of itself, provide. - the OpenStack Object Storage (``swift``) provides temporary storage for the configdrive, user images, deployment logs and inspection data. The Bare Metal service includes the following components: ironic-api A RESTful API that processes application requests by sending them to the ironic-conductor over `remote procedure call (RPC)`_. ironic-conductor Adds/edits/deletes nodes; powers on/off nodes with ipmi or other vendor-specific protocol; provisions/deploys/cleans bare metal nodes. ironic-python-agent A python service which is run in a temporary ramdisk to provide ironic-conductor and ironic-inspector services with remote access, in-band hardware control, and hardware introspection. .. _`remote procedure call (RPC)`: https://en.wikipedia.org/wiki/Remote_procedure_call Additionally, the Bare Metal service has certain external dependencies, which are very similar to other OpenStack services: - A database to store hardware information and state. You can set the database back-end type and location. A simple approach is to use the same database back end as the Compute service. Another approach is to use a separate database back-end to further isolate bare metal resources (and associated metadata) from users. - An oslo.messaging compatible queue, such as RabbitMQ. It may use the same implementation as that of the Compute service, but that is not a requirement. Optionally, one may wish to utilize the following associated projects for additional functionality: python-ironicclient_ A command-line interface (CLI) and python bindings for interacting with the Bare Metal service. ironic-inspector_ An associated service which performs in-band hardware introspection by PXE booting unregistered hardware into the ironic-python-agent ramdisk. diskimage-builder_ A related project to help facilitate the creation of ramdisks and machine images, such as those running the ironic-python-agent. bifrost_ A set of Ansible playbooks that automates the task of deploying a base image onto a set of known hardware using ironic in a standalone mode. .. _python-ironicclient: https://docs.openstack.org/python-ironicclient/latest/ .. _ironic-inspector: https://docs.openstack.org/ironic-inspector/latest/ .. _diskimage-builder: https://docs.openstack.org/diskimage-builder/latest/ .. _bifrost: https://docs.openstack.org/bifrost/latest/ ironic-10.1.1/doc/source/install/configure-ipmi.rst0000666000175100017510000000611313243617463022277 0ustar zuulzuul00000000000000Configuring IPMI support ------------------------ Installing ipmitool command ~~~~~~~~~~~~~~~~~~~~~~~~~~~ To enable one of the drivers that use IPMI_ protocol for power and management actions (for example, ``ipmi``), the ``ipmitool`` command must be present on the service node(s) where ``ironic-conductor`` is running. On most distros, it is provided as part of the ``ipmitool`` package. Source code is available at http://ipmitool.sourceforge.net/. .. warning:: Certain distros, notably Mac OS X and SLES, install ``openipmi`` instead of ``ipmitool`` by default. This driver is not compatible with ``openipmi`` as it relies on error handling options not provided by this tool. Please refer to the :doc:`/admin/drivers/ipmitool` for information on how to use IPMItool-based drivers. Validation and troubleshooting ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Check that you can connect to, and authenticate with, the IPMI controller in your bare metal server by running ``ipmitool``:: ipmitool -I lanplus -H -U -P chassis power status where ```` is the IP of the IPMI controller you want to access. This is not the bare metal node's main IP. The IPMI controller should have its own unique IP. If the above command doesn't return the power status of the bare metal server, check that - ``ipmitool`` is installed and is available via the ``$PATH`` environment variable. - The IPMI controller on your bare metal server is turned on. - The IPMI controller credentials and IP address passed in the command are correct. - The conductor node has a route to the IPMI controller. This can be checked by just pinging the IPMI controller IP from the conductor node. IPMI configuration ~~~~~~~~~~~~~~~~~~ If there are slow or unresponsive BMCs in the environment, the ``min_command_interval`` configuration option in the ``[ipmi]`` section may need to be raised. The default is fairly conservative, as setting this timeout too low can cause older BMCs to crash and require a hard-reset. .. _ipmi-sensor-data: Collecting sensor data ~~~~~~~~~~~~~~~~~~~~~~ Bare Metal service supports sending IPMI sensor data to Telemetry with certain hardware types, such as ``ipmi``, ``ilo`` and ``irmc``. By default, support for sending IPMI sensor data to Telemetry is disabled. If you want to enable it, you should make the following two changes in ``ironic.conf``: .. code-block:: ini [DEFAULT] notification_driver = messaging [conductor] send_sensor_data = true If you want to customize the sensor types which will be sent to Telemetry, change the ``send_sensor_data_types`` option. For example, the below settings will send information about temperature, fan, voltage from sensors to the Telemetry service: .. code-block:: ini send_sensor_data_types=Temperature,Fan,Voltage Supported sensor types are defined by the Telemetry service, currently these are ``Temperature``, ``Fan``, ``Voltage``, ``Current``. Special value ``All`` (the default) designates all supported sensor types. .. _IPMI: https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface ironic-10.1.1/doc/source/install/configure-integration.rst0000666000175100017510000000057013243617463023665 0ustar zuulzuul00000000000000========================================= Integration with other OpenStack services ========================================= .. toctree:: :maxdepth: 1 configure-identity configure-compute configure-networking configure-glance-swift enabling-https configure-cleaning configure-tenant-networks.rst configure-glance-images configure-nova-flavors ironic-10.1.1/doc/source/install/conf.py0000666000175100017510000002357713243617463020144 0ustar zuulzuul00000000000000# Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or # implied. # See the License for the specific language governing permissions and # limitations under the License. # This file is execfile()d with the current directory set to its # containing dir. # # Note that not all possible configuration values are present in this # autogenerated file. # # All configuration values have a default; values that are commented out # serve to show the default. import os # import sys import openstackdocstheme # If extensions (or modules to document with autodoc) are in another directory, # add these directories to sys.path here. If the directory is relative to the # documentation root, use os.path.abspath to make it absolute, like shown here. # sys.path.insert(0, os.path.abspath('.')) # -- General configuration ------------------------------------------------ # If your documentation needs a minimal Sphinx version, state it here. # needs_sphinx = '1.0' # Add any Sphinx extension module names here, as strings. They can be # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom # ones. # TODO(ajaeger): enable PDF building, for example add 'rst2pdf.pdfbuilder' # extensions = # Add any paths that contain templates here, relative to this directory. # templates_path = ['_templates'] # The suffix of source filenames. source_suffix = '.rst' # The encoding of source files. # source_encoding = 'utf-8-sig' # The master toctree document. master_doc = 'index' # General information about the project. project = u'Installation Guide for Bare Metal Service' bug_tag = u'install-guide' copyright = u'2016, OpenStack contributors' # The version info for the project you're documenting, acts as replacement for # |version| and |release|, also used in various other places throughout the # built documents. # # The short X.Y version. version = '0.1' # The full version, including alpha/beta/rc tags. release = '0.1' # A few variables have to be set for the log-a-bug feature. # giturl: The location of conf.py on Git. Must be set manually. # gitsha: The SHA checksum of the bug description. Automatically extracted # from git log. # bug_tag: Tag for categorizing the bug. Must be set manually. # These variables are passed to the logabug code via html_context. giturl = u'https://git.openstack.org/cgit/openstack/ironic/tree/install-guide/source' # noqa git_cmd = "/usr/bin/git log | head -n1 | cut -f2 -d' '" gitsha = os.popen(git_cmd).read().strip('\n') html_context = {"gitsha": gitsha, "bug_tag": bug_tag, "giturl": giturl, "bug_project": "ironic"} # The language for content autogenerated by Sphinx. Refer to documentation # for a list of supported languages. # language = None # There are two options for replacing |today|: either, you set today to some # non-false value, then it is used: # today = '' # Else, today_fmt is used as the format for a strftime call. # today_fmt = '%B %d, %Y' # List of patterns, relative to source directory, that match files and # directories to ignore when looking for source files. exclude_patterns = ['include'] # The reST default role (used for this markup: `text`) to use for all # documents. # default_role = None # If true, '()' will be appended to :func: etc. cross-reference text. # add_function_parentheses = True # If true, the current module name will be prepended to all description # unit titles (such as .. function::). # add_module_names = True # If true, sectionauthor and moduleauthor directives will be shown in the # output. They are ignored by default. # show_authors = False # The name of the Pygments (syntax highlighting) style to use. pygments_style = 'sphinx' # A list of ignored prefixes for module index sorting. # modindex_common_prefix = [] # If true, keep warnings as "system message" paragraphs in the built documents. # keep_warnings = False # -- Options for HTML output ---------------------------------------------- # The theme to use for HTML and HTML Help pages. See the documentation for # a list of builtin themes. html_theme = 'openstackdocs' # Theme options are theme-specific and customize the look and feel of a theme # further. For a list of options available for each theme, see the # documentation. # html_theme_options = {} # Add any paths that contain custom themes here, relative to this directory. html_theme_path = [openstackdocstheme.get_html_theme_path()] # The name for this set of Sphinx documents. If None, it defaults to # " v documentation". # html_title = None # A shorter title for the navigation bar. Default is the same as html_title. # html_short_title = None # The name of an image file (relative to this directory) to place at the top # of the sidebar. # html_logo = None # The name of an image file (within the static path) to use as favicon of the # docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 # pixels large. # html_favicon = None # Add any paths that contain custom static files (such as style sheets) here, # relative to this directory. They are copied after the builtin static files, # so a file named "default.css" will overwrite the builtin "default.css". # html_static_path = [] # Add any extra paths that contain custom files (such as robots.txt or # .htaccess) here, relative to this directory. These files are copied # directly to the root of the documentation. # html_extra_path = [] # If not '', a 'Last updated on:' timestamp is inserted at every page bottom, # using the given strftime format. # So that we can enable "log-a-bug" links from each output HTML page, this # variable must be set to a format that includes year, month, day, hours and # minutes. html_last_updated_fmt = '%Y-%m-%d %H:%M' # If true, SmartyPants will be used to convert quotes and dashes to # typographically correct entities. # html_use_smartypants = True # Custom sidebar templates, maps document names to template names. # html_sidebars = {} # Additional templates that should be rendered to pages, maps page names to # template names. # html_additional_pages = {} # If false, no module index is generated. # html_domain_indices = True # If false, no index is generated. html_use_index = False # If true, the index is split into individual pages for each letter. # html_split_index = False # If true, links to the reST sources are added to the pages. html_show_sourcelink = False # If true, "Created using Sphinx" is shown in the HTML footer. Default is True. # html_show_sphinx = True # If true, "(C) Copyright ..." is shown in the HTML footer. Default is True. # html_show_copyright = True # If true, an OpenSearch description file will be output, and all pages will # contain a tag referring to it. The value of this option must be the # base URL from which the finished HTML is served. # html_use_opensearch = '' # This is the file name suffix for HTML files (e.g. ".xhtml"). # html_file_suffix = None # Output file base name for HTML help builder. htmlhelp_basename = 'install-guide' # If true, publish source files html_copy_source = False # -- Options for LaTeX output --------------------------------------------- latex_elements = { # The paper size ('letterpaper' or 'a4paper'). # 'papersize': 'letterpaper', # The font size ('10pt', '11pt' or '12pt'). # 'pointsize': '10pt', # Additional stuff for the LaTeX preamble. # 'preamble': '', } # Grouping the document tree into LaTeX files. List of tuples # (source start file, target name, title, # author, documentclass [howto, manual, or own class]). latex_documents = [ ('index', 'InstallGuide.tex', u'Install Guide', u'OpenStack contributors', 'manual'), ] # The name of an image file (relative to this directory) to place at the top of # the title page. # latex_logo = None # For "manual" documents, if this is true, then toplevel headings are parts, # not chapters. # latex_use_parts = False # If true, show page references after internal links. # latex_show_pagerefs = False # If true, show URL addresses after external links. # latex_show_urls = False # Documents to append as an appendix to all manuals. # latex_appendices = [] # If false, no module index is generated. # latex_domain_indices = True # -- Options for manual page output --------------------------------------- # One entry per manual page. List of tuples # (source start file, name, description, authors, manual section). man_pages = [ ('index', 'installguide', u'Install Guide', [u'OpenStack contributors'], 1) ] # If true, show URL addresses after external links. # man_show_urls = False # -- Options for Texinfo output ------------------------------------------- # Grouping the document tree into Texinfo files. List of tuples # (source start file, target name, title, author, # dir menu entry, description, category) texinfo_documents = [ ('index', 'InstallGuide', u'Install Guide', u'OpenStack contributors', 'InstallGuide', 'This guide shows OpenStack end users how to install ' 'an OpenStack cloud.', 'Miscellaneous'), ] # Documents to append as an appendix to all manuals. # texinfo_appendices = [] # If false, no module index is generated. # texinfo_domain_indices = True # How to display URL addresses: 'footnote', 'no', or 'inline'. # texinfo_show_urls = 'footnote' # If true, do not generate a @detailmenu in the "Top" node's menu. # texinfo_no_detailmenu = False # -- Options for Internationalization output ------------------------------ locale_dirs = ['locale/'] # -- Options for PDF output -------------------------------------------------- pdf_documents = [ ('index', u'InstallGuide', u'Install Guide', u'OpenStack contributors') ] ironic-10.1.1/doc/source/install/configure-cleaning.rst0000666000175100017510000000211213243617463023114 0ustar zuulzuul00000000000000.. _configure-cleaning: Configure the Bare Metal service for cleaning ============================================= .. note:: If you configured the Bare Metal service to do :ref:`automated_cleaning` (which is enabled by default), you will need to set the ``cleaning_network`` configuration option. #. Note the network UUID (the `id` field) of the network you created in :ref:`configure-networking` or another network you created for cleaning: .. code-block:: console $ neutron net-list #. Configure the cleaning network UUID via the ``cleaning_network`` option in the Bare Metal service configuration file (``/etc/ironic/ironic.conf``). In the following, replace ``NETWORK_UUID`` with the UUID you noted in the previous step: .. code-block:: ini [neutron] cleaning_network = NETWORK_UUID #. Restart the Bare Metal service's ironic-conductor: .. code-block:: console Fedora/RHEL7/CentOS7/SUSE: sudo systemctl restart openstack-ironic-conductor Ubuntu: sudo service ironic-conductor restart ironic-10.1.1/doc/source/install/configure-glance-images.rst0000666000175100017510000001134613243617463024041 0ustar zuulzuul00000000000000.. _image-requirements: Create and add images to the Image service ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Bare Metal provisioning requires two sets of images: the deploy images and the user images. The deploy images are used by the Bare Metal service to prepare the bare metal server for actual OS deployment. Whereas the user images are installed on the bare metal server to be used by the end user. Below are the steps to create the required images and add them to the Image service: #. Build the user images The `disk-image-builder`_ can be used to create user images required for deployment and the actual OS which the user is going to run. .. _disk-image-builder: https://docs.openstack.org/diskimage-builder/latest/ - Install diskimage-builder package (use virtualenv, if you don't want to install anything globally): .. code-block:: console # pip install diskimage-builder - Build the image your users will run (Ubuntu image has been taken as an example): - Partition images .. code-block:: console $ disk-image-create ubuntu baremetal dhcp-all-interfaces grub2 -o my-image - Whole disk images .. code-block:: console $ disk-image-create ubuntu vm dhcp-all-interfaces -o my-image The partition image command creates ``my-image.qcow2``, ``my-image.vmlinuz`` and ``my-image.initrd`` files. The ``grub2`` element in the partition image creation command is only needed if local boot will be used to deploy ``my-image.qcow2``, otherwise the images ``my-image.vmlinuz`` and ``my-image.initrd`` will be used for PXE booting after deploying the bare metal with ``my-image.qcow2``. If you want to use Fedora image, replace ``ubuntu`` with ``fedora`` in the chosen command. #. Add the user images to the Image service Load all the images created in the below steps into the Image service, and note the image UUIDs in the Image service for each one as it is generated. - Add the kernel and ramdisk images to the Image service: .. code-block:: console $ glance image-create --name my-kernel --visibility public \ --disk-format aki --container-format aki < my-image.vmlinuz Store the image uuid obtained from the above step as ``MY_VMLINUZ_UUID``. .. code-block:: console $ glance image-create --name my-image.initrd --visibility public \ --disk-format ari --container-format ari < my-image.initrd Store the image UUID obtained from the above step as ``MY_INITRD_UUID``. - Add the *my-image* to the Image service which is going to be the OS that the user is going to run. Also associate the above created images with this OS image. These two operations can be done by executing the following command: .. code-block:: console $ glance image-create --name my-image --visibility public \ --disk-format qcow2 --container-format bare --property \ kernel_id=$MY_VMLINUZ_UUID --property \ ramdisk_id=$MY_INITRD_UUID < my-image.qcow2 .. note:: To deploy a whole disk image, a kernel_id and a ramdisk_id shouldn't be associated with the image. For example, .. code-block:: console $ glance image-create --name my-whole-disk-image --visibility public \ --disk-format qcow2 \ --container-format bare < my-whole-disk-image.qcow2 #. Build or download the deploy images The deploy images are used initially for preparing the server (creating disk partitions) before the actual OS can be deployed. There are several methods to build or download deploy images, please read the :ref:`deploy-ramdisk` section. The recommended method is to use CoreOS to build deploy images, you will get one kernel disk ``coreos_production_pxe.vmlinuz`` and one ram disk ``coreos_production_pxe_image-oem.cpio.gz``. .. note:: If you want to customize your deploy images, please read `Image Builders `_. #. Add the deploy images to the Image service Add the *coreos_production_pxe.vmlinuz* and *coreos_production_pxe_image-oem.cpio.gz* images to the Image service: .. code-block:: console $ glance image-create --name deploy-vmlinuz --visibility public \ --disk-format aki --container-format aki < coreos_production_pxe.vmlinuz Store the image UUID obtained from the above step as ``DEPLOY_VMLINUZ_UUID``. .. code-block:: console $ glance image-create --name deploy-initrd --visibility public \ --disk-format ari --container-format ari < coreos_production_pxe_image-oem.cpio.gz Store the image UUID obtained from the above step as ``DEPLOY_INITRD_UUID``. ironic-10.1.1/doc/source/install/install-ubuntu.rst0000666000175100017510000000134713243617463022354 0ustar zuulzuul00000000000000.. _install-ubuntu: ================================ Install and configure for Ubuntu ================================ This section describes how to install and configure the Bare Metal service for Ubuntu 14.04 (LTS). .. include:: include/common-prerequisites.inc Install and configure components ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #. Install from packages (using apt-get) .. code-block:: console # apt-get install ironic-api ironic-conductor python-ironicclient #. Enable services Services are enabled by default on Ubuntu. .. include:: include/common-configure.inc .. include:: include/configure-ironic-api.inc .. include:: include/configure-ironic-api-mod_wsgi.inc .. include:: include/configure-ironic-conductor.inc ironic-10.1.1/doc/source/install/next-steps.rst0000666000175100017510000000016313243617463021473 0ustar zuulzuul00000000000000.. _next-steps: ========== Next steps ========== Your OpenStack environment now includes the Bare Metal service. ironic-10.1.1/doc/source/install/configdrive.rst0000666000175100017510000001403513243617463021663 0ustar zuulzuul00000000000000.. _configdrive: Enabling the configuration drive (configdrive) ============================================== The Bare Metal service supports exposing a configuration drive image to the instances. The configuration drive is used to store instance-specific metadata and is present to the instance as a disk partition labeled ``config-2``. The configuration drive has a maximum size of 64MB. One use case for using the configuration drive is to expose a networking configuration when you do not use DHCP to assign IP addresses to instances. The configuration drive is usually used in conjunction with the Compute service, but the Bare Metal service also offers a standalone way of using it. The following sections will describe both methods. When used with Compute service ------------------------------ To enable the configuration drive for a specific request, pass ``--config-drive true`` parameter to the :command:`nova boot` command, for example:: nova boot --config-drive true --flavor baremetal --image test-image instance-1 It's also possible to enable the configuration drive automatically on all instances by configuring the ``OpenStack Compute service`` to always create a configuration drive by setting the following option in the ``/etc/nova/nova.conf`` file, for example:: [DEFAULT] ... force_config_drive=True In some cases, you may wish to pass a user customized script when deploying an instance. To do this, pass ``--user-data /path/to/file`` to the :command:`nova boot` command. When used standalone -------------------- When used without the Compute service, the operator needs to create a configuration drive and provide the file or HTTP URL to the Bare Metal service. For the format of the configuration drive, Bare Metal service expects a ``gzipped`` and ``base64`` encoded ISO 9660 [*]_ file with a ``config-2`` label. The `openstack baremetal client `_ can generate a configuration drive in the `expected format`_. Just pass a directory path containing the files that will be injected into it via the ``--config-drive`` parameter of the ``openstack baremetal node deploy`` command, for example:: openstack baremetal node deploy $node_identifier --config-drive /dir/configdrive_files Configuration drive storage in an object store ---------------------------------------------- Under normal circumstances, the configuration drive can be stored in the Bare Metal service when the size is less than 64KB. Optionally, if the size is larger than 64KB there is support to store it in swift or radosgw backed object store. Both swift and radosgw use swift-style APIs. The following option in ``/etc/ironic/ironic.conf`` enables swift as an object store backend to store config drive. This uses the Identity service to establish a session between the Bare Metal service and the Object Storage service. :: [deploy] ... configdrive_use_object_store = True Use the following options in ``/etc/ironic/ironic.conf`` to enable radosgw. Credentials in the swift section are needed because radosgw will not use the Identity service and relies on radosgw's username and password authentication instead. :: [deploy] ... configdrive_use_object_store = True object_store_endpoint_type = radosgw [swift] ... username = USERNAME password = PASSWORD auth_url = http://RADOSGW_IP:8000/auth/v1 If the :ref:`direct-deploy` is being used, edit ``/etc/glance/glance-api.conf`` to store the instance images in respective object store (radosgw or swift) as well:: [glance_store] ... swift_store_user = USERNAME swift_store_key = PASSWORD swift_store_auth_address = http://RADOSGW_OR_SWIFT_IP:PORT/auth/v1 Accessing the configuration drive data -------------------------------------- When the configuration drive is enabled, the Bare Metal service will create a partition on the instance disk and write the configuration drive image onto it. The configuration drive must be mounted before use. This is performed automatically by many tools, such as cloud-init and cloudbase-init. To mount it manually on a Linux distribution that supports accessing devices by labels, simply run the following:: mkdir -p /mnt/config mount /dev/disk/by-label/config-2 /mnt/config If the guest OS doesn't support accessing devices by labels, you can use other tools such as ``blkid`` to identify which device corresponds to the configuration drive and mount it, for example:: CONFIG_DEV=$(blkid -t LABEL="config-2" -odevice) mkdir -p /mnt/config mount $CONFIG_DEV /mnt/config .. [*] A configuration drive could also be a data block with a VFAT filesystem on it instead of ISO 9660. But it's unlikely that it would be needed since ISO 9660 is widely supported across operating systems. Cloud-init integration ---------------------- The configuration drive can be especially useful when used with `cloud-init `_, but in order to use it we should follow some rules: * ``Cloud-init`` data should be organized in the `expected format`_. * Since the Bare Metal service uses a disk partition as the configuration drive, it will only work with `cloud-init version >= 0.7.5 `_. * ``Cloud-init`` has a collection of data source modules, so when building the image with `disk-image-builder`_ we have to define ``DIB_CLOUD_INIT_DATASOURCES`` environment variable and set the appropriate sources to enable the configuration drive, for example:: DIB_CLOUD_INIT_DATASOURCES="ConfigDrive, OpenStack" disk-image-create -o fedora-cloud-image fedora baremetal For more information see `how to configure cloud-init data sources `_. .. _`expected format`: https://docs.openstack.org/nova/latest/user/vendordata.html .. _disk-image-builder: https://docs.openstack.org/diskimage-builder/latest/ ironic-10.1.1/doc/source/install/standalone.rst0000666000175100017510000002023213243617471021507 0ustar zuulzuul00000000000000 Using Bare Metal service as a standalone service ================================================ It is possible to use the Bare Metal service without other OpenStack services. You should make the following changes to ``/etc/ironic/ironic.conf``: #. To disable usage of Identity service tokens:: [DEFAULT] ... auth_strategy=noauth #. If you want to disable the Networking service, you should have your network pre-configured to serve DHCP and TFTP for machines that you're deploying. To disable it, change the following lines:: [dhcp] ... dhcp_provider=none .. note:: If you disabled the Networking service and the driver that you use is supported by at most one conductor, PXE boot will still work for your nodes without any manual config editing. This is because you know all the DHCP options that will be used for deployment and can set up your DHCP server appropriately. If you have multiple conductors per driver, it would be better to use Networking since it will do all the dynamically changing configurations for you. If you don't use Image service, it's possible to provide images to Bare Metal service via a URL. .. note:: At the moment, only two types of URLs are acceptable instead of Image service UUIDs: HTTP(S) URLs (for example, "http://my.server.net/images/img") and file URLs (file:///images/img). There are however some limitations for different hardware interfaces: * If you're using :ref:`direct-deploy`, you have to provide the Bare Metal service with the MD5 checksum of your instance image. To compute it, you can use the following command:: md5sum image.qcow2 ed82def8730f394fb85aef8a208635f6 image.qcow2 * :ref:`direct-deploy` requires the instance image be accessible through a HTTP(s) URL. * Some :doc:`boot interfaces ` (for example, ``ilo-virtual-media``) require the Object Storage service, as these drivers need to store floppy image that is used to pass parameters to deployment iso. For this method also only HTTP(S) URLs are acceptable, as HP iLO servers cannot attach other types of URLs as virtual media. Steps to start a deployment are pretty similar to those when using Compute: #. To use the `openstack baremetal CLI `_, set up these environment variables. Since no authentication strategy is being used, the value can be any string for OS_TOKEN. OS_URL is the URL of the ironic-api process. For example:: export OS_TOKEN=fake-token export OS_URL=http://localhost:6385/ #. Create a node in Bare Metal service. At minimum, you must specify the driver name (for example, ``ipmi``). You can also specify all the required driver parameters in one command. This will return the node UUID:: openstack baremetal node create --driver ipmi \ --driver-info ipmi_address=ipmi.server.net \ --driver-info ipmi_username=user \ --driver-info ipmi_password=pass \ --driver-info deploy_kernel=file:///images/deploy.vmlinuz \ --driver-info deploy_ramdisk=http://my.server.net/images/deploy.ramdisk +--------------+--------------------------------------------------------------------------+ | Property | Value | +--------------+--------------------------------------------------------------------------+ | uuid | be94df40-b80a-4f63-b92b-e9368ee8d14c | | driver_info | {u'deploy_ramdisk': u'http://my.server.net/images/deploy.ramdisk', | | | u'deploy_kernel': u'file:///images/deploy.vmlinuz', u'ipmi_address': | | | u'ipmi.server.net', u'ipmi_username': u'user', u'ipmi_password': | | | u'******'} | | extra | {} | | driver | ipmi | | chassis_uuid | | | properties | {} | +--------------+--------------------------------------------------------------------------+ Note that here deploy_kernel and deploy_ramdisk contain links to images instead of Image service UUIDs. #. As in case of Compute service, you can also provide ``capabilities`` to node properties, but they will be used only by Bare Metal service (for example, boot mode). Although you don't need to add properties like ``memory_mb``, ``cpus`` etc. as Bare Metal service will require UUID of a node you're going to deploy. #. Then create a port to inform Bare Metal service of the network interface cards which are part of the node by creating a port with each NIC's MAC address. In this case, they're used for naming of PXE configs for a node:: openstack baremetal port create $MAC_ADDRESS --node $NODE_UUID #. You also need to specify some fields in the node's ``instance_info``: * ``image_source`` - URL of the whole disk or root partition image, mandatory. For :ref:`direct-deploy` only HTTP(s) links are accepted, while :ref:`iscsi-deploy` also accepts links to local files (prefixed with ``file://``). * ``root_gb`` - size of the root partition, mandatory. .. TODO(dtantsur): root_gb should not be mandatory for whole disk images, but it seems to be. * ``image_checksum`` - MD5 checksum of the image specified by ``image_source``, only required for :ref:`direct-deploy`. * ``kernel``, ``ramdisk`` - HTTP(s) or file URLs of the kernel and initramfs of the target OS, only required for partition images. For example:: openstack baremetal node set $NODE_UUID \ --instance-info image_source=$IMG \ --instance-info image_checksum=$MD5HASH \ --instance-info kernel=$KERNEL \ --instance-info ramdisk=$RAMDISK \ --instance-info root_gb=10 #. Validate that all parameters are correct:: openstack baremetal node validate $NODE_UUID +------------+--------+----------------------------------------------------------------+ | Interface | Result | Reason | +------------+--------+----------------------------------------------------------------+ | boot | True | | | console | False | Missing 'ipmi_terminal_port' parameter in node's driver_info. | | deploy | True | | | inspect | True | | | management | True | | | network | True | | | power | True | | | raid | True | | | storage | True | | +------------+--------+----------------------------------------------------------------+ #. Now you can start the deployment, run:: openstack baremetal node deploy $NODE_UUID For iLO drivers, fields that should be provided are: * ``ilo_deploy_iso`` under ``driver_info``; * ``ilo_boot_iso``, ``image_source``, ``root_gb`` under ``instance_info``. .. note:: The Bare Metal service tracks content changes for non-Glance images by checking their modification date and time. For example, for HTTP image, if 'Last-Modified' header value from response to a HEAD request to "http://my.server.net/images/deploy.ramdisk" is greater than cached image modification time, Ironic will re-download the content. For "file://" images, the file system modification time is used. Other references ---------------- * :ref:`local-boot-without-compute` ironic-10.1.1/doc/source/install/install-obs.rst0000666000175100017510000000222613243617463021612 0ustar zuulzuul00000000000000.. _install-obs: ============================================================ Install and configure for openSUSE and SUSE Linux Enterprise ============================================================ This section describes how to install and configure the Bare Metal service for openSUSE Leap 42.2 and SUSE Linux Enterprise Server 12 SP2. .. note:: Installation of the Bare Metal service on openSUSE and SUSE Linux Enterprise Server is not officially supported. Nevertheless, installation should be possible. .. include:: include/common-prerequisites.inc Install and configure components ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #. Install from packages .. code-block:: console # zypper install openstack-ironic-api openstack-ironic-conductor python-ironicclient #. Enable services .. code-block:: console # systemctl enable openstack-ironic-api openstack-ironic-conductor # systemctl start openstack-ironic-api openstack-ironic-conductor .. include:: include/common-configure.inc .. include:: include/configure-ironic-api.inc .. include:: include/configure-ironic-api-mod_wsgi.inc .. include:: include/configure-ironic-conductor.inc ironic-10.1.1/doc/source/install/setup-drivers.rst0000666000175100017510000000030513243617463022173 0ustar zuulzuul00000000000000Set up the drivers for the Bare Metal service ============================================= .. toctree:: :maxdepth: 1 enabling-drivers configure-pxe configure-ipmi configure-iscsi ironic-10.1.1/doc/source/install/deploy-ramdisk.rst0000666000175100017510000000557713243617463022323 0ustar zuulzuul00000000000000.. _deploy-ramdisk: Building or downloading a deploy ramdisk image ============================================== Ironic depends on having an image with the ironic-python-agent_ (IPA) service running on it for controlling and deploying bare metal nodes. You can download a pre-built version of the deploy ramdisk built with the `CoreOS tools`_ at: * `CoreOS deploy kernel `_ * `CoreOS deploy ramdisk `_ .. _ironic-python-agent: https://docs.openstack.org/ironic-python-agent/latest/ Building from source -------------------- There are two known methods for creating the deployment image with the IPA service: .. _BuildingCoreOSDeployRamdisk: CoreOS tools ~~~~~~~~~~~~ #. Clone the ironic-python-agent_ project:: git clone https://git.openstack.org/openstack/ironic-python-agent #. Install the requirements:: Fedora 21/RHEL7/CentOS7: sudo yum install docker gzip util-linux cpio findutils grep gpg Fedora 22 or higher: sudo dnf install docker gzip util-linux cpio findutils grep gpg Ubuntu 14.04 (trusty) or higher: sudo apt-get install docker.io gzip uuid-runtime cpio findutils grep gnupg cgroup-lite SUSE: sudo zypper install docker gzip util-linux cpio findutils grep gpg2 #. Change directory to ``imagebuild/coreos``:: cd ironic-python-agent/imagebuild/coreos #. Start the docker daemon:: Fedora/RHEL7/CentOS7/SUSE: sudo systemctl start docker Ubuntu: sudo service docker start #. Create the image:: sudo make #. Or, create an ISO image to boot with virtual media:: sudo make iso .. note:: Once built the deploy ramdisk and kernel will appear inside of a directory called ``UPLOAD``. .. _BuildingDibBasedDeployRamdisk: disk-image-builder ~~~~~~~~~~~~~~~~~~ #. Follow `diskimage-builder installation documentation`_ to install diskimage-builder. #. Create the image:: disk-image-create ironic-agent fedora -o ironic-deploy The above command creates the deploy ramdisk and kernel named ``ironic-deploy.vmlinuz`` and ``ironic-deploy.initramfs`` in your current directory. #. Or, create an ISO image to boot with virtual media:: disk-image-create ironic-agent fedora iso -o ironic-deploy The above command creates the deploy ISO named ``ironic-deploy.iso`` in your current directory. .. note:: Fedora was used as an example for the base operational system. Please check the `diskimage-builder documentation`_ for other supported operational systems. .. _`diskimage-builder documentation`: https://docs.openstack.org/diskimage-builder/latest/ .. _`diskimage-builder installation documentation`: https://docs.openstack.org/diskimage-builder/latest/user_guide/installation.html ironic-10.1.1/doc/source/install/configure-compute.rst0000666000175100017510000001671313243617463023024 0ustar zuulzuul00000000000000Configure the Compute service to use the Bare Metal service ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Compute service needs to be configured to use the Bare Metal service's driver. The configuration file for the Compute service is typically located at ``/etc/nova/nova.conf``. .. note:: As of the Newton release, it is possible to have multiple nova-compute services running the ironic virtual driver (in nova) to provide redundancy. Bare metal nodes are mapped to the services via a hash ring. If a service goes down, the available bare metal nodes are remapped to different services. Once active, a node will stay mapped to the same nova-compute even when it goes down. The node is unable to be managed through the Compute API until the service responsible returns to an active state. The following configuration file must be modified on the Compute service's controller nodes and compute nodes. #. Change these configuration options in the Compute service configuration file (for example, ``/etc/nova/nova.conf``): .. code-block:: ini [default] # Defines which driver to use for controlling virtualization. # Enable the ironic virt driver for this compute instance. compute_driver=ironic.IronicDriver # Firewall driver to use with nova-network service. # Ironic supports only neutron, so set this to noop. firewall_driver=nova.virt.firewall.NoopFirewallDriver # Amount of memory in MB to reserve for the host so that it is always # available to host processes. # It is impossible to reserve any memory on bare metal nodes, so set # this to zero. reserved_host_memory_mb=0 [filter_scheduler] # Enables querying of individual hosts for instance information. # Not possible for bare metal nodes, so set it to False. track_instance_changes=False [scheduler] # This value controls how often (in seconds) the scheduler should # attempt to discover new hosts that have been added to cells. # If negative (the default), no automatic discovery will occur. # As each bare metal node is represented by a separate host, it has # to be discovered before the Compute service can deploy on it. # The value here has to be carefully chosen based on a compromise # between the enrollment speed and the load on the Compute scheduler. # The recommended value of 2 minutes matches how often the Compute # service polls the Bare Metal service for node information. discover_hosts_in_cells_interval=120 .. note:: The alternative to setting the ``discover_hosts_in_cells_interval`` option is to run the following command on any Compute controller node after each node is enrolled:: nova-manage cell_v2 discover_hosts #. If you have not switched to make use of :ref:`scheduling-resource-classes`, then the following options should be set as well. They must be removed from the configuration file after switching to resource classes. .. code-block:: ini [scheduler] # Use the ironic scheduler host manager. This host manager will consume # all CPUs, disk space, and RAM from a host as bare metal hosts, can not # be subdivided into multiple instances. Scheduling based on resource # classes does not use CPU/disk/RAM, so the default host manager can be # used in such cases. host_manager=ironic_host_manager [filter_scheduler] # Size of subset of best hosts selected by scheduler. # New instances will be scheduled on a host chosen randomly from a # subset of the 999 hosts. The big value is used to avoid race # conditions, when several instances are scheduled on the same bare # metal nodes. This is not a problem when resource classes are used. # You should carefully consider increasing this option from its # default value of 1 in mixed hypervisor case, as placement # of virtual instances will become less optimal. host_subset_size=999 # This flag enables a different set of scheduler filters, which is more # suitable for bare metals. CPU, disk and memory filters are replaced # with their exact counterparts, to make sure only nodes strictly # matching the flavor are picked. These filters do not work with # scheduling based on resource classes only. # You must not enable this option if you have compute hosts # with other than 'ironic' drivers as enabling it will make scheduling # of virtual instances problematic. use_baremetal_filters=True #. Consider enabling the following option on controller nodes: .. code-block:: ini [filter_scheduler] # Enabling this option is beneficial as it reduces re-scheduling events # for ironic nodes when scheduling is based on resource classes, # especially for mixed hypervisor case with host_subset_size = 1. # However enabling it will also make packing of VMs on hypervisors # less dense even when scheduling weights are completely disabled. #shuffle_best_same_weighed_hosts = false #. Carefully consider the following option: .. code-block:: ini [compute] # This option will cause nova-compute to set itself to a disabled state # if a certain number of consecutive build failures occur. This will # prevent the scheduler from continuing to send builds to a compute # service that is consistently failing. In the case of bare metal # provisioning, however, a compute service is rarely the cause of build # failures. Furthermore, bare metal nodes, managed by a disabled # compute service, will be remapped to a different one. That may cause # the second compute service to also be disabled, and so on, until no # compute services are active. # If this is not the desired behavior, consider increasing this value or # setting it to 0 to disable this behavior completely. #consecutive_build_service_disable_threshold = 10 #. Change these configuration options in the ``ironic`` section. Replace: - ``IRONIC_PASSWORD`` with the password you chose for the ``ironic`` user in the Identity Service - ``IRONIC_NODE`` with the hostname or IP address of the ironic-api node - ``IDENTITY_IP`` with the IP of the Identity server .. code-block:: ini [ironic] # Ironic authentication type auth_type=password # Keystone API endpoint auth_url=http://IDENTITY_IP:35357/v3 # Ironic keystone project name project_name=service # Ironic keystone admin name username=ironic # Ironic keystone admin password password=IRONIC_PASSWORD # Ironic keystone project domain # or set project_domain_id project_domain_name=Default # Ironic keystone user domain # or set user_domain_id user_domain_name=Default #. On the Compute service's controller nodes, restart the ``nova-scheduler`` process: .. code-block:: console Fedora/RHEL7/CentOS7/SUSE: sudo systemctl restart openstack-nova-scheduler Ubuntu: sudo service nova-scheduler restart #. On the Compute service's compute nodes, restart the ``nova-compute`` process: .. code-block:: console Fedora/RHEL7/CentOS7/SUSE: sudo systemctl restart openstack-nova-compute Ubuntu: sudo service nova-compute restart ironic-10.1.1/doc/source/install/install-rdo.rst0000666000175100017510000000216513243617463021615 0ustar zuulzuul00000000000000.. _install-rdo: ============================================================= Install and configure for Red Hat Enterprise Linux and CentOS ============================================================= This section describes how to install and configure the Bare Metal service for Red Hat Enterprise Linux 7 and CentOS 7. .. include:: include/common-prerequisites.inc Install and configure components ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #. Install from packages - Using ``dnf`` .. code-block:: console # dnf install openstack-ironic-api openstack-ironic-conductor python-ironicclient - Using ``yum`` .. code-block:: console # yum install openstack-ironic-api openstack-ironic-conductor python-ironicclient #. Enable services .. code-block:: console # systemctl enable openstack-ironic-api openstack-ironic-conductor # systemctl start openstack-ironic-api openstack-ironic-conductor .. include:: include/common-configure.inc .. include:: include/configure-ironic-api.inc .. include:: include/configure-ironic-api-mod_wsgi.inc .. include:: include/configure-ironic-conductor.inc ironic-10.1.1/doc/source/index.rst0000666000175100017510000000456413243617463017033 0ustar zuulzuul00000000000000================================== Welcome to Ironic's documentation! ================================== Introduction ============ Ironic is an OpenStack project which provisions bare metal (as opposed to virtual) machines. It may be used independently or as part of an OpenStack Cloud, and integrates with the OpenStack Identity (keystone), Compute (nova), Network (neutron), Image (glance), and Object (swift) services. The Bare Metal service manages hardware through both common (eg. PXE and IPMI) and vendor-specific remote management protocols. It provides the cloud operator with a unified interface to a heterogeneous fleet of servers while also providing the Compute service with an interface that allows physical servers to be managed as though they were virtual machines. This documentation is continually updated and may not represent the state of the project at any specific prior release. To access documentation for a previous release of ironic, append the OpenStack release name to the URL; for example, the ``ocata`` release is available at https://docs.openstack.org/ironic/ocata/. Installation Guide ================== .. toctree:: :maxdepth: 2 install/index Upgrade Guide ============= .. toctree:: :maxdepth: 2 admin/upgrade-guide admin/upgrade-to-hardware-types User Guide ========== .. toctree:: :maxdepth: 2 user/index Administrator Guide =================== .. toctree:: :maxdepth: 2 admin/index Configuration Guide =================== .. toctree:: :maxdepth: 2 configuration/index Bare Metal API References ========================= Ironic's REST API has changed since its first release, and continues to evolve to meet the changing needs of the community. Here we provide a conceptual guide as well as more detailed reference documentation. .. toctree:: :maxdepth: 1 API Concept Guide API Reference (latest) API Version History Command References ================== Here are references for commands not elsewhere documented. .. toctree:: :maxdepth: 2 cli/index Contributor Guide ================= .. toctree:: :maxdepth: 2 contributor/index Release Notes ============= `Release Notes `_ Indices and tables ================== * :ref:`genindex` * :ref:`search` ironic-10.1.1/doc/source/cli/0000775000175100017510000000000013243617733015726 5ustar zuulzuul00000000000000ironic-10.1.1/doc/source/cli/index.rst0000666000175100017510000000022013243617463017563 0ustar zuulzuul00000000000000Command References ================== Here are references for commands not elsewhere documented. .. toctree:: :maxdepth: 1 ironic-dbsync ironic-10.1.1/doc/source/cli/ironic-dbsync.rst0000666000175100017510000001430113243617463021224 0ustar zuulzuul00000000000000============= ironic-dbsync ============= The :command:`ironic-dbsync` utility is used to create the database schema tables that the ironic services will use for storage. It can also be used to upgrade existing database tables when migrating between different versions of ironic. The `Alembic library `_ is used to perform the database migrations. Options ======= This is a partial list of the most useful options. To see the full list, run the following:: ironic-dbsync --help .. program:: ironic-dbsync .. option:: -h, --help Show help message and exit. .. option:: --config-dir Path to a config directory with configuration files. .. option:: --config-file Path to a configuration file to use. .. option:: -d, --debug Print debugging output. .. option:: --version Show the program's version number and exit. .. option:: upgrade, stamp, revision, version, create_schema, online_data_migrations The :ref:`command ` to run. Usage ===== Options for the various :ref:`commands ` for :command:`ironic-dbsync` are listed when the :option:`-h` or :option:`--help` option is used after the command. For example:: ironic-dbsync create_schema --help Information about the database is read from the ironic configuration file used by the API server and conductor services. This file must be specified with the :option:`--config-file` option:: ironic-dbsync --config-file /path/to/ironic.conf create_schema The configuration file defines the database backend to use with the *connection* database option:: [database] connection=mysql+pymysql://root@localhost/ironic If no configuration file is specified with the :option:`--config-file` option, :command:`ironic-dbsync` assumes an SQLite database. .. _dbsync_cmds: Command Options =============== :command:`ironic-dbsync` is given a command that tells the utility what actions to perform. These commands can take arguments. Several commands are available: .. _create_schema: create_schema ------------- .. program:: create_schema .. option:: -h, --help Show help for create_schema and exit. This command will create database tables based on the most current version. It assumes that there are no existing tables. An example of creating database tables with the most recent version:: ironic-dbsync --config-file=/etc/ironic/ironic.conf create_schema online_data_migrations ---------------------- .. program:: online_data_migrations .. option:: -h, --help Show help for online_data_migrations and exit. .. option:: --max-count The maximum number of objects (a positive value) to migrate. Optional. If not specified, all the objects will be migrated (in batches of 50 to avoid locking the database for long periods of time). .. option:: --option If a migration accepts additional parameters, they can be passed via this argument. It can be specified several times. This command will migrate objects in the database to their most recent versions. This command must be successfully run (return code 0) before upgrading to a future release. It returns: * 1 (not completed) if there are still pending objects to be migrated. Before upgrading to a newer release, this command must be run until 0 is returned. * 0 (success) after migrations are finished or there are no data to migrate * 127 (error) if max-count is not a positive value or an option is invalid * 2 (error) if the database is not compatible with this release. This command needs to be run using the previous release of ironic, before upgrading and running it with this release. revision -------- .. program:: revision .. option:: -h, --help Show help for revision and exit. .. option:: -m , --message The message to use with the revision file. .. option:: --autogenerate Compares table metadata in the application with the status of the database and generates migrations based on this comparison. This command will create a new revision file. You can use the :option:`--message` option to comment the revision. This is really only useful for ironic developers making changes that require database changes. This revision file is used during database migration and will specify the changes that need to be made to the database tables. Further discussion is beyond the scope of this document. stamp ----- .. program:: stamp .. option:: -h, --help Show help for stamp and exit. .. option:: --revision The revision number. This command will 'stamp' the revision table with the version specified with the :option:`--revision` option. It will not run any migrations. upgrade ------- .. program:: upgrade .. option:: -h, --help Show help for upgrade and exit. .. option:: --revision The revision number to upgrade to. This command will upgrade existing database tables to the most recent version, or to the version specified with the :option:`--revision` option. Before this ``upgrade`` is invoked, the command :command:`ironic-dbsync online_data_migrations` must have been successfully run using the previous version of ironic (if you are doing an upgrade as opposed to a new installation of ironic). If it wasn't run, the database will not be compatible with this recent version of ironic, and this command will return 2 (error). If there are no existing tables, then new tables are created, beginning with the oldest known version, and successively upgraded using all of the database migration files, until they are at the specified version. Note that this behavior is different from the :ref:`create_schema` command that creates the tables based on the most recent version. An example of upgrading to the most recent table versions:: ironic-dbsync --config-file=/etc/ironic/ironic.conf upgrade .. note:: This command is the default if no command is given to :command:`ironic-dbsync`. .. warning:: The upgrade command is not compatible with SQLite databases since it uses ALTER TABLE commands to upgrade the database tables. SQLite supports only a limited subset of ALTER TABLE. version ------- .. program:: version .. option:: -h, --help Show help for version and exit. This command will output the current database version. ironic-10.1.1/doc/source/conf.py0000666000175100017510000001114713243617463016464 0ustar zuulzuul00000000000000# -*- coding: utf-8 -*- # Licensed under the Apache License, Version 2.0 (the "License"); you may # not use this file except in compliance with the License. You may obtain # a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, WITHOUT # WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the # License for the specific language governing permissions and limitations # under the License. import eventlet # NOTE(dims): monkey patch subprocess to prevent failures in latest eventlet # See https://github.com/eventlet/eventlet/issues/398 try: eventlet.monkey_patch(subprocess=True) except TypeError: pass # -- General configuration ---------------------------------------------------- # Add any Sphinx extension module names here, as strings. They can be # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom ones. extensions = ['sphinx.ext.autodoc', 'sphinx.ext.viewcode', 'sphinx.ext.graphviz', 'sphinxcontrib.httpdomain', 'sphinxcontrib.pecanwsme.rest', 'sphinxcontrib.seqdiag', 'wsmeext.sphinxext', 'oslo_config.sphinxext', 'oslo_config.sphinxconfiggen', 'oslo_policy.sphinxext', 'oslo_policy.sphinxpolicygen', ] try: import openstackdocstheme extensions.append('openstackdocstheme') except ImportError: openstackdocstheme = None repository_name = 'openstack/ironic' bug_project = 'ironic' bug_tag = '' html_last_updated_fmt = '%Y-%m-%d %H:%M' wsme_protocols = ['restjson'] # autodoc generation is a bit aggressive and a nuisance when doing heavy # text edit cycles. # execute "export SPHINX_DEBUG=1" in your terminal to disable # Add any paths that contain templates here, relative to this directory. templates_path = ['_templates'] # The suffix of source filenames. source_suffix = '.rst' # The master toctree document. master_doc = 'index' # General information about the project. project = u'Ironic' copyright = u'OpenStack Foundation' config_generator_config_file = '../../tools/config/ironic-config-generator.conf' sample_config_basename = '_static/ironic' policy_generator_config_file = '../../tools/policy/ironic-policy-generator.conf' sample_policy_basename = '_static/ironic' # The version info for the project you're documenting, acts as replacement for # |version| and |release|, also used in various other places throughout the # built documents. # # The short X.Y version. from ironic import version as ironic_version # The full version, including alpha/beta/rc tags. release = ironic_version.version_info.release_string() # The short X.Y version. version = ironic_version.version_info.version_string() # A list of ignored prefixes for module index sorting. modindex_common_prefix = ['ironic.'] # If true, '()' will be appended to :func: etc. cross-reference text. add_function_parentheses = True # If true, the current module name will be prepended to all description # unit titles (such as .. function::). add_module_names = True # The name of the Pygments (syntax highlighting) style to use. pygments_style = 'sphinx' # A list of glob-style patterns that should be excluded when looking for # source files. They are matched against the source file names relative to the # source directory, using slashes as directory separators on all platforms. exclude_patterns = ['api/ironic.drivers.modules.ansible.playbooks.*', 'api/ironic.tests.*'] # Ignore the following warning: WARNING: while setting up extension # wsmeext.sphinxext: directive 'autoattribute' is already registered, # it will be overridden. suppress_warnings = ['app.add_directive'] # -- Options for HTML output -------------------------------------------------- # The theme to use for HTML and HTML Help pages. Major themes that come with # Sphinx are currently 'default' and 'sphinxdoc'. if openstackdocstheme is not None: html_theme = 'openstackdocs' else: html_theme = 'default' # Output file base name for HTML help builder. htmlhelp_basename = '%sdoc' % project # Grouping the document tree into LaTeX files. List of tuples # (source start file, target name, title, author, documentclass # [howto/manual]). latex_documents = [ ( 'index', '%s.tex' % project, u'%s Documentation' % project, u'OpenStack Foundation', 'manual' ), ] # -- Options for seqdiag ------------------------------------------------------ seqdiag_html_image_format = "SVG" ironic-10.1.1/doc/source/contributor/0000775000175100017510000000000013243617733017531 5ustar zuulzuul00000000000000ironic-10.1.1/doc/source/contributor/drivers.rst0000666000175100017510000001774113243617463021755 0ustar zuulzuul00000000000000.. _pluggable_drivers: ================= Pluggable Drivers ================= Ironic supports a pluggable driver model. This allows contributors to easily add new drivers, and operators to use third-party drivers or write their own. A driver is built at runtime from a *hardware type* and *hardware interfaces*. See :doc:`/install/enabling-drivers` for a detailed explanation of these concepts. Hardware types and interfaces are loaded by the ``ironic-conductor`` service during initialization from the setuptools entrypoints ``ironic.hardware.types`` and ``ironic.hardware.interfaces.`` where ```` is an interface type (for example, ``deploy``). Only hardware types listed in the configuration option ``enabled_hardware_types`` and interfaces listed in configuration options ``enabled__interfaces`` are loaded. A complete list of hardware types available on the system may be found by enumerating this entrypoint by running the following python script:: #!/usr/bin/env python import pkg_resources as pkg print [p.name for p in pkg.iter_entry_points("ironic.hardware.types") if not p.name.startswith("fake")] A list of drivers enabled in a running Ironic service may be found by issuing the following command against that API end point:: openstack baremetal driver list .. note:: This listing also includes *classic drivers* which are deprecated and are not covered by this guide. Writing a hardware type ----------------------- A hardware type is a Python class, inheriting :py:class:`ironic.drivers.hardware_type.AbstractHardwareType` and listed in the setuptools entry point ``ironic.hardware.types``. Most of the real world hardware types inherit :py:class:`ironic.drivers.generic.GenericHardware` instead. This helper class provides useful implementations for interfaces that are usually the same for all hardware types, such as ``deploy``. The minimum required interfaces are: * :doc:`boot ` that specifies how to boot ramdisks and instances on the hardware. A generic ``pxe`` implementation is provided by the ``GenericHardware`` base class. * :doc:`deploy ` that orchestrates the deployment. A few common implementations are provided by the ``GenericHardware`` base class. .. note:: Most of the hardware types should not override this interface. * `power` implements power actions for the hardware. These common implementations may be used, if supported by the hardware: * :py:class:`ironic.drivers.modules.ipmitool.IPMIPower` * :py:class:`ironic.drivers.modules.redfish.power.RedfishPower` Otherwise, you need to write your own implementation by subclassing :py:class:`ironic.drivers.base.PowerInterface` and providing missing methods. .. note:: Power actions in Ironic are blocking - methods of a power interface should not return until the power action is finished or errors out. * `management` implements additional out-of-band management actions, such as setting a boot device. A few common implementations exist and may be used, if supported by the hardware: * :py:class:`ironic.drivers.modules.ipmitool.IPMIManagement` * :py:class:`ironic.drivers.modules.redfish.management.RedfishManagement` Some hardware types, such as ``snmp`` do not support out-of-band management. They use the fake implementation in :py:class:`ironic.drivers.modules.fake.FakeManagement` instead. Otherwise, you need to write your own implementation by subclassing :py:class:`ironic.drivers.base.ManagementInterface` and providing missing methods. Combine the interfaces in a hardware type by populating the lists of supported interfaces. These lists are prioritized, with the most preferred implementation first. For example: .. code-block:: python class MyHardware(generic.GenericHardware): @property def supported_management_interfaces(self): """List of supported management interfaces.""" return [MyManagement, ipmitool.IPMIManagement] @property def supported_power_interfaces(self): """List of supported power interfaces.""" return [MyPower, ipmitool.IPMIPower] .. note:: In this example, all interfaces, except for ``management`` and ``power`` are taken from the ``GenericHardware`` base class. Finally, give the new hardware type and new interfaces human-friendly names and create entry points for them in the ``setup.cfg`` file:: ironic.hardware.types = my-hardware = ironic.drivers.my_hardware:MyHardware ironic.hardware.interfaces.power = my-power = ironic.drivers.modules.my_hardware:MyPower ironic.hardware.interfaces.management = my-management = ironic.drivers.modules.my_hardware:MyManagement Supported Drivers ----------------- For a list of supported drivers (those that are continuously tested on every upstream commit) please consult the wiki page:: https://wiki.openstack.org/wiki/Ironic/Drivers Node Vendor Passthru -------------------- Drivers may implement a passthrough API, which is accessible via the ``/v1/nodes//vendor_passthru?method={METHOD}`` endpoint. Beyond basic checking, Ironic does not introspect the message body and simply "passes it through" to the relevant driver. A method: * can support one or more HTTP methods (for example, GET, POST) * is asynchronous or synchronous + For asynchronous methods, a 202 (Accepted) HTTP status code is returned to indicate that the request was received, accepted and is being acted upon. No body is returned in the response. + For synchronous methods, a 200 (OK) HTTP status code is returned to indicate that the request was fulfilled. The response may include a body. * can require an exclusive lock on the node. This only occurs if the method doesn't specify require_exclusive_lock=False in the decorator. If an exclusive lock is held on the node, other requests for the node will be delayed and may fail with an HTTP 409 (Conflict) error code. This endpoint exposes a node's driver directly, and as such, it is expressly not part of Ironic's standard REST API. There is only a single HTTP endpoint exposed, and the semantics of the message body are determined solely by the driver. Ironic makes no guarantees about backwards compatibility; this is solely up to the discretion of each driver's author. To get information about all the methods available via the vendor_passthru endpoint for a particular node, you can issue an HTTP GET request:: GET /v1/nodes//vendor_passthru/methods The response's JSON body will contain information for each method, such as the method's name, a description, the HTTP methods supported, and whether it's asynchronous or synchronous. Driver Vendor Passthru ---------------------- Drivers may implement an API for requests not related to any node, at ``/v1/drivers//vendor_passthru?method={METHOD}``. A method: * can support one or more HTTP methods (for example, GET, POST) * is asynchronous or synchronous + For asynchronous methods, a 202 (Accepted) HTTP status code is returned to indicate that the request was received, accepted and is being acted upon. No body is returned in the response. + For synchronous methods, a 200 (OK) HTTP status code is returned to indicate that the request was fulfilled. The response may include a body. .. note:: Unlike methods in `Node Vendor Passthru`_, a request does not lock any resource, so it will not delay other requests and will not fail with an HTTP 409 (Conflict) error code. Ironic makes no guarantees about the semantics of the message BODY sent to this endpoint. That is left up to each driver's author. To get information about all the methods available via the driver vendor_passthru endpoint, you can issue an HTTP GET request:: GET /v1/drivers//vendor_passthru/methods The response's JSON body will contain information for each method, such as the method's name, a description, the HTTP methods supported, and whether it's asynchronous or synchronous. ironic-10.1.1/doc/source/contributor/ironic-boot-from-volume.rst0000666000175100017510000001003113243617463024752 0ustar zuulzuul00000000000000===================================== Ironic Boot-from-Volume with DevStack ===================================== This guide shows how to setup DevStack for enabling boot-from-volume feature, which has been supported from the Pike release. This scenario shows how to setup DevStack to enable nodes to boot from volumes managed by cinder with VMs as baremetal servers. DevStack Configuration ====================== The following is ``local.conf`` that will setup DevStack with 3 VMs that are registered in ironic. A volume connector with IQN is created for each node. These connectors can be used to connect volumes created by cinder. The detailed description for DevStack is at :ref:`deploy_devstack`. :: [[local|localrc]] enable_plugin ironic git://git.openstack.org/openstack/ironic IRONIC_STORAGE_INTERFACE=cinder # Credentials ADMIN_PASSWORD=password DATABASE_PASSWORD=password RABBIT_PASSWORD=password SERVICE_PASSWORD=password SERVICE_TOKEN=password SWIFT_HASH=password SWIFT_TEMPURL_KEY=password # Enable Neutron which is required by Ironic and disable nova-network. disable_service n-net disable_service n-novnc enable_service q-svc enable_service q-agt enable_service q-dhcp enable_service q-l3 enable_service q-meta enable_service neutron # Enable Swift for the direct deploy interface. enable_service s-proxy enable_service s-object enable_service s-container enable_service s-account # Disable Horizon disable_service horizon # Disable Heat disable_service heat h-api h-api-cfn h-api-cw h-eng # Swift temp URL's are required for the direct deploy interface. SWIFT_ENABLE_TEMPURLS=True # Create 3 virtual machines to pose as Ironic's baremetal nodes. IRONIC_VM_COUNT=3 IRONIC_BAREMETAL_BASIC_OPS=True DEFAULT_INSTANCE_TYPE=baremetal # Enable additional hardware types, if needed. #IRONIC_ENABLED_HARDWARE_TYPES=ipmi,fake-hardware # Don't forget that many hardware types require enabling of additional # interfaces, most often power and management: #IRONIC_ENABLED_MANAGEMENT_INTERFACES=ipmitool,fake #IRONIC_ENABLED_POWER_INTERFACES=ipmitool,fake # The default deploy interface is 'iscsi', you can use 'direct' with #IRONIC_DEFAULT_DEPLOY_INTERFACE=direct # Change this to alter the default driver for nodes created by devstack. # This driver should be in the enabled list above. IRONIC_DEPLOY_DRIVER=ipmi # The parameters below represent the minimum possible values to create # functional nodes. IRONIC_VM_SPECS_RAM=1280 IRONIC_VM_SPECS_DISK=10 # Size of the ephemeral partition in GB. Use 0 for no ephemeral partition. IRONIC_VM_EPHEMERAL_DISK=0 # To build your own IPA ramdisk from source, set this to True IRONIC_BUILD_DEPLOY_RAMDISK=False VIRT_DRIVER=ironic # By default, DevStack creates a 10.0.0.0/24 network for instances. # If this overlaps with the hosts network, you may adjust with the # following. NETWORK_GATEWAY=10.1.0.1 FIXED_RANGE=10.1.0.0/24 FIXED_NETWORK_SIZE=256 # Log all output to files LOGFILE=$HOME/devstack.log LOGDIR=$HOME/logs IRONIC_VM_LOG_DIR=$HOME/ironic-bm-logs After the environment is built, you can create a volume with cinder and request an instance with the volume to nova:: . ~/devstack/openrc # query the image id of the default cirros image image=$(openstack image show $DEFAULT_IMAGE_NAME -f value -c id) # create keypair ssh-keygen openstack keypair create --public-key ~/.ssh/id_rsa.pub default # create volume volume=$(openstack volume create --image $image --size 1 my-volume -f value -c id) # spawn instance openstack server create --flavor baremetal --volume $volume --key-name default testing You can also run an integration test that an instance is booted from a remote volume with tempest in the environment:: cd /opt/stack/tempest tox -e all-plugin -- ironic_tempest_plugin.tests.scenario.test_baremetal_boot_from_volume ironic-10.1.1/doc/source/contributor/vendor-passthru.rst0000666000175100017510000001432113243617463023432 0ustar zuulzuul00000000000000.. _vendor-passthru: ============== Vendor Methods ============== This document is a quick tutorial on writing vendor specific methods to a driver. The first thing to note is that the Ironic API supports two vendor endpoints: A driver vendor passthru and a node vendor passthru. * The ``VendorInterface`` allows hardware types to expose a custom top-level functionality which is not specific to a Node. For example, let's say the driver `ipmi` exposed a method called `authentication_types` that would return what are the authentication types supported. It could be accessed via the Ironic API like: :: GET http://
:/v1/drivers/ipmi/vendor_passthru/authentication_types .. warning:: The Bare Metal API currently only allows to use driver passthru for the default ``vendor`` interface implementation for a given hardware type. This limitation will be lifted in the future. * The node vendor passthru allows drivers to expose custom functionality on per-node basis. For example the same driver `ipmi` exposing a method called `send_raw` that would send raw bytes to the BMC, the method also receives a parameter called `raw_bytes` which the value would be the bytes to be sent. It could be accessed via the Ironic API like: :: POST {'raw_bytes': '0x01 0x02'} http://
:/v1/nodes//vendor_passthru/send_raw Writing Vendor Methods ====================== Writing a custom vendor method in Ironic should be simple. The first thing to do is write a class inheriting from the `VendorInterface`_ class: .. code-block:: python class ExampleVendor(VendorInterface) def get_properties(self): return {} def validate(self, task, **kwargs): pass The `get_properties` is a method that all driver interfaces have, it should return a dictionary of : telling in the description whether that property is required or optional so the node can be manageable by that driver. For example, a required property for a `ipmi` driver would be `ipmi_address` which is the IP address or hostname of the node. We are returning an empty dictionary in our example to make it simpler. The `validate` method is responsible for validating the parameters passed to the vendor methods. Ironic will not introspect into what is passed to the drivers, it's up to the developers writing the vendor method to validate that data. Let's extend the `ExampleVendor` class to support two methods, the `authentication_types` which will be exposed on the driver vendor passthru endpoint; And the `send_raw` method that will be exposed on the node vendor passthru endpoint: .. code-block:: python class ExampleVendor(VendorInterface) def get_properties(self): return {} def validate(self, task, method, **kwargs): if method == 'send_raw': if 'raw_bytes' not in kwargs: raise MissingParameterValue() @base.driver_passthru(['GET'], async=False) def authentication_types(self, context, **kwargs): return {"types": ["NONE", "MD5", "MD2"]} @base.passthru(['POST']) def send_raw(self, task, **kwargs): raw_bytes = kwargs.get('raw_bytes') ... That's it! Writing a node or driver vendor passthru method is pretty much the same, the only difference is how you decorate the methods and the first parameter of the method (ignoring self). A method decorated with the `@passthru` decorator should expect a Task object as first parameter and a method decorated with the `@driver_passthru` decorator should expect a Context object as first parameter. Both decorators accept these parameters: * http_methods: A list of what the HTTP methods supported by that vendor function. To know what HTTP method that function was invoked with, a `http_method` parameter will be present in the `kwargs`. Supported HTTP methods are *POST*, *PUT*, *GET* and *PATCH*. * method: By default the method name is the name of the python function, if you want to use a different name this parameter is where this name can be set. For example: .. code-block:: python @passthru(['PUT'], method="alternative_name") def name(self, task, **kwargs): ... * description: A string containing a nice description about what that method is supposed to do. Defaults to "" (empty string). .. _VendorInterface: ../api/ironic.drivers.base.html#ironic.drivers.base.VendorInterface * async: A boolean value to determine whether this method should run asynchronously or synchronously. Defaults to True (Asynchronously). The node vendor passthru decorator (`@passthru`) also accepts the following parameter: * require_exclusive_lock: A boolean value determining whether this method should require an exclusive lock on a node between validate() and the beginning of method execution. For synchronous methods, the lock on the node would also be kept for the duration of method execution. Defaults to True. .. WARNING:: Please avoid having a synchronous method for slow/long-running operations **or** if the method does talk to a BMC; BMCs are flaky and very easy to break. .. WARNING:: Each asynchronous request consumes a worker thread in the ``ironic-conductor`` process. This can lead to starvation of the thread pool, resulting in a denial of service. Give the new vendor interface implementation a human-friendly name and create an entry point for it in the ``setup.cfg``:: ironic.hardware.interfaces.vendor = example = ironic.drivers.modules.example:ExampleVendor Finally, add it to the list of supported vendor interfaces for relevant hardware types, for example: .. code-block:: python class ExampleHardware(generic.GenericHardware): ... @property def supported_vendor_interfaces(self): return [example.ExampleVendor] Backwards Compatibility ======================= There is no requirement that changes to a vendor method be backwards compatible. However, for your users' sakes, we highly recommend that you do so. If you are changing the exceptions being raised, you might want to ensure that the same HTTP code is being returned to the user. For non-backwards compatibility, please make sure you add a release note that indicates this. ironic-10.1.1/doc/source/contributor/osprofiler-support.rst0000666000175100017510000000752013243617463024167 0ustar zuulzuul00000000000000.. _OSProfiler-support: ================ About OSProfiler ================ OSProfiler is an OpenStack cross-project profiling library. Its API provides different ways to add a new trace point. Trace points contain two messages (start and stop). Messages like below are sent to a collector:: { "name": -(start|stop), "base_id": , "parent_id": , "trace_id": , "info": } The fields are defined as follows: ``base_id`` - that is same for all trace points that belong to one trace. This is used to simplify the process of retrieving all trace points (related to one trace) from the collector. ``parent_id`` - of parent trace point. ``trace_id`` - of current trace point. ``info`` - the dictionary that contains user information passed when calling profiler start() & stop() methods. The profiler uses ceilometer as a centralized collector. Two other alternatives for ceilometer are pure MongoDB driver and Elasticsearch. A notifier is setup to send notifications to ceilometer using oslo.messaging and ceilometer API is used to retrieve all messages related to one trace. OSProfiler has entry point that allows the user to retrieve information about traces and present it in HTML/JSON using CLI. For more details see `OSProfiler – Cross-project profiling library`_. How to Use OSProfiler with Ironic in Devstack ============================================= To use or test OSProfiler in ironic, the user needs to setup Devstack with OSProfiler and ceilometer. In addition to the setup described at :ref:`deploy_devstack`, the user needs to do the following: Add the following to ``localrc`` to enable OSProfiler and ceilometer:: enable_plugin panko https://git.openstack.org/openstack/panko enable_plugin ceilometer https://git.openstack.org/openstack/ceilometer enable_plugin osprofiler https://git.openstack.org/openstack/osprofiler # Enable the following services CEILOMETER_NOTIFICATION_TOPICS=notifications,profiler ENABLED_SERVICES+=,ceilometer-acompute,ceilometer-acentral ENABLED_SERVICES+=,ceilometer-anotification,ceilometer-collector ENABLED_SERVICES+=,ceilometer-alarm-evaluator,ceilometer-alarm-notifier ENABLED_SERVICES+=,ceilometer-api Run stack.sh. Once Devstack environment is setup, edit ``ironic.conf`` to set the following profiler options and restart ironic services:: [profiler] enabled = True hmac_keys = SECRET_KEY # default value used across several OpenStack projects trace_sqlalchemy = True In order to trace ironic using OSProfiler, use openstackclient to run baremetal commands with ``--os-profile SECRET_KEY``. For example, the following will cause a to be printed after node list:: $ openstack --os-profile SECRET_KEY baremetal node list Output of the above command will include the following:: Trace ID: Display trace with command: osprofiler trace show --html The trace results can be seen using this command:: $ osprofiler trace show --html The trace results can be saved in a file with ``--out file-name`` option:: $ osprofiler trace show --html --out trace.html The trace results show the time spent in ironic-api, ironic-conductor, and db calls. More detailed db tracing is enabled if ``trace_sqlalchemy`` is set to true. Sample Trace: .. figure:: ../images/sample_trace.svg :width: 660px :align: left :alt: Sample Trace Each trace has embedded trace point details as shown below: .. figure:: ../images/sample_trace_details.svg :width: 660px :align: left :alt: Sample Trace Details References ========== - `OSProfiler – Cross-project profiling library`_ - :ref:`deploy_devstack` .. _OSProfiler – Cross-project profiling library: https://docs.openstack.org/osprofiler/latest/index.html ironic-10.1.1/doc/source/contributor/states.rst0000666000175100017510000002327113243617463021575 0ustar zuulzuul00000000000000.. _states: ====================== Ironic's State Machine ====================== State Machine Diagram ===================== The diagram below shows the provisioning states that an Ironic node goes through during the lifetime of a node. The diagram also depicts the events that transition the node to different states. Stable states are highlighted with a thicker border. All transitions from stable states are initiated by API requests. There are a few other API-initiated-transitions that are possible from non-stable states. The events for these API-initiated transitions are indicated with '(via API)'. Internally, the conductor initiates the other transitions (depicted in gray). .. figure:: ../images/states.svg :width: 660px :align: left :alt: Ironic state transitions State Descriptions ================== enroll (stable state) This is the state that all nodes start off in when created using API version 1.11 or newer. When a node is in the ``enroll`` state, the only thing ironic knows about it is that it exists, and ironic cannot take any further action by itself. Once a node has its driver/interfaces and their required information set in ``node.driver_info``, the node can be transitioned to the ``verifying`` state by setting the node's provision state using the ``manage`` verb. verifying ironic will validate that it can manage the node using the information given in ``node.driver_info`` and with either the driver/hardware type and interfaces it has been assigned. This involves going out and confirming that the credentials work to access whatever node control mechanism they talk to. manageable (stable state) Once ironic has verified that it can manage the node using the driver/interfaces and credentials passed in at node create time, the node will be transitioned to the ``manageable`` state. From ``manageable``, nodes can transition to: * ``manageable`` (through ``cleaning``) by setting the node's provision state using the ``clean`` verb. * ``manageable`` (through ``inspecting``) by setting the node's provision state using the ``inspect`` verb. * ``available`` (through ``cleaning`` if automatic cleaning is enabled) by setting the node's provision state using the ``provide`` verb. * ``active`` (through ``adopting``) by setting the node's provision state using the ``adopt`` verb. ``manageable`` is the state that a node should be moved into when any updates need to be made to it such as changes to fields in driver_info and updates to networking information on ironic ports assigned to the node. ``manageable`` is also the only stable state that can be transitioned to, from these failure states: * ``adopt failed`` * ``clean failed`` * ``inspect failed`` inspecting ``inspecting`` will utilize node introspection to update hardware-derived node properties to reflect the current state of the hardware. If introspection fails, the node will transition to ``inspect failed``. inspect failed This is the state a node will move into when inspection of the node fails. From here the node can transitioned to: * ``inspecting`` by setting the node's provision state using the ``inspect`` verb. * ``manageable`` by setting the node's provision state using the ``manage`` verb cleaning Nodes in the ``cleaning`` state are being scrubbed and reprogrammed into a known configuration. When a node is in the ``cleaning`` state it means that the conductor is executing the clean step (for out-of-band clean steps) or preparing the environment (building PXE configuration files, configuring the DHCP, etc) to boot the ramdisk for running in-band clean steps. clean wait Just like the ``cleaning`` state, the nodes in the ``clean wait`` state are being scrubbed and reprogrammed. The difference is that in the ``clean wait`` state the conductor is waiting for the ramdisk to boot or the clean step which is running in-band to finish. The cleaning process of a node in the ``clean wait`` state can be interrupted by setting the node's provision state using the ``abort`` verb if the task that is running allows it. available (stable state) After nodes have been successfully preconfigured and cleaned, they are moved into the ``available`` state and are ready to be provisioned. From ``available``, nodes can transition to: * ``active`` (through ``deploying``) by setting the node's provision state using the ``active`` verb. * ``manageable`` by setting the node's provision state using the ``manage`` verb deploying Nodes in ``deploying`` are being prepared to run a workload on them. This consists of running a series of tasks, such as: * Setting appropriate BIOS configurations * Partitioning drives and laying down file systems. * Creating any additional resources (node-specific network config, a config drive partition, etc.) that may be required by additional subsystems. wait call-back Just like the ``deploying`` state, the nodes in ``wait call-back`` are being deployed. The difference is that in ``wait call-back`` the conductor is waiting for the ramdisk to boot or execute parts of the deployment which need to run in-band on the node (for example, installing the bootloader, or writing the image to the disk). The deployment of a node in ``wait call-back`` can be interrupted by setting the node's provision state using the ``deleted`` verb. deploy failed This is the state a node will move into when a deployment fails, for example a timeout waiting for the ramdisk to PXE boot. From here the node can be transitioned to: * ``active`` (through ``deploying``) by setting the node's provision state using either the ``active`` or ``rebuild`` verbs. * ``available`` (through ``deleting`` and ``cleaning``) by setting the node's provision state using the ``deleted`` verb. active (stable state) Nodes in ``active`` have a workload running on them. ironic may collect out-of-band sensor information (including power state) on a regular basis. Nodes in ``active`` can transition to: * ``available`` (through ``deleting`` and ``cleaning``) by setting the node's provision state using the ``deleted`` verb. * ``active`` (through ``deploying``) by setting the node's provision state using the ``rebuild`` verb. * ``rescue`` (through ``rescuing``) by setting the node's provision state using the ``rescue`` verb. deleting Nodes in ``deleting`` state are being torn down from running an active workload. In ``deleting``, ironic tears down and removes any configuration and resources it added in ``deploying`` or ``rescuing``. error (stable state) This is the state a node will move into when deleting an active deployment fails. From ``error``, nodes can transition to: * ``available`` (through ``deleting`` and ``cleaning``) by setting the node's provision state using the ``deleted`` verb. adopting This state allows ironic to take over management of a baremetal node with an existing workload on it. Ordinarily when a baremetal node is enrolled and managed by ironic, it must transition through ``cleaning`` and ``deploying`` to reach ``active`` state. However, those baremetal nodes that have an existing workload on them, do not need to be deployed or cleaned again, so this transition allows these nodes to move directly from ``manageable`` to ``active``. rescuing Nodes in ``rescuing`` are being prepared to perform rescue operations. This consists of running a series of tasks, such as: * Setting appropriate BIOS configurations. * Creating any additional resources (node-specific network config, etc.) that may be required by additional subsystems. rescue wait Just like the ``rescuing`` state, the nodes in ``rescue wait`` are being rescued. The difference is that in ``rescue wait`` the conductor is waiting for the ramdisk to boot or execute parts of the rescue which need to run in-band on the node (for example, setting the password for user named ``rescue``). The rescue operation of a node in ``rescue wait`` can be aborted by setting the node's provision state using the ``abort`` verb. rescue failed This is the state a node will move into when a rescue operation fails, for example a timeout waiting for the ramdisk to PXE boot. From here the node can be transitioned to: * ``rescue`` (through ``rescuing``) by setting the node's provision state using the ``rescue`` verb. * ``active`` (through ``unrescuing``) by setting the node's provision state using the ``unrescue`` verb. * ``available`` (through ``deleting``) by setting the node's provision state using the ``deleted`` verb. rescue (stable state) Nodes in ``rescue`` have a rescue ramdisk running on them. Ironic may collect out-of-band sensor information (including power state) on a regular basis. Nodes in ``rescue`` can transition to: * ``active`` (through ``unrescuing``) by setting the node's provision state using the ``unrescue`` verb. * ``available`` (through ``deleting``) by setting the node's provision state using the ``deleted`` verb. unrescuing Nodes in ``unrescuing`` are being prepared to transition to ``active`` state from ``rescue`` state. This consists of running a series of tasks, such as setting appropriate BIOS configurations such as changing boot device. unrescue failed This is the state a node will move into when an unrescue operation fails. From here the node can be transitioned to: * ``rescue`` (through ``rescuing``) by setting the node's provision state using the ``rescue`` verb. * ``active`` (through ``unrescuing``) by setting the node's provision state using the ``unrescue`` verb. * ``available`` (through ``deleting``) by setting the node's provision state using the ``deleted`` verb. ironic-10.1.1/doc/source/contributor/third-party-ci.rst0000666000175100017510000000333713243617463023133 0ustar zuulzuul00000000000000.. _third-party-ci: ================================== Third Party Continuous Integration ================================== .. NOTE:: This document is a work-in-progress. Unfilled sections will be worked in follow-up patchsets. This version is to get a basic outline and index done so that we can then build on it. (krtaylor) This document provides tips and guidelines for third-party driver developers setting up their continuous integration test systems. CI Architecture Overview ======================== Requirements Cookbook ===================== Sizing ------ Infrastructure -------------- This section describes what changes you'll need to make to a your CI system to add an ironic job. jenkins changes ############### nodepool changes ################ neutron changes ############### pre-test hook ############# cleanup hook ############ Ironic ------ Hardware Pool Management ======================== Problem ------- If you are using actual hardware as target machines for your CI testing then the problem of two jobs trying to use the name target arises. If you have one target machine and a maximum number of one jobs running on your ironic pipeline at a time, then you won't run into this problem. However, one target may not handle the load of ironic's daily patch submissions. Solutions --------- Zuul v3 ####### Molten Iron ########### `molteniron `_ is a tool that allows you to reserve hardware from a pool at the last minute to use in your job. Once finished testing, you can unreserve the hardware making it available for the next test job. Tips and Tricks =============== Optimize Run Time ----------------- Image Server ############ Other References ---------------- ironic-10.1.1/doc/source/contributor/webapi.rst0000666000175100017510000000553213243617463021541 0ustar zuulzuul00000000000000========================= REST API Conceptual Guide ========================= Versioning ========== The ironic REST API supports two types of versioning: - "major versions", which have dedicated urls. - "microversions", which can be requested through the use of the ``X-OpenStack-Ironic-API-Version`` header. There is only one major version supported currently, "v1". As such, most URLs in this documentation are written with the "/v1/" prefix. Starting with the Kilo release, ironic supports microversions. In this context, a version is defined as a string of 2 integers separated by a dot: **X.Y**. Here ``X`` is a major version, always equal to ``1``, and ``Y`` is a minor version. Server minor version is increased every time the API behavior is changed (note `Exceptions from Versioning`_). .. note:: `Nova versioning documentation`_ has a nice guide for developers on when to bump an API version. The server indicates its minimum and maximum supported API versions in the ``X-OpenStack-Ironic-API-Minimum-Version`` and ``X-OpenStack-Ironic-API-Maximum-Version`` headers respectively, returned with every response. Client may request a specific API version by providing ``X-OpenStack-Ironic-API-Version`` header with request. The requested microversion determines both the allowable requests and the response format for all requests. A resource may be represented differently based on the requested microversion. If no version is requested by the client, the minimum supported version will be assumed. In this way, a client is only exposed to those API features that are supported in the requested (explicitly or implicitly) API version (again note `Exceptions from Versioning`_, they are not covered by this rule). We recommend clients that require a stable API to always request a specific version of API that they have been tested against. .. note:: A special value ``latest`` can be requested instead a numerical microversion, which always requests the newest supported API version from the server. .. _Nova versioning documentation: https://docs.openstack.org/nova/latest/contributor/microversions.html#when-do-i-need-a-new-microversion REST API Versions History ------------------------- .. toctree:: :maxdepth: 1 API Version History Exceptions from Versioning -------------------------- The following API-visible things are not covered by the API versioning: * Current node state is always exposed as it is, even if not supported by the requested API version, with exception of ``available`` state, which is returned in version 1.1 as ``None`` (in Python) or ``null`` (in JSON). * Data within free-form JSON attributes: ``properties``, ``driver_info``, ``instance_info``, ``driver_internal_info`` fields on a node object; ``extra`` fields on all objects. * Addition of new drivers. * All vendor passthru methods. ironic-10.1.1/doc/source/contributor/index.rst0000666000175100017510000000622113243617463021375 0ustar zuulzuul00000000000000Developer's Guide ================= Getting Started --------------- If you are new to ironic, this section contains information that should help you get started as a developer working on the project or contributing to the project. .. toctree:: :maxdepth: 1 Developer Contribution Guide Setting Up Your Development Environment Priorities Specifications Frequently Asked Questions The following pages describe the architecture of the Bare Metal service and may be helpful to anyone working on or with the service, but are written primarily for developers. .. toctree:: :maxdepth: 1 Ironic System Architecture Provisioning State Machine Developing New Notifications OSProfiler Tracing Rolling Upgrades These pages contain information for PTLs, cross-project liaisons, and core reviewers. .. toctree:: :maxdepth: 1 Releasing Ironic Projects Ironic Governance Structure Writing Drivers --------------- Ironic's community includes many hardware vendors who contribute drivers that enable more advanced functionality when Ironic is used in conjunction with that hardware. To do this, the Ironic developer community is committed to standardizing on a `Python Driver API `_ that meets the common needs of all hardware vendors, and evolving this API without breaking backwards compatibility. However, it is sometimes necessary for driver authors to implement functionality - and expose it through the REST API - that can not be done through any existing API. To facilitate that, we also provide the means for API calls to be "passed through" ironic and directly to the driver. Some guidelines on how to implement this are provided below. Driver authors are strongly encouraged to talk with the developer community about any implementation using this functionality. .. toctree:: :maxdepth: 1 Driver Overview Writing "vendor_passthru" methods Third party continuous integration testing Testing Network Integration --------------------------- In order to test the integration between the Bare Metal and Networking services, support has been added to `devstack `_ to mimic an external physical switch. Here we include a recommended configuration for devstack to bring up this environment. .. toctree:: :maxdepth: 1 Configuring Devstack for multitenant network testing Testing Boot-from-Volume ------------------------ Starting with the Pike release, it is also possible to use DevStack for testing booting from Cinder volumes with VMs. .. toctree:: :maxdepth: 1 Configuring Devstack for boot-from-volume testing Full Ironic Server Python API Reference --------------------------------------- * :ref:`modindex` .. # api/autoindex is hidden since it's in the modindex link above. .. toctree:: :hidden: api/autoindex ironic-10.1.1/doc/source/contributor/dev-quickstart.rst0000666000175100017510000007400013243617463023234 0ustar zuulzuul00000000000000.. _dev-quickstart: ===================== Developer Quick-Start ===================== This is a quick walkthrough to get you started developing code for Ironic. This assumes you are already familiar with submitting code reviews to an OpenStack project. The gate currently runs the unit tests under Python 2.7 and Python 3.5. It is strongly encouraged to run the unit tests locally prior to submitting a patch. .. note:: Do not run unit tests on the same environment as devstack due to conflicting configuration with system dependencies. .. note:: This document is compatible with Python (3.5), Ubuntu (16.04) and Fedora (24). When referring to different versions of Python and OS distributions, this is explicitly stated. .. seealso:: https://docs.openstack.org/infra/manual/developers.html#development-workflow Prepare Development System ========================== System Prerequisites -------------------- The following packages cover the prerequisites for a local development environment on most current distributions. Instructions for getting set up with non-default versions of Python and on older distributions are included below as well. - Ubuntu/Debian:: sudo apt-get install build-essential python-dev libssl-dev python-pip libmysqlclient-dev libxml2-dev libxslt-dev libpq-dev git git-review libffi-dev gettext ipmitool psmisc graphviz libjpeg-dev - Fedora 21/RHEL7/CentOS7:: sudo yum install python-devel openssl-devel python-pip mysql-devel libxml2-devel libxslt-devel postgresql-devel git git-review libffi-devel gettext ipmitool psmisc graphviz gcc libjpeg-turbo-devel If using RHEL and yum reports "No package python-pip available" and "No package git-review available", use the EPEL software repository. Instructions can be found at ``_. - Fedora 22 or higher:: sudo dnf install python-devel openssl-devel python-pip mysql-devel libxml2-devel libxslt-devel postgresql-devel git git-review libffi-devel gettext ipmitool psmisc graphviz gcc libjpeg-turbo-devel Additionally, if using Fedora 23, ``redhat-rpm-config`` package should be installed so that development virtualenv can be built successfully. - openSUSE/SLE 12:: sudo zypper install git git-review libffi-devel libmysqlclient-devel libopenssl-devel libxml2-devel libxslt-devel postgresql-devel python-devel python-nose python-pip gettext-runtime psmisc Graphviz is only needed for generating the state machine diagram. To install it on openSUSE or SLE 12, see ``_. Python Prerequisites -------------------- If your distro has at least tox 1.8, use similar command to install ``python-tox`` package. Otherwise install this on all distros:: sudo pip install -U tox You may need to explicitly upgrade virtualenv if you've installed the one from your OS distribution and it is too old (tox will complain). You can upgrade it individually, if you need to:: sudo pip install -U virtualenv Running Unit Tests Locally ========================== If you haven't already, Ironic source code should be pulled directly from git:: # from your home or source directory cd ~ git clone https://git.openstack.org/openstack/ironic cd ironic Running Unit and Style Tests ---------------------------- All unit tests should be run using tox. To run Ironic's entire test suite:: # to run the py27, py35 unit tests, and the style tests tox To run a specific test or tests, use the "-e" option followed by the tox target name. For example:: # run the unit tests under py27 and also run the pep8 tests tox -epy27 -epep8 You may pass options to the test programs using positional arguments. To run a specific unit test, this passes the -r option and desired test (regex string) to `os-testr `_:: # run a specific test for Python 2.7 tox -epy27 -- -r test_conductor Debugging unit tests -------------------- In order to break into the debugger from a unit test we need to insert a breaking point to the code: .. code-block:: python import pdb; pdb.set_trace() Then run ``tox`` with the debug environment as one of the following:: tox -e debug tox -e debug test_file_name tox -e debug test_file_name.TestClass tox -e debug test_file_name.TestClass.test_name For more information see the `oslotest documentation `_. Database Setup -------------- The unit tests need a local database setup, you can use ``tools/test-setup.sh`` to set up the database the same way as setup in the OpenStack test systems. Additional Tox Targets ---------------------- There are several additional tox targets not included in the default list, such as the target which builds the documentation site. See the ``tox.ini`` file for a complete listing of tox targets. These can be run directly by specifying the target name:: # generate the documentation pages locally tox -edocs # generate the sample configuration file tox -egenconfig Exercising the Services Locally =============================== In addition to running automated tests, sometimes it can be helpful to actually run the services locally, without needing a server in a remote datacenter. If you would like to exercise the Ironic services in isolation within your local environment, you can do this without starting any other OpenStack services. For example, this is useful for rapidly prototyping and debugging interactions over the RPC channel, testing database migrations, and so forth. Here we describe two ways to install and configure the dependencies, either run directly on your local machine or encapsulated in a virtual machine or container. Step 1: Create a Python virtualenv ---------------------------------- #. If you haven't already downloaded the source code, do that first:: cd ~ git clone https://git.openstack.org/openstack/ironic cd ironic #. Create the Python virtualenv:: tox -evenv --notest --develop -r #. Activate the virtual environment:: . .tox/venv/bin/activate #. Install the openstack baremetal client:: pip install python-ironicclient .. note:: You can install python-ironicclient from source by cloning the git repository and running `pip install .` while in the root of the cloned repository. #. Export some ENV vars so the client will connect to the local services that you'll start in the next section:: export OS_TOKEN=fake-token export OS_URL=http://localhost:6385/ Next, install and configure system dependencies. Two different approaches are described below; you should only do one of these. Step 2a: System Dependencies In A Virtual Machine ------------------------------------------------- This option requires `virtualbox `_, `vagrant `_, and `ansible `_. You may install these using your favorite package manager, or by downloading from the provided links. #. Let vagrant do the work:: vagrant up This will create a VM available to your local system at `192.168.99.11`, will install all the necessary service dependencies, and configure some default users. It will also generate `./etc/ironic/ironic.conf.local` preconfigured for local dev work. We recommend you compare and familiarize yourself with the settings in `./etc/ironic/ironic.conf.sample` so you can adjust it to meet your own needs. Step 2b: Install System Dependencies Locally -------------------------------------------- This option will install RabbitMQ and MySQL on your local system. This may not be desirable in some situations (eg, you're developing from a laptop and do not want to run a MySQL server on it all the time). #. Install rabbitmq-server:: # install rabbit message broker # Ubuntu/Debian: sudo apt-get install rabbitmq-server # Fedora 21/RHEL7/CentOS7: sudo yum install rabbitmq-server sudo systemctl start rabbitmq-server.service # Fedora 22 or higher: sudo dnf install rabbitmq-server sudo systemctl start rabbitmq-server.service # openSUSE/SLE 12: sudo zypper install rabbitmq-server sudo systemctl start rabbitmq-server.service #. Install mysql-server:: # Ubuntu/Debian: # sudo apt-get install mysql-server # Fedora 21/RHEL7/CentOS7: # sudo yum install mariadb mariadb-server # sudo systemctl start mariadb.service # Fedora 22 or higher: # sudo dnf install mariadb mariadb-server # sudo systemctl start mariadb.service # openSUSE/SLE 12: # sudo zypper install mariadb # sudo systemctl start mysql.service # If using MySQL, you need to create the initial database mysql -u root -pMYSQL_ROOT_PWD -e "create schema ironic" .. note:: if you choose not to install mysql-server, ironic will default to using a local sqlite database. #. Create a configuration file within the ironic source directory:: # generate a sample config tox -egenconfig # copy sample config and modify it as necessary cp etc/ironic/ironic.conf.sample etc/ironic/ironic.conf.local # disable auth since we are not running keystone here sed -i "s/#auth_strategy = keystone/auth_strategy = noauth/" etc/ironic/ironic.conf.local # use the 'fake-hardware' test hardware type sed -i "s/#enabled_hardware_types = .*/enabled_hardware_types = fake-hardware/" etc/ironic/ironic.conf.local # use the 'fake' deploy and boot interfaces sed -i "s/#enabled_deploy_interfaces = .*/enabled_deploy_interfaces = fake/" etc/ironic/ironic.conf.local sed -i "s/#enabled_boot_interfaces = .*/enabled_boot_interfaces = fake/" etc/ironic/ironic.conf.local # enable both fake and ipmitool management and power interfaces sed -i "s/#enabled_management_interfaces = .*/enabled_management_interfaces = fake,ipmitool/" etc/ironic/ironic.conf.local sed -i "s/#enabled_power_interfaces = .*/enabled_power_interfaces = fake,ipmitool/" etc/ironic/ironic.conf.local # set a fake host name [useful if you want to test multiple services on the same host] sed -i "s/#host = .*/host = test-host/" etc/ironic/ironic.conf.local # change the periodic sync_power_state_interval to a week, to avoid getting NodeLocked exceptions sed -i "s/#sync_power_state_interval = 60/sync_power_state_interval = 604800/" etc/ironic/ironic.conf.local # if you opted to install mysql-server, switch the DB connection from sqlite to mysql sed -i "s/#connection = .*/connection = mysql\+pymysql:\/\/root:MYSQL_ROOT_PWD@localhost\/ironic/" etc/ironic/ironic.conf.local Step 3: Start the Services -------------------------- From within the python virtualenv, run the following command to prepare the database before you start the ironic services:: # initialize the database for ironic ironic-dbsync --config-file etc/ironic/ironic.conf.local create_schema Next, open two new terminals for this section, and run each of the examples here in a separate terminal. In this way, the services will *not* be run as daemons; you can observe their output and stop them with Ctrl-C at any time. #. Start the API service in debug mode and watch its output:: cd ~/ironic . .tox/venv/bin/activate ironic-api -d --config-file etc/ironic/ironic.conf.local #. Start the Conductor service in debug mode and watch its output:: cd ~/ironic . .tox/venv/bin/activate ironic-conductor -d --config-file etc/ironic/ironic.conf.local Step 4: Interact with the running services ------------------------------------------ You should now be able to interact with ironic via the python client, which is present in the python virtualenv, and observe both services' debug outputs in the other two windows. This is a good way to test new features or play with the functionality without necessarily starting DevStack. To get started, export the following variables to point the client at the local instance of ironic and disable the authentication:: export OS_AUTH_TYPE=token_endpoint export OS_TOKEN=fake export OS_ENDPOINT=http://127.0.0.1:6385 Then list the available commands and resources:: # get a list of available commands openstack help baremetal # get the list of drivers currently supported by the available conductor(s) openstack baremetal driver list # get a list of nodes (should be empty at this point) openstack baremetal node list Here is an example walkthrough of creating a node:: MAC="aa:bb:cc:dd:ee:ff" # replace with the MAC of a data port on your node IPMI_ADDR="1.2.3.4" # replace with a real IP of the node BMC IPMI_USER="admin" # replace with the BMC's user name IPMI_PASS="pass" # replace with the BMC's password # enroll the node with the fake hardware type and IPMI-based power and # management interfaces. Note that driver info may be added at node # creation time with "--driver-info" NODE=$(openstack baremetal node create \ --driver fake-hardware \ --management-interface ipmitool \ --power-interface ipmitool \ --driver-info ipmi_address=$IPMI_ADDR \ --driver-info ipmi_username=$IPMI_USER \ -f value -c uuid) # driver info may also be added or updated later on openstack baremetal node set $NODE --driver-info ipmi_password=$IPMI_PASS # add a network port openstack baremetal port create $MAC --node $NODE # view the information for the node openstack baremetal node show $NODE # request that the node's driver validate the supplied information openstack baremetal node validate $NODE # you have now enrolled a node sufficiently to be able to control # its power state from ironic! openstack baremetal node power on $NODE If you make some code changes and want to test their effects, simply stop the services with Ctrl-C and restart them. Step 5: Fixing your test environment ------------------------------------ If you are testing changes that add or remove python entrypoints, or making significant changes to ironic's python modules, or simply keep the virtualenv around for a long time, your development environment may reach an inconsistent state. It may help to delete cached ".pyc" files, update dependencies, reinstall ironic, or even recreate the virtualenv. The following commands may help with that, but are not an exhaustive troubleshooting guide:: # clear cached pyc files cd ~/ironic/ironic find ./ -name '*.pyc' | xargs rm # reinstall ironic modules cd ~/ironic . .tox/venv/bin/activate pip uninstall ironic pip install -e . # install and upgrade ironic and all python dependencies cd ~/ironic . .tox/venv/bin/activate pip install -U -e . .. _`deploy_devstack`: Deploying Ironic with DevStack ============================== DevStack may be configured to deploy Ironic, setup Nova to use the Ironic driver and provide hardware resources (network, baremetal compute nodes) using a combination of OpenVSwitch and libvirt. It is highly recommended to deploy on an expendable virtual machine and not on your personal work station. Deploying Ironic with DevStack requires a machine running Ubuntu 16.04 (or later) or Fedora 24 (or later). Make sure your machine is fully up to date and has the latest packages installed before beginning this process. .. seealso:: https://docs.openstack.org/devstack/latest/ .. note:: The devstack "demo" tenant is now granted the "baremetal_observer" role and thereby has read-only access to ironic's API. This is sufficient for all the examples below. Should you want to create or modify bare metal resources directly (ie. through ironic rather than through nova) you will need to use the devstack "admin" tenant. Devstack will no longer create the user 'stack' with the desired permissions, but does provide a script to perform the task:: git clone https://git.openstack.org/openstack-dev/devstack.git devstack sudo ./devstack/tools/create-stack-user.sh Switch to the stack user and clone DevStack:: sudo su - stack git clone https://git.openstack.org/openstack-dev/devstack.git devstack Create devstack/local.conf with minimal settings required to enable Ironic. An example local.conf that enables both ``direct`` and ``iscsi`` :doc:`deploy interfaces ` and uses the ``ipmi`` hardware type by default:: cd devstack cat >local.conf <`_ to control the power state of the virtual baremetal nodes. .. note:: When running QEMU as non-root user (e.g. ``qemu`` on Fedora or ``libvirt-qemu`` on Ubuntu), make sure ``IRONIC_VM_LOG_DIR`` points to a directory where QEMU will be able to write. You can verify this with, for example:: # on Fedora sudo -u qemu touch $HOME/ironic-bm-logs/test.log # on Ubuntu sudo -u libvirt-qemu touch $HOME/ironic-bm-logs/test.log .. note:: To check out an in-progress patch for testing, you can add a Git ref to the ``enable_plugin`` line. For instance:: enable_plugin ironic git://git.openstack.org/openstack/ironic refs/changes/46/295946/15 For a patch in review, you can find the ref to use by clicking the "Download" button in Gerrit. You can also specify a different git repo, or a branch or tag:: enable_plugin ironic https://github.com/openstack/ironic stable/kilo For more details, see the `devstack plugin interface documentation `_. Run stack.sh:: ./stack.sh Source credentials, create a key, and spawn an instance as the ``demo`` user:: . ~/devstack/openrc # query the image id of the default cirros image image=$(openstack image show $DEFAULT_IMAGE_NAME -f value -c id) # create keypair ssh-keygen openstack keypair create --public-key ~/.ssh/id_rsa.pub default # spawn instance openstack server create --flavor baremetal --image $image --key-name default testing .. note:: Because devstack create multiple networks, we need to pass an additional parameter ``--nic net-id`` to the nova boot command when using the admin account, for example:: net_id=$(openstack network list | egrep "$PRIVATE_NETWORK_NAME"'[^-]' | awk '{ print $2 }') openstack server create --flavor baremetal --nic net-id=$net_id --image $image --key-name default testing You should now see a Nova instance building:: openstack server list --long +----------+---------+--------+------------+-------------+----------+------------+----------+-------------------+------+------------+ | ID | Name | Status | Task State | Power State | Networks | Image Name | Image ID | Availability Zone | Host | Properties | +----------+---------+--------+------------+-------------+----------+------------+----------+-------------------+------+------------+ | a2c7f812 | testing | BUILD | spawning | NOSTATE | | cirros-0.3 | 44d4092a | nova | | | | -e386-4a | | | | | | .5-x86_64- | -51ac-47 | | | | | 22-b393- | | | | | | disk | 51-9c50- | | | | | fe1802ab | | | | | | | fd6e2050 | | | | | d56e | | | | | | | faa1 | | | | +----------+---------+--------+------------+-------------+----------+------------+----------+-------------------+------+------------+ Nova will be interfacing with Ironic conductor to spawn the node. On the Ironic side, you should see an Ironic node associated with this Nova instance. It should be powered on and in a 'wait call-back' provisioning state:: openstack baremetal node list +--------------------------------------+--------+--------------------------------------+-------------+--------------------+-------------+ | UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance | +--------------------------------------+--------+--------------------------------------+-------------+--------------------+-------------+ | 9e592cbe-e492-4e4f-bf8f-4c9e0ad1868f | node-0 | None | power off | None | False | | ec0c6384-cc3a-4edf-b7db-abde1998be96 | node-1 | None | power off | None | False | | 4099e31c-576c-48f8-b460-75e1b14e497f | node-2 | a2c7f812-e386-4a22-b393-fe1802abd56e | power on | wait call-back | False | +--------------------------------------+--------+--------------------------------------+-------------+--------------------+-------------+ At this point, Ironic conductor has called to libvirt (via virtualbmc) to power on a virtual machine, which will PXE + TFTP boot from the conductor node and progress through the Ironic provisioning workflow. One libvirt domain should be active now:: sudo virsh list --all Id Name State ---------------------------------------------------- 2 node-2 running - node-0 shut off - node-1 shut off This provisioning process may take some time depending on the performance of the host system, but Ironic should eventually show the node as having an 'active' provisioning state:: openstack baremetal node list +--------------------------------------+--------+--------------------------------------+-------------+--------------------+-------------+ | UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance | +--------------------------------------+--------+--------------------------------------+-------------+--------------------+-------------+ | 9e592cbe-e492-4e4f-bf8f-4c9e0ad1868f | node-0 | None | power off | None | False | | ec0c6384-cc3a-4edf-b7db-abde1998be96 | node-1 | None | power off | None | False | | 4099e31c-576c-48f8-b460-75e1b14e497f | node-2 | a2c7f812-e386-4a22-b393-fe1802abd56e | power on | active | False | +--------------------------------------+--------+--------------------------------------+-------------+--------------------+-------------+ This should also be reflected in the Nova instance state, which at this point should be ACTIVE, Running and an associated private IP:: openstack server list --long +----------+---------+--------+------------+-------------+---------------+------------+----------+-------------------+------+------------+ | ID | Name | Status | Task State | Power State | Networks | Image Name | Image ID | Availability Zone | Host | Properties | +----------+---------+--------+------------+-------------+---------------+------------+----------+-------------------+------+------------+ | a2c7f812 | testing | ACTIVE | none | Running | private=10.1. | cirros-0.3 | 44d4092a | nova | | | | -e386-4a | | | | | 0.4, fd7d:1f3 | .5-x86_64- | -51ac-47 | | | | | 22-b393- | | | | | c:4bf1:0:f816 | disk | 51-9c50- | | | | | fe1802ab | | | | | :3eff:f39d:6d | | fd6e2050 | | | | | d56e | | | | | 94 | | faa1 | | | | +----------+---------+--------+------------+-------------+---------------+------------+----------+-------------------+------+------------+ The server should now be accessible via SSH:: ssh cirros@10.1.0.4 $ Running Tempest tests ===================== After `Deploying Ironic with DevStack`_ one might want to run integration tests against the running cloud. The Tempest project is the project that offers an integration test suite for OpenStack. First, navigate to Tempest directory:: cd /opt/stack/tempest To run all tests from the `Ironic plugin `_, execute the following command:: tox -e all-plugin -- ironic To limit the amount of tests that you would like to run, you can use a regex. For instance, to limit the run to a single test file, the following command can be used:: tox -e all-plugin -- ironic_tempest_plugin.tests.scenario.test_baremetal_basic_ops Debugging Tempest tests ----------------------- It is sometimes useful to step through the test code, line by line, especially when the error output is vague. This can be done by running the tests in debug mode and using a debugger such as `pdb `_. For example, after editing the *test_baremetal_basic_ops* file and setting up the pdb traces you can invoke the ``run_tempest.sh`` script in the Tempest directory with the following parameters:: ./run_tempest.sh -N -d ironic_tempest_plugin.tests.scenario.test_baremetal_basic_ops * The *-N* parameter tells the script to run the tests in the local environment (without a virtualenv) so it can find the Ironic tempest plugin. * The *-d* parameter enables the debug mode, allowing it to be used with pdb. For more information about the supported parameters see:: ./run_tempest.sh --help .. note:: Always be careful when running debuggers in time sensitive code, they may cause timeout errors that weren't there before. OSProfiler Tracing in Ironic ============================ OSProfiler is an OpenStack cross-project profiling library. It is being used among OpenStack projects to look at performance issues and detect bottlenecks. For details on how OSProfiler works and how to use it in ironic, please refer to `OSProfiler Support Documentation `_. Building developer documentation ================================ If you would like to build the documentation locally, eg. to test your documentation changes before uploading them for review, run these commands to build the documentation set: - On your local machine:: # activate your development virtualenv . .tox/venv/bin/activate # build the docs tox -edocs #Now use your browser to open the top-level index.html located at: ironic/doc/build/html/index.html - On a remote machine:: # Go to the directory that contains the docs cd ~/ironic/doc/source/ # Build the docs tox -edocs # Change directory to the newly built HTML files cd ~/ironic/doc/build/html/ # Create a server using python on port 8000 python -m SimpleHTTPServer 8000 #Now use your browser to open the top-level index.html located at: http://your_ip:8000 ironic-10.1.1/doc/source/contributor/notifications.rst0000666000175100017510000001502013243617463023134 0ustar zuulzuul00000000000000.. _develop-notifications: ============================ Developing New Notifications ============================ Ironic notifications are events intended for consumption by external services. Notifications are sent to these services over a message bus by oslo.messaging's Notifier class [1]_. For more information about configuring notifications and available notifications, see :ref:`deploy-notifications`. Ironic also has a set of base classes that assist in clearly defining the notification itself, the payload, and the other fields not auto-generated by oslo (level, event_type and publisher_id). Below describes how to use these base classes to add a new notification to ironic. Adding a new notification to ironic =================================== To add a new notification to ironic, a new versioned notification class should be created by subclassing the NotificationBase class to define the notification itself and the NotificationPayloadBase class to define which fields the new notification will contain inside its payload. You may also define a schema to allow the payload to be automatically populated by the fields of an ironic object. Here's an example:: # The ironic object whose fields you want to use in your schema @base.IronicObjectRegistry.register class ExampleObject(base.IronicObject): # Version 1.0: Initial version VERSION = '1.0' fields = { 'id': fields.IntegerField(), 'uuid': fields.UUIDField(), 'a_useful_field': fields.StringField(), 'not_useful_field': fields.StringField() } # A class for your new notification @base.IronicObjectRegistry.register class ExampleNotification(notification.NotificationBase): # Version 1.0: Initial version VERSION = '1.0' fields = { 'payload': fields.ObjectField('ExampleNotifPayload') } # A class for your notification's payload @base.IronicObjectRegistry.register class ExampleNotifPayload(notification.NotificationPayloadBase): # Schemas are optional. They just allow you to reuse other objects' # fields by passing in that object and calling populate_schema with # a kwarg set to the other object. SCHEMA = { 'a_useful_field': ('example_obj', 'a_useful_field') } # Version 1.0: Initial version VERSION = '1.0' fields = { 'a_useful_field': fields.StringField(), 'an_extra_field': fields.StringField(nullable=True) } Note that both the payload and notification classes are oslo versioned objects [2]_. Modifications to these require a version bump so that consumers of notifications know when the notifications have changed. SCHEMA defines how to populate the payload fields. It's an optional attribute that subclasses may use to easily populate notifications with data from other objects. It is a dictionary where every key value pair has the following format:: : (, ) The ```` is the name where the data will be stored in the payload object; this field has to be defined as a field of the payload. The ```` shall refer to name of the parameter passed as kwarg to the payload's ``populate_schema()`` call and this object will be used as the source of the data. The ```` shall be a valid field of the passed argument. The SCHEMA needs to be applied with the ``populate_schema()`` call before the notification can be emitted. The value of the ``payload.`` field will be set by the ``.`` field. The ```` will not be part of the payload object internal or external representation. Payload fields that are not set by the SCHEMA can be filled in the same way as in any versioned object. Then, to create a payload, you would do something like the following. Note that if you choose to define a schema in the SCHEMA class variable, you must populate the schema by calling ``populate_schema(example_obj=my_example_obj)`` before emitting the notification is allowed:: my_example_obj = ExampleObject(id=1, a_useful_field='important', not_useful_field='blah') # an_extra_field is optional since it's not a part of the SCHEMA and is a # nullable field in the class fields my_notify_payload = ExampleNotifyPayload(an_extra_field='hello') # populate the schema with the ExampleObject fields my_notify_payload.populate_schema(example_obj=my_example_obj) You then create the notification with the oslo required fields (event_type, publisher_id, and level, all sender fields needed by oslo that are defined in the ironic notification base classes) and emit it:: notify = ExampleNotification( event_type=notification.EventType(object='example_obj', action='do_something', status=fields.NotificationStatus.START), publisher=notification.NotificationPublisher( service='ironic-conductor', host='hostname01'), level=fields.NotificationLevel.DEBUG, payload=my_notify_payload) notify.emit(context) When specifying the event_type, ``object`` will specify the object being acted on, ``action`` will be a string describing what action is being performed on that object, and ``status`` will be one of "start", "end", "error", or "success". "start" and "end" are used to indicate when actions that are not immediate begin and succeed. "success" is used to indicate when actions that are immediate succeed. "error" is used to indicate when any type of action fails, regardless of whether it's immediate or not. As a result of specifying these parameters, event_type will be formatted as ``baremetal...`` on the message bus. This example will send the following notification over the message bus:: { "priority": "debug", "payload":{ "ironic_object.namespace":"ironic", "ironic_object.name":"ExampleNotifyPayload", "ironic_object.version":"1.0", "ironic_object.data":{ "a_useful_field":"important", "an_extra_field":"hello" } }, "event_type":"baremetal.example_obj.do_something.start", "publisher_id":"ironic-conductor.hostname01" } .. [1] https://docs.openstack.org/oslo.messaging/latest/reference/notifier.html .. [2] https://docs.openstack.org/oslo.versionedobjects/latest/ ironic-10.1.1/doc/source/contributor/code-contribution-guide.rst0000666000175100017510000003133713243617463025016 0ustar zuulzuul00000000000000.. _code-contribution-guide: ======================= Code Contribution Guide ======================= This document provides some necessary points for developers to consider when writing and reviewing Ironic code. The checklist will help developers get things right. Getting Started =============== If you're completely new to OpenStack and want to contribute to the ironic project, please start by familiarizing yourself with the `Infra Team's Developer Guide `_. This will help you get your accounts set up in Launchpad and Gerrit, familiarize you with the workflow for the OpenStack continuous integration and testing systems, and help you with your first commit. LaunchPad Project ----------------- Most of the tools used for OpenStack require a launchpad.net ID for authentication. .. seealso:: * https://launchpad.net * https://launchpad.net/ironic Related Projects ---------------- There are several projects that are tightly integrated with ironic and which are developed by the same community. .. seealso:: * https://launchpad.net/bifrost * https://launchpad.net/ironic-inspector * https://launchpad.net/ironic-lib * https://launchpad.net/ironic-python-agent * https://launchpad.net/python-ironicclient * https://launchpad.net/python-ironic-inspector-client Project Hosting Details ----------------------- Bug tracker https://bugs.launchpad.net/ironic Mailing list (prefix Subject line with ``[ironic]``) http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Wiki https://wiki.openstack.org/Ironic Code Hosting https://git.openstack.org/cgit/openstack/ironic Code Review https://review.openstack.org/#/q/status:open+project:openstack/ironic,n,z Adding New Features =================== Starting with the Mitaka development cycle, Ironic tracks new features using RFEs (Requests for Feature Enhancements) instead of blueprints. These are bugs with 'rfe' tag, and they should be submitted before a spec or code is proposed. When a member of `ironic-drivers launchpad team `_ decides that the proposal is worth implementing, a spec (if needed) and code should be submitted, referencing the RFE bug. Contributors are welcome to submit a spec and/or code before the RFE is approved, however those patches will not land until the RFE is approved. Feature Submission Process -------------------------- #. Submit a bug report at https://bugs.launchpad.net/ironic/+filebug. There are two fields that must be filled: 'summary' and 'further information'. The 'summary' must be brief enough to fit in one line: if you can’t describe it in a few words it may mean that you are either trying to capture more than one RFE at once, or that you are having a hard time defining what you are trying to solve at all. #. Describe the proposed change in the 'further information' field. The description should provide enough details for a knowledgeable developer to understand what is the existing problem in the current platform that needs to be addressed, or what is the enhancement that would make the platform more capable, both from a functional and a non-functional standpoint. #. Submit the bug, add an 'rfe' tag to it and assign yourself or whoever is going to work on this feature. #. As soon as a member of the ironic-drivers team acknowledges the bug, it will be moved into the 'Triaged' state. The importance will be set to 'Wishlist' to signal the fact that the report is indeed a feature and there is no severity associated to it. Discussion about the RFE, and whether to approve it, happens in bug comments while in the 'Triaged' state. #. The ironic-drivers team will evaluate the RFE and may advise the submitter to file a spec in ironic-specs to elaborate on the feature request, in case the RFE requires extra scrutiny, more design discussion, etc. For the spec submission process, please see the `Ironic Specs Process`_. #. If a spec is not required, once the discussion has happened and there is positive consensus among the ironic-drivers team on the RFE, the RFE is 'approved', and its tag will move from 'rfe' to 'rfe-approved'. This means that the feature is approved and the related code may be merged. #. If a spec is required, the spec must be submitted (with the bug properly referenced as 'Partial-Bug' in the commit message), reviewed, and merged before the RFE will be 'approved' (and the tag changed to 'rfe-approved'). #. The bug then goes through the usual process -- first to 'In progress' when the spec/code is being worked on, then 'Fix Released' when it is implemented. #. If the RFE is rejected, the ironic-drivers team will move the bug to "Won't Fix" status. Change Tracking --------------- When working on an RFE, please be sure to tag your commits properly: "Partial-Bug: #xxxx" or "Related-Bug: #xxxx" for intermediate commits for the feature, and "Closes-Bug: #xxxx" for the final commit. It is also helpful to set a consistent review topic, such as "bug/xxxx" for all patches related to the RFE. If the RFE spans across several projects (e.g. ironic and python-ironicclient), but the main work is going to happen within ironic, please use the same bug for all the code you're submitting, there is no need to create a separate RFE in every project. .. note:: Currently the Ironic bug tracker is managed by the open 'ironic-bugs' team, not the ironic-drivers team. This means that anyone may edit bug details, and there is room to game the system here. **RFEs may only be approved by members of the ironic-drivers team**. Managing Change Sets -------------------- If you would like some help, or if you (or some members of your team) are unable to continue working on the feature, updating and maintaining the changes, please let the rest of the ironic community know. You could leave a comment in one or more of the changes/patches, bring it up in IRC, the weekly meeting, or on the OpenStack development email list. Communicating this will make other contributors aware of the situation and allow for others to step forward and volunteer to continue with the work. In the event that a contributor leaves the community, do not expect the contributor's changes to be continued unless someone volunteers to do so. Timeline Expectations ===================== As with any large project, it does take time for features and changes to be merged in any of the project repositories. This is largely due to limited review bandwidth coupled with varying reviewer priorities and focuses. When establishing an understanding of complexity, the following things should be kept in mind. * Generally, small and minor changes can gain consensus and merge fairly quickly. These sorts of changes would be: bug fixes, minor documentation updates, follow-up changes. * Medium changes generally consist of driver feature parity changes, where one driver is working to match functionality of another driver. * These changes generally only require an RFE for the purposes of tracking and correlating the change. * Documentation updates are expected to be submitted with or immediately following the initial change set. * Larger or controversial changes generally take much longer to merge. This is often due to the necessity of reviewers to gain additional context and for change sets to be iterated upon to reach a state where there is consensus. These sorts of changes include: database, object, internal interface additions, RPC, rest API changes. * These changes will very often require specifications to reach consensus, unless there are pre-existing patterns or code already present. * These changes may require many reviews and iterations, and can also expect to be impacted by merge conflicts as other code or features are merged. * These changes must typically be split into a series of changes. Reviewers typically shy away from larger single change sets due to increased difficulty in reviewing. * Do not expect any API or user-visible data model changes to merge after the API client freeze. Some substrate changes may merge if not user visible. * You should expect complex features, such as cross-project features or integration, to take longer than a single development cycle to land. * Building consensus is vital. * Often these changes are controversial or have multiple considerations that need to be worked through in the specification process, which may cause the design to change. As such, it may take months to reach consensus over design. * These features are best broken into larger chunks and tackled in an incremental fashion. Live Upgrade Related Concerns ============================= See :doc:`/contributor/rolling-upgrades`. Driver Internal Info ==================== The ``driver_internal_info`` node field was introduced in the Kilo release. It allows driver developers to store internal information that can not be modified by end users. Here is the list of existing common and agent driver attributes: * Common attributes: * ``is_whole_disk_image``: A Boolean value to indicate whether the user image contains ramdisk/kernel. * ``clean_steps``: An ordered list of clean steps that will be performed on the node. * ``instance``: A list of dictionaries containing the disk layout values. * ``root_uuid_or_disk_id``: A String value of the bare metal node's root partition uuid or disk id. * ``persistent_boot_device``: A String value of device from ``ironic.common.boot_devices``. * ``is_next_boot_persistent``: A Boolean value to indicate whether the next boot device is ``persistent_boot_device``. * Agent driver attributes: * ``agent_url``: A String value of IPA API URL so that Ironic can talk to IPA ramdisk. * ``hardware_manager_version``: A String value of the version of the hardware manager in IPA ramdisk. * ``target_raid_config``: A Dictionary containing the target RAID configuration. This is a copy of the same name attribute in Node object. But this one is never actually saved into DB and is only read by IPA ramdisk. .. note:: These are only some fields in use. Other vendor drivers might expose more ``driver_internal_info`` properties, please check their development documentation and/or module docstring for details. It is important for developers to make sure these properties follow the precedent of prefixing their variable names with a specific interface name (e.g., ilo_bar, drac_xyz), so as to minimize or avoid any conflicts between interfaces. Ironic Specs Process ==================== Specifications must follow the template which can be found at `specs/template.rst `_, which is quite self-documenting. Specifications are proposed by adding them to the `specs/approved` directory, adding a soft link to it from the `specs/not-implemented` directory, and posting it for review to Gerrit. For more information, please see the `README `_. The same `Gerrit process `_ as with source code, using the repository `ironic-specs `_, is used to add new specifications. All approved specifications are available at: https://specs.openstack.org/openstack/ironic-specs. If a specification has been approved but not completed within one or more releases since the approval, it may be re-reviewed to make sure it still makes sense as written. Ironic specifications are part of the `RFE (Requests for Feature Enhancements) process <#adding-new-features>`_. You are welcome to submit patches associated with an RFE, but they will have a -2 ("do not merge") until the specification has been approved. This is to ensure that the patches don't get accidentally merged beforehand. You will still be able to get reviewer feedback and push new patch sets, even with a -2. The `list of core reviewers `_ for the specifications is small but mighty. (This is not necessarily the same list of core reviewers for code patches.) Changes to existing specs ------------------------- For approved but not-completed specs: - cosmetic cleanup, fixing errors, and changing the definition of a feature can be done to the spec. For approved and completed specs: - changing a previously approved and completed spec should only be done for cosmetic cleanup or fixing errors. - changing the definition of the feature should be done in a new spec. Please see the `Ironic specs process wiki page `_ for further reference. ironic-10.1.1/doc/source/contributor/webapi-version-history.rst0000666000175100017510000002442613243617463024726 0ustar zuulzuul00000000000000======================== REST API Version History ======================== 1.38 (Queens, 10.1.0) --------------------- Added provision_state verbs ``rescue`` and ``unrescue`` along with the following states: ``rescue``, ``rescue failed``, ``rescue wait``, ``rescuing``, ``unrescue failed``, and ``unrescuing``. After rescuing a node, it will be left in the ``rescue`` state running a rescue ramdisk, configured with the ``rescue_password``, and listening with ssh on the specified network interfaces. Unrescuing a node will return it to ``active``. Added ``rescue_interface`` to the node object, to allow setting the rescue interface for a dynamic driver. 1.37 (Queens, 10.1.0) --------------------- Adds support for node traits, with the following new endpoints. * GET /v1/nodes//traits lists the traits for a node. * PUT /v1/nodes//traits sets all traits for a node. * PUT /v1/nodes//traits/ adds a trait to a node. * DELETE /v1/nodes//traits removes all traits from a node. * DELETE /v1/nodes//traits/ removes a trait from a node. A node's traits are also included the following node query and list responses: * GET /v1/nodes/ * GET /v1/nodes/detail * GET /v1/nodes?fields=traits Traits cannot be specified on node creation, nor can they be updated via a PATCH request on the node. 1.36 (Queens, 10.0.0) --------------------- Added ``agent_version`` parameter to deploy heartbeat request for version negotiation with Ironic Python Agent features. 1.35 (Queens, 9.2.0) -------------------- Added ability to provide ``configdrive`` when node is updated to ``rebuild`` provision state. 1.34 (Pike, 9.0.0) ------------------ Adds a ``physical_network`` field to the port object. All ports in a portgroup must have the same value in their ``physical_network`` field. 1.33 (Pike, 9.0.0) ------------------ Added ``storage_interface`` field to the node object to allow getting and setting the interface. Added ``default_storage_interface`` and ``enabled_storage_interfaces`` fields to the driver object to show the information. 1.32 (Pike, 9.0.0) ------------------ Added new endpoints for remote volume configuration: * GET /v1/volume as a root for volume resources * GET /v1/volume/connectors for listing volume connectors * POST /v1/volume/connectors for creating a volume connector * GET /v1/volume/connectors/ for showing a volume connector * PATCH /v1/volume/connectors/ for updating a volume connector * DELETE /v1/volume/connectors/ for deleting a volume connector * GET /v1/volume/targets for listing volume targets * POST /v1/volume/targets for creating a volume target * GET /v1/volume/targets/ for showing a volume target * PATCH /v1/volume/targets/ for updating a volume target * DELETE /v1/volume/targets/ for deleting a volume target Volume resources also can be listed as sub resources of nodes: * GET /v1/nodes//volume * GET /v1/nodes//volume/connectors * GET /v1/nodes//volume/targets 1.31 (Ocata, 7.0.0) ------------------- Added the following fields to the node object, to allow getting and setting interfaces for a dynamic driver: * boot_interface * console_interface * deploy_interface * inspect_interface * management_interface * power_interface * raid_interface * vendor_interface 1.30 (Ocata, 7.0.0) ------------------- Added dynamic driver APIs: * GET /v1/drivers now accepts a ``type`` parameter (optional, one of ``classic`` or ``dynamic``), to limit the result to only classic drivers or dynamic drivers (hardware types). Without this parameter, both classic and dynamic drivers are returned. * GET /v1/drivers now accepts a ``detail`` parameter (optional, one of ``True`` or ``False``), to show all fields for a driver. Defaults to ``False``. * GET /v1/drivers now returns an additional ``type`` field to show if the driver is classic or dynamic. * GET /v1/drivers/ now returns an additional ``type`` field to show if the driver is classic or dynamic. * GET /v1/drivers/ now returns additional fields that are null for classic drivers, and set as following for dynamic drivers: * The value of the default__interface is the entrypoint name of the calculated default interface for that type: * default_boot_interface * default_console_interface * default_deploy_interface * default_inspect_interface * default_management_interface * default_network_interface * default_power_interface * default_raid_interface * default_vendor_interface * The value of the enabled__interfaces is a list of entrypoint names of the enabled interfaces for that type: * enabled_boot_interfaces * enabled_console_interfaces * enabled_deploy_interfaces * enabled_inspect_interfaces * enabled_management_interfaces * enabled_network_interfaces * enabled_power_interfaces * enabled_raid_interfaces * enabled_vendor_interfaces 1.29 (Ocata, 7.0.0) ------------------- Add a new management API to support inject NMI, 'PUT /v1/nodes/(node_ident)/management/inject_nmi'. 1.28 (Ocata, 7.0.0) ------------------- Add '/v1/nodes//vifs' endpoint for attach, detach and list of VIFs. 1.27 (Ocata, 7.0.0) ------------------- Add ``soft rebooting`` and ``soft power off`` as possible values for the ``target`` field of the power state change payload, and also add ``timeout`` field to it. 1.26 (Ocata, 7.0.0) ------------------- Add portgroup ``mode`` and ``properties`` fields. 1.25 (Ocata, 7.0.0) ------------------- Add possibility to unset chassis_uuid from a node. 1.24 (Ocata, 7.0.0) ------------------- Added new endpoints '/v1/nodes//portgroups' and '/v1/portgroups//ports'. Added new field ``port.portgroup_uuid``. 1.23 (Ocata, 7.0.0) ------------------- Added '/v1/portgroups/ endpoint. 1.22 (Newton, 6.1.0) -------------------- Added endpoints for deployment ramdisks. 1.21 (Newton, 6.1.0) -------------------- Add node ``resource_class`` field. 1.20 (Newton, 6.1.0) -------------------- Add node ``network_interface`` field. 1.19 (Newton, 6.1.0) -------------------- Add ``local_link_connection`` and ``pxe_enabled`` fields to the port object. 1.18 (Newton, 6.1.0) -------------------- Add ``internal_info`` readonly field to the port object, that will be used by ironic to store internal port-related information. 1.17 (Newton, 6.0.0) -------------------- Addition of provision_state verb ``adopt`` which allows an operator to move a node from ``manageable`` state to ``active`` state without performing a deployment operation on the node. This is intended for nodes that have already been deployed by external means. 1.16 (Mitaka, 5.0.0) -------------------- Add ability to filter nodes by driver. 1.15 (Mitaka, 5.0.0) -------------------- Add ability to do manual cleaning when a node is in the manageable provision state via PUT v1/nodes//states/provision, target:clean, clean_steps:[...]. 1.14 (Liberty, 4.2.0) --------------------- Make the following endpoints discoverable via Ironic API: * '/v1/nodes//states' * '/v1/drivers//properties' 1.13 (Liberty, 4.2.0) --------------------- Add a new verb ``abort`` to the API used to abort nodes in ``CLEANWAIT`` state. 1.12 (Liberty, 4.2.0) --------------------- This API version adds the following abilities: * Get/set ``node.target_raid_config`` and to get ``node.raid_config``. * Retrieve the logical disk properties for the driver. 1.11 (Liberty, 4.0.0, breaking change) -------------------------------------- Newly registered nodes begin in the ``enroll`` provision state by default, instead of ``available``. To get them to the ``available`` state, the ``manage`` action must first be run to verify basic hardware control. On success the node moves to ``manageable`` provision state. Then the ``provide`` action must be run. Automated cleaning of the node is done and the node is made ``available``. 1.10 (Liberty, 4.0.0) --------------------- Logical node names support all RFC 3986 unreserved characters. Previously only valid fully qualified domain names could be used. 1.9 (Liberty, 4.0.0) -------------------- Add ability to filter nodes by provision state. 1.8 (Liberty, 4.0.0) -------------------- Add ability to return a subset of resource fields. 1.7 (Liberty, 4.0.0) -------------------- Add node ``clean_step`` field. 1.6 (Kilo) ---------- Add :ref:`inspection` process: introduce ``inspecting`` and ``inspectfail`` provision states, and ``inspect`` action that can be used when a node is in ``manageable`` provision state. 1.5 (Kilo) ---------- Add logical node names that can be used to address a node in addition to the node UUID. Name is expected to be a valid `fully qualified domain name`_ in this version of API. 1.4 (Kilo) ---------- Add ``manageable`` state and ``manage`` transition, which can be used to move a node to ``manageable`` state from ``available``. The node cannot be deployed in ``manageable`` state. This change is mostly a preparation for future inspection work and introduction of ``enroll`` provision state. 1.3 (Kilo) ---------- Add node ``driver_internal_info`` field. 1.2 (Kilo, breaking change) --------------------------- Renamed NOSTATE (``None`` in Python, ``null`` in JSON) node state to ``available``. This is needed to reduce confusion around ``None`` state, especially when future additions to the state machine land. 1.1 (Kilo) ---------- This was the initial version when API versioning was introduced. Includes the following changes from Kilo release cycle: * Add node ``maintenance_reason`` field and an API endpoint to set/unset the node maintenance mode. * Add sync and async support for vendor passthru methods. * Vendor passthru endpoints support different HTTP methods, not only ``POST``. * Make vendor methods discoverable via the Ironic API. * Add logic to store the config drive passed by Nova. This has been the minimum supported version since versioning was introduced. 1.0 (Juno) ---------- This version denotes Juno API and was never explicitly supported, as API versioning was not implemented in Juno, and 1.1 became the minimum supported version in Kilo. .. _fully qualified domain name: https://en.wikipedia.org/wiki/Fully_qualified_domain_name ironic-10.1.1/doc/source/contributor/faq.rst0000666000175100017510000001265613243617463021046 0ustar zuulzuul00000000000000.. _faq: ========================================== Developer FAQ (frequently asked questions) ========================================== Here are some answers to frequently-asked questions from IRC and elsewhere. .. contents:: :local: :depth: 2 How do I... =========== ...create a migration script template? -------------------------------------- Using the ``ironic-dbsync revision`` command, e.g:: $ cd ironic $ tox -evenv -- ironic-dbsync revision -m \"create foo table\" It will create an empty alembic migration. For more information see the `alembic documentation`_. .. _`alembic documentation`: http://alembic.zzzcomputing.com/en/latest/tutorial.html#create-a-migration-script .. _faq_release_note: ...know if a release note is needed for my change? -------------------------------------------------- `Reno documentation`_ contains a description of what can be added to each section of a release note. If, after reading this, you're still unsure about whether to add a release note for your change or not, keep in mind that it is intended to contain information for deployers, so changes to unit tests or documentation are unlikely to require one. ...create a new release note? ----------------------------- By running ``reno`` command via tox, e.g:: $ tox -e venv -- reno new version-foo venv create: /home/foo/ironic/.tox/venv venv installdeps: -r/home/foo/ironic/test-requirements.txt venv develop-inst: /home/foo/ironic venv runtests: PYTHONHASHSEED='0' venv runtests: commands[0] | reno new version-foo Created new notes file in releasenotes/notes/version-foo-ecb3875dc1cbf6d9.yaml venv: commands succeeded congratulations :) $ git status On branch test Untracked files: (use "git add ..." to include in what will be committed) releasenotes/notes/version-foo-ecb3875dc1cbf6d9.yaml Then edit the result file. Note that: - we prefer to use present tense in release notes. For example, a release note should say "Adds support for feature foo", not "Added support for feature foo". (We use 'adds' instead of 'add' because grammatically, it is "ironic adds support", not "ironic add support".) - any variant of English spelling (American, British, Canadian, Australian...) is acceptable. The release note itself should be consistent and not have different spelling variants of the same word. For more information see the `reno documentation`_. .. _`reno documentation`: https://docs.openstack.org/reno/latest/user/usage.html ...update a release note? ------------------------- If this is a release note that pertains to something that was fixed on master or an intermediary release (during a development cycle, that hasn't been branched yet), you can go ahead and update it by submitting a patch. If it is the release note of an ironic release that has branched, `it can be updated `_ but we will only allow it in extenuating circumstances. (It can be updated by *only* updating the file in that branch. DO NOT update the file in master and cherry-pick it. If you do, `see how the mess was cleaned up `_.) ...get a decision on something? ------------------------------- You have an issue and would like a decision to be made. First, make sure that the issue hasn't already been addressed, by looking at documentation, bugs, specifications, or asking. Information and links can be found on the `Ironic wiki`_ page. There are several ways to solicit comments and opinions: * bringing it up at the `weekly Ironic meeting`_ * bringing it up on IRC_ * bringing it up on the `mailing list`_ (add "[Ironic]" to the Subject of the email) If there are enough core folks at the weekly meeting, after discussing an issue, voting could happen and a decision could be made. The problem with IRC or the weekly meeting is that feedback will only come from the people that are actually present. To inform (and solicit feedback from) more people about an issue, the preferred process is: #. bring it up on the mailing list #. after some period of time has elapsed (and depending on the thread activity), someone should propose a solution via gerrit. (E.g. the person that started the thread if no one else steps up.) The proposal should be made in the git repository that is associated with the issue. (For instance, this decision process was proposed as a documentation patch to the ironic repository.) #. In the email thread, don't forget to provide a link to the proposed patch! #. The discussion then moves to the proposed patch. If this is a big decision, we could declare that some percentage of the cores should vote on it before landing it. (This process was suggested in an email thread about `process for making decisions`_.) .. _Ironic wiki: https://wiki.openstack.org/wiki/Ironic .. _weekly Ironic meeting: https://wiki.openstack.org/wiki/Meetings/Ironic .. _IRC: https://wiki.openstack.org/wiki/Ironic#IRC .. _mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev .. _process for making decisions: http://lists.openstack.org/pipermail/openstack-dev/2016-May/095460.html ...add support for GMRs to new executables and extending the GMR? ----------------------------------------------------------------- For more information, see the `oslo.reports documentation `_ page. ironic-10.1.1/doc/source/contributor/architecture.rst0000666000175100017510000000637713243617463022764 0ustar zuulzuul00000000000000.. _architecture: =================== System Architecture =================== High Level description ====================== An Ironic deployment will be composed of the following components: - An admin-only RESTful `API service`_, by which privileged users, such as cloud operators and other services within the cloud control plane, may interact with the managed bare metal servers. - A `Conductor service`_, which does the bulk of the work. Functionality is exposed via the `API service`_. The Conductor and API services communicate via RPC. - A Database and `DB API`_ for storing the state of the Conductor and Drivers. - A Deployment Ramdisk or Deployment Agent, which provide control over the hardware which is not available remotely to the Conductor. A ramdisk should be built which contains one of these agents, eg. with `diskimage-builder`_. This ramdisk can be booted on-demand. .. note:: The agent is never run inside a tenant instance. .. _`architecture_drivers`: Drivers ======= The internal driver API provides a consistent interface between the Conductor service and the driver implementations. A driver is defined by a *hardware type* deriving from the AbstractHardwareType_ class, defining supported *hardware interfaces*. See :doc:`/install/enabling-drivers` for a more detailed explanation. See :doc:`drivers` for an explanation on how to write new hardware types and interfaces. Driver-Specific Periodic Tasks ------------------------------ Drivers may run their own periodic tasks, i.e. actions run repeatedly after a certain amount of time. Such a task is created by using the periodic_ decorator on an interface method. For example :: from futurist import periodics class FakePower(base.PowerInterface): @periodics.periodic(spacing=42) def task(self, manager, context): pass # do something Here the ``spacing`` argument is a period in seconds for a given periodic task. For example 'spacing=5' means every 5 seconds. Message Routing =============== Each Conductor registers itself in the database upon start-up, and periodically updates the timestamp of its record. Contained within this registration is a list of the drivers which this Conductor instance supports. This allows all services to maintain a consistent view of which Conductors and which drivers are available at all times. Based on their respective driver, all nodes are mapped across the set of available Conductors using a `consistent hashing algorithm`_. Node-specific tasks are dispatched from the API tier to the appropriate conductor using conductor-specific RPC channels. As Conductor instances join or leave the cluster, nodes may be remapped to different Conductors, thus triggering various driver actions such as take-over or clean-up. .. _API service: webapi.html .. _AbstractHardwareType: api/ironic.drivers.hardware_type.html#ironic.drivers.hardware_type.AbstractHardwareType .. _Conductor service: api/ironic.conductor.manager.html .. _DB API: api/ironic.db.api.html .. _diskimage-builder: https://docs.openstack.org/diskimage-builder/latest/ .. _consistent hashing algorithm: https://docs.openstack.org/tooz/latest/user/tutorial/hashring.html .. _periodic: https://docs.openstack.org/futurist/latest/reference/index.html#futurist.periodics.periodic ironic-10.1.1/doc/source/contributor/ironic-multitenant-networking.rst0000666000175100017510000001004513243617463026277 0ustar zuulzuul00000000000000========================================== Ironic multitenant networking and DevStack ========================================== This guide will walk you through using OpenStack Ironic/Neutron with the ML2 ``networking-generic-switch`` plugin. Using VMs as baremetal servers ============================== This scenario shows how to setup Devstack to use Ironic/Neutron integration with VMs as baremetal servers and ML2 ``networking-generic-switch`` that interacts with OVS. DevStack Configuration ---------------------- The following is ``local.conf`` that will setup Devstack with 3 VMs that are registered in ironic. ``networking-generic-switch`` driver will be installed and configured in Neutron. :: [[local|localrc]] # Configure ironic from ironic devstack plugin. enable_plugin ironic https://git.openstack.org/openstack/ironic # Install networking-generic-switch Neutron ML2 driver that interacts with OVS enable_plugin networking-generic-switch https://git.openstack.org/openstack/networking-generic-switch # Add link local info when registering Ironic node IRONIC_USE_LINK_LOCAL=True IRONIC_ENABLED_NETWORK_INTERFACES=flat,neutron IRONIC_NETWORK_INTERFACE=neutron #Networking configuration OVS_PHYSICAL_BRIDGE=brbm PHYSICAL_NETWORK=mynetwork IRONIC_PROVISION_NETWORK_NAME=ironic-provision IRONIC_PROVISION_SUBNET_PREFIX=10.0.5.0/24 IRONIC_PROVISION_SUBNET_GATEWAY=10.0.5.1 Q_PLUGIN=ml2 ENABLE_TENANT_VLANS=True Q_ML2_TENANT_NETWORK_TYPE=vlan TENANT_VLAN_RANGE=100:150 # Neutron public network type was changed to flat by default # in neutron commit 1554adef26bd3bd184ddab668660428bdf392232 Q_USE_PROVIDERNET_FOR_PUBLIC=False # Credentials ADMIN_PASSWORD=password RABBIT_PASSWORD=password DATABASE_PASSWORD=password SERVICE_PASSWORD=password SERVICE_TOKEN=password SWIFT_HASH=password SWIFT_TEMPURL_KEY=password # Enable Ironic API and Ironic Conductor enable_service ironic enable_service ir-api enable_service ir-cond # Disable nova novnc service, ironic does not support it anyway. disable_service n-novnc # Enable Swift for the direct deploy interface. enable_service s-proxy enable_service s-object enable_service s-container enable_service s-account # Disable Horizon disable_service horizon # Disable Cinder disable_service cinder c-sch c-api c-vol # Disable Tempest disable_service tempest # Swift temp URL's are required for the direct deploy interface. SWIFT_ENABLE_TEMPURLS=True # Create 3 virtual machines to pose as Ironic's baremetal nodes. IRONIC_VM_COUNT=3 IRONIC_BAREMETAL_BASIC_OPS=True # Enable additional hardware types, if needed. #IRONIC_ENABLED_HARDWARE_TYPES=ipmi,fake-hardware # Don't forget that many hardware types require enabling of additional # interfaces, most often power and management: #IRONIC_ENABLED_MANAGEMENT_INTERFACES=ipmitool,fake #IRONIC_ENABLED_POWER_INTERFACES=ipmitool,fake # The default deploy interface is 'iscsi', you can use 'direct' with #IRONIC_DEFAULT_DEPLOY_INTERFACE=direct # Change this to alter the default driver for nodes created by devstack. # This driver should be in the enabled list above. IRONIC_DEPLOY_DRIVER=ipmi # The parameters below represent the minimum possible values to create # functional nodes. IRONIC_VM_SPECS_RAM=1024 IRONIC_VM_SPECS_DISK=10 # Size of the ephemeral partition in GB. Use 0 for no ephemeral partition. IRONIC_VM_EPHEMERAL_DISK=0 # To build your own IPA ramdisk from source, set this to True IRONIC_BUILD_DEPLOY_RAMDISK=False VIRT_DRIVER=ironic # By default, DevStack creates a 10.0.0.0/24 network for instances. # If this overlaps with the hosts network, you may adjust with the # following. NETWORK_GATEWAY=10.1.0.1 FIXED_RANGE=10.1.0.0/24 FIXED_NETWORK_SIZE=256 # Log all output to files LOGFILE=$HOME/devstack.log LOGDIR=$HOME/logs IRONIC_VM_LOG_DIR=$HOME/ironic-bm-logs ironic-10.1.1/doc/source/contributor/rolling-upgrades.rst0000666000175100017510000006062713243617463023556 0ustar zuulzuul00000000000000.. _rolling-upgrades-dev: ================ Rolling Upgrades ================ The ironic (ironic-api and ironic-conductor) services support rolling upgrades, starting with a rolling upgrade from the Ocata to the Pike release. This describes the design of rolling upgrades, followed by notes for developing new features or modifying an IronicObject. Design ====== Rolling upgrades between releases --------------------------------- Ironic follows the `release-cycle-with-intermediary release model `_. The releases are `semantic-versioned `_, in the form ... We refer to a ``named release`` of ironic as the release associated with a development cycle like Pike. In addition, ironic follows the `standard deprecation policy `_, which says that the deprecation period must be at least three months and a cycle boundary. This means that there will never be anything that is both deprecated *and* removed between two named releases. Rolling upgrades will be supported between: * named release N to N+1 (starting with N == Ocata) * any named release to its latest revision, containing backported bug fixes. Because those bug fixes can contain improvements to the upgrade process, the operator should patch the system before upgrading between named releases. * most recent named release N (and semver releases newer than N) to master. As with the above bullet point, there may be a bug or a feature introduced on a master branch, that we want to remove before publishing a named release. Deprecation policy allows to do this in a 3 month time frame. If the feature was included and removed in intermediate releases, there should be a release note added, with instructions on how to do a rolling upgrade to master from an affected release or release span. This would typically instruct the operator to upgrade to a particular intermediate release, before upgrading to master. Rolling upgrade process ----------------------- Ironic supports rolling upgrades as described in the :doc:`upgrade guide <../admin/upgrade-guide>`. The upgrade process will cause the ironic services to be running the ``FromVer`` and ``ToVer`` releases in this order: 0. Upgrade ironic code and run database schema migrations via the ``ironic-dbsync upgrade`` command. 1. Upgrade code and restart ironic-conductor services, one at a time. 2. Upgrade code and restart ironic-api services, one at a time. 3. Unpin API, RPC and object versions so that the services can now use the latest versions in ``ToVer``. This is done via updating the configuration option described below in `API, RPC and object version pinning`_ and then restarting the services. ironic-conductor services should be restarted first, followed by the ironic-api services. This is to ensure that when new functionality is exposed on the unpinned API service (via API micro version), it is available on the backend. +------+---------------------------------+---------------------------------+ | step | ironic-api | ironic-conductor | +======+=================================+=================================+ | 0 | all FromVer | all FromVer | +------+---------------------------------+---------------------------------+ | 1.1 | all FromVer | some FromVer, some ToVer-pinned | +------+---------------------------------+---------------------------------+ | 1.2 | all FromVer | all ToVer-pinned | +------+---------------------------------+---------------------------------+ | 2.1 | some FromVer, some ToVer-pinned | all ToVer-pinned | +------+---------------------------------+---------------------------------+ | 2.2 | all ToVer-pinned | all ToVer-pinned | +------+---------------------------------+---------------------------------+ | 3.1 | all ToVer-pinned | some ToVer-pinned, some ToVer | +------+---------------------------------+---------------------------------+ | 3.2 | all ToVer-pinned | all ToVer | +------+---------------------------------+---------------------------------+ | 3.3 | some ToVer-pinned, some ToVer | all ToVer | +------+---------------------------------+---------------------------------+ | 3.4 | all ToVer | all ToVer | +------+---------------------------------+---------------------------------+ Policy for changes to the DB model ---------------------------------- The policy for changes to the DB model is as follows: * Adding new items to the DB model is supported. * The dropping of columns or tables and corresponding objects' fields is subject to ironic's `deprecation policy `_. But its alembic script has to wait one more deprecation period, otherwise an ``unknown column`` exception will be thrown when ``FromVer`` services access the DB. This is because :command:`ironic-dbsync upgrade` upgrades the DB schema but ``FromVer`` services still contain the dropped field in their SQLAlchemy DB model. * An ``alembic.op.alter_column()`` to rename or resize a column is not allowed. Instead, split it into multiple operations, with one operation per release cycle (to maintain compatibility with an old SQLAlchemy model). For example, to rename a column, add the new column in release N, then remove the old column in release N+1. * Some implementations of SQL's ``ALTER TABLE``, such as adding foreign keys in PostgreSQL, may impose table locks and cause downtime. If the change cannot be avoided and the impact is significant (e.g. the table can be frequently accessed and/or store a large dataset), these cases must be mentioned in the release notes. API, RPC and object version pinning ----------------------------------- For the ironic services to be running old and new releases at the same time during a rolling upgrade, the services need to be able to handle different API, RPC and object versions. This versioning is handled via the configuration option: ``[DEFAULT]/pin_release_version``. It is used to pin the API, RPC and IronicObject (e.g., Node, Conductor, Chassis, Port, and Portgroup) versions for all the ironic services. The default value of empty indicates that ironic-api and ironic-conductor will use the latest versions of API, RPC and IronicObjects. Its possible values are releases, named (e.g. ``ocata``) or sem-versioned (e.g. ``7.0``). Internally, in `common/release_mappings.py `_, ironic maintains a mapping that indicates the API, RPC and IronicObject versions associated with each release. This mapping is maintained manually. During a rolling upgrade, the services using the new release will set the configuration option value to be the name (or version) of the old release. This will indicate to the services running the new release, which API, RPC and object versions that they should be compatible with, in order to communicate with the services using the old release. Handling API versions --------------------- When the (newer) service is pinned, the maximum API version it supports will be the pinned version -- which the older service supports (as described above at `API, RPC and object version pinning`_). The ironic-api service returns HTTP status code 406 for any requests with API versions that are higher than this maximum version. Handling RPC versions --------------------- `ConductorAPI.__init__() `_ sets the ``version_cap`` variable to the desired (latest or pinned) RPC API version and passes it to the ``RPCClient`` as an initialization parameter. This variable is then used to determine the maximum requested message version that the ``RPCClient`` can send. Each RPC call can customize the request according to this ``version_cap``. The `Ironic RPC versions`_ section below has more details about this. Handling IronicObject versions ------------------------------ Internally, ironic services deal with IronicObjects in their latest versions. Only at these boundaries, when the IronicObject enters or leaves the service, do we deal with object versioning: * getting objects from the database: convert to latest version * saving objects to the database: if pinned, save in pinned version; else save in latest version * serializing objects (to send over RPC): if pinned, send pinned version; else send latest version * deserializing objects (receiving objects from RPC): convert to latest version The ironic-api service also has to handle API requests/responses based on whether or how a feature is supported by the API version and object versions. For example, when the ironic-api service is pinned, it can only allow actions that are available to the object's pinned version, and cannot allow actions that are only available for the latest version of that object. To support this: * All the database tables (SQLAlchemy models) of the IronicObjects have a column named ``version``. The value is the version of the object that is saved in the database. * The method ``IronicObject.get_target_version()`` returns the target version. If pinned, the pinned version is returned. Otherwise, the latest version is returned. * The method ``IronicObject.convert_to_version()`` converts the object into the target version. The target version may be a newer or older version than the existing version of the object. The bulk of the work is done in the helper method ``IronicObject._convert_to_version()``. Subclasses that have new versions redefine this to perform the actual conversions. In the following, * The old release is ``FromVer``; it uses version 1.14 of a Node object. * The new release is ``ToVer``. It uses version 1.15 of a Node object -- this has a deprecated ``extra`` field and a new ``meta`` field that replaces ``extra``. * db_obj['meta'] and db_obj['extra'] are the database representations of those node fields. Getting objects from the database (API/conductor <-- DB) :::::::::::::::::::::::::::::::::::::::::::::::::::::::: Both ironic-api and ironic-conductor services read values from the database. These values are converted to IronicObjects via the method ``IronicObject._from_db_object()``. This method always returns the IronicObject in its latest version, even if it was in an older version in the database. This is done regardless of the service being pinned or not. Note that if an object is converted to a later version, that IronicObject will retain any changes (in its ``_changed_fields`` field) resulting from that conversion. This is needed in case the object gets saved later, in the latest version. For example, if the node in the database is in version 1.14 and has db_obj['extra'] set: * a ``FromVer`` service will get a Node with node.extra = db_obj['extra'] (and no knowledge of node.meta since it doesn't exist) * a ``ToVer`` service (pinned or unpinned), will get a Node with: * node.meta = db_obj['extra'] * node.extra = None * node._changed_fields = ['meta', 'extra'] Saving objects to the database (API/conductor --> DB) ::::::::::::::::::::::::::::::::::::::::::::::::::::: The version used for saving IronicObjects to the database is determined as follows: * For an unpinned service, the object is saved in its latest version. Since objects are always in their latest version, no conversions are needed. * For a pinned service, the object is saved in its pinned version. Since objects are always in their latest version, the object needs to be converted to the pinned version before being saved. The method ``IronicObject.do_version_changes_for_db()`` handles this logic, returning a dictionary of changed fields and their new values (similar to the existing ``oslo.versionedobjects.VersionedObject.obj_get_changes()``). Since we do not keep track internally, of the database version of an object, the object's ``version`` field will always be part of these changes. The `Rolling upgrade process`_ (at step 3.1) ensures that by the time an object can be saved in its latest version, all services are running the newer release (although some may still be pinned) and can handle the latest object versions. An interesting situation can occur when the services are as described in step 3.1. It is possible for an IronicObject to be saved in a newer version and subsequently get saved in an older version. For example, a ``ToVer`` unpinned conductor might save a node in version 1.5. A subsequent request may cause a ``ToVer`` pinned conductor to replace and save the same node in version 1.4! Sending objects via RPC (API/conductor -> RPC) :::::::::::::::::::::::::::::::::::::::::::::: When a service makes an RPC request, any IronicObjects that are sent as part of that request are serialized into entities or primitives via ``IronicObjectSerializer.serialize_entity()``. The version used for objects being serialized is as follows: * For an unpinned service, the object is serialized to its latest version. Since objects are always in their latest version, no conversions are needed. * For a pinned service, the object is serialized to its pinned version. Since objects are always in their latest version, the object is converted to the pinned version before being serialized. The converted object includes changes that resulted from the conversion; this is needed so that the service at the other end of the RPC request has the necessary information if that object will be saved to the database. Receiving objects via RPC (API/conductor <- RPC) :::::::::::::::::::::::::::::::::::::::::::::::: When a service receives an RPC request, any entities that are part of the request need to be deserialized (via ``oslo.versionedobjects.VersionedObjectSerializer.deserialize_entity()``). For entities that represent IronicObjects, we want the deserialization process (via ``IronicObjectSerializer._process_object()``) to result in IronicObjects that are in their latest version, regardless of the version they were sent in and regardless of whether the receiving service is pinned or not. Again, any objects that are converted will retain the changes that resulted from the conversion, useful if that object is later saved to the database. For example, a ``FromVer`` ironic-api could issue an ``update_node()`` RPC request with a node in version 1.4, where node.extra was changed (so node._changed_fields = ['extra']). This node will be serialized in version 1.4. The receiving ``ToVer`` pinned ironic-conductor deserializes it and converts it to version 1.5. The resulting node will have node.meta set (to the changed value from node.extra in v1.4), node.extra = None, and node._changed_fields = ['meta', 'extra']. When developing a new feature or modifying an IronicObject ========================================================== When adding a new feature or changing an IronicObject, they need to be coded so that things work during a rolling upgrade. The following describe areas where the code may need to be changed, as well as some points to keep in mind when developing code. ironic-api ---------- During a rolling upgrade, the new, pinned ironic-api is talking to a new conductor that might also be pinned. There may also be old ironic-api services. So the new, pinned ironic-api service needs to act like it was the older service: * New features should not be made available, unless they are somehow totally supported in the old and new releases. Pinning the API version is in place to handle this. * If, for whatever reason, the API version pinning doesn't prevent a request from being handled that cannot or should not be handled, it should be coded so that the response has HTTP status code 406 (Not Acceptable). This is the same response to requests that have an incorrect (old) version specified. Ironic RPC versions ------------------- When the signature (arguments) of an RPC method is changed or new methods are added, the following needs to be considered: - The RPC version must be incremented and be the same value for both the client (``ironic/conductor/rpcapi.py``, used by ironic-api) and the server (``ironic/conductor/manager.py``, used by ironic-conductor). It should also be updated in ``ironic/common/release_mappings.py``. - Until there is a major version bump, new arguments of an RPC method can only be added as optional. Existing arguments cannot be removed or changed in incompatible ways with the method in older RPC versions. - ironic-api (client-side) sets a version cap (by passing the version cap to the constructor of oslo_messaging.RPCClient). This "pinning" is in place during a rolling upgrade when the ``[DEFAULT]/pin_release_version`` configuration option is set. - New RPC methods are not available when the service is pinned to the older release version. In this case, the corresponding REST API function should return a server error or implement alternative behaviours. - Methods which change arguments should run ``client.can_send_version()`` to see if the version of the request is compatible with the version cap of the RPC Client. Otherwise the request needs to be created to work with a previous version that is supported. - ironic-conductor (server-side) should tolerate older versions of requests in order to keep working during the rolling upgrade process. The behaviour of ironic-conductor will depend on the input parameters passed from the client-side. - Old methods can be removed only after they are no longer used by a previous named release. Object versions --------------- When subclasses of ``ironic.objects.base.IronicObject`` are modified, the following needs to be considered: - Any change of fields or change in signature of remotable methods needs a bump of the object version. The object versions are also maintained in ``ironic/common/release_mappings.py``. - New objects must be added to ``ironic/common/release_mappings.py``. - The arguments of remotable methods (methods which are remoted to the conductor via RPC) can only be added as optional. They cannot be removed or changed in an incompatible way (to the previous release). - Field types cannot be changed. Instead, create a new field and deprecate the old one. - There is a `unit test `_ that generates the hash of an object using its fields and the signatures of its remotable methods. Objects that have a version bump need to be updated in the `expected_object_fingerprints `_ dictionary; otherwise this test will fail. A failed test can also indicate to the developer that their change(s) to an object require a version bump. - When new version objects communicate with old version objects and when reading or writing to the database, ``ironic.objects.base.IronicObject._convert_to_version()`` will be called to convert objects to the target version. Objects should implement their own ._convert_to_version() to remove or alter fields which were added or changed after the target version:: def _convert_to_version(self, target_version, remove_unavailable_fields=True): """Convert to the target version. Subclasses should redefine this method, to do the conversion of the object to the target version. Convert the object to the target version. The target version may be the same, older, or newer than the version of the object. This is used for DB interactions as well as for serialization/deserialization. The remove_unavailable_fields flag is used to distinguish these two cases: 1) For serialization/deserialization, we need to remove the unavailable fields, because the service receiving the object may not know about these fields. remove_unavailable_fields is set to True in this case. 2) For DB interactions, we need to set the unavailable fields to their appropriate values so that these fields are saved in the DB. (If they are not set, the VersionedObject magic will not know to save/update them to the DB.) remove_unavailable_fields is set to False in this case. :param target_version: the desired version of the object :param remove_unavailable_fields: True to remove fields that are unavailable in the target version; set this to True when (de)serializing. False to set the unavailable fields to appropriate values; set this to False for DB interactions. This method must handle: * converting from an older version to a newer version * converting from a newer version to an older version * making sure, when converting, that you take into consideration other object fields that may have been affected by a field (value) only available in a newer version. For example, if field 'new' is only available in Node version 1.5 and Node.affected = Node.new+3, when converting to 1.4 (an older version), you may need to change the value of Node.affected too. Online data migrations ---------------------- The ``ironic-dbsync online_data_migrations`` command will perform online data migrations. Keep in mind the `Policy for changes to the DB model`_. Future incompatible changes in SQLAlchemy models, like removing or renaming columns and tables can break rolling upgrades (when ironic services are run with different release versions simultaneously). It is forbidden to remove these database resources when they may still be used by the previous named release. When `creating new Alembic migrations `_ which modify existing models, make sure that any new columns default to NULL. Test the migration out on a non-empty database to make sure that any new constraints don't cause the database to be locked out for normal operations. You can find an overview on what DDL operations may cause downtime in https://dev.mysql.com/doc/refman/5.7/en/innodb-create-index-overview.html. (You should also check older, widely deployed InnoDB versions for issues.) In the case of PostgreSQL, adding a foreign key may lock a whole table for writes. Make sure to add a release note if there are any downtime-related concerns. Backfilling default values, and migrating data between columns or between tables must be implemented inside an online migration script. A script is a database API method (added to ``ironic/db/api.py`` and ``ironic/db/sqlalchemy/api.py``) which takes two arguments: - context: an admin context - max_count: this is used to limit the query. It is the maximum number of objects to migrate; >= 0. If zero, all the objects will be migrated. It returns a two-tuple: - the total number of objects that need to be migrated, at the start of the method, and - the number of migrated objects. In this method, the version column can be used to select and update old objects. The method name should be added to the list of ``ONLINE_MIGRATIONS`` in ``ironic/cmd/dbsync.py``. The method should be removed in the next named release after this one. After online data migrations are completed and the SQLAlchemy models no longer contain old fields, old columns can be removed from the database. This takes at least 3 releases, since we have to wait until the previous named release no longer contains references to the old schema. Before removing any resources from the database by modifying the schema, make sure that your implementation checks that all objects in the affected tables have been migrated. This check can be implemented using the version column. "ironic-dbsync upgrade" command ------------------------------- The ``ironic-dbsync upgrade`` command first checks that the versions of the objects are compatible with the (new) release of ironic, before it will make any DB schema changes. If one or more objects are not compatible, the upgrade will not be performed. This check is done by comparing the objects' ``version`` field in the database with the expected (or supported) versions of these objects. The supported versions are the versions specified in ``ironic.common.release_mappings.RELEASE_MAPPING``. ironic-10.1.1/doc/source/contributor/governance.rst0000666000175100017510000000265413243617463022423 0ustar zuulzuul00000000000000=========================== Ironic Governance Structure =========================== The ironic project manages a number of repositories that contribute to our mission. The full list of repositories that ironic manages is available in the `governance site`_. .. _`governance site`: https://governance.openstack.org/reference/projects/ironic.html What belongs in ironic governance? ================================== For a repository to be part of the Ironic project: * It must comply with the TC's `rules for a new project `_. * It must not be intended for use with only a single vendor's hardware. A library that implements a standard to manage hardware from multiple vendors (such as IPMI or redfish) is okay. * It must align with Ironic's `mission statement `_. Lack of contributor diversity is a chicken-egg problem, and as such a repository where only a single company is contributing is okay, with the hope that other companies will contribute after joining the ironic project. Repositories that are no longer maintained should be pruned from governance regularly. Proposing a new project to ironic governance ============================================ Bring the proposal to the ironic `weekly meeting `_ to discuss with the team. ironic-10.1.1/doc/source/contributor/releasing.rst0000666000175100017510000001316513243617471022243 0ustar zuulzuul00000000000000========================= Releasing Ironic Projects ========================= Since the responsibility for releases will move between people, we document that process here. A full list of projects that ironic manages is available in the `governance site`_. .. _`governance site`: https://governance.openstack.org/reference/projects/ironic.html Who is responsible for releases? ================================ The current PTL is ultimately responsible for making sure code gets released. They may choose to delegate this responsibility to a liaison, which is documented in the `cross-project liaison wiki`_. Anyone may submit a release request per the process below, but the PTL or liaison must +1 the request for it to be processed. .. _`cross-project liaison wiki`: https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management Release process =============== Releases are managed by the OpenStack release team. The release process is documented in the `Project Team Guide`_. .. _`Project Team Guide`: https://docs.openstack.org/project-team-guide/release-management.html#how-to-release Things to do before releasing ============================= * Review the unreleased release notes, if the project uses them. Make sure they follow our :ref:`standards `, are coherent, and have proper grammar. Combine release notes if necessary (for example, a release note for a feature and another release note to add to that feature may be combined). * For ironic releases only, not ironic-inspector releases: if any new API microversions have been added since the last release, update the REST API version history (``doc/source/contributor/webapi-version-history.rst``) to indicate that they were part of the new release. * To support rolling upgrades, add this new release version (and release name if it is a named release) into ``ironic/common/release_mappings.py``: * in ``RELEASE_MAPPING`` make a copy of the ``master`` entry, and rename the first ``master`` entry to the new semver release version. * If this is a named release, add a ``RELEASE_MAPPING`` entry for the named release. Its value should be the same as that of the latest semver one (that you just added above). It is important to do this before a stable/ branch is made (or if `the grenade switch is made `_ to use the latest release from stable as the 'old' release). Otherwise, once it is made, CI (a `unit test `_ and grenade that tests new-release -> master) will fail. Things to do after releasing ============================ When a release is done that results in a stable branch ------------------------------------------------------ When a release is done that results in a stable branch for the project, several changes need to be made. The release automation will push a number of changes that need to be approved. This includes: * In the new stable branch: * a change to point ``.gitreview`` at the branch * a change to update the upper constraints file used by ``tox`` * In the master branch: * updating the release notes RST to include the new branch. The generated RST does not include the version range in the title, so we typically submit a follow-up patch to do that. We also manually mark the ``earliest-version`` directive on the new page, due to a `reno bug ` that may cause this to be incorrect for stable branches. We need to submit patches for changes in the stable branch to: * update the ironic devstack plugin to point at the branched tarball for IPA. An example of this patch is `here `_. * update links in the documentation (``ironic/doc/source/``) to point to the branched versions of any openstack projects' (that branch) documents. As of Pike release, the only outlier is `diskimage-builder `_. * set appropriate defaults for ``TEMPEST_BAREMETAL_MIN_MICROVERSION`` and ``TEMPEST_BAREMETAL_MAX_MICROVERSION`` in ``devstack/lib/ironic`` to make sure that unsupported API tempest tests are skipped on stable branches. E.g. `patch 495319 `_. We need to submit patches for changes on master to: * create an empty commit with a ``Sem-Ver`` tag to bump the generated minor version. See `example `_ and `pbr documentation `_ for details. * to support rolling upgrades, since the release was a named release: * In ``ironic/common/release_mappings.py``, delete any entries from ``RELEASE_MAPPING`` associated with the oldest named release. Since we support upgrades between adjacent named releases, the master branch will only support upgrades from the most recent named release to master. * remove any DB migration scripts from ``ironic.cmd.dbsync.ONLINE_MIGRATIONS`` and remove the corresponding code from ironic. (These migration scripts are used to migrate from an old release to this latest release; they shouldn't be needed after that.) For all releases ---------------- For all releases, whether or not it results in a stable branch: * update the specs repo to mark any specs completed in the release as implemented. * remove any -2s on patches that were blocked until after the release. ironic-10.1.1/LICENSE0000666000175100017510000002363713243617463014134 0ustar zuulzuul00000000000000 Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. "Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. "Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License. "Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. "Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. "Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. "Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution." "Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and (b) You must cause any modified files to carry prominent notices stating that You changed the files; and (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and (d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. 8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. 9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability. ironic-10.1.1/PKG-INFO0000664000175100017510000000463313243617733014215 0ustar zuulzuul00000000000000Metadata-Version: 1.1 Name: ironic Version: 10.1.1 Summary: OpenStack Bare Metal Provisioning Home-page: https://docs.openstack.org/ironic/latest/ Author: OpenStack Author-email: openstack-dev@lists.openstack.org License: UNKNOWN Description-Content-Type: UNKNOWN Description: ======================== Team and repository tags ======================== .. image:: https://governance.openstack.org/badges/ironic.svg :target: https://governance.openstack.org/reference/tags/index.html .. Change things from this point on ====== Ironic ====== Ironic consists of an API and plug-ins for managing and provisioning physical machines in a security-aware and fault-tolerant manner. It can be used with nova as a hypervisor driver, or standalone service using bifrost. By default, it will use PXE and IPMI to interact with bare metal machines. Ironic also supports vendor-specific plug-ins which may implement additional functionality. Ironic is distributed under the terms of the Apache License, Version 2.0. The full terms and conditions of this license are detailed in the LICENSE file. Project resources ~~~~~~~~~~~~~~~~~ * Documentation: https://docs.openstack.org/ironic/latest * Source: https://git.openstack.org/cgit/openstack/ironic * Bugs: https://bugs.launchpad.net/ironic * Wiki: https://wiki.openstack.org/wiki/Ironic * APIs: https://developer.openstack.org/api-ref/baremetal/index.html Project status, bugs, and requests for feature enhancements (RFEs) are tracked on Launchpad: https://launchpad.net/ironic For information on how to contribute to ironic, see https://docs.openstack.org/ironic/latest/contributor Platform: UNKNOWN Classifier: Environment :: OpenStack Classifier: Intended Audience :: Information Technology Classifier: Intended Audience :: System Administrators Classifier: License :: OSI Approved :: Apache Software License Classifier: Operating System :: POSIX :: Linux Classifier: Programming Language :: Python Classifier: Programming Language :: Python :: 2 Classifier: Programming Language :: Python :: 2.7 Classifier: Programming Language :: Python :: 3 Classifier: Programming Language :: Python :: 3.5 ironic-10.1.1/requirements.txt0000666000175100017510000000332213243617471016377 0ustar zuulzuul00000000000000# The order of packages is significant, because pip processes them in the order # of appearance. Changing the order has an impact on the overall integration # process, which may cause wedges in the gate later. pbr!=2.1.0,>=2.0.0 # Apache-2.0 SQLAlchemy!=1.1.5,!=1.1.6,!=1.1.7,!=1.1.8,>=1.0.10 # MIT alembic>=0.8.10 # MIT automaton>=1.9.0 # Apache-2.0 eventlet!=0.18.3,!=0.20.1,<0.21.0,>=0.18.2 # MIT WebOb>=1.7.1 # MIT python-cinderclient>=3.3.0 # Apache-2.0 python-neutronclient>=6.3.0 # Apache-2.0 python-glanceclient>=2.8.0 # Apache-2.0 keystoneauth1>=3.3.0 # Apache-2.0 ironic-lib>=2.5.0 # Apache-2.0 python-swiftclient>=3.2.0 # Apache-2.0 pytz>=2013.6 # MIT stevedore>=1.20.0 # Apache-2.0 pysendfile>=2.0.0 # MIT oslo.concurrency>=3.25.0 # Apache-2.0 oslo.config>=5.1.0 # Apache-2.0 oslo.context>=2.19.2 # Apache-2.0 oslo.db>=4.27.0 # Apache-2.0 oslo.rootwrap>=5.8.0 # Apache-2.0 oslo.i18n>=3.15.3 # Apache-2.0 oslo.log>=3.36.0 # Apache-2.0 oslo.middleware>=3.31.0 # Apache-2.0 oslo.policy>=1.30.0 # Apache-2.0 oslo.reports>=1.18.0 # Apache-2.0 oslo.serialization!=2.19.1,>=2.18.0 # Apache-2.0 oslo.service!=1.28.1,>=1.24.0 # Apache-2.0 oslo.utils>=3.33.0 # Apache-2.0 osprofiler>=1.4.0 # Apache-2.0 os-traits>=0.4.0 # Apache-2.0 pecan!=1.0.2,!=1.0.3,!=1.0.4,!=1.2,>=1.0.0 # BSD requests>=2.14.2 # Apache-2.0 rfc3986>=0.3.1 # Apache-2.0 six>=1.10.0 # MIT jsonpatch!=1.20,>=1.16 # BSD WSME>=0.8.0 # MIT Jinja2!=2.9.0,!=2.9.1,!=2.9.2,!=2.9.3,!=2.9.4,>=2.8 # BSD License (3 clause) keystonemiddleware>=4.17.0 # Apache-2.0 oslo.messaging>=5.29.0 # Apache-2.0 retrying!=1.3.0,>=1.2.3 # Apache-2.0 oslo.versionedobjects>=1.31.2 # Apache-2.0 jsonschema<3.0.0,>=2.6.0 # MIT psutil>=3.2.2 # BSD futurist>=1.2.0 # Apache-2.0 tooz>=1.58.0 # Apache-2.0 ironic-10.1.1/ironic.egg-info/0000775000175100017510000000000013243617733016067 5ustar zuulzuul00000000000000ironic-10.1.1/ironic.egg-info/not-zip-safe0000664000175100017510000000000113243617634020315 0ustar zuulzuul00000000000000 ironic-10.1.1/ironic.egg-info/PKG-INFO0000664000175100017510000000463313243617730017167 0ustar zuulzuul00000000000000Metadata-Version: 1.1 Name: ironic Version: 10.1.1 Summary: OpenStack Bare Metal Provisioning Home-page: https://docs.openstack.org/ironic/latest/ Author: OpenStack Author-email: openstack-dev@lists.openstack.org License: UNKNOWN Description-Content-Type: UNKNOWN Description: ======================== Team and repository tags ======================== .. image:: https://governance.openstack.org/badges/ironic.svg :target: https://governance.openstack.org/reference/tags/index.html .. Change things from this point on ====== Ironic ====== Ironic consists of an API and plug-ins for managing and provisioning physical machines in a security-aware and fault-tolerant manner. It can be used with nova as a hypervisor driver, or standalone service using bifrost. By default, it will use PXE and IPMI to interact with bare metal machines. Ironic also supports vendor-specific plug-ins which may implement additional functionality. Ironic is distributed under the terms of the Apache License, Version 2.0. The full terms and conditions of this license are detailed in the LICENSE file. Project resources ~~~~~~~~~~~~~~~~~ * Documentation: https://docs.openstack.org/ironic/latest * Source: https://git.openstack.org/cgit/openstack/ironic * Bugs: https://bugs.launchpad.net/ironic * Wiki: https://wiki.openstack.org/wiki/Ironic * APIs: https://developer.openstack.org/api-ref/baremetal/index.html Project status, bugs, and requests for feature enhancements (RFEs) are tracked on Launchpad: https://launchpad.net/ironic For information on how to contribute to ironic, see https://docs.openstack.org/ironic/latest/contributor Platform: UNKNOWN Classifier: Environment :: OpenStack Classifier: Intended Audience :: Information Technology Classifier: Intended Audience :: System Administrators Classifier: License :: OSI Approved :: Apache Software License Classifier: Operating System :: POSIX :: Linux Classifier: Programming Language :: Python Classifier: Programming Language :: Python :: 2 Classifier: Programming Language :: Python :: 2.7 Classifier: Programming Language :: Python :: 3 Classifier: Programming Language :: Python :: 3.5 ironic-10.1.1/ironic.egg-info/SOURCES.txt0000664000175100017510000016623613243617733017771 0ustar zuulzuul00000000000000.mailmap .stestr.conf AUTHORS CONTRIBUTING.rst ChangeLog LICENSE README.rst Vagrantfile babel.cfg bindep.txt driver-requirements.txt requirements.txt setup.cfg setup.py test-requirements.txt tox.ini vagrant.yaml api-ref/regenerate-samples.sh api-ref/source/baremetal-api-v1-chassis.inc api-ref/source/baremetal-api-v1-driver-passthru.inc api-ref/source/baremetal-api-v1-drivers.inc api-ref/source/baremetal-api-v1-misc.inc api-ref/source/baremetal-api-v1-node-management.inc api-ref/source/baremetal-api-v1-node-passthru.inc api-ref/source/baremetal-api-v1-nodes-portgroups.inc api-ref/source/baremetal-api-v1-nodes-ports.inc api-ref/source/baremetal-api-v1-nodes-traits.inc api-ref/source/baremetal-api-v1-nodes-vifs.inc api-ref/source/baremetal-api-v1-nodes-volume.inc api-ref/source/baremetal-api-v1-nodes.inc api-ref/source/baremetal-api-v1-portgroups-ports.inc api-ref/source/baremetal-api-v1-portgroups.inc api-ref/source/baremetal-api-v1-ports.inc api-ref/source/baremetal-api-v1-volume.inc api-ref/source/baremetal-api-versions.inc api-ref/source/conf.py api-ref/source/index.rst api-ref/source/parameters.yaml api-ref/source/samples/api-root-response.json api-ref/source/samples/api-v1-root-response.json api-ref/source/samples/chassis-create-request.json api-ref/source/samples/chassis-list-details-response.json api-ref/source/samples/chassis-list-response.json api-ref/source/samples/chassis-show-response.json api-ref/source/samples/chassis-update-request.json api-ref/source/samples/chassis-update-response.json api-ref/source/samples/driver-get-response.json api-ref/source/samples/driver-logical-disk-properties-response.json api-ref/source/samples/driver-property-response.json api-ref/source/samples/drivers-list-detail-response.json api-ref/source/samples/drivers-list-response.json api-ref/source/samples/lookup-node-response.json api-ref/source/samples/node-create-request-classic.json api-ref/source/samples/node-create-request-dynamic.json api-ref/source/samples/node-create-response.json api-ref/source/samples/node-get-boot-device-response.json api-ref/source/samples/node-get-state-response.json api-ref/source/samples/node-get-supported-boot-devices-response.json api-ref/source/samples/node-inject-nmi.json api-ref/source/samples/node-maintenance-request.json api-ref/source/samples/node-port-detail-response.json api-ref/source/samples/node-port-list-response.json api-ref/source/samples/node-portgroup-detail-response.json api-ref/source/samples/node-portgroup-list-response.json api-ref/source/samples/node-set-active-state.json api-ref/source/samples/node-set-available-state.json api-ref/source/samples/node-set-boot-device.json api-ref/source/samples/node-set-clean-state.json api-ref/source/samples/node-set-manage-state.json api-ref/source/samples/node-set-power-off.json api-ref/source/samples/node-set-raid-request.json api-ref/source/samples/node-set-soft-power-off.json api-ref/source/samples/node-set-traits-request.json api-ref/source/samples/node-show-response.json api-ref/source/samples/node-traits-list-response.json api-ref/source/samples/node-update-driver-info-request.json api-ref/source/samples/node-update-driver-info-response.json api-ref/source/samples/node-update-driver.json api-ref/source/samples/node-validate-response.json api-ref/source/samples/node-vendor-passthru-response.json api-ref/source/samples/node-vif-attach-request.json api-ref/source/samples/node-vif-list-response.json api-ref/source/samples/node-volume-connector-detail-response.json api-ref/source/samples/node-volume-connector-list-response.json api-ref/source/samples/node-volume-list-response.json api-ref/source/samples/node-volume-target-detail-response.json api-ref/source/samples/node-volume-target-list-response.json api-ref/source/samples/nodes-list-details-response.json api-ref/source/samples/nodes-list-response.json api-ref/source/samples/port-create-request.json api-ref/source/samples/port-create-response.json api-ref/source/samples/port-list-detail-response.json api-ref/source/samples/port-list-response.json api-ref/source/samples/port-update-request.json api-ref/source/samples/port-update-response.json api-ref/source/samples/portgroup-create-request.json api-ref/source/samples/portgroup-create-response.json api-ref/source/samples/portgroup-list-detail-response.json api-ref/source/samples/portgroup-list-response.json api-ref/source/samples/portgroup-port-detail-response.json api-ref/source/samples/portgroup-port-list-response.json api-ref/source/samples/portgroup-update-request.json api-ref/source/samples/portgroup-update-response.json api-ref/source/samples/volume-connector-create-request.json api-ref/source/samples/volume-connector-create-response.json api-ref/source/samples/volume-connector-list-detail-response.json api-ref/source/samples/volume-connector-list-response.json api-ref/source/samples/volume-connector-update-request.json api-ref/source/samples/volume-connector-update-response.json api-ref/source/samples/volume-list-response.json api-ref/source/samples/volume-target-create-request.json api-ref/source/samples/volume-target-create-response.json api-ref/source/samples/volume-target-list-detail-response.json api-ref/source/samples/volume-target-list-response.json api-ref/source/samples/volume-target-update-request.json api-ref/source/samples/volume-target-update-response.json devstack/common_settings devstack/plugin.sh devstack/settings devstack/files/apache-ipxe-ironic.template devstack/files/apache-ironic-api-redirect.template devstack/files/apache-ironic-api.template devstack/files/debs/ironic devstack/files/hooks/qemu.py devstack/files/rpms/ironic devstack/lib/ironic devstack/tools/ironic/scripts/cleanup-node.sh devstack/tools/ironic/scripts/configure-vm.py devstack/tools/ironic/scripts/create-node.sh devstack/tools/ironic/scripts/setup-network.sh devstack/tools/ironic/templates/brbm.xml devstack/tools/ironic/templates/tftpd-xinetd.template devstack/tools/ironic/templates/vm.xml devstack/upgrade/resources.sh devstack/upgrade/settings devstack/upgrade/shutdown.sh devstack/upgrade/upgrade.sh doc/source/conf.py doc/source/index.rst doc/source/admin/adoption.rst doc/source/admin/api-audit-support.rst doc/source/admin/boot-from-volume.rst doc/source/admin/cleaning.rst doc/source/admin/console.rst doc/source/admin/drivers.rst doc/source/admin/gmr.rst doc/source/admin/index.rst doc/source/admin/inspection.rst doc/source/admin/metrics.rst doc/source/admin/multitenancy.rst doc/source/admin/notifications.rst doc/source/admin/portgroups.rst doc/source/admin/radosgw.rst doc/source/admin/raid.rst doc/source/admin/report.txt doc/source/admin/security.rst doc/source/admin/troubleshooting.rst doc/source/admin/upgrade-guide.rst doc/source/admin/upgrade-to-hardware-types.rst doc/source/admin/drivers/ansible.rst doc/source/admin/drivers/cimc.rst doc/source/admin/drivers/idrac.rst doc/source/admin/drivers/ilo.rst doc/source/admin/drivers/ipa.rst doc/source/admin/drivers/ipmitool.rst doc/source/admin/drivers/irmc.rst doc/source/admin/drivers/oneview.rst doc/source/admin/drivers/pxe.rst doc/source/admin/drivers/redfish.rst doc/source/admin/drivers/snmp.rst doc/source/admin/drivers/ucs.rst doc/source/admin/interfaces/boot.rst doc/source/admin/interfaces/deploy.rst doc/source/cli/index.rst doc/source/cli/ironic-dbsync.rst doc/source/configuration/config.rst doc/source/configuration/index.rst doc/source/configuration/policy.rst doc/source/configuration/sample-config.rst doc/source/configuration/sample-policy.rst doc/source/contributor/architecture.rst doc/source/contributor/code-contribution-guide.rst doc/source/contributor/dev-quickstart.rst doc/source/contributor/drivers.rst doc/source/contributor/faq.rst doc/source/contributor/governance.rst doc/source/contributor/index.rst doc/source/contributor/ironic-boot-from-volume.rst doc/source/contributor/ironic-multitenant-networking.rst doc/source/contributor/notifications.rst doc/source/contributor/osprofiler-support.rst doc/source/contributor/releasing.rst doc/source/contributor/rolling-upgrades.rst doc/source/contributor/states.rst doc/source/contributor/third-party-ci.rst doc/source/contributor/vendor-passthru.rst doc/source/contributor/webapi-version-history.rst doc/source/contributor/webapi.rst doc/source/images/conceptual_architecture.png doc/source/images/deployment_architecture_2.png doc/source/images/logical_architecture.png doc/source/images/sample_trace.svg doc/source/images/sample_trace_details.svg doc/source/images/states.svg doc/source/install/advanced.rst doc/source/install/conf.py doc/source/install/configdrive.rst doc/source/install/configure-cleaning.rst doc/source/install/configure-compute.rst doc/source/install/configure-glance-images.rst doc/source/install/configure-glance-swift.rst doc/source/install/configure-identity.rst doc/source/install/configure-integration.rst doc/source/install/configure-ipmi.rst doc/source/install/configure-iscsi.rst doc/source/install/configure-networking.rst doc/source/install/configure-nova-flavors.rst doc/source/install/configure-pxe.rst doc/source/install/configure-tenant-networks.rst doc/source/install/deploy-ramdisk.rst doc/source/install/enabling-drivers.rst doc/source/install/enabling-https.rst doc/source/install/enrollment.rst doc/source/install/get_started.rst doc/source/install/index.rst doc/source/install/install-obs.rst doc/source/install/install-rdo.rst doc/source/install/install-ubuntu.rst doc/source/install/install.rst doc/source/install/next-steps.rst doc/source/install/setup-drivers.rst doc/source/install/standalone.rst doc/source/install/troubleshooting.rst doc/source/install/include/boot-mode.inc doc/source/install/include/common-configure.inc doc/source/install/include/common-prerequisites.inc doc/source/install/include/configure-ironic-api-mod_wsgi.inc doc/source/install/include/configure-ironic-api.inc doc/source/install/include/configure-ironic-conductor.inc doc/source/install/include/console.inc doc/source/install/include/disk-label.inc doc/source/install/include/kernel-boot-parameters.inc doc/source/install/include/local-boot-partition-images.inc doc/source/install/include/notifications.inc doc/source/install/include/root-device-hints.inc doc/source/install/include/trusted-boot.inc doc/source/install/refarch/common.rst doc/source/install/refarch/index.rst doc/source/user/index.rst etc/apache2/ironic etc/ironic/README-ironic.conf.txt etc/ironic/README-policy.yaml.txt etc/ironic/api_audit_map.conf.sample etc/ironic/rootwrap.conf etc/ironic/rootwrap.d/ironic-images.filters etc/ironic/rootwrap.d/ironic-lib.filters etc/ironic/rootwrap.d/ironic-utils.filters ironic/__init__.py ironic/version.py ironic.egg-info/PKG-INFO ironic.egg-info/SOURCES.txt ironic.egg-info/dependency_links.txt ironic.egg-info/entry_points.txt ironic.egg-info/not-zip-safe ironic.egg-info/pbr.json ironic.egg-info/requires.txt ironic.egg-info/top_level.txt ironic/api/__init__.py ironic/api/app.py ironic/api/app.wsgi ironic/api/config.py ironic/api/expose.py ironic/api/hooks.py ironic/api/wsgi.py ironic/api/controllers/__init__.py ironic/api/controllers/base.py ironic/api/controllers/link.py ironic/api/controllers/root.py ironic/api/controllers/v1/__init__.py ironic/api/controllers/v1/chassis.py ironic/api/controllers/v1/collection.py ironic/api/controllers/v1/driver.py ironic/api/controllers/v1/node.py ironic/api/controllers/v1/notification_utils.py ironic/api/controllers/v1/port.py ironic/api/controllers/v1/portgroup.py ironic/api/controllers/v1/ramdisk.py ironic/api/controllers/v1/state.py ironic/api/controllers/v1/types.py ironic/api/controllers/v1/utils.py ironic/api/controllers/v1/versions.py ironic/api/controllers/v1/volume.py ironic/api/controllers/v1/volume_connector.py ironic/api/controllers/v1/volume_target.py ironic/api/middleware/__init__.py ironic/api/middleware/auth_token.py ironic/api/middleware/json_ext.py ironic/api/middleware/parsable_error.py ironic/cmd/__init__.py ironic/cmd/api.py ironic/cmd/conductor.py ironic/cmd/dbsync.py ironic/common/__init__.py ironic/common/boot_devices.py ironic/common/cinder.py ironic/common/config.py ironic/common/context.py ironic/common/dhcp_factory.py ironic/common/driver_factory.py ironic/common/exception.py ironic/common/fsm.py ironic/common/grub_conf.template ironic/common/hash_ring.py ironic/common/i18n.py ironic/common/image_service.py ironic/common/images.py ironic/common/isolinux_config.template ironic/common/keystone.py ironic/common/network.py ironic/common/neutron.py ironic/common/policy.py ironic/common/profiler.py ironic/common/pxe_utils.py ironic/common/raid.py ironic/common/release_mappings.py ironic/common/rpc.py ironic/common/rpc_service.py ironic/common/service.py ironic/common/states.py ironic/common/swift.py ironic/common/utils.py ironic/common/wsgi_service.py ironic/common/glance_service/__init__.py ironic/common/glance_service/base_image_service.py ironic/common/glance_service/service.py ironic/common/glance_service/service_utils.py ironic/common/glance_service/v1/__init__.py ironic/common/glance_service/v1/image_service.py ironic/common/glance_service/v2/__init__.py ironic/common/glance_service/v2/image_service.py ironic/conductor/__init__.py ironic/conductor/base_manager.py ironic/conductor/manager.py ironic/conductor/notification_utils.py ironic/conductor/rpcapi.py ironic/conductor/task_manager.py ironic/conductor/utils.py ironic/conf/__init__.py ironic/conf/agent.py ironic/conf/ansible.py ironic/conf/api.py ironic/conf/audit.py ironic/conf/auth.py ironic/conf/cinder.py ironic/conf/cisco.py ironic/conf/conductor.py ironic/conf/console.py ironic/conf/database.py ironic/conf/default.py ironic/conf/deploy.py ironic/conf/dhcp.py ironic/conf/drac.py ironic/conf/glance.py ironic/conf/ilo.py ironic/conf/inspector.py ironic/conf/ipmi.py ironic/conf/irmc.py ironic/conf/iscsi.py ironic/conf/keystone.py ironic/conf/metrics.py ironic/conf/metrics_statsd.py ironic/conf/neutron.py ironic/conf/oneview.py ironic/conf/opts.py ironic/conf/pxe.py ironic/conf/redfish.py ironic/conf/service_catalog.py ironic/conf/snmp.py ironic/conf/swift.py ironic/conf/xclarity.py ironic/db/__init__.py ironic/db/api.py ironic/db/migration.py ironic/db/sqlalchemy/__init__.py ironic/db/sqlalchemy/alembic.ini ironic/db/sqlalchemy/api.py ironic/db/sqlalchemy/migration.py ironic/db/sqlalchemy/models.py ironic/db/sqlalchemy/alembic/README ironic/db/sqlalchemy/alembic/env.py ironic/db/sqlalchemy/alembic/script.py.mako ironic/db/sqlalchemy/alembic/versions/10b163d4481e_add_port_portgroup_internal_info.py ironic/db/sqlalchemy/alembic/versions/1a59178ebdf6_add_volume_targets_table.py ironic/db/sqlalchemy/alembic/versions/1d6951876d68_add_storage_interface_db_field_and_.py ironic/db/sqlalchemy/alembic/versions/1e1d5ace7dc6_add_inspection_started_at_and_.py ironic/db/sqlalchemy/alembic/versions/21b331f883ef_add_provision_updated_at.py ironic/db/sqlalchemy/alembic/versions/2353895ecfae_add_conductor_hardware_interfaces_table.py ironic/db/sqlalchemy/alembic/versions/242cc6a923b3_add_node_maintenance_reason.py ironic/db/sqlalchemy/alembic/versions/2581ebaf0cb2_initial_migration.py ironic/db/sqlalchemy/alembic/versions/2fb93ffd2af1_increase_node_name_length.py ironic/db/sqlalchemy/alembic/versions/31baaf680d2b_add_node_instance_info.py ironic/db/sqlalchemy/alembic/versions/3ae36a5f5131_add_logical_name.py ironic/db/sqlalchemy/alembic/versions/3bea56f25597_add_unique_constraint_to_instance_uuid.py ironic/db/sqlalchemy/alembic/versions/3cb628139ea4_nodes_add_console_enabled.py ironic/db/sqlalchemy/alembic/versions/3d86a077a3f2_add_port_physical_network.py ironic/db/sqlalchemy/alembic/versions/405cfe08f18d_add_rescue_interface_to_node.py ironic/db/sqlalchemy/alembic/versions/487deb87cc9d_add_conductor_affinity_and_online.py ironic/db/sqlalchemy/alembic/versions/48d6c242bb9b_add_node_tags.py ironic/db/sqlalchemy/alembic/versions/493d8f27f235_add_portgroup_configuration_fields.py ironic/db/sqlalchemy/alembic/versions/4f399b21ae71_add_node_clean_step.py ironic/db/sqlalchemy/alembic/versions/516faf1bb9b1_resizing_column_nodes_driver.py ironic/db/sqlalchemy/alembic/versions/5674c57409b9_replace_nostate_with_available.py ironic/db/sqlalchemy/alembic/versions/5ea1b0d310e_added_port_group_table_and_altered_ports.py ironic/db/sqlalchemy/alembic/versions/60cf717201bc_add_standalone_ports_supported.py ironic/db/sqlalchemy/alembic/versions/789acc877671_add_raid_config.py ironic/db/sqlalchemy/alembic/versions/868cb606a74a_add_version_field_in_base_class.py ironic/db/sqlalchemy/alembic/versions/b4130a7fc904_create_nodetraits_table.py ironic/db/sqlalchemy/alembic/versions/bb59b63f55a_add_node_driver_internal_info.py ironic/db/sqlalchemy/alembic/versions/bcdd431ba0bf_add_fields_for_all_interfaces.py ironic/db/sqlalchemy/alembic/versions/c14cef6dfedf_populate_node_network_interface.py ironic/db/sqlalchemy/alembic/versions/daa1ba02d98_add_volume_connectors_table.py ironic/db/sqlalchemy/alembic/versions/dbefd6bdaa2c_add_default_column_to_.py ironic/db/sqlalchemy/alembic/versions/dd34e1f1303b_add_resource_class_to_node.py ironic/db/sqlalchemy/alembic/versions/e294876e8028_add_node_network_interface.py ironic/db/sqlalchemy/alembic/versions/e918ff30eb42_resize_column_nodes_instance_info.py ironic/db/sqlalchemy/alembic/versions/f6fdb920c182_set_pxe_enabled_true.py ironic/dhcp/__init__.py ironic/dhcp/base.py ironic/dhcp/neutron.py ironic/dhcp/none.py ironic/drivers/__init__.py ironic/drivers/agent.py ironic/drivers/base.py ironic/drivers/cisco_ucs.py ironic/drivers/drac.py ironic/drivers/fake.py ironic/drivers/fake_hardware.py ironic/drivers/generic.py ironic/drivers/hardware_type.py ironic/drivers/ilo.py ironic/drivers/ipmi.py ironic/drivers/irmc.py ironic/drivers/oneview.py ironic/drivers/pxe.py ironic/drivers/raid_config_schema.json ironic/drivers/redfish.py ironic/drivers/snmp.py ironic/drivers/utils.py ironic/drivers/xclarity.py ironic/drivers/modules/__init__.py ironic/drivers/modules/agent.py ironic/drivers/modules/agent_base_vendor.py ironic/drivers/modules/agent_client.py ironic/drivers/modules/agent_config.template ironic/drivers/modules/boot.ipxe ironic/drivers/modules/console_utils.py ironic/drivers/modules/deploy_utils.py ironic/drivers/modules/elilo_efi_pxe_config.template ironic/drivers/modules/fake.py ironic/drivers/modules/image_cache.py ironic/drivers/modules/inspector.py ironic/drivers/modules/ipmitool.py ironic/drivers/modules/ipxe_config.template ironic/drivers/modules/iscsi_deploy.py ironic/drivers/modules/master_grub_cfg.txt ironic/drivers/modules/noop.py ironic/drivers/modules/pxe.py ironic/drivers/modules/pxe_config.template ironic/drivers/modules/pxe_grub_config.template ironic/drivers/modules/snmp.py ironic/drivers/modules/ansible/__init__.py ironic/drivers/modules/ansible/deploy.py ironic/drivers/modules/ansible/playbooks/add-ironic-nodes.yaml ironic/drivers/modules/ansible/playbooks/ansible.cfg ironic/drivers/modules/ansible/playbooks/clean.yaml ironic/drivers/modules/ansible/playbooks/clean_steps.yaml ironic/drivers/modules/ansible/playbooks/deploy.yaml ironic/drivers/modules/ansible/playbooks/inventory ironic/drivers/modules/ansible/playbooks/shutdown.yaml ironic/drivers/modules/ansible/playbooks/callback_plugins/ironic_log.ini ironic/drivers/modules/ansible/playbooks/callback_plugins/ironic_log.py ironic/drivers/modules/ansible/playbooks/library/facts_wwn.py ironic/drivers/modules/ansible/playbooks/library/root_hints.py ironic/drivers/modules/ansible/playbooks/library/stream_url.py ironic/drivers/modules/ansible/playbooks/roles/clean/defaults/main.yaml ironic/drivers/modules/ansible/playbooks/roles/clean/tasks/main.yaml ironic/drivers/modules/ansible/playbooks/roles/clean/tasks/shred.yaml ironic/drivers/modules/ansible/playbooks/roles/clean/tasks/wipe.yaml ironic/drivers/modules/ansible/playbooks/roles/clean/tasks/zap.yaml ironic/drivers/modules/ansible/playbooks/roles/configure/defaults/main.yaml ironic/drivers/modules/ansible/playbooks/roles/configure/tasks/grub.yaml ironic/drivers/modules/ansible/playbooks/roles/configure/tasks/main.yaml ironic/drivers/modules/ansible/playbooks/roles/configure/tasks/mounts.yaml ironic/drivers/modules/ansible/playbooks/roles/deploy/files/partition_configdrive.sh ironic/drivers/modules/ansible/playbooks/roles/deploy/tasks/configdrive.yaml ironic/drivers/modules/ansible/playbooks/roles/deploy/tasks/download.yaml ironic/drivers/modules/ansible/playbooks/roles/deploy/tasks/main.yaml ironic/drivers/modules/ansible/playbooks/roles/deploy/tasks/write.yaml ironic/drivers/modules/ansible/playbooks/roles/discover/tasks/main.yaml ironic/drivers/modules/ansible/playbooks/roles/discover/tasks/roothints.yaml ironic/drivers/modules/ansible/playbooks/roles/prepare/tasks/main.yaml ironic/drivers/modules/ansible/playbooks/roles/prepare/tasks/parted.yaml ironic/drivers/modules/ansible/playbooks/roles/shutdown/tasks/main.yaml ironic/drivers/modules/cimc/__init__.py ironic/drivers/modules/cimc/common.py ironic/drivers/modules/cimc/management.py ironic/drivers/modules/cimc/power.py ironic/drivers/modules/drac/__init__.py ironic/drivers/modules/drac/bios.py ironic/drivers/modules/drac/common.py ironic/drivers/modules/drac/inspect.py ironic/drivers/modules/drac/job.py ironic/drivers/modules/drac/management.py ironic/drivers/modules/drac/power.py ironic/drivers/modules/drac/raid.py ironic/drivers/modules/drac/vendor_passthru.py ironic/drivers/modules/ilo/__init__.py ironic/drivers/modules/ilo/boot.py ironic/drivers/modules/ilo/common.py ironic/drivers/modules/ilo/console.py ironic/drivers/modules/ilo/firmware_processor.py ironic/drivers/modules/ilo/inspect.py ironic/drivers/modules/ilo/management.py ironic/drivers/modules/ilo/power.py ironic/drivers/modules/ilo/vendor.py ironic/drivers/modules/irmc/__init__.py ironic/drivers/modules/irmc/boot.py ironic/drivers/modules/irmc/common.py ironic/drivers/modules/irmc/inspect.py ironic/drivers/modules/irmc/management.py ironic/drivers/modules/irmc/power.py ironic/drivers/modules/network/__init__.py ironic/drivers/modules/network/common.py ironic/drivers/modules/network/flat.py ironic/drivers/modules/network/neutron.py ironic/drivers/modules/network/noop.py ironic/drivers/modules/oneview/__init__.py ironic/drivers/modules/oneview/common.py ironic/drivers/modules/oneview/deploy.py ironic/drivers/modules/oneview/deploy_utils.py ironic/drivers/modules/oneview/inspect.py ironic/drivers/modules/oneview/management.py ironic/drivers/modules/oneview/power.py ironic/drivers/modules/redfish/__init__.py ironic/drivers/modules/redfish/management.py ironic/drivers/modules/redfish/power.py ironic/drivers/modules/redfish/utils.py ironic/drivers/modules/storage/__init__.py ironic/drivers/modules/storage/cinder.py ironic/drivers/modules/storage/noop.py ironic/drivers/modules/ucs/__init__.py ironic/drivers/modules/ucs/helper.py ironic/drivers/modules/ucs/management.py ironic/drivers/modules/ucs/power.py ironic/drivers/modules/xclarity/__init__.py ironic/drivers/modules/xclarity/common.py ironic/drivers/modules/xclarity/management.py ironic/drivers/modules/xclarity/power.py ironic/locale/ja/LC_MESSAGES/ironic.po ironic/objects/__init__.py ironic/objects/base.py ironic/objects/chassis.py ironic/objects/conductor.py ironic/objects/fields.py ironic/objects/indirection.py ironic/objects/node.py ironic/objects/notification.py ironic/objects/port.py ironic/objects/portgroup.py ironic/objects/trait.py ironic/objects/volume_connector.py ironic/objects/volume_target.py ironic/tests/__init__.py ironic/tests/base.py ironic/tests/functional/__init__.py ironic/tests/unit/__init__.py ironic/tests/unit/policy_fixture.py ironic/tests/unit/raid_constants.py ironic/tests/unit/stubs.py ironic/tests/unit/api/__init__.py ironic/tests/unit/api/base.py ironic/tests/unit/api/test_acl.py ironic/tests/unit/api/test_audit.py ironic/tests/unit/api/test_hooks.py ironic/tests/unit/api/test_middleware.py ironic/tests/unit/api/test_ospmiddleware.py ironic/tests/unit/api/test_root.py ironic/tests/unit/api/utils.py ironic/tests/unit/api/controllers/__init__.py ironic/tests/unit/api/controllers/test_base.py ironic/tests/unit/api/controllers/v1/__init__.py ironic/tests/unit/api/controllers/v1/test_chassis.py ironic/tests/unit/api/controllers/v1/test_driver.py ironic/tests/unit/api/controllers/v1/test_expose.py ironic/tests/unit/api/controllers/v1/test_node.py ironic/tests/unit/api/controllers/v1/test_notification_utils.py ironic/tests/unit/api/controllers/v1/test_port.py ironic/tests/unit/api/controllers/v1/test_portgroup.py ironic/tests/unit/api/controllers/v1/test_ramdisk.py ironic/tests/unit/api/controllers/v1/test_root.py ironic/tests/unit/api/controllers/v1/test_types.py ironic/tests/unit/api/controllers/v1/test_utils.py ironic/tests/unit/api/controllers/v1/test_versions.py ironic/tests/unit/api/controllers/v1/test_volume.py ironic/tests/unit/api/controllers/v1/test_volume_connector.py ironic/tests/unit/api/controllers/v1/test_volume_target.py ironic/tests/unit/cmd/__init__.py ironic/tests/unit/cmd/test_conductor.py ironic/tests/unit/cmd/test_dbsync.py ironic/tests/unit/common/__init__.py ironic/tests/unit/common/test_cinder.py ironic/tests/unit/common/test_context.py ironic/tests/unit/common/test_driver_factory.py ironic/tests/unit/common/test_exception.py ironic/tests/unit/common/test_fsm.py ironic/tests/unit/common/test_glance_service.py ironic/tests/unit/common/test_hash_ring.py ironic/tests/unit/common/test_image_service.py ironic/tests/unit/common/test_images.py ironic/tests/unit/common/test_keystone.py ironic/tests/unit/common/test_network.py ironic/tests/unit/common/test_neutron.py ironic/tests/unit/common/test_policy.py ironic/tests/unit/common/test_pxe_utils.py ironic/tests/unit/common/test_raid.py ironic/tests/unit/common/test_release_mappings.py ironic/tests/unit/common/test_rpc.py ironic/tests/unit/common/test_rpc_service.py ironic/tests/unit/common/test_states.py ironic/tests/unit/common/test_swift.py ironic/tests/unit/common/test_utils.py ironic/tests/unit/common/test_wsgi_service.py ironic/tests/unit/conductor/__init__.py ironic/tests/unit/conductor/mgr_utils.py ironic/tests/unit/conductor/test__mgr_utils.py ironic/tests/unit/conductor/test_base_manager.py ironic/tests/unit/conductor/test_manager.py ironic/tests/unit/conductor/test_notification_utils.py ironic/tests/unit/conductor/test_rpcapi.py ironic/tests/unit/conductor/test_task_manager.py ironic/tests/unit/conductor/test_utils.py ironic/tests/unit/conf/__init__.py ironic/tests/unit/conf/test_auth.py ironic/tests/unit/db/__init__.py ironic/tests/unit/db/base.py ironic/tests/unit/db/test_api.py ironic/tests/unit/db/test_chassis.py ironic/tests/unit/db/test_conductor.py ironic/tests/unit/db/test_node_tags.py ironic/tests/unit/db/test_node_traits.py ironic/tests/unit/db/test_nodes.py ironic/tests/unit/db/test_portgroups.py ironic/tests/unit/db/test_ports.py ironic/tests/unit/db/test_volume_connectors.py ironic/tests/unit/db/test_volume_targets.py ironic/tests/unit/db/utils.py ironic/tests/unit/db/sqlalchemy/__init__.py ironic/tests/unit/db/sqlalchemy/test_api.py ironic/tests/unit/db/sqlalchemy/test_migrations.py ironic/tests/unit/db/sqlalchemy/test_types.py ironic/tests/unit/dhcp/__init__.py ironic/tests/unit/dhcp/test_factory.py ironic/tests/unit/dhcp/test_neutron.py ironic/tests/unit/drivers/__init__.py ironic/tests/unit/drivers/boot.ipxe ironic/tests/unit/drivers/elilo_efi_pxe_config.template ironic/tests/unit/drivers/ipxe_config.template ironic/tests/unit/drivers/ipxe_config_boot_from_volume.template ironic/tests/unit/drivers/ipxe_config_boot_from_volume_no_volumes.template ironic/tests/unit/drivers/ipxe_config_timeout.template ironic/tests/unit/drivers/pxe_config.template ironic/tests/unit/drivers/pxe_grub_config.template ironic/tests/unit/drivers/test_base.py ironic/tests/unit/drivers/test_cisco.py ironic/tests/unit/drivers/test_drac.py ironic/tests/unit/drivers/test_fake.py ironic/tests/unit/drivers/test_generic.py ironic/tests/unit/drivers/test_ilo.py ironic/tests/unit/drivers/test_ipmi.py ironic/tests/unit/drivers/test_irmc.py ironic/tests/unit/drivers/test_oneview.py ironic/tests/unit/drivers/test_pxe.py ironic/tests/unit/drivers/test_redfish.py ironic/tests/unit/drivers/test_snmp.py ironic/tests/unit/drivers/test_utils.py ironic/tests/unit/drivers/test_xclarity.py ironic/tests/unit/drivers/third_party_driver_mock_specs.py ironic/tests/unit/drivers/third_party_driver_mocks.py ironic/tests/unit/drivers/modules/__init__.py ironic/tests/unit/drivers/modules/test_agent.py ironic/tests/unit/drivers/modules/test_agent_base_vendor.py ironic/tests/unit/drivers/modules/test_agent_client.py ironic/tests/unit/drivers/modules/test_console_utils.py ironic/tests/unit/drivers/modules/test_deploy_utils.py ironic/tests/unit/drivers/modules/test_image_cache.py ironic/tests/unit/drivers/modules/test_inspector.py ironic/tests/unit/drivers/modules/test_ipmitool.py ironic/tests/unit/drivers/modules/test_iscsi_deploy.py ironic/tests/unit/drivers/modules/test_noop.py ironic/tests/unit/drivers/modules/test_pxe.py ironic/tests/unit/drivers/modules/test_snmp.py ironic/tests/unit/drivers/modules/ansible/__init__.py ironic/tests/unit/drivers/modules/ansible/test_deploy.py ironic/tests/unit/drivers/modules/cimc/__init__.py ironic/tests/unit/drivers/modules/cimc/test_common.py ironic/tests/unit/drivers/modules/cimc/test_management.py ironic/tests/unit/drivers/modules/cimc/test_power.py ironic/tests/unit/drivers/modules/drac/__init__.py ironic/tests/unit/drivers/modules/drac/test_bios.py ironic/tests/unit/drivers/modules/drac/test_common.py ironic/tests/unit/drivers/modules/drac/test_inspect.py ironic/tests/unit/drivers/modules/drac/test_job.py ironic/tests/unit/drivers/modules/drac/test_management.py ironic/tests/unit/drivers/modules/drac/test_periodic_task.py ironic/tests/unit/drivers/modules/drac/test_power.py ironic/tests/unit/drivers/modules/drac/test_raid.py ironic/tests/unit/drivers/modules/drac/utils.py ironic/tests/unit/drivers/modules/ilo/__init__.py ironic/tests/unit/drivers/modules/ilo/test_boot.py ironic/tests/unit/drivers/modules/ilo/test_common.py ironic/tests/unit/drivers/modules/ilo/test_console.py ironic/tests/unit/drivers/modules/ilo/test_firmware_processor.py ironic/tests/unit/drivers/modules/ilo/test_inspect.py ironic/tests/unit/drivers/modules/ilo/test_management.py ironic/tests/unit/drivers/modules/ilo/test_power.py ironic/tests/unit/drivers/modules/ilo/test_vendor.py ironic/tests/unit/drivers/modules/irmc/__init__.py ironic/tests/unit/drivers/modules/irmc/fake_sensors_data_ng.xml ironic/tests/unit/drivers/modules/irmc/fake_sensors_data_ok.xml ironic/tests/unit/drivers/modules/irmc/test_boot.py ironic/tests/unit/drivers/modules/irmc/test_common.py ironic/tests/unit/drivers/modules/irmc/test_inspect.py ironic/tests/unit/drivers/modules/irmc/test_management.py ironic/tests/unit/drivers/modules/irmc/test_power.py ironic/tests/unit/drivers/modules/network/__init__.py ironic/tests/unit/drivers/modules/network/test_common.py ironic/tests/unit/drivers/modules/network/test_flat.py ironic/tests/unit/drivers/modules/network/test_neutron.py ironic/tests/unit/drivers/modules/network/test_noop.py ironic/tests/unit/drivers/modules/oneview/__init__.py ironic/tests/unit/drivers/modules/oneview/test_common.py ironic/tests/unit/drivers/modules/oneview/test_deploy.py ironic/tests/unit/drivers/modules/oneview/test_deploy_utils.py ironic/tests/unit/drivers/modules/oneview/test_inspect.py ironic/tests/unit/drivers/modules/oneview/test_management.py ironic/tests/unit/drivers/modules/oneview/test_power.py ironic/tests/unit/drivers/modules/redfish/__init__.py ironic/tests/unit/drivers/modules/redfish/test_management.py ironic/tests/unit/drivers/modules/redfish/test_power.py ironic/tests/unit/drivers/modules/redfish/test_utils.py ironic/tests/unit/drivers/modules/storage/__init__.py ironic/tests/unit/drivers/modules/storage/test_cinder.py ironic/tests/unit/drivers/modules/ucs/__init__.py ironic/tests/unit/drivers/modules/ucs/test_helper.py ironic/tests/unit/drivers/modules/ucs/test_management.py ironic/tests/unit/drivers/modules/ucs/test_power.py ironic/tests/unit/drivers/modules/xclarity/__init__.py ironic/tests/unit/drivers/modules/xclarity/test_common.py ironic/tests/unit/drivers/modules/xclarity/test_management.py ironic/tests/unit/drivers/modules/xclarity/test_power.py ironic/tests/unit/objects/__init__.py ironic/tests/unit/objects/test_chassis.py ironic/tests/unit/objects/test_conductor.py ironic/tests/unit/objects/test_fields.py ironic/tests/unit/objects/test_node.py ironic/tests/unit/objects/test_notification.py ironic/tests/unit/objects/test_objects.py ironic/tests/unit/objects/test_port.py ironic/tests/unit/objects/test_portgroup.py ironic/tests/unit/objects/test_trait.py ironic/tests/unit/objects/test_volume_connector.py ironic/tests/unit/objects/test_volume_target.py ironic/tests/unit/objects/utils.py playbooks/legacy/grenade-dsvm-ironic/run.yaml playbooks/legacy/grenade-dsvm-ironic-multinode-multitenant/run.yaml playbooks/legacy/ironic-dsvm-base/post.yaml playbooks/legacy/ironic-dsvm-base-multinode/post.yaml playbooks/legacy/ironic-dsvm-functional/run.yaml playbooks/legacy/ironic-dsvm-standalone/run.yaml playbooks/legacy/tempest-dsvm-ironic-bfv/run.yaml playbooks/legacy/tempest-dsvm-ironic-inspector/run.yaml playbooks/legacy/tempest-dsvm-ironic-ipa-partition-pxe_ipmitool-tinyipa-python3/run.yaml playbooks/legacy/tempest-dsvm-ironic-ipa-partition-redfish-tinyipa/run.yaml playbooks/legacy/tempest-dsvm-ironic-ipa-partition-uefi-pxe_ipmitool-tinyipa/run.yaml playbooks/legacy/tempest-dsvm-ironic-ipa-resourceclasses-partition-pxe_ipmitool-tinyipa/run.yaml playbooks/legacy/tempest-dsvm-ironic-ipa-wholedisk-agent_ipmitool-tinyipa-multinode/run.yaml playbooks/legacy/tempest-dsvm-ironic-ipa-wholedisk-bios-agent_ipmitool-tinyipa/run.yaml playbooks/legacy/tempest-dsvm-ironic-ipa-wholedisk-bios-pxe_snmp-tinyipa/run.yaml playbooks/legacy/tempest-dsvm-ironic-parallel/run.yaml playbooks/legacy/tempest-dsvm-ironic-pxe_ipa-full/run.yaml playbooks/legacy/tempest-dsvm-ironic-pxe_ipmitool-postgres/run.yaml releasenotes/notes/.placeholder releasenotes/notes/5.0-release-afb1fbbe595b6bc8.yaml releasenotes/notes/Add-port-option-support-to-ipmitool-e125d07fe13c53e7.yaml releasenotes/notes/active-node-creation-a41c9869c966c82b.yaml releasenotes/notes/add-agent-api-error-77ec6c272390c488.yaml releasenotes/notes/add-agent-erase-fallback-b07613a7042fe236.yaml releasenotes/notes/add-agent-iboot-0a4b5471c6ace461.yaml releasenotes/notes/add-agent-proxy-support-790e629634ca2eb7.yaml releasenotes/notes/add-boot-from-volume-support-9f64208f083d0691.yaml releasenotes/notes/add-chassis_uuid-removal-possibility-8b06341a91f7c676.yaml releasenotes/notes/add-choice-to-some-options-9fb327c48e6bfda1.yaml releasenotes/notes/add-cisco-ucs-hardware-types-ee597ff0416f158f.yaml releasenotes/notes/add-db-deadlock-handling-6bc10076537f3727.yaml releasenotes/notes/add-dynamic-allocation-feature-2fd6b4df7943f178.yaml releasenotes/notes/add-error-check-ipmitool-reboot-ca7823202c5ab71d.yaml releasenotes/notes/add-gmr-3c9278d5d785895f.yaml releasenotes/notes/add-id-and-uuid-filtering-to-sqalchemy-api.yaml releasenotes/notes/add-ipv6-pxe-support-8fb51c355cc977c4.yaml releasenotes/notes/add-iscsi-portal-port-option-bde3b386f44f2a90.yaml releasenotes/notes/add-node-resource-class-c31e26df4196293e.yaml releasenotes/notes/add-notifications-97b6c79c18b48073.yaml releasenotes/notes/add-oneview-driver-96088bf470b16c34.yaml releasenotes/notes/add-port-advanced-net-fields-55465091f019d962.yaml releasenotes/notes/add-port-internal-info-b7e02889416570f7.yaml releasenotes/notes/add-pxe-support-for-petitboot-50d1fe4e7da4bfba.yaml releasenotes/notes/add-secure-boot-suport-irmc-2c1f09271f96424d.yaml releasenotes/notes/add-secure-boot-suport-irmc-9509f3735df2aa5d.yaml releasenotes/notes/add-snmp-inspection-support-e68fd6d57cb33846.yaml releasenotes/notes/add-socat-console-ipmitool-ab4402ec976c5c96.yaml releasenotes/notes/add-ssl-support-4547801eedba5942.yaml releasenotes/notes/add-storage-interface-d4e64224804207fc.yaml releasenotes/notes/add-support-for-no-poweroff-on-failure-86e43b3e39043990.yaml releasenotes/notes/add-timeout-parameter-to-power-methods-5f632c936497685e.yaml releasenotes/notes/add-tooz-dep-85c56c74733a222d.yaml releasenotes/notes/add-validate-rescue-2202e8ce9a174ece.yaml releasenotes/notes/add-vif-attach-detach-support-99eca43eea6e5a30.yaml releasenotes/notes/add_infiniband_support-f497767f77277a1a.yaml releasenotes/notes/add_portgroup_support-7d5c6663bb00684a.yaml releasenotes/notes/add_standalone_ports_supported_field-4c59702a052acf38.yaml releasenotes/notes/added-redfish-driver-00ff5e3f7e9d6ee8.yaml releasenotes/notes/adding-audit-middleware-b95f2a00baed9750.yaml releasenotes/notes/adopt-ironic-context-5e75540dc2b2f009.yaml releasenotes/notes/adopt-oslo-config-generator-15afd2e7c2f008b4.yaml releasenotes/notes/adoption-feature-update-d2160954a2c36b0a.yaml releasenotes/notes/agent-api-bf9f18d8d38075e4.yaml releasenotes/notes/agent-can-request-reboot-6238e13e2e898f68.yaml releasenotes/notes/agent-takeover-60f27cef21ebfb48.yaml releasenotes/notes/agent-wol-driver-4116f64907d0db9c.yaml releasenotes/notes/agent_partition_image-48a03700f41a3980.yaml releasenotes/notes/allow-set-interface-to-node-in-available-bd6f695620c2d77f.yaml releasenotes/notes/allow-to-attach-vif-to-active-node-55963be2ec269043.yaml releasenotes/notes/always-return-chassis-uuid-4eecbc8da2170cb1.yaml releasenotes/notes/amt-driver-wake-up-0880ed85476968be.yaml releasenotes/notes/ansible-deploy-15da234580ca0c30.yaml releasenotes/notes/apache-multiple-workers-11d4ba52c89a13e3.yaml releasenotes/notes/automated_clean_config-0170c95ae210f953.yaml releasenotes/notes/backfill_version_column_db_race_condition-713fa05832b93ca5.yaml releasenotes/notes/bfv-pxe-boot-3375d331ee2f04f2.yaml releasenotes/notes/bmc_reset-warm-9396ac444cafd734.yaml releasenotes/notes/boot-ipxe-inc-workaround-548e10d1d6616752.yaml releasenotes/notes/bug-1506657-3bcb4ef46623124d.yaml releasenotes/notes/bug-1518374-decd73fd82c2eb94.yaml releasenotes/notes/bug-1548086-ed88646061b88faf.yaml releasenotes/notes/bug-1570283-6cdc62e4ef43cb02.yaml releasenotes/notes/bug-1579635-cffd990b51bcb5ab.yaml releasenotes/notes/bug-1592335-7c5835868fe364ea.yaml releasenotes/notes/bug-1596421-0cb8f59073f56240.yaml releasenotes/notes/bug-1607527-75885e145db62d69.yaml releasenotes/notes/bug-1611555-de1ec64ba46982ec.yaml releasenotes/notes/bug-1611556-92cbfde5ee7f44d6.yaml releasenotes/notes/bug-1626453-e8df46aa5db6dd5a.yaml releasenotes/notes/bug-1648387-92db52cbe007fabd.yaml releasenotes/notes/bug-1672457-563d5354b41b060e.yaml releasenotes/notes/bug-1694645-57289200e35bd883.yaml releasenotes/notes/bug-1696296-a972c8d879b98940.yaml releasenotes/notes/bug-1702158-79bf57bd4d8087b6.yaml releasenotes/notes/bug-1745630-d28c8de54cebd329.yaml releasenotes/notes/bug-1749433-363b747d2db67df6.yaml releasenotes/notes/bug-1749860-457292cf62e18a0e.yaml releasenotes/notes/build_instance_info-c7e3f12426b48965.yaml releasenotes/notes/catch-third-party-driver-validate-exceptions-94ed2a91c50d2d8e.yaml releasenotes/notes/change-ramdisk-log-filename-142b10d0b02a5ca6.yaml releasenotes/notes/change-updated-at-object-field-a74466f7c4541072.yaml releasenotes/notes/check-dynamic-allocation-enabled-e94f3b8963b114d0.yaml releasenotes/notes/check-for-whole-disk-image-uefi-3bf2146588de2423.yaml releasenotes/notes/check_protocol_for_ironic_api-32f35c93a140d3ae.yaml releasenotes/notes/classic-drivers-deprecation-de464065187d4c14.yaml releasenotes/notes/clean-nodes-stuck-in-cleaning-on-startup-443823ea4f937965.yaml releasenotes/notes/cleaning-retry-fix-89a5d0e65920a064.yaml releasenotes/notes/cleanup-provision-ports-before-retry-ec3c89c193766d70.yaml releasenotes/notes/clear-hung-iscsi-sessions-d3b55c4c65fa4c8b.yaml releasenotes/notes/clear-node-target-power-state-de1f25be46d3e6d7.yaml releasenotes/notes/clear-target-stable-states-4545602d7aed9898.yaml releasenotes/notes/collect-deployment-logs-2ec1634847c3f6a5.yaml releasenotes/notes/conductor-version-backfill-9d06f2ad81aebec3.yaml releasenotes/notes/conductor_early_import-fd29fa8b89089977.yaml releasenotes/notes/conf-debug-ipa-1d75e2283ca83395.yaml releasenotes/notes/config-drive-support-for-whole-disk-images-in-iscsi-deploy-0193c5222a7cd129.yaml releasenotes/notes/configdrive-support-using-ceph-radosgw-8c6f7b8bede2077c.yaml releasenotes/notes/configure-notifications-72824356e7d8832a.yaml releasenotes/notes/context-domain-id-name-deprecation-ae6e40718273be8d.yaml releasenotes/notes/correct-api-version-check-conditional-for-nodename-439bebc02fb5493d.yaml releasenotes/notes/create-on-conductor-c1c52a1f022c4048.yaml releasenotes/notes/create-port-on-conductor-b921738b4b2a5def.yaml releasenotes/notes/dbsync-check-version-c71d5f4fd89ed117.yaml releasenotes/notes/dbsync-online_data_migration-edcf0b1cc3667582.yaml releasenotes/notes/debug-no-api-tracebacks-a8a0caddc9676b06.yaml releasenotes/notes/default-resource-class-e11bacfb01d6841b.yaml releasenotes/notes/default-swift_account-b008d08e85bdf154.yaml releasenotes/notes/default_boot_option-f22c01f976bc2de7.yaml releasenotes/notes/deny-too-long-chassis-description-0690d6f67ed002d5.yaml releasenotes/notes/deprecate-agent-passthru-67d1e2cf25b30a30.yaml releasenotes/notes/deprecate-clustered-compute-manager-3dd68557446bcc5c.yaml releasenotes/notes/deprecate-dhcp-update-mac-address-f12a4959432c8e20.yaml releasenotes/notes/deprecate-elilo-2beca4800f475426.yaml releasenotes/notes/deprecate-glance-url-scheme-ceff3008cf9cf590.yaml releasenotes/notes/deprecate-global-region-4dbea91de71ebf59.yaml releasenotes/notes/deprecate-support-for-glance-v1-8b194e6b20cbfebb.yaml releasenotes/notes/deprecated-cinder-opts-e10c153768285cab.yaml releasenotes/notes/deprecated-glance-opts-4825f000d20c2932.yaml releasenotes/notes/deprecated-inspector-opts-b19a08339712cfd7.yaml releasenotes/notes/deprecated-neutron-opts-2e1d9e65f00301d3.yaml releasenotes/notes/dhcp-provider-clean-dhcp-9352717903d6047e.yaml releasenotes/notes/disable-clean-step-reset-ilo-1869a6e08f39901c.yaml releasenotes/notes/disk-label-capability-d36d126e0ad36dca.yaml releasenotes/notes/disk-label-fix-7580de913835ff44.yaml releasenotes/notes/drac-fix-double-manage-provide-cycle-6ac8a427068f87fe.yaml releasenotes/notes/drac-fix-get_bios_config-vendor-passthru-causes-exception-1e1dbeeb3e924f29.yaml releasenotes/notes/drac-fix-oob-cleaning-b4b717895e243c9b.yaml releasenotes/notes/drac-fix-prepare-cleaning-d74ba45135d84531.yaml releasenotes/notes/drac-inspection-interface-b0abbad98fec1c2e.yaml releasenotes/notes/drac-list-unfinished-jobs-10400419b6bc3c6e.yaml releasenotes/notes/drac-migrate-to-dracclient-2bd8a6d1dd3fdc69.yaml releasenotes/notes/drac-missing-lookup-3ad98e918e1a852a.yaml releasenotes/notes/drac-raid-interface-f4c02b1c4fb37e2d.yaml releasenotes/notes/drac_host-deprecated-b181149246eecb47.yaml releasenotes/notes/duplicated-driver-entry-775370ad84736206.yaml releasenotes/notes/dynamic-allocation-spt-has-physical-mac-8967a1d926ed9301.yaml releasenotes/notes/dynamic-driver-list-show-apis-235e9fca26fc580d.yaml releasenotes/notes/emit-metrics-for-api-calls-69f18fd1b9d54b05.yaml releasenotes/notes/enable-osprofiler-support-e3839b0fa90d3831.yaml releasenotes/notes/erase-devices-metadata-config-f39b6ca415a87757.yaml releasenotes/notes/error-resilient-enabled_drivers-4e9c864ed6eaddd1.yaml releasenotes/notes/fail-when-vif-port-id-is-missing-7640669f9d9e705d.yaml releasenotes/notes/fake-noop-bebc43983eb801d1.yaml releasenotes/notes/fake_soft_power-32683a848a989fc2.yaml releasenotes/notes/fix-agent-clean-up-9a25deb85bc53d9b.yaml releasenotes/notes/fix-agent-ilo-temp-image-cleanup-711429d0e67807ae.yaml releasenotes/notes/fix-api-access-logs-68b9ca4f411f339c.yaml releasenotes/notes/fix-api-node-name-updates-f3813295472795be.yaml releasenotes/notes/fix-baremetal-admin-user-not-neutron-admin-f163df90ab520dad.yaml releasenotes/notes/fix-boot-from-volume-for-iscsi-deploy-60bc0790ada62b26.yaml releasenotes/notes/fix-boot-from-volume-for-iscsi-deploy-71c1f2905498c50d.yaml releasenotes/notes/fix-bug-1675529-479357c217819420.yaml releasenotes/notes/fix-clean-steps-not-running-0d065cb022bc0419.yaml releasenotes/notes/fix-cleaning-spawn-error-60b60281f3be51c2.yaml releasenotes/notes/fix-cleaning-with-traits-3a54faa70d594fd0.yaml releasenotes/notes/fix-cve-2016-4985-b62abae577025365.yaml releasenotes/notes/fix-dir-permissions-bc56e83a651bbdb0.yaml releasenotes/notes/fix-disk-identifier-overwrite-42b33a5a0f7742d8.yaml releasenotes/notes/fix-get-boot-device-not-persistent-de6159d8d2b60656.yaml releasenotes/notes/fix-get-deploy-info-port.yaml releasenotes/notes/fix-ilo-drivers-log-message-c3c64c1ca0a0bca8.yaml releasenotes/notes/fix-ilo-firmware-update-swift-path-with-pseudo-folder-0660345510ec0bb4.yaml releasenotes/notes/fix-ipa-ephemeral-partition-1f1e020727a49078.yaml releasenotes/notes/fix-ipmi-numeric-password-75e080aa8bdfb9a2.yaml releasenotes/notes/fix-ipmitool-console-empty-password-a8edc5e2a1a7daf6.yaml releasenotes/notes/fix-ipxe-macro-4ae8bc4fe82e8f19.yaml releasenotes/notes/fix-ipxe-template-for-whole-disk-image-943da0311ca7aeb5.yaml releasenotes/notes/fix-keystone-parameters-cdb93576d7e7885b.yaml releasenotes/notes/fix-mac-address-48060f9e2847a38c.yaml releasenotes/notes/fix-mac-address-update-with-contrail-b1e1b725cc0829c2.yaml releasenotes/notes/fix-mitaka-ipa-iscsi.yaml releasenotes/notes/fix-net-ifaces-rebuild-1cc03df5d37f38dd.yaml releasenotes/notes/fix-noop-net-vif-list-a3d8ecee29097662.yaml releasenotes/notes/fix-oneview-deallocate-server-8256e279af837e5d.yaml releasenotes/notes/fix-oneview-deploy-return-values-ab2ec6ae568d95a5.yaml releasenotes/notes/fix-oneview-periodics-0f535fe7a0ad83cd.yaml releasenotes/notes/fix-policy-checkers-1a08203e3c2cf859.yaml releasenotes/notes/fix-provisioning-port-cleanup-79ee7930ca206c42.yaml releasenotes/notes/fix-reboot-log-collection-c3e22fc166135e61.yaml releasenotes/notes/fix-rpc-exceptions-12c70eb6ba177e39.yaml releasenotes/notes/fix-socat-command-afc840284446870a.yaml releasenotes/notes/fix-swift-ssl-options-d93d653dcd404960.yaml releasenotes/notes/fix-sync-power-state-last-error-65fa42bad8e38c3b.yaml releasenotes/notes/fix-updating-node-driver-to-classic-16b0d5ba47e74d10.yaml releasenotes/notes/fix-url-collisions-43abfc8364ca34e7.yaml releasenotes/notes/fix-vif-detach-fca221f1a1c0e9fa.yaml releasenotes/notes/fix-virtualbox-localboot-not-working-558a3dec72b5116b.yaml releasenotes/notes/flag_always_reboot-62468a7058b58823.yaml releasenotes/notes/futurist-e9c55699f479f97a.yaml releasenotes/notes/get-supported-boot-devices-manadatory-task-0462fc072d6ea517.yaml releasenotes/notes/glance-keystone-dd30b884f07f83fb.yaml releasenotes/notes/glance-v2-83b04fec247cd22f.yaml releasenotes/notes/hctl-root-device-hints-0cab86673bc4a924.yaml releasenotes/notes/heartbeat_agent_version-70f4e64b19b51d87.yaml releasenotes/notes/hexraw-support-removed-8e8fa07595a629f4.yaml releasenotes/notes/idrac-hardware-type-54383960af3459d0.yaml releasenotes/notes/idrac-no-vendor-911904dd69457826.yaml releasenotes/notes/ilo-automated-cleaning-fails-14ee438de3dd8690.yaml releasenotes/notes/ilo-boot-from-iscsi-volume-41e8d510979c5037.yaml releasenotes/notes/ilo-boot-interface-92831b78c5614733.yaml releasenotes/notes/ilo-do-not-power-off-non-deploying-nodes-0a3aed7c8ea3940a.yaml releasenotes/notes/ilo-erase-device-priority-config-509661955a11c28e.yaml releasenotes/notes/ilo-firmware-update-manual-clean-step-e6763dc6dc0d441b.yaml releasenotes/notes/ilo-fix-inspection-b169ad0a22aea2ff.yaml releasenotes/notes/ilo-hardware-type-48fd1c8bccd70659.yaml releasenotes/notes/ilo-inconsistent-default-boot-mode-ef5a7c56372f89f1.yaml releasenotes/notes/ilo-license-activate-manual-clean-step-84d335998d708b49.yaml releasenotes/notes/ilo-update-proliantutils-version-fd41a7c2a27be735.yaml releasenotes/notes/ilo-vendor-e8d299ae13388184.yaml releasenotes/notes/image-no-data-c281f638d3dedfb2.yaml releasenotes/notes/implement-policy-in-code-cbb0216ef5f8224f.yaml releasenotes/notes/improve-conductor-shutdown-42687d8b9dac4054.yaml releasenotes/notes/inject-nmi-dacd692b1f259a30.yaml releasenotes/notes/inspection-agent-drivers-cad619ec8a4874b1.yaml releasenotes/notes/inspection-logging-e1172f549ef80b04.yaml releasenotes/notes/inspector-enabled-f8a643f03e1e0360.yaml releasenotes/notes/inspector-for-cisco-bffe1d1af7aec677.yaml releasenotes/notes/inspector-session-179f83cbb0dc169b.yaml releasenotes/notes/ipa-streams-raw-images-1010327b0dad763c.yaml releasenotes/notes/ipmi-cmd-for-ipmi-consoles-2e1104f22df3efcd.yaml releasenotes/notes/ipminative-bootdev-uefi-954a0dd825bcef97.yaml releasenotes/notes/ipmitool-bootdev-persistent-uefi-b1181a3c82343c8f.yaml releasenotes/notes/ipmitool-vendor-3f0f52240ebbe489.yaml releasenotes/notes/ipv6-provision-67bd9c1dbcc48c97.yaml releasenotes/notes/ipxe-and-uefi-7722bd5db71df02c.yaml releasenotes/notes/ipxe-dhcp-b799bc326cd2529a.yaml releasenotes/notes/ipxe-uefi-f5be11c7b0606a84.yaml releasenotes/notes/ipxe-use-swift-5ccf490daab809cc.yaml releasenotes/notes/ipxe_retry_on_failure-e71fc6b3e9a5be3b.yaml releasenotes/notes/ipxe_timeout_parameter-03fc3c76c520fac2.yaml releasenotes/notes/irmc-add-clean-step-reset-bios-config-a8bed625670b7fdf.yaml releasenotes/notes/irmc-additional-capabilities-4fd72ba50d05676c.yaml releasenotes/notes/irmc-boot-from-volume-4bc5d20a0a780669.yaml releasenotes/notes/irmc-boot-interface-8c2e26affd1ebfc4.yaml releasenotes/notes/irmc-oob-inspection-6d072c60f6c88ecb.yaml releasenotes/notes/ironic-cfg-defaults-4708eed8adeee609.yaml releasenotes/notes/iscsi-inband-cleaning-bff87aac16e5d488.yaml releasenotes/notes/iscsi-whole-disk-cd464d589d029b01.yaml releasenotes/notes/keystone-auth-3155762c524e44df.yaml releasenotes/notes/keystoneauth-adapter-opts-ca4f68f568e6cf6f.yaml releasenotes/notes/keystoneauth-config-1baa45a0a2dd93b4.yaml releasenotes/notes/kill-old-ramdisk-6fa7a16269ff11b0.yaml releasenotes/notes/list-nodes-by-driver-a1ab9f2b73f652f8.yaml releasenotes/notes/logging-keystoneauth-9db7e56c54c2473d.yaml releasenotes/notes/lookup-heartbeat-f9772521d12a0549.yaml releasenotes/notes/lookup-ignore-malformed-macs-09e7e909f3a134a3.yaml releasenotes/notes/make-terminal-session-timeout-configurable-b2365b7699b0f98b.yaml releasenotes/notes/manual-abort-d3d8985a5de7376a.yaml releasenotes/notes/manual-clean-4cc2437be1aea69a.yaml releasenotes/notes/mask-configdrive-contents-77fc557d6bc63b2b.yaml releasenotes/notes/mask-ssh-creds-54ab7b2656578d2e.yaml releasenotes/notes/messaging-log-level-5f870ea69db53d26.yaml releasenotes/notes/migrate_to_hardware_types-0c85c6707c4f296d.yaml releasenotes/notes/multi-arch-deploy-bcf840107fc94bef.yaml releasenotes/notes/multiple-workers-for-send-sensor-data-89d29c12da30ec54.yaml releasenotes/notes/multitenant-networking-0a13c4aba252573e.yaml releasenotes/notes/name-root-device-hints-a1484ea01e399065.yaml releasenotes/notes/name-suffix-47aea2d265fa75ae.yaml releasenotes/notes/net-names-b8a36aa30659ce2f.yaml releasenotes/notes/network-flat-use-node-uuid-for-binding-hostid-afb43097e7204b99.yaml releasenotes/notes/neutron-port-timeout-cbd82e1d09c6a46c.yaml releasenotes/notes/new_capabilities-5241619c4b46a460.yaml releasenotes/notes/newton-driver-deprecations-e40369be37203057.yaml releasenotes/notes/next-link-for-instance-uuid-f46eafe5b575f3de.yaml releasenotes/notes/no-downward-sql-migration-52279e875cd8b7a3.yaml releasenotes/notes/no-instance-uuid-workaround-fc458deb168c7a8b.yaml releasenotes/notes/no-more-legacy-auth-eeb32f907d0ab5de.yaml releasenotes/notes/no-root-device-as-kernel-param-5e5326acae7b77a4.yaml releasenotes/notes/no-ssh-drivers-6ee5ff4c3ecdd3fb.yaml releasenotes/notes/node-credentials-cleaning-b1903f49ffeba029.yaml releasenotes/notes/node-deletion-update-resources-53862e48ab658f77.yaml releasenotes/notes/node-name-remove-720aa8007f2f8b75.yaml releasenotes/notes/node-save-internal-info-c5cc8f56f1d0dab0.yaml releasenotes/notes/node-storage-interface-api-1d6e217303bd53ff.yaml releasenotes/notes/node-traits-2d950b62eea24491.yaml releasenotes/notes/nodes-classic-drivers-cannot-set-interfaces-620b37c4e5c88b80.yaml releasenotes/notes/non-persistent-boot-5e3a0cd78e9dc91b.yaml releasenotes/notes/notify-node-storage-interface-7fd07ee7ee71cd22.yaml releasenotes/notes/notimplementederror-misspell-276a181afd652cf6.yaml releasenotes/notes/ocata-summary-a70f995cb3b18e18.yaml releasenotes/notes/oneview-agent-mixin-removal-b7277e8f20df5ef2.yaml releasenotes/notes/oneview-hardware-type-69bbb79da434871f.yaml releasenotes/notes/oneview-inspection-interface-c2d6902bbeca0501.yaml releasenotes/notes/oneview-node-free-for-ironic-61b05fee827664cb.yaml releasenotes/notes/oneview-onetime-boot-64a68e135a45f5e2.yaml releasenotes/notes/oneview-timeout-power-db5125e05831d925.yaml releasenotes/notes/oneview-timing-metrics-0b6c1b54e80eb683.yaml releasenotes/notes/only_default_flat_network_if_enabled-b5c6ea415239a53c.yaml releasenotes/notes/oob-power-off-7bbdf5947ed24bf8.yaml releasenotes/notes/opentack-baremetal-request-id-daa72b785eaaaa8d.yaml releasenotes/notes/oslopolicy-scripts-bdcaeaf7dd9ce2ac.yaml releasenotes/notes/pass-metrics-config-to-agent-on-lookup-6db9ae187c4e8151.yaml releasenotes/notes/pass-region-to-swiftclient-c8c8bf1020f62ebc.yaml releasenotes/notes/pass_portgroup_settings_to_neutron-a6aec830a82c38a3.yaml releasenotes/notes/periodic-tasks-drivers-ae9cddab88b546c6.yaml releasenotes/notes/pin-api-version-029748f7d3be68d1.yaml releasenotes/notes/port-0-is-valid-d7188af3be6f3ecb.yaml releasenotes/notes/port-list-bad-request-078512862c22118e.yaml releasenotes/notes/port-physical-network-a7009dc514353796.yaml releasenotes/notes/portgroup-crud-notifications-91204635528972b2.yaml releasenotes/notes/proliantutils_version_update-b6e5ff0e496215a5.yaml releasenotes/notes/pxe-snmp-driver-supported-9c559c6182c6ec4b.yaml releasenotes/notes/pxe-takeover-d8f14bcb60e5b121.yaml releasenotes/notes/queens-prelude-61fb897e96ed64c5.yaml releasenotes/notes/radosgw-temp-url-b04aac50698b4461.yaml releasenotes/notes/raid-to-support-jbod-568f88207b9216e2.yaml releasenotes/notes/raise-bad-request-exception-on-validating-inspection-failure-57d7fd2999cf4ecf.yaml releasenotes/notes/reboot-do-not-power-off-if-already-1452256167d40009.yaml releasenotes/notes/rebuild-configdrive-f52479fd55b0f5ce.yaml releasenotes/notes/refactor-ironic-lib-22939896d8d46a77.yaml releasenotes/notes/release-4.3.0-cc531ab7190f8a00.yaml releasenotes/notes/rely-on-standalone-ports-supported-8153e1135787828b.yaml releasenotes/notes/removal-pre-allocation-for-oneview-09310a215b3aaf3c.yaml releasenotes/notes/remove-DEPRECATED-options-from-[agent]-7b6cce21b5f52022.yaml releasenotes/notes/remove-agent-passthru-432b18e6c430cee6.yaml releasenotes/notes/remove-agent-passthru-complete-a6b2df65b95889d5.yaml releasenotes/notes/remove-agent_last_heartbeat-65a9fe02f20465c5.yaml releasenotes/notes/remove-clean-nodes-38cfa633ca518f99.yaml releasenotes/notes/remove-clustered-compute-manager-6b45ed3803be53d1.yaml releasenotes/notes/remove-deprecated-build-instance-info-for-deploy-2fe165fc018010e4.yaml releasenotes/notes/remove-deprecated-deploy-erase-devices-iterations-55680ab95cbce3e9.yaml releasenotes/notes/remove-deprecated-dhcp-provider-method-89926a8f0f4793a4.yaml releasenotes/notes/remove-deprecated-dhcp-provider-methods-582742f3000be3c7.yaml releasenotes/notes/remove-deprecated-ilo-clean-priority-erase-devices-bb3073da562ed41d.yaml releasenotes/notes/remove-deprecated-option-names-6d5d53cc70dd2d49.yaml releasenotes/notes/remove-discoverd-group-03eaf75e9f94d7be.yaml releasenotes/notes/remove-driver-object-periodic-tasks-1357a1cd3589becf.yaml releasenotes/notes/remove-driver-periodic-task-f5e513b06b601ce4.yaml releasenotes/notes/remove-exception-message-92100debeb40d4c7.yaml releasenotes/notes/remove-ipminative-driver-3367d25bbcc41fdc.yaml releasenotes/notes/remove-iscsi-deploy-ipa-mitaka-c0efa0d5c31933b6.yaml releasenotes/notes/remove-manage-tftp-0c2f4f417b92b1ee.yaml releasenotes/notes/remove-messaging-aliases-0a6ba1ed392b1fed.yaml releasenotes/notes/remove-most-unsupported-049f3401c2554a3c.yaml releasenotes/notes/remove-neutron-client-workarounds-996c59623684929b.yaml releasenotes/notes/remove-periodic-interval-45f57ebad9aaa14e.yaml releasenotes/notes/remove-policy-json-be92ffdba7bda951.yaml releasenotes/notes/remove-pxe-http-5a05c54f57747bfe.yaml releasenotes/notes/remove-python-oneviewclient-b1d345ef861e156e.yaml releasenotes/notes/remove-ssh-power-port-delay-7ae6e5eb893439cd.yaml releasenotes/notes/remove-verbose-option-261f1b9e24212ee2.yaml releasenotes/notes/removed-glance-host-port-protocol-dc6e682097ba398f.yaml releasenotes/notes/rescue-node-87e3b673c61ef628.yaml releasenotes/notes/reserved-node-names-67a08012ed1131ae.yaml releasenotes/notes/resource-class-change-563797d5a3c35683.yaml releasenotes/notes/resource-classes-1bf903547236a473.yaml releasenotes/notes/resources-crud-notifications-70cba9f761da3afe.yaml releasenotes/notes/restart-console-on-conductor-startup-5cff6128c325b18e.yaml releasenotes/notes/reusing-oneview-client-6a3936fb8f113c10.yaml releasenotes/notes/rolling-upgrades-ccad5159ca3cedbe.yaml releasenotes/notes/root-api-version-info-9dd6cadd3d3d4bbe.yaml releasenotes/notes/root-device-hints-rotational-c21f02130394e1d4.yaml releasenotes/notes/scciclient-0.4.0-6f01c0f0a5c39062.yaml releasenotes/notes/security_groups-b57a5d6c30c2fae4.yaml releasenotes/notes/server_profile_template_uri-c79e4f15cc20a1cf.yaml releasenotes/notes/setting_provisioning_cleaning_network-fb60caa1cf59cdcf.yaml releasenotes/notes/shred-final-overwrite-with-zeros-50b5ba5b19c0da27.yaml releasenotes/notes/snmp-driver-udp-transport-settings-67419be988fcff40.yaml releasenotes/notes/snmp-hardware-type-ee3d471cf5c596f4.yaml releasenotes/notes/snmp-outlet-validate-ffbe8e6687172efc.yaml releasenotes/notes/snmp-reboot-delay-d18ee3f6c6fc0998.yaml releasenotes/notes/socat-address-conf-5cf043fabb10bd76.yaml releasenotes/notes/soft-power-operations-oneview-e7ac054668235998.yaml releasenotes/notes/soft-reboot-poweroff-9fdb0a4306dd668d.yaml releasenotes/notes/sort_key_allowed_field-091f8eeedd0a2ace.yaml releasenotes/notes/ssh-console-58721af6830f8892.yaml releasenotes/notes/sum-based-update-firmware-manual-clean-step-e69ade488060cf27.yaml releasenotes/notes/support-root-device-hints-with-operators-96cf34fa37b5b2e8.yaml releasenotes/notes/tempest_plugin_removal-009f9ce8456b16fe.yaml releasenotes/notes/uefi-grub2-by-default-6b797a9e690d2dd5.yaml releasenotes/notes/update-irmc-set-boot-device-fd50d9dce42aaa89.yaml releasenotes/notes/update-live-port-ee3fa9b77f5d0cf7.yaml releasenotes/notes/update-proliantutils-version-20ebcc22dc2df527.yaml releasenotes/notes/update-proliantutils-version-54c0cd5c5d3c01dc.yaml releasenotes/notes/update-python-scciclient-required-version-71398d5d5e1c0bf8.yaml releasenotes/notes/use-dhcp-option-numbers-8b0b0efae912ff5f.yaml releasenotes/notes/validate-ilo-certificates-3ab98bb8cfad7d60.yaml releasenotes/notes/validate-image-url-wnen-deploying-8820f4398ea9de9f.yaml releasenotes/notes/validate-node-properties-73509ee40f409ca2.yaml releasenotes/notes/validate-port-info-before-using-it-e26135982d37c698.yaml releasenotes/notes/vendor-passthru-shared-lock-6a9e32952ee6c2fe.yaml releasenotes/notes/vif-detach-locking-fix-7be66f8150e19819.yaml releasenotes/notes/vif-detach-locking-fix-revert-3961d47fe419460a.yaml releasenotes/notes/volume-connector-and-target-api-dd172f121ab3af8e.yaml releasenotes/notes/wipe-disk-before-deployment-0a8b9cede4a659e9.yaml releasenotes/notes/wsgi-applications-5d36cf2a8885a56d.yaml releasenotes/notes/wwn-extension-root-device-hints-de40ca1444ba4888.yaml releasenotes/notes/xclarity-driver-622800d17459e3f9.yaml releasenotes/notes/xenserver-ssh-driver-398084fe91ac56f1.yaml releasenotes/source/conf.py releasenotes/source/index.rst releasenotes/source/liberty.rst releasenotes/source/mitaka.rst releasenotes/source/newton.rst releasenotes/source/ocata.rst releasenotes/source/pike.rst releasenotes/source/unreleased.rst releasenotes/source/_static/.placeholder releasenotes/source/_templates/.placeholder tools/__init__.py tools/check-releasenotes.py tools/flake8wrap.sh tools/run_bashate.sh tools/states_to_dot.py tools/test-setup.sh tools/with_venv.sh tools/config/check_uptodate.sh tools/config/ironic-config-generator.conf tools/policy/ironic-policy-generator.conf zuul.d/legacy-ironic-jobs.yaml zuul.d/project.yamlironic-10.1.1/ironic.egg-info/pbr.json0000664000175100017510000000005613243617730017543 0ustar zuulzuul00000000000000{"git_version": "46828a2", "is_release": true}ironic-10.1.1/ironic.egg-info/requires.txt0000664000175100017510000000177713243617730020500 0ustar zuulzuul00000000000000pbr!=2.1.0,>=2.0.0 SQLAlchemy!=1.1.5,!=1.1.6,!=1.1.7,!=1.1.8,>=1.0.10 alembic>=0.8.10 automaton>=1.9.0 eventlet!=0.18.3,!=0.20.1,<0.21.0,>=0.18.2 WebOb>=1.7.1 python-cinderclient>=3.3.0 python-neutronclient>=6.3.0 python-glanceclient>=2.8.0 keystoneauth1>=3.3.0 ironic-lib>=2.5.0 python-swiftclient>=3.2.0 pytz>=2013.6 stevedore>=1.20.0 pysendfile>=2.0.0 oslo.concurrency>=3.25.0 oslo.config>=5.1.0 oslo.context>=2.19.2 oslo.db>=4.27.0 oslo.rootwrap>=5.8.0 oslo.i18n>=3.15.3 oslo.log>=3.36.0 oslo.middleware>=3.31.0 oslo.policy>=1.30.0 oslo.reports>=1.18.0 oslo.serialization!=2.19.1,>=2.18.0 oslo.service!=1.28.1,>=1.24.0 oslo.utils>=3.33.0 osprofiler>=1.4.0 os-traits>=0.4.0 pecan!=1.0.2,!=1.0.3,!=1.0.4,!=1.2,>=1.0.0 requests>=2.14.2 rfc3986>=0.3.1 six>=1.10.0 jsonpatch!=1.20,>=1.16 WSME>=0.8.0 Jinja2!=2.9.0,!=2.9.1,!=2.9.2,!=2.9.3,!=2.9.4,>=2.8 keystonemiddleware>=4.17.0 oslo.messaging>=5.29.0 retrying!=1.3.0,>=1.2.3 oslo.versionedobjects>=1.31.2 jsonschema<3.0.0,>=2.6.0 psutil>=3.2.2 futurist>=1.2.0 tooz>=1.58.0 ironic-10.1.1/ironic.egg-info/entry_points.txt0000664000175100017510000001564313243617730021373 0ustar zuulzuul00000000000000[console_scripts] ironic-api = ironic.cmd.api:main ironic-conductor = ironic.cmd.conductor:main ironic-dbsync = ironic.cmd.dbsync:main ironic-rootwrap = oslo_rootwrap.cmd:main [ironic.database.migration_backend] sqlalchemy = ironic.db.sqlalchemy.migration [ironic.dhcp] neutron = ironic.dhcp.neutron:NeutronDHCPApi none = ironic.dhcp.none:NoneDHCPApi [ironic.drivers] agent_ilo = ironic.drivers.ilo:IloVirtualMediaAgentDriver agent_ipmitool = ironic.drivers.ipmi:AgentAndIPMIToolDriver agent_ipmitool_socat = ironic.drivers.ipmi:AgentAndIPMIToolAndSocatDriver agent_irmc = ironic.drivers.irmc:IRMCVirtualMediaAgentDriver agent_pxe_oneview = ironic.drivers.oneview:AgentPXEOneViewDriver agent_ucs = ironic.drivers.agent:AgentAndUcsDriver fake = ironic.drivers.fake:FakeDriver fake_agent = ironic.drivers.fake:FakeAgentDriver fake_cimc = ironic.drivers.fake:FakeCIMCDriver fake_drac = ironic.drivers.fake:FakeDracDriver fake_ilo = ironic.drivers.fake:FakeIloDriver fake_inspector = ironic.drivers.fake:FakeIPMIToolInspectorDriver fake_ipmitool = ironic.drivers.fake:FakeIPMIToolDriver fake_ipmitool_socat = ironic.drivers.fake:FakeIPMIToolSocatDriver fake_irmc = ironic.drivers.fake:FakeIRMCDriver fake_oneview = ironic.drivers.fake:FakeOneViewDriver fake_pxe = ironic.drivers.fake:FakePXEDriver fake_snmp = ironic.drivers.fake:FakeSNMPDriver fake_soft_power = ironic.drivers.fake:FakeSoftPowerDriver fake_ucs = ironic.drivers.fake:FakeUcsDriver iscsi_ilo = ironic.drivers.ilo:IloVirtualMediaIscsiDriver iscsi_irmc = ironic.drivers.irmc:IRMCVirtualMediaIscsiDriver iscsi_pxe_oneview = ironic.drivers.oneview:ISCSIPXEOneViewDriver pxe_agent_cimc = ironic.drivers.agent:AgentAndCIMCDriver pxe_drac = ironic.drivers.drac:PXEDracDriver pxe_drac_inspector = ironic.drivers.drac:PXEDracInspectorDriver pxe_ilo = ironic.drivers.pxe:PXEAndIloDriver pxe_ipmitool = ironic.drivers.ipmi:PXEAndIPMIToolDriver pxe_ipmitool_socat = ironic.drivers.ipmi:PXEAndIPMIToolAndSocatDriver pxe_irmc = ironic.drivers.pxe:PXEAndIRMCDriver pxe_iscsi_cimc = ironic.drivers.pxe:PXEAndCIMCDriver pxe_snmp = ironic.drivers.pxe:PXEAndSNMPDriver pxe_ucs = ironic.drivers.pxe:PXEAndUcsDriver [ironic.hardware.interfaces.boot] fake = ironic.drivers.modules.fake:FakeBoot ilo-pxe = ironic.drivers.modules.ilo.boot:IloPXEBoot ilo-virtual-media = ironic.drivers.modules.ilo.boot:IloVirtualMediaBoot irmc-pxe = ironic.drivers.modules.irmc.boot:IRMCPXEBoot irmc-virtual-media = ironic.drivers.modules.irmc.boot:IRMCVirtualMediaBoot pxe = ironic.drivers.modules.pxe:PXEBoot [ironic.hardware.interfaces.console] fake = ironic.drivers.modules.fake:FakeConsole ilo = ironic.drivers.modules.ilo.console:IloConsoleInterface ipmitool-shellinabox = ironic.drivers.modules.ipmitool:IPMIShellinaboxConsole ipmitool-socat = ironic.drivers.modules.ipmitool:IPMISocatConsole no-console = ironic.drivers.modules.noop:NoConsole [ironic.hardware.interfaces.deploy] ansible = ironic.drivers.modules.ansible.deploy:AnsibleDeploy direct = ironic.drivers.modules.agent:AgentDeploy fake = ironic.drivers.modules.fake:FakeDeploy iscsi = ironic.drivers.modules.iscsi_deploy:ISCSIDeploy oneview-direct = ironic.drivers.modules.oneview.deploy:OneViewAgentDeploy oneview-iscsi = ironic.drivers.modules.oneview.deploy:OneViewIscsiDeploy [ironic.hardware.interfaces.inspect] fake = ironic.drivers.modules.fake:FakeInspect idrac = ironic.drivers.modules.drac.inspect:DracInspect ilo = ironic.drivers.modules.ilo.inspect:IloInspect inspector = ironic.drivers.modules.inspector:Inspector irmc = ironic.drivers.modules.irmc.inspect:IRMCInspect no-inspect = ironic.drivers.modules.noop:NoInspect oneview = ironic.drivers.modules.oneview.inspect:OneViewInspect [ironic.hardware.interfaces.management] cimc = ironic.drivers.modules.cimc.management:CIMCManagement fake = ironic.drivers.modules.fake:FakeManagement idrac = ironic.drivers.modules.drac.management:DracManagement ilo = ironic.drivers.modules.ilo.management:IloManagement ipmitool = ironic.drivers.modules.ipmitool:IPMIManagement irmc = ironic.drivers.modules.irmc.management:IRMCManagement oneview = ironic.drivers.modules.oneview.management:OneViewManagement redfish = ironic.drivers.modules.redfish.management:RedfishManagement ucsm = ironic.drivers.modules.ucs.management:UcsManagement xclarity = ironic.drivers.modules.xclarity.management:XClarityManagement [ironic.hardware.interfaces.network] flat = ironic.drivers.modules.network.flat:FlatNetwork neutron = ironic.drivers.modules.network.neutron:NeutronNetwork noop = ironic.drivers.modules.network.noop:NoopNetwork [ironic.hardware.interfaces.power] cimc = ironic.drivers.modules.cimc.power:Power fake = ironic.drivers.modules.fake:FakePower idrac = ironic.drivers.modules.drac.power:DracPower ilo = ironic.drivers.modules.ilo.power:IloPower ipmitool = ironic.drivers.modules.ipmitool:IPMIPower irmc = ironic.drivers.modules.irmc.power:IRMCPower oneview = ironic.drivers.modules.oneview.power:OneViewPower redfish = ironic.drivers.modules.redfish.power:RedfishPower snmp = ironic.drivers.modules.snmp:SNMPPower ucsm = ironic.drivers.modules.ucs.power:Power xclarity = ironic.drivers.modules.xclarity.power:XClarityPower [ironic.hardware.interfaces.raid] agent = ironic.drivers.modules.agent:AgentRAID fake = ironic.drivers.modules.fake:FakeRAID idrac = ironic.drivers.modules.drac.raid:DracRAID no-raid = ironic.drivers.modules.noop:NoRAID [ironic.hardware.interfaces.rescue] agent = ironic.drivers.modules.agent:AgentRescue fake = ironic.drivers.modules.fake:FakeRescue no-rescue = ironic.drivers.modules.noop:NoRescue [ironic.hardware.interfaces.storage] cinder = ironic.drivers.modules.storage.cinder:CinderStorage fake = ironic.drivers.modules.fake:FakeStorage noop = ironic.drivers.modules.storage.noop:NoopStorage [ironic.hardware.interfaces.vendor] fake = ironic.drivers.modules.fake:FakeVendorB idrac = ironic.drivers.modules.drac.vendor_passthru:DracVendorPassthru ilo = ironic.drivers.modules.ilo.vendor:VendorPassthru ipmitool = ironic.drivers.modules.ipmitool:VendorPassthru no-vendor = ironic.drivers.modules.noop:NoVendor [ironic.hardware.types] cisco-ucs-managed = ironic.drivers.cisco_ucs:CiscoUCSManaged cisco-ucs-standalone = ironic.drivers.cisco_ucs:CiscoUCSStandalone fake-hardware = ironic.drivers.fake_hardware:FakeHardware idrac = ironic.drivers.drac:IDRACHardware ilo = ironic.drivers.ilo:IloHardware ipmi = ironic.drivers.ipmi:IPMIHardware irmc = ironic.drivers.irmc:IRMCHardware manual-management = ironic.drivers.generic:ManualManagementHardware oneview = ironic.drivers.oneview:OneViewHardware redfish = ironic.drivers.redfish:RedfishHardware snmp = ironic.drivers.snmp:SNMPHardware xclarity = ironic.drivers.xclarity:XClarityHardware [oslo.config.opts] ironic = ironic.conf.opts:list_opts [oslo.config.opts.defaults] ironic = ironic.conf.opts:update_opt_defaults [oslo.policy.enforcer] ironic = ironic.common.policy:get_oslo_policy_enforcer [oslo.policy.policies] ironic.api = ironic.common.policy:list_policies [wsgi_scripts] ironic-api-wsgi = ironic.api.wsgi:initialize_wsgi_app ironic-10.1.1/ironic.egg-info/dependency_links.txt0000664000175100017510000000000113243617730022132 0ustar zuulzuul00000000000000 ironic-10.1.1/ironic.egg-info/top_level.txt0000664000175100017510000000000713243617730020613 0ustar zuulzuul00000000000000ironic ironic-10.1.1/Vagrantfile0000666000175100017510000000173213243617463015304 0ustar zuulzuul00000000000000# -*- mode: ruby -*- # vi: set ft=ruby : # WARNING: This Vagrantfile is for development purposes only. It is intended to # bootstrap required services - such as mysql and rabbit - into a reliably # accessible VM, rather than forcing the engineer to install and manage these # services manually. This Vagrantfile is not intended to assist in provisioning # Ironic. For that, please use the bifrost project. VAGRANTFILE_API_VERSION = '2' Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| config.vm.box = 'ubuntu/trusty64' config.vm.define 'ironic' do |ironic| ironic.vm.provider :virtualbox do |vb| vb.customize ['modifyvm', :id, '--memory', '512', '--cpuexecutioncap', '25'] end ironic.vm.network 'private_network', ip: '192.168.99.11' # It goes to 11. ironic.vm.provision 'ansible' do |ansible| ansible.verbose = 'v' ansible.playbook = 'vagrant.yaml' ansible.extra_vars = { ip: '192.168.99.11' } end end end ironic-10.1.1/tox.ini0000666000175100017510000000702013243617471014425 0ustar zuulzuul00000000000000[tox] minversion = 1.8 skipsdist = True envlist = py3,py27,pep8 [testenv] usedevelop = True install_command = pip install -U -c{env:UPPER_CONSTRAINTS_FILE:https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt?h=stable/queens} {opts} {packages} setenv = VIRTUAL_ENV={envdir} PYTHONDONTWRITEBYTECODE = 1 LANGUAGE=en_US LC_ALL=en_US.UTF-8 PYTHONWARNINGS=default::DeprecationWarning TESTS_DIR=./ironic/tests/unit/ deps = -r{toxinidir}/test-requirements.txt commands = ostestr {posargs} passenv = http_proxy HTTP_PROXY https_proxy HTTPS_PROXY no_proxy NO_PROXY [testenv:unit-with-driver-libs] basepython = python2 deps = {[testenv]deps} -r{toxinidir}/driver-requirements.txt [testenv:genstates] deps = {[testenv]deps} pydot2 commands = {toxinidir}/tools/states_to_dot.py -f {toxinidir}/doc/source/images/states.svg --format svg [testenv:pep8] whitelist_externals = bash commands = bash tools/flake8wrap.sh {posargs} # Run bashate during pep8 runs to ensure violations are caught by # the check and gate queues. {toxinidir}/tools/run_bashate.sh {toxinidir} # Check that .po and .pot files are valid: bash -c "find ironic -type f -regex '.*\.pot?' -print0|xargs -0 -n 1 msgfmt --check-format -o /dev/null" # Check the *.rst files doc8 README.rst CONTRIBUTING.rst doc/source --ignore D001 [testenv:cover] setenv = VIRTUAL_ENV={envdir} LANGUAGE=en_US PYTHON=coverage run --source ironic --omit='*tests*' --parallel-mode commands = coverage erase ostestr {posargs} coverage combine coverage report --omit='*tests*' coverage html -d ./cover --omit='*tests*' [testenv:checkconfig] sitepackages = False envdir = {toxworkdir}/venv commands = {toxinidir}/tools/config/check_uptodate.sh [testenv:genconfig] sitepackages = False envdir = {toxworkdir}/venv commands = oslo-config-generator --config-file=tools/config/ironic-config-generator.conf [testenv:genpolicy] sitepackages = False envdir = {toxworkdir}/venv commands = oslopolicy-sample-generator --config-file=tools/policy/ironic-policy-generator.conf [testenv:debug] commands = oslo_debug_helper -t ironic/tests/unit {posargs} [testenv:docs] # FIXME(dtantsur): workaround for bug #1714025 basepython = python2 setenv = PYTHONHASHSEED=0 sitepackages = False envdir = {toxworkdir}/venv commands = python setup.py build_sphinx [testenv:api-ref] # This environment is called from CI scripts to test and publish # the API Ref to developer.openstack.org. whitelist_externals = bash commands = bash -c 'rm -rf api-ref/build' sphinx-build -W -b html -d api-ref/build/doctrees api-ref/source api-ref/build/html [testenv:releasenotes] commands = {toxinidir}/tools/check-releasenotes.py sphinx-build -a -E -W -d releasenotes/build/doctrees -b html releasenotes/source releasenotes/build/html [testenv:venv] setenv = PYTHONHASHSEED=0 commands = {posargs} [flake8] # TODO(vdrok): Remove I202 from ignore list when we split out # the tempest plugin ignore = E129,I202 filename = *.py,app.wsgi exclude = .venv,.git,.tox,dist,doc,*lib/python*,*egg,build import-order-style = pep8 application-import-names = ironic max-complexity=18 # [H106] Don’t put vim configuration in source files. # [H203] Use assertIs(Not)None to check for None. # [H204] Use assert(Not)Equal to check for equality. # [H205] Use assert(Greater|Less)(Equal) for comparison. # [H904] Delay string interpolations at logging calls. enable-extensions=H106,H203,H204,H205,H904 [hacking] import_exceptions = testtools.matchers, ironic.common.i18n ironic-10.1.1/releasenotes/0000775000175100017510000000000013243617733015603 5ustar zuulzuul00000000000000ironic-10.1.1/releasenotes/notes/0000775000175100017510000000000013243617733016733 5ustar zuulzuul00000000000000ironic-10.1.1/releasenotes/notes/socat-address-conf-5cf043fabb10bd76.yaml0000666000175100017510000000036313243617464025644 0ustar zuulzuul00000000000000--- features: - | Adds new configuration option ``[console]/socat_address`` to set the binding address for socat-based console. The default is the value of the ``[DEFAULT]my_ip`` option of the conductor responsible for the node. ironic-10.1.1/releasenotes/notes/network-flat-use-node-uuid-for-binding-hostid-afb43097e7204b99.yaml0000666000175100017510000000373613243617464032560 0ustar zuulzuul00000000000000--- features: - Adds support for `routed networks `_ when using the ``flat`` network interface. This feature requires the ``baremetal`` ML2 mechanism driver and L2 agent from the `networking-baremetal `_ plugin. See the `networking configuration documentation `_ for more details. upgrade: - | The ``baremetal`` ML2 mechanism driver and L2 agent should now be used with the ``flat`` network interface. When installed, the ``baremetal`` mechanism driver and agent ensure that ports are properly bound in the Networking service. Installation and configuration of the ML2 components are documented in the `networking-baremetal project documentation `_. Without the ML2 mechanism driver and L2 agent, the Networking service's ports will not be correctly bound. In the Networking service, ports will have a ``DOWN`` status, and the ``binding_vif_type`` field equal to ``binding_failed``. This was always the status for the ``flat`` network interface ports prior to the introduction of the ``baremetal`` mechanism driver. For a non-routed network, bare metal nodes can still be deployed and are functional, despite this port binding state in the Networking service. fixes: - Fixes an issue where the Networking service would reject port bindings with the ``flat`` network interface because no host would match the *host-id* used in such configurations. The ``flat`` network interface no longer requires a networking agent (such as ``neutron-openvswitch-agent``) to be run on the ``nova-compute`` proxy node which executes the ironic virt driver. Instead, the interface uses the `baremetal mechanism driver `_. ironic-10.1.1/releasenotes/notes/use-dhcp-option-numbers-8b0b0efae912ff5f.yaml0000666000175100017510000000043013243617464026743 0ustar zuulzuul00000000000000--- fixes: - | Uses standard DHCP option codes instead of dnsmasq-specific option names, because different backends use different option names. This fixes the `compatibility issues with neutron's DHCP backends `_. ironic-10.1.1/releasenotes/notes/remove-clustered-compute-manager-6b45ed3803be53d1.yaml0000666000175100017510000000023113243617464030376 0ustar zuulzuul00000000000000--- upgrade: - | The deprecated ironic.nova.ClusteredComputerManager module is now removed. This is not required with nova >= 14.0.0 (Newton). ironic-10.1.1/releasenotes/notes/flag_always_reboot-62468a7058b58823.yaml0000666000175100017510000000061013243617464025412 0ustar zuulzuul00000000000000--- features: - | Adds a boolean flag called ``force_persistent_boot_device`` into a node's ``driver_info`` to enable persistent behavior when you set the boot device during deploy and cleaning operations. This flag will override a non-persistent behavior in the cleaning and deploy process. For more information, see https://bugs.launchpad.net/ironic/+bug/1703945. ironic-10.1.1/releasenotes/notes/fix-baremetal-admin-user-not-neutron-admin-f163df90ab520dad.yaml0000666000175100017510000000026513243617464032326 0ustar zuulzuul00000000000000--- fixes: - Changes interactions with neutron to always use the neutron credentials from ironic configuration, instead of forwarding the credentials from the API client. ironic-10.1.1/releasenotes/notes/validate-image-url-wnen-deploying-8820f4398ea9de9f.yaml0000666000175100017510000000015013243617464030470 0ustar zuulzuul00000000000000--- fixes: - Ironic now validates any swift temporary URL when preparing for deployment of nodes. ironic-10.1.1/releasenotes/notes/reusing-oneview-client-6a3936fb8f113c10.yaml0000666000175100017510000000017013243617464026352 0ustar zuulzuul00000000000000--- fixes: - Fixes a bug where OneView drivers create a new instance of the OneView client for each request made. ironic-10.1.1/releasenotes/notes/image-no-data-c281f638d3dedfb2.yaml0000666000175100017510000000036513243617464024611 0ustar zuulzuul00000000000000--- fixes: - | Fails deployment with the correct error message in a node's ``last_error`` field if an image from the Image service doesn't contain any data. See `bug 1741223 `_ for details. ironic-10.1.1/releasenotes/notes/adopt-ironic-context-5e75540dc2b2f009.yaml0000666000175100017510000000014113243617464026020 0ustar zuulzuul00000000000000--- fixes: - Fixes a bug where Ironic won't log the request-id during hardware inspection. ironic-10.1.1/releasenotes/notes/irmc-additional-capabilities-4fd72ba50d05676c.yaml0000666000175100017510000000133113243617464027522 0ustar zuulzuul00000000000000--- features: - | Adds new capabilities (``server_model``, ``rom_firmware_version``, ``pci_gpu_devices``, ``trusted_boot`` and ``irmc_firmware_version``) to the iRMC out-of-band hardware inspection for FUJITSU PRIMERGY bare metal nodes with firmware iRMC S4 and newer. other: - | During the out-of-band inspection for nodes using the ``irmc`` hardware type, nodes will be powered on. The original power state will be restored after inspection is finished. upgrade: - | *python-scciclient* of version 0.6.0 or newer is required by the ``irmc`` hardware type to support new out-of-band inspection capabilities. If an older version is used, the new capabilities will not be discovered. ironic-10.1.1/releasenotes/notes/no-downward-sql-migration-52279e875cd8b7a3.yaml0000666000175100017510000000033113243617464027015 0ustar zuulzuul00000000000000--- features: - Database migrations downgrade support was removed. More info about database migration/rollback could be found here http://docs.openstack.org/openstack-ops/content/ops_upgrades-roll-back.html ironic-10.1.1/releasenotes/notes/bfv-pxe-boot-3375d331ee2f04f2.yaml0000666000175100017510000000031713243617464024263 0ustar zuulzuul00000000000000--- fixes: - Fixes a problem when using boot from volume with the ``pxe`` boot interface (`bug 1724275 `_). Now the correct iSCSI initiator is used. ironic-10.1.1/releasenotes/notes/fix-cleaning-with-traits-3a54faa70d594fd0.yaml0000666000175100017510000000045213243617464026735 0ustar zuulzuul00000000000000--- fixes: - | Fixes an issue seen during cleaning when the node being cleaned has one or more traits assigned. This issue caused cleaning to fail, and the node to enter the ``clean failed`` state. See `bug 1750027 `_ for details. ironic-10.1.1/releasenotes/notes/idrac-hardware-type-54383960af3459d0.yaml0000666000175100017510000000113413243617464025460 0ustar zuulzuul00000000000000--- features: - | Adds a new hardware type, ``idrac``, for Dell EMC integrated Dell Remote Access Controllers (iDRAC). ``idrac`` hardware type supports PXE-based provisioning using an iDRAC. It supports the following driver interfaces: * boot: ``pxe`` * console: ``no-console`` * deploy: ``iscsi`` and ``direct`` * inspect: ``idrac``, ``inspector``, and ``no-inspect`` * management: ``idrac`` * network: ``flat``, ``neutron``, and ``noop`` * power: ``idrac`` * raid: ``idrac`` and ``no-raid`` * storage: ``noop`` and ``cinder`` * vendor: ``idrac`` ironic-10.1.1/releasenotes/notes/kill-old-ramdisk-6fa7a16269ff11b0.yaml0000666000175100017510000000040613243617464025173 0ustar zuulzuul00000000000000--- prelude: > Starting with this release IPA is the only deployment and inspection ramdisk supported by Ironic. upgrade: - Support for the old ramdisk ("deploy-ironic" diskimage-builder element) was removed. Please switch to IPA before upgrading. ironic-10.1.1/releasenotes/notes/ssh-console-58721af6830f8892.yaml0000666000175100017510000000011013243617464024064 0ustar zuulzuul00000000000000--- features: - Adds ShellinaboxConsole support for virsh SSH driver. ironic-10.1.1/releasenotes/notes/ilo-firmware-update-manual-clean-step-e6763dc6dc0d441b.yaml0000666000175100017510000000021013243617464031267 0ustar zuulzuul00000000000000--- features: - iLO drivers now provide out-of-band firmware update as a manual cleaning step, for supported hardware components. ironic-10.1.1/releasenotes/notes/bug-1506657-3bcb4ef46623124d.yaml0000666000175100017510000000100013243617464023427 0ustar zuulzuul00000000000000--- upgrade: - Adds a new configuration option, hash_ring_reset_interval, to control how often the conductor's view of the hash ring is reset. This has a default of 180 seconds, the same as the default for the sync_local_state periodic task that used to handle this reset. critical: - Fixes a bug where the conductor's view of the hash ring was never refreshed if the sync_local_state periodic task was disabled. For more info, see https://bugs.launchpad.net/ironic/+bug/1506657. ironic-10.1.1/releasenotes/notes/fix-get-boot-device-not-persistent-de6159d8d2b60656.yaml0000666000175100017510000000042013243617464030521 0ustar zuulzuul00000000000000--- fixes: - | The ``oneview`` management interface now correctly detects whether the current boot device setting is persistent at the machine's iLO. Previously it always returned ``True``. See https://bugs.launchpad.net/ironic/+bug/1706725 for details. ironic-10.1.1/releasenotes/notes/keystone-auth-3155762c524e44df.yaml0000666000175100017510000000461113243617464024503 0ustar zuulzuul00000000000000--- upgrade: - | Changes the way to configure access credentials for OpenStack services clients. For each service, both Keystone session options (timeout, SSL-related ones) and Keystone auth_plugin options (auth_url, auth_type and corresponding auth_plugin options) should be specified in the configuration section for this service. Configuration sections affected are: * ``[neutron]`` for Neutron service user * ``[glance]`` for Glance service user * ``[swift]`` for Swift service user * ``[inspector]`` for Ironic Inspector service user * ``[service_catalog]`` *new section* for Ironic service user, used to discover Ironic endpoint from Keystone Catalog This enables fine tuning of authentication for each service. Backward-compatible options handling is provided using values from ``[keystone_authtoken]`` config section, but operators are advised to switch to the new config options as the old options are deprecated. The old options will be removed during the Ocata cycle. For more information on sessions, auth plugins and their settings, please refer to http://docs.openstack.org/developer/keystoneauth/. - | Small change in semantics of default for ``[neutron]/url`` option * default is changed to None. * For the case when ``[neutron]/auth_strategy`` is ``noauth``, default means use ``http://$my_ip:9696``. * For the case when ``[neutron]/auth_strategy`` is ``keystone``, default means to resolve the endpoint from Keystone Catalog. - New config section ``[service_catalog]`` for access credentials used to discover Ironic API URL from Keystone Catalog. Previously credentials from ``[keystone_authtoken]`` section were used, which is now deprecated for such purpose. deprecations: - The ``[keystone_authtoken]`` configuration section is deprecated for configuring clients for other services (but is still used for configuring API token authentication), in favor of the ``[service_catalog]`` section. The ability to configure clients for other services via the ``[keystone_authtoken]`` section will be removed during the Ocata cycle. fixes: - Do not rely on keystonemiddleware config options for instantiating clients for other OpenStack services. This allows changing keystonemiddleware options from legacy ones and thus support Keystone V3 for token validation. ironic-10.1.1/releasenotes/notes/root-api-version-info-9dd6cadd3d3d4bbe.yaml0000666000175100017510000000045013243617464026562 0ustar zuulzuul00000000000000--- features: - | The API root endpoint (GET /) now returns version information for the server; specifically: * min_version - minimum API version supported by the server; * version - maximum API version supported by the server; * status - version status, "CURRENT" for v1. ironic-10.1.1/releasenotes/notes/add-support-for-no-poweroff-on-failure-86e43b3e39043990.yaml0000666000175100017510000000070613243617464031157 0ustar zuulzuul00000000000000--- features: - Operators can now set deploy.power_off_after_deploy_failure to leave nodes powered on when a deployment fails. This is useful for troubleshooting deployment issues. As a note, Nova will still attempt to delete a node after a failed deployment, so deploy.power_off_after_deploy_failure may not be very effective in non-standalone deployments until a similar patch to ironic's driver in nova is proposed. ironic-10.1.1/releasenotes/notes/fix-api-access-logs-68b9ca4f411f339c.yaml0000666000175100017510000000021013243617464025573 0ustar zuulzuul00000000000000--- fixes: - API service once again records HTTP access logs. See https://bugs.launchpad.net/ironic/+bug/1536828 for details. ironic-10.1.1/releasenotes/notes/proliantutils_version_update-b6e5ff0e496215a5.yaml0000666000175100017510000000041413243617464030062 0ustar zuulzuul00000000000000--- upgrade: - The minimum required version of proliantutils (needed for iLO drivers) was bumped to 2.1.11. This version includes fixes for the bugs caused by python request library version 2.11.0, Proliant Gen7 support and iLO based RAID configuration. ironic-10.1.1/releasenotes/notes/resources-crud-notifications-70cba9f761da3afe.yaml0000666000175100017510000000214413243617464030072 0ustar zuulzuul00000000000000--- features: - | Adds the following notifications: - Creation, updates, or deletions of ironic resources (node, port and chassis). Event types are ``baremetal..{create,update,delete}.{start,end,error}``. - Start and stop console on a node. Event types are ``baremetal.node.console_{set,restore}.{start,end,error}``. - Changes in node maintenance status. Event types are ``baremetal.node.maintenance_set.{start,end,error}``. - When ironic attempts to set the power state on the node. Event types are ``baremetal.node.power_set.{start,end,error}``. - When ironic detects the power state on baremetal hardware has changed and updates the node in the database appropriately. Event types are ``baremetal.node.power_state_corrected.success``. - Node provision state changes. Event types are ``baremetal.node.provision_set.{start,end,success,error}``. These are only emitted when notifications are enabled. For more details, see the developer documentation: http://docs.openstack.org/developer/ironic/deploy/notifications.html. ironic-10.1.1/releasenotes/notes/pxe-snmp-driver-supported-9c559c6182c6ec4b.yaml0000666000175100017510000000011713243617464027133 0ustar zuulzuul00000000000000--- features: - The pxe_snmp and fake_snmp are now supported and tested. ironic-10.1.1/releasenotes/notes/backfill_version_column_db_race_condition-713fa05832b93ca5.yaml0000666000175100017510000000045013243617464032347 0ustar zuulzuul00000000000000--- fixes: - | Fixes an issue when running ``ironic-dbsync online_data_migrations``. The value of an object's new ``version`` column might have been incorrectly changed from a newer object version to an older object version, due to a race condition. This is no longer the case. ironic-10.1.1/releasenotes/notes/vif-detach-locking-fix-revert-3961d47fe419460a.yaml0000666000175100017510000000031513243617464027433 0ustar zuulzuul00000000000000--- fixes: - | Reverts the fix for orphaned VIF records from the previous release, as it causes a regression. See `bug 1750785 `_ for details. ironic-10.1.1/releasenotes/notes/fix-get-deploy-info-port.yaml0000666000175100017510000000025013243617464024367 0ustar zuulzuul00000000000000--- fixes: - Fixed the default value of 'port' in iscsi_deploy.get_deploy_info to be set to [iscsi]/portal_port option value, instead of hardcoding it to '3260'. ironic-10.1.1/releasenotes/notes/fix-cve-2016-4985-b62abae577025365.yaml0000666000175100017510000000124513243617464024312 0ustar zuulzuul00000000000000--- security: - A critical security vulnerability (CVE-2016-4985) was fixed in this release. Previously, a client with network access to the ironic-api service was able to bypass Keystone authentication and retrieve all information about any Node registered with Ironic, if they knew (or were able to guess) the MAC address of a network card belonging to that Node, by sending a crafted POST request to the /v1/drivers/$DRIVER_NAME/vendor_passthru resource. Ironic's policy.json configuration is now respected when responding to this request such that, if passwords should be masked for other requests, they are also masked for this request. ironic-10.1.1/releasenotes/notes/rely-on-standalone-ports-supported-8153e1135787828b.yaml0000666000175100017510000000227613243617464030463 0ustar zuulzuul00000000000000--- other: - | Some combinations of port group protocols and hardware might not support falling back to single interface mode. If a static port group was created under such circumstances (where ``portgroup.standalone_ports_supported = False``), additional restrictions apply to such ports and port groups, for example such ports will not support booting over PXE. Certain restrictions are imposed on values of port properties for ports belonging to a port group: * ``port.pxe_enabled`` cannot be set to True if the port is a member of a port group with portgroup.standalone_ports_supported already set to False. * ``portgroup.standalone_ports_supported`` cannot be set to False on a port group if at least one port in that port group has ``port.pxe_enabled=True`` * ``port.extra.vif_port_id`` cannot be set on a port that is a member of a port group with ``portgroup.standalone_ports_supported=False`` as setting it means that we using port in single interface mode. * ``portgroup.standalone_ports_supported`` cannot be set to False on a port group if it has at least one port with ``port.extra.vif_port_id`` set. ironic-10.1.1/releasenotes/notes/fix-api-node-name-updates-f3813295472795be.yaml0000666000175100017510000000045013243617464026475 0ustar zuulzuul00000000000000--- fixes: - Remove the possibility to set incorrect node name by specifying multiple add/replace operations in patch request. Since this version, all the values specified in the patch for name are checked, in order to conform to JSON PATCH RFC https://tools.ietf.org/html/rfc6902. ironic-10.1.1/releasenotes/notes/build_instance_info-c7e3f12426b48965.yaml0000666000175100017510000000046013243617464025706 0ustar zuulzuul00000000000000--- deprecations: - The function ``build_instance_info_for_deploy`` is deprecated from ``ironic.drivers.modules.agent`` and will be removed in the Pike cycle. Its new home is ``ironic.drivers.modules.deploy_utils``. Out-of-tree drivers that use this function should be updated accordingly. ironic-10.1.1/releasenotes/notes/add-iscsi-portal-port-option-bde3b386f44f2a90.yaml0000666000175100017510000000045013243617464027546 0ustar zuulzuul00000000000000--- features: - IPA supported iSCSI portal port customization already. With this patch, we added new portal_port argument into agent_client.start_iscsi_target() method to pass iSCSI portal port to IPA side. And add new configuration into iscsi module as CONF.iscsi.portal_port ironic-10.1.1/releasenotes/notes/inspection-logging-e1172f549ef80b04.yaml0000666000175100017510000000022113243617464025552 0ustar zuulzuul00000000000000--- fixes: - Correctly handle unexpected exceptions during inspection. Return more detailed error message to a user and log the traceback. ironic-10.1.1/releasenotes/notes/iscsi-whole-disk-cd464d589d029b01.yaml0000666000175100017510000000033013243617464025132 0ustar zuulzuul00000000000000--- fixes: - | No longer validates requested root partition size for whole-disk images using ``iscsi`` deploy interface, see `bug 1742451 `_ for details. ironic-10.1.1/releasenotes/notes/rolling-upgrades-ccad5159ca3cedbe.yaml0000666000175100017510000000026713243617464025673 0ustar zuulzuul00000000000000--- features: - Adds support for rolling upgrades, starting from upgrading Ocata to Pike. For details, see http://docs.openstack.org/ironic/latest/admin/upgrade-guide.html. ironic-10.1.1/releasenotes/notes/check_protocol_for_ironic_api-32f35c93a140d3ae.yaml0000666000175100017510000000065713243617464030074 0ustar zuulzuul00000000000000--- fixes: - A ``[conductor]/api_url`` value specified in the configuration file that does not start with either ``https://`` or ``http://`` is no longer allowed. An incorrect value led to deployment failure on ironic-python-agent side. This misconfiguration will now be detected during ironic-conductor and ironic-api startup. An exception will be raised and an error about the invalid value will be logged. ironic-10.1.1/releasenotes/notes/clear-target-stable-states-4545602d7aed9898.yaml0000666000175100017510000000023713243617464027045 0ustar zuulzuul00000000000000--- fixes: - Ensure node's target_provision_state is cleared when the node is moved to a stable state, indicating that the state transition is done. ironic-10.1.1/releasenotes/notes/bug-1672457-563d5354b41b060e.yaml0000666000175100017510000000012013243617464023271 0ustar zuulzuul00000000000000--- fixes: - Fixed a bug that was causing an increase in CPU usage over time. ironic-10.1.1/releasenotes/notes/ipxe-dhcp-b799bc326cd2529a.yaml0000666000175100017510000000024313243617464023724 0ustar zuulzuul00000000000000--- fixes: - Remove "dhcp" command from the default iPXE script. It is redundant, and may even break booting when the provisioning NIC is not the first one. ironic-10.1.1/releasenotes/notes/agent-wol-driver-4116f64907d0db9c.yaml0000666000175100017510000000020113243617464025140 0ustar zuulzuul00000000000000--- features: - Adds an `agent_wol` driver that combines the Agent deploy interface with the Wake-On-LAN power driver. ironic-10.1.1/releasenotes/notes/ipa-streams-raw-images-1010327b0dad763c.yaml0000666000175100017510000000122313243617464026210 0ustar zuulzuul00000000000000--- features: - The Agent deploy driver now streams raw images directly to disk (instead of staging in memory) by default. upgrade: - The Agent deploy driver now streams raw images directly to disk (instead of staging in memory) by default; this can be turned off by setting the [agent]stream_raw_images configuration option to False. Streaming may be undesirable if the disk the image is being written is significantly slower than the network. fixes: - Because the agent deploy driver now streams raw images directly to disk, images larger than the RAM available to the deploy ramdisk will no longer fail to deploy. ironic-10.1.1/releasenotes/notes/glance-v2-83b04fec247cd22f.yaml0000666000175100017510000000050713243617464023674 0ustar zuulzuul00000000000000--- upgrade: - | Ironic now uses only the Image Service (glance) v2 API by default. Use of the deprecated v1 API for certain basic tasks can still be enabled by setting ``[glance]/glance_api_version`` to ``1``. This option, however, does not affect temporary URL generation, as it always requires the v2 API. ironic-10.1.1/releasenotes/notes/oneview-inspection-interface-c2d6902bbeca0501.yaml0000666000175100017510000000011713243617464027656 0ustar zuulzuul00000000000000--- features: - Adds in-band inspection interface usable by OneView drivers. ironic-10.1.1/releasenotes/notes/add-error-check-ipmitool-reboot-ca7823202c5ab71d.yaml0000666000175100017510000000022713243617464030077 0ustar zuulzuul00000000000000--- fixes: - Adds a missing error check into ``ipmitool`` power driver's reboot method so that the reboot can fail properly if power off failed. ironic-10.1.1/releasenotes/notes/remove-clean-nodes-38cfa633ca518f99.yaml0000666000175100017510000000024213243617464025533 0ustar zuulzuul00000000000000--- upgrade: - Remove the deprecated "[conductor]/clean_nodes" option. Configuration files should instead use the "[conductor]/automated_clean" option. ironic-10.1.1/releasenotes/notes/default-swift_account-b008d08e85bdf154.yaml0000666000175100017510000000135413243617464026332 0ustar zuulzuul00000000000000features: - | If the ``[glance]swift_account`` option is not set, the default value is now calculated based on the ID of the project used to access the object store. Previously this option was required. This change does not affect using RadosGW as an object store backend. - | If the ``[glance]swift_temp_url_key`` option is not set, ironic now tries to fetch the key from the project used to access swift (often called ``service``). This change does not affect using RadosGW as an object store backend. - | If the ``[glance]swift_endpoint_url`` option is not set, ironic now tries to fetch the Object Store service URL from the service catalog. The ``/v1/AUTH_*`` suffix is stripped, if present. ironic-10.1.1/releasenotes/notes/add-node-resource-class-c31e26df4196293e.yaml0000666000175100017510000000101313243617464026362 0ustar zuulzuul00000000000000--- features: - Adds a ``resource_class`` field to the node resource, which will be used by Nova to define which nodes may quantitatively match a Nova flavor. Operators should populate this accordingly before deploying the Ocata version of Nova. upgrade: - Adds a ``resource_class`` field to the node resource, which will be used by Nova to define which nodes may quantitatively match a Nova flavor. Operators should populate this accordingly before deploying the Ocata version of Nova. ironic-10.1.1/releasenotes/notes/fix-ipxe-template-for-whole-disk-image-943da0311ca7aeb5.yaml0000666000175100017510000000024313243617464031352 0ustar zuulzuul00000000000000--- fixes: - Fixes an issue with the provided iPXE template where whole disk images could not be booted. See https://bugs.launchpad.net/ironic/+bug/1524403. ironic-10.1.1/releasenotes/notes/node-traits-2d950b62eea24491.yaml0000666000175100017510000000202213243617464024201 0ustar zuulzuul00000000000000--- features: - | Adds a ``traits`` field to the node resource, which will be used by the Compute service to define which nodes may match a Compute flavor using qualitative attributes. The following new endpoints have been added to the Bare Metal REST API in version 1.37: * ``GET /v1/nodes//traits`` lists the traits for a node. * ``PUT /v1/nodes//traits`` sets all traits for a node. * ``PUT /v1/nodes//traits/`` adds a trait to a node. * ``DELETE /v1/nodes//traits`` removes all traits from a node. * ``DELETE /v1/nodes//traits/`` removes a trait from a node. A node's traits are also included in the following node query and list responses: * ``GET /v1/nodes/`` * ``GET /v1/nodes/detail`` * ``GET /v1/nodes?fields=traits`` Traits cannot be specified on node creation, nor can they be updated via a ``PATCH`` request on the node. ironic-10.1.1/releasenotes/notes/node-save-internal-info-c5cc8f56f1d0dab0.yaml0000666000175100017510000000031513243617464026673 0ustar zuulzuul00000000000000--- fixes: - | Fixes an issue where some internal information for a node was not being saved to the database. See `bug 1679297 `_ for details. ironic-10.1.1/releasenotes/notes/no-more-legacy-auth-eeb32f907d0ab5de.yaml0000666000175100017510000000060413243617464026030 0ustar zuulzuul00000000000000--- upgrade: - | Ironic no longer falls back to loading authentication configuration options for accessing other services from the ``[keystone_authtoken]`` section. As a result, the following configuration sections now must contain proper authentication options for appropriate services: - glance - neutron - swift - inspector - service_catalog ironic-10.1.1/releasenotes/notes/xenserver-ssh-driver-398084fe91ac56f1.yaml0000666000175100017510000000011613243617464026075 0ustar zuulzuul00000000000000--- features: - Adds support to the SSH power driver for XenServer VMs. ironic-10.1.1/releasenotes/notes/hctl-root-device-hints-0cab86673bc4a924.yaml0000666000175100017510000000020013243617464026317 0ustar zuulzuul00000000000000--- features: - Add ``hctl`` to root device hints. HCTL is the SCSI address and stands for Host, Channel, Target and Lun. ironic-10.1.1/releasenotes/notes/inject-nmi-dacd692b1f259a30.yaml0000666000175100017510000000043413243617464024147 0ustar zuulzuul00000000000000--- features: - Add support for the injection of Non-Masking Interrupts (NMI) for a node in REST API version 1.29. This feature can be used for hardware diagnostics, and actual support depends on the driver. In 7.0.0, this is available in the ipmitool and iRMC drivers. ironic-10.1.1/releasenotes/notes/ipxe_timeout_parameter-03fc3c76c520fac2.yaml0000666000175100017510000000016713243617464026663 0ustar zuulzuul00000000000000--- features: - Add the ability to adjust ipxe timeout during image downloading, default is still unlimited (0). ironic-10.1.1/releasenotes/notes/update-irmc-set-boot-device-fd50d9dce42aaa89.yaml0000666000175100017510000000027313243617464027464 0ustar zuulzuul00000000000000--- fixes: - This forces iRMC vmedia boot from remotely connected (redirected) CD/DVD instead of default CD/DVD. See https://bugs.launchpad.net/ironic/+bug/1561852 for details. ironic-10.1.1/releasenotes/notes/fix-noop-net-vif-list-a3d8ecee29097662.yaml0000666000175100017510000000023113243617464026124 0ustar zuulzuul00000000000000--- fixes: - | Fixes an issue with the 'noop' network interface where listing the VIFs for a node fails with a HTTP 500 Internal Server Error. ironic-10.1.1/releasenotes/notes/pxe-takeover-d8f14bcb60e5b121.yaml0000666000175100017510000000041213243617464024512 0ustar zuulzuul00000000000000--- fixes: - | Drivers using the ``PXEBoot`` boot interface now correctly support node take-over for netboot-ed nodes in ``ACTIVE`` state. During take-over, the PXE environment is first re-created before attempting to switch it to "service mode". ironic-10.1.1/releasenotes/notes/node-credentials-cleaning-b1903f49ffeba029.yaml0000666000175100017510000000025613243617464027121 0ustar zuulzuul00000000000000--- security: - | Sensitive information is now removed from a node's ``driver_info`` and ``instance_info`` fields before sending it to the ramdisk during cleaning. ironic-10.1.1/releasenotes/notes/oneview-agent-mixin-removal-b7277e8f20df5ef2.yaml0000666000175100017510000000031013243617464027460 0ustar zuulzuul00000000000000--- features: - | The OneView drivers now retain the next boot device in node's internal info when setting a boot device is requested. It is applied on the node when it is power cycled. ironic-10.1.1/releasenotes/notes/drac-migrate-to-dracclient-2bd8a6d1dd3fdc69.yaml0000666000175100017510000000126613243617464027354 0ustar zuulzuul00000000000000--- fixes: - DRAC driver migrated from ``pywsman`` to ``python-dracclient`` fixing the driver lockup issue caused by the python interpreter not handling signals when execution handed to the c library. - Fixes an issue with setting the boot device multiple times without a reboot in the DRAC driver by setting the boot device only before power management operations. upgrade: - Dependency for DRAC driver changed from ``pywsman`` to ``python-dracclient`` with version >= 0.0.5. Exceptions thrown by the driver and return values of the ``set_bios_config``, ``commit_bios_config`` and ``abandon_bios_config`` methods changed on the vendor-passthru interface. ironic-10.1.1/releasenotes/notes/automated_clean_config-0170c95ae210f953.yaml0000666000175100017510000000027013243617464026341 0ustar zuulzuul00000000000000--- deprecations: - The [conductor]/clean_nodes config is deprecated and will be removed in the Newton cycle. It has been replaced by the [conductor]/automated_clean config. ironic-10.1.1/releasenotes/notes/fix-virtualbox-localboot-not-working-558a3dec72b5116b.yaml0000666000175100017510000000060513243617464031247 0ustar zuulzuul00000000000000--- fixes: - Fixed a VirtualBox issue that Ironic fails to set VirtualBox VM's boot device when it is powered on. This bug causes two problems 1. VirtualBox cannot deploy VMs in local boot mode. 2. Ironic fails to set boot device when VirtualBox VMs is powered on and also fails to get the correct boot device from Ironic API call when VMs is powered on. ironic-10.1.1/releasenotes/notes/notify-node-storage-interface-7fd07ee7ee71cd22.yaml0000666000175100017510000000113413243617464030037 0ustar zuulzuul00000000000000--- features: - | Adds ``storage_interface`` field to the node-related notifications: * ``baremetal.node.create.*`` (new payload version 1.2) * ``baremetal.node.update.*`` (new payload version 1.2) * ``baremetal.node.delete.*`` (new payload version 1.2) * ``baremetal.node.maintenance.*`` (new payload version 1.4) * ``baremetal.node.console.*`` (new payload version 1.4) * ``baremetal.node.power_set.*`` (new payload version 1.4) * ``baremetal.node.power_state_corrected.*`` (new payload version 1.4) * ``baremetal.node.provision_set.*`` (new payload version 1.4) ironic-10.1.1/releasenotes/notes/multiple-workers-for-send-sensor-data-89d29c12da30ec54.yaml0000666000175100017510000000073313243617464031317 0ustar zuulzuul00000000000000--- features: - Adds new configuration option ``[conductor]/send_sensor_data_workers`` to allow concurrent sending of sensor data using the specified number of green threads. The ``[conductor]/wait_timeout_for_send_sensor_data`` configuration option is the time to wait for all spawned green threads before running the periodic task again. upgrade: - Increases the default number of workers for the ``send_sensor_data`` periodic task from 1 to 4. ironic-10.1.1/releasenotes/notes/fix-cleaning-spawn-error-60b60281f3be51c2.yaml0000666000175100017510000000022713243617464026565 0ustar zuulzuul00000000000000--- fixes: - Fix issues with error handling when spawning a new thread to continue cleaning. See https://bugs.launchpad.net/ironic/+bug/1539118. ironic-10.1.1/releasenotes/notes/deprecate-glance-url-scheme-ceff3008cf9cf590.yaml0000666000175100017510000000046113243617464027435 0ustar zuulzuul00000000000000--- other: - | Support for parsing the glance API endpoint from the full REST path to a glance image was removed as it was not working anyway. The image service API is now always resolved from keystone catalog or via the options in the ``[glance]`` section in ironic configuration file. ironic-10.1.1/releasenotes/notes/support-root-device-hints-with-operators-96cf34fa37b5b2e8.yaml0000666000175100017510000000063313243617464032173 0ustar zuulzuul00000000000000--- features: - Adds support for using operators with the root device hints mechanism. The supported operators are, ``=``, ``==``, ``!=``, ``>=``, ``<=``, ``>``, ``<``, ``s==``, ``s!=``, ``s>=``, ``s>``, ``s<=``, ``s<``, ````, ```` and ````. See http://docs.openstack.org/project-install-guide/baremetal/draft/advanced.html#specifying-the-disk-for-deployment-root-device-hints ironic-10.1.1/releasenotes/notes/logging-keystoneauth-9db7e56c54c2473d.yaml0000666000175100017510000000031113243617464026212 0ustar zuulzuul00000000000000--- other: - Do not show DEBUG logging from keystoneauth and keystonemiddleware by default. - Log eventlet.wsgi.server events with a proper logger name and ignore DEBUG logging by default. ironic-10.1.1/releasenotes/notes/add-ssl-support-4547801eedba5942.yaml0000666000175100017510000000022013243617464025014 0ustar zuulzuul00000000000000--- features: - The ironic-api service now supports SSL when running the service directly (as opposed to behind mod_wsgi or similar). ironic-10.1.1/releasenotes/notes/bug-1592335-7c5835868fe364ea.yaml0000666000175100017510000000024113243617464023405 0ustar zuulzuul00000000000000--- fixes: - A node using the ``agent_ilo`` or ``iscsi_ilo`` driver now has its ``driver_info/ilo_deploy_iso`` field validated during node validation. ironic-10.1.1/releasenotes/notes/pass-region-to-swiftclient-c8c8bf1020f62ebc.yaml0000666000175100017510000000034413243617464027371 0ustar zuulzuul00000000000000--- fixes: - Fixes a bug where the keystone_authtoken/region_name wasn't passed to Swift when instantiating its client, in a multi-region environment this is needed so the client can choose the correct swift endpoint. ironic-10.1.1/releasenotes/notes/lookup-heartbeat-f9772521d12a0549.yaml0000666000175100017510000000165113243617464025071 0ustar zuulzuul00000000000000--- features: - New API endpoint for deploy ramdisk lookup ``/v1/lookup``. This endpoint is not authenticated to allow ramdisks to access it without passing the credentials to them. - New API endpoint for deploy ramdisk heartbeat ``/v1/heartbeat/``. This endpoint is not authenticated to allow ramdisks to access it without passing the credentials to them. deprecations: - The configuration option ``[agent]/heartbeat_timeout`` was renamed to ``[api]/ramdisk_heartbeat_timeout``. The old variant is deprecated. upgrade: - A new configuration option ``[api]/restrict_lookup`` is added, which restricts the lookup API (normally only used by ramdisks) to only work when the node is in specific states used by the ramdisk, and defaults to True. Operators that need this endpoint to work in any state may set this to False, though this is insecure and should not be used in normal operation. ironic-10.1.1/releasenotes/notes/non-persistent-boot-5e3a0cd78e9dc91b.yaml0000666000175100017510000000052313243617464026135 0ustar zuulzuul00000000000000fixes: - | Fixes a bug which caused boot device changes to be persistent in places where they did not need to be during cleaning and deployment phases, due to the default behavior of PXE interface forcing a persistent change. For more information, see `bug 1701721 `_. ironic-10.1.1/releasenotes/notes/default_boot_option-f22c01f976bc2de7.yaml0000666000175100017510000000060013243617464026153 0ustar zuulzuul00000000000000--- features: - Adds new option ``[deploy]/default_boot_option`` for setting the default boot option when no explicit boot option is requested via capabilities. upgrade: - A future release will change the default value of ``[deploy]/default_boot_option`` from "netboot" to "local". To avoid disruptions, it is recommended to set an explicit value for this option. ironic-10.1.1/releasenotes/notes/active-node-creation-a41c9869c966c82b.yaml0000666000175100017510000000145313243617464026002 0ustar zuulzuul00000000000000--- features: - Addition of the provision state target verb of ``adopt`` which allows an operator to move a node into an ``active`` state from ``manageable`` state, without performing a deployment operation on the node. This can be used to represent nodes that have been previously deployed by other means that will now be managed by ironic and be later released to the available hardware pool. other: - When a node is enrolled into ironic, upon transition to the ``manageable`` state, the current power state of the node is recorded. Once the node is adopted and in an ``active`` state, that recorded power state will be enforced by ironic unless an operator changes the power state in ironic. This was the default behavior of ironic prior to the adoption feature. ironic-10.1.1/releasenotes/notes/fake-noop-bebc43983eb801d1.yaml0000666000175100017510000000033513243617464023773 0ustar zuulzuul00000000000000--- fixes: - | Adds missed noop implementations (e.g. ``no-inspect``) to the ``fake-hardware`` hardware type. This fixes enabling this hardware type without enabling all (even optional) ``fake`` interfaces. ironic-10.1.1/releasenotes/notes/only_default_flat_network_if_enabled-b5c6ea415239a53c.yaml0000666000175100017510000000063513243617464031431 0ustar zuulzuul00000000000000--- fixes: - | Fixes a bug seen when no ``default_network_interface`` is set, because the conductor tries use the ``flat`` network interface instead even if it is not included in the conductor's ``enabled_network_interfaces`` config option. Resulting in `Failed to register hardware types` error. See `bug 1744332 `_ for more information.ironic-10.1.1/releasenotes/notes/bmc_reset-warm-9396ac444cafd734.yaml0000666000175100017510000000021313243617464024751 0ustar zuulzuul00000000000000--- fixes: - Fix a problem that caused the bmc_reset() vendor passthru method from the IPMI drivers to be always executed as "warm". ironic-10.1.1/releasenotes/notes/fix-provisioning-port-cleanup-79ee7930ca206c42.yaml0000666000175100017510000000057713243617464027713 0ustar zuulzuul00000000000000--- fixes: - | Fixes an issue whereby in certain deployment failure scenarios a node's provisioning ports are not deleted. The issue would typically have been masked by nova, which deletes all ports with a device ID matching the instance's UUID during instance termination. See `bug 1732412 `_ for details. ironic-10.1.1/releasenotes/notes/collect-deployment-logs-2ec1634847c3f6a5.yaml0000666000175100017510000000144713243617464026535 0ustar zuulzuul00000000000000--- features: - | Adds support for collecting deployment logs from the IPA ramdisk. Five new configuration options were added: * ``[agent]/deploy_logs_collect`` * ``[agent]/deploy_logs_storage_backend`` * ``[agent]/deploy_logs_local_path`` * ``[agent]/deploy_logs_swift_container`` * ``[agent]/deploy_logs_swift_days_to_expire``. upgrade: - Collecting logs on deploy failure is enabled by default and the logs will be saved to the local disk at the location specified by the configuration option ``[agent]/deploy_logs_local_path`` (by default, ``/var/log/ironic/deploy``). Operators upgrading may want to disable this feature, enable some form of rotation for the logs or change the configuration to store the logs in Swift to avoid disk space problems. ironic-10.1.1/releasenotes/notes/inspection-agent-drivers-cad619ec8a4874b1.yaml0000666000175100017510000000014013243617464027040 0ustar zuulzuul00000000000000--- features: - Adds inspection support for the `agent_ipmitool` and `agent_ssh` drivers. ironic-10.1.1/releasenotes/notes/bug-1745630-d28c8de54cebd329.yaml0000666000175100017510000000054713243617464023620 0ustar zuulzuul00000000000000--- fixes: - | Fixes a bug to get a node stuck in ``deploying`` state when the size of the configdrive exceeds the limitation of the database. In MySQL, the limitation is about 64KiB. With this fix, the provision state gets ``deploy failed`` in this case. See `bug 1745630 `_ for details. ././@LongLink0000000000000000000000000000015200000000000011213 Lustar 00000000000000ironic-10.1.1/releasenotes/notes/correct-api-version-check-conditional-for-nodename-439bebc02fb5493d.yamlironic-10.1.1/releasenotes/notes/correct-api-version-check-conditional-for-nodename-439bebc02fb5493d0000666000175100017510000000030513243617464032772 0ustar zuulzuul00000000000000--- fixes: - Correct api version check conditional for node.name to address an issue that we could set node name to '' using API version lower than 1.5, where node names were introduced. ironic-10.1.1/releasenotes/notes/tempest_plugin_removal-009f9ce8456b16fe.yaml0000666000175100017510000000063413243617464026641 0ustar zuulzuul00000000000000--- other: - | The tempest plugin code that was in ``ironic_tempest_plugin/`` has been removed. Tempest plugin code has been migrated to the project `openstack/ironic-tempest-plugin `_. This was an OpenStack wide `goal for the Queens cycle `_. ironic-10.1.1/releasenotes/notes/improve-conductor-shutdown-42687d8b9dac4054.yaml0000666000175100017510000000020013243617464027306 0ustar zuulzuul00000000000000--- fixes: - Shutdown of conductor process should take less time, as we do not wait for completion of all periodic tasks. ironic-10.1.1/releasenotes/notes/fake_soft_power-32683a848a989fc2.yaml0000666000175100017510000000023213243617464025072 0ustar zuulzuul00000000000000--- other: - | All ``fake`` classic drivers now implement fake soft power actions. The ``fake_soft_power`` driver is now identical to ``fake``. ironic-10.1.1/releasenotes/notes/update-proliantutils-version-20ebcc22dc2df527.yaml0000666000175100017510000000031113243617464030032 0ustar zuulzuul00000000000000--- upgrade: - | Updates required proliantutils version for iLO drivers to 2.2.1. This version has support for HPSUM firmware update and matches requirements to meet global-requirements. ironic-10.1.1/releasenotes/notes/ilo-boot-from-iscsi-volume-41e8d510979c5037.yaml0000666000175100017510000000032713243617464026732 0ustar zuulzuul00000000000000--- features: - The ``ilo-pxe`` and ``ilo-virtual-media`` boot interfaces now support firmware-based booting from iSCSI volume in UEFI boot mode. Requires **proliantutils** library version 2.5.0 or newer. ironic-10.1.1/releasenotes/notes/ilo-erase-device-priority-config-509661955a11c28e.yaml0000666000175100017510000000032713243617464030063 0ustar zuulzuul00000000000000--- deprecations: - The ``[ilo]/clean_priority_erase_devices`` configuration option is deprecated and will be removed in the Ocata cycle. Please use the ``[deploy]/erase_devices_priority`` option instead. ironic-10.1.1/releasenotes/notes/iscsi-inband-cleaning-bff87aac16e5d488.yaml0000666000175100017510000000021213243617464026326 0ustar zuulzuul00000000000000--- features: - Adds support for in-band clean steps in the iSCSI deploy driver, when using ironic-python-agent as the ramdisk. ironic-10.1.1/releasenotes/notes/add-secure-boot-suport-irmc-9509f3735df2aa5d.yaml0000666000175100017510000000042313243617464027303 0ustar zuulzuul00000000000000--- features: - | Adds support to provision an instance in secure boot mode for ``irmc-virtual-media`` boot interface. For details, see the `iRMC driver documentation `_.ironic-10.1.1/releasenotes/notes/snmp-hardware-type-ee3d471cf5c596f4.yaml0000666000175100017510000000036113243617464025662 0ustar zuulzuul00000000000000--- features: - | Adds a new hardware type ``snmp`` for SNMP powered systems. It supports the following driver interfaces: * boot: ``pxe`` * deploy: ``iscsi``, ``direct`` * power: ``snmp`` * management: ``fake`` ironic-10.1.1/releasenotes/notes/fix-agent-clean-up-9a25deb85bc53d9b.yaml0000666000175100017510000000023113243617464025564 0ustar zuulzuul00000000000000--- fixes: - | Fixes an issue wherein agent based deploy do not call clean up the instance related configurations done on the Ironic node. ironic-10.1.1/releasenotes/notes/glance-keystone-dd30b884f07f83fb.yaml0000666000175100017510000000075213243617464025222 0ustar zuulzuul00000000000000--- upgrade: - | The configuration option ``[glance]glance_host`` is now empty by default. If neither it nor ``[glance]glance_api_servers`` are provided, ironic will now try fetching the Image service endpoint from the service catalog. deprecations: - | The configuration options ``[glance]glance_host``, ``[glance]glance_port`` and ``[glance]glance_protocol`` are deprecated in favor of either using ``[glance]glance_api_servers`` or using the service catalog. ironic-10.1.1/releasenotes/notes/resource-classes-1bf903547236a473.yaml0000666000175100017510000000141513243617464025101 0ustar zuulzuul00000000000000--- upgrade: - | Due to upcoming changes in the way Nova schedules bare metal nodes, all nodes in a deployment using Nova have to get the ``resource_class`` field populated before the upgrade. See `enrollment documentation `_ and `flavor configuration documentation `_ for details. Once you've migrated your flavors to resource classes, you should unset the deprecated ``use_baremetal_filters`` option in the Compute service configuration. Otherwise you'll be using the filters incompatible with scheduling based on resource classes. ironic-10.1.1/releasenotes/notes/bug-1696296-a972c8d879b98940.yaml0000666000175100017510000000072113243617464023352 0ustar zuulzuul00000000000000--- fixes: - | Fixes an issue where an ironic-conductor service was deemed dead because the service could not report its heartbeat due to the database connection experiencing an unexpected failure. Full tracebacks of these exceptions are now logged, and if the database connection recovers in a reasonable amount of time the service will still be available. See `bug 1696296 `_ for details. ironic-10.1.1/releasenotes/notes/radosgw-temp-url-b04aac50698b4461.yaml0000666000175100017510000000021313243617464025154 0ustar zuulzuul00000000000000--- features: - Adds support for using Glance with a Ceph backend via the RADOS Gateway Swift API, with the Agent deploy driver. ironic-10.1.1/releasenotes/notes/add-id-and-uuid-filtering-to-sqalchemy-api.yaml0000666000175100017510000000027313243617464027606 0ustar zuulzuul00000000000000--- fixes: - Fixes `bug 1749755 `_ causing timeouts to not work properly because an unsupported sqalchemy filter was being used. ironic-10.1.1/releasenotes/notes/duplicated-driver-entry-775370ad84736206.yaml0000666000175100017510000000025213243617464026312 0ustar zuulzuul00000000000000--- fixes: - Fixes a problem which causes the conductor to error out on startup in case there's a duplicated entry in the enabled_drivers configuration option. ironic-10.1.1/releasenotes/notes/snmp-outlet-validate-ffbe8e6687172efc.yaml0000666000175100017510000000011413243617464026274 0ustar zuulzuul00000000000000--- fixes: - Adds validation of ``snmp_outlet`` parameter to SNMP driver. ironic-10.1.1/releasenotes/notes/shred-final-overwrite-with-zeros-50b5ba5b19c0da27.yaml0000666000175100017510000000136613243617464030437 0ustar zuulzuul00000000000000--- features: - A new configuration option, `shred_final_overwrite_with_zeros` is now available. This option controls the final overwrite with zeros done on all block devices for a node under cleaning. This feature was previously always enabled and not configurable. This option is only used when a block device could not be ATA Secure Erased. deprecations: - The [deploy]/erase_devices_iterations config is deprecated and will be removed in the Ocata cycle. It has been replaced by the [deploy]/shred_random_overwrite_iterations config. This configuration option controls the number of times block devices are overwritten with random data. This option is only used when a block device could not be ATA Secure Erased. ironic-10.1.1/releasenotes/notes/no-root-device-as-kernel-param-5e5326acae7b77a4.yaml0000666000175100017510000000102413243617464027723 0ustar zuulzuul00000000000000--- upgrade: - Ironic no longer passes ``root_device`` as kernel parameter via boot config files. Passing root device hints to Ironic Python Agent (IPA) as kernel parameters was deprecated in Newton release. As a consequence, using root device hints with Ironic as of Ocata release will not be possible when deploying nodes with the help of ramdisks based on IPA as of Mitaka release. Operators relying on root device hints functionality are advised to update their IPA-based Ironic deploy images. ironic-10.1.1/releasenotes/notes/fix-disk-identifier-overwrite-42b33a5a0f7742d8.yaml0000666000175100017510000000041713243617464027636 0ustar zuulzuul00000000000000--- fixes: - Fix handling of whole disk images with disk identifier 0x00000000. Instances failed to boot as the identifier in the boot config was overwritten during config drive creation. See `bug 1685093 `_. ironic-10.1.1/releasenotes/notes/update-live-port-ee3fa9b77f5d0cf7.yaml0000666000175100017510000000041613243617464025475 0ustar zuulzuul00000000000000--- fixes: - Fixed updating a MAC on a port for active instances in maintenance mode (previously returned HTTP 500). - Return HTTP 400 for requests to update a MAC on a port for an active instance without maintenance mode set (previously returned HTTP 500). ironic-10.1.1/releasenotes/notes/notimplementederror-misspell-276a181afd652cf6.yaml0000666000175100017510000000042113243617464027761 0ustar zuulzuul00000000000000--- fixes: - In conductor/rpcapi.py, object_backport_version(), object_action() and object_class_action_versions() misspell NotImplementedError with NotImplemented which returns nothing useful to users. See https://bugs.launchpad.net/ironic/+bug/1524163. ironic-10.1.1/releasenotes/notes/irmc-boot-interface-8c2e26affd1ebfc4.yaml0000666000175100017510000000010413243617464026163 0ustar zuulzuul00000000000000--- other: - iRMC drivers are now based on the new BootInterface. ironic-10.1.1/releasenotes/notes/no-ssh-drivers-6ee5ff4c3ecdd3fb.yaml0000666000175100017510000000057413243617464025316 0ustar zuulzuul00000000000000--- upgrade: - | SSH-based power and management driver interfaces were removed from ironic. The drivers ``pxe_ssh``, ``agent_ssh`` and ``fake_ssh`` are no longer available. Operators are required to ensure that these drivers are not used or enabled (in ``[DEFAULT]enabled_drivers`` configuration file option) in their ironic installation before upgrade. ironic-10.1.1/releasenotes/notes/agent-takeover-60f27cef21ebfb48.yaml0000666000175100017510000000020013243617464025104 0ustar zuulzuul00000000000000--- fixes: - Drivers using the ``AgentDeploy`` interface now correctly support take-over for ``ACTIVE`` netboot-ed nodes. ironic-10.1.1/releasenotes/notes/fix-bug-1675529-479357c217819420.yaml0000666000175100017510000000176013243617464023674 0ustar zuulzuul00000000000000--- deprecations: - | Configuration option ``[ipmi]/retry_timeout`` is deprecated in favor of these new options: * ``[ipmi]/command_retry_timeout``: timeout value to wait for an IPMI command to complete (be acknowledged by the baremetal node) * ``[conductor]/power_state_change_timeout``: timeout value to wait for a power operation to complete, so that the baremetal node is in the desired new power state fixes: - | Prevents the IPMI driver from needlessly checking status of the baremetal node if a power change action fails. Additionally, stops retrying power actions and power status polls on receipt of a non-retryable error from ipmitool. For more information, see `bug 1675529 `_. A new configuration option ``[conductor]/power_state_change_timeout`` can be used to specify how many seconds to wait for a baremetal node to change the power state when a power action is requested. ironic-10.1.1/releasenotes/notes/bug-1626453-e8df46aa5db6dd5a.yaml0000666000175100017510000000033513243617464023747 0ustar zuulzuul00000000000000--- fixes: - Fixes an issue where setting a boot device as persistent does not work when ``ipmi_force_boot_device`` is set to ``True``. For more information, see https://bugs.launchpad.net/ironic/+bug/1626453. ironic-10.1.1/releasenotes/notes/fix-mac-address-update-with-contrail-b1e1b725cc0829c2.yaml0000666000175100017510000000032713243617464031041 0ustar zuulzuul00000000000000--- fixes: - Fixes `an issue `_ where the update of a MAC address failed for ports that were bound (for example, when using the 'contrail' neutron backend). ironic-10.1.1/releasenotes/notes/ansible-deploy-15da234580ca0c30.yaml0000666000175100017510000000250513243617464024643 0ustar zuulzuul00000000000000--- features: - | Adds a new ``ansible`` deploy interface. It targets mostly undercloud use-case by allowing greater customization of provisioning process. This new deploy interface is usable only with hardware types. It is set as supported for a ``generic`` hardware type and all its subclasses, but must be explicitly enabled in the ``[DEFAULT]enabled_deploy_interfaces`` configuration file option to actually allow setting nodes to use it. For migration from the ``staging-ansible`` interface from the ``ironic-staging-drivers`` project to this ``ansible`` interface, operators have to consider the following differences: - Callback-less operation is not supported. - Node's ``driver_info`` fields ``ansible_deploy_username`` and ``ansible_deploy_key_file`` are deprecated and will be removed in the Rocky release. Instead, please use ``ansible_username`` and ``ansible_key_file`` respectively. - Base path for playbooks can be defined in the node's ``driver_info['ansible_playbooks_path']`` field. The default is the value of the ``[ansible]/playbooks_path`` option from the ironic configuration file. - Default playbooks for actions and cleaning steps file can be set in ironic configuration file as various ``[ansible]/default_*`` options. ironic-10.1.1/releasenotes/notes/fix-swift-ssl-options-d93d653dcd404960.yaml0000666000175100017510000000034713243617464026177 0ustar zuulzuul00000000000000--- fixes: - | Fixes a bug when SSL-related options in ``[swift]`` section of ironic configuration file were ignored when performing API requests to Swift. See https://launchpad.net/bugs/1736158 for more information. ironic-10.1.1/releasenotes/notes/sum-based-update-firmware-manual-clean-step-e69ade488060cf27.yaml0000666000175100017510000000044713243617464032334 0ustar zuulzuul00000000000000--- features: - iLO drivers now support firmware update based on `Smart Update Manager `_ (SUM) as an in-band manual cleaning step ``update_firmware_sum`` for all the hardware components. ironic-10.1.1/releasenotes/notes/fix-oneview-periodics-0f535fe7a0ad83cd.yaml0000666000175100017510000000021213243617464026406 0ustar zuulzuul00000000000000--- fixes: - Fixes a bug in the OneView driver where the periodic task to check if a node is in use by OneView may end prematurely. ironic-10.1.1/releasenotes/notes/apache-multiple-workers-11d4ba52c89a13e3.yaml0000666000175100017510000000031513243617464026567 0ustar zuulzuul00000000000000--- fixes: - Fixes an issue with requests to the ironic API service sometimes timing out when running under Apache. This was due to mixing two concurrency models (for handling multiple threads). ironic-10.1.1/releasenotes/notes/fix-oneview-deploy-return-values-ab2ec6ae568d95a5.yaml0000666000175100017510000000025713243617464030553 0ustar zuulzuul00000000000000--- fixes: - Fixes an issue where the OneView deploy interface does not return the node properties and in the tear down phase does not return the state of the node. ironic-10.1.1/releasenotes/notes/reboot-do-not-power-off-if-already-1452256167d40009.yaml0000666000175100017510000000051613243617464030056 0ustar zuulzuul00000000000000--- fixes: - | Fixes a problem when rebooting a node using the ``ipmitool`` power interface could cause a deploy to fail. Now it no longer tries to power off nodes that are already off, because some BMCs will error in these cases. See `bug 1718794 `_ for details. ironic-10.1.1/releasenotes/notes/dhcp-provider-clean-dhcp-9352717903d6047e.yaml0000666000175100017510000000024113243617464026306 0ustar zuulzuul00000000000000--- other: - Adds a `clean_dhcp_opts` method to the DHCP provider base class, to give DHCP providers a method to clean up DHCP reservations if needed. ironic-10.1.1/releasenotes/notes/refactor-ironic-lib-22939896d8d46a77.yaml0000666000175100017510000000127713243617464025511 0ustar zuulzuul00000000000000--- upgrade: - | Adds new configuration [ironic_lib]root_helper, to specify the command that is prefixed to commands that are run as root. Defaults to using the rootwrap config file at /etc/ironic/rootwrap.conf. - | Moves these configuration options from [deploy] group to the new [disk_utils] group: efi_system_partition_size, dd_block_size and iscsi_verify_attempts. deprecations: - | The following configuration options have been moved to the [disk_utils] group; they are deprecated from the [deploy] group: efi_system_partition_size, dd_block_size and iscsi_verify_attempts. other: - Code related to disk partitioning was moved to ironic-lib. ironic-10.1.1/releasenotes/notes/agent_partition_image-48a03700f41a3980.yaml0000666000175100017510000000012113243617464026131 0ustar zuulzuul00000000000000--- features: - Adds support for partition images for agent based drivers. ironic-10.1.1/releasenotes/notes/fix-ipmitool-console-empty-password-a8edc5e2a1a7daf6.yaml0000666000175100017510000000014313243617464031405 0ustar zuulzuul00000000000000--- fixes: - Fixes an issue where ipmitool console did not work with an empty IPMI password. ironic-10.1.1/releasenotes/notes/default-resource-class-e11bacfb01d6841b.yaml0000666000175100017510000000033213243617464026530 0ustar zuulzuul00000000000000--- features: - | Adds new configuration option ``[DEFAULT]default_resource_class`` that specifies the resource class to use for new nodes when no resource class is provided in the node creation request. ironic-10.1.1/releasenotes/notes/oneview-timing-metrics-0b6c1b54e80eb683.yaml0000666000175100017510000000007213243617464026437 0ustar zuulzuul00000000000000--- features: - Adds timing metrics to OneView drivers. ironic-10.1.1/releasenotes/notes/remove-iscsi-deploy-ipa-mitaka-c0efa0d5c31933b6.yaml0000666000175100017510000000033613243617464030021 0ustar zuulzuul00000000000000--- upgrade: - | There is no longer any support for doing an iSCSI deploy on ironic python agent (IPA) ramdisks with versions < 1.3 (Mitaka or earlier). Please upgrade ironic python agent to a newer version. ironic-10.1.1/releasenotes/notes/ilo-do-not-power-off-non-deploying-nodes-0a3aed7c8ea3940a.yaml0000666000175100017510000000062613243617464031743 0ustar zuulzuul00000000000000--- fixes: - A bug was identified in the behavior of the iLO drivers where nodes that are not active but taking part of a conductor takeover could be powered off. In preparation for new features and functionality, that risk encountering this bug, we are limiting the deployment preparation steps to the ``deploying`` state to prevent nodes from being erroneously powered off. ironic-10.1.1/releasenotes/notes/allow-set-interface-to-node-in-available-bd6f695620c2d77f.yaml0000666000175100017510000000014313243617464031602 0ustar zuulzuul00000000000000--- features: - | Allows updating hardware interfaces on nodes in the ``available`` state. ironic-10.1.1/releasenotes/notes/remove-DEPRECATED-options-from-[agent]-7b6cce21b5f52022.yaml0000666000175100017510000000036213243617464030736 0ustar zuulzuul00000000000000--- upgrade: - | In the configuration group ``[agent]``, the following options were deprecated in the Liberty cycle and they have been removed: * ``[agent]/agent_pxe_append_params`` * ``[agent]/agent_pxe_config_template`` ironic-10.1.1/releasenotes/notes/port-list-bad-request-078512862c22118e.yaml0000666000175100017510000000036413243617464025706 0ustar zuulzuul00000000000000--- fixes: - | Fixes rare race condition which resulted in the port list API returning HTTP 400 (bad request) if some nodes were being removed in parallel. See `bug 1748893 `_ for details. ironic-10.1.1/releasenotes/notes/ipmi-cmd-for-ipmi-consoles-2e1104f22df3efcd.yaml0000666000175100017510000000014413243617464027226 0ustar zuulzuul00000000000000fixes: - Fixes a bug with incorrect base socat command, which prevented the usage of console. ironic-10.1.1/releasenotes/notes/fix-reboot-log-collection-c3e22fc166135e61.yaml0000666000175100017510000000056313243617464026743 0ustar zuulzuul00000000000000--- fixes: - | Fixes an issue where if a failure occurs during deployment, the Bare Metal service could attempt to collect logs from a node that had been powered off. This would result in a number of failed attempts to collect the logs before failing the deployment. See `bug 1732939 `_ for details. ironic-10.1.1/releasenotes/notes/deprecated-neutron-opts-2e1d9e65f00301d3.yaml0000666000175100017510000000431513243617464026523 0ustar zuulzuul00000000000000--- deprecations: - | Configuration option ``[neutron]/url`` is deprecated and will be ignored in the Rocky release. Instead, use ``[neutron]/endpoint_override`` configuration option to set specific neutron API address when automatic discovery of neutron API endpoint from keystone catalog is not desired. This option has no default value, and must be set explicitly for a stand alone deployment of ironic and neutron (when ``[neutron]/auth_type`` is set to ``none``), since the service catalog is not available in this case. Otherwise it is generally recommended to rely on keystone service catalog for service endpoint discovery. - | Configuration option ``[neutron]/url_timeout`` is deprecated and will be ignored in the Rocky release. Instead, use ``[neutron]/timeout`` configuration option. This new option has no default value and must be set explicitly to ``30`` to keep previous default behavior. - | Configuration option ``[neutron]/auth_strategy`` is deprecated and will be ignored in the Rocky release. Instead, set ``[neutron]/auth_type`` configuration option to ``none``, and provide neutron API address as ``[neutron]/endpoint_override`` configuration option. other: - | Signatures of several networking-related functions/methods have been changed to include request context as an optional keyword argument. The functions/methods in question are: - ``ironic.common.neutron.get_client`` - ``ironic.common.neutron.unbind_neutron_port`` - ``ironic.common.neutron.update_port_address`` - ``ironic.common.neutron.validate_network`` - ``ironic.common.neutron.NeutronNetworkInterfaceMixin.get_cleaning_network`` - ``ironic.common.neutron.NeutronNetworkInterfaceMixin.get_provisioning_network`` - ``ironic.dhcp.neutron.NeutronDHCPApi.update_port_dhcp_opts`` - ``ironic.dhcp.none.NeutronDHCPApi.update_port_dhcp_opts`` If you are using any of the above functions/methods in your out-of-tree ironic driver or driver interface code, you should update the code to pass an instance of ``ironic.common.context.RequestContext`` class as a ``context`` keyword argument to those functions/methods. ironic-10.1.1/releasenotes/notes/drac-missing-lookup-3ad98e918e1a852a.yaml0000666000175100017510000000021113243617464025727 0ustar zuulzuul00000000000000--- fixes: - Add missing "lookup" method to the pxe_drac driver vendor interface enabling it to be deployed using the IPA ramdisk. ironic-10.1.1/releasenotes/notes/configdrive-support-using-ceph-radosgw-8c6f7b8bede2077c.yaml0000666000175100017510000000204213243617464031725 0ustar zuulzuul00000000000000--- features: - | Adds support for storing the configdrive in `Ceph Object Gateway `_ (radosgw) instead of the OpenStack Object service (swift) using the compatible API. - | Adds support to use the radosgw authentication mechanism that relies on a user name and a password instead of an authentication token. The following options must be specified in ironic configuration file: * ``[swift]/auth_url`` * ``[swift]/username`` * ``[swift]/password`` deprecations: - The ``[conductor]/configdrive_use_swift`` and ``[glance]/temp_url_endpoint_type`` options are deprecated and will be removed in the Queens release. Use ``[deploy]/configdrive_use_object_store`` and ``[deploy]/object_store_endpoint_type`` respectively instead. upgrade: - Adds the ``[deploy]/object_store_endpoint_type`` option to specify the type of endpoint to use for instance images and configdrive storage. Allowed values are ``swift`` or ``radosgw``. The default is ``swift``. ironic-10.1.1/releasenotes/notes/add-gmr-3c9278d5d785895f.yaml0000666000175100017510000000063613243617464023254 0ustar zuulzuul00000000000000--- features: - Adds support for generating `Guru Meditation Reports `_ (GMR) for both ironic-api and ironic-conductor services. GMR provides debugging information that can be used to obtain an accurate view on the current state of the system. For example, what threads are running, what configuration parameters are in effect, and more. ironic-10.1.1/releasenotes/notes/bug-1570283-6cdc62e4ef43cb02.yaml0000666000175100017510000000016613243617464023600 0ustar zuulzuul00000000000000--- fixes: - Fixes the issue of not attaching virtual media during cleaning operation for vmedia based drivers. ironic-10.1.1/releasenotes/notes/add_standalone_ports_supported_field-4c59702a052acf38.yaml0000666000175100017510000000034513243617464031413 0ustar zuulzuul00000000000000--- features: - Add the field `standalone_ports_supported` to the port group object. This field indicates whether ports that are members of this port group can be used as stand-alone ports. The default is ``True``. ironic-10.1.1/releasenotes/notes/messaging-log-level-5f870ea69db53d26.yaml0000666000175100017510000000017013243617464025707 0ustar zuulzuul00000000000000--- fixes: - | ``DEBUG``-level logging from the ``oslo.messaging`` library is no longer displayed by default. ironic-10.1.1/releasenotes/notes/oneview-hardware-type-69bbb79da434871f.yaml0000666000175100017510000000077413243617464026310 0ustar zuulzuul00000000000000--- features: - | Adds a new hardware type ``oneview`` for HPE OneView supported servers. This hardware type supports the following driver interfaces: * boot: ``pxe`` * console: ``no-console`` * deploy: ``oneview-direct`` and ``oneview-iscsi`` (based on "direct" and "iscsi" respectively) * inspect: ``oneview`` and ``no-inspect`` * management: ``oneview`` * network: ``flat``, ``neutron`` and ``no-op`` * power: ``oneview`` * raid: ``no-raid`` and ``agent`` ././@LongLink0000000000000000000000000000015100000000000011212 Lustar 00000000000000ironic-10.1.1/releasenotes/notes/remove-deprecated-deploy-erase-devices-iterations-55680ab95cbce3e9.yamlironic-10.1.1/releasenotes/notes/remove-deprecated-deploy-erase-devices-iterations-55680ab95cbce3e9.0000666000175100017510000000036313243617464033026 0ustar zuulzuul00000000000000--- upgrade: - | The configuration option ``[deploy]/erase_devices_iterations`` was deprecated in the Newton cycle (6.0.0). It is no longer supported. Please use the option ``[deploy]/shred_random_overwrite_iterations`` instead. ironic-10.1.1/releasenotes/notes/deny-too-long-chassis-description-0690d6f67ed002d5.yaml0000666000175100017510000000017513243617464030431 0ustar zuulzuul00000000000000fixes: - The API now returns an appropriate error message when a chassis description over 255 characters is specified. ironic-10.1.1/releasenotes/notes/adoption-feature-update-d2160954a2c36b0a.yaml0000666000175100017510000000072313243617464026470 0ustar zuulzuul00000000000000--- fixes: - Adoption feature logic was updated to prevent ramdisk creation and default to instance creation where appropriate based on the driver. - Adoption documentation has been updated to note that the boot_option should likely be defined for nodes by a user leveraging the feature. - Adoption documentation has been updated to note that a user may wish to utilize the ``noop`` network interface that arrived with API version 1.20. ironic-10.1.1/releasenotes/notes/dbsync-check-version-c71d5f4fd89ed117.yaml0000666000175100017510000000071213243617464026152 0ustar zuulzuul00000000000000--- upgrade: - | The ``ironic-dbsync`` command will check the database object (record) versions to make sure they are compatible with the new ironic release, before doing the ``upgrade`` or ``online_data_migrations``. other: - | The ``ironic-dbsync`` command will check the database object (record) versions to make sure they are compatible with the new ironic release, before doing the ``upgrade`` or ``online_data_migrations``. ironic-10.1.1/releasenotes/notes/remove-exception-message-92100debeb40d4c7.yaml0000666000175100017510000000034413243617464027017 0ustar zuulzuul00000000000000--- upgrade: - Removes support for the "message" attribute from the "IronicException" class. Subclasses of "IronicException" should instead use the "_msg_fmt" attribute. This change is only relevant to developers. ironic-10.1.1/releasenotes/notes/oneview-onetime-boot-64a68e135a45f5e2.yaml0000666000175100017510000000022513243617464026034 0ustar zuulzuul00000000000000--- fixes: - Fixes the OneView driver to make the ``set_boot_device`` method work as expected with the ``persistent`` option set to ``False``. ironic-10.1.1/releasenotes/notes/fix-rpc-exceptions-12c70eb6ba177e39.yaml0000666000175100017510000000101513243617464025560 0ustar zuulzuul00000000000000--- fixes: - Ironic exceptions that contained arbitrary objects in ``kwargs`` and were sent via RPC were causing ``oslo_messaging`` serializer to fail. This was leading to 500 errors from ironic API, timing out waiting for response from the conductor. Starting with this release, all non-serializable objects contained in an exception's kwargs are dropped. Whether the error is going to be returned by the service will depend on the configuration option ``[DEFAULT]/fatal_exception_format_errors``. ironic-10.1.1/releasenotes/notes/error-resilient-enabled_drivers-4e9c864ed6eaddd1.yaml0000666000175100017510000000036013243617464030542 0ustar zuulzuul00000000000000--- fixes: - Fixes an issue where the ironic-conductor service would not run if a trailing comma or empty driver was specified in the ``[DEFAULT]enabled_drivers`` configuration option. The service now runs and logs a warning. ironic-10.1.1/releasenotes/notes/cleanup-provision-ports-before-retry-ec3c89c193766d70.yaml0000666000175100017510000000031013243617464031213 0ustar zuulzuul00000000000000--- fixes: - Fixes an issue with the ``neutron`` network interface that could lead to an inability to retry the deployment in case of failure on boot interface's ``prepare_ramdisk`` stage. ironic-10.1.1/releasenotes/notes/server_profile_template_uri-c79e4f15cc20a1cf.yaml0000666000175100017510000000036213243617464027773 0ustar zuulzuul00000000000000--- upgrade: - When registering a OneView node in ironic, operator should make sure field ``server_profile_template_uri`` is set in properties/capabilities and not in driver_info anymore. Otherwise the node will fail on validation. ironic-10.1.1/releasenotes/notes/drac-list-unfinished-jobs-10400419b6bc3c6e.yaml0000666000175100017510000000041513243617464026707 0ustar zuulzuul00000000000000--- features: - Adds ``list_unfinished_jobs`` method to the vendor-passthru interface of the DRAC driver. It provides a way to check the status of the remote config job after a BIOS configuration change was submitted using the ``set_bios_config`` method. ironic-10.1.1/releasenotes/notes/manual-abort-d3d8985a5de7376a.yaml0000666000175100017510000000025613243617464024444 0ustar zuulzuul00000000000000--- fixes: - | Fixes a bug in manual clean step caching, which resulted in all clean steps not being abortable. See https://bugs.launchpad.net/ironic/+bug/1658061. ironic-10.1.1/releasenotes/notes/adopt-oslo-config-generator-15afd2e7c2f008b4.yaml0000666000175100017510000000063413243617464027422 0ustar zuulzuul00000000000000--- other: - Adopt oslo-config-generator to generate sample config files. New config options from Ironic code should register with ironic/conf/opts.py. New external libraries should register with tools/config/ironic-config-generator.conf. A deprecated option should add a deprecated group even if it didn't alter its group, otherwise the deprecated group will use 'DEFAULT' by default. ironic-10.1.1/releasenotes/notes/nodes-classic-drivers-cannot-set-interfaces-620b37c4e5c88b80.yaml0000666000175100017510000000024713243617464032361 0ustar zuulzuul00000000000000--- fixes: - | Nodes with classic drivers cannot have any interfaces (except for network and storage) specified. HTTP status 400 is returned in these cases. ironic-10.1.1/releasenotes/notes/lookup-ignore-malformed-macs-09e7e909f3a134a3.yaml0000666000175100017510000000066213243617464027444 0ustar zuulzuul00000000000000--- fixes: - Fixes a problem where the deployment of a node would fail to continue if a malformed MAC address was passed to the lookup mechanism in the Ironic API. For example, if a node contains an Infiniband card, the lookup used to fail because the agent ramdisk passes a MAC address (or GID) with 20 octets (instead of the expected 6 octets) as part of the lookup request. Invalid addresses are now ignored. ironic-10.1.1/releasenotes/notes/remove-agent-passthru-432b18e6c430cee6.yaml0000666000175100017510000000133613243617464026276 0ustar zuulzuul00000000000000--- features: - | Agent lookup/heartbeat as vendor passthru is removed from most of in-tree ironic drivers. Affected drivers are * agent_ipmitool * agent_ipmitool_socat * agent_ipminative * agent_irmc * agent_ssh * agent_vbox * agent_ucs * pxe_agent_cimc * pxe_ipmitool * pxe_ipmitool_socat * pxe_ssh * pxe_ipminative * pxe_seamicro * pxe_snmp * pxe_irmc * pxe_vbox * pxe_msftocs * pxe_ucs * pxe_iscsi_cimc * pxe_drac * pxe_drac_inspector * iscsi_irmc * agent_ilo * iscsi_ilo * pxe_ilo * agent_pxe_oneview * iscsi_pxe_oneview All the other vendor passthru methods are left in place if the driver had them. ironic-10.1.1/releasenotes/notes/add-socat-console-ipmitool-ab4402ec976c5c96.yaml0000666000175100017510000000027713243617464027203 0ustar zuulzuul00000000000000--- features: - Adds support for socat-based serial console to ipmitool-based drivers. These are available by using the ``agent_ipmitool_socat`` and ``pxe_ipmitool_socat`` drivers. ironic-10.1.1/releasenotes/notes/validate-ilo-certificates-3ab98bb8cfad7d60.yaml0000666000175100017510000000042513243617464027277 0ustar zuulzuul00000000000000--- features: - Added support to validate iLO SSL certificate in iLO drivers. A new configuration option ``[ilo]/ca_file`` is added to specify the iLO CA certificate file. If ``[ilo]/ca_file`` is specified, the iLO drivers will validate iLO SSL certificates. ironic-10.1.1/releasenotes/notes/remove-python-oneviewclient-b1d345ef861e156e.yaml0000666000175100017510000000115213243617464027526 0ustar zuulzuul00000000000000--- issues: - | The library ``python-ilorest-library`` is a fork of the ``python-redfish-library`` and imported with same name, hence conflict when together. ``python-redfish-library`` cannot be used when ``oneview`` hardware type is in use. upgrade: - | The ``oneview`` hardware type now uses ``hpOneView`` and ``python-ilorest-library`` libraries to communicate with OneView appliances. The ``python-oneviewclient`` library is no longer used. upgrade: - | Configuration option ``[oneview]max_polling_attempts`` is removed since the ``hpOneView`` library doesn't support it. ironic-10.1.1/releasenotes/notes/cleaning-retry-fix-89a5d0e65920a064.yaml0000666000175100017510000000046213243617464025411 0ustar zuulzuul00000000000000--- fixes: - A bug has been corrected where a node's current clean_step was not purged upon that node timing out from a CLEANWAIT state. Previously, this bug would prevent a user from retrying cleaning operations. For more information, see https://bugs.launchpad.net/ironic/+bug/1590146. ironic-10.1.1/releasenotes/notes/security_groups-b57a5d6c30c2fae4.yaml0000666000175100017510000000102213243617464025431 0ustar zuulzuul00000000000000--- features: - Adds support for security groups for the provisioning and cleaning network. These are optionally specified by the configuration options ``[neutron]/provisioning_network_security_groups`` and ``[neutron]/cleaning_network_security_groups``, respectively. If not specified, the default security group for the network is used. These options are only applicable for nodes using the "neutron" network interface. These options are ignored for nodes using the "flat" and "noop" network interfaces. ironic-10.1.1/releasenotes/notes/check-for-whole-disk-image-uefi-3bf2146588de2423.yaml0000666000175100017510000000041713243617464027615 0ustar zuulzuul00000000000000--- fixes: - Removes a check that was preventing whole disk images from being deployed in UEFI mode without explicitly setting the ``boot_option`` capability to ``local``. For whole disk images, ironic already assumes booting from local storage by default. ironic-10.1.1/releasenotes/notes/vendor-passthru-shared-lock-6a9e32952ee6c2fe.yaml0000666000175100017510000000030713243617464027467 0ustar zuulzuul00000000000000--- features: - Adds the ability for node vendor passthru methods to use shared locks. Default behavior of always acquiring an exclusive lock for node vendor passthru methods is unchanged. ironic-10.1.1/releasenotes/notes/list-nodes-by-driver-a1ab9f2b73f652f8.yaml0000666000175100017510000000012513243617464026102 0ustar zuulzuul00000000000000--- features: - Add support for filtering nodes using the same driver via the API. ironic-10.1.1/releasenotes/notes/change-updated-at-object-field-a74466f7c4541072.yaml0000666000175100017510000000014113243617464027416 0ustar zuulzuul00000000000000--- fixes: - Now sets node's ``updated_at`` field correctly after a node has been updated. ironic-10.1.1/releasenotes/notes/no-instance-uuid-workaround-fc458deb168c7a8b.yaml0000666000175100017510000000024513243617464027564 0ustar zuulzuul00000000000000--- upgrade: - Removed the workaround in API allowing removing "instance_uuid" during cleaning. It was only required for Nova during introduction of cleaning. ironic-10.1.1/releasenotes/notes/setting_provisioning_cleaning_network-fb60caa1cf59cdcf.yaml0000666000175100017510000000136113243617464032307 0ustar zuulzuul00000000000000--- features: - | Allows specifying the provisioning and cleaning networks on a node as ``driver_info['cleaning_network']`` and ``driver_info['provisioning_network']`` respectively. If these values are defined in the node's driver_info at the time of provisioning or cleaning the baremetal node, they will be used. Otherwise, the configuration options ``cleaning_network`` and ``provisioning_network`` are used as before. fixes: - | A network UUID for provisioning and cleaning network is no longer cached locally if the requested network (either via node's ``driver_info`` or via configuration options) is specified as a network name. Fixes the situation when a network is re-created with the same name. ironic-10.1.1/releasenotes/notes/fix-dir-permissions-bc56e83a651bbdb0.yaml0000666000175100017510000000063113243617464026101 0ustar zuulzuul00000000000000--- fixes: - Adds the capability for an operator to explicitly define the permission for created tftpboot folders. This provides the ability for ironic to be utilized with a restrictive umask, where the tftp server may not be able to read the file. Introduces a new configuration option ``[pxe]/dir_permission`` to specify the permission for the tftpboot directories to be created with. ironic-10.1.1/releasenotes/notes/update-proliantutils-version-54c0cd5c5d3c01dc.yaml0000666000175100017510000000023613243617464030036 0ustar zuulzuul00000000000000--- upgrade: - Updates required proliantutils version for iLO drivers to 2.2.0. This version has support for sanitize disk erase using SSA utility. ironic-10.1.1/releasenotes/notes/neutron-port-timeout-cbd82e1d09c6a46c.yaml0000666000175100017510000000035113243617464026333 0ustar zuulzuul00000000000000--- other: - Add Neutron ``port_setup_delay`` configuration option. This delay allows Ironic to wait for Neutron port operations until we have a mechanism for synchronizing events with Neutron. Set to 0 by default. ironic-10.1.1/releasenotes/notes/remove-pxe-http-5a05c54f57747bfe.yaml0000666000175100017510000000026113243617464025112 0ustar zuulzuul00000000000000--- upgrade: - Removes deprecated options "[pxe]/http_url" and "[pxe]/http_root". Configuration files should instead use "[deploy]/http_url" and "[deploy]/http_root". ironic-10.1.1/releasenotes/notes/context-domain-id-name-deprecation-ae6e40718273be8d.yaml0000666000175100017510000000057313243617464030604 0ustar zuulzuul00000000000000--- deprecations: - | Usage of the following values was deprecated in the policy files: - ``domain_id`` and ``domain_name`` - ``user_domain_id`` should be used instead of those (note - ``user_domain_id`` is an ID of the domain, not its name). - ``tenant`` - ``project_name`` should be used instead. - ``user`` - ``user_id`` should be used instead. ironic-10.1.1/releasenotes/notes/bug-1648387-92db52cbe007fabd.yaml0000666000175100017510000000024713243617464023667 0ustar zuulzuul00000000000000--- fixes: - Fixes an issue where the API service does not start if audit is enabled with the default value of ``[audit]/ignore_req_list`` configuration option. ironic-10.1.1/releasenotes/notes/bug-1611555-de1ec64ba46982ec.yaml0000666000175100017510000000007013243617464023602 0ustar zuulzuul00000000000000--- features: - Adds timing metrics to DRAC drivers. ironic-10.1.1/releasenotes/notes/change-ramdisk-log-filename-142b10d0b02a5ca6.yaml0000666000175100017510000000066213243617464027217 0ustar zuulzuul00000000000000--- upgrade: - | Changes timestamp part of ramdisk log filename by replacing colon with dash. The ``tar`` command does not handle colon properly, and untar of the file with colon in filename will fail. fixes: - | Changes timestamp part of ramdisk log filename by replacing colon with dash. The ``tar`` command does not handle colon properly, and untar of the file with colon in filename will fail. ironic-10.1.1/releasenotes/notes/add-boot-from-volume-support-9f64208f083d0691.yaml0000666000175100017510000000016513243617464027302 0ustar zuulzuul00000000000000--- other: - Adds a configuration section ``cinder`` and a requirement of cinder client (python-cinderclient). ironic-10.1.1/releasenotes/notes/name-suffix-47aea2d265fa75ae.yaml0000666000175100017510000000154013243617464024417 0ustar zuulzuul00000000000000--- fixes: - | Nodes and port groups with names ending with known file extensions are now correctly handled by the API. See `bug 1643995 `_ for more details. issues: - | If you have two nodes or port groups with names that only differ in a ``.json`` suffix (for example, ``test`` and ``test.json``) you won't be able to get, update or delete the one with the suffix via the ``/v1/nodes/`` endpoint (``/v1/portgroups/`` for port groups). Similarly, the ``/v1/heartbeat/`` endpoint won't work for the node with the suffix. To work around it, add one more ``.json`` suffix (for example, use ``/v1/nodes/test`` for node ``test`` and ``/v1/nodes/test.json.json`` for ``test.json``). This issue will be addressed in one of the future API revisions. ironic-10.1.1/releasenotes/notes/removal-pre-allocation-for-oneview-09310a215b3aaf3c.yaml0000666000175100017510000000040713243617464030623 0ustar zuulzuul00000000000000--- upgrade: - | The pre-allocation model for OneView drivers was deprecated in Newton cycle (Ironic 6.1.0) and all pertaining code was marked for removal during Pike cycle. From now on, OneView drivers works only with dynamic allocation model. ironic-10.1.1/releasenotes/notes/agent-can-request-reboot-6238e13e2e898f68.yaml0000666000175100017510000000053213243617464026537 0ustar zuulzuul00000000000000--- features: - This adds the reboot_requested option for in-band cleaning. If set to true, Ironic will reboot the node after that step has completed and before continuing with the next step. This option is useful for when some action, such as a BIOS upgrade or setting change, requires a reboot to take effect. ironic-10.1.1/releasenotes/notes/bug-1702158-79bf57bd4d8087b6.yaml0000666000175100017510000000262213243617464023464 0ustar zuulzuul00000000000000--- fixes: - | Fixes database schema that could cause the wrong database engine to be utilized for the ``conductor_hardware_interfaces`` table, if the system is using MySQL prior to version 5.5 or the ``default_storage_engine`` option is set explicitly to 'MyISAM' in ``my.cnf``. In this case, a table could be created with MyISAM engine, and the foreign key constraint ``conductor_id(conductors.id)`` was ignored. See `bug 1702158 `_ for details. upgrade: - | Due to `bug 1702158 `_, the ``conductor_hardware_interfaces`` table could be created with MyISAM database engine, while all other tables in ironic database are using InnoDB engine. This could happen during initial installation, or upgrade to the Ocata release, if the system was using MySQL prior to version 5.5 or the ``default_storage_engine`` option was set explicitly to 'MyISAM' in ``my.cnf``. If this is the case, the ``conductor_hardware_interfaces`` table needs to be manually migrated to InnoDB, and the foreign key constraint needs to be re-created:: alter table conductor_hardware_interfaces engine='InnoDB'; alter table conductor_hardware_interfaces add constraint conductor_hardware_interfaces_ibfk_1 foreign key (conductor_id) references conductors(id); ironic-10.1.1/releasenotes/notes/erase-devices-metadata-config-f39b6ca415a87757.yaml0000666000175100017510000000117713243617464027540 0ustar zuulzuul00000000000000--- features: - Adds a new ``[deploy]/erase_devices_metadata_priority`` configuration option to allow operators to configure the priority of (or disable) the "erase_devices_metadata" cleaning step. upgrade: - The new "erase_devices_metadata" cleaning step is enabled by default (if available) in the ironic-python-agent project (priority 99). Wiping the devices metadata is usually very fast and shouldn't add much time (if any) to the overall cleaning process. Operators wanting to disable this cleaning step can do it by setting the ``[deploy]/erase_devices_metadata_priority`` configuration option to 0. ironic-10.1.1/releasenotes/notes/Add-port-option-support-to-ipmitool-e125d07fe13c53e7.yaml0000666000175100017510000000025513243617464031003 0ustar zuulzuul00000000000000--- features: - Add support for ipmitool's port (-p) option. This allows ipmitool support for operators that do not use the default port (623) as their IPMI port. ././@LongLink0000000000000000000000000000016400000000000011216 Lustar 00000000000000ironic-10.1.1/releasenotes/notes/raise-bad-request-exception-on-validating-inspection-failure-57d7fd2999cf4ecf.yamlironic-10.1.1/releasenotes/notes/raise-bad-request-exception-on-validating-inspection-failure-57d7fd0000666000175100017510000000032513243617464033520 0ustar zuulzuul00000000000000--- fixes: - Raises HTTP 400 ``Bad Request`` (instead of HTTP 500 ``Internal Server``) error on failure to validate ``power`` or ``inspect`` interface parameters before performing a hardware inspection. ironic-10.1.1/releasenotes/notes/clear-node-target-power-state-de1f25be46d3e6d7.yaml0000666000175100017510000000014113243617464027745 0ustar zuulzuul00000000000000--- fixes: - Clear target_power_state of the nodes locked by the conductor on its startup. ironic-10.1.1/releasenotes/notes/bug-1749433-363b747d2db67df6.yaml0000666000175100017510000000033613243617464023463 0ustar zuulzuul00000000000000--- fixes: - | Fixes a bug preventing a node from booting into the user instance after unrescuing if instance netboot is used. See `bug 1749433 `_ for details. ironic-10.1.1/releasenotes/notes/reserved-node-names-67a08012ed1131ae.yaml0000666000175100017510000000043113243617464025576 0ustar zuulzuul00000000000000--- fixes: - Fixes a problem which allowed nodes to be named with some reserved words that are implicitly not allowed due the way the Ironic API works. The reserved words are "maintenance", "management", "ports", "states", "vendor_passthru", "validate" and "detail". ironic-10.1.1/releasenotes/notes/dynamic-driver-list-show-apis-235e9fca26fc580d.yaml0000666000175100017510000000654513243617464027733 0ustar zuulzuul00000000000000--- features: - | Adds support for dynamic drivers. Using a dynamic driver in a node's ``driver`` field is now possible. Dynamic drivers are composed of a ``hardware type`` and a number of ``hardware interfaces``. NOTE: this feature is considered somewhat experimental, as not all classic drivers have a corresponding dynamic driver, and there is minimal CI for dynamic drivers at the time of this writing. Hardware types are enabled via the ``[DEFAULT]/enabled_hardware_types`` configuration option, and hardware interfaces are enabled via the ``[DEFAULT]/enabled_*_interfaces`` configuration option. A default interface to use when creating or updating nodes can be specified with the ``[DEFAULT]/default_*_interface`` configuration option. The ironic-conductor process will now fail to start if: - a default interface implementation for any enabled hardware type cannot be found. - a dynamic driver and a classic driver with the same name are both enabled. - at least one classic driver *or* one dynamic driver is not enabled. Hardware types available in this release are: - ``ipmi`` for IPMI-compatible hardware. This type is enabled by default. Uses the ``ipmitool`` utility under the hood, similar to existing classic drivers ``pxe_ipmitool`` and ``agent_ipmitool``. Supports both types of serial console: via ``shellinabox`` and via ``socat``, both are disabled by default. - ``irmc`` for FUJITSU PRIMERGY servers, disabled by default. This feature has a number of REST API changes, all of which are available in API version 1.31. - Adds additional parameters and response fields for GET /v1/drivers and GET /v1/drivers/. - Exposes the following fields on the node resource, to allow getting and setting interfaces for a dynamic driver: * boot_interface * console_interface * deploy_interface * inspect_interface * management_interface * power_interface * raid_interface * vendor_interface - Allows dynamic drivers to be used and returned in the following API calls, in all versions of the REST API: * GET /v1/drivers * GET /v1/drivers/ * GET /v1/drivers//properties * GET /v1/drivers//vendor_passthru/methods * GET/POST /v1/drivers//vendor_passthru * GET/POST /v1/nodes//vendor_passthru For more details on the REST API changes, see the `REST API Version History documentation `_. This also adds dynamic interface fields to node-related notifications: * boot_interface * console_interface * deploy_interface * inspect_interface * management_interface * power_interface * raid_interface * vendor_interface The affected notifications are: * baremetal.node.create.*, new payload version 1.1 * baremetal.node.update.*, new payload version 1.1 * baremetal.node.delete.*, new payload version 1.1 * baremetal.node.maintenance.*, new payload version 1.3 * baremetal.node.console.*, new payload version 1.3 * baremetal.node.power_set.*, new payload version 1.3 * baremetal.node.power_state_corrected.*, new payload version 1.3 * baremetal.node.provision_set.*, new payload version 1.3 ironic-10.1.1/releasenotes/notes/add-cisco-ucs-hardware-types-ee597ff0416f158f.yaml0000666000175100017510000000171713243617464027440 0ustar zuulzuul00000000000000--- features: - | Adds two new hardware types to support Cisco UCS Servers, ``cisco-ucs-standalone`` and ``cisco-ucs-managed``. ``cisco-ucs-standalone`` supports driver interfaces for controlling UCS servers in standalone mode via either CIMC APIs or via IPMI. ``cisco-ucs-managed`` is a superset of ``cisco-ucs-standalone`` and supports additional driver interfaces for controlling the UCS server via UCSM. To support these hardware types the following Ironic driver interfaces were made available to be configured on a node: * ``node.power_interface`` can be set to: * ``cimc`` for CIMC API power control (power on/off, reboot, etc.) * ``ucsm`` for UCSM API power control (power on/off, reboot, etc.) * ``node.management_interface`` can be set to: * ``cimc`` for CIMC API management control (setting the boot device, etc.) * ``ucsm`` for UCSM API management control (setting the boot device, etc.) ironic-10.1.1/releasenotes/notes/wwn-extension-root-device-hints-de40ca1444ba4888.yaml0000666000175100017510000000014213243617464030217 0ustar zuulzuul00000000000000--- features: - Adds root device hints for `wwn_with_extension` and `wwn_vendor_extension`. ironic-10.1.1/releasenotes/notes/deprecate-global-region-4dbea91de71ebf59.yaml0000666000175100017510000000064313243617464026743 0ustar zuulzuul00000000000000--- deprecations: - | Configuration option ``[keystone]/region_name`` is deprecated and will be ignored in the Rocky release. Instead, provide per-service ``region_name`` option in the following configuration file sections: ``[service_catalog]`` (for bare metal API endpoint discovery from keystone service catalog), ``[glance]``, ``[neutron]``, ``[cinder]``, ``[inspector]`` and ``[swift]``. ironic-10.1.1/releasenotes/notes/idrac-no-vendor-911904dd69457826.yaml0000666000175100017510000000020213243617464024537 0ustar zuulzuul00000000000000--- fixes: - | Adds missing ``no-vendor`` implementation to supported vendor interfaces of the ``idrac`` hardware type. ironic-10.1.1/releasenotes/notes/fix-ipxe-macro-4ae8bc4fe82e8f19.yaml0000666000175100017510000000016713243617464025050 0ustar zuulzuul00000000000000--- fixes: - Fixes an issue where iPXE may try to boot from the wrong MAC address, resulting in deploy failures. ironic-10.1.1/releasenotes/notes/rebuild-configdrive-f52479fd55b0f5ce.yaml0000666000175100017510000000062213243617464026054 0ustar zuulzuul00000000000000--- features: - | Starting with the Bare Metal API version 1.35, it is possible to provide a configdrive when rebuilding a node. fixes: - | Fixes the problem of an old configdrive (used for deploying the node) being used again when rebuilding the node. Starting with the Bare Metal API version 1.35, it is possible to specify a different configdrive when rebuilding a node. ironic-10.1.1/releasenotes/notes/remove-agent-passthru-complete-a6b2df65b95889d5.yaml0000666000175100017510000000140413243617464030126 0ustar zuulzuul00000000000000--- upgrade: - Ironic no longer supports agent lookup/heartbeats as vendor passthru methods. All out-of-tree drivers must be updated to use ``AgentDeployMixin`` classes directly without relying on ``BaseAgentVendor`` class and other classes that were inheriting from it (e.g. ``agent.AgentVendorInterface`` and ``iscsi_deploy.VendorPassthru``). This means that ironic is incompatible with deploy ramdisks based on Ironic Python Agent (IPA) < 1.5.0. Operators must update their IPA-based deploy ramdisks in this case. Operators using non-IPA based deploy ramdisks which use ironic lookup/heartbeats functionality must update their ramdisks to use the top level ironic lookup/heartbeats REST API, available since ironic API v1.22. ././@LongLink0000000000000000000000000000015000000000000011211 Lustar 00000000000000ironic-10.1.1/releasenotes/notes/remove-deprecated-build-instance-info-for-deploy-2fe165fc018010e4.yamlironic-10.1.1/releasenotes/notes/remove-deprecated-build-instance-info-for-deploy-2fe165fc018010e4.y0000666000175100017510000000052013243617464032550 0ustar zuulzuul00000000000000--- other: - | The method ``build_instance_info_for_deploy()`` from the ``ironic.drivers.modules.agent`` module was deprecated in the Ocata cycle (version 7.0.0). It is no longer available. Please use the method ``build_instance_info_for_deploy()`` from the ``ironic.drivers.modules.deploy_utils`` module instead. ironic-10.1.1/releasenotes/notes/hexraw-support-removed-8e8fa07595a629f4.yaml0000666000175100017510000000032213243617464026445 0ustar zuulzuul00000000000000--- upgrade: - Removes support for "hexraw" type in the iPXE script (boot.ipxe) since "hexraw" is not supported in older versions of iPXE. "hexhyp" replaced "hexraw" and has been used since kilo. ironic-10.1.1/releasenotes/notes/restart-console-on-conductor-startup-5cff6128c325b18e.yaml0000666000175100017510000000032513243617464031275 0ustar zuulzuul00000000000000--- fixes: - Some nodes' console may be enabled but the corresponding console services stopped while starting conductors, this tries to start consoles on conductor startup to make the status consistent. ironic-10.1.1/releasenotes/notes/fix-sync-power-state-last-error-65fa42bad8e38c3b.yaml0000666000175100017510000000020313243617464030271 0ustar zuulzuul00000000000000--- fixes: - Fixes an issue where `node.last_error` did not show the actual issue when the periodic power state sync failed. ironic-10.1.1/releasenotes/notes/conf-debug-ipa-1d75e2283ca83395.yaml0000666000175100017510000000043413243617464024465 0ustar zuulzuul00000000000000--- upgrade: - The ``[DEFAULT]/debug`` configuration option now also enables debug logs for the ``ironic-python-agent`` ramdisk. If the ``ipa-debug`` kernel option is already present in the ``[pxe]/pxe_append_params`` configuration option, ironic will not overwrite it. ironic-10.1.1/releasenotes/notes/bug-1607527-75885e145db62d69.yaml0000666000175100017510000000015613243617464023330 0ustar zuulzuul00000000000000--- fixes: - Fixes SSH driver validation when using a private key with a passphrase for authentication. ironic-10.1.1/releasenotes/notes/fix-ilo-drivers-log-message-c3c64c1ca0a0bca8.yaml0000666000175100017510000000034613243617464027460 0ustar zuulzuul00000000000000--- fixes: - | When the deletion of a swift temporary object fails because the object is no longer available in swift, a message is logged. The log level of this message was changed from ``WARNING`` to ``INFO``. ironic-10.1.1/releasenotes/notes/add-validate-rescue-2202e8ce9a174ece.yaml0000666000175100017510000000026613243617464025724 0ustar zuulzuul00000000000000--- other: - | Adds new method ``validate_rescue()`` to ``NetworkInterface`` to validate rescuing network. This method is called during validation of rescue interface. ironic-10.1.1/releasenotes/notes/newton-driver-deprecations-e40369be37203057.yaml0000666000175100017510000000124713243617464027101 0ustar zuulzuul00000000000000--- deprecations: - | The following drivers are marked as unsupported and therefore deprecated. Some or all of these drivers may be removed in the Ocata cycle or later. * ``agent_amt`` * ``agent_iboot`` * ``agent_pyghmi`` * ``agent_ssh`` * ``agent_vbox`` * ``agent_wol`` * ``fake_ipminative`` * ``fake_ssh`` * ``fake_seamicro`` * ``fake_iboot`` * ``fake_snmp`` * ``fake_vbox`` * ``fake_amt`` * ``fake_msftocs`` * ``fake_wol`` * ``pxe_ipminative`` * ``pxe_ssh`` * ``pxe_vbox`` * ``pxe_seamicro`` * ``pxe_iboot`` * ``pxe_snmp`` * ``pxe_amt`` * ``pxe_msftocs`` * ``pxe_wol`` ironic-10.1.1/releasenotes/notes/ilo-hardware-type-48fd1c8bccd70659.yaml0000666000175100017510000000111313243617464025461 0ustar zuulzuul00000000000000--- features: - | Adds a new hardware type ``ilo`` for iLO 4 based Proliant Gen 8 and Gen 9 servers. This hardware type supports virtual media and PXE based boot using HPE iLO 4 management engine. The following driver interfaces are supported: * boot: ``ilo-virtual-media`` and ``ilo-pxe`` * console: ``ilo`` and ``no-console`` * deploy: ``iscsi`` and ``direct`` * inspect: ``ilo``, ``inspector`` and ``no-inspect`` * management: ``ilo`` * network: ``flat``, ``noop`` and ``neutron`` * power: ``ilo`` * raid: ``no-raid`` and ``agent`` ././@LongLink0000000000000000000000000000016200000000000011214 Lustar 00000000000000ironic-10.1.1/releasenotes/notes/config-drive-support-for-whole-disk-images-in-iscsi-deploy-0193c5222a7cd129.yamlironic-10.1.1/releasenotes/notes/config-drive-support-for-whole-disk-images-in-iscsi-deploy-0193c5220000666000175100017510000000037213243617464033040 0ustar zuulzuul00000000000000--- features: - Added configdrive support for whole disk images for iSCSI based deploy. This will work for UEFI only or BIOS only images. It will not work for hybrid images which are capable of booting from BIOS and UEFI boot mode. ironic-10.1.1/releasenotes/notes/disable-clean-step-reset-ilo-1869a6e08f39901c.yaml0000666000175100017510000000034613243617464027252 0ustar zuulzuul00000000000000--- fixes: - Disables default execution of clean step 'reset_ilo' during automated cleaning. Resetting of iLO is not required during every invocation of automated cleaning. If required, operator can enable the same. ironic-10.1.1/releasenotes/notes/remove-ssh-power-port-delay-7ae6e5eb893439cd.yaml0000666000175100017510000000051713243617464027441 0ustar zuulzuul00000000000000--- upgrade: - | For SSH power drivers, if the configuration option ``[neutron]/port_setup_delay`` had been set to 0, a delay of 15 seconds was used. This is no longer the case. Please set the configuration option to the desired value; otherwise the service will not wait for Neutron agents to set up a port. ironic-10.1.1/releasenotes/notes/ilo-automated-cleaning-fails-14ee438de3dd8690.yaml0000666000175100017510000000035613243617464027472 0ustar zuulzuul00000000000000--- fixes: - Fixes issue where automated cleaning fails for iLO drivers. Automated cleaning fails for iLO driver if iLO is in System POST state. iLO does not allow setting of boot device when it is in System POST state. ironic-10.1.1/releasenotes/notes/ipmitool-bootdev-persistent-uefi-b1181a3c82343c8f.yaml0000666000175100017510000000041713243617464030372 0ustar zuulzuul00000000000000--- fixes: - Fixes a problem where the boot mode (UEFI or BIOS) wasn't being considered when setting the boot device of a node using the "ipmitool" management interface. It would incorrectly switch from UEFI to Legacy BIOS mode on some hardware models. ironic-10.1.1/releasenotes/notes/rescue-node-87e3b673c61ef628.yaml0000666000175100017510000000512513243617464024211 0ustar zuulzuul00000000000000--- features: - | Adds support for rescuing and unrescuing nodes: - Adds version 1.38 of the Bare Metal API, which includes: * A node in the ``active`` provision state can be rescued via the ``GET /v1/nodes/{node_ident}/states/provision`` API, by specifying ``rescue`` as the ``target`` value, and a ``rescue_password`` value. When the node has been rescued, it will be in the ``rescue`` provision state. A rescue ramdisk will be running, configured with the specified ``rescue_password``, and listening with ssh on the tenant network. * A node in the ``rescue`` provision state can be unrescued (to the ``active`` state) via the ``GET /v1/nodes/{node_ident}/states/provision`` API, by specifying ``unrescue`` as the ``target`` value. * The ``rescue_interface`` field of the node resource. A rescue interface can be set when creating or updating a node. * The ``default_rescue_interface`` and ``enabled_rescue_interfaces`` fields of the driver resource. - Adds new configuration options for the rescue feature: * Rescue interfaces are enabled via ``[DEFAULT]/enabled_rescue_interfaces``. A default rescue interface to use when creating or updating nodes can be specified with ``[DEFAULT]/enabled_rescue_interfaces``. * Adds ``[conductor]/check_rescue_state_interval`` and ``[conductor]/rescue_callback_timeout`` to fail the rescue operation upon timeout, for the nodes that are stuck in the rescue wait state. * Adds support for providing ``rescuing`` network (UUIR or name) with its security groups using new options ``[neutron]/rescuing_network`` and ``[neutron]/rescuing_network_security_groups`` respectively. It is required to provide ``[neutron]/rescuing_network``. Alternatively, the rescuing network can be provided per node via the node's ``driver_info['rescuing_network']`` field. - Adds ``rescue_interface`` field to the following node-related notifications: * ``baremetal.node.create.*``, new payload version 1.3 * ``baremetal.node.update.*``, new payload version 1.3 * ``baremetal.node.delete.*``, new payload version 1.3 * ``baremetal.node.maintenance.*``, new payload version 1.5 * ``baremetal.node.console.*``, new payload version 1.5 * ``baremetal.node.power_set.*``, new payload version 1.5 * ``baremetal.node.power_state_corrected.*``, new payload version 1.5 * ``baremetal.node.provision_set.*``, new payload version 1.5 ironic-10.1.1/releasenotes/notes/queens-prelude-61fb897e96ed64c5.yaml0000666000175100017510000000247113243617464025027 0ustar zuulzuul00000000000000--- prelude: | The 10.1.0 (Queens) release includes many new features and bug fixes. Please review the "Upgrade Notes" sections (for 9.2.0, 10.0.0 and 10.1.0) which describe the required actions to upgrade your installation from 9.1.x (Pike) to 10.1.0 (Queens). A few major changes since 9.1.x (Pike) are worth mentioning: - New `traits API `_. - New ``ansible`` deploy interface that allows greater customization of the provisioning process. - Support for rescuing and unrescuing nodes. - Support for `routed networks `_ when using the ``flat`` network interface. - New ``xclarity`` hardware type for managing Lenovo server hardware. Finally, this release deprecates classic drivers in favor of hardware types. Please check `the migration guide `_ for information on which hardware types and interfaces to enable before upgrade and how to update the nodes. The ``ironic-dbsync online_data_migrations`` command will handle the migration, if all required hardware types and interfaces are enabled before the upgrade. ironic-10.1.1/releasenotes/notes/port-physical-network-a7009dc514353796.yaml0000666000175100017510000000232413243617464026110 0ustar zuulzuul00000000000000--- features: - | Adds a ``physical_network`` field to the port object in REST API version 1.34. This field specifies the name of the physical network to which the port is connected, and is empty by default. This field may be set by the operator to allow the Bare Metal service to incorporate physical network information when attaching virtual interfaces (VIFs). The REST API endpoints related to ports provide support for the ``physical_network`` field. The `multi-tenancy documentation `_ provides information on how to configure and use physical networks. upgrade: - | Following an upgrade to this release, all ports will have an empty ``physical_network`` field. Attachment of Virtual Interfaces (VIFs) will continue to function as in the previous release until any ports have their physical network field set. During a live upgrade to this release, the ``physical_network`` field will not be available. It will also not be possible to create ports which are members of a port group during a live upgrade, as the API service will be unable to validate the consistency of the request. ironic-10.1.1/releasenotes/notes/bug-1596421-0cb8f59073f56240.yaml0000666000175100017510000000067413243617464023316 0ustar zuulzuul00000000000000--- upgrade: - Extends the ``instance_info`` column in the nodes table for MySQL/MariaDB from up to 64KiB to up to 4GiB (type is changed from TEXT to LONGTEXT). This upgrade will not be executed on PostgreSQL as its TEXT is unlimited. fixes: - The config drive passed to the node can now contain more than 64KiB in case of MySQL/MariaDB. For more details see `bug 1596421 `_. ironic-10.1.1/releasenotes/notes/fix-socat-command-afc840284446870a.yaml0000666000175100017510000000060113243617464025207 0ustar zuulzuul00000000000000--- fixes: - Fixes issue with socat console support where an unlimited number of connections could be created, resulting in the prior session being destroyed. Connections are now limited to a single connection per server. Socat now closes the console connection upon disconnect or timeout 10min. To reconnect, users should re-activate the console. ironic-10.1.1/releasenotes/notes/adding-audit-middleware-b95f2a00baed9750.yaml0000666000175100017510000000071113243617464026555 0ustar zuulzuul00000000000000--- features: - | The ironic-api service now supports logging audit messages of API calls. The following configuration parameters have been added. By default audit logging for ironic-api service is turned off. * ``[audit]/enabled`` * ``[audit]/ignore_req_list`` * ``[audit]/audit_map_file`` Further documentation for this feature is available at http://docs.openstack.org/developer/ironic/deploy/api-audit-support.html . ironic-10.1.1/releasenotes/notes/ilo-vendor-e8d299ae13388184.yaml0000666000175100017510000000013413243617464023772 0ustar zuulzuul00000000000000--- features: - | Adds missing ``ilo`` vendor interface to the ``ilo`` hardware type. ironic-10.1.1/releasenotes/notes/catch-third-party-driver-validate-exceptions-94ed2a91c50d2d8e.yaml0000666000175100017510000000013613243617464032707 0ustar zuulzuul00000000000000--- fixes: - Catch unknown exceptions with traceback when validating driver interfaces. ironic-10.1.1/releasenotes/notes/ipxe-use-swift-5ccf490daab809cc.yaml0000666000175100017510000000122613243617464025146 0ustar zuulzuul00000000000000--- features: - By default, the ironic-conductor service caches the node's deploy ramdisk and kernel images locally and serves them via a separate HTTP server. A new ``[pxe]/ipxe_use_swift`` configuration option (disabled by default) allows images to be accessed directly from object store via Swift temporary URLs. This is only applicable if iPXE is enabled (via ``[pxe]/ipxe_enabled`` configuration option) and image store is in Glance/Swift. For user images that are partition images requiring non-local boot, the default behavior with local caching and an HTTP server will still apply for user image kernel and ramdisk. ironic-10.1.1/releasenotes/notes/fix-agent-ilo-temp-image-cleanup-711429d0e67807ae.yaml0000666000175100017510000000021513243617464030013 0ustar zuulzuul00000000000000--- fixes: - Fixes an issue where the `agent_ilo` driver did not correctly clean up temporary files created during the deploy process. ironic-10.1.1/releasenotes/notes/bug-1749860-457292cf62e18a0e.yaml0000666000175100017510000000027113243617471023374 0ustar zuulzuul00000000000000--- fixes: - | Fixes rescue timeout due to incorrect kernel parameter in the iPXE script. See `bug 1749860 `_ for details. ironic-10.1.1/releasenotes/notes/next-link-for-instance-uuid-f46eafe5b575f3de.yaml0000666000175100017510000000047113243617464027537 0ustar zuulzuul00000000000000--- fixes: - | Fixes a `bug `_ with the response for a ``GET /nodes?limit=1&instance_uuid=`` request. If a node matched, a ``next`` link was returned, even though there are no more nodes that will match. That link is no longer returned. ironic-10.1.1/releasenotes/notes/xclarity-driver-622800d17459e3f9.yaml0000666000175100017510000000030113243617464024750 0ustar zuulzuul00000000000000--- features: - | Adds the new ``xclarity`` hardware type for managing Lenovo server hardware with the following interfaces: * management: ``xclarity`` * power: ``xclarity`` ironic-10.1.1/releasenotes/notes/bug-1518374-decd73fd82c2eb94.yaml0000666000175100017510000000017113243617464023674 0ustar zuulzuul00000000000000--- critical: - Fixes an issue where the next cleaning for a node would hang if the previous cleaning was aborted. ironic-10.1.1/releasenotes/notes/remove-policy-json-be92ffdba7bda951.yaml0000666000175100017510000000123313243617464026101 0ustar zuulzuul00000000000000--- upgrade: - | The default policy file located at ``etc/ironic/policy.json`` was removed in this release, as no policy file is required to run the ironic-api service. other: - | The sample configuration file located at ``etc/ironic/ironic.conf.sample`` and the sample policy file located at ``etc/ironic/policy.json.sample`` were removed in this release, as they are now published with documentation. See `the sample configuration file `_ and `the sample policy file `_. ironic-10.1.1/releasenotes/notes/keystoneauth-adapter-opts-ca4f68f568e6cf6f.yaml0000666000175100017510000000312213243617464027346 0ustar zuulzuul00000000000000--- features: - | To facilitate automatic discovery of services from the service catalog, the configuration file sections for service clients may include these configuration options: ``service_type``, ``service_name``, ``valid_interfaces``, ``region_name`` and other keystoneauth options. These options together must uniquely specify an endpoint for a service registered in the service catalog. Alternatively, the ``endpoint_override`` option can be used to specify the endpoint. Consult the `keystoneauth library documentation `_ for a full list of available options, their meaning and possible values. Default values for ``service_type`` are set by ironic to sane defaults based on required services and their entries in the `service types authority `_. The ``valid_interfaces`` option defaults to ``['internal', 'public']``. The ``region_name`` option defaults to ``None`` and must be explicitly set for multi-regional setup for endpoint discovery to succeed. Currently only the ``[service_catalog]`` section supports these options. deprecations: - | Configuration option ``[conductor]api_url`` is deprecated and will be removed in the Rocky release. Instead, use the ``[service_catalog]endpoint_override`` configuration option to set the Bare Metal API endpoint if its automatic discovery from the service catalog is not desired. This new option defaults to ``None`` and must be set explicitly if needed. ironic-10.1.1/releasenotes/notes/ipv6-provision-67bd9c1dbcc48c97.yaml0000666000175100017510000000010113243617464025114 0ustar zuulzuul00000000000000--- fixes: - Adds support for deploying to IPv6 iSCSI portals. ironic-10.1.1/releasenotes/notes/configure-notifications-72824356e7d8832a.yaml0000666000175100017510000000053413243617464026464 0ustar zuulzuul00000000000000--- features: - It is now possible to configure the notifications to use a different transport URL than the RPCs. These could potentially be completely different message broker hosts (though they don't need to be). If the notification-specific configuration is not provided, the notifier will use the same transport as the RPCs. ironic-10.1.1/releasenotes/notes/agent-api-bf9f18d8d38075e4.yaml0000666000175100017510000000033413243617464023724 0ustar zuulzuul00000000000000--- other: - The ``continue_deploy`` and ``reboot_to_instance`` methods in the ``BaseAgentVendor`` class stopped accepting ** arguments. They were never used anyway; drivers should stop passing anything there. ironic-10.1.1/releasenotes/notes/remove-most-unsupported-049f3401c2554a3c.yaml0000666000175100017510000000214513243617464026531 0ustar zuulzuul00000000000000--- upgrade: - | A number of drivers that were declared as unsupported in Newton release have been removed from ironic tree. This includes drivers with power and/or management driver interfaces based on: - MSFT OCS - SeaMicro client - Virtualbox over pyremotevbox client As a result, the following ironic drivers will no longer be available: - agent_vbox - fake_msftocs - fake_seamicro - fake_vbox - pxe_msftocs - pxe_seamicro - pxe_vbox After upgrading, if one or more of these drivers are in the 'enabled_drivers' configuration option, the ironic-conductor service will fail to start. Any existing ironic nodes with these drivers assigned will become inoperational via ironic after ironic upgrade, as it will be not possible to change any node state/properties except changing the node driver. Operators having one of the drivers listed above enabled are required to either disable those drivers and assign another existing driver to affected nodes as appropriate, or install these drivers from elsewhere separately. ironic-10.1.1/releasenotes/notes/create-on-conductor-c1c52a1f022c4048.yaml0000666000175100017510000000120013243617464025600 0ustar zuulzuul00000000000000--- upgrade: - Moves node creation logic from the API service to the conductor service. This is more consistent with other node operations and opens opportunities for conductor-side validations on nodes. However, with this change, node creation may take longer, and this may limit the number of nodes that can be enrolled in parallel. - The ``[DEFAULT]/default_network_interface`` and ``[dhcp]/dhcp_provider`` configuration options were previously required for the ironic-api service to calculate the correct "network_interface" default. Now these options are only required by the ironic-conductor service. ironic-10.1.1/releasenotes/notes/add-choice-to-some-options-9fb327c48e6bfda1.yaml0000666000175100017510000000155413243617464027243 0ustar zuulzuul00000000000000--- upgrade: - | Add ``choices`` parameter to config options. Invalid values will be rejected when first accessing them, which can happen in the middle of deployment. ================================= ================ Option Choices ================================= ================ [DEFAULT]/auth_strategy keystone, noauth [glance]/auth_strategy keystone, noauth [glance]/glance_protocol http, https [neutron]/auth_strategy keystone, noauth [amt]/protocol http, https [irmc]/remote_image_share_type CIFS, NFS [irmc]/port 443, 80 [irmc]/auth_method basic, digest [irmc]/sensor_method ipmitool, scci ================================= ================ ironic-10.1.1/releasenotes/notes/fix-net-ifaces-rebuild-1cc03df5d37f38dd.yaml0000666000175100017510000000023013243617464026420 0ustar zuulzuul00000000000000--- fixes: - | Fixes an issue with node rebuild, when tenant network ports were not unbound prior to moving the node to provisioning network. ironic-10.1.1/releasenotes/notes/node-deletion-update-resources-53862e48ab658f77.yaml0000666000175100017510000000027013243617464027737 0ustar zuulzuul00000000000000--- fixes: - Fixed performance issue for 'ironic.nova.compute.ClusteredComputeManager' when during Nova instance termination resources were updated for all Nova hypervisors. ironic-10.1.1/releasenotes/notes/clear-hung-iscsi-sessions-d3b55c4c65fa4c8b.yaml0000666000175100017510000000014013243617464027173 0ustar zuulzuul00000000000000--- fixes: - An issue with hung iscsi sessions not being cleaned up in case of deploy failure.ironic-10.1.1/releasenotes/notes/ironic-cfg-defaults-4708eed8adeee609.yaml0000666000175100017510000000035113243617464026037 0ustar zuulzuul00000000000000--- other: - | The default rootwrap configuration files are now included when building the ironic python package. The files are included in the path ``etc/ironic`` relative to the root of where ironic is installed. ironic-10.1.1/releasenotes/notes/get-supported-boot-devices-manadatory-task-0462fc072d6ea517.yaml0000666000175100017510000000032213243617464032227 0ustar zuulzuul00000000000000--- upgrade: - The `task` parameter to `ManagementInterface.get_supported_boot_devices` was previously deprecated as optional, and is now mandatory for all implementations of ManagementInterface. ironic-10.1.1/releasenotes/notes/emit-metrics-for-api-calls-69f18fd1b9d54b05.yaml0000666000175100017510000000025213243617464027077 0ustar zuulzuul00000000000000--- features: - Ironic now emits timing metrics for all API methods to statsd, if enabled by the ``[metrics]`` and ``[metrics_statsd]`` configuration sections. ironic-10.1.1/releasenotes/notes/oslopolicy-scripts-bdcaeaf7dd9ce2ac.yaml0000666000175100017510000000125113243617464026433 0ustar zuulzuul00000000000000--- features: - | Ironic is now configured to work with two oslo.policy CLI scripts that have been added. The first of these can be called like ``oslopolicy-list-redundant --namespace ironic`` and will output a list of policy rules in policy.[json|yaml] that match the project defaults. These rules can be removed from the policy file as they have no effect there. The second script can be called like ``oslopolicy-policy-generator --namespace ironic --output-file policy-merged.yaml`` and will populate the policy-merged.yaml file with the effective policy. This is the merged results of project defaults and config file overrides. ironic-10.1.1/releasenotes/notes/add-oneview-driver-96088bf470b16c34.yaml0000666000175100017510000000020613243617464025375 0ustar zuulzuul00000000000000--- features: - Adds `agent_pxe_oneview` and `iscsi_pxe_oneview` drivers for integration with the HP OneView Management System. ironic-10.1.1/releasenotes/notes/add-pxe-support-for-petitboot-50d1fe4e7da4bfba.yaml0000666000175100017510000000035513243617464030162 0ustar zuulzuul00000000000000--- features: - Adds the use of DHCP option 210 (tftp-path-prefix). This enables PXE for systems using petitboot, which cannot infer their tftp-path-prefix from the boot file location as petitboot does not use a boot file. ironic-10.1.1/releasenotes/notes/dynamic-allocation-spt-has-physical-mac-8967a1d926ed9301.yaml0000666000175100017510000000057313243617464031413 0ustar zuulzuul00000000000000--- upgrade: - The minimum version of python-oneviewclient is now 2.5.2. fixes: - A validation step is added to verify that the Server Profile Template's MAC type is set to Physical when dynamic allocation is enabled. The OneView Driver needs this verification because the machine is going to use a MAC that will only be specified at the profile application. ironic-10.1.1/releasenotes/notes/new_capabilities-5241619c4b46a460.yaml0000666000175100017510000000137713243617464025123 0ustar zuulzuul00000000000000--- features: - | Adds support for the following Boolean capabilities keys to the ``ilo`` inspect interface: * ``sriov_enabled`` * ``has_ssd`` * ``has_rotational`` * ``rotational_drive_4800_rpm`` * ``rotational_drive_5400_rpm`` * ``rotational_drive_7200_rpm`` * ``rotational_drive_10000_rpm`` * ``rotational_drive_15000_rpm`` * ``logical_raid_level_0`` * ``logical_raid_level_1`` * ``logical_raid_level_2`` * ``logical_raid_level_10`` * ``logical_raid_level_5`` * ``logical_raid_level_6`` * ``logical_raid_level_50`` * ``logical_raid_level_60`` * ``cpu_vt`` * ``hardware_supports_raid`` * ``has_nvme_ssd`` * ``nvdimm_n`` * ``logical_nvdimm_n`` * ``persistent_memory`` ironic-10.1.1/releasenotes/notes/fix-boot-from-volume-for-iscsi-deploy-71c1f2905498c50d.yaml0000666000175100017510000000072113243617464031065 0ustar zuulzuul00000000000000--- fixes: - | Fixes an issue in boot from volume for a node with the ``iscsi`` deploy interface. It would fail if no ``image_source`` was provided in the node's ``instance_info`` field because it would try to validate the ``image_source`` which didn't exist. There is no need to specify the ``image_source`` and the validation is no longer being attempted. See `bug 1714147 `_ for details. ironic-10.1.1/releasenotes/notes/drac-fix-double-manage-provide-cycle-6ac8a427068f87fe.yaml0000666000175100017510000000063013243617464031012 0ustar zuulzuul00000000000000--- fixes: - Fixes an issue that caused a node using a Dell EMC integrated Dell Remote Access Controller (iDRAC) *classic driver*, ``pxe_drac`` or ``pxe_drac_inspector``, to be placed in the ``clean failed`` state after a double ``manage``/``provide`` cycle, instead of the ``available`` state. For more information, see `bug 1676387 `_. ironic-10.1.1/releasenotes/notes/inspector-for-cisco-bffe1d1af7aec677.yaml0000666000175100017510000000011013243617464026223 0ustar zuulzuul00000000000000--- features: - Enabled Inspector Inspection for CIMC and UCS drivers ironic-10.1.1/releasenotes/notes/add-timeout-parameter-to-power-methods-5f632c936497685e.yaml0000666000175100017510000000036513243617464031257 0ustar zuulzuul00000000000000--- other: - | The ironic-conductor expects that all PowerInterface's set_power_state() and reboot() methods accept a ``timeout`` parameter. Any out-of-tree implementations that don't, will cause TypeError exceptions to be raised. ironic-10.1.1/releasenotes/notes/remove-deprecated-dhcp-provider-methods-582742f3000be3c7.yaml0000666000175100017510000000115613243617464031473 0ustar zuulzuul00000000000000--- upgrade: - | Removes these deprecated methods from the neutron DHCP provider built into ironic: * create_cleaning_ports * delete_cleaning_ports Removes these related methods from ``ironic.drivers.modules.deploy_utils``: * prepare_cleaning_ports * tear_down_cleaning_ports If you have your own custom ironic DHCP provider that implements cleaning methods, you may need to update your code to use the ``add_cleaning_network()`` and ``remove_cleaning_network()`` network interface methods. See the modules in ``ironic/drivers/modules/network/`` for more information. ironic-10.1.1/releasenotes/notes/pin-api-version-029748f7d3be68d1.yaml0000666000175100017510000000055513243617464025020 0ustar zuulzuul00000000000000--- upgrade: - | During a `rolling upgrade `_ when the new services are pinned to the old release, the Bare Metal API version will also be pinned to the old release. This will prevent new features from being accessed until after the upgrade is done. ironic-10.1.1/releasenotes/notes/inspector-session-179f83cbb0dc169b.yaml0000666000175100017510000000050413243617464025607 0ustar zuulzuul00000000000000--- fixes: - Ironic Inspector inspection interface will now fetch the service endpoint for the service catalog, if "service_url" is not provided and keystone support is enabled. upgrade: - Minimum required version of python-ironic-inspector-client was bumped to 1.5.0 (released as part of the Mitaka cycle). ironic-10.1.1/releasenotes/notes/oneview-timeout-power-db5125e05831d925.yaml0000666000175100017510000000024113243617464026163 0ustar zuulzuul00000000000000--- features: - | Adds support for ``timeout`` parameter when powering on/off or rebooting a bare metal node managed by the ``oneview`` hardware type. ironic-10.1.1/releasenotes/notes/remove-messaging-aliases-0a6ba1ed392b1fed.yaml0000666000175100017510000000040613243617464027132 0ustar zuulzuul00000000000000--- upgrade: - | Removes old messaging transport aliases. These are listed below with the new value that should be used. * ``ironic.rpc.impl_kombu`` -> ``rabbit`` * ``ironic.rpc.impl_qpid`` -> ``qpid`` * ``ironic.rpc.impl_zmq`` -> ``zmq`` ironic-10.1.1/releasenotes/notes/sort_key_allowed_field-091f8eeedd0a2ace.yaml0000666000175100017510000000036713243617464027051 0ustar zuulzuul00000000000000--- fixes: - | When returning lists of nodes, port groups, or ports, checks the sort key to make sure the field is available in the requested API version. A 406 (Not Acceptable) HTTP status is returned if the field is not available. ironic-10.1.1/releasenotes/notes/conductor_early_import-fd29fa8b89089977.yaml0000666000175100017510000000032213243617464026601 0ustar zuulzuul00000000000000--- fixes: - Fixes a bug which prevented the ironic-conductor service from using the interval values from the configuration options, for the periodic tasks. Instead, the default values had been used. ironic-10.1.1/releasenotes/notes/disk-label-capability-d36d126e0ad36dca.yaml0000666000175100017510000000026313243617464026313 0ustar zuulzuul00000000000000--- features: - Add support for a new capability called 'disk_label' to allow operators to choose the disk label that will be used when Ironic is partitioning the disk. ironic-10.1.1/releasenotes/notes/fix-vif-detach-fca221f1a1c0e9fa.yaml0000666000175100017510000000027213243617464025036 0ustar zuulzuul00000000000000--- fixes: - An issue when it was impossible to detach manually attached VIF to port (port.extra) when port is in portgroup by using DELETE ``v1/nodes//vifs`` API. ironic-10.1.1/releasenotes/notes/add-chassis_uuid-removal-possibility-8b06341a91f7c676.yaml0000666000175100017510000000026113243617464031130 0ustar zuulzuul00000000000000--- features: - Adds support for removing the chassis UUID associated with a node (via ``PATCH /v1/nodes/``). This is available starting with API version 1.25. ironic-10.1.1/releasenotes/notes/remove-manage-tftp-0c2f4f417b92b1ee.yaml0000666000175100017510000000022513243617464025607 0ustar zuulzuul00000000000000--- upgrade: - Removes deprecated option "[agent]/manage_tftp". Configuration files should instead use the "[agent]/manage_agent_boot" option. ironic-10.1.1/releasenotes/notes/futurist-e9c55699f479f97a.yaml0000666000175100017510000000132313243617464023707 0ustar zuulzuul00000000000000--- prelude: > This release features switch to Oslo Futurist library for asynchronous thread execution and periodic tasks. Main benefit is that periodic tasks are now executed truly in parallel, and not sequentially in one green thread. upgrade: - Configuration option "workers_pool_size" can no longer be less or equal to 2. Please set it to greater value (the default is 100) before update. deprecations: - Configuration option "periodic_interval" is deprecated. - Using "driver_periodic_task" decorator is deprecated. Please update your out-of-tree drivers to use "periodics.periodic" decorator from Futurist library. fixes: - Periodic tasks are no longer executed all in one thread. ironic-10.1.1/releasenotes/notes/soft-power-operations-oneview-e7ac054668235998.yaml0000666000175100017510000000016113243617464027576 0ustar zuulzuul00000000000000--- features: - | Enables support for soft power off and soft reboot in the ``oneview`` hardware type. ironic-10.1.1/releasenotes/notes/add-tooz-dep-85c56c74733a222d.yaml0000666000175100017510000000027113243617464024167 0ustar zuulzuul00000000000000--- upgrade: - | Adds a new dependency on the `tooz library `_, as the consistent hash ring code was moved out of ironic and into tooz. ././@LongLink0000000000000000000000000000015200000000000011213 Lustar 00000000000000ironic-10.1.1/releasenotes/notes/remove-deprecated-ilo-clean-priority-erase-devices-bb3073da562ed41d.yamlironic-10.1.1/releasenotes/notes/remove-deprecated-ilo-clean-priority-erase-devices-bb3073da562ed41d0000666000175100017510000000035113243617464032772 0ustar zuulzuul00000000000000--- upgrade: - | The configuration option ``[ilo]/clean_priority_erase_devices`` was deprecated in the Newton cycle (6.1.0). It is no longer supported. Please use the option ``[deploy]/erase_devices_priority`` instead. ironic-10.1.1/releasenotes/notes/added-redfish-driver-00ff5e3f7e9d6ee8.yaml0000666000175100017510000000100213243617464026164 0ustar zuulzuul00000000000000--- features: - | Adds support for the `Redfish `_ standard via a new ``redfish`` hardware type. (There is no equivalent "classic" driver for this.) It uses two new interfaces: * ``redfish`` power interface supports all hard and soft power operations * ``redfish`` management interface supports: - getting and setting the boot device (PXE, disk, CD-ROM or BIOS) - making the configured boot device persistent or not - injecting NMI ironic-10.1.1/releasenotes/notes/vif-detach-locking-fix-7be66f8150e19819.yaml0000666000175100017510000000057713243617464026151 0ustar zuulzuul00000000000000--- fixes: - | Addresses a condition where the Compute Service may have been unable to remove VIF attachment records while a baremetal node is being unprovisiond. This condition resulted in VIF records being orphaned, blocking future deployments without manual intervention. See `bug 1743652 `_ for more details. ironic-10.1.1/releasenotes/notes/soft-reboot-poweroff-9fdb0a4306dd668d.yaml0000666000175100017510000000057213243617464026216 0ustar zuulzuul00000000000000--- features: - Adds support for soft reboot and soft power off requests in REST API version 1.27. Also adds an optional ``timeout`` parameter to the node power state API. Adds a new configuration option ``[conductor]/soft_power_off_timeout`` to define the default timeout for soft power actions. In 7.0.0, this is supported for ipmitool and iRMC drivers. ironic-10.1.1/releasenotes/notes/ilo-inconsistent-default-boot-mode-ef5a7c56372f89f1.yaml0000666000175100017510000000100513243617464030661 0ustar zuulzuul00000000000000--- fixes: - When no boot mode is explicitly set on a node using an iLO driver, ironic automatically picks a boot mode based on hardware capabilities. This confuses deployers, as these factors are system specific and not configurable. In order to ensure predictable behavior, a new configuration parameter, ``[ilo]/default_boot_mode``, was added to allow deployers to explicitly set a default. The default value of this option keeps behavior consistent for existing deployments. ironic-10.1.1/releasenotes/notes/debug-no-api-tracebacks-a8a0caddc9676b06.yaml0000666000175100017510000000034413243617464026544 0ustar zuulzuul00000000000000--- upgrade: - Adds a config option 'debug_tracebacks_in_api' to allow the API service to return tracebacks in API responses in an error condition. fixes: - No longer returns tracebacks for API errors in debug mode. ironic-10.1.1/releasenotes/notes/add-port-advanced-net-fields-55465091f019d962.yaml0000666000175100017510000000057613243617464027064 0ustar zuulzuul00000000000000--- features: - | Exposes the ``local_link_connection`` and ``pxe_enabled`` properties of the Port resource to the REST API, raising the API maximum version to 1.19. * The ``pxe_enabled`` field indicates whether this Port should be used when PXE booting this Node. * The ``local_link_connection`` field may be used to supply the port binding profile. ironic-10.1.1/releasenotes/notes/heartbeat_agent_version-70f4e64b19b51d87.yaml0000666000175100017510000000072513243617464026654 0ustar zuulzuul00000000000000--- other: - The agent heartbeat API (POST ``/v1/heartbeat/``) can now receive a new ``agent_version`` parameter. If received, this will be stored in the node's ``driver_internal_info['agent_version']`` field. This information will be used by the Bare Metal service to gracefully degrade support for agent features that are requested by the Bare Metal service, ensuring that we don't request a feature that an older ramdisk doesn't support. ironic-10.1.1/releasenotes/notes/fix-policy-checkers-1a08203e3c2cf859.yaml0000666000175100017510000000017613243617464025626 0ustar zuulzuul00000000000000--- fixes: - Fixes a bug where some of the API methods were not using the right context values for checking the policy. ironic-10.1.1/releasenotes/notes/remove-ipminative-driver-3367d25bbcc41fdc.yaml0000666000175100017510000000035513243617464027125 0ustar zuulzuul00000000000000upgrade: - | The agent_pyghmi, pxe_ipminative, and fake_ipminative drivers have all been removed from ironic due to lack of testing. Nodes using these drivers should be changed to the agent_ipmitool or pxe_ipmitool driver. ironic-10.1.1/releasenotes/notes/fix-mac-address-48060f9e2847a38c.yaml0000666000175100017510000000011713243617464024657 0ustar zuulzuul00000000000000--- fixes: - This fixes InvalidMAC exception of iRMC out-of-band inspection. ironic-10.1.1/releasenotes/notes/amt-driver-wake-up-0880ed85476968be.yaml0000666000175100017510000000110113243617464025336 0ustar zuulzuul00000000000000--- upgrade: - Adds a config [amt]awake_interval for the interval to wake up the AMT interface for a node. This should correspond to the IdleTimeout config option on the AMT interface. Setting to 0 will disable waking the AMT interface, just like setting IdleTimeout=0 on the AMT interface will disable the AMT interface from sleeping when idle. fixes: - Fixes an issue with talking to a sleeping AMT interface by waking up the interface before sending commands, if needed. This is configured with the [amt]awake_interval config option. ironic-10.1.1/releasenotes/notes/portgroup-crud-notifications-91204635528972b2.yaml0000666000175100017510000000046213243617464027327 0ustar zuulzuul00000000000000--- features: - | Adds notifications for creation, updates, or deletions of port groups. Event types are formatted as follows: * baremetal.portgroup.{create, update, delete}.{start,end,error} Also adds portgroup_uuid field to port notifications, port payload version bumped to 1.1. ironic-10.1.1/releasenotes/notes/opentack-baremetal-request-id-daa72b785eaaaa8d.yaml0000666000175100017510000000013113243617464030142 0ustar zuulzuul00000000000000--- features: - Append request_id as ``Openstack-Request-Id`` header to the response. ironic-10.1.1/releasenotes/notes/.placeholder0000666000175100017510000000000013243617464021207 0ustar zuulzuul00000000000000ironic-10.1.1/releasenotes/notes/oneview-node-free-for-ironic-61b05fee827664cb.yaml0000666000175100017510000000017113243617464027425 0ustar zuulzuul00000000000000--- fixes: - Fixes an issue with ironic being able to change the power state of nodes currently in use by OneView. ironic-10.1.1/releasenotes/notes/conductor-version-backfill-9d06f2ad81aebec3.yaml0000666000175100017510000000027513243617464027507 0ustar zuulzuul00000000000000--- upgrade: - | The ``conductors`` database table's ``version`` column is populated as part of the data migration (via the command ``ironic-dbsync online_data_migrations``). ironic-10.1.1/releasenotes/notes/fix-boot-from-volume-for-iscsi-deploy-60bc0790ada62b26.yaml0000666000175100017510000000062113243617464031204 0ustar zuulzuul00000000000000--- fixes: - | Fixes an issue in boot from volume for ``iscsi`` deploy interface. Booting from a volume would fail for a node with the ``iscsi`` deploy interface because the pxelinux.cfg file for the MAC address wasn't created and the node would fail to boot. The pxelinux.cfg file is now created. See `bug 1714436 `_ for details. ironic-10.1.1/releasenotes/notes/root-device-hints-rotational-c21f02130394e1d4.yaml0000666000175100017510000000014413243617464027373 0ustar zuulzuul00000000000000--- features: - Extend the root device hints to identify whether a disk is rotational or not. ironic-10.1.1/releasenotes/notes/add-agent-api-error-77ec6c272390c488.yaml0000666000175100017510000000025013243617464025433 0ustar zuulzuul00000000000000--- fixes: - Fixes propagation of HTTP errors from **ironic-python-agent** commands. Now an operation is aborted on receiving HTTP error status from the ramdisk. ironic-10.1.1/releasenotes/notes/enable-osprofiler-support-e3839b0fa90d3831.yaml0000666000175100017510000000135313243617464027104 0ustar zuulzuul00000000000000--- features: - | Adds `OSProfiler `_ support. This cross-project profiling library provides the ability to trace various OpenStack requests through all OpenStack services that support it. For more information, see https://docs.openstack.org/ironic/latest/contributor/osprofiler-support.html. security: - | `OSProfiler `_ support requires passing of trace information between various OpenStack services. This information is securely signed by one of the HMAC keys, defined in the ``ironic.conf`` configuration file. To allow cross-project tracing, the same key should be used for all OpenStack services. ././@LongLink0000000000000000000000000000016100000000000011213 Lustar 00000000000000ironic-10.1.1/releasenotes/notes/drac-fix-get_bios_config-vendor-passthru-causes-exception-1e1dbeeb3e924f29.yamlironic-10.1.1/releasenotes/notes/drac-fix-get_bios_config-vendor-passthru-causes-exception-1e1dbeeb30000666000175100017510000000051213243617464033542 0ustar zuulzuul00000000000000--- fixes: - Fixes an issue which caused the DRAC driver (``pxe_drac``) ``get_bios_config()`` vendor passthru method to unintentionally raise an ``AttributeError`` exception. That method once again returns the current BIOS configuration. For more information, see https://bugs.launchpad.net/ironic/+bug/1637671. ironic-10.1.1/releasenotes/notes/resource-class-change-563797d5a3c35683.yaml0000666000175100017510000000100413243617464026005 0ustar zuulzuul00000000000000--- upgrade: - | Changing the ``resource_class`` field of a node in the ``active`` state or any of the transient states is no longer possible. Please update your scripts to only set a resource class for nodes that are not deployed to. Setting a resource class for nodes that do not have it is still possible. fixes: - | No longer allows changing the ``resource_class`` field for ``active`` nodes if it was already set to a non-empty value. Doing so would break the Compute scheduler. ironic-10.1.1/releasenotes/notes/mask-ssh-creds-54ab7b2656578d2e.yaml0000666000175100017510000000016613243617464024615 0ustar zuulzuul00000000000000--- security: - Private SSH keys are now masked when using the SSH power driver and node details are requested. ironic-10.1.1/releasenotes/notes/manual-clean-4cc2437be1aea69a.yaml0000666000175100017510000000031713243617464024526 0ustar zuulzuul00000000000000--- features: - Adds support for manual cleaning. This is available with API version 1.15. For more information, see http://docs.openstack.org/developer/ironic/deploy/cleaning.html#manual-cleaning ironic-10.1.1/releasenotes/notes/deprecated-inspector-opts-b19a08339712cfd7.yaml0000666000175100017510000000146713243617464027060 0ustar zuulzuul00000000000000--- deprecations: - | Configuration option ``[inspector]/service_url`` is deprecated and will be ignored in the Rocky release. Instead, use ``[inspector]/endpoint_override`` configuration option to set the specific ironic-inspector API endpoint when its automatic discovery from the keystone catalog is not desired. This new option has no default value (``None``) and must be set explicitly. - | Relying on the value of ``[DEFAULT]/auth_strategy`` configuration option to configure usage of standalone mode for ironic-inspector is deprecated and will be impossible the Rocky release. Instead, set ``[inspector]/auth_type`` configuration option to ``none`` and provide the ironic-inspector inspector API address as ``[inspector]/endpoint_override`` configuration option. ironic-10.1.1/releasenotes/notes/deprecate-agent-passthru-67d1e2cf25b30a30.yaml0000666000175100017510000000041113243617464026714 0ustar zuulzuul00000000000000--- deprecations: - Agent vendor passthru is deprecated and will be removed in Ocata release. Operators should update their IPA image to the Newton version to use the new replacement API. Driver developers should stop using the agent vendor passthru. ironic-10.1.1/releasenotes/notes/irmc-oob-inspection-6d072c60f6c88ecb.yaml0000666000175100017510000000011013243617464025774 0ustar zuulzuul00000000000000--- features: - Adds out-of-band inspection support for iRMC drivers. ironic-10.1.1/releasenotes/notes/remove-discoverd-group-03eaf75e9f94d7be.yaml0000666000175100017510000000024413243617464026624 0ustar zuulzuul00000000000000--- upgrade: - Removes support for the deprecated "discoverd" group for inspection options. Configuration files should use the "inspector" group instead. ironic-10.1.1/releasenotes/notes/irmc-add-clean-step-reset-bios-config-a8bed625670b7fdf.yaml0000666000175100017510000000165013243617464031236 0ustar zuulzuul00000000000000--- features: - Adds new boot interface named ``irmc-pxe`` for PXE booting FUJITSU PRIMERGY servers. - Adds clean step ``restore_irmc_bios_config`` to restore BIOS config for a node with an ``irmc``-based driver during automatic cleaning. upgrade: - Adds new configuration option ``[irmc]clean_priority_restore_irmc_bios_config``, which enables setting priority for the ``restore_irmc_bios_config`` clean step. The default value for this option is 0, which means the clean step is disabled. deprecations: - The use of the ``pxe`` boot interface with the ``irmc`` hardware type has been deprecated. It is recommended to switch to the new ``irmc-pxe`` boot interface as soon as possible. issues: - The ``restore_irmc_bios_config`` clean step does not work for nodes using the ``pxe`` boot interface with the ``irmc`` hardware type. The ``irmc-pxe`` boot interface has to be used instead. ironic-10.1.1/releasenotes/notes/mask-configdrive-contents-77fc557d6bc63b2b.yaml0000666000175100017510000000201013243617464027201 0ustar zuulzuul00000000000000--- features: - Adds a new policy rule that may be used to mask instance-specific secrets, such as configdrive contents or the temp URL used to store a configdrive or instance image. This is similar to how passwords are already masked. upgrade: - Instance secrets will now, by default, be masked in API responses. Operators wishing to expose the configdrive or instance image to specific users will need to update their policy.json file and grant the relevant keystone roles. security: - Configdrives often contain sensitive information. Users may upload their own images, which could also contain sensitive information. The Agent drivers may store this information in a Swift temp URL to allow access from the Agent ramdisk. These URLs are considered sensitive information because they grant unauthenticated access to sensitive information. Now, we only selectively expose this information to privileged users, whereas previously it was exposed to all authenticated users. ironic-10.1.1/releasenotes/notes/add-agent-iboot-0a4b5471c6ace461.yaml0000666000175100017510000000017013243617464024760 0ustar zuulzuul00000000000000--- features: - Adds an `agent_iboot` driver to allow use of the Iboot power driver with the Agent deploy driver. ironic-10.1.1/releasenotes/notes/ipminative-bootdev-uefi-954a0dd825bcef97.yaml0000666000175100017510000000044513243617464026667 0ustar zuulzuul00000000000000--- fixes: - Fixes a problem where the boot mode (UEFI or BIOS) wasn't being considered when setting the boot device of a node using the "ipminative" management interface. It would incorrectly switch UEFI to legacy BIOS mode as part of the request to change the boot device. ironic-10.1.1/releasenotes/notes/raid-to-support-jbod-568f88207b9216e2.yaml0000666000175100017510000000011013243617464025611 0ustar zuulzuul00000000000000--- features: - Added support for JBOD volumes in RAID configuration. ironic-10.1.1/releasenotes/notes/add-storage-interface-d4e64224804207fc.yaml0000666000175100017510000000034513243617464026026 0ustar zuulzuul00000000000000--- features: - | Adds the initial substrate to allow for the creation of storage interfaces. The default storage interface for nodes is ``noop``, which routes to a no-op driver that is included with the substrate. ironic-10.1.1/releasenotes/notes/drac-fix-prepare-cleaning-d74ba45135d84531.yaml0000666000175100017510000000016113243617464026601 0ustar zuulzuul00000000000000--- fixes: - Fixes DRAC deploy interface failure when automated cleaning is called without any clean step. ironic-10.1.1/releasenotes/notes/scciclient-0.4.0-6f01c0f0a5c39062.yaml0000666000175100017510000000017113243617464024516 0ustar zuulzuul00000000000000--- upgrade: - The minimum required version of python-scciclient (needed for the iRMC driver) was bumped to 0.4.0. ironic-10.1.1/releasenotes/notes/add-dynamic-allocation-feature-2fd6b4df7943f178.yaml0000666000175100017510000000217613243617464030012 0ustar zuulzuul00000000000000--- features: - OneView drivers now support dynamic allocation of nodes in OneView, allowing for better resource sharing with non-OpenStack users since Server Hardware will be allocated only when the node is scheduled to be used. To enable the new allocation feature for a node, set the flag ``dynamic_allocation=True`` on the node's ``driver_info``. More information is available at http://docs.openstack.org/developer/ironic/drivers/oneview.html. deprecations: - Deprecates pre-allocation feature for the OneView drivers since it requires resource allocation to Ironic prior to boot time, which makes Server Hardware unavailable to non-OpenStack OneView users. Pre-allocation will be removed in the OpenStack Pike release. All nodes with ``dynamic_allocation=False`` set, or that don't have the ``dynamic_allocation`` flag set, will be assumed to be in pre-allocation. Users may use the REST API or the ``ironic-oneview-cli`` to migrate nodes from pre-allocation to dynamic allocation. More information is available at http://docs.openstack.org/developer/ironic/drivers/oneview.html. ironic-10.1.1/releasenotes/notes/disk-label-fix-7580de913835ff44.yaml0000666000175100017510000000020013243617464024500 0ustar zuulzuul00000000000000--- fixes: - Fixes the bug where the user specified disk_label is ignored for the agent drivers for partition images. ironic-10.1.1/releasenotes/notes/volume-connector-and-target-api-dd172f121ab3af8e.yaml0000666000175100017510000000473213243617464030265 0ustar zuulzuul00000000000000--- features: - | Adds support for volume connectors and volume targets with new API endpoints ``/v1/volume/connectors`` and ``/v1/volume/targets``. These endpoints are available with API version 1.32 or later. These new resources are used to connect a node to a volume. A volume connector represents connector information of a node such as an iSCSI initiator. A volume target provides volume information such as an iSCSI target. These endpoints are available: * ``GET /v1/volume/connectors`` for listing volume connectors * ``POST /v1/volume/connectors`` for creating a volume connector * ``GET /v1/volume/connectors/`` for showing a volume connector * ``PATCH /v1/volume/connectors/`` for updating a volume connector * ``DELETE /v1/volume/connectors/`` for deleting a volume connector * ``GET /v1/volume/targets`` for listing volume targets * ``POST /v1/volume/targets`` for creating a volume target * ``GET /v1/volume/targets/`` for showing a volume target * ``PATCH /v1/volume/targets/`` for updating a volume target * ``DELETE /v1/volume/targets/`` for deleting a volume target The Volume resources also can be listed as sub resources of nodes: * ``GET /v1/nodes//volume/connectors`` * ``GET /v1/nodes//volume/targets`` Root endpoints of volume resources are also added. These endpoints provide links to volume connectors and volume targets: * ``GET /v1/volume`` * ``GET /v1/node//volume`` When a volume connector or a volume target is created, updated, or deleted, these CRUD notifications can be emitted: * ``baremetal.volumeconnector.create.start`` * ``baremetal.volumeconnector.create.end`` * ``baremetal.volumeconnector.create.error`` * ``baremetal.volumeconnector.update.start`` * ``baremetal.volumeconnector.update.end`` * ``baremetal.volumeconnector.update.error`` * ``baremetal.volumeconnector.delete.start`` * ``baremetal.volumeconnector.delete.end`` * ``baremetal.volumeconnector.delete.error`` * ``baremetal.volumetarget.create.start`` * ``baremetal.volumetarget.create.end`` * ``baremetal.volumetarget.create.error`` * ``baremetal.volumetarget.update.start`` * ``baremetal.volumetarget.update.end`` * ``baremetal.volumetarget.update.error`` * ``baremetal.volumetarget.delete.start`` * ``baremetal.volumetarget.delete.end`` * ``baremetal.volumetarget.delete.error`` ironic-10.1.1/releasenotes/notes/remove-deprecated-option-names-6d5d53cc70dd2d49.yaml0000666000175100017510000000041313243617464030122 0ustar zuulzuul00000000000000--- upgrade: - | In the config section ``[agent]`` two config options were deprecated in the Liberty cycle and they have been removed. The options were named: * ``[agent]/agent_erase_devices_priority`` * ``[agent]/agent_erase_devices_iterations`` ironic-10.1.1/releasenotes/notes/ilo-license-activate-manual-clean-step-84d335998d708b49.yaml0000666000175100017510000000015713243617464031156 0ustar zuulzuul00000000000000--- features: - Support for activation of iLO Advanced license as a manual cleaning step in iLO drivers. ironic-10.1.1/releasenotes/notes/remove-agent_last_heartbeat-65a9fe02f20465c5.yaml0000666000175100017510000000025113243617464027411 0ustar zuulzuul00000000000000--- deprecations: - The ``agent_last_heartbeat`` field of ``driver_internal_info`` has been removed from all agent drivers, since this field was unused by ironic. ironic-10.1.1/releasenotes/notes/snmp-reboot-delay-d18ee3f6c6fc0998.yaml0000666000175100017510000000037713243617464025511 0ustar zuulzuul00000000000000--- upgrade: - Adds a configuration option for the Iboot driver, [iboot]reboot_delay, to allow adding a pause between power off and power on. fixes: - Fixes an issue where some SNMP power controllers will not power back on after a deploy. ironic-10.1.1/releasenotes/notes/ocata-summary-a70f995cb3b18e18.yaml0000666000175100017510000000235713243617464024636 0ustar zuulzuul00000000000000--- prelude: | The 7.0.0 release includes many new features and bug fixes. Please review the upgrade section which describes the required actions to upgrade your ironic installation from 6.2.2 (Newton) to 7.0.0 (Ocata). A few major changes are worth mentioning. This is not an exhaustive list: - "Port group" support allows users to take advantage of bonded network interfaces. - State change and CRUD notifications can now be emitted. - Soft power off, soft reboot, and sending non-maskable interrupts (NMI) are now supported in the REST API. - The AMT, iBoot, msftocs, seamicro, VirtualBox, and Wake-On-Lan drivers have been removed from ironic. Please see the upgrade notes for additional details and options. - "Dynamic drivers" is a revamp of how drivers are composed. Rather than a huge matrix of hardware drivers supporting different things, now users select a "hardware type" for a machine, and can independently change the deploy method, console manager, RAID management, power control interface, etc. This is experimental, as not all "classic" drivers have a dynamic equivalent yet, but we encourage users to try this feature out and submit feedback. ironic-10.1.1/releasenotes/notes/ilo-update-proliantutils-version-fd41a7c2a27be735.yaml0000666000175100017510000000073413243617464030554 0ustar zuulzuul00000000000000--- upgrade: - | Updates required proliantutils version for iLO drivers to 2.4.0. This version of the library comes with quite a few features: * Adds support for Gen10 servers using `Redfish `_ protocol. * Provides support for one-pass disk erase using HPE SSA CLI through Proliant hardware manager in IPA. * ``local_gb`` defaults to 0 (zero) when no disk could be discovered during inspection. ironic-10.1.1/releasenotes/notes/net-names-b8a36aa30659ce2f.yaml0000666000175100017510000000134013243617464024001 0ustar zuulzuul00000000000000--- features: - Names can now be used instead of UUIDs for ``[neutron]/cleaning_network`` and ``[neutron]/provisioning_network`` configuration options (formerly called ``[neutron]/cleaning_network_uuid`` and ``[neutron]/provisioning_network_uuid``). Care has to be taken to ensure that the names are unique among all networks in this case. Note that the mapping between a name and a UUID is cached for the lifetime of the conductor. deprecations: - Configuration options ``[neutron]/cleaning_network_uuid`` and ``[neutron]/provisioning_network_uuid`` are deprecated in favor of the new configuration options ``[neutron]/cleaning_network`` and ``[neutron]/provisioning_network`` respectively. ironic-10.1.1/releasenotes/notes/remove-periodic-interval-45f57ebad9aaa14e.yaml0000666000175100017510000000011313243617464027162 0ustar zuulzuul00000000000000--- upgrade: - Removes the deprecated config option "periodic_interval". ironic-10.1.1/releasenotes/notes/removed-glance-host-port-protocol-dc6e682097ba398f.yaml0000666000175100017510000000060113243617464030537 0ustar zuulzuul00000000000000--- upgrade: - | Deprecated options ``glance_host``, ``glance_port`` and ``glance_protocol`` from ``[glance]`` section of ironic configuration file were removed and will be ignored. Please use ``[glance]/glance_api_servers`` options to provide specific addresses for the Image service endpoint when its discovery from keystone service catalog is not desired. ironic-10.1.1/releasenotes/notes/add-db-deadlock-handling-6bc10076537f3727.yaml0000666000175100017510000000112513243617464026260 0ustar zuulzuul00000000000000--- fixes: - Fixes an issue which caused conductor's periodic tasks to stop executing. See https://bugs.launchpad.net/ironic/+bug/1637210. features: - Adds DBDeadlock handling which may improve stability when using Galera. See https://bugs.launchpad.net/ironic/+bug/1639338. Number of retries depends on the configuration option ``[database]db_max_retries``. upgrade: - All DB API methods doing database writes now retry on deadlock. The ``[database]db_max_retries`` configuration option specifies the maximum number of times to retry, and can be customised if necessary.ironic-10.1.1/releasenotes/notes/bug-1694645-57289200e35bd883.yaml0000666000175100017510000000103213243617464023237 0ustar zuulzuul00000000000000--- fixes: - | Fixes netboot with virtual media boot in an environment using syslinux 5.00 or later, such as Ubuntu 16.04. It was broken by a change in the location of the ``ldlinux.c32`` file. features: - | New configuration option ``[DEFAULT]/ldlinux_32`` can be used to set the location of the ``ldlinux.c32`` file (from the syslinux package). The default behavior is to look for it in the following locations: * ``/usr/lib/syslinux/modules/bios/ldlinux.c32`` * ``/usr/share/syslinux/ldlinux.c32`` ironic-10.1.1/releasenotes/notes/ipmitool-vendor-3f0f52240ebbe489.yaml0000666000175100017510000000021113243617464025157 0ustar zuulzuul00000000000000--- features: - | The ``ipmi`` hardware type now supports ``ipmitool`` vendor interface (similar to classic ipmitool drivers). ironic-10.1.1/releasenotes/notes/inspector-enabled-f8a643f03e1e0360.yaml0000666000175100017510000000045413243617464025351 0ustar zuulzuul00000000000000--- upgrade: - | The ``[inspector]/enabled`` configuration option no longer has effect on the ``fake_inspector`` driver. It will also not have effect on new-style dynamic drivers based on hardware types; it will be necessary to use ``[DEFAULT]/enabled_inspect_interfaces`` instead. ironic-10.1.1/releasenotes/notes/ipxe-uefi-f5be11c7b0606a84.yaml0000666000175100017510000000025413243617464023724 0ustar zuulzuul00000000000000--- fixes: - Fixes bug where ironic reboots the node with deploy image instead of the user image during second reboot in uefi boot mode when ipxe is enabled. ironic-10.1.1/releasenotes/notes/fix-clean-steps-not-running-0d065cb022bc0419.yaml0000666000175100017510000000056713243617464027220 0ustar zuulzuul00000000000000--- prelude: > A major bug was fixed where clean steps do not run. critical: - This fixes a bug where Ironic skipped all clean steps, which may leave the previous tenant's data on disk available to new users. security: - This fixes a bug where Ironic skipped all clean steps, which may leave the previous tenant's data on disk available to new users. ironic-10.1.1/releasenotes/notes/release-4.3.0-cc531ab7190f8a00.yaml0000666000175100017510000000016313243617464024101 0ustar zuulzuul00000000000000--- prelude: > Ironic's 4.3.0 release brings a number of new features, driver enhancements, and bug fixes. ironic-10.1.1/releasenotes/notes/add-port-internal-info-b7e02889416570f7.yaml0000666000175100017510000000043013243617464026106 0ustar zuulzuul00000000000000--- features: - A new dictionary field ``internal_info`` is added to the port API object. It is readonly from the API side, and can contain any internal information ironic needs to store for the port. ``cleaning_vif_port_id`` is being stored inside this dictionary. ironic-10.1.1/releasenotes/notes/clean-nodes-stuck-in-cleaning-on-startup-443823ea4f937965.yaml0000666000175100017510000000032713243617464031453 0ustar zuulzuul00000000000000--- fixes: - When a conductor managing a node dies mid-cleaning the node would get stuck in the CLEANING state. Now upon conductor startup nodes in the CLEANING state will be moved to the CLEANFAIL state. ././@LongLink0000000000000000000000000000015500000000000011216 Lustar 00000000000000ironic-10.1.1/releasenotes/notes/fix-ilo-firmware-update-swift-path-with-pseudo-folder-0660345510ec0bb4.yamlironic-10.1.1/releasenotes/notes/fix-ilo-firmware-update-swift-path-with-pseudo-folder-0660345510ec00000666000175100017510000000023513243617464032570 0ustar zuulzuul00000000000000--- fixes: - Fixes an issue where iLO drivers fail to download the firmware file from swift when the swift file path includes swift pseudo folder. ironic-10.1.1/releasenotes/notes/pass_portgroup_settings_to_neutron-a6aec830a82c38a3.yaml0000666000175100017510000000034013243617464031367 0ustar zuulzuul00000000000000--- features: - Port group information (``mode`` and ``properties`` fields) is now passed to Neutron via the port's ``binding:profile`` field. This allows an ML2 driver to configure the port bonding automatically. ironic-10.1.1/releasenotes/notes/ipxe_retry_on_failure-e71fc6b3e9a5be3b.yaml0000666000175100017510000000036213243617464026656 0ustar zuulzuul00000000000000--- features: - ipxe will now retry to download the kernel or the initrd in case of failure. The previous behavior was to give up and continue the boot on the next boot device. See https://bugs.launchpad.net/ironic/+bug/1326656 ironic-10.1.1/releasenotes/notes/always-return-chassis-uuid-4eecbc8da2170cb1.yaml0000666000175100017510000000034313243617464027456 0ustar zuulzuul00000000000000--- fixes: - Fixed an issue of not returning ``chassis_uuid`` field of a node in API responses if it does not belong to a chassis. It should be always returned, either set to None, or to a corresponding chassis UUID. ironic-10.1.1/releasenotes/notes/bug-1611556-92cbfde5ee7f44d6.yaml0000666000175100017510000000006613243617464023701 0ustar zuulzuul00000000000000--- features: - Adds timing metrics to iRMC drivers.ironic-10.1.1/releasenotes/notes/ilo-boot-interface-92831b78c5614733.yaml0000666000175100017510000000010313243617464025223 0ustar zuulzuul00000000000000--- other: - iLO drivers are now based on the new BootInterface. ironic-10.1.1/releasenotes/notes/add-agent-proxy-support-790e629634ca2eb7.yaml0000666000175100017510000000217213243617464026505 0ustar zuulzuul00000000000000--- features: - Pass proxy information from agent driver to IPA ramdisk, so that images can be cached on the proxy server. issues: - When using caching proxy with ``agent_*`` drivers, caching the image on the proxy server might involve increasing [glance]swift_temp_url_duration config option value. This way, the cached entry will be valid for a period of time long enough to see the benefits of caching. Large temporary URL duration might become a security issue in some cases. upgrade: - Adds a [glance]swift_temp_url_cache_enabled configuration option to enable Swift temporary URL caching. It is only useful if the caching proxy is used. Also adds [glance]swift_temp_url_expected_download_start_delay, which is used to check if the Swift temporary URL duration is long enough to let the image download to start, and, if temporary URL caching is enabled, to determine if a cached entry will be still valid when download starts. The value of [glance]swift_temp_url_expected_download_start_delay must be less than the value for the [glance]swift_temp_url_duration configuration option. ironic-10.1.1/releasenotes/notes/remove-driver-object-periodic-tasks-1357a1cd3589becf.yaml0000666000175100017510000000016613243617464031075 0ustar zuulzuul00000000000000--- upgrade: - | Removes support for attaching periodic tasks on a driver object, rather than an interface. ironic-10.1.1/releasenotes/notes/drac-fix-oob-cleaning-b4b717895e243c9b.yaml0000666000175100017510000000045413243617464026023 0ustar zuulzuul00000000000000--- fixes: - Fixes `bug 1691808 `_ causing RAID creation/deletion to frequently fail when using the iDRAC driver due to an *Export Configuration* job running. The fix requires the ``python-dracclient`` library of version 1.3.0 or higher. ironic-10.1.1/releasenotes/notes/deprecate-elilo-2beca4800f475426.yaml0000666000175100017510000000045213243617464025011 0ustar zuulzuul00000000000000--- deprecations: - | Support for the ``elilo`` boot loader has been deprecated and will be removed in the Queens release cycle. The elilo boot loader has been orphaned as a project and dropped from the majority of Linux distributions. Please switch to the ``grub2`` boot loader. ironic-10.1.1/releasenotes/notes/name-root-device-hints-a1484ea01e399065.yaml0000666000175100017510000000011113243617464026147 0ustar zuulzuul00000000000000--- features: - Root device hints extended to support the device name. ironic-10.1.1/releasenotes/notes/periodic-tasks-drivers-ae9cddab88b546c6.yaml0000666000175100017510000000030613243617464026662 0ustar zuulzuul00000000000000--- deprecations: - Putting periodic tasks on a driver object (rather than interface) is deprecated. Driver developers should move periodic tasks from driver objects to interface objects. ironic-10.1.1/releasenotes/notes/5.0-release-afb1fbbe595b6bc8.yaml0000666000175100017510000000033713243617464024263 0ustar zuulzuul00000000000000--- prelude: > This release adds support for manual cleaning and RAID configuration. Operators may now manually run clean steps, including setting up RAID on a node, while a node is in the manageable state. ironic-10.1.1/releasenotes/notes/validate-port-info-before-using-it-e26135982d37c698.yaml0000666000175100017510000000025013243617464030336 0ustar zuulzuul00000000000000--- fixes: - Fixes an issue when attaching VIF to a port with missed ``local_link_connection`` field was allowed when node network interface was ``neutron``. ironic-10.1.1/releasenotes/notes/deprecate-dhcp-update-mac-address-f12a4959432c8e20.yaml0000666000175100017510000000166413243617464030217 0ustar zuulzuul00000000000000--- features: - | Adds new methods to network interfaces, which will become mandatory in Pike release: * ``vif_list``: List attached VIF IDs for a node. * ``vif_attach``: Attach a virtual network interface to a node. * ``vif_detach``: Detach a virtual network interface from a node. * ``port_changed``: Handle any actions required when a port changes. * ``portgroup_changed``: Handle any actions required when a port group changes. * ``get_current_vif``: Return VIF ID attached to port or port group object. deprecations: - | ``update_mac_address`` method in the DHCP provider interface is deprecated and will be removed in the Pike release. The logic should be moved to a custom network interface's ``port_changed`` and ``portgroup_changed`` methods. fixes: - | Fixes an issue where a pre-created tenant port was automatically deleted by ironic on instance delete. ironic-10.1.1/releasenotes/notes/remove-verbose-option-261f1b9e24212ee2.yaml0000666000175100017510000000071313243617464026215 0ustar zuulzuul00000000000000--- upgrade: - The 'verbose' configuration option was removed, consequently the "--verbose, -v" parameter from all command lines was also removed. This affects the ironic-api, ironic-conductor, ironic-dbsync, and ironic-rootwrap commands. The verbose config/parameter was originally a shortcut to set the log level to INFO, however the log level has defaulted to INFO since this option was deprecated, so this option was a noop. ironic-10.1.1/releasenotes/notes/multi-arch-deploy-bcf840107fc94bef.yaml0000666000175100017510000000154513243617464025545 0ustar zuulzuul00000000000000--- features: - | Adds support to deploy to nodes with different CPU architectures from a single conductor. This depends on two new configuration options, ``[pxe]/pxe_config_template_by_arch`` and ``[pxe]/pxe_bootfile_name_by_arch``. Each is a dictionary mapping CPU architecture to PXE config template or PXE boot file name, respectively. As an example, the syntax might look like:: pxe_config_template_by_arch=aarch64:pxe_grubaa64_config.template,ppc64:pxe_ppc64_config.template Ironic attempts to map the CPU architecture in this mapping to the ``properties/cpu_arch`` field for a node. If the node's CPU architecture is not found in the mapping, ironic will fall back to the standard options ``pxe_config_template``, ``pxe_bootfile_name``, ``uefi_pxe_config_template``, and ``uefi_pxe_bootfile_name``. ironic-10.1.1/releasenotes/notes/deprecated-glance-opts-4825f000d20c2932.yaml0000666000175100017510000000266313243617464026122 0ustar zuulzuul00000000000000--- deprecations: - | Configuration option ``glance_api_servers`` from the ``[glance]`` section in the configuration file is deprecated and will be ignored in the Rocky release. Instead, use ``[glance]/endpoint_override`` configuration option to set a specific (possibly load-balanced) glance API address when automatic discovery of glance API endpoint from keystone catalog is not desired. This new option defaults to ``None`` and must be set explicitly if needed. This new option is mostly suited for standalone ironic deployments without keystone and its service catalog, and it is generally recommended to rely on keystone service catalog for service endpoint discovery. - | Configuration option ``[glance]/glance_api_insecure`` is deprecated and will be ignored in the Rocky release. Instead, use ``[glance]/insecure`` configuration option (its default is ``False``). - | Configuration option ``[glance]/glance_cafile`` is deprecated and will be ignored in the Rocky release. Instead, use ``[glance]/cafile`` configuration option (its default is ``None``). - | Configuration option ``[glance]/auth_strategy`` is deprecated and will be ignored in the Rocky release. Instead, to setup glance in noauth mode set ``[glance]/auth_type`` configuration option to ``none`` and provide glance API address as ``[glance]/endpoint_override`` configuration option. ironic-10.1.1/releasenotes/notes/fail-when-vif-port-id-is-missing-7640669f9d9e705d.yaml0000666000175100017510000000023513243617464030016 0ustar zuulzuul00000000000000--- fixes: - Fail deployment when no ports or port groups are linked to a node. This is to avoid active nodes not connected to any tenant network. ironic-10.1.1/releasenotes/notes/implement-policy-in-code-cbb0216ef5f8224f.yaml0000666000175100017510000000207613243617464026723 0ustar zuulzuul00000000000000--- features: - | RESTful access to every API resource may now be controlled by adjusting policy settings. Defaults are set in code, and remain backwards compatible with the previously-included policy.json file. Two new roles are checked by default, "baremetal_admin" and "baremetal_observer", though these may be replaced or overridden by configuration. The "baremetal_observer" role grants read-only access to Ironic's API. security: - | Previously, access to Ironic's REST API was "all or nothing". With this release, it is now possible to restrict read and write access to API resources to specific cloud roles. upgrade: - | During an upgrade, it is recommended that all deployers re-evaluate the settings in their ``/etc/ironic/policy.json`` file. This file should now be used only to override default configuration, such as by limiting access to the ironic service to specific tenants or restricting access to specific API endpoints. A ``policy.json.sample`` file is provided that lists all supported policies. ironic-10.1.1/releasenotes/notes/fix-keystone-parameters-cdb93576d7e7885b.yaml0000666000175100017510000000024313243617464026651 0ustar zuulzuul00000000000000--- fixes: - Fixes a multi-region issue where the region specified in the configuration file was ignored when getting the Identity service's (keystone) URL. ironic-10.1.1/releasenotes/notes/ipxe-and-uefi-7722bd5db71df02c.yaml0000666000175100017510000000007413243617464024545 0ustar zuulzuul00000000000000--- features: - Adds support for using iPXE in UEFI mode. ironic-10.1.1/releasenotes/notes/remove-deprecated-dhcp-provider-method-89926a8f0f4793a4.yaml0000666000175100017510000000144313243617464031341 0ustar zuulzuul00000000000000--- upgrade: - | Removes the deprecated DHCP provider method ``update_port_address``. For users who created their own network interfaces or DHCP providers the logic should be moved to a custom network interface's ``port_changed`` and ``portgroup_changed`` methods. The following methods should be implemented by custom network interfaces: * ``vif_list``: List attached VIF IDs for a node. * ``vif_attach``: Attach a virtual network interface to a node. * ``vif_detach``: Detach a virtual network interface from a node. * ``port_changed``: Handle any actions required when a port changes. * ``portgroup_changed``: Handle any actions required when a port group changes. * ``get_current_vif``: Return VIF ID attached to port or port group object. ironic-10.1.1/releasenotes/notes/snmp-driver-udp-transport-settings-67419be988fcff40.yaml0000666000175100017510000000055613243617464031015 0ustar zuulzuul00000000000000--- features: - Adds SNMP request timeout and retries settings for the SNMP UDP transport. Some SNMP devices take longer than others to respond. The new Ironic configuration settings ``[snmp]/udp_transport_retries`` and ``[snmp]/udp_transport_timeout`` allow to change the number of retries and the timeout values respectively for the SNMP driver. ironic-10.1.1/releasenotes/notes/node-name-remove-720aa8007f2f8b75.yaml0000666000175100017510000000015113243617464025110 0ustar zuulzuul00000000000000--- fixes: - Fixes an issue that prevented the node name to be removed as part of the node update. ironic-10.1.1/releasenotes/notes/add-ipv6-pxe-support-8fb51c355cc977c4.yaml0000666000175100017510000000021513243617464025765 0ustar zuulzuul00000000000000--- features: - Adds experimental support for IPv6 PXE booting. This is configurable via the [pxe]ip_version configuration option. ironic-10.1.1/releasenotes/notes/add-notifications-97b6c79c18b48073.yaml0000666000175100017510000000062213243617464025315 0ustar zuulzuul00000000000000--- features: - Adds support for inter-service notifications (disabled by default until the ``notification_level`` configuration option is set). For more information, see the notifications documentation in the developer's guide (http://docs.openstack.org/developer/ironic/dev/notifications.html). Notifications are not actually emitted yet, but will be added in a future release. ironic-10.1.1/releasenotes/notes/keystoneauth-config-1baa45a0a2dd93b4.yaml0000666000175100017510000000034313243617464026141 0ustar zuulzuul00000000000000--- features: - | Adds the ability to set keystoneauth settings for automatic service discovery in the following configuration sections: ``[glance]``, ``[cinder]``, ``[inspector]``, ``[swift]`` and ``[neutron]``. ironic-10.1.1/releasenotes/notes/add_infiniband_support-f497767f77277a1a.yaml0000666000175100017510000000017013243617464026427 0ustar zuulzuul00000000000000--- features: - Adds support for InfiniBand networking to allow hardware inspection and PXE boot over InfiniBand. ironic-10.1.1/releasenotes/notes/pass-metrics-config-to-agent-on-lookup-6db9ae187c4e8151.yaml0000666000175100017510000000033713243617464031362 0ustar zuulzuul00000000000000--- features: - Adds the ability for ironic conductor to pass configurations for agent metrics on lookup. When paired with a sufficiently new ironic python agent, this will configure the metrics backends. ironic-10.1.1/releasenotes/notes/boot-ipxe-inc-workaround-548e10d1d6616752.yaml0000666000175100017510000000026713243617464026473 0ustar zuulzuul00000000000000--- fixes: - Make boot.ipxe fallback to its previous behavior on *really* old iPXE ROMs where 'inc' command is not available at all, see https://launchpad.net/bugs/1507738. ironic-10.1.1/releasenotes/notes/oob-power-off-7bbdf5947ed24bf8.yaml0000666000175100017510000000057313243617464024702 0ustar zuulzuul00000000000000--- fixes: - Fixes a problem where some hardware/firmware (specially faulty ones) won't come back online after an in-band ACPI soft power off by adding a new driver property called "deploy_forces_oob_reboot" that can be set to the nodes being deployed by the IPA ramdisk. If the value of this property is True, Ironic will power cycle the node via out-of-band. ironic-10.1.1/releasenotes/notes/fix-oneview-deallocate-server-8256e279af837e5d.yaml0000666000175100017510000000036513243617464027645 0ustar zuulzuul00000000000000--- fixes: - Fixes an issue with oneview driver trying to deallocate a node when an error is encountered while performing server profile application. Also ensures only those nodes that are managed by ironic can be deallocated. ironic-10.1.1/releasenotes/notes/bug-1548086-ed88646061b88faf.yaml0000666000175100017510000000070013243617464023465 0ustar zuulzuul00000000000000--- features: - Adds support to pass a optional CA certificate using [glance]glance_cafile configuration option to validate the SSL certificate served by glance for secured https communication between Glance and Ironic. upgrade: - Adds a [glance]glance_cafile configuration option to pass a optional certificate for secured https communication. It is used when [glance]glance_api_insecure configuration option is set to False. ironic-10.1.1/releasenotes/notes/fix-ipmi-numeric-password-75e080aa8bdfb9a2.yaml0000666000175100017510000000020613243617464027214 0ustar zuulzuul00000000000000--- fixes: - Fixes an issue where ironic could not communicate with IPMI endpoints when the password consisted of only numbers. ironic-10.1.1/releasenotes/notes/irmc-boot-from-volume-4bc5d20a0a780669.yaml0000666000175100017510000000053713243617464026117 0ustar zuulzuul00000000000000--- features: - | Adds support for booting from remote volumes via the ``irmc-virtual-media`` boot interface. It enables boot configuration for iSCSI or FibreChannel via out-of-band network. For details, see the `iRMC driver documentation `_. ironic-10.1.1/releasenotes/notes/bug-1579635-cffd990b51bcb5ab.yaml0000666000175100017510000000014313243617464023747 0ustar zuulzuul00000000000000--- fixes: - This fixes the issue of RAID interface not being supported in iscsi_ilo driver. ironic-10.1.1/releasenotes/notes/wsgi-applications-5d36cf2a8885a56d.yaml0000666000175100017510000000071013243617464025505 0ustar zuulzuul00000000000000--- upgrade: - A new WSGI application script ``ironic-api-wsgi`` is now available. It is auto-generated by ``pbr`` and provides the ability to serve the bare metal API using a WSGI server (for example Nginx and uWSGI or Apache with mod_wsgi). deprecations: - Using ``ironic/api/app.wsgi`` script is deprecated and it will be removed in Rocky release. Please switch to automatically generated ``ironic-api-wsgi`` script instead. ironic-10.1.1/releasenotes/notes/fix-ipa-ephemeral-partition-1f1e020727a49078.yaml0000666000175100017510000000030313243617464027113 0ustar zuulzuul00000000000000--- fixes: - Fixed a bug where the ironic python agent ramdisk was not creating an ephemeral partition because the ephemeral partition size was not being passed correctly to the agent. ironic-10.1.1/releasenotes/notes/fix-mitaka-ipa-iscsi.yaml0000666000175100017510000000072413243617464023536 0ustar zuulzuul00000000000000--- upgrade: - Fixed Mitaka ironic python agent ramdisk iSCSI deploy compatibility with newer versions of ironic by logging the warning and retrying the deploy if wiping root disk metadata before exposing it over iSCSI fails. If custom iSCSI port is requested, an error clarifying the issue is logged and the operator is requested either to use the default iSCSI portal port, or to upgrade ironic python agent ramdisk to version >= 1.3 (Newton). ironic-10.1.1/releasenotes/notes/add-secure-boot-suport-irmc-2c1f09271f96424d.yaml0000666000175100017510000000016713243617464027144 0ustar zuulzuul00000000000000--- features: - | Adds support to provision an instance in UEFI secure boot for ``irmc-pxe`` boot interface. ironic-10.1.1/releasenotes/notes/update-python-scciclient-required-version-71398d5d5e1c0bf8.yaml0000666000175100017510000000043013243617464032263 0ustar zuulzuul00000000000000--- upgrade: - Updated python-scciclient required version number for iRMC driver to 0.3.0 which fixed the bug '#1518999' and '#1519000'. fixes: - Updated python-scciclient required version number for iRMC driver to 0.3.0 which fixed the bug '#1518999' and '#1519000'. ironic-10.1.1/releasenotes/notes/add-agent-erase-fallback-b07613a7042fe236.yaml0000666000175100017510000000125613243617464026350 0ustar zuulzuul00000000000000--- features: - A new configuration option ``[deploy]continue_if_disk_secure_erase_fails``, which has a default value of False, has been added. If set to True, the Ironic Python Agent will revert to a disk shred operation if an ATA secure erase operation fails. Under normal circumstances, the failure of an ATA secure erase operation results in the node being put in ``clean failed`` state. upgrade: - A new configuration option ``[deploy]continue_if_disk_secure_erase_fails``, which has a default value of False, has been added. The default setting represents the standard behavior of the Ironic Python Agent during a cleaning failure. ironic-10.1.1/releasenotes/notes/check-dynamic-allocation-enabled-e94f3b8963b114d0.yaml0000666000175100017510000000045513243617464030200 0ustar zuulzuul00000000000000--- fixes: - The ``dynamic_allocation`` flag in a node's driver_info previously only accepted a Boolean. It now also accepts the strings 't', 'true', 'on', 'y', 'yes', or '1' as True, and the strings 'f', 'false', 'off', 'n', 'no', or '0' as False. These are matched case-insensitively. ironic-10.1.1/releasenotes/notes/fix-url-collisions-43abfc8364ca34e7.yaml0000666000175100017510000000021213243617464025653 0ustar zuulzuul00000000000000--- fixes: - Removed invalid API URL ``/v1/nodes/ports``. For more information, see https://bugs.launchpad.net/ironic/+bug/1580997. ironic-10.1.1/releasenotes/notes/deprecate-support-for-glance-v1-8b194e6b20cbfebb.yaml0000666000175100017510000000031613243617464030257 0ustar zuulzuul00000000000000--- deprecations: - | Support for the Image service v1 API has been deprecated along with the ``[glance]/glance_api_version`` configuration option and will be removed in the `Queens` release. ironic-10.1.1/releasenotes/notes/uefi-grub2-by-default-6b797a9e690d2dd5.yaml0000666000175100017510000000053613243617464026064 0ustar zuulzuul00000000000000--- upgrade: - The default bootloader for PXE + UEFI has changed from ELILO to Grub2 because ELILO is not being actively developed anymore. Operators relying on ELILO should explicitly set the ``[pxe]/uefi_pxe_bootfile_name`` and ``[pxe]/uefi_pxe_config_template`` configuration options to the ELILO ROM and configuration template. ironic-10.1.1/releasenotes/notes/ilo-fix-inspection-b169ad0a22aea2ff.yaml0000666000175100017510000000023113243617464025754 0ustar zuulzuul00000000000000--- fixes: - Fixes a bug in the iLO drivers' inspection where an existing ``local_gb`` node property was overwritten with "0" if not detected. ironic-10.1.1/releasenotes/notes/deprecate-clustered-compute-manager-3dd68557446bcc5c.yaml0000666000175100017510000000061113243617464031053 0ustar zuulzuul00000000000000--- deprecations: - | The ClusteredComputeManager is now deprecated. The Newton version of Nova adds functionality to the ironic virt driver to support multiple compute hosts without using the hack we call ClusteredComputeManager. As such, we are marking this unsupported component as deprecated, and plan to remove it before the end of the Ocata development cycle. ironic-10.1.1/releasenotes/notes/validate-node-properties-73509ee40f409ca2.yaml0000666000175100017510000000023513243617464026664 0ustar zuulzuul00000000000000--- fixes: - The `cpus`, `local_gb`, and `memory_mb` properties of a node are now validated at input time to ensure they are non-negative numbers. ironic-10.1.1/releasenotes/notes/add-snmp-inspection-support-e68fd6d57cb33846.yaml0000666000175100017510000000107213243617464027445 0ustar zuulzuul00000000000000--- fixes: - Fixes disk size detection for out-of-band inspection in iLO drivers, by optionally using SNMPv3 to get the disk size for certain types of storage. features: - To enable SNMPv3 inspection in iLO drivers, the following parameters must be set in the node's ``driver_info``. * ``snmp_auth_user`` * ``snmp_auth_prot_password`` * ``snmp_auth_priv_password`` * ``snmp_auth_protocol`` (optional, defaults to iLO default value ``MD5``) * ``snmp_auth_priv_protocol`` (optional, defaults to iLO default value ``DES``) ironic-10.1.1/releasenotes/notes/create-port-on-conductor-b921738b4b2a5def.yaml0000666000175100017510000000054213243617464026754 0ustar zuulzuul00000000000000--- upgrade: - Moves port creation logic from the API service to the conductor service. This is more consistent with port update operations and opens opportunities for conductor-side validations on ports. However, with this change, port creation may take longer, and this may limit the number of ports that can be created in parallel. ironic-10.1.1/releasenotes/notes/classic-drivers-deprecation-de464065187d4c14.yaml0000666000175100017510000000120413243617464027266 0ustar zuulzuul00000000000000--- deprecations: - | The classic drivers, as well as the ``enabled_drivers`` configuration option, are now deprecated and may be removed in the Rocky relese. A deprecation warning will be logged for every loaded classic driver. Check `the migration guide `_ for information on how to update your nodes. .. note:: Check `the classic drivers future specification `_ for technical information behind this deprecation. ironic-10.1.1/releasenotes/notes/fix-updating-node-driver-to-classic-16b0d5ba47e74d10.yaml0000666000175100017510000000014513243617464030676 0ustar zuulzuul00000000000000--- fixes: - Fixes failure to update a node's driver from a hardware type to a classic driver. ironic-10.1.1/releasenotes/notes/drac-inspection-interface-b0abbad98fec1c2e.yaml0000666000175100017510000000045213243617464027426 0ustar zuulzuul00000000000000--- features: - Adds out-of-band inspection interface usable by DRAC drivers. upgrade: - The ``inspect`` interface of the ``pxe_drac`` driver has switched to use out-of-band inspection. For inband inspection, the node should be updated to use the ``pxe_drac_inspector`` driver instead. ironic-10.1.1/releasenotes/notes/deprecated-cinder-opts-e10c153768285cab.yaml0000666000175100017510000000051213243617464026276 0ustar zuulzuul00000000000000--- deprecations: - | Configuration option ``[cinder]/url`` is deprecated and will be ignored in the Rocky release. Instead, use ``[cinder]/endpoint_override`` configuration option to set a specific cinder API address when automatic discovery of the cinder API endpoint from keystone catalog is not desired. ironic-10.1.1/releasenotes/notes/drac-raid-interface-f4c02b1c4fb37e2d.yaml0000666000175100017510000000100513243617464025745 0ustar zuulzuul00000000000000--- features: - Adds out-of-band RAID management to DRAC driver using the generic RAID interface which makes the functionality available via manual cleaning steps. - New configuration option, ``[drac]/query_raid_config_job_status_interval`` was added. After Ironic has created the RAID config job on the DRAC card, it continues to check for status update on the config job to determine whether the RAID configuration was successfully finished within this interval. Default is 120 seconds. ironic-10.1.1/releasenotes/notes/node-storage-interface-api-1d6e217303bd53ff.yaml0000666000175100017510000000144413243617464027130 0ustar zuulzuul00000000000000--- features: - | Adds version 1.33 of the REST API, which exposes the ``storage_interface`` field of the node resource. This version also exposes ``default_storage_interface`` and ``enable_storage_interfaces`` fields of the driver resource. There are 2 available storage interfaces: * ``noop``: This interface provides nothing regarding storage. * ``cinder``: This interface enables a node to attach and detach volumes by leveraging cinder API. A storage interface can be set when creating or updating a node. Enabled storage interfaces are defined via the ``[DEFAULT]/enabled_storage_interfaces`` configuration option. A default interface for a created node can be specified with ``[DEFAULT]/default_storage_interface`` configuration option. ironic-10.1.1/releasenotes/notes/make-terminal-session-timeout-configurable-b2365b7699b0f98b.yaml0000666000175100017510000000027413243617464032331 0ustar zuulzuul00000000000000--- features: - | Adds configuration option ``[console]terminal_timeout`` to allow setting the time (in seconds) of inactivity, after which a socat-based console terminates. ironic-10.1.1/releasenotes/notes/multitenant-networking-0a13c4aba252573e.yaml0000666000175100017510000001000213243617464026536 0ustar zuulzuul00000000000000--- features: - | Adds multitenant networking support. Ironic now has the concept of "network interfaces" for a node, which represent a networking driver. There are three network interfaces available: * ``flat``: this replicates the old flat network behavior and is the default when using neutron for DHCP. * ``noop``: this replicates the old flat behavior when not using neutron for DHCP, and is the default when the configuration option ``[DHCP]/dhcp_provider`` is set to "none". * ``neutron``: this allows for separating the provisioning and cleaning networks from the tenant networks, and provides isolation from tenant network to tenant network, and tenant network to control plane. The following configuration options must be set if the neutron interface is enabled, or ironic-conductor will fail to start: * ``[neutron]/provisioning_network_uuid`` * ``[neutron]/cleaning_network_uuid`` A ``[DEFAULT]/enabled_network_interfaces`` option (which must be set for both ironic-api and ironic-conductor services) controls which network interfaces are available for use. A network interface is set for a node by setting the ``network_interface`` field for the node via the REST API. This field is available in API version 1.20 and above. Changing the network interface may only be done in the ``enroll``, ``inspecting``, and ``manageable`` states. The configuration option ``[DEFAULT]/default_network_interface`` may be used to specify which network interface is defined when a node is created. **WARNING: don't set the option ``[DEFAULT]/default_network_interface`` before upgrading to this release without reading the upgrade notes about it, due to data migrations depending on the value.** deprecations: - | ``create_cleaning_ports`` and ``delete_cleaning_ports`` methods in DHCP providers are deprecated and will be removed completely in the Ocata release. The logic they are implementing should be moved to a custom network interface's ``add_cleaning_network`` and ``remove_cleaning_network`` methods respectively. After that, the methods themselves should be removed from DHCP provider so that the custom network interface is used instead. ``flat`` network interface does not require ``[neutron]/cleaning_network_uuid`` for now so as not to break standalone deployments upon upgrade, but it will be required in the Ocata release if the ``flat`` network interface is enabled. upgrade: - | ``[DEFAULT]/default_network_interface`` configuration option is introduced, with empty default value. If set, the specified interface will be used as the network interface for nodes that don't have ``network_interface`` field set. If it is not set, the network interface is determined by looking at the ``[dhcp]/dhcp_provider`` value. If it is ``neutron`` - ``flat`` network interface is the default, ``noop`` otherwise. The network interface will be set for all nodes without network_interface already set via a database migration. This will be set following the logic above. When running database migrations for an existing deployment, it's important to check the above configuration options to ensure the existing nodes will have the expected network_interface. If ``[DEFAULT]/default_network_interface`` is not set, everything should go as expected. If it is set, ensure that it is set to the value that you wish existing nodes to use. - Note that if the configuration option ``[DEFAULT]/default_network_interface`` is set, it must be set in the configuration file for both the API and conductor hosts. - If ``neutron`` network interface is specified for the configuration option ``[DEFAULT]/enabled_network_interfaces``, then ``[neutron]/provisioning_network_uuid`` and ``[neutron]/cleaning_network_uuid`` configuration options are required. If either of them is not specified, the ironic-conductor service will fail to start. ironic-10.1.1/releasenotes/notes/port-0-is-valid-d7188af3be6f3ecb.yaml0000666000175100017510000000032613243617464025115 0ustar zuulzuul00000000000000--- fixes: - Fixes the issue of port number 0 (zero) being considered invalid (`bug 1729628 `_). Zero is a valid port number and is now recognized as such. ironic-10.1.1/releasenotes/notes/wipe-disk-before-deployment-0a8b9cede4a659e9.yaml0000666000175100017510000000076613243617464027536 0ustar zuulzuul00000000000000--- fixes: - Fixed a bug that was causing grub installation failure. If the disk was already coming with a partition table, the conductor was not able to wipe it properly and the new partition table would conflict with the old one. The issue was only impacting new nodes and installations with automated_clean disabled in the configuration. A disk instance without preserve_ephemeral is now purged before new deployment. See https://bugs.launchpad.net/ironic-lib/+bug/1550604 ironic-10.1.1/releasenotes/notes/allow-to-attach-vif-to-active-node-55963be2ec269043.yaml0000666000175100017510000000011713243617464030301 0ustar zuulzuul00000000000000--- features: - Adds possibility to attach/detach VIFs to/from active nodes. ironic-10.1.1/releasenotes/notes/remove-neutron-client-workarounds-996c59623684929b.yaml0000666000175100017510000000035113243617464030407 0ustar zuulzuul00000000000000--- fixes: - Update create provisioning ports logic to fail only when no neutron ports were created. If we created at least one neutron port, proceed with the deployment. It was the default behaviour for flat scenario. ironic-10.1.1/releasenotes/notes/add_portgroup_support-7d5c6663bb00684a.yaml0000666000175100017510000000160213243617464026422 0ustar zuulzuul00000000000000--- features: - | Adds support for port groups with a new endpoint ``/v1/portgroups/``. Ports can be combined into port groups to support static Link Aggregation Group (LAG) and Multi-Chassis LAG (MLAG) configurations. Note that if the optional ``mode`` field for a port group is not specified, its value will be set to the value of the configuration option ``[DEFAULT]default_portgroup_mode``, which defaults to ``active-backup``. Additionally, adds the following API changes: * a new endpoint ``/v1/nodes//portgroups``. * a new endpoint ``/v1/portgroups//ports``. * a new field ``portgroup_uuid`` on the port object. This is the UUID of a port group that this port belongs to, or None if it does not belong to any port group. All port group API functions are available starting with version 1.26 of the REST API. ironic-10.1.1/releasenotes/notes/drac_host-deprecated-b181149246eecb47.yaml0000666000175100017510000000032513243617464026023 0ustar zuulzuul00000000000000--- deprecations: - For DRAC drivers, the node's ``driver_info["drac_host"]`` property is deprecated and will be ignored starting in the Pike release. Please use ``driver_info["drac_address"]`` instead. ironic-10.1.1/releasenotes/notes/add-vif-attach-detach-support-99eca43eea6e5a30.yaml0000666000175100017510000000142013243617464027711 0ustar zuulzuul00000000000000--- features: - Adds support for attaching and detaching network VIFs to ironic ports and port groups by using the ``/v1/nodes//vifs`` API endpoint that was added in API version 1.28. When attaching a VIF to a node, it is attached to the first free port group. A port group is considered free if it has no VIFs attached to any of its ports. Otherwise, only the unattached ports of this port group are available for attachment. If there are no free port groups, the first available port is used instead, where ports with ``pxe_enabled`` set to ``True`` have higher priority. deprecations: - Using ``port.extra['vif_port_id']`` for attaching and detaching VIFs to ports or port groups is deprecated and will be removed in Pike release. ironic-10.1.1/releasenotes/notes/remove-driver-periodic-task-f5e513b06b601ce4.yaml0000666000175100017510000000025313243617464027347 0ustar zuulzuul00000000000000--- upgrade: - Removes the deprecated decorator "driver_periodic_task", Drivers should use the "periodics.periodic" decorator from the futurist library instead. ironic-10.1.1/releasenotes/notes/migrate_to_hardware_types-0c85c6707c4f296d.yaml0000666000175100017510000000272013243617464027224 0ustar zuulzuul00000000000000--- upgrade: - | Adds new data migration ``migrate_to_hardware_types`` that will try to migrate nodes from classic drivers to hardware types on upgrade. Nodes that cannot be migrated are skipped. This may happen due to one of these reasons: * migration is not implemented for the classic driver, * the matching hardware type is not enabled, * one or more matching hardware interfaces are not enabled. In the latter case, the new migration command line option ``reset_unsupported_interfaces`` can be used to reset optional interfaces (all except for ``boot``, ``deploy``, ``management`` and ``power``) to their no-op implementations (e.g. ``no-inspect``) if the matching implementation is not enabled. Use it like:: ironic-dbsync online_data_migrations --option migrate_to_hardware_types.reset_unsupported_interfaces=true This migration can be repeated several times to migrate skipped nodes after the configuration is changed. other: - | A classic driver implementation can now provide matching hardware type and interfaces to enable automatic migration to hardware types. See `the specification `_ for an explanation on how to do it. .. note:: This feature will only be available until the classic drivers support is removed (presumably in the Rocky release). ironic-10.1.1/releasenotes/notes/dbsync-online_data_migration-edcf0b1cc3667582.yaml0000666000175100017510000000061213243617464027724 0ustar zuulzuul00000000000000--- upgrade: - The new ``ironic-dbsync online_data_migrations`` command should be run after each upgrade to ensure all DB records are converted to the newest format. It must be run before starting the software as part of a new upgrade to the next named release. For more information about this command, see https://docs.openstack.org/ironic/latest/cli/ironic-dbsync.html. ironic-10.1.1/releasenotes/source/0000775000175100017510000000000013243617733017103 5ustar zuulzuul00000000000000ironic-10.1.1/releasenotes/source/pike.rst0000666000175100017510000000031113243617464020563 0ustar zuulzuul00000000000000========================================== Pike Series (8.0.0 - 9.1.x) Release Notes ========================================== .. release-notes:: :branch: stable/pike :earliest-version: 8.0.0 ironic-10.1.1/releasenotes/source/mitaka.rst0000666000175100017510000000032513243617464021106 0ustar zuulzuul00000000000000=========================================== Mitaka Series (4.3.0 - 5.1.x) Release Notes =========================================== .. release-notes:: :branch: origin/stable/mitaka :earliest-version: 4.3.0 ironic-10.1.1/releasenotes/source/ocata.rst0000666000175100017510000000032113243617464020723 0ustar zuulzuul00000000000000========================================== Ocata Series (7.0.0 - 7.0.x) Release Notes ========================================== .. release-notes:: :branch: origin/stable/ocata :earliest-version: 7.0.0 ironic-10.1.1/releasenotes/source/index.rst0000666000175100017510000000061313243617471020745 0ustar zuulzuul00000000000000===================== Ironic Release Notes ===================== .. toctree:: :maxdepth: 1 unreleased pike ocata newton mitaka liberty Kilo (2015.1) Juno (2014.2) Icehouse (2014.1) ironic-10.1.1/releasenotes/source/newton.rst0000666000175100017510000000032513243617464021152 0ustar zuulzuul00000000000000=========================================== Newton Series (6.0.0 - 6.2.x) Release Notes =========================================== .. release-notes:: :branch: origin/stable/newton :earliest-version: 6.0.0 ironic-10.1.1/releasenotes/source/liberty.rst0000666000175100017510000002032613243617464021315 0ustar zuulzuul00000000000000============================================ Liberty Series (4.0.0 - 4.2.5) Release Notes ============================================ .. release-notes:: :branch: origin/stable/liberty :earliest-version: 4.2.2 .. _V4-2-1: 4.2.1 ===== This release is a patch release on top of 4.2.0, as part of the stable Liberty series. Full details are available on Launchpad: https://launchpad.net/ironic/liberty/4.2.1. * Import Japanese translations - our first major translation addition! * Fix a couple of locale issues with deployments, when running on a system using the Japanese locale .. _V4-2-0: 4.2.0 ===== This release is proposed as the stable Liberty release for Ironic, and brings with it some bug fixes and small features. Full release details are available on Launchpad: https://launchpad.net/ironic/liberty/4.2.0. * Deprecated the bash ramdisk The older bash ramdisk built by diskimage-builder is now deprecated and support will be removed at the beginning of the "N" development cycle. Users should migrate to a ramdisk running ironic-python-agent, which now also supports the pxe_* drivers that the bash ramdisk was responsible for. For more info on building an ironic-python-agent ramdisk, see: https://docs.openstack.org/developer/ironic/deploy/install-guide.html#building-or-downloading-a-deploy-ramdisk-image * Raised API version to 1.14 * 1.12 allows setting RAID properties for a node; however support for putting this configuration on a node is not yet implemented for in-tree drivers; this will be added in a future release. * 1.13 adds a new 'abort' verb to the provision state API. This may be used to abort cleaning for nodes in the CLEANWAIT state. * 1.14 makes the following endpoints discoverable in the API: * /v1/nodes//states * /v1/drivers//properties * Implemented a new Boot interface for drivers This change enhances the driver interface for driver authors, and should not affect users of Ironic, by splitting control of booting a server from the DeployInterface. The BootInterface is responsible for booting an image on a server, while the DeployInterface is responsible for deploying a tenant image to a server. This has been implemented in most in-tree drivers, and is a backwards-compatible change for out-of-tree drivers. The following in-tree drivers will be updated in a forth-coming release: * agent_ilo * agent_irmc * iscsi_ilo * iscsi_irmc * Implemented a new RAID interface for drivers This change enhances the driver interface for driver authors. Drivers may begin implementing this interface to support RAID configuration for nodes. This is not yet implemented for any in-tree drivers. * Image size is now checked before deployment with agent drivers The agent must download the tenant image in full before writing it to disk. As such, the server being deployed must have enough RAM for running the agent and storing the image. This is now checked before Ironic tells the agent to deploy an image. An optional config [agent]memory_consumed_by_agent is provided. When Ironic does this check, this config option may be set to factor in the amount of RAM to reserve for running the agent. * Added Cisco IMC driver This driver supports managing Cisco UCS C-series servers through the CIMC API, rather than IPMI. Documentation is available at: https://docs.openstack.org/developer/ironic/drivers/cimc.html * iLO virtual media drivers can work without Swift iLO virtual media drivers (iscsi_ilo and agent_ilo) can work standalone without Swift, by configuring an HTTP(S) server for hosting the deploy/boot images. A web server needs to be running on every conductor node and needs to be configured in ironic.conf. iLO driver documentation is available at: https://docs.openstack.org/developer/ironic/drivers/ilo.html Known issues ~~~~~~~~~~~~ * Out of tree drivers may be broken by this release. The AgentDeploy and ISCSIDeploy (formerly known as PXEDeploy) classes now depend on drivers to utilize an instance of a BootInterface. For drivers that exist out of tree, that use these deploy classes, an error will be thrown during deployment. There is a simple fix. For drivers that expect these deploy classes to handle PXE booting, one can add the following code to the driver's `__init__` method:: from ironic.drivers.modules import pxe class YourDriver(...): def __init__(self): # ... self.boot = pxe.PXEBoot() A driver that handles booting itself (for example, a driver that implements booting from virtual media) should use the following to make calls to the boot interface a no-op:: from ironic.drivers.modules import fake class YourDriver(...) def __init__(self): # ... self.boot = fake.FakeBoot() Additionally, as mentioned before, `ironic.drivers.modules.pxe.PXEDeploy` has moved to `ironic.drivers.modules.iscsi_deploy.ISCSIDeploy`, which will break drivers that use this class. The Ironic team apologizes profusely for this inconvenience. .. _V4-1-0: 4.1.0 ===== This brings some bug fixes and small features on top of Ironic 4.0.0. Major changes are listed below, and full release details are available on Launchpad: https://launchpad.net/ironic/liberty/4.1.0. * Added CORS support The Ironic API now has support for CORS requests, that may be used by, for example, web browser-based clients. This is configured in the [cors] section of ironic.conf. * Removed deprecated 'admin_api' policy rule * Deprecated the 'parallel' option to periodic task decorator .. _V4-0-0: 4.0.0 First semver release ============================ This is the first semver-versioned release of Ironic, created during the OpenStack "Liberty" development cycle. It marks a pivot in our versioning schema from date-based versioning; the previous released version was 2015.1. Full release details are available on Launchpad: https://launchpad.net/ironic/liberty/4.0.0. * Raised API version to 1.11 - v1.7 exposes a new 'clean_step' property on the Node resource. - v1.8 and v1.9 improve query and filter support - v1.10 fixes Node logical names to support all `RFC 3986`_ unreserved characters - v1.11 changes the default state of newly created Nodes from AVAILABLE to ENROLL * Support for the new ENROLL workflow during Node creation Previously, all Nodes were created in the "available" provision state - before management credentials were validated, hardware was burned in, etc. This could lead to workloads being scheduled to Nodes that were not yet ready for it. Beginning with API v1.11, newly created Nodes begin in the ENROLL state, and must be "managed" and "provided" before they are made available for provisioning. API clients must be updated to handle the new workflow when they begin sending the X-OpenStack-Ironic-API-Version header with a value >= 1.11. * Migrations from Nova "baremetal" have been removed After a deprecation period, the scripts and support for migrating from the old Nova "baremetal" driver to the new Nova "ironic" driver have been removed from Ironic's tree. * Removal of deprecated vendor driver methods A new @passthru decorator was introduced to the driver API in a previous release. In this release, support for vendor_passthru and driver_vendor_passthru methods has been removed. All in-tree drivers have been updated. Any out of tree drivers which did not update to the @passthru decorator during the previous release will need to do so to be compatible with this release. * Introduce new BootInterface to the Driver API Drivers may optionally add a new BootInterface. This is merely a refactoring of the Driver API to support future improvements. * Several hardware drivers have been added or enhanced - Add OCS Driver - Add UCS Driver - Add Wake-On-Lan Power Driver - ipmitool driver supports IPMI v1.5 - Add support to SNMP driver for "APC MasterSwitchPlus" series PDU's - pxe_ilo driver now supports UEFI Secure Boot (previous releases of the iLO driver only supported this for agent_ilo and iscsi_ilo) - Add Virtual Media support to iRMC Driver - Add BIOS config to DRAC Driver - PXE drivers now support GRUB2 .. _`RFC 3986`: https://www.ietf.org/rfc/rfc3986.txt ironic-10.1.1/releasenotes/source/conf.py0000666000175100017510000002202313243617464020404 0ustar zuulzuul00000000000000# -*- coding: utf-8 -*- # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or # implied. # See the License for the specific language governing permissions and # limitations under the License. # Ironic Release Notes documentation build configuration file, created by # sphinx-quickstart on Tue Nov 3 17:40:50 2015. # # This file is execfile()d with the current directory set to its # containing dir. # # Note that not all possible configuration values are present in this # autogenerated file. # # All configuration values have a default; values that are commented out # serve to show the default. # If extensions (or modules to document with autodoc) are in another directory, # add these directories to sys.path here. If the directory is relative to the # documentation root, use os.path.abspath to make it absolute, like shown here. # sys.path.insert(0, os.path.abspath('.')) # -- General configuration ------------------------------------------------ # If your documentation needs a minimal Sphinx version, state it here. # needs_sphinx = '1.0' # Add any Sphinx extension module names here, as strings. They can be # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom # ones. extensions = [ 'reno.sphinxext', ] try: import openstackdocstheme extensions.append('openstackdocstheme') except ImportError: openstackdocstheme = None repository_name = 'openstack/ironic' bug_project = 'ironic' bug_tag = '' html_last_updated_fmt = '%Y-%m-%d %H:%M' # Add any paths that contain templates here, relative to this directory. templates_path = ['_templates'] # The suffix of source filenames. source_suffix = '.rst' # The encoding of source files. # source_encoding = 'utf-8-sig' # The master toctree document. master_doc = 'index' # General information about the project. project = u'Ironic Release Notes' copyright = u'2015, Ironic Developers' # Release notes do not need a version number in the title, they # cover multiple releases. # The full version, including alpha/beta/rc tags. release = '' # The short X.Y version. version = '' # The language for content autogenerated by Sphinx. Refer to documentation # for a list of supported languages. # language = None # There are two options for replacing |today|: either, you set today to some # non-false value, then it is used: # today = '' # Else, today_fmt is used as the format for a strftime call. # today_fmt = '%B %d, %Y' # List of patterns, relative to source directory, that match files and # directories to ignore when looking for source files. exclude_patterns = [] # The reST default role (used for this markup: `text`) to use for all # documents. # default_role = None # If true, '()' will be appended to :func: etc. cross-reference text. # add_function_parentheses = True # If true, the current module name will be prepended to all description # unit titles (such as .. function::). # add_module_names = True # If true, sectionauthor and moduleauthor directives will be shown in the # output. They are ignored by default. # show_authors = False # The name of the Pygments (syntax highlighting) style to use. pygments_style = 'sphinx' # A list of ignored prefixes for module index sorting. # modindex_common_prefix = [] # If true, keep warnings as "system message" paragraphs in the built documents. # keep_warnings = False # -- Options for HTML output ---------------------------------------------- # The theme to use for HTML and HTML Help pages. See the documentation for # a list of builtin themes. if openstackdocstheme is not None: html_theme = 'openstackdocs' else: html_theme = 'default' # Theme options are theme-specific and customize the look and feel of a theme # further. For a list of options available for each theme, see the # documentation. # html_theme_options = {} # Add any paths that contain custom themes here, relative to this directory. # html_theme_path = [] # The name for this set of Sphinx documents. If None, it defaults to # " v documentation". # html_title = None # A shorter title for the navigation bar. Default is the same as html_title. # html_short_title = None # The name of an image file (relative to this directory) to place at the top # of the sidebar. # html_logo = None # The name of an image file (within the static path) to use as favicon of the # docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 # pixels large. # html_favicon = None # Add any paths that contain custom static files (such as style sheets) here, # relative to this directory. They are copied after the builtin static files, # so a file named "default.css" will overwrite the builtin "default.css". html_static_path = ['_static'] # Add any extra paths that contain custom files (such as robots.txt or # .htaccess) here, relative to this directory. These files are copied # directly to the root of the documentation. # html_extra_path = [] # If not '', a 'Last updated on:' timestamp is inserted at every page bottom, # using the given strftime format. # html_last_updated_fmt = '%b %d, %Y' # If true, SmartyPants will be used to convert quotes and dashes to # typographically correct entities. # html_use_smartypants = True # Custom sidebar templates, maps document names to template names. # html_sidebars = {} # Additional templates that should be rendered to pages, maps page names to # template names. # html_additional_pages = {} # If false, no module index is generated. # html_domain_indices = True # If false, no index is generated. # html_use_index = True # If true, the index is split into individual pages for each letter. # html_split_index = False # If true, links to the reST sources are added to the pages. # html_show_sourcelink = True # If true, "Created using Sphinx" is shown in the HTML footer. Default is True. # html_show_sphinx = True # If true, "(C) Copyright ..." is shown in the HTML footer. Default is True. # html_show_copyright = True # If true, an OpenSearch description file will be output, and all pages will # contain a tag referring to it. The value of this option must be the # base URL from which the finished HTML is served. # html_use_opensearch = '' # This is the file name suffix for HTML files (e.g. ".xhtml"). # html_file_suffix = None # Output file base name for HTML help builder. htmlhelp_basename = 'IronicReleaseNotesdoc' # -- Options for LaTeX output --------------------------------------------- latex_elements = { # The paper size ('letterpaper' or 'a4paper'). # 'papersize': 'letterpaper', # The font size ('10pt', '11pt' or '12pt'). # 'pointsize': '10pt', # Additional stuff for the LaTeX preamble. # 'preamble': '', } # Grouping the document tree into LaTeX files. List of tuples # (source start file, target name, title, # author, documentclass [howto, manual, or own class]). latex_documents = [ ('index', 'IronicReleaseNotes.tex', u'Ironic Release Notes Documentation', u'Ironic Developers', 'manual'), ] # The name of an image file (relative to this directory) to place at the top of # the title page. # latex_logo = None # For "manual" documents, if this is true, then toplevel headings are parts, # not chapters. # latex_use_parts = False # If true, show page references after internal links. # latex_show_pagerefs = False # If true, show URL addresses after external links. # latex_show_urls = False # Documents to append as an appendix to all manuals. # latex_appendices = [] # If false, no module index is generated. # latex_domain_indices = True # -- Options for manual page output --------------------------------------- # One entry per manual page. List of tuples # (source start file, name, description, authors, manual section). man_pages = [ ('index', 'ironicreleasenotes', u'Ironic Release Notes Documentation', [u'Ironic Developers'], 1) ] # If true, show URL addresses after external links. # man_show_urls = False # -- Options for Texinfo output ------------------------------------------- # Grouping the document tree into Texinfo files. List of tuples # (source start file, target name, title, author, # dir menu entry, description, category) texinfo_documents = [ ('index', 'IronicReleaseNotes', u'Ironic Release Notes Documentation', u'Ironic Developers', 'IronicReleaseNotes', 'One line description of project.', 'Miscellaneous'), ] # Documents to append as an appendix to all manuals. # texinfo_appendices = [] # If false, no module index is generated. # texinfo_domain_indices = True # How to display URL addresses: 'footnote', 'no', or 'inline'. # texinfo_show_urls = 'footnote' # If true, do not generate a @detailmenu in the "Top" node's menu. # texinfo_no_detailmenu = False # -- Options for Internationalization output ------------------------------ locale_dirs = ['locale/'] ironic-10.1.1/releasenotes/source/_templates/0000775000175100017510000000000013243617733021240 5ustar zuulzuul00000000000000ironic-10.1.1/releasenotes/source/_templates/.placeholder0000666000175100017510000000000013243617464023514 0ustar zuulzuul00000000000000ironic-10.1.1/releasenotes/source/_static/0000775000175100017510000000000013243617733020531 5ustar zuulzuul00000000000000ironic-10.1.1/releasenotes/source/_static/.placeholder0000666000175100017510000000000013243617464023005 0ustar zuulzuul00000000000000ironic-10.1.1/releasenotes/source/unreleased.rst0000666000175100017510000000015313243617464021766 0ustar zuulzuul00000000000000============================ Current Series Release Notes ============================ .. release-notes:: ironic-10.1.1/zuul.d/0000775000175100017510000000000013243617733014333 5ustar zuulzuul00000000000000ironic-10.1.1/zuul.d/project.yaml0000666000175100017510000000347313243617464016677 0ustar zuulzuul00000000000000- project: check: jobs: - ironic-dsvm-standalone - ironic-grenade-dsvm # Temporary mark multinode job as NV. # see https://bugs.launchpad.net/ironic/+bug/1744139 - ironic-grenade-dsvm-multinode-multitenant: voting: false - ironic-tempest-dsvm-bfv - ironic-tempest-dsvm-ipa-partition-pxe_ipmitool-tinyipa-python3 - ironic-tempest-dsvm-ipa-partition-redfish-tinyipa - ironic-tempest-dsvm-ipa-partition-uefi-pxe_ipmitool-tinyipa - ironic-tempest-dsvm-ipa-wholedisk-agent_ipmitool-tinyipa-multinode - ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa # Non-voting jobs - ironic-tempest-dsvm-ipa-wholedisk-bios-pxe_snmp-tinyipa: voting: false - ironic-tempest-dsvm-ironic-inspector: voting: false - ironic-tempest-dsvm-pxe_ipmitool-postgres: voting: false gate: queue: ironic jobs: - ironic-dsvm-standalone - ironic-grenade-dsvm # Temporary disable multinode job, no need to run non-voting in gate. # see https://bugs.launchpad.net/ironic/+bug/1744139 # - ironic-grenade-dsvm-multinode-multitenant - ironic-tempest-dsvm-bfv - ironic-tempest-dsvm-ipa-partition-pxe_ipmitool-tinyipa-python3 - ironic-tempest-dsvm-ipa-partition-redfish-tinyipa - ironic-tempest-dsvm-ipa-partition-uefi-pxe_ipmitool-tinyipa - ironic-tempest-dsvm-ipa-wholedisk-agent_ipmitool-tinyipa-multinode - ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa experimental: jobs: - ironic-dsvm-functional - ironic-tempest-dsvm-ipa-resourceclasses-partition-pxe_ipmitool-tinyipa - ironic-tempest-dsvm-parallel - ironic-tempest-dsvm-pxe_ipa-full ironic-10.1.1/zuul.d/legacy-ironic-jobs.yaml0000666000175100017510000001443513243617464020711 0ustar zuulzuul00000000000000- job: name: legacy-ironic-dsvm-base parent: legacy-dsvm-base irrelevant-files: - ^(test-|driver-)requirements.txt$ - ^.*\.rst$ - ^api-ref/.*$ - ^doc/.*$ - ^install-guide/.*$ - ^ironic/locale/.*$ - ^ironic/tests/.*$ - ^releasenotes/.*$ - ^setup.cfg$ - ^tools/.*$ - ^tox.ini$ # NOTE: When adding to 'required-projects' also need to add a corresponding # "export PROJECTS=..." line in all the playbooks/legacy/*/run.yaml files required-projects: - openstack/ironic - openstack/ironic-lib - openstack/ironic-python-agent - openstack/ironic-tempest-plugin - openstack/pyghmi - openstack/python-ironicclient - openstack/virtualbmc post-run: playbooks/legacy/ironic-dsvm-base/post.yaml - job: name: legacy-ironic-dsvm-base-multinode parent: legacy-dsvm-base-multinode irrelevant-files: - ^(test-|driver-|)requirements.txt$ - ^.*\.rst$ - ^api-ref/.*$ - ^doc/.*$ - ^install-guide/.*$ - ^ironic/locale/.*$ - ^ironic/tests/.*$ - ^releasenotes/.*$ - ^setup.cfg$ - ^tools/.*$ - ^tox.ini$ # NOTE: When adding to 'required-projects' also need to add a corresponding # "export PROJECTS=..." line in all the playbooks/legacy/*/run.yaml files required-projects: - openstack/ironic - openstack/ironic-lib - openstack/ironic-python-agent - openstack/ironic-tempest-plugin - openstack/networking-generic-switch - openstack/pyghmi - openstack/python-ironicclient - openstack/virtualbmc post-run: playbooks/legacy/ironic-dsvm-base-multinode/post.yaml - job: name: ironic-tempest-dsvm-pxe_ipmitool-postgres parent: legacy-ironic-dsvm-base run: playbooks/legacy/tempest-dsvm-ironic-pxe_ipmitool-postgres/run.yaml timeout: 10800 - job: name: ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa parent: legacy-ironic-dsvm-base run: playbooks/legacy/tempest-dsvm-ironic-ipa-wholedisk-bios-agent_ipmitool-tinyipa/run.yaml timeout: 5400 - job: name: ironic-tempest-dsvm-ipa-wholedisk-bios-pxe_snmp-tinyipa parent: legacy-ironic-dsvm-base run: playbooks/legacy/tempest-dsvm-ironic-ipa-wholedisk-bios-pxe_snmp-tinyipa/run.yaml timeout: 5400 - job: name: ironic-tempest-dsvm-ipa-partition-uefi-pxe_ipmitool-tinyipa parent: legacy-ironic-dsvm-base run: playbooks/legacy/tempest-dsvm-ironic-ipa-partition-uefi-pxe_ipmitool-tinyipa/run.yaml timeout: 5400 - job: name: ironic-tempest-dsvm-ipa-partition-pxe_ipmitool-tinyipa-python3 parent: legacy-ironic-dsvm-base run: playbooks/legacy/tempest-dsvm-ironic-ipa-partition-pxe_ipmitool-tinyipa-python3/run.yaml timeout: 5400 - job: name: ironic-tempest-dsvm-ipa-wholedisk-agent_ipmitool-tinyipa-multinode parent: legacy-ironic-dsvm-base-multinode run: playbooks/legacy/tempest-dsvm-ironic-ipa-wholedisk-agent_ipmitool-tinyipa-multinode/run.yaml timeout: 10800 nodeset: legacy-ubuntu-xenial-2-node - job: name: ironic-tempest-dsvm-ipa-partition-redfish-tinyipa parent: legacy-ironic-dsvm-base run: playbooks/legacy/tempest-dsvm-ironic-ipa-partition-redfish-tinyipa/run.yaml timeout: 5400 - job: name: ironic-tempest-dsvm-bfv parent: legacy-ironic-dsvm-base run: playbooks/legacy/tempest-dsvm-ironic-bfv/run.yaml timeout: 9600 - job: name: ironic-dsvm-standalone parent: legacy-ironic-dsvm-base run: playbooks/legacy/ironic-dsvm-standalone/run.yaml timeout: 10800 required-projects: - openstack-infra/devstack-gate - openstack/ironic - openstack/ironic-lib - openstack/ironic-python-agent - openstack/python-ironicclient - job: name: ironic-tempest-dsvm-ironic-inspector parent: legacy-ironic-dsvm-base run: playbooks/legacy/tempest-dsvm-ironic-inspector/run.yaml timeout: 10800 required-projects: - openstack-infra/devstack-gate - openstack/ironic - openstack/ironic-inspector - openstack/ironic-lib - openstack/ironic-python-agent - openstack/pyghmi - openstack/python-ironic-inspector-client - openstack/python-ironicclient - openstack/tempest - openstack/virtualbmc - job: name: ironic-grenade-dsvm parent: legacy-ironic-dsvm-base run: playbooks/legacy/grenade-dsvm-ironic/run.yaml timeout: 10800 required-projects: - openstack-dev/grenade - openstack-infra/devstack-gate - openstack/ironic - openstack/ironic-lib - openstack/ironic-python-agent - openstack/pyghmi - openstack/python-ironicclient - openstack/virtualbmc - job: name: ironic-grenade-dsvm-multinode-multitenant parent: legacy-ironic-dsvm-base-multinode run: playbooks/legacy/grenade-dsvm-ironic-multinode-multitenant/run.yaml timeout: 10800 required-projects: - openstack-dev/grenade - openstack-infra/devstack-gate - openstack/ironic - openstack/ironic-lib - openstack/ironic-python-agent - openstack/networking-generic-switch - openstack/pyghmi - openstack/python-ironicclient - openstack/virtualbmc nodeset: legacy-ubuntu-xenial-2-node - job: name: ironic-dsvm-functional parent: legacy-ironic-dsvm-base run: playbooks/legacy/ironic-dsvm-functional/run.yaml timeout: 4800 required-projects: - openstack-infra/devstack-gate - openstack/ironic - openstack/ironic-python-agent - job: name: ironic-tempest-dsvm-parallel parent: legacy-ironic-dsvm-base run: playbooks/legacy/tempest-dsvm-ironic-parallel/run.yaml timeout: 10800 required-projects: - openstack-infra/devstack-gate - openstack/ara - openstack/ironic - openstack/ironic-lib - openstack/ironic-python-agent - openstack/python-ironicclient - openstack/tempest - job: name: ironic-tempest-dsvm-pxe_ipa-full parent: legacy-ironic-dsvm-base run: playbooks/legacy/tempest-dsvm-ironic-pxe_ipa-full/run.yaml timeout: 9600 - job: name: ironic-tempest-dsvm-ipa-resourceclasses-partition-pxe_ipmitool-tinyipa parent: legacy-ironic-dsvm-base run: playbooks/legacy/tempest-dsvm-ironic-ipa-resourceclasses-partition-pxe_ipmitool-tinyipa/run.yaml timeout: 5400 ironic-10.1.1/CONTRIBUTING.rst0000666000175100017510000000051213243617463015553 0ustar zuulzuul00000000000000If you would like to contribute to the development of OpenStack, you must follow the steps documented at: https://docs.openstack.org/infra/manual/developers.html#development-workflow Pull requests submitted through GitHub will be ignored. Bugs should be filed on Launchpad, not GitHub: https://bugs.launchpad.net/ironic ironic-10.1.1/.mailmap0000666000175100017510000000022413243617463014533 0ustar zuulzuul00000000000000# Format is: # # Joe Gordon ironic-10.1.1/devstack/0000775000175100017510000000000013243617733014716 5ustar zuulzuul00000000000000ironic-10.1.1/devstack/tools/0000775000175100017510000000000013243617733016056 5ustar zuulzuul00000000000000ironic-10.1.1/devstack/tools/ironic/0000775000175100017510000000000013243617733017341 5ustar zuulzuul00000000000000ironic-10.1.1/devstack/tools/ironic/scripts/0000775000175100017510000000000013243617733021030 5ustar zuulzuul00000000000000ironic-10.1.1/devstack/tools/ironic/scripts/setup-network.sh0000777000175100017510000000210313243617463024214 0ustar zuulzuul00000000000000#!/usr/bin/env bash # **setup-network** # Setups openvswitch libvirt network suitable for # running baremetal poseur nodes for ironic testing purposes set -exu # Make tracing more educational export PS4='+ ${BASH_SOURCE:-}:${FUNCNAME[0]:-}:L${LINENO:-}: ' LIBVIRT_CONNECT_URI=${LIBVIRT_CONNECT_URI:-"qemu:///system"} # Keep track of the DevStack directory TOP_DIR=$(cd $(dirname "$0")/.. && pwd) BRIDGE_NAME=${1:-brbm} PUBLIC_BRIDGE_MTU=${2:-1500} export VIRSH_DEFAULT_CONNECT_URI="$LIBVIRT_CONNECT_URI" # Only add bridge if missing. Bring it UP. (sudo ovs-vsctl list-br | grep ${BRIDGE_NAME}$) || sudo ovs-vsctl add-br ${BRIDGE_NAME} sudo ip link set dev ${BRIDGE_NAME} up # Remove bridge before replacing it. (virsh net-list | grep "${BRIDGE_NAME} ") && virsh net-destroy ${BRIDGE_NAME} (virsh net-list --inactive | grep "${BRIDGE_NAME} ") && virsh net-undefine ${BRIDGE_NAME} virsh net-define <(sed s/brbm/$BRIDGE_NAME/ $TOP_DIR/templates/brbm.xml) virsh net-autostart ${BRIDGE_NAME} virsh net-start ${BRIDGE_NAME} sudo ip link set dev ${BRIDGE_NAME} mtu $PUBLIC_BRIDGE_MTU ironic-10.1.1/devstack/tools/ironic/scripts/configure-vm.py0000777000175100017510000001152413243617463024013 0ustar zuulzuul00000000000000#!/usr/bin/env python # # Licensed under the Apache License, Version 2.0 (the "License"); you may # not use this file except in compliance with the License. You may obtain # a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, WITHOUT # WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the # License for the specific language governing permissions and limitations # under the License. import argparse import os.path import jinja2 import libvirt templatedir = os.path.join(os.path.dirname(os.path.dirname(__file__)), 'templates') CONSOLE_LOG = """ """ CONSOLE_PTY = """ """ def main(): parser = argparse.ArgumentParser( description="Configure a kvm virtual machine for the seed image.") parser.add_argument('--name', default='seed', help='the name to give the machine in libvirt.') parser.add_argument('--image', help='Use a custom image file (must be qcow2).') parser.add_argument('--engine', default='qemu', help='The virtualization engine to use') parser.add_argument('--arch', default='i686', help='The architecture to use') parser.add_argument('--memory', default='2097152', help="Maximum memory for the VM in KB.") parser.add_argument('--cpus', default='1', help="CPU count for the VM.") parser.add_argument('--bootdev', default='hd', help="What boot device to use (hd/network).") parser.add_argument('--libvirt-nic-driver', default='virtio', help='The libvirt network driver to use') parser.add_argument('--interface-count', default=1, type=int, help='The number of interfaces to add to VM.'), parser.add_argument('--mac', default=None, help='The mac for the first interface on the vm') parser.add_argument('--console-log', help='File to log console') parser.add_argument('--emulator', default=None, help='Path to emulator bin for vm template') parser.add_argument('--disk-format', default='qcow2', help='Disk format to use.') parser.add_argument('--uefi-loader', default='', help='The absolute path of the UEFI firmware blob.') parser.add_argument('--uefi-nvram', default='', help=('The absolute path of the non-volatile memory ' 'to store the UEFI variables. Should be used ' 'only when --uefi-loader is also specified.')) args = parser.parse_args() env = jinja2.Environment(loader=jinja2.FileSystemLoader(templatedir)) template = env.get_template('vm.xml') params = { 'name': args.name, 'imagefile': args.image, 'engine': args.engine, 'arch': args.arch, 'memory': args.memory, 'cpus': args.cpus, 'bootdev': args.bootdev, 'interface_count': args.interface_count, 'mac': args.mac, 'nicdriver': args.libvirt_nic_driver, 'emulator': args.emulator, 'disk_format': args.disk_format, 'uefi_loader': args.uefi_loader, 'uefi_nvram': args.uefi_nvram, } if args.emulator: params['emulator'] = args.emulator else: qemu_kvm_locations = ['/usr/bin/kvm', '/usr/bin/qemu-kvm', '/usr/libexec/qemu-kvm'] for location in qemu_kvm_locations: if os.path.exists(location): params['emulator'] = location break else: raise RuntimeError("Unable to find location of kvm executable") if args.console_log: params['console'] = CONSOLE_LOG % {'console_log': args.console_log} else: params['console'] = CONSOLE_PTY libvirt_template = template.render(**params) conn = libvirt.open("qemu:///system") a = conn.defineXML(libvirt_template) print("Created machine %s with UUID %s" % (args.name, a.UUIDString())) if __name__ == '__main__': main() ironic-10.1.1/devstack/tools/ironic/scripts/cleanup-node.sh0000777000175100017510000000203513243617463023743 0ustar zuulzuul00000000000000#!/usr/bin/env bash # **cleanup-nodes** # Cleans up baremetal poseur nodes and volumes created during ironic setup # Assumes calling user has proper libvirt group membership and access. set -exu # Make tracing more educational export PS4='+ ${BASH_SOURCE:-}:${FUNCNAME[0]:-}:L${LINENO:-}: ' LIBVIRT_STORAGE_POOL=${LIBVIRT_STORAGE_POOL:-"default"} LIBVIRT_CONNECT_URI=${LIBVIRT_CONNECT_URI:-"qemu:///system"} NAME=$1 export VIRSH_DEFAULT_CONNECT_URI=$LIBVIRT_CONNECT_URI VOL_NAME="$NAME.qcow2" virsh list | grep -q $NAME && virsh destroy $NAME virsh list --inactive | grep -q $NAME && virsh undefine $NAME --nvram # Delete the Virtual BMC if [[ $(type -P vbmc) != "" ]]; then vbmc list | grep -a $NAME && vbmc delete $NAME fi if virsh pool-list | grep -q $LIBVIRT_STORAGE_POOL ; then virsh vol-list $LIBVIRT_STORAGE_POOL | grep -q $VOL_NAME && virsh vol-delete $VOL_NAME --pool $LIBVIRT_STORAGE_POOL fi sudo brctl delif br-$NAME ovs-$NAME || true sudo ip link set dev br-$NAME down || true sudo brctl delbr br-$NAME || true ironic-10.1.1/devstack/tools/ironic/scripts/create-node.sh0000777000175100017510000001073413243617463023564 0ustar zuulzuul00000000000000#!/usr/bin/env bash # **create-nodes** # Creates baremetal poseur nodes for ironic testing purposes set -ex # Make tracing more educational export PS4='+ ${BASH_SOURCE:-}:${FUNCNAME[0]:-}:L${LINENO:-}: ' # Keep track of the DevStack directory TOP_DIR=$(cd $(dirname "$0")/.. && pwd) while getopts "n:c:i:m:M:d:a:b:e:E:p:o:f:l:L:N:A:" arg; do case $arg in n) NAME=$OPTARG;; c) CPU=$OPTARG;; i) INTERFACE_COUNT=$OPTARG;; M) INTERFACE_MTU=$OPTARG;; m) MEM=$(( 1024 * OPTARG ));; # Extra G to allow fuzz for partition table : flavor size and registered # size need to be different to actual size. d) DISK=$(( OPTARG + 1 ));; a) ARCH=$OPTARG;; b) BRIDGE=$OPTARG;; e) EMULATOR=$OPTARG;; E) ENGINE=$OPTARG;; p) VBMC_PORT=$OPTARG;; o) PDU_OUTLET=$OPTARG;; f) DISK_FORMAT=$OPTARG;; l) LOGDIR=$OPTARG;; L) UEFI_LOADER=$OPTARG;; N) UEFI_NVRAM=$OPTARG;; A) MAC_ADDRESS=$OPTARG;; esac done shift $(( $OPTIND - 1 )) if [ -z "$UEFI_LOADER" ] && [ ! -z "$UEFI_NVRAM" ]; then echo "Parameter -N (UEFI NVRAM) cannot be used without -L (UEFI Loader)" exit 1 fi LIBVIRT_NIC_DRIVER=${LIBVIRT_NIC_DRIVER:-"virtio"} LIBVIRT_STORAGE_POOL=${LIBVIRT_STORAGE_POOL:-"default"} LIBVIRT_CONNECT_URI=${LIBVIRT_CONNECT_URI:-"qemu:///system"} export VIRSH_DEFAULT_CONNECT_URI=$LIBVIRT_CONNECT_URI if ! virsh pool-list --all | grep -q $LIBVIRT_STORAGE_POOL; then virsh pool-define-as --name $LIBVIRT_STORAGE_POOL dir --target /var/lib/libvirt/images >&2 virsh pool-autostart $LIBVIRT_STORAGE_POOL >&2 virsh pool-start $LIBVIRT_STORAGE_POOL >&2 fi pool_state=$(virsh pool-info $LIBVIRT_STORAGE_POOL | grep State | awk '{ print $2 }') if [ "$pool_state" != "running" ] ; then [ ! -d /var/lib/libvirt/images ] && sudo mkdir /var/lib/libvirt/images virsh pool-start $LIBVIRT_STORAGE_POOL >&2 fi if [ -n "$LOGDIR" ] ; then mkdir -p "$LOGDIR" fi PREALLOC= if [ -f /etc/debian_version -a "$DISK_FORMAT" == "qcow2" ]; then PREALLOC="--prealloc-metadata" fi if [ -n "$LOGDIR" ] ; then VM_LOGGING="--console-log $LOGDIR/${NAME}_console.log" else VM_LOGGING="" fi VOL_NAME="${NAME}.${DISK_FORMAT}" UEFI_OPTS="" if [ ! -z "$UEFI_LOADER" ]; then UEFI_OPTS="--uefi-loader $UEFI_LOADER" if [ ! -z "$UEFI_NVRAM" ]; then UEFI_OPTS+=" --uefi-nvram $UEFI_NVRAM" fi fi # Create bridge and add VM interface to it. # Additional interface will be added to this bridge and # it will be plugged to OVS. # This is needed in order to have interface in OVS even # when VM is in shutdown state INTERFACE_COUNT=${INTERFACE_COUNT:-1} for int in $(seq 1 $INTERFACE_COUNT); do tapif=tap-${NAME}i${int} ovsif=ovs-${NAME}i${int} # NOTE(vsaienko) use veth pair here to ensure that interface # exists in OVS even when VM is powered off. sudo ip link add dev $tapif type veth peer name $ovsif for l in $tapif $ovsif; do sudo ip link set dev $l up sudo ip link set $l mtu $INTERFACE_MTU done sudo ovs-vsctl add-port $BRIDGE $ovsif done if [ -n "$MAC_ADDRESS" ] ; then MAC_ADDRESS="--mac $MAC_ADDRESS" fi if ! virsh list --all | grep -q $NAME; then virsh vol-list --pool $LIBVIRT_STORAGE_POOL | grep -q $VOL_NAME && virsh vol-delete $VOL_NAME --pool $LIBVIRT_STORAGE_POOL >&2 virsh vol-create-as $LIBVIRT_STORAGE_POOL ${VOL_NAME} ${DISK}G --format $DISK_FORMAT $PREALLOC >&2 volume_path=$(virsh vol-path --pool $LIBVIRT_STORAGE_POOL $VOL_NAME) # Pre-touch the VM to set +C, as it can only be set on empty files. sudo touch "$volume_path" sudo chattr +C "$volume_path" || true vm_opts="" if [[ -n "$EMULATOR" ]]; then vm_opts+="--emulator $EMULATOR " fi $PYTHON $TOP_DIR/scripts/configure-vm.py \ --bootdev network --name $NAME --image "$volume_path" \ --arch $ARCH --cpus $CPU --memory $MEM --libvirt-nic-driver $LIBVIRT_NIC_DRIVER \ --disk-format $DISK_FORMAT $VM_LOGGING --engine $ENGINE $UEFI_OPTS $vm_opts \ --interface-count $INTERFACE_COUNT $MAC_ADDRESS >&2 # Createa Virtual BMC for the node if IPMI is used if [[ $(type -P vbmc) != "" ]]; then vbmc add $NAME --port $VBMC_PORT vbmc start $NAME fi fi # echo mac in format mac1,ovs-node-0i1;mac2,ovs-node-0i2;...;macN,ovs-node0iN VM_MAC=$(echo -n $(virsh domiflist $NAME |awk '/tap-/{print $5","$3}')|tr ' ' ';' |sed s/tap-/ovs-/g) echo -n "$VM_MAC $VBMC_PORT $PDU_OUTLET" ironic-10.1.1/devstack/tools/ironic/templates/0000775000175100017510000000000013243617733021337 5ustar zuulzuul00000000000000ironic-10.1.1/devstack/tools/ironic/templates/brbm.xml0000666000175100017510000000020013243617463022775 0ustar zuulzuul00000000000000 brbm ironic-10.1.1/devstack/tools/ironic/templates/vm.xml0000666000175100017510000000446713243617463022520 0ustar zuulzuul00000000000000 {{ name }} {{ memory }} {{ cpus }} hvm {% if uefi_loader %} {{ uefi_loader }} {% if uefi_nvram %} {{ uefi_nvram }} {% endif %} {% endif %} {% if engine == 'kvm' %} {% endif %} destroy restart restart {{ emulator }} {% if uefi_loader %}
{% else %}
{% endif %}
{% for n in range(1, interface_count+1) %} {% if n == 1 and mac %} {% endif %}
{% endfor %}