OpenStack - User contributions [en]

Meetings/TripleO

2015-12-04T17:50:00Z

Tzumainn: /* One-off agenda items */

= Weekly TripleO team meeting =
'''MEETING TIME: Every Tuesday at 14:00 UTC''' in <code><nowiki>#openstack-meeting-alt</nowiki></code>.

See [http://eavesdrop.openstack.org/irc-meetings.ical the iCal feed] to check the time this week.

== Agenda for next meeting ==

We have a standing agenda + one-off items, please add your one-off thing here:

=== One-off agenda items ===
<pre>
* confirm that people are okay with *not* renaming tripleo-common just yet, even though we're placing the API code in there (tzumainn)
* add items here.
</pre>

=== Review Highlights ===
* https://review.openstack.org/#/c/209505/ (Docker compute)
* https://review.openstack.org/#/c/188137/ (Manila integration)
* https://review.openstack.org/#/c/220863/ (Sahara integration)
* https://review.openstack.org/#/c/219927/ (os-net-config linux bridge)
* https://review.openstack.org/#/c/218134/10 (os-net-config linux bonding)

=== Regular agenda ===
Copy/Paste into IRC to kick the meeting off:
<pre>
#startmeeting tripleo
</pre>

Then, once the bot has caught up and everyone is settled:

<pre>
#topic agenda
* bugs
* Projects releases or stable backports
* CI
* Specs
* one off agenda items
* open discussion

Remember that anyone can use the link and info commands, not just the moderator - if you have something worth noting in the meeting minutes feel free to tag it
#topic bugs
</pre>

== bugs ==
* https://bugs.launchpad.net/tripleo/
* https://bugs.launchpad.net/diskimage-builder/
* https://bugs.launchpad.net/os-refresh-config
* https://bugs.launchpad.net/os-apply-config
* https://bugs.launchpad.net/os-cloud-config
* https://bugs.launchpad.net/os-collect-config
* https://bugs.launchpad.net/os-net-config
* https://bugs.launchpad.net/tuskar
* https://bugs.launchpad.net/python-tuskarclient

Copy/Paste for IRC:
<pre>
#link https://bugs.launchpad.net/tripleo/
#link https://bugs.launchpad.net/diskimage-builder/
#link https://bugs.launchpad.net/os-refresh-config
#link https://bugs.launchpad.net/os-apply-config
#link https://bugs.launchpad.net/os-collect-config
#link https://bugs.launchpad.net/os-cloud-config
#link https://bugs.launchpad.net/os-net-config
#link https://bugs.launchpad.net/tuskar
#link https://bugs.launchpad.net/python-tuskarclient
</pre>

== reviews ==

Here we check the review SLA and discuss any thorny blocked reviews.

Copy/paste for IRC:
<pre>
#info There's a dashboard linked from https://wiki.openstack.org/wiki/TripleO#Review_team - look for "TripleO Inbox Dashboard"
#link http://russellbryant.net/openstack-stats/tripleo-openreviews.html
#link http://russellbryant.net/openstack-stats/tripleo-reviewers-30.txt
#link http://russellbryant.net/openstack-stats/tripleo-reviewers-90.txt
</pre>

Other useful links:
* http://www.stackalytics.com/report/reviews/tripleo-group/open
* http://stackalytics.com/report/contribution/tripleo-group/30
* http://stackalytics.com/report/contribution/tripleo-group/90
* http://russellbryant.net/openstack-stats/tripleo-openreviews.html
* http://russellbryant.net/openstack-stats/tripleo-reviewers-30.txt
* http://russellbryant.net/openstack-stats/tripleo-reviewers-90.txt

== CI ==
CI status - http://tripleo.org/cistatus.html

== Previous meetings ==

* [http://eavesdrop.openstack.org/meetings/tripleo]

Meetings/TripleO

2015-11-13T12:16:35Z

Tzumainn: /* Agenda for next meeting */

= Weekly TripleO team meeting =
'''MEETING TIME: Every Tuesday at 14:00 UTC''' in <code><nowiki>#openstack-meeting-alt</nowiki></code>.

See [https://www.google.com/calendar/ical/bj05mroquq28jhud58esggqmh4@group.calendar.google.com/public/basic.ics the iCal feed] to check the time this week.

== Agenda for next meeting ==

We have a standing agenda + one-off items, please add your one-off thing here:

=== One-off agenda items ===
<pre>
* followup on tripleo-api location - separate repo or a renamed tripleo-common (tzumainn)
* add items here...
</pre>

=== Review Highlights ===
* https://review.openstack.org/#/c/209505/ (Docker compute)
* https://review.openstack.org/#/c/188137/ (Manila integration)
* https://review.openstack.org/#/c/220863/ (Sahara integration)
* https://review.openstack.org/#/c/219927/ (os-net-config linux bridge)
* https://review.openstack.org/#/c/218134/10 (os-net-config linux bonding)

=== Regular agenda ===
Copy/Paste into IRC to kick the meeting off:
<pre>
#startmeeting tripleo
</pre>

Then, once the bot has caught up and everyone is settled:

<pre>
#topic agenda
* bugs
* Projects releases or stable backports
* CI
* Specs
* Review Priorities: https://etherpad.openstack.org/p/tripleo-review-priorities
* one off agenda items
* open discussion

Remember that anyone can use the link and info commands, not just the moderator - if you have something worth noting in the meeting minutes feel free to tag it
#topic bugs
</pre>

== bugs ==
* https://bugs.launchpad.net/tripleo/
* https://bugs.launchpad.net/diskimage-builder/
* https://bugs.launchpad.net/os-refresh-config
* https://bugs.launchpad.net/os-apply-config
* https://bugs.launchpad.net/os-cloud-config
* https://bugs.launchpad.net/os-collect-config
* https://bugs.launchpad.net/os-net-config
* https://bugs.launchpad.net/tuskar
* https://bugs.launchpad.net/python-tuskarclient

Copy/Paste for IRC:
<pre>
#link https://bugs.launchpad.net/tripleo/
#link https://bugs.launchpad.net/diskimage-builder/
#link https://bugs.launchpad.net/os-refresh-config
#link https://bugs.launchpad.net/os-apply-config
#link https://bugs.launchpad.net/os-collect-config
#link https://bugs.launchpad.net/os-cloud-config
#link https://bugs.launchpad.net/os-net-config
#link https://bugs.launchpad.net/tuskar
#link https://bugs.launchpad.net/python-tuskarclient
</pre>

== reviews ==

Here we check the review SLA and discuss any thorny blocked reviews.

Copy/paste for IRC:
<pre>
#info There's a dashboard linked from https://wiki.openstack.org/wiki/TripleO#Review_team - look for "TripleO Inbox Dashboard"
#link http://russellbryant.net/openstack-stats/tripleo-openreviews.html
#link http://russellbryant.net/openstack-stats/tripleo-reviewers-30.txt
#link http://russellbryant.net/openstack-stats/tripleo-reviewers-90.txt
</pre>

Other useful links:
* http://www.stackalytics.com/report/reviews/tripleo-group/open
* http://stackalytics.com/report/contribution/tripleo-group/30
* http://stackalytics.com/report/contribution/tripleo-group/90
* http://russellbryant.net/openstack-stats/tripleo-openreviews.html
* http://russellbryant.net/openstack-stats/tripleo-reviewers-30.txt
* http://russellbryant.net/openstack-stats/tripleo-reviewers-90.txt

== CI ==
CI status - http://tripleo.org/cistatus.html

== Previous meetings ==

* [http://eavesdrop.openstack.org/meetings/tripleo]

Meetings/TripleO

2015-11-07T04:37:02Z

Tzumainn: /* One-off agenda items */

= Weekly TripleO team meeting =
'''MEETING TIME: Every Tuesday at 14:00 UTC''' in <code><nowiki>#openstack-meeting-alt</nowiki></code>.

See [https://www.google.com/calendar/ical/bj05mroquq28jhud58esggqmh4@group.calendar.google.com/public/basic.ics the iCal feed] to check the time this week.

== Agenda for next meeting ==

We have a standing agenda + one-off items, please add your one-off thing here:

=== One-off agenda items ===
<pre>
* Add "Bump trunk" as a regular item (derekh)
* OAC templates breakage, better to just leave those as they are now that we don't have CI? (gfidente)
* Discuss REST API naming - tripleo-api or tuskar v3? The latter was the consensus at Summit, but comments on the spec review - https://review.openstack.org/#/c/230432/7 - argue for the former. (tzumainn)
</pre>

=== Review Highlights ===
* https://review.openstack.org/#/c/209505/ (Docker compute)
* https://review.openstack.org/#/c/188137/ (Manila integration)
* https://review.openstack.org/#/c/220863/ (Sahara integration)
* https://review.openstack.org/#/c/219927/ (os-net-config linux bridge)
* https://review.openstack.org/#/c/218134/10 (os-net-config linux bonding)

=== Regular agenda ===
Copy/Paste into IRC to kick the meeting off:
<pre>
#startmeeting tripleo
</pre>

Then, once the bot has caught up and everyone is settled:

<pre>
#topic agenda
* bugs
* Projects releases or stable backports
* CI
* Specs
* Review Priorities: https://etherpad.openstack.org/p/tripleo-review-priorities
* one off agenda items
* open discussion

Remember that anyone can use the link and info commands, not just the moderator - if you have something worth noting in the meeting minutes feel free to tag it
#topic bugs
</pre>

== bugs ==
* https://bugs.launchpad.net/tripleo/
* https://bugs.launchpad.net/diskimage-builder/
* https://bugs.launchpad.net/os-refresh-config
* https://bugs.launchpad.net/os-apply-config
* https://bugs.launchpad.net/os-cloud-config
* https://bugs.launchpad.net/os-collect-config
* https://bugs.launchpad.net/os-net-config
* https://bugs.launchpad.net/tuskar
* https://bugs.launchpad.net/python-tuskarclient

Copy/Paste for IRC:
<pre>
#link https://bugs.launchpad.net/tripleo/
#link https://bugs.launchpad.net/diskimage-builder/
#link https://bugs.launchpad.net/os-refresh-config
#link https://bugs.launchpad.net/os-apply-config
#link https://bugs.launchpad.net/os-collect-config
#link https://bugs.launchpad.net/os-cloud-config
#link https://bugs.launchpad.net/os-net-config
#link https://bugs.launchpad.net/tuskar
#link https://bugs.launchpad.net/python-tuskarclient
</pre>

== reviews ==

Here we check the review SLA and discuss any thorny blocked reviews.

Copy/paste for IRC:
<pre>
#info There's a dashboard linked from https://wiki.openstack.org/wiki/TripleO#Review_team - look for "TripleO Inbox Dashboard"
#link http://russellbryant.net/openstack-stats/tripleo-openreviews.html
#link http://russellbryant.net/openstack-stats/tripleo-reviewers-30.txt
#link http://russellbryant.net/openstack-stats/tripleo-reviewers-90.txt
</pre>

Other useful links:
* http://www.stackalytics.com/report/reviews/tripleo-group/open
* http://stackalytics.com/report/contribution/tripleo-group/30
* http://stackalytics.com/report/contribution/tripleo-group/90
* http://russellbryant.net/openstack-stats/tripleo-openreviews.html
* http://russellbryant.net/openstack-stats/tripleo-reviewers-30.txt
* http://russellbryant.net/openstack-stats/tripleo-reviewers-90.txt

== CI ==
CI status - http://tripleo.org/cistatus.html

== Previous meetings ==

* [http://eavesdrop.openstack.org/meetings/tripleo]

Tuskar/Devtest

2014-09-08T04:28:17Z

Tzumainn: /* Setup devtest */

== Overview ==
Devtest is a script that creates a development environment for TripleO / Tuskar / TuskarUI development. Below you can find step-by-step instructions for setting up the environment using devtest. If you would like more information about how devtest works as well as the script itself, see the following links
* http://docs.openstack.org/developer/tripleo-incubator/index.html
* https://github.com/openstack/tripleo-incubator/blob/master/scripts/devtest.sh
However, following the steps below should lead to a complete functioning setup.

== Instructions ==

=== Setup devtest ===
All commands (unless otherwise specified) should be run as root, in a dedicated machine you will use for TripleO development. We will call this machine "the lab machine" or "the lab server". The setup has been tested with lab machines running Fedora 19.

Note: You might want to move the location of the default libvirt storage pool. The default location is /var/lib/libvirt/images. Depending on your file system / partitions setup, there might not be enough space for images at this default location. To be on the safe side, you can move it to another location which has plenty of space. Below is an example how to move the default storage pool location to /home/images. If you are sure that there is enough space at the default location, you can skip this step.

mkdir /home/images
yum install -y libvirt
service libvirtd start
virsh pool-destroy default
virsh pool-undefine default
virsh pool-define-as default dir --target /home/images
virsh pool-start default
virsh pool-autostart default
service libvirtd restart

Install git and kvm. Installing kvm at this point sets the ownership of the /dev/kvm correctly (it should be owned by the root user and kvm group). If you don't do this, devtest will fail due to incorrectly set ownership of /dev/kvm.
yum -y install git kvm

Check access rights on /dev/kvm afterwards. If group is not kvm or group doesn't have rw on this file, execute the following commands and reboot:
chgrp kvm /dev/kvm
chmod g+rw /dev/kvm

Create devtest configuration file:
cat <<'EOF' > ~/.devtestrc
export NODE_CPU=1 NODE_MEM=4096 NODE_DISK=60 NODE_ARCH=amd64
export NODE_DIST="fedora selinux-permissive"
export DIB_RELEASE=20
export UNDERCLOUD_DIB_EXTRA_ARGS=""
export OVERCLOUD_DIB_EXTRA_ARGS=""
export OVERCLOUD_COMPUTESCALE=1
export TRIPLEO_CLEANUP=1
export USE_IRONIC=1
EOF

Clone the tripleo-incubator repo and run the devtest script:
export TRIPLEO_ROOT=~/tripleo
mkdir -p $TRIPLEO_ROOT
cd $TRIPLEO_ROOT
git clone https://git.openstack.org/openstack/tripleo-incubator
$TRIPLEO_ROOT/tripleo-incubator/scripts/devtest.sh --trash-my-machine
# wait around 2+ hours
# mawagner: if openvswitch fails to start, see https://bugzilla.redhat.com/show_bug.cgi?id=1006412 (or just mkdir /var/lock/subsys)

If you want to e.g. redeploy Overcloud for testing purposes, you will need to source following
source tripleo-incubator/scripts/devtest_variables.sh
source ./tripleo-undercloud-passwords
source ./tripleo-incubator/undercloudrc
source $TRIPLEO_ROOT/tripleo-incubator/cloudprompt
source ~/.devtestrc

Build the block storage image
$TRIPLEO_ROOT/diskimage-builder/bin/disk-image-create $NODE_DIST \
-a $NODE_ARCH -o $TRIPLEO_ROOT/overcloud-cinder-volume hosts \
baremetal cinder-volume neutron-openvswitch-agent os-collect-config heat-cfntools pip-cache \
dhcp-all-interfaces $DIB_COMMON_ELEMENTS $OVERCLOUD_COMPUTE_DIB_EXTRA_ARGS 2>&1 | \
tee $TRIPLEO_ROOT/dib-overcloud-cinder-volume.log

load-image overcloud-cinder-volume.qcow2

To be able to deploy object storage node, you need this
$TRIPLEO_ROOT/diskimage-builder/bin/disk-image-create $NODE_DIST \
-a $NODE_ARCH -o $TRIPLEO_ROOT/overcloud-swift-storage hosts \
baremetal swift-storage neutron-openvswitch-agent os-collect-config \
dhcp-all-interfaces $DIB_COMMON_ELEMENTS $OVERCLOUD_COMPUTE_DIB_EXTRA_ARGS 2>&1 | \
tee $TRIPLEO_ROOT/dib-overcloud-swift-storage.log

load-image overcloud-swift-storage.qcow2

To list MAC's for virsh listed machines run
virsh list --all
virsh dumpxml baremetal_0 | grep 'mac address' | cut -d\' -f2

At this point, your devtest environment is configured. To proceed, you need to install Tuskar, Horizon and Tuskar-UI, since they are not installed by devtest.

=== Install Tuskar ===

mkdir -p /opt/stack && cd /opt/stack
git clone https://git.openstack.org/openstack/tuskar

Follow the instructions here to complete the install: https://github.com/openstack/tuskar/blob/master/doc/source/INSTALL.rst. Make sure that you create the initial data.

To be able to deploy Overcloud via Tuskar, you need to delete the Overcloud created by Devtest first.
Go to the Undercloud machine and delete the Overcloud:
ssh heat-admin@192.0.2.3
sudo -i
source stackrc
heat stack-delete overcloud

Devtest will also set up Tuskar endpoints, but pointing to the undercloud machine. You need them point to your machine. This can be done by deleting and readding endpoints, but it's quicker to just modify them in mysql:
ssh heat-admin@192.0.2.3
sudo -i
mysql -u keystone -p keystone
Enter password: unset
update endpoint, service set endpoint.url="http://<yourlocalip>:8585/" where service.type="management" and endpoint.service_id=service.id;

Finally, you'll want to set up an initial plan, some roles, and link the two:

# create a plan
curl -i -X POST -H 'X-Auth-Token: xxxxxxxxxxxxxxxxxxxxxxxx' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-tuskarclient' -d '{"name": "overcloud", "description": "overcloud"}' http://127.0.0.1:8585/v2/plans
# load roles
tuskar-load-roles --config-file etc/tuskar/tuskar.conf sample-hot-templates/

# list roles to get their uuids
curl -i -X GET -H 'X-Auth-Token: xxxxxxxxxxxxxxxxxxxxxxxxx' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-tuskarclient' http://127.0.0.1:8585/v2/roles
# add each role to the plan (you'll have to run this once for each role)
curl -i -X POST -H 'X-Auth-Token: 2ac5b3b685bc5fd18c9618a7d7e306a3' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-tuskarclient' -d '{"uuid": "<role_uuid>"}' http://127.0.0.1:8585/v2/plans/<plan_uuid>roles

=== Add Horizon and Tuskar-UI ===
Install and configure Horizon and Tuskar-UI using the instructions at: http://tuskar-ui.readthedocs.org/en/latest/install.html. Make sure to clone the horizon and tuskar-ui repositories in /opt/stack.

.Afterwards, copy /root/stackrc from the undercloud to the lab machine, change the OS_AUTH_URL to point to the undercloud, and source it:
ssh heat-admin@192.0.2.3 "sudo -i cat /root/stackrc" > /root/stackrc
sed -i 's/localhost:5000/192.0.2.3:5000/' /root/stackrc
source /root/stackrc

Configure OPENSTACK_HOST in horizon settings to point to the undercloud machine:
sed -i 's/OPENSTACK_HOST = "127.0.0.1"/OPENSTACK_HOST = "192.0.2.3"/' /opt/stack/horizon/openstack_dashboard/local/local_settings.py

Start the server:
tools/with_venv.sh ./manage.py runserver 0.0.0.0:8111

Now you can see the UI from your browser (you can find credentials for dashboard in undercloud machine in /root/stackrc):
lab-machine:8111

If you want to develop locally, you need only to mount the remote folder containing the code, in your local file system:
yum install -y sshfs && mkdir -p ~/devtest
sshfs root@lab-machine:/opt/stack/ ~/devtest

=== Script for installing Tuskar and Tuskar UI ===
There is a script to automatically do previous two steps: https://gist.github.com/Divius/9525147. It clones to the current directory, uses sudo to do privileged operations, so it can be used by non-root. The only requirement is that stackrc file is in the current directory. Also note that the script is mostly unsupported and can become outdated.

Tuskar/Devtest

2014-09-08T04:27:40Z

Tzumainn: /* Setup devtest */

Tuskar/Devtest

2014-08-26T20:53:56Z

Tzumainn: /* Install Tuskar */

== Overview ==
Devtest is a script that creates a development environment for TripleO / Tuskar / TuskarUI development. Below you can find step-by-step instructions for setting up the environment using devtest. If you would like more information about how devtest works as well as the script itself, see the following links
* http://docs.openstack.org/developer/tripleo-incubator/index.html
* https://github.com/openstack/tripleo-incubator/blob/master/scripts/devtest.sh
However, following the steps below should lead to a complete functioning setup.

== Instructions ==

=== Setup devtest ===
All commands (unless otherwise specified) should be run as root, in a dedicated machine you will use for TripleO development. We will call this machine "the lab machine" or "the lab server". The setup has been tested with lab machines running Fedora 19.

Note: You might want to move the location of the default libvirt storage pool. The default location is /var/lib/libvirt/images. Depending on your file system / partitions setup, there might not be enough space for images at this default location. To be on the safe side, you can move it to another location which has plenty of space. Below is an example how to move the default storage pool location to /home/images. If you are sure that there is enough space at the default location, you can skip this step.

mkdir /home/images
yum install -y libvirt
service libvirtd start
virsh pool-destroy default
virsh pool-undefine default
virsh pool-define-as default dir --target /home/images
virsh pool-start default
virsh pool-autostart default
service libvirtd restart

Install git and kvm. Installing kvm at this point sets the ownership of the /dev/kvm correctly (it should be owned by the root user and kvm group). If you don't do this, devtest will fail due to incorrectly set ownership of /dev/kvm.
yum -y install git kvm

Check access rights on /dev/kvm afterwards. If group is not kvm or group doesn't have rw on this file, execute the following commands and reboot:
chgrp kvm /dev/kvm
chmod g+rw /dev/kvm

Create devtest configuration file:
cat <<'EOF' > ~/.devtestrc
export NODE_CPU=1 NODE_MEM=4096 NODE_DISK=60 NODE_ARCH=amd64
export NODE_DIST="fedora selinux-permissive"
export DIB_RELEASE=20
export UNDERCLOUD_DIB_EXTRA_ARGS=""
export OVERCLOUD_DIB_EXTRA_ARGS=""
export OVERCLOUD_COMPUTESCALE=1
export TRIPLEO_CLEANUP=1
EOF

Clone the tripleo-incubator repo and run the devtest script:
export TRIPLEO_ROOT=~/tripleo
mkdir -p $TRIPLEO_ROOT
cd $TRIPLEO_ROOT
git clone https://git.openstack.org/openstack/tripleo-incubator
$TRIPLEO_ROOT/tripleo-incubator/scripts/devtest.sh --trash-my-machine
# wait around 2+ hours
# mawagner: if openvswitch fails to start, see https://bugzilla.redhat.com/show_bug.cgi?id=1006412 (or just mkdir /var/lock/subsys)

If you want to e.g. redeploy Overcloud for testing purposes, you will need to source following
source tripleo-incubator/scripts/devtest_variables.sh
source ./tripleo-undercloud-passwords
source ./tripleo-incubator/undercloudrc
source $TRIPLEO_ROOT/tripleo-incubator/cloudprompt
source ~/.devtestrc

Build the block storage image
$TRIPLEO_ROOT/diskimage-builder/bin/disk-image-create $NODE_DIST \
-a $NODE_ARCH -o $TRIPLEO_ROOT/overcloud-cinder-volume hosts \
baremetal cinder-volume neutron-openvswitch-agent os-collect-config heat-cfntools pip-cache \
dhcp-all-interfaces $DIB_COMMON_ELEMENTS $OVERCLOUD_COMPUTE_DIB_EXTRA_ARGS 2>&1 | \
tee $TRIPLEO_ROOT/dib-overcloud-cinder-volume.log

load-image overcloud-cinder-volume.qcow2

To be able to deploy object storage node, you need this
$TRIPLEO_ROOT/diskimage-builder/bin/disk-image-create $NODE_DIST \
-a $NODE_ARCH -o $TRIPLEO_ROOT/overcloud-swift-storage hosts \
baremetal swift-storage neutron-openvswitch-agent os-collect-config \
dhcp-all-interfaces $DIB_COMMON_ELEMENTS $OVERCLOUD_COMPUTE_DIB_EXTRA_ARGS 2>&1 | \
tee $TRIPLEO_ROOT/dib-overcloud-swift-storage.log

load-image overcloud-swift-storage.qcow2

To list MAC's for virsh listed machines run
virsh list --all
virsh dumpxml baremetal_0 | grep 'mac address' | cut -d\' -f2

At this point, your devtest environment is configured. To proceed, you need to install Tuskar, Horizon and Tuskar-UI, since they are not installed by devtest.

=== Install Tuskar ===

mkdir -p /opt/stack && cd /opt/stack
git clone https://git.openstack.org/openstack/tuskar

Follow the instructions here to complete the install: https://github.com/openstack/tuskar/blob/master/doc/source/INSTALL.rst. Make sure that you create the initial data.

To be able to deploy Overcloud via Tuskar, you need to delete the Overcloud created by Devtest first.
Go to the Undercloud machine and delete the Overcloud:
ssh heat-admin@192.0.2.3
sudo -i
source stackrc
heat stack-delete overcloud

Devtest will also set up Tuskar endpoints, but pointing to the undercloud machine. You need them point to your machine. This can be done by deleting and readding endpoints, but it's quicker to just modify them in mysql:
ssh heat-admin@192.0.2.3
sudo -i
mysql -u keystone -p keystone
Enter password: unset
update endpoint, service set endpoint.url="http://<yourlocalip>:8585/" where service.type="management" and endpoint.service_id=service.id;

Finally, you'll want to set up an initial plan, some roles, and link the two:

# create a plan
curl -i -X POST -H 'X-Auth-Token: xxxxxxxxxxxxxxxxxxxxxxxx' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-tuskarclient' -d '{"name": "overcloud", "description": "overcloud"}' http://127.0.0.1:8585/v2/plans
# load roles
tuskar-load-roles --config-file etc/tuskar/tuskar.conf sample-hot-templates/

# list roles to get their uuids
curl -i -X GET -H 'X-Auth-Token: xxxxxxxxxxxxxxxxxxxxxxxxx' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-tuskarclient' http://127.0.0.1:8585/v2/roles
# add each role to the plan (you'll have to run this once for each role)
curl -i -X POST -H 'X-Auth-Token: 2ac5b3b685bc5fd18c9618a7d7e306a3' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-tuskarclient' -d '{"uuid": "<role_uuid>"}' http://127.0.0.1:8585/v2/plans/<plan_uuid>roles

=== Add Horizon and Tuskar-UI ===
Install and configure Horizon and Tuskar-UI using the instructions at: http://tuskar-ui.readthedocs.org/en/latest/install.html. Make sure to clone the horizon and tuskar-ui repositories in /opt/stack.

.Afterwards, copy /root/stackrc from the undercloud to the lab machine, change the OS_AUTH_URL to point to the undercloud, and source it:
ssh heat-admin@192.0.2.3 "sudo -i cat /root/stackrc" > /root/stackrc
sed -i 's/localhost:5000/192.0.2.3:5000/' /root/stackrc
source /root/stackrc

Configure OPENSTACK_HOST in horizon settings to point to the undercloud machine:
sed -i 's/OPENSTACK_HOST = "127.0.0.1"/OPENSTACK_HOST = "192.0.2.3"/' /opt/stack/horizon/openstack_dashboard/local/local_settings.py

Start the server:
tools/with_venv.sh ./manage.py runserver 0.0.0.0:8111

Now you can see the UI from your browser (you can find credentials for dashboard in undercloud machine in /root/stackrc):
lab-machine:8111

If you want to develop locally, you need only to mount the remote folder containing the code, in your local file system:
yum install -y sshfs && mkdir -p ~/devtest
sshfs root@lab-machine:/opt/stack/ ~/devtest

=== Script for installing Tuskar and Tuskar UI ===
There is a script to automatically do previous two steps: https://gist.github.com/Divius/9525147. It clones to the current directory, uses sudo to do privileged operations, so it can be used by non-root. The only requirement is that stackrc file is in the current directory. Also note that the script is mostly unsupported and can become outdated.

Tuskar/Devtest

2014-08-26T20:44:58Z

Tzumainn: /* Install Tuskar */

== Overview ==
Devtest is a script that creates a development environment for TripleO / Tuskar / TuskarUI development. Below you can find step-by-step instructions for setting up the environment using devtest. If you would like more information about how devtest works as well as the script itself, see the following links
* http://docs.openstack.org/developer/tripleo-incubator/index.html
* https://github.com/openstack/tripleo-incubator/blob/master/scripts/devtest.sh
However, following the steps below should lead to a complete functioning setup.

== Instructions ==

=== Setup devtest ===
All commands (unless otherwise specified) should be run as root, in a dedicated machine you will use for TripleO development. We will call this machine "the lab machine" or "the lab server". The setup has been tested with lab machines running Fedora 19.

Note: You might want to move the location of the default libvirt storage pool. The default location is /var/lib/libvirt/images. Depending on your file system / partitions setup, there might not be enough space for images at this default location. To be on the safe side, you can move it to another location which has plenty of space. Below is an example how to move the default storage pool location to /home/images. If you are sure that there is enough space at the default location, you can skip this step.

mkdir /home/images
yum install -y libvirt
service libvirtd start
virsh pool-destroy default
virsh pool-undefine default
virsh pool-define-as default dir --target /home/images
virsh pool-start default
virsh pool-autostart default
service libvirtd restart

Install git and kvm. Installing kvm at this point sets the ownership of the /dev/kvm correctly (it should be owned by the root user and kvm group). If you don't do this, devtest will fail due to incorrectly set ownership of /dev/kvm.
yum -y install git kvm

Check access rights on /dev/kvm afterwards. If group is not kvm or group doesn't have rw on this file, execute the following commands and reboot:
chgrp kvm /dev/kvm
chmod g+rw /dev/kvm

Create devtest configuration file:
cat <<'EOF' > ~/.devtestrc
export NODE_CPU=1 NODE_MEM=4096 NODE_DISK=60 NODE_ARCH=amd64
export NODE_DIST="fedora selinux-permissive"
export DIB_RELEASE=20
export UNDERCLOUD_DIB_EXTRA_ARGS=""
export OVERCLOUD_DIB_EXTRA_ARGS=""
export OVERCLOUD_COMPUTESCALE=1
export TRIPLEO_CLEANUP=1
EOF

Clone the tripleo-incubator repo and run the devtest script:
export TRIPLEO_ROOT=~/tripleo
mkdir -p $TRIPLEO_ROOT
cd $TRIPLEO_ROOT
git clone https://git.openstack.org/openstack/tripleo-incubator
$TRIPLEO_ROOT/tripleo-incubator/scripts/devtest.sh --trash-my-machine
# wait around 2+ hours
# mawagner: if openvswitch fails to start, see https://bugzilla.redhat.com/show_bug.cgi?id=1006412 (or just mkdir /var/lock/subsys)

If you want to e.g. redeploy Overcloud for testing purposes, you will need to source following
source tripleo-incubator/scripts/devtest_variables.sh
source ./tripleo-undercloud-passwords
source ./tripleo-incubator/undercloudrc
source $TRIPLEO_ROOT/tripleo-incubator/cloudprompt
source ~/.devtestrc

Build the block storage image
$TRIPLEO_ROOT/diskimage-builder/bin/disk-image-create $NODE_DIST \
-a $NODE_ARCH -o $TRIPLEO_ROOT/overcloud-cinder-volume hosts \
baremetal cinder-volume neutron-openvswitch-agent os-collect-config heat-cfntools pip-cache \
dhcp-all-interfaces $DIB_COMMON_ELEMENTS $OVERCLOUD_COMPUTE_DIB_EXTRA_ARGS 2>&1 | \
tee $TRIPLEO_ROOT/dib-overcloud-cinder-volume.log

load-image overcloud-cinder-volume.qcow2

To be able to deploy object storage node, you need this
$TRIPLEO_ROOT/diskimage-builder/bin/disk-image-create $NODE_DIST \
-a $NODE_ARCH -o $TRIPLEO_ROOT/overcloud-swift-storage hosts \
baremetal swift-storage neutron-openvswitch-agent os-collect-config \
dhcp-all-interfaces $DIB_COMMON_ELEMENTS $OVERCLOUD_COMPUTE_DIB_EXTRA_ARGS 2>&1 | \
tee $TRIPLEO_ROOT/dib-overcloud-swift-storage.log

load-image overcloud-swift-storage.qcow2

To list MAC's for virsh listed machines run
virsh list --all
virsh dumpxml baremetal_0 | grep 'mac address' | cut -d\' -f2

At this point, your devtest environment is configured. To proceed, you need to install Tuskar, Horizon and Tuskar-UI, since they are not installed by devtest.

=== Install Tuskar ===

mkdir -p /opt/stack && cd /opt/stack
git clone https://git.openstack.org/openstack/tuskar

Follow the instructions here to complete the install: https://github.com/openstack/tuskar/blob/master/doc/source/INSTALL.rst. Make sure that you create the initial data.

To be able to deploy Overcloud via Tuskar, you need to delete the Overcloud created by Devtest first.
Go to the Undercloud machine and delete the Overcloud:
ssh heat-admin@192.0.2.3
sudo -i
source stackrc
heat stack-delete overcloud

Devtest will also set up Tuskar endpoints, but pointing to the undercloud machine. You need them point to your machine. This can be done by deleting and readding endpoints, but it's quicker to just modify them in mysql:
ssh heat-admin@192.0.2.3
sudo -i
mysql -u keystone -p keystone
Enter password: unset
update endpoint, service set endpoint.url="http://<yourlocalip>:8585/" where service.type="management" and endpoint.service_id=service.id;

Finally, you'll want to set up an initial plan, some roles, and link the two:

curl -i -X POST -H 'X-Auth-Token: xxxxxxxxxxxxxxxxxxxxxxxx' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-tuskarclient' -d '{"name": "overcloud", "description": "overcloud"}' http://127.0.0.1:8585/v2/plans
tuskar-load-roles --config-file etc/tuskar/tuskar.conf sample-hot-templates/

=== Add Horizon and Tuskar-UI ===
Install and configure Horizon and Tuskar-UI using the instructions at: http://tuskar-ui.readthedocs.org/en/latest/install.html. Make sure to clone the horizon and tuskar-ui repositories in /opt/stack.

.Afterwards, copy /root/stackrc from the undercloud to the lab machine, change the OS_AUTH_URL to point to the undercloud, and source it:
ssh heat-admin@192.0.2.3 "sudo -i cat /root/stackrc" > /root/stackrc
sed -i 's/localhost:5000/192.0.2.3:5000/' /root/stackrc
source /root/stackrc

Configure OPENSTACK_HOST in horizon settings to point to the undercloud machine:
sed -i 's/OPENSTACK_HOST = "127.0.0.1"/OPENSTACK_HOST = "192.0.2.3"/' /opt/stack/horizon/openstack_dashboard/local/local_settings.py

Start the server:
tools/with_venv.sh ./manage.py runserver 0.0.0.0:8111

Now you can see the UI from your browser (you can find credentials for dashboard in undercloud machine in /root/stackrc):
lab-machine:8111

If you want to develop locally, you need only to mount the remote folder containing the code, in your local file system:
yum install -y sshfs && mkdir -p ~/devtest
sshfs root@lab-machine:/opt/stack/ ~/devtest

=== Script for installing Tuskar and Tuskar UI ===
There is a script to automatically do previous two steps: https://gist.github.com/Divius/9525147. It clones to the current directory, uses sudo to do privileged operations, so it can be used by non-root. The only requirement is that stackrc file is in the current directory. Also note that the script is mostly unsupported and can become outdated.

Tuskar/Devtest

2014-08-26T20:44:13Z

Tzumainn: /* Install Tuskar */

== Overview ==
Devtest is a script that creates a development environment for TripleO / Tuskar / TuskarUI development. Below you can find step-by-step instructions for setting up the environment using devtest. If you would like more information about how devtest works as well as the script itself, see the following links
* http://docs.openstack.org/developer/tripleo-incubator/index.html
* https://github.com/openstack/tripleo-incubator/blob/master/scripts/devtest.sh
However, following the steps below should lead to a complete functioning setup.

== Instructions ==

=== Setup devtest ===
All commands (unless otherwise specified) should be run as root, in a dedicated machine you will use for TripleO development. We will call this machine "the lab machine" or "the lab server". The setup has been tested with lab machines running Fedora 19.

Note: You might want to move the location of the default libvirt storage pool. The default location is /var/lib/libvirt/images. Depending on your file system / partitions setup, there might not be enough space for images at this default location. To be on the safe side, you can move it to another location which has plenty of space. Below is an example how to move the default storage pool location to /home/images. If you are sure that there is enough space at the default location, you can skip this step.

mkdir /home/images
yum install -y libvirt
service libvirtd start
virsh pool-destroy default
virsh pool-undefine default
virsh pool-define-as default dir --target /home/images
virsh pool-start default
virsh pool-autostart default
service libvirtd restart

Install git and kvm. Installing kvm at this point sets the ownership of the /dev/kvm correctly (it should be owned by the root user and kvm group). If you don't do this, devtest will fail due to incorrectly set ownership of /dev/kvm.
yum -y install git kvm

Check access rights on /dev/kvm afterwards. If group is not kvm or group doesn't have rw on this file, execute the following commands and reboot:
chgrp kvm /dev/kvm
chmod g+rw /dev/kvm

Create devtest configuration file:
cat <<'EOF' > ~/.devtestrc
export NODE_CPU=1 NODE_MEM=4096 NODE_DISK=60 NODE_ARCH=amd64
export NODE_DIST="fedora selinux-permissive"
export DIB_RELEASE=20
export UNDERCLOUD_DIB_EXTRA_ARGS=""
export OVERCLOUD_DIB_EXTRA_ARGS=""
export OVERCLOUD_COMPUTESCALE=1
export TRIPLEO_CLEANUP=1
EOF

Clone the tripleo-incubator repo and run the devtest script:
export TRIPLEO_ROOT=~/tripleo
mkdir -p $TRIPLEO_ROOT
cd $TRIPLEO_ROOT
git clone https://git.openstack.org/openstack/tripleo-incubator
$TRIPLEO_ROOT/tripleo-incubator/scripts/devtest.sh --trash-my-machine
# wait around 2+ hours
# mawagner: if openvswitch fails to start, see https://bugzilla.redhat.com/show_bug.cgi?id=1006412 (or just mkdir /var/lock/subsys)

If you want to e.g. redeploy Overcloud for testing purposes, you will need to source following
source tripleo-incubator/scripts/devtest_variables.sh
source ./tripleo-undercloud-passwords
source ./tripleo-incubator/undercloudrc
source $TRIPLEO_ROOT/tripleo-incubator/cloudprompt
source ~/.devtestrc

Build the block storage image
$TRIPLEO_ROOT/diskimage-builder/bin/disk-image-create $NODE_DIST \
-a $NODE_ARCH -o $TRIPLEO_ROOT/overcloud-cinder-volume hosts \
baremetal cinder-volume neutron-openvswitch-agent os-collect-config heat-cfntools pip-cache \
dhcp-all-interfaces $DIB_COMMON_ELEMENTS $OVERCLOUD_COMPUTE_DIB_EXTRA_ARGS 2>&1 | \
tee $TRIPLEO_ROOT/dib-overcloud-cinder-volume.log

load-image overcloud-cinder-volume.qcow2

To be able to deploy object storage node, you need this
$TRIPLEO_ROOT/diskimage-builder/bin/disk-image-create $NODE_DIST \
-a $NODE_ARCH -o $TRIPLEO_ROOT/overcloud-swift-storage hosts \
baremetal swift-storage neutron-openvswitch-agent os-collect-config \
dhcp-all-interfaces $DIB_COMMON_ELEMENTS $OVERCLOUD_COMPUTE_DIB_EXTRA_ARGS 2>&1 | \
tee $TRIPLEO_ROOT/dib-overcloud-swift-storage.log

load-image overcloud-swift-storage.qcow2

To list MAC's for virsh listed machines run
virsh list --all
virsh dumpxml baremetal_0 | grep 'mac address' | cut -d\' -f2

At this point, your devtest environment is configured. To proceed, you need to install Tuskar, Horizon and Tuskar-UI, since they are not installed by devtest.

=== Install Tuskar ===

mkdir -p /opt/stack && cd /opt/stack
git clone https://git.openstack.org/openstack/tuskar

Follow the instructions here to complete the install: https://github.com/openstack/tuskar/blob/master/doc/source/INSTALL.rst. Make sure that you create the initial data.

To be able to deploy Overcloud via Tuskar, you need to delete the Overcloud created by Devtest first.
Go to the Undercloud machine and delete the Overcloud:
ssh heat-admin@192.0.2.3
sudo -i
source stackrc
heat stack-delete overcloud

Devtest will also set up Tuskar endpoints, but pointing to the undercloud machine. You need them point to your machine. This can be done by deleting and readding endpoints, but it's quicker to just modify them in mysql:
ssh heat-admin@192.0.2.3
sudo -i
mysql -u keystone -p keystone
Enter password: unset
update endpoint, service set endpoint.url="http://<yourlocalip>:8585/" where service.type="management" and endpoint.service_id=service.id;

Finally, you'll want to set up an initial plan, some roles, and link the two:

curl -iPOST -H 'X-Auth-Token: xxxxxxxxxxxxxxxxxx' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-tuskarclient' -d '{"name": "overcloud", "description": "overcloud"}' http://127.0.0.1:8585/v2/plans
tuskar-load-roles --config-file etc/tuskar/tuskar.conf sample-hot-templates/

=== Add Horizon and Tuskar-UI ===
Install and configure Horizon and Tuskar-UI using the instructions at: http://tuskar-ui.readthedocs.org/en/latest/install.html. Make sure to clone the horizon and tuskar-ui repositories in /opt/stack.

.Afterwards, copy /root/stackrc from the undercloud to the lab machine, change the OS_AUTH_URL to point to the undercloud, and source it:
ssh heat-admin@192.0.2.3 "sudo -i cat /root/stackrc" > /root/stackrc
sed -i 's/localhost:5000/192.0.2.3:5000/' /root/stackrc
source /root/stackrc

Configure OPENSTACK_HOST in horizon settings to point to the undercloud machine:
sed -i 's/OPENSTACK_HOST = "127.0.0.1"/OPENSTACK_HOST = "192.0.2.3"/' /opt/stack/horizon/openstack_dashboard/local/local_settings.py

Start the server:
tools/with_venv.sh ./manage.py runserver 0.0.0.0:8111

Now you can see the UI from your browser (you can find credentials for dashboard in undercloud machine in /root/stackrc):
lab-machine:8111

If you want to develop locally, you need only to mount the remote folder containing the code, in your local file system:
yum install -y sshfs && mkdir -p ~/devtest
sshfs root@lab-machine:/opt/stack/ ~/devtest

=== Script for installing Tuskar and Tuskar UI ===
There is a script to automatically do previous two steps: https://gist.github.com/Divius/9525147. It clones to the current directory, uses sudo to do privileged operations, so it can be used by non-root. The only requirement is that stackrc file is in the current directory. Also note that the script is mostly unsupported and can become outdated.

Tuskar/Devtest

2014-08-26T20:36:42Z

Tzumainn: /* Install Tuskar */

== Overview ==
Devtest is a script that creates a development environment for TripleO / Tuskar / TuskarUI development. Below you can find step-by-step instructions for setting up the environment using devtest. If you would like more information about how devtest works as well as the script itself, see the following links
* http://docs.openstack.org/developer/tripleo-incubator/index.html
* https://github.com/openstack/tripleo-incubator/blob/master/scripts/devtest.sh
However, following the steps below should lead to a complete functioning setup.

== Instructions ==

=== Setup devtest ===
All commands (unless otherwise specified) should be run as root, in a dedicated machine you will use for TripleO development. We will call this machine "the lab machine" or "the lab server". The setup has been tested with lab machines running Fedora 19.

Note: You might want to move the location of the default libvirt storage pool. The default location is /var/lib/libvirt/images. Depending on your file system / partitions setup, there might not be enough space for images at this default location. To be on the safe side, you can move it to another location which has plenty of space. Below is an example how to move the default storage pool location to /home/images. If you are sure that there is enough space at the default location, you can skip this step.

mkdir /home/images
yum install -y libvirt
service libvirtd start
virsh pool-destroy default
virsh pool-undefine default
virsh pool-define-as default dir --target /home/images
virsh pool-start default
virsh pool-autostart default
service libvirtd restart

Install git and kvm. Installing kvm at this point sets the ownership of the /dev/kvm correctly (it should be owned by the root user and kvm group). If you don't do this, devtest will fail due to incorrectly set ownership of /dev/kvm.
yum -y install git kvm

Check access rights on /dev/kvm afterwards. If group is not kvm or group doesn't have rw on this file, execute the following commands and reboot:
chgrp kvm /dev/kvm
chmod g+rw /dev/kvm

Create devtest configuration file:
cat <<'EOF' > ~/.devtestrc
export NODE_CPU=1 NODE_MEM=4096 NODE_DISK=60 NODE_ARCH=amd64
export NODE_DIST="fedora selinux-permissive"
export DIB_RELEASE=20
export UNDERCLOUD_DIB_EXTRA_ARGS=""
export OVERCLOUD_DIB_EXTRA_ARGS=""
export OVERCLOUD_COMPUTESCALE=1
export TRIPLEO_CLEANUP=1
EOF

Clone the tripleo-incubator repo and run the devtest script:
export TRIPLEO_ROOT=~/tripleo
mkdir -p $TRIPLEO_ROOT
cd $TRIPLEO_ROOT
git clone https://git.openstack.org/openstack/tripleo-incubator
$TRIPLEO_ROOT/tripleo-incubator/scripts/devtest.sh --trash-my-machine
# wait around 2+ hours
# mawagner: if openvswitch fails to start, see https://bugzilla.redhat.com/show_bug.cgi?id=1006412 (or just mkdir /var/lock/subsys)

If you want to e.g. redeploy Overcloud for testing purposes, you will need to source following
source tripleo-incubator/scripts/devtest_variables.sh
source ./tripleo-undercloud-passwords
source ./tripleo-incubator/undercloudrc
source $TRIPLEO_ROOT/tripleo-incubator/cloudprompt
source ~/.devtestrc

Build the block storage image
$TRIPLEO_ROOT/diskimage-builder/bin/disk-image-create $NODE_DIST \
-a $NODE_ARCH -o $TRIPLEO_ROOT/overcloud-cinder-volume hosts \
baremetal cinder-volume neutron-openvswitch-agent os-collect-config heat-cfntools pip-cache \
dhcp-all-interfaces $DIB_COMMON_ELEMENTS $OVERCLOUD_COMPUTE_DIB_EXTRA_ARGS 2>&1 | \
tee $TRIPLEO_ROOT/dib-overcloud-cinder-volume.log

load-image overcloud-cinder-volume.qcow2

To be able to deploy object storage node, you need this
$TRIPLEO_ROOT/diskimage-builder/bin/disk-image-create $NODE_DIST \
-a $NODE_ARCH -o $TRIPLEO_ROOT/overcloud-swift-storage hosts \
baremetal swift-storage neutron-openvswitch-agent os-collect-config \
dhcp-all-interfaces $DIB_COMMON_ELEMENTS $OVERCLOUD_COMPUTE_DIB_EXTRA_ARGS 2>&1 | \
tee $TRIPLEO_ROOT/dib-overcloud-swift-storage.log

load-image overcloud-swift-storage.qcow2

To list MAC's for virsh listed machines run
virsh list --all
virsh dumpxml baremetal_0 | grep 'mac address' | cut -d\' -f2

At this point, your devtest environment is configured. To proceed, you need to install Tuskar, Horizon and Tuskar-UI, since they are not installed by devtest.

=== Install Tuskar ===

mkdir -p /opt/stack && cd /opt/stack
git clone https://git.openstack.org/openstack/tuskar

Follow the instructions here to complete the install: https://github.com/openstack/tuskar/blob/master/doc/source/INSTALL.rst. Make sure that you create the initial data.

To be able to deploy Overcloud via Tuskar, you need to delete the Overcloud created by Devtest first.
Go to the Undercloud machine and delete the Overcloud:
ssh heat-admin@192.0.2.3
sudo -i
source stackrc
heat stack-delete overcloud

Devtest will also set up Tuskar endpoints, but pointing to the undercloud machine. You need them point to your machine. This can be done by deleting and readding endpoints, but it's quicker to just modify them in mysql:
ssh heat-admin@192.0.2.3
sudo -i
mysql -u keystone -p keystone
Enter password: unset
update endpoint, service set endpoint.url="http://<yourlocalip>:8585/" where service.type="management" and endpoint.service_id=service.id;

Finally, you'll want to set up an initial plan, some roles, and link the two:

tuskar-load-roles --config-file etc/tuskar/tuskar.conf sample-hot-templates/

=== Add Horizon and Tuskar-UI ===
Install and configure Horizon and Tuskar-UI using the instructions at: http://tuskar-ui.readthedocs.org/en/latest/install.html. Make sure to clone the horizon and tuskar-ui repositories in /opt/stack.

.Afterwards, copy /root/stackrc from the undercloud to the lab machine, change the OS_AUTH_URL to point to the undercloud, and source it:
ssh heat-admin@192.0.2.3 "sudo -i cat /root/stackrc" > /root/stackrc
sed -i 's/localhost:5000/192.0.2.3:5000/' /root/stackrc
source /root/stackrc

Configure OPENSTACK_HOST in horizon settings to point to the undercloud machine:
sed -i 's/OPENSTACK_HOST = "127.0.0.1"/OPENSTACK_HOST = "192.0.2.3"/' /opt/stack/horizon/openstack_dashboard/local/local_settings.py

Start the server:
tools/with_venv.sh ./manage.py runserver 0.0.0.0:8111

Now you can see the UI from your browser (you can find credentials for dashboard in undercloud machine in /root/stackrc):
lab-machine:8111

If you want to develop locally, you need only to mount the remote folder containing the code, in your local file system:
yum install -y sshfs && mkdir -p ~/devtest
sshfs root@lab-machine:/opt/stack/ ~/devtest

=== Script for installing Tuskar and Tuskar UI ===
There is a script to automatically do previous two steps: https://gist.github.com/Divius/9525147. It clones to the current directory, uses sudo to do privileged operations, so it can be used by non-root. The only requirement is that stackrc file is in the current directory. Also note that the script is mostly unsupported and can become outdated.

Tuskar/UsageGuide

2014-05-09T20:54:46Z

Tzumainn: /* Specifiy Deployment Parameters and Options */

== Overview ==

This guide details the usage of the Tuskar UI. It assumes that you have already installed Tuskar and the Tuskar UI. If you have not, please follow one of the [[TripleO/Tuskar#Getting_Started|Installation Guides]] first.

A [https://www.youtube.com/watch?v=-6whFIqCqLU narrated video] is also available.

== Register Nodes ==

Start by logging into the Tuskar UI. The Tuskar UI is designed as a plugin to Horizon. The recommended installation will eliminate the standard 'Project' and 'Admin' dashboard, leaving only the Tuskar UI's 'Infrastructure' dashboard.

First you'll need to register some nodes. Click on the Nodes tab, then on the "Register Nodes" button in the upper-right corner.

You'll see a form that asks you to input your nodes' details. At a minimum you must specify the NIC mac address, the number of CPUs, the memory, and the local disk. You can enter information for multiple nodes by clicking on the "Add Node" link. Once done, click "Register Nodes".

If the nodes are registered successfully, you'll be back at the Nodes index page; only now there will be a count of Free Nodes. Before using these nodes for a cloud deployment, you'll want to wait a minute for nova to register them for use as a hypervisor.

== Create Flavors ==

The next step is to create flavors. Flavors are used so that your OpenStack Deployment knows which Nodes are appropriate for use.

Click on the Flavors tab. If no flavors exist, click on Flavor Suggestions. Here, you'll see suggested flavor specifications that match the nodes created in the previous step. To create them, simply click on the 'Create' button, and you'll be taken to a pre-filled flavor creation form. If you are satisfied with the form values, click on 'Create Flavor'. Make sure the "Deploy Kernel Image" and "Deploy Ramdisk Image" are set to the bm-deploy-kernel and bm-deploy-ramdisk images.

Now if you select the 'Flavor' tab, you'll see that your flavor has been created.

== Associate Flavors with Roles ==

Now that your nodes and flavors have been created, we can get started on creating the actual OpenStack Deployment. Click on that tab.

You'll see a deployment creation workflow, beginning with a list of pre-defined roles. However before specifying the node count for each role, you must specify the flavor that each role will use to match appropriate nodes. To do this for each role, click on 'Add a flavor'.

An 'Edit Deployment Role' form will pop up. As these are default roles, the only value that can be modified is Flavor. Select your desired flavor and click on 'Apply Changes'.

== Specify Deployment Parameters and Options ==

Now it's time to specify the parameters and options for your Deployment. First, select the number of nodes you wish deployed in each role. Note that the Controller role must be exactly 1.

Afterwards, click on the Configuration tab. Here you can specify various configuration options for your deployment. You can also choose not to modify any of these values; Tuskar will use appropriate defaults. You'll need to set the NovaComputeLibvirtType flag to the correct option for your environment - probably kvm for Baremetal deployments and qemu for virtualized ones.

== Deployment ==

Once you are satisfied with your deployment choices, click on the 'Deploy' button. If everything goes as expected, you'll see a deployment progress bar, and here your watch begins.

As nodes are provisioned with the appropriate image for a role, this page will refresh with updated information. You can also click on the 'Log' tab to see a log of events that Heat is undertaking while creating the deployment stack.

== Post-Deployment ==

For the installation via Devtest, the initialization code can be found in Overcloud deployment
docs: http://docs.openstack.org/developer/tripleo-incubator/devtest_overcloud.html starting with step 13

Tuskar/UsageGuide

2014-05-09T20:54:33Z

Tzumainn: /* Post-Deployment */

== Overview ==

This guide details the usage of the Tuskar UI. It assumes that you have already installed Tuskar and the Tuskar UI. If you have not, please follow one of the [[TripleO/Tuskar#Getting_Started|Installation Guides]] first.

A [https://www.youtube.com/watch?v=-6whFIqCqLU narrated video] is also available.

== Register Nodes ==

Start by logging into the Tuskar UI. The Tuskar UI is designed as a plugin to Horizon. The recommended installation will eliminate the standard 'Project' and 'Admin' dashboard, leaving only the Tuskar UI's 'Infrastructure' dashboard.

First you'll need to register some nodes. Click on the Nodes tab, then on the "Register Nodes" button in the upper-right corner.

You'll see a form that asks you to input your nodes' details. At a minimum you must specify the NIC mac address, the number of CPUs, the memory, and the local disk. You can enter information for multiple nodes by clicking on the "Add Node" link. Once done, click "Register Nodes".

If the nodes are registered successfully, you'll be back at the Nodes index page; only now there will be a count of Free Nodes. Before using these nodes for a cloud deployment, you'll want to wait a minute for nova to register them for use as a hypervisor.

== Create Flavors ==

The next step is to create flavors. Flavors are used so that your OpenStack Deployment knows which Nodes are appropriate for use.

Click on the Flavors tab. If no flavors exist, click on Flavor Suggestions. Here, you'll see suggested flavor specifications that match the nodes created in the previous step. To create them, simply click on the 'Create' button, and you'll be taken to a pre-filled flavor creation form. If you are satisfied with the form values, click on 'Create Flavor'. Make sure the "Deploy Kernel Image" and "Deploy Ramdisk Image" are set to the bm-deploy-kernel and bm-deploy-ramdisk images.

Now if you select the 'Flavor' tab, you'll see that your flavor has been created.

== Associate Flavors with Roles ==

Now that your nodes and flavors have been created, we can get started on creating the actual OpenStack Deployment. Click on that tab.

You'll see a deployment creation workflow, beginning with a list of pre-defined roles. However before specifying the node count for each role, you must specify the flavor that each role will use to match appropriate nodes. To do this for each role, click on 'Add a flavor'.

An 'Edit Deployment Role' form will pop up. As these are default roles, the only value that can be modified is Flavor. Select your desired flavor and click on 'Apply Changes'.

== Specifiy Deployment Parameters and Options ==

Now it's time to specify the parameters and options for your Deployment. First, select the number of nodes you wish deployed in each role. Note that the Controller role must be exactly 1.

Afterwards, click on the Configuration tab. Here you can specify various configuration options for your deployment. You can also choose not to modify any of these values; Tuskar will use appropriate defaults. You'll need to set the NovaComputeLibvirtType flag to the correct option for your environment - probably kvm for Baremetal deployments and qemu for virtualized ones.

== Deployment ==

Once you are satisfied with your deployment choices, click on the 'Deploy' button. If everything goes as expected, you'll see a deployment progress bar, and here your watch begins.

As nodes are provisioned with the appropriate image for a role, this page will refresh with updated information. You can also click on the 'Log' tab to see a log of events that Heat is undertaking while creating the deployment stack.

== Post-Deployment ==

For the installation via Devtest, the initialization code can be found in Overcloud deployment
docs: http://docs.openstack.org/developer/tripleo-incubator/devtest_overcloud.html starting with step 13

Tuskar/UsageGuide

2014-05-09T18:59:31Z

Tzumainn: /* Register Nodes */

== Overview ==

This guide details the usage of the Tuskar UI. It assumes that you have already installed Tuskar and the Tuskar UI. If you have not, please follow one of the [[TripleO/Tuskar#Getting_Started|Installation Guides]] first.

A [https://www.youtube.com/watch?v=-6whFIqCqLU narrated video] is also available.

== Register Nodes ==

Start by logging into the Tuskar UI. The Tuskar UI is designed as a plugin to Horizon. The recommended installation will eliminate the standard 'Project' and 'Admin' dashboard, leaving only the Tuskar UI's 'Infrastructure' dashboard.

First you'll need to register some nodes. Click on the Nodes tab, then on the "Register Nodes" button in the upper-right corner.

You'll see a form that asks you to input your nodes' details. At a minimum you must specify the NIC mac address, the number of CPUs, the memory, and the local disk. You can enter information for multiple nodes by clicking on the "Add Node" link. Once done, click "Register Nodes".

If the nodes are registered successfully, you'll be back at the Nodes index page; only now there will be a count of Free Nodes. Before using these nodes for a cloud deployment, you'll want to wait a minute for nova to register them for use as a hypervisor.

== Create Flavors ==

The next step is to create flavors. Flavors are used so that your OpenStack Deployment knows which Nodes are appropriate for use.

Click on the Flavors tab. If no flavors exist, click on Flavor Suggestions. Here, you'll see suggested flavor specifications that match the nodes created in the previous step. To create them, simply click on the 'Create' button, and you'll be taken to a pre-filled flavor creation form. If you are satisfied with the form values, click on 'Create Flavor'. Make sure the "Deploy Kernel Image" and "Deploy Ramdisk Image" are set to the bm-deploy-kernel and bm-deploy-ramdisk images.

Now if you select the 'Flavor' tab, you'll see that your flavor has been created.

== Associate Flavors with Roles ==

Now that your nodes and flavors have been created, we can get started on creating the actual OpenStack Deployment. Click on that tab.

You'll see a deployment creation workflow, beginning with a list of pre-defined roles. However before specifying the node count for each role, you must specify the flavor that each role will use to match appropriate nodes. To do this for each role, click on 'Add a flavor'.

An 'Edit Deployment Role' form will pop up. As these are default roles, the only value that can be modified is Flavor. Select your desired flavor and click on 'Apply Changes'.

== Specifiy Deployment Parameters and Options ==

Now it's time to specify the parameters and options for your Deployment. First, select the number of nodes you wish deployed in each role. Note that the Controller role must be exactly 1.

Afterwards, click on the Configuration tab. Here you can specify various configuration options for your deployment. You can also choose not to modify any of these values; Tuskar will use appropriate defaults. You'll need to set the NovaComputeLibvirtType flag to the correct option for your environment - probably kvm for Baremetal deployments and qemu for virtualized ones.

== Deployment ==

Once you are satisfied with your deployment choices, click on the 'Deploy' button. If everything goes as expected, you'll see a deployment progress bar, and here your watch begins.

As nodes are provisioned with the appropriate image for a role, this page will refresh with updated information. You can also click on the 'Log' tab to see a log of events that Heat is undertaking while creating the deployment stack.

== Post-Deployment ==

For the installation via Devtest, the initialization code can be found in Overcloud deployment
docs: http://docs.openstack.org/developer/tripleo-incubator/devtest_overcloud.html starting with step 13

For the installation via Instack, you can find the code for Overcloud Deployment here:
https://github.com/agroup/instack-undercloud/blob/master/scripts/instack-deploy-overcloud-tuskarcli

TripleO/TuskarJunoPlanning/TemplateBackend

2014-05-07T15:00:40Z

Tzumainn: /* Overview */

= Overview =

The purpose of this page is to describe a change in architecture to use Heat templates and environments as the data store for Tuskar.

This design assumes the following:

* completion of the Juno changes to the TripleO Heat templates to use provider resources.
* images are created outside of Tuskar

----

= Format =

There are two main types of information that are needed when configuring an overcloud:
* The selection and count of what services will be run in the cloud.
* The configuration for those services.

The Icehouse release for Tuskar uses a database to store both pieces of information. For Juno, the goal is to move that information directly into the Heat templates themselves. This will be accomplished using two recently added features of Heat: provider resources and environments. Provider resources allow for fine-grained stacks to be defined and built up into a larger Heat stack. Environments are a way to capture the selection of which provider resources to use and their configuration values.

Using these features, Tuskar will be able to choose a subset of the TripleO Heat templates to include in the overcloud. Those templates remain static and unedited by Tuskar. Tuskar is then responsible for generating the overall cloud template that includes each of the provider resources and the environment file for saving the configuration.

The following series of diagrams shows the relationships between the provider resource templates and the Tuskar-generated files that will use them for configuring a cloud. ''Note: Discussion on where these files are stored is elsewhere on this page; what follows is a description of the interplay between the TripleO templates and the Tuskar-generated files.''

== Step 1: Create a Cloud ==

[[File:Generated-1.png]]

When a cloud is initially created in Tuskar, it is comprised of two files: the deployment plan which is the overarching Heat template that configures the cloud's stack and the environment file which contains the provider resource mappings and cloud's configuration values. ''Note: The names of these files as depicted in the diagram are not final.''

The files listed on the left are provider resource templates from TripleO. They are not edited by Tuskar and are used as building blocks for the cloud's stack.

== Step 2: Select Roles ==

[[File:Generated-2.png]]

The Icehouse release of Tuskar uses the term "role" to describe an individual function of the cloud. For the purposes of this discussion, they are considered to map 1:1 with provider resource template files. ''Note: This is likely not 100% accurate but is a sufficient abstraction for now.''

In the diagram above, the user has selected both alpha and beta for inclusion in the cloud. At this point, Tuskar makes the following changes to its generated files:
* A reference to the template file is added to the environment. The example simply names them X and Y; a better naming scheme will be determined in the future. More details on what this reference looks like are discussed below.
* A resource for each provider resource is added to the plan template.

== Step 3: Configuration Consolidation ==

[[File:Generated-3.png]]

The plan template needs to expose the configurable parameters of each provider resource. The example in the diagram is intentionally simplistic; there is no overlap in parameter names between provider resources. Resolving conflicts is potentially complicated. There are a few scenarios to consider:
* The same value should be used across multiple resources. For instance, if both alpha and beta expose a value called "key_name" for the SSH keypair and the same keypair should be used for each resource.
* Multiple provider resources use the same name for a parameter but will need separate values. For instance, if alpha and beta both simply use "image_id", however the likely usage is that they will be created from different images.
* A single provider resource, used multiple times and configured differently in each case. For instance, two uses of the provider resource that use a different flavor.

Further discussion on possible solutions can be found in the Open Questions section.

== Step 4: Configuration Mapping ==

[[File:Generated-4.png]]

In addition to consolidating the configurable parameters, the generated plan template needs to map the parameters to the appropriate resources. How much work needs to be done here is contingent on how the consolidation takes place in step 3. If there is a renaming of the values, they will need to be properly mapped here. If the names are taken directly from the provider resource templates, this step can be omitted as Heat will automatically pass the parameters in a parent stack to its nested stacks.

== Summary ==

[[File:Generated-end.png]]

The diagram above is a summary of the steps necessary for Tuskar to generate an environment and overall plan for a cloud.

----

= Storage =

== Provider Resource Templates ==

There are two approaches being discussed with regard to how to store the provider templates and their inclusion in a deployment plan. Keep in mind that provider resource templates refers to both the TripleO Heat templates as well as any custom Heat templates uploaded by a user.

The approaches that follow are conceptual. Notes on particular implementations will be provided, but the purpose of the following sections is to focus on the desired approach. Tuskar should be written that the actual implementation backend be pluggable to support integration with existing processes (for instance, the ability to use a git-based backend for CI systems).

When considering these approaches, the following use cases should be taken into account:
* Initial creation of the cloud and selection of which provider resources to include
* Making changes to a provider resource template (either by the user or through an upgrade of Tuskar) and how those changes are propagated
* Migrating changes from one cloud to another, such as in a promotion workflow (e.g. testing in a development cloud and then migrating the new templates to a QE cloud)

In both cases, the deployment plan constitutes multiple files (at very least, an environment file and an overall Heat template). Where and how that directory of files is stored should be comparable for both of these approaches.

=== Referenced ===

[[File:Storage-ref.png]]

This approach focuses around a global repository of hosted provider resource templates. Each template is immutable and versioned, which allows templates to be changed but the changes not made live in the clouds until the user explicitly wishes them to be.

The environment file references a specific provider template (including its version) in the resource_registry section. The simplest solution is for Tuskar to use the Heat client libraries for making stack requests, which currently support HTTP URLs.

One of the drawbacks to using strict version numbering is that Heat templates do not have the concept of a version. One approach is to assume the version information is in the URL for the referenced template.

Pros:
* Strong notion of template versioning and accountability for changes
* Easy mechanism for determining the differences between two templates (for example, in the event that a template is changed globally and we need to see which clouds would be affected)

Cons:
* Places more requirements on the storage backend, such as the ability to expose multiple versions of a template with unique, static URLs
* Long term will likely need APIs for culling old versions that takes into account if they are in use

=== Copied ===

[[File:Storage-copy.png]]

This approach stores the entire contents of the deployment plan together. When the user elects to include a provider resource in a cloud, a copy is made of the template and placed in the plan. Changes can then be made on a per cloud basis.

Pros:
* Less overhead involved in making custom changes for a particular cloud; no need for a new version, the changes are made directly in the cloud
* Simpler workflow around deleting the original provider templates

Cons:
* More complicated to determine the difference between two provider templates

== Deployment Plan ==

As previous stated, the deployment plan consists of multiple files. Again, Tuskar should be written in such a way that the backend storage for these files is configurable.

----

= Tuskar APIs =

Below are some thoughts on the behavior of the Tuskar APIs. The intent is not to be full fledged REST API documentation (however the grouping of the calls is similar to how REST APIs would be structured) but rather a conceptual discussion of what each call's implementation needs to take into consideration.

== Cloud Collection ==

Example URL: <code>/clouds/</code>

Create: Creates a new cloud to be managed by Tuskar. This will create the empty environment and plan templates, as well as creating the empty stack in Heat.

List: Returns a list of all defined clouds. The format of what is returned needs to be determined and may be as simple as a list of names or enhanced include its current configuration.

== Individual Cloud ==

Example URL: <code>/clouds/<id>/</code>

Get: Retrieve the full details of the specified cloud. The format of what is returned need s to be determined, but should at least include a list of all of the roles (and their versions) and the full list of configuration values for the cloud.

Update: Adds/removes/changes values for the configuration parameters found in the environment file. This should not trigger a call to update Heat, allowing the user to stage and review multiple changes before making them live.

Delete: Deletes the given cloud's deployment plan from Tuskar and the corresponding stack in Heat.

Deploy: Trigger the current state of the cloud to be deployed/updated in Heat. ''Note: This is another case where the APIs are more conceptual than literal; from a REST point of view we'll need to figure out the right approach.''

== Cloud Roles Collection ==

Example URL: <code>/clouds/<cloud_id>/roles/</code>

Create: Adds an entry for the role to the cloud's environment file and consolidates the stack's configuration parameters. Additional steps may be taken depending on the storage model discussion above.

List: Return a list of role names, versions, and UUIDs that are present in the cloud.

== Individual Cloud Role ==

Example URL: <code>/clouds/<cloud_id>/roles/<role_uuid>/</code>

Delete: Removes the given role from the specified cloud. The configuration parameter consolidation will need to occur to remove the role's parameters from both the overall template and the parameter values in the environment file.

== Roles ==

Example URL: <code>/roles/</code>

List: List the names and versions of all roles known to Tuskar.

''Note: Create/Update/Delete: Future functionality for managing custom roles. For the immediate future, a Tuskar installation step will take care of getting the TripleO templates in the correct location.''

== Individual Role ==

Example URL: <code>/roles/<role_name_and_version/>/</code>

Get: Retrieve details of the specific role. This can either be the template directly or a parsed version that simply describes it's possible configuration parameters.

----

= Open Questions =

== Post-install Configuration Steps ==

The biggest problem with this approach is that not everything is done in the Heat templates themselves. For TripleO specifically, the os-cloud-config project exists to perform these post-Heat configuration of the cloud. In working with purely the provider resource templates, these steps are not represented.

== Parameter Consolidation ==

This was touched on earlier, but there are a number of things that need to be taken into account when arbitrarily selecting provider resources:
* In the event that two provider resources request the same parameter, there is a question of whether or not it should be the same across the stack or unique for each resource.
* There needs to be a mechanism for differentiating between two provider resources that define the same parameter. This should also take into consideration the possibility of using the same provider resource multiple times in a stack. For instance, having multiple the same resource deployed with different flavors.
* This mechanism should provide some form of UI clue as to their grouping/relationship.

== Other Cloud Data ==

The deployment plan already consists of two files: the environment and the overall Heat template. Since Tuskar is already storing a directory of files for a given cloud, it would be simple to add a Tuskar-specific file that contains extra information. This may be necessary for Tuskar to track a dirty bit that indicates if any changes have been made to the cloud but not yet sent to Heat to be made live.

== Display Name ==

A minor issue surrounds the fact that Heat templates have a description but no user-frienedly name. When displaying a list of possible roles to select, there is currently no simple way to present a user-friendly list.

TripleO/TuskarJunoPlanning/TemplateBackend

2014-05-07T15:00:15Z

Tzumainn: /* Overview */

Tuskar/Devtest

2014-04-30T20:30:05Z

Tzumainn: /* Add Horizon and Tuskar-UI */

== Overview ==
Devtest is a script that creates a development environment for TripleO / Tuskar / TuskarUI development. Below you can find step-by-step instructions for setting up the environment using devtest. If you would like more information about how devtest works as well as the script itself, see the following links
* http://docs.openstack.org/developer/tripleo-incubator/index.html
* https://github.com/openstack/tripleo-incubator/blob/master/scripts/devtest.sh
However, following the steps below should lead to a complete functioning setup.

== Instructions ==

=== Setup devtest ===
All commands (unless otherwise specified) should be run as root, in a dedicated machine you will use for TripleO development. We will call this machine "the lab machine" or "the lab server". The setup has been tested with lab machines running Fedora 19.

Note: You might want to move the location of the default libvirt storage pool. The default location is /var/lib/libvirt/images. Depending on your file system / partitions setup, there might not be enough space for images at this default location. To be on the safe side, you can move it to another location which has plenty of space. Below is an example how to move the default storage pool location to /home/images. If you are sure that there is enough space at the default location, you can skip this step.

mkdir /home/images
yum install -y libvirt
service libvirtd start
virsh pool-destroy default
virsh pool-undefine default
virsh pool-define-as default dir --target /home/images
virsh pool-start default
virsh pool-autostart default
service libvirtd restart

Install git and kvm. Installing kvm at this point sets the ownership of the /dev/kvm correctly (it should be owned by the root user and kvm group). If you don't do this, devtest will fail due to incorrectly set ownership of /dev/kvm.
yum -y install git kvm

Check access rights on /dev/kvm afterwards. If group is not kvm or group doesn't have rw on this file, execute the following commands and reboot:
chgrp kvm /dev/kvm
chmod g+rw /dev/kvm

Create devtest configuration file:
cat <<'EOF' > ~/.devtestrc
export NODE_CPU=1 NODE_MEM=4096 NODE_DISK=60 NODE_ARCH=amd64
export NODE_DIST="fedora selinux-permissive"
export DIB_RELEASE=20
export UNDERCLOUD_DIB_EXTRA_ARGS=""
export OVERCLOUD_DIB_EXTRA_ARGS=""
export OVERCLOUD_COMPUTESCALE=1
export TRIPLEO_CLEANUP=1
EOF

Clone the tripleo-incubator repo and run the devtest script:
export TRIPLEO_ROOT=~/tripleo
mkdir -p $TRIPLEO_ROOT
cd $TRIPLEO_ROOT
git clone https://git.openstack.org/openstack/tripleo-incubator
$TRIPLEO_ROOT/tripleo-incubator/scripts/devtest.sh --trash-my-machine
# wait around 2+ hours
# mawagner: if openvswitch fails to start, see https://bugzilla.redhat.com/show_bug.cgi?id=1006412 (or just mkdir /var/lock/subsys)

Create more baremetals, you can use their MAC addresses to register them from the UI later, so save the MACS somewhere
source $TRIPLEO_ROOT/tripleorc
source tripleo-incubator/scripts/devtest_variables.sh
source ./tripleo-undercloud-passwords
source ./tripleo-incubator/undercloudrc
source ~/.devtestrc
export SSH_USER=$(whoami)
export HOSTIP=${HOSTIP:-192.168.122.1}

export MORE_MACS=$(create-nodes $NODE_CPU $NODE_MEM $NODE_DISK $NODE_ARCH 4 $SSH_USER $HOSTIP $TE_DATAFILE | tr '\r\n' ' ')

To be able to deploy block-storage role, you will need image for it in glance, here is pre-built image
curl -L -O "https://s3-eu-west-1.amazonaws.com/somerandomname/overcloud-cinder-volume.qcow2"
load-image overcloud-cinder-volume.qcow2

Or build the block storage image
$TRIPLEO_ROOT/diskimage-builder/bin/disk-image-create $NODE_DIST \
-a $NODE_ARCH -o $TRIPLEO_ROOT/overcloud-cinder-volume hosts \
baremetal cinder-volume neutron-openvswitch-agent os-collect-config heat-cfntools pip-cache \
dhcp-all-interfaces $DIB_COMMON_ELEMENTS $OVERCLOUD_COMPUTE_DIB_EXTRA_ARGS 2>&1 | \
tee $TRIPLEO_ROOT/dib-overcloud-cinder-volume.log

load-image overcloud-cinder-volume.qcow2

To be able to deploy object storage node, you need this
$TRIPLEO_ROOT/diskimage-builder/bin/disk-image-create $NODE_DIST \
-a $NODE_ARCH -o $TRIPLEO_ROOT/overcloud-swift-storage hosts \
baremetal swift-storage neutron-openvswitch-agent os-collect-config \
dhcp-all-interfaces $DIB_COMMON_ELEMENTS $OVERCLOUD_COMPUTE_DIB_EXTRA_ARGS 2>&1 | \
tee $TRIPLEO_ROOT/dib-overcloud-swift-storage.log

load-image overcloud-swift-storage.qcow2

To list MAC's for virsh listed machines run
virsh list --all
virsh dumpxml baremetal_0 | grep 'mac address' | cut -d\' -f2

At this point, your devtest environment is configured. To proceed, you need to install Tuskar, Horizon and Tuskar-UI, since they are not installed by devtest.

=== Install Tuskar ===

mkdir -p /opt/stack && cd /opt/stack
git clone https://git.openstack.org/openstack/tuskar

Follow the instructions here to complete the install: https://github.com/openstack/tuskar/blob/master/doc/source/INSTALL.rst. Make sure that you create the initial data.

To be able to deploy Overcloud via Tuskar, you need to delete the Overcloud created by Devtest first.
Go to the Undercloud machine and delete the Overcloud:
ssh heat-admin@192.0.2.3
sudo -i
source stackrc
heat stack-delete overcloud

=== Add Horizon and Tuskar-UI ===
Install and configure Horizon and Tuskar-UI using the instructions at: http://tuskar-ui.readthedocs.org/en/latest/install.html. Make sure to clone the horizon and tuskar-ui repositories in /opt/stack.

.Afterwards, copy /root/stackrc from the undercloud to the lab machine, change the OS_AUTH_URL to point to the undercloud, and source it:
ssh heat-admin@192.0.2.3 "sudo -i cat /root/stackrc" > /root/stackrc
sed -i 's/localhost:5000/192.0.2.3:5000/' /root/stackrc
source /root/stackrc

Configure OPENSTACK_HOST in horizon settings to point to the undercloud machine:
sed -i 's/OPENSTACK_HOST = "127.0.0.1"/OPENSTACK_HOST = "192.0.2.3"/' /opt/stack/horizon/openstack_dashboard/local/local_settings.py

Start the server:
tools/with_venv.sh ./manage.py runserver 0.0.0.0:8111

Now you can see the UI from your browser (you can find credentials for dashboard in undercloud machine in /root/stackrc):
lab-machine:8111

If you want to develop locally, you need only to mount the remote folder containing the code, in your local file system:
yum install -y sshfs && mkdir -p ~/devtest
sshfs root@lab-machine:/opt/stack/ ~/devtest

=== Script for installing Tuskar and Tuskar UI ===
There is a script to automatically do previous two steps: https://gist.github.com/Divius/9525147. It clones to the current directory, uses sudo to do privileged operations, so it can be used by non-root. The only requirement is that stackrc file is in the current directory. Also note that the script is mostly unsupported and can become outdated.

Tuskar/UsageGuide

2014-04-29T14:47:29Z

Tzumainn: /* Create Flavors */

== Overview ==

This guide details the usage of the Tuskar UI. It assumes that you have already installed Tuskar and the Tuskar UI. If you have not, please follow one of the [[TripleO/Tuskar#Getting_Started|Installation Guides]] first.

A [https://www.youtube.com/watch?v=-6whFIqCqLU narrated video] is also available.

== Register Nodes ==

Start by logging into the Tuskar UI. The Tuskar UI is designed as a plugin to Horizon. The recommended installation will eliminate the standard 'Project' and 'Admin' dashboard, leaving only the Tuskar UI's 'Infrastructure' dashboard.

First you'll need to register some nodes. Click on the Nodes tab, then on the "Register Nodes" button in the upper-right corner.

You'll see a form that asks you to input your nodes' details. At a minimum you must specify the NIC mac address, the number of CPUs, the memory, and the local disk. You can enter information for multiple nodes by clicking on the "Add Node" link. Once done, click "Register Nodes".

If the nodes are registered successfully, you'll be back at the Nodes index page; only now there will be a count of Free Nodes.

== Create Flavors ==

The next step is to create flavors. Flavors are used so that your OpenStack Deployment knows which Nodes are appropriate for use.

Click on the Flavors tab. If no flavors exist, click on Flavor Suggestions. Here, you'll see suggested flavor specifications that match the nodes created in the previous step. To create them, simply click on the 'Create' button, and you'll be taken to a pre-filled flavor creation form. If you are satisfied with the form values, click on 'Create Flavor'. Make sure the "Deploy Kernel Image" and "Deploy Ramdisk Image" are set to the bm-deploy-kernel and bm-deploy-ramdisk images.

Now if you select the 'Flavor' tab, you'll see that your flavor has been created.

== Associate Flavors with Roles ==

Now that your nodes and flavors have been created, we can get started on creating the actual OpenStack Deployment. Click on that tab.

You'll see a deployment creation workflow, beginning with a list of pre-defined roles. However before specifying the node count for each role, you must specify the flavor that each role will use to match appropriate nodes. To do this for each role, click on 'Add a flavor'.

An 'Edit Deployment Role' form will pop up. As these are default roles, the only value that can be modified is Flavor. Select your desired flavor and click on 'Apply Changes'.

== Specifiy Deployment Parameters and Options ==

Now it's time to specify the parameters and options for your Deployment. First, select the number of nodes you wish deployed in each role. Note that the Controller role must be exactly 1.

Afterwards, click on the Configuration tab. Here you can specify various configuration options for your deployment. You can also choose not to modify any of these values; Tuskar will use appropriate defaults.

== Deployment ==

Once you are satisfied with your deployment choices, click on the 'Deploy' button. If everything goes as expected, you'll see a deployment progress bar, and here your watch begins.

As nodes are provisioned with the appropriate image for a role, this page will refresh with updated information. You can also click on the 'Log' tab to see a log of events that Heat is undertaking while creating the deployment stack.

== Post-Deployment ==

For the installation via Devtest, the initialization code can be found in Overcloud deployment
docs: http://docs.openstack.org/developer/tripleo-incubator/devtest_overcloud.html starting with step 13

For the installation via Instack, you can find the code for Overcloud Deployment here:
https://github.com/agroup/instack-undercloud/blob/master/scripts/instack-deploy-overcloud-tuskarcli

Tuskar/UsageGuide

2014-04-29T13:38:49Z

Tzumainn: /* Create Flavors */

== Overview ==

This guide details the usage of the Tuskar UI. It assumes that you have already installed Tuskar and the Tuskar UI. If you have not, please follow one of the [[TripleO/Tuskar#Getting_Started|Installation Guides]] first.

A [https://www.youtube.com/watch?v=-6whFIqCqLU narrated video] is also available.

== Register Nodes ==

Start by logging into the Tuskar UI. The Tuskar UI is designed as a plugin to Horizon. The recommended installation will eliminate the standard 'Project' and 'Admin' dashboard, leaving only the Tuskar UI's 'Infrastructure' dashboard.

First you'll need to register some nodes. Click on the Nodes tab, then on the "Register Nodes" button in the upper-right corner.

You'll see a form that asks you to input your nodes' details. At a minimum you must specify the NIC mac address, the number of CPUs, the memory, and the local disk. You can enter information for multiple nodes by clicking on the "Add Node" link. Once done, click "Register Nodes".

If the nodes are registered successfully, you'll be back at the Nodes index page; only now there will be a count of Free Nodes.

== Create Flavors ==

The next step is to create flavors. Flavors are used so that your OpenStack Deployment knows which Nodes are appropriate for use.

Click on the Flavors tab. If no flavors exist, click on Flavor Suggestions. Here, you'll see suggested flavor specifications that match the nodes created in the previous step. To create them, simply click on the 'Create' button, and you'll be taken to a pre-filled flavor creation form. If you are satisfied with the form values, click on 'Create Flavor'. Make sure the "Deploy Kernel Image" and "Deploy Ramdisk Image" are set to kernel and ramdisk images.

Now if you select the 'Flavor' tab, you'll see that your flavor has been created.

== Associate Flavors with Roles ==

Now that your nodes and flavors have been created, we can get started on creating the actual OpenStack Deployment. Click on that tab.

You'll see a deployment creation workflow, beginning with a list of pre-defined roles. However before specifying the node count for each role, you must specify the flavor that each role will use to match appropriate nodes. To do this for each role, click on 'Add a flavor'.

An 'Edit Deployment Role' form will pop up. As these are default roles, the only value that can be modified is Flavor. Select your desired flavor and click on 'Apply Changes'.

== Specifiy Deployment Parameters and Options ==

Now it's time to specify the parameters and options for your Deployment. First, select the number of nodes you wish deployed in each role. Note that the Controller role must be exactly 1.

Afterwards, click on the Configuration tab. Here you can specify various configuration options for your deployment. You can also choose not to modify any of these values; Tuskar will use appropriate defaults.

== Deployment ==

Once you are satisfied with your deployment choices, click on the 'Deploy' button. If everything goes as expected, you'll see a deployment progress bar, and here your watch begins.

As nodes are provisioned with the appropriate image for a role, this page will refresh with updated information. You can also click on the 'Log' tab to see a log of events that Heat is undertaking while creating the deployment stack.

== Post-Deployment ==

For the installation via Devtest, the initialization code can be found in Overcloud deployment
docs: http://docs.openstack.org/developer/tripleo-incubator/devtest_overcloud.html starting with step 13

For the installation via Instack, you can find the code for Overcloud Deployment here:
https://github.com/agroup/instack-undercloud/blob/master/scripts/instack-deploy-overcloud-tuskarcli

Design Summit/Juno/Etherpads

2014-04-29T00:27:01Z

Tzumainn: /* TripleO (Deployment) */

[[Category:Summit]]
[[Category:Juno]]
[[Category:Etherpad]]

<div style="column-count:3;-moz-column-count:3;-webkit-column-count:3">
__TOC__
</div>

== Ceilometer ==
== Cinder ==
==Cross-Project==
== Devstack ==
* Fri 16:00 [https://etherpad.openstack.org/p/juno-summit-devstack-update DevStack Update]
* Fri 16:50 [https://etherpad.openstack.org/p/juno-summit-devstack-project-support DevStack Project Support]

== Documentation ==
== Glance ==
== Heat ==

* Wed 9.00-9:40 [https://etherpad.openstack.org/p/juno-summit-heat-dev-ops Dev/Ops Session]
* Wed 9.50-10:30 [https://etherpad.openstack.org/p/juno-summit-heat-sw-orch Next Steps for Software Orchestration]
* Wed 11.00-11:40 [https://etherpad.openstack.org/p/heat-workflow-vs-convergence Scaling, Robustness and Convergence]
* Wed 11.50-12:30 [https://etherpad.openstack.org/p/juno-summit-heat-notifications Augmenting Polling with Notifications]
* Wed 13.50-14:30 [https://etherpad.openstack.org/p/juno-summit-heat-event Event notifications]
* Wed 14.40-15:20 [https://etherpad.openstack.org/p/juno-summit-heat-callbacks Stack and Resource lifecycle callbacks]
* Wed 15.30-16:10 [https://etherpad.openstack.org/p/juno-summit-heat-api-v2 API v2]
* Wed 16.30-17:10 [https://etherpad.openstack.org/p/juno-summit-heat-plugin-versioning Resource Plugin Versioning]

== Horizon ==
* Wed 4:30 - 5:10 [https://etherpad.openstack.org/p/juno-summit-horizon-devops Horizon Dev/Ops Session]

== Infrastructure ==
== Ironic ==

* Tues 11:15 [https://etherpad.openstack.org/p/juno-summit-ironic-python-agent Ironic Python Agent]
* Tues 12:05 [https://etherpad.openstack.org/p/juno-summit-ironic-multitenancy Hardware Multitenancy Risk Mitigation]
* Tues 14:50 [https://etherpad.openstack.org/p/juno-summit-ironic-performance Performance and Scalability]
* Tues 15:40 [https://etherpad.openstack.org/p/juno-summit-ironic-arch Planning changes for Juno]

== Keystone ==
== Marconi ==
== Neutron ==
* Wed 9:00-9:40: [https://etherpad.openstack.org/p/juno-neutron-policies New Policies for Neutron in Juno]
* Wed 9:50-10:30: Code Review Process Improvements
* Wed 11:00-11:40: IPv6 status in Neutron
* Wed 11:50-12:30: ML2 Juno Roadmap
**[https://etherpad.openstack.org/p/ML2_mechanismdriver_extensions_support Extensions Support In ML2 Mechanism Drivers]
* Wed 13:50-14:30: Refactoring the Neutron Server Core
* Wed 14:40-15:20: [https://etherpad.openstack.org/p/novanet-neutron-migration Nova-Net to Neutron migration]
* Wed 15:30-14:10: Integrating Tasks into Neutron
* Wed 16:30-17:10: Neutron Advanced Services and Flavor Framework
* Wed 17:20-18:00: Neutron Distributed Virtual Router Progress Update
* Thu 9:00-9:40: Neutron QA and Testing
** https://etherpad.openstack.org/p/TempestAndNeutronJuno
* Thu 9:50-10:30: Sharing the load of operational responsibility
* Thu 11:00-11:40: Neutron LBaaS Update
* Thur 11:50-12:30: Modular Layer2 Agents
** https://etherpad.openstack.org/p/JunoSummit-ovs-firewall-driver
* Fri 10:50-11:30: Neutron Group Based Policy
* Fri 11:40-12:30: Combined FWaaS and VPNaaS Session
* Fri 13:20-14:00: LBaaS SSL L7 and automated scenarios
* Fri 14:10-14:50: Hierarchical Network Topologies
** https://etherpad.openstack.org/p/hierarchical_network_topology
* Fri 15:00-15:40: [https://etherpad.openstack.org/p/L3-vendor-plugins L3 Vendor Plugins]
* Fri 16:00-16:40: Dynamic routing and pluggable external networks
* Fri 16:50-17:30: Service VM Discussion:
** https://etherpad.openstack.org/p/servicevm

== Nova ==
== Ops ==
* Mon 1115 – 1155 [https://etherpad.openstack.org/p/juno-summit-ops-askthedevs Ask the devs: Meet the PTLs and TC, How to get the best out of the design summit]
* Mon 1205 – 1245 [https://etherpad.openstack.org/p/juno-summit-ops-reasonabledefaults Reasonable Defaults]
* Mon 1400 – 1440 [https://etherpad.openstack.org/p/juno-summit-ops-upgradesdeployment Upgrades and Deployment Approaches]
* Mon 1450 – 1620 [https://etherpad.openstack.org/p/juno-summit-ops-architecture Architecture Show and Tell, Tales and Fails]
* Mon 1730 – 1810 [https://etherpad.openstack.org/p/juno-summit-ops-security Security]

* Fri 9:00 – 9:40 [https://etherpad.openstack.org/p/juno-summit-ops-enterprise Enterprise Gaps]
* Fri 9:50 – 10:30 [https://etherpad.openstack.org/p/juno-summit-ops-database Database]
* Fri 10:50 – 11:30 [https://etherpad.openstack.org/p/juno-summit-ops-issuesatscale Issues at Scale]
* Fri 11:40 – 12:20 [https://etherpad.openstack.org/p/juno-summit-ops-meta Meta Discussion – ops communication and governance]
* Fri 1:20 – 2:00 [https://etherpad.openstack.org/p/juno-summit-ops-ansible Ansible]
* Fri 2:10 – 2:50 [https://etherpad.openstack.org/p/juno-summit-ops-chef Chef]
* Fri 3:00 – 3:40 [https://etherpad.openstack.org/p/juno-summit-ops-puppet Puppet]
* Fri 4:00 – 4:40 [https://etherpad.openstack.org/p/juno-summit-ops-networking Networking]
* Fri 4:50 – 5:30 [https://etherpad.openstack.org/p/juno-summit-ops-monitoringlogging Monitoring and Logging]

== Oslo ==
* Wed 9:00 - 9:40 Release Plan for Low-level Libraries
* Wed 9:50 - 10:30 Semantic versioning and oslo
* Wed 11:00 - 11:40 oslo.rootwrap: performance and other improvements
* Thu 9:00 - 9:40 Oslo Library Teams Breakout Session
* Thu 9:50 - 10:30 Testing pre-releases of Oslo libs with apps
* Thu 11:00 - 11:40 OpenStack cross service/project OpenStack profiler
* Thu 15:10 - 16:00 Upstream chat with Mike Bayer
* Thu 16:10 - 17:00 rpc proxy(oslo.messaging): https://etherpad.openstack.org/p/juno-summit-oslo-messaging-rpc-proxy
* Fri 14:10 - 15:50 oslo.messaging status and plans for Juno
* Fri 15:00 - 16:40 AMQP 1.0 protocol driver
* Fri 16:00 - 16:40 PKI for messaging

== QA ==

===Thursday===
* 1:30 – 2:10 [https://etherpad.openstack.org/p/juno-summit-api-tests-with-jsonschema API tests with JSONSchema]

== Release Management ==
== Sahara (ex. Savanna) ==

* [http://junodesignsummit.sched.org/event/b4f52627efa42f285978d5af3643e189 Thu 13:30] [https://etherpad.openstack.org/p/juno-summit-sahara-relmngmt-backward Releasing and backward compatibility]
* [http://junodesignsummit.sched.org/event/c8774beefd9e9188a3e0729d2bd7131e Thu 14:20] [https://etherpad.openstack.org/p/juno-summit-sahara-testing-plugins CI/gating and plugin requirements]
* [http://junodesignsummit.sched.org/event/10bc9a23eb43eb9df885586035fb2491 Thu 15:10] [https://etherpad.openstack.org/p/juno-summit-sahara-scale-integration Scalable Sahara and further OpenStack integration]
* [http://junodesignsummit.sched.org/event/be842178a085fe95b7665a653f8ab541 Thu 16:10] [https://etherpad.openstack.org/p/juno-summit-sahara-ux UX improvements]
* [http://junodesignsummit.sched.org/event/dfa603324c0bbf29c2f09a77efb82d1d Thu 17:00] [https://etherpad.openstack.org/p/juno-summit-sahara-edp Future of EDP: plugins, SPI, Oozie]
* [http://junodesignsummit.sched.org/event/a64f771cf28ed3ad637730db828668ff Fri 09:00] [https://etherpad.openstack.org/p/juno-summit-sahara-v2-api Next major REST API - v2]
* [http://junodesignsummit.sched.org/event/49089a1d9c8203c6a4c1f0001fa417af Fri 09:50] [https://etherpad.openstack.org/p/juno-summit-sahara-roadmap-retro Sahara in Icehouse and Juno]

== Swift ==
== TripleO (Deployment) ==
* Fri 11:40 - 12:20 [https://etherpad.openstack.org/p/juno-summit-tripleo-tuskar-planning TripleO Tuskar Planning]
* Fri
* Fri 14:10 - 14:50 [https://etherpad.openstack.org/p/juno-summit-tripleo-and-docker TripleO and Docker]
* Fri 15:00 - 15:40 [https://etherpad.openstack.org/p/juno-summit-tripleo-ci TripleO CI]
* Fri 16:00 - 16:40 [https://etherpad.openstack.org/p/juno-summit-tripleo-neutron TripleO and Neutron]
* Fri 16:50 - 17:30 [https://etherpad.openstack.org/p/juno-summit-tripleo-devops TripleO Dev/Ops Session]

== Trove ==
== User Committee ==

Tuskar/UsageGuide

2014-04-16T03:23:15Z

Tzumainn: /* Deployment */

== Overview ==

This guide details the usage of the Tuskar UI. It assumes that you have already installed Tuskar and the Tuskar UI. If you have not, please follow one of the [[TripleO/Tuskar#Getting_Started|Installation Guides]] first.

A [https://www.youtube.com/watch?v=-6whFIqCqLU narrated video] is also available.

== Register Nodes ==

Start by logging into the Tuskar UI. The Tuskar UI is designed as a plugin to Horizon. The recommended installation will eliminate the standard 'Project' and 'Admin' dashboard, leaving only the Tuskar UI's 'Infrastructure' dashboard.

First you'll need to register some nodes. Click on the Nodes tab, then on the "Register Nodes" button in the upper-right corner.

You'll see a form that asks you to input your nodes' details. At a minimum you must specify the NIC mac address, the number of CPUs, the memory, and the local disk. You can enter information for multiple nodes by clicking on the "Add Node" link. Once done, click "Register Nodes".

If the nodes are registered successfully, you'll be back at the Nodes index page; only now there will be a count of Free Nodes.

== Create Flavors ==

The next step is to create flavors. Flavors are used so that your OpenStack Deployment knows which Nodes are appropriate for use.

Click on the Flavors tab. If no flavors exist, click on Flavor Suggestions. Here, you'll see suggested flavor specifications that match the nodes created in the previous step. To create them, simply click on the 'Create' button, and you'll be taken to a pre-filled flavor creation form. If you are satisfied with the form values, click on 'Create Flavor'.

Now if you select the 'Flavor' tab, you'll see that your flavor has been created.

== Associate Flavors with Roles ==

Now that your nodes and flavors have been created, we can get started on creating the actual OpenStack Deployment. Click on that tab.

You'll see a deployment creation workflow, beginning with a list of pre-defined roles. However before specifying the node count for each role, you must specify the flavor that each role will use to match appropriate nodes. To do this for each role, click on 'Add a flavor'.

An 'Edit Deployment Role' form will pop up. As these are default roles, the only value that can be modified is Flavor. Select your desired flavor and click on 'Apply Changes'.

== Specifiy Deployment Parameters and Options ==

Now it's time to specify the parameters and options for your Deployment. First, select the number of nodes you wish deployed in each role. Note that the Controller role must be exactly 1.

Afterwards, click on the Configuration tab. Here you can specify various configuration options for your deployment. You can also choose not to modify any of these values; Tuskar will use appropriate defaults.

== Deployment ==

Once you are satisfied with your deployment choices, click on the 'Deploy' button. If everything goes as expected, you'll see a deployment progress bar, and here your watch begins.

As nodes are provisioned with the appropriate image for a role, this page will refresh with updated information. You can also click on the 'Log' tab to see a log of events that Heat is undertaking while creating the deployment stack.

== Post-Deployment ==

Tuskar/UsageGuide

2014-04-16T03:18:52Z

Tzumainn: /* Specifiy Deployment Options */

Tuskar/UsageGuide

2014-04-16T03:11:49Z

Tzumainn: /* Associate Flavors with Roles */

Tuskar/UsageGuide

2014-04-16T03:08:42Z

Tzumainn: /* Create Flavors */

Tuskar/UsageGuide

2014-04-16T03:08:16Z

Tzumainn: /* Create Flavors */

Tuskar/UsageGuide

2014-04-16T03:01:34Z

Tzumainn: /* Register Nodes */

Tuskar/UsageGuide

2014-04-16T02:50:29Z

Tzumainn: /* Overview */

Tuskar/UsageGuide

2014-04-16T02:46:03Z

Tzumainn: /* Overview */

== Overview ==

This guide details the usage of the Tuskar UI. It assumes that you have already installed Tuskar and the Tuskar UI. If you have not, please follow one of the [[TripleO/Tuskar#Getting_Started|Installation Guides]] first.

== Register Nodes ==

== Create Flavors ==

== Associate Flavors with Roles ==

== Specifiy Deployment Options ==

== Deployment ==

== Post-Deployment ==

Tuskar/UsageGuide

2014-04-15T21:01:22Z

Tzumainn: /* Create Flavors */

== Overview ==

== Register Nodes ==

== Create Flavors ==

== Associate Flavors with Roles ==

== Specifiy Deployment Options ==

== Deployment ==

== Post-Deployment ==

Tuskar/UsageGuide

2014-04-15T21:00:52Z

Tzumainn: Tuskar-UI Usage Guide

== Overview ==

== Register Nodes ==

== Create Flavors ==

== Associate Flavors with Roles

== Specifiy Deployment Options ==

== Deployment ==

== Post-Deployment ==

TripleO/Tuskar

2014-04-15T14:08:07Z

Tzumainn: /* Getting Started */

== Overview ==

Tuskar gives administrators the ability to control how and where OpenStack services are deployed across the datacenter. Using Tuskar,
administrators divide hardware into "resource classes" that allow predictable elastic scaling as cloud demands grow. This resource
orchestration allows Tuskar users to ensure SLAs, improve performance, and maximize utilization across the datacenter.

Tuskar services are available via a RESTful API and management console through which administrators are able to classify their hardware and
define their datacenters. In addition, Tuskar components provide administrators with performance monitoring, health statistics, and usage metrics, aiding in capacity planning and hardware procurement decisions.

For more information, take a look at the [[TripleO/TuskarGlossary|Tuskar Glossary]].

If you're interested in seeing Tuskar in action, [https://www.youtube.com/watch?v=VEY035-Lyzo watch a demo].

=== Sub-Projects ===

Tuskar also consists of two sub-projects:

* '''tuskar-ui''' - Built on top of [[Horizon|Horizon]], tuskar-ui provides dashboard access to Tuskar functionality.
* '''python-tuskarclient''' - A Python client for the Tuskar API, python-tuskarclient is utilized by tuskar-ui.

== Icehouse ==

We are currently finishing up development for the Icehouse timeframe. For future planning, see the '''Juno''' section.

* [[TripleO/TuskarIcehouseRequirements|Requirements]] ([http://lists.openstack.org/pipermail/openstack-dev/2013-December/021388.html discussion])
** [[TripleO/Tuskar/IcehouseUserStories|User Stories]] ([http://lists.openstack.org/pipermail/openstack-dev/2013-December/021483.html discussion])
** [https://docs.google.com/document/d/16rkiXWxxgzGT47_Wc6hzIPzO2-s2JWAPEKD0gP2mt7E/edit?pli=1# OpenStack Personas]
* Wireframes ([http://lists.openstack.org/pipermail/openstack-dev/2013-December/020944.html discussion])
** [http://ask-openstackux.rhcloud.com/question/95/tripleo-ui-resource-management/ Resource Management]
** [http://ask-openstackux.rhcloud.com/question/96/tripleo-ui-deployment-management/ Deployment Management]
* Architecture (coming soon)
* Blueprints (coming soon)

== Juno ==

* [[TripleO/TuskarJunoInitialDiscussion|Initial Discussion]]
* [[TripleO/TuskarJunoPlanning|Planning]]

== Resources ==

{| border="1" cellpadding="2" cellspacing="0"
|
| tuskar
| tuskar-ui
| python-tuskarclient
|-
| Source Code
| https://github.com/openstack/tuskar/
| https://github.com/openstack/tuskar-ui/
| https://github.com/openstack/python-tuskarclient
|-
| Blueprints
| https://blueprints.launchpad.net/tuskar
| https://blueprints.launchpad.net/tuskar-ui
| https://blueprints.launchpad.net/python-tuskarclient
|-
| Bugs
| https://bugs.launchpad.net/tuskar
| https://bugs.launchpad.net/tuskar-ui
| https://bugs.launchpad.net/python-tuskarclient
|-
| Code Reviews
| https://review.openstack.org/#/q/status:open+project:openstack/tuskar,n,z
| https://review.openstack.org/#/q/status:open+project:openstack/tuskar-ui,n,z
| https://review.openstack.org/#/q/status:open+project:openstack/python-tuskarclient,n,z
|}

== Getting Started ==

To install both Tuskar and Tuskar UI alongside Devtest, follow the [[Tuskar/Devtest|Devtest installation instructions]]

To install Tuskar by itself, follow these guides:

* [https://github.com/openstack/tuskar/blob/master/doc/source/INSTALL.rst Installation Guide]
* [https://github.com/openstack/tuskar/blob/master/doc/source/CONTRIBUTING.rst Contribution Guide]

To install Tuskar UI by itself, follow the [https://github.com/openstack/tuskar-ui/blob/master/docs/install.rst Tuskar UI Installation Guide]

Once Tuskar and Tuskar UI are set up, follow this [[Tuskar/UsageGuide|Usage Guide]].

== Contact Us ==

Join us on IRC:

Network: Freenode (irc.freenode.net/tuskar)
Channel: #tuskar

TripleO/Tuskar

2014-04-15T14:03:39Z

Tzumainn:

== Overview ==

Tuskar gives administrators the ability to control how and where OpenStack services are deployed across the datacenter. Using Tuskar,
administrators divide hardware into "resource classes" that allow predictable elastic scaling as cloud demands grow. This resource
orchestration allows Tuskar users to ensure SLAs, improve performance, and maximize utilization across the datacenter.

Tuskar services are available via a RESTful API and management console through which administrators are able to classify their hardware and
define their datacenters. In addition, Tuskar components provide administrators with performance monitoring, health statistics, and usage metrics, aiding in capacity planning and hardware procurement decisions.

For more information, take a look at the [[TripleO/TuskarGlossary|Tuskar Glossary]].

If you're interested in seeing Tuskar in action, [https://www.youtube.com/watch?v=VEY035-Lyzo watch a demo].

=== Sub-Projects ===

Tuskar also consists of two sub-projects:

* '''tuskar-ui''' - Built on top of [[Horizon|Horizon]], tuskar-ui provides dashboard access to Tuskar functionality.
* '''python-tuskarclient''' - A Python client for the Tuskar API, python-tuskarclient is utilized by tuskar-ui.

== Icehouse ==

We are currently finishing up development for the Icehouse timeframe. For future planning, see the '''Juno''' section.

* [[TripleO/TuskarIcehouseRequirements|Requirements]] ([http://lists.openstack.org/pipermail/openstack-dev/2013-December/021388.html discussion])
** [[TripleO/Tuskar/IcehouseUserStories|User Stories]] ([http://lists.openstack.org/pipermail/openstack-dev/2013-December/021483.html discussion])
** [https://docs.google.com/document/d/16rkiXWxxgzGT47_Wc6hzIPzO2-s2JWAPEKD0gP2mt7E/edit?pli=1# OpenStack Personas]
* Wireframes ([http://lists.openstack.org/pipermail/openstack-dev/2013-December/020944.html discussion])
** [http://ask-openstackux.rhcloud.com/question/95/tripleo-ui-resource-management/ Resource Management]
** [http://ask-openstackux.rhcloud.com/question/96/tripleo-ui-deployment-management/ Deployment Management]
* Architecture (coming soon)
* Blueprints (coming soon)

== Juno ==

* [[TripleO/TuskarJunoInitialDiscussion|Initial Discussion]]
* [[TripleO/TuskarJunoPlanning|Planning]]

== Resources ==

{| border="1" cellpadding="2" cellspacing="0"
|
| tuskar
| tuskar-ui
| python-tuskarclient
|-
| Source Code
| https://github.com/openstack/tuskar/
| https://github.com/openstack/tuskar-ui/
| https://github.com/openstack/python-tuskarclient
|-
| Blueprints
| https://blueprints.launchpad.net/tuskar
| https://blueprints.launchpad.net/tuskar-ui
| https://blueprints.launchpad.net/python-tuskarclient
|-
| Bugs
| https://bugs.launchpad.net/tuskar
| https://bugs.launchpad.net/tuskar-ui
| https://bugs.launchpad.net/python-tuskarclient
|-
| Code Reviews
| https://review.openstack.org/#/q/status:open+project:openstack/tuskar,n,z
| https://review.openstack.org/#/q/status:open+project:openstack/tuskar-ui,n,z
| https://review.openstack.org/#/q/status:open+project:openstack/python-tuskarclient,n,z
|}

== Getting Started ==

To install both Tuskar and Tuskar UI alongside Devtest, follow this guide:

* [[Tuskar/Devtest|Devtest installation instructions]]

To install Tuskar by itself, follow these guides:

* [https://github.com/openstack/tuskar/blob/master/doc/source/INSTALL.rst Installation Guide]
* [https://github.com/openstack/tuskar/blob/master/doc/source/CONTRIBUTING.rst Contribution Guide]

To install Tuskar UI by itself, follow this guide:

* [https://github.com/openstack/tuskar-ui/blob/master/docs/install.rst Installation Guide]

== Contact Us ==

Join us on IRC:

Network: Freenode (irc.freenode.net/tuskar)
Channel: #tuskar

TripleO/Tuskar

2014-04-07T08:44:28Z

Tzumainn: /* Getting Started */

== Overview ==

Tuskar gives administrators the ability to control how and where OpenStack services are deployed across the datacenter. Using Tuskar,
administrators divide hardware into "resource classes" that allow predictable elastic scaling as cloud demands grow. This resource
orchestration allows Tuskar users to ensure SLAs, improve performance, and maximize utilization across the datacenter.

Tuskar services are available via a RESTful API and management console through which administrators are able to classify their hardware and
define their datacenters. In addition, Tuskar components provide administrators with performance monitoring, health statistics, and usage metrics, aiding in capacity planning and hardware procurement decisions.

For more information, take a look at the [[TripleO/TuskarGlossary|Tuskar Glossary]].

If you're interested in seeing Tuskar in action, [https://www.youtube.com/watch?v=VEY035-Lyzo watch a demo].

=== Sub-Projects ===

Tuskar also consists of two sub-projects:

* '''tuskar-ui''' - Built on top of [[Horizon|Horizon]], tuskar-ui provides dashboard access to Tuskar functionality.
* '''python-tuskarclient''' - A Python client for the Tuskar API, python-tuskarclient is utilized by tuskar-ui.

== Icehouse ==

We are currently finishing up development for the Icehouse timeframe. For future planning, see the '''Juno''' section.

* [[TripleO/TuskarIcehouseRequirements|Requirements]] ([http://lists.openstack.org/pipermail/openstack-dev/2013-December/021388.html discussion])
** [[TripleO/Tuskar/IcehouseUserStories|User Stories]] ([http://lists.openstack.org/pipermail/openstack-dev/2013-December/021483.html discussion])
** [https://docs.google.com/document/d/16rkiXWxxgzGT47_Wc6hzIPzO2-s2JWAPEKD0gP2mt7E/edit?pli=1# OpenStack Personas]
* Wireframes ([http://lists.openstack.org/pipermail/openstack-dev/2013-December/020944.html discussion])
** [http://ask-openstackux.rhcloud.com/question/95/tripleo-ui-resource-management/ Resource Management]
** [http://ask-openstackux.rhcloud.com/question/96/tripleo-ui-deployment-management/ Deployment Management]
* Architecture (coming soon)
* Blueprints (coming soon)

== Juno ==

* [[TripleO/TuskarJunoInitialDiscussion|Initial Discussion]]
* [[TripleO/TuskarJunoPlanning|Planning]]

== Resources ==

{| border="1" cellpadding="2" cellspacing="0"
|
| tuskar
| tuskar-ui
| python-tuskarclient
|-
| Source Code
| https://github.com/openstack/tuskar/
| https://github.com/openstack/tuskar-ui/
| https://github.com/openstack/python-tuskarclient
|-
| Blueprints
| https://blueprints.launchpad.net/tuskar
| https://blueprints.launchpad.net/tuskar-ui
| https://blueprints.launchpad.net/python-tuskarclient
|-
| Bugs
| https://bugs.launchpad.net/tuskar
| https://bugs.launchpad.net/tuskar-ui
| https://bugs.launchpad.net/python-tuskarclient
|-
| Code Reviews
| https://review.openstack.org/#/q/status:open+project:openstack/tuskar,n,z
| https://review.openstack.org/#/q/status:open+project:openstack/tuskar-ui,n,z
| https://review.openstack.org/#/q/status:open+project:openstack/python-tuskarclient,n,z
|}

== Getting Started ==

To install both Tuskar and Tuskar UI alongside Devtest, follow this guide:

* [[Tuskar/Devtest|Devtest installation instructions]]

To install Tuskar by itself, follow these guides:

* [https://github.com/openstack/tuskar/blob/master/doc/source/INSTALL.rst Installation Guide]
* [https://github.com/openstack/tuskar/blob/master/doc/source/CONTRIBUTING.rst Contribution Guide]

To install Tuskar UI by itself, follow this guide:

* [https://github.com/openstack/tuskar-ui/blob/master/docs/install.rst Installation Guide]

== Additional Documentation ==

'''API'''

* [https://github.com/openstack/tuskar/blob/master/docs/api/api.md API Information]
* [https://github.com/openstack/tuskar/blob/master/docs/api/curl.rst cURL Commands]
* [https://github.com/openstack/tuskar/blob/master/docs/resource-class-demo-script.rst Resource Class Demo Script] (uses cURL)

'''Other'''

* [https://github.com/openstack/tuskar/blob/master/docs/debugging-with-ipython.rst Debugging with iPython]
* [https://github.com/openstack/tuskar/blob/master/docs/demo-data-script.rst Demo Data Script]

== Contact Us ==

Join us on IRC:

Network: Freenode (irc.freenode.net/tuskar)
Channel: #tuskar

Tuskar/Devtest

2014-04-07T08:43:04Z

Tzumainn: /* Add Horizon and Tuskar-UI */

== Overview ==
Devtest is a script that creates a development environment for TripleO / Tuskar / TuskarUI development. Below you can find step-by-step instructions for setting up the environment using devtest. If you would like more information about how devtest works as well as the script itself, see the following links
* http://docs.openstack.org/developer/tripleo-incubator/index.html
* https://github.com/openstack/tripleo-incubator/blob/master/scripts/devtest.sh
However, following the steps below should lead to a complete functioning setup.

== Instructions ==

=== Setup devtest ===
All commands (unless otherwise specified) should be run as root, in a dedicated machine you will use for TripleO development. We will call this machine "the lab machine" or "the lab server". The setup has been tested with lab machines running Fedora 19.

Note: You might want to move the location of the default libvirt storage pool. The default location is /var/lib/libvirt/images. Depending on your file system / partitions setup, there might not be enough space for images at this default location. To be on the safe side, you can move it to another location which has plenty of space. Below is an example how to move the default storage pool location to /home/images. If you are sure that there is enough space at the default location, you can skip this step.

mkdir /home/images
yum install -y libvirt
service libvirtd start
virsh pool-destroy default
virsh pool-undefine default
virsh pool-define-as default dir --target /home/images
virsh pool-start default
virsh pool-autostart default
service libvirtd restart

Install git and kvm. Installing kvm at this point sets the ownership of the /dev/kvm correctly (it should be owned by the root user and kvm group). If you don't do this, devtest will fail due to incorrectly set ownership of /dev/kvm.
yum -y install git kvm

Check access rights on /dev/kvm afterwards. If group is not kvm or group doesn't have rw on this file, execute the following commands and reboot:
chgrp kvm /dev/kvm
chmod g+rw /dev/kvm

Create devtest configuration file:
cat <<'EOF' > ~/.devtestrc
export NODE_CPU=1 NODE_MEM=4096 NODE_DISK=60 NODE_ARCH=amd64
export NODE_DIST="fedora selinux-permissive"
export DIB_RELEASE=20
export UNDERCLOUD_DIB_EXTRA_ARGS=""
export OVERCLOUD_DIB_EXTRA_ARGS=""
export OVERCLOUD_COMPUTESCALE=1
export TRIPLEO_CLEANUP=1
EOF

Clone the tripleo-incubator repo and run the devtest script:
export TRIPLEO_ROOT=~/tripleo
mkdir -p $TRIPLEO_ROOT
cd $TRIPLEO_ROOT
git clone https://git.openstack.org/openstack/tripleo-incubator
$TRIPLEO_ROOT/tripleo-incubator/scripts/devtest.sh --trash-my-machine
# wait around 2+ hours
# mawagner: if openvswitch fails to start, see https://bugzilla.redhat.com/show_bug.cgi?id=1006412 (or just mkdir /var/lock/subsys)

Create more baremetals, you can use their MAC addresses to register them from the UI later, so save the MACS somewhere
source $TRIPLEO_ROOT/tripleorc
source tripleo-incubator/scripts/devtest_variables.sh
source ./tripleo-undercloud-passwords
source ./tripleo-incubator/undercloudrc
source ~/.devtestrc
export SSH_USER=$(whoami)
export HOSTIP=${HOSTIP:-192.168.122.1}

export MORE_MACS=$(create-nodes $NODE_CPU $NODE_MEM $NODE_DISK $NODE_ARCH 4 $SSH_USER $HOSTIP $TE_DATAFILE | tr '\r\n' ' ')

To be able to deploy block-storage role, you will need image for it in glance, here is pre-built image
curl -L -O "https://s3-eu-west-1.amazonaws.com/somerandomname/overcloud-cinder-volume.qcow2"
load-image overcloud-cinder-volume.qcow2

To be able to deploy object storage node, you need this
$TRIPLEO_ROOT/diskimage-builder/bin/disk-image-create $NODE_DIST \
-a $NODE_ARCH -o $TRIPLEO_ROOT/overcloud-swift-storage hosts \
baremetal swift-storage neutron-openvswitch-agent os-collect-config \
dhcp-all-interfaces $DIB_COMMON_ELEMENTS $OVERCLOUD_COMPUTE_DIB_EXTRA_ARGS 2>&1 | \
tee $TRIPLEO_ROOT/dib-overcloud-swift-storage.log

load-image overcloud-swift-storage.qcow2

To list MAC's for virsh listed machines run
virsh list --all
virsh dumpxml baremetal_0 | grep 'mac address' | cut -d\' -f2

At this point, your devtest environment is configured. To proceed, you need to install Tuskar, Horizon and Tuskar-UI, since they are not installed by devtest.

=== Install Tuskar ===

mkdir -p /opt/stack && cd /opt/stack
git clone https://git.openstack.org/openstack/tuskar

Follow the instructions here to complete the install: https://github.com/openstack/tuskar/blob/master/doc/source/INSTALL.rst. Make sure that you create the initial data.

=== Add Horizon and Tuskar-UI ===
Install and configure Horizon and Tuskar-UI using the instructions at: https://github.com/openstack/tuskar-ui/blob/master/docs/install.rst. Make sure to clone the horizon and tuskar-ui repositories in /opt/stack.

.Afterwards, copy /root/stackrc from the undercloud to the lab machine, change the OS_AUTH_URL to point to the undercloud, and source it:
ssh heat-admin@192.0.2.3 "sudo -i cat /root/stackrc" > /root/stackrc
sed -i 's/localhost:5000/192.0.2.3:5000/' /root/stackrc
source /root/stackrc

Configure OPENSTACK_HOST in horizon settings to point to the undercloud machine:
sed -i 's/OPENSTACK_HOST = "127.0.0.1"/OPENSTACK_HOST = "192.0.2.3"/' /opt/stack/horizon/openstack_dashboard/local/local_settings.py

Start the server:
tools/with_venv.sh ./manage.py runserver 0.0.0.0:8111

Now you can see the UI from your browser (you can find credentials for dashboard in undercloud machine in /root/stackrc):
lab-machine:8111

If you want to develop locally, you need only to mount the remote folder containing the code, in your local file system:
yum install -y sshfs && mkdir -p ~/devtest
sshfs root@lab-machine:/opt/stack/ ~/devtest

=== Script for installing Tuskar and Tuskar UI ===
There is a script to automatically do previous two steps: https://gist.github.com/Divius/9525147. It clones to the current directory, uses sudo to do privileged operations, so it can be used by non-root. The only requirement is that stackrc file is in the current directory. Also note that the script is mostly unsupported and can become outdated.

Tuskar/Devtest

2014-04-07T08:42:45Z

Tzumainn:

== Overview ==
Devtest is a script that creates a development environment for TripleO / Tuskar / TuskarUI development. Below you can find step-by-step instructions for setting up the environment using devtest. If you would like more information about how devtest works as well as the script itself, see the following links
* http://docs.openstack.org/developer/tripleo-incubator/index.html
* https://github.com/openstack/tripleo-incubator/blob/master/scripts/devtest.sh
However, following the steps below should lead to a complete functioning setup.

== Instructions ==

=== Setup devtest ===
All commands (unless otherwise specified) should be run as root, in a dedicated machine you will use for TripleO development. We will call this machine "the lab machine" or "the lab server". The setup has been tested with lab machines running Fedora 19.

Note: You might want to move the location of the default libvirt storage pool. The default location is /var/lib/libvirt/images. Depending on your file system / partitions setup, there might not be enough space for images at this default location. To be on the safe side, you can move it to another location which has plenty of space. Below is an example how to move the default storage pool location to /home/images. If you are sure that there is enough space at the default location, you can skip this step.

mkdir /home/images
yum install -y libvirt
service libvirtd start
virsh pool-destroy default
virsh pool-undefine default
virsh pool-define-as default dir --target /home/images
virsh pool-start default
virsh pool-autostart default
service libvirtd restart

Install git and kvm. Installing kvm at this point sets the ownership of the /dev/kvm correctly (it should be owned by the root user and kvm group). If you don't do this, devtest will fail due to incorrectly set ownership of /dev/kvm.
yum -y install git kvm

Check access rights on /dev/kvm afterwards. If group is not kvm or group doesn't have rw on this file, execute the following commands and reboot:
chgrp kvm /dev/kvm
chmod g+rw /dev/kvm

Create devtest configuration file:
cat <<'EOF' > ~/.devtestrc
export NODE_CPU=1 NODE_MEM=4096 NODE_DISK=60 NODE_ARCH=amd64
export NODE_DIST="fedora selinux-permissive"
export DIB_RELEASE=20
export UNDERCLOUD_DIB_EXTRA_ARGS=""
export OVERCLOUD_DIB_EXTRA_ARGS=""
export OVERCLOUD_COMPUTESCALE=1
export TRIPLEO_CLEANUP=1
EOF

Clone the tripleo-incubator repo and run the devtest script:
export TRIPLEO_ROOT=~/tripleo
mkdir -p $TRIPLEO_ROOT
cd $TRIPLEO_ROOT
git clone https://git.openstack.org/openstack/tripleo-incubator
$TRIPLEO_ROOT/tripleo-incubator/scripts/devtest.sh --trash-my-machine
# wait around 2+ hours
# mawagner: if openvswitch fails to start, see https://bugzilla.redhat.com/show_bug.cgi?id=1006412 (or just mkdir /var/lock/subsys)

Create more baremetals, you can use their MAC addresses to register them from the UI later, so save the MACS somewhere
source $TRIPLEO_ROOT/tripleorc
source tripleo-incubator/scripts/devtest_variables.sh
source ./tripleo-undercloud-passwords
source ./tripleo-incubator/undercloudrc
source ~/.devtestrc
export SSH_USER=$(whoami)
export HOSTIP=${HOSTIP:-192.168.122.1}

export MORE_MACS=$(create-nodes $NODE_CPU $NODE_MEM $NODE_DISK $NODE_ARCH 4 $SSH_USER $HOSTIP $TE_DATAFILE | tr '\r\n' ' ')

To be able to deploy block-storage role, you will need image for it in glance, here is pre-built image
curl -L -O "https://s3-eu-west-1.amazonaws.com/somerandomname/overcloud-cinder-volume.qcow2"
load-image overcloud-cinder-volume.qcow2

To be able to deploy object storage node, you need this
$TRIPLEO_ROOT/diskimage-builder/bin/disk-image-create $NODE_DIST \
-a $NODE_ARCH -o $TRIPLEO_ROOT/overcloud-swift-storage hosts \
baremetal swift-storage neutron-openvswitch-agent os-collect-config \
dhcp-all-interfaces $DIB_COMMON_ELEMENTS $OVERCLOUD_COMPUTE_DIB_EXTRA_ARGS 2>&1 | \
tee $TRIPLEO_ROOT/dib-overcloud-swift-storage.log

load-image overcloud-swift-storage.qcow2

To list MAC's for virsh listed machines run
virsh list --all
virsh dumpxml baremetal_0 | grep 'mac address' | cut -d\' -f2

At this point, your devtest environment is configured. To proceed, you need to install Tuskar, Horizon and Tuskar-UI, since they are not installed by devtest.

=== Install Tuskar ===

mkdir -p /opt/stack && cd /opt/stack
git clone https://git.openstack.org/openstack/tuskar

Follow the instructions here to complete the install: https://github.com/openstack/tuskar/blob/master/doc/source/INSTALL.rst. Make sure that you create the initial data.

=== Add Horizon and Tuskar-UI ===
Install and configure Horizon and Tuskar-UI using the instructions at: Follow the instructions here to complete the install: https://github.com/openstack/tuskar-ui/blob/master/docs/install.rst. Make sure to clone the horizon and tuskar-ui repositories in /opt/stack.

.Afterwards, copy /root/stackrc from the undercloud to the lab machine, change the OS_AUTH_URL to point to the undercloud, and source it:
ssh heat-admin@192.0.2.3 "sudo -i cat /root/stackrc" > /root/stackrc
sed -i 's/localhost:5000/192.0.2.3:5000/' /root/stackrc
source /root/stackrc

Configure OPENSTACK_HOST in horizon settings to point to the undercloud machine:
sed -i 's/OPENSTACK_HOST = "127.0.0.1"/OPENSTACK_HOST = "192.0.2.3"/' /opt/stack/horizon/openstack_dashboard/local/local_settings.py

Start the server:
tools/with_venv.sh ./manage.py runserver 0.0.0.0:8111

Now you can see the UI from your browser (you can find credentials for dashboard in undercloud machine in /root/stackrc):
lab-machine:8111

If you want to develop locally, you need only to mount the remote folder containing the code, in your local file system:
yum install -y sshfs && mkdir -p ~/devtest
sshfs root@lab-machine:/opt/stack/ ~/devtest

=== Script for installing Tuskar and Tuskar UI ===
There is a script to automatically do previous two steps: https://gist.github.com/Divius/9525147. It clones to the current directory, uses sudo to do privileged operations, so it can be used by non-root. The only requirement is that stackrc file is in the current directory. Also note that the script is mostly unsupported and can become outdated.

TripleO/Tuskar

2014-04-07T08:39:19Z

Tzumainn: /* Getting Started */

== Overview ==

Tuskar gives administrators the ability to control how and where OpenStack services are deployed across the datacenter. Using Tuskar,
administrators divide hardware into "resource classes" that allow predictable elastic scaling as cloud demands grow. This resource
orchestration allows Tuskar users to ensure SLAs, improve performance, and maximize utilization across the datacenter.

Tuskar services are available via a RESTful API and management console through which administrators are able to classify their hardware and
define their datacenters. In addition, Tuskar components provide administrators with performance monitoring, health statistics, and usage metrics, aiding in capacity planning and hardware procurement decisions.

For more information, take a look at the [[TripleO/TuskarGlossary|Tuskar Glossary]].

If you're interested in seeing Tuskar in action, [https://www.youtube.com/watch?v=VEY035-Lyzo watch a demo].

=== Sub-Projects ===

Tuskar also consists of two sub-projects:

* '''tuskar-ui''' - Built on top of [[Horizon|Horizon]], tuskar-ui provides dashboard access to Tuskar functionality.
* '''python-tuskarclient''' - A Python client for the Tuskar API, python-tuskarclient is utilized by tuskar-ui.

== Icehouse ==

We are currently finishing up development for the Icehouse timeframe. For future planning, see the '''Juno''' section.

* [[TripleO/TuskarIcehouseRequirements|Requirements]] ([http://lists.openstack.org/pipermail/openstack-dev/2013-December/021388.html discussion])
** [[TripleO/Tuskar/IcehouseUserStories|User Stories]] ([http://lists.openstack.org/pipermail/openstack-dev/2013-December/021483.html discussion])
** [https://docs.google.com/document/d/16rkiXWxxgzGT47_Wc6hzIPzO2-s2JWAPEKD0gP2mt7E/edit?pli=1# OpenStack Personas]
* Wireframes ([http://lists.openstack.org/pipermail/openstack-dev/2013-December/020944.html discussion])
** [http://ask-openstackux.rhcloud.com/question/95/tripleo-ui-resource-management/ Resource Management]
** [http://ask-openstackux.rhcloud.com/question/96/tripleo-ui-deployment-management/ Deployment Management]
* Architecture (coming soon)
* Blueprints (coming soon)

== Juno ==

* [[TripleO/TuskarJunoInitialDiscussion|Initial Discussion]]
* [[TripleO/TuskarJunoPlanning|Planning]]

== Resources ==

{| border="1" cellpadding="2" cellspacing="0"
|
| tuskar
| tuskar-ui
| python-tuskarclient
|-
| Source Code
| https://github.com/openstack/tuskar/
| https://github.com/openstack/tuskar-ui/
| https://github.com/openstack/python-tuskarclient
|-
| Blueprints
| https://blueprints.launchpad.net/tuskar
| https://blueprints.launchpad.net/tuskar-ui
| https://blueprints.launchpad.net/python-tuskarclient
|-
| Bugs
| https://bugs.launchpad.net/tuskar
| https://bugs.launchpad.net/tuskar-ui
| https://bugs.launchpad.net/python-tuskarclient
|-
| Code Reviews
| https://review.openstack.org/#/q/status:open+project:openstack/tuskar,n,z
| https://review.openstack.org/#/q/status:open+project:openstack/tuskar-ui,n,z
| https://review.openstack.org/#/q/status:open+project:openstack/python-tuskarclient,n,z
|}

== Getting Started ==

To install Tuskar, follow these guides:

* [https://github.com/openstack/tuskar/blob/master/doc/source/INSTALL.rst Installation Guide]
* [https://github.com/openstack/tuskar/blob/master/doc/source/CONTRIBUTING.rst Contribution Guide]

To install Tuskar UI, follow this guide:

* [[Tuskar/Devtest|Devtest installation instructions]]
* [https://github.com/openstack/tuskar-ui/blob/master/docs/install.rst Installation Guide]

== Additional Documentation ==

'''API'''

* [https://github.com/openstack/tuskar/blob/master/docs/api/api.md API Information]
* [https://github.com/openstack/tuskar/blob/master/docs/api/curl.rst cURL Commands]
* [https://github.com/openstack/tuskar/blob/master/docs/resource-class-demo-script.rst Resource Class Demo Script] (uses cURL)

'''Other'''

* [https://github.com/openstack/tuskar/blob/master/docs/debugging-with-ipython.rst Debugging with iPython]
* [https://github.com/openstack/tuskar/blob/master/docs/demo-data-script.rst Demo Data Script]

== Contact Us ==

Join us on IRC:

Network: Freenode (irc.freenode.net/tuskar)
Channel: #tuskar

TripleO/TuskarJunoPlanning

2014-04-04T20:34:13Z

Tzumainn:

== Overview ==

This planning document is born from discussions from the TripleO mid-cycle Icehouse meetup in Sunnyvale ([[TripleO/TuskarJunoInitialDiscussion]], [https://etherpad.openstack.org/p/openstack-management-features OpenStack Management Features]). The ideas iterated there were then individually fleshed out and detailed, with much input coming from conversations with other OpenStack projects.

Our principal concerns duing the Juno cycle are:

* integrating further with other OpenStack services, using their capabilities to enhance our TripleO management experience
* ensuring that Tuskar does not try to implement functionality that is better located in other projects

This document details our high-level goals for Juno. It does so at multiple levels; for each we provide:

* a description of the goal
* a list of project requirements and/or blueprints needed

== Cloud Service Representation ==

A cloud service represents a cloud function - provisioning service, storage service, message broker, database server, etc. A cloud service is fulfilled by a cloud service element; for example, a user can fulfill the message broker cloud service by either choosing the qpid-server element or the rabbitmq-server element.

With the cloud service concept in play, overcloud roles are updated as follows: instead of being associated with images, they are associated with a list of cloud service elements. This provides greater flexibility for the Tuskar user when designing the scalable components of a cloud. For example, instead of being limited to a Controller role, the user can separate out the network components of that role into a Network role and scale it individually.

[[File:Tuskar-service-model.png|Tuskar Service Model]]

For Juno, Tuskar will provide role defaults or suggestions corresponding to current default roles in Icehouse, as well as an "All-in-One" role. Each default role will be automatically associated with a list of cloud service elements and a pre-created image. Later iterations of Tuskar will allow for more user customization in this area.

If possible, we would also like to support customized roles that specify their own elements. This would require the development of additional TripleO features as described in a later section ('''Custom Roles''').

==== Tuskar ====

* ensure existence of default images
* create default roles, each associated with a list of elements, an image, and a Heat template

==== TripleO-UI ====

* update deployment workflow to accomodate cloud services

== Overcloud Planning and Deployment ==

In Icehouse, the planning stage of overcloud deployment is represented by data stored in Tuskar database tables. For Juno, we would like to remove the database from Tuskar. Instead, the planning stage of a deployment will be represented by the full Heat template that would be used to deploy it. Since Heat does not intend to be a template store, this template will be stored in Swift instead. When the overcloud is ready to be deployed, the Tuskar service will pull the template out of Swift.

[[File:tuskar-arch-juno.png|Tuskar Architecture]]

Once an overcloud is deployed, all Tuskar interactions with that overcloud should be done through Heat. This includes queries about running Nova instances and relevant Ironic nodes.

==== Heat ====

* Allow stacks to be updated without forcing the user to re-provide all parameters (https://bugs.launchpad.net/heat/+bug/1224828)
* Stack update, allow retry from failed states (https://blueprints.launchpad.net/heat/+spec/update-failure-recovery)
* Stack update, rolling updates (canary deployments etc) (https://blueprints.launchpad.net/heat/+spec/rolling-updates)
* Stack update, enable cancelling in-progress update (e.g to pause or rollback) (https://blueprints.launchpad.net/heat/+spec/cancel-update-stack)
* Possibly allow inline specification of provider resources, e.g have a resource which generates a heat template, then refer to it, e.g like type: {get_attr: [SomeResource, template]} (''may not be required by Tuskar'')
* nested resource templates
* Stack preview (preview what would happen via stack-create) (https://blueprints.launchpad.net/heat/+spec/preview-stack) (''may not be required for Juno'')
* Stack check (sync state of stack with the real state of underlying resources, e.g persist out-of-band failures in stack resource states) (https://blueprints.launchpad.net/heat/+spec/stack-check) (''may not be required for Juno'')
* Stack converge - "fixes" stack and returns to known state (https://blueprints.launchpad.net/heat/+spec/stack-convergence) (''may not be required for Juno'')

==== TripleO ====

* update Heat templates in TripleO for: HOT, provider resources, software config

==== Tuskar ====

* provide default templates for default roles (these will be wrapped in ProviderResources)
* construct an overcloud template that references the default roles through ProviderResources
* ensure constructed templates define the appropriate ResourceAttributes to be queried through the UI/CLI
* given a Heat template constructed in this way, parse it in such a way as to retrieve the role specification and Heat parameters
* rebuild Tuskar to save and retrieve Heat templates from Swift
* update CLI as necessary

==== TripleO-UI ====

* update stack queries to take advantage of Heat ResourceAttributes (make sure information is gotten through Heat); for example, Role
* update deployment workflow

== Custom Roles ==

Although default, predefined roles are the immediate goal, it would be nice to also allow users to define their own roles. To do so, they would specify their own list of elements. Tuskar would then use that information to call out to diskimage-builder to create a custom image matching the role; and it would create a custom Heat template for that role that the master overcloud template could then use.

If the above cannot be achieved within Juno, a simpler alternative would be to allow users to specify a custom role, and then associate it with manually created templates and images.

The remainder of the workflow is the same as with default roles.

==== Heat ====

* Diskimage builder resource (question raised wrt ability to spawn VM to host it in seed/undercloud), also OS::GlanceImageUploader resource
==== TripleO ====

* given an image element, return the list of Heat parameters that it needs

==== Tuskar ====

* given a role specification, use diskimage-builder to construct a matching image (derived from the role's image elements)
* given a role specification, return the list of Heat parameters that it needs (derived from the role's image elements)
* given a role specification and its Heat parameters, construct a Heat template for that role that meets those specifications
* allow user to specify a custom role and associate it with a manually created template and image

==== TripleO-UI ====

* create custom role workflow

== High Availability ==

One of TripleO's top priorities for Juno is to allow the deployment of a High-Availability (HA) overcloud. We would like to extend Tuskar to ensure that it can be used to deploy a HA overcloud as well.

==== TripleO ====

* Deploy HA Overcloud
:* glusterfs
:* pacemaker, corosync
:* neutron (?)
:* heat-engine A/A
:* qpid proton (assuming amqp 1.0 have merged into oslo.messaging and oslo.messaging have merged in each core project. If not, will use rabbitmq)
:* etc etc

==== Tuskar ====

* allow the generation of Heat templates that support HA

==== TripleO-UI ====

* deployment workflow support for HA architecture

== Auto-Scaling ==

Having the option for an auto-scaling cloud deployment would be greatly appealing to many users. Heat is actively working on auto-scaling support, as are other projects.

==== Ceilometer ====

* Inhibit autoscaling during stack abandon/adopt (quiesce and revitalize)

==== Heat ====

* hooks to do cleanup on scale-down (e.g host evacuation etc) (https://blueprints.launchpad.net/heat/+spec/update-hooks)
* choose victim on scale-down, or specify strategy for choosing (e.g oldest first or newest first) (https://blueprints.launchpad.net/heat/+spec/autoscaling-parameters)
* support complex conditionals when choosing victim on scale-down (e.g get notification or poll metric via ceilometer related to occupancy or other application metrics); possibly handled by above, if we can get ceilometer to pass us appropriate data when signalling the scaling policy, TBC (''may not be required for Juno'')
* Method to inhibit autoscaling/alarms during abandon/adopt (and suspend/resume?)

==== Tuskar ====

* allow the generation of Heat templates that support auto-scaling

==== TripleO-UI ====

* update deployment workflow to include options that allow an auto-scaled overcloud deployment

== Node Management (Ironic) ==

We would like to switch over to using Ironic in the near future, as there are a host of features that would depend upon it.

==== Ironic ====

* Ironic graduation
:* CI jobs
:* Nova driver
:* Serial console
:* Migration path
:* User documentation

* Autodiscovery of nodes
* Ceilometer
* Tagging
* scalability

==== Nova ====

* create a nova filter for exact matches to Ironic nodes (including all node metadata) (https://review.openstack.org/#/c/83728/)

==== TripleO ====

* Allow settings for Nova Scheduler (https://review.openstack.org/#/c/84131/)

==== Tuskar ====

* use exact match filter when deploying overcloud

==== TripleO-UI ====

* added node tag values to flavor extra_specs

== Metric Graphs ==

Data visualization is a key part of maintaining a cloud. We would like to start integrating Ceilometer usage into Tuskar.

==== Ceilometer ====

* Combine samples for different meters in a transformer to produce a single derived meter
* Rollup of course-grained statistics for UI queries
* Configurable data retention based on rollups
* Overarching "health" metric for nodes
* Ceilometer native auth for alarm notifications (and possibly metrics in future) (https://blueprints.launchpad.net/ceilometer/+spec/trust-alarm-notifier)
* Eliminate central agent SPoF
* SNMP batch mode, one bulk command per node per polling cycle

For additional data:

* Acquire hardware-oriented metrics via IPMI (e.g., voltage, fan speeds, etc.)
* Keystone v3 usage would avoid IPMI credentials; allowing pollster-style interaction
* Look into consistent hashing; see if it can be reused in ceilometer -- though it requires stateful DB

==== Ironic ====

* Add a periodic task to send hardware sensor data to ceilometer (https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer)

==== TripleO ====

* update undercloud images to allow for the monitoring of hardware (setup Central Agent for polling all hardware)

==== Tuskar ====

* add SNMP agents to overcloud images

==== TripleO-UI ====

* Add Ceilometer-based graphs and metric data

== User Interfaces ==

This is a general category intended to encapsulate work needed in the UI and CLI.

==== Horizon ====

* separate horizon from openstack-dashboard
* test the replacement of lesscpy with pyScss
* improve error handling so that messages are less generic
* additional work on the plugin architecture to support dynamic hardware-specific views

==== Tuskar-CLI ====

* create a tuskar-cli plugin for OpenStackClient

==== TripleO-UI ====

* increase the modularity of views
* investigate usage of Heat UI components in Horizon (for example, parameter form building)
* create a mechanism for asynchronous communication

TripleO/TuskarJunoPlanning

2014-04-02T13:23:14Z

Tzumainn: /* Cloud Service Representation */

== Overview ==

This planning document is born from discussions from the TripleO mid-cycle Icehouse meetup in Sunnyvale ([[TripleO/TuskarJunoInitialDiscussion]], [https://etherpad.openstack.org/p/openstack-management-features OpenStack Management Features]). The ideas iterated there were then individually fleshed out and detailed, with much input coming from conversations with other OpenStack projects.

Our principal concerns duing the Juno cycle are:

* integrating further with other OpenStack services, using their capabilities to enhance our TripleO management experience
* ensuring that Tuskar does not try to implement functionality that is better located in other projects

This document details our high-level goals for Juno. It does so at multiple levels; for each we provide:

* a description of the goal
* a list of project requirements and/or blueprints needed

== Cloud Service Representation ==

A cloud service represents a cloud function - provisioning service, storage service, message broker, database server, etc. A cloud service is fulfilled by a cloud service element; for example, a user can fulfill the message broker cloud service by either choosing the qpid-server element or the rabbitmq-server element.

With the cloud service concept in play, overcloud roles are updated as follows: instead of being associated with images, they are associated with a list of cloud service elements. This provides greater flexibility for the Tuskar user when designing the scalable components of a cloud. For example, instead of being limited to a Controller role, the user can separate out the network components of that role into a Network role and scale it individually.

[[File:Tuskar-service-model.png|Tuskar Service Model]]

For Juno, Tuskar will provide role defaults or suggestions corresponding to current default roles in Icehouse, as well as an "All-in-One" role. Each default role will be automatically associated with a list of cloud service elements and a pre-created image. Later iterations of Tuskar will allow for more user customization in this area.

If possible, we would also like to support customized roles that specify their own elements. This would require the development of additional TripleO features as described in the next section.

==== Heat ====

* Diskimage builder resource (question raised wrt ability to spawn VM to host it in seed/undercloud), also OS::GlanceImageUploader resource (''may not be required for Juno'')

==== Tuskar ====

* ensure existence of default images
* create default roles, each associated with a list of elements, an image, and a Heat template

==== TripleO-UI ====

* update deployment workflow to accomodate cloud services

== Overcloud Planning and Deployment ==

In Icehouse, the planning stage of overcloud deployment is represented by data stored in Tuskar database tables. For Juno, we would like to remove the database from Tuskar. Instead, the planning stage of a deployment will be represented by the full Heat template that would be used to deploy it. Since Heat does not intend to be a template store, this template will be stored in Swift instead. When the overcloud is ready to be deployed, the Tuskar service will pull the template out of Swift.

[[File:tuskar-arch-juno.png|Tuskar Architecture]]

Once an overcloud is deployed, all Tuskar interactions with that overcloud should be done through Heat. This includes queries about running Nova instances and relevant Ironic nodes.

==== Heat ====

* Allow stacks to be updated without forcing the user to re-provide all parameters (https://bugs.launchpad.net/heat/+bug/1224828)
* Stack update, allow retry from failed states (https://blueprints.launchpad.net/heat/+spec/update-failure-recovery)
* Stack update, rolling updates (canary deployments etc) (https://blueprints.launchpad.net/heat/+spec/rolling-updates)
* Stack update, enable cancelling in-progress update (e.g to pause or rollback) (https://blueprints.launchpad.net/heat/+spec/cancel-update-stack)
* Possibly allow inline specification of provider resources, e.g have a resource which generates a heat template, then refer to it, e.g like type: {get_attr: [SomeResource, template]} (''may not be required by Tuskar'')
* nested resource templates
* Stack preview (preview what would happen via stack-create) (https://blueprints.launchpad.net/heat/+spec/preview-stack) (''may not be required for Juno'')
* Stack check (sync state of stack with the real state of underlying resources, e.g persist out-of-band failures in stack resource states) (https://blueprints.launchpad.net/heat/+spec/stack-check) (''may not be required for Juno'')
* Stack converge - "fixes" stack and returns to known state (https://blueprints.launchpad.net/heat/+spec/stack-convergence) (''may not be required for Juno'')

==== TripleO ====

* update Heat templates in TripleO for: HOT, provider resources, software config

==== Tuskar ====

* provide default templates for default roles (these will be wrapped in ProviderResources)
* construct an overcloud template that references the default roles through ProviderResources
* ensure constructed templates define the appropriate ResourceAttributes to be queried through the UI/CLI
* given a Heat template constructed in this way, parse it in such a way as to retrieve the role specification and Heat parameters
* rebuild Tuskar to save and retrieve Heat templates from Swift
* update CLI as necessary

==== TripleO-UI ====

* update stack queries to take advantage of Heat ResourceAttributes (make sure information is gotten through Heat); for example, Role
* update deployment workflow

== Custom Roles ==

Although default, predefined roles are the immediate goal, it would be nice to also allow users to define their own roles. To do so, they would specify their own list of elements. Tuskar would then use that information to call out to diskimage-builder to create a custom image matching the role; and it would create a custom Heat template for that role that the master overcloud template could then use.

If the above cannot be achieved within Juno, a simpler alternative would be to allow users to specify a custom role, and then associate it with manually created templates and images.

The remainder of the workflow is the same as with default roles.

==== TripleO ====

* given an image element, return the list of Heat parameters that it needs

==== Tuskar ====

* given a role specification, use diskimage-builder to construct a matching image (derived from the role's image elements)
* given a role specification, return the list of Heat parameters that it needs (derived from the role's image elements)
* given a role specification and its Heat parameters, construct a Heat template for that role that meets those specifications
* allow user to specify a custom role and associate it with a manually created template and image

==== TripleO-UI ====

* create custom role workflow

== High Availability ==

One of TripleO's top priorities for Juno is to allow the deployment of a High-Availability (HA) overcloud. We would like to extend Tuskar to ensure that it can be used to deploy a HA overcloud as well.

==== TripleO ====

* Deploy HA Overcloud
:* glusterfs
:* pacemaker, corosync
:* neutron (?)
:* heat-engine A/A
:* qpid proton (assuming amqp 1.0 have merged into oslo.messaging and oslo.messaging have merged in each core project. If not, will use rabbitmq)
:* etc etc

==== Tuskar ====

* allow the generation of Heat templates that support HA

==== TripleO-UI ====

* deployment workflow support for HA architecture

== Auto-Scaling ==

Having the option for an auto-scaling cloud deployment would be greatly appealing to many users. Heat is actively working on auto-scaling support, as are other projects.

==== Ceilometer ====

* Inhibit autoscaling during stack abandon/adopt (quiesce and revitalize)

==== Heat ====

* hooks to do cleanup on scale-down (e.g host evacuation etc) (https://blueprints.launchpad.net/heat/+spec/update-hooks)
* choose victim on scale-down, or specify strategy for choosing (e.g oldest first or newest first) (https://blueprints.launchpad.net/heat/+spec/autoscaling-parameters)
* support complex conditionals when choosing victim on scale-down (e.g get notification or poll metric via ceilometer related to occupancy or other application metrics); possibly handled by above, if we can get ceilometer to pass us appropriate data when signalling the scaling policy, TBC (''may not be required for Juno'')
* Method to inhibit autoscaling/alarms during abandon/adopt (and suspend/resume?)

==== Tuskar ====

* allow the generation of Heat templates that support auto-scaling

==== TripleO-UI ====

* update deployment workflow to include options that allow an auto-scaled overcloud deployment

== Node Management (Ironic) ==

We would like to switch over to using Ironic in the near future, as there are a host of features that would depend upon it.

==== Ironic ====

* Ironic graduation
:* CI jobs
:* Nova driver
:* Serial console
:* Migration path
:* User documentation

* Autodiscovery of nodes
* Ceilometer
* Tagging
* scalability

==== Nova ====

* create a nova filter for exact matches to Ironic nodes (including all node metadata) (https://review.openstack.org/#/c/83728/)

==== TripleO ====

* Allow settings for Nova Scheduler (https://review.openstack.org/#/c/84131/)

==== Tuskar ====

* use exact match filter when deploying overcloud

==== TripleO-UI ====

* added node tag values to flavor extra_specs

== Metric Graphs ==

Data visualization is a key part of maintaining a cloud. We would like to start integrating Ceilometer usage into Tuskar.

==== Ceilometer ====

* Combine samples for different meters in a transformer to produce a single derived meter
* Rollup of course-grained statistics for UI queries
* Configurable data retention based on rollups
* Overarching "health" metric for nodes
* Ceilometer native auth for alarm notifications (and possibly metrics in future) (https://blueprints.launchpad.net/ceilometer/+spec/trust-alarm-notifier)
* Eliminate central agent SPoF
* SNMP batch mode, one bulk command per node per polling cycle

For additional data:

* Acquire hardware-oriented metrics via IPMI (e.g., voltage, fan speeds, etc.)
* Keystone v3 usage would avoid IPMI credentials; allowing pollster-style interaction
* Look into consistent hashing; see if it can be reused in ceilometer -- though it requires stateful DB

==== Ironic ====

* Add a periodic task to send hardware sensor data to ceilometer (https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer)

==== TripleO ====

* update undercloud images to allow for the monitoring of hardware (setup Central Agent for polling all hardware)

==== Tuskar ====

* add SNMP agents to overcloud images

==== TripleO-UI ====

* Add Ceilometer-based graphs and metric data

== User Interfaces ==

This is a general category intended to encapsulate work needed in the UI and CLI.

==== Horizon ====

* separate horizon from openstack-dashboard
* test the replacement of lesscpy with pyScss
* improve error handling so that messages are less generic
* additional work on the plugin architecture to support dynamic hardware-specific views

==== Tuskar-CLI ====

* create a tuskar-cli plugin for OpenStackClient

==== TripleO-UI ====

* increase the modularity of views
* investigate usage of Heat UI components in Horizon (for example, parameter form building)
* create a mechanism for asynchronous communication

TripleO/TuskarJunoPlanning

2014-04-01T14:31:24Z

Tzumainn: /* TripleO-UI */

== Overview ==

This planning document is born from discussions from the TripleO mid-cycle Icehouse meetup in Sunnyvale ([[TripleO/TuskarJunoInitialDiscussion]], [https://etherpad.openstack.org/p/openstack-management-features OpenStack Management Features]). The ideas iterated there were then individually fleshed out and detailed, with much input coming from conversations with other OpenStack projects.

Our principal concerns duing the Juno cycle are:

* integrating further with other OpenStack services, using their capabilities to enhance our TripleO management experience
* ensuring that Tuskar does not try to implement functionality that is better located in other projects

This document details our high-level goals for Juno. It does so at multiple levels; for each we provide:

* a description of the goal
* a list of project requirements and/or blueprints needed

== Cloud Service Representation ==

A cloud service represents a cloud function - provisioning service, storage service, message broker, database server, etc. A cloud service is fulfilled by a cloud service element; for example, a user can fulfill the message broker cloud service by either choosing the qpid-server element or the rabbitmq-server element.

With the cloud service concept in play, overcloud roles are updated as follows: instead of being associated with images, they are associated with a list of cloud service elements. This provides greater flexibility for the Tuskar user when designing the scalable components of a cloud. For example, instead of being limited to a Controller role, the user can separate out the network components of that role into a Network role and scale it individually.

[[File:Tuskar-service-model.png|Tuskar Service Model]]

For Juno, Tuskar will provide role defaults or suggestions corresponding to current default roles, as well as an "All-in-One" role. Each default role will be automatically associated with a list of cloud service elements and a pre-created image. Later iterations of Tuskar will allow for more user customization in this area.

If possible, we would also like to support customized roles that specify their own elements. This would require the development of additional TripleO features as described in the next section.

==== Heat ====

* Diskimage builder resource (question raised wrt ability to spawn VM to host it in seed/undercloud), also OS::GlanceImageUploader resource (''may not be required for Juno'')

==== Tuskar ====

* ensure existence of default images
* create default roles, each associated with a list of elements, an image, and a Heat template

==== TripleO-UI ====

* update deployment workflow to accomodate cloud services

== Overcloud Planning and Deployment ==

In Icehouse, the planning stage of overcloud deployment is represented by data stored in Tuskar database tables. For Juno, we would like to remove the database from Tuskar. Instead, the planning stage of a deployment will be represented by the full Heat template that would be used to deploy it. Since Heat does not intend to be a template store, this template will be stored in Swift instead. When the overcloud is ready to be deployed, the Tuskar service will pull the template out of Swift.

[[File:tuskar-arch-juno.png|Tuskar Architecture]]

Once an overcloud is deployed, all Tuskar interactions with that overcloud should be done through Heat. This includes queries about running Nova instances and relevant Ironic nodes.

==== Heat ====

* Allow stacks to be updated without forcing the user to re-provide all parameters (https://bugs.launchpad.net/heat/+bug/1224828)
* Stack update, allow retry from failed states (https://blueprints.launchpad.net/heat/+spec/update-failure-recovery)
* Stack update, rolling updates (canary deployments etc) (https://blueprints.launchpad.net/heat/+spec/rolling-updates)
* Stack update, enable cancelling in-progress update (e.g to pause or rollback) (https://blueprints.launchpad.net/heat/+spec/cancel-update-stack)
* Possibly allow inline specification of provider resources, e.g have a resource which generates a heat template, then refer to it, e.g like type: {get_attr: [SomeResource, template]} (''may not be required by Tuskar'')
* nested resource templates
* Stack preview (preview what would happen via stack-create) (https://blueprints.launchpad.net/heat/+spec/preview-stack) (''may not be required for Juno'')
* Stack check (sync state of stack with the real state of underlying resources, e.g persist out-of-band failures in stack resource states) (https://blueprints.launchpad.net/heat/+spec/stack-check) (''may not be required for Juno'')
* Stack converge - "fixes" stack and returns to known state (https://blueprints.launchpad.net/heat/+spec/stack-convergence) (''may not be required for Juno'')

==== TripleO ====

* update Heat templates in TripleO for: HOT, provider resources, software config

==== Tuskar ====

* provide default templates for default roles (these will be wrapped in ProviderResources)
* construct an overcloud template that references the default roles through ProviderResources
* ensure constructed templates define the appropriate ResourceAttributes to be queried through the UI/CLI
* given a Heat template constructed in this way, parse it in such a way as to retrieve the role specification and Heat parameters
* rebuild Tuskar to save and retrieve Heat templates from Swift
* update CLI as necessary

==== TripleO-UI ====

* update stack queries to take advantage of Heat ResourceAttributes (make sure information is gotten through Heat); for example, Role
* update deployment workflow

== Custom Roles ==

Although default, predefined roles are the immediate goal, it would be nice to also allow users to define their own roles. To do so, they would specify their own list of elements. Tuskar would then use that information to call out to diskimage-builder to create a custom image matching the role; and it would create a custom Heat template for that role that the master overcloud template could then use.

If the above cannot be achieved within Juno, a simpler alternative would be to allow users to specify a custom role, and then associate it with manually created templates and images.

The remainder of the workflow is the same as with default roles.

==== TripleO ====

* given an image element, return the list of Heat parameters that it needs

==== Tuskar ====

* given a role specification, use diskimage-builder to construct a matching image (derived from the role's image elements)
* given a role specification, return the list of Heat parameters that it needs (derived from the role's image elements)
* given a role specification and its Heat parameters, construct a Heat template for that role that meets those specifications
* allow user to specify a custom role and associate it with a manually created template and image

==== TripleO-UI ====

* create custom role workflow

== High Availability ==

One of TripleO's top priorities for Juno is to allow the deployment of a High-Availability (HA) overcloud. We would like to extend Tuskar to ensure that it can be used to deploy a HA overcloud as well.

==== TripleO ====

* Deploy HA Overcloud
:* glusterfs
:* pacemaker, corosync
:* neutron (?)
:* heat-engine A/A
:* qpid proton (assuming amqp 1.0 have merged into oslo.messaging and oslo.messaging have merged in each core project. If not, will use rabbitmq)
:* etc etc

==== Tuskar ====

* allow the generation of Heat templates that support HA

==== TripleO-UI ====

* deployment workflow support for HA architecture

== Auto-Scaling ==

Having the option for an auto-scaling cloud deployment would be greatly appealing to many users. Heat is actively working on auto-scaling support, as are other projects.

==== Ceilometer ====

* Inhibit autoscaling during stack abandon/adopt (quiesce and revitalize)

==== Heat ====

* hooks to do cleanup on scale-down (e.g host evacuation etc) (https://blueprints.launchpad.net/heat/+spec/update-hooks)
* choose victim on scale-down, or specify strategy for choosing (e.g oldest first or newest first) (https://blueprints.launchpad.net/heat/+spec/autoscaling-parameters)
* support complex conditionals when choosing victim on scale-down (e.g get notification or poll metric via ceilometer related to occupancy or other application metrics); possibly handled by above, if we can get ceilometer to pass us appropriate data when signalling the scaling policy, TBC (''may not be required for Juno'')
* Method to inhibit autoscaling/alarms during abandon/adopt (and suspend/resume?)

==== Tuskar ====

* allow the generation of Heat templates that support auto-scaling

==== TripleO-UI ====

* update deployment workflow to include options that allow an auto-scaled overcloud deployment

== Node Management (Ironic) ==

We would like to switch over to using Ironic in the near future, as there are a host of features that would depend upon it.

==== Ironic ====

* Ironic graduation
:* CI jobs
:* Nova driver
:* Serial console
:* Migration path
:* User documentation

* Autodiscovery of nodes
* Ceilometer
* Tagging
* scalability

==== Nova ====

* create a nova filter for exact matches to Ironic nodes (including all node metadata) (https://review.openstack.org/#/c/83728/)

==== TripleO ====

* Allow settings for Nova Scheduler (https://review.openstack.org/#/c/84131/)

==== Tuskar ====

* use exact match filter when deploying overcloud

==== TripleO-UI ====

* added node tag values to flavor extra_specs

== Metric Graphs ==

Data visualization is a key part of maintaining a cloud. We would like to start integrating Ceilometer usage into Tuskar.

==== Ceilometer ====

* Combine samples for different meters in a transformer to produce a single derived meter
* Rollup of course-grained statistics for UI queries
* Configurable data retention based on rollups
* Overarching "health" metric for nodes
* Ceilometer native auth for alarm notifications (and possibly metrics in future) (https://blueprints.launchpad.net/ceilometer/+spec/trust-alarm-notifier)
* Eliminate central agent SPoF
* SNMP batch mode, one bulk command per node per polling cycle

For additional data:

* Acquire hardware-oriented metrics via IPMI (e.g., voltage, fan speeds, etc.)
* Keystone v3 usage would avoid IPMI credentials; allowing pollster-style interaction
* Look into consistent hashing; see if it can be reused in ceilometer -- though it requires stateful DB

==== Ironic ====

* Add a periodic task to send hardware sensor data to ceilometer (https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer)

==== TripleO ====

* update undercloud images to allow for the monitoring of hardware (setup Central Agent for polling all hardware)

==== Tuskar ====

* add SNMP agents to overcloud images

==== TripleO-UI ====

* Add Ceilometer-based graphs and metric data

== User Interfaces ==

This is a general category intended to encapsulate work needed in the UI and CLI.

==== Horizon ====

* separate horizon from openstack-dashboard
* test the replacement of lesscpy with pyScss
* improve error handling so that messages are less generic
* additional work on the plugin architecture to support dynamic hardware-specific views

==== Tuskar-CLI ====

* create a tuskar-cli plugin for OpenStackClient

==== TripleO-UI ====

* increase the modularity of views
* investigate usage of Heat UI components in Horizon (for example, parameter form building)
* create a mechanism for asynchronous communication

TripleO/TuskarJunoPlanning

2014-04-01T14:29:37Z

Tzumainn: /* Node Management (Ironic) */

== Overview ==

This planning document is born from discussions from the TripleO mid-cycle Icehouse meetup in Sunnyvale ([[TripleO/TuskarJunoInitialDiscussion]], [https://etherpad.openstack.org/p/openstack-management-features OpenStack Management Features]). The ideas iterated there were then individually fleshed out and detailed, with much input coming from conversations with other OpenStack projects.

Our principal concerns duing the Juno cycle are:

* integrating further with other OpenStack services, using their capabilities to enhance our TripleO management experience
* ensuring that Tuskar does not try to implement functionality that is better located in other projects

This document details our high-level goals for Juno. It does so at multiple levels; for each we provide:

* a description of the goal
* a list of project requirements and/or blueprints needed

== Cloud Service Representation ==

A cloud service represents a cloud function - provisioning service, storage service, message broker, database server, etc. A cloud service is fulfilled by a cloud service element; for example, a user can fulfill the message broker cloud service by either choosing the qpid-server element or the rabbitmq-server element.

With the cloud service concept in play, overcloud roles are updated as follows: instead of being associated with images, they are associated with a list of cloud service elements. This provides greater flexibility for the Tuskar user when designing the scalable components of a cloud. For example, instead of being limited to a Controller role, the user can separate out the network components of that role into a Network role and scale it individually.

[[File:Tuskar-service-model.png|Tuskar Service Model]]

For Juno, Tuskar will provide role defaults or suggestions corresponding to current default roles, as well as an "All-in-One" role. Each default role will be automatically associated with a list of cloud service elements and a pre-created image. Later iterations of Tuskar will allow for more user customization in this area.

If possible, we would also like to support customized roles that specify their own elements. This would require the development of additional TripleO features as described in the next section.

==== Heat ====

* Diskimage builder resource (question raised wrt ability to spawn VM to host it in seed/undercloud), also OS::GlanceImageUploader resource (''may not be required for Juno'')

==== Tuskar ====

* ensure existence of default images
* create default roles, each associated with a list of elements, an image, and a Heat template

==== TripleO-UI ====

* update deployment workflow to accomodate cloud services

== Overcloud Planning and Deployment ==

In Icehouse, the planning stage of overcloud deployment is represented by data stored in Tuskar database tables. For Juno, we would like to remove the database from Tuskar. Instead, the planning stage of a deployment will be represented by the full Heat template that would be used to deploy it. Since Heat does not intend to be a template store, this template will be stored in Swift instead. When the overcloud is ready to be deployed, the Tuskar service will pull the template out of Swift.

[[File:tuskar-arch-juno.png|Tuskar Architecture]]

Once an overcloud is deployed, all Tuskar interactions with that overcloud should be done through Heat. This includes queries about running Nova instances and relevant Ironic nodes.

==== Heat ====

* Allow stacks to be updated without forcing the user to re-provide all parameters (https://bugs.launchpad.net/heat/+bug/1224828)
* Stack update, allow retry from failed states (https://blueprints.launchpad.net/heat/+spec/update-failure-recovery)
* Stack update, rolling updates (canary deployments etc) (https://blueprints.launchpad.net/heat/+spec/rolling-updates)
* Stack update, enable cancelling in-progress update (e.g to pause or rollback) (https://blueprints.launchpad.net/heat/+spec/cancel-update-stack)
* Possibly allow inline specification of provider resources, e.g have a resource which generates a heat template, then refer to it, e.g like type: {get_attr: [SomeResource, template]} (''may not be required by Tuskar'')
* nested resource templates
* Stack preview (preview what would happen via stack-create) (https://blueprints.launchpad.net/heat/+spec/preview-stack) (''may not be required for Juno'')
* Stack check (sync state of stack with the real state of underlying resources, e.g persist out-of-band failures in stack resource states) (https://blueprints.launchpad.net/heat/+spec/stack-check) (''may not be required for Juno'')
* Stack converge - "fixes" stack and returns to known state (https://blueprints.launchpad.net/heat/+spec/stack-convergence) (''may not be required for Juno'')

==== TripleO ====

* update Heat templates in TripleO for: HOT, provider resources, software config

==== Tuskar ====

* provide default templates for default roles (these will be wrapped in ProviderResources)
* construct an overcloud template that references the default roles through ProviderResources
* ensure constructed templates define the appropriate ResourceAttributes to be queried through the UI/CLI
* given a Heat template constructed in this way, parse it in such a way as to retrieve the role specification and Heat parameters
* rebuild Tuskar to save and retrieve Heat templates from Swift
* update CLI as necessary

==== TripleO-UI ====

* update stack queries to take advantage Heat ResourceAttributes (make sure information is gotten through Heat)
* update deployment workflow

== Custom Roles ==

Although default, predefined roles are the immediate goal, it would be nice to also allow users to define their own roles. To do so, they would specify their own list of elements. Tuskar would then use that information to call out to diskimage-builder to create a custom image matching the role; and it would create a custom Heat template for that role that the master overcloud template could then use.

If the above cannot be achieved within Juno, a simpler alternative would be to allow users to specify a custom role, and then associate it with manually created templates and images.

The remainder of the workflow is the same as with default roles.

==== TripleO ====

* given an image element, return the list of Heat parameters that it needs

==== Tuskar ====

* given a role specification, use diskimage-builder to construct a matching image (derived from the role's image elements)
* given a role specification, return the list of Heat parameters that it needs (derived from the role's image elements)
* given a role specification and its Heat parameters, construct a Heat template for that role that meets those specifications
* allow user to specify a custom role and associate it with a manually created template and image

==== TripleO-UI ====

* create custom role workflow

== High Availability ==

One of TripleO's top priorities for Juno is to allow the deployment of a High-Availability (HA) overcloud. We would like to extend Tuskar to ensure that it can be used to deploy a HA overcloud as well.

==== TripleO ====

* Deploy HA Overcloud
:* glusterfs
:* pacemaker, corosync
:* neutron (?)
:* heat-engine A/A
:* qpid proton (assuming amqp 1.0 have merged into oslo.messaging and oslo.messaging have merged in each core project. If not, will use rabbitmq)
:* etc etc

==== Tuskar ====

* allow the generation of Heat templates that support HA

==== TripleO-UI ====

* deployment workflow support for HA architecture

== Auto-Scaling ==

Having the option for an auto-scaling cloud deployment would be greatly appealing to many users. Heat is actively working on auto-scaling support, as are other projects.

==== Ceilometer ====

* Inhibit autoscaling during stack abandon/adopt (quiesce and revitalize)

==== Heat ====

* hooks to do cleanup on scale-down (e.g host evacuation etc) (https://blueprints.launchpad.net/heat/+spec/update-hooks)
* choose victim on scale-down, or specify strategy for choosing (e.g oldest first or newest first) (https://blueprints.launchpad.net/heat/+spec/autoscaling-parameters)
* support complex conditionals when choosing victim on scale-down (e.g get notification or poll metric via ceilometer related to occupancy or other application metrics); possibly handled by above, if we can get ceilometer to pass us appropriate data when signalling the scaling policy, TBC (''may not be required for Juno'')
* Method to inhibit autoscaling/alarms during abandon/adopt (and suspend/resume?)

==== Tuskar ====

* allow the generation of Heat templates that support auto-scaling

==== TripleO-UI ====

* update deployment workflow to include options that allow an auto-scaled overcloud deployment

== Node Management (Ironic) ==

We would like to switch over to using Ironic in the near future, as there are a host of features that would depend upon it.

==== Ironic ====

* Ironic graduation
:* CI jobs
:* Nova driver
:* Serial console
:* Migration path
:* User documentation

* Autodiscovery of nodes
* Ceilometer
* Tagging
* scalability

==== Nova ====

* create a nova filter for exact matches to Ironic nodes (including all node metadata) (https://review.openstack.org/#/c/83728/)

==== TripleO ====

* Allow settings for Nova Scheduler (https://review.openstack.org/#/c/84131/)

==== Tuskar ====

* use exact match filter when deploying overcloud

==== TripleO-UI ====

* added node tag values to flavor extra_specs

== Metric Graphs ==

Data visualization is a key part of maintaining a cloud. We would like to start integrating Ceilometer usage into Tuskar.

==== Ceilometer ====

* Combine samples for different meters in a transformer to produce a single derived meter
* Rollup of course-grained statistics for UI queries
* Configurable data retention based on rollups
* Overarching "health" metric for nodes
* Ceilometer native auth for alarm notifications (and possibly metrics in future) (https://blueprints.launchpad.net/ceilometer/+spec/trust-alarm-notifier)
* Eliminate central agent SPoF
* SNMP batch mode, one bulk command per node per polling cycle

For additional data:

* Acquire hardware-oriented metrics via IPMI (e.g., voltage, fan speeds, etc.)
* Keystone v3 usage would avoid IPMI credentials; allowing pollster-style interaction
* Look into consistent hashing; see if it can be reused in ceilometer -- though it requires stateful DB

==== Ironic ====

* Add a periodic task to send hardware sensor data to ceilometer (https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer)

==== TripleO ====

* update undercloud images to allow for the monitoring of hardware (setup Central Agent for polling all hardware)

==== Tuskar ====

* add SNMP agents to overcloud images

==== TripleO-UI ====

* Add Ceilometer-based graphs and metric data

== User Interfaces ==

This is a general category intended to encapsulate work needed in the UI and CLI.

==== Horizon ====

* separate horizon from openstack-dashboard
* test the replacement of lesscpy with pyScss
* improve error handling so that messages are less generic
* additional work on the plugin architecture to support dynamic hardware-specific views

==== Tuskar-CLI ====

* create a tuskar-cli plugin for OpenStackClient

==== TripleO-UI ====

* increase the modularity of views
* investigate usage of Heat UI components in Horizon (for example, parameter form building)
* create a mechanism for asynchronous communication

TripleO/TuskarJunoPlanning

2014-04-01T14:28:10Z

Tzumainn: /* Custom Roles */

== Overview ==

This planning document is born from discussions from the TripleO mid-cycle Icehouse meetup in Sunnyvale ([[TripleO/TuskarJunoInitialDiscussion]], [https://etherpad.openstack.org/p/openstack-management-features OpenStack Management Features]). The ideas iterated there were then individually fleshed out and detailed, with much input coming from conversations with other OpenStack projects.

Our principal concerns duing the Juno cycle are:

* integrating further with other OpenStack services, using their capabilities to enhance our TripleO management experience
* ensuring that Tuskar does not try to implement functionality that is better located in other projects

This document details our high-level goals for Juno. It does so at multiple levels; for each we provide:

* a description of the goal
* a list of project requirements and/or blueprints needed

== Cloud Service Representation ==

A cloud service represents a cloud function - provisioning service, storage service, message broker, database server, etc. A cloud service is fulfilled by a cloud service element; for example, a user can fulfill the message broker cloud service by either choosing the qpid-server element or the rabbitmq-server element.

With the cloud service concept in play, overcloud roles are updated as follows: instead of being associated with images, they are associated with a list of cloud service elements. This provides greater flexibility for the Tuskar user when designing the scalable components of a cloud. For example, instead of being limited to a Controller role, the user can separate out the network components of that role into a Network role and scale it individually.

[[File:Tuskar-service-model.png|Tuskar Service Model]]

For Juno, Tuskar will provide role defaults or suggestions corresponding to current default roles, as well as an "All-in-One" role. Each default role will be automatically associated with a list of cloud service elements and a pre-created image. Later iterations of Tuskar will allow for more user customization in this area.

If possible, we would also like to support customized roles that specify their own elements. This would require the development of additional TripleO features as described in the next section.

==== Heat ====

* Diskimage builder resource (question raised wrt ability to spawn VM to host it in seed/undercloud), also OS::GlanceImageUploader resource (''may not be required for Juno'')

==== Tuskar ====

* ensure existence of default images
* create default roles, each associated with a list of elements, an image, and a Heat template

==== TripleO-UI ====

* update deployment workflow to accomodate cloud services

== Overcloud Planning and Deployment ==

In Icehouse, the planning stage of overcloud deployment is represented by data stored in Tuskar database tables. For Juno, we would like to remove the database from Tuskar. Instead, the planning stage of a deployment will be represented by the full Heat template that would be used to deploy it. Since Heat does not intend to be a template store, this template will be stored in Swift instead. When the overcloud is ready to be deployed, the Tuskar service will pull the template out of Swift.

[[File:tuskar-arch-juno.png|Tuskar Architecture]]

Once an overcloud is deployed, all Tuskar interactions with that overcloud should be done through Heat. This includes queries about running Nova instances and relevant Ironic nodes.

==== Heat ====

* Allow stacks to be updated without forcing the user to re-provide all parameters (https://bugs.launchpad.net/heat/+bug/1224828)
* Stack update, allow retry from failed states (https://blueprints.launchpad.net/heat/+spec/update-failure-recovery)
* Stack update, rolling updates (canary deployments etc) (https://blueprints.launchpad.net/heat/+spec/rolling-updates)
* Stack update, enable cancelling in-progress update (e.g to pause or rollback) (https://blueprints.launchpad.net/heat/+spec/cancel-update-stack)
* Possibly allow inline specification of provider resources, e.g have a resource which generates a heat template, then refer to it, e.g like type: {get_attr: [SomeResource, template]} (''may not be required by Tuskar'')
* nested resource templates
* Stack preview (preview what would happen via stack-create) (https://blueprints.launchpad.net/heat/+spec/preview-stack) (''may not be required for Juno'')
* Stack check (sync state of stack with the real state of underlying resources, e.g persist out-of-band failures in stack resource states) (https://blueprints.launchpad.net/heat/+spec/stack-check) (''may not be required for Juno'')
* Stack converge - "fixes" stack and returns to known state (https://blueprints.launchpad.net/heat/+spec/stack-convergence) (''may not be required for Juno'')

==== TripleO ====

* update Heat templates in TripleO for: HOT, provider resources, software config

==== Tuskar ====

* provide default templates for default roles (these will be wrapped in ProviderResources)
* construct an overcloud template that references the default roles through ProviderResources
* ensure constructed templates define the appropriate ResourceAttributes to be queried through the UI/CLI
* given a Heat template constructed in this way, parse it in such a way as to retrieve the role specification and Heat parameters
* rebuild Tuskar to save and retrieve Heat templates from Swift
* update CLI as necessary

==== TripleO-UI ====

* update stack queries to take advantage Heat ResourceAttributes (make sure information is gotten through Heat)
* update deployment workflow

== Custom Roles ==

Although default, predefined roles are the immediate goal, it would be nice to also allow users to define their own roles. To do so, they would specify their own list of elements. Tuskar would then use that information to call out to diskimage-builder to create a custom image matching the role; and it would create a custom Heat template for that role that the master overcloud template could then use.

If the above cannot be achieved within Juno, a simpler alternative would be to allow users to specify a custom role, and then associate it with manually created templates and images.

The remainder of the workflow is the same as with default roles.

==== TripleO ====

* given an image element, return the list of Heat parameters that it needs

==== Tuskar ====

* given a role specification, use diskimage-builder to construct a matching image (derived from the role's image elements)
* given a role specification, return the list of Heat parameters that it needs (derived from the role's image elements)
* given a role specification and its Heat parameters, construct a Heat template for that role that meets those specifications
* allow user to specify a custom role and associate it with a manually created template and image

==== TripleO-UI ====

* create custom role workflow

== High Availability ==

One of TripleO's top priorities for Juno is to allow the deployment of a High-Availability (HA) overcloud. We would like to extend Tuskar to ensure that it can be used to deploy a HA overcloud as well.

==== TripleO ====

* Deploy HA Overcloud
:* glusterfs
:* pacemaker, corosync
:* neutron (?)
:* heat-engine A/A
:* qpid proton (assuming amqp 1.0 have merged into oslo.messaging and oslo.messaging have merged in each core project. If not, will use rabbitmq)
:* etc etc

==== Tuskar ====

* allow the generation of Heat templates that support HA

==== TripleO-UI ====

* deployment workflow support for HA architecture

== Auto-Scaling ==

Having the option for an auto-scaling cloud deployment would be greatly appealing to many users. Heat is actively working on auto-scaling support, as are other projects.

==== Ceilometer ====

* Inhibit autoscaling during stack abandon/adopt (quiesce and revitalize)

==== Heat ====

* hooks to do cleanup on scale-down (e.g host evacuation etc) (https://blueprints.launchpad.net/heat/+spec/update-hooks)
* choose victim on scale-down, or specify strategy for choosing (e.g oldest first or newest first) (https://blueprints.launchpad.net/heat/+spec/autoscaling-parameters)
* support complex conditionals when choosing victim on scale-down (e.g get notification or poll metric via ceilometer related to occupancy or other application metrics); possibly handled by above, if we can get ceilometer to pass us appropriate data when signalling the scaling policy, TBC (''may not be required for Juno'')
* Method to inhibit autoscaling/alarms during abandon/adopt (and suspend/resume?)

==== Tuskar ====

* allow the generation of Heat templates that support auto-scaling

==== TripleO-UI ====

* update deployment workflow to include options that allow an auto-scaled overcloud deployment

== Node Management (Ironic) ==

We would like to switch over to using Ironic in the near future, as there are a host of features that would depend upon it.

==== Ironic ====

* Ironic graduation
:* CI jobs
:* Nova driver
:* Serial console
:* Migration path
:* User documentation

* Autodiscovery of nodes
* Ceilometer
* Tagging
* scalability

==== Nova ====

* create a nova filter for exact matches to Ironic nodes (including all node metadata) (https://review.openstack.org/#/c/83728/)

==== Tuskar ====

* use exact match filter when deploying overcloud

==== TripleO-UI ====

* added node tag values to flavor extra_specs

== Metric Graphs ==

Data visualization is a key part of maintaining a cloud. We would like to start integrating Ceilometer usage into Tuskar.

==== Ceilometer ====

* Combine samples for different meters in a transformer to produce a single derived meter
* Rollup of course-grained statistics for UI queries
* Configurable data retention based on rollups
* Overarching "health" metric for nodes
* Ceilometer native auth for alarm notifications (and possibly metrics in future) (https://blueprints.launchpad.net/ceilometer/+spec/trust-alarm-notifier)
* Eliminate central agent SPoF
* SNMP batch mode, one bulk command per node per polling cycle

For additional data:

* Acquire hardware-oriented metrics via IPMI (e.g., voltage, fan speeds, etc.)
* Keystone v3 usage would avoid IPMI credentials; allowing pollster-style interaction
* Look into consistent hashing; see if it can be reused in ceilometer -- though it requires stateful DB

==== Ironic ====

* Add a periodic task to send hardware sensor data to ceilometer (https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer)

==== TripleO ====

* update undercloud images to allow for the monitoring of hardware (setup Central Agent for polling all hardware)

==== Tuskar ====

* add SNMP agents to overcloud images

==== TripleO-UI ====

* Add Ceilometer-based graphs and metric data

== User Interfaces ==

This is a general category intended to encapsulate work needed in the UI and CLI.

==== Horizon ====

* separate horizon from openstack-dashboard
* test the replacement of lesscpy with pyScss
* improve error handling so that messages are less generic
* additional work on the plugin architecture to support dynamic hardware-specific views

==== Tuskar-CLI ====

* create a tuskar-cli plugin for OpenStackClient

==== TripleO-UI ====

* increase the modularity of views
* investigate usage of Heat UI components in Horizon (for example, parameter form building)
* create a mechanism for asynchronous communication

TripleO/TuskarJunoPlanning

2014-04-01T14:15:08Z

Tzumainn: /* TripleO */

== Overview ==

This planning document is born from discussions from the TripleO mid-cycle Icehouse meetup in Sunnyvale ([[TripleO/TuskarJunoInitialDiscussion]], [https://etherpad.openstack.org/p/openstack-management-features OpenStack Management Features]). The ideas iterated there were then individually fleshed out and detailed, with much input coming from conversations with other OpenStack projects.

Our principal concerns duing the Juno cycle are:

* integrating further with other OpenStack services, using their capabilities to enhance our TripleO management experience
* ensuring that Tuskar does not try to implement functionality that is better located in other projects

This document details our high-level goals for Juno. It does so at multiple levels; for each we provide:

* a description of the goal
* a list of project requirements and/or blueprints needed

== Cloud Service Representation ==

A cloud service represents a cloud function - provisioning service, storage service, message broker, database server, etc. A cloud service is fulfilled by a cloud service element; for example, a user can fulfill the message broker cloud service by either choosing the qpid-server element or the rabbitmq-server element.

With the cloud service concept in play, overcloud roles are updated as follows: instead of being associated with images, they are associated with a list of cloud service elements. This provides greater flexibility for the Tuskar user when designing the scalable components of a cloud. For example, instead of being limited to a Controller role, the user can separate out the network components of that role into a Network role and scale it individually.

[[File:Tuskar-service-model.png|Tuskar Service Model]]

For Juno, Tuskar will provide role defaults or suggestions corresponding to current default roles, as well as an "All-in-One" role. Each default role will be automatically associated with a list of cloud service elements and a pre-created image. Later iterations of Tuskar will allow for more user customization in this area.

If possible, we would also like to support customized roles that specify their own elements. This would require the development of additional TripleO features as described in the next section.

==== Heat ====

* Diskimage builder resource (question raised wrt ability to spawn VM to host it in seed/undercloud), also OS::GlanceImageUploader resource (''may not be required for Juno'')

==== Tuskar ====

* ensure existence of default images
* create default roles, each associated with a list of elements, an image, and a Heat template

==== TripleO-UI ====

* update deployment workflow to accomodate cloud services

== Overcloud Planning and Deployment ==

In Icehouse, the planning stage of overcloud deployment is represented by data stored in Tuskar database tables. For Juno, we would like to remove the database from Tuskar. Instead, the planning stage of a deployment will be represented by the full Heat template that would be used to deploy it. Since Heat does not intend to be a template store, this template will be stored in Swift instead. When the overcloud is ready to be deployed, the Tuskar service will pull the template out of Swift.

[[File:tuskar-arch-juno.png|Tuskar Architecture]]

Once an overcloud is deployed, all Tuskar interactions with that overcloud should be done through Heat. This includes queries about running Nova instances and relevant Ironic nodes.

==== Heat ====

* Allow stacks to be updated without forcing the user to re-provide all parameters (https://bugs.launchpad.net/heat/+bug/1224828)
* Stack update, allow retry from failed states (https://blueprints.launchpad.net/heat/+spec/update-failure-recovery)
* Stack update, rolling updates (canary deployments etc) (https://blueprints.launchpad.net/heat/+spec/rolling-updates)
* Stack update, enable cancelling in-progress update (e.g to pause or rollback) (https://blueprints.launchpad.net/heat/+spec/cancel-update-stack)
* Possibly allow inline specification of provider resources, e.g have a resource which generates a heat template, then refer to it, e.g like type: {get_attr: [SomeResource, template]} (''may not be required by Tuskar'')
* nested resource templates
* Stack preview (preview what would happen via stack-create) (https://blueprints.launchpad.net/heat/+spec/preview-stack) (''may not be required for Juno'')
* Stack check (sync state of stack with the real state of underlying resources, e.g persist out-of-band failures in stack resource states) (https://blueprints.launchpad.net/heat/+spec/stack-check) (''may not be required for Juno'')
* Stack converge - "fixes" stack and returns to known state (https://blueprints.launchpad.net/heat/+spec/stack-convergence) (''may not be required for Juno'')

==== TripleO ====

* update Heat templates in TripleO for: HOT, provider resources, software config

==== Tuskar ====

* provide default templates for default roles (these will be wrapped in ProviderResources)
* construct an overcloud template that references the default roles through ProviderResources
* ensure constructed templates define the appropriate ResourceAttributes to be queried through the UI/CLI
* given a Heat template constructed in this way, parse it in such a way as to retrieve the role specification and Heat parameters
* rebuild Tuskar to save and retrieve Heat templates from Swift
* update CLI as necessary

==== TripleO-UI ====

* update stack queries to take advantage Heat ResourceAttributes (make sure information is gotten through Heat)
* update deployment workflow

== Custom Roles ==

Although default, predefined roles are the immediate goal, it would be nice to also allow users to define their own roles. To do so, they would specify their own list of elements. Tuskar would then use that information to call out to diskimage-builder to create a custom image matching the role; and it would create a custom Heat template for that role that the master overcloud template could then use.

The remainder of the workflow is the same as with default roles.

==== TripleO ====

* given an image element, return the list of Heat parameters that it needs

==== Tuskar ====

* given a role specification, use diskimage-builder to construct a matching image (derived from the role's image elements)
* given a role specification, return the list of Heat parameters that it needs (derived from the role's image elements)
* given a role specification and its Heat parameters, construct a Heat template for that role that meets those specifications

==== TripleO-UI ====

* create custom role workflow

== High Availability ==

One of TripleO's top priorities for Juno is to allow the deployment of a High-Availability (HA) overcloud. We would like to extend Tuskar to ensure that it can be used to deploy a HA overcloud as well.

==== TripleO ====

* Deploy HA Overcloud
:* glusterfs
:* pacemaker, corosync
:* neutron (?)
:* heat-engine A/A
:* qpid proton (assuming amqp 1.0 have merged into oslo.messaging and oslo.messaging have merged in each core project. If not, will use rabbitmq)
:* etc etc

==== Tuskar ====

* allow the generation of Heat templates that support HA

==== TripleO-UI ====

* deployment workflow support for HA architecture

== Auto-Scaling ==

Having the option for an auto-scaling cloud deployment would be greatly appealing to many users. Heat is actively working on auto-scaling support, as are other projects.

==== Ceilometer ====

* Inhibit autoscaling during stack abandon/adopt (quiesce and revitalize)

==== Heat ====

* hooks to do cleanup on scale-down (e.g host evacuation etc) (https://blueprints.launchpad.net/heat/+spec/update-hooks)
* choose victim on scale-down, or specify strategy for choosing (e.g oldest first or newest first) (https://blueprints.launchpad.net/heat/+spec/autoscaling-parameters)
* support complex conditionals when choosing victim on scale-down (e.g get notification or poll metric via ceilometer related to occupancy or other application metrics); possibly handled by above, if we can get ceilometer to pass us appropriate data when signalling the scaling policy, TBC (''may not be required for Juno'')
* Method to inhibit autoscaling/alarms during abandon/adopt (and suspend/resume?)

==== Tuskar ====

* allow the generation of Heat templates that support auto-scaling

==== TripleO-UI ====

* update deployment workflow to include options that allow an auto-scaled overcloud deployment

== Node Management (Ironic) ==

We would like to switch over to using Ironic in the near future, as there are a host of features that would depend upon it.

==== Ironic ====

* Ironic graduation
:* CI jobs
:* Nova driver
:* Serial console
:* Migration path
:* User documentation

* Autodiscovery of nodes
* Ceilometer
* Tagging
* scalability

==== Nova ====

* create a nova filter for exact matches to Ironic nodes (including all node metadata) (https://review.openstack.org/#/c/83728/)

==== Tuskar ====

* use exact match filter when deploying overcloud

==== TripleO-UI ====

* added node tag values to flavor extra_specs

== Metric Graphs ==

Data visualization is a key part of maintaining a cloud. We would like to start integrating Ceilometer usage into Tuskar.

==== Ceilometer ====

* Combine samples for different meters in a transformer to produce a single derived meter
* Rollup of course-grained statistics for UI queries
* Configurable data retention based on rollups
* Overarching "health" metric for nodes
* Ceilometer native auth for alarm notifications (and possibly metrics in future) (https://blueprints.launchpad.net/ceilometer/+spec/trust-alarm-notifier)
* Eliminate central agent SPoF
* SNMP batch mode, one bulk command per node per polling cycle

For additional data:

* Acquire hardware-oriented metrics via IPMI (e.g., voltage, fan speeds, etc.)
* Keystone v3 usage would avoid IPMI credentials; allowing pollster-style interaction
* Look into consistent hashing; see if it can be reused in ceilometer -- though it requires stateful DB

==== Ironic ====

* Add a periodic task to send hardware sensor data to ceilometer (https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer)

==== TripleO ====

* update undercloud images to allow for the monitoring of hardware (setup Central Agent for polling all hardware)

==== Tuskar ====

* add SNMP agents to overcloud images

==== TripleO-UI ====

* Add Ceilometer-based graphs and metric data

== User Interfaces ==

This is a general category intended to encapsulate work needed in the UI and CLI.

==== Horizon ====

* separate horizon from openstack-dashboard
* test the replacement of lesscpy with pyScss
* improve error handling so that messages are less generic
* additional work on the plugin architecture to support dynamic hardware-specific views

==== Tuskar-CLI ====

* create a tuskar-cli plugin for OpenStackClient

==== TripleO-UI ====

* increase the modularity of views
* investigate usage of Heat UI components in Horizon (for example, parameter form building)
* create a mechanism for asynchronous communication

TripleO/TuskarJunoPlanning

2014-04-01T14:05:10Z

Tzumainn: /* Heat */

== Overview ==

This planning document is born from discussions from the TripleO mid-cycle Icehouse meetup in Sunnyvale ([[TripleO/TuskarJunoInitialDiscussion]], [https://etherpad.openstack.org/p/openstack-management-features OpenStack Management Features]). The ideas iterated there were then individually fleshed out and detailed, with much input coming from conversations with other OpenStack projects.

Our principal concerns duing the Juno cycle are:

* integrating further with other OpenStack services, using their capabilities to enhance our TripleO management experience
* ensuring that Tuskar does not try to implement functionality that is better located in other projects

This document details our high-level goals for Juno. It does so at multiple levels; for each we provide:

* a description of the goal
* a list of project requirements and/or blueprints needed

== Cloud Service Representation ==

A cloud service represents a cloud function - provisioning service, storage service, message broker, database server, etc. A cloud service is fulfilled by a cloud service element; for example, a user can fulfill the message broker cloud service by either choosing the qpid-server element or the rabbitmq-server element.

With the cloud service concept in play, overcloud roles are updated as follows: instead of being associated with images, they are associated with a list of cloud service elements. This provides greater flexibility for the Tuskar user when designing the scalable components of a cloud. For example, instead of being limited to a Controller role, the user can separate out the network components of that role into a Network role and scale it individually.

[[File:Tuskar-service-model.png|Tuskar Service Model]]

For Juno, Tuskar will provide role defaults or suggestions corresponding to current default roles, as well as an "All-in-One" role. Each default role will be automatically associated with a list of cloud service elements and a pre-created image. Later iterations of Tuskar will allow for more user customization in this area.

If possible, we would also like to support customized roles that specify their own elements. This would require the development of additional TripleO features as described in the next section.

==== Heat ====

* Diskimage builder resource (question raised wrt ability to spawn VM to host it in seed/undercloud), also OS::GlanceImageUploader resource (''may not be required for Juno'')

==== Tuskar ====

* ensure existence of default images
* create default roles, each associated with a list of elements, an image, and a Heat template

==== TripleO-UI ====

* update deployment workflow to accomodate cloud services

== Overcloud Planning and Deployment ==

In Icehouse, the planning stage of overcloud deployment is represented by data stored in Tuskar database tables. For Juno, we would like to remove the database from Tuskar. Instead, the planning stage of a deployment will be represented by the full Heat template that would be used to deploy it. Since Heat does not intend to be a template store, this template will be stored in Swift instead. When the overcloud is ready to be deployed, the Tuskar service will pull the template out of Swift.

[[File:tuskar-arch-juno.png|Tuskar Architecture]]

Once an overcloud is deployed, all Tuskar interactions with that overcloud should be done through Heat. This includes queries about running Nova instances and relevant Ironic nodes.

==== Heat ====

* Allow stacks to be updated without forcing the user to re-provide all parameters (https://bugs.launchpad.net/heat/+bug/1224828)
* Stack update, allow retry from failed states (https://blueprints.launchpad.net/heat/+spec/update-failure-recovery)
* Stack update, rolling updates (canary deployments etc) (https://blueprints.launchpad.net/heat/+spec/rolling-updates)
* Stack update, enable cancelling in-progress update (e.g to pause or rollback) (https://blueprints.launchpad.net/heat/+spec/cancel-update-stack)
* Possibly allow inline specification of provider resources, e.g have a resource which generates a heat template, then refer to it, e.g like type: {get_attr: [SomeResource, template]} (''may not be required by Tuskar'')
* nested resource templates
* Stack preview (preview what would happen via stack-create) (https://blueprints.launchpad.net/heat/+spec/preview-stack) (''may not be required for Juno'')
* Stack check (sync state of stack with the real state of underlying resources, e.g persist out-of-band failures in stack resource states) (https://blueprints.launchpad.net/heat/+spec/stack-check) (''may not be required for Juno'')
* Stack converge - "fixes" stack and returns to known state (https://blueprints.launchpad.net/heat/+spec/stack-convergence) (''may not be required for Juno'')

==== TripleO ====

* update Heat templates in TripleO for: HOT, provider resources, software config

==== Tuskar ====

* provide default templates for default roles (these will be wrapped in ProviderResources)
* construct an overcloud template that references the default roles through ProviderResources
* ensure constructed templates define the appropriate ResourceAttributes to be queried through the UI/CLI
* given a Heat template constructed in this way, parse it in such a way as to retrieve the role specification and Heat parameters
* rebuild Tuskar to save and retrieve Heat templates from Swift
* update CLI as necessary

==== TripleO-UI ====

* update stack queries to take advantage Heat ResourceAttributes (make sure information is gotten through Heat)
* update deployment workflow

== Custom Roles ==

Although default, predefined roles are the immediate goal, it would be nice to also allow users to define their own roles. To do so, they would specify their own list of elements. Tuskar would then use that information to call out to diskimage-builder to create a custom image matching the role; and it would create a custom Heat template for that role that the master overcloud template could then use.

The remainder of the workflow is the same as with default roles.

==== TripleO ====

* given an image element, return the list of Heat parameters that it needs

==== Tuskar ====

* given a role specification, use diskimage-builder to construct a matching image (derived from the role's image elements)
* given a role specification, return the list of Heat parameters that it needs (derived from the role's image elements)
* given a role specification and its Heat parameters, construct a Heat template for that role that meets those specifications

==== TripleO-UI ====

* create custom role workflow

== High Availability ==

One of TripleO's top priorities for Juno is to allow the deployment of a High-Availability (HA) overcloud. We would like to extend Tuskar to ensure that it can be used to deploy a HA overcloud as well.

==== TripleO ====

* Deploy HA Overcloud
:* glusterfs
:* pacemaker, corosync
:* neutron (?)
:* heat-engine A/A
:* qpid proton (assuming amqp 1.0 have merged into oslo.messaging and oslo.messaging have merged in each core project. If not, will use rabbitmq)
:* etc etc

==== Tuskar ====

* allow the generation of Heat templates that support HA

==== TripleO-UI ====

* deployment workflow support for HA architecture

== Auto-Scaling ==

Having the option for an auto-scaling cloud deployment would be greatly appealing to many users. Heat is actively working on auto-scaling support, as are other projects.

==== Ceilometer ====

* Inhibit autoscaling during stack abandon/adopt (quiesce and revitalize)

==== Heat ====

* hooks to do cleanup on scale-down (e.g host evacuation etc) (https://blueprints.launchpad.net/heat/+spec/update-hooks)
* choose victim on scale-down, or specify strategy for choosing (e.g oldest first or newest first) (https://blueprints.launchpad.net/heat/+spec/autoscaling-parameters)
* support complex conditionals when choosing victim on scale-down (e.g get notification or poll metric via ceilometer related to occupancy or other application metrics); possibly handled by above, if we can get ceilometer to pass us appropriate data when signalling the scaling policy, TBC (''may not be required for Juno'')
* Method to inhibit autoscaling/alarms during abandon/adopt (and suspend/resume?)

==== TripleO ====

* update image elements to support auto-scaling

==== Tuskar ====

* allow the generation of Heat templates that support auto-scaling

==== TripleO-UI ====

* update deployment workflow to include options that allow an auto-scaled overcloud deployment

== Node Management (Ironic) ==

We would like to switch over to using Ironic in the near future, as there are a host of features that would depend upon it.

==== Ironic ====

* Ironic graduation
:* CI jobs
:* Nova driver
:* Serial console
:* Migration path
:* User documentation

* Autodiscovery of nodes
* Ceilometer
* Tagging
* scalability

==== Nova ====

* create a nova filter for exact matches to Ironic nodes (including all node metadata) (https://review.openstack.org/#/c/83728/)

==== Tuskar ====

* use exact match filter when deploying overcloud

==== TripleO-UI ====

* added node tag values to flavor extra_specs

== Metric Graphs ==

Data visualization is a key part of maintaining a cloud. We would like to start integrating Ceilometer usage into Tuskar.

==== Ceilometer ====

* Combine samples for different meters in a transformer to produce a single derived meter
* Rollup of course-grained statistics for UI queries
* Configurable data retention based on rollups
* Overarching "health" metric for nodes
* Ceilometer native auth for alarm notifications (and possibly metrics in future) (https://blueprints.launchpad.net/ceilometer/+spec/trust-alarm-notifier)
* Eliminate central agent SPoF
* SNMP batch mode, one bulk command per node per polling cycle

For additional data:

* Acquire hardware-oriented metrics via IPMI (e.g., voltage, fan speeds, etc.)
* Keystone v3 usage would avoid IPMI credentials; allowing pollster-style interaction
* Look into consistent hashing; see if it can be reused in ceilometer -- though it requires stateful DB

==== Ironic ====

* Add a periodic task to send hardware sensor data to ceilometer (https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer)

==== TripleO ====

* update undercloud images to allow for the monitoring of hardware (setup Central Agent for polling all hardware)

==== Tuskar ====

* add SNMP agents to overcloud images

==== TripleO-UI ====

* Add Ceilometer-based graphs and metric data

== User Interfaces ==

This is a general category intended to encapsulate work needed in the UI and CLI.

==== Horizon ====

* separate horizon from openstack-dashboard
* test the replacement of lesscpy with pyScss
* improve error handling so that messages are less generic
* additional work on the plugin architecture to support dynamic hardware-specific views

==== Tuskar-CLI ====

* create a tuskar-cli plugin for OpenStackClient

==== TripleO-UI ====

* increase the modularity of views
* investigate usage of Heat UI components in Horizon (for example, parameter form building)
* create a mechanism for asynchronous communication

TripleO/TuskarJunoPlanning

2014-03-31T16:30:27Z

Tzumainn: /* Metric Graphs */

== Overview ==

This planning document is born from discussions from the TripleO mid-cycle Icehouse meetup in Sunnyvale ([[TripleO/TuskarJunoInitialDiscussion]], [https://etherpad.openstack.org/p/openstack-management-features OpenStack Management Features]). The ideas iterated there were then individually fleshed out and detailed, with much input coming from conversations with other OpenStack projects.

Our principal concerns duing the Juno cycle are:

* integrating further with other OpenStack services, using their capabilities to enhance our TripleO management experience
* ensuring that Tuskar does not try to implement functionality that is better located in other projects

This document details our high-level goals for Juno. It does so at multiple levels; for each we provide:

* a description of the goal
* a list of project requirements and/or blueprints needed

== Cloud Service Representation ==

A cloud service represents a cloud function - provisioning service, storage service, message broker, database server, etc. A cloud service is fulfilled by a cloud service element; for example, a user can fulfill the message broker cloud service by either choosing the qpid-server element or the rabbitmq-server element.

With the cloud service concept in play, overcloud roles are updated as follows: instead of being associated with images, they are associated with a list of cloud service elements. This provides greater flexibility for the Tuskar user when designing the scalable components of a cloud. For example, instead of being limited to a Controller role, the user can separate out the network components of that role into a Network role and scale it individually.

[[File:Tuskar-service-model.png|Tuskar Service Model]]

For Juno, Tuskar will provide role defaults or suggestions corresponding to current default roles, as well as an "All-in-One" role. Each default role will be automatically associated with a list of cloud service elements and a pre-created image. Later iterations of Tuskar will allow for more user customization in this area.

If possible, we would also like to support customized roles that specify their own elements. This would require the development of additional TripleO features as described in the next section.

==== Heat ====

* Diskimage builder resource (question raised wrt ability to spawn VM to host it in seed/undercloud), also OS::GlanceImageUploader resource (''may not be required for Juno'')

==== Tuskar ====

* ensure existence of default images
* create default roles, each associated with a list of elements, an image, and a Heat template

==== TripleO-UI ====

* update deployment workflow to accomodate cloud services

== Overcloud Planning and Deployment ==

In Icehouse, the planning stage of overcloud deployment is represented by data stored in Tuskar database tables. For Juno, we would like to remove the database from Tuskar. Instead, the planning stage of a deployment will be represented by the full Heat template that would be used to deploy it. Since Heat does not intend to be a template store, this template will be stored in Swift instead. When the overcloud is ready to be deployed, the Tuskar service will pull the template out of Swift.

[[File:tuskar-arch-juno.png|Tuskar Architecture]]

Once an overcloud is deployed, all Tuskar interactions with that overcloud should be done through Heat. This includes queries about running Nova instances and relevant Ironic nodes.

==== Heat ====

* Allow stacks to be updated without forcing the user to re-provide all parameters (https://bugs.launchpad.net/heat/+bug/1224828)
* Stack update, allow retry from failed states (https://blueprints.launchpad.net/heat/+spec/update-failure-recovery)
* Stack update, rolling updates (canary deployments etc) (https://blueprints.launchpad.net/heat/+spec/rolling-updates) (''may not be required by Tuskar'')
* Stack update, enable cancelling in-progress update (e.g to pause or rollback) (https://blueprints.launchpad.net/heat/+spec/cancel-update-stack)
* Possibly allow inline specification of provider resources, e.g have a resource which generates a heat template, then refer to it, e.g like type: {get_attr: [SomeResource, template]} (''may not be required by Tuskar'')
* nested resource templates (''may not be required for Juno'')
* Stack preview (preview what would happen via stack-create) (https://blueprints.launchpad.net/heat/+spec/preview-stack) (''may not be required for Juno'')
* Stack check (sync state of stack with the real state of underlying resources, e.g persist out-of-band failures in stack resource states) (https://blueprints.launchpad.net/heat/+spec/stack-check) (''may not be required for Juno'')
* Stack converge - "fixes" stack and returns to known state (https://blueprints.launchpad.net/heat/+spec/stack-convergence) (''may not be required for Juno'')

==== TripleO ====

* update Heat templates in TripleO for: HOT, provider resources, software config

==== Tuskar ====

* provide default templates for default roles (these will be wrapped in ProviderResources)
* construct an overcloud template that references the default roles through ProviderResources
* ensure constructed templates define the appropriate ResourceAttributes to be queried through the UI/CLI
* given a Heat template constructed in this way, parse it in such a way as to retrieve the role specification and Heat parameters
* rebuild Tuskar to save and retrieve Heat templates from Swift
* update CLI as necessary

==== TripleO-UI ====

* update stack queries to take advantage Heat ResourceAttributes (make sure information is gotten through Heat)
* update deployment workflow

== Custom Roles ==

Although default, predefined roles are the immediate goal, it would be nice to also allow users to define their own roles. To do so, they would specify their own list of elements. Tuskar would then use that information to call out to diskimage-builder to create a custom image matching the role; and it would create a custom Heat template for that role that the master overcloud template could then use.

The remainder of the workflow is the same as with default roles.

==== TripleO ====

* given an image element, return the list of Heat parameters that it needs

==== Tuskar ====

* given a role specification, use diskimage-builder to construct a matching image (derived from the role's image elements)
* given a role specification, return the list of Heat parameters that it needs (derived from the role's image elements)
* given a role specification and its Heat parameters, construct a Heat template for that role that meets those specifications

==== TripleO-UI ====

* create custom role workflow

== High Availability ==

One of TripleO's top priorities for Juno is to allow the deployment of a High-Availability (HA) overcloud. We would like to extend Tuskar to ensure that it can be used to deploy a HA overcloud as well.

==== TripleO ====

* Deploy HA Overcloud
:* glusterfs
:* pacemaker, corosync
:* neutron (?)
:* heat-engine A/A
:* qpid proton (assuming amqp 1.0 have merged into oslo.messaging and oslo.messaging have merged in each core project. If not, will use rabbitmq)
:* etc etc

==== Tuskar ====

* allow the generation of Heat templates that support HA

==== TripleO-UI ====

* deployment workflow support for HA architecture

== Auto-Scaling ==

Having the option for an auto-scaling cloud deployment would be greatly appealing to many users. Heat is actively working on auto-scaling support, as are other projects.

==== Ceilometer ====

* Inhibit autoscaling during stack abandon/adopt (quiesce and revitalize)

==== Heat ====

* hooks to do cleanup on scale-down (e.g host evacuation etc) (https://blueprints.launchpad.net/heat/+spec/update-hooks)
* choose victim on scale-down, or specify strategy for choosing (e.g oldest first or newest first) (https://blueprints.launchpad.net/heat/+spec/autoscaling-parameters)
* support complex conditionals when choosing victim on scale-down (e.g get notification or poll metric via ceilometer related to occupancy or other application metrics); possibly handled by above, if we can get ceilometer to pass us appropriate data when signalling the scaling policy, TBC (''may not be required for Juno'')
* Method to inhibit autoscaling/alarms during abandon/adopt (and suspend/resume?)

==== TripleO ====

* update image elements to support auto-scaling

==== Tuskar ====

* allow the generation of Heat templates that support auto-scaling

==== TripleO-UI ====

* update deployment workflow to include options that allow an auto-scaled overcloud deployment

== Node Management (Ironic) ==

We would like to switch over to using Ironic in the near future, as there are a host of features that would depend upon it.

==== Ironic ====

* Ironic graduation
:* CI jobs
:* Nova driver
:* Serial console
:* Migration path
:* User documentation

* Autodiscovery of nodes
* Ceilometer
* Tagging
* scalability

==== Nova ====

* create a nova filter for exact matches to Ironic nodes (including all node metadata) (https://review.openstack.org/#/c/83728/)

==== Tuskar ====

* use exact match filter when deploying overcloud

==== TripleO-UI ====

* added node tag values to flavor extra_specs

== Metric Graphs ==

Data visualization is a key part of maintaining a cloud. We would like to start integrating Ceilometer usage into Tuskar.

==== Ceilometer ====

* Combine samples for different meters in a transformer to produce a single derived meter
* Rollup of course-grained statistics for UI queries
* Configurable data retention based on rollups
* Overarching "health" metric for nodes
* Ceilometer native auth for alarm notifications (and possibly metrics in future) (https://blueprints.launchpad.net/ceilometer/+spec/trust-alarm-notifier)
* Eliminate central agent SPoF
* SNMP batch mode, one bulk command per node per polling cycle

For additional data:

* Acquire hardware-oriented metrics via IPMI (e.g., voltage, fan speeds, etc.)
* Keystone v3 usage would avoid IPMI credentials; allowing pollster-style interaction
* Look into consistent hashing; see if it can be reused in ceilometer -- though it requires stateful DB

==== Ironic ====

* Add a periodic task to send hardware sensor data to ceilometer (https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer)

==== TripleO ====

* update undercloud images to allow for the monitoring of hardware (setup Central Agent for polling all hardware)

==== Tuskar ====

* add SNMP agents to overcloud images

==== TripleO-UI ====

* Add Ceilometer-based graphs and metric data

== User Interfaces ==

This is a general category intended to encapsulate work needed in the UI and CLI.

==== Horizon ====

* separate horizon from openstack-dashboard
* test the replacement of lesscpy with pyScss
* improve error handling so that messages are less generic
* additional work on the plugin architecture to support dynamic hardware-specific views

==== Tuskar-CLI ====

* create a tuskar-cli plugin for OpenStackClient

==== TripleO-UI ====

* increase the modularity of views
* investigate usage of Heat UI components in Horizon (for example, parameter form building)
* create a mechanism for asynchronous communication

TripleO/TuskarJunoPlanning

2014-03-31T16:26:55Z

Tzumainn: /* Tuskar */

== Overview ==

This planning document is born from discussions from the TripleO mid-cycle Icehouse meetup in Sunnyvale ([[TripleO/TuskarJunoInitialDiscussion]], [https://etherpad.openstack.org/p/openstack-management-features OpenStack Management Features]). The ideas iterated there were then individually fleshed out and detailed, with much input coming from conversations with other OpenStack projects.

Our principal concerns duing the Juno cycle are:

* integrating further with other OpenStack services, using their capabilities to enhance our TripleO management experience
* ensuring that Tuskar does not try to implement functionality that is better located in other projects

This document details our high-level goals for Juno. It does so at multiple levels; for each we provide:

* a description of the goal
* a list of project requirements and/or blueprints needed

== Cloud Service Representation ==

A cloud service represents a cloud function - provisioning service, storage service, message broker, database server, etc. A cloud service is fulfilled by a cloud service element; for example, a user can fulfill the message broker cloud service by either choosing the qpid-server element or the rabbitmq-server element.

With the cloud service concept in play, overcloud roles are updated as follows: instead of being associated with images, they are associated with a list of cloud service elements. This provides greater flexibility for the Tuskar user when designing the scalable components of a cloud. For example, instead of being limited to a Controller role, the user can separate out the network components of that role into a Network role and scale it individually.

[[File:Tuskar-service-model.png|Tuskar Service Model]]

For Juno, Tuskar will provide role defaults or suggestions corresponding to current default roles, as well as an "All-in-One" role. Each default role will be automatically associated with a list of cloud service elements and a pre-created image. Later iterations of Tuskar will allow for more user customization in this area.

If possible, we would also like to support customized roles that specify their own elements. This would require the development of additional TripleO features as described in the next section.

==== Heat ====

* Diskimage builder resource (question raised wrt ability to spawn VM to host it in seed/undercloud), also OS::GlanceImageUploader resource (''may not be required for Juno'')

==== Tuskar ====

* ensure existence of default images
* create default roles, each associated with a list of elements, an image, and a Heat template

==== TripleO-UI ====

* update deployment workflow to accomodate cloud services

== Overcloud Planning and Deployment ==

In Icehouse, the planning stage of overcloud deployment is represented by data stored in Tuskar database tables. For Juno, we would like to remove the database from Tuskar. Instead, the planning stage of a deployment will be represented by the full Heat template that would be used to deploy it. Since Heat does not intend to be a template store, this template will be stored in Swift instead. When the overcloud is ready to be deployed, the Tuskar service will pull the template out of Swift.

[[File:tuskar-arch-juno.png|Tuskar Architecture]]

Once an overcloud is deployed, all Tuskar interactions with that overcloud should be done through Heat. This includes queries about running Nova instances and relevant Ironic nodes.

==== Heat ====

* Allow stacks to be updated without forcing the user to re-provide all parameters (https://bugs.launchpad.net/heat/+bug/1224828)
* Stack update, allow retry from failed states (https://blueprints.launchpad.net/heat/+spec/update-failure-recovery)
* Stack update, rolling updates (canary deployments etc) (https://blueprints.launchpad.net/heat/+spec/rolling-updates) (''may not be required by Tuskar'')
* Stack update, enable cancelling in-progress update (e.g to pause or rollback) (https://blueprints.launchpad.net/heat/+spec/cancel-update-stack)
* Possibly allow inline specification of provider resources, e.g have a resource which generates a heat template, then refer to it, e.g like type: {get_attr: [SomeResource, template]} (''may not be required by Tuskar'')
* nested resource templates (''may not be required for Juno'')
* Stack preview (preview what would happen via stack-create) (https://blueprints.launchpad.net/heat/+spec/preview-stack) (''may not be required for Juno'')
* Stack check (sync state of stack with the real state of underlying resources, e.g persist out-of-band failures in stack resource states) (https://blueprints.launchpad.net/heat/+spec/stack-check) (''may not be required for Juno'')
* Stack converge - "fixes" stack and returns to known state (https://blueprints.launchpad.net/heat/+spec/stack-convergence) (''may not be required for Juno'')

==== TripleO ====

* update Heat templates in TripleO for: HOT, provider resources, software config

==== Tuskar ====

* provide default templates for default roles (these will be wrapped in ProviderResources)
* construct an overcloud template that references the default roles through ProviderResources
* ensure constructed templates define the appropriate ResourceAttributes to be queried through the UI/CLI
* given a Heat template constructed in this way, parse it in such a way as to retrieve the role specification and Heat parameters
* rebuild Tuskar to save and retrieve Heat templates from Swift
* update CLI as necessary

==== TripleO-UI ====

* update stack queries to take advantage Heat ResourceAttributes (make sure information is gotten through Heat)
* update deployment workflow

== Custom Roles ==

Although default, predefined roles are the immediate goal, it would be nice to also allow users to define their own roles. To do so, they would specify their own list of elements. Tuskar would then use that information to call out to diskimage-builder to create a custom image matching the role; and it would create a custom Heat template for that role that the master overcloud template could then use.

The remainder of the workflow is the same as with default roles.

==== TripleO ====

* given an image element, return the list of Heat parameters that it needs

==== Tuskar ====

* given a role specification, use diskimage-builder to construct a matching image (derived from the role's image elements)
* given a role specification, return the list of Heat parameters that it needs (derived from the role's image elements)
* given a role specification and its Heat parameters, construct a Heat template for that role that meets those specifications

==== TripleO-UI ====

* create custom role workflow

== High Availability ==

One of TripleO's top priorities for Juno is to allow the deployment of a High-Availability (HA) overcloud. We would like to extend Tuskar to ensure that it can be used to deploy a HA overcloud as well.

==== TripleO ====

* Deploy HA Overcloud
:* glusterfs
:* pacemaker, corosync
:* neutron (?)
:* heat-engine A/A
:* qpid proton (assuming amqp 1.0 have merged into oslo.messaging and oslo.messaging have merged in each core project. If not, will use rabbitmq)
:* etc etc

==== Tuskar ====

* allow the generation of Heat templates that support HA

==== TripleO-UI ====

* deployment workflow support for HA architecture

== Auto-Scaling ==

Having the option for an auto-scaling cloud deployment would be greatly appealing to many users. Heat is actively working on auto-scaling support, as are other projects.

==== Ceilometer ====

* Inhibit autoscaling during stack abandon/adopt (quiesce and revitalize)

==== Heat ====

* hooks to do cleanup on scale-down (e.g host evacuation etc) (https://blueprints.launchpad.net/heat/+spec/update-hooks)
* choose victim on scale-down, or specify strategy for choosing (e.g oldest first or newest first) (https://blueprints.launchpad.net/heat/+spec/autoscaling-parameters)
* support complex conditionals when choosing victim on scale-down (e.g get notification or poll metric via ceilometer related to occupancy or other application metrics); possibly handled by above, if we can get ceilometer to pass us appropriate data when signalling the scaling policy, TBC (''may not be required for Juno'')
* Method to inhibit autoscaling/alarms during abandon/adopt (and suspend/resume?)

==== TripleO ====

* update image elements to support auto-scaling

==== Tuskar ====

* allow the generation of Heat templates that support auto-scaling

==== TripleO-UI ====

* update deployment workflow to include options that allow an auto-scaled overcloud deployment

== Node Management (Ironic) ==

We would like to switch over to using Ironic in the near future, as there are a host of features that would depend upon it.

==== Ironic ====

* Ironic graduation
:* CI jobs
:* Nova driver
:* Serial console
:* Migration path
:* User documentation

* Autodiscovery of nodes
* Ceilometer
* Tagging
* scalability

==== Nova ====

* create a nova filter for exact matches to Ironic nodes (including all node metadata) (https://review.openstack.org/#/c/83728/)

==== Tuskar ====

* use exact match filter when deploying overcloud

==== TripleO-UI ====

* added node tag values to flavor extra_specs

== Metric Graphs ==

Data visualization is a key part of maintaining a cloud. We would like to start integrating Ceilometer usage into Tuskar.

==== Ceilometer ====

* Combine samples for different meters in a transformer to produce a single derived meter
* Rollup of course-grained statistics for UI queries
* Configurable data retention based on rollups
* Overarching "health" metric for nodes
* Ceilometer native auth for alarm notifications (and possibly metrics in future) (https://blueprints.launchpad.net/ceilometer/+spec/trust-alarm-notifier)
* Eliminate central agent SPoF
* SNMP batch mode, one bulk command per node per polling cycle

For additional data:

* Acquire hardware-oriented metrics via IPMI (e.g., voltage, fan speeds, etc.)
* Keystone v3 usage would avoid IPMI credentials; allowing pollster-style interaction
* Look into consistent hashing; see if it can be reused in ceilometer -- though it requires stateful DB

==== Ironic ====

* Add a periodic task to send hardware sensor data to ceilometer (https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer)

==== TripleO ====

* update undercloud images to allow for the monitoring of hardware

==== Tuskar ====

* add appropriate Ceilometer agents to generated Heat templates
* add SNMP agents to overcloud images

==== TripleO-UI ====

* Add Ceilometer-based graphs and metric data

== User Interfaces ==

This is a general category intended to encapsulate work needed in the UI and CLI.

==== Horizon ====

* separate horizon from openstack-dashboard
* test the replacement of lesscpy with pyScss
* improve error handling so that messages are less generic
* additional work on the plugin architecture to support dynamic hardware-specific views

==== Tuskar-CLI ====

* create a tuskar-cli plugin for OpenStackClient

==== TripleO-UI ====

* increase the modularity of views
* investigate usage of Heat UI components in Horizon (for example, parameter form building)
* create a mechanism for asynchronous communication

TripleO/TuskarJunoPlanning

2014-03-31T16:25:14Z

Tzumainn: /* Metric Graphs */

== Overview ==

This planning document is born from discussions from the TripleO mid-cycle Icehouse meetup in Sunnyvale ([[TripleO/TuskarJunoInitialDiscussion]], [https://etherpad.openstack.org/p/openstack-management-features OpenStack Management Features]). The ideas iterated there were then individually fleshed out and detailed, with much input coming from conversations with other OpenStack projects.

Our principal concerns duing the Juno cycle are:

* integrating further with other OpenStack services, using their capabilities to enhance our TripleO management experience
* ensuring that Tuskar does not try to implement functionality that is better located in other projects

This document details our high-level goals for Juno. It does so at multiple levels; for each we provide:

* a description of the goal
* a list of project requirements and/or blueprints needed

== Cloud Service Representation ==

A cloud service represents a cloud function - provisioning service, storage service, message broker, database server, etc. A cloud service is fulfilled by a cloud service element; for example, a user can fulfill the message broker cloud service by either choosing the qpid-server element or the rabbitmq-server element.

With the cloud service concept in play, overcloud roles are updated as follows: instead of being associated with images, they are associated with a list of cloud service elements. This provides greater flexibility for the Tuskar user when designing the scalable components of a cloud. For example, instead of being limited to a Controller role, the user can separate out the network components of that role into a Network role and scale it individually.

[[File:Tuskar-service-model.png|Tuskar Service Model]]

For Juno, Tuskar will provide role defaults or suggestions corresponding to current default roles, as well as an "All-in-One" role. Each default role will be automatically associated with a list of cloud service elements and a pre-created image. Later iterations of Tuskar will allow for more user customization in this area.

If possible, we would also like to support customized roles that specify their own elements. This would require the development of additional TripleO features as described in the next section.

==== Heat ====

* Diskimage builder resource (question raised wrt ability to spawn VM to host it in seed/undercloud), also OS::GlanceImageUploader resource (''may not be required for Juno'')

==== Tuskar ====

* ensure existence of default images
* create default roles, each associated with a list of elements, an image, and a Heat template

==== TripleO-UI ====

* update deployment workflow to accomodate cloud services

== Overcloud Planning and Deployment ==

In Icehouse, the planning stage of overcloud deployment is represented by data stored in Tuskar database tables. For Juno, we would like to remove the database from Tuskar. Instead, the planning stage of a deployment will be represented by the full Heat template that would be used to deploy it. Since Heat does not intend to be a template store, this template will be stored in Swift instead. When the overcloud is ready to be deployed, the Tuskar service will pull the template out of Swift.

[[File:tuskar-arch-juno.png|Tuskar Architecture]]

Once an overcloud is deployed, all Tuskar interactions with that overcloud should be done through Heat. This includes queries about running Nova instances and relevant Ironic nodes.

==== Heat ====

* Allow stacks to be updated without forcing the user to re-provide all parameters (https://bugs.launchpad.net/heat/+bug/1224828)
* Stack update, allow retry from failed states (https://blueprints.launchpad.net/heat/+spec/update-failure-recovery)
* Stack update, rolling updates (canary deployments etc) (https://blueprints.launchpad.net/heat/+spec/rolling-updates) (''may not be required by Tuskar'')
* Stack update, enable cancelling in-progress update (e.g to pause or rollback) (https://blueprints.launchpad.net/heat/+spec/cancel-update-stack)
* Possibly allow inline specification of provider resources, e.g have a resource which generates a heat template, then refer to it, e.g like type: {get_attr: [SomeResource, template]} (''may not be required by Tuskar'')
* nested resource templates (''may not be required for Juno'')
* Stack preview (preview what would happen via stack-create) (https://blueprints.launchpad.net/heat/+spec/preview-stack) (''may not be required for Juno'')
* Stack check (sync state of stack with the real state of underlying resources, e.g persist out-of-band failures in stack resource states) (https://blueprints.launchpad.net/heat/+spec/stack-check) (''may not be required for Juno'')
* Stack converge - "fixes" stack and returns to known state (https://blueprints.launchpad.net/heat/+spec/stack-convergence) (''may not be required for Juno'')

==== TripleO ====

* update Heat templates in TripleO for: HOT, provider resources, software config

==== Tuskar ====

* provide default templates for default roles (these will be wrapped in ProviderResources)
* construct an overcloud template that references the default roles through ProviderResources
* ensure constructed templates define the appropriate ResourceAttributes to be queried through the UI/CLI
* given a Heat template constructed in this way, parse it in such a way as to retrieve the role specification and Heat parameters
* rebuild Tuskar to save and retrieve Heat templates from Swift
* update CLI as necessary

==== TripleO-UI ====

* update stack queries to take advantage Heat ResourceAttributes (make sure information is gotten through Heat)
* update deployment workflow

== Custom Roles ==

Although default, predefined roles are the immediate goal, it would be nice to also allow users to define their own roles. To do so, they would specify their own list of elements. Tuskar would then use that information to call out to diskimage-builder to create a custom image matching the role; and it would create a custom Heat template for that role that the master overcloud template could then use.

The remainder of the workflow is the same as with default roles.

==== TripleO ====

* given an image element, return the list of Heat parameters that it needs

==== Tuskar ====

* given a role specification, use diskimage-builder to construct a matching image (derived from the role's image elements)
* given a role specification, return the list of Heat parameters that it needs (derived from the role's image elements)
* given a role specification and its Heat parameters, construct a Heat template for that role that meets those specifications

==== TripleO-UI ====

* create custom role workflow

== High Availability ==

One of TripleO's top priorities for Juno is to allow the deployment of a High-Availability (HA) overcloud. We would like to extend Tuskar to ensure that it can be used to deploy a HA overcloud as well.

==== TripleO ====

* Deploy HA Overcloud
:* glusterfs
:* pacemaker, corosync
:* neutron (?)
:* heat-engine A/A
:* qpid proton (assuming amqp 1.0 have merged into oslo.messaging and oslo.messaging have merged in each core project. If not, will use rabbitmq)
:* etc etc

==== Tuskar ====

* allow the generation of Heat templates that support HA

==== TripleO-UI ====

* deployment workflow support for HA architecture

== Auto-Scaling ==

Having the option for an auto-scaling cloud deployment would be greatly appealing to many users. Heat is actively working on auto-scaling support, as are other projects.

==== Ceilometer ====

* Inhibit autoscaling during stack abandon/adopt (quiesce and revitalize)

==== Heat ====

* hooks to do cleanup on scale-down (e.g host evacuation etc) (https://blueprints.launchpad.net/heat/+spec/update-hooks)
* choose victim on scale-down, or specify strategy for choosing (e.g oldest first or newest first) (https://blueprints.launchpad.net/heat/+spec/autoscaling-parameters)
* support complex conditionals when choosing victim on scale-down (e.g get notification or poll metric via ceilometer related to occupancy or other application metrics); possibly handled by above, if we can get ceilometer to pass us appropriate data when signalling the scaling policy, TBC (''may not be required for Juno'')
* Method to inhibit autoscaling/alarms during abandon/adopt (and suspend/resume?)

==== TripleO ====

* update image elements to support auto-scaling

==== Tuskar ====

* allow the generation of Heat templates that support auto-scaling

==== TripleO-UI ====

* update deployment workflow to include options that allow an auto-scaled overcloud deployment

== Node Management (Ironic) ==

We would like to switch over to using Ironic in the near future, as there are a host of features that would depend upon it.

==== Ironic ====

* Ironic graduation
:* CI jobs
:* Nova driver
:* Serial console
:* Migration path
:* User documentation

* Autodiscovery of nodes
* Ceilometer
* Tagging
* scalability

==== Nova ====

* create a nova filter for exact matches to Ironic nodes (including all node metadata) (https://review.openstack.org/#/c/83728/)

==== Tuskar ====

* use exact match filter when deploying overcloud

==== TripleO-UI ====

* added node tag values to flavor extra_specs

== Metric Graphs ==

Data visualization is a key part of maintaining a cloud. We would like to start integrating Ceilometer usage into Tuskar.

==== Ceilometer ====

* Combine samples for different meters in a transformer to produce a single derived meter
* Rollup of course-grained statistics for UI queries
* Configurable data retention based on rollups
* Overarching "health" metric for nodes
* Ceilometer native auth for alarm notifications (and possibly metrics in future) (https://blueprints.launchpad.net/ceilometer/+spec/trust-alarm-notifier)
* Eliminate central agent SPoF
* SNMP batch mode, one bulk command per node per polling cycle

For additional data:

* Acquire hardware-oriented metrics via IPMI (e.g., voltage, fan speeds, etc.)
* Keystone v3 usage would avoid IPMI credentials; allowing pollster-style interaction
* Look into consistent hashing; see if it can be reused in ceilometer -- though it requires stateful DB

==== Ironic ====

* Add a periodic task to send hardware sensor data to ceilometer (https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer)

==== TripleO ====

* update undercloud images to allow for the monitoring of hardware

==== Tuskar ====

* add appropriate Ceilometer agents to generated Heat templates

==== TripleO-UI ====

* Add Ceilometer-based graphs and metric data

== User Interfaces ==

This is a general category intended to encapsulate work needed in the UI and CLI.

==== Horizon ====

* separate horizon from openstack-dashboard
* test the replacement of lesscpy with pyScss
* improve error handling so that messages are less generic
* additional work on the plugin architecture to support dynamic hardware-specific views

==== Tuskar-CLI ====

* create a tuskar-cli plugin for OpenStackClient

==== TripleO-UI ====

* increase the modularity of views
* investigate usage of Heat UI components in Horizon (for example, parameter form building)
* create a mechanism for asynchronous communication

TripleO/TuskarJunoPlanning

2014-03-31T16:18:50Z

Tzumainn: /* TripleO UI */

== Overview ==

This planning document is born from discussions from the TripleO mid-cycle Icehouse meetup in Sunnyvale ([[TripleO/TuskarJunoInitialDiscussion]], [https://etherpad.openstack.org/p/openstack-management-features OpenStack Management Features]). The ideas iterated there were then individually fleshed out and detailed, with much input coming from conversations with other OpenStack projects.

Our principal concerns duing the Juno cycle are:

* integrating further with other OpenStack services, using their capabilities to enhance our TripleO management experience
* ensuring that Tuskar does not try to implement functionality that is better located in other projects

This document details our high-level goals for Juno. It does so at multiple levels; for each we provide:

* a description of the goal
* a list of project requirements and/or blueprints needed

== Cloud Service Representation ==

A cloud service represents a cloud function - provisioning service, storage service, message broker, database server, etc. A cloud service is fulfilled by a cloud service element; for example, a user can fulfill the message broker cloud service by either choosing the qpid-server element or the rabbitmq-server element.

With the cloud service concept in play, overcloud roles are updated as follows: instead of being associated with images, they are associated with a list of cloud service elements. This provides greater flexibility for the Tuskar user when designing the scalable components of a cloud. For example, instead of being limited to a Controller role, the user can separate out the network components of that role into a Network role and scale it individually.

[[File:Tuskar-service-model.png|Tuskar Service Model]]

For Juno, Tuskar will provide role defaults or suggestions corresponding to current default roles, as well as an "All-in-One" role. Each default role will be automatically associated with a list of cloud service elements and a pre-created image. Later iterations of Tuskar will allow for more user customization in this area.

If possible, we would also like to support customized roles that specify their own elements. This would require the development of additional TripleO features as described in the next section.

==== Heat ====

* Diskimage builder resource (question raised wrt ability to spawn VM to host it in seed/undercloud), also OS::GlanceImageUploader resource (''may not be required for Juno'')

==== Tuskar ====

* ensure existence of default images
* create default roles, each associated with a list of elements, an image, and a Heat template

==== TripleO-UI ====

* update deployment workflow to accomodate cloud services

== Overcloud Planning and Deployment ==

In Icehouse, the planning stage of overcloud deployment is represented by data stored in Tuskar database tables. For Juno, we would like to remove the database from Tuskar. Instead, the planning stage of a deployment will be represented by the full Heat template that would be used to deploy it. Since Heat does not intend to be a template store, this template will be stored in Swift instead. When the overcloud is ready to be deployed, the Tuskar service will pull the template out of Swift.

[[File:tuskar-arch-juno.png|Tuskar Architecture]]

Once an overcloud is deployed, all Tuskar interactions with that overcloud should be done through Heat. This includes queries about running Nova instances and relevant Ironic nodes.

==== Heat ====

* Allow stacks to be updated without forcing the user to re-provide all parameters (https://bugs.launchpad.net/heat/+bug/1224828)
* Stack update, allow retry from failed states (https://blueprints.launchpad.net/heat/+spec/update-failure-recovery)
* Stack update, rolling updates (canary deployments etc) (https://blueprints.launchpad.net/heat/+spec/rolling-updates) (''may not be required by Tuskar'')
* Stack update, enable cancelling in-progress update (e.g to pause or rollback) (https://blueprints.launchpad.net/heat/+spec/cancel-update-stack)
* Possibly allow inline specification of provider resources, e.g have a resource which generates a heat template, then refer to it, e.g like type: {get_attr: [SomeResource, template]} (''may not be required by Tuskar'')
* nested resource templates (''may not be required for Juno'')
* Stack preview (preview what would happen via stack-create) (https://blueprints.launchpad.net/heat/+spec/preview-stack) (''may not be required for Juno'')
* Stack check (sync state of stack with the real state of underlying resources, e.g persist out-of-band failures in stack resource states) (https://blueprints.launchpad.net/heat/+spec/stack-check) (''may not be required for Juno'')
* Stack converge - "fixes" stack and returns to known state (https://blueprints.launchpad.net/heat/+spec/stack-convergence) (''may not be required for Juno'')

==== TripleO ====

* update Heat templates in TripleO for: HOT, provider resources, software config

==== Tuskar ====

* provide default templates for default roles (these will be wrapped in ProviderResources)
* construct an overcloud template that references the default roles through ProviderResources
* ensure constructed templates define the appropriate ResourceAttributes to be queried through the UI/CLI
* given a Heat template constructed in this way, parse it in such a way as to retrieve the role specification and Heat parameters
* rebuild Tuskar to save and retrieve Heat templates from Swift
* update CLI as necessary

==== TripleO-UI ====

* update stack queries to take advantage Heat ResourceAttributes (make sure information is gotten through Heat)
* update deployment workflow

== Custom Roles ==

Although default, predefined roles are the immediate goal, it would be nice to also allow users to define their own roles. To do so, they would specify their own list of elements. Tuskar would then use that information to call out to diskimage-builder to create a custom image matching the role; and it would create a custom Heat template for that role that the master overcloud template could then use.

The remainder of the workflow is the same as with default roles.

==== TripleO ====

* given an image element, return the list of Heat parameters that it needs

==== Tuskar ====

* given a role specification, use diskimage-builder to construct a matching image (derived from the role's image elements)
* given a role specification, return the list of Heat parameters that it needs (derived from the role's image elements)
* given a role specification and its Heat parameters, construct a Heat template for that role that meets those specifications

==== TripleO-UI ====

* create custom role workflow

== High Availability ==

One of TripleO's top priorities for Juno is to allow the deployment of a High-Availability (HA) overcloud. We would like to extend Tuskar to ensure that it can be used to deploy a HA overcloud as well.

==== TripleO ====

* Deploy HA Overcloud
:* glusterfs
:* pacemaker, corosync
:* neutron (?)
:* heat-engine A/A
:* qpid proton (assuming amqp 1.0 have merged into oslo.messaging and oslo.messaging have merged in each core project. If not, will use rabbitmq)
:* etc etc

==== Tuskar ====

* allow the generation of Heat templates that support HA

==== TripleO-UI ====

* deployment workflow support for HA architecture

== Auto-Scaling ==

Having the option for an auto-scaling cloud deployment would be greatly appealing to many users. Heat is actively working on auto-scaling support, as are other projects.

==== Ceilometer ====

* Inhibit autoscaling during stack abandon/adopt (quiesce and revitalize)

==== Heat ====

* hooks to do cleanup on scale-down (e.g host evacuation etc) (https://blueprints.launchpad.net/heat/+spec/update-hooks)
* choose victim on scale-down, or specify strategy for choosing (e.g oldest first or newest first) (https://blueprints.launchpad.net/heat/+spec/autoscaling-parameters)
* support complex conditionals when choosing victim on scale-down (e.g get notification or poll metric via ceilometer related to occupancy or other application metrics); possibly handled by above, if we can get ceilometer to pass us appropriate data when signalling the scaling policy, TBC (''may not be required for Juno'')
* Method to inhibit autoscaling/alarms during abandon/adopt (and suspend/resume?)

==== TripleO ====

* update image elements to support auto-scaling

==== Tuskar ====

* allow the generation of Heat templates that support auto-scaling

==== TripleO-UI ====

* update deployment workflow to include options that allow an auto-scaled overcloud deployment

== Node Management (Ironic) ==

We would like to switch over to using Ironic in the near future, as there are a host of features that would depend upon it.

==== Ironic ====

* Ironic graduation
:* CI jobs
:* Nova driver
:* Serial console
:* Migration path
:* User documentation

* Autodiscovery of nodes
* Ceilometer
* Tagging
* scalability

==== Nova ====

* create a nova filter for exact matches to Ironic nodes (including all node metadata) (https://review.openstack.org/#/c/83728/)

==== Tuskar ====

* use exact match filter when deploying overcloud

==== TripleO-UI ====

* added node tag values to flavor extra_specs

== Metric Graphs ==

Data visualization is a key part of maintaining a cloud. We would like to start integrating Ceilometer usage into Tuskar.

==== Ceilometer ====

* Combine samples for different meters in a transformer to produce a single derived meter
* Rollup of course-grained statistics for UI queries
* Configurable data retention based on rollups
* Overarching "health" metric for nodes
* Ceilometer native auth for alarm notifications (and possibly metrics in future) (https://blueprints.launchpad.net/ceilometer/+spec/trust-alarm-notifier)
* Eliminate central agent SPoF
* SNMP batch mode, one bulk command per node per polling cycle

For additional data:

* Acquire hardware-oriented metrics via IPMI (e.g., voltage, fan speeds, etc.)
* Keystone v3 usage would avoid IPMI credentials; allowing pollster-style interaction
* Look into consistent hashing; see if it can be reused in ceilometer -- though it requires stateful DB

==== Ironic ====

* Add a periodic task to send hardware sensor data to ceilometer (https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer)

==== Tuskar ====

* add appropriate Ceilometer agents to generated Heat templates

==== TripleO-UI ====

* Add Ceilometer-based graphs and metric data

== User Interfaces ==

This is a general category intended to encapsulate work needed in the UI and CLI.

==== Horizon ====

* separate horizon from openstack-dashboard
* test the replacement of lesscpy with pyScss
* improve error handling so that messages are less generic
* additional work on the plugin architecture to support dynamic hardware-specific views

==== Tuskar-CLI ====

* create a tuskar-cli plugin for OpenStackClient

==== TripleO-UI ====

* increase the modularity of views
* investigate usage of Heat UI components in Horizon (for example, parameter form building)
* create a mechanism for asynchronous communication

TripleO/TuskarJunoPlanning

2014-03-31T16:18:39Z

Tzumainn: /* Node Management (Ironic) */

== Overview ==

This planning document is born from discussions from the TripleO mid-cycle Icehouse meetup in Sunnyvale ([[TripleO/TuskarJunoInitialDiscussion]], [https://etherpad.openstack.org/p/openstack-management-features OpenStack Management Features]). The ideas iterated there were then individually fleshed out and detailed, with much input coming from conversations with other OpenStack projects.

Our principal concerns duing the Juno cycle are:

* integrating further with other OpenStack services, using their capabilities to enhance our TripleO management experience
* ensuring that Tuskar does not try to implement functionality that is better located in other projects

This document details our high-level goals for Juno. It does so at multiple levels; for each we provide:

* a description of the goal
* a list of project requirements and/or blueprints needed

== Cloud Service Representation ==

A cloud service represents a cloud function - provisioning service, storage service, message broker, database server, etc. A cloud service is fulfilled by a cloud service element; for example, a user can fulfill the message broker cloud service by either choosing the qpid-server element or the rabbitmq-server element.

With the cloud service concept in play, overcloud roles are updated as follows: instead of being associated with images, they are associated with a list of cloud service elements. This provides greater flexibility for the Tuskar user when designing the scalable components of a cloud. For example, instead of being limited to a Controller role, the user can separate out the network components of that role into a Network role and scale it individually.

[[File:Tuskar-service-model.png|Tuskar Service Model]]

For Juno, Tuskar will provide role defaults or suggestions corresponding to current default roles, as well as an "All-in-One" role. Each default role will be automatically associated with a list of cloud service elements and a pre-created image. Later iterations of Tuskar will allow for more user customization in this area.

If possible, we would also like to support customized roles that specify their own elements. This would require the development of additional TripleO features as described in the next section.

==== Heat ====

* Diskimage builder resource (question raised wrt ability to spawn VM to host it in seed/undercloud), also OS::GlanceImageUploader resource (''may not be required for Juno'')

==== Tuskar ====

* ensure existence of default images
* create default roles, each associated with a list of elements, an image, and a Heat template

==== TripleO-UI ====

* update deployment workflow to accomodate cloud services

== Overcloud Planning and Deployment ==

In Icehouse, the planning stage of overcloud deployment is represented by data stored in Tuskar database tables. For Juno, we would like to remove the database from Tuskar. Instead, the planning stage of a deployment will be represented by the full Heat template that would be used to deploy it. Since Heat does not intend to be a template store, this template will be stored in Swift instead. When the overcloud is ready to be deployed, the Tuskar service will pull the template out of Swift.

[[File:tuskar-arch-juno.png|Tuskar Architecture]]

Once an overcloud is deployed, all Tuskar interactions with that overcloud should be done through Heat. This includes queries about running Nova instances and relevant Ironic nodes.

==== Heat ====

* Allow stacks to be updated without forcing the user to re-provide all parameters (https://bugs.launchpad.net/heat/+bug/1224828)
* Stack update, allow retry from failed states (https://blueprints.launchpad.net/heat/+spec/update-failure-recovery)
* Stack update, rolling updates (canary deployments etc) (https://blueprints.launchpad.net/heat/+spec/rolling-updates) (''may not be required by Tuskar'')
* Stack update, enable cancelling in-progress update (e.g to pause or rollback) (https://blueprints.launchpad.net/heat/+spec/cancel-update-stack)
* Possibly allow inline specification of provider resources, e.g have a resource which generates a heat template, then refer to it, e.g like type: {get_attr: [SomeResource, template]} (''may not be required by Tuskar'')
* nested resource templates (''may not be required for Juno'')
* Stack preview (preview what would happen via stack-create) (https://blueprints.launchpad.net/heat/+spec/preview-stack) (''may not be required for Juno'')
* Stack check (sync state of stack with the real state of underlying resources, e.g persist out-of-band failures in stack resource states) (https://blueprints.launchpad.net/heat/+spec/stack-check) (''may not be required for Juno'')
* Stack converge - "fixes" stack and returns to known state (https://blueprints.launchpad.net/heat/+spec/stack-convergence) (''may not be required for Juno'')

==== TripleO ====

* update Heat templates in TripleO for: HOT, provider resources, software config

==== Tuskar ====

* provide default templates for default roles (these will be wrapped in ProviderResources)
* construct an overcloud template that references the default roles through ProviderResources
* ensure constructed templates define the appropriate ResourceAttributes to be queried through the UI/CLI
* given a Heat template constructed in this way, parse it in such a way as to retrieve the role specification and Heat parameters
* rebuild Tuskar to save and retrieve Heat templates from Swift
* update CLI as necessary

==== TripleO-UI ====

* update stack queries to take advantage Heat ResourceAttributes (make sure information is gotten through Heat)
* update deployment workflow

== Custom Roles ==

Although default, predefined roles are the immediate goal, it would be nice to also allow users to define their own roles. To do so, they would specify their own list of elements. Tuskar would then use that information to call out to diskimage-builder to create a custom image matching the role; and it would create a custom Heat template for that role that the master overcloud template could then use.

The remainder of the workflow is the same as with default roles.

==== TripleO ====

* given an image element, return the list of Heat parameters that it needs

==== Tuskar ====

* given a role specification, use diskimage-builder to construct a matching image (derived from the role's image elements)
* given a role specification, return the list of Heat parameters that it needs (derived from the role's image elements)
* given a role specification and its Heat parameters, construct a Heat template for that role that meets those specifications

==== TripleO-UI ====

* create custom role workflow

== High Availability ==

One of TripleO's top priorities for Juno is to allow the deployment of a High-Availability (HA) overcloud. We would like to extend Tuskar to ensure that it can be used to deploy a HA overcloud as well.

==== TripleO ====

* Deploy HA Overcloud
:* glusterfs
:* pacemaker, corosync
:* neutron (?)
:* heat-engine A/A
:* qpid proton (assuming amqp 1.0 have merged into oslo.messaging and oslo.messaging have merged in each core project. If not, will use rabbitmq)
:* etc etc

==== Tuskar ====

* allow the generation of Heat templates that support HA

==== TripleO-UI ====

* deployment workflow support for HA architecture

== Auto-Scaling ==

Having the option for an auto-scaling cloud deployment would be greatly appealing to many users. Heat is actively working on auto-scaling support, as are other projects.

==== Ceilometer ====

* Inhibit autoscaling during stack abandon/adopt (quiesce and revitalize)

==== Heat ====

* hooks to do cleanup on scale-down (e.g host evacuation etc) (https://blueprints.launchpad.net/heat/+spec/update-hooks)
* choose victim on scale-down, or specify strategy for choosing (e.g oldest first or newest first) (https://blueprints.launchpad.net/heat/+spec/autoscaling-parameters)
* support complex conditionals when choosing victim on scale-down (e.g get notification or poll metric via ceilometer related to occupancy or other application metrics); possibly handled by above, if we can get ceilometer to pass us appropriate data when signalling the scaling policy, TBC (''may not be required for Juno'')
* Method to inhibit autoscaling/alarms during abandon/adopt (and suspend/resume?)

==== TripleO ====

* update image elements to support auto-scaling

==== Tuskar ====

* allow the generation of Heat templates that support auto-scaling

==== TripleO-UI ====

* update deployment workflow to include options that allow an auto-scaled overcloud deployment

== Node Management (Ironic) ==

We would like to switch over to using Ironic in the near future, as there are a host of features that would depend upon it.

==== Ironic ====

* Ironic graduation
:* CI jobs
:* Nova driver
:* Serial console
:* Migration path
:* User documentation

* Autodiscovery of nodes
* Ceilometer
* Tagging
* scalability

==== Nova ====

* create a nova filter for exact matches to Ironic nodes (including all node metadata) (https://review.openstack.org/#/c/83728/)

==== Tuskar ====

* use exact match filter when deploying overcloud

==== TripleO UI ====

* added node tag values to flavor extra_specs

== Metric Graphs ==

Data visualization is a key part of maintaining a cloud. We would like to start integrating Ceilometer usage into Tuskar.

==== Ceilometer ====

* Combine samples for different meters in a transformer to produce a single derived meter
* Rollup of course-grained statistics for UI queries
* Configurable data retention based on rollups
* Overarching "health" metric for nodes
* Ceilometer native auth for alarm notifications (and possibly metrics in future) (https://blueprints.launchpad.net/ceilometer/+spec/trust-alarm-notifier)
* Eliminate central agent SPoF
* SNMP batch mode, one bulk command per node per polling cycle

For additional data:

* Acquire hardware-oriented metrics via IPMI (e.g., voltage, fan speeds, etc.)
* Keystone v3 usage would avoid IPMI credentials; allowing pollster-style interaction
* Look into consistent hashing; see if it can be reused in ceilometer -- though it requires stateful DB

==== Ironic ====

* Add a periodic task to send hardware sensor data to ceilometer (https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer)

==== Tuskar ====

* add appropriate Ceilometer agents to generated Heat templates

==== TripleO-UI ====

* Add Ceilometer-based graphs and metric data

== User Interfaces ==

This is a general category intended to encapsulate work needed in the UI and CLI.

==== Horizon ====

* separate horizon from openstack-dashboard
* test the replacement of lesscpy with pyScss
* improve error handling so that messages are less generic
* additional work on the plugin architecture to support dynamic hardware-specific views

==== Tuskar-CLI ====

* create a tuskar-cli plugin for OpenStackClient

==== TripleO-UI ====

* increase the modularity of views
* investigate usage of Heat UI components in Horizon (for example, parameter form building)
* create a mechanism for asynchronous communication

TripleO/TuskarJunoPlanning

2014-03-31T16:12:53Z

Tzumainn: /* Nova */

== Overview ==

This planning document is born from discussions from the TripleO mid-cycle Icehouse meetup in Sunnyvale ([[TripleO/TuskarJunoInitialDiscussion]], [https://etherpad.openstack.org/p/openstack-management-features OpenStack Management Features]). The ideas iterated there were then individually fleshed out and detailed, with much input coming from conversations with other OpenStack projects.

Our principal concerns duing the Juno cycle are:

* integrating further with other OpenStack services, using their capabilities to enhance our TripleO management experience
* ensuring that Tuskar does not try to implement functionality that is better located in other projects

This document details our high-level goals for Juno. It does so at multiple levels; for each we provide:

* a description of the goal
* a list of project requirements and/or blueprints needed

== Cloud Service Representation ==

A cloud service represents a cloud function - provisioning service, storage service, message broker, database server, etc. A cloud service is fulfilled by a cloud service element; for example, a user can fulfill the message broker cloud service by either choosing the qpid-server element or the rabbitmq-server element.

With the cloud service concept in play, overcloud roles are updated as follows: instead of being associated with images, they are associated with a list of cloud service elements. This provides greater flexibility for the Tuskar user when designing the scalable components of a cloud. For example, instead of being limited to a Controller role, the user can separate out the network components of that role into a Network role and scale it individually.

[[File:Tuskar-service-model.png|Tuskar Service Model]]

For Juno, Tuskar will provide role defaults or suggestions corresponding to current default roles, as well as an "All-in-One" role. Each default role will be automatically associated with a list of cloud service elements and a pre-created image. Later iterations of Tuskar will allow for more user customization in this area.

If possible, we would also like to support customized roles that specify their own elements. This would require the development of additional TripleO features as described in the next section.

==== Heat ====

* Diskimage builder resource (question raised wrt ability to spawn VM to host it in seed/undercloud), also OS::GlanceImageUploader resource (''may not be required for Juno'')

==== Tuskar ====

* ensure existence of default images
* create default roles, each associated with a list of elements, an image, and a Heat template

==== TripleO-UI ====

* update deployment workflow to accomodate cloud services

== Overcloud Planning and Deployment ==

In Icehouse, the planning stage of overcloud deployment is represented by data stored in Tuskar database tables. For Juno, we would like to remove the database from Tuskar. Instead, the planning stage of a deployment will be represented by the full Heat template that would be used to deploy it. Since Heat does not intend to be a template store, this template will be stored in Swift instead. When the overcloud is ready to be deployed, the Tuskar service will pull the template out of Swift.

[[File:tuskar-arch-juno.png|Tuskar Architecture]]

Once an overcloud is deployed, all Tuskar interactions with that overcloud should be done through Heat. This includes queries about running Nova instances and relevant Ironic nodes.

==== Heat ====

* Allow stacks to be updated without forcing the user to re-provide all parameters (https://bugs.launchpad.net/heat/+bug/1224828)
* Stack update, allow retry from failed states (https://blueprints.launchpad.net/heat/+spec/update-failure-recovery)
* Stack update, rolling updates (canary deployments etc) (https://blueprints.launchpad.net/heat/+spec/rolling-updates) (''may not be required by Tuskar'')
* Stack update, enable cancelling in-progress update (e.g to pause or rollback) (https://blueprints.launchpad.net/heat/+spec/cancel-update-stack)
* Possibly allow inline specification of provider resources, e.g have a resource which generates a heat template, then refer to it, e.g like type: {get_attr: [SomeResource, template]} (''may not be required by Tuskar'')
* nested resource templates (''may not be required for Juno'')
* Stack preview (preview what would happen via stack-create) (https://blueprints.launchpad.net/heat/+spec/preview-stack) (''may not be required for Juno'')
* Stack check (sync state of stack with the real state of underlying resources, e.g persist out-of-band failures in stack resource states) (https://blueprints.launchpad.net/heat/+spec/stack-check) (''may not be required for Juno'')
* Stack converge - "fixes" stack and returns to known state (https://blueprints.launchpad.net/heat/+spec/stack-convergence) (''may not be required for Juno'')

==== TripleO ====

* update Heat templates in TripleO for: HOT, provider resources, software config

==== Tuskar ====

* provide default templates for default roles (these will be wrapped in ProviderResources)
* construct an overcloud template that references the default roles through ProviderResources
* ensure constructed templates define the appropriate ResourceAttributes to be queried through the UI/CLI
* given a Heat template constructed in this way, parse it in such a way as to retrieve the role specification and Heat parameters
* rebuild Tuskar to save and retrieve Heat templates from Swift
* update CLI as necessary

==== TripleO-UI ====

* update stack queries to take advantage Heat ResourceAttributes (make sure information is gotten through Heat)
* update deployment workflow

== Custom Roles ==

Although default, predefined roles are the immediate goal, it would be nice to also allow users to define their own roles. To do so, they would specify their own list of elements. Tuskar would then use that information to call out to diskimage-builder to create a custom image matching the role; and it would create a custom Heat template for that role that the master overcloud template could then use.

The remainder of the workflow is the same as with default roles.

==== TripleO ====

* given an image element, return the list of Heat parameters that it needs

==== Tuskar ====

* given a role specification, use diskimage-builder to construct a matching image (derived from the role's image elements)
* given a role specification, return the list of Heat parameters that it needs (derived from the role's image elements)
* given a role specification and its Heat parameters, construct a Heat template for that role that meets those specifications

==== TripleO-UI ====

* create custom role workflow

== High Availability ==

One of TripleO's top priorities for Juno is to allow the deployment of a High-Availability (HA) overcloud. We would like to extend Tuskar to ensure that it can be used to deploy a HA overcloud as well.

==== TripleO ====

* Deploy HA Overcloud
:* glusterfs
:* pacemaker, corosync
:* neutron (?)
:* heat-engine A/A
:* qpid proton (assuming amqp 1.0 have merged into oslo.messaging and oslo.messaging have merged in each core project. If not, will use rabbitmq)
:* etc etc

==== Tuskar ====

* allow the generation of Heat templates that support HA

==== TripleO-UI ====

* deployment workflow support for HA architecture

== Auto-Scaling ==

Having the option for an auto-scaling cloud deployment would be greatly appealing to many users. Heat is actively working on auto-scaling support, as are other projects.

==== Ceilometer ====

* Inhibit autoscaling during stack abandon/adopt (quiesce and revitalize)

==== Heat ====

* hooks to do cleanup on scale-down (e.g host evacuation etc) (https://blueprints.launchpad.net/heat/+spec/update-hooks)
* choose victim on scale-down, or specify strategy for choosing (e.g oldest first or newest first) (https://blueprints.launchpad.net/heat/+spec/autoscaling-parameters)
* support complex conditionals when choosing victim on scale-down (e.g get notification or poll metric via ceilometer related to occupancy or other application metrics); possibly handled by above, if we can get ceilometer to pass us appropriate data when signalling the scaling policy, TBC (''may not be required for Juno'')
* Method to inhibit autoscaling/alarms during abandon/adopt (and suspend/resume?)

==== TripleO ====

* update image elements to support auto-scaling

==== Tuskar ====

* allow the generation of Heat templates that support auto-scaling

==== TripleO-UI ====

* update deployment workflow to include options that allow an auto-scaled overcloud deployment

== Node Management (Ironic) ==

We would like to switch over to using Ironic in the near future, as there are a host of features that would depend upon it.

==== Ironic ====

* Ironic graduation
:* CI jobs
:* Nova driver
:* Serial console
:* Migration path
:* User documentation

* Autodiscovery of nodes
* Ceilometer
* Tagging
* scalability

==== Nova ====

* ensure that flavor metadata can include node tag values
* create a nova filter for exact matches to Ironic nodes (including all node metadata) (https://review.openstack.org/#/c/83728/)

== Metric Graphs ==

Data visualization is a key part of maintaining a cloud. We would like to start integrating Ceilometer usage into Tuskar.

==== Ceilometer ====

* Combine samples for different meters in a transformer to produce a single derived meter
* Rollup of course-grained statistics for UI queries
* Configurable data retention based on rollups
* Overarching "health" metric for nodes
* Ceilometer native auth for alarm notifications (and possibly metrics in future) (https://blueprints.launchpad.net/ceilometer/+spec/trust-alarm-notifier)
* Eliminate central agent SPoF
* SNMP batch mode, one bulk command per node per polling cycle

For additional data:

* Acquire hardware-oriented metrics via IPMI (e.g., voltage, fan speeds, etc.)
* Keystone v3 usage would avoid IPMI credentials; allowing pollster-style interaction
* Look into consistent hashing; see if it can be reused in ceilometer -- though it requires stateful DB

==== Ironic ====

* Add a periodic task to send hardware sensor data to ceilometer (https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer)

==== Tuskar ====

* add appropriate Ceilometer agents to generated Heat templates

==== TripleO-UI ====

* Add Ceilometer-based graphs and metric data

== User Interfaces ==

This is a general category intended to encapsulate work needed in the UI and CLI.

==== Horizon ====

* separate horizon from openstack-dashboard
* test the replacement of lesscpy with pyScss
* improve error handling so that messages are less generic
* additional work on the plugin architecture to support dynamic hardware-specific views

==== Tuskar-CLI ====

* create a tuskar-cli plugin for OpenStackClient

==== TripleO-UI ====

* increase the modularity of views
* investigate usage of Heat UI components in Horizon (for example, parameter form building)
* create a mechanism for asynchronous communication

TripleO/TuskarJunoPlanning

2014-03-31T16:12:24Z

Tzumainn: /* Node Management (Ironic) */

== Overview ==

This planning document is born from discussions from the TripleO mid-cycle Icehouse meetup in Sunnyvale ([[TripleO/TuskarJunoInitialDiscussion]], [https://etherpad.openstack.org/p/openstack-management-features OpenStack Management Features]). The ideas iterated there were then individually fleshed out and detailed, with much input coming from conversations with other OpenStack projects.

Our principal concerns duing the Juno cycle are:

* integrating further with other OpenStack services, using their capabilities to enhance our TripleO management experience
* ensuring that Tuskar does not try to implement functionality that is better located in other projects

This document details our high-level goals for Juno. It does so at multiple levels; for each we provide:

* a description of the goal
* a list of project requirements and/or blueprints needed

== Cloud Service Representation ==

A cloud service represents a cloud function - provisioning service, storage service, message broker, database server, etc. A cloud service is fulfilled by a cloud service element; for example, a user can fulfill the message broker cloud service by either choosing the qpid-server element or the rabbitmq-server element.

With the cloud service concept in play, overcloud roles are updated as follows: instead of being associated with images, they are associated with a list of cloud service elements. This provides greater flexibility for the Tuskar user when designing the scalable components of a cloud. For example, instead of being limited to a Controller role, the user can separate out the network components of that role into a Network role and scale it individually.

[[File:Tuskar-service-model.png|Tuskar Service Model]]

For Juno, Tuskar will provide role defaults or suggestions corresponding to current default roles, as well as an "All-in-One" role. Each default role will be automatically associated with a list of cloud service elements and a pre-created image. Later iterations of Tuskar will allow for more user customization in this area.

If possible, we would also like to support customized roles that specify their own elements. This would require the development of additional TripleO features as described in the next section.

==== Heat ====

* Diskimage builder resource (question raised wrt ability to spawn VM to host it in seed/undercloud), also OS::GlanceImageUploader resource (''may not be required for Juno'')

==== Tuskar ====

* ensure existence of default images
* create default roles, each associated with a list of elements, an image, and a Heat template

==== TripleO-UI ====

* update deployment workflow to accomodate cloud services

== Overcloud Planning and Deployment ==

In Icehouse, the planning stage of overcloud deployment is represented by data stored in Tuskar database tables. For Juno, we would like to remove the database from Tuskar. Instead, the planning stage of a deployment will be represented by the full Heat template that would be used to deploy it. Since Heat does not intend to be a template store, this template will be stored in Swift instead. When the overcloud is ready to be deployed, the Tuskar service will pull the template out of Swift.

[[File:tuskar-arch-juno.png|Tuskar Architecture]]

Once an overcloud is deployed, all Tuskar interactions with that overcloud should be done through Heat. This includes queries about running Nova instances and relevant Ironic nodes.

==== Heat ====

* Allow stacks to be updated without forcing the user to re-provide all parameters (https://bugs.launchpad.net/heat/+bug/1224828)
* Stack update, allow retry from failed states (https://blueprints.launchpad.net/heat/+spec/update-failure-recovery)
* Stack update, rolling updates (canary deployments etc) (https://blueprints.launchpad.net/heat/+spec/rolling-updates) (''may not be required by Tuskar'')
* Stack update, enable cancelling in-progress update (e.g to pause or rollback) (https://blueprints.launchpad.net/heat/+spec/cancel-update-stack)
* Possibly allow inline specification of provider resources, e.g have a resource which generates a heat template, then refer to it, e.g like type: {get_attr: [SomeResource, template]} (''may not be required by Tuskar'')
* nested resource templates (''may not be required for Juno'')
* Stack preview (preview what would happen via stack-create) (https://blueprints.launchpad.net/heat/+spec/preview-stack) (''may not be required for Juno'')
* Stack check (sync state of stack with the real state of underlying resources, e.g persist out-of-band failures in stack resource states) (https://blueprints.launchpad.net/heat/+spec/stack-check) (''may not be required for Juno'')
* Stack converge - "fixes" stack and returns to known state (https://blueprints.launchpad.net/heat/+spec/stack-convergence) (''may not be required for Juno'')

==== TripleO ====

* update Heat templates in TripleO for: HOT, provider resources, software config

==== Tuskar ====

* provide default templates for default roles (these will be wrapped in ProviderResources)
* construct an overcloud template that references the default roles through ProviderResources
* ensure constructed templates define the appropriate ResourceAttributes to be queried through the UI/CLI
* given a Heat template constructed in this way, parse it in such a way as to retrieve the role specification and Heat parameters
* rebuild Tuskar to save and retrieve Heat templates from Swift
* update CLI as necessary

==== TripleO-UI ====

* update stack queries to take advantage Heat ResourceAttributes (make sure information is gotten through Heat)
* update deployment workflow

== Custom Roles ==

Although default, predefined roles are the immediate goal, it would be nice to also allow users to define their own roles. To do so, they would specify their own list of elements. Tuskar would then use that information to call out to diskimage-builder to create a custom image matching the role; and it would create a custom Heat template for that role that the master overcloud template could then use.

The remainder of the workflow is the same as with default roles.

==== TripleO ====

* given an image element, return the list of Heat parameters that it needs

==== Tuskar ====

* given a role specification, use diskimage-builder to construct a matching image (derived from the role's image elements)
* given a role specification, return the list of Heat parameters that it needs (derived from the role's image elements)
* given a role specification and its Heat parameters, construct a Heat template for that role that meets those specifications

==== TripleO-UI ====

* create custom role workflow

== High Availability ==

One of TripleO's top priorities for Juno is to allow the deployment of a High-Availability (HA) overcloud. We would like to extend Tuskar to ensure that it can be used to deploy a HA overcloud as well.

==== TripleO ====

* Deploy HA Overcloud
:* glusterfs
:* pacemaker, corosync
:* neutron (?)
:* heat-engine A/A
:* qpid proton (assuming amqp 1.0 have merged into oslo.messaging and oslo.messaging have merged in each core project. If not, will use rabbitmq)
:* etc etc

==== Tuskar ====

* allow the generation of Heat templates that support HA

==== TripleO-UI ====

* deployment workflow support for HA architecture

== Auto-Scaling ==

Having the option for an auto-scaling cloud deployment would be greatly appealing to many users. Heat is actively working on auto-scaling support, as are other projects.

==== Ceilometer ====

* Inhibit autoscaling during stack abandon/adopt (quiesce and revitalize)

==== Heat ====

* hooks to do cleanup on scale-down (e.g host evacuation etc) (https://blueprints.launchpad.net/heat/+spec/update-hooks)
* choose victim on scale-down, or specify strategy for choosing (e.g oldest first or newest first) (https://blueprints.launchpad.net/heat/+spec/autoscaling-parameters)
* support complex conditionals when choosing victim on scale-down (e.g get notification or poll metric via ceilometer related to occupancy or other application metrics); possibly handled by above, if we can get ceilometer to pass us appropriate data when signalling the scaling policy, TBC (''may not be required for Juno'')
* Method to inhibit autoscaling/alarms during abandon/adopt (and suspend/resume?)

==== TripleO ====

* update image elements to support auto-scaling

==== Tuskar ====

* allow the generation of Heat templates that support auto-scaling

==== TripleO-UI ====

* update deployment workflow to include options that allow an auto-scaled overcloud deployment

== Node Management (Ironic) ==

We would like to switch over to using Ironic in the near future, as there are a host of features that would depend upon it.

==== Ironic ====

* Ironic graduation
:* CI jobs
:* Nova driver
:* Serial console
:* Migration path
:* User documentation

* Autodiscovery of nodes
* Ceilometer
* Tagging
* scalability

==== Nova ====

* ensure that flavor metadata can include node tag values
* create a nova filter for exact matches to Ironic nodes (including all node metadata)

== Metric Graphs ==

Data visualization is a key part of maintaining a cloud. We would like to start integrating Ceilometer usage into Tuskar.

==== Ceilometer ====

* Combine samples for different meters in a transformer to produce a single derived meter
* Rollup of course-grained statistics for UI queries
* Configurable data retention based on rollups
* Overarching "health" metric for nodes
* Ceilometer native auth for alarm notifications (and possibly metrics in future) (https://blueprints.launchpad.net/ceilometer/+spec/trust-alarm-notifier)
* Eliminate central agent SPoF
* SNMP batch mode, one bulk command per node per polling cycle

For additional data:

* Acquire hardware-oriented metrics via IPMI (e.g., voltage, fan speeds, etc.)
* Keystone v3 usage would avoid IPMI credentials; allowing pollster-style interaction
* Look into consistent hashing; see if it can be reused in ceilometer -- though it requires stateful DB

==== Ironic ====

* Add a periodic task to send hardware sensor data to ceilometer (https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer)

==== Tuskar ====

* add appropriate Ceilometer agents to generated Heat templates

==== TripleO-UI ====

* Add Ceilometer-based graphs and metric data

== User Interfaces ==

This is a general category intended to encapsulate work needed in the UI and CLI.

==== Horizon ====

* separate horizon from openstack-dashboard
* test the replacement of lesscpy with pyScss
* improve error handling so that messages are less generic
* additional work on the plugin architecture to support dynamic hardware-specific views

==== Tuskar-CLI ====

* create a tuskar-cli plugin for OpenStackClient

==== TripleO-UI ====

* increase the modularity of views
* investigate usage of Heat UI components in Horizon (for example, parameter form building)
* create a mechanism for asynchronous communication

TripleO/TuskarJunoPlanning

2014-03-31T16:06:15Z

Tzumainn: /* Metric Graphs */

== Overview ==

This planning document is born from discussions from the TripleO mid-cycle Icehouse meetup in Sunnyvale ([[TripleO/TuskarJunoInitialDiscussion]], [https://etherpad.openstack.org/p/openstack-management-features OpenStack Management Features]). The ideas iterated there were then individually fleshed out and detailed, with much input coming from conversations with other OpenStack projects.

Our principal concerns duing the Juno cycle are:

* integrating further with other OpenStack services, using their capabilities to enhance our TripleO management experience
* ensuring that Tuskar does not try to implement functionality that is better located in other projects

This document details our high-level goals for Juno. It does so at multiple levels; for each we provide:

* a description of the goal
* a list of project requirements and/or blueprints needed

== Cloud Service Representation ==

A cloud service represents a cloud function - provisioning service, storage service, message broker, database server, etc. A cloud service is fulfilled by a cloud service element; for example, a user can fulfill the message broker cloud service by either choosing the qpid-server element or the rabbitmq-server element.

With the cloud service concept in play, overcloud roles are updated as follows: instead of being associated with images, they are associated with a list of cloud service elements. This provides greater flexibility for the Tuskar user when designing the scalable components of a cloud. For example, instead of being limited to a Controller role, the user can separate out the network components of that role into a Network role and scale it individually.

[[File:Tuskar-service-model.png|Tuskar Service Model]]

For Juno, Tuskar will provide role defaults or suggestions corresponding to current default roles, as well as an "All-in-One" role. Each default role will be automatically associated with a list of cloud service elements and a pre-created image. Later iterations of Tuskar will allow for more user customization in this area.

If possible, we would also like to support customized roles that specify their own elements. This would require the development of additional TripleO features as described in the next section.

==== Heat ====

* Diskimage builder resource (question raised wrt ability to spawn VM to host it in seed/undercloud), also OS::GlanceImageUploader resource (''may not be required for Juno'')

==== Tuskar ====

* ensure existence of default images
* create default roles, each associated with a list of elements, an image, and a Heat template

==== TripleO-UI ====

* update deployment workflow to accomodate cloud services

== Overcloud Planning and Deployment ==

In Icehouse, the planning stage of overcloud deployment is represented by data stored in Tuskar database tables. For Juno, we would like to remove the database from Tuskar. Instead, the planning stage of a deployment will be represented by the full Heat template that would be used to deploy it. Since Heat does not intend to be a template store, this template will be stored in Swift instead. When the overcloud is ready to be deployed, the Tuskar service will pull the template out of Swift.

[[File:tuskar-arch-juno.png|Tuskar Architecture]]

Once an overcloud is deployed, all Tuskar interactions with that overcloud should be done through Heat. This includes queries about running Nova instances and relevant Ironic nodes.

==== Heat ====

* Allow stacks to be updated without forcing the user to re-provide all parameters (https://bugs.launchpad.net/heat/+bug/1224828)
* Stack update, allow retry from failed states (https://blueprints.launchpad.net/heat/+spec/update-failure-recovery)
* Stack update, rolling updates (canary deployments etc) (https://blueprints.launchpad.net/heat/+spec/rolling-updates) (''may not be required by Tuskar'')
* Stack update, enable cancelling in-progress update (e.g to pause or rollback) (https://blueprints.launchpad.net/heat/+spec/cancel-update-stack)
* Possibly allow inline specification of provider resources, e.g have a resource which generates a heat template, then refer to it, e.g like type: {get_attr: [SomeResource, template]} (''may not be required by Tuskar'')
* nested resource templates (''may not be required for Juno'')
* Stack preview (preview what would happen via stack-create) (https://blueprints.launchpad.net/heat/+spec/preview-stack) (''may not be required for Juno'')
* Stack check (sync state of stack with the real state of underlying resources, e.g persist out-of-band failures in stack resource states) (https://blueprints.launchpad.net/heat/+spec/stack-check) (''may not be required for Juno'')
* Stack converge - "fixes" stack and returns to known state (https://blueprints.launchpad.net/heat/+spec/stack-convergence) (''may not be required for Juno'')

==== TripleO ====

* update Heat templates in TripleO for: HOT, provider resources, software config

==== Tuskar ====

* provide default templates for default roles (these will be wrapped in ProviderResources)
* construct an overcloud template that references the default roles through ProviderResources
* ensure constructed templates define the appropriate ResourceAttributes to be queried through the UI/CLI
* given a Heat template constructed in this way, parse it in such a way as to retrieve the role specification and Heat parameters
* rebuild Tuskar to save and retrieve Heat templates from Swift
* update CLI as necessary

==== TripleO-UI ====

* update stack queries to take advantage Heat ResourceAttributes (make sure information is gotten through Heat)
* update deployment workflow

== Custom Roles ==

Although default, predefined roles are the immediate goal, it would be nice to also allow users to define their own roles. To do so, they would specify their own list of elements. Tuskar would then use that information to call out to diskimage-builder to create a custom image matching the role; and it would create a custom Heat template for that role that the master overcloud template could then use.

The remainder of the workflow is the same as with default roles.

==== TripleO ====

* given an image element, return the list of Heat parameters that it needs

==== Tuskar ====

* given a role specification, use diskimage-builder to construct a matching image (derived from the role's image elements)
* given a role specification, return the list of Heat parameters that it needs (derived from the role's image elements)
* given a role specification and its Heat parameters, construct a Heat template for that role that meets those specifications

==== TripleO-UI ====

* create custom role workflow

== High Availability ==

One of TripleO's top priorities for Juno is to allow the deployment of a High-Availability (HA) overcloud. We would like to extend Tuskar to ensure that it can be used to deploy a HA overcloud as well.

==== TripleO ====

* Deploy HA Overcloud
:* glusterfs
:* pacemaker, corosync
:* neutron (?)
:* heat-engine A/A
:* qpid proton (assuming amqp 1.0 have merged into oslo.messaging and oslo.messaging have merged in each core project. If not, will use rabbitmq)
:* etc etc

==== Tuskar ====

* allow the generation of Heat templates that support HA

==== TripleO-UI ====

* deployment workflow support for HA architecture

== Auto-Scaling ==

Having the option for an auto-scaling cloud deployment would be greatly appealing to many users. Heat is actively working on auto-scaling support, as are other projects.

==== Ceilometer ====

* Inhibit autoscaling during stack abandon/adopt (quiesce and revitalize)

==== Heat ====

* hooks to do cleanup on scale-down (e.g host evacuation etc) (https://blueprints.launchpad.net/heat/+spec/update-hooks)
* choose victim on scale-down, or specify strategy for choosing (e.g oldest first or newest first) (https://blueprints.launchpad.net/heat/+spec/autoscaling-parameters)
* support complex conditionals when choosing victim on scale-down (e.g get notification or poll metric via ceilometer related to occupancy or other application metrics); possibly handled by above, if we can get ceilometer to pass us appropriate data when signalling the scaling policy, TBC (''may not be required for Juno'')
* Method to inhibit autoscaling/alarms during abandon/adopt (and suspend/resume?)

==== TripleO ====

* update image elements to support auto-scaling

==== Tuskar ====

* allow the generation of Heat templates that support auto-scaling

==== TripleO-UI ====

* update deployment workflow to include options that allow an auto-scaled overcloud deployment

== Node Management (Ironic) ==

We would like to switchover to using Ironic in the near future, as there are a host of features that would depend upon it.

==== Ironic ====

* Ironic graduation
:* CI jobs
:* Nova driver
:* Serial console
:* Migration path
:* User documentation

* Autodiscovery of nodes
* Ceilometer
* Tagging
* scalability

==== Nova ====

* ensure that flavor metadata can include node tag values
* create a nova filter for exact matches to Ironic nodes (including all node metadata)

==== Heat ====

* Ironic resource plugin (''may not be required by us'')

== Metric Graphs ==

Data visualization is a key part of maintaining a cloud. We would like to start integrating Ceilometer usage into Tuskar.

==== Ceilometer ====

* Combine samples for different meters in a transformer to produce a single derived meter
* Rollup of course-grained statistics for UI queries
* Configurable data retention based on rollups
* Overarching "health" metric for nodes
* Ceilometer native auth for alarm notifications (and possibly metrics in future) (https://blueprints.launchpad.net/ceilometer/+spec/trust-alarm-notifier)
* Eliminate central agent SPoF
* SNMP batch mode, one bulk command per node per polling cycle

For additional data:

* Acquire hardware-oriented metrics via IPMI (e.g., voltage, fan speeds, etc.)
* Keystone v3 usage would avoid IPMI credentials; allowing pollster-style interaction
* Look into consistent hashing; see if it can be reused in ceilometer -- though it requires stateful DB

==== Ironic ====

* Add a periodic task to send hardware sensor data to ceilometer (https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer)

==== Tuskar ====

* add appropriate Ceilometer agents to generated Heat templates

==== TripleO-UI ====

* Add Ceilometer-based graphs and metric data

== User Interfaces ==

This is a general category intended to encapsulate work needed in the UI and CLI.

==== Horizon ====

* separate horizon from openstack-dashboard
* test the replacement of lesscpy with pyScss
* improve error handling so that messages are less generic
* additional work on the plugin architecture to support dynamic hardware-specific views

==== Tuskar-CLI ====

* create a tuskar-cli plugin for OpenStackClient

==== TripleO-UI ====

* increase the modularity of views
* investigate usage of Heat UI components in Horizon (for example, parameter form building)
* create a mechanism for asynchronous communication

TripleO/TuskarJunoPlanning

2014-03-31T16:05:54Z

Tzumainn:

== Overview ==

This planning document is born from discussions from the TripleO mid-cycle Icehouse meetup in Sunnyvale ([[TripleO/TuskarJunoInitialDiscussion]], [https://etherpad.openstack.org/p/openstack-management-features OpenStack Management Features]). The ideas iterated there were then individually fleshed out and detailed, with much input coming from conversations with other OpenStack projects.

Our principal concerns duing the Juno cycle are:

* integrating further with other OpenStack services, using their capabilities to enhance our TripleO management experience
* ensuring that Tuskar does not try to implement functionality that is better located in other projects

This document details our high-level goals for Juno. It does so at multiple levels; for each we provide:

* a description of the goal
* a list of project requirements and/or blueprints needed

== Cloud Service Representation ==

A cloud service represents a cloud function - provisioning service, storage service, message broker, database server, etc. A cloud service is fulfilled by a cloud service element; for example, a user can fulfill the message broker cloud service by either choosing the qpid-server element or the rabbitmq-server element.

With the cloud service concept in play, overcloud roles are updated as follows: instead of being associated with images, they are associated with a list of cloud service elements. This provides greater flexibility for the Tuskar user when designing the scalable components of a cloud. For example, instead of being limited to a Controller role, the user can separate out the network components of that role into a Network role and scale it individually.

[[File:Tuskar-service-model.png|Tuskar Service Model]]

For Juno, Tuskar will provide role defaults or suggestions corresponding to current default roles, as well as an "All-in-One" role. Each default role will be automatically associated with a list of cloud service elements and a pre-created image. Later iterations of Tuskar will allow for more user customization in this area.

If possible, we would also like to support customized roles that specify their own elements. This would require the development of additional TripleO features as described in the next section.

==== Heat ====

* Diskimage builder resource (question raised wrt ability to spawn VM to host it in seed/undercloud), also OS::GlanceImageUploader resource (''may not be required for Juno'')

==== Tuskar ====

* ensure existence of default images
* create default roles, each associated with a list of elements, an image, and a Heat template

==== TripleO-UI ====

* update deployment workflow to accomodate cloud services

== Overcloud Planning and Deployment ==

In Icehouse, the planning stage of overcloud deployment is represented by data stored in Tuskar database tables. For Juno, we would like to remove the database from Tuskar. Instead, the planning stage of a deployment will be represented by the full Heat template that would be used to deploy it. Since Heat does not intend to be a template store, this template will be stored in Swift instead. When the overcloud is ready to be deployed, the Tuskar service will pull the template out of Swift.

[[File:tuskar-arch-juno.png|Tuskar Architecture]]

Once an overcloud is deployed, all Tuskar interactions with that overcloud should be done through Heat. This includes queries about running Nova instances and relevant Ironic nodes.

==== Heat ====

* Allow stacks to be updated without forcing the user to re-provide all parameters (https://bugs.launchpad.net/heat/+bug/1224828)
* Stack update, allow retry from failed states (https://blueprints.launchpad.net/heat/+spec/update-failure-recovery)
* Stack update, rolling updates (canary deployments etc) (https://blueprints.launchpad.net/heat/+spec/rolling-updates) (''may not be required by Tuskar'')
* Stack update, enable cancelling in-progress update (e.g to pause or rollback) (https://blueprints.launchpad.net/heat/+spec/cancel-update-stack)
* Possibly allow inline specification of provider resources, e.g have a resource which generates a heat template, then refer to it, e.g like type: {get_attr: [SomeResource, template]} (''may not be required by Tuskar'')
* nested resource templates (''may not be required for Juno'')
* Stack preview (preview what would happen via stack-create) (https://blueprints.launchpad.net/heat/+spec/preview-stack) (''may not be required for Juno'')
* Stack check (sync state of stack with the real state of underlying resources, e.g persist out-of-band failures in stack resource states) (https://blueprints.launchpad.net/heat/+spec/stack-check) (''may not be required for Juno'')
* Stack converge - "fixes" stack and returns to known state (https://blueprints.launchpad.net/heat/+spec/stack-convergence) (''may not be required for Juno'')

==== TripleO ====

* update Heat templates in TripleO for: HOT, provider resources, software config

==== Tuskar ====

* provide default templates for default roles (these will be wrapped in ProviderResources)
* construct an overcloud template that references the default roles through ProviderResources
* ensure constructed templates define the appropriate ResourceAttributes to be queried through the UI/CLI
* given a Heat template constructed in this way, parse it in such a way as to retrieve the role specification and Heat parameters
* rebuild Tuskar to save and retrieve Heat templates from Swift
* update CLI as necessary

==== TripleO-UI ====

* update stack queries to take advantage Heat ResourceAttributes (make sure information is gotten through Heat)
* update deployment workflow

== Custom Roles ==

Although default, predefined roles are the immediate goal, it would be nice to also allow users to define their own roles. To do so, they would specify their own list of elements. Tuskar would then use that information to call out to diskimage-builder to create a custom image matching the role; and it would create a custom Heat template for that role that the master overcloud template could then use.

The remainder of the workflow is the same as with default roles.

==== TripleO ====

* given an image element, return the list of Heat parameters that it needs

==== Tuskar ====

* given a role specification, use diskimage-builder to construct a matching image (derived from the role's image elements)
* given a role specification, return the list of Heat parameters that it needs (derived from the role's image elements)
* given a role specification and its Heat parameters, construct a Heat template for that role that meets those specifications

==== TripleO-UI ====

* create custom role workflow

== High Availability ==

One of TripleO's top priorities for Juno is to allow the deployment of a High-Availability (HA) overcloud. We would like to extend Tuskar to ensure that it can be used to deploy a HA overcloud as well.

==== TripleO ====

* Deploy HA Overcloud
:* glusterfs
:* pacemaker, corosync
:* neutron (?)
:* heat-engine A/A
:* qpid proton (assuming amqp 1.0 have merged into oslo.messaging and oslo.messaging have merged in each core project. If not, will use rabbitmq)
:* etc etc

==== Tuskar ====

* allow the generation of Heat templates that support HA

==== TripleO-UI ====

* deployment workflow support for HA architecture

== Auto-Scaling ==

Having the option for an auto-scaling cloud deployment would be greatly appealing to many users. Heat is actively working on auto-scaling support, as are other projects.

==== Ceilometer ====

* Inhibit autoscaling during stack abandon/adopt (quiesce and revitalize)

==== Heat ====

* hooks to do cleanup on scale-down (e.g host evacuation etc) (https://blueprints.launchpad.net/heat/+spec/update-hooks)
* choose victim on scale-down, or specify strategy for choosing (e.g oldest first or newest first) (https://blueprints.launchpad.net/heat/+spec/autoscaling-parameters)
* support complex conditionals when choosing victim on scale-down (e.g get notification or poll metric via ceilometer related to occupancy or other application metrics); possibly handled by above, if we can get ceilometer to pass us appropriate data when signalling the scaling policy, TBC (''may not be required for Juno'')
* Method to inhibit autoscaling/alarms during abandon/adopt (and suspend/resume?)

==== TripleO ====

* update image elements to support auto-scaling

==== Tuskar ====

* allow the generation of Heat templates that support auto-scaling

==== TripleO-UI ====

* update deployment workflow to include options that allow an auto-scaled overcloud deployment

== Node Management (Ironic) ==

We would like to switchover to using Ironic in the near future, as there are a host of features that would depend upon it.

==== Ironic ====

* Ironic graduation
:* CI jobs
:* Nova driver
:* Serial console
:* Migration path
:* User documentation

* Autodiscovery of nodes
* Ceilometer
* Tagging
* scalability

==== Nova ====

* ensure that flavor metadata can include node tag values
* create a nova filter for exact matches to Ironic nodes (including all node metadata)

==== Heat ====

* Ironic resource plugin (''may not be required by us'')

== Metric Graphs ==

Data visualization is a key part of maintaining a cloud. We would like to start integrating Ceilometer usage into Tuskar.

==== Ceilometer ====

* Combine samples for different meters in a transformer to produce a single derived meter
* Rollup of course-grained statistics for UI queries
* Configurable data retention based on rollups
* Overarching "health" metric for nodes
* Ceilometer native auth for alarm notifications (and possibly metrics in future) (https://blueprints.launchpad.net/ceilometer/+spec/trust-alarm-notifier)
* Eliminate central agent SPoF
* SNMP batch mode, one bulk command per node per polling cycle

For additional data:

* Acquire hardware-oriented metrics via IPMI (e.g., voltage, fan speeds, etc.)
* Keystone v3 usage would avoid IPMI credentials; allowing pollster-style interaction
* Look into consistent hashing; see if it can be reused in ceilometer -- though it requires stateful DB

==== Ironic ====

* Add a periodic task to send hardware sensor data to ceilometer (https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer)

==== Tuskar ====

* add appropriate Ceilometer agents to generated Heat templates

==== TripleO-UI ====

* Add Ceilometer-based graphs and metric data

== User Interfaces ==

This is a general category intended to encapsulate work needed in the UI and CLI.

==== Horizon ====

* separate horizon from openstack-dashboard
* test the replacement of lesscpy with pyScss
* improve error handling so that messages are less generic
* additional work on the plugin architecture to support dynamic hardware-specific views

==== Tuskar-CLI ====

* create a tuskar-cli plugin for OpenStackClient

==== TripleO-UI ====

* increase the modularity of views
* investigate usage of Heat UI components in Horizon (for example, parameter form building)
* create a mechanism for asynchronous communication