Today was another wet day but unlike yesterday, the Muni streetcar came on time this morning. After my usual walk from the BART station to the office, I continued where I left off yesterday.
Looking at my to-do list sheet, I looked at systemd for most of my early morning and then looked at Kubernetes Incubator’s Service Catalog. This is was perhaps the easiest entry to contributing to Kubernetes with the help of Carolyn who works at Microsoft. It was also through her help that I was able to make my first pull request on this repository. Watching one of their recorded meetings on youtube and contributing again are certainly on my to-do list.
After the kick off meeting for the new scrum team that I’ll be a part of, I chatted with Nick, to get a better scope of what’ll be doing for today day. Ignition tests were his emphasis. So I accessed my container linux VM, booted it on the booted file system which was made possible using Cork.
Cork is an OS tool that changes the root of my machine’s files system when doing $ cork enter on the command line within the coreos_sdk directory as specified in this guide. Cork comes bundled with Qemu but your machine should have virtualization enabled first. So essentially I am skipping this guide on installing Container Linux on top of Qemu by installing Cork straightaway. The first thing I did with Ignition is that I tried using ignition as a user (one who’s interested in trying out Container Linux) then would proceed to understand how I could do develop/improve it. This sounded like plausible workflow.
As I have discovered yesterday, it is important to save it somewhere/remember exactly the password you’ve entered after running ./set_shared_user_password.sh . Otherwise, you’ll need to build your image again which takes a long time! Additionally, you can generate ssh keys through this guide and then feed it when you ssh into the container linux VM.
The getting started with Ignition guide was perhaps the least informative, and found this github issue to be more valuable in getting started with ignition on Container Linux than any of the Ignition guides available. This took me a considerable amount of time reading between the website which has better readability and with the docs on github (which has less readability) but eventually, I stuck with github. As Andrew and I have noted yesterday, the updated docs on github weren’t showing on the Ignition website.
With that considerable amount of time searching, understanding and then knowing what keywords to search for, the github issue that I’ve found helped me significantly. Through that issue, I learned about journalctl and that is used to stdout (show) the processes of a service like ignition (the one you specify).
Feeding an ignition config file with the .ign extension to the VM is simple as doing $ ./coreos_production.img -i config.ign -nographic . The ignition config file just needs to be in the same directory when you invoke this command or specify the path.
This is where it gets interesting. Ignition only reads the config file once. Rebooting with any Ignition config file again will not work because an ignition config file has already been booted with it once and it won’t do it again regardless if the file was changed in any way.
So ways to work around this that I didn’t understand in the beginning but eventually understood as I am writing it down here:
./image_to_vm.sh generates the Container Linux image that is bootable. This is a clean image, as in, it is not used before. In terms of VirtualBox, it is the image that you first loaded onto VirtualBox and that you have not initiated the install (or started it before kind of state).
./coreos_production_qemu.image and the directory for it, store the logins, states, etc and keep track if an ignition config has been feed to it before. Rebooting the image with an ignition config file again does not mean it will booted for the first time with ignition (because it has already done so). ./coreos_production.image initiates the install, user login, etc which allows you to enter the guest OS.
I initially thought that ./coreos_production_qemu.image loads the image, starts the install every time I invoke this command. Meaning I thought that states weren’t being saved and that I was accessing a new Container Linux guest OS each time.
Does this mean I have to have a clean image of Container Linux again? Or one that was not booted with ignition before? It seemed that way, but with Derek’s explanations, I learned about the fact in the paragraph above this one and this neat trick that he taught me:
After doing, for example (with any options you want):
When Qemu loads GRUB i.e the bootloader (the very first thing you’ll see), press “e” quickly once and you’ll see a line of words with the $ sign next to them (will include screenshot) go to the end of the line that says “linux”, add a space and put “coreos.first_boot=1”. Finally, press Ctrl+x to continue with booting the machine.
$ journalctl -t ignition –no-pager will show the ignition process log and will specify in the log if the config file was empty or not. In the case that if it was empty (otherwise you’ll see the ignition config file contents in JSON), you’ll need to start the whole procedure again, make sure the format is correct and that you do not include the -s option (safe mode) when starting the image with ./core_production_qemu.image .
Now that I understood how to use ignition with Container Linux. It was time to learn how to develop it. This guide is not shown on the CoreOS Ignition website, but found here:
./test <– checks for license headers and checks vendor
And then there’s the blackbox tests, which will run on the host OS. To exit out of Cork (the booted file system) is by doing $ exit on the command line. The following is the prefered way of doing these tests:
./build_blackbox_tests builds ./tests.test
Tomorrow I’ll continue from:
and do something with RedHat Atomic!