My cloud may not look like your cloud. The contract between the application deployment and the Kubernetes installation is a set of manifest files that guide Kubernetes in selecting, naming, and exposing resources. In order to make the generation of the Manifests sane in KubeVirt, we’ve provided a little bit of build system support.
I have been geting prepped to build the OpenShift origin codebase on Centos 7. I started from a fairly minimal VM which did not have docker or Development Tools installed. Once I thought I had all the prerequisites, I kicked off the build and got
Cannot connect to the Docker daemon. Is the docker daemon running on this host? |
This seems to be due to the fact that the ayoung user does not have permissions to read/write on the domain socket. /var/run/docker.sock
In my continued investigations of networking stuff, I came across the question “How do you bond two ethernet devices together?”  While I did this years ago on RHEL3, I have pretty much forgotten how, so I decided to research and relearn this.
I recently created a new Centos VM. When it booted, I noticed it did not have a working ethernet connection. So, I started playing with things, and got it working. Here are my notes:
Once I got the Ansible playbook to run, I was able to poke at the openshift setup.
The install creates a default configuration in the Ansible users home directory on the master node.
While many people referred me to run one of the virtualized setups of OpenShift, I wanted something on baremetal in order to eventually test out KubeVirt. Just running
oc cluster up
As some people suggested did not work, as it assumes prerequisites are properly set up; the docker registry was one that I tripped over. So, I decided to give openshift-ansible a test run. Here are my notes.
I have two machines beyond the Laptop on which I am currently typing this article. I want to manage them from my workstation using Ansible. All three machines are running Fedora 25 Workstation.
My eventual goal is to deploy Keystone using Kubernetes. However, I want to understand things from the lowest level on up. Since Kubernetes will be driving Docker for my deployment, I wanted to get things working for a single node Docker deployment before I move on to Kubernetes. As such, you’ll notice I took a few short cuts. Mostly, these involve configuration changes. Since I will need to use Kubernetes for deployment and configuration, I’ll postpone doing it right until I get to that layer. With that caveat, let’s begin.
Continue reading
Rex was setting up a server and wanted some help. His hosting provider had set him up with a username and password for authentication. He wanted me to log in to the machine under his account to help out. I didn’t want him to have to give me his password. Rex is a smart guy, but he is not a Linux user. He is certainly not a system administrator. The system was CentOS. The process was far more difficult to walk
Once I have the undercloud deployed, I want to be able to quickly deploy and redeploy overclouds. However, my last attempt to affect change on the overcloud did not modify the Keystone config file the way I intended. Once again, Steve Hardy helped me to understand what I was doing wrong.