OpenStack supports “provider” networks, which are networks that pre-exist in your physical infrastructure and are “provided” to the cloud users rather than created by the user. Only an admin is permitted to create a provider network. A prequisite is the provider network must be plumbed to the external bridge on your controller and nova nodes. Here is an Ansible playbook to create a project, place a unshared provider network and subnet in that project.
This playbook is written for RHEL 7.2 and OSE v3.1. It will perform the following steps which should take place before running the openshift-ansible byo playbook. Install prerequisite RPMs like docker, python, etc. Persist the systemd journal for easier debugging Setup docker ephemeral storage on 2nd disk Turn off swap Enable use of NFS in selinux Prerequisites See my Testing OpenShift Enterprise V3 post for the prereqs. The Playbook The lastest version is available here.
You just deployed a complex multi-host app using Ansible. Wouldn’t it be helpful to see a overview of the deployment including hardware details? I just found ansible-cmdb which combines info from the Ansible inventory and discovered facts to create a detailed HTML report akin to a Configuration Management Database. To use it in your playbook dir, just create a directory to hold facts discovered by the setup module then generate the report.
The OpenShift Origin project provides Ansible playbooks and roles for installing OpenShift on various infratructure. I’m going to try out the example using Vagrant and VirtualBox on my Mac. I’m not very familiar with Vagrant or OpenShift v3 yet, so I’m just going to think out loud and see how it goes. I’ve also recently started testing OpenShift Enterprise. Some Background OpenShift Origin is an opensource PaaS (platform as a service).
Ansible is Awesome! Ansible is a Mess! So you found Ansible, and you were all Woah! Ansible is awesome! Ansibilize all the things! Then you created a git repo and started hacking. Playbooks look in the current directory to find roles, libraries, and inventories, so naturally you put everything in one big git repo, right? You tried to follow the best practices for writing playbooks, you created roles, and maybe you wrote a filter plugin or a custom module for configuring an application unique to your environment.
Starting with a jumbled git repo of various Ansible roles, playbooks, inventories, group_vars, etc. I want to create a new repo out of a selection of the subdirectories and retain the commit history. I have an ansible-test repo with a tree that looks roughly like this: . ├── adhoc/ │ ├── rolling-reboot.yml │ └── scripts/ ├── README.md └── runtime/ ├── roles/ │ ├── foo-role/ │ └── zimbra/ │ ├── ansible.cfg │ ├── hosts │ ├── tasks/ │ └── .
Zimbra is a email collaboration suite. Its various compontents perform MTA duties, message store, full text indexing. In a large environment, the number of files and I/O operations can really add up. How we ensure the filesystem is ready to support it? Zimbra’s Recommendations Zimbra offers some guidance for tuning the filesystem, with tips like: Mount file systems with the noatime option. It generally is not important to know the last access time of all the files, so the extra write ops are wasteful.
Zimbra is a email / collaboration suite that is typically deployed in a cluster or clusters of dedicated servers which fill roles like LDAP master, LDAP replica, Proxy, MTA, Mailstore, etc. The LDAP servers are used by all the other servers to store configuration and provisioning data. Servers in the cluster understand where to find the LDAP master (read/write) and LDAP replicas (read only) though values defined in /opt/zimbra/conf/localconfig.xml. There are 2 values relevant to LDAP server lists and they have values like this: