openstack/tripleo-docs
Code Issues Proposed changes

Retire Tripleo: remove repo content

Browse Source 
TripleO project is retiring
- https://review.opendev.org/c/openstack/governance/+/905145

this commit remove the content of this project repo

Change-Id: Ie970f3f04c78e9bfcd9212bfa97a9cc9ee376b0c
This commit is contained in:
Ghanshyam Mann
2024-02-24 11:42:59 -08:00
parent 09e3ef837b
commit d67a6ebe02
237 changed files with 8 additions and 47319 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.gitignore
-17
View File
@@ -1,17 +0,0 @@
*.swp
*~
*.qcow2
.DS_Store
*.egg*
*.pyc
.tox
doc/build
deploy-guide/source/_build
build
# pbr generates these
AUTHORS
ChangeLog
.zuul.yaml
-4
View File
@@ -1,4 +0,0 @@
- project:
templates:
- publish-openstack-docs-pti
- deploy-guide-jobs
README.rst
+8 -49
View File
@@ -1,51 +1,10 @@
========================
Team and repository tags
========================
This project is no longer maintained.
.. image:: https://governance.openstack.org/tc/badges/tripleo-docs.svg
:target: https://governance.openstack.org/tc/reference/tags/index.html
The contents of this repository are still available in the Git
source code management system. To see the contents of this
repository before it reached its end of life, please check out the
previous commit with "git checkout HEAD^1".
.. Change things from this point on
TripleO Documentation
=====================
This is the documentation source for the TripleO project. You can read
the generated documentation at `TripleO
Docs <https://docs.openstack.org/tripleo-docs/latest/>`__.
You can find out more about TripleO at the `TripleO
Wiki <https://wiki.openstack.org/wiki/TripleO>`__.
Getting Started
---------------
Documentation for the TripleO project is hosted on the OpenStack Gerrit
site. You can view all open and resolved issues in the
``openstack/tripleo-docs`` project at `TripleO
Reviews <https://review.opendev.org/#/q/project:openstack/tripleo-docs>`__.
General information about contributing to the OpenStack documentation
available at `OpenStack Documentation Contributor
Guide <https://docs.openstack.org/doc-contrib-guide/>`__
Quick Start
-----------
The following is a quick set of instructions to get you up and running
by building the TripleO documentation locally. The first step is to get
your Python environment configured. Information on configuring is
available at `Python Project
Guide <https://docs.openstack.org/project-team-guide/project-setup/python.html>`__
Next you can generate the documentation using the following command. Be
sure to run all the commands from within the recently checked out
repository.
::
tox -edocs,pdf-docs,deploy-guide
Now you have the documentation generated for the various available
formats from the local source. The resulting documentation will be
available within the ``doc/build/`` directory.
For any further questions, please email
openstack-discuss@lists.openstack.org or join #openstack-dev on
OFTC.
_custom/admonition_selector.js
-58
View File
@@ -1,58 +0,0 @@
/*
This function will search for all classes matching all IDs which are under
#admonition_selector element and display/hide their content.
State is saved in cookies so user doesn't lose his settings after page
reload or changing pages.
To make this feature work, you need to:
- add checkbox to _templates/layout.html file with proper ID
- in admonitions use proper class which matches above mentioned ID
*/
// after document is loaded
$(document).ready(function() {
// for each checkbox in #admonition_selector do
$('#admonition_selector :checkbox').each(function() {
// check value of cookies and set state to the related element
if ($.cookie($(this).attr("id")) == "true") {
$(this).prop("checked", true);
} else {
$(this).prop("checked", false);
}
// show/hide elements after page loaded
toggle_admonition($(this).attr("id"));
});
// when user clicks on the checkbox, react
$('#admonition_selector :checkbox').change(function() {
// show/hide related elements
toggle_admonition($(this).attr("id"));
// save the state in the cookies
$.cookie($(this).attr("id"), $(this).is(':checked'), { path: '/' });
});
});
// function to show/hide elements based on checkbox state
// checkbox has ID and it toggles elements having class named same way as the ID
function toggle_admonition(admonition) {
// for each element having class as the checkbox's ID
$(".admonition." + admonition).each(function() {
// set show/hide
if($("#" + admonition).is(':checked')) {
$(this).show();
} else {
$(this).hide();
}
});
}
_custom/cookies.js
-117
View File
@@ -1,117 +0,0 @@
/*!
* jQuery Cookie Plugin v1.4.1
* https://github.com/carhartl/jquery-cookie
*
* Copyright 2013 Klaus Hartl
* Released under the MIT license
*/
(function (factory) {
if (typeof define === 'function' && define.amd) {
// AMD
define(['jquery'], factory);
} else if (typeof exports === 'object') {
// CommonJS
factory(require('jquery'));
} else {
// Browser globals
factory(jQuery);
}
}(function ($) {
var pluses = /\+/g;
function encode(s) {
return config.raw ? s : encodeURIComponent(s);
}
function decode(s) {
return config.raw ? s : decodeURIComponent(s);
}
function stringifyCookieValue(value) {
return encode(config.json ? JSON.stringify(value) : String(value));
}
function parseCookieValue(s) {
if (s.indexOf('"') === 0) {
// This is a quoted cookie as according to RFC2068, unescape...
s = s.slice(1, -1).replace(/\\"/g, '"').replace(/\\\\/g, '\\');
}
try {
// Replace server-side written pluses with spaces.
// If we can't decode the cookie, ignore it, it's unusable.
// If we can't parse the cookie, ignore it, it's unusable.
s = decodeURIComponent(s.replace(pluses, ' '));
return config.json ? JSON.parse(s) : s;
} catch(e) {}
}
function read(s, converter) {
var value = config.raw ? s : parseCookieValue(s);
return $.isFunction(converter) ? converter(value) : value;
}
var config = $.cookie = function (key, value, options) {
// Write
if (value !== undefined && !$.isFunction(value)) {
options = $.extend({}, config.defaults, options);
if (typeof options.expires === 'number') {
var days = options.expires, t = options.expires = new Date();
t.setTime(+t + days * 864e+5);
}
return (document.cookie = [
encode(key), '=', stringifyCookieValue(value),
options.expires ? '; expires=' + options.expires.toUTCString() : '', // use expires attribute, max-age is not supported by IE
options.path ? '; path=' + options.path : '',
options.domain ? '; domain=' + options.domain : '',
options.secure ? '; secure' : ''
].join(''));
}
// Read
var result = key ? undefined : {};
// To prevent the for loop in the first place assign an empty array
// in case there are no cookies at all. Also prevents odd result when
// calling $.cookie().
var cookies = document.cookie ? document.cookie.split('; ') : [];
for (var i = 0, l = cookies.length; i < l; i++) {
var parts = cookies[i].split('=');
var name = decode(parts.shift());
var cookie = parts.join('=');
if (key && key === name) {
// If second argument (value) is a function it's a converter...
result = read(cookie, value);
break;
}
// Prevent storing a cookie that we couldn't decode.
if (!key && (cookie = read(cookie)) !== undefined) {
result[name] = cookie;
}
}
return result;
};
config.defaults = {};
$.removeCookie = function (key, options) {
if ($.cookie(key) === undefined) {
return false;
}
// Must not alter options, thus extending a fresh object...
$.cookie(key, '', $.extend({}, options, { expires: -1 }));
return !$.cookie(key);
};
}));
_custom/custom.css
-146
View File
@@ -1,146 +0,0 @@
/* CUSTOM CSS OVERRIDES GO HERE */
/* ============================ */
/* remove backgrounds */
#admonition_selector {
background: none !important;
color: black !important;
}
/* admonition selector */
#admonition_selector {
border-top: 0 none !important;
}
#admonition_selector .title {
color: rgba(0, 0, 0, 0.6) !important;
}
.trigger {
color: rgba(0, 0, 0, 0.7) !important;
border-top: 1px solid rgba(0, 0, 0, 0.2);
border-bottom: 1px solid rgba(0, 0, 0, 0.2);
background: rgba(0, 0, 0, 0.05);
}
.trigger:hover {
color: rgba(0, 0, 0, 0.9) !important;
}
/* NOTES, ADMONITIONS AND TAGS */
.admonition {
font-size: 85%; /* match code size */
background: rgb(240, 240, 240);
color: rgba(0, 0, 0, 0.55);
border: 1px solid rgba(0, 0, 0, 0.1);
padding: 0.5em 1em 0.75em 1em;
margin-bottom: 24px;
}
.admonition .admonition {
/* Don't keep shrinking the font for nested admonitions. */
font-size: 100%;
}
.admonition p {
font-size: inherit;
}
.admonition p.last {
margin-bottom: 0;
}
.admonition p.first.admonition-title {
display: inline;
background: none;
font-weight: bold;
color: rgba(0, 0, 0, 0.75);
}
/* notes */
.rst-content .note {
background: rgb(240, 240, 240);
}
/* tags */
.fedora28 {background: #aee;}
.centos7 {background: #cea;}
.centos8 {background: #cae;}
.rhel {background: #fee;}
.portal {background-color: #ded;}
.satellite {background-color: #dee;}
.stable {background: #eed;}
.newton {background: #ede;}
.ocata {background: #edd;}
.pike {background: #dfb;}
.queens {background: #afd;}
.rocky {background: #aee;}
.stein {background: #ade;}
.centos {background: #fef;}
.baremetal {background: #eef;}
.virtual {background: #efe;}
.ceph {background: #eff;}
.mton {background: #ded;}
.ntoo {background: #edd;}
.otop {background: #dfb;}
.ptoq {background: #afd;}
.qtor {background: #aee;}
.rtos {background: #ade;}
.validations {background: #fdd;}
.optional {background: #ffe;}
.tls {background: #ded;}
/* admonition selector */
#admonition_selector {
color: white;
font-size: 85%;
line-height: 1.4;
background: #2980b9;
border-top: 1px solid rgba(255, 255, 255, 0.4);
}
.trigger {
color: rgba(255, 255, 255, 0.75);
line-height: 2.5;
position: relative;
cursor: pointer;
padding: 0 1.618em;
}
.trigger:after {
content: '▾';
font-family: FontAwesome;
}
.trigger:hover {
color: white;
}
.content {
display: none;
border-top: 1px solid rgba(255, 255, 255, 0.1);
background: rgba(255, 255, 255, 0.1);
padding: 0.5em 1.618em;
}
.displayed .trigger:after {
content: '▴';
}
#admonition_selector .title {
color: rgba(255, 255, 255, 0.45);
}
#admonition_selector ul {
margin-bottom: 0.75em;
}
#admonition_selector ul li {
display: block;
}
#admonition_selector label {
display: inline;
color: inherit;
text-decoration: underline dotted;
}
_custom/expandable.js
-31
View File
@@ -1,31 +0,0 @@
$(document).ready(function() {
// for each trigger
$('.trigger').each(function() {
// check if cookie has value on true
if ($.cookie($(this).parent().prop('id')) == "true") {
// add displayed class and show the content
$(this).parent().addClass("displayed");
$(this).next('.content').show();
} else {
// remove displayed class and hide the content
$(this).parent().removeClass("displayed");
$(this).next('.content').hide();
}
});
// if user clicked trigger element
$('.trigger').click(function() {
// toggle parent's class and animate the content
$(this).parent().toggleClass('displayed');
$(this).next('.content').slideToggle("fast");
// save the state to cookies
$.cookie($(this).parent().prop('id'),
$(this).parent().hasClass('displayed'),
{ path: '/' });
});
});
_custom/jquery.nav.js
-223
View File
@@ -1,223 +0,0 @@
/*
* jQuery One Page Nav Plugin
* http://github.com/davist11/jQuery-One-Page-Nav
*
* Copyright (c) 2010 Trevor Davis (http://trevordavis.net)
* Dual licensed under the MIT and GPL licenses.
* Uses the same license as jQuery, see:
* http://jquery.org/license
*
* @version 3.0.0
*
* Example usage:
* $('#nav').onePageNav({
* currentClass: 'current',
* changeHash: false,
* scrollSpeed: 750
* });
*/
;(function($, window, document, undefined){
// our plugin constructor
var OnePageNav = function(elem, options){
this.elem = elem;
this.$elem = $(elem);
this.options = options;
this.metadata = this.$elem.data('plugin-options');
this.$win = $(window);
this.sections = {};
this.didScroll = false;
this.$doc = $(document);
this.docHeight = this.$doc.height();
};
// the plugin prototype
OnePageNav.prototype = {
defaults: {
navItems: 'a',
currentClass: 'active',
changeHash: false,
easing: 'swing',
filter: '',
scrollSpeed: 750,
scrollThreshold: 0.2,
begin: false,
end: false,
scrollChange: false
},
init: function() {
// Introduce defaults that can be extended either
// globally or using an object literal.
this.config = $.extend({}, this.defaults, this.options, this.metadata);
this.$nav = this.$elem.find(this.config.navItems);
//Filter any links out of the nav
if(this.config.filter !== '') {
this.$nav = this.$nav.filter(this.config.filter);
}
//Handle clicks on the nav
this.$nav.on('click.onePageNav', $.proxy(this.handleClick, this));
//Get the section positions
this.getPositions();
//Handle scroll changes
this.bindInterval();
//Update the positions on resize too
this.$win.on('resize.onePageNav', $.proxy(this.getPositions, this));
return this;
},
adjustNav: function(self, $parent) {
self.$elem.find('.' + self.config.currentClass).removeClass(self.config.currentClass);
$parent.addClass(self.config.currentClass);
},
bindInterval: function() {
var self = this;
var docHeight;
self.$win.on('scroll.onePageNav', function() {
self.didScroll = true;
});
self.t = setInterval(function() {
docHeight = self.$doc.height();
//If it was scrolled
if(self.didScroll) {
self.didScroll = false;
self.scrollChange();
}
//If the document height changes
if(docHeight !== self.docHeight) {
self.docHeight = docHeight;
self.getPositions();
}
}, 250);
},
getHash: function($link) {
return $link.attr('href').split('#')[1];
},
getPositions: function() {
var self = this;
var linkHref;
var topPos;
var $target;
self.$nav.each(function() {
linkHref = self.getHash($(this));
$target = $('#' + linkHref);
if($target.length) {
topPos = $target.offset().top;
self.sections[linkHref] = Math.round(topPos);
}
});
},
getSection: function(windowPos) {
var returnValue = null;
var windowHeight = Math.round(this.$win.height() * this.config.scrollThreshold);
for(var section in this.sections) {
if((this.sections[section] - windowHeight) < windowPos) {
returnValue = section;
}
}
return returnValue;
},
handleClick: function(e) {
var self = this;
var $link = $(e.currentTarget);
var $parent = $link.parent();
var newLoc = '#' + self.getHash($link);
if(!$parent.hasClass(self.config.currentClass)) {
//Start callback
if(self.config.begin) {
self.config.begin();
}
//Change the highlighted nav item
self.adjustNav(self, $parent);
//Removing the auto-adjust on scroll
self.unbindInterval();
//Scroll to the correct position
self.scrollTo(newLoc, function() {
//Do we need to change the hash?
if(self.config.changeHash) {
window.location.hash = newLoc;
}
//Add the auto-adjust on scroll back in
self.bindInterval();
//End callback
if(self.config.end) {
self.config.end();
}
});
}
e.preventDefault();
},
scrollChange: function() {
var windowTop = this.$win.scrollTop();
var position = this.getSection(windowTop);
var $parent;
//If the position is set
if(position !== null) {
$parent = this.$elem.find('a[href$="#' + position + '"]').parent();
//If it's not already the current section
if(!$parent.hasClass(this.config.currentClass)) {
//Change the highlighted nav item
this.adjustNav(this, $parent);
//If there is a scrollChange callback
if(this.config.scrollChange) {
this.config.scrollChange($parent);
}
}
}
},
scrollTo: function(target, callback) {
var offset = $(target).offset().top;
$('html, body').animate({
scrollTop: offset
}, this.config.scrollSpeed, this.config.easing, callback);
},
unbindInterval: function() {
clearInterval(this.t);
this.$win.unbind('scroll.onePageNav');
}
};
OnePageNav.defaults = OnePageNav.prototype.defaults;
$.fn.onePageNav = function(options) {
return this.each(function() {
new OnePageNav(this, options).init();
});
};
})( jQuery, window , document );
_custom/jquery.scrollTo.js
-208
View File
@@ -1,208 +0,0 @@
/*!
* jQuery.scrollTo
* Copyright (c) 2007-2015 Ariel Flesler - aflesler<a>gmail<d>com | http://flesler.blogspot.com
* Licensed under MIT
* http://flesler.blogspot.com/2007/10/jqueryscrollto.html
* @projectDescription Easy element scrolling using jQuery.
* @author Ariel Flesler
* @version 2.1.0
*/
;(function(define) {
'use strict';
define(['jquery'], function($) {
var $scrollTo = $.scrollTo = function(target, duration, settings) {
return $(window).scrollTo(target, duration, settings);
};
$scrollTo.defaults = {
axis:'xy',
duration: 0,
limit:true
};
function isWin(elem) {
return !elem.nodeName ||
$.inArray(elem.nodeName.toLowerCase(), ['iframe','#document','html','body']) !== -1;
}
$.fn.scrollTo = function(target, duration, settings) {
if (typeof duration === 'object') {
settings = duration;
duration = 0;
}
if (typeof settings === 'function') {
settings = { onAfter:settings };
}
if (target === 'max') {
target = 9e9;
}
settings = $.extend({}, $scrollTo.defaults, settings);
// Speed is still recognized for backwards compatibility
duration = duration || settings.duration;
// Make sure the settings are given right
var queue = settings.queue && settings.axis.length > 1;
if (queue) {
// Let's keep the overall duration
duration /= 2;
}
settings.offset = both(settings.offset);
settings.over = both(settings.over);
return this.each(function() {
// Null target yields nothing, just like jQuery does
if (target === null) return;
var win = isWin(this),
elem = win ? this.contentWindow || window : this,
$elem = $(elem),
targ = target,
attr = {},
toff;
switch (typeof targ) {
// A number will pass the regex
case 'number':
case 'string':
if (/^([+-]=?)?\d+(\.\d+)?(px|%)?$/.test(targ)) {
targ = both(targ);
// We are done
break;
}
// Relative/Absolute selector
targ = win ? $(targ) : $(targ, elem);
if (!targ.length) return;
/* falls through */
case 'object':
// DOMElement / jQuery
if (targ.is || targ.style) {
// Get the real position of the target
toff = (targ = $(targ)).offset();
}
}
var offset = $.isFunction(settings.offset) && settings.offset(elem, targ) || settings.offset;
$.each(settings.axis.split(''), function(i, axis) {
var Pos = axis === 'x' ? 'Left' : 'Top',
pos = Pos.toLowerCase(),
key = 'scroll' + Pos,
prev = $elem[key](),
max = $scrollTo.max(elem, axis);
if (toff) {// jQuery / DOMElement
attr[key] = toff[pos] + (win ? 0 : prev - $elem.offset()[pos]);
// If it's a dom element, reduce the margin
if (settings.margin) {
attr[key] -= parseInt(targ.css('margin'+Pos), 10) || 0;
attr[key] -= parseInt(targ.css('border'+Pos+'Width'), 10) || 0;
}
attr[key] += offset[pos] || 0;
if (settings.over[pos]) {
// Scroll to a fraction of its width/height
attr[key] += targ[axis === 'x'?'width':'height']() * settings.over[pos];
}
} else {
var val = targ[pos];
// Handle percentage values
attr[key] = val.slice && val.slice(-1) === '%' ?
parseFloat(val) / 100 * max
: val;
}
// Number or 'number'
if (settings.limit && /^\d+$/.test(attr[key])) {
// Check the limits
attr[key] = attr[key] <= 0 ? 0 : Math.min(attr[key], max);
}
// Don't waste time animating, if there's no need.
if (!i && settings.axis.length > 1) {
if (prev === attr[key]) {
// No animation needed
attr = {};
} else if (queue) {
// Intermediate animation
animate(settings.onAfterFirst);
// Don't animate this axis again in the next iteration.
attr = {};
}
}
});
animate(settings.onAfter);
function animate(callback) {
var opts = $.extend({}, settings, {
// The queue setting conflicts with animate()
// Force it to always be true
queue: true,
duration: duration,
complete: callback && function() {
callback.call(elem, targ, settings);
}
});
$elem.animate(attr, opts);
}
});
};
// Max scrolling position, works on quirks mode
// It only fails (not too badly) on IE, quirks mode.
$scrollTo.max = function(elem, axis) {
var Dim = axis === 'x' ? 'Width' : 'Height',
scroll = 'scroll'+Dim;
if (!isWin(elem))
return elem[scroll] - $(elem)[Dim.toLowerCase()]();
var size = 'client' + Dim,
doc = elem.ownerDocument || elem.document,
html = doc.documentElement,
body = doc.body;
return Math.max(html[scroll], body[scroll]) - Math.min(html[size], body[size]);
};
function both(val) {
return $.isFunction(val) || $.isPlainObject(val) ? val : { top:val, left:val };
}
// Add special hooks so that window scroll properties can be animated
$.Tween.propHooks.scrollLeft =
$.Tween.propHooks.scrollTop = {
get: function(t) {
return $(t.elem)[t.prop]();
},
set: function(t) {
var curr = this.get(t);
// If interrupt is true and user scrolled, stop animating
if (t.options.interrupt && t._last && t._last !== curr) {
return $(t.elem).stop();
}
var next = Math.round(t.now);
// Don't waste CPU
// Browsers don't render floating point scroll
if (curr !== next) {
$(t.elem)[t.prop](next);
t._last = this.get(t);
}
}
};
// AMD requirement
return $scrollTo;
});
}(typeof define === 'function' && define.amd ? define : function(deps, factory) {
'use strict';
if (typeof module !== 'undefined' && module.exports) {
// Node
module.exports = factory(require('jquery'));
} else {
factory(jQuery);
}
}));
_custom/menu.js
-3
View File
@@ -1,3 +0,0 @@
$(document).ready(function() {
$('.wy-menu').onePageNav();
});
_templates/layout.html
-65
View File
@@ -1,65 +0,0 @@
{% extends "!layout.html" %}
{% set script_files = script_files + ["_static/cookies.js"] %}
{% set script_files = script_files + ["_static/expandable.js"] %}
{% set script_files = script_files + ["_static/admonition_selector.js"] %}
{% set script_files = script_files + ["_static/jquery.scrollTo.js"] %}
{% set script_files = script_files + ["_static/jquery.nav.js"] %}
{% set script_files = script_files + ["_static/menu.js"] %}
{% set css_files = css_files + ['_static/custom.css'] %}
{% block otherversions %}
<div id="admonition_selector">
<span class="trigger">Limit Environment Specific Content</span>
<div class="content">
<span class="title">Operating Systems</span>
<ul>
<li><input type="checkbox" id="centos" checked="checked"><label for="centos" title="Step that should only be run when using CentOS.">CentOS</label></li>
<li><input type="checkbox" id="rhel" checked="checked"><label for="rhel" title="Step that should only be run when using RHEL.">RHEL</label></li>
</ul>
<span class="title">Branches</span>
<ul>
<li><input type="checkbox" id="stable" checked=""><label for="stable" title="Step that should only be run when choosing to use components from their stable branches rather than using packages/source based on current master.">Install from stable branch</label></li>
<li><input type="checkbox" id="newton" checked=""><label for="newton" title="Step that should only be run when installing from the Newton stable branch.">Install from Newton branch</label></li>
<li><input type="checkbox" id="ocata" checked=""><label for="ocata" title="Step that should only be run when installing from the Ocata stable branch.">Install from Ocata branch</label></li>
</ul>
<span class="title">RHEL Registration Types</span>
<ul>
<li><input type="checkbox" id="portal" checked="checked"><label for="portal" title="Step that should only be run when registering to the Red Hat Portal.">Portal</label></li>
<li><input type="checkbox" id="satellite" checked="checked"><label for="satellite" title="Step that should only be run when registering to Red Hat Satellite.">Satellite</label></li>
</ul>
<span class="title">Environments</span>
<ul>
<li><input type="checkbox" id="baremetal" checked="checked"><label for="baremetal" title="Step that should only be run when deploying to baremetal.">Baremetal</label></li>
<li><input type="checkbox" id="virtual" checked="checked"><label for="virtual" title="Step that should only be run when deploying to virtual machines.">Virtual</label></li>
</ul>
<span class="title">Features</span>
<ul>
<li><input type="checkbox" id="validations" checked="checked"><label for="validations" title="Step that should only be run when deploying with validations.">Validations</label></li>
<li><input type="checkbox" id="optional" checked="checked"><label for="optional" title="Step that is optional. A deployment can be done without these steps, but they may provide useful additional functionality.">Optional</label></li>
</ul>
<span class="title">Additional Overcloud Roles</span>
<ul>
<li><input type="checkbox" id="ceph" checked="checked"><label for="ceph" title="Step that should only be run when deploying Ceph for use by the Overcloud.">Ceph</label></li>
</ul>
<span class="title">Upgrade Version</span>
<ul>
<li><input type="checkbox" id="mton" checked="checked"><label for="mton" title="Step that should only be run for upgrading from Mitaka to Newton">Upgrading Mitaka to Newton</label></li>
<li><input type="checkbox" id="ntoo" checked="checked"><label for="ntoo" title="Step that should only be run for upgrading from Newton to Ocata">Upgrading Newton to Ocata</label></li>
<li><input type="checkbox" id="otop" checked="checked"><label for="otop" title="Step that should only be run for upgrading from Ocata to Pike">Upgrading Ocata to Pike</label></li>
</ul>
</div>
</div>
{{ super() }}
{% endblock %}
bindep.txt
-2
View File
@@ -1,2 +0,0 @@
librsvg2-tools [doc platform:rpm]
librsvg2-bin [doc platform:dpkg]
deploy-guide/source/_images/TripleO_Network_Diagram_.jpg
BIN
View File
Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 92 KiB

deploy-guide/source/_images/spine_and_leaf.svg
-938
View File
@@ -1,938 +0,0 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
version="1.2"
width="221.28786mm"
height="95.618492mm"
viewBox="0 0 22128.785 9561.849"
preserveAspectRatio="xMidYMid"
clip-path="url(#presentation_clip_path)"
xml:space="preserve"
id="svg2"
inkscape:version="0.92.2 (5c3e80d, 2017-08-06)"
sodipodi:docname="spine_and_leaf.svg"
inkscape:export-filename="/home/remote/hjensas/Documents/Projects/FKassan/spine_and_leaf_grey.png"
inkscape:export-xdpi="90"
inkscape:export-ydpi="90"
style="fill-rule:evenodd;stroke-width:28.22200012;stroke-linejoin:round"><metadata
id="metadata2202"><rdf:RDF><cc:Work
rdf:about=""><dc:format>image/svg+xml</dc:format><dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" /><dc:title></dc:title></cc:Work></rdf:RDF></metadata><sodipodi:namedview
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1"
objecttolerance="10"
gridtolerance="10"
guidetolerance="10"
inkscape:pageopacity="0"
inkscape:pageshadow="2"
inkscape:window-width="1920"
inkscape:window-height="1016"
id="namedview2200"
showgrid="true"
inkscape:zoom="1"
inkscape:cx="325.01545"
inkscape:cy="362.39456"
inkscape:window-x="0"
inkscape:window-y="27"
inkscape:window-maximized="1"
inkscape:current-layer="svg2"
fit-margin-top="0"
fit-margin-left="0"
fit-margin-right="0"
fit-margin-bottom="0"
showguides="false"
inkscape:snap-grids="true"
inkscape:snap-bbox="true"><inkscape:grid
type="xygrid"
id="grid2162"
originx="-3557.8186"
originy="-465.85891" /></sodipodi:namedview><defs
class="ClipPathGroup"
id="defs4"><clipPath
id="presentation_clip_path"
clipPathUnits="userSpaceOnUse"><rect
x="0"
y="0"
width="21000"
height="14800"
id="rect7" /></clipPath></defs><defs
class="TextShapeIndex"
id="defs9" /><defs
class="EmbeddedBulletChars"
id="defs13" /><defs
class="TextEmbeddedBitmaps"
id="defs42" /><rect
style="fill:#000000;fill-opacity:0.26666667;fill-rule:evenodd;stroke:none;stroke-width:99.59664917;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
id="rect7472-1-4"
width="21068.076"
height="3327.2278"
x="1060.71"
y="5783.6973"
ry="493.24051" /><rect
style="fill:#000000;fill-opacity:0.26666667;stroke:none;stroke-width:70.56232452;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
id="rect7472"
width="21172.889"
height="1661.8187"
x="955.89368"
y="0"
ry="246.35416" /><rect
style="fill:#000000;fill-opacity:0.26666667;stroke-width:23.36642456;stroke-miterlimit:4;stroke-dasharray:186.93141099, 93.46570549;stroke-dashoffset:0"
id="rect7187"
width="4004.1733"
height="5368.9526"
x="1060.71"
y="4192.897"
ry="244.64894" /><g
id="g44"
transform="translate(-3557.8188,-1102.0474)"><g
id="id2"
class="Master_Slide"><g
id="bg-id2"
class="Background" /><g
id="bo-id2"
class="BackgroundObjects" /></g></g><path
style="fill:none;stroke:#000000;stroke-width:13.56770134;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:108.54160421, 54.2708021;stroke-dashoffset:0;stroke-opacity:1"
d="m 925.65479,5022.3992 c -60.51808,14.927 -121.17892,9.0977 -181.76702,9.0977 -172.42701,0 -344.8541,0 -517.28111,0 -45.48585,0 -53.55151,0 -91.5542,0 -9.15541,0 -18.31082,0 -27.46622,0 -3.05182,0 -6.10366,0 -9.155409,0 -1.525908,0 -6.103651,0 -4.577737,0 3.051829,0 12.207226,0 9.155406,0 -6.103577,0 -12.207234,0 -18.31081,0 -19.836723,0 -39.673445,0 -59.510248,0 -4.577662,0 -9.155405,0 -13.733067,0 -1.5259141,0 -5.2813943,5.859 -4.5777418,0 0.9296198,-7.7403 3.7802008,-6.065 5.6703408,-9.0977"
id="path6251"
inkscape:connector-curvature="0" /><text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:329.94973755px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:232.79600525"
x="227.58598"
y="4397.6118"
id="text6255"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan6253"
x="227.58598"
y="4397.6118"
style="stroke-width:232.79600525">L3</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:367.5909729px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:259.3538208"
x="211.54889"
y="4957.1426"
id="text6259"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan6257"
x="211.54889"
y="4957.1426"
style="stroke-width:259.3538208">L2</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:386.90072632px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:272.9777832"
x="2280.334"
y="5325.6221"
id="text7127"><tspan
sodipodi:role="line"
id="tspan7125"
x="2280.334"
y="5667.9385"
style="stroke-width:272.9777832" /></text>
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:386.90075684px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:272.97781372;stroke-linejoin:round"
x="4539.1108"
y="5329.9927"
id="text7127-0"><tspan
sodipodi:role="line"
id="tspan7125-3"
x="4539.1108"
y="5672.3091"
style="stroke-width:272.97781372" /></text>
<rect
id="rect2109-6-5-9-0"
width="5118.355"
height="946.78052"
x="1670.5643"
y="305.97485"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:66.52793121;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="240.99867" /><text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:1058.33337402px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:746.70709229"
x="3481.3599"
y="1986.9637"
id="text7185"><tspan
sodipodi:role="line"
id="tspan7183"
x="3481.3599"
y="2923.3408"
style="stroke-width:746.70709229" /></text>
<path
style="fill:none;stroke:#000000;stroke-width:23.1507225px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 1675.6302,4832.0574 2442.6235,1252.7555"
id="path7189"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" /><path
style="fill:none;stroke:#000000;stroke-width:23.1507225px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 2212.0703,4727.9807 15737.173,1252.7555"
id="path7191"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" /><path
style="fill:none;stroke:#000000;stroke-width:23.1507225px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 3465.2812,4832.0574 2442.6235,1252.7555"
id="path7193"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" /><path
style="fill:none;stroke:#000000;stroke-width:23.1507225px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 3899.7681,4727.9805 15737.173,1252.7555"
id="path7195"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" /><rect
style="fill:#000000;fill-opacity:0.26666667;fill-rule:evenodd;stroke-width:23.40653419;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:187.25226202, 93.62613113;stroke-dashoffset:0"
id="rect7187-4"
width="3990.1204"
height="5406.373"
x="5995.4189"
y="4155.4761"
ry="246.35411" /><path
style="fill:none;stroke:#000000;stroke-width:23.1507225px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 16759.831,1252.7555 6825.6059,4704.2258 2953.9523,1252.7555"
id="path7446"
inkscape:connector-curvature="0"
sodipodi:nodetypes="ccc" /><path
style="fill:none;stroke:#000000;stroke-width:23.1507225px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 2953.9523,1252.7555 5852.4337,3475.225 7953.445,-3475.225"
id="path7448"
inkscape:connector-curvature="0"
sodipodi:nodetypes="ccc" /><text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:304.87020874px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:215.10116577"
x="2737.1526"
y="8551.4111"
id="text7452"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7450"
x="2737.1526"
y="8551.4111"
style="stroke-width:215.10116577">Rack A</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:304.87023926px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:215.10118103;stroke-linejoin:round"
x="8249.8623"
y="8547.1641"
id="text7452-0"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7450-5"
x="8249.8623"
y="8547.1641"
style="stroke-width:215.10118103">Rack B</tspan></text>
<rect
id="rect2109-6-5-9-8-0-5"
width="3458.9375"
height="639.16052"
x="1270.3427"
y="6059.2471"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:35.14209747;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="162.69539" /><rect
id="rect2109-6-5-9-8-0-5-0"
width="3458.9377"
height="639.16058"
x="1270.3418"
y="6877.374"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:35.14210129;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="162.6954" /><rect
id="rect2109-6-5-9-8-0-5-6"
width="3458.9377"
height="639.16058"
x="1270.3427"
y="7644.3667"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:35.14210129;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="162.6954" /><rect
id="rect2109-6-5-9-8-0-5-4"
width="3458.9377"
height="639.16058"
x="1270.3427"
y="8411.3604"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:35.14210129;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="162.6954" /><text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:368.00549316px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e6e6e6;fill-opacity:1;stroke:none;stroke-width:259.64627075"
x="2238.1521"
y="5906.1802"
id="text7569"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7567"
x="2238.1521"
y="5906.1802"
style="fill:#e6e6e6;fill-opacity:1;stroke-width:259.64627075">Undercloud</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:368.00552368px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e6e6e6;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:259.64630127;stroke-linejoin:round"
x="2230.365"
y="6600.7021"
id="text7569-6"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7567-2"
x="2230.365"
y="6600.7021"
style="fill:#e6e6e6;fill-opacity:1;stroke-width:259.64630127">Controller-0</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:368.00552368px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e6e6e6;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:259.64630127;stroke-linejoin:round"
x="2283.1382"
y="7295.2236"
id="text7569-5"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7567-8"
x="2283.1382"
y="7295.2236"
style="fill:#e6e6e6;fill-opacity:1;stroke-width:259.64630127">Controller-1</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:368.00552368px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e6e6e6;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:259.64630127;stroke-linejoin:round"
x="2293.3462"
y="7989.7456"
id="text7569-62"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7567-84"
x="2293.3462"
y="7989.7456"
style="fill:#e6e6e6;fill-opacity:1;stroke-width:259.64630127">Controller-2</tspan></text>
<path
style="fill:none;stroke:#000000;stroke-width:23.1507225px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 6993.313,5343.3869 v 766.9932"
id="path7762"
inkscape:connector-curvature="0" /><rect
id="rect2109-6-5-9-8-0-5-3"
width="3458.9377"
height="639.16058"
x="6301.5244"
y="6033.6812"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:35.14210129;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="162.6954" /><rect
id="rect2109-6-5-9-8-0-5-0-1"
width="3458.938"
height="639.16064"
x="6301.5239"
y="6851.8071"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:35.1421051;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="162.69542" /><rect
id="rect2109-6-5-9-8-0-5-6-1"
width="3458.938"
height="639.16064"
x="6301.5244"
y="7618.8003"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:35.1421051;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="162.69542" /><rect
id="rect2109-6-5-9-8-0-5-4-0"
width="3458.938"
height="639.16064"
x="6301.5244"
y="8385.7939"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:35.1421051;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="162.69542" /><text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:368.00552368px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e6e6e6;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:259.64630127;stroke-linejoin:round"
x="7794.3252"
y="5883.0293"
id="text7569-3"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7567-4"
x="7794.3252"
y="5883.0293"
style="fill:#e6e6e6;fill-opacity:1;stroke-width:259.64630127">Compute-1</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:368.0055542px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e6e6e6;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:259.64633179;stroke-linejoin:round"
x="7786.5371"
y="6577.5518"
id="text7569-6-0"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7567-2-3"
x="7786.5371"
y="6577.5518"
style="fill:#e6e6e6;fill-opacity:1;stroke-width:259.64633179">Compute-2</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:368.0055542px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e6e6e6;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:259.64633179;stroke-linejoin:round"
x="7839.311"
y="7272.0737"
id="text7569-5-9"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7567-8-1"
x="7839.311"
y="7272.0737"
style="fill:#e6e6e6;fill-opacity:1;stroke-width:259.64633179">Compute-3</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:368.0055542px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e6e6e6;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:259.64633179;stroke-linejoin:round"
x="7849.5195"
y="7966.5952"
id="text7569-62-9"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7567-84-6"
x="7849.5195"
y="7966.5952"
style="fill:#e6e6e6;fill-opacity:1;stroke-width:259.64633179">Compute-4</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:479.77911377px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e9e9e9;fill-opacity:1;stroke:none;stroke-width:338.50814819"
x="3706.873"
y="825.29425"
id="text7700"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7698"
x="3706.873"
y="825.29425"
style="fill:#e9e9e9;fill-opacity:1;stroke-width:338.50814819">Spine 1</tspan></text>
<path
style="fill:none;stroke:#000000;stroke-width:23.1507225px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 1899.2403,5343.3869 v 766.9932"
id="path7758"
inkscape:connector-curvature="0" /><path
style="fill:none;stroke:#000000;stroke-width:23.1507225px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 3869.7864,5343.3869 v 766.9932"
id="path7760"
inkscape:connector-curvature="0" /><path
style="fill:none;stroke:#000000;stroke-width:23.1507225px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 9005.7841,5343.3869 v 766.9932"
id="path7764"
inkscape:connector-curvature="0" /><text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:347.70367432px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:231.50720215;stroke-miterlimit:4;stroke-dasharray:none"
x="21719.07"
y="849.41766"
id="text7772"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7770"
x="21719.07"
y="849.41766"
style="stroke-width:231.50720215;stroke-miterlimit:4;stroke-dasharray:none">Spine Switches</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:350.77200317px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:247.48719788;stroke-linejoin:round"
x="21927.396"
y="6772.7363"
id="text7776-0"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7774-0"
x="21927.396"
y="6772.7363"
style="stroke-width:247.48719788">Servers</tspan></text>
<rect
style="fill:#000000;fill-opacity:0.26666667;fill-rule:evenodd;stroke-width:23.40653419;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:187.25228269, 93.62614135;stroke-dashoffset:0"
id="rect7187-4-2"
width="3990.1208"
height="5406.3735"
x="10816.969"
y="4129.9087"
ry="246.35414" /><text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:304.87026978px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:215.10121155;stroke-linejoin:round"
x="13574.528"
y="8524.0117"
id="text7452-0-3"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7450-5-7"
x="13574.528"
y="8524.0117"
style="stroke-width:215.10121155">Rack C</tspan></text>
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:23.15072632px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 11814.863,5317.8196 v 766.9932"
id="path7762-9"
inkscape:connector-curvature="0" /><rect
id="rect2109-6-5-9-8-0-5-3-2"
width="3458.938"
height="639.16064"
x="11123.074"
y="6008.1138"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:35.1421051;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="162.69542" /><rect
id="rect2109-6-5-9-8-0-5-0-1-2"
width="3458.9385"
height="639.16071"
x="11123.072"
y="6826.2402"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:35.14210892;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="162.69543" /><rect
id="rect2109-6-5-9-8-0-5-6-1-8"
width="3458.9385"
height="639.16071"
x="11123.074"
y="7593.2339"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:35.14210892;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="162.69543" /><rect
id="rect2109-6-5-9-8-0-5-4-0-9"
width="3458.9385"
height="639.16071"
x="11123.074"
y="8360.2266"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:35.14210892;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="162.69543" /><text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:368.00558472px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e6e6e6;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:259.64633179;stroke-linejoin:round"
x="13118.99"
y="5859.8784"
id="text7569-3-7"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7567-4-3"
x="13118.99"
y="5859.8784"
style="fill:#e6e6e6;fill-opacity:1;stroke-width:259.64633179">Compute-5</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:368.00558472px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e6e6e6;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:259.6463623;stroke-linejoin:round"
x="13111.204"
y="6554.4009"
id="text7569-6-0-6"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7567-2-3-1"
x="13111.204"
y="6554.4009"
style="fill:#e6e6e6;fill-opacity:1;stroke-width:259.6463623">Compute-6</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:368.00558472px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e6e6e6;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:259.6463623;stroke-linejoin:round"
x="13163.978"
y="7248.9224"
id="text7569-5-9-2"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7567-8-1-9"
x="13163.978"
y="7248.9224"
style="fill:#e6e6e6;fill-opacity:1;stroke-width:259.6463623">Compute-7</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:368.00558472px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e6e6e6;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:259.6463623;stroke-linejoin:round"
x="13174.185"
y="7943.4443"
id="text7569-62-9-3"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7567-84-6-1"
x="13174.185"
y="7943.4443"
style="fill:#e6e6e6;fill-opacity:1;stroke-width:259.6463623">Compute-8</tspan></text>
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:23.15072632px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 13827.334,5317.8196 v 766.9932"
id="path7764-4"
inkscape:connector-curvature="0" /><rect
style="fill:#000000;fill-opacity:0.26666667;fill-rule:evenodd;stroke-width:23.4065361;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:187.2523033, 93.62615153;stroke-dashoffset:0"
id="rect7187-4-2-0"
width="3990.1216"
height="5406.374"
x="15470.81"
y="4155.4756"
ry="246.35416" /><text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:304.87030029px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:215.10124207;stroke-linejoin:round"
x="18713.99"
y="8547.1641"
id="text7452-0-3-6"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7450-5-7-1"
x="18713.99"
y="8547.1641"
style="stroke-width:215.10124207">Rack D</tspan></text>
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:23.15072823px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 16468.705,5343.3865 v 766.9938"
id="path7762-9-6"
inkscape:connector-curvature="0" /><rect
id="rect2109-6-5-9-8-0-5-3-2-3"
width="3458.9385"
height="639.16071"
x="15776.916"
y="6033.6812"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:35.14210892;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="162.69543" /><rect
id="rect2109-6-5-9-8-0-5-0-1-2-2"
width="3458.939"
height="639.16077"
x="15776.915"
y="6851.8071"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:35.14211273;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="162.69545" /><rect
id="rect2109-6-5-9-8-0-5-6-1-8-0"
width="3458.939"
height="639.16077"
x="15776.916"
y="7618.8003"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:35.14211273;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="162.69545" /><rect
id="rect2109-6-5-9-8-0-5-4-0-9-6"
width="3458.939"
height="639.16077"
x="15776.916"
y="8385.7939"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:35.14211273;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="162.69545" /><text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:368.00561523px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e6e6e6;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:259.6463623;stroke-linejoin:round"
x="18258.451"
y="5883.0293"
id="text7569-3-7-1"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7567-4-3-5"
x="18258.451"
y="5883.0293"
style="fill:#e6e6e6;fill-opacity:1;stroke-width:259.6463623">Compute-9</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:368.00561523px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e6e6e6;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:259.64639282;stroke-linejoin:round"
x="18250.664"
y="6577.5522"
id="text7569-6-0-6-5"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7567-2-3-1-4"
x="18250.664"
y="6577.5522"
style="fill:#e6e6e6;fill-opacity:1;stroke-width:259.64639282">Compute-10</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:368.00561523px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e6e6e6;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:259.64639282;stroke-linejoin:round"
x="18303.438"
y="7272.0742"
id="text7569-5-9-2-7"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7567-8-1-9-6"
x="18303.438"
y="7272.0742"
style="fill:#e6e6e6;fill-opacity:1;stroke-width:259.64639282">Compute-11</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:368.00561523px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e6e6e6;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:259.64639282;stroke-linejoin:round"
x="18313.645"
y="7966.5952"
id="text7569-62-9-3-5"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7567-84-6-1-6"
x="18313.645"
y="7966.5952"
style="fill:#e6e6e6;fill-opacity:1;stroke-width:259.64639282">Compute-12</tspan></text>
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:23.15072823px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 18481.177,5343.3865 v 766.9938"
id="path7764-4-5"
inkscape:connector-curvature="0" /><rect
id="rect2109-6-5-9-0-5"
width="5118.356"
height="946.78058"
x="7806.5093"
y="281.23059"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:66.52793121;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="240.99869" /><text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:479.77914429px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e9e9e9;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:338.50820923;stroke-linejoin:round"
x="10483.087"
y="802.88812"
id="text7700-4"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7698-7"
x="10483.087"
y="802.88812"
style="fill:#e9e9e9;fill-opacity:1;stroke-width:338.50820923">Spine 2</tspan></text>
<path
style="fill:none;stroke:#000000;stroke-width:23.1507225px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 11856.789,4832.0579 4232.2745,1252.7555"
id="path1177"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" /><path
style="fill:none;stroke:#000000;stroke-width:23.1507225px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 13533.849,4832.0579 4232.2745,1252.7555"
id="path1179"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" /><path
style="fill:none;stroke:#000000;stroke-width:23.1507225px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 16259.072,4832.0579 5254.9322,1252.7555 v 0"
id="path1181"
inkscape:connector-curvature="0"
sodipodi:nodetypes="ccc" /><path
style="fill:none;stroke:#000000;stroke-width:23.1507225px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 17936.133,4832.0579 5254.9322,1252.7555"
id="path1183"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" /><path
style="fill:none;stroke:#000000;stroke-width:23.1507225px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 18565.031,4832.0579 18293.819,1252.7555"
id="path1185"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" /><path
style="fill:none;stroke:#000000;stroke-width:23.1507225px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 16248.503,4832.0574 18293.819,1252.7555"
id="path1187"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" /><path
style="fill:none;stroke:#000000;stroke-width:23.1507225px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 11902.207,4832.0574 17526.825,1252.7555"
id="path1189"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" /><path
style="fill:none;stroke:#000000;stroke-width:23.1507225px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 13947.523,4832.0574 17526.825,1252.7555"
id="path1191"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" /><rect
style="fill:#000000;fill-opacity:0.26666667;fill-rule:evenodd;stroke:none;stroke-width:57.1015358;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
id="rect7472-1"
width="21068.076"
height="1093.6759"
x="1060.71"
y="4521.9468"
ry="162.13054" /><text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:350.77197266px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:247.48716736"
x="21855.145"
y="4661.4409"
id="text7776"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7774"
x="21855.145"
y="4661.4409"
style="stroke-width:247.48716736">Leaf Switches</tspan></text>
<rect
id="rect2109-6-5-9-8"
width="1585.0544"
height="639.1604"
x="6283.0039"
y="4704.2261"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:23.78912354;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="162.69536" /><rect
id="rect2109-6-5-9-8-1"
width="1585.0546"
height="639.16046"
x="3144.2256"
y="4704.2266"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:23.78912354;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="162.69537" /><rect
id="rect2109-6-5-9-8-0"
width="1585.0546"
height="639.16046"
x="1257.5322"
y="4704.2261"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:23.78912354;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="162.69537" /><rect
id="rect2109-6-5-9-8-8"
width="1585.0546"
height="639.16046"
x="8175.4072"
y="4704.2266"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:23.78912354;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="162.69537" /><text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:333.13885498px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e9e9e9;fill-opacity:1;stroke:none;stroke-width:235.04612732"
x="1715.7467"
y="4661.6909"
id="text7722"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7720"
x="1715.7467"
y="4661.6909"
style="fill:#e9e9e9;fill-opacity:1;stroke-width:235.04612732">Leaf 1</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:333.13885498px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e9e9e9;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:235.04614258;stroke-linejoin:round"
x="3763.0071"
y="4643.5928"
id="text7722-3"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7720-8"
x="3763.0071"
y="4643.5928"
style="fill:#e9e9e9;fill-opacity:1;stroke-width:235.04614258">Leaf 1</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:333.13885498px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e9e9e9;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:235.04614258;stroke-linejoin:round"
x="7318.2295"
y="4638.5405"
id="text7722-0"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7720-5"
x="7318.2295"
y="4638.5405"
style="fill:#e9e9e9;fill-opacity:1;stroke-width:235.04614258">Leaf 2</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:333.13885498px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e9e9e9;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:235.04614258;stroke-linejoin:round"
x="9424.9385"
y="4661.6909"
id="text7722-6"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7720-6"
x="9424.9385"
y="4661.6909"
style="fill:#e9e9e9;fill-opacity:1;stroke-width:235.04614258">Leaf 2</tspan></text>
<path
style="fill:none;stroke:#000000;stroke-width:23.1507225px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 3157.0358,5087.7224 H 2842.5869"
id="path7766"
inkscape:connector-curvature="0" /><path
style="fill:none;stroke:#000000;stroke-width:23.1507225px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 8188.2177,5087.7224 H 7768.9525"
id="path7768"
inkscape:connector-curvature="0" /><rect
id="rect2109-6-5-9-8-02"
width="1585.0546"
height="639.16046"
x="11104.554"
y="4678.6587"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:23.78912544;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="162.69537" /><rect
id="rect2109-6-5-9-8-8-5"
width="1585.0548"
height="639.16052"
x="12996.957"
y="4678.6592"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:23.78912735;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="162.69539" /><text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:333.1388855px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e9e9e9;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:235.0461731;stroke-linejoin:round"
x="12642.896"
y="4615.3896"
id="text7722-0-9"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7720-5-4"
x="12642.896"
y="4615.3896"
style="fill:#e9e9e9;fill-opacity:1;stroke-width:235.0461731">Leaf 3</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:333.1388855px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e9e9e9;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:235.0461731;stroke-linejoin:round"
x="14749.604"
y="4638.54"
id="text7722-6-7"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7720-6-8"
x="14749.604"
y="4638.54"
style="fill:#e9e9e9;fill-opacity:1;stroke-width:235.0461731">Leaf 3</tspan></text>
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:23.15072632px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 13009.768,5062.155 h -419.265"
id="path7768-5"
inkscape:connector-curvature="0" /><rect
id="rect2109-6-5-9-8-02-3"
width="1585.0548"
height="639.16052"
x="15758.396"
y="4704.2256"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:23.78912735;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="162.69539" /><rect
id="rect2109-6-5-9-8-8-5-0"
width="1585.0551"
height="639.16058"
x="17650.801"
y="4704.2266"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:23.78913116;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="162.6954" /><text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:333.13891602px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e9e9e9;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:235.04620361;stroke-linejoin:round"
x="17782.357"
y="4638.541"
id="text7722-0-9-9"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7720-5-4-3"
x="17782.357"
y="4638.541"
style="fill:#e9e9e9;fill-opacity:1;stroke-width:235.04620361">Leaf 4</tspan></text>
<text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:333.13891602px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e9e9e9;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:235.04620361;stroke-linejoin:round"
x="19889.064"
y="4661.6914"
id="text7722-6-7-7"
transform="scale(0.90551207,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7720-6-8-4"
x="19889.064"
y="4661.6914"
style="fill:#e9e9e9;fill-opacity:1;stroke-width:235.04620361">Leaf 4</tspan></text>
<path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:23.15072823px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 17663.609,5087.7218 h -419.265"
id="path7768-5-2"
inkscape:connector-curvature="0" /><rect
id="rect2109-6-5-9-0-5-4"
width="5118.3569"
height="946.7807"
x="13942.457"
y="305.9747"
style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:66.52793884;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;image-rendering:auto"
ry="240.99872" /><text
xml:space="preserve"
style="font-style:normal;font-weight:normal;font-size:479.77920532px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#e9e9e9;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:338.50827026;stroke-linejoin:round"
x="17259.299"
y="871.5957"
id="text7700-4-3"
transform="scale(0.90551208,1.1043475)"><tspan
sodipodi:role="line"
id="tspan7698-7-0"
x="17259.299"
y="871.5957"
style="fill:#e9e9e9;fill-opacity:1;stroke-width:338.50827026">Spine 3</tspan></text>
<path
style="fill:none;stroke:#000000;stroke-width:25.56644249px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 1931.2946,4832.0575 C 8578.57,1252.7555 8578.57,1252.7555 8578.57,1252.7555"
id="path1229"
inkscape:connector-curvature="0" /><path
style="fill:none;stroke:#000000;stroke-width:25.56644249px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 3720.9458,4832.0575 C 8578.57,1252.7555 8578.57,1252.7555 8578.57,1252.7555"
id="path1231"
inkscape:connector-curvature="0" /><path
style="fill:none;stroke:#000000;stroke-width:25.56644249px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 7300.2478,4832.0575 C 8834.2345,1252.7555 8834.2345,1252.7555 8834.2345,1252.7555"
id="path1233"
inkscape:connector-curvature="0" /><path
style="fill:none;stroke:#000000;stroke-width:25.56644249px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 9345.5633,4832.0575 C 8834.2347,1252.7555 8834.2347,1252.7555 8834.2347,1252.7555"
id="path1235"
inkscape:connector-curvature="0" /><path
style="fill:none;stroke:#000000;stroke-width:25.56644249px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 11646.543,4832.0574 9856.8923,1252.7555"
id="path1237"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" /><path
style="fill:none;stroke:#000000;stroke-width:25.56644249px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 13691.859,4832.0574 9856.8923,1252.7555"
id="path1239"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" /><path
style="fill:none;stroke:#000000;stroke-width:25.56644249px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 16248.503,4832.0575 c -4601.96,-3579.302 -4601.96,-3579.302 -4601.96,-3579.302"
id="path1241"
inkscape:connector-curvature="0" /><path
style="fill:none;stroke:#000000;stroke-width:25.56644249px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="M 18038.154,4832.0575 C 11646.543,1252.7555 11646.543,1252.7555 11646.543,1252.7555"
id="path1243"
inkscape:connector-curvature="0" /></svg>
Side by Side

Before

Width:  |  Height:  |  Size: 45 KiB

deploy-guide/source/_images/tripleo_ansible_arch.png
BIN
View File
Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 165 KiB

deploy-guide/source/conf.py
-131
View File
@@ -1,131 +0,0 @@
# instack-undercloud documentation build configuration file, created by
# sphinx-quickstart on Wed Feb 25 10:56:57 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.
# import os
# import sys
# 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 = [
'sphinx.ext.intersphinx',
'openstackdocstheme'
]
# 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'TripleO'
copyright = u'2015, OpenStack Foundation'
bug_tracker = u'Launchpad'
bug_tracker_url = u'https://launchpad.net/tripleo'
# 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 = '3.0.0'
# The full version, including alpha/beta/rc tags.
release = '3.0.0'
# 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 = 'native'
# A list of ignored prefixes for module index sorting.
# modindex_common_prefix = []
# -- Options for HTML output -------------------------------------------------
html_static_path = ['../../_custom']
# html_style = 'custom.css'
templates_path = ['../../_templates']
# Output file base name for HTML help builder.
htmlhelp_basename = '%sdoc' % project
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
html_theme = 'openstackdocs'
# -- 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': '',
}
rst_prolog = """
.. |project| replace:: %s
.. |bug_tracker| replace:: %s
.. |bug_tracker_url| replace:: %s
""" % (project, bug_tracker, bug_tracker_url)
# openstackdocstheme options
openstackdocs_repo_name = 'openstack/tripleo-docs'
openstackdocs_auto_name = False
openstackdocs_auto_version = False
openstackdocs_bug_project = 'tripleo'
openstackdocs_bug_tag = 'documentation'
deploy-guide/source/deployment/3rd_party.rst
-447
View File
@@ -1,447 +0,0 @@
Integrating 3rd Party Containers in TripleO
===========================================
.. _build_container_images:
One of the following methods can be used to extend or build from scratch
custom 3rd party containers.
Extend TripleO Containers
-------------------------
Any extra RPMs required by 3rd party drivers may need to be post-installed into
our stock TripleO containers. In this case the 3rd party vendor may opt to add
a layer to an existing container in order to deploy their software.
Adding layers to existing containers using TripleO tooling
..........................................................
The example below demonstrates how to extend a container image, where the goal
is to create a layer on top of the cinder-volume image that will be named
"cinder-cooldriver".
* Make sure python-tripleoclient and the dependencies are installed:
.. code-block:: shell
sudo dnf install -y python-tripleoclient
* Create a vendor directory (which later can be pushed into a git
repository):
.. code-block:: shell
mkdir ~/vendor
* Create a tcib directory under the vendor folder. All container build
yaml needs to live in a tcib folder as a root directory.
.. code-block:: shell
mkdir ~/vendor/tcib
* Create the `~/vendor/containers.yaml` which contains the list
of images that we want to build:
.. code-block:: yaml
container_images:
- image_source: tripleo
imagename: localhost/tripleomaster/openstack-cinder-cooldriver:latest
* Create `~/vendor/tcib/cinder-cooldriver` to hold our container image
configuration.
.. code-block:: shell
mkdir ~/vendor/tcib/cinder-cooldriver
* Optionally, add custom files into the build environment.
.. code-block:: shell
mkdir ~/vendor/tcib/cinder-cooldriver/files
cp custom-package.rpm ~/vendor/tcib/cinder-cooldriver/files
* Create `~/vendor/tcib/cinder-cooldriver/cinder-cooldriver.yaml` file which
contains the container image configuration:
.. code-block:: yaml
---
# that's the parent layer, here cinder-volume
tcib_from: localhost/tripleomaster/openstack-cinder-volume:latest
tcib_actions:
- user: root
- run: mkdir /tmp/cooldriver/example.py
- run: mkdir -p /rpms
- run: dnf install -y cooldriver_package
tcib_copies:
- '{{lookup(''env'',''HOME'')}}/vendor/tcib/cinder-cooldriver/files/custom-package.rpm /rpms'
tcib_gather_files: >
{{ lookup('fileglob', '~/vendor/tcib/cinder-cooldriver/files/*', wantlist=True) }}
tcib_runs:
- dnf install -y /rpms/*.rpm
tcib_user: cinder
.. note:: Here `tcib_runs` provides a shortcut to `tcib_actions:run`. See more tcib parameters documented in the `tcib`_ role.
.. _tcib: https://docs.openstack.org/tripleo-ansible/latest/roles/role-tripleo_container_image_build.html#r-o-l-e-d-e-f-a-u-l-t-s
* The result file structure should look something like:
.. code-block:: shell
$ tree vendor
vendor
├── containers.yaml
└── tcib
└── cinder-cooldriver
└── cinder-cooldriver.yaml
└── files
└── custom-package.rpm
* Build the vendor container image:
.. code-block:: shell
openstack tripleo container image build \
--config-file ~/vendor/containers.yaml \
--config-path ~/vendor
* Use `sudo buildah images` command to check if the image was built:
.. code-block:: shell
localhost/tripleomaster/openstack-cinder-cooldriver latest 257592a90133 1 minute ago 1.22 GB
.. note:: If you want to push the image into a Docker Registry, you can use
`--push` with `--registry`. Use
`openstack tripleo container image build --help` for more details.
* Push the image into the TripleO Container registry:
.. code-block:: shell
sudo openstack tripleo container image push \
--local --registry-url 192.168.24.1:8787 \
localhost/tripleomaster/openstack-cinder-cooldriver:latest
* Use `openstack tripleo container image list` to check if the image was pushed:
.. code-block:: shell
+--------------------------------------------------------------------------------------------------+
| Image Name |
+--------------------------------------------------------------------------------------------------+
| docker://undercloud.ctlplane.localdomain:8787/tripleomaster/openstack-cinder-vendor:latest |
+--------------------------------------------------------------------------------------------------+
Adding layers to existing containers using Docker
.................................................
.. note:: Note that this method has been simplified in Victoria and backported
down to train, with the new `openstack tripleo container image build`
command.
The example below demonstrates how to extend a container on the Undercloud host
machine. It assumes you are running a local docker registry on the undercloud.
We recommend that you create a Dockerfile to extend the existing container.
Here is an example extending the cinder-volume container::
FROM 127.0.0.1:8787/tripleo/centos-binary-cinder-volume
MAINTAINER Vendor X
LABEL name="tripleo/centos-binary-cinder-volume-vendorx" vendor="Vendor X" version="2.1" release="1"
# switch to root and install a custom RPM, etc.
USER root
COPY vendor_x.rpm /tmp
RUN rpm -ivh /tmp/vendor_x.rpm
# switch the container back to the default user
USER cinder
Docker build the container above using `docker build` on the command line. This
will output a container image <ID> (used below to tag it). Create a docker tag
and push it into the local registry::
docker tag <ID> 127.0.0.1:8787/tripleo/centos-binary-cinder-volume-vendorx:rev1
docker push 127.0.0.1:8787/tripleo/centos-binary-cinder-volume-vendorx:rev1
Start an overcloud deployment as normal with the extra custom Heat environment
above to obtain the new container.
.. warning:: Note that the new container will have the complete software stack
built into it as is normal for containers. When other containers
are updated and include security fixes in these lower layers, this
container will NOT be updated as a result and will require rebuilding.
Building new containers with tripleo container image build
----------------------------------------------------------
Usage
.....
Use the following command to build all of the container images used in TripleO:
.. code-block:: shell
openstack tripleo container image build
Different options are provided for advanced usage. They can be discovered
by using `--help` argument.
Here are some of them:
* `--config-file` to use a custom YAML config file specifying the images to build.
* `--config-path` to use a custom base configuration path.
This is the base path for all container-image files. If this option is set,
the default path for <config-file> will be modified.
* `--extra-config` to apply additional options from a given configuration YAML
file. This will apply to all containers built.
* `--exclude` to skip some containers during the build.
* `--registry` to specify a Container Registry where the images will be pushed.
* `--authfile` to specify an authentication file if the Container Registry
requires authentication.
* `--skip-build` if we don't want to build and push images. It will only
generate the configuration files.
* `--push` to push the container images into the Container Registry.
* `--volume` to overrides the default bind mounts needed when the container
images are built. If you use this argument, don't forget that you might need
to include the default ones.
* `--work-dir` to specify the place where the configuration files will be generated.
Tips and Tricks with tripleo_container_image_build
..................................................
Here's a non-exhaustive list of tips and tricks that might make things faster,
especially on a dev env where you need to build multiple times the containers.
Inject a caching proxy
______________________
Using a caching proxy can make things faster when it comes to package fetching.
One of the way is to either expose the dnf.conf/yum.conf using `--volume`.
Since `dnf.conf is edited during the container build`_, you want to expose a
copy of your host config::
sudo cp -r /etc/dnf /srv/container-dnf
openstack tripleo container image build --volume /srv/container-dnf:/etc/dnf:z
Another way is to expose the `http_proxy` and `https_proxy` environment
variable.
In order to do so, create a simple yaml file, for instance ~/proxy.yaml::
---
tcib_envs:
LANG: en_US.UTF-8
container: oci
http_proxy: http://PROXY_HOST:PORT
https_proxy: http://PROXY_HOST:PORT
Then, pass that file using the `--extra-config` parameter::
openstack tripleo container image build --extra-config proxy.yaml
And you're set.
.. note:: Please ensure you also pass the `default values`_, since ansible
isn't configured to `merge dicts/lists`_ by default.
.. _dnf.conf is edited during the container build: https://opendev.org/openstack/tripleo-common/src/commit/156b565bdf74c19d3513f9586fa5fcf1181db3a7/container-images/tcib/base/base.yaml#L3-L14
.. _default values: https://opendev.org/openstack/tripleo-common/src/commit/156b565bdf74c19d3513f9586fa5fcf1181db3a7/container-images/tcib/base/base.yaml#L35-L37
.. _merge dicts/lists: https://docs.ansible.com/ansible/latest/reference_appendices/config.html#default-hash-behaviour
Get a minimal environment to build containers
_____________________________________________
As a dev, you might want to get a daily build of your container images. While
you can, of course, run this on an Undercloud, you actually don't need an
undercloud: you can use `this playbook`_ from `tripleo-operator-ansible`_
project
With this, you can set a nightly cron that will ensure you're always getting
latest build on your registry.
.. _this playbook: https://opendev.org/openstack/tripleo-operator-ansible/src/branch/master/playbooks/container-build.yaml
.. _tripleo-operator-ansible: https://docs.openstack.org/tripleo-operator-ansible/latest/
Building new containers with kolla-build
........................................
.. note:: Note that this method will be deprecated during the Victoria cycle
and replaced by the new `openstack tripleo container image build`
command.
To create new containers, or modify existing ones, you can use ``kolla-build``
from the `Kolla`_ project to build and push the images yourself. The command
to build a new containers is below. Note that this assumes you are on an
undercloud host where the registry IP address is 192.168.24.1.
Configure Kolla to build images for TripleO, in `/etc/kolla/kolla-build.conf`::
[DEFAULT]
base=centos
type=binary
namespace=master
registry=192.168.24.1:8787
tag=latest
template_override=/usr/share/tripleo-common/container-images/tripleo_kolla_template_overrides.j2
rpm_setup_config=http://trunk.rdoproject.org/centos9/current-tripleo/delorean.repo,http://trunk.rdoproject.org/centos9/delorean-deps.repo
push=True
Use the following command to build all of the container images used in TripleO::
openstack overcloud container image build \
--config-file /usr/share/tripleo-common/container-images/overcloud_containers.yaml \
--kolla-config-file /etc/kolla/kolla-build.conf
Or use `kolla-build` to build the images yourself, which provides more
flexibility and allows you to rebuild selectively just the images matching
a given name, for example to build only the heat images with the TripleO
customization::
kolla-build heat
Notice that TripleO already uses the
``/usr/share/tripleo-common/container-images/tripleo_kolla_template_overrides.j2``
to add or change specific aspects of the containers using the `kolla template
override mechanism`_. This file can be copied and modified to create custom
containers. The original copy of this file can be found in the
`tripleo-common`_ repository.
The following template is an example of the template used for building the base
images that are consumed by TripleO. In this case we are adding the `puppet`
RPM to the base image::
{% extends parent_template %}
{% set base_centos_binary_packages_append = ['puppet'] %}
.. _Kolla: https://github.com/openstack/kolla
.. _kolla template override mechanism: https://docs.openstack.org/kolla/latest/admin/image-building.html#dockerfile-customisation
.. _tripleo-common: https://github.com/openstack/tripleo-common/blob/master/container-images/tripleo_kolla_template_overrides.j2
Integrating 3rd party containers with tripleo-heat-templates
------------------------------------------------------------
The `TripleO Heat Templates`_ repo is where most of the logic resides in the form
of heat templates. These templates define each service, the containers'
configuration and the initialization or post-execution operations.
.. _TripleO Heat Templates: https://opendev.org/openstack/tripleo-heat-templates
The docker templates can be found under the `docker` sub directory in the
`tripleo-heat-templates` root. The services files are under the
`docker/service` directory.
For more information on how to integrate containers into the TripleO Heat templates,
see the :ref:`Containerized TripleO architecture<containers_arch_tht>` document.
If all you need to do is change out a container for a specific service, you can
create a custom heat environment file that contains your override. To swap out
the cinder container from our previous example we would add::
parameter_defaults:
   ContainerCinderVolumeImage: centos-binary-cinder-volume-vendorx:rev1
.. note:: Image parameters were named Docker*Image prior to the Train cycle.
3rd party kernel modules
------------------------
Some applications (like Neutron or Cinder plugins) require specific kernel modules to be installed
and loaded on the system.
We recommend two different methods to deploy and load these modules.
kernel module is deployed on the host
.....................................
The kernel module is deployed on the base Operating System via RPM or DKMS.
Deploy the module by using the ``tripleo-mount-image`` tool and create a
``chroot``.
First you need to create a repository file where the module will be downloaded from, and copy the repo file into the image::
temp_dir=$(mktemp -d)
sudo tripleo-mount-image -a /path/to/overcloud-full.qcow2 -m $temp_dir
sudo cp my-repo.repo $temp_dir/etc/yum.repos.d/
You can now start a chroot and install the rpm that contains the kernel module::
sudo mount -o bind /dev $temp_dir/dev/
sudo cp /etc/resolv.conf $temp_dir/etc/resolv.conf
sudo chroot $temp_dir /bin/bash
dnf install my-rpm
exit
Then unmount the image::
sudo rm $temp_dir/etc/resolv.conf
sudo umount $temp_dir/dev
sudo tripleo-unmount-image -m $temp_dir
Now that the rpm is deployed with the kernel module, we need to configure TripleO to load it.
To configure an extra kernel module named "dpdk_module" for a specific role, we would add::
parameter_defaults:
ControllerExtraKernelModules:
dpdk_module: {}
Since our containers don't get their own kernels, we load modules on the host.
Therefore, ExtraKernelModules parameter is used to configure which modules we want to configure.
This parameter will be applied to the Puppet manifest (in the kernel.yaml service).
The container needs the modules mounted from the host, so make sure the plugin template has the
following configuration (at minimum)::
volumes:
- /lib/modules:/lib/modules:ro
However, this method might be problematic if RPMs dependencies are too complex to deploy the kernel
module on the host.
kernel module is containerized
..............................
Kernel modules can be loaded from the container.
The module can be deployed in the same container as the application that will use it, or in a separated
container.
Either way, if you need to run a privileged container, make sure to set this parameter::
privileged: true
If privilege mode isn't required, it is suggested to set it to false for security reasons.
Kernel modules will need to be loaded when the container will be started by Docker. To do so, it is
suggested to configure the composable service which deploys the module in the container this way::
kolla_config:
/var/lib/kolla/config_files/neutron_ovs_agent.json:
command: /dpdk_module_launcher.sh
docker_config_scripts:
dpdk_module_launcher.sh:
mode: "0755"
content: |
#!/bin/bash
set -xe
modprobe dpdk_module
docker_config:
step_3:
neutron_ovs_bridge:
volumes:
list_concat:
- {get_attr: [ContainersCommon, volumes]}
-
- /var/lib/docker-config-scripts/dpdk_module_launcher.sh:/dpdk_module_launcher.sh:ro
That way, the container will be configured to load the module at start, so the operator can restart containers without caring about loading the module manually.
deploy-guide/source/deployment/ansible_config_download.rst
-657
View File
@@ -1,657 +0,0 @@
.. _config_download:
TripleO config-download User's Guide: Deploying with Ansible
=============================================================
Introduction
------------
This documentation details using ``config-download``.
``config-download`` is the feature that enables deploying the Overcloud software
configuration with Ansible in TripleO.
Summary
-------
Since the Queens release, it has been possible to use Ansible to apply the
overcloud configuration and with the Rocky release it became the default.
Ansible is used to replace the communication and transport of the software
configuration deployment data between Heat and the Heat agent
(os-collect-config) on the overcloud nodes.
Instead of os-collect-config running on each overcloud node and polling for
deployment data from Heat, the Ansible control node applies the configuration
by running ``ansible-playbook`` with an Ansible inventory file and a set of
playbooks and tasks.
The Ansible control node (the node running ``ansible-playbook``) is the
undercloud by default.
``config-download`` is the feature name that enables using Ansible in this
manner, and will often be used to refer to the method detailed in this
documentation.
Heat is still used to create the stack, then the ansible playbooks are saved
to the filesystem in a git repository. These playbook are used to deploy the
openstack services and configuration to the Overcloud nodes.
The same parameter values and environment files are passed to Heat as they were
previously. During the stack creation, Heat simply takes the user inputs from the
templates and renders the required playbooks for the deployment.
The difference with ``config-download`` is that although Heat creates all the
deployment data necessary via SoftwareDeployment resources to perform the
overcloud installation and configuration, it does not apply any of the software
deployments. The data is only made available via the Heat API. Once the stack
is created, deployment data is downloaded from Heat and ansible playbooks are
generated.
Using the downloaded deployment data and ansible playbooks configuration of
the overcloud using ``ansible-playbook`` are completed.
This diagram details the overall sequence of how using config-download
completes an overcloud deployment:
.. image:: ../_images/tripleo_ansible_arch.png
:scale: 40%
Deployment with config-download
-------------------------------
Ansible and ``config-download`` are used by default when ``openstack
overcloud deploy`` (tripleoclient) is run. The command is backwards compatible
in terms of functionality, meaning that running ``openstack overcloud deploy``
will still result in a full overcloud deployment.
The deployment is done through a series of steps in tripleoclient. All of the
workflow steps are automated by tripleoclient. The workflow steps are summarized
as:
#. Create deployment plan
#. Create Heat stack
#. Create software configuration within the Heat stack
#. Create tripleo-admin ssh user
#. Download the software configuration from Heat
#. Applying the downloaded software configuration to the overcloud nodes with
``ansible-playbook``.
.. _`authorized on the overcloud nodes`:
Creating the ``tripleo-admin`` user on each overcloud node is necessary since
ansible uses ssh to connect to each node to perform configuration.
The following steps are done to create the ``tripleo-admin`` user:
#. Runs a playbook to create ``tripleo-admin`` on each node. Also, gives sudo
permissions to the user, as well as creates and stores a new ssh keypair
for ``tripleo-admin``.
The values for these cli arguments must be the same for all nodes in the
overcloud deployment. ``overcloud-ssh-key`` should be the private key that
corresponds with the public key specified by the Heat parameter ``KeyName``
when using Ironic deployed nodes.
config-download related CLI arguments
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
There are some new CLI arguments for ``openstack overcloud deploy`` that can be
used to influence the behavior of the overcloud deployment as it relates to
``config-download``::
--overcloud-ssh-user # Initial ssh user used for creating tripleo-admin.
# Defaults to heat-admin
--overcloud-ssh-key # Initial ssh private key (file path) to be used for
# creating tripleo-admin.
# Defaults to ~/.ssh/id_rsa
--override-ansible-cfg # path to an ansible config file, to inject any
# arbitrary ansible config to be used when running
# ansible-playbook
--stack-only # Only update the stack. Skips applying the
# software configuration with ansible-playbook.
--config-download-only # Only apply the software configuration with
# ansible-playbook. Skips the stack update.
See ``openstack overcloud deploy --help`` for further help text.
.. include:: deployment_output.rst
.. _deployment_status:
.. include:: deployment_status.rst
.. include:: deployment_log.rst
Ansible configuration
^^^^^^^^^^^^^^^^^^^^^
When ``ansible-playbook`` runs, it will use a configuration file with the
following default values::
[defaults]
retry_files_enabled = False
log_path = <working directory>/ansible.log
forks = 25
[ssh_connection]
ssh_args = -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o ControlMaster=auto -o ControlPersist=60s
control_path_dir = <working directory>/ansible-ssh
Any of the above configuration options can be overridden, or any additional
ansible configuration used by passing the path to an ansible configuration file
with ``--override-ansible-cfg`` on the deployment command.
For example the following command will use the configuration options from
``/home/stack/ansible.cfg``. Any options specified in the override file will
take precedence over the defaults::
openstack overcloud deploy \
...
--override-ansible-cfg /home/stack/ansible.cfg
Ansible project directory
^^^^^^^^^^^^^^^^^^^^^^^^^
The workflow will create an Ansible project directory with the plan name under
``$HOME/overcloud-deploy/<stack>/config-download``. For the default plan name of ``overcloud`` the working
directory will be::
$HOME/overcloud-deploy/overcloud/config-download/overcloud
The project directory is where the downloaded software configuration from
Heat will be saved. It also includes other ansible-related files necessary to
run ``ansible-playbook`` to configure the overcloud.
The contents of the project directory include the following files:
tripleo-ansible-inventory.yaml
Ansible inventory file containing hosts and vars for all the overcloud nodes.
ansible.log
Log file from the last run of ``ansible-playbook``.
ansible.cfg
Config file used when running ``ansible-playbook``.
ansible-playbook-command.sh
Executable script that can be used to rerun ``ansible-playbook``.
ssh_private_key
Private ssh key used to ssh to the overcloud nodes.
Reproducing ansible-playbook
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Once in the project directory created, simply run ``ansible-playbook-command.sh``
to reproduce the deployment::
./ansible-playbook-command.sh
Any additional arguments passed to this script will be passed unchanged to the
``ansible-playbook`` command::
./ansible-playbook-command.sh --check
Using this method it is possible to take advantage of various Ansible features,
such as check mode (``--check``), limiting hosts (``--limit``), or overriding
variables (``-e``).
Git repository
^^^^^^^^^^^^^^
The ansible project directory is a git repository. Each time config-download
downloads the software configuration data from Heat, the project directory will
be checked for differences. A new commit will be created if there are any
changes from the previous revision.
From within the ansible project directory, standard git commands can be used to
explore each revision. Commands such as ``git log``, ``git show``, and ``git
diff`` are useful ways to describe how each commit to the software
configuration differs from previous commits.
Applying earlier versions of configuration
__________________________________________
Using commands such as ``git revert`` or ``git checkout``, it is possible to
update the ansible project directory to an earlier version of the software
configuration.
It is possible to then apply this earlier version with ``ansible-playbook``.
However, caution should be exercised as this could lead to a broken overcloud
deployment. Only well understood earlier versions should be attempted to be
applied.
.. note::
Data migration changes will never be undone by applying an earlier version
of the software configuration with config-download. For example, database
schema migrations that had already been applied would never be undone by
only applying an earlier version of the configuration.
Software changes that were related to hardware changes in the overcloud
(such as scaling up or down) would also not be completely undone by
applying earlier versions of the software configuration.
.. note::
Reverting to earlier revisions of the project directory has no effect on
the configuration stored in the Heat stack. A corresponding change should
be made to the deployment templates, and the stack updated to make the
changes permanent.
.. _manual-config-download:
Manual config-download
----------------------
Prior to running the ansible playbooks generated by config-download, it is necessary
to ensure the baremetal nodes have already been provisioned. See the baremetal deployment
guide first:
:doc:`configure-nodes-before-deployment <./network_v2>`
The config-download steps can be skipped when running ``openstack overcloud deploy``
by passing ``--stack-only``. This will cause tripleoclient to only deploy the Heat
stack.
When running ``openstack overcloud deploy`` with the ``--stack-only`` option, this
will still download the ansible content to the default directory
``$HOME/overcloud-deploy/overcloud/config-download``. But it will stop before running
the ``ansible-playbook`` command.
This method is described in the following sections.
Run ansible-playbook
^^^^^^^^^^^^^^^^^^^^
Once the baremetal nodes have been configured, and the configuration has been
downloaded during the ``--stack-only`` run of ``openstack overcloud deploy``.
You can then run ``ansible-playbook`` manually to configure the overcloud nodes::
ansible-playbook \
-i /home/stack/config-download/overcloud/tripleo-ansible-inventory.yaml \
--private-key /path/private/ssh/key \
--become \
config-download/deploy_steps_playbook.yaml
.. note::
``--become`` is required when running ansible-playbook.
All default ansible configuration values will be used when manually running
``ansible-playbook`` in this manner. These values can be customized through
`ansible configuration
<https://docs.ansible.com/ansible/latest/installation_guide/intro_configuration.html>`_.
The following minimum configuration is recommended::
[defaults]
log_path = ansible.log
forks = 25
timeout = 30
[ssh_connection]
ssh_args = -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o ControlMaster=auto -o ControlPersist=30m
retries = 8
pipelining = True
.. note::
When running ``ansible-playbook`` manually, the overcloud status as returned
by ``openstack overcloud status`` won't be automatically updated due to the
configuration being applied outside of the API.
See :ref:`deployment_status` for setting the status manually.
Ansible project directory contents
----------------------------------
This section details the structure of the ``config-download`` generated
Ansible project directory.
Playbooks
^^^^^^^^^
deploy_steps_playbook.yaml
Initial deployment or template update (not minor update)
Further detailed in :ref:`deploy_steps_playbook.yaml`
fast_forward_upgrade_playbook.yaml
Fast forward upgrades
post_upgrade_steps_playbook.yaml
Post upgrade steps for major upgrade
pre_upgrade_rolling_steps_playbook.yaml
Pre upgrade steps for major upgrade
update_steps_playbook.yaml
Minor update steps
upgrade_steps_playbook.yaml
Major upgrade steps
.. _deploy_steps_playbook.yaml:
deploy_steps_playbook.yaml
__________________________
``deploy_steps_playbook.yaml`` is the playbook used for deployment and template
update. It applies all the software configuration necessary to deploy a full
overcloud based on the templates provided as input to the deployment command.
This section will summarize at high level the different ansible plays used
within this playbook. The play names shown here are the same names used within
the playbook and are what will be shown in the output when ``ansible-playbook`` is
run.
The ansible tags set on each play are also shown below.
Gather facts from undercloud
Fact gathering for the undercloud node
tags: facts
Gather facts from overcloud
Fact gathering for the overcloud nodes
tags: facts
Load global variables
Loads all variables from `l`global_vars.yaml``
tags: always
Common roles for TripleO servers
Applies common ansible roles to all overcloud nodes. Includes
``tripleo_bootstrap`` for installing bootstrap packages and
``tripleo_ssh_known_hosts`` for configuring ssh known hosts.
tags: common_roles
Overcloud deploy step tasks for step 0
Applies tasks from the ``deploy_steps_tasks`` template interface
tags: overcloud, deploy_steps
Server deployments
Applies server specific Heat deployments for configuration such as networking
and hieradata. Includes ``NetworkDeployment``, ``<Role>Deployment``,
``<Role>AllNodesDeployment``, etc.
tags: overcloud, pre_deploy_steps
Host prep steps
Applies tasks from the ``host_prep_steps`` template interface
tags: overcloud, host_prep_steps
External deployment step [1,2,3,4,5]
Applies tasks from the ``external_deploy_steps_tasks`` template interface.
These tasks are run against the undercloud node only.
tags: external, external_deploy_steps
Overcloud deploy step tasks for [1,2,3,4,5]
Applies tasks from the ``deploy_steps_tasks`` template interface
tags: overcloud, deploy_steps
Overcloud common deploy step tasks [1,2,3,4,5]
Applies the common tasks done at each step to include puppet host
configuration, ``container-puppet.py``, and ``paunch`` or
``tripleo_container_manage`` Ansible role (container configuration).
tags: overcloud, deploy_steps
Server Post Deployments
Applies server specific Heat deployments for configuration done after the 5
step deployment process.
tags: overcloud, post_deploy_steps
External deployment Post Deploy tasks
Applies tasks from the ``external_post_deploy_steps_tasks`` template interface.
These tasks are run against the undercloud node only.
tags: external, external_deploy_steps
Task files
^^^^^^^^^^
These task files include tasks specific to their intended function. The task
files are automatically used by specific playbooks from the previous section.
**boot_param_tasks.yaml**
**common_deploy_steps_tasks.yaml**
**docker_puppet_script.yaml**
**external_deploy_steps_tasks.yaml**
**external_post_deploy_steps_tasks.yaml**
**fast_forward_upgrade_bootstrap_role_tasks.yaml**
**fast_forward_upgrade_bootstrap_tasks.yaml**
**fast_forward_upgrade_post_role_tasks.yaml**
**fast_forward_upgrade_prep_role_tasks.yaml**
**fast_forward_upgrade_prep_tasks.yaml**
**fast_forward_upgrade_release_tasks.yaml**
**upgrade_steps_tasks.yaml**
**update_steps_tasks.yaml**
**pre_upgrade_rolling_steps_tasks.yaml**
**post_upgrade_steps_tasks.yaml**
**post_update_steps_tasks.yaml**
Heat Role directories
^^^^^^^^^^^^^^^^^^^^^
Each Heat role from the roles data file used in the deployment (specified with
``-r`` from the ``openstack overcloud deploy`` command), will have a
correspondingly named directory.
When using the default roles, these directories would be:
**Controller**
**Compute**
**ObjectStorage**
**BlockStorage**
**CephStorage**
A given role directory contains role specific task files and a subdirectory for
each host for that role. For example, when using the default hostnames, the
**Controller** role directory would contain the following host subdirectories:
**overcloud-controller-0**
**overcloud-controller-1**
**overcloud-controller-2**
Variable and template related files
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
group_vars
Directory which contains variables specific to different ansible inventory
groups.
global_vars.yaml
Global ansible variables applied to all overcloud nodes
templates
Directory containing any templates used during the deployment
Other files
^^^^^^^^^^^
Other files in the project directory are:
ansible-playbook-command.sh
Script to reproduce ansible-playbook command
tripleo-ansible-inventory.yaml
Ansible inventory file
overcloud-config.tar.gz
Tarball of Ansible project directory
Running specific tasks
----------------------
Running only specific tasks (or skipping certain tasks) can be done from within
the ansible project directory.
.. note::
Running specific tasks is an advanced use case and only recommended for
specific scenarios where the deployer is aware of the impact of skipping or
only running certain tasks.
This can be useful during troubleshooting and debugging scenarios, but
should be used with caution as it can result in an overcloud that is not
fully configured.
.. warning::
All tasks that are part of the deployment need to be run, and in the order
specified. When skipping tasks with ``--tags``, ``-skip-tags``,
``--start-at-task``, the deployment could be left in an inoperable state.
The functionality to skip tasks or only run certain tasks is meant to aid in
troubleshooting and iterating more quickly on failing deployments and
updates.
All changes to the deployed cloud must still be applied through the Heat
templates and environment files passed to the ``openstack overcloud deploy``
command. Doing so ensures that the deployed cloud is kept in sync with the
state of the templates and the state of the Heat stack.
.. warning::
When skipping tasks, the overcloud must be in the state expected by the task
starting task. Meaning, the state of the overcloud should be the same as if
all the skipped tasks had been applied. Otherwise, the result of the tasks
that get executed will be undefined and could leave the cloud in an
inoperable state.
Likewise, the deployed cloud may not be left in its fully configured state
if tasks are skipped at the end of the deployment.
Complete the :ref:`manual-config-download` steps to create the ansible project
directory, or use the existing project directory at
``$HOME/overcloud-deploy/<stack-name>/config-download/<stack-name>``.
Tags
^^^^
The playbooks use tagged tasks for finer-grained control of what to apply if
desired. Tags can be used with the ``ansible-playbook`` CLI arguments ``--tags`` or
``--skip-tags`` to control what tasks are executed. The enabled tags are:
facts
fact gathering
common_roles
ansible roles common to all nodes
overcloud
all plays for overcloud deployment
pre_deploy_steps
deployments that happen pre deploy_steps
host_prep_steps
Host preparation steps
deploy_steps
deployment steps
post_deploy_steps
deployments that happen post deploy_steps
external
all external deployments
external_deploy_steps
external deployments that run on the undercloud
See :ref:`deploy_steps_playbook.yaml` for a description of which tags apply to
specific plays in the deployment playbook.
Server specific pre and post deployments
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The list of server specific pre and post deployments run during the `Server
deployments` and `Server Post Deployments` plays (see
:ref:`deploy_steps_playbook.yaml`) are dependent upon what custom roles and
templates are used with the deployment.
The list of these tasks are defined in an ansible group variable that applies
to each server in the inventory group named after the Heat role. From the
ansible project directory, the value can be seen within the group variable file
named after the Heat role::
$ cat group_vars/Compute
Compute_pre_deployments:
- UpgradeInitDeployment
- HostsEntryDeployment
- DeployedServerBootstrapDeployment
- InstanceIdDeployment
- NetworkDeployment
- ComputeUpgradeInitDeployment
- ComputeDeployment
- ComputeHostsDeployment
- ComputeAllNodesDeployment
- ComputeAllNodesValidationDeployment
- ComputeHostPrepDeployment
- ComputeArtifactsDeploy
Compute_post_deployments: []
``<Role>_pre_deployments`` is the list of pre deployments, and
``<Role>_post_deployments`` is the list of post deployments.
To specify the specific task to run for each deployment, the value of the
variable can be defined on the command line when running ``ansible-playbook``,
which will overwrite the value from the group variable file for that role.
For example::
ansible-playbook \
-e Compute_pre_deployments=NetworkDeployment \
--tags pre_deploy_steps
# other CLI arguments
Using the above example, only the task for the ``NetworkDeployment`` resource
would get applied since it would be the only value defined in
``Compute_pre_deployments``, and ``--tags pre_deploy_steps`` is also specified,
causing all other plays to get skipped.
Starting at a specific task
^^^^^^^^^^^^^^^^^^^^^^^^^^^
To start the deployment at a specific task, use the ``ansible-playbook`` CLI
argument ``--start-at-task``. To see a list of task names for a given playbook,
``--list-tasks`` can be used to list the task names.
.. note::
Some tasks that include the ``step`` variable or other ansible variables in
the task name do not work with ``--start-at-task`` due to a limitation in
ansible. For example the task with the name::
Start containers for step 1
won't work with ``--start-at-task`` since the step number is in the name
(1).
When using ``--start-at-task``, the tasks that gather facts and load global
variables for the playbook execution are skipped by default. Skipping those
tasks can cause unexpected errors in later tasks. To avoid errors, those tasks
can be forced to execute when using ``--start-at-task`` by including the
following options to the ``ansible-playbook`` command::
ansible-playbook \
<other options > \
-e gather_facts=true \
-e @global_vars.yaml
The ``global_vars.yaml`` variable file exists in the config-download directory
that was either generated manually or under ``$HOME/config-download``.
Previewing changes
------------------
Changes can be previewed to see what will be changed before any changes are
applied to the overcloud. To preview changes, the stack update must be run with
the ``--stack-only`` cli argument::
openstack overcloud deploy \
--stack-only
# other CLI arguments
When ansible-playbook is run, use the ``--check`` CLI argument with
ansible-playbook to preview any changes. The extent to which changes can be
previewed is dependent on many factors such as the underlying tools in use
(puppet, docker, etc) and the support for ansible check mode in the given
ansible module.
The ``--diff`` option can also be used with ``--check`` to show the
differences that would result from changes.
See `Ansible Check Mode ("Dry Run")
<https://docs.ansible.com/ansible/2.5/user_guide/playbooks_checkmode.html>`_
for more details.
deploy-guide/source/deployment/ansible_config_download_differences.rst
-133
View File
@@ -1,133 +0,0 @@
.. _config_download_differences:
Ansible config-download differences
===================================
With the Queens release, it became possible to use Ansible to apply the
overcloud configuration and this method became the default behavior with
the Rockt release.
The feature is fully documented at
:doc:`ansible_config_download`, while this page details
the differences to the deployer experience with config-download.
Ansible vs. os-collect-config
-----------------------------
Previously, TripleO used an agent running on each overcloud node called
``os-collect-config``. This agent periodically polled the undercloud Heat API for
software configuration changes that needed to be applied to the node.
``os-collect-config`` ran ``os-refresh-config`` and ``os-apply-config`` as
needed whenever new software configuration changes were detected. This model
is a **"pull"** style model given each node polled the Heat API and pulled changes,
then applied them locally.
With config-download, TripleO has switched to a **"push"** style model. Ansible
is run from a central control node which is the undercloud.
``ansible-playbook`` is run from the undercloud and software configuration
changes are pushed out to each overcloud node via ssh.
With the new model, ``os-collect-config``, ``os-refresh-config``, and
``os-apply-config`` are no longer used in a TripleO deployment. The
``os-collect-config`` service is now disabled by default and won't start on
boot.
.. note::
Heat standalone software deployments still rely on ``os-collect-config``.
They are a type of deployment that can be applied to overcloud nodes
directly via Heat outside of the overcloud stack, and without having to do
a full stack update of the overcloud stack.
These types of deployments are **NOT** typically used when doing TripleO.
However, if these deployments are being used in an environment to manage
overcloud nodes, then the ``os-collect-config`` service must be started and
enabled on the overcloud nodes where these types of deployments are
applied.
For reference, the Heat CLI commands that are used to create these types of
deployments are::
openstack software config create ...
openstack software deployment create ...
If these commands are not being used in the environment, then
``os-collect-config`` can be left disabled.
Deployment workflow
-------------------
The default workflow executed by ``openstack overcloud deploy`` takes care of
all the necessary changes when using config-download. In both the previous and
new workflows, ``openstack overcloud deploy`` (tripleoclient) takes care of
automating all the steps through Mistral workflow(s). Therefore, existing CLI
scripts that called ``openstack overcloud deploy`` will continue to work with
no changes.
It's important to recognize the differences in the workflow to aid in
understanding the deployment and operator experience. Previously, Heat was
responsible for:
#. (Heat) Creating OpenStack resources (Neutron networks, Nova/Ironic instances, etc)
#. (Heat) Creating software configuration
#. (Heat) Applying the created software configuration to the Nova/Ironic instances
With config-download, Heat is no longer responsible for the last item of
applying the created software configuration as ``ansible-playbook`` is used
instead.
Therefore, only creating the Heat stack for an overcloud is no longer all that
is required to fully deploy the overcloud. Ansible also must be run from the
undercloud to apply the software configuration, and do all the required tasks
to fully deploy an overcloud such as configuring services, bootstrap tasks, and
starting containers.
The new steps are summarized as:
#. (Heat) Creating OpenStack resources (Neutron networks, Nova/Ironic instances, etc)
#. (Heat) Creating software configuration
#. (tripleoclient) Enable tripleo-admin ssh user
#. (ansible) Applying the created software configuration to the Nova/Ironic instances
See :doc:`ansible_config_download` for details on the
tripleo-admin ssh user step.
Deployment CLI output
---------------------
During a deployment, the expected output from ``openstack overcloud deploy``
has changed. Output up to and including the stack create/update is similar to
previous releases. Stack events will be shown until the stack operation is
complete.
After the stack goes to ``CREATE_COMPLETE`` (or ``UPDATE_COMPLETE``), output
from the steps to enable the tripleo-admin user via ssh are shown.
.. include:: deployment_output.rst
.. include:: deployment_status.rst
.. include:: deployment_log.rst
config-download Use Cases
-------------------------
config-download exposes the ability to manually run the ``ansible-playbook``
command against the playbooks that are generated for the deployment. This leads
to many advantages over the older Heat deployment model.
- Test deployments. Using the
``ansible-playbook --check --diff deploy_steps_playbook.yaml``
arguments will not modify an existing deployment. Instead, it will only show
any changes that would be made.
- Development environment testing. Ansible variables can be modified to do
quick testing. Once verified, Heat environment templates need to be updated
to reflect the change permanently. Then the config-download content should
be re-generated by running ``openstack overcloud deploy --stack-only``.
- Run specific tasks. It is possible to run certain parts of a deployment by
using ``--tags``.
- Prepare the deployment or update ahead of time and then run the playbooks
later. The operations around a deployment can be done at different times to
minimize risk.
- Integration with CI/CD. Additional checks and verification can be added to
a CI/CD pipeline relating to updating Heat templates and the Ansible
config-download content.
- AWX or Ansible Tower integration. Ansible content can be imported and ran
through a scalable and distributed system.
deploy-guide/source/deployment/architecture.rst
-335
View File
@@ -1,335 +0,0 @@
TripleO Containers Architecture
===============================
This document explains the details around TripleO's containers architecture. The
document goes into the details of how the containers are built for TripleO,
how the configuration files are generated and how the containers are eventually
run.
Like other areas of TripleO, the containers based deployment requires a couple
of different projects to play together. The next section will cover each of the
parts that allow for deploying OpenStack in containers using TripleO.
Containers runtime deployment and configuration notes
-----------------------------------------------------
TripleO has transitioned to the `podman`_ container runtime. Podman does not
use a persistent daemon to manage containers. TripleO wraps the container
service execution in systemd managed services. These services are named
tripleo_<container name>. Prior to Stein, TripleO deployed the containers
runtime and image components from the docker packages. The installed components
include the docker daemon system service and `OCI`_ compliant `Moby`_ and
`Containerd`_ - the building blocks for the container system.
Containers control plane includes `Paunch`_ or tripleo_container_manage_ and
systemd for the stateless services, and Pacemaker `Bundle`_ for the
containerized stateful services, like the messaging system or database.
.. _podman: https://podman.io/
.. _OCI: https://www.opencontainers.org/
.. _Moby: https://mobyproject.org/
.. _Containerd: https://github.com/containerd/containerd
.. _Bundle: https://wiki.clusterlabs.org/wiki/Bundle_Walk-Through
Currently we provide a ``ContainerCli`` parameter which can be used to change
the container runtimes, but only podman is supported for both undercloud and
overcloud.
We have provided various ``Container*`` configuration parameters in TripleO
Heat Templates for operators to tune some of the container based settings.
There are still some ``Docker*`` configuration parameters in TripleO Heat
Templates available for operators which are left over for the Docker based
deployment or historical reasons.
Parameter override example::
parameter_defaults:
DockerDebug: true
DockerOptions: '--log-driver=syslog --live-restore'
DockerNetworkOptions: '--bip=10.10.0.1/16'
DockerInsecureRegistryAddress: ['myregistry.local:8787']
DockerRegistryMirror: 'mirror.regionone.local:8081/myregistry-1.local/'
* ``DockerDebug`` adds more framework-specific details to the deployment logs.
* ``DockerOptions``, ``DockerNetworkOptions``, ``DockerAdditionalSockets`` define
the docker service startup options, like the default IP address for the
`docker0` bridge interface (``--bip``) or SELinux mode (``--selinux-enabled``).
.. note:: Make sure the default CIDR assigned for the `docker0` bridge interface
does not conflict to other network ranges defined for your deployment.
.. note:: These options have no effect when using podman.
* ``DockerInsecureRegistryAddress``, ``DockerRegistryMirror`` allow you to
specify a custom registry mirror which can optionally be accessed insecurely
by using the ``DockerInsecureRegistryAddress`` parameter.
See the official dockerd `documentation`_ for the reference.
.. _documentation: https://docs.docker.com/engine/reference/commandline/dockerd/
Building Containers
-------------------
The containers used for TripleO are sourced from Kolla. Kolla is an OpenStack
team that aims to create tools to allow for deploying OpenStack on container
technologies. Kolla (or Kolla Build) is one of the tools produced by this team
and it allows for building and customizing container images for OpenStack
services and their dependencies.
TripleO consumes these images and takes advantage of the customization
capabilities provided by the `Kolla`_ build tool to install some packages that
are required by other parts of TripleO.
TripleO maintains its complete list of kolla customization in the
`tripleo-common`_ project.
.. _Kolla: https://docs.openstack.org/kolla/latest/admin/image-building.html#dockerfile-customisation
.. _tripleo-common: https://github.com/openstack/tripleo-common/blob/master/container-images/tripleo_kolla_template_overrides.j2
Paunch
------
.. note:: During Ussuri cycle, Paunch has been replaced by the
tripleo_container_manage_ Ansible role. Therefore, the following block
is deprecated in favor of the new role. However, the JSON input remains
backward compatible and the containers are configured the same way as it
was with Paunch.
The `paunch`_ hook is used to manage containers. This hook takes json
as input and uses it to create and run containers on demand. The json
describes how the container will be started. Some example keys are:
* **net**: To specify what network to use. This is commonly set to host.
* **privileged**: Whether to give full access to the host's devices to the
container, similar to what happens when the service runs directly on the host.
* **volumes**: List of host path volumes, named volumes, or dynamic volumes to
bind on the container.
* **environment**: List of environment variables to set on the container.
.. note:: The list above is not exhaustive and you should refer to the
`paunch` docs for the complete list.
The json file passed to this hook is built out of the `docker_config` attribute
defined in the service's yaml file. Refer to the `Docker specific settings`_
section for more info on this.
.. _paunch: https://github.com/openstack/paunch
.. _tripleo_container_manage: https://docs.openstack.org/tripleo-ansible/latest/roles/role-tripleo_container_manage.html
TripleO Heat Templates
----------------------
.. _containers_arch_tht:
The `TripleO Heat Templates`_ repo is where most of the logic resides in the form
of heat templates. These templates define each service, the containers'
configuration and the initialization or post-execution operations.
.. _TripleO Heat Templates: https://opendev.org/openstack/tripleo-heat-templates
Understanding container related files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The docker templates can be found under the `docker` sub directory in the
`tripleo-heat-templates` root. The services files are under `docker/service` but
the `docker` directory contains a bit more than just service files and some of
them are worth diving into:
deploy-steps.j2
...............
This file is a jinja template and it's rendered before the deployment is
started. This file defines the resources that are executed before and after the
container initialization.
.. _container-puppet.py:
container-puppet.py
...................
This script is responsible for generating the config files for each service. The
script is called from the `deploy-steps.j2` file and it takes a `json` file as
configuration. The json files passed to this script are built out of the
`puppet_config` parameter set in every service template (explained in the
`Docker specific settings`_ section).
The `container-puppet.py` execution results in a oneshot container being executed
(usually named `puppet-$service_name`) to generate the configuration options or
run other service specific initialization tasks. Example: Create Keystone endpoints.
.. note:: container-puppet.py was previously docker-puppet.py prior to the Train
cycle.
Anatomy of a containerized service template
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Containerized services templates inherit almost everything from the puppet based
templates, with some exceptions for some services. New properties have been
added to define container specific configurations, which will be covered in this
section.
Docker specific settings
........................
Each service may define output variable(s) which control config file generation,
initialization, and stepwise deployment of all the containers for this service.
The following sections are available:
* config_settings: This setting containers hiera data that is used
to control how the Puppet modules generate config files for each service.
* step_config: This setting controls the manifest that is used to
create docker config files via puppet. The puppet tags below are
used along with this manifest to generate a config directory for
this container.
* kolla_config: Contains YAML that represents how to map config files
into the kolla container. This config file is typically mapped into
the container itself at the /var/lib/kolla/config_files/config.json
location and drives how kolla's external config mechanisms work.
* docker_config: Data that is passed to the docker-cmd hook to configure
a container, or step of containers at each step. See the available steps
below and the related docker-cmd hook documentation in the heat-agents
project.
* puppet_config: This section is a nested set of key value pairs
that drive the creation of config files using puppet.
Required parameters include:
* puppet_tags: Puppet resource tag names that are used to generate config
files with puppet. Only the named config resources are used to generate
a config file. Any service that specifies tags will have the default
tags of 'file,concat,file_line,augeas,cron' appended to the setting.
Example: keystone_config
* config_volume: The name of the volume (directory) where config files
will be generated for this service. Use this as the location to
bind mount into the running Kolla container for configuration.
* config_image: The name of the docker image that will be used for
generating configuration files. This is often the same container
that the runtime service uses. Some services share a common set of
config files which are generated in a common base container.
* step_config: This setting controls the manifest that is used to
create docker config files via puppet. The puppet tags below are
used along with this manifest to generate a config directory for
this container.
* container_puppet_tasks: This section provides data to drive the
container-puppet.py tool directly. The task is executed only once
within the cluster (not on each node) and is useful for several
puppet snippets we require for initialization of things like
keystone endpoints, database users, etc. See container-puppet.py
for formatting. NOTE: these tasks were docker_puppet_tasks prior to the
Train cycle.
Container steps
...............
Similar to baremetal, containers are brought up in a stepwise manner. The
current architecture supports bringing up baremetal services alongside of
containers. Therefore, baremetal steps may be required depending on the service
and they are always executed before the corresponding container step.
The list below represents the correlation between the baremetal and the
containers steps. These steps are executed sequentially:
* Containers config files generated per hiera settings.
* Host Prep
* Load Balancer configuration baremetal
* Step 1 external steps (execute Ansible on Undercloud)
* Step 1 deployment steps (Ansible)
* Common Deployment steps
* Step 1 baremetal (Puppet)
* Step 1 containers
* Core Services (Database/Rabbit/NTP/etc.)
* Step 2 external steps (execute Ansible on Undercloud)
* Step 2 deployment steps (Ansible)
* Common Deployment steps
* Step 2 baremetal (Puppet)
* Step 2 containers
* Early Openstack Service setup (Ringbuilder, etc.)
* Step 3 external steps (execute Ansible on Undercloud)
* Step 3 deployment steps (Ansible)
* Common Deployment steps
* Step 3 baremetal (Puppet)
* Step 3 containers
* General OpenStack Services
* Step 4 external steps (execute Ansible on Undercloud)
* Step 4 deployment steps (Ansible)
* Common Deployment steps
* Step 4 baremetal (Puppet)
* Step 4 containers (Keystone initialization occurs here)
* Service activation (Pacemaker)
* Step 5 external steps (execute Ansible on Undercloud)
* Step 5 deployment steps (Ansible)
* Common Deployment steps
* Step 5 baremetal (Puppet)
* Step 5 containers
Service Bootstrap
~~~~~~~~~~~~~~~~~
Bootstrapping services is a one-shot operation for most services and it's done
by defining a separate container that shares the same structure as the main
service container commonly defined under the `docker_step` number 3 (see `Container
steps`_ section above).
Unlike normal service containers, the bootstrap container should be run in the
foreground - `detach: false` - so there can be more control on when the
execution is done and whether it succeeded or not.
Example taken from Glance's service file::
docker_config:
step_3:
glance_api_db_sync:
image: *glance_image
net: host
privileged: false
detach: false
volumes: &glance_volumes
- /var/lib/kolla/config_files/glance-api.json:/var/lib/kolla/config_files/config.json
- /etc/localtime:/etc/localtime:ro
- /lib/modules:/lib/modules:ro
- /var/lib/config-data/glance_api/:/var/lib/kolla/config_files/src:ro
- /run:/run
- /dev:/dev
- /etc/hosts:/etc/hosts:ro
environment:
- KOLLA_BOOTSTRAP=True
- KOLLA_CONFIG_STRATEGY=COPY_ALWAYS
step_4:
glance_api:
image: *glance_image
net: host
privileged: false
restart: always
volumes: *glance_volumes
environment:
- KOLLA_CONFIG_STRATEGY=COPY_ALWAYS
deploy-guide/source/deployment/build_single_image.rst
-30
View File
@@ -1,30 +0,0 @@
Building a Single Image
=======================
The ``openstack overcloud image build --all`` command builds all the images
needed for an overcloud deploy. However, you may need to rebuild a single
one of them. Use the following commands if you want to do it::
openstack overcloud image build --type {agent-ramdisk|deploy-ramdisk|fedora-user|overcloud-full}
If the target image exist, this commands ends silently. Make sure to delete a
previous version of the image to run the command as you expect.
Uploading the New Single Image
------------------------------
After the new image is built, it can be uploaded using the same command as
before, with the ``--update-existing`` flag added::
openstack overcloud image upload --update-existing
Note that if the new image is a ramdisk, the Ironic nodes need to be
re-configured to use it. This can be done by re-running::
openstack overcloud node configure --all-manageable
.. note::
If you want to use custom images for boot configuration, specify their names in
``--deploy-kernel`` and ``--deploy-ramdisk`` options.
Now the new image should be fully ready for use by new deployments.
deploy-guide/source/deployment/container_image_prepare.rst
-552
View File
@@ -1,552 +0,0 @@
.. _prepare-environment-containers:
Container Image Preparation
===========================
This documentation explains how to instruct container image preparation to do
different preparation tasks.
Choosing an image registry strategy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Container images need to be pulled from an image registry which is reliably
available to overcloud nodes. The three common options to serve images are to
use the default registry, the registry available on the undercloud, or an
independently managed registry.
.. note:: Private SSL-enabled registries with a custom CA are not tested.
If you have to use one, the custom CA (certificate authority) that is needed
for the registry should be installed before deploying the overcloud. For
example, it can be injected into the overcloud image, or installed via first
boot scripts.
During deployment the environment parameter
`ContainerImagePrepare` is used to specify any desired behaviour, including:
- Where to pull images from
- Optionally, which local repository to push images to
- How to discover the latest versioned tag for each image
In the following examples, the parameter `ContainerImagePrepare` will be
specified in its own file `containers-prepare-parameters.yaml`.
Default registry
................
By default the images will be pulled from a remote registry namespace such as
`docker.io/tripleomaster`. This is fine for development or POC clouds but is
not appropriate for production clouds due to the transfer of large amounts of
duplicate image data over a potentially unreliable internet connection.
During deployment with this default, any heat parameters which refer to
required container images will be populated with a value pointing at the
default registry, with a tag representing the latest image version.
To generate the `containers-prepare-parameters.yaml` containing these defaults,
run this command::
openstack tripleo container image prepare default \
--output-env-file containers-prepare-parameters.yaml
This will generate a file containing a `ContainerImagePrepare` similar to the
following::
parameter_defaults:
ContainerImagePrepare:
- set:
ceph_image: daemon
ceph_namespace: docker.io/ceph
ceph_tag: v4.0.0-stable-4.0-nautilus-centos-7-x86_64
name_prefix: centos-binary-
name_suffix: ''
namespace: docker.io/tripleomaster
neutron_driver: null
tag: current-tripleo
tag_from_label: rdo_version
During deployment, this will lookup images in `docker.io/tripleomaster` tagged
with `current-tripleo` and discover a versioned tag by looking up the label
`rdo_version`. This will result in the heat image parameters in the plan being
set with appropriate values, such as::
DockerNeutronMetadataImage: docker.io/tripleomaster/centos-binary-neutron-metadata-agent:35414701c176a6288fc2ad141dad0f73624dcb94_43527485
DockerNovaApiImage: docker.io/tripleomaster/centos-binary-nova-api:35414701c176a6288fc2ad141dad0f73624dcb94_43527485
.. note:: The tag is actually a Delorean hash. You can find out the versions
of packages by using this tag.
For example, `35414701c176a6288fc2ad141dad0f73624dcb94_43527485` tag,
is in fact using this `Delorean repository`_.
.. _populate-local-registry-containers:
Undercloud registry
...................
As part of the undercloud install, an image registry is configured on port
`8787`. This can be used to increase reliability of image pulls, and minimise
overall network transfers.
The undercloud registry can be used by generating the following
`containers-prepare-parameters.yaml` file::
openstack tripleo container image prepare default \
--local-push-destination \
--output-env-file containers-prepare-parameters.yaml
This will generate a file containing a `ContainerImagePrepare` similar to the
following::
parameter_defaults:
ContainerImagePrepare:
- push_destination: true
set:
ceph_image: daemon
ceph_namespace: docker.io/ceph
ceph_tag: v4.0.0-stable-4.0-nautilus-centos-7-x86_64
name_prefix: centos-binary-
name_suffix: ''
namespace: docker.io/tripleomaster
neutron_driver: null
tag: current-tripleo
tag_from_label: rdo_version
This is identical to the default registry, except for the `push_destination:
true` entry which indicates that the address of the local undercloud registry
will be discovered at upload time.
By specifying a `push_destination` value such as `192.168.24.1:8787`, during
deployment all images will be pulled from the remote registry then pushed to
the specified registry. The resulting image parameters will also be modified to
refer to the images in `push_destination` instead of `namespace`.
.. admonition:: Stein and newer
:class: stein
Prior to Stein, Docker Registry v2 (provided by "Docker
Distribution" package), was the service running on tcp 8787.
Since Stein it has been replaced with an Apache vhost called
"image-serve", which serves the containers on tcp 8787 and
supports podman or buildah pull commands. Though podman or buildah
tag, push, and commit commands are not supported, they are not
necessary because the same functionality may be achieved through
use of the "sudo openstack tripleo container image prepare"
commands described in this document.
Running container image prepare
...............................
The prepare operations are run at the following times:
#. During ``undercloud install`` when `undercloud.conf` has
`container_images_file=$HOME/containers-prepare-parameters.yaml` (see
:ref:`install_undercloud`)
#. During ``overcloud deploy`` when a `ContainerImagePrepare` parameter is
provided by including the argument `-e
$HOME/containers-prepare-parameters.yaml`
(see :ref:`overcloud-prepare-container-images`)
#. Any other time when ``sudo openstack tripleo container image prepare`` is run
As seen in the last of the above commands, ``sudo openstack tripleo
container image prepare`` may be run without ``default`` to set up an
undercloud registry without deploying the overcloud. It is run with
``sudo`` because it needs to write to `/var/lib/image-serve` on the
undercloud.
Options available in heat parameter ContainerImagePrepare
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To do something different to the above two registry scenarios, your custom
environment can set the value of the ContainerImagePrepare heat parameter to
result in any desired registry and image scenario.
Discovering versioned tags with tag_from_label
..............................................
If you want these parameters to have the actual tag `current-tripleo` instead of
the discovered tag (in this case the Delorean hash,
`35414701c176a6288fc2ad141dad0f73624dcb94_43527485` ) then the `tag_from_label`
entry can be omitted.
Likewise, if all images should be deployed with a different tag, the value of
`tag` can be set to the desired tag.
Some build pipelines have a versioned tag which can only be discovered via a
combination of labels. For this case, a template format can be specified
instead::
tag_from_label: {version}-{release}
It's possible to use the above feature while also disabling it only
for a subset of images by using an `includes` and `excludes` list as
described later in this document. This is useful when using the above
but also using containers from external projects which doesn't follow
the same convention like Ceph.
Copying images with push_destination
....................................
By specifying a `push_destination`, the required images will be copied from
`namespace` to this registry, for example::
ContainerImagePrepare:
- push_destination: 192.168.24.1:8787
set:
namespace: docker.io/tripleomaster
...
This will result in images being copied from `docker.io/tripleomaster` to
`192.168.24.1:8787/tripleomaster` and heat parameters set with values such as::
DockerNeutronMetadataImage: 192.168.24.1:8787/tripleomaster/centos-binary-neutron-metadata-agent:35414701c176a6288fc2ad141dad0f73624dcb94_43527485
DockerNovaApiImage: 192.168.24.1:8787/tripleomaster/centos-binary-nova-api:35414701c176a6288fc2ad141dad0f73624dcb94_43527485
.. note:: Use the IP address of your undercloud, which you previously set with
the `local_ip` parameter in your `undercloud.conf` file. For these example
commands, the address is assumed to be `192.168.24.1:8787`.
By setting different values for `namespace` and `push_destination` any
alternative registry strategy can be specified.
Ceph and other set options
..........................
The options `ceph_namespace`, `ceph_image`, and `ceph_tag` are similar to
`namespace` and `tag` but they specify the values for the ceph image. It will
often come from a different registry, and have a different versioned tag
policy.
The values in the `set` map are used when evaluating the file
`/usr/share/openstack-tripleo-common/container-images/tripleo_containers.yaml.j2`
as a Jinja2 template. This file contains the list of every container image and
how it relates to TripleO services and heat parameters.
If Ceph is not part of the overcloud deployment, it's possible to skip pulling
the related containers by setting the `ceph_images` parameter to false as shown
in the example below::
ContainerImagePrepare:
- push_destination: 192.168.24.1:8787
set:
ceph_images: false
By doing this, the Ceph container images are not pulled from the remote registry
during the deployment.
Authenticated Registries
........................
If a container registry requires a username and password, then those
values may be passed using the following syntax::
ContainerImagePrepare:
- push_destination: 192.168.24.1:8787
set:
namespace: quay.io/...
...
ContainerImageRegistryCredentials:
'quay.io': {'<your_quay_username>': '<your_quay_password>'}
.. note:: If the `ContainerImageRegistryCredentials` contain the credentials
for a registry whose name matches the `ceph_namespace` parameter, those
credentials will be extracted and passed to ceph-ansible as the
`ceph_docker_registry_username` and `ceph_docker_registry_password` parameters.
Layering image preparation entries
..................................
Since the value of `ContainerImagePrepare` is a list, multiple entries can be
specified, and later entries will overwrite any earlier ones. Consider the
following::
ContainerImagePrepare:
- tag_from_label: rdo_version
push_destination: true
excludes:
- nova-api
set:
namespace: docker.io/tripleomaster
name_prefix: centos-binary-
name_suffix: ''
tag: current-tripleo
- push_destination: true
includes:
- nova-api
set:
namespace: mylocal
tag: myhotfix
This will result in the following heat parameters which shows a `locally built
<build_container_images>`
and tagged `centos-binary-nova-api` being used for `DockerNovaApiImage`::
DockerNeutronMetadataImage: 192.168.24.1:8787/tripleomaster/centos-binary-neutron-metadata-agent:35414701c176a6288fc2ad141dad0f73624dcb94_43527485
DockerNovaApiImage: 192.168.24.1:8787/mylocal/centos-binary-nova-api:myhotfix
The `includes` and `excludes` entries can control the resulting image list in
addition to the filtering which is determined by roles and containerized
services in the plan. `includes` matches take precedence over `excludes`
matches, followed by role/service filtering. The image name must contain the
value within it to be considered a match.
The `includes` and `excludes` list is useful when pulling OpenStack
images using `tag_from_label: '{version}-{release}'` while also
pulling images which are not tagged the same way. The following
example shows how to do this with Ceph::
ContainerImagePrepare:
- push_destination: true
set:
namespace: docker.io/tripleomaster
name_prefix: centos-binary-
name_suffix: ''
tag: current-tripleo
tag_from_label: '{version}-{release}'
excludes: [ceph]
- push_destination: true
set:
ceph_image: ceph
ceph_namespace: docker.io/ceph
ceph_tag: latest
includes: [ceph]
Modifying images during prepare
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It is possible to modify images during prepare to make any required changes,
then immediately deploy with those changes. The use-cases for modifying images
include:
- As part of a Continuous Integration pipeline where images are modified with
the changes being tested before deployment
- As part of a development workflow where local changes need to be deployed for
testing and development
- When changes need to be deployed but are not available through an image
build pipeline (proprietary addons, emergency fixes)
The modification is done by invoking an ansible role on each image which needs
to be modified. The role takes a source image, makes the requested changes,
then tags the result. The prepare can then push the image and set the heat
parameters to refer to the modified image. The modification is done in
the undercloud registry so it is not possible to use this feature when
using the Default registry, where images are pulled directly from a
remote registry during deployment.
The ansible role `tripleo-modify-image`_ conforms with the required role
interface, and provides the required behaviour for the modify use-cases. Modification is controlled via modify-specific keys in the
`ContainerImagePrepare` parameter:
- `modify_role` specifies what ansible role to invoke for each image to modify.
- `modify_append_tag` is used to append to the end of the
source image tag. This makes it obvious that the resulting image has been
modified. It is also used to skip modification if the `push_destination`
registry already has that image, so it is recommended to change
`modify_append_tag` whenever the image must be modified.
- `modify_vars` is a dictionary of ansible variables to pass to the role.
The different use-cases handled by role `tripleo-modify-image`_ are selected by
setting the `tasks_from` variable to the required file in that role. For all of
the following examples, see the documentation for the role
`tripleo-modify-image`_ for the other variables supported by that `tasks_from`.
While developing and testing the `ContainerImagePrepare` entries which modify
images, it is recommended to run prepare on its own to confirm it is being
modified as expected::
sudo openstack tripleo container image prepare \
-e ~/containers-prepare-parameters.yaml
Updating existing packages
..........................
The following entries will result in all packages being updated in the images,
but using the undercloud host's yum repository configuration::
ContainerImagePrepare:
- push_destination: true
...
modify_role: tripleo-modify-image
modify_append_tag: "-updated"
modify_vars:
tasks_from: yum_update.yml
compare_host_packages: true
yum_repos_dir_path: /etc/yum.repos.d
...
Install RPM files
.................
It is possible to install a directory of RPM files, which is useful for
installing hotfixes, local package builds, or any package which is not
available through a package repository. For example the following would install
some hotfix packages only in the `centos-binary-nova-compute` image::
ContainerImagePrepare:
- push_destination: true
...
includes:
- nova-compute
modify_role: tripleo-modify-image
modify_append_tag: "-hotfix"
modify_vars:
tasks_from: rpm_install.yml
rpms_path: /home/stack/nova-hotfix-pkgs
...
Modify with custom Dockerfile
.............................
For maximum flexibility, it is possible to specify a directory containing a
`Dockerfile` to make the required changes. When the role is invoked, a
`Dockerfile.modified` is generated which changes the `FROM` directive and adds
extra `LABEL` directives. The following example runs the custom
`Dockerfile` on the `centos-binary-nova-compute` image::
ContainerImagePrepare:
- push_destination: true
...
includes:
- nova-compute
modify_role: tripleo-modify-image
modify_append_tag: "-hotfix"
modify_vars:
tasks_from: modify_image.yml
modify_dir_path: /home/stack/nova-custom
...
An example `/home/stack/nova-custom/Dockerfile` follows. Note that after any
`USER root` directives have been run, it is necessary to switch back to the
original image default user::
FROM docker.io/tripleomaster/centos-binary-nova-compute:latest
USER root
COPY customize.sh /tmp/
RUN /tmp/customize.sh
USER "nova"
.. _Delorean repository: https://trunk.rdoproject.org/centos7-master/ac/82/ac82ea9271a4ae3860528eaf8a813da7209e62a6_28eeb6c7/
.. _tripleo-modify-image: https://github.com/openstack/ansible-role-tripleo-modify-image
Modify with Python source code installed via pip from OpenDev Gerrit
....................................................................
If you would like to build an image and apply your patch in a Python project in
OpenStack, you can use this example::
ContainerImagePrepare:
- push_destination: true
...
includes:
- heat-api
modify_role: tripleo-modify-image
modify_append_tag: "-devel"
modify_vars:
tasks_from: dev_install.yml
source_image: docker.io/tripleomaster/centos-binary-heat-api:current-tripleo
refspecs:
-
project: heat
refspec: refs/changes/12/1234/3
...
It will produce a modified image with Python source code installed via pip.
Building hotfixed containers
............................
The `tripleoclient` OpenStack plugin provides a command line interface which
will allow operators to apply packages (hotfixes) to running containers. This
capability leverages the **tripleo-modify-image** role, and automates its
application to a set of containers for a given collection of packages.
Using the provided command line interface is simple. The interface has very few
required options. The noted options below inform the tooling which containers
need to have the hotfix(es) applied, and where to find the hotfixed package(s).
============ =================================================================
option Description
============ =================================================================
--image The `--image` argument requires the use fully qualified image
name, something like *localhost/image/name:tag-data*. The
`--image` option can be used more than once, which will inform
the tooling that multiple containers need to have the same
hotfix packages applied.
--rpms-path The `--rpms-path` argument requires the full path to a
directory where RPMs exist. The RPMs within this directory will
be installed into the container, producing a new layer for an
existing container.
--tag The `--tag` argument is optional, though it is recommended to
be used. The value of this option will append to the tag of the
running container. By using the tag argument, images that have
been modified can be easily identified.
============ =================================================================
With all of the required information, the command to modify existing container
images can be executed like so.
.. code-block:: shell
# The shell variables need to be replaced with data that pertains to the given environment.
openstack tripleo container image hotfix --image ${FULLY_QUALIFIED_IMAGE_NAME} \
--rpms-path ${RPM_DIRECTORY} \
--tag ${TAG_VALUE}
When this command completes, new container images will be available on the
local system and are ready to be integrated into the environment.
You should see the image built on your local system via buildah CLI:
.. code-block:: shell
# The shell variables need to be replaced with data that pertains to the given environment.
sudo buildah images | grep ${TAG_VALUE}
Here is an example on how to push it into the TripleO Container registry:
.. code-block:: shell
# ${IMAGE} is in this format: <registry>/<namespace>/<name>:<tag>
sudo openstack tripleo container image push --local \
--registry-url 192.168.24.1:8787 ${IMAGE}
.. note::
Container images can be pushed to the TripleO Container registry or
a Docker Registry (using basic auth or the bearer token auth).
Now that your container image is pushed into a registry, you can deploy it
where it's needed. Two ways are supported:
* (Long but persistent): Update Container$NameImage where $Name is the name of
the service we update (e.g. ContainerNovaComputeImage). The parameters
can be found in TripleO Heat Templates. Once you update it into your
environment, you need to re-run the "openstack overcloud deploy" command
again and the necessary hosts will get the new container.
Example::
parameter_defaults:
# Replace the values by where the image is stored
ContainerNovaComputeImage: <registry>/<namespace>/<name>:<tag>
* (Short but not persistent after a minor update): Run Paunch or Ansible
to update the container on a host. The procedure is already documented
in the :doc:`./tips_tricks` manual.
Once the hotfixed container image has been deployed, it's very important to
check that the container is running with the right rpm version.
For example, if the nova-compute container was updated with a new hotfix image,
we want to check that the right nova-compute rpm is installed:
.. code-block:: shell
sudo podman exec -ti -u root nova_compute rpm -qa | grep nova-compute
It will return the version of the openstack-nova-compute rpm and we can compare
it with the one that was delivered via rpm. If the version is not correct (e.g.
older), it means that the hotfix image is wrong and doesn't contain the rpm
provided to build the new image. The image has to be rebuilt and redeployed.
deploy-guide/source/deployment/deployment_log.rst
-4
View File
@@ -1,4 +0,0 @@
Deployment Log
^^^^^^^^^^^^^^
The ansible part of the deployment creates a log file that is saved on the
undercloud. The log file is available at ``$HOME/ansible.log``.
deploy-guide/source/deployment/deployment_output.rst
-31
View File
@@ -1,31 +0,0 @@
Deployment Output
^^^^^^^^^^^^^^^^^
After the tripleo-admin user is created, ``ansible-playbook`` will be used to
configure the overcloud nodes.
The output from ``ansible-playbook`` will begin to appear in the console
and will be updated periodically as more tasks are applied.
When ansible is finished a play recap will be shown, and the usual overcloudrc
details will then be displayed. The following is an example of the end of the
output from a successful deployment::
PLAY RECAP ****************************************************************
compute-0 : ok=134 changed=48 unreachable=0 failed=0
openstack-0 : ok=164 changed=28 unreachable=0 failed=1
openstack-1 : ok=160 changed=28 unreachable=0 failed=0
openstack-2 : ok=160 changed=28 unreachable=0 failed=0
pacemaker-0 : ok=138 changed=30 unreachable=0 failed=0
pacemaker-1 : ok=138 changed=30 unreachable=0 failed=0
pacemaker-2 : ok=138 changed=30 unreachable=0 failed=0
undercloud : ok=2 changed=0 unreachable=0 failed=0
Overcloud configuration completed.
Overcloud Endpoint: http://192.168.24.8:5000/
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
When a failure happens, the deployment will stop and the error will be shown.
Review the ``PLAY RECAP`` which will show each host that is part of the
overcloud and the grouped count of each task status.
deploy-guide/source/deployment/deployment_status.rst
-33
View File
@@ -1,33 +0,0 @@
Deployment Status
^^^^^^^^^^^^^^^^^
Since Heat is no longer the source of authority on the status of the overcloud
deployment, a new tripleoclient command is available to show the overcloud
deployment status::
openstack overcloud status
The output will report the status of the deployment, taking into consideration
the result of all the steps to do the full deployment. The following is an
example of the output::
[stack@undercloud ]$ openstack overcloud status
+------------+-------------------+
| Stack Name | Deployment Status |
+------------+-------------------+
| overcloud | DEPLOY_SUCCESS |
+------------+-------------------+
A different stack name can be specified with ``--stack``::
[stack@undercloud ]$ openstack overcloud status --stack my-deployment
+---------------+-------------------+
| Stack Name | Deployment Status |
+-----------+-----------------------+
| my-deployment | DEPLOY_SUCCESS |
+---------------+-------------------+
The deployment status is stored in the YAML file, generated at
``$HOME/overcloud-deploy/<stack>/<stack>-deployment_status.yaml`` in
the undercloud node.
deploy-guide/source/deployment/ephemeral_heat.rst
-169
View File
@@ -1,169 +0,0 @@
.. _ephemeral_heat:
Ephemeral Heat
==============
Introduction
------------
Ephemeral Heat is a means to install the overcloud by using an ephemeral Heat
process instead of a system installed Heat process. This change is possible
beginning in the Wallaby release.
In a typical undercloud, Heat is installed on the undercloud and processes are
run in podman containers for heat-api and heat-engine. When using ephemeral
Heat, there is no longer a requirement that Heat is installed on the
undercloud, instead these processes are started on demand by the deployment,
update, and upgrade commands.
This model has been in use within TripleO already for both the undercloud and
:ref:`standalone <standalone>` installation methods, which start an on demand
all in one heat-all process in order to perform only the installation. Using
ephemeral Heat in this way allows for re-use of the Heat templates from
tripleo-heat-templates without having to require an already fully installed
undercloud.
Description
-----------
Ephemeral Heat is enabled by passing the ``--heat-type`` argument to
``openstack overcloud deploy``. The ephemeral process can also be launched
outside of a deployment with the ``openstack tripleo launch heat`` command. The
latter command also takes a ``--heat-type`` argument to enable selecting the
type of Heat process to use.
Heat types
__________
The ``--heat-type`` argument allows for the following options described below.
installed
Use the system Heat installation. This is the historical TripleO usage of
Heat with Heat fully installed on the undercloud. This is the default
value, and requires a fully installed undercloud.
native
Use an ephemeral ``heat-all`` process. The process will be started natively
on the system executing tripleoclient commands by way of an OS (operating
system) fork.
container
A podman container will be started on the executing system that runs a
single ``heat-all`` process.
pod
A podman pod will be started on the executing system that runs containers
for ``heat-api`` and ``heat-engine``.
In all cases, the process(es) are terminated at the end of the deployment.
.. note::
The native and container methods are limited in scale due to being a single
Heat process. Deploying more than 3 nodes or 2 roles will significantly
impact the deployment time with these methods as Heat has only a single
worker thread.
Using the installed or pod methods enable scaling node and role counts as
is typically required.
Using
-----
The following example shows using ``--heat-type`` to enable ephemeral Heat::
openstack overcloud deploy \
--stack overcloud \
--work-dir ~/overcloud-deploy/overcloud \
--heat-type <pod|container|native> \
<other cli arguments>
With ephemeral Heat enabled, several additional deployment artifacts are
generated related to the management of the Heat process(es). These artifacts
are generated under the working directory of the deployment in a
``heat-launcher`` subdirectory. The working directory can be overridden with
the ``--work-dir`` argument.
Using the above example, the Heat artifact directory would be located at
``~/overcloud-deploy/overcloud/heat-launcher``. An example of the directory
contents is shown below::
[centos@ephemeral-heat ~]$ ls -l ~/overcloud-deploy/overcloud/heat-launcher/
total 41864
-rw-rw-r--. 1 centos centos 650 Mar 24 18:39 api-paste.ini
-rw-rw-r--. 1 centos centos 1054 Mar 24 18:39 heat.conf
-rw-rw-r--. 1 centos centos 42852118 Mar 24 18:31 heat-db-dump.sql
-rw-rw-r--. 1 centos centos 2704 Mar 24 18:39 heat-pod.yaml
drwxrwxr-x. 2 centos centos 49 Mar 24 16:02 log
-rw-rw-r--. 1 centos centos 1589 Mar 24 18:39 token_file.json
The directory contains the necessary files to inspect and debug the Heat
process(es), and if necessary reproduce the deployment.
.. note::
The consolidated log file for the Heat process is the ``log`` file in the
``heat-launcher`` directory.
Launching Ephemeral Heat
________________________
Outside of a deployment, the ephemeral Heat process can also be started with the
``openstack tripleo launch heat`` command. This can be used to interactively
use the ephemeral Heat process or to debug a previous deployment.
When combined with ``--heat-dir`` and ``--restore-db``, the command can be used
to restore the Heat process and database from a previous deployment::
openstack tripleo launch heat \
--heat-type pod \
--heat-dir ~/overcloud-deploy/overcloud/heat-launcher \
--restore-db
The command will exit after launching the Heat process, and the Heat process
will continue to run in the background.
Interacting with ephemeral Heat
...............................
With the ephemeral Heat process launched and running, ``openstackclient`` can be
used to interact with the Heat API. The following shell environment
configuration must set up access to the Heat API::
unset OS_CLOUD
unset OS_PROJECT_NAME
unset OS_PROJECT_DOMAIN_NAME
unset OS_USER_DOMAIN_NAME
export OS_AUTH_TYPE=none
export OS_ENDPOINT=http://127.0.0.1:8006/v1/admin
You can also use the ``OS_CLOUD`` environment to set up the same::
export OS_CLOUD=heat
Once the environment is configured, ``openstackclient`` work as expected
against the Heat API::
[centos@ephemeral-heat ~]$ openstack stack list
+--------------------------------------+------------+---------+-----------------+----------------------+--------------+
| ID | Stack Name | Project | Stack Status | Creation Time | Updated Time |
+--------------------------------------+------------+---------+-----------------+----------------------+--------------+
| 761e2a54-c6f9-4e0f-abe6-c8e0ad51a76c | overcloud | admin | CREATE_COMPLETE | 2021-03-22T20:48:37Z | None |
+--------------------------------------+------------+---------+-----------------+----------------------+--------------+
Killing ephemeral Heat
......................
To stop the ephemeral Heat process previously started with ``openstack tripleo
launch heat``, use the ``--kill`` argument::
openstack tripleo launch heat \
--heat-type pod \
--heat-dir ~/overcloud-deploy/overcloud/heat-launcher \
--kill
Limitations
-----------
Ephemeral Heat currently only supports new deployments. Update and Upgrade
support for deployments that previously used the system installed Heat will be
coming.
deploy-guide/source/deployment/index.rst
-35
View File
@@ -1,35 +0,0 @@
TripleO OpenStack Deployment
============================
This section describes how to deploy OpenStack clouds on containers, either on
the undercloud or the overcloud.
.. toctree::
:maxdepth: 1
undercloud
install_undercloud
overcloud
install_overcloud
TripleO Deployment Advanced Topics
==================================
This section has additional documentation around advanced deployment related topics.
.. toctree::
:maxdepth: 1
3rd_party
ansible_config_download
ansible_config_download_differences
architecture
build_single_image
container_image_prepare
ephemeral_heat
instack_undercloud
network_v2
standalone
template_deploy
tips_tricks
upload_single_image
deploy-guide/source/deployment/instack_undercloud.rst
-227
View File
@@ -1,227 +0,0 @@
(DEPRECATED) Installing the Undercloud
--------------------------------------
.. note::
Instack-undercloud is deprecated in Rocky cycle. Containerized undercloud
should be installed instead. See :doc:`undercloud` for backward
compatibility related information.
.. note::
Please ensure all your nodes (undercloud, compute, controllers, etc) have
their internal clock set to UTC in order to prevent any issue with possible
file future-dated timestamp if hwclock is synced before any timezone offset
is applied.
#. Log in to your machine (baremetal or VM) where you want to install the
undercloud as a non-root user (such as the stack user)::
ssh <non-root-user>@<undercloud-machine>
.. note::
If you don't have a non-root user created yet, log in as root and create
one with following commands::
sudo useradd stack
sudo passwd stack # specify a password
echo "stack ALL=(root) NOPASSWD:ALL" | sudo tee -a /etc/sudoers.d/stack
sudo chmod 0440 /etc/sudoers.d/stack
su - stack
.. note::
The undercloud is intended to work correctly with SELinux enforcing.
Installations with the permissive/disabled SELinux are not recommended.
The ``undercloud_enable_selinux`` config option controls that setting.
.. note::
vlan tagged interfaces must follow the if_name.vlan_id convention, like for
example: eth0.vlan100 or bond0.vlan120.
.. admonition:: Baremetal
:class: baremetal
Ensure that there is a FQDN hostname set and that the $HOSTNAME environment
variable matches that value. The easiest way to do this is to set the
``undercloud_hostname`` option in undercloud.conf before running the
install. This will allow the installer to configure all of the hostname-
related settings appropriately.
Alternatively the hostname settings can be configured manually, but
this is strongly discouraged. The manual steps are as follows::
sudo hostnamectl set-hostname myhost.mydomain
sudo hostnamectl set-hostname --transient myhost.mydomain
An entry for the system's FQDN hostname is also needed in /etc/hosts. For
example, if the system is named *myhost.mydomain*, /etc/hosts should have
an entry like::
127.0.0.1 myhost.mydomain myhost
#. Enable needed repositories:
.. admonition:: RHEL
:class: rhel
Enable optional repo::
sudo yum install -y yum-utils
sudo yum-config-manager --enable rhelosp-rhel-7-server-opt
.. include:: ../repositories.rst
#. Install the TripleO CLI, which will pull in all other necessary packages as dependencies::
sudo yum install -y python-tripleoclient
.. admonition:: Ceph
:class: ceph
If you intend to deploy Ceph in the overcloud, or configure the overcloud to use an external Ceph cluster, and are running Pike or newer, then install ceph-ansible on the undercloud::
sudo yum install -y ceph-ansible
#. Prepare the configuration file::
cp /usr/share/python-tripleoclient/undercloud.conf.sample ~/undercloud.conf
It is backwards compatible with non-containerized instack underclouds.
.. admonition:: Stable Branch
:class: stable
For a non-containerized undercloud, copy in the sample configuration
file and edit it to reflect your environment::
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf
.. note:: There is a tool available that can help with writing a basic
``undercloud.conf``:
`Undercloud Configuration Wizard <http://ucw.tripleo.org/>`_
It takes some basic information about the intended overcloud
environment and generates sane values for a number of the important
options.
#. (OPTIONAL) Generate configuration for preparing container images
As part of the undercloud install, an image registry is configured on port
`8787`. This is used to increase reliability of overcloud image pulls, and
minimise overall network transfers. The undercloud registry will be
populated with images required by the undercloud by generating the following
`containers-prepare-parameter.yaml` file and including it in
``undercloud.conf:
container_images_file=$HOME/containers-prepare-parameter.yaml``::
openstack tripleo container image prepare default \
--local-push-destination \
--output-env-file ~/containers-prepare-parameter.yaml
.. note::
This command is available since Rocky.
See :ref:`prepare-environment-containers` for details on using
`containers-prepare-parameter.yaml` to control what can be done
during the container images prepare phase of an undercloud install.
Additionally, ``docker_insecure_registries`` and ``docker_registry_mirror``
parameters allow to customize container registries via the
``undercloud.conf`` file.
#. (OPTIONAL) Override heat parameters and environment files used for undercloud
deployment.
Similarly to overcloud deployments, see :ref:`override-heat-templates` and
:ref:`custom-template-location`, the ``undercloud.conf: custom_env_files``
and ``undercloud.conf: templates`` configuration parameters allow to
use a custom heat templates location and override or specify additional
information for Heat resources used for undercloud deployment.
Additionally, the ``undercloud.conf: roles_file`` parameter brings in the
ultimate flexibility of :ref:`custom_roles` and :ref:`composable_services`.
This allows you to deploy an undercloud composed of highly customized
containerized services, with the same workflow that TripleO uses for
overcloud deployments.
.. note:: The CLI and configuration interface used to deploy a containerized
undercloud is the same as that used by 'legacy' non-containerized
underclouds. As noted above however mechanism by which the undercloud is
actually deployed is completely changed and what is more, for the first
time aligns with the overcloud deployment. See the command
``openstack tripleo deploy --standalone`` help for details.
That interface extension for standalone clouds is experimental for Rocky.
It is normally should not be used directly for undercloud installations.
#. Run the command to install the undercloud:
.. admonition:: SSL
:class: optional
To deploy an undercloud with SSL, see :doc:`../features/ssl`.
.. admonition:: Validations
:class: validations
:doc:`../post_deployment/validations/index` will be installed and
configured during undercloud installation. You can set
``enable_validations = false`` in ``undercloud.conf`` to prevent
that.
To deploy an undercloud::
openstack undercloud install
.. note::
The undercloud is containerized by default as of Rocky.
.. note::
It's possible to enable verbose logging with ``--verbose`` option.
Since Rocky, we run all the OpenStack services in a moby container runtime
unless the default settings are overwritten.
This command requires 2 services to be running at all times. The first one is a
basic keystone service, which is currently executed by `tripleoclient` itself, the
second one is `heat-all` which executes the templates and installs the services.
The latter can be run on baremetal or in a container (tripleoclient will run it
in a container by default).
Once the install has completed, you should take note of the files ``stackrc`` and
``undercloud-passwords.conf``. You can source ``stackrc`` to interact with the
undercloud via the OpenStack command-line client. The ``undercloud-passwords.conf``
file contains the passwords used for each service in the undercloud. These passwords
will be automatically reused if the undercloud is reinstalled on the same system,
so it is not necessary to copy them to ``undercloud.conf``.
.. note:: Heat installer configuration, logs and state is ephemeral for
undercloud deployments. Generated artifacts for consequent deployments get
overwritten or removed (when ``undercloud.conf: cleanup = true``).
Although, you can still find them stored in compressed files.
Miscellaneous undercloud deployment artifacts, like processed heat templates and
compressed files, can be found in ``undercloud.conf: output_dir`` locations
like ``~/tripleo-heat-installer-templates``.
There is also a compressed file created and placed into the output dir, named as
``undercloud-install-<TS>.tar.bzip2``, where TS represents a timestamp.
Downloaded ansible playbooks and inventory files (see :ref:`config_download`)
used for undercloud deployment are stored in the tempdir
``~/undercloud-ansible-<XXXX>`` by default.
.. note::
Any passwords set in ``undercloud.conf`` will take precedence over the ones in
``undercloud-passwords.conf``.
.. note::
The used undercloud installation command can be rerun to reapply changes from
``undercloud.conf`` to the undercloud. Note that this should **not** be done
if an overcloud has already been deployed or is in progress.
.. note::
If running ``docker`` commands as a stack user after an undercloud install fail
with a permission error, log out and log in again. The stack user does get added
to the docker group during install, but that change gets reflected only after a
new login.
deploy-guide/source/deployment/install_overcloud.rst
-712
View File
@@ -1,712 +0,0 @@
.. _basic-deployment-cli:
Basic Deployment (CLI)
======================
These steps document a basic deployment with |project| in an environment using
the project defaults.
.. note::
Since Rocky, Ansible is used to deploy the software configuration of
the overcloud nodes using a feature called **config-download**. While
there are no necessary changes to the default deployment commands,
there are several differences to the deployer experience.
It's recommended to review these differences as documented at
:doc:`ansible_config_download_differences`
**config-download** is fully documented at
:doc:`ansible_config_download`
Prepare Your Environment
------------------------
#. Make sure you have your environment ready and undercloud running:
* :doc:`../environments/index`
* :doc:`undercloud`
#. Log into your undercloud virtual machine and become the non-root user (stack
by default)::
ssh root@<undercloud-machine>
su - stack
#. In order to use CLI commands easily you need to source needed environment
variables::
source stackrc
.. _basic-deployment-cli-get-images:
Get Images
----------
.. note::
If you already have images built, perhaps from a previous installation of
|project|, you can simply copy those image files into your non-root user's
home directory and skip this section.
If you do this, be aware that sometimes newer versions of |project| do not
work with older images, so if the deployment fails it may be necessary to
delete the older images and restart the process from this step.
Alternatively, images are available via RDO at
https://images.rdoproject.org/centos9/master/rdo_trunk/ which offers images from both the
CentOS Build System (cbs) and RDO Trunk (called rdo_trunk or delorean).
However this mirror is slow so if you experience slow download speeds
you should skip to building the images instead.
The image files required are::
ironic-python-agent.initramfs
ironic-python-agent.kernel
overcloud-full.initrd
overcloud-full.qcow2
overcloud-full.vmlinuz
Images must be built prior to doing a deployment. An IPA ramdisk and
openstack-full image can all be built using tripleo-common.
It's recommended to build images on the installed undercloud directly since all
the dependencies are already present, but this is not a requirement.
The following steps can be used to build images. They should be run as the same
non-root user that was used to install the undercloud. If the images are not
created on the undercloud, one should use a non-root user.
#. Choose image operating system:
.. admonition:: CentOS
:class: centos
The image build with no arguments will build CentOS 8. It will include the
common YAML of
``/usr/share/openstack-tripleo-common/image-yaml/overcloud-images-python3.yaml``
and the CentOS YAML at
``/usr/share/openstack-tripleo-common/image-yaml/overcloud-images-centos8.yaml``.
.. admonition:: CentOS 9
:class: centos9
The default YAML for Centos 9 is
``/usr/share/openstack-tripleo-common/image-yaml/overcloud-images-centos9.yaml``
::
export OS_YAML="/usr/share/openstack-tripleo-common/image-yaml/overcloud-images-centos9.yaml"
.. admonition:: RHEL
:class: rhel
The common YAML is
``/usr/share/openstack-tripleo-common/image-yaml/overcloud-images-python3.yaml``.
It must be specified along with the following.
The default YAML for RHEL is
``/usr/share/openstack-tripleo-common/image-yaml/overcloud-images-rhel8.yaml``
::
export OS_YAML="/usr/share/openstack-tripleo-common/image-yaml/overcloud-images-rhel8.yaml"
#. Install the ``current-tripleo`` delorean repository and deps repository:
.. include:: ../repositories.rst
3. Export environment variables
::
export DIB_YUM_REPO_CONF="/etc/yum.repos.d/delorean*"
.. admonition:: Ceph
:class: ceph
::
export DIB_YUM_REPO_CONF="$DIB_YUM_REPO_CONF /etc/yum.repos.d/tripleo-centos-ceph*.repo"
.. admonition:: CentOS 9
:class: centos9
::
export DIB_YUM_REPO_CONF="/etc/yum.repos.d/delorean* /etc/yum.repos.d/tripleo-centos-*"
.. admonition:: Stable Branch
:class: stable
.. admonition:: Victoria
:class: victoria
::
export STABLE_RELEASE="victoria"
.. admonition:: Ussuri
:class: ussuri
::
export STABLE_RELEASE="ussuri"
.. admonition:: Train
:class: train
::
export STABLE_RELEASE="train"
#. Build the required images:
.. admonition:: RHEL
:class: rhel
Download the RHEL 7.4 cloud image or copy it over from a different location,
for example:
``https://access.redhat.com/downloads/content/69/ver=/rhel---7/7.4/x86_64/product-software``,
and define the needed environment variables for RHEL 7.4 prior to running
``tripleo-build-images``::
export DIB_LOCAL_IMAGE=rhel-server-7.4-x86_64-kvm.qcow2
.. admonition:: RHEL Portal Registration
:class: portal
To register the image builds to the Red Hat Portal define the following variables::
export REG_METHOD=portal
export REG_USER="[your username]"
export REG_PASSWORD="[your password]"
# Find this with `sudo subscription-manager list --available`
export REG_POOL_ID="[pool id]"
export REG_REPOS="rhel-7-server-rpms rhel-7-server-extras-rpms rhel-ha-for-rhel-7-server-rpms \
rhel-7-server-optional-rpms rhel-7-server-openstack-6.0-rpms"
.. admonition:: Ceph
:class: ceph
If using Ceph, additional channels need to be added to `REG_REPOS`.
Enable the appropriate channels for the desired release, as indicated below.
Do not enable any other channels not explicitly marked for that release.
::
rhel-7-server-rhceph-2-mon-rpms
rhel-7-server-rhceph-2-osd-rpms
rhel-7-server-rhceph-2-tools-rpms
.. admonition:: RHEL Satellite Registration
:class: satellite
To register the image builds to a Satellite define the following
variables. Only using an activation key is supported when registering to
Satellite, username/password is not supported for security reasons. The
activation key must enable the repos shown::
export REG_METHOD=satellite
# REG_SAT_URL should be in the format of:
# http://<satellite-hostname>
export REG_SAT_URL="[satellite url]"
export REG_ORG="[satellite org]"
# Activation key must enable these repos:
# rhel-7-server-rpms
# rhel-7-server-optional-rpms
# rhel-7-server-extras-rpms
# rhel-7-server-openstack-6.0-rpms
# rhel-7-server-rhceph-{2,1.3}-mon-rpms
# rhel-7-server-rhceph-{2,1.3}-osd-rpms
# rhel-7-server-rhceph-{2,1.3}-tools-rpms
export REG_ACTIVATION_KEY="[activation key]"
::
openstack overcloud image build
..
.. admonition:: RHEL 9
:class: rhel9
::
openstack overcloud image build \
--config-file /usr/share/openstack-tripleo-common/image-yaml/overcloud-images-python3.yaml \
--config-file /usr/share/openstack-tripleo-common/image-yaml/overcloud-images-rhel9.yaml \
--config-file $OS_YAML
.. admonition:: CentOS 9
:class: centos9
::
openstack overcloud image build \
--config-file /usr/share/openstack-tripleo-common/image-yaml/overcloud-images-python3.yaml \
--config-file /usr/share/openstack-tripleo-common/image-yaml/overcloud-images-centos9.yaml \
--config-file $OS_YAML
See the help for ``openstack overcloud image build`` for further options.
The YAML files are cumulative. Order on the command line is important. The
packages, elements, and options sections will append. All others will overwrite
previously read values.
.. note::
This command will build **overcloud-full** images (\*.qcow2, \*.initrd,
\*.vmlinuz) and **ironic-python-agent** images (\*.initramfs, \*.kernel)
In order to build specific images, one can use the ``--image-name`` flag
to ``openstack overcloud image build``. It can be specified multiple times.
.. note::
If you want to use whole disk images with TripleO, please see :doc:`../provisioning/whole_disk_images`.
.. _basic-deployment-cli-upload-images:
Upload Images
-------------
Load the images into the containerized undercloud Glance::
openstack overcloud image upload
To upload a single image, see :doc:`upload_single_image`.
If working with multiple architectures and/or platforms with an architecture these
attributes can be specified at upload time as in::
openstack overcloud image upload
openstack overcloud image upload --arch x86_64 \
--httpboot /var/lib/ironic/httpboot/x86_64
openstack overcloud image upload --arch x86_64 --platform SNB \
--httpboot /var/lib/ironic/httpboot/x86_64-SNB
.. note::
Adding ``--httpboot`` is optional but suggested if you need to ensure that
the ``agent`` images are unique within your environment.
.. admonition:: Prior to Rocky release
:class: stable
Before Rocky, the undercloud isn't containerized by default. Hence
you should use the ``/httpboot/*`` paths instead.
This will create 3 sets of images with in the undercloud image service for later
use in deployment, see :doc:`../environments/baremetal`
.. _node-registration:
Register Nodes
--------------
Register and configure nodes for your deployment with Ironic::
openstack overcloud node import instackenv.json
The file to be imported may be either JSON, YAML or CSV format, and
the type is detected via the file extension (json, yaml, csv).
The file format is documented in :ref:`instackenv`.
The nodes status will be set to ``manageable`` by default, so that
introspection may later be run. To also run introspection and make the
nodes available for deployment in one step, the following flags can be
used::
openstack overcloud node import --introspect --provide instackenv.json
Starting with the Newton release you can take advantage of the ``enroll``
provisioning state - see :doc:`../provisioning/node_states` for details.
If your hardware has several hard drives, it's highly recommended that you
specify the exact device to be used during introspection and deployment
as a root device. Please see :ref:`root_device` for details.
.. warning::
If you don't specify the root device explicitly, any device may be picked.
Also the device chosen automatically is **NOT** guaranteed to be the same
across rebuilds. Make sure to wipe the previous installation before
rebuilding in this case.
If there is information from previous deployments on the nodes' disks, it is
recommended to at least remove the partitions and partition table(s). See
:doc:`../provisioning/cleaning` for information on how to do it.
Finally, if you want your nodes to boot in the UEFI mode, additional steps may
have to be taken - see :doc:`../provisioning/uefi_boot` for details.
.. warning::
It's not recommended to delete nodes and/or rerun this command after
you have proceeded to the next steps. Particularly, if you start introspection
and then re-register nodes, you won't be able to retry introspection until
the previous one times out (1 hour by default). If you are having issues
with nodes after registration, please follow
:ref:`node_registration_problems`.
Another approach to enrolling node is
:doc:`../provisioning/node_discovery`.
.. _introspection:
Introspect Nodes
----------------
.. admonition:: Validations
:class: validations
Once the undercloud is installed, you can run the
``pre-introspection`` validations::
openstack tripleo validator run --group pre-introspection
Then verify the results as described in :ref:`running_validation_group`.
Nodes must be in the ``manageable`` provisioning state in order to run
introspection. Introspect hardware attributes of nodes with::
openstack overcloud node introspect --all-manageable
Nodes can also be specified individually by UUID. The ``--provide``
flag can be used in order to move the nodes automatically to the
``available`` provisioning state once the introspection is finished,
making the nodes available for deployment.
::
openstack overcloud node introspect --all-manageable --provide
.. note:: **Introspection has to finish without errors.**
The process can take up to 5 minutes for VM / 15 minutes for baremetal. If
the process takes longer, see :ref:`introspection_problems`.
.. note:: If you need to introspect just a single node, see
:doc:`../provisioning/introspect_single_node`
Provide Nodes
-------------
Only nodes in the ``available`` provisioning state can be deployed to
(see :doc:`../provisioning/node_states` for details). To move
nodes from ``manageable`` to ``available`` the following command can be
used::
openstack overcloud node provide --all-manageable
Flavor Details
--------------
The undercloud will have a number of default flavors created at install time.
In most cases these flavors do not need to be modified, but they can be if
desired. By default, all overcloud instances will be booted with the
``baremetal`` flavor, so all baremetal nodes must have at least as much
memory, disk, and cpu as that flavor.
In addition, there are profile-specific flavors created which can be used with
the profile-matching feature. For more details on deploying with profiles,
see :doc:`../provisioning/profile_matching`.
.. _basic-deployment-cli-configure-namserver:
Configure a nameserver for the Overcloud
----------------------------------------
Overcloud nodes can have a nameserver configured in order to resolve
hostnames via DNS. The nameserver is defined in the undercloud's neutron
subnet. If needed, define the nameserver to be used for the environment::
# List the available subnets
openstack subnet list
openstack subnet set <subnet-uuid> --dns-nameserver <nameserver-ip>
.. admonition:: Stable Branch
:class: stable
For Mitaka release and older, the subnet commands are executed within the
`neutron` command::
neutron subnet-list
neutron subnet-update <subnet-uuid> --dns-nameserver <nameserver-ip>
.. note::
A public DNS server, such as 8.8.8.8 or the undercloud DNS name server
can be used if there is no internal DNS server.
.. admonition:: Virtual
:class: virtual
In virtual environments, the libvirt default network DHCP server address,
typically 192.168.122.1, can be used as the overcloud nameserver.
.. _deploy-the-overcloud:
Deploy the Overcloud
--------------------
.. admonition:: Validations
:class: validations
Before you start the deployment, you may want to run the
``pre-deployment`` validations::
openstack tripleo validator run --group pre-deployment
Then verify the results as described in :ref:`running_validation_group`.
By default 1 compute and 1 control node will be deployed, with networking
configured for the virtual environment. To customize this, see the output of::
openstack help overcloud deploy
.. admonition:: Swap
:class: optional
Swap files or partitions can be installed as part of an Overcloud deployment.
For adding swap files there is no restriction besides having
4GB available on / (by default). When using a swap partition,
the partition must exist and be tagged as `swap1` (by default).
To deploy a swap file or partition in each Overcloud node use one
of the following arguments when deploying::
-e /usr/share/openstack-tripleo-heat-templates/environments/enable-swap-partition.yaml
-e /usr/share/openstack-tripleo-heat-templates/environments/enable-swap.yaml
.. admonition:: Ceph
:class: ceph
When deploying Ceph with dedicated CephStorage nodes to host the CephOSD
service it is necessary to specify the number of CephStorage nodes
to be deployed and to provide some additional parameters to enable usage
of Ceph for Glance, Cinder, Nova or all of them. To do so, use the
following arguments when deploying::
--ceph-storage-scale <number of nodes> -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml
When deploying Ceph without dedicated CephStorage nodes, opting for an HCI
architecture instead, where the CephOSD service is colocated with the
NovaCompute service on the Compute nodes, use the following arguments::
-e /usr/share/openstack-tripleo-heat-templates/environments/hyperconverged-ceph.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml
The `hyperconverged-ceph.yaml` environment file will also enable a port on the
`StorageMgmt` network for the Compute nodes. This will be the Ceph private
network and the Compute NIC templates have to be configured to use that, see
:doc:`../features/network_isolation` for more details on how to do
it.
.. admonition:: RHEL Satellite Registration
:class: satellite
To register the Overcloud nodes to a Satellite add the following flags
to the deploy command::
--rhel-reg --reg-method satellite --reg-org <ORG ID#> --reg-sat-url <satellite URL> --reg-activation-key <KEY>
.. note::
Only using an activation key is supported when registering to
Satellite, username/password is not supported for security reasons.
The activation key must enable the following repos:
rhel-7-server-rpms
rhel-7-server-optional-rpms
rhel-7-server-extras-rpms
rhel-7-server-openstack-6.0-rpms
.. admonition:: SSL
:class: optional
To deploy an overcloud with SSL, see :doc:`../features/ssl`.
Run the deploy command, including any additional parameters as necessary::
openstack overcloud deploy --templates [additional parameters]
.. note::
When deploying a new stack or updating a preexisting deployment, it is
important to avoid using component cli along side the unified cli. This
will lead to unexpected results.
Example:
The following will present a behavior where the my_roles_data will persist,
due to the location of the custom roles data, which is stored in swift::
openstack overcloud deploy --templates -r my_roles_data.yaml
heat stack-delete overcloud
Allow the stack to be deleted then continue::
openstack overcloud deploy --templates
The execution of the above will still reference my_roles_data as the
unified command line client will perform a look up against the swift
storage. The reason for the unexpected behavior is due to the heatclient
lack of awareness of the swift storage.
The correct course of action should be as followed::
openstack overcloud deploy --templates -r my_roles_data.yaml
openstack overcloud delete <stack name>
Allow the stack to be deleted then continue::
openstack overcloud deploy --templates
To deploy an overcloud with multiple controllers and achieve HA,
follow :doc:`../features/high_availability`.
.. admonition:: Virtual
:class: virtual
When deploying the Compute node in a virtual machine
without nested guest support, add ``--libvirt-type qemu``
or launching instances on the deployed overcloud will fail.
.. note::
To deploy the overcloud with network isolation, bonds, and/or custom
network interface configurations, instead follow the workflow here to
deploy: :doc:`../features/network_isolation`
.. note::
Previous versions of the client had many parameters defaulted. Some of these
parameters are now pulling defaults directly from the Heat templates. In
order to override these parameters, one should use an environment file to
specify these overrides, via 'parameter_defaults'.
The parameters that controlled these parameters will be deprecated in the
client, and eventually removed in favor of using environment files.
Post-Deployment
---------------
.. admonition:: Validations
:class: validations
After the deployment finishes, you can run the ``post-deployment``
validations::
openstack tripleo validator run --group post-deployment
Then verify the results as described in :ref:`running_validation_group`.
Deployment artifacts
^^^^^^^^^^^^^^^^^^^^
Artifacts from the deployment, including log files, rendered
templates, and generated environment files are saved under the working
directory which can be specified with the ``--work-dir`` argument to
``openstack overcloud deploy``. By default, the location is
``~/overcloud-deploy/<stack>``.
Access the Overcloud
^^^^^^^^^^^^^^^^^^^^
``openstack overcloud deploy`` generates an overcloudrc file appropriate for
interacting with the deployed overcloud in the current user's home directory.
To use it, simply source the file::
source ~/overcloudrc
To return to working with the undercloud, source the ``stackrc`` file again::
source ~/stackrc
Add entries to /etc/hosts
^^^^^^^^^^^^^^^^^^^^^^^^^
In cases where the overcloud hostnames are not already resolvable with DNS,
entries can be added to /etc/hosts to make them resolvable. This is
particularly convenient on the undercloud. The Heat stack provides an output
value that can be appended to /etc/hosts easily. Run the following command to
get the output value and add it to /etc/hosts wherever the hostnames should
be resolvable::
openstack stack output show overcloud HostsEntry -f value -c output_value
Setup the Overcloud network
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Initial networks in Neutron in the overcloud need to be created for tenant
instances. The following are example commands to create the initial networks.
Edit the address ranges, or use the necessary ``neutron`` commands to match the
environment appropriately. This assumes a dedicated interface or native VLAN::
openstack network create public --external --provider-network-type flat \
--provider-physical-network datacentre
openstack subnet create --allocation-pool start=172.16.23.140,end=172.16.23.240 \
--network public --gateway 172.16.23.251 --no-dhcp --subnet-range \
172.16.23.128/25 public
The example shows naming the network "public" because that will allow tempest
tests to pass, based on the default floating pool name set in ``nova.conf``.
You can confirm that the network was created with::
openstack network list
Sample output of the command::
+--------------------------------------+----------+--------------------------------------+
| ID | Name | Subnets |
+--------------------------------------+----------+--------------------------------------+
| 4db8dd5d-fab5-4ea9-83e5-bdedbf3e9ee6 | public | 7a315c5e-f8e2-495b-95e2-48af9442af01 |
+--------------------------------------+----------+--------------------------------------+
To use a VLAN, the following example should work. Customize the address ranges
and VLAN id based on the environment::
openstack network create public --external --provider-network-type vlan \
--provider-physical-network datacentre --provider-segment 195
openstack subnet create --allocation-pool start=172.16.23.140,end=172.16.23.240 \
--network public --no-dhcp --gateway 172.16.23.251 \
--subnet-range 172.16.23.128/25 public
Validate the Overcloud
^^^^^^^^^^^^^^^^^^^^^^
Check the `Tempest`_ documentation on how to run tempest.
.. _tempest: ../post_deployment/tempest/tempest.html
Redeploy the Overcloud
^^^^^^^^^^^^^^^^^^^^^^
The overcloud can be redeployed when desired.
#. First, delete any existing Overcloud::
openstack overcloud delete overcloud
#. Confirm the Overcloud has deleted. It may take a few minutes to delete::
# This command should show no stack once the Delete has completed
openstack stack list
#. It is recommended that you delete existing partitions from all nodes before
redeploying, see :doc:`../provisioning/cleaning` for details.
#. Deploy the Overcloud again::
openstack overcloud deploy --templates
deploy-guide/source/deployment/install_undercloud.rst
-325
View File
@@ -1,325 +0,0 @@
Undercloud Installation
=======================
This section contains instructions on how to install the undercloud. For update
or upgrade to a deployed undercloud see undercloud_upgrade_.
.. _undercloud_upgrade: ../post_deployment/upgrade/undercloud.html
.. _install_undercloud:
Installing the Undercloud
--------------------------
.. note::
Instack-undercloud was deprecated in Rocky cycle. Containerized undercloud
should be installed instead. See :doc:`undercloud`
for backward compatibility related information.
.. note::
Please ensure all your nodes (undercloud, compute, controllers, etc) have
their internal clock set to UTC in order to prevent any issue with possible
file future-dated timestamp if hwclock is synced before any timezone offset
is applied.
#. Log in to your machine (baremetal or VM) where you want to install the
undercloud as a non-root user (such as the stack user)::
ssh <non-root-user>@<undercloud-machine>
.. note::
If you don't have a non-root user created yet, log in as root and create
one with following commands::
sudo useradd stack
sudo passwd stack # specify a password
echo "stack ALL=(root) NOPASSWD:ALL" | sudo tee -a /etc/sudoers.d/stack
sudo chmod 0440 /etc/sudoers.d/stack
su - stack
.. note::
The undercloud is intended to work correctly with SELinux enforcing.
Installations with the permissive/disabled SELinux are not recommended.
The ``undercloud_enable_selinux`` config option controls that setting.
.. note::
vlan tagged interfaces must follow the if_name.vlan_id convention, like for
example: eth0.vlan100 or bond0.vlan120.
.. admonition:: Baremetal
:class: baremetal
Ensure that there is a FQDN hostname set and that the $HOSTNAME environment
variable matches that value. The easiest way to do this is to set the
``undercloud_hostname`` option in undercloud.conf before running the
install. This will allow the installer to configure all of the hostname-
related settings appropriately.
Alternatively the hostname settings can be configured manually, but
this is strongly discouraged. The manual steps are as follows::
sudo hostnamectl set-hostname myhost.mydomain
sudo hostnamectl set-hostname --transient myhost.mydomain
An entry for the system's FQDN hostname is also needed in /etc/hosts. For
example, if the system is named *myhost.mydomain*, /etc/hosts should have
an entry like::
127.0.0.1 myhost.mydomain myhost
#. Enable needed repositories:
.. admonition:: RHEL
:class: rhel
Enable optional repo for RHEL7::
sudo yum install -y yum-utils
sudo yum-config-manager --enable rhelosp-rhel-7-server-opt
.. include:: ../repositories.rst
#. Install the TripleO CLI, which will pull in all other necessary packages as dependencies::
sudo dnf install -y python*-tripleoclient
.. admonition:: RHEL7 / CentOS
For RHEL or CentOS 7 the command would be::
sudo yum install -y python-tripleoclient
.. admonition:: Ceph
:class: ceph
If you intend to deploy Ceph in the overcloud, or configure the overcloud to use an external Ceph cluster, and are running Pike or newer, then install ceph-ansible on the undercloud::
sudo dnf install -y ceph-ansible
.. admonition:: TLS
:class: tls
If you intend to deploy *TLS-everywhere* in the overcloud and are
deploying Train with python3 or Ussuri+, install the following packages::
sudo yum install -y python3-ipalib python3-ipaclient krb5-devel
If you're deploying Train with python2, install the corresponding python2
version of the above packages::
sudo yum install -y python-ipalib python-ipaclient krb5-devel
if you intend to use Novajoin to implement *TLS-everywhere* install the
following package::
sudo yum install -y python-novajoin
You can find more information about deploying with TLS in the
:doc:`../features/tls-introduction` documentation.
#. Prepare the configuration file::
cp /usr/share/python-tripleoclient/undercloud.conf.sample ~/undercloud.conf
It is backwards compatible with non-containerized instack underclouds.
.. admonition:: Stable Branch
:class: stable
For a non-containerized undercloud, copy in the sample configuration
file and edit it to reflect your environment::
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf
.. note:: There is a tool available that can help with writing a basic
``undercloud.conf``:
`Undercloud Configuration Wizard <http://ucw.tripleo.org/>`_
It takes some basic information about the intended overcloud
environment and generates sane values for a number of the important
options.
#. (OPTIONAL) Generate configuration for preparing container images
As part of the undercloud install, an image registry is configured on port
`8787`. This is used to increase reliability of overcloud image pulls, and
minimise overall network transfers. The undercloud registry will be
populated with images required by the undercloud by generating the following
`containers-prepare-parameter.yaml` file and including it in
``undercloud.conf:
container_images_file=$HOME/containers-prepare-parameter.yaml``::
openstack tripleo container image prepare default \
--local-push-destination \
--output-env-file ~/containers-prepare-parameter.yaml
.. note::
This command is available since Rocky.
See :ref:`prepare-environment-containers` for details on using
`containers-prepare-parameter.yaml` to control what can be done
during the container images prepare phase of an undercloud install.
Additionally, ``docker_insecure_registries`` and ``docker_registry_mirror``
parameters allow to customize container registries via the
``undercloud.conf`` file.
#. (OPTIONAL) Override heat parameters and environment files used for undercloud
deployment.
Similarly to overcloud deployments, see :ref:`override-heat-templates` and
:ref:`custom-template-location`, the ``undercloud.conf: custom_env_files``
and ``undercloud.conf: templates`` configuration parameters allow to
use a custom heat templates location and override or specify additional
information for Heat resources used for undercloud deployment.
Additionally, the ``undercloud.conf: roles_file`` parameter brings in the
ultimate flexibility of :ref:`custom_roles` and :ref:`composable_services`.
This allows you to deploy an undercloud composed of highly customized
containerized services, with the same workflow that TripleO uses for
overcloud deployments.
.. note:: The CLI and configuration interface used to deploy a containerized
undercloud is the same as that used by 'legacy' non-containerized
underclouds. As noted above however mechanism by which the undercloud is
actually deployed is completely changed and what is more, for the first
time aligns with the overcloud deployment. See the command
``openstack tripleo deploy --standalone`` help for details.
It normally should not be used directly for undercloud installations.
#. Run the command to install the undercloud:
.. admonition:: SSL
:class: optional
To deploy an undercloud with SSL, see :doc:`../features/ssl`.
.. admonition:: Validations
:class: validations
:doc:`../post_deployment/validations/index` will be installed and
configured during undercloud installation. You can set
``enable_validations = false`` in ``undercloud.conf`` to prevent
that.
To deploy an undercloud::
openstack undercloud install
.. note::
The undercloud is containerized by default as of Rocky.
.. note::
It's possible to enable verbose logging with ``--verbose`` option.
.. note::
To install a deprecated instack undercloud, you'll need to deploy
with ``--use-heat=False`` option.
Since Rocky, we will run all the OpenStack services in a moby container runtime
unless the default settings are overwritten.
This command requires 2 services to be running at all times. The first one is a
basic keystone service, which is currently executed by `tripleoclient` itself, the
second one is `heat-all` which executes the templates and installs the services.
The latter can be run on baremetal or in a container (tripleoclient will run it
in a container by default).
Once the install has completed, you should take note of the files ``stackrc`` and
``undercloud-passwords.conf``. You can source ``stackrc`` to interact with the
undercloud via the OpenStack command-line client. The ``undercloud-passwords.conf``
file contains the passwords used for each service in the undercloud. These passwords
will be automatically reused if the undercloud is reinstalled on the same system,
so it is not necessary to copy them to ``undercloud.conf``.
.. note:: Heat installer configuration, logs and state is ephemeral for
undercloud deployments. Generated artifacts for consequent deployments get
overwritten or removed (when ``undercloud.conf: cleanup = true``).
Although, you can still find them stored in compressed files.
Miscellaneous undercloud deployment artifacts, like processed heat templates and
compressed files, can be found in ``undercloud.conf: output_dir`` locations
like ``~/tripleo-heat-installer-templates``.
There is also a compressed file created and placed into the output dir, named as
``undercloud-install-<TS>.tar.bzip2``, where TS represents a timestamp.
Downloaded ansible playbooks and inventory files (see :ref:`config_download`)
used for undercloud deployment are stored in the tempdir
``~/undercloud-ansible-<XXXX>`` by default.
.. note::
In order to obtain the ansible command used for the installation of the
Undercloud in the artifacts directory, it is necessary to pass the option
``--reproduce-command`` in the Undercloud deployment command.
.. note::
Any passwords set in ``undercloud.conf`` will take precedence over the ones in
``undercloud-passwords.conf``.
.. note::
The undercloud installation command can be rerun to reapply changes from
``undercloud.conf`` to the undercloud. Note that this should be done with
caution if an overcloud has already been deployed or is in progress as some
configuration changes could affect the overcloud. These changes include but
are not limited to:
#. Package repository changes on the undercloud, followed by running the
installation command could update the undercloud such that further
management operations are not possible on the overcloud until the
overcloud update or upgrade procedure is followed.
#. Reconfiguration of the undercloud container registry if the
overcloud is using the undercloud as the source for container images.
#. Networking configuration changes on the undercloud which may affect
the overcloud's ability to connect to the undercloud for
instance metadata services.
.. note::
If running ``docker`` commands as a stack user after an undercloud install fail
with a permission error, log out and log in again. The stack user does get added
to the docker group during install, but that change gets reflected only after a
new login.
Cleaning the Undercloud
-----------------------
This procedure isn't cleaning everything that TripleO generates, but enough
so an Undercloud could be re-deployed.
.. note::
This procedure has been tested on Train and onward. There is no guarantee
that it works before this version, due to container commands and
new directories.
#. Log in to your machine (baremetal or VM) where you want to cleanup the
undercloud as a non-root user (such as the stack user)::
ssh <non-root-user>@<undercloud-machine>
#. Cleanup the containers and their images::
sudo podman rm -af
sudo podman rmi -af
#. Remove directories generated by TripleO::
sudo rm -rf \
/var/lib/tripleo-config \
/var/lib/config-data \
/var/lib/container-config-scripts \
/var/lib/container-puppet \
/var/lib/heat-config \
/var/lib/image-service \
/var/lib/mysql
#. Cleanup systemd::
sudo rm -rf /etc/systemd/system/tripleo*
sudo systemctl daemon-reload
deploy-guide/source/deployment/network_v2.rst
-485
View File
@@ -1,485 +0,0 @@
.. _network_v2:
Networking Version 2 (Two)
==========================
Introduction
------------
In the Wallaby cycle TripleO Networking has been refactored so that no
OS::Neutron heat resources are used. This was a pre-requisite for
:doc:`./ephemeral_heat`. Managing non-ephemeral neutron resources with an
ephemeral heat stack is not feasible, so the management of neutron resources
has been externalized from the overcloud heat stack.
High level overview of the changes
..................................
* NIC config templates was migrated to ansible j2 templates during the
Victoria release. Replacing the heat templates previously used for NIC
configuration. Sample ansible j2 templates are available in the
`tripleo-ansible <https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ansible/roles/tripleo_network_config/templates>`_
git repository as well as in
``/usr/share/ansible/roles/tripleo_network_config/templates/`` on a deployed
undercloud.
Please refer to :ref:`creating_custom_interface_templates` on the
:ref:`network_isolation` documentation page for further details on writing
custom Ansible j2 NIC config templates.
* A new schema for the network definitions used for Jinja2 rendering of the
``tripleo-heat-templates`` was introduced, in addition to tripleoclient
commands to provision networks using the new network definitions schema.
* A new schema for network Virtual IPs was introduced in conjunction with
tripleoclient commands to provision the Virtual IPs.
* Service Virtual IPs (redis and ovsdb) was refactored so that the neutron
resources are created by the deploy-steps playbook post-stack create/update.
* The baremetal provisioning schema was extended to include advanced network
layouts. The ``overcloud node provision`` command was extended so that it
also provision neutron port resources for all networks defined for instances/
roles in the baremetal provisioning definition.
* The tool (``tripleo-ansible-inventory``) used to generate the ansible
inventory was extended to use neutron as a source for the inventory in
addition to the overcloud heat stack outputs.
* With the TripleO ansible inventory's support to use neutron resources as a
data source, the baremetal provisioning schema and ``overcloud node
provision`` command was extended to allow arbitrary playbook
execute against the provisioned nodes, as well as applying node network
configuration utilizing the ``tripleo_network_config`` ansible role and the
ansible j2 NIC config templates.
With all of the above in place the ``overcloud deploy`` command was extended so
that it can run all the steps:
#. Create Networks
Run the ``cli-overcloud-network-provision.yaml`` ansible playbook using the
network definitions provided via the ``--network-file`` argument. This
playbook creates/updates the neutron networks on the undercloud and
generates the ``networks-deployed.yaml`` environment file which is included
as a user-environment when creating the overcloud heat stack.
#. Create Virtual IPs
Run the ``cli-overcloud-network-vip-provision.yaml`` ansible playbook using
the Virtual IP definitions provided via the ``--vip-file`` argument. This
playbook creates/updates the Virtual IP port resources in neutron on the
undercloud and generates the ``virtual-ips-deployed.yaml`` environment file
which is included as a user-environment when creating the overcloud heat
stack.
#. Provision Baremetal Instances
Run the ``cli-overcloud-node-provision.yaml`` ansible playbook using the
baremetal instance definitions provided via the ``--baremetal-deployment``
argument in combination with the ``--network-config`` argument so that
baremetal nodes are provisioned and network port resources are created. Also
run any arbitrary Ansible playbooks provided by the user on the provisioned
nodes before finally configured overcloud node networking using the
``tripleo_network_config`` ansible role.
#. Create the overcloud Ephemeral Heat stack
The environment files with the parameters and resource registry overrides
required is automatically included when the ``overcloud deploy`` command is
run with the arguments: ``--vip-file``, ``--baremetal-deployment`` and
``--network-config``.
#. Run Config-Download and the deploy-steps playbook
As an external deploy step the neutron ports for Service Virtual IPs are
created, and the properties of the Virtual IPs are included in hieradata.
.. admonition:: Ceph
:class: ceph
Optionally Ceph may be deployed after the baremetal instances
are provisioned but before the ephemeral Heat stack is created
as described in :doc:`../features/deployed_ceph`.
Using
-----
Pre-Provision networks
......................
The command to pre-provision networks for one or more overcloud stack(s) is
``openstack overcloud network provision``. The command takes a network-v2
version networks definitions YAML file as input, and writes a heat environment
file to the file specified using the ``--output`` argument.
Please refer to the :ref:`network_definition_opts` reference section on the
:ref:`custom_networks` document page for a reference on available options in
the network data YAML schema.
Sample network definition YAML files can be located in the
`tripleo-heat-templates git repository
<https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/network-data-samples/>`_,
or in the ``/usr/share/openstack-tripleo-heat-templates/network-data-samples``
directory on the undercloud.
**Example**: Networks definition YAML file defining the external network.
.. code-block:: yaml
- name: External
name_lower: external
vip: true
mtu: 1500
subnets:
external_subnet:
ip_subnet: 10.0.0.0/24
allocation_pools:
- start: 10.0.0.4
end: 10.0.0.250
gateway_ip: 10.0.0.1
vlan: 10
**Example**: Create or update networks
.. code-block:: bash
$ openstack overcloud network provision \
--output ~/overcloud-networks-deployed.yaml \
~/network_data_v2.yaml
When deploying the overcloud include the environment file generated by the
``overcloud network provision`` command.
.. code-block:: bash
$ openstack overcloud deploy --templates \
-e ~/overcloud-networks-deployed.yaml
Pre-Provision network Virtual IPs
.................................
The command to pre-provision Virtual IPs for an overcloud stack is:
``openstack overcloud network vip provision``. The command takes a Virtual IPs
definitions YAML file as input, and writes a heat environment file to the file
specified using the ``--output`` argument. The ``--stack`` argument defines the
name of the overcloud stack for which Virtual IPs will be provisioned.
Please refer to the :ref:`virtual_ips_definition_opts` reference section on the
:ref:`custom_networks` document page for a reference on available options in
the Virtual IPs YAML schema.
Sample network definition YAML files can be located in the
`tripleo-heat-templates git repository
<https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/network-data-samples/>`_,
or in the ``/usr/share/openstack-tripleo-heat-templates/network-data-samples``
directory on the undercloud.
**Example**: Virtual IPs definition YAML file defining the ctlplane and the
external network Virtual IPs.
.. code-block:: yaml
- network: ctlplane
dns_name: overcloud
- network: external
dns_name: overcloud
**Example**: Create or update Virtual IPs
.. code-block:: bash
$ openstack overcloud network vip provision \
--stack overcloud \
--output ~/overcloud-vip-deployed.yaml \
~/vip_data.yaml
When deploying the overcloud include the environment file generated by the
``overcloud network provision`` command. For example:
.. code-block:: bash
$ openstack overcloud deploy --templates \
-e ~/overcloud-vip-deployed.yaml
Service Virtual IPs
...................
Service Virtual IPs are created as needed when the service is enabled. To
configure the subnet to use the existing ``ServiceVipMap`` heat parameter.
For a fixed IP allocation the existing heat parameters ``RedisVirtualFixedIPs``
and/or ``OVNDBsVirtualFixedIPs`` can be used.
**Example**: Setting fixed ips:
.. code-block:: yaml
parameter_defaults:
RedisVirtualFixedIPs: [{'ip_address': '172.20.0.11'}]
OVNDBsVirtualFixedIPs: [{'ip_address': '172.20.0.12'}]
**Example**: Setting fixed IP address and not creating a neutron resource:
.. code-block:: yaml
parameter_defaults:
RedisVirtualFixedIPs: [{'ip_address': '172.20.0.11', 'use_neutron': false}]
OVNDBsVirtualFixedIPs: [{'ip_address': '172.20.0.12', 'use_neutron': false}]
.. note:: Overriding the Service Virtual IPs using the resource registry
entries ``OS::TripleO::Network::Ports::RedisVipPort`` and
``OS::TripleO::Network::Ports::OVNDBsVipPort`` is no longer
supported.
Provision Baremetal Instances
.............................
Pre provisioning baremetal instances using Metalsmith has been supported for a
while. The TripleO Network v2 work extended the workflow that provision
baremetal instances to also provision the neutron network port resources and
added the interface to run arbitrary Ansible playbooks after node provisioning.
Please refer to the :ref:`baremetal_provision` document page for a reference on
available options in the Baremetal Deployment YAML schema.
**Example**: Baremetal Deployment YAML set up for default the default
network-isolation scenario, including one pre-network config Ansible playbook
that will be run against the nodes in each role.
.. code-block:: yaml
- name: Controller
count: 1
hostname_format: controller-%index%
ansible_playbooks:
- playbook: bm-deploy-playbook.yaml
defaults:
profile: control
networks:
- network: external
subnet: external_subnet
- network: internal_api
subnet: internal_api_subnet01
- network: storage
subnet: storage_subnet01
- network: storage_mgmt
subnet: storage_mgmt_subnet01
- network: tenant
subnet: tenant_subnet01
network_config:
template: templates/multiple_nics/multiple_nics_dvr.j2
default_route_network:
- external
- name: Compute
count: 1
hostname_format: compute-%index%
ansible_playbooks:
- playbook: bm-deploy-playbook.yaml
defaults:
profile: compute-leaf2
networks:
- network: internal_api
subnet: internal_api_subnet02
- network: tenant
subnet: tenant_subnet02
- network: storage
subnet: storage_subnet02
network_config:
template: templates/multiple_nics/multiple_nics_dvr.j2
**Example**: Arbitrary Ansible playbook example bm-deploy-playbook.yaml
.. code-block:: yaml
- name: Overcloud Node Network Config
hosts: allovercloud
any_errors_fatal: true
gather_facts: false
tasks:
- name: A task
debug:
msg: "A message"
To provision baremetal nodes, create neutron port resource and apply network
configuration as defined in the above definition run the ``openstack overcloud
node provision`` command including the ``--network-config`` argument as shown
in the below example:
.. code-block:: bash
$ openstack overcloud node provision \
--stack overcloud \
--network-config \
--output ~/overcloud-baremetal-deployed.yaml \
~/baremetal_deployment.yaml
When deploying the overcloud include the environment file generated by the
``overcloud node provision`` command and enable the ``--deployed-server``
argument.
.. code-block:: bash
$ openstack overcloud deploy --templates \
--deployed-server \
-e ~/overcloud-baremetal-deployed.yaml
The *All-in-One* alternative using overcloud deploy command
.............................................................
It is possible to instruct the ``openstack overcloud deploy`` command to do all
of the above steps in one go. The same YAML definitions can be used and the
environment files will be automatically included.
**Example**: Use the **All-in-One** deploy command:
.. code-block:: bash
$ openstack overcloud deploy \
--templates \
--stack overcloud \
--network-config \
--deployed-server \
--roles-file ~/my_roles_data.yaml \
--networks-file ~/network_data_v2.yaml \
--vip-file ~/vip_data.yaml \
--baremetal-deployment ~/baremetal_deployment.yaml
Managing Multiple Overclouds
............................
When managing multiple overclouds using a single undercloud one would have to
use a different ``--stack`` name and ``--output`` as well as per-overcloud
YAML definitions for provisioning Virtual IPs and baremetal nodes.
Networks can be shared, or separate for each overcloud stack. If they are
shared, use the same network definition YAML and deployed network environment
for all stacks. In the case where networks are not shared, a separate network
definitions YAML and a separate deployed network environment file must be used
by each stack.
.. note:: The ``ctlplane`` provisioning network will always be shared.
Migrating existing deployments
------------------------------
To facilitate the migration for deployed overclouds tripleoclient commands to
extract information from deployed overcloud stacks has been added. During the
upgrade to Wallaby these tools will be executed as part of the undercloud
upgrade, placing the generated YAML definition files in the working directory
(Defaults to: ``~/overcloud-deploy/$STACK_NAME/``). Below each export command
is described, and examples to use them manually with the intent for developers
and operators to be able to better understand what happens "under the hood"
during the undercloud upgrade.
There is also a tool ``convert_heat_nic_config_to_ansible_j2.py`` that can be
used to convert heat template NIC config to Ansible j2 templates.
.. warning:: If migrating to use Networking v2 while using the non-Ephemeral
heat i.e ``--heat-type installed``, the existing overcloud stack
must **first** be updated to set the ``deletion_policy`` for
``OS::Nova`` and ``OS::Neutron`` resources. This can be done
using a ``--stack-only`` update, including an environment file
setting the following tripleo-heat-templates parameters
``NetworkDeletionPolicy``, ``PortDeletionPolicy`` and
``ServerDeletionPolicy`` to ``retain``.
If the deletion policy is not set to ``retain`` the
orchestration service will **delete** the existing resources
when an update using the Networking v2 environments is
performed.
Conflicting legacy environment files
....................................
The heat environment files created by the Networking v2 commands uses resource
registry overrides to replace the existing resources with *pre-deployed*
resource types. These resource registry entries was also used by legacy
environment files, such as ``network-isolation.yaml``. The legacy files should
no longer be used, as they will nullify the new overrides.
It is recommended to compare the generated environment files with existing
environment files used with the overcloud deployment prior to the migration and
remove all settings that overlap with the settings in the generated environment
files.
Convert NIC configs
...................
In the tripleo-heat-templates ``tools`` directory there is a script
``convert_heat_nic_config_to_ansible_j2.py`` that can be used to convert heat
NIC config templates to Ansible j2 NIC config templates.
**Example**: Convert the compute.yaml heat NIC config template to Ansible j2.
.. code-block:: bash
$ /usr/share/openstack-tripleo-heat-templates/convert_heat_nic_config_to_ansible_j2.py \
--stack overcloud \
--networks-file network_data.yaml \
~/nic-configs/compute.yaml
.. warning:: The tool does a best-effort to fully automate the conversion. The
new Ansible j2 template files should be inspected, there may be
a need to manually edit the new Ansible j2 template. The tool will
try to highlight any issues that need manual intervention by
adding comments in the Ansible j2 file.
The :ref:`migrating_existing_network_interface_templates` section on the
:ref:`network_isolation` documentation page provides a guide for manual
migration.
Generate Network YAML
.....................
The command ``openstack overcloud network extract`` can be used to generate
a Network definition YAML file from a deployed overcloud stack. The YAML
definition file can then be used with ``openstack overcloud network provision``
and the ``openstack overcloud deploy`` command.
**Example**: Generate a Network definition YAML for the ``overcloud`` stack:
.. code-block:: bash
$ openstack overcloud network extract \
--stack overcloud \
--output ~/network_data_v2.yaml
Generate Virtual IPs YAML
.........................
The command ``openstack overcloud network vip extract`` can be used to generate
a Virtual IPs definition YAML file from a deployed overcloud stack. The YAML
definition file can then be used with ``openstack overcloud network vip
provision`` command and/or the ``openstack overcloud deploy`` command.
**Example**: Generate a Virtual IPs definition YAML for the ``overcloud``
stack:
.. code-block:: bash
$ openstack overcloud network vip extract \
--stack overcloud \
--output /home/centos/overcloud/network_vips_data.yaml
Generate Baremetal Provision YAML
.................................
The command ``openstack overcloud node extract provisioned`` can be used to
generate a Baremetal Provision definition YAML file from a deployed overcloud
stack. The YAML definition file can then be used with ``openstack overcloud
node provision`` command and/or the ``openstack overcloud deploy`` command.
**Example**: Export deployed overcloud nodes to Baremetal Deployment YAML
definition
.. code-block:: bash
$ openstack overcloud node extract provisioned \
--stack overcloud \
--roles-file ~/tht_roles_data.yaml \
--output ~/baremetal_deployment.yaml
deploy-guide/source/deployment/overcloud.rst
-84
View File
@@ -1,84 +0,0 @@
Containers based Overcloud Deployment
======================================
This documentation explains how to deploy a fully containerized overcloud
utilizing Podman which is the default since the Stein release.
The requirements for a containerized overcloud are the same as for any other
overcloud deployment. The real difference is in where the overcloud services
will be deployed (containers vs base OS).
Architecture
------------
The container-based overcloud architecture is not very different from the
baremetal/VM based one. The services deployed in the traditional baremetal
overcloud are also deployed in the docker-based one.
One obvious difference between these two types of deployments is that the
Openstack services are deployed as containers in a container runtime rather
than directly on the host operating system. This reduces the required packages
in the host to the bare minimum for running the container runtime and managing
the base network layer.
Manual overcloud deployment
----------------------------
This section explains how to deploy a containerized overcloud manually. For an
automated overcloud deployment, please follow the steps in the
`Using TripleO Quickstart`_ section below.
Preparing overcloud images
..........................
As part of the undercloud install, an image registry is configured on port
`8787`. This is used to increase reliability of overcloud image pulls, and
minimise overall network transfers. The undercloud registry will be populated
with images required by the overcloud deploy by generating the following
`containers-prepare-parameter.yaml` file and using that for the prepare call::
openstack tripleo container image prepare default \
--local-push-destination \
--output-env-file containers-prepare-parameter.yaml
.. note:: The file `containers-prepare-parameter.yaml` may have already been
created during :ref:`install_undercloud`. It is
encouraged to share the same `containers-prepare-parameter.yaml` file
for undercloud install and overcloud deploy.
See :ref:`prepare-environment-containers` for details on using
`containers-prepare-parameter.yaml` to control what can be done
with image preparation during overcloud deployment.
.. _overcloud-prepare-container-images:
Deploying the containerized Overcloud
-------------------------------------
A containerized overcloud deployment follows all the steps described in the
baremetal :ref:`deploy-the-overcloud` documentation with the exception that it
requires an extra environment file to be added to the ``openstack overcloud
deploy`` command::
-e ~/containers-prepare-parameter.yaml
If deploying with highly available controller nodes, include the
following extra environment file in addition to the above and in place
of the `environments/puppet-pacemaker.yaml` file::
-e /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml
Using TripleO Quickstart
------------------------
.. note:: Please refer to the `TripleO Quickstart`_ docs for more info about
quickstart, the minimum requirements, the setup process and the
available plugins.
The command below will deploy a containerized overcloud on top of a baremetal undercloud::
bash quickstart.sh --config=~/.quickstart/config/general_config/containers_minimal.yml $VIRTHOST
.. _TripleO Quickstart: https://docs.openstack.org/tripleo-quickstart/
deploy-guide/source/deployment/repositories.rst
-6
View File
@@ -1,6 +0,0 @@
:orphan:
Repository Enablement
=====================
.. include:: ../repositories.rst
deploy-guide/source/deployment/standalone.rst
-1132
View File
File diff suppressed because it is too large Load Diff
deploy-guide/source/deployment/template_deploy.rst
-85
View File
@@ -1,85 +0,0 @@
Deploying with Heat Templates
=============================
It is possible to use the ``--templates`` and ``--environment-file``
options to override specific templates or even deploy using a separate
set of templates entirely.
Deploying an Overcloud using the default templates
--------------------------------------------------
The ``--templates`` option without an argument enables deploying using
the packaged Heat templates::
openstack overcloud deploy --templates
.. note::
The default location for the templates is
`/usr/share/openstack-tripleo-heat-templates`.
.. _override-heat-templates:
Overriding specific templates with local versions
-------------------------------------------------
You may use heat environment files (via the ``--environment-file`` or ``-e``
option), combined with the ``--templates`` option to override specific
templates, e.g to test a bugfix outside of the location of the packaged
templates.
The mapping between heat resource types and the underlying templates can be
found in
`/usr/share/\
openstack-tripleo-heat-templates/overcloud-resource-registry-puppet.j2.yaml`
Here is an example of copying a specific resource template and overriding
so the deployment uses the local version::
mkdir local_templates
cp /usr/share/openstack-tripleo-heat-templates/puppet/controller-puppet.yaml local_templates
cat > override_templates.yaml << EOF
resource_registry:
OS::TripleO::Controller: local_templates/controller-puppet.yaml
EOF
openstack overcloud deploy --templates --environment-file override_templates.yaml
.. note::
The ``--environment-file``/``-e`` option may be specified multiple times,
if duplicate keys are specified in the environment files, the last one
takes precedence.
.. note::
You must also pass the environment files (again using the ``-e`` or
``--environment-file`` option) whenever you make subsequent changes to the
overcloud, such as :doc:`../post_deployment/scale_roles`,
:doc:`../post_deployment/delete_nodes` or
:doc:`../post_deployment/upgrade/minor_update`.
.. _custom-template-location:
Using a custom location for all templates
-----------------------------------------
You may specify a path to the ``--templates`` option, such that the packaged
tree may be copied to another location, which is useful e.g for developer usage
where you wish to check the templates into a revision control system.
.. note::
Use caution when using this approach as you will need to rebase any local
changes on updates to the openstack-tripleo-heat-templates package, and
care will be needed to avoid modifying anything in the tree which the CLI
tools rely on (such as top-level parameters). In many cases using the
:doc:`ExtraConfig <../features/extra_config>` interfaces or specific template overrides
as outlined above may be preferable.
Here is an example of copying the entire tripleo-heat-templates tree to a
local directory and launching a deployment using the new location::
cp -r /usr/share/openstack-tripleo-heat-templates /home/stack/
openstack overcloud deploy --templates /home/stack/openstack-tripleo-heat-templates
deploy-guide/source/deployment/tips_tricks.rst
-380
View File
@@ -1,380 +0,0 @@
Tips and Tricks for containerizing services
===========================================
This document contains a list of tips and tricks that are useful when
containerizing an OpenStack service.
Important Notes
---------------
Podman
------
Prior to Stein, containerized OpenStack deployments used Docker.
Starting with the Stein release, Docker is no longer part of OpenStack,
and Podman has taken its place. The notes here are regarding Stein and later.
Monitoring containers
---------------------
It's often useful to monitor the running containers and see what has been
executed and what not. The puppet containers are created and removed
automatically unless they fail. For all the other containers, it's enough to
monitor the output of the command below::
$ watch -n 0.5 sudo podman ps -a --filter label=managed_by=tripleo_ansible
.. admonition:: Train
:class: stable
::
$ watch -n 0.5 sudo podman ps -a --filter label=managed_by=paunch
.. _debug-containers:
Viewing container logs
----------------------
You can view the output of the main process running in a container by running::
$ sudo podman logs $CONTAINER_ID_OR_NAME
Since the Stein release, standard out and standard error from containers are
captured in `/var/log/containers/stdouts`.
We export traditional logs from containers into the `/var/log/containers`
directory on the host, where you can look at them.
systemd and podman
------------------
Throughout this document you'll find references to direct podman commands
for things like restarting services. These are valid and supported methods,
but it's worth noting that services are tied into the systemd management
system, which is often the preferred way to operate.
Restarting nova_scheduler for example::
$ sudo systemctl restart tripleo_nova_scheduler
Stopping a container with systemd::
$ sudo systemctl stop tripleo_nova_scheduler
.. _toggle_debug:
Toggle debug
------------
For services that support `reloading their configuration at runtime`_::
$ sudo podman exec -u root nova_scheduler crudini --set /etc/nova/nova.conf DEFAULT debug true
$ sudo podman kill -s SIGHUP nova_scheduler
.. _reloading their configuration at runtime: https://storyboard.openstack.org/#!/story/2001545
Restart the container to turn back the configuration to normal::
$ sudo podman restart nova_scheduler
Otherwise, if the service does not yet support reloading its configuration, it
is necessary to change the configuration on the host filesystem and restart the
container::
$ sudo crudini --set /var/lib/config-data/puppet-generated/nova/etc/nova/nova.conf DEFAULT debug true
$ sudo podman restart nova_scheduler
Apply the inverse change to restore the default log verbosity::
$ sudo crudini --set /var/lib/config-data/puppet-generated/nova/etc/nova/nova.conf DEFAULT debug false
$ sudo podman restart nova_scheduler
Debugging container failures
----------------------------
The following commands are useful for debugging containers.
* **inspect**: This command allows for inspecting the container's structure and
metadata. It provides info about the bind mounts on the container, the
container's labels, the container's command, etc::
$ sudo podman inspect $CONTAINER_ID_OR_NAME
* **top**: Viewing processes running within a container is trivial with Podman::
$ sudo podman top $CONTAINER_ID_OR_NAME
* **exec**: Running commands on or attaching to a running container is extremely
useful to get a better understanding of what's happening in the container.
It's possible to do so by running the following command::
$ sudo podman exec -ti $CONTAINER_ID_OR_NAME /bin/bash
Replace the `/bin/bash` above with other commands to run oneshot commands. For
example::
$ sudo podman exec -ti mysql mysql -u root -p $PASSWORD
The above will start a mysql shell on the mysql container.
* **export** When the container fails, it's basically impossible to know what
happened. It's possible to get the logs from docker but those will contain
things that were printed on the stdout by the entrypoint. Exporting the
filesystem structure from the container will allow for checking other logs
files that may not be in the mounted volumes::
$ sudo podman export $CONTAINER_ID_OR_NAME -o $CONTAINER_ID_OR_NAME.tar
Debugging with tripleo_container_manage Ansible role
----------------------------------------------------
The debugging manual for tripleo_container_manage is documented in the role_
directly.
.. _role: https://docs.openstack.org/tripleo-ansible/latest/roles/role-tripleo_container_manage.html#debug
Debugging with Paunch
---------------------
.. note:: During Ussuri cycle, Paunch has been replaced by the
tripleo_container_manage Ansible role. Therefore, the following block
is deprecated in favor of the new role which contains a Debug manual.
The ``paunch debug`` command allows you to perform specific actions on a given
container. This can be used to:
* Run a container with a specific configuration.
* Dump the configuration of a given container in either json or yaml.
* Output the docker command line used to start the container.
* Run a container with any configuration additions you wish such that you can
run it with a shell as any user etc.
The configuration options you will likely be interested in include:
::
--file <file> YAML or JSON file containing configuration data
--action <name> Action can be one of: "dump-json", "dump-yaml",
"print-cmd", or "run"
--container <name> Name of the container you wish to manipulate
--interactive Run container in interactive mode - modifies config
and execution of container
--shell Similar to interactive but drops you into a shell
--user <name> Start container as the specified user
--overrides <name> JSON configuration information used to override
default config values
--default-runtime Default runtime for containers. Can be docker or
podman.
``file`` is the name of the configuration file to use
containing the configuration for the container you wish to use.
TripleO creates configuration files for starting containers in
``/var/lib/tripleo-config/container-startup-config``. If you look in this directory
you will see a number of files corresponding with the steps in
TripleO heat templates. Most of the time, you will likely want to use
``/var/lib/tripleo-config/container-startup-config/step_4``
as it contains most of the final startup configurations for the running
containers.
``shell``, ``user`` and ``interactive`` are available as shortcuts that
modify the configuration to easily allow you to run an interactive session
in a given container.
To make sure you get the right container you can use the ``paunch list``
command to see what containers are running and which config id they
are using. This config id corresponds to which file you will find the
container configuration in.
TripleO uses ``managed_by`` and ``config_id`` labels to help identify the
containers it is managing. These can be checked by inspecting the labels section
like so:
::
# podman inspect nova_api | jq '.[0].Config.Labels | "managed_by=\(.managed_by) config_id=\(.config_id)"'
"managed_by=tripleo-Controller config_id=tripleo_step4"
Note that if you wish to replace a currently running container you will
want to ``sudo podman rm -f`` the running container before starting a new one.
Here is an example of using ``paunch debug`` to start a root shell inside the
heat api container:
::
# paunch debug --file /var/lib/tripleo-config/container-startup-config/step_4 --managed-by=tripleo-Controller --config-id=tripleo_step4 --interactive --shell --user root --container nova_api --action run
This will drop you into an interactive session inside the heat api container,
starting /bin/bash running as root.
To see how this container is started by TripleO:
::
# paunch debug --file /var/lib/tripleo-config/container-startup-config/step_4 --managed-by=tripleo-Controller --config-id=tripleo_step4 --container nova_api --action print-cmd
podman run --name nova_api-1jpm5kyv --label config_id=tripleo_step4 --label container_name=nova_api --label managed_by=tripleo-Controller --label config_data={"environment": {"KOLLA_CONFIG_STRATEGY": "COPY_ALWAYS", "TRIPLEO_CONFIG_HASH": "5cbcd2d39667626874f547214d3980ec"}, "healthcheck": {"test": "/openstack/healthcheck"}, "image": "undercloud-0.ctlplane.redhat.local:8787/rh-osbs/rhosp16-openstack-nova-api:16.1_20210726.1", "net": "host", "privileged": false, "restart": "always", "start_order": 2, "user": "root", "volumes": ["/etc/hosts:/etc/hosts:ro", "/etc/localtime:/etc/localtime:ro", "/etc/pki/ca-trust/extracted:/etc/pki/ca-trust/extracted:ro", "/etc/pki/ca-trust/source/anchors:/etc/pki/ca-trust/source/anchors:ro", "/etc/pki/tls/certs/ca-bundle.crt:/etc/pki/tls/certs/ca-bundle.crt:ro", "/etc/pki/tls/certs/ca-bundle.trust.crt:/etc/pki/tls/certs/ca-bundle.trust.crt:ro", "/etc/pki/tls/cert.pem:/etc/pki/tls/cert.pem:ro", "/dev/log:/dev/log", "/etc/puppet:/etc/puppet:ro", "/var/log/containers/nova:/var/log/nova:z", "/var/log/containers/httpd/nova-api:/var/log/httpd:z", "/var/lib/kolla/config_files/nova_api.json:/var/lib/kolla/config_files/config.json:ro", "/var/lib/config-data/puppet-generated/nova:/var/lib/kolla/config_files/src:ro"]} --conmon-pidfile=/var/run/nova_api-1jpm5kyv.pid --detach=true --env=KOLLA_CONFIG_STRATEGY=COPY_ALWAYS --env=TRIPLEO_CONFIG_HASH=5cbcd2d39667626874f547214d3980ec --net=host --privileged=false --user=root --volume=/etc/hosts:/etc/hosts:ro --volume=/etc/localtime:/etc/localtime:ro --volume=/etc/pki/ca-trust/extracted:/etc/pki/ca-trust/extracted:ro --volume=/etc/pki/ca-trust/source/anchors:/etc/pki/ca-trust/source/anchors:ro --volume=/etc/pki/tls/certs/ca-bundle.crt:/etc/pki/tls/certs/ca-bundle.crt:ro --volume=/etc/pki/tls/certs/ca-bundle.trust.crt:/etc/pki/tls/certs/ca-bundle.trust.crt:ro --volume=/etc/pki/tls/cert.pem:/etc/pki/tls/cert.pem:ro --volume=/dev/log:/dev/log --volume=/etc/puppet:/etc/puppet:ro --volume=/var/log/containers/nova:/var/log/nova:z --volume=/var/log/containers/httpd/nova-api:/var/log/httpd:z --volume=/var/lib/kolla/config_files/nova_api.json:/var/lib/kolla/config_files/config.json:ro --volume=/var/lib/config-data/puppet-generated/nova:/var/lib/kolla/config_files/src:ro undercloud-0.ctlplane.redhat.local:8787/rh-osbs/rhosp16-openstack-nova-api:16.1_20210726.1
You can also dump the configuration of a container to a file so you can
edit it and rerun it with different a different configuration:
::
# paunch debug --file /var/lib/tripleo-config/container-startup-config/step_4 --container nova_api --action dump-json > nova_api.json
You can then use ``nova_api.json`` as your ``--file`` argument after
editing it to your liking.
To add configuration elements on the command line you can use the
``overrides`` option. In this example I'm adding a health check to
the container:
::
# paunch debug --file nova_api.json --overrides '{"health-cmd": "/usr/bin/curl -f http://localhost:8004/v1/", "health-interval": "30s"}' --container nova_api --managed-by=tripleo-Controller --config-id=tripleo_step4 --action run
f47949a7cb205083a3adaa1530fcdd4ed7dcfa9b9afb4639468357b36786ecf0
Debugging container-puppet.py
-----------------------------
The :ref:`container-puppet.py` script manages the config file generation and
puppet tasks for each service. This also exists in the `common` directory
of tripleo-heat-templates. When writing these tasks, it's useful to be
able to run them manually instead of running them as part of the entire
stack. To do so, one can run the script as shown below::
CONFIG=/path/to/task.json /path/to/container-puppet.py
.. note:: Prior to the Train cycle, container-puppet.py was called
docker-puppet.py which was located in the `docker` directory.
The json file must follow the following form::
[
{
"config_image": ...,
"config_volume": ...,
"puppet_tags": ...,
"step_config": ...
}
]
Using a more realistic example. Given a `puppet_config` section like this::
puppet_config:
config_volume: glance_api
puppet_tags: glance_api_config,glance_api_paste_ini,glance_swift_config,glance_cache_config
step_config: {get_attr: [GlanceApiPuppetBase, role_data, step_config]}
config_image: {get_param: DockerGlanceApiConfigImage}
Would generated a json file called `/var/lib/container-puppet/container-puppet-tasks2.json` that looks like::
[
{
"config_image": "tripleomaster/centos-binary-glance-api:latest",
"config_volume": "glance_api",
"puppet_tags": "glance_api_config,glance_api_paste_ini,glance_swift_config,glance_cache_config",
"step_config": "include ::tripleo::profile::base::glance::api\n"
}
]
Setting the path to the above json file as the `CONFIG` environment
variable passed to `container-puppet.py` will create a container using
the `centos-binary-glance-api:latest` image and it and run puppet on a
catalog restricted to the given puppet `puppet_tags`.
As mentioned above, it's possible to create custom json files and call
`container-puppet.py` manually, which makes developing and debugging puppet
steps easier.
`container-puppet.py` also supports the environment variable `SHOW_DIFF`,
which causes it to print out a docker diff of the container before and
after the configuration step has occurred.
By default `container-puppet.py` runs things in parallel. This can make
it hard to see the debug output of a given container so there is a
`PROCESS_COUNT` variable that lets you override this. A typical debug
run for container-puppet might look like::
SHOW_DIFF=True PROCESS_COUNT=1 CONFIG=glance_api.json ./container-puppet.py
Testing a code fix in a container
---------------------------------
Let's assume that we need to test a code patch or an updated package in a
container. We will look at a few steps that can be taken to test a fix
in a container on an existing deployment.
For example let's update packages for the mariadb container::
(undercloud) [stack@undercloud ~]$ sudo podman images | grep mariadb
192.168.24.1:8787/tripleomaster/centos-binary-mariadb latest 035a8237c376 2 weeks ago 723.5 MB
So container image `035a8237c376` is the one we need to base our work on. Since
container images are supposed to be immutable we will base our work off of
`035a8237c376` and create a new one::
mkdir -p galera-workaround
cat > galera-workaround/Dockerfile <<EOF
FROM 192.168.24.1:8787/tripleomaster/centos-binary-mariadb:latest
USER root
RUN yum-config-manager --add-repo http://people.redhat.com/mbaldess/rpms/container-repo/pacemaker-bundle.repo && yum clean all && rm -rf /var/cache/yum
RUN yum update -y pacemaker pacemaker-remote pcs libqb resource-agents && yum clean all && rm -rf /var/cache/yum
USER mysql
EOF
To determine which user is the default one being used in a container you can run `docker run -it 035a8237c376 whoami`.
Then we build the new image and tag it with `:workaround1`::
docker build --rm -t 192.168.24.1:8787/tripleomaster/centos-binary-mariadb:workaround1 ~/galera-workaround
Then we push it in our docker registry on the undercloud::
docker push 192.168.24.1:8787/tripleomaster/centos-binary-mariadb:workaround1
At this stage we can either point THT to use
`192.168.24.1:8787/tripleomaster/centos-binary-mariadb:workaround1` as the
container image by tweaking the necessary environment files and we redeploy the overcloud.
If we only want to test a tweaked image, the following steps can be used:
First, determine if the containers are managed by pacemaker (those will typically have a `:pcmklatest` tag) or by paunch.
For the paunch-managed containers see `Debugging with Paunch`_.
For the pacemaker-managed containers you can (best done on your staging env, as it might be an invasive operation) do the following::
1. `pcs cluster cib cib.xml`
2. Edit the cib.xml with the changes around the bundle you are tweaking
3. `pcs cluster cib-push --config cib.xml`
Testing in CI
-------------
When new service containers are added, be sure to update the image names in
`container-images` in the tripleo-common repo. These service
images are pulled in and available in the local docker registry that the
containers ci job uses.
Packages versions in containers
-------------------------------
With the container CI jobs, it can be challenging to find which version of OpenStack runs in the containers.
An easy way to find out is to use the `logs/undercloud/home/zuul/overcloud_containers.yaml.txt.gz` log file and
see which tag was deployed.
For example::
container_images:
- imagename: docker.io/tripleomaster/centos-binary-ceilometer-central:ac82ea9271a4ae3860528eaf8a813da7209e62a6_28eeb6c7
push_destination: 192.168.24.1:8787
So we know the tag is `ac82ea9271a4ae3860528eaf8a813da7209e62a6_28eeb6c7`.
The tag is actually a Delorean hash. You can find out the versions
of packages by using this tag.
For example, `ac82ea9271a4ae3860528eaf8a813da7209e62a6_28eeb6c7` tag,
is in fact using this `Delorean repository`_.
.. _Delorean repository: https://trunk.rdoproject.org/centos7-master/ac/82/ac82ea9271a4ae3860528eaf8a813da7209e62a6_28eeb6c7/
deploy-guide/source/deployment/undercloud.rst
-31
View File
@@ -1,31 +0,0 @@
Containers based Undercloud Deployment
======================================
The requirements for a containerized undercloud are the same as for any other
undercloud deployment. The real difference is in where the undercloud services
will be deployed (containers vs base OS).
The undercloud architecture based on Moby_ (also Podman_ as of Stein) containers
is not very different from the baremetal/VM based one. The services deployed in
the traditional baremetal undercloud are also deployed in the containers based
one.
.. _Moby: https://mobyproject.org/
.. _Podman: https://podman.io/
One obvious difference between these two types of deployments is that the
openstack services are deployed as containers in a container runtime rather than
directly on the host operating system. This reduces the required packages in
the host to the bare minimum for running the container runtime and managing the
base network layer.
.. note:: Check the :doc:`install_undercloud` and :doc:`../post_deployment/upgrade/undercloud`
sections for deploying and upgrading a containerized undercloud.
.. note:: Check the :ref:`debug-containers` section for more tips and tricks for
debugging containers.
.. note:: Check our "Deep Dive" video_ which explain the architecture backgrounds and changes
as well as some demos and Q/A.
.. _video: https://www.youtube.com/watch?v=lv233gPynwk
deploy-guide/source/deployment/upload_single_image.rst
-14
View File
@@ -1,14 +0,0 @@
Uploading a Single Image
========================
After a new image is built, it can be uploaded using the same command as
before, with the ``--update-existing`` flag added::
openstack overcloud image upload --update-existing
Note that if the new image is a ramdisk, the Ironic nodes need to be
re-configured to use it. This can be done by re-running::
openstack overcloud node configure --all-manageable
Now the new image should be fully ready for use by new deployments.
deploy-guide/source/environments/baremetal.rst
-399
View File
@@ -1,399 +0,0 @@
Baremetal Environment
---------------------
|project| can be used in an all baremetal environment. One machine will be
used for Undercloud, the others will be used for your Overcloud.
Minimum System Requirements
^^^^^^^^^^^^^^^^^^^^^^^^^^^
To deploy a minimal TripleO cloud with |project| you need the following baremetal
machines:
* 1 Undercloud
* 1 Overcloud Controller
* 1 Overcloud Compute
For each additional Overcloud role, such as Block Storage or Object Storage,
you need an additional baremetal machine.
..
<REMOVE WHEN HA IS AVAILABLE>
For minimal **HA (high availability)** deployment you need at least 3 Overcloud
Controller machines and 2 Overcloud Compute machines.
The baremetal machines must meet the following minimum specifications:
* 8 core CPU
* 12 GB memory
* 60 GB free disk space
Larger systems are recommended for production deployments, however.
For instance, the undercloud needs a bit more capacity, especially regarding RAM (minimum of 16G is advised)
and is pretty intense for the I/O - fast disks (SSD, SAS) are strongly advised.
Please also note the undercloud needs space in order to store twice the "overcloud-full" image (one time
in its glance, one time in /var/lib subdirectories for PXE/TFTP).
TripleO is supporting only the following operating systems:
* RHEL 9 (x86_64)
* CentOS Stream 9 (x86_64)
Please also ensure your node clock is set to UTC in order to prevent any issue
when the OS hwclock syncs to the BIOS clock before applying timezone offset,
causing files to have a future-dated timestamp.
Preparing the Baremetal Environment
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Networking
^^^^^^^^^^
The overcloud nodes will be deployed from the undercloud machine and therefore the machines need to have their network settings modified to allow for the overcloud nodes to be PXE booted using the undercloud machine. As such, the setup requires that:
* All overcloud machines in the setup must support IPMI
* A management provisioning network is setup for all of the overcloud machines.
One NIC from every machine needs to be in the same broadcast domain of the
provisioning network. In the tested environment, this required setting up a new
VLAN on the switch. Note that you should use the same NIC on each of the
overcloud machines ( for example: use the second NIC on each overcloud
machine). This is because during installation we will need to refer to that NIC
using a single name across all overcloud machines e.g. em2
* The provisioning network NIC should not be the same NIC that you are using
for remote connectivity to the undercloud machine. During the undercloud
installation, a openvswitch bridge will be created for Neutron and the
provisioning NIC will be bridged to the openvswitch bridge. As such,
connectivity would be lost if the provisioning NIC was also used for remote
connectivity to the undercloud machine.
* The overcloud machines can PXE boot off the NIC that is on the private VLAN.
In the tested environment, this required disabling network booting in the BIOS
for all NICs other than the one we wanted to boot and then ensuring that the
chosen NIC is at the top of the boot order (ahead of the local hard disk drive
and CD/DVD drives).
* For each overcloud machine you have: the MAC address of the NIC that will PXE
boot on the provisioning network the IPMI information for the machine (i.e. IP
address of the IPMI NIC, IPMI username and password)
Refer to the following diagram for more information
.. image:: ../_images/TripleO_Network_Diagram_.jpg
Setting Up The Undercloud Machine
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#. Select a machine within the baremetal environment on which to install the
undercloud.
#. Install RHEL 9 x86_64 or CentOS Stream 9 x86_64 on this machine.
#. If needed, create a non-root user with sudo access to use for installing the
Undercloud::
sudo useradd stack
sudo passwd stack # specify a password
echo "stack ALL=(root) NOPASSWD:ALL" | sudo tee -a /etc/sudoers.d/stack
sudo chmod 0440 /etc/sudoers.d/stack
.. admonition:: RHEL
:class: rhel
If using RHEL, register the Undercloud for package installations/updates.
.. admonition:: RHEL Portal Registration
:class: portal
Register the host machine using Subscription Management::
sudo subscription-manager register --username="[your username]" --password="[your password]"
# Find this with `subscription-manager list --available`
sudo subscription-manager attach --pool="[pool id]"
# Verify repositories are available
sudo subscription-manager repos --list
# Enable repositories needed
sudo subscription-manager repos \
--enable=rhel-8-for-x86_64-baseos-eus-rpms \
--enable=rhel-8-for-x86_64-appstream-eus-rpms \
--enable=rhel-8-for-x86_64-highavailability-eus-rpms \
--enable=ansible-2.9-for-rhel-8-x86_64-rpms
.. admonition:: RHEL Satellite Registration
:class: satellite
To register the host machine to a Satellite, the following repos must
be synchronized on the Satellite and enabled for registered systems::
rhel-8-for-x86_64-baseos-eus-rpms
rhel-8-for-x86_64-appstream-eus-rpms
rhel-8-for-x86_64-highavailability-eus-rpms
ansible-2.9-for-rhel-8-x86_64-rpms
See the `Red Hat Satellite User Guide`_ for how to configure the system to
register with a Satellite server. It is suggested to use an activation
key that automatically enables the above repos for registered systems.
.. _Red Hat Satellite User Guide: https://access.redhat.com/documentation/en-US/Red_Hat_Satellite/
Validations
^^^^^^^^^^^
You can run the ``prep`` validations to verify the hardware. Later in
the process, the validations will be run by the undercloud processes.
Refer to the Ansible section for running directly the validations
over baremetal nodes `validations_no_undercloud`_.
Configuration Files
^^^^^^^^^^^^^^^^^^^
.. _instackenv:
instackenv.json
^^^^^^^^^^^^^^^
Create a JSON file describing your Overcloud baremetal nodes, call it
``instackenv.json`` and place in your home directory. The file should contain
a JSON object with the only field ``nodes`` containing list of node
descriptions.
Each node description should contains required fields:
* ``pm_type`` - driver for Ironic nodes, see `Ironic Hardware Types`_
for details
* ``pm_addr`` - node BMC IP address (hypervisor address in case of virtual
environment)
* ``pm_user``, ``pm_password`` - node BMC credentials
Some fields are optional if you're going to use introspection later:
* ``ports`` - list of baremetal port objects, a map specifying the following
keys: address, physical_network (optional) and local_link_connection
(optional). Optional for bare metal. Example::
"ports": [
{
"address": "52:54:00:87:c8:2f",
"physical_network": "physical-network",
"local_link_connection": {
"switch_info": "switch",
"port_id": "gi1/0/11",
"switch_id": "a6:18:66:33:cb:48"
}
}
]
* ``cpu`` - number of CPU's in system
* ``arch`` - CPU architecture (common values are ``i386`` and ``x86_64``)
* ``memory`` - memory size in MiB
* ``disk`` - hard driver size in GiB
It is also possible (but optional) to set Ironic node capabilities directly
in the JSON file. This can be useful for assigning node profiles or setting
boot options at registration time:
* ``capabilities`` - Ironic node capabilities. For example::
"capabilities": "profile:compute,boot_option:local"
There are also two additional and optional fields that can be used to help a
user identifying machines inside ``instackenv.json`` file:
* ``name`` - name associated to the node, it will appear in the ``Name``
column while listing nodes
* ``_comment`` to associate a comment to the node (like position, long
description and so on). Note that this field will not be considered by
Ironic during the import
Also if you're working in a diverse environment with multiple architectures
and/or platforms within an architecture you may find it necessary to include a
platform field:
* ``platform`` - String paired with images to fine tune image selection
For example::
{
"nodes": [
{
"name": "node-a",
"pm_type": "ipmi",
"ports": [
{
"address": "fa:16:3e:2a:0e:36",
"physical_network": "ctlplane"
}
],
"cpu": "2",
"memory": "4096",
"disk": "40",
"arch": "x86_64",
"pm_user": "admin",
"pm_password": "password",
"pm_addr": "10.0.0.8",
"_comment": "Room 1 - Rack A - Unit 22/24"
},
{
"name": "node-b",
"pm_type": "ipmi",
"ports": [
{
"address": "fa:16:3e:da:39:c9",
"physical_network": "ctlplane"
}
],
"cpu": "2",
"memory": "4096",
"disk": "40",
"arch": "x86_64",
"pm_user": "admin",
"pm_password": "password",
"pm_addr": "10.0.0.15",
"_comment": "Room 1 - Rack A - Unit 26/28"
},
{
"name": "node-n",
"pm_type": "ipmi",
"ports": [
{
"address": "fa:16:3e:51:9b:68",
"physical_network": "leaf1"
}
],
"cpu": "2",
"memory": "4096",
"disk": "40",
"arch": "x86_64",
"pm_user": "admin",
"pm_password": "password",
"pm_addr": "10.0.0.16",
"_comment": "Room 1 - Rack B - Unit 10/12"
}
]
}
.. note::
You don't need to create this file, if you plan on using
:doc:`../provisioning/node_discovery`.
Ironic Hardware Types
^^^^^^^^^^^^^^^^^^^^^
Ironic *hardware types* provide various level of support for different
hardware. Hardware types, introduced in the Ocata cycle, are a new generation
of Ironic *drivers*. Previously, the word *drivers* was used to refer to what
is now called *classic drivers*. See `Ironic drivers documentation`_ for a full
explanation of similarities and differences between the two types.
Hardware types are enabled in the ``undercloud.conf`` using the
``enabled_hardware_types`` configuration option. Classic drivers are enabled
using the ``enabled_drivers`` option. It has been deprecated since the Queens
release and should no longer be used. See the `hardware types migration guide`_
for information on how to migrate existing nodes.
Both hardware types and classic drivers can be equally used in the
``pm_addr`` field of the ``instackenv.json``.
See https://docs.openstack.org/ironic/latest/admin/drivers.html for the most
up-to-date information about Ironic hardware types and hardware
interfaces, but note that this page always targets Ironic git master, not the
release we use.
Generic Hardware Types
~~~~~~~~~~~~~~~~~~~~~~~
* This most generic hardware type is ipmi_. It uses the `ipmitool`_ utility
to manage a bare metal node, and supports a vast variety of hardware.
.. admonition:: Stable Branch
:class: stable
This hardware type is supported starting with the Pike release. For older
releases use the functionally equivalent ``pxe_ipmitool`` driver.
.. admonition:: Virtual
:class: virtual
This hardware type can be used for developing and testing TripleO in a
:doc:`virtual` as well.
* Another generic hardware type is redfish_. It provides support for the
quite new `Redfish standard`_, which aims to replace IPMI eventually as
a generic protocol for managing hardware. In addition to the ``pm_*`` fields
mentioned above, this hardware type also requires setting ``pm_system_id``
to the full identifier of the node in the controller (e.g.
``/redfish/v1/Systems/42``).
.. admonition:: Stable Branch
:class: stable
Redfish support was introduced in the Pike release.
The following generic hardware types are not enabled by default:
* The snmp_ hardware type supports controlling PDUs for power management.
It requires boot device to be manually configured on the nodes.
* Finally, the ``manual-management`` hardware type (not enabled by default)
skips power and boot device management completely. It requires manual power
and boot operations to be done at the right moments, so it's not recommended
for a generic production.
.. admonition:: Stable Branch
:class: stable
The functional analog of this hardware type before the Queens release
was the ``fake_pxe`` driver.
Vendor Hardware Types
~~~~~~~~~~~~~~~~~~~~~
TripleO also supports vendor-specific hardware types for some types
of hardware:
* ilo_ targets HPE Proliant Gen 8 and Gen 9 systems.
.. admonition:: Stable Branch
:class: stable
Use the ``pxe_ilo`` classic driver before the Queens release.
* idrac_ targets DELL 12G and newer systems.
.. admonition:: Stable Branch
:class: stable
Use the ``pxe_drac`` classic driver before the Queens release.
The following hardware types are supported but not enabled by default:
* irmc_ targets FUJITSU PRIMERGY servers.
* cisco-ucs-managed_ targets UCS Manager managed Cisco UCS B/C series servers.
* cisco-ucs-standalone_ targets standalone Cisco UCS C series servers.
.. note::
Contact a specific vendor team if you have problems with any of these
drivers, as the TripleO team often cannot assist with them.
.. _Ironic drivers documentation: https://docs.openstack.org/ironic/latest/install/enabling-drivers.html
.. _hardware types migration guide: https://docs.openstack.org/ironic/latest/admin/upgrade-to-hardware-types.html
.. _ipmitool: http://sourceforge.net/projects/ipmitool/
.. _Redfish standard: https://www.dmtf.org/standards/redfish
.. _ipmi: https://docs.openstack.org/ironic/latest/admin/drivers/ipmitool.html
.. _redfish: https://docs.openstack.org/ironic/latest/admin/drivers/redfish.html
.. _snmp: https://docs.openstack.org/ironic/latest/admin/drivers/snmp.html
.. _ilo: https://docs.openstack.org/ironic/latest/admin/drivers/ilo.html
.. _idrac: https://docs.openstack.org/ironic/latest/admin/drivers/idrac.html
.. _irmc: https://docs.openstack.org/ironic/latest/admin/drivers/irmc.html
.. _cisco-ucs-managed: https://docs.openstack.org/ironic/latest/admin/drivers/ucs.html
.. _cisco-ucs-standalone: https://docs.openstack.org/ironic/latest/admin/drivers/cimc.html
.. _validations_no_undercloud: ../../validations/ansible.html
deploy-guide/source/environments/index.rst
-12
View File
@@ -1,12 +0,0 @@
Environment Setup
=================
|project| can be used in baremetal as well as in virtual environments. This
section contains instructions on how to setup your environments properly.
.. toctree::
:maxdepth: 2
standalone
virtual
baremetal
deploy-guide/source/environments/standalone.rst
-12
View File
@@ -1,12 +0,0 @@
Standalone Environment
----------------------
.. include_after_header
|project| can be used as a standalone environment with all services installed
on a single virtual or baremetal machine.
The machine you are deploying on must meet the following minimum specifications:
* 4 core CPU
* 8 GB memory
* 60 GB free disk space
deploy-guide/source/environments/virtual.rst
-14
View File
@@ -1,14 +0,0 @@
Virtual Environment
-------------------
|project| can be used in a virtual environment using virtual machines instead
of actual baremetal. However, one baremetal machine is still
needed to act as the host for the virtual machines.
.. warning:: Virtual deployments with TripleO are for development and testing
purposes only. This method cannot be used for production-ready
deployments.
The tripleo-quickstart project is used for creating virtual environments
for use with TripleO. Please see that documentation at
https://docs.openstack.org/tripleo-quickstart/
deploy-guide/source/features/api_policies.rst
-28
View File
@@ -1,28 +0,0 @@
Configuring API access policies
===============================
Each OpenStack service, has its own role-based access policies.
They determine which user can access which resources in which way,
and are defined in the service’s policy.json file.
.. Warning::
While editing policy.json is supported, modifying the policy can
have unexpected side effects and is not encouraged.
|project| supports custom API access policies through parameters in
TripleO Heat Templates.
To enable this feature, you need to use some parameters to enable
the custom policies on the services you want.
Creating an environment file and adding the following arguments to your
``openstack overcloud deploy`` command will do the trick::
$ cat ~/nova-policies.yaml
parameter_defaults:
NovaApiPolicies: { nova-context_is_admin: { key: 'compute:get_all', value: '' } }
-e nova-policies.yaml
In this example, we allow anyone to list Nova instances, which is very insecure but
can be done with this feature.
deploy-guide/source/features/backends.rst
-16
View File
@@ -1,16 +0,0 @@
Backend Configuration
=====================
Documentation on how to enable and configure various backends available for
OpenStack projects.
.. toctree::
deploy_manila
cinder_custom_backend
cinder_netapp
deployed_ceph
ceph_external
domain_specific_ldap_backends
swift_external
deploy-guide/source/features/baremetal_overcloud.rst
-1169
View File
File diff suppressed because it is too large Load Diff
deploy-guide/source/features/ceph_external.rst
-394
View File
@@ -1,394 +0,0 @@
Use an external Ceph cluster with the Overcloud
===============================================
|project| supports use of an external Ceph cluster for certain services deployed
in the Overcloud.
Deploying Cinder, Glance, Nova, Gnocchi with an external Ceph RBD service
-------------------------------------------------------------------------
The overcloud may be configured to use an external Ceph RBD service by
enabling a particular environment file when deploying the
Overcloud. For Wallaby and newer include
`environments/external-ceph.yaml`.
For Ocata and earlier use
`environments/puppet-ceph-external.yaml`. For Pike through Victoria
use `environments/ceph-ansible/ceph-ansible-external.yaml` and install
ceph-ansible on the Undercloud as described in
:doc:`../deployment/index`. For Pike through Victoria a Ceph container
is downloaded and executed on Overcloud nodes to use Ceph binaries
only available within the container. These binaries are used to create
the CephX client keyrings on the overcloud. Thus, between Pike and
Victoria it was necessary when preparing to deploy a containerized
overcloud, as described in
:doc:`../deployment/container_image_prepare`, to include the Ceph
container even if that overcloud will only connect to an external Ceph
cluster. Starting in Wallaby neither ceph-ansible or cephadm configure
Ceph clients and instead the tripleo-ansible role tripleo_ceph_client
is used. Thus, it is not necessary to install ceph-ansible nor prepare
a Ceph container when configuring external Ceph in Wallaby and
newer. Simply include `environments/external-ceph.yaml` in the
deployment. All parameters described below remain consistent
regardless of external Ceph configuration method.
Some of the parameters in the above environment files can be overridden::
parameter_defaults:
# Enable use of RBD backend in nova-compute
NovaEnableRbdBackend: true
# Enable use of RBD backend in cinder-volume
CinderEnableRbdBackend: true
# Backend to use for cinder-backup
CinderBackupBackend: ceph
# Backend to use for glance
GlanceBackend: rbd
# Backend to use for gnocchi-metricsd
GnocchiBackend: rbd
# Name of the Ceph pool hosting Nova ephemeral images
NovaRbdPoolName: vms
# Name of the Ceph pool hosting Cinder volumes
CinderRbdPoolName: volumes
# Name of the Ceph pool hosting Cinder backups
CinderBackupRbdPoolName: backups
# Name of the Ceph pool hosting Glance images
GlanceRbdPoolName: images
# Name of the Ceph pool hosting Gnocchi metrics
GnocchiRbdPoolName: metrics
# Name of the user to authenticate with the external Ceph cluster
CephClientUserName: openstack
The pools and the CephX user **must** be created on the external Ceph cluster
before deploying the Overcloud. TripleO expects a single user, configured via
CephClientUserName, to have the capabilities to use all the OpenStack pools;
the user could be created with a command like this::
ceph auth add client.openstack mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=volumes, allow rwx pool=vms, allow rwx pool=images, allow rwx pool=backups, allow rwx pool=metrics'
In addition to the above customizations, the deployer **needs** to provide
at least three required parameters related to the external Ceph cluster::
parameter_defaults:
# The cluster FSID
CephClusterFSID: '4b5c8c0a-ff60-454b-a1b4-9747aa737d19'
# The CephX user auth key
CephClientKey: 'AQDLOh1VgEp6FRAAFzT7Zw+Y9V6JJExQAsRnRQ=='
# The list of Ceph monitors
CephExternalMonHost: '172.16.1.7, 172.16.1.8, 172.16.1.9'
The above parameters will result in TripleO creating a Ceph
configuration file and cephx keyring in /etc/ceph on every
node which needs to connect to Ceph to use the RBD service.
Configuring Ceph Clients for Multiple External Ceph RBD Services
----------------------------------------------------------------
In Train and newer it's possible to use TripleO to deploy an
overcloud which is capable of using the RBD services of multiple
external Ceph clusters. A separate keyring and Ceph configuration file
is created for each external Ceph cluster in /etc/ceph on every
overcloud node which needs to connect to Ceph. This functionality is
provided by the `CephExternalMultiConfig` parameter.
Do not use `CephExternalMultiConfig` when configuring an overcloud to
use only one external Ceph cluster. Instead follow the example in the
previous section. The example in the previous section and the method
of deploying an internal Ceph cluster documented in
:doc:`deployed_ceph` are mutually exclusive per Heat stack. The
following scenarios are the only supported ones in which
`CephExternalMultiConfig` may be used per Heat stack:
* One external Ceph cluster configured, as described in previous
section, in addition to multiple external Ceph clusters configured
via `CephExternalMultiConfig`.
* One internal Ceph cluster, as described in :doc:`deployed_ceph` in
addition to multiple external ceph clusters configured via
`CephExternalMultiConfig`.
The `CephExternalMultiConfig` parameter is used like this::
CephExternalMultiConfig:
- cluster: 'ceph2'
fsid: 'af25554b-42f6-4d2b-9b9b-d08a1132d3e8'
external_cluster_mon_ips: '172.18.0.5,172.18.0.6,172.18.0.7'
keys:
- name: "client.openstack"
caps:
mgr: "allow *"
mon: "profile rbd"
osd: "profile rbd pool=volumes, profile rbd pool=backups, profile rbd pool=vms, profile rbd pool=images"
key: "AQCwmeRcAAAAABAA6SQU/bGqFjlfLro5KxrB1Q=="
mode: "0600"
dashboard_enabled: false
- cluster: 'ceph3'
fsid: 'e2cba068-5f14-4b0f-b047-acf375c0004a'
external_cluster_mon_ips: '172.18.0.8,172.18.0.9,172.18.0.10'
keys:
- name: "client.openstack"
caps:
mgr: "allow *"
mon: "profile rbd"
osd: "profile rbd pool=volumes, profile rbd pool=backups, profile rbd pool=vms, profile rbd pool=images"
key: "AQCwmeRcAAAAABAA6SQU/bGqFjlfLro5KxrB2Q=="
mode: "0600"
dashboard_enabled: false
The above, in addition to the parameters from the previous section,
will result in an overcloud with the following files in /etc/ceph:
* ceph.client.openstack.keyring
* ceph.conf
* ceph2.client.openstack.keyring
* ceph2.conf
* ceph3.client.openstack.keyring
* ceph3.conf
The first two files which start with `ceph` will be created based on
the parameters discussed in the previous section. The next two files
which start with `ceph2` will be created based on the parameters from
the first list item within the `CephExternalMultiConfig` parameter
(e.g. `cluster: ceph2`). The last two files which start with `ceph3`
will be created based on the parameters from the last list item within
the `CephExternalMultiConfig` parameter (e.g. `cluster: ceph3`).
The last four files in the list which start with `ceph2` or `ceph3`
will also contain parameters found in the first two files which
start with `ceph` except where those parameters intersect. When
there's an intersection those parameters will be overridden with the
values from the `CephExternalMultiConfig` parameter. For example there
will only be one FSID in each Ceph configuration file with the
following values per file:
* ceph.conf will have `fsid = 4b5c8c0a-ff60-454b-a1b4-9747aa737d19`
(as seen in the previous section)
* ceph2.conf will have `fsid = af25554b-42f6-4d2b-9b9b-d08a1132d3e8`
* ceph3.conf will have `fsid = e2cba068-5f14-4b0f-b047-acf375c0004a`
However, if the `external_cluster_mon_ips` key was not set within
the `CephExternalMultiConfig` parameter, then all three Ceph
configuration files would contain `mon host = 172.16.1.7, 172.16.1.8,
172.16.1.9`, as seen in the previous section. Thus, it is necessary to
override the `external_cluster_mon_ips` key within each list item of
the `CephExternalMultiConfig` parameter because each external Ceph
cluster will have its own set of unique monitor IPs.
The `CephExternalMultiConfig` and `external_cluster_mon_ips` keys map
one to one but have different names because each element of the
`CephExternalMultiConfig` list should contain a map of keys and values
directly supported by ceph-ansible. See `ceph-ansible/group_vars`_ for
an example of all possible keys.
The following parameters are the minimum necessary to configure an
overcloud to connect to an external ceph cluster:
* cluster: The name of the configuration file and key name prefix.
This name defaults to "ceph" so if this parameter is not overridden
there will be a name collision. It is not relevant if the
external ceph cluster's name is already "ceph". For client role
configuration this parameter is only used for setting a unique name
for the configuration and key files.
* fsid: The FSID of the external ceph cluster.
* external_cluster_mon_ips: The list of monitor IPs of the external
ceph cluster as a single string where each IP is comma delimited.
If the external Ceph cluster is using both the v1 and v2 MSGR
protocol this value may look like '[v2:10.0.0.1:3300,
v1:10.0.0.1:6789], [v2:10.0.0.2:3300, v1:10.0.0.2:6789],
[v2:10.0.0.3:3300, v1:10.0.0.3:6789]'.
* dashboard_enabled: Always set this value to false when using
`CephExternalMultiConfig`. It ensures that the Ceph Dashboard is not
installed. It is not supported to use ceph-ansible dashboard roles
to communicate with an external Ceph cluster so not passing this
parameter with a value of false within `CephExternalMultiConfig`
will result in a failed deployment because the default value of true
will be used.
* keys: This is a list of maps where each map defines CephX keys which
OpenStack clients will use to connect to an external Ceph cluster.
As stated in the previous section, the pools and the CephX user must
be created on the external Ceph cluster before deploying the
overcloud. The format of each map is the same as found in
ceph-ansible. Thus, if the external Ceph cluster was deployed by
ceph-ansible, then the deployer of that cluster could share that map
with the TripleO deployer so that it could be used as a list item of
`CephExternalMultiConfig`. Similarly, the `CephExtraKeys` parameter,
described in the :doc:`deployed_ceph` documentation, has the same
syntax.
Deploying Manila with an External CephFS Service
------------------------------------------------
If choosing to configure Manila with Ganesha as NFS gateway for CephFS,
with an external Ceph cluster, then add `environments/manila-cephfsganesha-config.yaml`
to the list of environment files used to deploy the overcloud and also
configure the following parameters::
parameter_defaults:
ManilaCephFSDataPoolName: manila_data
ManilaCephFSMetadataPoolName: manila_metadata
ManilaCephFSCephFSAuthId: 'manila'
CephManilaClientKey: 'AQDLOh1VgEp6FRAAFzT7Zw+Y9V6JJExQAsRnRQ=='
Which represent the data and metadata pools in use by the MDS for
the CephFS filesystems, the CephX keyring to use and its secret.
Like for the other services, the pools and keyring must be created on the
external Ceph cluster before attempting the deployment of the overcloud.
The keyring should look like the following::
ceph auth add client.manila mgr "allow *" mon "allow r, allow command 'auth del', allow command 'auth caps', allow command 'auth get', allow command 'auth get-or-create'" mds "allow *" osd "allow rw"
Compatibility Options
---------------------
As of the Train release TripleO will install Ceph Nautilus. If the
external Ceph cluster uses the Hammer release instead, pass the
following parameters to enable backward compatibility features::
parameter_defaults:
ExtraConfig:
ceph::profile::params::rbd_default_features: '1'
Deployment of an Overcloud with External Ceph
---------------------------------------------
Finally add the above environment files to the deploy commandline. For
Wallaby and newer use::
openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/external-ceph.yaml -e ~/my-additional-ceph-settings.yaml
For Train use::
openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible-external.yaml -e ~/my-additional-ceph-settings.yaml
Standalone Ansible Roles for External Ceph
------------------------------------------
To configure an overcloud to use an external Ceph cluster, a directory
(e.g. /etc/ceph) in the overcloud containers should be populated with
Ceph configuration files and overcloud services (e.g. Nova) should be
configured to use those files. Tripleo provides Ansible roles to do
this standalone without tripleo-heat-templates or config-download.
Single Ceph Cluster
^^^^^^^^^^^^^^^^^^^
The `tripleo_ceph_client_files` Ansible role copies files from a
source directory (`tripleo_ceph_client_files_source`) on the host
where Ansible is run to a destination directory
(`tripleo_ceph_client_config_home`) on the overcloud nodes.
The user must create and populate the
`tripleo_ceph_client_files_source` directory with actual Ceph
configuration and cephx key files before running the role. For
example::
$ ls -l /home/stack/ceph_files/
total 16
-rw-r--r--. 1 stack stack 245 Nov 14 13:40 ceph.client.openstack.keyring
-rw-r--r--. 1 stack stack 173 Nov 14 13:40 ceph.conf
If the above directory exists on the host where the `ansible-playbook`
command is run, then the `tripleo_ceph_client_files_source` parameter
should be set to `/home/stack/ceph_files/`. The optional parameter
`tripleo_ceph_client_config_home` defaults to
`/var/lib/tripleo-config/ceph` since OpenStack containers will bind
mount this directory to `/etc/ceph`. The `tripleo_nova_libvirt`
Ansible role will add a secret key to libvirt so that it uses the
cephx key put in place by the `tripleo_ceph_client_files` role; it
does this if either `tripleo_nova_libvirt_enable_rbd_backend` or
`tripleo_cinder_enable_rbd_backend` are true. When these roles
are used to configure a compute node the following `group_vars` should
be set::
tripleo_ceph_client_files_source: /home/stack/ceph_files
tripleo_ceph_client_config_home: /var/lib/tripleo-config/ceph
tripleo_nova_libvirt_enable_rbd_backend: true
tripleo_cinder_enable_rbd_backend: true
The `tripleo_ceph_client_files` role may then be included in a
playbook as follows in order to configure a standalone compute node to
use a single Ceph cluster::
- name: configure ceph client
import_role:
name: tripleo_ceph_client_files
In order for Nova to use the Ceph cluster, the `libvirt` section of
the `nova.conf` file should be configured. The `tripleo_nova_compute`
role `tripleo_nova_compute_config_overrides` variable may be set as
follows in the inventory to set the `libvirt` values along with
others::
Compute:
vars:
tripleo_nova_compute_config_overrides:
libvirt:
images_rbd_ceph_conf: /etc/ceph/ceph.conf
images_rbd_glance_copy_poll_interval: '15'
images_rbd_glance_copy_timeout: '600'
images_rbd_glance_store_name: default_backend
images_rbd_pool: vms
images_type: rbd
rbd_secret_uuid: 604c9994-1d82-11ed-8ae5-5254003d6107
rbd_user: openstack
TripleO's convention is to set the `rbd_secret_uuid` to the FSID of
the Ceph cluster. The FSID should be in the ceph.conf file. The
`tripleo_nova_libvirt` role will use `virsh secret-*` commands so that
libvirt can retrieve the cephx secret using the FSID as a key. This
can be confirmed after running Ansible with `podman exec
nova_virtsecretd virsh secret-get-value $FSID`.
The `tripleo_ceph_client_files` role only supports the _configure_
aspect of the standalone tripleo-ansible roles because it just
configures one or more pairs of files on its target nodes. Thus, the
`import_role` example above could be placed in a playbook file like
`deploy-tripleo-openstack-configure.yml`, before the roles for
`tripleo_nova_libvirt` and `tripleo_nova_compute` are imported.
Multiple Ceph Clusters
^^^^^^^^^^^^^^^^^^^^^^
To configure more than one Ceph backend include the
`tripleo_ceph_client_files` role from the single cluster example
above. Populate the `tripleo_ceph_client_files_source` directory with
all of the ceph configuration and cephx key files For example::
$ ls -l /home/stack/ceph_files/
total 16
-rw-r--r--. 1 stack stack 213 Nov 14 13:41 ceph2.client.openstack.keyring
-rw-r--r--. 1 stack stack 228 Nov 14 13:41 ceph2.conf
-rw-r--r--. 1 stack stack 245 Nov 14 13:40 ceph.client.openstack.keyring
-rw-r--r--. 1 stack stack 173 Nov 14 13:40 ceph.conf
For multiple Ceph clusters, the `tripleo_nova_libvirt` role expects a
`tripleo_cinder_rbd_multi_config` Ansible variable like this::
tripleo_cinder_rbd_multi_config:
ceph2:
CephClusterName: ceph2
CephClientUserName: openstack
It is not necessary to put the default Ceph cluster (named "ceph" from
the single node example) in `tripleo_cinder_rbd_multi_config`. Only
the additional clusters (e.g. ceph2) and name their keys so they
match the `CephClusterName`. In the above example, the
`CephClusterName` value "ceph2" matches the "ceph2.conf" and
"ceph2.client.openstack.keyring". Also, the `CephClientUserName` value
"openstack" matches "ceph2.client.openstack.keyring". The
`tripleo_nova_libvirt` Ansible role uses the
`tripleo_cinder_rbd_multi_config` map as a guide to know which libvirt
secrets to create and which cephx keys to make available within the
Nova containers.
If the combined examples above from the single cluster section for
the primary cluster "ceph" and this section for the seconary Ceph
cluster "ceph2" are used, then the directory defined by
`tripleo_ceph_client_config_home` will be populated with four files:
`ceph.conf`, `ceph2.conf`, `ceph.client.openstack.keyring` and
`ceph2.client.openstack.keyring`, which will be mounted into the Nova
containers and two libvirt secrets will be created for each cephx
key. To add more Ceph clusters, extend the list
`tripleo_cinder_rbd_multi_config` and populate
`tripleo_ceph_client_files_source` with additional files.
.. _`ceph-ansible/group_vars`: https://github.com/ceph/ceph-ansible/tree/master/group_vars
deploy-guide/source/features/cinder_custom_backend.rst
-69
View File
@@ -1,69 +0,0 @@
Configuring Cinder with a Custom Unmanaged Backend
==================================================
This guide assumes that your undercloud is already installed and ready to
deploy an overcloud.
Adding a custom backend to Cinder
---------------------------------
It is possible to provide the config settings to add an arbitrary and
unmanaged backend to Cinder at deployment time via Heat environment files.
Each backend is represented in `cinder.conf` with a ``stanza`` and a
reference to it from the `enabled_backends` key. The keys valid in the
backend ``stanza`` are dependent on the actual backend driver and
unknown to Cinder.
For example, to provision in Cinder two additional backends one could
create a Heat environment file with the following contents::
parameter_defaults:
ExtraConfig:
cinder::config::cinder_config:
netapp1/volume_driver:
value: cinder.volume.drivers.netapp.common.NetAppDriver
netapp1/netapp_storage_family:
value: ontap_7mode
netapp1/netapp_storage_protocol:
value: iscsi
netapp1/netapp_server_hostname:
value: 1.1.1.1
netapp1/netapp_server_port:
value: 80
netapp1/netapp_login:
value: root
netapp1/netapp_password:
value: 123456
netapp1/volume_backend_name:
value: netapp_1
netapp2/volume_driver:
value: cinder.volume.drivers.netapp.common.NetAppDriver
netapp2/netapp_storage_family:
value: ontap_7mode
netapp2/netapp_storage_protocol:
value: iscsi
netapp2/netapp_server_hostname:
value: 2.2.2.2
netapp2/netapp_server_port:
value: 80
netapp2/netapp_login:
value: root
netapp2/netapp_password:
value: 123456
netapp2/volume_backend_name:
value: netapp_2
cinder_user_enabled_backends: ['netapp1','netapp2']
This will not interfere with the deployment of the other backends managed by
TripleO, like Ceph or NFS and will just add these two to the list of the
backends enabled in Cinder.
Remember to add such an environment file to the deploy commandline::
openstack overcloud deploy [other overcloud deploy options] -e ~/my-backends.yaml
.. note::
The :doc:`extra_config` doc has more details on the usage of the different
ExtraConfig interfaces.
deploy-guide/source/features/cinder_netapp.rst
-60
View File
@@ -1,60 +0,0 @@
Configuring Cinder with a NetApp Backend
========================================
This guide assumes that your undercloud is already installed and ready to
deploy an overcloud.
Deploying the Overcloud
-----------------------
.. note::
The :doc:`../deployment/template_deploy` doc has a more detailed explanation of the
following steps.
#. Copy the NetApp configuration file to your home directory::
sudo cp /usr/share/openstack-tripleo-heat-templates/environments/cinder-netapp-config.yaml ~
#. Edit the permissions (user is typically ``stack``)::
sudo chown $USER ~/cinder-netapp-config.yaml
sudo chmod 755 ~/cinder-netapp-config.yaml
#. Edit the parameters in this file to fit your requirements. Ensure that the following line is changed::
OS::TripleO::ControllerExtraConfigPre: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/pre_deploy/controller/cinder-netapp.yaml
#. Continue following the TripleO instructions for deploying an overcloud.
Before entering the command to deploy the overcloud, add the environment
file that you just configured as an argument::
openstack overcloud deploy --templates -e ~/cinder-netapp-config.yaml
#. Wait for the completion of the overcloud deployment process.
Creating a NetApp Volume
------------------------
.. note::
The following steps will refer to running commands as an admin user or a
tenant user. Sourcing the ``overcloudrc`` file will authenticate you as
the admin user. You can then create a tenant user and use environment
files to switch between them.
#. Create a new volume type that maps to the new NetApp backend [admin]::
cinder type-create [name]
cinder type-key [name] set volume_backend_name=tripleo_netapp
#. Create the volume [admin]::
cinder create --volume-type [type name] [size of volume]
#. Attach the volume to a server::
nova volume-attach <server> <volume> <device>
deploy-guide/source/features/composable_services.rst
-58
View File
@@ -1,58 +0,0 @@
.. _composable_services:
Deploying with Composable Services
==================================
TripleO offers the option of deploying with a user-defined list of services
per role (where "role" means group of nodes, e.g "Controller", and "service"
refers to the individual services or configurations e.g "Nova API").
Deploying with custom service lists
-----------------------------------
Each role to be used in the deployment is defined in a `roles_data.yaml` file.
There is a sample file in `/usr/share/openstack-tripleo-heat-templates`, or the
tripleo-heat-templates_ git repository. Additional example roles are located in
the `/usr/share/openstack-tripleo-heat-templates/roles` directory and can be used
to create a custom `roles_data.yaml` file. See :doc:`custom_roles` for additional
usage details.
The data in `roles_data.yaml` is used to set the defaults for per-role parameters
e.g `ControllerServices`. These defaults can be overridden via environment
files, e.g::
cat > keystone_only_params.yaml << EOF
parameter_defaults:
ControllerServices:
- OS::TripleO::Services::Keystone
- OS::TripleO::Services::RabbitMQ
- OS::TripleO::Services::HAproxy
- OS::TripleO::Services::MySQL
- OS::TripleO::Services::Keepalived
ComputeCount: 0
EOF
The example above overrides the default list of services, and instead deploys
Keystone and the services it requires. It also sets the ComputeCount to zero
to enable a minimal "keystone only" deployment on a single node.
You can then pass the environment file on deployment as follows::
openstack overcloud deploy -e keystone_only_params.yaml
The same approach can be used for any role.
.. warning::
While considerable flexibility is available regarding service placement with
these interfaces, the flexible placement of pacemaker managed services is only
available since the Ocata release.
.. warning::
In general moving control-plane services to the Compute role is not
recommended, as the compute nodes require a different upgrade lifecycle
and thus control-plane services on this role may present problems during
major upgrades between releases.
.. _tripleo-heat-templates: https://opendev.org/openstack/tripleo-heat-templates
deploy-guide/source/features/compute_nvdimm.rst
-83
View File
@@ -1,83 +0,0 @@
Manage Virtual Persistent Memory (vPMEM)
=====================================================
Virtual Persistent Memory (vPMEM) is a Nova feature that allows to expose
Persistent Memory (PMEM) namespaces to guests using libvirt compute driver.
This guide show how the vPMEM feature is supported in TripleO deployment
framework. For in-depth description of Nova's vPMEM feature check Nova
documentation: `Attaching virtual persistent memory to guests
<https://docs.openstack.org/nova/latest/admin/virtual-persistent-memory.html>`_
.. warning::
vPMEM feature is only available in Train(20.0.0) or later releases.
.. contents::
:depth: 3
:backlinks: none
Prerequisite
------------
Operators needs to properly configured PMEM Hardware before deploying Overcloud
with vPMEM support. Example of such a hardware is Intel Optane DC Persistent Memory.
Intel provides tool (`ipmctl <https://software.intel.com/en-us/articles/quick-start-guide-configure-intel-optane-dc-persistent-memory-on-linux>`_)
to configure the PMEM hardware.
Operators need to configure the hardware in such a way to enable TripleO to create
`PMEM namespaces <http://pmem.io/ndctl/ndctl-create-namespace.html>`_ in **devdax** mode.
TripleO currently support one backend NVDIMM region, so in case of multiple NVDIMMs
Interleaved Region needs to be configured.
TripleO vPMEM parameters
------------------------
Following parameter are used within TripleO to configure vPMEM:
.. code::