openstack/instack-undercloud
Code Issues Proposed changes

Merge "Remove docs from instack-undercloud"

Browse Source
This commit is contained in:
Jenkins 2015-09-13 01:55:37 +00:00 committed by Gerrit Code Review
commit 6c96d84d1e
60 changed files with 3 additions and 11625 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
README.md
View File

@ -1,9 +1,7 @@
Undercloud Install via instack
==============================
instack-undercloud documentation:
https://repos.fedorapeople.org/repos/openstack-m/instack-undercloud/html/
instack-undercloud is tooling for installing a TripleO undercloud.
To build the docs locally:
tox -e docs
It is part of the TripleO project:
http://docs.openstack.org/developer/tripleo-docs/index.html

58
doc/source/_custom/admonition_selector.js
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 if (($.cookie($(this).attr("id")) == "false")) {
$(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();
}
});
}

117
doc/source/_custom/cookies.js
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);
};
}));

226
doc/source/_custom/custom.css
View File

@ -1,226 +0,0 @@
@import url("css/theme.css");
@import url("rdo_styling.css");
/* CUSTOM CSS OVERRIDES GO HERE */
/* ============================ */
/* LAYOUT */
.wy-nav-side {
overflow: visible;
}
.wy-side-nav-search {
margin-bottom: 0;
}
.wy-nav-content-wrap {
background: white;
}
.wy-nav-content {
max-width: 100%;
box-sizing: border-box;
}
.rst-content .section ol li p.first:last-child {
margin-bottom: 24px;
}
/* LOGO */
.wy-side-nav-search a {
margin-bottom: 5px;
}
.wy-side-nav-search img {
background: none;
border-radius: 0;
height: 60px;
width: auto;
margin: 0;
}
/* TYPOGRAPHY */
p {
margin-bottom: 16px;
}
p + ul, p + ol.simple {
margin-top: -12px;
}
h1, h2, h3, h4, h5, h6, p.rubric {
margin-top: 48px;
}
h2 {
border-bottom: 1px solid rgba(0, 0, 0, 0.2);
}
/* BREADCRUMBS */
.wy-breadcrumbs {
font-size: 85%;
color: rgba(0, 0, 0, 0.45);
}
.wy-breadcrumbs a {
text-decoration: underline;
color: inherit;
}
.wy-breadcrumbs a:hover,
.wy-breadcrumbs a:focus {
color: rgba(0, 0, 0, 0.75);
text-decoration: none;
}
/* FOOTER */
footer {
font-size: 70%;
margin-top: 48px;
}
footer p {
font-size: inherit;
}
/* NOTES, ADMONITTIONS 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 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);
}
.note > p.first.admonition-title {
display: inline-block;
background: rgba(0, 0, 0, 0.55);
color: rgba(255, 255, 255, 0.95);
}
/* optional */
.rst-content .optional {
background: white;
}
/* tags */
.rhel {background: #fee;}
.portal {background-color: #ded;}
.satellite {background-color: #dee;}
.centos {background: #fef;}
.baremetal {background: #eef;}
.virtual {background: #efe;}
.ceph {background: #eff;}
/* 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 {
display: block;
font-size: 110%;
color: rgba(255, 255, 255, 0.75);
line-height: 2.5;
position: relative;
cursor: pointer;
padding: 0 1.618em;
}
.trigger:after {
content: '';
display: block;
font-family: FontAwesome;
font-size: 70%;
position: absolute;
right: 1.618em;
top: 6px;
}
.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;
}
/* LINKS */
a.external:after {
font-family: FontAwesome;
content: '';
visibility: visible;
display: inline-block;
font-size: 70%;
position: relative;
padding-left: 0.5em;
top: -0.5em;
}
/* LIST */
.wy-plain-list-decimal > li > ul,
.rst-content .section ol > li > ul,
.rst-content ol.arabic > li > ul,
article ol > li > ul {
margin-bottom: 24px;
}

32
doc/source/_custom/expandable.js
View File

@ -1,32 +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
var parent_id =
$.cookie($(this).parent().prop('id'),
$(this).parent().hasClass('displayed'),
{ path: '/' });
});
});

223
doc/source/_custom/jquery.nav.js
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 );

208
doc/source/_custom/jquery.scrollTo.js
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);
}
}));

3
doc/source/_custom/menu.js
View File

@ -1,3 +0,0 @@
$(document).ready(function() {
$('.wy-menu').onePageNav();
});

208
doc/source/_custom/rdo_styling.css
View File

@ -1,208 +0,0 @@
/* general settings */
body {
font-family: "Open Sans", Helvetica, Arial, sans-serif;
font-weight: 300;
font-size: 16px;
}
/* remove backgrounds */
.wy-nav-content,
.wy-body-for-nav,
.wy-nav-side,
#admonition_selector {
background: none !important;
color: black !important;
}
/* page header */
.wy-side-nav-search,
.wy-nav-top {
background: rgba(0, 0, 0, 0.05) !important;
}
.wy-nav-top {
line-height: 40px;
border-bottom: 1px solid rgba(0, 0, 0, 0.1);
}
.wy-side-nav-search a,
.wy-nav-top a,
.wy-nav-top i {
color: rgb(160, 0, 0) !important;
}
.wy-nav-top i {
position: relative;
top: 0.1em;
}
.wy-side-nav-search input[type="text"] {
border-color: rgba(0, 0, 0, 0.25);
}
/* sidebar*/
.wy-nav-side {
border-right: 1px solid rgba(0, 0, 0, 0.2);
}
/* admonition selector */
#admonition_selector {
border-top: 0 none !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;
}
.content {
border-top: 0 none !important;
border-bottom: 1px solid rgba(0, 0, 0, 0.2) !important;
background: rgba(0, 0, 0, 0.025) !important;
}
#admonition_selector .title {
color: rgba(0, 0, 0, 0.6) !important;
}
/* menu */
.wy-menu li a,
.wy-menu-vertical li a {
font-size: 100%;
line-height: 1.6;
color: rgb(80, 80, 80);
}
.wy-menu-vertical li a:hover,
.wy-menu-vertical li a:focus,
.wy-menu-vertical li.current a:hover,
.wy-menu-vertical li.current a:focus {
color: black;
text-decoration: underline;
background: none;
}
.wy-menu-vertical li.current,
.wy-menu-vertical li.current a {
border: 0 none;
color: rgb(80, 80, 80);
font-weight: inherit;
background: none;
}
/* level-1 menu item */
.wy-menu-vertical li.toctree-l1.current > a,
.wy-menu-vertical li.toctree-l1.current > a:hover,
.wy-menu-vertical li.toctree-l1.current > a:focus {
background: rgb(230, 230, 230);
}
.wy-menu li.toctree-l1 > a:before {
font-family: FontAwesome;
content: "";
display: inline-block;
position: relative;
padding-right: 0.5em;
}
/* level-2 menu item */
.toctree-l2 {
font-size: 90%;
color: inherit;
}
.wy-menu-vertical .toctree-l2 a {
padding: 0.4045em 0.5em 0.4045em 2.8em !important;
}
.wy-menu-vertical li.toctree-l2.current > a,
.wy-menu-vertical li.toctree-l2.current > a:hover,
.wy-menu-vertical li.toctree-l2.current > a:focus,
.wy-menu-vertical li.toctree-l2.active > a,
.wy-menu-vertical li.toctree-l2.active > a:hover,
.wy-menu-vertical li.toctree-l2.active > a:focus {
background: rgb(242, 242, 242);
}
.wy-menu li.toctree-l2 > a:before {
font-family: FontAwesome;
content: "";
font-size: 30%;
display: inline-block;
position: relative;
bottom: 0.55em;
padding-right: 1.5em;
}
/* typography */
h1 {
color: rgb(160, 0, 0);
font-weight: 300;
margin-top: 36px !important;
}
h3 {
font-size: 135%;
}
h2, h3, h4, h5 {
font-weight: 200;
}
a, a:visited {
color: #2275b4;
text-decoration: none;
}
a:hover, a:focus {
color: #1c6094;
text-decoration: underline;
}
.rst-content .toc-backref {
color: inherit;
}
strong {
font-weight: 600;
}
/* code */
.codeblock,
pre.literal-block,
.rst-content .literal-block,
.rst-content pre.literal-block,
div[class^="highlight"] {
background: rgba(0, 0, 0, 0.05);
color: black;
}
/* notes */
.admonition {
color: rgba(0, 0, 0, 0.5) !important;
font-weight: 400;
}
.rst-content .note {
background: none !important;
}
.note > p.first.admonition-title {
background: rgba(0, 0, 0, 0.5) !important;
color: rgba(255, 255, 255, 0.9) !important;
}

BIN
doc/source/_images/TripleO_Network_Diagram_.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 92 KiB

BIN
doc/source/_images/discovery_diagram.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 62 KiB

192
doc/source/_images/discovery_diagram.svg
View File

@ -1,192 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 16.0.4, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
width="1075.511px" height="793.5px" viewBox="1020 0 1075.511 793.5" enable-background="new 1020 0 1075.511 793.5"
xml:space="preserve">
<g>
<rect x="1046.5" y="42.271" fill="#FFFFFF" width="230.863" height="82.729"/>
<g>
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1277.363,122 1277.363,125 1274.363,125 "/>
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="6.0774,6.0774" x1="1268.286" y1="125" x2="1052.539" y2="125"/>
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1049.5,125 1046.5,125 1046.5,122 "/>
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="5.9022,5.9022" x1="1046.5" y1="116.098" x2="1046.5" y2="48.222"/>
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1046.5,45.271 1046.5,42.271 1049.5,42.271 "/>
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="6.0774,6.0774" x1="1055.577" y1="42.271" x2="1271.324" y2="42.271"/>
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1274.363,42.271 1277.363,42.271 1277.363,45.271 "/>
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="5.9022,5.9022" x1="1277.363" y1="51.173" x2="1277.363" y2="119.049"/>
</g>
</g>
<rect x="1048.5" y="73.745" fill="none" width="228.863" height="21.781"/>
<text transform="matrix(1 0 0 1 1138.9512 87.4243)" font-family="'OpenSans'" font-size="18">Client</text>
<g>
<rect x="1310.675" y="42.271" fill="#FFFFFF" width="230.863" height="82.729"/>
<g>
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1541.538,122 1541.538,125 1538.538,125 "/>
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="6.0774,6.0774" x1="1532.461" y1="125" x2="1316.714" y2="125"/>
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1313.675,125 1310.675,125 1310.675,122 "/>
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="5.9022,5.9022" x1="1310.675" y1="116.097" x2="1310.675" y2="48.222"/>
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1310.675,45.271 1310.675,42.271 1313.675,42.271 "/>
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="6.0774,6.0774" x1="1319.752" y1="42.271" x2="1535.499" y2="42.271"/>
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1538.538,42.271 1541.538,42.271 1541.538,45.271 "/>
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="5.9022,5.9022" x1="1541.538" y1="51.173" x2="1541.538" y2="119.048"/>
</g>
</g>
<rect x="1310.675" y="73.745" fill="none" width="230.863" height="21.781"/>
<text transform="matrix(1 0 0 1 1402.4023 87.4243)" font-family="'OpenSans'" font-size="18">Ironic</text>
<g>
<rect x="1577.004" y="43.271" fill="#FFFFFF" width="230.863" height="82.729"/>
<g>
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1807.867,123 1807.867,126 1804.867,126 "/>
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="6.0774,6.0774" x1="1798.79" y1="126" x2="1583.043" y2="126"/>
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1580.004,126 1577.004,126 1577.004,123 "/>
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="5.9022,5.9022" x1="1577.004" y1="117.097" x2="1577.004" y2="49.222"/>
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1577.004,46.271 1577.004,43.271 1580.004,43.271 "/>
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="6.0774,6.0774" x1="1586.081" y1="43.271" x2="1801.828" y2="43.271"/>
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1804.867,43.271 1807.867,43.271 1807.867,46.271 "/>
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="5.9022,5.9022" x1="1807.867" y1="52.173" x2="1807.867" y2="120.048"/>
</g>
</g>
<rect x="1578.582" y="74.745" fill="none" width="230.863" height="21.781"/>
<text transform="matrix(1 0 0 1 1615.3076 88.4243)" font-family="'OpenSans'" font-size="18">Discovery Ramdisk</text>
<g>
<rect x="1837.637" y="42.271" fill="#FFFFFF" width="230.863" height="82.729"/>
<g>
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="2068.5,122 2068.5,125 2065.5,125 "/>
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="6.0774,6.0774" x1="2059.423" y1="125" x2="1843.676" y2="125"/>
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1840.637,125 1837.637,125 1837.637,122 "/>
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="5.9022,5.9022" x1="1837.637" y1="116.097" x2="1837.637" y2="48.222"/>
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1837.637,45.271 1837.637,42.271 1840.637,42.271 "/>
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="6.0774,6.0774" x1="1846.714" y1="42.271" x2="2062.461" y2="42.271"/>
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="2065.5,42.271 2068.5,42.271 2068.5,45.271 "/>
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="5.9022,5.9022" x1="2068.5" y1="51.173" x2="2068.5" y2="119.048"/>
</g>
</g>
<rect x="1835.637" y="73.745" fill="none" width="232.863" height="21.781"/>
<text transform="matrix(1 0 0 1 1910.4697 87.4243)" font-family="'OpenSans'" font-size="18">Discoverd</text>
<g>
<g>
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" x1="1161.932" y1="126" x2="1161.932" y2="132"/>
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" stroke-dasharray="12.1939,12.1939" x1="1161.932" y1="144.193" x2="1161.932" y2="723.403"/>
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" x1="1161.932" y1="729.5" x2="1161.932" y2="735.5"/>
</g>
</g>
<g>
<g>
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" x1="1426.106" y1="126" x2="1426.106" y2="132"/>
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" stroke-dasharray="12.1939,12.1939" x1="1426.106" y1="144.193" x2="1426.106" y2="723.403"/>
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" x1="1426.106" y1="729.5" x2="1426.106" y2="735.5"/>
</g>
</g>
<g>
<g>
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" x1="1692.436" y1="126" x2="1692.436" y2="132"/>
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" stroke-dasharray="12.1939,12.1939" x1="1692.436" y1="144.193" x2="1692.436" y2="723.403"/>
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" x1="1692.436" y1="729.5" x2="1692.436" y2="735.5"/>
</g>
</g>
<g>
<g>
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" x1="1953.068" y1="126" x2="1953.068" y2="132"/>
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" stroke-dasharray="12.1939,12.1939" x1="1953.068" y1="144.193" x2="1953.068" y2="723.403"/>
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" x1="1953.068" y1="729.5" x2="1953.068" y2="735.5"/>
</g>
</g>
<rect x="1156.932" y="169.729" fill="#820E0A" stroke="#000000" stroke-width="2" stroke-linejoin="round" stroke-miterlimit="10" width="12" height="537.771"/>
<rect x="1420.106" y="169.729" fill="#820E0A" stroke="#000000" stroke-width="2" stroke-linejoin="round" stroke-miterlimit="10" width="12" height="158.771"/>
<rect x="1420.106" y="386" fill="#820E0A" stroke="#000000" stroke-width="2" stroke-linejoin="round" stroke-miterlimit="10" width="12" height="319.635"/>
<rect x="1946.068" y="612.5" fill="#820E0A" stroke="#000000" stroke-width="2" stroke-linejoin="round" stroke-miterlimit="10" width="12" height="92.089"/>
<g>
<g>
<line fill="none" stroke="#000000" stroke-width="2" stroke-linejoin="round" x1="1182.5" y1="169.729" x2="1394.43" y2="169.729"/>
<g>
<path d="M1406.5,169.729c-5.68,2.107-12.727,5.703-17.095,9.512l3.44-9.512l-3.44-9.51
C1393.773,164.028,1400.82,167.624,1406.5,169.729z"/>
</g>
</g>
</g>
<g>
<g>
<line fill="none" stroke="#000000" stroke-width="2" stroke-linejoin="round" x1="1182.5" y1="383.729" x2="1394.43" y2="383.729"/>
<g>
<path d="M1406.5,383.729c-5.68,2.107-12.727,5.703-17.095,9.512l3.44-9.512l-3.44-9.509
C1393.773,378.027,1400.82,381.623,1406.5,383.729z"/>
</g>
</g>
</g>
<g>
<g>
<line fill="none" stroke="#000000" stroke-width="2" stroke-linejoin="round" x1="1706.5" y1="612.5" x2="1918.43" y2="612.5"/>
<g>
<path d="M1930.5,612.5c-5.68,2.107-12.727,5.703-17.095,9.512l3.44-9.512l-3.44-9.51
C1917.773,606.799,1924.82,610.395,1930.5,612.5z"/>
</g>
</g>
</g>
<rect x="1686.436" y="386" fill="#820E0A" stroke="#000000" stroke-width="2" stroke-linejoin="round" stroke-miterlimit="10" width="12" height="226.5"/>
<g>
<g>
<line fill="none" stroke="#000000" stroke-width="2" stroke-linejoin="round" x1="1450.436" y1="386" x2="1662.365" y2="386"/>
<g>
<path d="M1674.436,386c-5.68,2.107-12.727,5.703-17.095,9.512l3.44-9.512l-3.44-9.51
C1661.709,380.299,1668.756,383.895,1674.436,386z"/>
</g>
</g>
</g>
<g>
<g>
<line fill="none" stroke="#000000" stroke-width="2" stroke-linejoin="round" x1="1460.506" y1="704.589" x2="1930.5" y2="704.589"/>
<g>
<path d="M1448.436,704.589c5.68,2.107,12.727,5.703,17.095,9.512l-3.44-9.512l3.44-9.51
C1461.162,698.888,1454.115,702.483,1448.436,704.589z"/>
</g>
</g>
</g>
<rect x="1180.068" y="134.706" fill="none" width="228.863" height="33.317"/>
<text transform="matrix(1 0 0 1 1180.0684 145.3457)"><tspan x="0" y="0" font-family="'OpenSans'" font-size="14">Register nodes’</tspan><tspan x="0" y="16.8" font-family="'OpenSans'" font-size="14">power management details</tspan></text>
<rect x="1182.5" y="348.047" fill="none" width="228.863" height="33.316"/>
<text transform="matrix(1 0 0 1 1182.5 375.4868)" font-family="'OpenSans'" font-size="14">Send nodes for introspection</text>
<rect x="1448.004" y="350.047" fill="none" width="228.863" height="33.316"/>
<text transform="matrix(1 0 0 1 1448.0039 360.687)"><tspan x="0" y="0" font-family="'OpenSans'" font-size="14">Reboot nodes -&gt; PXE boot generic </tspan><tspan x="0" y="16.799" font-family="'OpenSans'" font-size="14">discovery ramdisk image</tspan></text>
<rect x="1584.004" y="669.545" fill="none" width="346.496" height="33.316"/>
<text transform="matrix(1 0 0 1 1599.0186 696.9844)" font-family="'OpenSans'" font-size="14">Facts checking and registration of hardware details</text>
<rect x="1705.068" y="579.184" fill="none" width="228.863" height="33.316"/>
<text transform="matrix(1 0 0 1 1705.0684 606.623)" font-family="'OpenSans'" font-size="14">Post hardware metrics</text>
<g>
<g>
<line fill="none" stroke="#000000" stroke-width="2" stroke-linejoin="round" x1="1192.139" y1="321.729" x2="1404.068" y2="321.729"/>
<g>
<path d="M1180.068,321.729c5.68,2.107,12.727,5.703,17.095,9.512l-3.44-9.512l3.44-9.51
C1192.795,316.027,1185.748,319.623,1180.068,321.729z"/>
</g>
</g>
</g>
<rect x="1179.068" y="286.047" fill="none" width="228.863" height="33.316"/>
<text transform="matrix(1 0 0 1 1295.7676 313.4868)" font-family="'OpenSans'" font-size="14">Nodes registered</text>
<rect x="1258.858" y="748.158" fill="none" width="346.496" height="33.316"/>
<text transform="matrix(1 0 0 1 1341.6709 758.7988)"><tspan x="0" y="0" font-family="'OpenSans-Bold'" font-size="14">Nodes are fully registered</tspan><tspan x="-38.877" y="16.799" font-family="'OpenSans-Bold'" font-size="14">wth full stack of hardware attributes</tspan></text>
</svg>
Side by Side

Before

Width:  |  Height:  |  Size: 12 KiB

BIN
doc/source/_images/logical_view.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 120 KiB

2383
doc/source/_images/logical_view.svg
View File

File diff suppressed because it is too large Load Diff
Side by Side

Before

Width:  |  Height:  |  Size: 259 KiB

BIN
doc/source/_images/overview.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 16 KiB

32
doc/source/_images/overview.svg
View File

@ -1,32 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 16.0.4, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
width="644.5px" height="294px" viewBox="0 0 644.5 294" enable-background="new 0 0 644.5 294" xml:space="preserve">
<path fill="#820A0E" d="M10.775,93.754L10.775,93.754c0-10.828,8.667-19.605,19.357-19.605h110.615
c5.134,0,10.058,2.066,13.688,5.743s5.669,8.664,5.669,13.864v78.422c0,10.828-8.667,19.605-19.357,19.605H30.133l0,0
c-10.691,0-19.357-8.777-19.357-19.605L10.775,93.754L10.775,93.754z"/>
<path fill="none" stroke="#000000" stroke-width="2" stroke-linejoin="round" stroke-miterlimit="10" d="M10.775,93.754
L10.775,93.754c0-10.828,8.667-19.605,19.357-19.605h110.615c5.134,0,10.058,2.066,13.688,5.743s5.669,8.664,5.669,13.864v78.422
c0,10.828-8.667,19.605-19.357,19.605H30.133l0,0c-10.691,0-19.357-8.777-19.357-19.605L10.775,93.754L10.775,93.754z"/>
<path fill-opacity="0" d="M299.077,53.848L299.077,53.848c0-21.85,17.485-39.562,39.058-39.562h255.822
c10.358,0,20.293,4.167,27.618,11.587c7.325,7.417,11.438,17.481,11.438,27.973v158.235c0,21.85-17.485,39.562-39.058,39.562
H338.135c-21.57,0-39.058-17.712-39.058-39.562V53.848L299.077,53.848z"/>
<path fill="#DDDDDD" stroke="#000000" stroke-width="2" stroke-linejoin="round" stroke-miterlimit="10" d="M299.077,53.848
L299.077,53.848c0-21.85,17.485-39.562,39.058-39.562h255.822c10.358,0,20.293,4.167,27.618,11.587
c7.325,7.417,11.438,17.481,11.438,27.973v158.235c0,21.85-17.485,39.562-39.058,39.562H338.135
c-21.57,0-39.058-17.712-39.058-39.562V53.848L299.077,53.848z"/>
<path fill-opacity="0" d="M160.105,132.965h138.972"/>
<path fill="none" stroke="#000000" stroke-width="2" stroke-linejoin="round" stroke-miterlimit="10" d="M160.105,132.965h127.253"
/>
<path stroke="#000000" stroke-width="2" stroke-miterlimit="10" d="M287.358,136.233l8.864-3.269l-8.864-3.268V136.233z"/>
<path fill-opacity="0" d="M180.854,79.397h97.472v92.433h-97.472V79.397z"/>
<rect x="17.44" y="125.359" fill="none" width="139" height="16.712"/>
<text transform="matrix(0.9873 0 0 1 26.0718 139.2148)" fill="#FFFFFF" font-family="'OpenSans-Semibold'" font-size="18.2314">RDO-Manager</text>
<rect x="329.94" y="125.359" fill="none" width="261" height="16.712"/>
<text transform="matrix(0.9873 0 0 1 335.8867 139.2148)" font-family="'OpenSans-Semibold'" font-size="18.2314">Production OpenStack Cloud</text>
<rect x="160.105" y="80.287" fill="none" width="138.972" height="106.856"/>
<text transform="matrix(0.9873 0 0 1 202.6709 91.0645)" font-family="'OpenSans-Semibold'" font-size="14.18">Deploys</text>
<text transform="matrix(0.9873 0 0 1 201.4199 108.0801)" font-family="'OpenSans-Semibold'" font-size="14.18">Updates</text>
<text transform="matrix(0.9873 0 0 1 199.0068 125.0957)" font-family="'OpenSans-Semibold'" font-size="14.18">Monitors</text>
</svg>
Side by Side

Before

Width:  |  Height:  |  Size: 3.0 KiB

BIN
doc/source/_images/physical_view.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 138 KiB

2243
doc/source/_images/physical_view.svg
View File

File diff suppressed because it is too large Load Diff
Side by Side

Before

Width:  |  Height:  |  Size: 243 KiB

BIN
doc/source/_images/rdo-manager-logo.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 5.4 KiB

50
doc/source/_templates/layout.html
View File

@ -1,50 +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"] %}
{% block sidebartitle %}
<a href="{{ pathto(master_doc) }}">
{# Not strictly valid HTML, but it's the only way to display/scale it properly, without weird scripting or heaps of work #}
<img src="{{ pathto('_static/' + 'rdo-manager-logo.png', 1) }}" class="logo" />
</a>
{% endblock %}
{% block menu %}
<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">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">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>
</div>
</div>
{{ super() }}
{% endblock %}

26
doc/source/advanced_deployment/advanced_deployment.rst
View File

@ -1,26 +0,0 @@
Advanced Deployment
===================
In this chapter you will find advanced deployment of various RDO-Manager areas.
.. toctree::
Advanced Profile Matching <profile_matching>
Ready-State (BIOS, RAID) <ready_state>
Automated Health Check <automated_health_check>
Additional node configuration <extra_config>
Deploying with Heat Templates <template_deploy>
Network Isolation <network_isolation>
Managing Tuskar Plans and Roles <managing_plans_and_roles>
Deploying Manila <deploy_manila>
Configuring Cinder with a NetApp Backend <cinder_netapp>
.. <MOVE THESE UNDER TOCTREE WHEN READY, KEEP LOGICAL WORKFLOW ORDER>
Images <images>
Nodes <nodes>
Flavors <flavors>
Deployment <deployment>
Connection to Overcloud <overcloud>
Updates <updates>

290
doc/source/advanced_deployment/automated_health_check.rst
View File

@ -1,290 +0,0 @@
Automated Health Check (AHC)
============================
Start with matching the nodes to profiles as described in
:doc:`profile_matching`.
Enable running benchmarks during discovery
------------------------------------------
By default, the benchmark tests do not run during the discovery process.
You can enable this feature by setting *discovery_runbench = true* in the
**undercloud.conf** file prior to installing the undercloud.
If you want to enable this feature after installing the undercloud, you can set
*discovery_runbench = true* in **undercloud.conf**, and re-run
``openstack undercloud install``
Analyze the collected benchmark data
------------------------------------
After discovery has completed, we can do analysis on the benchmark data.
* Run the ``ahc-report`` script to see a general overview of the hardware
::
$ source stackrc
$ ahc-report --categories
##### HPA Controller #####
3 identical systems :
[u'7F8831F1-0D81-464E-A767-7577DF49AAA5', u'B9FE637A-5B97-4A52-BFDA-9244CEA65E23', u'7884BC95-6EF8-4447-BDE5-D19561718B29']
[]
########################
##### Megaraid Controller #####
3 identical systems :
[u'7F8831F1-0D81-464E-A767-7577DF49AAA5', u'B9FE637A-5B97-4A52-BFDA-9244CEA65E23', u'7884BC95-6EF8-4447-BDE5-D19561718B29']
[]
#############################
##### AHCI Controller #####
3 identical systems :
[u'7F8831F1-0D81-464E-A767-7577DF49AAA5', u'B9FE637A-5B97-4A52-BFDA-9244CEA65E23', u'7884BC95-6EF8-4447-BDE5-D19561718B29']
[]
#########################
##### IPMI SDR #####
3 identical systems :
[u'7F8831F1-0D81-464E-A767-7577DF49AAA5', u'B9FE637A-5B97-4A52-BFDA-9244CEA65E23', u'7884BC95-6EF8-4447-BDE5-D19561718B29']
[]
##################
##### Firmware #####
3 identical systems :
[u'7F8831F1-0D81-464E-A767-7577DF49AAA5', u'B9FE637A-5B97-4A52-BFDA-9244CEA65E23', u'7884BC95-6EF8-4447-BDE5-D19561718B29']
[(u'firmware', u'bios', u'date', u'01/01/2011'),
(u'firmware', u'bios', u'vendor', u'Seabios'),
(u'firmware', u'bios', u'version', u'0.5.1')]
##################
##### Memory Timing(RAM) #####
3 identical systems :
[u'7F8831F1-0D81-464E-A767-7577DF49AAA5', u'B9FE637A-5B97-4A52-BFDA-9244CEA65E23', u'7884BC95-6EF8-4447-BDE5-D19561718B29']
[]
############################
##### Network Interfaces #####
3 identical systems :
[u'7F8831F1-0D81-464E-A767-7577DF49AAA5', u'B9FE637A-5B97-4A52-BFDA-9244CEA65E23', u'7884BC95-6EF8-4447-BDE5-D19561718B29']
[(u'network', u'eth0', u'businfo', u'pci@0000:00:04.0'),
(u'network', u'eth0', u'busy-poll', u'off [fixed]'),
(u'network', u'eth0', u'driver', u'virtio_net'),
(u'network', u'eth0', u'fcoe-mtu', u'off [fixed]'),
(u'network', u'eth0', u'generic-receive-offload', u'on'),
(u'network', u'eth0', u'generic-segmentation-offload', u'on'),
(u'network', u'eth0', u'highdma', u'on [fixed]'),
(u'network', u'eth0', u'large-receive-offload', u'off [fixed]'),
(u'network', u'eth0', u'latency', u'0'),
(u'network', u'eth0', u'link', u'yes'),
(u'network', u'eth0', u'loopback', u'off [fixed]'),
(u'network', u'eth0', u'netns-local', u'off [fixed]'),
(u'network', u'eth0', u'ntuple-filters', u'off [fixed]'),
(u'network', u'eth0', u'receive-hashing', u'off [fixed]'),
(u'network', u'eth0', u'rx-all', u'off [fixed]'),
(u'network', u'eth0', u'rx-checksumming', u'on [fixed]'),
(u'network', u'eth0', u'rx-fcs', u'off [fixed]'),
(u'network', u'eth0', u'rx-vlan-filter', u'on [fixed]'),
(u'network', u'eth0', u'rx-vlan-offload', u'off [fixed]'),
(u'network', u'eth0', u'rx-vlan-stag-filter', u'off [fixed]'),
(u'network', u'eth0', u'rx-vlan-stag-hw-parse', u'off [fixed]'),
(u'network', u'eth0', u'scatter-gather', u'on'),
(u'network', u'eth0', u'scatter-gather/tx-scatter-gather', u'on'),
(u'network', u'eth0', u'scatter-gather/tx-scatter-gather-fraglist', u'on'),
(u'network', u'eth0', u'tcp-segmentation-offload', u'on'),
(u'network',
u'eth0',
u'tcp-segmentation-offload/tx-tcp-ecn-segmentation',
u'on'),
(u'network', u'eth0', u'tcp-segmentation-offload/tx-tcp-segmentation', u'on'),
(u'network',
u'eth0',
u'tcp-segmentation-offload/tx-tcp6-segmentation',
u'on'),
(u'network', u'eth0', u'tx-checksumming', u'on'),
(u'network',
u'eth0',
u'tx-checksumming/tx-checksum-fcoe-crc',
u'off [fixed]'),
(u'network', u'eth0', u'tx-checksumming/tx-checksum-ip-generic', u'on'),
(u'network', u'eth0', u'tx-checksumming/tx-checksum-ipv6', u'off [fixed]'),
(u'network', u'eth0', u'tx-checksumming/tx-checksum-sctp', u'off [fixed]'),
(u'network', u'eth0', u'tx-fcoe-segmentation', u'off [fixed]'),
(u'network', u'eth0', u'tx-gre-segmentation', u'off [fixed]'),
(u'network', u'eth0', u'tx-gso-robust', u'off [fixed]'),
(u'network', u'eth0', u'tx-ipip-segmentation', u'off [fixed]'),
(u'network', u'eth0', u'tx-lockless', u'off [fixed]'),
(u'network', u'eth0', u'tx-mpls-segmentation', u'off [fixed]'),
(u'network', u'eth0', u'tx-nocache-copy', u'on'),
(u'network', u'eth0', u'tx-sit-segmentation', u'off [fixed]'),
(u'network', u'eth0', u'tx-udp_tnl-segmentation', u'off [fixed]'),
(u'network', u'eth0', u'tx-vlan-offload', u'off [fixed]'),
(u'network', u'eth0', u'tx-vlan-stag-hw-insert', u'off [fixed]'),
(u'network', u'eth0', u'udp-fragmentation-offload', u'on'),
(u'network', u'eth0', u'vlan-challenged', u'off [fixed]')]
############################
##### Processors #####
1 identical systems :
[u'B9FE637A-5B97-4A52-BFDA-9244CEA65E23']
[(u'cpu', u'logical', u'number', u'2'),
(u'cpu', u'physical', u'number', u'2'),
(u'cpu',
u'physical_0',
u'flags',
u'fpu fpu_exception wp de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx x86-64 rep_good nopl pni cx16 hypervisor lahf_lm'),
(u'cpu', u'physical_0', u'frequency', u'2000000000'),
(u'cpu', u'physical_0', u'physid', u'401'),
(u'cpu', u'physical_0', u'product', u'QEMU Virtual CPU version 1.5.3'),
(u'cpu', u'physical_0', u'vendor', u'Intel Corp.'),
(u'cpu',
u'physical_1',
u'flags',
u'fpu fpu_exception wp de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx x86-64 rep_good nopl pni cx16 hypervisor lahf_lm'),
(u'cpu', u'physical_1', u'frequency', u'2000000000'),
(u'cpu', u'physical_1', u'physid', u'402'),
(u'cpu', u'physical_1', u'product', u'QEMU Virtual CPU version 1.5.3'),
(u'cpu', u'physical_1', u'vendor', u'Intel Corp.')]
2 identical systems :
[u'7F8831F1-0D81-464E-A767-7577DF49AAA5', u'7884BC95-6EF8-4447-BDE5-D19561718B29']
[(u'cpu', u'logical', u'number', u'1'),
(u'cpu', u'physical', u'number', u'1'),
(u'cpu',
u'physical_0',
u'flags',
u'fpu fpu_exception wp de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx x86-64 rep_good nopl pni cx16 hypervisor lahf_lm'),
(u'cpu', u'physical_0', u'frequency', u'2000000000'),
(u'cpu', u'physical_0', u'physid', u'401'),
(u'cpu', u'physical_0', u'product', u'QEMU Virtual CPU version 1.5.3'),
(u'cpu', u'physical_0', u'vendor', u'Intel Corp.')]
In the example above we have two nodes with a single CPU, and one with two CPU's.
* We can also look for performance outliers
::
$ ahc-report --outliers
Group 0 : Checking logical disks perf
standalone_randread_4k_KBps : INFO : sda : Group performance : min=45296.00, mean=53604.67, max=67923.00, stddev=12453.21
standalone_randread_4k_KBps : ERROR : sda : Group's variance is too important : 23.23% of 53604.67 whereas limit is set to 15.00%
standalone_randread_4k_KBps : ERROR : sda : Group performance : UNSTABLE
standalone_read_1M_IOps : INFO : sda : Group performance : min= 1199.00, mean= 1259.00, max= 1357.00, stddev= 85.58
standalone_read_1M_IOps : INFO : sda : Group performance = 1259.00 : CONSISTENT
standalone_randread_4k_IOps : INFO : sda : Group performance : min=11320.00, mean=13397.33, max=16977.00, stddev= 3113.39
standalone_randread_4k_IOps : ERROR : sda : Group's variance is too important : 23.24% of 13397.33 whereas limit is set to 15.00%
standalone_randread_4k_IOps : ERROR : sda : Group performance : UNSTABLE
standalone_read_1M_KBps : INFO : sda : Group performance : min=1231155.00, mean=1292799.67, max=1393152.00, stddev=87661.11
standalone_read_1M_KBps : INFO : sda : Group performance = 1292799.67 : CONSISTENT
Group 0 : Checking CPU perf
bogomips : INFO : logical_0 : Group performance : min= 4199.99, mean= 4199.99, max= 4199.99, stddev= 0.00
bogomips : INFO : logical_0 : Group performance = 4199.99 : CONSISTENT
bogomips : INFO : logical_1 : Group performance : min= 4199.99, mean= 4199.99, max= 4199.99, stddev= nan
bogomips : INFO : logical_1 : Group performance = 4199.99 : CONSISTENT
loops_per_sec : INFO : logical_0 : Group performance : min= 379.00, mean= 398.67, max= 418.00, stddev= 19.50
loops_per_sec : INFO : logical_0 : Group performance = 398.67 : CONSISTENT
loops_per_sec : INFO : logical_1 : Group performance : min= 423.00, mean= 423.00, max= 423.00, stddev= nan
loops_per_sec : INFO : logical_1 : Group performance = 423.00 : CONSISTENT
loops_per_sec : INFO : CPU Effi. : Group performance : min= 99.28, mean= inf, max= inf, stddev= nan
loops_per_sec : INFO : CPU Effi. : Group performance = inf % : CONSISTENT
Group 0 : Checking Memory perf
Memory benchmark 1K : INFO : logical_0 : Group performance : min= 1677.00, mean= 1698.33, max= 1739.00, stddev= 35.23
Memory benchmark 1K : INFO : logical_0 : Group performance = 1698.33 : CONSISTENT
Memory benchmark 1K : INFO : logical_1 : Group performance : min= 1666.00, mean= 1666.00, max= 1666.00, stddev= nan
Memory benchmark 1K : INFO : logical_1 : Group performance = 1666.00 : CONSISTENT
Memory benchmark 1K : INFO : Thread effi. : Group performance : min= 71.54, mean= 71.54, max= 71.54, stddev= nan
Memory benchmark 1K : INFO : Thread effi. : Group performance = 71.54 : CONSISTENT
Memory benchmark 1K : INFO : Forked Effi. : Group performance : min= 101.97, mean= 101.97, max= 101.97, stddev= nan
Memory benchmark 1K : INFO : Forked Effi. : Group performance = 101.97 % : CONSISTENT
Memory benchmark 4K : INFO : logical_0 : Group performance : min= 4262.00, mean= 4318.00, max= 4384.00, stddev= 61.61
Memory benchmark 4K : INFO : logical_0 : Group performance = 4318.00 : CONSISTENT
Memory benchmark 4K : INFO : logical_1 : Group performance : min= 4363.00, mean= 4363.00, max= 4363.00, stddev= nan
Memory benchmark 4K : INFO : logical_1 : Group performance = 4363.00 : CONSISTENT
Memory benchmark 4K : INFO : Thread effi. : Group performance : min= 77.75, mean= 77.75, max= 77.75, stddev= nan
Memory benchmark 4K : INFO : Thread effi. : Group performance = 77.75 : CONSISTENT
Memory benchmark 4K : INFO : Forked Effi. : Group performance : min= 95.98, mean= 95.98, max= 95.98, stddev= nan
Memory benchmark 4K : INFO : Forked Effi. : Group performance = 95.98 % : CONSISTENT
Memory benchmark 1M : INFO : logical_0 : Group performance : min= 7734.00, mean= 7779.00, max= 7833.00, stddev= 50.11
Memory benchmark 1M : INFO : logical_0 : Group performance = 7779.00 : CONSISTENT
Memory benchmark 1M : INFO : logical_1 : Group performance : min= 7811.00, mean= 7811.00, max= 7811.00, stddev= nan
Memory benchmark 1M : INFO : logical_1 : Group performance = 7811.00 : CONSISTENT
Memory benchmark 1M : INFO : Thread effi. : Group performance : min= 101.20, mean= 101.20, max= 101.20, stddev= nan
Memory benchmark 1M : INFO : Thread effi. : Group performance = 101.20 : CONSISTENT
Memory benchmark 1M : INFO : Forked Effi. : Group performance : min= 99.26, mean= 99.26, max= 99.26, stddev= nan
Memory benchmark 1M : INFO : Forked Effi. : Group performance = 99.26 % : CONSISTENT
Memory benchmark 16M : INFO : logical_0 : Group performance : min= 5986.00, mean= 6702.33, max= 7569.00, stddev= 802.14
Memory benchmark 16M : ERROR : logical_0 : Group's variance is too important : 11.97% of 6702.33 whereas limit is set to 7.00%
Memory benchmark 16M : ERROR : logical_0 : Group performance : UNSTABLE
Memory benchmark 16M : INFO : logical_1 : Group performance : min= 7030.00, mean= 7030.00, max= 7030.00, stddev= nan
Memory benchmark 16M : INFO : logical_1 : Group performance = 7030.00 : CONSISTENT
Memory benchmark 16M : INFO : Thread effi. : Group performance : min= 109.94, mean= 109.94, max= 109.94, stddev= nan
Memory benchmark 16M : INFO : Thread effi. : Group performance = 109.94 : CONSISTENT
Memory benchmark 16M : INFO : Forked Effi. : Group performance : min= 93.14, mean= 93.14, max= 93.14, stddev= nan
Memory benchmark 16M : INFO : Forked Effi. : Group performance = 93.14 % : CONSISTENT
Memory benchmark 128M : INFO : logical_0 : Group performance : min= 6021.00, mean= 6387.00, max= 7084.00, stddev= 603.87
Memory benchmark 128M : ERROR : logical_0 : Group's variance is too important : 9.45% of 6387.00 whereas limit is set to 7.00%
Memory benchmark 128M : ERROR : logical_0 : Group performance : UNSTABLE
Memory benchmark 128M : INFO : logical_1 : Group performance : min= 7089.00, mean= 7089.00, max= 7089.00, stddev= nan
Memory benchmark 128M : INFO : logical_1 : Group performance = 7089.00 : CONSISTENT
Memory benchmark 128M : INFO : Thread effi. : Group performance : min= 107.11, mean= 107.11, max= 107.11, stddev= nan
Memory benchmark 128M : INFO : Thread effi. : Group performance = 107.11 : CONSISTENT
Memory benchmark 128M : INFO : Forked Effi. : Group performance : min= 95.55, mean= 95.55, max= 95.55, stddev= nan
Memory benchmark 128M : INFO : Forked Effi. : Group performance = 95.55 % : CONSISTENT
Memory benchmark 256M : WARNING : Thread effi. : Benchmark not run on this group
Memory benchmark 256M : WARNING : Forked Effi. : Benchmark not run on this group
Memory benchmark 1G : INFO : logical_0 : Group performance : min= 6115.00, mean= 6519.67, max= 7155.00, stddev= 557.05
Memory benchmark 1G : ERROR : logical_0 : Group's variance is too important : 8.54% of 6519.67 whereas limit is set to 7.00%
Memory benchmark 1G : ERROR : logical_0 : Group performance : UNSTABLE
Memory benchmark 1G : INFO : logical_1 : Group performance : min= 7136.00, mean= 7136.00, max= 7136.00, stddev= nan
Memory benchmark 1G : INFO : logical_1 : Group performance = 7136.00 : CONSISTENT
Memory benchmark 1G : INFO : Thread effi. : Group performance : min= 104.29, mean= 104.29, max= 104.29, stddev= nan
Memory benchmark 1G : INFO : Thread effi. : Group performance = 104.29 : CONSISTENT
Memory benchmark 1G : INFO : Forked Effi. : Group performance : min= 98.98, mean= 98.98, max= 98.98, stddev= nan
Memory benchmark 1G : INFO : Forked Effi. : Group performance = 98.98 % : CONSISTENT
Memory benchmark 2G : INFO : logical_0 : Group performance : min= 6402.00, mean= 6724.33, max= 7021.00, stddev= 310.30
Memory benchmark 2G : INFO : logical_0 : Group performance = 6724.33 : CONSISTENT
Memory benchmark 2G : INFO : logical_1 : Group performance : min= 7167.00, mean= 7167.00, max= 7167.00, stddev= nan
Memory benchmark 2G : INFO : logical_1 : Group performance = 7167.00 : CONSISTENT
Memory benchmark 2G : WARNING : Thread effi. : Benchmark not run on this group
Memory benchmark 2G : WARNING : Forked Effi. : Benchmark not run on this group
The output above is from a virtual setup, so the benchmarks are not accurate.
However we can see that the variance of the "standalone_randread_4k_KBps"
metric was above the threshold, so the group is marked as unstable.
Exclude outliers from deployment
--------------------------------
We will use the sample reports above to construct some matching rules
for our deployment. Refer to :doc:`profile_matching` for details.
* Add a rule to the **control.specs** file to match the system with two CPUs
::
[
('cpu', 'logical', 'number', 'ge(2)'),
('disk', '$disk', 'size', 'gt(4)'),
('network', '$eth', 'ipv4', 'network(192.0.2.0/24)'),
('memory', 'total', 'size', 'ge(4294967296)'),
]
* Add a rule to the **control.specs** file to exclude systems with below
average disk performance from the control role
::
[
('disk', '$disk', 'standalone_randread_4k_IOps', 'gt(13397)')
('cpu', 'logical', 'number', 'ge(2)'),
('disk', '$disk', 'size', 'gt(4)'),
('network', '$eth', 'ipv4', 'network(192.0.2.0/24)'),
('memory', 'total', 'size', 'ge(4294967296)'),
]
* Now rerun the matching and proceed with remaining steps from
:doc:`profile_matching`.

60
doc/source/advanced_deployment/cinder_netapp.rst
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:`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>

129
doc/source/advanced_deployment/deploy_manila.rst
View File

@ -1,129 +0,0 @@
Deploying Manila in the Overcloud
=================================
This guide assumes that your undercloud is already installed and ready to
deploy an overcloud with Manila enabled.
Deploying the Overcloud
-----------------------
.. note::
The :doc:`template_deploy` doc has a more detailed explanation of the
following steps.
#. Copy the Manila driver-specific configuration file to your home directory:
- Generic driver::
sudo cp /usr/share/openstack-tripleo-heat-templates/environments/manila-generic-config.yaml ~
- NetApp driver::
sudo cp /usr/share/openstack-tripleo-heat-templates/environments/manila-netapp-config.yaml ~
#. Edit the permissions (user is typically ``stack``)::
sudo chown $USER ~/manila-*-config.yaml
sudo chmod 755 ~/manila-*-config.yaml
#. Edit the parameters in this file to fit your requirements.
- If you're using the generic driver, ensure that the service image
details correspond to the service image you intend to load.
- Ensure that the following line is changed::
OS::TripleO::ControllerExtraConfigPre: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/pre_deploy/controller/manila-[generic or 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 ~/manila-[generic or netapp]-config.yaml
#. Wait for the completion of the overcloud deployment process.
Creating the Share
------------------
.. 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.
#. Upload a service image:
.. note::
This step is only required for the generic driver.
Download a Manila service image to be used for share servers and upload it
to Glance so that Manila can use it [tenant]::
glance image-create --name manila-service-image --disk-format qcow2 --container-format bare --file manila_service_image.qcow2
#. Create a share network to host the shares:
- Create the overcloud networks. The
:doc:`../basic_deployment/basic_deployment` doc has a more detailed
explanation about creating the network and subnet. Note that you may also
need to perform the following steps to get Manila working::
neutron router-create router1
neutron router-interface-add router1 [subnet id]
- List the networks and subnets [tenant]::
neutron net-list && neutron subnet-list
- Create a share network (typically using the private default-net net/subnet)
[tenant]::
manila share-network-create --neutron-net-id [net] --neutron-subnet-id [subnet]
#. Create a new share type (yes/no is for specifying if the driver handles
share servers) [admin]::
manila type-create [name] [yes/no]
#. Create the share [tenant]::
manila create --share-network [share net ID] --share-type [type name] [nfs/cifs] [size of share]
Accessing the Share
-------------------
#. To access the share, create a new VM on the same Neutron network that was
used to create the share network::
nova boot --image [image ID] --flavor [flavor ID] --nic net-id=[network ID] [name]
#. Allow access to the VM you just created::
manila access-allow [share ID] ip [IP address of VM]
#. Run ``manila list`` and ensure that the share is available.
#. Log into the VM::
ssh [user]@[IP]
.. note::
You may need to configure Neutron security rules to access the
VM. That is not in the scope of this document, so it will not be covered
here.
5. In the VM, execute::
sudo mount [export location] [folder to mount to]
6. Ensure the share is mounted by looking at the bottom of the output of the
``mount`` command.
7. That's it - you're ready to start using Manila!

231
doc/source/advanced_deployment/extra_config.rst
View File

@ -1,231 +0,0 @@
Additional node configuration
=============================
It is possible to enable additional configuration during one of the
following deployment phases:
* firstboot - run once config (performed by cloud-init)
* post-deploy - run after the services have been deployed and configured
.. note::
This documentation assumes some knowledge of heat HOT_ template
syntax, and makes use of heat environment_ files. See the upstream
heat documentation_ for further information.
.. _HOT: http://docs.openstack.org/developer/heat/template_guide/hot_guide.html
.. _environment: http://docs.openstack.org/developer/heat/template_guide/environment.html
.. _documentation: http://docs.openstack.org/developer/heat/template_guide/index.html
Firstboot extra configuration
-----------------------------
Firstboot configuration is optional, and is performed on *all* nodes on initial
deployment.
Any configuration possible via cloud-init may be performed at this point,
either by applying cloud-config yaml or running arbitrary additional
scripts.
The heat templates used for deployment provide the `OS::TripleO::NodeUserData`
resource as the interface to enable this configuration. A basic example of its
usage is provided below, followed by some notes related to real world
usage.
The script snippet below shows how to create a simple example containing two
scripts, combined via the MultipartMime_ resource::
mkdir firstboot
cat > firstboot/one_two.yaml << EOF
heat_template_version: 2014-10-16
resources:
userdata:
type: OS::Heat::MultipartMime
properties:
parts:
- config: {get_resource: one_config}
- config: {get_resource: two_config}
one_config:
type: OS::Heat::SoftwareConfig
properties:
config: |
#!/bin/bash
echo "one" > /tmp/one
two_config:
type: OS::Heat::SoftwareConfig
properties:
config: |
#!/bin/bash
echo "two" > /tmp/two
outputs:
OS::stack_id:
value: {get_resource: userdata}
EOF
.. _MultipartMime: http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::MultipartMime
.. note::
The stack must expose an `OS::stack_id` output which references an
OS::Heat::MultipartMime resource.
This template is then mapped to the `OS::TripleO::NodeUserData` resource type
via a heat environment file::
cat > userdata_env.yaml << EOF
resource_registry:
OS::TripleO::NodeUserData: firstboot/one_two.yaml
EOF
You may then deploy your overcloud referencing the additional environment file::
openstack overcloud deploy --templates -e userdata_env.yaml
.. note::
The userdata is applied to *all* nodes in the deployment. If you need role
specific logic, the userdata scripts can contain conditionals which use
e.g the node hostname to determine the role.
.. note::
OS::TripleO::NodeUserData is only applied on initial node deployment,
not on any subsequent stack update, because cloud-init only processes the
nova user-data once, on first boot.
For a more complete example, which creates an additional user and configures
SSH keys by accessing the nova metadata server, see
/usr/share/openstack-tripleo-heat-templates/firstboot/userdata_example.yaml
on the undercloud node or the tripleo-heat-templates_ repo.
.. _tripleo-heat-templates: https://github.com/rdo-management/tripleo-heat-templates/blob/mgt-master/firstboot/userdata_example.yaml
Post-Deploy extra configuration
-------------------------------
Post-deploy additional configuration is possible via the
`OS::TripleO::NodeExtraConfigPost` interface - this allows a heat template
to be specified which performs additional configuration using standard
heat SoftwareConfig_ resources.
.. _SoftwareConfig: http://docs.openstack.org/developer/heat/template_guide/software_deployment.html
.. note::
The `OS::TripleO::NodeExtraConfigPost` applies configuration to *all* nodes,
there is currently no per-role NodeExtraConfigPost interface.
Below is an example of a post-deployment configuration template::
mkdir -p extraconfig/post-deploy/
cat > extraconfig/post-deploy/example.yaml << EOF
heat_template_version: 2014-10-16
parameters:
servers:
type: json
# Optional implementation specific parameters
some_extraparam:
type: string
resources:
ExtraConfig:
type: OS::Heat::SoftwareConfig
properties:
group: script
config:
str_replace:
template: |
#!/bin/sh
echo "extra _APARAM_" > /root/extra
parameters:
_APARAM_: {get_param: some_extraparam}
ExtraDeployments:
type: OS::Heat::SoftwareDeployments
properties:
servers: {get_param: servers}
config: {get_resource: ExtraConfig}
actions: ['CREATE'] # Only do this on CREATE
EOF
The "servers" parameter must be specified in all NodeExtraConfigPost
templates, this is the server list to apply the configuration to,
and is provided by the parent template.
Optionally, you may define additional parameters which are consumed by the
implementation. These may then be provided via parameter_defaults in the
environment which enables the configuration.
.. note::
If the parameter_defaults approach is used, care must be used to avoid
unintended reuse of parameter names between multiple templates, because
parameter_defaults is applied globally.
The "actions" property of the `OS::Heat::SoftwareDeployments` resource may be
used to specify when the configuration should be applied, e.g only on CREATE,
only on DELETE etc. If this is ommitted, the heat default is to apply the
config on CREATE and UPDATE, e.g on initial deployment and every subsequent
update.
The extra config may be enabled via an environment file::
cat > post_config_env.yaml << EOF
resource_registry:
OS::TripleO::NodeExtraConfigPost: extraconfig/post-deploy/example.yaml
parameter_defaults:
some_extraparam: avalue123
EOF
You may then deploy your overcloud referencing the additional environment file::
openstack overcloud deploy --templates -e post_config_env.yaml
Making configuration changes
----------------------------
If you want to make a configuration change, either prior to initial deployment,
or subsequently via an update, you can update hiera data files which
are used for passing configuration values to Puppet. [#]_ Hiera data files
are part of heat templates and are located in `puppet/hieradata` directory.
You can find a file for each of roles (controller, compute,...) in this
directory, so different configuration can be set for different roles. Put
your configuration changes into the file which corresponds to the role
of nodes you want to change. For example to set reserved host memory on
all compute nodes::
echo "nova::compute::reserved_host_memory: some_value" >> puppet/hieradata/compute.yaml
And then update your overcloud::
openstack overcloud deploy --templates "custom templates dir"
.. note::
If you set a configuration of a puppet class which is not being included
yet, make sure you include it in any of `puppet/manifests` file. For example
if you want to change CPU allocation ratio update controller hieradata::
echo "nova::scheduler::filter::cpu_allocation_ratio: '11.0'" >> puppet/hieradata/controller.yaml
And include `nova::scheduler::filter` class in `puppet/manifests/overcloud_controller_pacemaker.pp`.
.. note::
It's best to copy default heat templates to a custom location before making
any changes. See :ref:`custom-template-location`.
.. rubric:: Footnotes
.. [#] Note that this is a temporary workaround, and a `future version`_ is
expected to provide interfaces that enable specifying extra hieradata
without modifying any templates.
.. _future version: https://bugzilla.redhat.com/show_bug.cgi?id=1243971

189
doc/source/advanced_deployment/managing_plans_and_roles.rst
View File

@ -1,189 +0,0 @@
Managing Plans and Roles
========================
This section provides a description of the Plan and Role concepts and the
operations available to each from the command line.
To learn how to delete and reload all plans and roles skip to the relevant
`Reload the deployment plan and all deployment roles`_ section below.
Understanding Roles & Plans
---------------------------
Roles represent the functionality that will be served by a node, for example a
Compute or Storage node. Plans define the full deployment and consist of one
or more roles and their related Parameters.
Roles
-----
The Roles included in the Tuskar API can be viewed with the following command::
$ openstack management role list
+--------------------------------------+----------------+---------+---------------------------------------------------+
| uuid | name | version | description |
+--------------------------------------+----------------+---------+---------------------------------------------------+
| 6830e747-6d43-44bf-99b6-97a7145c58c6 | Swift-Storage | 1 | OpenStack swift storage node configured by Puppet |
| 96faca30-8c05-48b2-b9c8-d01cd2d0dc47 | Compute | 1 | OpenStack hypervisor node configured via Puppet. |
| b0c87438-871d-46e2-9fee-4b42c65f3c45 | Ceph-Storage | 1 | OpenStack ceph storage node configured by Puppet |
| d5ffd638-8df3-4ed6-8925-32e8891dae25 | Cinder-Storage | 1 | OpenStack cinder storage configured by Puppet |
| e3e09fa8-00c8-4870-8f2b-de67a9faa5ab | Controller | 1 | OpenStack controller node configured by Puppet. |
+--------------------------------------+----------------+---------+---------------------------------------------------+
Plans
-----
By default Tuskar comes with one Plan named overcloud with all of the above
Roles added to the plan. However, only Control and Compute have their scale
value set and will be deployed by default.
The Plan can be viewed with the following command::
$ openstack management plan list
+--------------------------------------+-----------+-------------+------------------------------------------------------------------+
| uuid | name | description | roles |
+--------------------------------------+-----------+-------------+------------------------------------------------------------------+
| eac9c4cc-9d85-4c6a-85bb-e1f38afcff7e | overcloud | None | Compute, Ceph-Storage, Cinder-Storage, Controller, Swift-Storage |
+--------------------------------------+-----------+-------------+------------------------------------------------------------------+
Once you have the Plan UUID you can view more details about the plan::
$ openstack management plan show eac9c4cc-9d85-4c6a-85bb-e1f38afcff7e
+-------------+------------------------------------------------------------------+
| Field | Value |
+-------------+------------------------------------------------------------------+
| created_at | 2015-07-13T10:09:14 |
| description | None |
| name | overcloud |
| parameters | Parameter output suppressed. Use --long to display them. |
| roles | Compute, Ceph-Storage, Cinder-Storage, Controller, Swift-Storage |
| updated_at | None |
| uuid | eac9c4cc-9d85-4c6a-85bb-e1f38afcff7e |
+-------------+------------------------------------------------------------------+
The command can be repeated with ``--long`` appended to the end for a
detailed output of all the available Plan parameters.
Adding and Removing Roles
~~~~~~~~~~~~~~~~~~~~~~~~~
Roles can be removed from the plan like this::
$ openstack management plan remove role "[plan-uuid]" "[role-uuid]"
And similarly they can be added back to the plan::
$ openstack management plan add role "[plan-uuid]" "[role-uuid]"
The output of both of these commands is the summary of the plan and it will
reflect the role being added or removed.
Assigning Flavors to Roles
~~~~~~~~~~~~~~~~~~~~~~~~~~
Roles can have a flavor assigned with the following command::
$ openstack management plan set "[plan-uuid]" -F Compute-1=baremetal
In this example we are assigning the ``baremetal`` flavor to the Compute role,
but we need to include the role version when doing this. Making the syntax
``-F [role-name]-[role-version]=[flavor-name]``.
Setting Scale values
~~~~~~~~~~~~~~~~~~~~
Similar to assigning Flavors, scaling an individual role can be done like
this::
$ openstack management plan set "[plan-uuid]" -S Compute-1=3
In this example we are scaling the Compute role to three nodes.
Setting other parameters
~~~~~~~~~~~~~~~~~~~~~~~~
Arbitrary parameters can be set for Roles. To do this, the following syntax
needs to be used.::
$ openstack management plan set "[plan-uuid]" -P Compute-1::Image=compute
Making the syntax ``-F [role-name]-[role-version]::[parameter-
name]=[value]``. The above example assigns the compute image to the compute
role - for this to work a compute image needs to be uploaded to glance.
Downloading a Plan
------------------
Plans can be downloaded from Tuskar. The result of doing this is a set of
Heat templates that can be then manipulated or manually passed to the Heat
client.::
$ openstack management plan download "[plan-uuid]" -O path/to/output
Once you have downloaded the templates from Tuskar, they can be sent directly
to Heat with this command.::
$ heat stack-create overcloud \
-f path/to/output/plan.yaml \
-e path/to/output/environment.yaml \
-t 240;
Reload the deployment plan and all deployment roles
---------------------------------------------------
You may wish to recreate the overcloud deployment plan and deployment roles
from scratch, for example to work with a newer version of the tripleo heat
templates from which the deployment roles are created.
.. note::
The steps documented below will completely remove the current
overcloud deployment plan and deployment roles including any overridden
and saved deployment parameters.
Delete the overcloud deployment plan and any roles
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Get the current deployment plan uuid and specify it for deletion::
openstack management plan list
openstack management plan delete PLAN_UUID
Now you can safely delete all deployment roles::
roles=`tuskar role-list | grep OpenStack | awk '{print $2}'`
tuskar-delete-roles --config-file /etc/tuskar/tuskar.conf --uuids $roles
Recreate the deployment roles
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Roles are reloaded by running the tuskar-db-sync script from the tuskar
tripleo image element::
/usr/share/tripleo-image-elements/tuskar/os-refresh-config/configure.d/90-tuskar-db-sync
This script defaults to using `/usr/share/openstack-tripleo-heat-templates/`
as the path to the local tripleo heat templates from which to define the roles.
This can be overridden by setting the TUSKAR_ROLE_DIRECTORY environment
variable::
TUSKAR_ROLE_DIRECTORY=/foo/ /usr/share/tripleo-image-elements/tuskar/os-refresh-config/configure.d/90-tuskar-db-sync
Recreate the deployment plan and associate the new roles
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Create a new deployment plan and associate the newly created roles to it. This
is achieved by running the plan-add-roles script from the tuskar tripleo image
element::
/usr/share/tripleo-image-elements/tuskar/os-refresh-config/post-configure.d/101-plan-add-roles

680
doc/source/advanced_deployment/network_isolation.rst
View File

@ -1,680 +0,0 @@
Configuring Network Isolation
=============================
Introduction
------------
RDO-Manager provides configuration of isolated overcloud networks. Using
this approach it is possible to host traffic for specific types of network
traffic (tenants, storage, API/RPC, etc.) in isolated networks. This allows
for assigning network traffic to specific network interfaces or bonds. Using
bonds provides fault tolerance, and may provide load sharing, depending on the
bonding protocols used. When isolated networks are configured, the OpenStack
services will be configured to use the isolated networks. If no isolated
networks are configured, all services run on the provisioning network.
There are two parts to the network configuration: the parameters that apply
to the network as a whole, and the templates which configure the network
interfaces on the deployed hosts.
Architecture
------------
The following VLANs will be used in the final deployment:
* IPMI* (IPMI System controller, iLO, DRAC)
* Provisioning* (Undercloud control plane for deployment and management)
* Internal API (OpenStack internal API, RPC, and DB)
* Tenant (Tenant tunneling network for GRE/VXLAN networks)
* Storage (Access to storage resources from Compute and Controller nodes)
* Storage Management (Replication, Ceph back-end services)
* External (Public OpenStack APIs, Horzizon dashboard, optionally floating IPs)
.. note::
Networks marked with '*' are usually native VLANs, others may be trunked.
Additionally, if floating IPs will be hosted on a separate VLAN, that VLAN will
need to be trunked to the controller hosts. It will not be included in the
network configuration steps in this document, the VLAN will be added as a
post-configuration step.
The External network should have a gateway router address. This will be used
in the subnet configuration of the network environment.
The Provisioning network will usually be delivered on a dedicated interface.
By default, PXE boot must occur on the native VLAN, although some system
controllers will allow booting from a VLAN. The Provisioning interface is
also used by the Compute and Storage nodes as their default gateway, in order
to contact DNS, NTP, and for system maintenance. The Undercloud can be used
as a default gateway, but in that case all traffic will be behind an IP
masquerade NAT, and will not be reachable from the rest of the network. The
Undercloud is also a single point of failure for the overcloud default route.
If there is an external gateway on a router device on the Provisioning network,
the Undercloud Neutron DHCP server can offer that instead::
neutron subnet-show # Copy the UUID from the provisioning subnet
neutron subnet-update <UUID> --gateway_ip <IP_ADDRESS>
Often, the number of VLANs will exceed the number of physical Ethernet ports,
so some VLANs are delivered with VLAN tagging to separate the traffic. On an
Ethernet bond, typically all VLANs are trunked, and there is no traffic on the
native VLAN (native VLANs on bonds are supported, but will require customizing
the NIC templates).
The networks are connected to the roles as follows:
Controller:
* Provisioning
* Internal API
* Storage
* Storage Management
* External
Compute:
* Provisioning
* Internal API
* Storage
* Tenant
Ceph Storage:
* Provisioning
* Storage
* Storage Management
Cinder Storage:
* Provisioning
* Internal API
* Storage
* Storage Management
Swift Storage:
* Provisioning
* Internal API
* Storage
* Storage Management
Workflow
--------
The procedure for enabling network isolation is this:
1. Create network environment file (e.g. /home/stack/network-environment.yaml)
2. Edit IP subnets and VLANs in the environment file to match local environment
3. Make a copy of the appropriate sample network interface configurations
4. Edit the network interface configurations to match local environment
5. Deploy overcloud with the proper parameters to include network isolation
The next section will walk through the elements that need to be added to
the network-environment.yaml to enable network isolation. The sections
after that deal with configuring the network interface templates. The final step
will deploy the overcloud with network isolation and a custom environment.
Create Network Environment File
-------------------------------
The environment file will describe the network environment and will point to
the network interface configuration files to use for the overcloud nodes.
The subnets that will be used for the isolated networks need to be defined,
along with the IP address ranges that should be used for IP assignment. These
values must be customized for the local environment.
It is important for the ExternalInterfaceDefaultRoute to be reachable on the
subnet that is used for ExternalNetCidr. This will allow the OpenStack Public
APIs and the Horizon Dashboard to be reachable. Without a valid default route,
the post-deployment steps cannot be performed.
.. note::
The ``resource_registry`` section of the network-environment.yaml contains
pointers to the network interface configurations for the deployed roles.
These files must exist at the path referenced here, and will be copied
later in this guide.
Example::
resource_registry:
OS::TripleO::BlockStorage::Net::SoftwareConfig: /home/stack/nic-configs/cinder-storage.yaml
OS::TripleO::Compute::Net::SoftwareConfig: /home/stack/nic-configs/compute.yaml
OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/nic-configs/controller.yaml
OS::TripleO::ObjectStorage::Net::SoftwareConfig: /home/stack/nic-configs/swift-storage.yaml
OS::TripleO::CephStorage::Net::SoftwareConfig: /home/stack/nic-configs/ceph-storage.yaml
parameters:
# Set to "br-ex" if using floating IPs on native VLAN on bridge br-ex
Controller-1::NeutronExternalNetworkBridge: "''"
parameter_defaults:
# Customize all these values to match the local environment
InternalApiNetCidr: 172.17.0.0/24
StorageNetCidr: 172.18.0.0/24
StorageMgmtNetCidr: 172.19.0.0/24
TenantNetCidr: 172.16.0.0/24
ExternalNetCidr: 10.1.2.0/24
InternalApiAllocationPools: [{'start': '172.17.0.10', 'end': '172.17.0.200'}]
StorageAllocationPools: [{'start': '172.18.0.10', 'end': '172.18.0.200'}]
StorageMgmtAllocationPools: [{'start': '172.19.0.10', 'end': '172.19.0.200'}]
TenantAllocationPools: [{'start': '172.16.0.10', 'end': '172.16.0.200'}]
# Use an External allocation pool which will leave room for floating IPs
ExternalAllocationPools: [{'start': '10.1.2.10', 'end': '10.1.2.50'}]
InternalApiNetworkVlanID: 201
StorageNetworkVlanID: 202
StorageMgmtNetworkVlanID: 203
TenantNetworkVlanID: 204
ExternalNetworkVlanID: 100
# Set to the router gateway on the external network
ExternalInterfaceDefaultRoute: 10.1.2.1
# Set to "br-ex" if using floating IPs on native VLAN on bridge br-ex
NeutronExternalNetworkBridge: "''"
# Customize bonding options if required (will be ignored if bonds are not used)
BondInterfaceOvsOptions:
"bond_mode=balance-tcp lacp=active other-config:lacp-fallback-ab=true"
Creating Custom Interface Templates
-----------------------------------
In order to configure the network interfaces on each node, the network
interface templates may need to be customized.
Start by copying the configurations from one of the example directories. The
first example copies the templates which include network bonding. The second
example copies the templates which use a single network interface with
multiple VLANs (this configuration is mostly intended for testing).
To copy the bonded example interface configurations, run::
$ cp /usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans/* ~/nic-configs
To copy the single NIC with VLANs example interface configurations, run::
$ cp /usr/share/openstack-tripleo-heat-templates/network/config/single-nic-vlans/* ~/nic-configs
Or, if you have custom NIC templates from another source, copy them to the location
referenced in the ``resource_registry`` section of the environment file.
Customizing the Interface Templates
-----------------------------------
The following example configures a bond on interfaces 3 and 4 of a system
with 4 interfaces. This example is based on the controller template from the
bond-with-vlans sample templates, but the bond has been placed on nic3 and nic4
instead of nic2 and nic3. The other roles will have a similar configuration,
but will have only a subset of the networks attached.
.. note::
The nic1, nic2... abstraction considers only network interfaces which are
connected to an Ethernet switch. If interfaces 1 and 4 are the only
interfaces which are plugged in, they will be referred to as nic1 and nic2.
Example::
heat_template_version: 2015-04-30
description: >
Software Config to drive os-net-config with 2 bonded nics on a bridge
with a VLANs attached for the controller role.
parameters:
ExternalIpSubnet:
default: ''
description: IP address/subnet on the external network
type: string
InternalApiIpSubnet:
default: ''
description: IP address/subnet on the internal API network
type: string
StorageIpSubnet:
default: ''
description: IP address/subnet on the storage network
type: string
StorageMgmtIpSubnet:
default: ''
description: IP address/subnet on the storage mgmt network
type: string
TenantIpSubnet:
default: ''
description: IP address/subnet on the tenant network
type: string
BondInterfaceOvsOptions:
default: ''
description: The ovs_options string for the bond interface. Set things like
lacp=active and/or bond_mode=balance-slb using this option.
type: string
ExternalNetworkVlanID:
default: 10
description: Vlan ID for the external network traffic.
type: number
InternalApiNetworkVlanID:
default: 20
description: Vlan ID for the internal_api network traffic.
type: number
StorageNetworkVlanID:
default: 30
description: Vlan ID for the storage network traffic.
type: number
StorageMgmtNetworkVlanID:
default: 40
description: Vlan ID for the storage mgmt network traffic.
type: number
TenantNetworkVlanID:
default: 50
description: Vlan ID for the tenant network traffic.
type: number
ExternalInterfaceDefaultRoute:
default: '10.0.0.1'
description: Default route for the external network.
type: string
resources:
OsNetConfigImpl:
type: OS::Heat::StructuredConfig
properties:
group: os-apply-config
config:
os_net_config:
network_config:
-
type: ovs_bridge
name: {get_input: bridge_name}
members:
-
type: ovs_bond
name: bond1
ovs_options: {get_param: BondInterfaceOvsOptions}
members:
-
type: interface
name: nic3
primary: true
-
type: interface
name: nic4
-
type: vlan
device: bond1
vlan_id: {get_param: ExternalNetworkVlanID}
addresses:
-
ip_netmask: {get_param: ExternalIpSubnet}
routes:
-
ip_netmask: 0.0.0.0/0
next_hop: {get_param: ExternalInterfaceDefaultRoute}
-
type: vlan
device: bond1
vlan_id: {get_param: InternalApiNetworkVlanID}
addresses:
-
ip_netmask: {get_param: InternalApiIpSubnet}
-
type: vlan
device: bond1
vlan_id: {get_param: StorageNetworkVlanID}
addresses:
-
ip_netmask: {get_param: StorageIpSubnet}
-
type: vlan
device: bond1
vlan_id: {get_param: StorageMgmtNetworkVlanID}
addresses:
-
ip_netmask: {get_param: StorageMgmtIpSubnet}
-
type: vlan
device: bond1
vlan_id: {get_param: TenantNetworkVlanID}
addresses:
-
ip_netmask: {get_param: TenantIpSubnet}
outputs:
OS::stack_id:
description: The OsNetConfigImpl resource.
value: {get_resource: OsNetConfigImpl}
Configuring Interfaces
----------------------
The individual interfaces may need to be modified. As an example, below are
the modifications that would be required to use the second NIC to connect to
an infrastructure network with DHCP addresses, and to use the third and fourth
NICs for the bond:
Example::
network_config:
# Add a DHCP infrastructure network to nic2
-
type: interface
name: nic2
use_dhcp: true
defroute: false
-
type: ovs_bridge
name: br-bond
members:
-
type: ovs_bond
name: bond1
ovs_options: {get_param: BondInterfaceOvsOptions}
members:
# Modify bond NICs to use nic3 and nic4
-
type: interface
name: nic3
primary: true
-
type: interface
name: nic4
When using numbered interfaces ("nic1", "nic2", etc.) instead of named
interfaces ("eth0", "eno2", etc.), the network interfaces of hosts within
a role do not have to be exactly the same. For instance, one host may have
interfaces em1 and em2, while another has eno1 and eno2, but both hosts' NICs
can be referred to as nic1 and nic2.
The numbered NIC scheme only takes into account the interfaces that are live
(have a cable attached to the switch). So if you have some hosts with 4
interfaces, and some with 6, you should use nic1-nic4 and only plug in 4
cables on each host.
Configuring Routes and Default Routes
-------------------------------------
There are two ways that a host may have its default routes set. If the interface
is using DHCP, and the DHCP server offers a gateway address, the system will
install a default route for that gateway. Otherwise, a default route may be set
manually on an interface with a static IP.
Although the Linux kernel supports multiple default gateways, it will only use
the one with the lowest metric. If there are multiple DHCP interfaces, this can
result in an unpredictable default gateway. In this case, it is recommended that
defroute=no be set for the interfaces other than the one where we want the
default route. In this case, we want a DHCP interface (NIC 2) to be the default
route (rather than the Provisioning interface), so we disable the default route
on the provisioning interface:
Example::
# No default route on the Provisioning network
-
type: interface
name: nic1
use_dhcp: true
defroute: no
# Instead use this DHCP infrastructure VLAN as the default route
-
type: interface
name: nic2
use_dhcp: true
To set a static route on an interface with a static IP, specify a route to the
subnet. For instance, here is a hypothetical route to the 10.1.2.0/24 subnet
via the gateway at 172.17.0.1 on the Internal API network:
Example::
-
type: vlan
device: bond1
vlan_id: {get_param: InternalApiNetworkVlanID}
addresses:
-
ip_netmask: {get_param: InternalApiIpSubnet}
routes:
-
ip_netmask: 10.1.2.0/24
next_hop: 172.17.0.1
Using a Dedicated Interface For Tenant VLANs
--------------------------------------------
When using a dedicated interface or bond for tenant VLANs, a bridge must be
created. Neutron will create OVS ports on that bridge with the VLAN tags for the
provider VLANs. For example, to use NIC 4 as a dedicated interface for tenant
VLANs, you would add the following to the Controller and Compute templates:
Example::
-
type: ovs_bridge
name: br-vlan
members:
-
type: interface
name: nic4
primary: true
A similar configuration may be used to define an interface or a bridge that
will be used for Provider VLANs. Provider VLANs are external networks which
are connected directly to the Compute hosts. VMs may be attached directly to
Provider networks to provide access to datacenter resources outside the cloud.
Using the Native VLAN for Floating IPs
--------------------------------------
By default, Neutron will be expecting the floating IP network to be delivered
on a tagged VLAN. If the floating IP network will use the native VLAN, then we
need to tell Neutron to put the floating IPs directly on the ``br-ex`` bridge.
The value must be set in both of these parameters in the parameters section:
Example::
parameters:
# Set to "br-ex" when using floating IPs on the native VLAN
Controller-1::NeutronExternalNetworkBridge: "''"
parameter_defaults:
# Set to "br-ex" when using floating IPs on the native VLAN
NeutronExternalNetworkBridge: "''"
The next section contains the changes to the NIC config that need to happen
to put the External network on the native VLAN (the External network may be
used for floating IPs in addition to the Horizon dashboard and Public APIs).
Using the Native VLAN on a Trunked Interface
--------------------------------------------
If a trunked interface or bond has a network on the native VLAN, then the IP
address will be assigned directly to the bridge and there will be no VLAN
interface. If the native VLAN is used for the External network, make sure to
set the NeutronExternalNetworkBridge parameters to "br-ex" instead of "''"
in the ``network-environment.yaml``.
For example, if the external network is on the native VLAN, the bond
configuration would look like this:
Example::
network_config:
-
type: ovs_bridge
name: {get_input: bridge_name}
addresses:
-
ip_netmask: {get_param: ExternalIpSubnet}
routes:
-
ip_netmask: 0.0.0.0/0
next_hop: {get_param: ExternalInterfaceDefaultRoute}
members:
-
type: ovs_bond
name: bond1
ovs_options: {get_param: BondInterfaceOvsOptions}
members:
-
type: interface
name: nic3
primary: true
-
type: interface
name: nic4
.. note::
When moving the address (and possibly route) statements onto the bridge, be
sure to remove the corresponding VLAN interface from the bridge. Make sure to
make the changes to all applicable roles. The External network is only on the
controllers, so only the controller template needs to be changed. The Storage
network on the other hand is attached to all roles, so if the storage network
were the default VLAN, all roles would need to be edited.
Configuring Jumbo Frames
------------------------
The Maximum Transmission Unit (MTU) setting determines the maximum amount of
data that can be transmitted by a single Ethernet frame. Using a larger value
can result in less overhead, since each frame adds data in the form of a
header. The default value is 1500, and using a value higher than that will
require the switch port to be configured to support jumbo frames. Most switches
support an MTU of at least 9000, but many are configured for 1500 by default.
The MTU of a VLAN cannot exceed the MTU of the physical interface. Make sure to
include the MTU value on the bond and/or interface.
Storage, Storage Management, Internal API, and Tenant networking can all
benefit from jumbo frames. In testing, tenant networking throughput was
over 300% greater when using jumbo frames in conjunction with VXLAN tunnels.
.. note::
It is recommended that the Provisioning interface, External interface, and
any floating IP interfaces be left at the default MTU of 1500. Connectivity
problems are likely to occur otherwise.
Example::
-
type: ovs_bond
name: bond1
mtu: 9000
ovs_options: {get_param: BondInterfaceOvsOptions}
members:
-
type: interface
name: nic3
mtu: 9000
primary: true
-
type: interface
name: nic4
mtu: 9000
-
# The external interface should stay at default
type: vlan
device: bond1
vlan_id: {get_param: ExternalNetworkVlanID}
addresses:
-
ip_netmask: {get_param: ExternalIpSubnet}
routes:
-
ip_netmask: 0.0.0.0/0
next_hop: {get_param: ExternalInterfaceDefaultRoute}
-
# MTU 9000 for Internal API, Storage, and Storage Management
type: vlan
device: bond1
mtu: 9000
vlan_id: {get_param: InternalApiNetworkVlanID}
addresses:
-
ip_netmask: {get_param: InternalApiIpSubnet}
Assinging OpenStack Services to Isolated Networks
-------------------------------------------------
Each OpenStack service is assigned to a network using a default mapping. The
service will be bound to the host IP within the named network on each host.
..note::
The services will be assigned to the networks according to the
``ServiceNetMap`` in ``overcloud-without-mergepy.yaml``. Unless these
defaults need to be overridden, the ServiceNetMap does not need to be defined
in the environment file.
A service can be assigned to an alternate network by overriding the service to
network map in an environment file. The defaults should generally work, but
can be overridden. To override these values, add the ServiceNetMap to the
``parameter_defaults`` section of the network environment.
Example::
parameter_defaults:
ServiceNetMap:
NeutronTenantNetwork: tenant
CeilometerApiNetwork: internal_api
MongoDbNetwork: internal_api
CinderApiNetwork: internal_api
CinderIscsiNetwork: storage
GlanceApiNetwork: storage
GlanceRegistryNetwork: internal_api
KeystoneAdminApiNetwork: internal_api
KeystonePublicApiNetwork: internal_api
NeutronApiNetwork: internal_api
HeatApiNetwork: internal_api
NovaApiNetwork: internal_api
NovaMetadataNetwork: internal_api
NovaVncProxyNetwork: internal_api
SwiftMgmtNetwork: storage_mgmt
SwiftProxyNetwork: storage
HorizonNetwork: internal_api
MemcachedNetwork: internal_api
RabbitMqNetwork: internal_api
RedisNetwork: internal_api
MysqlNetwork: internal_api
CephClusterNetwork: storage_mgmt
CephPublicNetwork: storage
# Define which network will be used for hostname resolution
ControllerHostnameResolveNetwork: internal_api
ComputeHostnameResolveNetwork: internal_api
BlockStorageHostnameResolveNetwork: internal_api
ObjectStorageHostnameResolveNetwork: internal_api
CephStorageHostnameResolveNetwork: storage
.. note::
If an entry in the ServiceNetMap points to a network which does not exist,
that service will be placed on the Provisioning network. To avoid that,
make sure that each entry points to a valid network.
Deploying the Overcloud With Network Isolation
----------------------------------------------
When deploying with network isolation, you should specify the NTP server for the
overcloud nodes. If the clocks are not synchronized, some OpenStack services may
be unable to start, especially when using HA. The NTP server should be reachable
from both the External and Provisioning subnets. The neutron network type should
be specified, along with the tunneling or VLAN parameters.
To deploy with network isolation and include the network environment file, use
the ``-e`` parameters with the ``openstack overcloud deploy`` command. For
instance, to deploy VXLAN mode, the deployment command might be::
openstack overcloud deploy -e /home/stack/network-environment.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
--plan openstack --ntp-server pool.ntp.org --neutron-network-type vxlan \
--neutron-tunnel-types vxlan
To deploy with VLAN mode, you should specify the range of VLANs that will be
used for tenant networks::
openstack overcloud deploy -e /home/stack/network-environment.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
--plan openstack --ntp-server pool.ntp.org --neutron-network-type vlan \
--neutron-bridge-mappings datacentre:br-ex \
--neutron-network-vlan-ranges datacentre:30:100 \
--neutron-disable-tunneling
If a dedicated interface or bridge is used for tenant VLANs, it should be
included in the bridge mappings. For instance, if the tenant VLANs were on a
bridge named ``br-vlan``, then use these values in the deployment command
above::
--neutron-bridge-mappings datacentre:br-ex,tenant:br-vlan \
--neutron-network-vlan-ranges tenant:30:100
.. 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/package_update`.

224
doc/source/advanced_deployment/profile_matching.rst
View File

@ -1,224 +0,0 @@
Advanced Profile Matching
=========================
Here are additional setup steps to take advantage of the advanced profile
matching and the AHC features.
Enable advanced profile matching
--------------------------------
* Install the ahc-tools package::
sudo yum install -y ahc-tools
* Add the credentials for Ironic and Swift to the
**/etc/ahc-tools/ahc-tools.conf** file.
These will be the same credentials that ironic-discoverd uses,
and can be copied from **/etc/ironic-discoverd/discoverd.conf**::
$ sudo -i
# mkdir -p /etc/ahc-tools
# sed 's/\[discoverd/\[ironic/' /etc/ironic-discoverd/discoverd.conf > /etc/ahc-tools/ahc-tools.conf
# chmod 0600 /etc/ahc-tools/ahc-tools.conf
# exit
Example::
[ironic]
os_auth_url = http://192.0.2.1:5000/v2.0
os_username = ironic
os_password = <PASSWORD>
os_tenant_name = service
[swift]
os_auth_url = http://192.0.2.1:5000/v2.0
os_username = ironic
os_password = <PASSWORD>
os_tenant_name = service
Accessing additional introspection data
---------------------------------------
Every introspection run (as described in
:doc:`../basic_deployment/basic_deployment_cli`) collects a lot of additional
facts about the hardware and puts them as JSON in Swift. Swift container name
is ``ironic-inspector`` and can be modified in
**/etc/ironic-discoverd/discoverd.conf**. Swift object name is stored under
``hardware_swift_object`` key in Ironic node extra field.
As an example, to download the swift data for all nodes to a local directory
and use that to collect a list of node mac addresses::
# You will need the discoverd user password
# from /etc/ironic-discoverd/discoverd.conf:
export IRONIC_DISCOVERD_PASSWORD=
# Download the extra introspection data from swift:
for node in $(ironic node-list | grep -v UUID| awk '{print $2}');
do swift -U service:ironic -K $IRONIC_DISCOVERD_PASSWORD download ironic-discoverd extra_hardware-$node;
done
# Use jq to access the local data - for example gather macs:
for f in extra_hardware-*;
do cat $f | jq -r 'map(select(.[0]=="network" and .[2]=="serial"))';
done
State file
----------
Configuration file **/etc/ahc-tools/edeploy/state** defines how many nodes of
each profile we want to match. This file contains list of tuples with profile
name and number of nodes for this profile. ``*`` symbol can be used to match
any number, but make sure that such tuple will go last.
For example to start with 1 control node and any number of compute ones,
populate this file with the following contents::
[('control', '1'), ('compute', '*')]
Matching rules
--------------
These matching rules will determine what profile gets assigned to each node
and are stored in files named **/etc/ahc-tools/edeploy/PROFILE.specs** for
each profile defined in **/etc/ahc-tools/edeploy/state**.
Open the **/etc/ahc-tools/edeploy/control.specs** file.
This is a JSON-like file that might look like this::
[
('disk', '$disk', 'size', 'gt(4)'),
('network', '$eth', 'ipv4', 'network(192.0.2.0/24)'),
('memory', 'total', 'size', 'ge(4294967296)'),
]
These rules match on the data collected during introspection.
Note that disk size is in GiB, while memory size is in KiB.
There is a set of helper functions to make matching more flexible.
* network() : the network interface shall be in the specified network
* gt(), ge(), lt(), le() : greater than (or equal), lower than (or equal)
* in() : the item to match shall be in a specified set
* regexp() : match a regular expression
* or(), and(), not(): boolean functions. or() and and() take 2 parameters
and not() one parameter.
There are also placeholders, *$disk* and *$eth* in the above example.
These will store the value in that place for later use.
* For example if we had a "fact" from discovery::
('disk', 'sda', 'size', '40')
This would match the first rule in the above control.specs file,
and we would store ``"disk": "sda"``.
Running advanced profile matching
---------------------------------
* After adjusting the matching rules, we are ready to do the matching::
sudo ahc-match
* This will attempt to match all of the available nodes to the roles
we have defined in the **/etc/ahc-tools/edeploy/state** file.
When a node matches a role, the role is added to the node in Ironic in
the form of a capability. We can check this with ``ironic node-show``::
[stack@instack ~]# ironic node-show b73fb5fa-1a2c-49c6-b38e-8de41e3c0532 | grep properties -A2
| properties | {u'memory_mb': u'4096', u'cpu_arch': u'x86_64', u'local_gb': u'40', |
| | u'cpus': u'1', u'capabilities': u'profile:control,boot_option:local'} |
| instance_uuid | None
* In the above output, we can see that the control profile is added
as a capability to the node. Next we will need to create flavors in Nova
that actually map to these profiles.
[Optional] Manually add the profiles to the nodes
-------------------------------------------------
In order to use the matching functionality without using the AHC tools. We can
instead add the profile "tags" manually. The example below will add the
"control" profile to a node::
ironic node-update <UUID> replace properties/capabilities='profile:control,boot_option:local'
.. note::
We can not update only a single key from the capabilities dictionary, so we
need to specify both the profile and the boot_option above. Otherwise, the
boot_option key will get removed.
Create flavors to use advanced matching
---------------------------------------
In order to use the profiles assigned to the Ironic nodes, Nova needs to have
flavors that have the property "capabilities:profile" set to the intended profile.
For example, with just the compute and control profiles:
* Create the flavors
::
openstack flavor create --id auto --ram 4096 --disk 40 --vcpus 1 control
openstack flavor create --id auto --ram 4096 --disk 40 --vcpus 1 compute
.. note::
The values for ram, disk, and vcpus should be set to a minimal lower bound,
as Nova will still check that the Ironic nodes have at least this much
even if we set lower properties in the **.specs** files.
* Assign the properties
::
openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="compute" compute
openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="control" control
Use the flavors to deploy
-------------------------
By default, all nodes are deployed to the **baremetal** flavor.
The RDO-Manager CLI has options to support more advanced role matching.
Continuing with the example with only a control and compute profile:
* Get the Tuskar plan name
::
openstack management plan list
* Deploy the overcloud
::
openstack overcloud deploy --control-flavor control --compute-flavor compute --plan <Name or UUID from above>
Use the flavors to scale
-------------------------
The process to scale an overcloud that uses our advanced profiles is the same
as the process used when we only have the **baremetal** flavor.
.. note::
The original overcloud must have been deployed as above in order to scale
using advanced profiles, as the flavor to role mapping happens then.
* Update the **/etc/ahc-tools/edeploy/state** file to match the number
of nodes we want to match to each role.
* Run `sudo ahc-match` to match available nodes to the defined roles.
* Scale the overcloud (example below adds two more nodes to the compute role)
::
openstack overcloud scale stack overcloud overcloud -r Compute-1 -n 2

112
doc/source/advanced_deployment/ready_state.rst
View File

@ -1,112 +0,0 @@
Ready-State (BIOS, RAID)
========================
.. note:: Ready-state configuration currently works only with Dell DRAC
machines.
Ready-state configuration can be used to prepare bare-metal resources for
deployment. It includes BIOS and RAID configuration based on a predefined
profile.
To define the target BIOS and RAID configuration for a deployment profile, you
need to create a JSON-like ``<profile>.cmdb`` file in
``/etc/ahc-tools/edeploy``. The configuration will be applied only to nodes
that match the ``<profile>.specs`` rules.
Define the target BIOS configuration
------------------------------------
To define a BIOS setting, list the name of the setting and its target
value::
[
{
'bios_settings': {'ProcVirtualization': 'Enabled'}
}
]
Define the target RAID configuration
------------------------------------
The RAID configuration can be defined in 2 ways: either by listing the IDs
of the physical disks, or letting Ironic assign physical disks to the
RAID volume.
By providing a list of physical disk IDs the following attributes are required:
``controller``, ``size_gb``, ``raid_level`` and the list of ``physical_disks``.
``controller`` should be the FQDD of the RAID controller assigned by the DRAC
card. Similarly, the list of ``physical_disks`` should be the FQDDs of physical
disks assigned by the DRAC card. An example::
[
{
'logical_disks': [
{'controller': 'RAID.Integrated.1-1',
'size_gb': 100,
'physical_disks': [
'Disk.Bay.0:Enclosure.Internal.0-1:RAID.Integrated.1-1',
'Disk.Bay.1:Enclosure.Internal.0-1:RAID.Integrated.1-1',
'Disk.Bay.2:Enclosure.Internal.0-1:RAID.Integrated.1-1'],
'raid_level': '5'},
]
}
]
By letting Ironic assign physical disks to the RAID volume, the following
attributes are required: ``controller``, ``size_gb``, ``raid_level`` and the
``number_of_physical_disks``. ``controller`` should be the FQDD of the RAID
controller assigned by the DRAC card. An example::
[
{
'logical_disks': [
{'controller': 'RAID.Integrated.1-1',
'size_gb': 50,
'raid_level': '1',
'number_of_physical_disks': 2},
]
}
]
Complete example for a ``control.cmdb``
---------------------------------------
::
[
{
'bios_settings': {'ProcVirtualization': 'Enabled'},
'logical_disks': [
{'controller': 'RAID.Integrated.1-1',
'size_gb': 50,
'raid_level': '1',
'number_of_physical_disks': 2,
'disk_type': 'hdd',
'interface_type': 'sas',
'volume_name': 'root_volume',
'is_root_volume': True},
{'controller': 'RAID.Integrated.1-1',
'size_gb': 100,
'physical_disks': [
'Disk.Bay.0:Enclosure.Internal.0-1:RAID.Integrated.1-1',
'Disk.Bay.1:Enclosure.Internal.0-1:RAID.Integrated.1-1',
'Disk.Bay.2:Enclosure.Internal.0-1:RAID.Integrated.1-1'],
'raid_level': '5',
'volume_name': 'data_volume1'}
]
}
]
Trigger the ready-state configuration
-------------------------------------
Continue with matching the nodes to profiles as described in
:doc:`profile_matching`.
Then trigger the BIOS and RAID configuration based on the matched deployment
profile::
instack-ironic-deployment --configure-nodes

87
doc/source/advanced_deployment/template_deploy.rst
View File

@ -1,87 +0,0 @@
Deploying with Heat Templates
=============================
It is possible to deploy to heat directly, using a directory of templates,
e.g without using any Tuskar plan. This is potentially a more convenient
approach if you are only deploying via the CLI (the UI requires Tuskar),
and/or if you are developing significant enhancements or site-specific
additions to the templates.
Deploying an Overcloud without Tuskar
-------------------------------------
You may use the ``--templates`` option to enable deploying only using heat
templates, e.g no tuskar plan::
openstack overcloud deploy --templates
.. note::
The default location for the templates is
`/usr/share/openstack-tripleo-heat-templates`. Using this option
will not include any modifications to the Tuskar role templates which
may have been performed, templates are always read from local files.
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.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/package_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 <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

437
doc/source/basic_deployment/basic_deployment_cli.rst
View File

@ -1,437 +0,0 @@
Basic Deployment (CLI)
======================
With these few steps you will be able to simply deploy RDO to your environment
using our defaults in a few steps.
Prepare Your Environment
------------------------
#. Make sure you have your environment ready and undercloud running:
* :doc:`../environments/environments`
* :doc:`../installation/installing`
#. Log into your undercloud (instack) virtual machine as non-root user::
ssh root@<rdo-manager-machine>
su - stack
#. In order to use CLI commands easily you need to source needed environment
variables::
source stackrc
Get Images
----------
.. note::
If you already have images built, perhaps from a previous installation of
RDO Manager, you can simply copy those image files into your regular user's
home directory and skip this section.
If you do this, be aware that sometimes newer versions of RDO Manager 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.
The image files required are::
deploy-ramdisk-ironic.initramfs
deploy-ramdisk-ironic.kernel
discovery-ramdisk.initramfs
discovery-ramdisk.kernel
overcloud-full.initrd
overcloud-full.qcow2
overcloud-full.vmlinuz
Images must be built prior to doing a deployment. A discovery ramdisk,
deployment ramdisk, and openstack-full image can all be built using
instack-undercloud.
It's recommended to build images on the installed undercloud directly since all
the dependencies are already present.
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.
#. Choose image operating system:
The built images will automatically have the same base OS as the
running undercloud. To choose a different OS use one of the following
commands (make sure you have your OS specific content visible):
.. admonition:: CentOS
:class: centos
::
export NODE_DIST=centos7
.. admonition:: RHEL
:class: rhel
::
export NODE_DIST=rhel7
#. Build the required images:
.. only:: internal
.. admonition:: RHEL
:class: rhel
Download the RHEL 7.1 cloud image or copy it over from a different location,
and define the needed environment variable for RHEL 7.1 prior to running
``openstack overcloud image build --all``::
IMAGE=http://download.devel.redhat.com/brewroot/packages/rhel-guest-image/7.1/20150224.0/images/rhel-guest-image-7.1-20150224.0.x86_64.qcow2
curl -O $IMAGE
export DIB_LOCAL_IMAGE=`basename $IMAGE`
# Enable RHOS
export USE_DELOREAN_TRUNK=0
export RHOS=1
export DIB_YUM_REPO_CONF="/etc/yum.repos.d/rhos-release-7-director-rhel-7.1.repo /etc/yum.repos.d/rhos-release-7-rhel-7.1.repo"
.. only:: external
.. admonition:: RHEL
:class: rhel
Download the RHEL 7.1 cloud image or copy it over from a different location,
for example:
https://access.redhat.com/downloads/content/69/ver=/rhel---7/7.1/x86_64/product-downloads,
and define the needed environment variables for RHEL 7.1 prior to running
``openstack overcloud image build --all``::
export DIB_LOCAL_IMAGE=rhel-guest-image-7.1-20150224.0.x86_64.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:: 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
export REG_ACTIVATION_KEY="[activation key]"
.. note ::
By default, images are built with the latest RDO-Manager Trunk repo which has passed CI. If you need to manually test packages before CI has passed, you can use:
::
export DELOREAN_TRUNK_MGT_REPO="http://trunk-mgt.rdoproject.org/centos-kilo/current"
::
openstack overcloud image build --all
.. note::
This script will build **overcloud-full** images (\*.qcow2, \*.initrd,
\*.vmlinuz), **deploy-ramdisk-ironic** images (\*.initramfs, \*.kernel),
**discovery-ramdisk** images (\*.initramfs, \*.kernel) and **testing**
fedora-user.qcow2 (which is always Fedora based).
Upload Images
-------------
Load the images into the undercloud Glance::
openstack overcloud image upload
Register Nodes
--------------
Register nodes for your deployment with Ironic::
openstack baremetal import --json instackenv.json
.. note::
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`.
.. note::
By default Ironic will not sync the power state of the nodes,
because in our HA (high availability) model Pacemaker is the
one responsible for controlling the power state of the nodes
when fencing. If you are using a non-HA setup and want Ironic
to take care of the power state of the nodes please change the
value of the "force_power_state_during_sync" configuration option
in the /etc/ironic/ironic.conf file to "True" and restart the
openstack-ironic-conductor service.
Also, note that if "openstack undercloud install" is re-run the value
of the "force_power_state_during_sync" configuration option will be
set back to the default, which is "False".
Assign kernel and ramdisk to nodes::
openstack baremetal configure boot
Introspect Nodes
----------------
Introspect hardware attributes of nodes::
openstack baremetal introspection bulk start
.. 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`.
Introspecting a single node
^^^^^^^^^^^^^^^^^^^^^^^^^^^
You can also introspect nodes one by one.
When doing so, you must take care to set the correct node states manually.
Use ``ironic node-show UUID`` command to figure out whether nodes are in
``manageable`` or ``available`` state. For all nodes in ``available`` state,
start with putting a node to ``manageable`` state::
ironic node-set-provision-state UUID manage
Then you can run introspection::
openstack baremetal introspection start UUID
This command won't poll for the introspection result, use the following command
to check the current introspection state::
openstack baremetal introspection status UUID
Repeat it for every node until you see ``True`` in the ``finished`` field.
The ``error`` field will contain an error message if introspection failed,
or ``None`` if introspection succeeded for this node.
Do not forget to make nodes available for deployment afterwards::
ironic node-set-provision-state UUID provide
Create Flavors
--------------
Create the necessary flavor::
openstack flavor create --id auto --ram 4096 --disk 40 --vcpus 1 baremetal
openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" baremetal
Configure a nameserver for the Overcloud
----------------------------------------
Overcloud nodes need to have a configured nameserver so that they can resolve
hostnames via DNS. The nameserver is defined in the undercloud's neutron
subnet. Define the nameserver to be used for the environment::
# List the available subnets
neutron subnet-list
neutron subnet-update <subnet-uuid> --dns-nameserver <nameserver-ip>
.. note::
A public DNS server, such as 8.8.8.8 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
--------------------
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:: Ceph
:class: ceph
When deploying Ceph it is necessary to use the regular Heat templates
instead of Tuskar, to specify the number of Ceph OSD nodes to be
deployed and to provide some additional parameters to enable usage
of Ceph for Glance, Cinder, Nova or all.
Make a copy of the file ``/usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml``
and edit it as appropriate, then pass the following additional arguments::
--ceph-storage-scale <number of nodes> --templates -e /path/to/customized/storage-environment.yaml
to the deploy command below.
By default when Ceph is enabled the Cinder LVM back-end is disabled. This
behavior may be changed by also passing::
--cinder-lvm
.. 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:: Virtual
:class: virtual
The deployment defaults to using kvm as a virtualization library.
If your compute nodes are virtual machines, this ends up having
nested ``kvm`` engines which is not recommended. Therefore you should
on a virtual install use ``qemu`` as a virtualization library instead
by adding the following to the deploy command::
--libvirt-type=qemu
::
openstack overcloud deploy --templates
.. note::
To deploy the overcloud with network isolation, bonds, and/or custom
network interface configurations, instead follow the workflow here to
deploy: :doc:`../advanced_deployment/network_isolation`
Post-Deployment
---------------
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
Setup the Overcloud network
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Initial networks in Neutron in the Overlcoud 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::
neutron net-create nova --router:external --provider:network_type flat \
--provider:physical_network datacentre
neutron subnet-create --name nova --disable-dhcp \
--allocation-pool start=172.16.23.140,end=172.16.23.240 \
--gateway 172.16.23.251 nova 172.16.23.128/25
The example shows naming the network "nova" because that will make tempest
tests to pass, based on the default floating pool name set in nova.conf. You
can confirm that the network was created with::
neutron net-list
+--------------------------------------+-------------+-------------------------------------------------------+
| id | name | subnets |
+--------------------------------------+-------------+-------------------------------------------------------+
| d474fe1f-222d-4e32-802b-cde86e746a2a | nova | 01c5f621-1e0f-4b9d-9c30-7dc59592a52f 172.16.23.128/25 |
+--------------------------------------+-------------+-------------------------------------------------------+
To use a VLAN, the following example should work. Customize the address ranges
and VLAN id based on the environment::
neutron net-create nova --router:external --provider:network_type vlan \
--provider:physical_network datacentre --provider:segmentation_id 195
neutron subnet-create --name nova --disable-dhcp \
--allocation-pool start=172.16.23.140,end=172.16.23.240 \
--gateway 172.16.23.251 nova 172.16.23.128/25
Validate the Overcloud
^^^^^^^^^^^^^^^^^^^^^^
To verify the Overcloud by running Tempest::
openstack overcloud validate --overcloud-auth-url $OS_AUTH_URL \
--overcloud-admin-password $OS_PASSWORD
.. note:: The full Tempest test suite might take hours to run on a single CPU.
To run only a part of the Tempest test suite (eg. tests with ``smoke`` tag)::
openstack overcloud validate --overcloud-auth-url $OS_AUTH_URL \
--overcloud-admin-password $OS_PASSWORD \
--tempest-args smoke
Redeploy the Overcloud
^^^^^^^^^^^^^^^^^^^^^^
The overcloud can be redeployed when desired.
#. First, delete any existing Overcloud::
heat stack-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
heat stack-list
#. Although not required, introspection can be rerun::
openstack baremetal introspection bulk start
#. Deploy the Overcloud again::
openstack overcloud deploy --templates

258
doc/source/basic_deployment/basic_deployment_gui.rst
View File

@ -1,258 +0,0 @@
Basic Deployment (GUI)
======================
Access the GUI
--------------
Part of the Undercloud installation is also Tuskar-UI which you can use to drive
the deployment.
.. admonition:: Virtual
:class: virtual
In the case of a virtual deployment, Tuskar-UI runs on the instack virtual
machine on ``http://localhost/dashboard``. Considering this and the fact that
the virt host is a remote host machine, to access the UI in the browser,
follow these steps:
#. On host machine create ssh tunnel from instack vm to virt host::
ssh -g -N -L 8080:127.0.0.1:80 root@<undercloud_vm_ip>
#. On instack VM edit ``/etc/openstack-dashboard/local_settings`` and add virt host ``hostname`` to ``ALLOWED_HOSTS`` array
#. Restart Apache::
systemctl restart httpd
#. Navigate to ``http://<virt_host_hostname>:8080/dashboard`` in the browser
When logging into the dashboard the default user and password are found in the ``/root/stackrc`` file on the instack virtual machine, ``OS_USERNAME`` and ``OS_PASSWORD``.
After logging into the dashboard, make sure that the project is set to *admin* (if it is not, change the project to *admin* using the Project switcher at the top bar).
Overview Page
-------------
When you log into the GUI, you will land on the *Overview* page. This page contains all the information about the
current state of the deployment. On the left side, there is a list of available deployment roles. On the right side,
there is a deployment checklist which indicates whether all the prerequisites for the deployment have been satisfied.
Get Images
----------
To perform a successful deployment, you will need the following images: discovery ramdisk, deployment ramdisk, and
openstack-full image. To upload the images and load them into Glance, navigate to *Provisioning Images* and use the
*Create Image* button to create the necessary images. You will need to following image files handy::
overcloud-full.vmlinuz
overcloud-full.initrd
overcloud-full.qcow2
deploy-ramdisk-ironic.kernel
deploy-ramdisk-ironic.initramfs
discovery-ramdisk.kernel
discovery-ramdisk.initramfs
To create the 'overcloud-full-vmlinuz' image, fill the *Create Image* form like so::
Name: overcloud-full-vmlinuz
Image Source: Image File
Image File: overcloud-full.vmlinuz
Format: AKI
Public: checked
To create the 'overcloud-full-initrd' image, fill the *Create Image* form like so::
Name: overcloud-full-initrd
Image Source: Image File
Image File: overcloud-full.initrd
Format: ARI
Public: checked
To create the 'overcloud-full' image, fill the *Create Image* form like so::
Name: overcloud-full
Image Source: Image File
Image File: overcloud-full.qcow2
Kernel: overcloud-full-vmlinuz
Ramdisk: overcloud-full-initrd
Format: QCOW2
Public: checked
To create the 'bm-deploy-kernel' image, fill the *Create Image* form like so::
Name: bm-deploy-kernel
Image Source: Image File
Image File: deploy-ramdisk-ironic.kernel
Format: AKI
Public: checked
To create the 'bm-deploy-ramdisk' image, fill the *Create Image* form like so::
Name: bm-deploy-ramdisk
Image Source: Image File
Image File: deploy-ramdisk-ironic.initramfs
Format: ARI
Public: checked
You will also need to copy the discovery images to HTTP BOOT directory on the undercloud node. Assuming you have these
images handy in your home directory on the undercloud node, run the following commands to copy them to /httpboot::
sudo cp -f discovery-ramdisk.kernel /httpboot/discovery.kernel
sudo cp -f discovery-ramdisk.initramfs /httpboot/discovery.ramdisk
Register Nodes
--------------
To register nodes for your deployment, navigate to the *Nodes* page, and click the + sign to open the *Register Nodes* form.
This form gives you a choice of manually adding node data using the *Add* link, or supplying a CSV file with node data
using the *Upload* link. Choose one of these two options to register your nodes with Ironic. Make sure you provide, at
minimum, the *Power Management* properties, the *MAC address(es)* for the nodes and the *Deployment Images*. The rest of the
attributes are optional and in case you don't supply them, they will be obtained by running the introspection on the
nodes. When you have finished providing the node data, click the *Register Nodes* button to register your nodes.
.. note::
When using a CSV file to upload node data, make sure the fields are in this order::
driver,address,username,password/ssh key,mac addresses,cpu architecture,number of CPUs,available memory,available storage
As stated above, hardware properties (cpu architecture, number of CPUs, available memory, available storage)
are not mandatory, and in case they are not provided in the CSV file, they will be obtained via introspection.
Here are the contents of an example CSV file to register two virtual nodes::
pxe_ssh,192.168.122.1,root,"-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAw6J6supEV40toLTiH6Taj8k6bI2CSJSK31spMfLIKzPuvzCV
PGZdhKMx1o++u9TcFFh7U1caojg1Jj/XKdPcktGBQvAmiNa9nybmTjiOqq/b1svr
W1Yn23WvkEBL7peFUZVAgJDvxcf42LtA72RdgzegFdrP0y4z6UJlJRnxAckxfa/o
b05N3nrK2yteZQVuMBVB2P7QAgy62aIqJBacWrLplaZMJZZYQJ9ialXZXAMPIN3P
5l9emMOJjBbXv76G6B/Ik9J6Ryv8SFhQbLzWu1eXjT8g3d5KlD/lvh6fwN/HjYOb
6o5LvMD61vpOaR0B8Ta/+vu4R+GiLB+ArhS9WQIDAQABAoIBAAUWLGqKfMxp902+
ZkK8XpJugP5hj4mjkxjLnf6WeW3mI8cE1FyFrNjOBXW2txbbKf29bzdzhFXDcF5W
Opnz0EBhAiNjax0TuEpzEHnoLo1xlR24n534V4D1RmNRyKejeOvuHYc6PYG++VFp
TP7sdSH8SEVJMy4ifWcLOuYEDqglL1uSPQgO8HkmlvOvgI1LnLx9wjeNC1D7weZu
Eh75GTGRLL8i0X0bLmaNZ1Fs3Ge2tLNS0hfu6epCiT3ZAQTBVyFbVmN6btnQ/BHM
nDSZQ2JEDjQByCiBch9hTk/V2UNmn5dOUGPTwp2IP5Blpq2X7u1IoXQiAhI+zVcN
9mqbK6ECgYEA9hbQF7iEP4RhClNUVmQJd1zQjC2D5Vj0ik68MdgcT1QFrrCGaRPb
eayCxyDoNyUAWGtqToTQ5v3b1dxwsJryMekHD0OL75fl1KbD0bRiawVG81QbyC3U
I05Lr5LCdm80xdktC6caIkpoRF6e9xhAQduXDHZyQ6TdJtRHS6E3uPsCgYEAy4N6
xFml63vk2qFPyMkSfp82ey6YiGchXxZSDl/tDiDDHgDVRtYi5+7iCNVrjkwtUXI3
zK+G+m74AIx1C9ZSW81y5ymxKLGz1+OUy3Vtp0Zf5R1/Q+l9I4sl1dkB2wJcb2Ls
2A3yl9NEt5M3bHZUQk4ttmhfqOFiSmNd/uFbersCgYEAvlAYMDAPfnum/HBDKeiF
dZz+31mXxjeMLqYDXtzNz/+fwWBdIkgsFKX4IX1ueK8R3E990Clg0TMD3xlywPGj
WjvnrMNFJk6nfFRX3gaNkkxreWTTc3UVuRQk7iwmXadU/akd8AQT7u7yQeWXNGq5
zvS+lPHJHk0ShqPmWzPbvx8CgYBAiB9slXSsN+v4e4AeDcwkhH21D7BkSDdnvF8m
mbpEaZUVNXRrcsk8vB3GaU4in/sawVn6OIpXbMqM+fy/VSVmYL4XmLvJSJfbVBnB
binoCcOsle7d7PK2S5AiwB37gUMoOrkZRUrwY5h9kVvYs6jCIaITHgN/PIB7UAjl
IjZsswKBgC9AgnXvw4M1bcS1SK1WdJXACrmfX5tGMLzCEVJgmJtiWobvpNsfcZ/Q
EanIrYxnJ1zWZstefEuLWGzja+xwL/rsnTl77DPuvZRr/QxXMRaPFn5VTnH5kh0y
9FlihAmgG1n2k3CCFNtdxAKBqPGLz2wUuRDHYhF4WKYuvghIpQA7
-----END RSA PRIVATE KEY-----",00:d1:2c:a2:ed:58
pxe_ssh,192.168.122.1,root,"-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAw6J6supEV40toLTiH6Taj8k6bI2CSJSK31spMfLIKzPuvzCV
PGZdhKMx1o++u9TcFFh7U1caojg1Jj/XKdPcktGBQvAmiNa9nybmTjiOqq/b1svr
W1Yn23WvkEBL7peFUZVAgJDvxcf42LtA72RdgzegFdrP0y4z6UJlJRnxAckxfa/o
b05N3nrK2yteZQVuMBVB2P7QAgy62aIqJBacWrLplaZMJZZYQJ9ialXZXAMPIN3P
5l9emMOJjBbXv76G6B/Ik9J6Ryv8SFhQbLzWu1eXjT8g3d5KlD/lvh6fwN/HjYOb
6o5LvMD61vpOaR0B8Ta/+vu4R+GiLB+ArhS9WQIDAQABAoIBAAUWLGqKfMxp902+
ZkK8XpJugP5hj4mjkxjLnf6WeW3mI8cE1FyFrNjOBXW2txbbKf29bzdzhFXDcF5W
Opnz0EBhAiNjax0TuEpzEHnoLo1xlR24n534V4D1RmNRyKejeOvuHYc6PYG++VFp
TP7sdSH8SEVJMy4ifWcLOuYEDqglL1uSPQgO8HkmlvOvgI1LnLx9wjeNC1D7weZu
Eh75GTGRLL8i0X0bLmaNZ1Fs3Ge2tLNS0hfu6epCiT3ZAQTBVyFbVmN6btnQ/BHM
nDSZQ2JEDjQByCiBch9hTk/V2UNmn5dOUGPTwp2IP5Blpq2X7u1IoXQiAhI+zVcN
9mqbK6ECgYEA9hbQF7iEP4RhClNUVmQJd1zQjC2D5Vj0ik68MdgcT1QFrrCGaRPb
eayCxyDoNyUAWGtqToTQ5v3b1dxwsJryMekHD0OL75fl1KbD0bRiawVG81QbyC3U
I05Lr5LCdm80xdktC6caIkpoRF6e9xhAQduXDHZyQ6TdJtRHS6E3uPsCgYEAy4N6
xFml63vk2qFPyMkSfp82ey6YiGchXxZSDl/tDiDDHgDVRtYi5+7iCNVrjkwtUXI3
zK+G+m74AIx1C9ZSW81y5ymxKLGz1+OUy3Vtp0Zf5R1/Q+l9I4sl1dkB2wJcb2Ls
2A3yl9NEt5M3bHZUQk4ttmhfqOFiSmNd/uFbersCgYEAvlAYMDAPfnum/HBDKeiF
dZz+31mXxjeMLqYDXtzNz/+fwWBdIkgsFKX4IX1ueK8R3E990Clg0TMD3xlywPGj
WjvnrMNFJk6nfFRX3gaNkkxreWTTc3UVuRQk7iwmXadU/akd8AQT7u7yQeWXNGq5
zvS+lPHJHk0ShqPmWzPbvx8CgYBAiB9slXSsN+v4e4AeDcwkhH21D7BkSDdnvF8m
mbpEaZUVNXRrcsk8vB3GaU4in/sawVn6OIpXbMqM+fy/VSVmYL4XmLvJSJfbVBnB
binoCcOsle7d7PK2S5AiwB37gUMoOrkZRUrwY5h9kVvYs6jCIaITHgN/PIB7UAjl
IjZsswKBgC9AgnXvw4M1bcS1SK1WdJXACrmfX5tGMLzCEVJgmJtiWobvpNsfcZ/Q
EanIrYxnJ1zWZstefEuLWGzja+xwL/rsnTl77DPuvZRr/QxXMRaPFn5VTnH5kh0y
9FlihAmgG1n2k3CCFNtdxAKBqPGLz2wUuRDHYhF4WKYuvghIpQA7
Introspect Nodes
----------------
When registering nodes as described above, if you leave out any of the hardware properties for any of the nodes,
introspection will be run on the nodes to obtain these missing properties, as soon as you click the *Register Nodes*
button. In this case, the nodes will be located in the *Maintenance* tab and will have the status *Discovering*. After
the introspection process has finished (this can take up to 5 minutes for VM / 15 minutes for baremetal), the hardware
properties will get populated and the nodes will have the status *Discovered*. At this point, you can move the nodes
to the *Free* tab, by selecting them using the checkbox on the left side and clicking the *Activate Nodes* button. Now
the nodes are ready and available for deployment.
Create Flavors
--------------
To create the necessary flavor, navigate to the *Flavors* page. One suggested flavor, matching the hardware properties
of the created nodes, will be available. To create it, open the dropdown menu under *Actions*, click *Edit before creating*,
change the name to 'baremetal' and click the *Create Flavors* button.
Configure Roles
---------------
To configure deployment roles, navigate to the *Deployment Roles* page. *Flavor* and *Image* needs to be set to all the
deployment roles. For each of the deployment roles, click the *edit* button and set the *Flavor* to 'baremetal' and
*Image* to 'overcloud-full'. Save the form.
Service Configuration
---------------------
To perform the necessary service configuration, navigate to the *Service Configuration* page and click the
*Simplified Configuration* button. In the *Service Configuration* form, make sure that the values of the *Deployment Type*
and *Public Interface* fields are correct. Also make sure you set the *SNMP Password* and the *Cloud name*.
Deploy the Overcloud
--------------------
To deploy the overcloud, navigate to the *Overview* page. The deployment plan validation will be performed and if the
plan is valid, the *Verify and Deploy* button will be enabled. Click this button to open the deployment confirmation
dialog. In case you want to enable network isolation, check the *Enable Network Isolation* box. Click *Deploy*.
This will trigger the creation of the overcloud heat stack. The page will reload and you will be able to monitor the
current status of the deployment. On the right side you will see the progress bar as well as the last event from
the Heat event list. If you want to see the full event list, you can navigate to the *Deployment Log* page.
Initialize the Overcloud
------------------------
Once the deployment has successfully completed, you need to perform the initialization of Keystone and Neutron in the
overcloud. To do this, click the *Initialize* button, fill out the form and click *Initialize*. Once the initialization has
completed, the page will reload and you will see deployment details on the *Overview* page. On the left side the
information about roles and node counts will be displayed, along with the system load charts for each deployment role.
On the right side, the access information for the overcloud Horizon will be displayed.
Post-Deployment
---------------
Access the Overcloud
^^^^^^^^^^^^^^^^^^^^
When the overcloud is deployed, the access information needed to to log into the overcloud Horizon is located on
the *Overview* page.
Redeploy the Overcloud
^^^^^^^^^^^^^^^^^^^^^^
The overcloud can be redeployed when desired. First, you have to delete the existing overcloud by clicking the
*Undeploy* button on the *Overview* page. This will trigger the deletion of the Heat stack. After the overcloud has been
deleted, the *Overview* page will again display the deployment checklist along with the *Verify and Deploy* button. If you
wish to deploy the overcloud again, repeat the steps from the *Deploy the Overcloud* section on this page.

245
doc/source/conf.py
View File

@ -1,245 +0,0 @@
# -*- coding: utf-8 -*-
#
# 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 sys, os
import sphinx_rtd_theme
# 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 = []
# Add any paths that contain templates here, relative to this directory.
templates_path = ['_templates']
# The suffix of source filenames.
source_suffix = '.rst'
# The encoding of source files.
#source_encoding = 'utf-8-sig'
# The master toctree document.
master_doc = 'index'
# General information about the project.
project = u'RDO-Manager'
copyright = u'2015, RDO Community'
# 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 = 'sphinx'
# A list of ignored prefixes for module index sorting.
#modindex_common_prefix = []
# -- Options for HTML output ---------------------------------------------------
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
html_theme = 'sphinx_rtd_theme'
# Theme options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the
# documentation.
html_theme_options = {}
# Add any paths that contain custom themes here, relative to this directory.
html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
# The name for this set of Sphinx documents. If None, it defaults to
# "<project> v<release> documentation".
#html_title = None
# A shorter title for the navigation bar. Default is the same as html_title.
#html_short_title = None
# The name of an image file (relative to this directory) to place at the top
# of the sidebar.
html_logo = '_images/rdo-manager-logo.png'
# The name of an image file (within the static path) to use as favicon of the
# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
# pixels large.
#html_favicon = None
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
html_static_path = ['_custom']
html_style = 'custom.css'
# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
# using the given strftime format.
html_last_updated_fmt = '%b %d, %Y'
# If true, SmartyPants will be used to convert quotes and dashes to
# typographically correct entities.
#html_use_smartypants = True
# Custom sidebar templates, maps document names to template names.
#html_sidebars = {}
# Additional templates that should be rendered to pages, maps page names to
# template names.
#html_additional_pages = {}
# If false, no module index is generated.
#html_domain_indices = True
# If false, no index is generated.
#html_use_index = True
# If true, the index is split into individual pages for each letter.
#html_split_index = False
# If true, links to the reST sources are added to the pages.
html_show_sourcelink = True
# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
html_show_sphinx = True
# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
html_show_copyright = True
# If true, an OpenSearch description file will be output, and all pages will
# contain a <link> tag referring to it. The value of this option must be the
# base URL from which the finished HTML is served.
#html_use_opensearch = ''
# This is the file name suffix for HTML files (e.g. ".xhtml").
#html_file_suffix = None
# Output file base name for HTML help builder.
htmlhelp_basename = 'rdo-manager-doc'
# -- Options for LaTeX output --------------------------------------------------
latex_elements = {
# The paper size ('letterpaper' or 'a4paper').
#'papersize': 'letterpaper',
# The font size ('10pt', '11pt' or '12pt').
#'pointsize': '10pt',
# Additional stuff for the LaTeX preamble.
#'preamble': '',
}
# Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title, author, documentclass [howto/manual]).
latex_documents = [
('index', 'rdo-manager.tex', u'RDO-Manager Documentation',
u'RDO Community', 'manual'),
]
# The name of an image file (relative to this directory) to place at the top of
# the title page.
#latex_logo = None
# For "manual" documents, if this is true, then toplevel headings are parts,
# not chapters.
#latex_use_parts = False
# If true, show page references after internal links.
#latex_show_pagerefs = False
# If true, show URL addresses after external links.
#latex_show_urls = False
# Documents to append as an appendix to all manuals.
#latex_appendices = []
# If false, no module index is generated.
#latex_domain_indices = True
# -- Options for manual page output --------------------------------------------
# One entry per manual page. List of tuples
# (source start file, name, description, authors, manual section).
man_pages = [
('index', 'rdo-manager', u'RDO-Manager Documentation',
[u'RDO Community'], 1)
]
# If true, show URL addresses after external links.
#man_show_urls = False
# -- Options for Texinfo output ------------------------------------------------
# Grouping the document tree into Texinfo files. List of tuples
# (source start file, target name, title, author,
# dir menu entry, description, category)
texinfo_documents = [
('index', 'rdo-manager', u'RDO-Manager Documentation',
u'RDO Community', 'RDO-Manager', 'One line description of project.',
'Miscellaneous'),
]
# Documents to append as an appendix to all manuals.
#texinfo_appendices = []
# If false, no module index is generated.
#texinfo_domain_indices = True
# How to display URL addresses: 'footnote', 'no', or 'inline'.
#texinfo_show_urls = 'footnote'

92
doc/source/contributions/contributions.rst
View File

@ -1,92 +0,0 @@
How to Contribute
=================
RDO-Manager source code is available. You can contribute code to individual
projects, documentation, report bugs and vulnerabilities, request features.
Contributing Code
-----------------
As long as RDO-Manager is a set of integrated OpenStack projects, all
development is happening in OpenStack upstream.
Learn `how to contribute into OpenStack's upstream <https://wiki.openstack.org/
wiki/How_To_Contribute>`_.
See :doc:`../introduction/components` to find out how to contribute into
individual projects.
..
<TODO UNCOMMENT WHEN THE DOCS ARE MOVED UNDER rdo-maangement/docs>
Contributing to this Documentation
-----------------------------------
RDO-Manager User Documentation lives on Github under RDO-Management
organization.
Learn `how to contribute into RDO-Manager Docs
<https://github.com/rdo-management/docs>`_.
Reporting Bugs
--------------
**OpenStack Upstream**: If you find bugs or volnurabilities which affect
upstream projects, please follow OpenStack's process of filing bugs.
* Learn `how to create Bugs in OpenStack
<https://wiki.openstack.org/wiki/Bugs>`_.
* If you want to file a bug against upstream project, you can find useful links
in our list of :doc:`../introduction/components`.
**RDO-Manager**: If the bug impacts RDO-Manager as a distribution of the TripleO
Installer, you can file a bug against Bugzilla:
#. Go to https://bugzilla.redhat.com/enter_bug.cgi?product=RDO
#. Choose component: **rdo-manager** (or any related individual project)
#. Fill in needed information (If you filed also upstream bug, please provide
its URL in advanced fields)
#. Submit bug
.. note:: If you follow base Bugzilla link, you need to select following: Enter
a new bug report -> Community -> RDO
Requesting Features
-------------------
**OpenStack Upstream**: Since we are developing projects in OpenStack community,
all the features are being requested upstream via Blueprints.
* Learn `how to create Blueprints in OpenStack
<https://wiki.openstack.org/wiki/Blueprints>`_.
* If you want to file a bug against upstream project, you can find useful links
in our list of :doc:`../introduction/components`.
**RDO-Manager**: If the feature concerns our community distribution named
RDO-Manager, you can use Bugzilla to enter new RFE (Request For Enhancement):
#. Go to https://bugzilla.redhat.com/enter_bug.cgi?product=RDO
#. Choose component: **rdo-manager**
#. Use '[RFE]' in the beginning of your Summary for quick identification
#. Display Advanced fields and enter new Kewyord 'RFE'
#. Fill in needed information (If you filed also upstream blueprint, please
provide its URL in advanced fields)
#. Submit "bug"
.. note:: If you follow base Bugzilla link, you need to select following: Enter
a new bug report -> Community -> RDO

244
doc/source/environments/baremetal.rst
View File

@ -1,244 +0,0 @@
Baremetal Environment
=====================
RDO-Manager 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 RDO cloud with RDO-Manager you need the following baremetal
machines:
* 1 Undercloud (where RDO-Manager lives)
* 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:
* multi-core CPU
* 4 GB memory
* 60 GB free disk space
RDO-Manager is supporting only the following operating systems:
* RHEL 7.1 x86_64 or
* CentOS 7 x86_64
Preparing the Baremetal Environment
-----------------------------------
Networking
^^^^^^^^^^
The overcloud nodes will be deployed from the undercloud machine and therefore the machines need to have have their network settings modified to allow for the overcloud nodes to be PXE boot'ed 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 7.1 x86_64 or CentOS 7 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
.. only:: external
.. 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-7-server-rpms \
--enable=rhel-7-server-optional-rpms --enable=rhel-7-server-extras-rpms \
--enable=rhel-7-server-openstack-6.0-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-7-server-rpms
rhel-7-server-optional-rpms
rhel-7-server-extras-rpms
rhel-7-server-openstack-6.0-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/
Configuration Files
-------------------
instackenv.json
^^^^^^^^^^^^^^^
Create a JSON file describing your 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 Drivers`_ 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:
* ``mac`` - list of MAC addresses, optional for bare metal
* ``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
For example::
{
"nodes": [
{
"pm_type":"pxe_ipmitool",
"mac":[
"fa:16:3e:2a:0e:36"
],
"cpu":"2",
"memory":"4096",
"disk":"40",
"arch":"x86_64",
"pm_user":"admin",
"pm_password":"password",
"pm_addr":"10.0.0.8"
},
{
"pm_type":"pxe_ipmitool",
"mac":[
"fa:16:3e:da:39:c9"
],
"cpu":"2",
"memory":"4096",
"disk":"40",
"arch":"x86_64",
"pm_user":"admin",
"pm_password":"password",
"pm_addr":"10.0.0.15"
},
{
"pm_type":"pxe_ipmitool",
"mac":[
"fa:16:3e:51:9b:68"
],
"cpu":"2",
"memory":"4096",
"disk":"40",
"arch":"x86_64",
"pm_user":"admin",
"pm_password":"password",
"pm_addr":"10.0.0.16"
}
]
}
Ironic Drivers
--------------
Ironic drivers provide various level of support for different hardware.
The most up-to-date information about Ironic drivers is at
http://docs.openstack.org/developer/ironic/deploy/drivers.html, but note that
this page always targets Ironic git master, not the release we use.
There are 2 generic drivers:
* ``pxe_ipmitool`` driver uses `ipmitool`_ utility to manage a bare metal
node, and supports fast variaty of hardware.
* ``pxe_ssh`` is a special driver for testing Ironic in the virtual
environment. This driver connects to the hypervisor to conduct management
operations on virtual nodes. In case of this driver, ``pm_addr`` is a
hypervisor address, ``pm_user`` is a SSH user name for accessing hypervisor,
``pm_password`` is a private SSH key for accessing hypervisor. Note that
private key must not be encrypted.
Ironic also provides specific drivers for some types of hardware:
* ``pxe_ilo`` targets HP Proliant Gen 8 and Gen 9 systems, and is recommended
for these systems instead of ``pxe_ipmitool``. Please refer to the `current
iLO driver documentation`_ or `detailed iLO documentation for Kilo version`_.
* ``pxe_drac`` targets DELL 11G and newer systems, and is recommended for these
systems instead of ``pxe_ipmitool``.
There are also 2 testing drivers:
* ``fake_pxe`` provides stubs instead of real power and management operations.
When using this driver, you have to conduct power on and off operations,
and set the current boot device, yourself.
* ``fake`` provides stubs for every operation, so that Ironic does not touch
hardware at all.
.. _ipmitool: http://sourceforge.net/projects/ipmitool/
.. _current iLO driver documentation: http://docs.openstack.org/developer/ironic/drivers/ilo.html
.. _detailed iLO documentation for Kilo version: https://wiki.openstack.org/wiki/Ironic/Drivers/iLODrivers/Kilo

10
doc/source/environments/environments.rst
View File

@ -1,10 +0,0 @@
Environment Setup
=================
RDO-Manager can be used in baremetal as well as in virtual environments. This
section contains instructions on how to setup your environments properly.
.. toctree::
Virtual Environment <virtual>
Baremetal Environment <baremetal>

305
doc/source/environments/virtual.rst
View File

@ -1,305 +0,0 @@
Virtual Environment
===================
RDO-Manager 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.
Minimum System Requirements
---------------------------
By default, this setup creates 3 virtual machines:
* 1 Undercloud
* 1 Overcloud Controller
* 1 Overcloud Compute
Each virtual machine must consist of at least 4 GB of memory and 40 GB of disk
space [#]_.
.. note::
The virtual machine disk files are thinly provisioned and will not take up
the full 40GB initially.
The baremetal machine must meet the following minimum system requirements:
* Virtualization hardware extenstions enabled (nested KVM is **not** supported)
* 1 quad core CPU
* 12 GB free memory
* 120 GB disk space
..
<REMOVE WHEN HA IS AVAILABLE>
For minimal **HA (high availability)** deployment you need at least 3 Overcloud
Controllers and 2 Overcloud Computes which increases the minimum system
requirements up to:
* 24 GB free memory
* 240 GB disk space.
RDO-Manager is supporting only the following operating systems:
* RHEL 7.1 x86_64 or
* CentOS 7 x86_64
.. _preparing_virtual_environment:
Preparing the Virtual Environment (Automated)
---------------------------------------------
#. Install RHEL 7.1 Server x86_64 or CentOS 7 x86_64 on your host machine.
.. only:: external
.. 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-7-server-rpms \
--enable=rhel-7-server-optional-rpms --enable=rhel-7-server-extras-rpms \
--enable=rhel-7-server-openstack-6.0-rpms
.. admonition:: RHEL Satellite Registration
:class: satellite
To register the host machine to a Satellite, the following repos must
be synchronized on the Satellite::
rhel-7-server-rpms
rhel-7-server-optional-rpms
rhel-7-server-extras-rpms
rhel-7-server-openstack-6.0-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.
#. Make sure sshd service is installed and running.
#. The user performing all of the installation steps on the virt host needs to
have sudo enabled. You can use an existing user or use the following commands
to create a new user called stack with password-less sudo enabled. Do not run
the rest of the steps in this guide as root.
* Example commands to create a user::
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
#. Make sure you are logged in as the non-root user you intend to use.
* Example commands to log in as the non-root user::
su - stack
#. Enable needed repositories:
.. only:: internal
.. admonition:: RHEL
:class: rhel
Enable rhos-release::
sudo rpm -ivh http://rhos-release.virt.bos.redhat.com/repos/rhos-release/rhos-release-latest.noarch.rpm
# Enable either poodles or puddles:
# To enable poodles:
sudo rhos-release 7-director -d
# To enable puddles:
sudo rhos-release 7-director
# We need openwsman-python from the optional repo
sudo yum install -y yum-utils
sudo yum-config-manager --enable rhelosp-rhel-7-server-opt
.. note::
If testing RDO as opposed to RHOS, you need to enable some extra
repositories:
::
# Enable RDO Kilo
sudo yum install -y https://rdoproject.org/repos/openstack-kilo/rdo-release-kilo.rpm
# Enable RDO-Manager Trunk
sudo curl -o /etc/yum.repos.d/rdo-management-trunk.repo http://trunk-mgt.rdoproject.org/centos-kilo/current-passed-ci/delorean-rdo-management.repo
The above RDO-Manager Trunk repo is updated after a successful CI run. The following repo can be used instead if the newest packages are needed before a CI run has passed.
::
sudo curl -o /etc/yum.repos.d/rdo-management-trunk.repo http://trunk-mgt.rdoproject.org/centos-kilo/current/delorean-rdo-management.repo
#. Install instack-undercloud::
sudo yum install -y instack-undercloud
#. The virt setup automatically sets up a vm for the Undercloud installed with
the same base OS as the host. See the Note below to choose a different
OS.:
.. note::
To setup the undercloud vm with a base OS different from the host,
set the ``$NODE_DIST`` environment variable prior to running
``instack-virt-setup``:
.. admonition:: CentOS
:class: centos
::
export NODE_DIST=centos7
.. admonition:: RHEL
:class: rhel
::
export NODE_DIST=rhel7
#. Run the script to setup your virtual environment:
.. note::
By default, VMs will be created with 1 vCPU and 4096 MiB RAM. To adjust
those values::
export NODE_CPU=4
export NODE_MEM=16384
.. only:: internal
.. admonition:: RHEL
:class: rhel
Download the RHEL 7.1 cloud image or copy it over from a different
location, and define the needed environment variables for RHEL 7.1 prior
to running ``instack-virt-setup``::
IMAGE=http://download.devel.redhat.com/brewroot/packages/rhel-guest-image/7.1/20150224.0/images/rhel-guest-image-7.1-20150224.0.x86_64.qcow2
curl -O $IMAGE
export DIB_LOCAL_IMAGE=`basename $IMAGE`
export DIB_YUM_REPO_CONF="/etc/yum.repos.d/rhos-release-7-director-rhel-7.1.repo /etc/yum.repos.d/rhos-release-7-rhel-7.1.repo"
.. only:: external
.. admonition:: RHEL
:class: rhel
Download the RHEL 7.1 cloud image or copy it over from a different
location, for example: https://access.redhat.com/downloads/content/69/ver=/rhel---7/7.1/x86_64/product-downloads,
and define the needed environment variables for RHEL 7.1 prior to
running ``instack-virt-setup``::
export DIB_LOCAL_IMAGE=rhel-guest-image-7.1-20150224.0.x86_64.qcow2
.. admonition:: RHEL Portal Registration
:class: portal
To register the Undercloud vm 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:: RHEL Satellite Registration
:class: satellite
To register the Undercloud vm 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
export REG_ACTIVATION_KEY="[activation key]"
.. admonition:: Ceph
:class: ceph
To use Ceph you will need at least one additional virtual machine to be
provisioned as a Ceph OSD; set the ``NODE_COUNT`` variable to 3, from a
default of 2, so that the overcloud will have exactly one more::
export NODE_COUNT=3
.. note::
The ``TESTENV_ARGS`` environment variable can be used to customize the
virtual environment configuration. For example, it could be used to
enable additional networks as follows::
export TESTENV_ARGS="--baremetal-bridge-names 'brbm brbm1 brbm2'"
::
instack-virt-setup
If the script encounters problems, see
:doc:`../troubleshooting/troubleshooting-virt-setup`.
When the script has completed successfully it will output the IP address of the
instack vm that has now been installed with a base OS.
Running ``sudo virsh list --all`` [#]_ will show you now have one virtual machine called
*instack* and 2 called *baremetal[0-1]*.
You can ssh to the instack vm as the root user::
ssh root@<instack-vm-ip>
The vm contains a ``stack`` user to be used for installing the undercloud. You
can ``su - stack`` to switch to the stack user account.
Continue with :doc:`../installation/installing`.
.. rubric:: Footnotes
.. [#] Note that some default partitioning scheme will most likely not provide
enough space to the partition containing the default path for libvirt image
storage (/var/lib/libvirt/images). The easiest fix is to customize the
partition layout at the time of install to provide at least 200 GB of space for
that path.
.. [#] The libvirt virtual machines have been defined under the system
instance (qemu:///system). The user account executing these instructions
gets added to the libvirtd group which grants passwordless access to
the system instance. It does however require logging into a new shell (or
desktop environment session if wanting to use virt-manager) before this
change will be fully applied. To avoid having to re-login, you can use
``sudo virsh``.
.. _Red Hat Satellite User Guide: https://access.redhat.com/documentation/en-US/Red_Hat_Satellite/

69
doc/source/index.rst
View File

@ -1,69 +0,0 @@
Welcome to RDO-Manager documentation
====================================
On these sites we are going to explain what `RDO-Manager <introduction/
introduction.html>`_ is and guide you how to use it to successfuly deploy and
manage `RDO <http://rdoproject.org>`_ (OpenStack packaged for Fedora, Centos and
RHEL distributions).
Contents:
.. toctree::
:maxdepth: 2
Introduction <introduction/introduction>
Environment Setup <environments/environments>
Undercloud Installation <installation/installation>
Basic Deployment (CLI) <basic_deployment/basic_deployment_cli>
Basic Deployment (GUI) <basic_deployment/basic_deployment_gui>
Advanced Deployment <advanced_deployment/advanced_deployment>
Post Deployment <post_deployment/post_deployment>
Troubleshooting <troubleshooting/troubleshooting>
How to Contribute <contributions/contributions>
Documentation Conventions
=========================
Some steps in the following instructions only apply to certain environments,
such as deployments to real baremetal and deployments using RHEL. These
steps are marked as follows:
.. admonition:: RHEL
:class: rhel
Step that should only be run when using RHEL
.. admonition:: Portal Registration
:class: portal
Step that should only be run when using Portal Registration
.. admonition:: Satellite Registration
:class: satellite
Step that should only be run when using Satellite Registration
.. admonition:: CentOS
:class: centos
Step that should only be run when using CentOS
.. admonition:: Baremetal
:class: baremetal
Step that should only be run when deploying to baremetal
.. admonition:: Virtual
:class: virtual
Step that should only be run when deploying to virtual machines
.. admonition:: Ceph
:class: ceph
Step that should only be run when deploying Ceph for use by the Overcloud
Any such steps should *not* be run if the target environment does not match
the section marking.

30
doc/source/installation/accessing_gui.rst
View File

@ -1,30 +0,0 @@
Accessing the GUI
=================
Part of the Undercloud installation is also Tuskar-UI which you can use to drive
the deployment. It runs on the instack virtual machine on ``http://localhost/dashboard``
Example of how to access Tuskar-UI:
-----------------------------------
Considering that Tuskar-UI runs in a instack VM and virt host is a remote host
machine, to access the UI in the browser, follow these steps:
#. On host machine create ssh tunnel from instack vm to virt host::
ssh -g -N -L 8080:127.0.0.1:80 root@<undercloud_vm_ip>
#. On instack VM edit ``/etc/openstack-dashboard/local_settings`` and add virt host ``hostname`` to ``ALLOWED_HOSTS`` array
#. Restart Apache::
systemctl restart httpd
#. Allow port ``8080`` on host machine::
sudo iptables -I INPUT -p tcp -m tcp --dport 8080 -j ACCEPT
#. Navigate to ``http://<virt_host_hostname>:8080/dashboard`` in the browser
When logging into the dashboard the default user and password are found in the ``/root/stackrc`` file on the instack virtual machine, ``OS_USERNAME`` and ``OS_PASSWORD``.

10
doc/source/installation/installation.rst
View File

@ -1,10 +0,0 @@
Undercloud Installation
=======================
This section contains instructions on how to install the undercloud and how to
update components after installation.
.. toctree::
Installing the Undercloud <installing>
Updating Undercloud Components <updating>

121
doc/source/installation/installing.rst
View File

@ -1,121 +0,0 @@
Installing the Undercloud
==========================
#. 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>@<rdo-manager-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, and
cannot be installed to a system with SELinux disabled. If SELinux
enforcement must be turned off for some reason, it should instead be set
to permissive.
.. admonition:: Baremetal
:class: baremetal
Ensure that there is a FQDN hostname set and that the $HOSTNAME environment
variable matches that value.
Use ``hostnamectl`` to set a hostname if needed::
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
#. Enable needed repositories:
.. only:: internal
.. admonition:: RHEL
:class: rhel
Enable rhos-release::
sudo rpm -ivh http://rhos-release.virt.bos.redhat.com/repos/rhos-release/rhos-release-latest.noarch.rpm
# Enable either poodles or puddles:
# To enable poodles:
sudo rhos-release 7-director -d
# To enable puddles:
sudo rhos-release 7-director
.. only:: external
.. admonition:: RHEL
:class: rhel
Enable optional repo::
sudo yum install -y yum-utils
sudo yum-config-manager --enable rhelosp-rhel-7-server-opt
.. note::
If testing RDO as opposed to RHOS, you need to enable some extra
repositories:
::
# Enable RDO Kilo
sudo yum install -y https://rdoproject.org/repos/openstack-kilo/rdo-release-kilo.rpm
# Enable RDO-Manager Trunk
sudo curl -o /etc/yum.repos.d/rdo-management-trunk.repo http://trunk-mgt.rdoproject.org/centos-kilo/current-passed-ci/delorean-rdo-management.repo
The above RDO-Manager Trunk repo is updated after a successful CI run. The following repo can be used instead if the newest packages are needed before a CI run has passed.
::
sudo curl -o /etc/yum.repos.d/rdo-management-trunk.repo http://trunk-mgt.rdoproject.org/centos-kilo/current/delorean-rdo-management.repo
#. Install the RDO Manager CLI, which will pull in all other necessary packages as dependencies::
sudo yum install -y python-rdomanager-oscplugin
#. Run the script to install the undercloud:
.. admonition:: Baremetal
:class: baremetal
Copy in the sample configuration file and edit it to reflect your environment::
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf
Install the undercloud::
openstack undercloud install
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. ``undercloud-passwords.conf``
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::
Any passwords set in ``undercloud.conf`` will take precedence over the ones in
``undercloud-passwords.conf``.

19
doc/source/installation/updating.rst
View File

@ -1,19 +0,0 @@
Updating Undercloud Components
------------------------------
You can upgrade any packages that are installed on the undercloud machine.
#. Update the RDO-Manager Trunk repository::
# Remove old and enable new RDO-Manager Trunk
sudo rm /etc/yum.repos.d/rdo-management-trunk.repo
sudo curl -o /etc/yum.repos.d/rdo-management-trunk.repo http://trunk-mgt.rdoproject.org/centos-kilo/current-passed-ci/delorean-rdo-management.repo
#. Use yum to update all installed packages::
sudo yum update -y
# You can specify the package names to update as options in the yum update command.
You do not need to restart any services after you update.

422
doc/source/introduction/architecture.rst
View File

@ -1,422 +0,0 @@
RDO-Manager Architecture
========================
This document lists the main components of RDO-Manager, and gives some
description of how each component is used. There are links to additional sources
of information throughout the document.
.. contents::
:depth: 3
:backlinks: none
Architecture Overview
---------------------
RDO-Manager is a community developed approach and set of tools for deploying,
and managing OpenStack cloud which is built upon the `TripleO
<https://wiki.openstack.org/wiki/TripleO>`_ project and its philosophy is
inspired by `SpinalStack <http://spinal-stack.readthedocs.org/en/latest/>`_.
TripleO
^^^^^^^
TripleO is the friendly name for "OpenStack on OpenStack". It is an official
OpenStack program with the goal of allowing you to deploy and manage a
production cloud onto bare metal hardware using a subset of existing OpenStack
components.
.. image:: ../_images/overview.png
With TripleO, you start by creating an "undercloud" (a deployment cloud)
that will contain the necessary OpenStack components to deploy and manage an
"overcloud" (a workload cloud). The overcloud is the deployed solution
and can represent a cloud for any purpose (e.g. production, staging, test, etc).
The operator can choose any OpenStack components they want for the overcloud.
.. image:: ../_images/logical_view.png
TripleO leverages several existing core components of OpenStack including Nova,
Neutron, Heat, Glance and Ceilometer to deploy OpenStack on hardware. Nova and
Ironic are used in the undercloud to manage bare metal instances that comprise
the infrastructure for the overcloud. Neutron is utilized to provide a
networking environment in which to deploy the overcloud, machine images are
stored in Glance and Ceilometer collects metrics about your overcloud.
The following diagram illustrates a physical view of how the undercloud may be
hosted on one physical server and the overcloud distributed across many physical
servers.
.. image:: ../_images/physical_view.png
SpinalStack's Inspiration
^^^^^^^^^^^^^^^^^^^^^^^^^
Some key aspects of SpinalStack workflow have been incorporated into
RDO-Manager, providing options to perform introspection, benchmarking and role
matching of your hardware prior to deploying OpenStack.
Hardware introspection features enable you to collect data about the properties
of your hardware prior to deployment, such that specific classes of hardware may
be matched to specific roles (e.g a special hardware configuration for Compute,
or Storage roles). There is also the option to enable performance benchmarking
during this phase, such that outliers which do not match the expected
performance profile may be excluded from the deployment.
RDO-Manager also configures servers in a similar way to SpinalStack, using
stable community puppet implementations, applied in a series of passes, such
that granular control and validation of the deployment is possible
Benefits
--------
Using RDO-Manager's combination of OpenStack components, and their APIs, as the
infrastructure to deploy and operate OpenStack itself delivers several benefits:
* RDO-Manager's APIs are the OpenStack APIs. They're well maintained, well
documented, and come with client libraries and command line tools. Users who
invest time in learning about RDO-Manager's APIs are also learning about
OpenStack itself, and users who are already familiar with OpenStack will find
a great deal in RDO-Manager that they already understand.
* Using the OpenStack components allows more rapid feature development of
RDO-Manager than might otherwise be the case; RDO-Manager automatically
inherits all the new features which are added to Glance, Heat etc., even when
the developer of the new feature didn't explicitly have TripleO and
RDO-Manager in mind.
* The same applies to bug fixes and security updates. When OpenStack developers
fix bugs in the common components, those fixes are inherited by RDO-Manager.
* Users' can invest time in integrating their own scripts and utilities with
RDO-Manager's APIs with some confidence. Those APIs are cooperatively
maintained and developed by the OpenStack community. They're not at risk of
being suddenly changed or retired by a single controlling vendor.
* For developers, tight integration with the OpenStack APIs provides a solid
architecture, which has gone through extensive community review.
It should be noted that not everything in RDO-Manager is a reused OpenStack
element. The Tuskar API, for example (which lets users design the workload cloud
that they want to deploy), is found in RDO-Manager but not, so far at least, in
a typical Openstack instance. The Tuskar API is described in more detail below.
Deployment Workflow Overview
----------------------------
#. Environment Preparation
* Prepare your environment (baremetal or virtual)
* Install undercloud
#. Undercloud Data Preparation
* Create images to establish the overcloud
* Register hardware nodes with undercloud
* Introspect hardware
* Create flavors (node profiles)
#. Deployment Planning
* Configure overcloud roles
* Assign flavor (node profile to match desired hardware specs)
* Assign image (provisioning image)
* Size the role (how many instances to deploy)
* Configure service parameters
* Create a Heat template describing the overcloud (auto-generated from above)
#. Deployment
* Use Heat to deploy your template
* Heat will use Nova to identify and reserve the appropriate nodes
* Nova will use Ironic to startup nodes and install the correct images
#. Per-node Setup
* When each node of the overcloud starts it will gather its configuration
metadata from Heat Template configuration files
* Hiera files are distributed across all nodes and Heat applies puppet
manifests to configure the services on the nodes
* Puppet runs in multiple steps, so that after each step there can be test
triggered to check progress of the deployment and allow easier debugging.
#. Overcloud Initialization
* Services on nodes of the overcloud are registered with Keystone
Deployment Workflow Detail
--------------------------
Environment Preparation
^^^^^^^^^^^^^^^^^^^^^^^
In the first place, you need to check that your environment is ready.
RDO-Manager can deploy OpenStack into baremetal as well as virtual environments.
You need to make sure that your environment satisfies minimum requirements for
given environment type and that networking is correctly set up.
Next step is to install the undercloud. We install undercloud using `Instack
<https://github.com/rdo-management/instack-undercloud>`_'s script and it calls
puppet scripts in the background. Upstream TripleO developers also use the
developer-based steps known as `devtest <http://docs.openstack.org/developer/
tripleo-incubator/devtest.html>`_.
Undercloud Data Preparation
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Images
""""""
Before deploying the overcloud, you must first download or build images which
will be installed on each of the nodes of the overcloud. TripleO uses
`diskimage-builder <https://github.com/openstack/diskimage-builder>`_ for
building these so called "Golden Images". The diskimage-builder tool takes a
base image e.g. `CentOS 7 <http://cloud.centos.org/centos/7/images/
CentOS-7-x86_64-GenericCloud.qcow2>`_ and then layers additional software via
configuration scripts (called elements) on top of that. The final result is a
qcow2 formatted image with software installed but not configured.
While the diskimage-builder repository provides operating-system specific
elements, ones specific to OpenStack, e.g. nova-api, are found in
`tripleo-image-elements <https://github.com/openstack/tripleo-image-elements>`_.
You can add different elements to an image to provide specific applications and
services. Once all the images required to deploy the overcloud are built, they
are stored in Glance running on the undercloud.
Nodes
"""""
Deploying the overcloud requires suitable hardware. The first task is to
register the available hardware with Ironic, OpenStack's equivalent of a
hypervisor for managing baremetal servers. User can define the hardware
attributes (such as number of CPUs, RAM, disk) manually or he can leave the
fields out and run introspection of the nodes afterwards.
The sequence of events is pictured below:
.. image:: ../_images/discovery_diagram.png
* The user, via the GUI, the command-line tools, or through direct API calls,
registers the power management credentials for a node with Ironic.
* The user then instructs Ironic to reboot the node.
* Because the node is new, and not already fully registered, there are no
specific PXE-boot instructions for it. In that case, the default action is to
boot into a discovery ramdisk
* The discovery ramdisk probes the hardware on the node and gathers facts,
including the number of CPU cores, the local disk size and the amount of RAM.
* The ramdisk posts the facts to the discoverd API.
* All facts are passed and stored in the Ironic database.
* There can be performed advanced role matching via the ''ahc-match'' tool,
which simply adds an additional role categorization to Ironic based on
discovered node facts and specified conditions.
Flavors
"""""""
When users are creating virtual machines (VMs) in an OpenStack cloud, the flavor
that they choose specifies the capacity of the VM which should be created. The
flavor defines the CPU count, the amount of RAM, the amount of disk space etc.
As long as the cloud has enough capacity to grant the user's wish, and the user
hasn't reached their quota limit, the flavor acts as a set of instructions on
exactly what kind of VM to create on the user's behalf.
In the undercloud, where the machines are usually physical rather than virtual
(or, at least, pre-existing, rather than created on demand), flavors have a
slightly different effect. Essentially, they act as a constraint. Of all of the
discovered hardware, only nodes which match a specified flavor are suitable for
a particular role. This can be used to ensure that the large machines with a
great deal of RAM and CPU capacity are used to run Nova in the overcloud, and
the smaller machines run less demanding services, such as Keystone.
The version of TripleO included in RDO-Manager is capable of handling flavors in
two different modes.
The simpler PoC (Proof of Concept) mode is intended to enable new users to
experiment, without worrying about matching hardware profiles. In this mode,
there's one single, global flavor, and any hardware can match it. That
effectively removes flavor matching. Users can use whatever hardware they wish.
For the second mode, named Scale because it is suited to larger scale overcloud
deployments, flavor matching is in full effect. A node will only be considered
suitable for a given role if the role is associated with a flavor which matches
the capacity of the node. Nodes without a matching flavor are effectively
unusable.
This second mode allows users to ensure that their different hardware types end
up running their intended role, though requires manual configuration of the role
definitions and role matching via the ahc-match tool (see
:doc:`../advanced_deployment/profile_matching`).
Deployment Planning
^^^^^^^^^^^^^^^^^^^
Whole part of planning your deployment is based on concept of **overcloud
roles**.
Roles are stored in the Tuskar DB, and are used through interaction with the
Tuskar API. A role brings together following things:
* An image; the software to be installed on a node
* A flavor; the size of node suited to the role
* A size; number of instances which should be deployed having given role
* A set of heat templates; instructions on how to configure the node for its
task
In the case of the "Compute" role:
* the image must contain all the required software to boot an OS and then run
the KVM hypervisor and the Nova compute service
* the flavor (at least for a deployment which isn't a simple proof of concept),
should specify that the machine has enough CPU capacity and RAM to host
several VMs concurrently
* the Heat templates will take care of ensuring that the Nova service is
correctly configured on each node when it first boots.
Currently, the roles in RDO-Manager are very prescriptive, and in particular
individual services cannot easily be scaled independently of the Controller role
(other than storage nodes). More flexibility in this regard is planned in a
future release.
Customizable things during deployment planning are:
* Number of nodes for each role
* Service parameters configuration
* Network configuration (NIC configuration options, isolated vs. single overlay)
* Ceph rbd backend options and defaults
* Ways to pass in extra configuration, e.g site-specific customizations
Deployment
^^^^^^^^^^
Deployment to physical servers happens through a collaboration of Tuskar, Heat,
Nova, Neutron, Glance and Ironic.
To deploy the overcloud Tuskar needs gather all plan information it keeps and
build a Heat templates which describe desired overcloud.
This template is served to to Heat which will orchestrate the whole deployment
and it will create a stack. Stack is Heat's own term for the applications that
it creates. The overcloud, in Heat terms, is a particularly complex instance of
a stack.
In order to the stack to be deployed, Heat makes successive calls to Nova,
OpenStack's compute service controller. Nova depends upon Ironic, which, as
described above has acquired an inventory of discovered hardware by this stage
in the process.
At this point, Nova flavors may act as a constraint, influencing the range of
machines which may be picked for deployment by the Nova scheduler. For each
request to deploy a new node with a specific role, Nova filters the of available
nodes, ensuring that the selected nodes meets the hardware requirements.
Once the target node has been selected, Ironic does the actual provisioning of
the node, Ironic retrieves the OS image associated with the role from Glance,
causes the node to boot a deployment ramdisk and then, in the typical case,
exports the node's local disk over iSCSI so that the disk can be partitioned and
the have the OS image written onto it by the Ironic Conductor.
See Ironic's `Understanding Baremetal Deployment <http://docs.openstack.org/
developer/ironic/deploy/user-guide.html#understanding-bare-metal-deployment>`_
for further details.
Per-node Setup
^^^^^^^^^^^^^^
TBD - Puppet
Overcloud Initialization
^^^^^^^^^^^^^^^^^^^^^^^^
After the overcloud has been deployed, the initialization of OpenStack services
(e.g Keystone, Neutron, etc) needs to occur. That is accomplished today by
scripts in the `tripleo-incubator <https://github.com/openstack/
tripleo-incubator>`_ source repository and it uses bits from `os-cloud-config
<https://github.com/openstack/os-cloud-config>`_ which contains common code,
the seed initialization logic, and the post heat completion initial
configuration of a cloud. There are three primary steps to completing the
initialization:
* Initializing Identity Services (Keystone)
* Registering service endpoints (e.g. Glance, Nova)
* Specify a block of IP addresses for overcloud instances (Neutron)
The first step initializes Keystone for use with normal authentication by
creating the admin and service tenants, the admin and Member roles, the admin
user, configure certificates and finally registers the initial identity
endpoint. The next step registers image, orchestration, network and compute
services running on the default ports on the control plane node. Finally,
Neutron is given a starting IP address, ending IP address, and a CIDR notation
to represent the subnet for the block of floating IP addresses that will be
used within the overcloud.
High Availability (HA)
----------------------
RDO-Manager will use Pacemaker to achieve high-availability.
Reference architecture document: https://github.com/beekhof/osp-ha-deploy
.. note:: **Current HA solution is being developed by our community.**
Managing the Deployment
-----------------------
After the overcloud deployment is completed, it will be possible to monitor,
scale it out or perform basic maintenance operations via GUI or CLI.
Monitoring the Overcloud
^^^^^^^^^^^^^^^^^^^^^^^^
When the overcloud is deployed, Ceilometer can be configured to track a set of
OS metrics for each node (system load, CPU utilization, swap usage etc.) These
metrics are graphed in the GUI, both for individual nodes, and for groups
of nodes, such as the collection of nodes which are all delivering a particular
role.
Additionally, Ironic exports IPMI metrics for nodes, which can also be stored in
Ceilometer. This enables checks on hardware state such as fan operation/failure
and internal chassis temperatures.
The metrics which Ceilometer gathers can be queried for Ceilometer's REST API,
or by using the command line client.
.. Note::
There are plans to add more operational tooling to the future release.
Scaling-out the Overcloud
^^^^^^^^^^^^^^^^^^^^^^^^^
The process of scaling out the overcloud by adding new nodes involves these
stages:
* Making sure you have enough nodes to deploy on (or register new nodes as
described in the "Undercloud Data Preparation" section above).
* Updating the plan managed by Tuskar, as described in the "Deployment Planning"
section above.
* Calling Heat to update the stack which will apply the set of changes to the
overcloud.

461
doc/source/introduction/components.rst
View File

@ -1,461 +0,0 @@
RDO-Manager Components
======================
.. contents::
:depth: 2
:backlinks: none
This section contains a list of components that RDO-Manager uses. The components
are organized in categories, and include a basic description, useful links, and
contribution information.
..
[Example Category Name]
-----------------------
[Example Component Name]
^^^^^^^^^^^^^^^^^^^^^^^^
This is short description what the project is about and how RDO-Manager uses
this project. Three sentences max.
**How to contribute**
* Instructions to prepare development environment. Should be mostly pointing to
upstream docs. If upstream docs doesn't exist, please, create one. Add tips
how to test the feature in RDO-Manager + other useful information.
**Useful links**
* Upstream Project: `link <#>`_
* Bugs: `link <#>`_
* Blueprints: `link <#>`_
Shared Libraries
----------------
diskimage-builder
^^^^^^^^^^^^^^^^^
diskimage-builder is an image building tool. It is used by
``openstack overcloud image build --all``.
**How to contribute**
See the diskimage-builder `README.rst
<https://git.openstack.org/cgit/openstack/diskimage-builder/tree/README.rst>`_
for a further explanation of the tooling. Submit your changes via
OpenStack Gerrit (see `OpenStack Developer's Guide
<http://docs.openstack.org/infra/manual/developers.html>`_).
**Useful links**
* Upstream Project Documentation: http://docs.openstack.org/developer/diskimage-builder/
* Bugs: https://bugs.launchpad.net/diskimage-builder
* Git repository: https://git.openstack.org/cgit/openstack/diskimage-builder/
dib-utils
^^^^^^^^^
dib-utils contains tools that are used by diskimage-builder.
**How to contribute**
Submit your changes via OpenStack Gerrit (see `OpenStack Developer's Guide
<http://docs.openstack.org/infra/manual/developers.html>`_).
**Useful links**
* Bugs: https://bugs.launchpad.net/diskimage-builder
* Git repository: https://git.openstack.org/cgit/openstack/dib-utils/
os-\*-config
^^^^^^^^^^^^
The os-\*-config projects are a suite of tools used to configure instances
deployed via TripleO. They include:
* os-collect-config
* os-refresh-config
* os-apply-config
* os-net-config
**How to contribute**
Each tool uses `tox <https://tox.readthedocs.org/en/latest/>`_ to manage the
development environment. Submit your changes via OpenStack Gerrit (see
`OpenStack Developer's Guide
<http://docs.openstack.org/infra/manual/developers.html>`_).
**Useful links**
* Bugs:
* os-collect-config: https://bugs.launchpad.net/os-collect-config
* os-refresh-config: https://bugs.launchpad.net/os-refresh-config
* os-apply-config: https://bugs.launchpad.net/os-apply-config
* os-net-config: https://bugs.launchpad.net/os-net-config
* Git repositories:
* os-collect-config: https://git.openstack.org/cgit/openstack/os-collect-config
* os-refresh-config https://git.openstack.org/cgit/openstack/os-refresh-config
* os-apply-config https://git.openstack.org/cgit/openstack/os-apply-config
* os-net-config https://git.openstack.org/cgit/openstack/os-net-config
tripleo-image-elements
^^^^^^^^^^^^^^^^^^^^^^
tripleo-image-elements is a repository of diskimage-builder style elements used
for installing various software components.
**How to contribute**
Submit your changes via OpenStack Gerrit (see
`OpenStack Developer's Guide
<http://docs.openstack.org/infra/manual/developers.html>`_).
**Useful links**
* Git repository: https://git.openstack.org/cgit/openstack/tripleo-image-elements
Installer
---------
instack
^^^^^^^
instack executes diskimage-builder style elements on the current system. This
enables a current running system to have an element applied in the same way
that diskimage-builder applies the element to an image build.
instack, in its current form, should be considered low level tooling. It is
meant to be used by higher level scripting that understands what elements and
hook scripts need execution. Using instack requires a rather in depth knowledge
of the elements within diskimage-builder and tripleo-image-elements.
**How to contribute**
Submit patches to gerrithub https://review.gerrithub.io/#/q/project:rdo-management/instack
**Useful links**
* Bugs: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Community&component=instack
instack-undercloud
^^^^^^^^^^^^^^^^^^
instack-undercloud is a TripleO style undercloud installer based around
instack.
**How to contribute**
Submit patches to gerrithub https://review.gerrithub.io/#/q/project:rdo-management/instack-undercloud
**Useful links**
* Bugs: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Community&component=instack-undercloud
tripleo-incubator
^^^^^^^^^^^^^^^^^
tripleo-incubator contains various scripts to aid in deploying a TripleO cloud.
**How to contribute**
Submit your changes via OpenStack Gerrit (see
`OpenStack Developer's Guide
<http://docs.openstack.org/infra/manual/developers.html>`_).
**Useful links**
* Documentation: http://docs.openstack.org/developer/tripleo-incubator/index.html
* Git repository: https://git.openstack.org/cgit/openstack/tripleo-incubator
Node Management
---------------
ironic
^^^^^^
Ironic project is responsible for provisioning and managing bare metal
instances.
For testing purposes Ironic can also be used for provisioning and managing
virtual machines which act as bare metal nodes via special driver ``pxe_ssh``.
**How to contribute**
Ironic uses `tox <https://tox.readthedocs.org/en/latest/>`_ to manage the
development environment, see `OpenStack's Documentation
<http://docs.openstack.org/developer/ironic/dev/contributing.html>`_,
`Ironic Developer Guidelines
<https://wiki.openstack.org/wiki/Ironic/Developer_guidelines>`_
and `OpenStack Developer's Guide`_ for details.
**Useful links**
* Upstream Project: http://docs.openstack.org/developer/ironic/index.html
* Bugs: https://bugs.launchpad.net/ironic
* Blueprints: https://blueprints.launchpad.net/ironic
* `Specs process <https://wiki.openstack.org/wiki/Ironic/Specs_Process>`_
should be followed for suggesting new features.
* Approved Specs: http://specs.openstack.org/openstack/ironic-specs/
ironic inspector (former ironic-discoverd)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Ironic Inspector project is responsible for inspection of hardware properties
for newly enrolled nodes (see also ironic_).
Ironic Inspector was called ironic-discoverd previously, and the RPM packages
are still based on the old version, so they are using the old name for now.
**How to contribute**
Ironic Inspector uses `tox <https://tox.readthedocs.org/en/latest/>`_ to manage
the development environment, see `upstream documentation
<https://github.com/openstack/ironic-inspector/blob/master/CONTRIBUTING.rst>`_
for details.
**Useful links**
* Upstream Project: https://github.com/openstack/ironic-inspector
* PyPI: https://pypi.python.org/pypi/ironic-inspector
Also https://pypi.python.org/pypi/ironic-discoverd for the old version which
RDO Manager currently uses.
* Bugs: https://bugs.launchpad.net/ironic-inspector
* Blueprints: https://blueprints.launchpad.net/ironic-inspector
Deployment Planning
-------------------
Tuskar
^^^^^^
The Tuskar project is responsible for planning of deployments through the use
of two main concepts: Role (unit of functionality, e.g. 'Compute') and Plan.
A given Role is associated with a number of Heat templates and extra
data files and Tuskar allows the user to provide values for a Role's template
attributes.
Once a Plan is specified in terms of Roles (and any desired
template attributes have been set) Tuskar can assemble and generate the
corresponding Heat deployment files and return these to the caller
(ready to be passed to Heat).
**How to contribute**
The Tuskar project uses the usual OpenStack code review process with gerrit
reviews (see links below). Tuskar is a sub-project falling under TripleO
and as such you can use the #tripleo irc channel (freenode) or the weekly
TripleO meeting to bring up issues about Tuskar, as well as the openstack-dev
mailing list of course.
**Useful links**
* Upstream Project: https://github.com/openstack/tuskar
* PyPI: https://pypi.python.org/pypi/tuskar
* Bugs: https://bugs.launchpad.net/tuskar
* Blueprints: https://blueprints.launchpad.net/tuskar
* REST API http://specs.openstack.org/openstack/tripleo-specs/specs/juno/tripleo-juno-tuskar-rest-api.html
* Reviews: https://review.openstack.org/#/q/status:open+project:openstack/tuskar,n,z
Deployment & Orchestration
--------------------------
heat
^^^^
Heat is OpenStack's orchestration tool. It reads YAML files describing
the OpenStack deployment's resources (machines, their configurations
etc.) and gets those resources into the desired state, often by
talking to other components (e.g. Nova).
**How to contribute**
* Use `devstack with Heat
<http://docs.openstack.org/developer/heat/getting_started/on_devstack.html>`_
to set up a development environment. Submit your changes via
OpenStack Gerrit (see `OpenStack Developer's Guide
<http://docs.openstack.org/infra/manual/developers.html>`_).
**Useful links**
* Upstream Project: https://wiki.openstack.org/wiki/Heat
* Bugs: https://bugs.launchpad.net/heat
* Blueprints: https://blueprints.launchpad.net/heat
heat-templates
^^^^^^^^^^^^^^
The heat-templates repository contains additional image elements for
producing disk images ready to be configured by Puppet via Heat.
**How to contribute**
* Use `devtest with Puppet
<http://docs.openstack.org/developer/tripleo-incubator/puppet.html>`_
to set up a development environment. Submit your changes via
OpenStack Gerrit (see `OpenStack Developer's Guide
<http://docs.openstack.org/infra/manual/developers.html>`_).
**Useful links**
* Upstream Project: https://git.openstack.org/cgit/openstack/heat-templates
* Bugs: https://bugs.launchpad.net/heat-templates
* Blueprints: https://blueprints.launchpad.net/heat-templates
tripleo-heat-templates
^^^^^^^^^^^^^^^^^^^^^^
The tripleo-heat-templates describe the OpenStack deployment in Heat
Orchestration Template YAML files and Puppet manifests. The templates
are processed through Tuskar and materialized into an actual
deployment via Heat.
**How to contribute**
* Use `devtest with Puppet
<http://docs.openstack.org/developer/tripleo-incubator/puppet.html>`_
to set up a development environment. Submit your changes via
OpenStack Gerrit (see `OpenStack Developer's Guide
<http://docs.openstack.org/infra/manual/developers.html>`_).
**Useful links**
* Upstream Project: https://git.openstack.org/cgit/openstack/tripleo-heat-templates
* Bugs: https://bugs.launchpad.net/tripleo
* Blueprints: https://blueprints.launchpad.net/tripleo
nova
^^^^
TBD
puppet-\*
^^^^^^^^^
The OpenStack Puppet modules are used to configure the OpenStack
deployment (write configuration, start services etc.). They are used
via the tripleo-heat-templates.
**How to contribute**
* Use `devtest with Puppet
<http://docs.openstack.org/developer/tripleo-incubator/puppet.html>`_
to set up a development environment. Submit your changes via
OpenStack Gerrit (see `OpenStack Developer's Guide
<http://docs.openstack.org/infra/manual/developers.html>`_).
**Useful links**
* Upstream Project: https://wiki.openstack.org/wiki/Puppet
tripleo-puppet-elements
^^^^^^^^^^^^^^^^^^^^^^^
The tripleo-puppet-elements describe the contents of disk images which
RDO-Manager uses to deploy OpenStack. It's the same kind of elements
as in tripleo-image-elements, but tripleo-puppet-elements are specific
for Puppet-enabled images.
**How to contribute**
* Use `devtest with Puppet
<http://docs.openstack.org/developer/tripleo-incubator/puppet.html>`_
to set up a development environment. Submit your changes via
OpenStack Gerrit (see `OpenStack Developer's Guide`_).
**Useful links**
* Upstream Project: https://git.openstack.org/cgit/openstack/tripleo-puppet-elements
* Bugs: https://bugs.launchpad.net/tripleo
* Blueprints: https://blueprints.launchpad.net/tripleo
User Interfaces
---------------
tuskar-ui
^^^^^^^^^
Tuskar-UI provides a GUI to install and manage OpenStack. It is implemented as
a plugin to Horizon.
**How to contribute**
* See `upstream documentation <http://tuskar-ui.readthedocs.org/en/latest/install.html>`_
for instuctions on how to set up a development environment. Submit your
changes via OpenStack Gerrit (see `OpenStack Developer's Guide`_).
**Useful links**
* Upstream Project: https://git.openstack.org/cgit/openstack/tuskar-ui
* Documentation: http://tuskar-ui.readthedocs.org
* Bugs: https://bugs.launchpad.net/tuskar-ui
* Blueprints: https://blueprints.launchpad.net/tuskar-ui
tuskar-ui-extras
^^^^^^^^^^^^^^^^
Tuskar-UI extras provides GUI enhancements for Tuskar-UI. It is implemented as
a plugin to Horizon.
**How to contribute**
* See `upstream documentation <http://tuskar-ui-extras.readthedocs.org/en/latest/install.html#development-install-instructions>`_
for instuctions on how to set up a development environment. Submit your
changes via `Gerrithub <https://review.gerrithub.io/#/q/project:rdo-management/tuskar-ui-extras>`_.
**Useful links**
* Project: https://github.com/rdo-management/tuskar-ui-extras
* Documentation: http://tuskar-ui-extras.readthedocs.org
python-openstackclient
^^^^^^^^^^^^^^^^^^^^^^
The python-openstackclient is an upstream CLI tool which can manage multiple
openstack services. It wraps openstack clients like glance, nova, etc. and maps
them under intuitive names like openstack image, compute, etc.
The main value is that all services can be controlled by a single (openstack)
command with consistent syntax and behaviour.
**How to contribute**
* python-openstackclient uses `tox <https://tox.readthedocs.org/en/latest/>`_
to manage the development environment, see `upstream documentation
<https://github.com/openstack/python-openstackclient/blob/master/README.rst>`_
for details. Submit your changes via OpenStack Gerrit
(see `OpenStack Developer's Guide`_).
**Useful links**
* Upstream Project: http://git.openstack.org/cgit/openstack/python-openstackclient
* Bugs: https://bugs.launchpad.net/python-openstackclient
* Blueprints: https://blueprints.launchpad.net/python-openstackclient
* Human interface guide: http://docs.openstack.org/developer/python-openstackclient/humaninterfaceguide.html
python-rdomanager-oscplugin
^^^^^^^^^^^^^^^^^^^^^^^^^^^
The python-rdomanager-oscplugin is a CLI tool embedded into
python-openstackclient. It provides functions related to instack
installation and initial configuration like node discovery, overcloud image
building and uploading, etc.
**How to contribute**
* python-rdomanager-oscplugin uses `tox <https://tox.readthedocs.org/en/latest/>`_
to manage the development environment, see `documentation
<https://github.com/rdo-management/python-rdomanager-oscplugin/blob/master/CONTRIBUTING.rst>`_
for details. Submit your changes via
`Gerrithub <https://review.gerrithub.io/#/q/project:rdo-management/python-rdomanager-oscplugin>`_.
**Useful links**
* Project: https://github.com/rdo-management/python-rdomanager-oscplugin
..
<GLOBAL_LINKS>
.. _OpenStack Developer's Guide: http://docs.openstack.org/infra/manual/developers.html

45
doc/source/introduction/introduction.rst
View File

@ -1,45 +0,0 @@
RDO-Manager Introduction
========================
RDO-Manager is an OpenStack Deployment & Management tool for RDO. It is based on
`OpenStack TripleO <https://wiki.openstack.org/wiki/TripleO>`_ project and its
philosophy is inspired by `SpinalStack <http://spinal-stack.readthedocs.org/en/
latest/>`_.
Useful links:
* `RDO-Manager Home Page <http://rdoproject.org/RDO-Manager>`_
* `RDO-Manager Repositories <http://github.com/rdo-management>`_
* `TripleO Documentation <http://docs.openstack.org/developer/tripleo-incubator/README.html>`_
|
**Architecture**
With RDO-Manager, you start by creating an **undercloud** (an actual operator
facing deployment cloud) that will contain the necessary OpenStack components to
deploy and manage an **overcloud** (an actual tenant facing workload cloud). The
overcloud is the deployed solution and can represent a cloud for any purpose
(e.g. production, staging, test, etc). The operator can choose any of available
Overcloud Roles (OpenStack components) they want to deploy to his environment.
Go to :doc:`architecture` to learn more.
|
**Components**
RDO-Manager is composed of set of official OpenStack components accompanied by
few other open sourced plugins which are increasing RDO-Manager capabilities.
Go to :doc:`components` to learn more.
.. toctree::
:hidden:
Architecture <architecture>
Components <components>

44
doc/source/post_deployment/delete_nodes.rst
View File

@ -1,44 +0,0 @@
.. _delete_nodes:
Deleting Overcloud Nodes
========================
You can delete specific nodes from an overcloud with command::
openstack overcloud node delete --stack $STACK_NAME --plan $PLAN_UUID <list of nova instance IDs>
This command updates number of nodes in tuskar plan and then updates heat stack
with updated numbers and list of resource IDs (which represent nodes) to be
deleted.
.. note::
If you passed any extra environment files when you created the overcloud (for
instance, in order to configure :doc:`network isolation
<../advanced_deployment/network_isolation>`), you must pass them again here
using the ``-e`` or ``--environment-file`` option to avoid making undesired
changes to the overcloud.
.. note::
Before deleting a compute node please make sure that the node is quiesced,
see :ref:`quiesce_compute`.
.. note::
A list of nova instance IDs can be listed with command::
nova list
Deleting nodes without using Tuskar
-----------------------------------
If the overcloud was :doc:`deployed from heat templates directly
<../advanced_deployment/template_deploy>` then use the ``--templates``
parameter when deleting nodes::
openstack overcloud node delete --stack $STACK_NAME --templates [templates dir] <list of nova instance IDs>
If you passed any extra environment files when you created the overcloud (for
instance, in order to configure :doc:`network isolation
<../advanced_deployment/network_isolation>`), you must pass them again here
using the ``-e`` or ``--environment-file`` option to avoid making undesired
changes to the overcloud.

53
doc/source/post_deployment/migration.rst
View File

@ -1,53 +0,0 @@
Migrating Workloads from an existing OpenStack cloud
====================================================
RDO Manager provides the ability to manage changes over time to a cloud that it
has deployed. However, it cannot automatically take over the management of
existing OpenStack clouds deployed with another installer. Since there can be
no one-size-fits-all procedure for upgrading an existing cloud to use RDO
Manager, it is recommended that a new cloud be deployed with RDO Manager and
any workloads running on an existing cloud be migrated off.
Migrating User Workloads
------------------------
Since the best way of avoiding or handling any downtime associated with moving
an application from one cloud to another is application-dependent, it is
preferable to have end users migrate their own applications at a time and in
the manner of their choosing. This can also help to spread out the network
bandwidth requirements, rather than copying a large number of snapshots in
bulk.
Ideally applications can be re-created from first principles (an Orchestration
tool such as Heat can help make this repeatable) and any data populated after
the fact. This allows the new VMs to be backed by a copy-on-write disk image
overlaid on the original base image. The alternative is to :doc:`export and
then import <./vm_snapshot>` snapshots of the VM images. This may require
considerably more disk space as each VM's base image becomes its snapshot,
where previously multiple VMs may have shared the same base image.
Reclaiming Excess Capacity
--------------------------
As workloads are migrated off the previous cloud, compute node hardware can be
freed up to reallocate to the new cloud. Since there is likely no guarantee as
to the order in which users will migrate, it will be necessary to consolidate
the remaining VMs onto a smaller number of machines as utilization drops. This
can be done by performing live migration within the old cloud.
Select a compute node to remove from service and follow the procedure for
:doc:`quiesce_compute`. Once this is done, the node can be removed from the old
cloud and the hardware reused, possibly by adding it to the new cloud.
Adding New Capacity
-------------------
As utilization of the new cloud increases and hardware becomes available from
the old cloud, additional compute nodes can be added to the new cloud with RDO
Manager.
First, register and introspect the additional hardware with Ironic just as you
would have done when :doc:`initially deploying
<../basic_deployment/basic_deployment_cli>` the cloud with RDO Manager. Then
:doc:`scale out <scale_roles>` the 'Compute' role in the new overcloud to start
making use of the additional capacity.

41
doc/source/post_deployment/package_update.rst
View File

@ -1,41 +0,0 @@
Updating Packages on Overcloud Nodes
====================================
You can update packages on all overcloud nodes with command::
openstack overcloud update stack --plan $PLAN_UUID -i overcloud
This command updates UpdateIdentifier parameter in the overcloud tuskar plan
and triggers stack update operation. If this parameter is set 'yum update'
command is executed and each node. Because running update on all nodes in
parallel might be unsafe (an update of a package might involve restarting
a service), the command above sets breakpoints on each overcloud node so nodes
are updated one by one. When the update is finished on a node the command
will prompt for removing breakpoint on next one.
.. note::
Multiple breakpoints can be removed by specifying list of nodes with a
regular expression.
.. note::
Make sure you use `-i` parameter, otherwise update runs on background and
doesn't prompt for removing of breakpoints.
.. note::
If the update command is aborted for some reason you can always continue
in the process by re-running same command.
Updating Packages on Overcloud Nodes Without Using Tuskar
---------------------------------------------------------
If the overcloud was :doc:`deployed from heat templates directly
<../advanced_deployment/template_deploy>` then use the ``--templates``
parameter when updating packages::
openstack overcloud update stack --templates [templates dir] -i overcloud
If you passed any extra environment files when you created the overcloud (for
instance, in order to configure :doc:`network isolation
<../advanced_deployment/network_isolation>`), you must pass them again here
using the ``-e`` or ``--environment-file`` option to avoid making undesired
changes to the overcloud.

15
doc/source/post_deployment/post_deployment.rst
View File

@ -1,15 +0,0 @@
Post Deployment
===============
In this chapter you will find advanced management of various RDO-Manager areas.
.. toctree::
Migrating Workloads from an Existing OpenStack Cloud <migration>
Scaling Overcloud Roles <scale_roles>
Deleting Overcloud Nodes <delete_nodes>
Quiescing a Compute node <quiesce_compute>
Replacing a Failed Controller Node <replace_controller>
Import/Export of VM Snapshots <vm_snapshot>
Updating Packages on Overcloud Nodes <package_update>

83
doc/source/post_deployment/quiesce_compute.rst
View File

@ -1,83 +0,0 @@
.. _quiesce_compute:
Quiescing a Compute Node
========================
The process of quiescing a compute node means to migrate workload off the node
so that it can be shut down without affecting the availability of end-users'
VMs. You might want to perform this procedure when rebooting a compute node to
ensure that package updates are applied (e.g. after a kernel update); to
consolidate workload onto a smaller number of machines when scaling down an
overcloud; or when replacing the compute node hardware.
Setting up Keys
---------------
Assuming that the backing files for Nova VMs are not hosted on a shared storage
volume (with all compute nodes having access), the compute nodes will need to
be configured with ssh keys so that the `nova` user on each compute node has
ssh access to the corresponding account on the other compute nodes.
First, generate an ssh key::
ssh-keygen -t rsa -f nova_id_rsa
Then, on each compute node, run the following script to set up the keys::
NOVA_SSH=/var/lib/nova/.ssh
mkdir ${NOVA_SSH}
cp nova_id_rsa ${NOVA_SSH}/id_rsa
chmod 600 ${NOVA_SSH}/id_rsa
cp nova_id_rsa.pub ${NOVA_SSH}/id_rsa.pub
cp nova_id_rsa.pub ${NOVA_SSH}/authorized_keys
chown -R nova.nova ${NOVA_SSH}
# enable login for nova user on compute hosts:
usermod -s /bin/bash nova
# add ssh keys of overcloud nodes into known hosts:
ssh-keyscan -t rsa `os-apply-config --key hosts --type raw --key-default '' | awk '{print $1}'` >>/etc/ssh/ssh_known_hosts
Initiating Migration
--------------------
First, obtain a list of the current Nova services::
source ~stack/overcloudrc # admin credentials for the overcloud
nova service-list
Disable the `nova-compute` service on the node you wish to quiesce, to prevent
new VMs being scheduled on it::
nova service-disable <service-host> nova-compute
Begin the process of migrating VMs off the node::
nova host-servers-migrate <service-host>
Completing Migration
--------------------
The current status of the migration process can be retrieved with the command::
nova migration-list
When migration of each VM completes, its state in Nova will change to
`VERIFY_RESIZE`. This gives you an opportunity to confirm that the migration
completed successfully, or to roll it back. To confirm the migration, use the
command::
nova resize-confirm <server-name>
Finally, once all migrations are complete and confirmed, remove the service
running (but disabled) on the compute node from Nova altogether::
nova service-delete <service-id>
You are now free to reboot or shut down the node (using the Ironic API), or
even remove it from the overcloud altogether by scaling down the overcloud
deployment, see :ref:`delete_nodes`.

105
doc/source/post_deployment/replace_controller.rst
View File

@ -1,105 +0,0 @@
.. _replace_controller:
Replacing a Controller Node
===========================
Replace Failed Node
-------------------
First, create a YAML file defining node index to remove. Node index reflects
suffix of instance name in `nova list` output. In this following text
`overcloud-controller-1` node is replaced with `overcloud-controller-3`::
$ cat ~/remove.yaml
parameters:
  ControllerRemovalPolicies:
      [{'resource_list': ['1']}]
Then, re-deploy overcloud including the extra environment file::
openstack overcloud deploy --templates --control-scale 3 -e ~/remove.yaml
The old node will be removed and a new one will be added.
Because some puppet modules don't support nodes replacement, re-deployment
fails and a couple of manual changes are needed to fix controller nodes setup.
Connect to one of remaining controller nodes and delete the failed node
from Pacemaker/Corosync cluster::
crm_node -R overcloud-controller-1 --force
Delete the failed node from RabbitMQ cluster::
rabbitmqctl forget_cluster_node rabbit@overcloud-controller-1
Delete the failed node from MongoDB::
# connect to MongoDB on any of remaining nodes:
mongo --host <node ip>
# check status of MongoDB cluster:
rs.status()
# remove the failed node:
rs.remove('<node_ip>:27017')
Update list of nodes in Galera cluster::
pcs resource update galera wsrep_cluster_address=gcomm://overcloud-controller-0,overcloud-controller-3,overcloud-controller-2
Start Pacemaker/Corosync on the new node::
pcs cluster node add overcloud-controller-3
pcs cluster start overcloud-controller-3
Enable keystone service on the new node::
copy /etc/keystone from a remaining node to the new node
set admin_bind_host and public_bind_host in /etc/keystone/keystone.conf to node's IP
pcs resource cleanup openstack-keystone-clone overcloud-controller-3
Re-deploy overcloud again::
openstack overcloud deploy --templates --control-scale 3
.. note::
If deployment fails with error `Failed to call refresh: Could not restart Service[httpd]`
then try re-deploy again.
Completing Update
-----------------
Delete the failed node from `/etc/corosync/corosync.conf` file and restart
Corosync one by one on each node::
systemctl restart corosync
When re-deployment finishes, connect to one of controller nodes and start
services on the new node::
pcs resource cleanup neutron-server-clone
pcs resource cleanup openstack-nova-api-clone
pcs resource cleanup openstack-nova-consoleauth-clone
pcs resource cleanup openstack-heat-engine-clone
pcs resource cleanup openstack-cinder-api-clone
pcs resource cleanup openstack-glance-registry-clone
pcs resource cleanup httpd-clone
Replacing Bootstrap Node
------------------------
If node with index 0 is being replaced it's necessary to edit heat templates
and change bootstrap node index before starting replacement. Open
`overcloud-without-mergepy.yaml` file in root directory of heat templates and
change lines::
bootstrap_nodeid: {get_attr: [Controller, resource.0.hostname]}
bootstrap_nodeid_ip: {get_attr: [Controller, resource.0.ip_address]}
to::
bootstrap_nodeid: {get_attr: [Controller, resource.1.hostname]}
bootstrap_nodeid_ip: {get_attr: [Controller, resource.1.ip_address]}
Tuskar doesn't support template editing so it's possible to do this change only
if overcloud is deployed with :doc:`templates directly <../advanced_deployment/template_deploy>`.

42
doc/source/post_deployment/scale_roles.rst
View File

@ -1,42 +0,0 @@
Scaling overcloud roles
=======================
If you want to increase or decrease resource capacity of a running overcloud,
you can start more servers of a selected role or delete some servers if
capacity should be decreased. First update the Overcloud plan with a new
number of nodes of the role::
openstack management plan set $PLAN_UUID -S Compute-1=5
.. note::
The role is specified including the role version. Both role names
and role versions can be listed with command::
openstack role list
And then re-deploy the Overcloud with the updated plan::
openstack overcloud deploy --plan $PLAN_UUID
.. note::
Scaling out assumes that newly added nodes has already been
registered in Ironic.
.. note::
When scaling down random servers of specified role will be deleted, how to
delete specific nodes is decribed in :ref:`delete_nodes`.
Scaling overcloud roles without using Tuskar
--------------------------------------------
If the overcloud was :doc:`deployed from heat templates directly
<../advanced_deployment/template_deploy>` then you can just re-deploy the
overcloud with ``--templates`` and ``--<role>-scale`` parameters::
openstack overcloud deploy --templates [templates dir] --compute-scale 5
If you passed any extra environment files when you created the overcloud (for
instance, in order to configure :doc:`network isolation
<../advanced_deployment/network_isolation>`), you must pass them again here
using the ``-e`` or ``--environment-file`` option to avoid making undesired
changes to the overcloud.

26
doc/source/post_deployment/vm_snapshot.rst
View File

@ -1,26 +0,0 @@
Import/Export of VM Snapshots
=============================
Create a snapshot of a running server
-------------------------------------
Create a new image by taking a snapshot of a running server and download the
image.
::
nova image-create instance_name image_name
glance image-download image_name --file exported_vm.qcow2
Import an image into Overcloud and launch an instance
-----------------------------------------------------
Upload the exported image into glance in Overcloud and launch a new instance.
::
glance image-create --name imported_image --file exported_vm.qcow2 --disk-format qcow2 --container-format bare
nova boot --poll --key-name default --flavor m1.demo --image imported_image --nic net-id=net_id imported
.. note::
**Warning**: disadvantage of using glance image for export/import VMs is
that each VM disk has to be copied in and out into glance in source and
target clouds. Also by making snapshot qcow layering system is lost.

16
doc/source/troubleshooting/troubleshooting-image-build.rst
View File

@ -1,16 +0,0 @@
Troubleshooting Image Build
===========================
Images fail to build
--------------------
More space needed
^^^^^^^^^^^^^^^^^
Images are built in tmpfs by default, to speed up the builds. In case
your machine doesn't have enough free RAM, the image building step
can fail with a message like "At least 174MB more space needed on
the / filesystem". If freeing up more RAM isn't a possibility,
images can be built on disk by exporting an environment variable::
export DIB_NO_TMPFS=1

91
doc/source/troubleshooting/troubleshooting-nodes.rst
View File

@ -1,91 +0,0 @@
Troubleshooting Node Management Failures
========================================
Where Are the Logs?
-------------------
Some logs are stored in *journald*, but most are stored as text files in
``/var/log``. Ironic and ironic-discoverd logs are stored in journald. Note
that Ironic has 2 units: ``openstack-ironic-api`` and
``openstack-ironic-conductor``. Similarly, ironic-discoverd has
``openstack-ironic-discoverd`` and ``openstack-ironic-discoverd-dnsmasq``. So
for example to get all ironic-discoverd logs use::
sudo journalctl -u openstack-ironic-discoverd -u openstack-ironic-discoverd-dnsmasq
If something fails during the discovery ramdisk run, ironic-discoverd
stores the ramdisk logs in ``/var/log/ironic-discoverd/ramdisk/`` as
gz-compressed tar files. File names contain date, time and IPMI address of the
node if it was detected (only for bare metal).
.. _node_registration_problems:
Node Registration Problems
--------------------------
Any problems with node data registered into Ironic can be fixed using the
Ironic CLI.
For example, a wrong MAC can be fixed in two steps:
* Find out the assigned port UUID by running
::
ironic node-port-list <NODE UUID>
* Update the MAC address by running
::
ironic port-update <PORT UUID> replace address=<NEW MAC>
A Wrong IPMI address can be fixed with the following command::
ironic node-update <NODE UUID> replace driver_info/ipmi_address=<NEW IPMI ADDRESS>
.. _introspection_problems:
Hardware Introspection Problems
--------------------------------
Discovery hangs and times out
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ironic-discoverd times out discovery process after some time (defaulting to 1
hour) if it never gets response from the discovery ramdisk. This can be
a sign of a bug in the discovery ramdisk, but usually it happens due to
environment misconfiguration, particularly BIOS boot settings. Please refer to
`ironic-discoverd troubleshooting documentation`_ for information on how to
detect and fix such problems.
Refusing to introspect node with provision state "available"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If you're running discovery directly using ironic-discoverd CLI (or in case of
bugs in our scripts), a node can be in the "AVAILABLE" state, which is meant for
deployment, not for discovery. You should advance node to the "MANAGEABLE" state
before discovery and move it back before deployment.
Please refer to `upstream node states documentation
<https://github.com/openstack/ironic-inspector#node-states>`_ for information
on how to fix it.
How can discovery be stopped?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Currently ironic-discoverd does not provide means for stopping discovery. The
recommended path is to wait until it times out. Changing ``timeout`` setting
in ``/etc/ironic-discoverd/discoverd.conf`` may be used to reduce this timeout
from 1 hour (which usually too much, especially on virtual environment).
If you do need to stop discovery **for all nodes** right now, do the
following for each node::
ironic node-set-power-state UUID off
then remove ironic-discoverd cache and restart it::
rm /var/lib/ironic-discoverd/discoverd.sqlite
sudo systemctl restart openstack-ironic-discoverd
.. _ironic-discoverd troubleshooting documentation: https://github.com/openstack/ironic-inspector#troubleshooting

288
doc/source/troubleshooting/troubleshooting-overcloud.rst
View File

@ -1,288 +0,0 @@
Troubleshooting a Failed Overcloud Deployment
=============================================
If an Overcloud deployment has failed, the OpenStack clients and service log
files can be used to troubleshoot the failed deployment. The following commands
are all run on the Undercloud and assume a stackrc file has been sourced.
Identifying Failed Component
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In most cases, Heat will show the failed overcloud stack when a deployment
has failed::
$ heat stack-list
+--------------------------------------+------------+--------------------+----------------------+
| id | stack_name | stack_status | creation_time |
+--------------------------------------+------------+--------------------+----------------------+
| 7e88af95-535c-4a55-b78d-2c3d9850d854 | overcloud | CREATE_FAILED | 2015-04-06T17:57:16Z |
+--------------------------------------+------------+--------------------+----------------------+
Occassionally, Heat is not even able to create the the stack, so the ``heat
stack-list`` output will be empty. If this is the case, observe the message
that was printed to the terminal when ``instack-deploy-overcloud`` or ``heat
stack-create`` was run.
Next, there are a few layers on which the deployment can fail:
* Orchestration (Heat and Nova services)
* Bare metal provisioning (Ironic service)
* Post-deploy configuration (Puppet)
As Ironic service is in the middle layer, you can use its shell to guess the
failed layer. Issue ``ironic node-list`` command to see all registered nodes
and their current status, you will see something like::
+--------------------------------------+------+---------------+-------------+-----------------+-------------+
| UUID | Name | Instance UUID | Power State | Provision State | Maintenance |
+--------------------------------------+------+---------------+-------------+-----------------+-------------+
| f1e26112-5fbd-4fc4-9612-ecce7a1d86aa | None | None | power off | available | False |
| f0b8c105-f1d7-4059-a9a3-b050c3340340 | None | None | power off | available | False |
+--------------------------------------+------+---------------+-------------+-----------------+-------------+
Pay close attention to **Provision State** and **Maintenance** columns
in the resulting table.
* If the command shows empty table or less nodes that you expect, or
**Maintenance** is ``True``, or **Provision State** is ``manageable``,
there was a problem during node enrolling and introspection.
Please go back to these steps.
For example, **Maintenance** goes to ``True`` automatically, if wrong power
credentials are provided.
* If **Provision State** is ``available`` then the problem occured before
bare metal deployment has even started. Proceed with `Debugging Using Heat`_.
* If **Provision State** is ``active`` and **Power State** is ``power on``,
then bare metal deployment has finished successfully, and problem happened
during the post-deployment configuration step. Again, refer to `Debugging
Using Heat`_.
* If **Provision State** is ``wait call-back``, then bare metal deployment is
not finished for this node yet. You may want to wait until the status
changes.
* If **Provision State** is ``error`` or ``deploy failed``, then bare metal
deployment has failed for this node. Issue
::
ironic node-show <UUID>
and look for **last_error** field. It will contain error description.
If the error message is vague, you can use logs to clarify it::
sudo journalctl -u openstack-ironic-conductor -u openstack-ironic-api
If you see wait timeout error, and node **Power State** is ``power on``,
then try to connect to the virtual console of the failed machine. Use
``virt-manager`` tool for virtual machines and vendor-specific virtual
console (e.g. iDRAC for DELL) for bare metal machines.
Debugging Using Heat
~~~~~~~~~~~~~~~~~~~~
* Identifying the failed Heat resource
List all the stack resources to see which one failed.
::
$ heat resource-list overcloud
+-----------------------------------+-----------------------------------------------+---------------------------------------------------+-----------------+----------------------+
| resource_name | physical_resource_id | resource_type | resource_status | updated_time |
+-----------------------------------+-----------------------------------------------+---------------------------------------------------+-----------------+----------------------+
| BlockStorage | 9e40a1ee-96d3-4920-868d-683d3788e129 | OS::Heat::ResourceGroup | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| BlockStorageAllNodesDeployment | 2c453f6b-7378-44c8-a0ad-57de57d9c57f | OS::Heat::StructuredDeployments | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| BlockStorageNodesPostDeployment | | OS::TripleO::BlockStoragePostDeployment | INIT_COMPLETE | 2015-04-06T21:15:20Z |
| CephClusterConfig | 1684e7a3-0e42-44fe-9db4-7543b742fbfc | OS::TripleO::CephClusterConfig::SoftwareConfig | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| CephStorage | 48b3460c-bf9a-4663-99fc-2b4fa01b8dc1 | OS::Heat::ResourceGroup | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| CephStorageAllNodesDeployment | 76beb3a9-8327-4d2e-a206-efe12f1613fb | OS::Heat::StructuredDeployments | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| CephStorageCephDeployment | af8fb02a-5bc6-468c-8fac-fbe7e5b2c689 | OS::Heat::StructuredDeployments | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| CephStorageNodesPostDeployment | | OS::TripleO::CephStoragePostDeployment | INIT_COMPLETE | 2015-04-06T21:15:20Z |
| Compute | e5e6ec84-197f-4bf6-b8ac-eb11fe494cdf | OS::Heat::ResourceGroup | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| ComputeAllNodesDeployment | e6d44fbf-9683-4765-acbb-4a3d31c8fd48 | OS::Heat::StructuredDeployments | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| ControllerNodesPostDeployment | e551e472-f2db-4468-b586-0374678d71a3 | OS::TripleO::ControllerPostDeployment | CREATE_FAILED | 2015-04-06T21:15:20Z |
| ComputeCephDeployment | 673608d5-70d7-453a-ac78-7987bc2c0158 | OS::Heat::StructuredDeployments | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| ComputeNodesPostDeployment | 1078e3e3-9f6f-48b9-8961-a30f44098856 | OS::TripleO::ComputePostDeployment | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| ControlVirtualIP | 6402b396-84aa-4cf6-9849-305205755604 | OS::Neutron::Port | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| Controller | ffc45352-9708-486d-81ac-3b60efa8e8b8 | OS::Heat::ResourceGroup | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| ControllerAllNodesDeployment | f73c6e33-3dd2-46f1-9eca-0d2981a4a986 | OS::Heat::StructuredDeployments | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| ControllerBootstrapNodeConfig | 01ce5b6a-794a-4828-bad9-49d5fbfd55bf | OS::TripleO::BootstrapNode::SoftwareConfig | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| ControllerBootstrapNodeDeployment | c963d53d-879b-4a41-a10a-9000ac9f02a1 | OS::Heat::StructuredDeployments | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| ControllerCephDeployment | 2d4281df-31ea-4433-820d-984a6dca6eb1 | OS::Heat::StructuredDeployments | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| ControllerClusterConfig | 719c0d30-a4b8-4f77-9ab6-b3c9759abeb3 | OS::Heat::StructuredConfig | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| ControllerClusterDeployment | d929aa40-1b73-429e-81d5-aaf966fa6756 | OS::Heat::StructuredDeployments | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| ControllerSwiftDeployment | cf28f9fe-025d-4eed-b3e5-3a5284a2aa60 | OS::Heat::StructuredDeployments | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| HeatAuthEncryptionKey | overcloud-HeatAuthEncryptionKey-5uw6wo7kavnq | OS::Heat::RandomString | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| MysqlClusterUniquePart | overcloud-MysqlClusterUniquePart-vazyj2s4n2o5 | OS::Heat::RandomString | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| MysqlRootPassword | overcloud-MysqlRootPassword-nek2iky7zfdm | OS::Heat::RandomString | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| ObjectStorage | 47327c98-533e-4cc2-b1f3-d8d0eedba822 | OS::Heat::ResourceGroup | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| ObjectStorageAllNodesDeployment | 7bb691aa-fa93-4f10-833e-6edeccc61408 | OS::Heat::StructuredDeployments | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| ObjectStorageNodesPostDeployment | d4d16f39-384a-4d6a-9719-1dd9b2d4ff09 | OS::TripleO::ObjectStoragePostDeployment | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| ObjectStorageSwiftDeployment | afc87385-8b40-4097-b529-2a5bc81c94c8 | OS::Heat::StructuredDeployments | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| PublicVirtualIP | 4dd92878-8f29-49d8-9d3d-bc0cd44d26a9 | OS::Neutron::Port | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| RabbitCookie | overcloud-RabbitCookie-uthzbos3l66v | OS::Heat::RandomString | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| SwiftDevicesAndProxyConfig | e2141170-bb77-4509-b8bd-58447b2cd15f | OS::TripleO::SwiftDevicesAndProxy::SoftwareConfig | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
| allNodesConfig | cbd42692-fffa-4527-a519-bd4014ebf0fb | OS::TripleO::AllNodes::SoftwareConfig | CREATE_COMPLETE | 2015-04-06T21:15:20Z |
+-----------------------------------+-----------------------------------------------+---------------------------------------------------+-----------------+----------------------+
In this example, notice how the **ControllerNodesPostDeployment** resource
has failed. The **\*PostDeployment** resources are the configuration that is
applied to the deployed Overcloud nodes. When these resources have failed it
indicates that something went wrong during the Overcloud node configuration,
perhaps when Puppet was run.
* Show the failed resource
::
$ heat resource-show overcloud ControllerNodesPostDeployment
+------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Property | Value |
+------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| attributes | {} |
| description | |
| links | http://192.0.2.1:8004/v1/cea2a0c78d2447bc9a0f7caa35c9224c/stacks/overcloud/ec3e3251-f949-4df9-92be-dbd37c6992a1/resources/ControllerNodesPostDeployment (self) |
| | http://192.0.2.1:8004/v1/cea2a0c78d2447bc9a0f7caa35c9224c/stacks/overcloud/ec3e3251-f949-4df9-92be-dbd37c6992a1 (stack) |
| | http://192.0.2.1:8004/v1/cea2a0c78d2447bc9a0f7caa35c9224c/stacks/overcloud-ControllerNodesPostDeployment-6kcqm5zuymqu/e551e472-f2db-4468-b586-0374678d71a3 (nested) |
| logical_resource_id | ControllerNodesPostDeployment |
| physical_resource_id | e551e472-f2db-4468-b586-0374678d71a3 |
| required_by | BlockStorageNodesPostDeployment |
| | CephStorageNodesPostDeployment |
| resource_name | ControllerNodesPostDeployment |
| resource_status | CREATE_FAILED |
| resource_status_reason | ResourceUnknownStatus: Resource failed - Unknown status FAILED due to "None" |
| resource_type | OS::TripleO::ControllerPostDeployment |
| updated_time | 2015-04-06T21:15:20Z |
+------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
The ``resource-show`` doesn't always show a clear reason why the resource
failed. In these cases, logging into the Overcloud node is required to
further troubleshoot the issue.
* Logging into Overcloud nodes
Use the nova client to see the IP addresses of the Overcloud nodes.
::
$ nova list
+--------------------------------------+-------------------------------------------------------+--------+------------+-------------+---------------------+
| ID | Name | Status | Task State | Power State | Networks |
+--------------------------------------+-------------------------------------------------------+--------+------------+-------------+---------------------+
| 18014b02-b143-4ca2-aeb9-5553bec93cff | ov-4tvbtgpv7w-0-soqocxy2w4fr-NovaCompute-nlrxd3lgmmlt | ACTIVE | - | Running | ctlplane=192.0.2.13 |
| 96a57a46-1e48-4c66-adaa-342ee4e98972 | ov-rf4hby6sblk-0-iso3zlqmyzfe-Controller-xm2imjkzalhi | ACTIVE | - | Running | ctlplane=192.0.2.14 |
+--------------------------------------+-------------------------------------------------------+--------+------------+-------------+---------------------+
Login as the ``heat-admin`` user to one of the deployed nodes. In this
example, since the **ControllerNodesPostDeployment** resource failed, login
to the controller node. The ``heat-admin`` user has sudo access.
::
$ ssh heat-admin@192.0.2.14
While logged in to the controller node, examine the log for the
``os-collect-config`` log for a possible reason for the failure.
::
$ sudo journalctl -u os-collect-config
* Failed Nova Server ResourceGroup Deployments
In some cases, Nova fails deploying the node in entirety. This situation
would be indicated by a failed ``OS::Heat::ResourceGroup`` for one of the
Overcloud role types such as Control or Compute.
Use nova to see the failure in this case.
::
$ nova list
$ nova show <server-id>
The most common error shown will reference the error message ``No valid host
was found``. Refer to `No Valid Host Found Error`_ below.
In other cases, look at the following log files for further troubleshooting::
/var/log/nova/*
/var/log/heat/*
/var/log/ironic/*
* Using SOS
SOS is a set of tools that gathers information about system hardware and
configuration. The information can then be used for diagnostic purposes and
debugging. SOS is commonly used to help support technicians and developers.
SOS is useful on both the undercloud and overcloud. Install the ``sos``
package and then generate a report::
$ sudo sosreport --all-logs
No Valid Host Found Error
~~~~~~~~~~~~~~~~~~~~~~~~~
Sometimes ``/var/log/nova/nova-conductor.log`` contains the following error::
NoValidHost: No valid host was found. There are not enough hosts available.
"No valid host was found" means that the Nova Scheduler could not find a bare
metal node suitable for booting the new instance.
This in turn usually means some mismatch between resources that Nova expects
to find and resources that Ironic advertised to Nova.
A few things should be checked in this case:
#. Introspection should have succeeded for you before, or you should have
entered the required Ironic node properties manually.
For each node in ``ironic node-list`` use
::
ironic node-show <IRONIC-NODE-UUID>
and make sure that ``properties`` JSON field has valid values for keys
``cpus``, ``cpu_arch``, ``memory_mb`` and ``local_gb``.
#. Nova flavor that you are using does not exceed the Ironic node properties
above for a required number of nodes. Use
::
nova flavor-show <FLAVOR NAME>
to compare.
#. Make sure that enough nodes are in ``available`` state according to
``ironic node-list``. Nodes in ``manageable`` state usually mean they
have failed introspection.
#. Make sure nodes you're going to deploy to are not in maintenance mode.
Again, use ``ironic node-list`` to check. A node automatically going to
maintenance mode usually means wrong power credentials for this node. Check
them and then remove maintenance mode::
ironic node-set-maintenance <IRONIC-NODE-UUID> off
#. If you're using advanced profile matching with multiple flavors, make sure
you have enough nodes corresponding to each flavor/profile. Watch
``capabilities`` key in ``properties`` field for ``ironic node-show``.
It should contain e.g. ``profile:compute``.
#. It takes some time for nodes information to propagate from Ironic to Nova
after introspection. Our tooling usually accounts for it, but if you did
some steps manually, there may be a period of time when nodes are not
available to Nova yet. Check that
::
nova hypervisor-stats
correctly shows total amount of resources in your system.

5
doc/source/troubleshooting/troubleshooting-tripleo-heat-templates.rst
View File

@ -1,5 +0,0 @@
Debugging TripleO Heat Templates
================================
Please follow this flow:
http://hardysteven.blogspot.co.uk/2015/04/debugging-tripleo-heat-templates.html

22
doc/source/troubleshooting/troubleshooting-virt-setup.rst
View File

@ -1,22 +0,0 @@
Troubleshooting instack-virt-setup Failures
===========================================
* Due to a `bug in libvirt`_, it is possible for instack-virt-setup to fail
with an error such as the following::
libvirt: QEMU Driver error : unsupported configuration: This QEMU doesn't support virtio scsi controller
Traceback (most recent call last):
File "/usr/libexec/openstack-tripleo/configure-vm", line 133, in <module>
main()
File "/usr/libexec/openstack-tripleo/configure-vm", line 129, in main
a = conn.defineXML(libvirt_template)
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3445, in defineXML
if ret is None:raise libvirtError('virDomainDefineXML() failed', conn=self)
libvirt.libvirtError: unsupported configuration: This QEMU doesn't support virtio scsi controller
The workaround is to do delete the libvirt capabilities cache and restart the service::
rm -Rf /var/cache/libvirt/qemu/capabilities/
systemctl restart libvirtd
.. _bug in libvirt: https://bugzilla.redhat.com/show_bug.cgi?id=1195882

14
doc/source/troubleshooting/troubleshooting.rst
View File

@ -1,14 +0,0 @@
Troubleshooting
===============
At this chapter you will find answers for frequently asked questions and
help with troubleshooting when using RDO-Manager.
.. toctree::
Virtual Setup Problems <troubleshooting-virt-setup>
Image Building Problems <troubleshooting-image-build>
Node Management Problems <troubleshooting-nodes>
Failed Overcloud Deployment <troubleshooting-overcloud>
Tripleo Heat Templates <troubleshooting-tripleo-heat-templates>

4
tox.ini
View File

@ -13,10 +13,6 @@ commands = python setup.py testr --slowest --testr-args='{posargs}'
[testenv:venv]
commands = {posargs}
[testenv:docs]
commands = sphinx-build -a -t external doc/source/ build/sphinx/html
sphinx-build -a -t internal doc/source/ build/sphinx/internal-html
[testenv:pep8]
whitelist_externals = bash
# We fail pretty horribly on bashate right now