Discussion on the state of cloud computing and open source software that helps build, manage, and deliver everything-as-a-service.
What is code signing
Code signing is the application of cryptographic hashes to code. Most people sign code in order to guarantee that no one has tampered with the code since publishing, and to explicitly be able to say that specific artifact originated somewhere. Most code signing relies on trusted third parties to effectively vouch for the identity of the signer.
Code signing isn’t really new, even in the open source world. Most Linux distributions have been signing their packages for years. But Linux distributions are fortunate in many ways. They own everything from the kernel to user land applications, and typically a user installs most if not all software via the distributions package repositories. This means you trust a code signing key shortly after or during installation for that distribution. Linux distribution users ‘trust’ packages that are signed by the same key as their installation medium. Most don’t check to verify that the signatures match what the project proclaims, but such verification is available....
With the Xen Project Hypervisor 4.4 having been released a few weeks ago, the project is starting the planning cycle for version 4.5 of the Hypervisor. So I thought it is worth walking you through how we manage releases.
Welcoming Oracle's Konrad Rzeszutek Wilk as Release Manager
But first I wanted to thank George Dunlap from Citrix for successfully managing the 4.3 and 4.4 releases of the Xen Project Hypervisor. The Release Manager role is a volunteer role open to Xen Project maintainers. George, has stepped down from his role recently to find more time for coding and help bootstrap the CentOS virtualization SIG.
Konrad is Software Development Manager at Oracle. His group's mission is to make Linux and Xen Project virtualization better and faster. As part of this work Konrad has been the maintainer of the Xen Project subsystem in Linux, Xen Project maintainer and now also Release Manager for the 4.5 release of the Xen Project Hypervisor. Konrad has been active in the Linux and Xen communities for more than 6 years and was instrumental in adding Xen Project support to the Linux Kernel.
How The Xen Project manages releases
As is the case for many open source projects, the Xen Project community does not maintain a committed roadmap as proprietary software vendors do. Instead, we strive to accurately track development for new releases, with a predictable release cadence for major releases and maintenance releases. We aim to release the Xen Project Hypervisor every 6-7 months: historically our release cadences ranged from 9 to 18 months. Introducing the Release Manager role was instrumental to getting us to shorter and a predictable release cadence....
Quite a few years ago I made a rather nice living coding things up. Some were big projects used in regulated industries, and others a bit more mundane, but in all cases I tried to ensure confusion over what the point of the project was could be minimized. After all, the last thing I wanted was a prospective user or partner investing in something which wouldn't meet their needs.
Fast-forward to today, and as the XenServer evangelist I want to accomplish the same task, but scope is a bit broader. I want people to be using XenServer, and I want many tens of thousands of them doing so. By the same token, I also want those same users to know they are using XenServer, and not something else. After all, its equally bad if someone thinks they're using XenServer when they aren't, or are using something different when they are in fact using XenServer.
A perfect case in point is the confusion over what "Xen" and "XenServer" are. For years I've heard people who want XenServer referring to it as "Xen" and occasionally as "Xen Server". While many of those people aren't technical, and for them the distinction is largely irrelevant, the fact of the matter is the distinction does matter. For example, if someone is working on a project which they wish to integrate with XenServer, it does them no good to see references to "Xen" all over XenServer content, or to look at examples which reference "Xen"; even if the actual code is for XenServer and not "Xen". Even more significant is that, with the move of the "Xen" hypervisor to the Linux Foundation last year, what was once known as the "Xen" hypervisor has now become the Xen Project hypervisor.
All of which gets me to Apache CloudStack. Apache CloudStack is a wonderful solution for anyone looking to get a cloud up and running quickly, particularly those looking to have multiple hypervisors in their cloud and managed from a single console. Unfortunately, Apache CloudStack is also a perfect example of the problem I'm highlighting here. Within the UI, documentation and code, the term "Xen" and "XenServer" are used interchangeably, when in reality Apache CloudStack only supports XenServer; or more precisely XAPI based toolstacks for the Xen Project hypervisor. To resolve this problem, and to pave the way for the Xen Project hypervisor to become a full citizen of Apache CloudStack, I put forth a proposal to distinguish and disambiguate "Xen" and "XenServer". The design document can be found on the CloudStack wiki. To give an example of the cost of resolving these things after the fact; the initial patch consisted of over 17,000 lines, subsequent patches will be needed following extensive testing, all with the result of no new functionality. If you're interested in following the progress of this activity, please do so on the CloudStack mailing lists, and on the wiki.
The point I hope I'm making here is that when there is the potential for confusion, someone will eventually become confused. If you are working on something which references "Xen" or "XenServer", I hope you'll take a few minutes to see if you're using the right references and if not plan on clarifying things for your customers and users. To assist, please refer to this handy-dandy list:
- "Xen" is a bare metal hypervisor which since April 2013 is a Linux Foundation Collaborative Project and has been renamed as the "Xen Project hypervisor". You can find more information about Xen Project at http://xenproject.org. Importantly, while "Xen" was the name Citrix used for the hypervisor, when "Xen" moved to the Linux Foundation, Citrix granted the Linux Foundation the limited rights to use the word "Xen" as part of the "Xen Project".
- Citrix continues to use the "Xen" mark in connection with a variety of products such as XenApp and XenDesktop, so if you are working on a project with integration into other Citrix products, and are referring to them as "Xen", you risk further confusion with the hypervisor work occurring with both XenServer and the Xen Project.
- XAPI, or XenAPI, is a toolstack for use with the Xen Project hypervisor and is a sub-project under Xen Project at the Linux Foundation. You can find more information about XAPI at http://xenproject.org/developers/teams/xapi.html
- XenServer is a packaged virtualization solution from Citrix which in June 2013 was made completely open source. XenServer uses the Xen Project hypervisor and API support is provided via XAPI. Commercial support for XenServer is available from Citrix, and open source activities can be found on xenserver.org.
- XCP, or Xen Cloud Platform, was a previous attempt at making XenServer open-source. With XenServer becoming open source in June of 2013, XCP development transitioned to XenServer.
Next Generation High Density App Servers Don't Require Scrapping Your Hypervisor
Recently, I sat in a conference session extolling the seemingly endless virtues of Linux Containers. I heard claims that hypervisors were old hat: ancient bloated engines which rely on inefficient replication of a large operating system stack in order to serve up applications. The speaker painted a picture of a future where hundreds of applications are virtualized on each piece of hardware. "What is really needed," glowed the speaker, "is a lightweight, efficient means of serving up application: containers."
Containers are cool, but not a panacea
Containers share the same kernel as the host, so they are not burdened with the extra memory and CPU cycles it costs to replicate a full operating system stack in a hypervisor scenario. Compared to hypervisor-generated virtual machines, containers can be fast and lean. But they are also limited.
Since Linux containers share the same kernel as the host, it is impossible to run Windows. Or FreeBSD. Or NetBSD. Or another version of the Linux kernel. Or another Linux distribution which requires a different kernel. All of those scenarios are best handled by a real hypervisor. And the security aspect of hypervisors is huge, worthy of a separate blog entry of its own. Still, if you need an environment within your organization where many workloads can leverage a single kernel environment, containers can be a viable solution.
However, some of the most vocal container advocates insist that these problems relating to containers are really application problems in disguise. Issues about kernel support and security are the results of improper application design, they claim. When we raise the bar on applications so that they are based solely on access to application servers, then the objections to containers will melt away -- and so will hypervisors, for the most part. Or that's what some of these advocates claim, at least.
The death of the hypervisor is greatly exaggerated
But is there another scenario which could answer the call for highly responsive and lightweight virtual instances which does not use the container solution? Maybe one that can actually leverage the flexibility and security which is part and parcel with most hypervisors?...