I know this topic has probably been beaten to death elsewhere. . . What can I say? I can't help myself.

When there is an untagged VLAN on a switch or port, it means the VLAN information is private to the switch. No VLAN information is added to packets leaving the switch. This has a lot of important implications. A machine connecting to an untagged VLAN port does not need to know (and will not know) what VLAN it is in. If I'm connecting two switches together using a cable connected to untagged VLAN ports, each end of the cable could be in a different VLAN and the switches will not care. So, for example, I could send untagged VLAN 1 from one switch and bring it into another switch as untagged VLAN 20.

Tagged VLAN means that the switch does insert the VLAN information into the header of each packet. In fact, this information is called a "tag", hence the term "tagged VLAN", which means "VLAN where packets contain VLAN tags". Assuming I'm sending tagged VLAN packets (and no untagged ones) on a port, if I connect the eth0 interface of a vanilla-installed PC to that port, and give the interface an address in the tagged VLAN's range, the network will not work over that interface. Of course, I will be able to 'see' the packets using wireshark or tcpdump, but I won't be able to make TCP, UDP, ICMP, etc. connections.

Long time not see, dear friends. But that does not mean that there is nothing to speak about. So, hence a new blog post for those that were wondering what was happenning in the reverse-straight engineering partnership.

After the moments in August and September, where I transitioned from working on LibreOffice to working on SuSE Linux Enterprise and after some breathing pause to give to the Cesar (or also known as family) what is belonging to Cesar, the activity on LibreOffice related stuff restarted in October. Just this time, during nights, weekends and other free time.

Sample Keynote presentation in LibreOffice 4.2

It is with a huge pleasure that I realized that we start to have a vibrant developer community around the libwpd/libwpg family, as well as around Valek's reverse-engineering framework. SUSE Hackweek 10 helped me to produce an initial importer for Freehand file-format. Close to that, David Tardon of RedHat fame added a library to parse Keynote files and a library to convert different e-book file-formats. Laurent Alonso works like a bee on importing Microsoft Works spreadsheets (*.wks). Many exciting things in the pipeline, as you can see.

Wireframe of shapes from a sample Freehand drawing in LibreOffice 4.2

With the extension to presentations and spreadsheets, we decided that the time has come to simply break the super-stable libwpd/libwpg API and profit to make it even more future-proof and in the same token solve some of the API issues that were preventing us from importing correctly several features; most notable of which the Visio connectors.

librevenge

We decided to diminish drastically dupplication of code and we extracted from libwpd, libwpg and from libetonyek the API classes along with the used types. We created a new library, librevenge where we also added as sub-libraries the (structured) stream implementations that used to be in libwpd-stream, as well as several classes that the libraries used to copy and paste between them. The structured stream implementations support now both OLE2 and Zip containers and the relevant libraries assume this. That means that we will have to eventually extend the WPXSvStream implementation in LibreOffice's "writerperfect" module to cater for Zip too.

A new sub-library, librevenge-generators has the simple implementations of the interface classes that we use to convert documents into html, text, or that we use to see the raw API calls for the purpose of regression testing. The exception is the RVNGSVGDrawingGenerator class. In the current stable branches, all of the libraries that convert graphics file-formats contain an SVG generator and they rely on its presence in several cases for things like fills with vector graphics. This class is thus not part of the librevenge-generators library, but of the base librevenge, which is a hard dependency of all of the converter libraries.

RVNGPropertyList

The base type for passing information using the API callbacks is RVNGPropertyList, which was born from libwpd's WPXPropertyList. We modified the design of this class the way that each atrribute can have as a value either a simple property or an array of RVNGPropertyList element. This allows us to do more or less all that JSON is able to do. The API classes are even more flexible and future-proof, since extending the information passed in the different callbacks will not modify function signatures.

Quality improvement

Although the relevant libraries were quite extensively regression-tested in the past, the new librevenge extends the coverage of unit tests. We hope that this helps us to keep under control the basic functionalities without having to use the heavy regression tests on each commit.

Other effort is to avoid to copy in the API calls huge data structures. This effort will result in some performance improvements especially if a document contains a lot of shapes that are filled by different bitmap fills.

When will it be ready?

When it is ready! But seriously, we are trying to take our time and get the APIs right. Like this we intend to prevent gratuitous breakages of binary compatibility in the future. So, it will not be in LibreOffice 4.2 for sure.

If this is interesting for you, please drop by at #libreoffice-dev channel at irc.freenode.net in order to meet us. We cannot promise you that you will become rich, but we can guarantee you fame and eternal gratitude

This morning during a cup of coffee I wanted to do something adventurous. I put the raspberry which I bought recently (without having very much played with it because of my light apt-* allergy) on the table and thought I will try to install the openSUSE distribution.

I remembered awesome Bernhard was blogging about that topic recently. On that page one can find this link where raspberrypi images can be found. Oh, surprise, there is even a file from november 10th, so I downloaded that. People always recommend the latest stuff.

Following this Howto I quickly had the RaspberryPi running in my home network, surprisingly enough identifying itself as powered by openSUSE 13.1 :-)

Well, that was easy and far away from adventure which I was looking for. So I remembered that the cool kids on the block have an ownCloud server running on the RaspberryPi. Would that be as easy? There are no official packages for the Pi yet, so what could I do?

Well, ownCloud is noarch, because it is plain PHP. So I downloaded the two ownCloud server packages owncloud and owncloud-3rdparty from our ownCloud nightly build repository on OBS and installed them with

zypper in owncloud owncloud-3rdparty

I was (adventure!) ignoring all the warnings and stuff, what you should never do! Just for a test, before the coffee is cold.

After having started apache, what should I say? It simply worked. No need for antihistamine, all nice green around, and ownCloud running after having finished it’s setup page.

That really pushed me for the day! It was such a smart experience having that running within a couple of minutes, with absolutely no fiddling around. This is cool stuff! Thanks to Bernhard and all the other openSUSE guys for doing that!

My congrats for the 13.1 release! I really hope that people will understand (again) how awesome the openSUSE distribution and the project is, especially for the more nerdy folks! Really, you wanna run the Geeko these days.

Enough praise, now, maybe there is somebody who will help me in OBS to provide proper ownCloud packages for ARM? I am sure there is not much missing.

And if you want to run ownCloud on your “normal” PC, this is the repository of the latest stable version which we actively maintain…

Over the past three days, i had the chance to attend the openSUSE summit once again in Florida. Attendance to the event was great and thanks to the wonderful talks that were offered, the event was a success.

Hello,

Recent events in the openSUSE community have left the board needing to fill a few seats. Although I have never been one to show deep interest in the board, I believe it is now the right time to step up my participation in the project. With this in mind I presented my candidacy for the openSUSE Board this year.

It is not news that our project is always looking to improve and put our culture closer to the hands of many people looking to make the "Linux switch." Under this premise, I have participated of the openSUSE Artwork team for the past few years and as an openSUSE Linux novice since 2000. New needs and ventures have also taken me to participate in the openSUSE News team as an editor.

Seeing that my participation in the project has become more evident and thereby making openSUSE more evident to users that follow us, the candidacy for the board comes at a time when we need to strengthen our marketing strategies and our overall communication structure not only to the community, but also those looking to use our distribution and are not quite decided yet.

You may be acquainted with the work I have done in the past. Much of our recent promotional artwork for CDs, Posters, Stickers, Website artwork for the openSUSE Summit and openSUSE Conference, and other visual projects has been conceptualized by me based on the ideals that openSUSE has a visual importance that needs expansion.

Editing news articles has also given incredible insight into what openSUSE is able to communicate and inspire about Linux in many people looking to make the jump.

I have also been a speaker in a couple of openSUSE-related events and have tried communicating our ideals and goals.

I believe in openSUSE as a means of visual communication. I believe there are many things that our project can shine about and many more things to discover as a team.

If you are a believer in the future of openSUSE I humbly as for your vote and support.

In 1996 Regurgitator released a song called “Kong Foo Sing“. It starts with the line “Happiness is a Kong Foo Sing”, in reference to a particular brand of fortune cookie. But one night last week at the OpenStack Summit, I couldn’t help but think it would be better stated as “Happiness is a Hong Kong SIM”, because I’ve apparently become thoroughly addicted to my data connection.

I was there with five other SUSE engineers who work on SUSE Cloud (our OpenStack offering); Ralf Haferkamp, Michal Jura, Dirk Müller, Vincent Untz and Bernhard Wiedemann. We also had SUSE crew manning a booth which had one of those skill tester machines filled with plush Geekos. I didn’t manage to get one. Apparently my manual dexterity is less well developed than my hacking skills, because I did make ATC thanks to a handful of openSUSE-related commits to TripleO (apologies for the shameless self-aggrandizement, but this is my blog after all).

Given this was my first design summit, I thought it most sensible to first attend “Design Summit 101“, to get a handle on the format. The summit as a whole is split into general sessions and design summit sessions, the former for everyone, the latter intended for developers to map out what needs to happen for the next release. There’s also vendor booths in the main hall.

Roughly speaking, design sessions get a bunch of people together with a moderator/leader and an etherpad up on a projector, which anyone can edit. Then whatever the topic is, is hashed out over the next forty-odd minutes. It’s actually a really good format. The sessions I was in, anyone who wanted to speak or had something to offer, was heard. Everyone was courteous, and very welcoming of input, and of newcomers. Actually, as I remarked on the last day towards the end of Joshua McKenty’s “Culture, Code, Community and Conway” talk, everyone is terrifyingly happy. And this is not normal, but it’s a good thing.

As I’ve been doing high availability and storage for the past several years, and have also spent time on SUSE porting and scalability work on Crowbar, I split my time largely between HA, storage and deployment sessions.

On the deployment front, I went to:

• HA/Production Configuration, where the pieces of OpenStack that TripleO needs to deploy in a highly available manner were discussed (actually this could have been discussed for a solid week
• Stable Branch Support and Update Futures, about updating images made for TripleO.
• An Evaluation of OpenStack Deployment Frameworks, where two guys from Symantec discussed the evaluation they’d done of Fuel, JuJu/MaaS, Crowbar, Foreman and Rackspace Private Cloud. In short, nothing was perfect, but Crowbar 1.6 performed the best (i.e. met their requirements better than any of the other solutions tested).
• Roundtable: Deploying and Upgrading OpenStack.
• OpenStack’s Bare Metal Provisioning Service, wherein I attained a better understanding of Ironic.
• It Not Just An Unicorn, Updating Our Public Cloud Platform from Folsom to Grizzly – how eNovance manage upgrades. Automate all the things and test, test, test. Binary updates are done by rsyncing prepared trees, but everything can be rolled back and forwards, because everything is in revision control. It sounds like they’ve done a very thorough job in their environment. I’m less sure this technique is applicable in a generic fashion.
• The Road to Live Upgrades. Notably they want to add a live upgrade test as a commit gate.
• Hardware Management Ramdisk. Lots of work to do here for Ironic to deploy ramdisks to do, e.g.: firmware updates, RAID configuration, etc.
• Firmware Updates (followed right on from the previous session).
• Making Ironic Resilient to Failures (what do you do if your TFTP/PXE server goes away?)
• Compass – Yet Another OpenStack Deployment System, from Huawei, to be released as open source under the Apache 2.0 license “soon” (end of November). A layer on top of Chef, but with other configuration tools as pluggable modules. If you squint at it just right, I’d argue it’s not dissimilar to Crowbar, at least from a high level.

On High Availability:

• Practical Lessons from Building a Highly Available OpenStack Private Cloud (Ceph for all storage, HA via four separate Pacemaker clusters. Notably the cluster running compute can scale out by just adding more nodes.
• High Availability Update: Havana and Icehouse, wherein I attempted to look scary sitting the front row wearing my STONITH Deathmatch t-shirt. I hope Florian and Syed will forgive my butchering their talk by summarizing it as: If you’re using MySQL, you want Galera. RabbitMQ still has consistency issues with mirrored queues and there can be only one Neutron L3 agent, so you need Pacemaker for those at least, so using Pacemaker to “HA all the things” is still an eminently reasonable approach (haproxy is great for load balancing, but no good if you have a service that’s fundamentally active/passive). Use Ceph for all your storage.
• Database Clusters as a Service in OpenStack: Integrated, Scalable, Highly Available and Secure. Focused on MySQL/MariaDB/Percona, Galera and variants thereof, which combinations are supported by Rackspace, HP Cloud and Amazon, and various deployment considerations (including replication across data centers).

On Storage:

• Encrypted Block Storage: Technical Walkthrough. This looks pretty neat. Crypto is done on the compute host via dm-crypt, so everything is encrypted in the volume store and even over the wire going to and from the compute host. Still needs work (naturally), notably it currently uses a single static key. Later, it will use Barbican.
• Swift Drive Workloads and Kinetic Open Storage. Sadly I had to skip out of this one early, but Seagate now have an interesting product which is a disk (and some enclosures) which present disks as key/value stores over ethernet, rather than as block devices. The idea here is you remove a whole lot of layers of the storage stack to try to get better performance.
• Real World Usage of GlusterFS + OpenStack. Interesting history of the project, what the pieces are, and how they now provide an “all-in-one” storage solution for OpenStack.
• Ceph: The De Facto Storage Backend for OpenStack. It was inevitable that this would go back-to-back with a GlusterFS presentation. All storage components (Glance, Cinder, object store) unified. Interestingly the
  libvirt_image_type=rbd option lets you directly boot all VMs from Ceph (at least if you’re using KVM). Is it the perfect stack? “Almost” (glance images are still copied around more than they should be, but there’s a patch for this floating around somewhere, also some snapshot integration work is still necessary).
• Sheepdog: Yet Another All-In-One Storage for Openstack. So everyone is doing all-in-one storage for OpenStack now I haven’t spent any time with Sheepdog in the past, so this was interesting. It apparently tries to have minimal assumptions about the underlying kernel and filesystem, yet supports thousands of nodes, is purportedly fast and small (<50MB memory footprint) and consists of only 35K lines of C code.
• Ceph OpenStack Integration Unconference (gathering ideas to improve Ceph integration in OpenStack).

Around all this of course were many interesting discussions, meals and drinks with all sorts of people; my immediate colleagues, my some-time partners in crime, various long-time conference buddies and an assortment of delightful (and occasionally crazy) new acquaintances. If you’ve made it this far and haven’t been to an OpenStack summit yet, try to get to Atlanta in six months or Paris in a year. I don’t know yet whether or not I’ll be there, but I can pretty much guarantee you’ll still have a good time.

Hello fellow geekos, Let's start with a little introduction for those that don't know me. I've been involved in the openSUSE project for more than 3 years by now while being among the top ten contributors to Factory for most of the time. I mainly develop the Python and Go stacks as well as OpenStack. … Continue reading openSUSE Board candidacy

Hello fellow Geekos!

After 10 months serving on the Board, my current tenure on the Board is
due to end this year.

It's been a busy 10 months, during which time I've been involved in
progressing the reform of the Ambassador/Advocate & Local Coordinator
Programmes, monitoring the improvements to the Travel support programme,
countless copyright requests and much more besides, all while
maintaining my contributions to other parts of the project as a regular
Geeko (GNOME & Branding in particular).

With all that said, there is lots more work that remains to be done,
which is why I'm announcing my intention to stand for (re)election to
the openSUSE Board

If you choose to re-elect me, my priority will be to continue to
represent you all, our community of contributors, and to address the
issues of greatest concern to you and our Project.
I hope to encourage further empowerment of both the Board and the wider
Community to take on responsibilities 'traditionally' held only by SUSE
employees. I also wish to improve the working relationship between the
Board and the openSUSE Team.

As you may already know, as of last week I have become a SUSE employee.
As I am working in QA, my 'day job' will continue to have relatively
little to do with openSUSE, but given that openSUSE has been my hobby
and my passion for something like 7 years, I am not intending to let my
new employment change how I serve this community; Though obviously being
surrounded by so many of our contributors in Nuremberg will hopefully
make it easier for me to hear what's of interest to you :)

I hope you trust me with your votes in a few weeks time.
Thanks for all the fun,

Richard