From 8625cf7d8bb6a6b119183ece1e591abe526a3e95 Mon Sep 17 00:00:00 2001 From: Thomas Wiest Date: Fri, 19 Jun 2015 10:14:07 -0400 Subject: changed Openshift to OpenShift --- docs/best_practices_guide.adoc | 2 +- docs/core_concepts_guide.adoc | 2 +- docs/style_guide.adoc | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) (limited to 'docs') diff --git a/docs/best_practices_guide.adoc b/docs/best_practices_guide.adoc index 841f6e72c..912617461 100644 --- a/docs/best_practices_guide.adoc +++ b/docs/best_practices_guide.adoc @@ -1,6 +1,6 @@ // vim: ft=asciidoc -= Openshift-Ansible Best Practices Guide += openshift-ansible Best Practices Guide The purpose of this guide is to describe the preferred patterns and best practices used in this repository (both in ansible and python). diff --git a/docs/core_concepts_guide.adoc b/docs/core_concepts_guide.adoc index 38187c55e..b29e467e2 100644 --- a/docs/core_concepts_guide.adoc +++ b/docs/core_concepts_guide.adoc @@ -1,6 +1,6 @@ // vim: ft=asciidoc -= Openshift-Ansible Core Concepts Guide += openshift-ansible Core Concepts Guide The purpose of this guide is to describe core concepts used in this repository. diff --git a/docs/style_guide.adoc b/docs/style_guide.adoc index 3b888db12..7dc240f2e 100644 --- a/docs/style_guide.adoc +++ b/docs/style_guide.adoc @@ -1,6 +1,6 @@ // vim: ft=asciidoc -= Openshift-Ansible Style Guide += openshift-ansible Style Guide The purpose of this guide is to describe the preferred coding conventions used in this repository (both in ansible and python). -- cgit v1.2.3 From 22d36791e985d0e78f6215bb46c6cd18bd7b719c Mon Sep 17 00:00:00 2001 From: Thomas Wiest Date: Wed, 24 Jun 2015 10:39:26 -0400 Subject: added .yml extension to style guide. --- docs/style_guide.adoc | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'docs') diff --git a/docs/style_guide.adoc b/docs/style_guide.adoc index 7dc240f2e..2f89a5fae 100644 --- a/docs/style_guide.adoc +++ b/docs/style_guide.adoc @@ -43,6 +43,20 @@ This is a hard limit and is enforced by the build bot. This check MUST NOT be di == Ansible + +=== Ansible Yaml file extension +''' +[cols="2v,v"] +|=== +| **Rule** +| All Ansible Yaml files MUST have a .yml extension (and NOT .YML, .yaml etc). +|=== + +Ansible tooling (like `ansible-galaxy init`) create files with a .yml extension. Also, the Ansible documentation website references files with a .yml extension several times. Because of this, it is normal in the Ansible community to use a .yml extension for all Ansible Yaml files. + +Example: `tasks.yml` + + === Ansible Global Variables Ansible global variables are defined as any variables outside of ansible roles. Examples include playbook variables, variables passed in on the cli, etc. -- cgit v1.2.3 From feed0b5595bb65b553459b6c6c256de51a4c4276 Mon Sep 17 00:00:00 2001 From: Thomas Wiest Date: Wed, 24 Jun 2015 10:48:11 -0400 Subject: added python new method params should use a default value to best practices guide. --- docs/best_practices_guide.adoc | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) (limited to 'docs') diff --git a/docs/best_practices_guide.adoc b/docs/best_practices_guide.adoc index 912617461..1e96655e1 100644 --- a/docs/best_practices_guide.adoc +++ b/docs/best_practices_guide.adoc @@ -27,6 +27,32 @@ The tooling is flexible enough that exceptions can be made so that the tool the == Python +=== Method Signatures + +''' +[cols="2v,v"] +|=== +| **Rule** +| When adding a new paramemter to an existing method, a default value SHOULD be used +|=== +The purpose of this rule is to make it so that method signatures are backwards compatible. + +If this rule isn't followed, it will be necessary for the person who changed the method to search out all callers and make sure that they're able to use the new method signature. + +Example: +.Before: +[source,python] +---- +def add_person(first_name, last_name): +---- + +.After: +[source,python] +---- +def add_person(first_name, last_name, age=None): +---- + + === PyLint http://www.pylint.org/[PyLint] is used in an attempt to keep the python code as clean and as managable as possible. The build bot runs each pull request through PyLint and any warnings or errors cause the build bot to fail the pull request. -- cgit v1.2.3 From 071880756c6862a8e45851735a19c3e9b33b4200 Mon Sep 17 00:00:00 2001 From: Thomas Wiest Date: Wed, 24 Jun 2015 11:28:57 -0400 Subject: Added using Yaml syntax to best practices guide. --- docs/best_practices_guide.adoc | 52 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) (limited to 'docs') diff --git a/docs/best_practices_guide.adoc b/docs/best_practices_guide.adoc index 1e96655e1..9208e99a3 100644 --- a/docs/best_practices_guide.adoc +++ b/docs/best_practices_guide.adoc @@ -125,6 +125,58 @@ YAML is a superset of JSON, which means that Ansible allows JSON syntax to be in Every effort should be made to keep our Ansible YAML files in pure YAML. +''' +[cols="2v,v"] +|=== +| **Rule** +| Parameters to Ansible Modules SHOULD use the Yaml dictionary format when 3 or more parameters are being passed +|=== + +When a module has several parameters that are being passed in, it's hard to see exactly what value each parameter is getting. It is preferred to use the Ansible Yaml syntax to pass in parameters so that it's more clear what values are being passed for each paramemter. + +.Bad: +[source,yaml] +---- +- file: src=/file/to/link/to dest=/path/to/symlink owner=foo group=foo state=link +---- + +.Good: +[source,yaml] +---- +- file: + src: /file/to/link/to + dest: /path/to/symlink + owner: foo + group: foo + state: link +---- + + +''' +[cols="2v,v"] +|=== +| **Rule** +| Parameters to Ansible Modules SHOULD use the Yaml dictionary format when the line length exceeds 120 characters +|=== + +Lines that are long quickly become a wall of text that isn't easily parsable. It is preferred to use the Ansible Yaml syntax to pass in parameters so that it's more clear what values are being passed for each paramemter. + +.Bad: +[source,yaml] +---- +- get_url: url=http://example.com/path/file.conf dest=/etc/foo.conf sha256sum=b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c +---- + +.Good: +[source,yaml] +---- +- get_url: + url: http://example.com/path/file.conf + dest: /etc/foo.conf + sha256sum: b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c +---- + + === Defensive Programming .Context -- cgit v1.2.3 From 0e67b142b4cb069c8986ac025ece78b8acb162ef Mon Sep 17 00:00:00 2001 From: Thomas Wiest Date: Wed, 8 Jul 2015 09:35:15 -0400 Subject: documented ansible arch team decisions --- docs/best_practices_guide.adoc | 141 ++++++++++++++++++++++++++++++++++++++++- docs/style_guide.adoc | 22 ++++++- 2 files changed, 159 insertions(+), 4 deletions(-) (limited to 'docs') diff --git a/docs/best_practices_guide.adoc b/docs/best_practices_guide.adoc index 9208e99a3..6aaf5228a 100644 --- a/docs/best_practices_guide.adoc +++ b/docs/best_practices_guide.adoc @@ -27,6 +27,24 @@ The tooling is flexible enough that exceptions can be made so that the tool the == Python +=== Python Source Files + +''' +[cols="2v,v"] +|=== +| **Rule** +| Python source files MUST contain the following vim mode line. +|=== + +[source] +---- +# vim: expandtab:tabstop=4:shiftwidth=4 +---- + +Since most developers contributing to this repository use vim, this rule helps to promote consistency. + +If mode lines for other editors are needed, please open a GitHub issue. + === Method Signatures ''' @@ -39,7 +57,6 @@ The purpose of this rule is to make it so that method signatures are backwards c If this rule isn't followed, it will be necessary for the person who changed the method to search out all callers and make sure that they're able to use the new method signature. -Example: .Before: [source,python] ---- @@ -125,6 +142,7 @@ YAML is a superset of JSON, which means that Ansible allows JSON syntax to be in Every effort should be made to keep our Ansible YAML files in pure YAML. +=== Modules ''' [cols="2v,v"] |=== @@ -176,6 +194,51 @@ Lines that are long quickly become a wall of text that isn't easily parsable. It sha256sum: b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c ---- +''' +[cols="2v,v"] +|=== +| **Rule** +| The Ansible `shell` module SHOULD NOT be used. Instead, use the `command` module. +|=== +.Context +* http://docs.ansible.com/shell_module.html#notes[Ansible Doc on why using the command module is a best practice] + +The Ansible `shell` module can run most commands that can be run from a bash CLI. This makes it extremely powerful, but it also opens our playbooks up to being exploited by attackers. + +.Bad: +[source,yaml] +---- +- shell: "/bin/echo {{ cli_var }}" +---- + +.Better: +[source,yaml] +---- +- command: "/bin/echo {{ cli_var }}" +---- + +''' +[cols="2v,v"] +|=== +| **Rule** +| The Ansible `quote` filter MUST be used with any variable passed into the shell module. +|=== +.Context +* http://docs.ansible.com/shell_module.html#notes[Ansible Doc describing why to use the quote filter] + +It is recommended not to use the `shell` module. However, if it absolutely must be used, all variables passed into the `shell` module MUST use the `quote` filter to ensure they are shell safe. + +.Bad: +[source,yaml] +---- +- shell: "/bin/echo {{ cli_var }}" +---- + +.Good: +[source,yaml] +---- +- shell: "/bin/echo {{ cli_var | quote }}" +---- === Defensive Programming @@ -220,8 +283,84 @@ If an Ansible role requires certain variables to be set, it's best to check for when: arl_environment is not defined or arl_environment == '' ---- +=== Tasks +''' +[cols="2v,v"] +|=== +| **Rule** +| Ansible tasks SHOULD NOT be used in ansible playbooks. Instead, use pre_tasks and post_tasks. +|=== +An Ansible play is defined as a Yaml dictionary. Because of that, ansible doesn't know if the play's tasks list or roles list was specified first. Therefore Ansible always runs tasks after roles. + +This can be quite confusing if the tasks list is defined in the playbook before the roles list because people assume in order execution in Ansible. + +Therefore, we SHOULD use pre_tasks and post_tasks to make it more clear when the tasks will be run. + +.Context +* https://docs.ansible.com/playbooks_roles.html[Ansible documentation on pre_tasks and post_tasks] + +.Bad: +[source,yaml] +---- +--- +# playbook.yml +- hosts: localhost + gather_facts: no + tasks: + - name: This will execute AFTER the example_role, so it's confusing + debug: msg="in tasks list" + roles: + - role: example_role + +# roles/example_role/tasks/main.yml +- debug: msg="in example_role" +---- + +.Good: +[source,yaml] +---- +--- +# playbook.yml +- hosts: localhost + gather_facts: no + pre_tasks: + - name: This will execute BEFORE the example_role, so it makes sense + debug: msg="in pre_tasks list" + roles: + - role: example_role + +# roles/example_role/tasks/main.yml +- debug: msg="in example_role" +---- + + === Roles +''' +[cols="2v,v"] +|=== +| **Rule** +| All tasks in a role SHOULD be tagged with the role name. +|=== + +.Context +* http://docs.ansible.com/playbooks_tags.html[Ansible doc explaining tags] + +Ansible tasks can be tagged, and then these tags can be used to either _run_ or _skip_ the tagged tasks using the `--tags` and `--skip-tags` ansible-playbook options respectively. + +This is very useful when developing and debugging new tasks. It can also significantly speed up playbook runs if the user specifies only the roles that changed. + +.Example: +[source,yaml] +---- +--- +# roles/example_role/tasks/main.yml +- debug: msg="in example_role" + tags: + - example_role +---- + + ''' [cols="2v,v"] |=== diff --git a/docs/style_guide.adoc b/docs/style_guide.adoc index 2f89a5fae..110e7153f 100644 --- a/docs/style_guide.adoc +++ b/docs/style_guide.adoc @@ -57,18 +57,34 @@ Ansible tooling (like `ansible-galaxy init`) create files with a .yml extension. Example: `tasks.yml` -=== Ansible Global Variables -Ansible global variables are defined as any variables outside of ansible roles. Examples include playbook variables, variables passed in on the cli, etc. +=== Ansible CLI Variables +''' +[cols="2v,v"] +|=== +| **Rule** +| Variables meant to be passed in from the ansible CLI MUST have a prefix of cli_ +|=== + +Ansible allows variables to be passed in on the command line using the `-e` option. These variables MUST have a prefix of cli_ so that it's clear where they came from, and how dangerous they are (can be exploited). + +.Example: +[source] +---- +ansible-playbook -e cli_foo=bar someplays.yml +---- + +=== Ansible Global Variables ''' [cols="2v,v"] |=== | **Rule** | Global variables MUST have a prefix of g_ |=== +Ansible global variables are defined as any variables outside of ansible roles. Examples include playbook variables, variables passed in on the cli, etc. -Example: +.Example: [source] ---- g_environment: someval -- cgit v1.2.3 From 56337d04f3c746b88382d13e13a6b5f52d4a7d24 Mon Sep 17 00:00:00 2001 From: Thomas Wiest Date: Wed, 22 Jul 2015 10:22:38 -0400 Subject: added decisions made at the last ansible arch meeting. --- docs/best_practices_guide.adoc | 43 +++++++++++++++++++++++++++++++++++++----- docs/style_guide.adoc | 2 +- 2 files changed, 39 insertions(+), 6 deletions(-) (limited to 'docs') diff --git a/docs/best_practices_guide.adoc b/docs/best_practices_guide.adoc index 6aaf5228a..a146b93ad 100644 --- a/docs/best_practices_guide.adoc +++ b/docs/best_practices_guide.adoc @@ -147,7 +147,40 @@ Every effort should be made to keep our Ansible YAML files in pure YAML. [cols="2v,v"] |=== | **Rule** -| Parameters to Ansible Modules SHOULD use the Yaml dictionary format when 3 or more parameters are being passed +| Custom Ansible modules SHOULD be embedded in a role. +|=== + +.Context +* http://docs.ansible.com/ansible/playbooks_roles.html#embedding-modules-in-roles[Ansible doc on how to embed modules in roles] + +The purpose of this rule is to make it easy to include custom modules in our playbooks and share them on Ansible Galaxy. + +.Custom module `openshift_facts.py` is embedded in the `openshift_facts` role. +---- +> ll openshift-ansible/roles/openshift_facts/library/ +-rwxrwxr-x. 1 user group 33616 Jul 22 09:36 openshift_facts.py +---- + +.Custom module `openshift_facts` can be used after `openshift_facts` role has been referenced. +[source,yaml] +---- +- hosts: openshift_hosts + gather_facts: no + roles: + - role: openshift_facts + post_tasks: + - openshift_facts + role: common + hostname: host + public_hostname: host.example.com +---- + + +''' +[cols="2v,v"] +|=== +| **Rule** +| Parameters to Ansible modules SHOULD use the Yaml dictionary format when 3 or more parameters are being passed |=== When a module has several parameters that are being passed in, it's hard to see exactly what value each parameter is getting. It is preferred to use the Ansible Yaml syntax to pass in parameters so that it's more clear what values are being passed for each paramemter. @@ -174,7 +207,7 @@ When a module has several parameters that are being passed in, it's hard to see [cols="2v,v"] |=== | **Rule** -| Parameters to Ansible Modules SHOULD use the Yaml dictionary format when the line length exceeds 120 characters +| Parameters to Ansible modules SHOULD use the Yaml dictionary format when the line length exceeds 120 characters |=== Lines that are long quickly become a wall of text that isn't easily parsable. It is preferred to use the Ansible Yaml syntax to pass in parameters so that it's more clear what values are being passed for each paramemter. @@ -198,10 +231,10 @@ Lines that are long quickly become a wall of text that isn't easily parsable. It [cols="2v,v"] |=== | **Rule** -| The Ansible `shell` module SHOULD NOT be used. Instead, use the `command` module. +| The Ansible `command` module SHOULD be used instead of the Ansible `shell` module. |=== .Context -* http://docs.ansible.com/shell_module.html#notes[Ansible Doc on why using the command module is a best practice] +* http://docs.ansible.com/shell_module.html#notes[Ansible doc on why using the command module is a best practice] The Ansible `shell` module can run most commands that can be run from a bash CLI. This makes it extremely powerful, but it also opens our playbooks up to being exploited by attackers. @@ -224,7 +257,7 @@ The Ansible `shell` module can run most commands that can be run from a bash CLI | The Ansible `quote` filter MUST be used with any variable passed into the shell module. |=== .Context -* http://docs.ansible.com/shell_module.html#notes[Ansible Doc describing why to use the quote filter] +* http://docs.ansible.com/shell_module.html#notes[Ansible doc describing why to use the quote filter] It is recommended not to use the `shell` module. However, if it absolutely must be used, all variables passed into the `shell` module MUST use the `quote` filter to ensure they are shell safe. diff --git a/docs/style_guide.adoc b/docs/style_guide.adoc index 110e7153f..09d4839c7 100644 --- a/docs/style_guide.adoc +++ b/docs/style_guide.adoc @@ -65,7 +65,7 @@ Example: `tasks.yml` | Variables meant to be passed in from the ansible CLI MUST have a prefix of cli_ |=== -Ansible allows variables to be passed in on the command line using the `-e` option. These variables MUST have a prefix of cli_ so that it's clear where they came from, and how dangerous they are (can be exploited). +Ansible allows variables to be passed in on the command line using the `-e` option. These variables MUST have a prefix of cli_ so that it's clear where they came from, and that they could be exploited. .Example: -- cgit v1.2.3 From 000e179cb3d39756d9bf5f846e2be3a7d3759f5f Mon Sep 17 00:00:00 2001 From: Avesh Agarwal Date: Wed, 12 Aug 2015 16:19:25 -0400 Subject: Changes to make documentation less specific to OSE or AE and also adds README_AEP.md. --- README.md | 7 +- README_AEP.md | 240 +++++++++++++++++++++++++++++++++++++++ docs/best_practices_guide.adoc | 2 +- roles/openshift_common/README.md | 6 +- 4 files changed, 248 insertions(+), 7 deletions(-) create mode 100644 README_AEP.md (limited to 'docs') diff --git a/README.md b/README.md index 2bdaefd4c..7544e8e2a 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ -#openshift-ansible +#Openshift and Atomic Enterprise Ansible -This repo contains OpenShift Ansible code. +This repo contains Ansible code for Openshift and Atomic Enterprise. ##Setup - Install base dependencies: @@ -23,12 +23,13 @@ This repo contains OpenShift Ansible code. - Bring your own host deployments: - [OpenShift Enterprise](README_OSE.md) - [OpenShift Origin](README_origin.md) + - [Atomic Enterprise](README_AEP.md) - Build - [How to build the openshift-ansible rpms](BUILD.md) - Directory Structure: - - [bin/cluster](bin/cluster) - python script to easily create OpenShift 3 clusters + - [bin/cluster](bin/cluster) - python script to easily create clusters - [docs](docs) - Documentation for the project - [filter_plugins/](filter_plugins) - custom filters used to manipulate data in Ansible - [inventory/](inventory) - houses Ansible dynamic inventory scripts diff --git a/README_AEP.md b/README_AEP.md new file mode 100644 index 000000000..e29888617 --- /dev/null +++ b/README_AEP.md @@ -0,0 +1,240 @@ +# Installing AEP from dev puddles using ansible + +* [Requirements](#requirements) +* [Caveats](#caveats) +* [Known Issues](#known-issues) +* [Configuring the host inventory](#configuring-the-host-inventory) +* [Creating the default variables for the hosts and host groups](#creating-the-default-variables-for-the-hosts-and-host-groups) +* [Running the ansible playbooks](#running-the-ansible-playbooks) +* [Post-ansible steps](#post-ansible-steps) +* [Overriding detected ip addresses and hostnames](#overriding-detected-ip-addresses-and-hostnames) + +## Requirements +* ansible + * Tested using ansible 1.9.1 and 1.9.2 + * There is currently a known issue with ansible-1.9.0, you can downgrade to 1.8.4 on Fedora by installing one of the builds from Koji: http://koji.fedoraproject.org/koji/packageinfo?packageID=13842 + * Available in Fedora channels + * Available for EL with EPEL and Optional channel +* One or more RHEL 7.1 VMs +* Either ssh key based auth for the root user or ssh key based auth for a user + with sudo access (no password) +* A checkout of atomic-enterprise-ansible from https://github.com/projectatomic/atomic-enterprise-ansible/ + + ```sh + git clone https://github.com/projectatomic/atomic-enterprise-ansible.git + cd atomic-enterprise-ansible + ``` + +## Caveats +This ansible repo is currently under heavy revision for providing OSE support; +the following items are highly likely to change before the OSE support is +merged into the upstream repo: + * the current git branch for testing + * how the inventory file should be configured + * variables that need to be set + * bootstrapping steps + * other configuration steps + +## Known Issues +* Host subscriptions are not configurable yet, the hosts need to be + pre-registered with subscription-manager or have the RHEL base repo + pre-configured. If using subscription-manager the following commands will + disable all but the rhel-7-server rhel-7-server-extras and + rhel-server7-ose-beta repos: +```sh +subscription-manager repos --disable="*" +subscription-manager repos \ +--enable="rhel-7-server-rpms" \ +--enable="rhel-7-server-extras-rpms" \ +--enable="rhel-7-server-ose-3.0-rpms" +``` +* Configuration of router is not automated yet +* Configuration of docker-registry is not automated yet + +## Configuring the host inventory +[Ansible docs](http://docs.ansible.com/intro_inventory.html) + +Example inventory file for configuring one master and two nodes for the test +environment. This can be configured in the default inventory file +(/etc/ansible/hosts), or using a custom file and passing the --inventory +option to ansible-playbook. + +/etc/ansible/hosts: +```ini +# This is an example of a bring your own (byo) host inventory + +# Create an OSEv3 group that contains the masters and nodes groups +[OSEv3:children] +masters +nodes + +# Set variables common for all OSEv3 hosts +[OSEv3:vars] +# SSH user, this user should allow ssh based auth without requiring a password +ansible_ssh_user=root + +# If ansible_ssh_user is not root, ansible_sudo must be set to true +#ansible_sudo=true + +# To deploy origin, change deployment_type to origin +deployment_type=enterprise + +# Pre-release registry URL +oreg_url=docker-buildvm-rhose.usersys.redhat.com:5000/openshift3/ose-${component}:${version} + +# Pre-release additional repo +openshift_additional_repos=[{'id': 'ose-devel', 'name': 'ose-devel', +'baseurl': +'http://buildvm-devops.usersys.redhat.com/puddle/build/OpenShiftEnterprise/3.0/latest/RH7-RHOSE-3.0/$basearch/os', +'enabled': 1, 'gpgcheck': 0}] + +# Origin copr repo +#openshift_additional_repos=[{'id': 'openshift-origin-copr', 'name': +'OpenShift Origin COPR', 'baseurl': +'https://copr-be.cloud.fedoraproject.org/results/maxamillion/origin-next/epel-7-$basearch/', +'enabled': 1, 'gpgcheck': 1, gpgkey: +'https://copr-be.cloud.fedoraproject.org/results/maxamillion/origin-next/pubkey.gpg'}] + +# host group for masters +[masters] +ose3-master.example.com + +# host group for nodes +[nodes] +ose3-node[1:2].example.com +``` + +The hostnames above should resolve both from the hosts themselves and +the host where ansible is running (if different). + +## Running the ansible playbooks +From the atomic-enterprise-ansible checkout run: +```sh +ansible-playbook playbooks/byo/config.yml +``` +**Note:** this assumes that the host inventory is /etc/ansible/hosts, if using a different +inventory file use the -i option for ansible-playbook. + +## Post-ansible steps +#### Create the default router +On the master host: +```sh +oadm router --create=true \ + --credentials=/etc/openshift/master/openshift-router.kubeconfig \ + --images='docker-buildvm-rhose.usersys.redhat.com:5000/openshift3/ose-${component}:${version}' +``` + +#### Create the default docker-registry +On the master host: +```sh +oadm registry --create=true \ + --credentials=/etc/openshift/master/openshift-registry.kubeconfig \ + --images='docker-buildvm-rhose.usersys.redhat.com:5000/openshift3/ose-${component}:${version}' \ + --mount-host=/var/lib/openshift/docker-registry +``` + +## Overriding detected ip addresses and hostnames +Some deployments will require that the user override the detected hostnames +and ip addresses for the hosts. To see what the default values will be you can +run the openshift_facts playbook: +```sh +ansible-playbook playbooks/byo/openshift_facts.yml +``` +The output will be similar to: +``` +ok: [10.3.9.45] => { + "result": { + "ansible_facts": { + "openshift": { + "common": { + "hostname": "jdetiber-osev3-ansible-005dcfa6-27c6-463d-9b95-ef059579befd.os1.phx2.redhat.com", + "ip": "172.16.4.79", + "public_hostname": "jdetiber-osev3-ansible-005dcfa6-27c6-463d-9b95-ef059579befd.os1.phx2.redhat.com", + "public_ip": "10.3.9.45", + "use_openshift_sdn": true + }, + "provider": { + ... ... + } + } + }, + "changed": false, + "invocation": { + "module_args": "", + "module_name": "openshift_facts" + } + } +} +ok: [10.3.9.42] => { + "result": { + "ansible_facts": { + "openshift": { + "common": { + "hostname": "jdetiber-osev3-ansible-c6ae8cdc-ba0b-4a81-bb37-14549893f9d3.os1.phx2.redhat.com", + "ip": "172.16.4.75", + "public_hostname": "jdetiber-osev3-ansible-c6ae8cdc-ba0b-4a81-bb37-14549893f9d3.os1.phx2.redhat.com", + "public_ip": "10.3.9.42", + "use_openshift_sdn": true + }, + "provider": { + ...... + } + } + }, + "changed": false, + "invocation": { + "module_args": "", + "module_name": "openshift_facts" + } + } +} +ok: [10.3.9.36] => { + "result": { + "ansible_facts": { + "openshift": { + "common": { + "hostname": "jdetiber-osev3-ansible-bc39a3d3-cdd7-42fe-9c12-9fac9b0ec320.os1.phx2.redhat.com", + "ip": "172.16.4.73", + "public_hostname": "jdetiber-osev3-ansible-bc39a3d3-cdd7-42fe-9c12-9fac9b0ec320.os1.phx2.redhat.com", + "public_ip": "10.3.9.36", + "use_openshift_sdn": true + }, + "provider": { + ...... + } + } + }, + "changed": false, + "invocation": { + "module_args": "", + "module_name": "openshift_facts" + } + } +} +``` +Now, we want to verify the detected common settings to verify that they are +what we expect them to be (if not, we can override them). + +* hostname + * Should resolve to the internal ip from the instances themselves. + * openshift_hostname will override. +* ip + * Should be the internal ip of the instance. + * openshift_ip will override. +* public hostname + * Should resolve to the external ip from hosts outside of the cloud + * provider openshift_public_hostname will override. +* public_ip + * Should be the externally accessible ip associated with the instance + * openshift_public_ip will override +* use_openshift_sdn + * Should be true unless the cloud is GCE. + * openshift_use_openshift_sdn overrides + +To override the the defaults, you can set the variables in your inventory: +``` +...snip... +[masters] +ose3-master.example.com openshift_ip=1.1.1.1 openshift_hostname=ose3-master.example.com openshift_public_ip=2.2.2.2 openshift_public_hostname=ose3-master.public.example.com +...snip... +``` diff --git a/docs/best_practices_guide.adoc b/docs/best_practices_guide.adoc index a146b93ad..4b7d7c43d 100644 --- a/docs/best_practices_guide.adoc +++ b/docs/best_practices_guide.adoc @@ -421,7 +421,7 @@ For consistency, role names SHOULD follow the above naming pattern. It is import Many times the `technology` portion of the pattern will line up with a package name. It is advised that whenever possible, the package name should be used. .Examples: -* The role to configure an OpenShift Master is called `openshift_master` +* The role to configure a Master is called `openshift_master` * The role to configure OpenShift specific yum repositories is called `openshift_repos` === Filters diff --git a/roles/openshift_common/README.md b/roles/openshift_common/README.md index eb4ef26e8..1eb04626f 100644 --- a/roles/openshift_common/README.md +++ b/roles/openshift_common/README.md @@ -1,7 +1,7 @@ -OpenShift Common -================ +OpenShift/Atomic Enterprise Common +=================================== -OpenShift common installation and configuration tasks. +OpenShift/Atomic Enterprise common installation and configuration tasks. Requirements ------------ -- cgit v1.2.3 From abd6132a81ed7b9e7931af1271db9067e9b51536 Mon Sep 17 00:00:00 2001 From: Avesh Agarwal Date: Thu, 13 Aug 2015 18:32:19 -0400 Subject: Changed the string Master to master to make it more readable. --- docs/best_practices_guide.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/best_practices_guide.adoc b/docs/best_practices_guide.adoc index 4b7d7c43d..08d95b2b8 100644 --- a/docs/best_practices_guide.adoc +++ b/docs/best_practices_guide.adoc @@ -421,7 +421,7 @@ For consistency, role names SHOULD follow the above naming pattern. It is import Many times the `technology` portion of the pattern will line up with a package name. It is advised that whenever possible, the package name should be used. .Examples: -* The role to configure a Master is called `openshift_master` +* The role to configure a master is called `openshift_master` * The role to configure OpenShift specific yum repositories is called `openshift_repos` === Filters -- cgit v1.2.3