For the second year in a row, I was fortunate enough to attend FOSDEM. FOSDEM (Free Open Source Developers European Meeting) takes place every year at the Universite libre de Bruxelles, Solbosch Campus. It is always massive conference (~5000+ attendees) and is always good fun with tasty, tasty beer!
A two-day event organised by volunteers to promote the widespread use of free and open source software.
This post is going just my opinion on the small number of talk I could go to. I encourage you to watch the videos of other talks from this years FOSDEM and previous years. I will also be (with some luck in quick succession) 3 other posts: FOSDEM - Day Two, CfgMgmtCamp - Day One and CfgMgmtCamp Day Two. I got quite the busy little trip at the start of this month.
Managing Container Infrastructure
Piotr Kliczewski - Senior Software Engineer/Community lead for oVirt
Kliczewski's talk was base on a several usecases demonstrating the advantages of combining VM technology and containers. Kliczewski showed how ManageIQ, OpenShift and oVirt made this possible and relatively simple. The main take away of this talk is the importance of the relationship between virtualised instances and the hardware on which they run.
1 - Maintenance
In this usecase, we have two hosts: Host0 and Host1. Host0 is running several VMs (which are running several containers each) and is in need of some maintenance. With ManageIQ you can migrate all VM instances from Host0 to Host1 with no noticeable effect on the applications running in the containers. This allows the containers to continue providing their services uninterrupted, while maintenance is performed on Host0.
Other cloud solutions do not provide this functionality as there isn't an apparent relationship between where a container is running and the host on which it is running.
2 - Location of Replicas
Again we have two hosts: Host0 and Host1.
Host0 is running two VM instances of our ServiceA, responsible for running the ServiceA containers. One container is active and the other is a hot spare.
Host1 is running have one instance of our ServiceB VMs running multiple containers of ServiceB. Both of these scenarios provide the same High Availablility advantages Z each other. Even though we are running fail over or multiple instances for redundancy, if the hypervisor they are running on loses network connectivity, we would lose either of the services. Even though we attempted to provide redundancy, we fail to because of the single point of failure that is the shared hardware.
ManageIQ allows you to set a restriction on where duplicate instances run, to help avoid these issues.
3 - Node distribution
If we were hosting from multiple different data-centres we could distribute/redistribute VMs and containers across our fleet evenly based on load, perhaps even move containers across data centres based on latency to a connected client. This also encapsulates the previous use case where we ensure keep parts of our product don't run on the same physical server or we want duplicates across data centres for HA reasons.
4 - Crashes and Mitigation
Say we have Host0, Host1 and Host2. Host2 is our hot spare VM host. Host0 and Host1 are active machines, we could migrate any VMs FROM the other two hosts to Host2 if failures started to occur.
For instance Host0 is running ServiceA and ServiceB. ServiceA is IO intensive and ServiceB is time sensitive. ServceB may crash or perform poorly due to it's noisy neighbour. Upon detecting this sort of behaviour we can migrate and enable rules to separate these two VMs from running on the same machine.
Another case would be if Host1 suddenly suffered a failure. ManageIQ could migrate all instances from Host1 to Host2 and they would continue running the as if nothing had happened.
The relationship between contianers, VMs and their physical hosts matter. Having this information available and the ability to manipulate your services based on that information it is important for reliability.
Next Generation Configuration Management
James Shubin (@purpleidea) - RedHat The Technical Blog of James
Shubin demostrated the progress of his new tool mgmt
The main three ideas behind the tool are:
- Parallel execution
- Event driven mechanism
- Distributed architecture
The talk was mostly a series of demos showing mgmt's current capabilities. Shubin is a bit of a demo wizard and was damn interactive with the audience, because of this I would encourage you to go and watch his debconf or FOSDEM video.
On a side note: I have actually started working on macOS support for mgmt, so mgmt might feature on the blog sometime soon.
Making Your Own Open Source Raspberry Pi HAT
Leon Anavi - Senior Software Engineer, Konsulko Group
Hat != HAT
- One of the first slides in the talk
That slide one got me, I had some spare time between talks so I went to this interestingly titled one. It wasn't about hats with embedded Raspberry Pis.
The talk was about designing Raspberry Pi HATs (Hardware Attached on Top). These are 65×56mm boards which connect via the 40 pin Raspberry Pi B+ GPIO pins. A HAT also has to provide a device tree fragment to follow the HAT standard.
I currently don't have any need to be designing my own hardware for the RPi so didn't take many notes about this one. There is a fantastic website pinout.xyz which is a directory for Raspberry Pi hats
Krause Aehlig - Software Engineer, Google
This was an interesting talk for me; I have recently come into contact with Bazel while working with TensorFlow at work.
Bazel is the core part of a tool called Blaze, the system which builds Google. It has been used to build Google for years.
The main design points of Bazel have been:
- Build one (giant) mono repo
- Agressively cache as much as possible
- Use declaritive style for BUILD files
- Partial rebuilding
- Subsequent builds should update the dependency graph and rebuild only the parts that have changed.
- Support remote execution
- Team based caching when using build clusters
- Skylark is the build language for Bazel.
Bazel has been slow in open sourcing, at the time of writing the core teams main focus is the continued stability for use inside Google. Apparently, there is also a lot of propeitry code/extensions compiled in when used internally and it is littered with hard coded paths and links to internal services. It seems to me that this project might have just been opened sourced because TensorFlow already using it before it was released and also to improve the code quality of the tool for free.
1.0 is due for release sometime in 2018.
Continuous Integration at the Distribution Level
Martin Pitt - Canonical
Pitt described the differences betweens Ubuntu's old 6 month release cycle and their new approach.
Every 6 months they would unfreeze for 4 months, push as many updates as possible and spend 2 month fixing bugs. Pitt said on average at release they would have corrected about 60% of the newly introduced bugs.
Ubuntu has since moved onto a new rolling approach to releases and have added testing to packages.
A lots of this testing came from dep8 and autopkgtest. They then built some infrastructure services around this to provide better testing. A large portion of packages now have tests which autopkgtest can run.
Building a Distro with Musl LibC
Nathanael Copa (@n_copa)
I have recently heard a bunch of people talking about musl libc, so I decided to go to this talk, to see what the fuss was about.
Musl is designed to be a small, light weight and correct libc implementation and Alpine Linux is designed to be a small, simple and secure Linux. Alpine Linux currently targets Docker so providing a small libc implementation aids in this goal. Copa discussed some issues with uClibc (it is old buggy and an ugly codebase) in comparison to musl libc (new, simpler, more secure, stable and in active development).
Using Musl libc will help improve the quality of your application when compiled against it because of the correctness it has (in view of the C standard and to safety) and it has an nice (annoyingly correct) active community.
All ages: How to build a movement
Deb Nicholson (@baconandcoconut) & Molly de Blanc (@mmillions)
Nicholson and de Blanc discussed the issue of ageism in FOSS and the overall tech industry, this being an issue which effects everyone but especially how this effects minority groups in the industry.
This was on of my favorite talks, it brings to light an issue I have noticed but of which I wasn't really aware. Nicholson and de Blanc do an amazing job in this talk explaining how improving inclusivity of a project or workplace culture can improve its diversity (you need to make everyone welcome). As everyone should know not only is diversity right but it improves the work and ideas you create in a group.
Seriously, I encourage you to go watch the video. I don't do justice to these two when I describe this issue and it is one that deserves thought and attention.
If you have any feedback or comments about this style of post let me know. Just contact me I'm @neuralsandwich on twitter and most other places.