Kevin's musings

After reading http://groveronline.com/2013/06/fedora-for-servers/ and the comments on lwn ( https://lwn.net/Articles/552800/ ) I thought I would share some thoughts on this.

First, I agree with Andy that this is a good way to use Fedora instances. With so many ways to spin up quickly a instance that does just exactly what you need it to these days, this should work great for a number of use cases. Lennart points out that containers is a even quicker/more minimal way to do things for some use cases ( https://plus.google.com/115547683951727699051/posts/G1DTXebUGGN ). Tie this to a CM like ansible and it’s easy to fire up and test your app in the next Fedora and move to it when you are ready, or even in an updated Fedora of the same version you are currently running.

Some of the comments on the lwn article in particular reiterate a strange divide that I see in the open source world. This group of folks wants a platform where they can exactly specify every version of everything they use and never have to change those versions based on external factors. To this group spinning up a Fedora instance to run their app on isn’t that appealing because Fedora the distribution only offers usually single versions of packages (or perhaps some compat packages for backward compatibility in some cases), so they have to manage their own versions/updates/setup. For them the platform itself should be only whats needed so they can bring up their own stack of tools. Thats a perfectly valid use case, and perhaps one Fedora should target some more.

That said, I’m still not sure I understand why there are so many folks who wish to design/build/maintain applications that way. Is this a fallout from many projects/people using “agile” development? Perhaps it shows my age, but what ever happened to designing an application such that it used interfaces other things it needed exposed and working with those other projects to make sure those interfaces were still stable over time or porting to new ones was possible/not too difficult? Why wouldn’t you want to leverage the distributions packaged versions of projects you depend on? Sure, you have your app working on Fedora 18 and then in Fedora 19 libfoo is libfoo2, so you keep using Fedora 18 until you have ported your app to use libfoo2 and then spin up Fedora 19 test instances and test until you are sure your app is working right. If libfoo2 dropped some functionality you needed, could you not ask them to readd it or add some new way to do the same thing?

The trade offs here seem poor to me, but of course everyone will do things the way they feel is best for their use case. I have a feeling that applications developed with a ‘ship my exact versions’ will more and more start seeing the issues in this model as time goes on, but we will see.

Fedora 19 is winding up to release soon, and so it’s that time in the cycle when a new fedora-release package pushes out that disables the fedora-updates-testing repository so folks who install after this point don’t get testing packages unless they opt in.

That update just pushed into the base Fedora 19 repo today: https://admin.fedoraproject.org/updates/fedora-release-19-2

This means if you have a Fedora 19 install you installed before today you very likely have updates-testing packages installed.

You should do one of the following things:

a) If you wish to help test updates ( https://fedoraproject.org/wiki/QA:Updates_Testing ) You should simply re-enable the updates-testing repoistory: “sudo yum-config-manager –enable updates-testing” and go on to help test and provide feedback for testing updates.

b) If you do not wish to continue to test updates-testing packages, you will need to sync your install with only the released/base/stable repository: “sudo yum distro-sync” and then you can move forward only getting the normal updates.

Note that in both cases you should continue to have the base fedora repository and the fedora-updates repository enabled. See ‘yum repolist’ if you wish to see what you have enabled.

With Fedora 19 being final (release is tuesday), I went and upgraded my main virthost and guest from Fedora 18 last night.

I used fedup to upgrade a laptop and another machine, but as my main server is a bit more complex, I usually just do a yum upgrade on it. Looking at: https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_18_-.3E_Fedora_19_.28pre_release_branched.29 there is currently only one gotcha noted there (systemd cgroups changing). I didn’t hit anything related to that, but I rebooted pretty soon after the transaction finished. Aside: There were a few texlive packages I had installed for some reason, which resulted in a vast increase in texlive packages after the distro-sync, so I went ahead and removed those before syncing to avoid that.

After rebooting I was hard pressed to find any problems, but finally did manage to find one: All my mysql using applications were no longer able to connect to the database. Digging into logs showed me that it was a password format change between the old Fedora 18 mysql and new Fedora 19 mariadb. I simply had to go in and set the passwords for those users again and it updated to the new hash setup and started working. Not sure if this is something that could be fixed in a mariadb update or noted in release notes, but it’s easy enough to fix up.

So far thats it. Everything else is working just fine, no problems at all.

I think Fedora 19 is going to be a very good release, hope everyone enjoys it.

As many folks may know, Seth Vidal was taken from us this last Monday Night.

He will be dearly missed by many. He was part of many families: Fedora, Red Hat, Open Source community, Biking enthusiasts and many many more. I knew him for many years in the Fedora Community, then when I joined Red Hat and started working with him every day I knew him even better.

Why did I title this an “Incomplete” rememberance?

Two reasons: First of all, it’s impossible to convey in something as trivial as a blog post what he meant to all those he touched.

He was always ready to be a sounding board for ideas, and more often than not he would get you to rethink some idea in a much more elegant way or get it to lead to a much bigger and impressive idea.

He was always looking out for his friends. Either to ask you if all was ok, or commiserate about some problem that was happening.

He was a master of open source tools. If you asked some random question on IRC, he would often say “just a second” and come back with a script that did exactly what you wanted. He didn’t do this just for people he knew, but anyone with problems to be solved.

He was patient with anyone who wanted to learn.

He had a terrific sense of work/life balance that I often wished I had. He would always be there if servers crashed or some urgent issue came up, but was quick to push less urgent issues off to ride his bike or walk his dog or spend time with his partner.

He had a way of gathering people at Fudcons or the like. After sessions were over you could always find a circle of people around him laughing and talking.

He always somehow remembered little things about everyone he knew. What you liked, something interesting in your area of interest he came across.

And so much more. 

The second reason I call this an Incomplete remembrance is that while Seth is gone, he’s not really GONE. He lives on in all the people he touched, all the communities he strengthened and all the code he wrote for the world to enjoy. So, the next time you ‘yum update’ your Fedora or RHEL machine, or use coprs, or use the ansible yum module, or anything he touched, remember him. The next time someone tells you their crazy idea, ask yourself “What would Seth say?” and help them make their idea more grand and awesome than they could ever have possibly imagined.

You will be missed, but never forgotten.

I’m a happy consumer of the excellent cyanogenmod android distro, and recently they have started doing a short weekly blog post with interesting things of note that happened in their community over the last week. I figured this might be a nice thing to try and do for Fedora Infrastructure too. Not sure if I will keep it up, but I’ll give it a go and if you find it interesting let me know. 😉

We had a meeting on IRC with a general overview and some things we need to sort out with our migration to ansible. You can read the meeting minutes at: http://meetbot.fedoraproject.org/meetbot/fedora-meeting-1/2013-07-17/infrastructure-ansible-meetup.2013-07-17-19.00.html help or comments always welcome. Many of the outstanding questions are things we likely will discuss and finish planning at the upcoming flocktofedora conference. There’s also now a wiki page with this information on it too: https://fedoraproject.org/wiki/Infrastructure_ansible_migration

We just finished up a long outage of our koji buildsystem. It went down at 21UTC on thursday and was back up around 20UTC today. This outage was to move out backend storage for builds. We were bumping up against capacity on our existing storage, so we wanted to move over to a place with more room to grow. Additionally, we tweaked the koji db instance (it’s a virtual as so many of our hosts, and it wasn’t using virtio for it’s disks) to be a lot faster. I also took the change to reinstall all of our builder instances. Ansible did pretty short work of the reinstall/reconfig. About 40 instances reinstalled and updated to the latest packages. We also did clean reinstall and config on all our arm builders (48 now added to the primary buildsys). Look for arm package import and enabling in Fedora 20 soon. 😉