Anyway, long story short spending some face time with other contributors and working out the kinks that existed in the pipeline worked wonders.  Rather than sending a small patch here and there the main implementation for openSUSE and SLE, lots of code, were accepted shortly after the cloud-init summit and over the last couple of days another couple of patches took us another step forward.

There are a few more loose ends that need work but with 17 patches removed from the package build, currently building in Cloud:Tools:Next in OBS we’ve made major progress.

Well, I for one am happy about this, and those that want to install from source can do so and have openSUSE and SLE support working from the upstream sources and not just from the packages included with openSUSE and SLE.

Thanks to Canonical for organizing the summit to get everyone together and thanks to Google for hosting the summit.

Oh and before I forget, getting the changes accepted was not the only major step forward, openSUSE Leap 42.3 will, in the not too distant future, like in the next couple of days, be integrated into cloud-init testing using containers the lxd project builds, go figure who knew these even existed.

With the end of 2014 my first term on the openSUSE board is already coming to an end, time flies. During my first term we collectively have seen many changes to our project. Many of these changes were difficult and I would say we had a rough ride for a good chunk of th last 2 years. I think, and am hoping others agree, that I was able to help smooth some of the rough spots and help the project move into what could now be considered calmer waters. It was not easy, but I am glad I was able to contribute.

Since 2009 I work for SUSE in the ISV Engineering team. When I started I primarily worked with IBM on joint projects. I also worked with other ISVs helping them with questions regarding their application on top of SUSE Linux. In recent years my role has transitioned and I am now focused on Public Cloud work, working with our partners.

I have been using SUSE Linux, now known as the openSUSE distribution since the beginning, i.e. I still remember when SUSE Linux 10 was released. I have been contributing to the project for many years, not from the get go, it took me some time to move from user to contributor, by maintaining packages, more recently also maintaining and publishing openSUSE images in the public cloud, and helping with organization of events. For the past two years I also had the privilege to contribute to the project as a board member. I would very much enjoy being able to continue my contribution to the board for another 2 years.

Looking forward I see the need that an effort needs to be made to re-invigorate our project. As a whole the distribution “business” has lost some of its appeal and shine. Something that is certainly to be expected. Never the less even in a world that is getting more and more dominated by cloud services, containers, and whatever else, distributions are a necessity and the openSUSE distributions always stands out as one of the top notch community distributions. We have also proven that there is still plenty of innovation potential with the recent merge of Tumbleweed and Factory, turning what was previously a pure development stream into a usable rolling release. The credit for this of course goes to the Factory team, release team and many others that contributed to the new tools and backend infrastructure that make all this possible. Re-invigoration for me not only means being proud and excited about such major technical accomplishments but also means we need to be better organized when it comes the representation of our project at FOSS events. Although the new booth box material is great we have had a difficult time getting things organized and helping those that want to represent the project at events. I want to continue to push on this part and help make the distribution of material better. There is plenty of work to be done at the board level and I am asking for your vote in the upcoming election to allow me to continue what is already in the works and help start new initiatives to re-invigorate our project.

Since LSB 4.1 and previous releases is a monolithic requirement, i.e. if you depend on lsb you depend/get everything that is in the standard, whether you want it or not, it is very likely that many applications depend on lsb while needing only a subset of the features. Thus, while we do not know all of those applications and cannot provide a list of “this will work and that will not“, there is a good chance that many external packages depending on lsb will not only install, but the payload they deliver will work with an lsb best effort approach. For those applications that are broken there is pretty much nothing we can do, sorry.

At a meeting last week at LinuxCon NA the goal was set to have LSB 5.0 released by the end of October. LSB 5.0 is incompatible with LSB 4.1 and prior releases. Thus, even if we provide an lsb 5.0 compliant package in short order after LSB 5.0 is released we still have the same risk as we do with the best effort approach. Basically some application packages that depend on “lsb” will deliver a payload that is broken. Exactly the opposite of what the LSB is trying to achieve, but hey one cannot hang on to Qt3 forever. Therefore, our “lsb best effort” approach to cover the gap does not create any additional pain.

Moving forward the LSB working group decided that the current approach, while providing value, has significant drawbacks. Predominantly there are not enough fingers on the keyboard to continue releases of such extensive “accepted standard” documentation. This is what we presently experience with the non installable lsb package. A for the LSB is being worked out. As this next/new LSB develops we will have to see how application providers deal with this. Without a formal LSB specification in the future, this problem will recur in a few years if application packages depend on a package named “lsb” which at some point may need to seize to exist. We will see how this plays out as the world we create keeps evolving.

It took a bit but I am happy to report that all openSUSE 13.1 images in Amazon EC2, Google Compute Engine and Microsoft Azure public cloud environments have been refreshed. After the latest round of the GNU-TLS and OpenSSL fixes the security was, as usual, extremely efficient in providing fixed packages and these have been available in all cloud images via zypper up since last Friday. As of today the base images available in the public cloud frameworks contain the fixes by default.

In Amazon the new images are as follows:

• ap-northeast-1: ami-79296078
• ap-southeast-1: ami-84a7fbd6
• ap-southeast-2: ami-41cbae7b
• eu-west-1: ami-b56aa4c2
• sa-east-1: ami-bffb54a2
• us-east-1: ami-5e708d36
• us-west-1: ami-16f2f553
• us-west-2: ami-b7097487

In Google compute engine the image name is: opensuse-13-1-v20140609

The old image (opensuse131-v20140417) has been deprecated. To access the image you will need to add –image=opensuse-cloud/global/images/opensuse-13-1-v20140609 as the openSUSE images are not yet fully integrated into the GCE framework. Still working on that part with Google. This image also has upgrades to the google-cloud-sdk package and enable the bq (big-query) command. The gcloud command is still a bit rough around the edges, but the gcutil command should work as expected. Eventually gcutil is going to be deprecated by Google thus there is work to be done to fix the integration issues with the gcloud command. If anyone has time to work on that please send submit request to the google-cloud-sdk package in the Cloud:Tools project in OBS. Unfortunately Google still hasn’t posted the source anywhere for open collaboration . They’ll get there eventually. I will try and push any changes upstream.

In Azure just search for openSUSE in the Gallery, it’s more of a point an click thing

And that’s a wrap. Not certain we will be able to improve on the speed of such fire drill updates, but we’ll try to keep refreshing images as quickly as time allows when critical vulnerabilities in the core libraries get exposed.

Have a lot of fun….

Well, that’s the announcement, but would make for a rather short blog. Thus, let me talk a bit about how this all works and speculate a bit why we’ve not been all that good with getting stuff out into the public cloud.

Let me start with the speculation part, i.e. hindrances in getting openSUSE images published. In general to get anything into a public cloud one has to have an account. This implies that you hand over your credit card number to the cloud provider and they charge you for the resources you use. Resources in the public cloud are anything and everything that has something to do with data. Compute resources, i.e. the size of an instance w.r.t. memory and number of CPUs are priced differently. Sending data across the network to and from your instances incurs network charges and of course storing stuff in the cloud is not free either. Thus, while anyone can put an image into the cloud and publish it, this service costs the person money, granted not necessarily a lot, but it is a monthly recurring out of pocket expense.

Then there always appears to be the “official” apprehension, meaning if person X publishes an openSUSE image from her/his account what makes it “official”. Well first we have the problem that the “official” stamp is really just an imaginary hurdle. An image that gets published by me is no more or less “official” than any other images. I am after all not the release manager or have any of my fingers in the openSUSE release in any way. I do have access to the SUSE accounts and can publish from there and I guess that makes the images “official”. But please do not get any ideas about “official” images, they do not exist.

Last but not least there is a technical hurdle. Building images in OBS is not necessarily for the faint of heart. Additionally there is a bunch of other stuff that goes along with cloud images. Once you have one it still has to get into the cloud of choice, which requires tools etc.

That’s enough speculation as to why or why not it may have taken us a bit longer than others, and just for the record we did have openSUSE 12.1 and openSUSE 12.2 images in Amazon. With that lets talk about what is going on.

We have a project in OBS now, actually it has been there for a while, Cloud:Images that is intended to be used to build openSUSE cloud images. The GCE image that is public and the Amazon image that is public both came from this project. The Azure image that is currently public is one built with SUSE Studio but will at some point also stem from the Cloud:Images OBS project.

Each cloud framework has it’s own set of tools. The tools are separated into two categories, initialization tools and command line tools. The initialization tools are tools that reside inside the image and these are generally services that interact with the cloud framework. For example cloud-init is such an initialization tool and it is used in OpenStack images, Amazon images, and Windows Azure images. The command line tools let you interact with the cloud framework to start and stop instances for example. All these tools get built in the Cloud:Tools project in OBS. From there you can install the command line tools into your system and interact with the cloud framework they support. I am also trying to get all these tools into openSUSE:Factory to make things a bit easier for image building and cloud interaction come 13.2.

With this lets take a brief closer look at each framework, in alphabetical order no favoritism here.

Amazon EC2

An openSUSE 13.1 image is available in all regions, the AMI (Amazon Machine Image) IDs are as follows:

sa-east-1 => ami-2101a23c
ap-northeast-1 => ami-bde999bc
ap-southeast-2 => ami-b165fc8b
ap-southeast-1 => ami-e2e7b6b0
eu-west-1 => ami-7110ec06
us-west-1 => ami-44ae9101
us-west-2 => ami-f0402ec0
us-east-1 => ami-ff0e0696

These images use cloud-init as opposed to the “suse-ami-tools” that has been used previously and is no longer available in OBS. The cloud-init package is developed in launchpad and was started by the Canonical folks. Unfortunately to contribute you have to sign the Canonical Contributor Agreement (CCA). If you do not want to sign it or cannot sign it for company reasons you can still send stuff to the package and I’ll try and get the stuff integrated upstream. For the interaction with Amazon we have the aws-cli package. The “aws” command line client supersedes all the ec2-*-tools and is an integrated package that can interact with all Amazon services, not just EC2. It is well documented fully open source and hosted on github. The aws-cli package replaces the previously maintained ec2-api-tools package which I have removed from OBS.

Google Compute Engine

In GCE things work by name and the openSUSE 13.1 image is named opensuse131-20140227 and is available in all regions. Google images use a number of tools for initialization, google-daemon and google-startup-scripts. All the Google specific tools are in the Cloud:Tools project. Interaction with GCE is handled with two commands, gcutil and gsutil, both provided by the google-cloud-sdk package. As the name suggests google-cloud-sdk has the goal to unify the various Google tools, same basic idea as aws-cli, and Google is working on the unification. Unfortunately they have decided to do this on their own and there is no public project for google-cloud-sdk which makes contributing a bit difficult to say the least. The gsutil code is hosted on github, thus at least contributing to gsutil is straight forward. Both utilities, gsutil for storage and gcutil for interacting with GCE are well documented.

In GCE we also were able to stand up openSUSE mirrors. These have been integrated into our mirrorbrain infrastructure and are already being used quite heavily. The infrastructure team is taking care of the monitoring and maintenance and that deserves a big THANK YOU from my side. The nice thing about hosting the mirrors in GCE is that when you run an openSUSE instance in GCE you will not have to pay for network charges to pull your updated packages and things are really fast as the update server is located in the same data center as your instance.

Windows Azure

As mentioned previously the current image we have in Azure is based on a build from SUSE Studio. It does not yet contain cloud-init and only has WALinuxAgent integrated. This implies that processing of user data is not possible in the image. User data processing requires cloud-init and I just put the finishing touches on cloud-init this week. Anyway, the image in Azure works just fine, and I have no time line when we might replace it with an image that contains cloud-init in addition to WALinuxAgent.

Interacting with Azure is a bit more cumbersome than with the other cloud frameworks. Well, let me qualify this with, if you want packages. The Azure command line tools are implemented using nodejs and are integrated into the npm nodejs package system. Thus, you can use npm to install everything you need. The nodejs implementation provides a bit of a problem in that we hardly have a nodejs infrastructure in the project. I have started packaging the dependencies, but there is a large number and thus this will take a while. Who would ever implement….. but that’s a different topic.

That’s where we are today. There is plenty of work left to do. For example we should unify the “generic” OpenStack image in Cloud:Images with the HP specific one, the HP cloud is based on OpenStack, and also get an openSUSE image published in the HP cloud. There’s tons of packaging left to do for nodejs modules to support the azure-cli tool. It would be great if we could have openSUSE mirrors in EC2 and Azure to avoid network charges for those using openSUSE images in those clouds. This requires discussions with Amazon and Microsoft, basically we need to be able to run those services for free, which implies that both would become sponsors of our project just like Google has become a sponsor of our project by letting us run the openSUSE mirrors in GCE.

So if you are interested in cloud and public cloud stuff get involved, there is plenty of work and lots of opportunities. If you just want to use the images in the public cloud go ahead, that’s why they are there. If you want to build on the images we have in OBS and customize them in your own project feel free and use them as you see fit.

Now a new integrated set of tools is available called with the “aws” command and provided by the aws-cli package. The package is available from the Cloud:Tools project and a submit request to Factory is pending. The new package does not obsolete the ec2-api-tools package as there is no issue with having both packages installed. However, I did take the liberty to remove the ec2-api-tool package from the Cloud:EC2 project as it would no longer receive updates considering that we have a nice new tool that unifies all Amazon services. The documentation for the new command can be found .

The aws code is hosted on github and thus contribution of fixes is easy and that is another big plus over the ec2-* tool sets.

Yes, and of course we need to get openSUSE 13.1 into EC2, and I am working on that, stay tuned….

The millions of thank you’s directed toward Kostas and Stella, the driving forces for the organization, are probably not enough. In addition to having a great event we also had the opportunity to learn a lot about what it takes to pull off oSC. Until oSC13 a lot of knowledge about the oSC organization was locked up within SUSE as the primary driving force of the conference organization in previous years. The “locking up” of information was just something that happened due to the nature of the organization of previous conferences. Information inside companies just gets lost, that’s the nature of the beast and this is certainly not intentional. Additionally, at least for me, having the community organized event this year made me think more about what it takes to pull off the organization. I guess with SUSE standing behind the event not just as a sponsor, but also as the lead organizer, it somewhat made the individuals that worked on the organization anonymous. We certainly had great conferences previously and many of us like to think back and reminisce about previous events when we meet. Another point is probably that one thinks that many more resources are brought to bare when a company is behind the organization of an event, although that is not necessarily the case.

Having the community drive the organization for oSC13 is just a completely different feeling, and I think I am not alone with this sentiment. The people that were involved in the organization of previous conferences were always happy to help and share information, and some were intimately involved in pulling things together, thank you.

The knowledge accumulated will certainly spread through the community and a number of meetings and many discussions at oSC13 started this process already. During the live project meeting, a.k.a. Town Hall meeting, it was my pleasure to announce that oSC14 will take place in Dubrovnik in April 2014. Svebor, the lead for the oSC14 organization endured a number of brain dumps and got bombarded with ideas and suggestions.

This conference paves the way for oSC to grow as a community organized event and I know that Stella and Kostas had to swallow more lumps, as the prime movers, than others in the future will have to. Thank you.

With somewhere around 250 attendees we all can be very proud of the first community organized oSC. For impressions check out some pictures of oSC13 and the video recordings of the sessions. Now is also a good time to seriously start thinking about your travel plans for April 2014. See you in Dubrovnik

Peter Czanik was caught in the middle of all of this at a recent FSF conference where he and others had an openSUSE booth. With no DVDs being shipped, due to the transition in the promo material shipping procedure (this has been announced) and no money available through TSP for local production of marketing materials due to a snafu (a temporary solution is in the works) there was basically no help from the resources where help should be coming from, sorry about that Peter.

Despite these obstacles Peter and the team showed up and made due with what was available to have great success. In Peter’s words:

“”””
– distributed the last few remaining openSUSE 12.2 DVDs. Many people complained, that it’s not the latest and greatest, but also many were happy, as they have an old machine and older Linux versions usually have lower resource requirements.
– reused the posters we printed last autumn to decorate the booth (at the end of the day they were in a sorry state, so can’t be reused any more…)
– used the few remaining openSUSE brochures, stickers we printed last year (printing was contributed last year by somebody working at a printing company and our company printer…)

– used my ARM machines and a few borrowed mini PCs to demo openSUSE and make the booth eye catching (people asked about the machines and went away with openSUSE DVDs and brochures )

So, in short: last autumn we had local contributions from community members, this year we used what was last few bits of it and some creativity.

The good thing is, that I was told from multiple directions, that openSUSE had the best booth among software projects at the conference (and they did not know, that it was from a ZERO budget…).

The bad thing is, that we don’t have any marketing materials left. No DVDs, posters or brochures.

“””””

There is no need to rose color the situation, leaving community members trying to represent openSUSE at a conference stranded like this should not happen and there is no excuse for creating this situation in the first place. Work is proceeding to address these issue. However, I want to focus on the positive, and that is undoubtedly how determined Peter and the team were to make the conference a success and how they overcame the obstacles presented to them.

Thank you Peter and team fro being such dedicated representatives of our community and project. Also thank you for pointing out the shortcomings in our current transition period. This will allow us to address these, hopefully in short order.

As I mentioned, am am certain many of you have similar stories to tell. Thanks for your efforts as well.

One can only thank everyone in the community for pulling together, getting a lot of stuff done and delivering a great release.

Yet, there’s one sprinkle that rains on our parade. While we completed the switch to systemd we somewhere along the lines forgot to check the status of NetworkManager on an installed system. Thus, when you upgrade from a previous release and NetworkManager is disabled, it will be enabled and running after the upgrade is complete, sorry. If you happen to be running a network bridge your bridge will not be working and you’ll end up in some weird network state where ifconfig will tell you that both your bridge and your Ethernet card have an IP address. Your routing table will also be messed up. Addressing the issue is easy.

Login as root, which you will have to do at the login manager if you happen to run NIS, disable NetworkManager, stop the NetworkManager service, and restart your network. You are now back to your original configuration, no sweat . Below is a list of commands you want to run as the root user to make this happen:

# systemctl –force disable NetworkManager.service

# systemctl stop NetworkManager.service

# rcnetwork restart

My feeling is that a good number of people that complain about the noise on our lists are also those that contribute to that noise at a good rate. Thus, I can only say that sometimes it is nice to exercise some restraint and not hit that “Send” button; who hasn’t had the “I shouldn’t have sent this” thought? The bottom line is, that it is almost impossible to write anything that does not step on somebody’s toes somewhere along the way and if everyone that feels the least bit uneasy about some comment would respond all the time we would really be in an endless loop. I am certain, this post will make someone uneasy, upset, angry or worse. If that’s the way you feel right now, I am sorry, I am not trying to make you angry or upset on purpose. Please accept my apology.

That said, who hasn’t been frustrated out of their mind by some perceived dumb software problem or other issue? Even worse when it is our own hurdle we cannot cross. In the end we just wanted to yell and scream and the result is too often a message with: pick your “Emotional state appropriate inflamatory subject…” and rant your question to the list. Everyone gets emotional, and frustration happens to be a very strong reaction. However, the question that should come to mind before hitting that “Send” button to a list of volunteers is this, “Will an emotional reaction with moaning, groaning, whining, and complaining, that hides the real problem, give me the feedback needed to resolve my issue?” The answer is simple; No it will not. A post charged with negative energy will, and there is plenty of proof on our lists, solicit emotional, mostly negative, responses. These do not contribute to resolving the problem at hand. However, once this storm is set in motion there is, for better or worse no stopping it and it just has to run its course, i.e. eventually people will be tired of feeding the storm that should have never happened and things will go back to “normal”, whatever that may be.

I believe that the people, volunteers, on the opensuse mailing lists are generally willing to help solve problems others encounter. Yes, there will be the occasional cynical remark here and there, but I do not believe these remarks are ushered in a mean spirited way, and in the end we do not really have to nit-pick everything to death. It is one thing to yell at someone because the product or service you purchased from them does not meet your expectations, it is another thing to go bananas on a list where answers are provided by people with generally good intentions that volunteer their time. As posters of questions we all have a responsibility to keep this in mind before we go down the emotionally charged road to the abyss of not getting our questions answered.

However, putting the onus completely on the question poster is a bit too easy, isn’t it. While we as helpers would all love to get the “perfect” problem description, that is completely factual and contains no mistakes in description and actions to reproduce the problem, we have to realize that this is just not going to happen. By the time an issue hits the list the person posting probably is charged up in one way or another and ready to get rid of some of that stored energy, some more than others. Thus, as helpers we have to develop a bit more tolerance and let things roll off our backs a bit more. As potential helper we can just ignore the ranting posters. If you have it within you to provide the answer to the hidden problem and can rise above the fray, fantastic! help and do a good deed. However, if you know the answer to the hidden problem but feel the urge to feed the emotional storm it may be best to just ignore the message and not respond. In the end a raging answer hides the kind deed of help just as the raging question hides the problem.

No we do not have to have boring and no fun lists, but in the end flame wars or endless bickering threads are not fun and having people leave the lists or even not using openSUSE because of silly things is just not helpful to anyone. If we as posters, seekers of answers and providers thereof can just tone it down a bit things will probably work better for everyone.