RETIRED, Disk image elements for deployment images of OpenStack
Go to file
Dan Prince 1f9c1f7385 Make nova-novncproxy usable in a public cloud.
This refactors the nova-novncproxy configuration in TripleO
so that it can be used in a cloud where the compute hosts
don't each have to be assigned a public IP. With the
new configuration the nova-novncproxy is configured
to run on the nova-api (controller) node which
typically will have a public IP assigned to it.

Specific changes include:

 -move novnc element to nova-novncproxy
 -move all the nova-novncproxy stuff out of nova-kvm into
  the new nova-novncproxy element
 -configures Fedora iptables rules to support noVNC
  connections on 6080
 -Adds a new nova.public_ip parameter which is used
  to construct the novncproxy_base_url. This may be
  returned directly to cloud users via
  'nova get-vnc-console' or consumed by Horizon.
 -Set vncserver_proxyclient_address to the real
  local(internal) IP address for the compute host.
  Previously we used 127.0.0.1 which won't work
  unless nova-novncproxy runs on the Nova compute host.
  To do this we use {{local-ipv4}} which should always
  be the Heat provided local management IP address
  for the compute host.

Change-Id: I18cdc36248749390f0ab1e2c454741dbf2736e7f
Closes-bug: #1309510
2014-04-18 10:14:49 -04:00
docs Rename Openstack to OpenStack 2014-02-13 16:58:25 +08:00
elements Make nova-novncproxy usable in a public cloud. 2014-04-18 10:14:49 -04:00
tests Add unit tests for os-svc-daemon 2014-03-28 19:55:29 -05:00
.gitignore Look for local.json in preference to config.json. 2014-02-14 14:27:12 +13:00
.gitreview Update stackforge references to openstack 2013-08-17 22:57:21 -04:00
.testr.conf Add a .testr.conf configuration and ignore .testrepository. 2012-12-14 20:17:39 +13:00
babel.cfg Make it possible for openstack-CI to run tests 2013-02-04 22:26:17 -08:00
LICENSE Fix copyrights for HP work. 2012-11-15 16:20:32 +13:00
MANIFEST.in Package with pbr 2013-08-06 12:50:39 +12:00
README.md Remove many references to github 2014-03-18 15:06:23 +11:00
requirements.txt Align build files and requirements 2013-09-28 23:18:29 -04:00
setup.cfg Support building wheels (PEP-427) 2013-11-19 10:35:35 +01:00
setup.py Align build files and requirements 2013-09-28 23:18:29 -04:00
test-requirements.txt Enable unit testing 2014-03-28 19:55:12 -05:00
tox.ini Enable unit testing 2014-03-28 19:55:12 -05:00

Image building rules for OpenStack images

These elements are used to build disk images for deploying OpenStack via Heat. They are built as part of the TripleO (https://wiki.openstack.org/wiki/TripleO) umbrella project.

Instructions

Checkout this source tree and also the diskimage builder, export an ELEMENTS_PATH to add elements from this tree, and build any disk images you need.

git clone https://git.openstack.org/openstack/diskimage-builder.git
git clone https://git.openstack.org/openstack/tripleo-image-elements.git
export ELEMENTS_PATH=tripleo-image-elements/elements
diskimage-builder/bin/disk-image-create -u base vm bootstrap local-config stackuser heat-cfntools -a i386 -o bootstrap

Common element combinations

Always include heat-cfntools in images that you intend to boot via heat : if that is not done, then the user ssh keys are not reliably pulled down from the metadata server due to interactions with cloud-init.

Architecture

OpenStack images are intended to be deployed and maintained using Nova + Heat.

As such they should strive to be stateless, maintained entirely via automation.

Configuration

In a running OpenStack there are several categories of config.

  • per user - e.g. ssh key registration with nova: we repeat this sort of config every time we add a user.
  • local node - e.g. nova.conf or ovs-vsctl add-br br-ex : settings that apply individually to machines
  • inter-node - e.g. credentials on rabbitmq for a given nova compute node
  • application state - e.g. 'neutron net-create ...' : settings that apply to the whole cluster not on a per-user / per-tenant basis

We have five places we can do configuration in TripleO:

  • image build time
  • in-instance heat-driven (ORC scripts)
  • in-instance first-boot scripts [deprecated]
  • from outside via APIs
  • orchestrated by Heat

Our current heuristic for deciding where to do any particular configuration step:

  • per user config should be done from the outside via APIs, even for users like 'admin' that we know we'll have. Note that service accounts are different - they are a form of inter-node configuration.
  • local node configuration should be done via ORC driven by Heat and/or configuration management system metadata.
  • inter-node configuration should be done by working through Heat. For instance, creating a rabbit account for a nova compute node is something that Heat should arrange, though the act of creating is probably done by a script on the rabbit server - triggered by Heat - and applying the config is done on the compute node by the local node script - again triggered by Heat.
  • application state changes should be done from outside via APIs
  • first-boot scripts should not be used.

Copyright

Copyright 2012,2013 Hewlett-Packard Development Company, L.P. Copyright (c) 2012 NTT DOCOMO, INC.

All Rights Reserved.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.