August one of the best months of 2018 for me, because for the first time I was accepted as a speaker at the 2018 OpenSUSE Asia Summit held in Taiwan, precisely in Taipei, one of the countries that I have never visited.

Before departh

on this departure I departed with several groups from their openSUSE Indonesia: Pak Kukuh, Pak Yan Arief and Pak Didiet. we went to taiwan boarding a China Airlines plane at 14:10 and arrived in Taiwan at 20:40 Taiwan time, and this was my first experience using international aircraft.

this is when we take photos at Taiwan MRT

and after we arrived in Taiwan we bought the MRT card to use the MRT there, after that at around 11:00 p.m. we arrived at the First Hostel, here I was roomed with several people, including Gus Aftian, Pak Darian, Pak Joko, Pak Kukuh and Kakek Yan Arief.

Day 0

on Friday, we all plan to take part in the openSUSE meeting, which is in the Micro Focus SUSE office in Taiwan, and we went there after we prayed Friday at the Taiwan Grand mosque. because we waited for a very long bus, finally we all decided to walk to the SUSE office after Friday prayers, WOW!

After we arrived there, we were placed in a different room because the main room was full

here we are at the SUSE Taiwan office Me at SUSE Office Taiwan

and in the night, there was a party speaker invitation, there I met a lot of cool people whom I haven’t memorized until now

before party speaker, Libre Office Taiwan invited us for dinner

Dinner with Libre Office Asia

the great place for speaker party

21.00 we back to hostel for tomorrow

Day 1

and the Event began, this year the OpenSUSE Asia Summit event was joined by several other major events, namely GNOME Asia Summit, and COSCUP

in this day i join to class 304

after that, on the night I attended the BoF openSUSE session, where we determined some things for next year, the openSUSE Asia Summit 2019

Day 2

Today is the day that most excited me, because on the second day I will present my paper in class 304, and also because this is the first time for me. My class started at 11.30 and it turned out that there were quite a lot, and after I talked about it, Igawa, one of the openStack and openSUSE Japanese contributors, asked about the differences between Nextcloud and Owncloud, and I was really nervous this is me with Masayuki Igawa

after the summit, the Indonesian contingent travels to the ximending night market and buys some souvenirs

No items found.

Day 3 – one day tour

After that event, many speaker join to one day tour at Taiwan, some of the places we visited were the National Palace Museum and Taipei 101, we went there by bus from Taipei Main Station. yes, before going to the destination we all gathered at Taipei Main Station

This is us

after that Pak Darian and team went first to the airport because the plane would fly tonight. And those who have not gone home, we are invited to eat together, thanks to Frank and Eric who have invited us

and Tomorrow me, Pak Kukuh, Kakek Yan Arief and Pak Didiet return to Jakarta on the hour 08.45

Epilog

This year was a very pleasant year, contributing with many great people. I hope next year you can join the next summit.

Thanks to Max Huang for holding this cool event, thanks to openSUSE and all who have contributed. you are great !

Sumber Foto:

• https://www.flickr.com/groups/gnomeasia2018/
• https://www.flickr.com/groups/3094051@N21/
• https://www.flickr.com/photos/coscup/albums/

In the spring of 2014 I was a college student in an IT program applying to coop job postings and needed something to differentiate myself from the other applicants. I decided that I would start a blog where I document random things I found interesting. Sound really broad? That’s because I didn’t really have any particular focus in mind and wanted to experiment with different topics. I think in the long run this was a good decision as it let me see what I was comfortable with, what worked and what didn't. This is the kind of thing you can learn best from experience but I will go more into detail about this later. For now, lets get back to my life story.

blog --init 💥

The first post came in April of 2014 titled Programming Paradigms. And yes I used WordPress back then. The post was short — 25 words — with a link to a YouTube series by Dr. Jerry Cain. If a picture is a thousand words I guess this video is 31.05 million (17.25min * 30fps * 1000words)? Does it work like that? 😅

Projects

After a few months I started working on a C++/Qt project called TLE. I used my blog to post screenshots and mockups (helpfully drawn by a close friend) whenever I got something interesting working. I’m confident to say that no one read it, but it was still nice just being able to get my thoughts onto “paper”. It helped me think about what I was doing and how I would explain it to someone who had never worked on the project before.

Getting Traction

As this was all going on, I started participating in the openSUSE community. I would post on the forums, the mailing lists and even in the IRC channel. I began to notice there were common questions about new releases and the direction of the project. So what did I do? I wrote blog posts explaining it for people who didn't have the time to watch the conference videos.

At this point the frequency of my posts got slower, partly due to the posts getting longer and partly due to being busy with school. To keep my blog alive I started blogging about things I was doing in school. This is how I started blogging about technical content (how to’s, beginners guides, etc.). The very first post like this was about configuring a DNS server in CentOS 6.6:

When I started posting these I began to notice that the traffic to my blog was increasing significantly. This gave me the confidence to try and write some bigger guides.

Moving To Medium

I discovered the existence of Medium around July 2016. I was really intrigued by the website since it looked really nice compared to my blog and seemed to be very popular with writers. After a bit of debating I decided to switch to Medium. A major reason I switched was in hopes that I would get better exposure. I wrote a reflection about using Medium that you can read here.

The Comprehensive Guide To AppArmor

In July 2016 I also released a guide to AppArmor called The Comprehensive Guide To AppArmor. The desire to create the post came from wanting to understand how AppArmor worked but having difficulty finding documentation that explained everything. So I decided to work with the developers of AppArmor to write a guide which explains all the basics you need to know to use AppArmor. The guide can be found here. This is one of the most unique posts I have ever written as it went through several revisions and I had constant feedback from the actual developers of AppArmor — something I don't usually get from tools I write about.

Becoming A Dev

In 2016 I graduated from my college and felt that I would still like to learn more about computers. So I decided to sign up for a transfer program that lets college students transfer into year 3 at McMaster university. At the end of my first year (April 2017) at McMaster we were allowed to apply to internship jobs and thinking it was good to get some work experience I applied. I ended up getting a position as a Software Developer Intern at Ontario Teachers’ Pension Plan (OTPP).

During my time at OTPP I worked with both JavaScript and Java. At the same time I was working on personal projects in my free time. At the start I started trying to re-implement a project I had created in school — a podcast feed. For our school project we had implemented it using Qt but the code was a mess and we had no tests. I decided to build the app again but this time using JavaFX — because it would help me get better at Java for work — and to test it, something I learned the importance of at work. While developing this application I learned a lot about testing philosophies and how to test JavaFX. Noticing that there was almost no documentation for TestFX — a library used to test JavaFX applications — I wrote some (you can find here).

This post turned out to be quite popular as there seems to be demand for testing JavaFX but a lack of documentation.

Saka

Spring of 2018 and I ended up becoming the maintainer of a browser extension called Saka. As I took over for the previous maintainer I was forced to learn a lot of the tools used in JavaScript projects. Things like Webpack, Karma, Babel and so on. As I began to understand the project I realized that there were no tests to validate the behavior of the application. This caused me worry — I didn’t have confidence in myself to modify code without breaking other parts of the app. So I decided to learn how browser extensions were tested and realizing it was not documented well I wrote a blog post titled Unit Testing Browser Extension that you can read here.

Saka represents a pretty important milestone in my journey as a dev. For the first time I was maintaining a project I had full control of that other people actually used! It was very exciting but also a bit nerve wrecking — I didn’t want to break it and lose users as a result. Looking back, it was a great idea to take over Saka since I have learned so much about JavaScript while maintaining it and it has inspired a lot of content on this blog.

Reflection

As my life has changed so has my blog. In a way it is a reflection of where I am with my life, what my focuses are and what goals I have for the future. It has changed quite a bit from what it started out as but I think it has only gotten better. It took me a long time to become confident enough to write my own content but it has been important in helping me learn new things and helping others do the same.

If you liked this post be sure to follow this blog, follow me on twitter and my blog on dev.to.

P.S. Looking to contribute to an open source project? Come contribute to Saka, we could use the help! You can find the project here: https://github.com/lusakasa/saka

Some Thoughts On Blogging was originally published in Information & Technology on Medium, where people are continuing the conversation by highlighting and responding to this story.

Trustr is my current project to create a simple certificate management app.
I decided that it is just about the right scope to demonstrate a few things about application development in Horde 5.

I have not made any research if the name is already occupied by some other software. Should any problems arise, please contact me and we will find a good solution. I just wanted to start without losing much time on unrelated issues.

My goals as of now:

– Keep everything neat, testable, fairly decoupled and reusable. The core logic should be exportable to a separate library without much change. There won’t be any class of static shortcut methods pulling stuff out of nowhere. Config and registry are only accessed at select points, never in the deeper layers.
– Provide a CLI using Horde_Cli and Horde_Cli_Application (modeled after the backup tool in horde base git)
– Store to relational database using Horde_Db and Horde_Rdo for abstraction
– Use php openssl extension for certificate actions, but design with future options in mind
– Rely on magic openssl defaults as little as possible
– Use conf.xml / conf.php for any global defaults
– Show how to use the inter-app API (reusable for xml-rpc and json-rpc)
– Showcase an approach to REST danabol ds in Horde (experimental)

The app is intended as a resource provider. The UI is NOT a top priority. However, I am currently toying around with a Flux-like design in some unrelated larger project and I may or may not try some ideas later on.

Initial Steps: Creating the working environment

I set up a new horde development container using the horde tumbleweed image from Open Build Service and a docker compose file from my colleague Florian Frank. Please mind both are WIP and improve-as-needed projects.


git clone https://github.com/FrankFlorian/hordeOnTumbelweed.git
cd hordeOnTumbelweed
docker-compose -f docker-compose.yml up

This yields a running horde instance on localhost and a database container.
I needed to perform a little manual setup in the web admin ui to get the DB to run and create all default horde schemas.

Next I entered the developer container with a shell
docker exec -it hordeOnTumbelWeed_php_1 bash

There are other ways to work with a container but that’s what I did.

Creating a  skeleton app

The container comes with a fairly complete horde git checkout in /srv/git/horde and a clone of the horde git tools in /srv/git/git-tools

A new skeleton app can be created using

horde-git-tools dev new --author "Ralf Lang <lastname@b1-systems.de>" --app-name trustr

The new app needs to be linked to the web directory using

horde-git-tools dev install


Also, a registry entry needs to be created by putting a little file into /srv/git/horde/base/config/registry.d

cat trustr-registry.d.php

<?php
// Copy this example snipped to horde/registry.d
$this->applications['trustr'] = array(
'name' => _('Certificates'),
'provides' => array('certificates')
);

This makes the new app show up in the admin menu. To actually use it and make it appear in topbar, you also need to go to /admin/config and create the config file for this app. Even though the settings don’t actually mean anything by now, the file must be present.

I hope to follow up soon with articles on the architecture and sub systems of the little app.

On Wednesday, I had a presentation about the latest features implemented for LibreOffice / Collabora Online in the past year at the annual LibreOffice Conference:

Please enjoy, there's a lot of screenshots there!

Bukan perjalanan pertama saya melalui rute ini, namun tak salah menuliskan catatan ini.

Pesawat saya berangkat Kamis pagi jam 8.15 dengan Catay Pacific CX-718. Saya sudah melakukan checkin online sebelumnya melalui website dan memilih nomor kursi. Catay Airways hanya mengijinkan melakukan checkin online mulai dari 48 jam sebelum keberangkatan. Kemudian saya memilih Muslim Food dari menu checkin Catay. Pilihan Muslim Food hanya tersedia di Penerbangan HK-TPE, sedangkan dari CGK-HK semua makanan adalah Halal. Untuk penerbangan pulang, pilihan Muslim Food hanya tersedia dalam penerbangan TPE-HK, sedangkan HK-CGK semua makanan dinyatakan halal, sehingga tidak perlu memilih lagi. Selalu bawa botol minum isi ulang.

Di bandara Terminal 2F, saya segera melakukan checkin dan drop bagasi. Meski berangkat bertiga, urusan ini mending diselesaikan sendiri tanpa harus tunggu-tungguan. Lanjut imigrasi karena bagian ini cukup memakan waktu. Sampai di loket imigrasi, tebakan saya benar, antrian mengular. Butuh 15 menit dari awal antri hingga pemerikasaan saya selesai. Huft. Sampai di bagian Gate baru mencari Pak Edwin dan Pak Haris yang ternyata sudah duduk ngopi dan sarapan di Old Town Coffee. Oh iya, dalam penerbangan internasional terdapat banyak catatan dalam barang bawaan yang biasanya rewel juga, diantaranya:

1. Aturan benda cair dalam botol, maksimal 100ml dan dimasukkan ke kantong zipper bening.
2. Sebelum x-ray terakhir, pastikan botol minum dikosongkan. Nanti bisa diisi kembali di water refil setelah x-ray tersebut.

Boarding 40 menit sebelum jam keberangkatan. Penerbangan ditempuh dalam kurun waktu 5 jam 10 menit. Terdapat perbedaan waktu antara Jakarta dan Hongkong, yaitu lebih cepat 1 jam. HK GMT+8. Saya langsung mengatur jam tangan dan jam di HP agar ikut berganti. Perjalanan saya habiskan dengan tidur, membaca novel dan mendengarkan musik. Terdapat layanan hiburan yang memadai di dalam kabin pesawat.

Oh iya, saya lupa penerbangan Catay menggunakan pesawat jenis berapa, namun di kedua pesawat itu terdapat colokan universal yang bisa digunakan untuk mencharge HP. Ada dua kemungkinan lokasi colokan itu berada. Pilihan pertama ada di lipatan meja makan. Yang kedua pilihannya di bawah kursi, di bagian pertemuan kursi. Silahkan diraba perlahan. Oh iya, ada indikasi lampu hijau yang hidup menandakan charger bisa digunakan karena jika lampu tidak hidup, berarti tidak ada arus yang berjalan. Lampu beberapa kali mati, biasanya ketika akan lepas landas, ada goncangan dan ketika akan mendarat.

Saya sedikit rewel jika berada dalam ruangan AC cukup lama. Apalagi jika di dalam pesawat. Ini menyebabkan hidung saya iritasi kemudian mimisan. Makanya saya selalu menggunakan masker dalam pesawat jika lama penerbangan lebih dari 2 jam. Tak lupa jaket tebal bertudung kepala.

Mendarat di HK pukul 14.20 waktu setempat. Setelah membawa bagasi kabin, kemudian menuju couter checkin transit. Nyari tempat isi ulang air minum, minum secukupnya. Lanjut menuju gate transit. Butuh naik 1 lantai dan kemudian dilakukan pemeriksaan ulang, x-ray bagasi kabin dan screening. Pastikan sebelum masuk pemeriksaan, kosongkan botol minum agar mempercepat proses scanning.

Koneksi internet di Bandara HK saya acungi jempol. Cukup aktifkan Wi-Fi kemudian pilih nama access point untuk bandara HK, setujui persyaratan dan peraturan. Setelah itu bisa berinternet ria tanpa pembatasan durasi berinternet. Untuk kecepatan tidak perlu dikomentari, cukup cepat.

Menuju Gate penerbangan selanjutnya. Tetapi butuh menemukan tempat sholat. Di terminal HK, tempat sholat dapat ditemukan di dekat Gate 42-43. Peralatan solat, mukena dan alquran tersedia rapi. Arah kiblat juga tersedia. Tempat wudhu tersedia di dalam ruangan. Perlu dicatat juga, mushola tersebut bukan merupakan tempat ibadah khusus muslim. Jadi kita kemungkinan akan berbagi ruang dalam sunyi dengan pemeluk agama lain.

Selesai sholat, kita mencari makan. Restoran Halal tersedia juga di foodcourt sekitaran Gate 40. Old Town Coffee. Makanan semenanjung malaya dan Indonesia.
Saya memilih kari ayam dengan harga 92 Dolar HK termasuk Es Teh Manis.

Selesai makan, kita bergeser ke Gate 62 dimana kita melanjutkan perjalanan selanjutnya ke TPE. Dalam pesawat kita dibagikan lembar pengisian informasi kedatangan. Saya sebelumnya sudah mengisi secara online, tapi nulis lagi gpp. Jadi selalu bawa ballpoint di tas kabin untuk memudahkan mengisi form pelaporan. Karena dengan mengisi ketika masih di pesawat, bisa mempercepat kita dalam antrian imigrasi.

Mendarat. Kemudian buru-buru antri imigrasi. Butuh sekitaz 20 menit antri hingga keluar imigrasi. Lanjut ke konter bagasi untuk mengambil koper. Sembari antri, saya mampir toilet dan mengaktifkan pake Mi Roaming Taiwan. Apa itu Mi roaming? Akan saya ceritakan di postingan selanjutnya.

Keluar bandara, sudah di jemput oleh Franklin Weng. dan cerita berlanjut ke tulisan ini

Salam
Estu

Yesterday I was watching a talk by Ben Ilegbodu at React Alicante called Help! My React App is Slowwwww! in which Ben discussed some optimizations developers can make to help improve performance of React applications. He goes over many of the potential bottlenecks that may arise such as unnecessary DOM updates, reconciliation and unnecessary object creation. It’s a really interesting talk and I encourage you to watch it (link below) but what I found most interesting was his first point about unnecessary DOM updates.

When trying to optimize performance of web apps, we can look for actions that are bottlenecks and try to minimize the amount of times the application performs these actions. It turns out updating the DOM is a very time consuming operation. It is in fact so time consuming that React has a process called reconciliation that exists to try and avoid unnecessary updates.

Unfortunately as Ben shows in his talk — and as I will show in this post — there are still situations where reconciliation will not be able to help us. However we don’t need to lose hope because there are some simple tweaks we can make to address the issue.

The 🔑 to Lists

This is a really handy trick you can use to optimize the rendering of list items in React. Suppose you have a page that displays a list of items and is defined as follows:

When the button is clicked, it will add an item to the list. This will then trigger an update to the DOM to display our new item along with all the old items. If we look at the DOM inspector while clicking the button we see the following (orange indicates the node is updating):

See how all the list items are updated? If we think about this for a moment this doesn’t actually seem like an ideal update. Why can’t we just insert the new node without having to update all the other nodes? The reason for this has to do with how we are using the map function in the List component.

See how we are setting the key for each list item as the index? The problem here is that React uses the key to determine if the item has actually changed. Unfortunately since the insertion we are doing happens at the start of the list, the indexes of all items in the list are increased by one. This causes React to think there has been a change to all the nodes and so it updates them all.

To work around this we need to modify the map function to use the unique id of each item instead of the index in the array:

And now when we click the button we see that the new nodes are being added without updating the old ones:

So what’s the lesson?

Always use a unique key when creating lists in React (and the index is not considered unique)!

The Exception ✋

There can be situations where you do not have a truly unique id in your arrays. The ideal solution is to find some unique key which may be derived by combining some values in the object together. However in certain cases — like an array of strings — this cannot be possible or guaranteed. In these cases you must rely on the index to be the key.

So there you have it, a simple trick to optimize list rendering in React! 🎉🏎

If you liked this post be sure to follow this blog, follow me on twitter and my blog on dev.to.

P.S. Looking to contribute to an open source project? Come contribute to Saka, we could use the help! You can find the project here: https://github.com/lusakasa/saka

A Simple List Render Optimization For React 🏎 was originally published in Information & Technology on Medium, where people are continuing the conversation by highlighting and responding to this story.

Наконец-то увидел свет новый движок портала https://kde.ru, посвященного русскоязычным пользователям KDE и проету KDE в частности. И хотя сам я уже давно KDE не пользуюсь, до сих пор многое связывает меня с этим проектом. Именно с разработки KDE начался мой путь в мир свободного ПО. Еще будучи студентом я познкомился с проетом GNU, Linux и Qt3, а уже после, в Германии – когда я начал работу в SUSE – занимался разработкой и портированием стека KDE4 на openSUSE (больше всего постов в этом блоге именно о KDE и openSUSE). Мы тогда еще сидели на svn, помните что это такое?
После SUSE я забросил проект KDE, опробовал и пересел на различные window managers. До тех пор, пока не устроился разработчиком LiMux (Kubuntu на основе собственной management-системы на основе LDAP) тут, в Мюнхене. И хотя занимался я в основном security-проектами,  было приятно вспомнить и почти весь KDE стек, который мы создавался более чем 10 лет назад.

Это очень интересный проект. Да, он большой, очень большой, и не всегда это хорошо, тем не менее он обладает самой на мой взгляд продуманной архитектурой. Программировать KDE всегда было здорово не только из-за мощи Qt и самым новейшим инструментам, используемым в проекте, но и благодаря идеям, заложенным в основу структуры стека его компонентов. Очень важным в проекте KDE всегда было сообщество людей, его разрабатывающих. Его окружило много молодых инженеров, открытых для новых, а порой даже и для откровенно сумасшедших идей. Это так освежало. Это так вписывалось в природу свободного ПО. Я никогда не забуду эти хиппи-тусовок по всей Европе, куда мы добирались по ночам и самыми сумасшедшими способами, доклады, подготавливаемые и читаемые друг другу просто ради удовольствия.

Я рад, что и в России есть люди, продолжающие разработку и продвигающие этот проект. Хочу пожелать вам, ребята, удачи. Постарайтесь сохранить эту атмосферу, сводящую с ума и увлекающую за собой. Я думаю, это самый большой стимул для разработки ПО. Увлечение процессом, удовольствие от наконец-то найденного решения, восхищение его элегантностью и простотой. Все это KDE, все это – сообщество людей, его продвигающих.

Adapted from announcement to opensuse-factory mailing list:

Tumbleweed Snapshots, fixed repositories containing previously released versions of Tumbleweed, are now officially hosted on download.opensuse.org! For those not familiar with the Tumbleweed Snapshots concept please see the short introduction video and the presentation I gave at oSC18. The overall concept is to allow Tumbleweed to be consumed as short-lived distributions that can be utilized after a new snapshot is published. The two primary benefits are not having to update just to install new packages and being able to sit on an older snapshot when avoiding problematic package updates. The latter working best with snapper rollbacks as it allows for normal system operation after rolling back.

Given the proper method for updating between snapshots is zypper dup instead of zypper up which is normally reserved for updating between major releases of the distribution, like Leap, keeping the previous repositories and switching between them with the use of dup is quite natural. Given the latest snapshot is accessible and zypper operates normally there are no down-sides to this approach while providing some important advantages. If you have not already tried them I would encourage you to do so. Many users are already updating Tumbleweed once a week and thus perfectly align with the design of snapshots.

The installation step and basic usage is documented in the tumbleweed-cli README. No additional resources are utilized on the local machine. If for whatever reason you want to go back just run tumbleweed uninit to restore the default repository setup.

If you are already using Tumbleweed Snapshots and would like to switch to the official hosting a migration command is provided in tumbleweed-cli 0.3.0 which will be included in Tumbleweed shortly. As a side-note, bash completion is also provided!

Once running version 0.3.0 (run tumbleweed --version to see which is installed), simply run tumbleweed migrate. Keep in mind the official hosting only provides 10 snapshots while my personal hosting on S3 provides 50. The count will hopefully be increased in the future, but given how long it has taken to get this far it may be some time. Additionally, my AWS hosting has a CDN setup and will likely remain faster until mirrors decide to host the snapshots. Based on feedback and how things progress I will decide when to stop hosting on AWS, but it will be announced and the tumbleweed-cli will be changed to auto-migrate.

For those interested, the difference in storage usage can be compared on metrics.opensuse.org.

• Official hosting
• Un-official hosting

Making Tumbleweed Snapshots the default is likely worth considering once everything settles and an appropriate level of adoption by mirrors is reached.

It is encouraging to see the enthusiastic discussions about Tumbleweed Snapshots in IRC and e-mails.

Enjoy!

We’re really excited to announce that as of today, we now officially supports the CRI-O Container Runtime Interface as our default way of interfacing with containers on your Kubic systems!

Um that’s great, but what is a Container Runtime Interface?

Contrary to what you might have heard, there are more ways to run containers than just the docker tool. In fact there are an increasing number of options, such as runc, rkt, frakti, cri-containerd and more. Most of these follow the OCI standard defining how the runtimes start and run your containers, but they lack a standard way of interfacing with an orchestrator. This makes things complicated for tools like kubernetes, which run on top of a container runtime to provide you with orchestration, high availability, and management.

Kubernetes therefore introduced a standard API to be able to talk to and manage a container runtime. This API is called the Container Runtime Interface (CRI).

Existing container runtimes like Docker use a “shim” to interface between Kubernetes and the runtime, but there is another way, using an interface that was designed to work with CRI natively. And that is where CRI-O comes into the picture.

Introduction to CRI-O

Started little over a year ago, CRI-O began as a Kubernetes incubator project, implementing the CRI Interface for OCI compliant runtimes. Using the lightweight runc runtime to actually run the containers, the simplest way of describing CRI-O would be as a lightweight alternative to the Docker engine, especially designed for running with Kubernetes.

As of 6th Sept 2018 CRI-O is no longer an incubator project, but now an official part of the Kubernetes family of tools.

Why CRI-O?

There are a lot of reasons the Kubic project love CRI-O, but to give a Top 4 some of the largest reasons include:

• A Truly Open Project: As already mentioned, CRI-O is operated as part of the broader Kubernetes community. There is a broad collection of contributors from companies including Red Hat, SUSE, Intel, Google, Alibaba, IBM and more. The project is run in a way that all these different stakeholders can actively propose changes and can expect to see them merged, or at least spur steps into that direction. This is harder to say of other similar projects.
• Lightweight: CRI-O is made of lots of small components, each with specific roles, working together with other pieces to give you a fully functional container experience. In comparison, the Docker Engine is a heavyweight daemon which is communicated to using the docker CLI tool in a client/server fashion. You need to have the Daemon running before you can use the CLI, and if that daemon is dead, so is your ability to do anything with your containers.
• More Securable: Every container run using the Docker CLI is a ‘child’ of that large Docker Daemon. This complicates or outright prevents the use of tooling like cgroups & security constraints to provide an extra layer of protection to your containers. As CRI-O containers are children of the process that spawned it (not the daemon) they’re fully compatible with these tools without complication. This is not only cool for Kubernetes, but also when using CRI-O with Podman, but more about that later…
• Aligned with Kubernetes: As an official Kubernetes project, CRI-O releases in lock step with Kubernetes, with similar version numbers. ie. CRI-O 1.11.x works with Kubernetes 1.11.x. This is hugely beneficial for a project like Kubic where we’re rolling and want to keep everything working together at the latest versions. On the other side of the fence, Kubernetes currently only officially supports Docker versions 17.03.x, now well over 1 year old and far behind the 18.06.x version we currently have in Kubic.

CRI-O and Kubernetes

Given one of the main roles of Kubic is to run Kubernetes, as of today, Kubic’s kubeadm system role is now designed to use CRI-O by default.

Our documentation has been updated to reflect the new CRI-O way of doing things.

The simplest way of describing it would be that we now have less steps than before.
You can now initialise your master node with a single command immediately after installation.
But you need to remember to add --cri-socket=/var/run/crio/crio.sock to your kubeadm init and join commands. (We’re looking into ways to streamline this).

CRI-O and MicroOS

Kubic is about more than Kubernetes, and our MicroOS system role is a perfect platform for running containers on stand-alone machines. That too now includes CRI-O as it’s default runtime interface.

In order to make use of CRI-O without Kubernetes, you need a command-line tool, and that tool is known as podman. It is now installed by default on Kubic MicroOS.

Podman

Podman has been available in Tumbleweed & Kubic for some time. Put simply, it is to CRI-O what the Docker CLI tool is to the Docker Engine daemon. It even has a very similar syntax.

• Use podman run to run containers in the same way you’d expect from docker run
• podman pull pulls containers from registries, just like docker pull, and by default our podman is configured to use the same Docker Hub as many users would expect.
• Some podman commands have additional functionality compared to their docker equivalents, such as podman rm --all and podman rmi --all which will remove all of your containers and their images respectively.
• A full crib-sheet of podman commands and their docker equivalents is available

Podman also benefits from CRI-Os more lightweight architecture. Because every Podman container is a direct child of the podman command that created it, it’s trivial to use podman as part of systemd services. This be combined with systemd features like socket activation to do really cool things like starting your container only when users try to access it!

What about Docker?

As excited as we are about CRI-O and Podman, we’re not blind to the reality that many users just won’t care and will be more comfortable running the well known docker tool.

For the basic use case of running containers, both docker and podman can co-exist on a system safely. Therefore it will still be available and installed by default on Kubic MicroOS.
If you wish to remove it, just run transactional-update pkg rm -u docker-kubic and reboot.

The Docker Engine doesn’t co-exist with CRI-O quite so well in the Kubernetes scenario, so we do not install both by default on the kubeadm system role.
We still wish to support users wishing to use the Docker Engine with Kubernetes. Therefore to swap from CRI-O to the Docker Engine just run transactional-update pkg in patterns-caasp-alt-container-runtime -cri-o-kubeadm-criconfig and reboot.

Alternatively if you’re installing Kubic from the installation media you can deselect the “Container Runtime” and instead choose the “Alternative Container Runtime” pattern from the “Software” option as part of the installation.

Regardless of which runtime you choose to use, thanks for using Kubic and please join in, send us your feedback, code, and other contributions, and remember, have a lot of fun!.