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:
The documentation says that to access a minishift-deployed VM you can use `minishift ssh` to log in, but what if you want to use other tooling (like Ansible) to get in there? How can you use standard ssh commands to connect?
In the interest of simplifying the development and deployment of Kubevirt, we decided to make sure it was possible to run with minishift. After downloading and running the minishift binary, I had a working minishift cluster. However, in order to deploy the api-server to the cluster, I needed an external IP; otherwise I’d get the error:
Error:
service "" is invalid spec.externalIPs: Forbidden: externalIPs have been disabled
Here is how I got around this error.
I spent the past six work days in a courthouse as a juror. It was a civil case, involving a house repair after a burst pipe flooded it. Verdict went in at around 3 PM (Aug. 2)
There is so much you don’t know on a jury. You can only consider the evidence placed before you…and sometimes you have to forget something you learned before the witness reacts to the word “Objection.”
It was a construction case, and, despite having grown up as the son (and sometimes employee) of a construction contractor, they chose me anyway. I don’t think it colored my reasoning anyway.
Based on this incomplete information, we had to award money to one or the other; doing nothing was, in effect, awarding money to the client who had not paid.
While I did not agree with the other eleven people on the jury about all of the outcomes (there were several charges both ways) I was very thankful to have all of them share the burden of making the decision. I can only imaging the burden carried by a judge in arbitration.
On the other hand, in arbitration, the judge can do research. We couldn’t. We had to even forget things we know about construction (like you postpone work on the outside to get the people back inside) if it was not presented as evidence.
I was very thankful to have my dad to talk this over with afterwards as he has fifty plus years in the construction industry. He clarified some of my assumptions (based on the incomplete information I gave him) and I think I can let go of my doubts. I can sleep soundly tonight knowing I did the best I could, and that, most likely, justice was served.
The number one thing I took away from this experience is, with anything involving contracting, or money in general, is to get everything in writing, communicate as clearly as possible. Aside from covering you for a future lawsuit, it might help prevent that lawsuit by keeping the other person on track. Run your business such that someone else could step in and take over from you, and know exactly what you were doing…or you can hand over what you want to a brand new contractor and they could take over. Obviously, that is a high bar to clear, but the better you do, the better for all involved.
Bottom line up front:
cluster/vagrant/sync_build.sh cluster/kubectl.sh delete -f manifests/virt-controller.yaml cluster/kubectl.sh create -f manifests/virt-controller.yaml |
When tests fail, as they often will, the debugger can greatly shorten the time it takes to figure out why. The Kubevirt functional tests run essentially as a remote client. Getting a debuggable setup is not that different from my earlier post on running virt-launcher in the debugger.
While developing Kubevirt, I often want to step through my code. My most recent tasks have involved the virt-controller process. Here’s how I debug them.
Continue reading