Ir ansible20

.gitignore

@@ -35,3 +35,4 @@ doc/_build/
 fence_xvm.key
 vm-host-table
 tools/kcli/etc/kcli.cfg
+*.swp

blueprints/break-out-overcloud-playbooks.rst

@@ -0,0 +1,88 @@
+..
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
+ License.
+
+ http://creativecommons.org/licenses/by/3.0/legalcode
+
+..
+ This template should be in ReSTructured text. The filename in the git
+ repository should match the launchpad URL, for example a URL of
+ https://bugzilla.redhat.com/show_bug.cgi?id=<rfe_id> should be named
+ <rfe_id>.rst .  Please do not delete any of the sections in this
+ template.  If you have nothing to say for a whole section, just write: None
+ For help with syntax, see http://sphinx-doc.org/rest.html
+ To test out your formatting, see http://www.tele3.cz/jbar/rest/rest.html
+
+===========================
+Break out overcloud playbooks to match tripleo documentation
+===========================
+
+Introduction paragraph -- why are we doing anything?
+
+Problem description
+===================
+
+Originally spec'd out as a requirement for dell/dci integration in December 2015.
+Search Google docs for dci_dell_khaleesi integration.
+
+Integration:
+------------
+How can 3rd parties inject a custom workflow?  At the moment 3rd parties to CI
+are not able to inject requirements into the ci w/o making a change directly to the code path.
+
+Integration:
+------------
+Any 3rd party changes are difficult to integrate and test. The complete matrix of
+gates must be executed for any change.
+
+Time to results:
+----------------
+Breaking out a deployment into two parts undercloud and overcloud is not sufficient
+when users want to deploy a cloud by hand.  If there is an issue one must start from
+the beginning.
+
+Proposed change
+===============
+
+The change will breakout the overcloud playbooks to match the sections as described in [1].
+A user can follow the code in the playbooks and match it directly to documentation.
+
+[1] http://docs.openstack.org/developer/tripleo-docs/
+
+Alternatives
+------------
+
+none propoposed.
+
+Implementation
+==============
+
+Assignee(s)
+-----------
+- wes hayutin
+- harry rybacki
+
+
+Milestones
+----------
+
+Target Milestone for completion:
+
+  -  create directory structure that matches the tripleo documentation
+  -  move the content of the playbooks into the new playbooks
+  -  test virt, and baremetal deployments
+  -  test puddle and poodle jobs
+
+Work Items
+----------
+
+  - create directory structure that matches the tripleo documentation
+  - move the content of the playbooks into the new playbooks
+  - test virt, and baremetal deployments
+  - test puddle and poodle jobs
+
+
+Dependencies
+============
+
+none

blueprints/depends-on_rpm_build.rst

@@ -0,0 +1,129 @@
+..
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
+ License.
+
+ http://creativecommons.org/licenses/by/3.0/legalcode
+
+
+===========================
+rpm build for depends-on
+===========================
+
+Depends-on functionality is broken at this moment.
+
+
+Problem description
+===================
+
+If a comment on a patch has a depends-on: <hash>[:codeng]
+
+It is supposed to get those patchs and add to the current run. For exemple is a tripleoclient needs
+
+a review from tht it is expected that we will gate the tripleoclient with a patched tht with that review.
+
+But, right now that funtionality is not working. As we are no longer building on repos under a git
+
+clone on the {{ base_dir }} the way that depends-on is doing right now does not work. What we need
+
+is for it to use the patch-rpm and build package playbook to create the packages so we can upload
+
+it to the test run. Furthermore to make things more complicated there are two kinds of depends-on.
+
+The filepath-related changes like when a patch depends on another patch from khaleesi and
+
+khaleesi-settings and the rpm-related when a patch depends on a change on another rpm
+
+
+Proposed change
+===============
+
+
+The idea is to split the depends-on playbook into two playbooks
+
+depends-on-repo
+---------------
+
+That it will update the current HEAD of the repos under the base_dir
+
+
+depends-on-rpm
+--------------
+
+This will generate an extra small ksgen_settings.yml probably called extra_settings_{{num}}.yml
+
+that is going to be passed together with ksgen_settings.yml
+
+The extra_settings_<num>.yml would be jus the needed change to the ksgen_settings and it would be
+
+something like:
+
+
+.. code-block:: yaml
+    gating_repo: openstack-tripleo-heat-templates
+    patch:
+      dist_git:
+        branch:
+          7-director: rhos-7.0-pmgr-rhel-7
+          8-director: rhos-8.0-director-rhel-7
+        name: openstack-tripleo-heat-templates
+        url: 'http://pkgs.devel.redhat.com/cgit/rpms/openstack-tripleo-heat-templates'
+      gerrit:
+        branch: rhos-7.0-patches  # the filled up branch from the dependend review
+        name: gerrit-openstack-tripleo-heat-templates
+        refspec: refs/changes/41/65241/9 # the filled up refspec from the dependend review
+        url: 'https://code.engineering.redhat.com/gerrit/openstack-tripleo-heat-templates'
+      upstream:
+        name: upstream-openstack-tripleo-heat-templates
+        url: https://git.openstack.org/openstack/tripleo-heat-templates
+
+
+So a job would look like this:
+
+
+.. code-block:: bash
+    # fetch dependent gating changes for khaleesi and khaleesi-settings
+    if [ $GERRIT_CHANGE_COMMIT_MESSAGE ]; then
+        ansible-playbook -i local_hosts -vv playbooks/depends-on-repo.yml
+    fi
+
+    # generate config
+    ksgen --config-dir settings generate \
+
+        ... yada yada yada
+
+        --extra-vars @../khaleesi-settings/settings/product/rhos/private_settings/redhat_internal.yml \
+        ksgen_settings.yml
+
+    # fetch dependent gating changes for related rpms
+    if [ $GERRIT_CHANGE_COMMIT_MESSAGE ]; then
+        ansible-playbook -i local_hosts -vv playbooks/depends-on-rpm.yml
+    fi
+
+    for extra_settings in extra_settings_*.yml; do
+        if [ -e "$extra_settings" ] ; then
+          ansible-playbook -vv --extra-vars @ksgen_settings.yml  --extra_vars @$extra_settings -i local_hosts playbooks/build_gate_rpm.yml;
+        fi;
+    done
+    #now the built rpms are in the base_dir/generated_rpms/*.rpm
+
+    ... continue with the deployment ...
+
+
+The second extra-vars will overwrite the common parameters of the ksgen_settings allowing us to
+
+build multiple packages The downside is that it will only work for the packages that we know how
+
+to build rpms.
+
+
+Implementation
+==============
+
+Assignee(s)
+-----------
+
+Primary assignee:
+
+  apetrich@redhat.com
+
+

blueprints/ospd8-undercloud-deploys-ospd7-overcloud.rst

@@ -0,0 +1,61 @@
+..
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
+ License.
+
+ http://creativecommons.org/licenses/by/3.0/legalcode
+
+===========================
+Deploy a ospd-7 overcloud using an ospd-8 undercloud
+===========================
+
+We have some requirements from PM to deploy a ospd-7 overcloud using an
+ospd-8 undercloud. PM would like this in CI's status jobs.
+
+Problem description
+===================
+
+Consult PM
+
+Proposed change
+===============
+
+- Deploy the undercloud
+- Remove the tripleo-heat-templates for opsd-8
+- Install the tripleo-heat-tempeates for ospd-7
+- Rerun ksgen for ospd-8
+- Deploy
+
+Alternatives
+------------
+
+None
+
+Implementation
+==============
+
+Assignee(s)
+-----------
+whayutin@redhat.com
+
+Milestones
+----------
+
+- Deploy the undercloud
+- Remove the tripleo-heat-templates for opsd-8
+- Install the tripleo-heat-tempeates for ospd-7
+- Deploy
+
+Work Items
+----------
+
+- test deployment in a dev enviornment
+- build POC job
+- build new jjb builder, template
+- test POC job
+- test w/ baremetal
+- push to production
+
+Dependencies
+============
+
+- The playbooks must be able to be called independently

blueprints/templates/template.rst

@@ -0,0 +1,93 @@
+..
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
+ License.
+
+ http://creativecommons.org/licenses/by/3.0/legalcode
+
+..
+ This template should be in ReSTructured text. The filename in the git
+ repository should match the launchpad URL, for example a URL of
+ https://bugzilla.redhat.com/show_bug.cgi?id=<rfe_id> should be named
+ <rfe_id>.rst .  Please do not delete any of the sections in this
+ template.  If you have nothing to say for a whole section, just write: None
+ For help with syntax, see http://sphinx-doc.org/rest.html
+ To test out your formatting, see http://www.tele3.cz/jbar/rest/rest.html
+
+===========================
+The title of your blueprint
+===========================
+
+Introduction paragraph -- why are we doing anything?
+
+Problem description
+===================
+
+A detailed description of the problem.
+
+Proposed change
+===============
+
+Here is where you cover the change you propose to make in detail. How do you
+propose to solve this problem?
+
+If this is one part of a larger effort make it clear where this piece ends. In
+other words, what's the scope of this effort?
+
+Include where in the Khaleesi tree hierarchy this will reside.
+
+Alternatives
+------------
+
+This is an optional section, where it does apply we'd just like a demonstration
+that some thought has been put into why the proposed approach is the best one.
+
+Implementation
+==============
+
+Assignee(s)
+-----------
+
+Who is leading the writing of the code? Or is this a blueprint where you're
+throwing it out there to see who picks it up?
+
+If more than one person is working on the implementation, please designate the
+primary author and contact.
+
+Primary assignee:
+
+  TBD: <bugzilla-id, gerrithub-id, or None>
+
+Can optionally can list additional ids if they intend on doing
+substantial implementation work on this blueprint.
+
+Milestones
+----------
+
+Target Milestone for completion:
+
+  TBD: As Khaleesi has no current 'release cycle' it's hard to project time lines and
+  allocate resources accordingly. This is something we should discuss.
+
+Work Items
+----------
+
+Work items or tasks -- break the feature up into the things that need to be
+done to implement it. Those parts might end up being done by different people,
+but we're mostly trying to understand the time line for implementation.
+
+- <Task 1>: <description>
+
+- <Task 2>: <description>
+
+  ...
+
+- <Task N>: <description>
+
+Dependencies
+============
+
+- Include specific references to specs and/or blueprints in Khaleesi, or in other
+  projects, that this one either depends on or is related to.
+
+- Does this feature require any new library dependencies or code otherwise not
+  included in OpenStack? Or does it depend on a specific version of library?