Add openstack provider #5797

tomassedovic · 2017-10-18T17:17:04Z

This adds the OpenStack provider support under playbooks/openstack and attempts to follow a similar file layout as the AWS code that's already there.

The playbooks and roles come from the openshift-ansible-contrib repository, specifically:

https://github.com/openshift/openshift-ansible-contrib/tree/master/playbooks/provisioning/openstack

Current status

We can do a functional multi-master OpenShift deployment on OpenStack Newton (or OSP 10) or newer. The playbooks here create the necessary OpenStack resources (VMs, networking, security groups, etc.).

The resulting cluster should more or less correspond to this reference architecture:
https://access.redhat.com/documentation/en-us/reference_architectures/2017/html-single/deploying_and_managing_red_hat_openshift_container_platform_3.6_on_red_hat_openstack_platform_10/

We don't do a much in terms of using the OpenStack-native resources, but that's something we want to look at soon (for load balancing, DNS, baremetal deployment, authentication, networking, etc.).

Deployment workflow overview:

We do all configuration up front
Then the provision playbook creates a Heat stack in the background (think of Heat as CloudFormation for OpenStack) -- this creates the VMs, networking, etc.
We configure the DNS (either by running the dns-server role on a VM from step 2 or by using the dynamic dns updates to a pre-existing server)
We configure all the VMs to use the DNS and install any dependencies, etc. that are necessary for openshift installation
Finally, we run the byo playbooks to install OpenShift.

History

The code came from the casl-ansible project. It has consequently moved to openshift-ansible-contrib.

And now we'd like to move and maintain it here and build it into a Red Hat supported deployment mechanism for OpenStack.

Some differences from the AWS provider

We don't have playbooks for building the golden images yet
Related: we create the entice cluster all at once (as opposed to the two-step "deploy master cluster, then add nodes which register themselves" approach AWS takes)
OpenStack doesn't have a universal support for DNS yet, so we allow using an external DNS and use RFC 2136 dynamic dns updates to populate it or create one ourselves and install BIND on it (for proof of concept deployments)
Our steps use the group_vars for configuration, AWS passes -e @provisioning_vars.yml to ansible-playbook instead. I quite like the group_vars approach, but we can switch to extra-vars if you prefer. Both providers work with either approach.

Additional questions and notes

We use Ansible Galaxy to optionally bring in the dns-server role from: https://github.com/redhat-cop/infra-ansible. What's openshift-ansible's stance towards using Galaxy modules?
We have a travis-based end-to-end CI running on every pull request. Can we integrate with your CI? Travis is not really suited for this. We can provide the necessary OpenStack resources via RDO Cloud.
Since we've experienced breakages introduced by openshift-ansible in the past, would it make sense to run the CI even on non-openstack changes? At least as a periodic job.
The @redhat-cop/casl people (who are using these roles in openshift-ansible-contrib) would like us to preserve the full history of the files we're bringing in. If you're fine with that, I'll create another pull request that does that. It would look something like this: Add an Openstack provider openshift-ansible-contrib#397
I'm sure some of the code here could use some clean up. I'd prefer if we merged what we have and did that in subsequent PRs, but it's your show.
Ditto for the roles this brings in -- some of them should probably be renamed -- should we do that here or can it be done later?

/cc @sdodson @kwoodson @redhat-cop/casl @mperezco @tzumainn @celebdor @bogdando @Tlacenka

This just copies all the files from the contrib[1] repo over. The changes will be addressed in subsequent commits. [1]: https://github.com/openshift/openshift-ansible-contrib/

tomassedovic · 2017-10-18T17:26:01Z

(sorry for the size of the pull request -- we can split it into smaller commits, but most of it is necessary for the full deployment)

michaelgugino · 2017-10-18T19:27:04Z

I appreciate you submitting this PR. I definitely want to see openstack supported as a target.

Overall, this patch set needs a fair amount of work. A few issues I want to highlight:

The plays contained in this patch set duplicate a lot of the logic that our existing roles and plays implement. This PR needs to better utilize what we have in tree, rather than re-implementing these pieces. An example: Docker registries.
Variable namespacing. The roles that are being added in this PR don't use great namespacing for their variables.
Too much in plays, not enough in roles for the openstack pieces. I would like to see a role similar to openshift_aws. That role breaks down the provisioning into logical components. Those components are then called using "include_role" and "tasks_from".
Continued from 3, due to the fact that things are being done in plays and not roles, an unnecessary amount of 'set_fact' is being performed. These default variable values can be easily set and overridden with role defaults.

Please see the latest version of our aws provisioning README: https://github.com/openshift/openshift-ansible/blob/master/playbooks/aws/README.md#high-level-overview

That section 'high-level-overview' breaks down all the steps to deploy a cluster onto AWS. We are reusing as much of the existing roles and plays as we can during the installation process. In fact, if you're not baking a golden node image, you can probably reuse almost all of it.

An example breakdown might be:

setup openstack-specific prerequisites; flavor, network, ssh keypair, etc as you see fit.
provision instances on openstack.
run the installer as normal on our newly created instances.

We use Ansible Galaxy to optionally bring in the dns-server role from: https://github.com/redhat-cop/infra-ansible. What's openshift-ansible's stance towards using Galaxy modules?

We vendor in roles into roles/ as necessary.

Our steps use the group_vars for configuration

I prefer to use group_vars as well, and the aws provisioning supports them, although it is maybe not as obviously. I recently added a note to the provisioning docs to this effect.

OpenStack doesn't have a universal support for DNS yet

We'll need to discuss this more in-depth I think during our architecture call. If we're going to ship a role that deploys bind and we support it, it better be in really, really good shape. I haven't reviewed this portion of the PR.

Can we integrate with your CI? Travis is not really suited for this. We can provide the necessary OpenStack resources via RDO Cloud.

This would definitely be my preference. I would love to see this supported in our CI.

bogdando · 2017-10-19T13:36:08Z

@tomassedovic please preserve the git history

tomassedovic · 2017-10-19T16:01:02Z

Thanks @michaelgugino!

Yeah what I've done so far is just moved all the code over and did changes necessary to get a successful deployment.

I'm sure there's a lot of roles we can re-use. I have looked at the AWS provider, but I didn't spend a lot of time looking at the roles yet. I'll make sure to do that and see how much we can share.

I'm a bit confused about your comments regarding the high-level overview and breakdown -- the process here is exactly as you described. Are you asking for docs changes to reflect that better?

I'll make sure to attend the architecture call, but regarding the DNS. When it comes to OpenStack, you have two options:

Bring your own DNS. If it supports dynamic updates, we'll add the entries, if not, set them up yourself
We can create and configure a DNS for evaluation purposes for you

The DNS I mentioned is in the latter category and is maintained by the CASL people here:

https://github.com/redhat-cop/infra-ansible/tree/master/roles/dns-server

I'm not sure we necessarily want to ship and support that (or a similar) role for production use, but would it be possible to have it there for the evaluation purposes?

Right now, you can get from zero to openshift with a single ansible-playbook run. I'd still love to keep the push-button option for folks who want to try it out.

@oybed any comments on the DNS role and situation?

bogdando · 2017-10-23T13:00:12Z

@michaelgugino please note that the purpose of the merge is to streamline the development process for the openstack provider, inlcude it into CI pipelines, simplify (and enable) packaging, which is basically "productization baby-steps". Please keep in mind that major rework of playbooks and roles is placed on the provider team's roadmap. The concerns you've raised are valid and correct, thank you for reviewing that! We'll be addressing those eventually, once we have a streamlined development process done. I hope that works.

michaelgugino · 2017-10-23T13:42:29Z

I'm a bit confused about your comments regarding the high-level overview and breakdown -- the process here is exactly as you described. Are you asking for docs changes to reflect that better?

@tomassedovic
If you take a look at the plays outlined in those sections (the install.yml part specifically, I believe), you'll see how we're using some existing roles to install the cluster.

please note that the purpose of the merge is to streamline the development process for the openstack provider, inlcude it into CI pipelines, simplify (and enable) packaging, which is basically "productization baby-steps". Please keep in mind that major rework of playbooks and roles is placed on the provider team's roadmap. The concerns you've raised are valid and correct, thank you for reviewing that! We'll be addressing those eventually, once we have a streamlined development process done. I hope that works.

@bogdando
I think if that is the case, there are alternatives to merging this as-is into master. Perhaps we could setup a feature branch that can be contributed to/have PR's filed against, and when it's in good shape, we can open a PR to merge into master.

@sdodson Any suggestions here?

All the tasks that were previously in playbooks are now under `roles/openshift_openstack`. The `openshift-cluster` directory now only contains playbooks that include tasks from that role. This makes the structure much closer to that of the AWS provider.

tomassedovic · 2017-10-26T17:31:48Z

@michaelgugino the new commit makes some of the changes you've requested.

Created the openshift_openstack role and moved tasks that were previously in playbooks there
Added the provision_install.yml playbook that includes provision.yml and install.yml -- these playbooks use include_role and tasks_from to get the actual tasks from the new role
Removed the DNS -- we'll need to figure it out, but that's a sizeable discussion on its own, so I've made it so the playbooks require a DNS that's set up for now and we'll address this in a later PR

I'll take a look at the variable naming/namespacing and re-using more code from the existing roles next.

If you have time though, please let take a look and me know whether this is closer to what you would expect.

Thanks!

tomassedovic · 2017-10-26T17:36:53Z

@michaelgugino regarding variable namespacing, do you mean that any openstack-specific variable should be prefixed with openshift_openstack. It's a bit of a mouthful, but I'm not sure how to make it shorter. OSP is Red Hat-specific, would openshift_os_* work?

michaelgugino

Overall, this looks to be in much better shape. I appreciate all the changes you made. Just a few more items I would like to discuss, but this patch set is definitely moving in the right direction.

michaelgugino · 2017-10-26T18:49:55Z

playbooks/openstack/custom-actions/add-docker-registry.yml

@@ -0,0 +1,90 @@
+---


We already have a docker role. Please remove this play and modify openstack provisioning to consume that role.

All the playbooks in custom-actions were just examples of custom actions people might want to do. I'll remove them from now and we'll see whether it makes sense to add them using the right roles later.

michaelgugino · 2017-10-26T18:50:41Z

playbooks/openstack/custom-actions/add-cas.yml

+---
+- hosts: cluster_hosts
+  become: true
+  vars:


This will override inventory/group vars. You should not define empty vars like this. use '| default([])' where the var is consumed.

michaelgugino · 2017-10-26T18:50:56Z

playbooks/openstack/custom-actions/add-cas.yml

@@ -0,0 +1,13 @@
+---
+- hosts: cluster_hosts


This does not conform to our group names.

michaelgugino · 2017-10-26T18:51:21Z

playbooks/openstack/custom-actions/add-rhn-pools.yml

@@ -0,0 +1,13 @@
+---
+- hosts: cluster_hosts


group name.

michaelgugino · 2017-10-26T18:51:30Z

playbooks/openstack/custom-actions/add-yum-repos.yml

@@ -0,0 +1,12 @@
+---
+- hosts: cluster_hosts


group name.

michaelgugino · 2017-10-26T18:53:19Z

playbooks/openstack/openshift-cluster/provision_install.yml

@@ -0,0 +1,9 @@
+---


This looks good.

michaelgugino · 2017-10-26T18:54:03Z

playbooks/openstack/openshift-cluster/scale-up.yaml

@@ -0,0 +1,70 @@
+---
+# Get the needed information about the current deployment
+- hosts: masters[0]


This is not conforming to the group names we use elsewhere.

For what it's worth, the install.yml playbook for AWS does use the masters group:

openshift-ansible/playbooks/aws/openshift-cluster/install.yml

Line 10 in 30d3fc6

hosts: masters

What should we use instead? oo_first_master?

I didn't realize that other play used masters group. We'll probably need to change that.

Yes, oo_first_master would the the correct one for the first host of the master group.

michaelgugino · 2017-10-26T19:01:20Z

roles/openshift_openstack/vars/main.yml

@@ -0,0 +1,49 @@
+---
+stack_name: "{{ env_id }}.{{ public_dns_domain }}"


Some of these variables are not namespaced well. Also, do we need to put these in vars/main.yml? Could they live in defaults/main.yml? That will allow them to be overriden by inventory.

Probably some of these variables don't need to be defined, we can just use the "openstack_x" variables in their places.

+1 good point with using defaults instead of vars. Ansible has a tricky precedence, so let's follow this recommendation

This is my last 'big item' for cleanup.

michaelgugino · 2017-10-26T19:03:38Z

roles/openstack-stack/README.md

@@ -0,0 +1,9 @@
+# Role openstack-stack


Let's merge this role with openshift-openstack and use include_role.

Oops, we already do that, I just forgot to remove the old role.

michaelgugino · 2017-10-26T19:05:43Z

roles/static_inventory/tasks/main.yml

@@ -0,0 +1,25 @@
+---


What is the primary purpose of this role? This part might need to stay in contrib?

Ah, good point. The contrib playbooks let you use either a dynamic inventory (as in this PR) or use this role to generate a static inventory. That's not used in this PR, so I can drop it for now and we deal with this in another change.

tomassedovic · 2017-10-27T11:04:15Z

Thanks! I can handle most of those comments by removing some more stuff :-). The playbooks in custom-actions serve more of an example/documentation purpose and are not directly used by anything else in here.

I'll take a look at the group names and vars next. Could you please point me out to the list of groups I can use. I grepped through the source, but it does show up both OSEv3 and masters so I'm not sure what the preferred groups are and where are they supposed to come from.

michaelgugino · 2017-10-27T13:28:29Z

@tomassedovic the group names are created in playbooks/common/openshift-cluster/evaluate_groups.yml, and the group names that play uses are created in playbooks/byo/openshift-cluster/initialize_groups.yml

I know it's confusing, I'm not a huge fan of it, but that's what we're doing currently and I'd like to stay consistent where possible.

tomassedovic · 2017-10-27T14:02:17Z

@michaelgugino thanks, this is quite useful! I certainly don't want to go against the grain here.

I'll update the PR.

The `openstack-stack` role is now under `openshift_openstack` and the `openstack-create-cinder-registry` one will be added there, later.

They're duplicating a lot of functionality that's already in openshift-ansible and they're not actually used from the provisioning playbooks. We'll revisit them later.

They're not necessary for the initial PR so let's add them properly later.

tomassedovic · 2017-10-27T16:05:33Z

@michaelgugino that should be most of your comments except for the vars stuff. I'll take a look at that on Monday.

Also, I need to re-test it to make sure it all still works.

bogdando

This commit removes more roles than it describes, please clarify the static_inventory role removal.

bogdando · 2017-10-30T08:37:02Z

playbooks/openstack/openshift-cluster/provision.yml

 # and configure their DNS if they have to.

 - name: Prepare the Nodes in the cluster for installation
-  hosts: cluster_hosts


this name change needs to be covered for the docs and the static_inventory and dynamic inventory please

bogdando · 2017-10-30T08:41:21Z

@tomassedovic The changes you submit on top of the dropped history will end up in a confusing git blame UX for developers. Could you please firstly copy the history as is, then put your changes on top?

tomassedovic · 2017-10-30T08:47:35Z

I still haven't heard from the openshift-ansible folks whether they would accept that going in.

@michaelgugino @sdodson can we add the git history here? It would bring in a bunch of commits, but it would keep the commits, git blame, etc. The PR would look something like this:

openshift/openshift-ansible-contrib#397

bogdando

I noted there is the rhel_subscribe role exists. Could you please as well remove the subscription role and update the code to use the former role?

tomassedovic · 2017-10-30T08:49:51Z

Yep, that's on my list.

The contents of roles/openshift_openstack/vars/main.yml were moved to the defaults/main.yml file instead. There are now duplication warnings we need to address, but the deployment does still work.

It's no longer being used.

Most of the vars in `roles/openshift_openstack/defaults/main.yml` are now prefixed with `openstack_`.

tomassedovic · 2017-11-01T15:49:46Z

@michaelgugino this latest set of changes handles the default/vars split as well any fixes I had to do to make this work again.

I've removed most of the vars duplications (num_etcd vs openstack_num_etcd) and added the openstack_ prefix so it should be better namespaced now. There's still a few stragglers -- let me know if you want me to fix all the names here or do that later.

For everyone else's benefit: the openshift-ansible team has OKd preserving git history so like I said, once this is good & done, I'll clone this PR and add the history there.

tomassedovic · 2017-11-01T15:51:32Z

@jeremyeder @mbruzek folks on the openshift-ansible architecture meeting suggested you take a look at this since you're doing a lot of openstack-based deployments.

The code here is basically just the playbooks from openshift-ansible-contrib plus changes that make it more consistent with the AWS provider.

openshift-ci-robot · 2017-11-01T16:00:49Z

@tomassedovic: The following test failed, say /retest to rerun them all:

Test name	Commit	Details	Rerun command
ci/openshift-jenkins/tox	`9e07520`	link	`/test tox`

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

michaelgugino

I would like to see the variable namespacing cleaned up. That will prevent any issues in the future, I didn't check every variable name against the rest of openshift-ansible as there are quite a few, but best practice is to include the role name as a prefix to the variable name.

I tend to apply this best-practice even on registered variables.

michaelgugino · 2017-11-01T16:21:41Z

playbooks/openstack/sample-inventory/group_vars/all.yml

@@ -0,0 +1,147 @@
+---
+env_id: "openshift"


Need to namespace this variable.

michaelgugino · 2017-11-01T16:22:04Z

playbooks/openstack/sample-inventory/group_vars/all.yml

@@ -0,0 +1,147 @@
+---
+env_id: "openshift"
+public_dns_domain: "example.com"


michaelgugino · 2017-11-01T16:23:05Z

roles/openshift_openstack/defaults/main.yml

@@ -0,0 +1,95 @@
+---


Need lots of namespacing here.

michaelgugino · 2017-11-01T16:24:14Z

roles/openshift_openstack/tasks/container-storage-setup.yml

+- block:
+    - name: create the docker-storage config file
+      template:
+        src: "{{ role_path }}/templates/docker-storage-setup-overlayfs.j2"


don't need '{{ role_path }}/templates/' here.

michaelgugino · 2017-11-01T16:24:33Z

roles/openshift_openstack/tasks/container-storage-setup.yml

+- block:
+    - name: create the docker-storage-setup config file
+      template:
+        src: "{{ role_path }}/templates/docker-storage-setup-dm.j2"


don't need '{{ role_path }}/templates/' here.

michaelgugino · 2017-11-01T16:24:38Z

roles/openshift_openstack/tasks/container-storage-setup.yml

+- block:
+    - name: create the docker-storage-setup config file for CentOS
+      template:
+        src: "{{ role_path }}/templates/docker-storage-setup-dm.j2"


don't need '{{ role_path }}/templates/' here.

michaelgugino · 2017-11-01T16:26:16Z

roles/openshift_openstack/tasks/check-prerequisites.yml

+  - "{{ openstack_etcd_image }}"
+  - "{{ openstack_dns_image }}"
+  loop_control:
+    loop_var: image


this needs a better name. Probably don't need this variable, using {{ item }} is self-explanatory to the end-user/developer that something is looping over the play.

michaelgugino · 2017-11-01T16:26:46Z

roles/openshift_openstack/tasks/check-prerequisites.yml

+    loop_var: image
+
+# Check that custom flavors are available
+- include: custom_flavor_check.yaml


Same comment as the image task above.

michaelgugino · 2017-11-01T16:29:16Z

roles/openshift_openstack/tasks/node-configuration.yml

+
+- include: node-network.yml
+
+- name: "Verify SELinux is enforcing"


nit: I would move this to the top of this file, or somewhere much earlier in the play run.

Because the templates are present in a role, the `template` module is able to look them up directly, without having to use `{{ role_path }}/templates`.

The `openstack_*_network_name` vars are strings, not booleans, so the absense shouldn't really be marked by `False`.

This makes sure that all the variables used in the `openshift_openstack` role are prefixed with `openshift_openstack_` as is the convention.

tomassedovic · 2017-11-02T17:58:24Z

That should address the latest batch of comments. I've namespaced everything and tested the deployment still works (it does!).

michaelgugino

/lgtm

michaelgugino · 2017-11-02T18:30:57Z

@tomassedovic Thank your for taking the time to address all of my comments. I realize it was a non-trivial amount of work and I appreciate the level of effort you provided.

This looks to be in pretty good shape now, I think it can be merged.
@sdodson would you like to look this over again or have someone else review it?

@tomassedovic Are you going to push a new PR with all the commit history?

tomassedovic · 2017-11-02T18:33:27Z

@michaelgugino yep, that's the plan. I'll create a new PR tomorrow that has all the git history.

bogdando

Just thinking of CASL folks who use the provisioning playbooks as a dependency, let's make sure we'll keep the old naming working, yet added a deprecation warnings. This can be done in follow up patches I suppose. Until then, CASL team could continue using the "old" location of the modules.

tomassedovic · 2017-11-03T13:27:10Z

Right so when I said "tomorrow" I apparently meant "at some point within the next 10 days or so". I'm too busy with travel right now and I'm not sure when I'll be able to get to this.

michaelgugino · 2017-11-03T16:29:54Z

Just thinking of CASL folks who use the provisioning playbooks as a dependency, let's make sure we'll keep the old naming working, yet added a deprecation warnings. This can be done in follow up patches I suppose. Until then, CASL team could continue using the "old" location of the modules.

I don't want to bring in a bunch of deprecated variables. casl should be the project where these deprecated variables are managed.

oybed · 2017-11-05T18:06:28Z

@michaelgugino @bogdando Agreed on the deprecated variables. The CASL project will monitor this PR and adopt to it. Also; I have some additional follow-up changes that I'd like to submit to make some of the HEAT templating more generic.

@tomassedovic I see some references to the DNS aspect still. Will that be addressed in a follow-up clean-up PR?

mbruzek · 2017-11-06T14:12:49Z

I will have to make several changes to variable names when this code lands, but it looks very similar to what I am using now. I looked over the changes and did not see any problems or issues at this time.
/lgtm

tomassedovic · 2017-11-07T03:53:14Z

@oybed yeah, that's the plan. At this point, I'd rather merge it and clean it up. We'll have to address DNS in followup patches anyway.

tomassedovic · 2017-11-07T04:00:22Z

Closing this PR in favour of #6039 which preserves the git history from openshift-ansible-contrib.

tomassedovic added 5 commits October 18, 2017 14:46

Port over the OpenStack provisioning code

fc9e3f7

This just copies all the files from the contrib[1] repo over. The changes will be addressed in subsequent commits. [1]: https://github.com/openshift/openshift-ansible-contrib/

.gitignore casl-infra

a94929b

Update lookup plugins path

5fbcce5

Update readme

8b22420

Use the docker-storage-setup role

033b197

openshift-ci-robot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Oct 18, 2017

michaelgugino suggested changes Oct 26, 2017

View reviewed changes

tomassedovic added 4 commits October 27, 2017 17:50

Remove the extra roles

f17c69e

The `openstack-stack` role is now under `openshift_openstack` and the `openstack-create-cinder-registry` one will be added there, later.

Remove the openstack custom-actions for now

1806f8d

They're duplicating a lot of functionality that's already in openshift-ansible and they're not actually used from the provisioning playbooks. We'll revisit them later.

Remove the post-install and scale-up playbooks

504f2c9

They're not necessary for the initial PR so let's add them properly later.

Use correct host group in provision.yml

b5daa51

bogdando suggested changes Oct 30, 2017

View reviewed changes

tomassedovic added 4 commits November 1, 2017 11:43

FIXUP ANSIBLE CFG

660608e

Move the vars/main.yml to defaults

01a9b26

The contents of roles/openshift_openstack/vars/main.yml were moved to the defaults/main.yml file instead. There are now duplication warnings we need to address, but the deployment does still work.

Remove the subnet_update_dns_servers task list

2bac623

It's no longer being used.

Add the DNS updates and rename the openstack vars

9e07520

Most of the vars in `roles/openshift_openstack/defaults/main.yml` are now prefixed with `openstack_`.

michaelgugino suggested changes Nov 1, 2017

View reviewed changes

tomassedovic added 7 commits November 2, 2017 10:07

Move the selinux check up

67fe2a9

Use the default item loop variable for checks

250e09c

Simplify the template paths for the storage setup

247d1c7

Because the templates are present in a role, the `template` module is able to look them up directly, without having to use `{{ role_path }}/templates`.

Use null instead of False where it makes sense

b16d898

The `openstack_*_network_name` vars are strings, not booleans, so the absense shouldn't really be marked by `False`.

Namespace the OpenStack vars

43ae229

This makes sure that all the variables used in the `openshift_openstack` role are prefixed with `openshift_openstack_` as is the convention.

Fix tox

271a819

Namespace the docker volumes

4fa7d49

michaelgugino approved these changes Nov 2, 2017

View reviewed changes

bogdando approved these changes Nov 3, 2017

View reviewed changes

openshift-ci-robot assigned mbruzek Nov 6, 2017

openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Nov 6, 2017

tomassedovic mentioned this pull request Nov 7, 2017

Add the OpenStack provider #6039

Merged

tomassedovic closed this Nov 7, 2017

		@@ -0,0 +1,49 @@
		---
		stack_name: "{{ env_id }}.{{ public_dns_domain }}"


		- include: node-network.yml

		- name: "Verify SELinux is enforcing"

Add openstack provider #5797

Add openstack provider #5797

Uh oh!

Conversation

tomassedovic commented Oct 18, 2017

Current status

Deployment workflow overview:

History

Some differences from the AWS provider

Additional questions and notes

Uh oh!

tomassedovic commented Oct 18, 2017

Uh oh!

michaelgugino commented Oct 18, 2017

Uh oh!

bogdando commented Oct 19, 2017

Uh oh!

tomassedovic commented Oct 19, 2017

Uh oh!

bogdando commented Oct 23, 2017

Uh oh!

michaelgugino commented Oct 23, 2017

Uh oh!

tomassedovic commented Oct 26, 2017

Uh oh!

tomassedovic commented Oct 26, 2017

Uh oh!

michaelgugino left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tomassedovic commented Oct 27, 2017

Uh oh!

michaelgugino commented Oct 27, 2017

Uh oh!

tomassedovic commented Oct 27, 2017

Uh oh!

tomassedovic commented Oct 27, 2017

Uh oh!

bogdando left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bogdando commented Oct 30, 2017

Uh oh!

tomassedovic commented Oct 30, 2017

openshift-ci-robot commented Nov 1, 2017 •

edited

Loading