Slashdot Mirror
OpenStack Ditches Microsoft Hyper-V
judgecorp writes "The OpenStack open source cloud project has removed Hyper-V from its infrastructure as a service (IaaS) framework, saying Microsoft's support for its hypervisor technology is 'broken.' This will embarass Microsoft, as major partners such as Dell and HP support OpenStack, along with service providers such as Internap." Adds reader alphadogg, this "means the code will be removed when the next version of OpenStack, called Essex, is released in the second quarter."
Hard for someone on the outside to know whether it's truly broken or this is a case of "it's too hard, let's leave it out and blame Microsoft".
"Eve of Destruction", it's not just for old hippies anymore...
As I read the article, it says that OpenStep's support for Hyper-V is broken or incomplete, leading to its removal from of Hyper-V support from the OpenStep codebase. The summary here could be read either as Microsoft support for OpenStep is broken, or Microsoft support for its own Hyper-V product is broken, neither of which appears to be the case.
In other words, OpenStep users haven't adopted Hyper-V widely or spent a lot of time working on the OpenStep code, and so that part of the tree has fallen into disrepair and it's being removed as not having sufficient interest.
That's my guess...perhaps someone with more knowledge could clarify?
“Just as Nova enters feature freeze, it sounds like a good moment to consider removing deprecated, known-buggy-and-unmaintained or useless feature code from the Essex tree, “ he wrote.
In reply, Ken Pepple, director of cloud development at Internap Network Services, wrote: “”Hyper-V support is missing support for even the most basic functions – volumes, Glance, several network managers, etc. We investigated it for our service, but found it only borderline functional.”
Advice: on VPS providers
There's no way content filters will allow anyone to access the site for Essex :-)
If you read the ML message (here : https://lists.launchpad.net/openstack/msg07065.html) you'll see all the reasons.
Microsoft has been trying to push Hyper-V support into Linux, but their original driver code was complete shit, and it's just barely starting to get better. It's almost stable now, but not fully functional. So, yes it is fair to say that Hyper-V support is being removed from OpenStack because Microsoft's support for Hyper-V on Linux has been very poor.
After fighting with openstack on my hardware for months with no success, this will be the final straw that pushes me to a 100% Azure.stack.
As someone who has spent a great amount of time trying to manage a Hyper-V infrastructure, I can say this was a completely appropriate move and criticism of the product. The management and maintenance of Hyper-V is abysmal, in my experience.
Appended to the end of comments you post. The maximum is 120 characters.
Why is it remotely interesting to use Hyper-V with Openstack even in theory? MS has their own tooling and if you don't want to use it, why would you want Hyper-V over the more spiritually similar Xen or KVM hypervisors? I've been in a few situations where people have mentioned this but aside from an academic concept of 'completeness', I haven't heard an explanation of the practical relevance of the combination instead of leaving the proprietary stacks to their own efforts.
XML is like violence. If it doesn't solve the problem, use more.
Actually this comment is wrong. You said that you read the article but still refer to the project as OpenStep. It is OpenStack and yes the summary is correct the hypervisor Hyper-V has not been supported with the changes made over this last year to OpenStack.
To the folks who said maybe the guys at CloudStack might think it is too hard to implement Hyper-V: WTF have you been smoking? These are the guys who built this from scratch, I doubt something would be "Too Hard" or that they were in some way too lazy to do it. To the folks who said Xen is not even in the picture: WTF have _YOU_ been smoking? Let's see...who uses Xen? RedHat, Oracle, Citrix, Microsoft (yep, they sure do!) and a host of other people from my measly little home box to MASSIVE hosting companies. My two centavos...
"My immediate reaction is "WTF? What kind of moron doesn't make things 64-bit safe to begin with?" Linus
Hyper-V contributions to OpenStack by Microsoft initially worked, or they wouldn't have been accepted.
There's no such thing as "bit rot", there are only people who fail to maintain binary backward compatibility in their products as they move forward, as OpenStack has done here.
Lack of interface contracts is probably one of the biggest barriers to commercial software sales in Open Source environments. I don't blame OpenStack for dropping the support, but I do blame them for breaking binary compatibility, and then saying it's the fault of the software they are no longer compatible with because it failed to field a bunch of engineers to make lock-step changes to accommodate OpenStack's apparently arbitrary interface changes.
Hyper-V is not suddenly a different mouse, OpenStack has moved their cheese.
-- Terry
The only was is Essex (UK 'reaility' TV show)!..... http://www.itv.com/essex/towie-faces/
The last analogy was a reference to the book "Who Moved My Cheese?". But you didn't like it, so let's try another one.
A commercial company is like a large cargo ship loaded with containers, and an Open Source project is like a sail boat. If you want to move a lot of freight reliably in one trip, you use the cargo ship. If you want to be able to change direction quickly to explore a lot of directions and could care less about cargo, you use the sailboat.
But a sailboat that wants to lead a cargo ship around is out of it's fricking little mind if it thinks that the cargo ship is going to be able to turn on a dime like the sailboat. It's up to the sailboat to make the necessary allowances to keep the fleet together.
As to your second point, about one vendors software changes breaking anothers:
The Solaris DDI/DKI has maintained binary backward compatibility for a long time. So Has Mac OS X. Many DOS programs still run on Windows systems, even today. All of those systems have moved forward without leaving swaths of collateral damage by maintaining binary compatibility over at least one major release cycle, usually longer.
Yes, Microsoft has orphaned the occasional product with no notice. Microsoft being assholes isn't a blanket asshole license for everybody who'd like to be one.
"But MOM! She hit me first!" is never a good starting point for winning an argument.
-- Terry
Solaris yes, backwards compatibility is very good...
OSX is an especially poor example, Apple dropped compatibility completely with OS9 in the name of progress and thus we have OSX at all. They then moved to a completely different hardware architecture, again dropping compatibility...
Apple have also deprecated a number of older APIs in the name of progress.
That's BS. Apple maintained binary backward compatibility with 68K Mac OS for multiple releases, then kept maintaining support for older programs using the Blue Box (Classic) environment. When the Intel switchover happened, they again maintained binary compatibility with PPC software over several releases using Rosetta.
Carbon was a stopgap solution that was not intended to survive transition to native APIs, yet stayed around far longer than it should have. It finally got shot in the head when 64 bit GUI libraries finally shipped because it was impossible to jam a 64 bit inode number into a 32 bit hard-coded on disk structure for the file ID mechanism without losing backward compatibility anyway.
The only thing people miss is Carbon, because they were using the CodeWarrior compiler, and all its C++ glue was based on reexporting the Carbon APIs instead of the Cocoa APIs, and they never got their act together to move the code to the APIs they were supposed to have been using instead. Mostly that came down to Adobe Photoshop plugins, and Adobe not doing the right thing with regard to Coca with plugins and binary compatibility on their part.
As a kernel engineer at Apple, I had to leave a glaring security hole in the kernel for two releases because of not being allowed to break binary compatibility with programs that had used a particular sysctl() that they had been told not to used, and that they were supposed to popen() the ps program instead, if they wanted to enumerate processes. Mostly this was because people not dropping pid files in /var/run simply because they didn't understand the UNIXy way of communicating process information was to record the information apriori rather than scanning the running processes to see if the Final Cut Pro renderer (for example) was already hanging around.
It's basically damn near impossible to deprecate anything at Apple in less than three release cycles. You would not believe the cruft that's still hanging around because of that. It took forever, but some of us finally jammed through __deprecated in and started marking APIs we wanted dead. Still takes three release cycles to kill something, but at least people can't use a deprecated API and -Werror at the same time, and get nastygrams from the compiler if they use XCode with the default settings.
NB: I work at Google now, so it's not like I've said any of the above out a misguided sense of company loyalty.
-- Terry
You're side-tracking.
Hyper-V got "broken" over a single release by an arbitrary OpenStack change that didn't try at all.
Hyper-V was broken by OpenStack in less than the 3 year amortization schedule for computer hardware and software permitted by FAS (Federal Accounting Standards). If they want to be taken as a serious comercial-competitive product, they have to permit the accountants to keep old software they work with around 3 years.
Your OS X examples all have one thing in common: 5-10 years before the official switch is thrown, which is well in excess of when a normal business would have had to throw the hardware out in order to avoid IRS penalties for continuing to use hardware they'd already amortized the value out of.
-- Terry