Giter Site home page Giter Site logo

ansible-role-tripleo-image-build's Introduction

Role Name

ansible-role-tripleo-image-build

This is a standard Ansible role, and can be installed as a dependency via ansible-galaxy, pip, or your own mechanism(s)

Consumers of this role (known)

Anyone who wants to build images. Tools such as:

via Ansible Galaxy

ansible-galaxy -v install -p roles-from-galaxy -r requirements-build.yml

- extracting ansible-role-tripleo-image-build to roles-from-galaxy/ansible-role-tripleo-image-build
- ansible-role-tripleo-image-build was installed successfully

requirements-build.yml

# from GitHub
   - sec: git+ssh://github.com/redhat-openstack/ansible-role-tripleo-parts
   - src: git+ssh://github.com/redhat-openstack/ansible-role-tripleo-image-build

# local files
#  - src: file:///home/me/ci/ansible-role-tripleo-image-build

via Python Setup Tools (virtualenv, pip) C.A.T.

In addition to supporting Galaxy, this role allows for being installed via pip. A file is provided in the root of this repo (setup.cfg) that will install the necessary files in egg form.

pip install -r requirements-build.txt

That file might look like this

requirements-build.txt

pbr>=1.6
ansible==2.0.1

git+https://github.com/redhat-openstack/ansible-role-tripleo-parts.git#egg=ansible-role-tripleo-parts
git+https://github.com/redhat-openstack/ansible-role-tripleo-image-build.git#egg=ansible-role-tripleo-image-build

# to pull in local development changes
#file:///home/me/ci/ansible-role-tripleo-image-build/#egg=ansible-role-tripleo-image-build

via ARTIB test script (tests/build.sh)

In addition to the methods described above to reference and/or import this role into your own project, a sample script is provided that allows for creating images directly from a clone of this git repository. If you have ideas on how to make this role better (and want to contribute) please see below for details on how to submit a patch.

build.sh is an easy way to quickly see how image building works, and iterate on this role locally.

build.sh

pushd tests/pip
./build.sh $VIRTHOST

Full options for build.sh

./build.sh [options] virthost

   -i, --install-deps            Install C.A.T. dependencies (git, python-virtualenv, gcc, libyaml)

 * Basic options w/ defaults
   -p, --playbook <playbook>     default: 'build_default_images.yml', Specify playbook to be executed.
   -z, --requirements <file>     default: 'requirements-build.txt', Specify the python setup tools requirements file.
   -r, --release <release>       default: 'mitaka',  { kilo | liberty | mitaka }
   -b, --base_os <os>            default: 'centos7', { centos7 | rhel }
   -u, --base_url <url>          Must be resolvable from $virthost. Shortcut for: \'-e artib_minimal_base_image_url=<url>\'
   -e, --extra-vars <file>       Additional Ansible variables.  Supports multiple ('-e f1 -e f2')
   -o, --output <logfile>        tee output to file

 * Advanced options
   -w, --working-dir <directory> Location of ci-ansible-tripleo sources and virtual env
   -c, --clean                   Clean the virtualenv before running a deployment
   -g, --git-clone               Git clone --> ssh://github.com/redhat-openstack/ansible-role-tripleo-image-build
   -s, --system-site-packages    Create virtual env with access to local site packages
   -v, --ansible-debug           Invoke ansible-playbook with -vvvv
   -h, -?, --help                Display this help and exit

Example Playbook

Note: this sample playbook leverages a simple role that dynamically adds $VIRTHOST (via 'virthost') to the Ansible inventory.

  hosts: localhost
  roles:
    - { role: add-inventory-virthost, virthost: "$VIRTHOST" }

    - name: Build images using defaults (rdo, mitaka, centos7)
      hosts: virthost
      remote_user: root
      roles:
        - parts/kvm
        - parts/libvirt
        - ansible-role-tripleo-image-build

Requirements

This role requires libguestfs, virt-customize, virt-sparsify, and other dependencies installed and configured via parts/kvm and parts/libvirt.

How does it work?

meta/main.yml pulls in the following dependencies that setup KVM, libvirt, and libguestfs. These are provided by ansible-role-tripleo-parts

  • parts/kvm
  • parts/libvirt

tasks/main.yml After nuking the working directory:

  • (repo_setup.yml) Get the base image and setup yum repositories
  • (package_install.yml) Install packages for overcloud base image
  • (convert_undercloud.yml) Use overcloud base image to create undercloud base image
  • (dib_build.yml) Use DIB to build the overlcloud-full and IPA images, leveraging support from tripleo-common
  • (undercloud_inject.yml) Inject overcloud-full and IPA images into the undercloud image

Notes:

  • The overcloud image is constructed by a series of calls to virt-customize, part of libguestfs to run scripts that 'yum install' directly to the qcow2. Other utilities from this toolset are also used to grow/shrink/sparsify/manipulate the image(s).
  • The undercloud qcow is generated by starting with the overcloud and adding/removing a few packages.
  • The overcloud and IPA images are then written --> undercloud image, so when undercloud.qcow2 is booted by tripleo-quickstart, the overcloud image is present and ready to be deployed.

Logs

All land in working_dir.

The builder logs are a canonical log of how the qcow2's are created, and is the best, first place to look/explore.

  • builder-undercloud.log
  • builder-overcloud.log

Content Manifests (every file, size, mode, etc)

  • content-undercloud.csv
  • content-overcloud.csv

Additional per-phase (potentially verbose) logs are found in working directory

Role Variables

The defaults for image building are located at defaults/main.yml. With no params specified this role will build images for:

  • Mitaka (RDO, delorean, current-passed-ci)
  • http://trunk.rdoproject.org/centos7-mitaka/{{ artib_delorean_hash | default('current-passed-ci')}}/delorean.repo
  • CentOS 7 base image
  • Disk Image Builder (DIB) tools from liberty are used
  • images are built in $virthost:/home/oooq-images

To change or customize how images are built and what they contain, enabling scenarios such as:

  • {rdo, rhos} x {centos, rhel}
  • RPM's, container (future), built from source (future)
  • additional test tools or configuration (be vocal, submit issues/blueprints!)
Variable Description
artib_working_dir All artifacts are created here.
artib_release (rdo only): mitaka, liberty
artib_dib_prepare_script Jinja2 template bash script used to prepare host for building images with DIB
artib_dib_release_rpm where DIB itself comes from. Default: "http://rdoproject.org/repos/openstack-liberty/rdo-release-liberty.rpm"
artib_minimal_base_image_url base image for undercloud and overcloud
artib_repo_script Jinja2 template bash script used to install repositories on base image for binaries via virt-customize
artib_undercloud_remove_packages the undercloud image is generated by starting with the overcloud, removing packages from, and adding packages to it. This is the list of packages to remove
artib_undercloud_install_packages ^ this is the list of packages to add
artib_overcloud_package_list the set of packages installed (by yum) on the images. Default: vars/default_package_list.yml
artib_overcloud_images the list of artifacts that are packaged and published by invoking this role
artib_vc_verbose (default: false) set to true for verbose virt-customize output
artib_vc_trace (default: false) set to true for trace/dbg virt-customize output
artib_dib_remove_epel if true, removes epel from the DIB elements tree with hostility
artib_dib_workarounds enabled (true) by default, this causes an additional virt-customize pass specifically to massage DIB inputs for temporary workarouds
artib_dib_workaround_script ^ the script for this
artib_overcloud_build_mode python module (default), "openstack overcloud image build", or "tripleo-build-images"

Here are the full defaults contained in defaults/main.yml. Note that most are internal and should not be modified.

# defaults file for ansible-role-tripleo-image-build

# global build vars
artib_working_dir: /var/lib/oooq-images
# Whether or not to delete the working directory before starting.
artib_start_over: true

# repo_setup vars
artib_minimal_base_image_url:
  http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2
# global build vars
artib_working_dir: /var/lib/oooq-images

# delete working directory prior to building images.
artib_start_over: true

# repo_setup vars
artib_minimal_base_image_url:
  http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2
artib_minimal_overwrite_existing: no
artib_base_os: centos7
artib_release: mitaka
artib_build_system: delorean
artib_image_stage_location: testing
artib_repo_script: "repo-{{ artib_base_os }}-{{ artib_build_system }}.sh.j2"

#swapfile arguments
artib_swapfile_script: swapfile-create.sh.j2

# package_install vars
artib_overcloud_base_image_url:
  "file:///{{ artib_working_dir }}/minimal-base.qcow2"
artib_overcloud_overwrite_existing: no
artib_package_install_script: package-install-default.sh.j2
artib_overcloud_package_list: default_package_list.yml

# convert_undercloud vars
artib_undercloud_base_image_url:
  "file:///{{ artib_working_dir }}/overcloud-base.qcow2"
artib_undercloud_overwrite_existing: no
artib_undercloud_convert_script: undercloud-convert-default.sh.j2
artib_undercloud_disk_size: 42

artib_vc_ram: 8192
artib_vc_cpu: 4
artib_vc_verbose: false
artib_vc_trace: false

# undercloud == overcloud (+/-) packages
artib_undercloud_remove_packages:
  - cloud-init
  - mariadb-galera-server
  - openstack-sahara*
  - python2-barbicanclient
artib_undercloud_install_packages:
  - mariadb-server
  - python-tripleoclient
  - openstack-tempest
  # -tests packages which contains tempest-style tests
  - python-aodh-tests
  - python-ceilometer-tests
  - python-heat-tests
  - python-ironic-tests
  - python-keystone-tests
  - python-manila-tests
  - python-mistral-tests
  - python-neutron-tests
  - python-sahara-tests
  - python-zaqar-tests
artib_undercloud_selinux_permissive: true

##################
# dib_build vars #
##################

#
# default  is to use an ansible module (python_module_tripleo_build_images) to invoke tripleo-common's python class directly
# ansible-role-tripleo-image-build/library/tripleo_build_images.py
#
# "openstack_overcloud_image_build" enable the upstream tripleo doc'd mechanism
# https://docs.openstack.org/developer/tripleo-docs/post_deployment/build_single_image.html
# note this is for ocata+ / osp 11+.
#
# "tripleo_build_images" call tripleo-build-images from tripleo-common.
# valid for mitaka/newton osp 9/10 only
#
artib_overcloud_build_mode: python_module_tripleo_build_images

# creates yaml file passed to the tripleo-common image building library
artib_image_yaml_template: "dib-manifest-default.yaml.j2"

# sets the filesystem type for overcloud-full image
artib_overcloud_fs_type: "xfs"

# https://github.com/redhat-openstack/ansible-role-tripleo-image-build/issues/15
artib_dib_workarounds: true
artib_dib_workaround_script: dib-workaround-default.sh.j2

artib_dib_elements_path:
  - /usr/share/tripleo-image-elements
  - /usr/share/tripleo-puppet-elements
  - /usr/share/instack-undercloud/
  - "{% if artib_release == 'mitaka' %}/usr/share/openstack-heat-templates/software-config/elements/{% endif %}"

# set up build host (build tools, etc)
artib_dib_prepare_script: dib-prepare-centos7-default.sh.j2

artib_dib_remove_epel: true

# TODO: currently we build by default with mitaka rpm...though IMHO this should track whatever release we are building
# "http://rdoproject.org/repos/openstack-{{ artib_release }}/rdo-release-{{ artib_release }}.rpm"
artib_dib_release_rpm:
  "http://rdoproject.org/repos/openstack-mitaka/rdo-release-mitaka.rpm"

# injected --> undercloud.qcow2
artib_overcloud_images:
  - ironic-python-agent.initramfs
  - ironic-python-agent.kernel
  - overcloud-full.initrd
  - overcloud-full.qcow2
  - overcloud-full.vmlinuz

# fail, ignore, continue.  See http://libguestfs.org/virt-sparsify.1.html
artib_virt_sparsify_checktmpdir_flag: fail

# artib_publish_dest_user:     username
# artib_publish_dest_host:     foo.example.com

# artib_publish_dest_basepath: /var/www/html/yourchoice
# artib_publish_create_dest_via_ssh: false

artib_publish: false
artib_publish_artifacts:
  - undercloud.qcow2
  - undercloud.qcow2.md5
  - ironic-python-agent.tar
  - ironic-python-agent.tar.md5
  - overcloud-full.tar
  - overcloud-full.tar.md5
  - artib-logs.tar.gz
  - artib-logs.tar.gz.md5

Dependencies

No other galaxy roles are leveraged. libvirt and portions of KVM are used to build images via parts/kvm, and parts/libvirt

How to contribute

Contributions and patches are welcome! Feel free to log issues and/or discuss here:

https://github.com/redhat-openstack/ansible-role-tripleo-image-build/issues

Code reviews and patches are managed by Gerrit here:

https://review.gerrithub.io/#/q/project:redhat-openstack/ansible-role-tripleo-image-build

Ideas for substantive changes and/or features/targets/requirements are heartily welcomed. Please do reach out on IRC (freenode) at #rdo or #tripleo, or please submit a blueprint here:

https://github.com/redhat-openstack/ansible-role-tripleo-image-build/blueprints

How to: setup env --> propose a patch:

$ git clone ssh://github.com/redhat-openstack/ansible-role-tripleo-image-build
$ cd ansible-role-tripleo-image-build/
$ git review -s
Creating a git remote called "gerrit" that maps to:
	ssh://[email protected]:29418/redhat-openstack/ansible-role-tripleo-image-build.git

$ git remote -v
gerrit	ssh://[email protected]:29418/redhat-openstack/ansible-role-tripleo-image-build.git (fetch)
gerrit	ssh://[email protected]:29418/redhat-openstack/ansible-role-tripleo-image-build.git (push)
origin	ssh://github.com/redhat-openstack/ansible-role-tripleo-image-build (fetch)
origin	ssh://github.com/redhat-openstack/ansible-role-tripleo-image-build (push)
  • create a branch (git checkout -b my-groovy-idea)
  • add files and commit
  • Post review (git review)

The commit message should be of the form:

A single line description of the change

A multi-line description of the change, ideally with
context and/or URL to github issue.

To address feedback and iterate on reviews, amend your existing commit (git commit --amend) and run "git review" again. Be sure to leave the Change-Id alone!

License

Apache 2.0

Author Information

redhat-openstack

ansible-role-tripleo-image-build's People

Contributors

amoralej avatar gabrielecerami avatar gbraad avatar gfidente avatar halcyondude avatar jaormx avatar matbu avatar sshnaidm avatar strider avatar tosky avatar weshayutin avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ansible-role-tripleo-image-build's Issues

add self-test for role

add script + basic playbook to generate images using defaults, with minimal dependencies. This [can & will] be used as base CI gate.

DIB elements passed to disk-image-create are hard coded

In tasks/dib_build.yml, when we call disk-image-create, the elements for the IPA and overcloud are hard coded. they should be a list defined in yaml, bonded to a variable that can be over-ridden.

This will help with making this more declarative, and for building non centos7 / non-RDO, is needed to keep things clean (and to keep keyboards from catching fire @weshayutin @trown)

This issue tracks migrating the hard coded lists (overcloud and IPA) --> variables.

Here's an example of where we build IPA:

shell: |
source {{ artib_working_dir }}/dib-optional-env-inject.sh
disk-image-create
-a amd64
-o {{ artib_working_dir }}/ironic-python-agent
centos7
dhcp-all-interfaces
dynamic-login
selinux-permissive
pip-and-virtualenv-override
ironic-agent
-p python-hardware-detect
--min-tmpfs 5 2>&1 | tee {{ artib_working_dir }}/dib-agent-ramdisk.log
environment:
DIB_LOCAL_IMAGE: "{{ artib_working_dir }}/minimal-base.qcow2"
DIB_DEFAULT_INSTALLTYPE: package
ELEMENTS_PATH: "{{ artib_dib_elements_path }}"
async: 3600
poll: 0
register: done_build_ironic

wrap call to tripleo-common in a jinja script

Now that we're calling tripleo-common with a manifest for the DIB invocation, we should wrap it in a bash jinja template, so debugging is simple / clear. Presently it's a PITA to debug things when they fail. It helps to keep the temp files around and debug in that fashion, but unlike the other steps there are no .sh artifacts that will reproduce a failed step (the actual tripleo-common call).

Handle input URL's with 302 / redirects

A change just landed in tripleo-quickstart to allow for handling 302 reply/redirects when downloading images.


openstack-archive/tripleo-quickstart@2118318

Add -L option for curl during image downloads
Some images will be hosted on CDNs that will redirect our attempts with
a 302 reply. By default curl won't follow these, so we would get an
incomplete image download.
Change-Id: Ifc9d72f93f0fc52ed83bc092ca188e4ddf516654


We should do the same thing where we download base images.

https://github.com/redhat-openstack/ansible-role-tripleo-image-build/blob/master/tasks/repo_setup.yml#L13

This is another instance where having shared image download / cache used by both quickstart and this role would remove duplication.

Fix the things in dib-workaround script in the right place

https://github.com/redhat-openstack/ansible-role-tripleo-image-build/blob/master/templates/dib-workaround-default.sh.j2 is some technical debt that we should try to pay off in order to make this more attractive to upstream TripleO.

One solution would just be to go back to including those elements in the build... This just goes back to hiding the tech debt in DIB though. I think for the overcloud-full element and the puppet-modules element, this is probably the way to go.

For os-collect-config, and sahara, those should be fixed in the respective packaging.

meta/main.yml has a typo which causes ansible-galaxy to cry

I am trying to pull in this role via ansible galaxy command:
ansible-galaxy install -p ~/.quickstart/tripleo-quickstart/playbooks/roles/ -r ~/.quickstart/tripleo-quickstart/ansible-role-requirements.yml --force

with ansible-role-requirements.yml:

- name: image-build
  src: https://github.com/redhat-openstack/ansible-role-tripleo-image-build
  scm: git
  version: master

This results in:

[WARNING]: - image-build was NOT installed successfully: this role does not appear to have a valid meta/main.yml file.

oooq for liberty is currently broken due to drift in delorean-deps. Create status deps repo

As one can see from https://ci.centos.org/view/rdo/view/tripleo-periodic/ the liberty jobs have been red since a packaging change w/ python-oslo in delorean-deps caused the undercloud to fail to install.

The delorean repo is versioned w/ a hash, so this is static and not an issue.
The delorean-deps repo is provided by centos and is not versioned and can change.

New image building requirement for RDO and TripleO images

  • We need a static yum repo for delorean-deps.

While building the image we should.

  1. reposync the delorean-deps repo down to the virtguest that will serve as the base image.
  2. Setup the yum repo file for delorean-deps to serve from file:/// vs. https

Original

[delorean-mitaka-testing]
name=dlrn-mitaka-testing
baseurl=http://buildlogs.centos.org/centos/7/cloud/$basearch/openstack-mitaka/
enabled=1
gpgcheck=0
priority=2

Proposed:

[delorean-mitaka-testing]
name=dlrn-mitaka-testing
baseurl=file:///user/share/deloreand-deps/openstack-mitaka/
enabled=1
gpgcheck=0
priority=2

Obviously change the names based on the release

Helpful links:
http://bencane.com/2013/04/15/creating-a-local-yum-repository/
https://access.redhat.com/solutions/23016

Plenty of ways to speed this up, but can discuss them outside of this ticket.

infra errors during DIB setup + virt-customize are not caught automatically

When rpm's are not available, or packaging conflicts occur during yum install portions of image build, they silently go into either /tmp/builder.log in the libguestfs appliance, or to the output of one of the later phases. The role then typically fails later, when either the image is not constructed correctly or simply does not exist (primary scenario).

This incurs a manual debug / investigation of the logs to find the culprit. This issue is to track the addition of either more intelligent log auto-scrubbing than we do now (ample opportunity for improvement) and/or earlier failure where possible (e.g., if an error happened during setup of DIB and build host, don't run dib itself, only to fail later.


A concrete example:
Adding new version of Ceph for newton:

Root cause was that the dib setup script was making ref to a bad URI

and the following error was being silently ignored:

@weshayutin FYI

Add fluentd and sensu to overcloud package list (master)

Per discussion with @larsks, we want to add the following packages to the overcloud package list.

  • fluentd
  • sensu

from the following repo:

This is to support centralized logging and the new OpsTools group

Currently it looks like the URI's defined in the repo from discussion are not yet live...

@larsks please advise. @trown, @weshayutin FYI

undercloud upload: role or config option

A method in which a file location can used to upload files / directories onto a deployed undercloud instance.

Example:

- name: undercloud fetch service.
  upload:
       src: "{{ path_to_files }}" or "{{ url }}"
       dest: "{{ upload_dir }}" 

scope variables with a prefix

all variables need to be scoped to this role, so we don't pollute the global namespace, and to ensure we don't break suddenly when someone uses a common name that we happen to use here. See here for more details (https://galaxy.ansible.com/intro#variables). Since having variables names like "ansible-role-tripleo-image-build-overcloud_overwrite_existing" would be silly, using the following prefix is not (in comparison):

artib_ ("ansible-role-tripleo-image-build_")

so... "artib_overcloud_overwrite_existing" isn't wonderful, but would suffice.

RFE Remove explicit package installs

In the current method of building up images, we pre-install all of the packages we might need in the base image, then feed this image to DIB to do the overcloud image builds, and finally modify the installed packages slightly to create the undercloud image.

This has the benefit of efficiency since we only download the packages once, but the drawback that we need to maintain a list of the packages to install. We recently updated our image building YAML to include the right upstream elements so that we will always get the right packages installed. However, as new packages are added to those elements, we will gradually lose our efficiency gain if we don't also update the package list.

Instead of maintaining a list of packages to install, we can instead pre-download every package from the delorean and delorean-deps repos without installing any of them. This will give us the same efficiency gain, without having to maintain any lists of packages.

There is another issue open #20, that would benefit from this approach. By using locally snapshot repos like this, we would be guaranteed to get the same content at run time as passed CI.

There is a WIP patch up to add the reposync to the build here. Beyond what is in that patch the other work items would be:

  1. update tripleo-quickstart to explicitly install python-tripleoclient prior to running openstack undercloud install
  2. remove all package lists from this project

self test: misc nits and naggles

Since build.sh is likely the first experience for someone experimenting with this role/code, we should leave a happy paved path for new contributors.

  • if you run ./build.sh with no args, you don't get the same pretty help text (--help) but instead a pile of - yuck.
  • build output contains double printing of time stamps per task. It's because the callback plugin we were using has now merged upstream in ansible so it's loaded twice (once from ansible 2+, once from local copy
  • it relies on being run from where it sits (relative path in pip-ansible-env.sh) and doesn't gracefully handle the situation where it's not.
  • help text doesn't make clear that to test local edits you need to modify requirements-build.txt. Note: that this isn't unique here, everything in the oooq library has the same issue.
  • when making a series of local edits, you end up running from the pip cache. need to add --no-cache-dir like quickstart does.
  • fix "no arg" invocation
  • fix build output
  • fix relative path
  • add --no-cache-dir to pip install

unify how env for DIB is generated --> .j2

Presently, the set of env vars set for disk-image-create (part of DIB) is specified both in Ansible as well as bash format.

- name: Build the ironic-python-agent ramdisk
  shell: |
    source {{ working_dir }}/dib-optional-env-inject.sh
    disk-image-create \
*** SNIP: DIB elements and packages ***
    --min-tmpfs 5 2>&1 | tee {{ working_dir }}/dib-agent-ramdisk.log
  environment:
    DIB_LOCAL_IMAGE: "{{ working_dir }}/minimal-base.qcow2"
    DIB_DEFAULT_INSTALLTYPE: package
    ELEMENTS_PATH: "{{ dib_elements_path }}"

While the way the local image and elements path are defined is more "Ansible nice" - the common theme through quickstart / CI is to emit bash that remove ambiguity about what was executed, and allows for ssh'ing to a machine and re-running exactly what was run.

This issue is to track ensuring that the "ansible" style env variables migrate to thejinja template. This file should also be renamed to remove the "optional" part.

implement 1-hop copy for publishing images (vs. 2)

moved from: redhat-openstack/tripleo-quickstart#64

halcyondude commented 18 days ago

Background: the existing publish role in oooq uses fetch to copy everything from ansible target (virthost in this case) where the images are built --> localhost (or the jenkins slave in the CI use case). They are then copied with a shell block calling rsync, from localhost to publishing destination.

On our jenkins slaves this is problematic as the images are single-digit GB in size, and the default home disk for the slaves is 20G . The existing playbook does clean up localhost after the copy, but already I've had a few failures in POC jobs due to space issues on the slaves.

This issue is to track creating a simple 1-hop (vs. existing 2-hop) variant of the publish role. Goal is for it to be small, simple, no frills. It will be useful for CI + developers using tripleo-quickstart image building to cook their own custom images.

It should use delagate to (from) --> publishing_dest using the synchronize standard module (instead of shell: rsync).

The existing playbook will be left alone. We still do require the 2 hop, rsync protocol only (vs ssh) implementation for RDO CI, as there is not direct routes between image build location --> publishing endpoint.

make output for failed job during tripleo-common exist

When the failures happen during DIB, we get logs, but the ansible output is fairly worthless. One always has to look in the logs generated by the tripleo-common library, and can never tell from the ansible output what the issue is/was, nor what logs to look in. The experience is sub-optimal. Here's an example of a failure:

TASK [tripleo-image-build : Build the overcloud-full image] ********************
task path: /home/matyoung/ci/ansible-role-tripleo-image-build/tests/pip/wd-mitaka/usr/local/share/ansible/roles/tripleo-image-build/tasks/dib_build.yml:69
Thursday 11 August 2016  15:20:15 -0400 (0:00:03.088)       0:19:39.769 ******* 
fatal: [centos-kvm]: FAILED! => {"changed": false, "failed": true, "msg": ""}

TASK [tripleo-image-build : fail] **********************************************
task path: /home/matyoung/ci/ansible-role-tripleo-image-build/tests/pip/wd-mitaka/usr/local/share/ansible/roles/tripleo-image-build/tasks/main.yml:46
Thursday 11 August 2016  15:20:16 -0400 (0:00:00.995)       0:19:40.764 ******* 
fatal: [centos-kvm]: FAILED! => {"changed": false, "failed": true, "msg": "*** Image Build Error ***"}

add support to output other disk formats

Add support to export additional file formats. Details on how. This would involve merely adding "-t " to DIB passes.

low hanging fruit...output any of these:

  • qcow2
  • tar
  • vhd
  • docker
  • raw

In particular, the docker image option is pretty interesting to think about IMHO. We could have them auto-uploaded to a dockerhub.

@weshayutin @rthallisey

Refactor repo location

Currently, the repository location for packages is 'harcoded' inside the template:

  • /ansible-role-tripleo-image-build/templates/dib-prepare-centos7-default.sh.j2
  • /ansible-role-tripleo-image-build/templates/repo-centos7-delorean.sh.j2

which makes it harder to override these paths when wanting to create an image with specific packages.

Use tripleo-common library to build images instead of direct DIB invocation

When I started on tripleo-quickstart, I had a chicken/egg problem in that I wanted to work on a tool that consumed an undercloud image, but there was no undercloud image produced. At the time, the only abstraction of DIB available was python-tripleoclient. However, this was not a good abstraction, as it made lots of assumptions that were difficult to override. This is all to explain why there is direct usage of DIB in this role.

The problem with using DIB with no abstraction on top, is that we have different images we would like to support. Right now, all of the upstream images can be produced with the same set of elements, however that is not guaranteed to be true in the future. Also, building images with a different distro, or even trying to use a different base element for the same distro (centos-minimal vs centos7) can not be easily done without some abstraction on top of DIB.

We could write that abstraction layer ourselves, since we are already using jinja templated bash to call DIB. However, that means that any improvements we would need to make over time to that layer would be locked away in this role. It turns out that there is now a better way. Since openstack-archive/tripleo-common@981c084 we are able to pass yaml definitions for images into the tripleo-common library.

That commit adds a handy python script for interacting with the image building library. https://github.com/openstack/tripleo-common/blob/981c084014226cad725bdf4929608373bc848ef7/scripts/tripleo-build-images

We can use that script as a guide to create an image build module in this role that similarly passes arbitrary yaml configs to the tripleo-common image building library.

Caching of the base image

The generic cloud image for image is now pulled from cloud.centos.org. this step happens every time. It can be overriden with a different location. However, implementing a caching strategy as used in tripleo-quikcstart might be a helpful addition.

image building: make logs / output more accessible and usable

Moved over from: redhat-openstack/tripleo-quickstart#53

Currently the output from the playbook that builds images is a bit of a land-mine. In the case of the output from DIB when it creates the overcloud image, it ends up being > 400,000 characters on a single line. This literally makes Atom, Emacs, PyCharm, Gedit, Kate, VIM, etc go into a death loop trying to parse the line. If one waits far longer than I have patience for (minutes) eventually you'll get back. Interim solutions are to not use the ansible output directly, rather passing it thru sed first to turn \n into \n, open the logfile that's captured, etc. It's a low priority issue, but the first time it happened to me I thought "Ouch...that hurt..." As this project catches on I think anything that increases friction for developers / newcomers should where possible be fixed. In addition, it would be pretty cool to have a nice summary of what was built, the source of the

refactor parts/libvirt and parts/kvm out of this role entirely

The image building role depends on a few packages from kvm and libvirt. The existing role pulls these in via meta (good) pointing to parts/* (bad). Specifically it pulls in these packages and service:

https://github.com/redhat-openstack/ansible-role-tripleo-image-build/blob/master/parts/libvirt/defaults/main.yml

and does some basic KVM config operations here:

https://github.com/redhat-openstack/ansible-role-tripleo-image-build/blob/master/parts/kvm/tasks/main.yml

This issue tracks migrating this out of this role --> something generic, so this role can remain clean/portable.

sync image yaml to tripleo-common

We presently have yaml for the DIB manifest that has drifted (again) from upstream.

This issue tracks not fixing it to always be in sync, but to sync it now (stopgap).

As this entire role/project is likely to be retired in the near term in favor of something else (TBD) upstream, we just need a band-aid at this point.

abstract: images built (and metadata needed to do so)

The current implementation has 2 disk-image-create passes, both hard coded (ironic python agent and overcloud-full). Older (and future) versions will require differences (e.g. discovery ramdisk for Kilo).

This issue tracks migrating these 2 hard coded passes (IPA, overcloud) to a declarative, data-driven idiom.

We will specify via YML a list of images to build. For each image the following shall be declarable:

  1. Name
  2. DIB elements
  3. DIB packages
  4. Custom env vars

Generating disk images will merely be a traversal of this list, and will maintain ability to rundisk-image-create tasks async, to leverage multi-core HW and nice disk subsystems/arrays.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.