toscalixopenSUSE transformation step 2. The user oriented distro.
Goals are easier to achieve if you have a good reference to beat. For those who worked in the project, Gentoo and specially Arch Linux were those references. As you can imagine, transform openSUSE required management support. We had it, specially from Roland Haidl, Operations and Communities Director at SUSE back then. He created the environment that allowed those who worked in his department to be creative.... and take risks.
Simplifying, for the new "development version", a.k.a Tumbleweed (former Factory), the goal was to implement a model that allowed us to improve the existing Factory one, based on continuous delivery. The target chosen were our core contributors (packagers fundamentally) and the metric was, in summary, to make sure that, no matter how wrong things could go after an update, you would always have a console and network, so you would be able to revert your change. In terms of the process, the resulting integration deployment processes should be transparent, not just internally but also from our community members perspective. It also needed to be simpler in order to gain contributors, not just users. And it needed to empower them to own it.
Instead of following what SUSE was doing back then, the company dedicated resources to challenge itself. As result, openSUSE Tumbleweed is today, not just the best rolling distro out there, with all what that means in terms of excitement among its contributors, but is generating higher value to SUSE, since the company have an outstanding playground at home that allows them to incorporate true innovation into their production process before their competitors do.
openSUSE is discussing nowadays to take a second step, this time focused on its user oriented version. Today is openSUSE 13.2.
In my opinion, based on the previous experience, and independently of the decision/discussion process chosen, the same steps need to be taken. They are unavoidable in any transformation process. It is necessary to define a clear goal, something short that you can explain and understand easily, a clear target and a key metric that helps to clarify the "acceptance criteria" to be used during the whole process.
Like back then, I would like to see SUSE challenging itself, putting in question well established principles within the OS industry. Again, choosing a reference would make the final picture easier to achieve.
Most openSUSE users are desktop users and sysadmin. If, as I conclude from the latest oSC15 videos and factory mailing list discussions, sysadmins are the chosen target, It would be great to see SUSE/openSUSE challenging the assumption that, through a continuous delivery process, you cannot release a stable and high quality (for the target) distribution. That stability is only achievable through a waterfall like model. I would choose CoreOS as reference. It is a project that, based on different questions, is providing innovative answers to new challenges.
I would like to see that, base on the current process (standing on the shoulders of giants) openSUSE/SUSE creates a process that "pulverize" the current mindset, deprecating many of the existing problems, focusing on solving new ones. Imagine the best of both worlds, a new paradigm of OS with the green values.
It took about a year and a half for a dedicated team to release what today is Tumbleweed. I think that this second challenge is bigger than the first one. An even bigger commitment from SUSE will be needed in order to succeed.
I wish them all the best in this new challenge.
The Running Geek … part 2
The Running Geek
Back again … no idea if this means more frequent updates though
MemberDynamically static
Since 26th December 2005, I’ve been runnning this blog with Wordpress. At the time there were little alternatives and finally I had got hold of a host (Dreamhost, at the time) that supported PHP and MySQL without being overly restrictive. 10 years later, things have somehow changed.
The issue
The main reason lies in how Wordpress has evolved over time: no, I’m not speaking about the subjective “bloat”, but the fact that it’s been moving towards a full-blown CMS, which is not what I have in mind to run my blog. Also, performance with many plugins had somehow worsened, in particular when accessing things like the administration interface. Not to mention that plugins itself are still somewhat fragile, and upgrade could still cause harm to your whole site. Lastly, the mere fact that I had to use plugins to lessen the performance impact was off-putting.
It wasn’t just Wordpress, of course. In the past years I’ve found myself unable to write long texts in a browser (and hoping that they won’t get lost in case I accidentally close a tab) and also the way I write posts changed. I much prefer a specialized editor (like this one I’m using) to compose the posts I write.
An alternative is found
So I went and loooked for alternatives around. I’ve looked at Ghost, and while it was reasonably appealing, there weren’t many themes that wanted this page to be like I wanted to (and I wasn’t convinced in handing out money for a premium theme before I was sure it did what I wanted). So I turned to static engines, and for now at least I went for Jekyll, which is what made the page as you see it today.
The learning curve wasn’t particularly steep, and with the help of some tools I was able to convert all the posts from dnenogumi.org with little effort. I also took the time to update some very outdated sections. What took most of the time in the migration was keeping links “WP-compatible”, that is preserving the structure of the page (more or less) as it was before to prevent many 404s, in particular for feeds which are aggregated on Planet KDE. With the aid of (many) plugins and a few tweaks to the nginx configuration, I can say that most of the structure should be in place.
As for the theme, I went for Feeling Responsive by Phlow, but not verbatim. I had to make changes (in short, a fork) because it was meant originally for portfolios and certain features I needed were not present by design. What I did was to clone the repo and hack in whatever I needed.
Deployment
I use my own GitLab instance to host the repository (now private, I’ll make it public the moment everything is up and running), coupled with micro Flask application that fires off the rebuilding to a script running to my server. I also wrote a couple of programs to make a new posts and commit the data (or to make new drafts).
All that glitters is not gold
A bad note is comments: I had to go for Disqus unfortunately, as even when I managed to set up Discourse, the complexity of the platform was overwhelming for me, which required only comments for a blog, and nothing else. That, and the reliance on Docker, which meant another PostgresQL server running (I have already one up which powers my GitLab instance. I’m really not happy about it. Should you know a better solution, let me know!
Should you find issues with the page, also let me know. I’ve been testing this for a while but of course I didn’t manage to find everything. In particular now the “Gallery” is gone, and I’ll still need to experiment for plugins to auto-create thumbnails and so on.
Credits
Of course this leverages on work of other people, which I feel they’d be credited:
- The aforementioned Phlow for the theme;
- Melissa Adkins for her work on banner images and typography.
Travel Support Program presentation video from oSC15
With this post, I would like to thank Andy Waafa for presenting Travel Support Program at openSUSE Conference 2015 at Den Haag.
Unfortunately, I couldn't make it to the conference due to family health problems (everything will be fine by the end of June 2015).
For those of you who didn't make it to the conference, here is the presentation.
Thank you Andy for helping me, Izabel and Marcel.
Working remotely as a Software Engineer
SUSE Ruling the Stack in Vancouver
Last week during the the OpenStack Summit in Vancouver, Intel organized a Rule the Stack contest. That's the third one, after Atlanta a year ago and Paris six months ago. In case you missed earlier episodes, SUSE won the two previous contests with Dirk being pretty fast in Atlanta and Adam completing the HA challenge so we could keep the crown. So of course, we had to try again!
For this contest, the rules came with a list of penalties and bonuses which made it easier for people to participate. And indeed, there were quite a number of participants with the schedule for booking slots being nearly full. While deploying Kilo was a goal, you could go with older releases getting a 10 minutes penalty per release (so +10 minutes for Juno, +20 minutes for Icehouse, and so on). In a similar way, the organizers wanted to see some upgrade and encouraged that with a bonus that could significantly impact the results (-40 minutes) — nobody tried that, though.
And guess what? SUSE kept the crown again. But we also went ahead with a new challenge: outperforming everyone else not just once, but twice, with two totally different methods.
For the super-fast approach, Dirk built again an appliance that has everything pre-installed and that configures the software on boot. This is actually not too difficult thanks to the amazing Kiwi tool and all the knowledge we have accumulated through the years at SUSE about building appliances, and also the small scripts we use for the CI of our OpenStack packages. Still, it required some work to adapt the setup to the contest and also to make sure that our Kilo packages (that were brand new and without much testing) were fully working. The clock result was 9 minutes and 6 seconds, resulting in a negative time of minus 10 minutes and 54 seconds (yes, the text in the picture is wrong) after the bonuses. Pretty impressive.
But we also wanted to show that our product would fare well, so Adam and I started looking at this. We knew it couldn't be faster than the way Dirk picked, and from the start, we targetted the second position. For this approach, there was not much to do since this was similar to what he did in Paris, and there was work to update our SUSE OpenStack Cloud Admin appliance recently. Our first attempt failed miserably due to a nasty bug (which was actually caused by some unicode character in the ID of the USB stick we were using to install the OS... we fixed that bug later in the night). The second attempt went smoother and was actually much faster than we had anticipated: SUSE OpenStack Cloud deployed everything in 23 minutes and 17 seconds, which resulted in a final time of 10 minutes and 17 seconds after bonuses/penalties. And this was with a 10 minutes penalty due to the use of Juno (as well as a couple of minutes lost debugging some setup issue that was just mispreparation on our side). A key contributor to this result is our use of Crowbar, which we've kept improving over time, and that really makes it easy and fast to deploy OpenStack.
Wall-clock time for SUSE OpenStack Cloud
These two results wouldn't have been possible without the help of Tom and Ralf, but also without the whole SUSE OpenStack Cloud team that works on a daily basis on our product to improve it and to adapt it to the needs of our customers. We really have an awesome team (and btw, we're hiring)!
For reference, three other contestants succeeded in deploying OpenStack, with the fastest of them ending at 58 minutes after bonuses/penalties. And as I mentioned earlier, there were even more contestants (including some who are not vendors of an OpenStack distribution), which is really good to see. I hope we'll see even more in Tokyo!
Results of the Rule the Stack contest
Also thanks to Intel for organizing this; I'm sure every contestant had fun and there was quite a good mood in the area reserved for the contest.
Update: See also the summary of the contest from the organizers.
Install ddclient on your openSUSE Raspberry Pi
1. First of all, install the program.
2. Create the confing file
with the following content
timeout=10
syslog=no # log update msgs to syslog
#mail=root # mail all msgs to root
#mail-failure=root # mail failed update msgs to root
pid=/var/run/ddclient.pid # record PID in file.
ssl=yes # use ssl-support. Works with
# ssl-library
use=if, if=eth0
server=freedns.afraid.org
protocol=freedns
login=login_name
password=the_password
somedomain.mooo.com
Change the ones that are in bold letters.
3. Start the service
Reboot
Upgrade your openSUSE Raspberry Pi from 13.1 to 13.2
We've seen how to create an SD card. I used the 13.1 version. The wiki page https://en.opensuse.org/HCL:Raspberry_Pi is not very clear (to me) about resize partitions. So I tried to upgrade the version 13.1. Here what I did.
1. Check if the update repository already exists and is enabled.
You should have the following enabled
If not, then add it
2. Refresh and update your system
3. Remove all third party/OBS repos you no longer need.
# Remove with
$ zypper rr (alias or number)
4. Change all remaining repo URLs to the new version of the distribution (needs to be run as root).
5. Change the repos.
6. Refresh new repositories (you might be asked to accept new gpg key)
If you haven't removed third party/OBS repositories you may encounter some errors as these repositories may not exist yet or they may have different unguessable URL. It is always recommended to remove them and add their newer version after upgrade.
7. Upgrade
Now you have to wait. Reboot at the end, just to be sure that everything went smooth.