Undercloud install should be automated by default

[Steven Hardy]

The final step after running quickstart.sh is to SSH to the undercloud and install the undercloud. From a new-user perspective I think this is confusing (hey, I just installed the undercloud!).

IMHO it's be better if we by default spawned the VM, then ran the undercloud install, including any workarounds we need in CI such as pinning versions etc.

A common problem for folks consuming upstream is we end up with stuff pinned in CI, like this:

https://github.com/openstack-infra/tripleo-ci/blob/master/scripts/tripleo.sh#L355

Developers work around it by running their undercloud install via tripleo.sh, but for new users it's a bad experience as the docs invariably diverge from what is tested in CI (e.g including the pinned versions).

So, I think we need to do one of:

- Run the undercloud install via ansible so it exactly matches CI (with a view to using it in CI)

- Generate images containing the exact versions of things used in CI, and ensure they're never changed during the ansible-automated undercloud install (which will really just be applying puppet).

[John Trowbridge (trown)]

I have been thinking about just using tripleo.sh for everything after the undercloud boots. We would then be doing exactly what CI does. The only difference would be the repo setup in the current image. That part overlaps the upstream image bug a bit:

https://bugs.launchpad.net/tripleo-quickstart/+bug/1569460

However, it could also be solved without a totally new image.
We could have a "dev" config file and a --dev option to quickstart.sh that takes the RDO image and adds the "current" repo for TripleO packages to both the undercloud and overcloud-full images before kicking off the undercloud install.
We would need to wire in using the deploy artifacts to get puppet modules from source in the overcloud as well.

[Steven Hardy (shardy)]

Yeah, I've not got a strong preference over whether we use tripleo.sh or not, perhaps going with that is the best first step, then we can evaluate if it makes sense to refactor that script (and each of it's actions) into native quickstart ansible in due course (related to discussion as to whether we can drive CI via quickstart instead of the script I guess).

Re the images - what you describe juggling repos sounds fine for a first step, but I'd really like to see the image based solution eventually - developers and new users have an awful time pulling a new environment together at a bad time (when we're suffering from trunk regressions), and using proven CI artefacts seems like a way to avoid that.

I guess having an option to just use current-tripleo somewhat mitigates that, but then we still need packaged puppet modules to avoid the from-source step (given that puppet modules are frequently what breaks us)

I'm kind of looking ahead with some of this stuff - quickstart is a big improvement on instack-virt-setup, but I think we can go further and provide hopefully a completely automated and proven-via-ci process that hugely improves the day-1 experience of TripleO :)

Here's my wishlist, FWIW:

1. Run a single command which results in a fully deployed and ready to use undercloud (both on virt and baremetal), after running it the next step should be deploying the overcloud.

2. Option to use pre-validated images (potentially undercloud although repos could work, definitely overcloud images so we reduce the image-build time and entropy for users).

3. Easily deploy any of stable/$release, trunk (current-tripleo), trunk (current-tripleo plus master-some-things, e.g what we test in CI), trunk (master all-the-things)

[John Trowbridge (trown)]

I think that wishlist is very reasonable.

We can track 1 with this bug.

I think 2 is what we have now, but the image is produced in RDO. Personally, I do not think that is an issue, as to me the undercloud image is like a giant container, which itself is like a package. I have intentionally postponed that discussion though, because 1 and 3 are issues no matter where the image is produced.

I would like to divide and conquer a bit on 3. I opened https://bugs.launchpad.net/tripleo-quickstart/+bug/1572958 for addressing the "what we test in CI" case, as that has the biggest potential impact on developer workflow.

The 'master all-the-things' case can actually be accomplished with the latest untested image in RDO.
The 'current-tripleo' case is a bit harder, but I really hope we can converge what RDO labels current-passed-ci, and what we use as current-tripleo. Then this just goes back to where the image gets produced.
The 'stable/$release' case is solved if we use the stable images in RDO, and I haven't seen a good argument not to.

[wes hayutin (weshayutin)]

FYI..
====================
re: Steve's comments
Here's my wishlist, FWIW:

1. Run a single command which results in a fully deployed and ready to use undercloud (both on virt and baremetal), after running it the next step should be deploying the overcloud.
====================

We've made nice progress w/ running quickstart against baremetal. We are now able to deploy to baremetal using:

1. A virtual undercloud that deploys to a baremetal overcloud
2. A undercloud installed on baremetal that deploys to a baremetal overcloud.

We'll have details out shortly.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/330176

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/330176
Committed: https://git.openstack.org/cgit/openstack/tripleo-quickstart/commit/?id=844cdd856b525cd739325fed14cffa0814d864ff
Submitter: Jenkins
Branch: master

commit 844cdd856b525cd739325fed14cffa0814d864ff
Author: John Trowbridge <email address hidden>
Date: Wed Jun 15 15:51:08 2016 -0400

    Move default stopping point to just before overcloud deploy

    For both the developer and new user use cases, there is rarely a
    need to do anything before the undercloud is installed and images
    and nodes are uploaded and registered. This patch moves up the
    default stopping point to just before the overcloud deploy command
    is run. This behavior is still changeable by changing the tags
    passed to quickstart.sh.

    Also fixes a small UI bug, where usage instructions get print out
    even when not using quickstart's default playbook. These instructions
    are unlikely to be accurate when used with a different playbook.

    Change-Id: I40eb8560732f266a1cd4ac37187e5fbb9b620b8e
    Closes-Bug: 1569477