Live data from Hacker News

Metal as a Service

maas.ubuntu.com

81–90 of 106 posts

Re: Metal as a Service

#81
post #47

Earlier quoted context omitted.

There's no money in desktop now, though. Maybe they need to expand into markets where there is money in order to pay for desktop development.

Well, that's not very true. I think you mean to say, "Desktop is not sexy". Most homes have either a desktop, or a laptop, or both, sometimes multiples of each. Every business has at least 1 computer (desktop or laptop, sometimes multiples of both). So there very much so is a lot of money still in desktop. Right now if you want to purchase a factory Linux computer, your choices are severely limited. It's either Syste…

Everyone has a desktop. That doesn't mean everyone is buying desktops. It's a shrinking market right now, and there's no escaping that. Why should Canonical invest in a shrinking market instead of an expanding one? When I first started working at Canonical it was when they were jumping on the whole netbook bandwagon. The future was a world where everyone was using tiny toy laptops, and Ubuntu was going to rule that world. There ended up being numerous problems, not least of which turned out to be that netbooks were just a passing fad.

They want to be in every consumer market, but they're too late to them all. Desktops are shrinking. They're having trouble finding a phone manufacturer that will do hardware for them. Probably the same with tablets. I can't even begin to imagine what all is involved in television. That's the market they want into that still hasn't been totally cracked by Microsoft, Apple, Google, or Amazon. And that fact alone should probably tell you that the odds of Canonical cracking it are not fantastic.

I'd love for Ubuntu to become huge on desktops and make them tons of money. And maybe it will happen and I'm just not seeing the big picture. But where you see every business running at least 1 computer and consider that an opportunity, I unfortunately see it as a missed opportunity. That's a computer they already bought, and if they're going to get rid of it and switch to something else what makes you think they would choose Ubuntu (something they've never heard of) rather than Windows 8.1 or an iPad?

Re: Metal as a Service

#82
post #40
post #37

Earlier quoted context omitted.

Amazon does not have a 'baremetal' instance type. OpenStack 'can', but in practice the baremetal nova driver[0] has many issues, and the newer OpenStack Ironic Project[1] is not yet ready for production workloads. Additionally, both baremetal and OpenStack Ironic have a focus on 'triple-O', or OpenStack on OpenStack[2] use cases -- that is using these projects to bootstrap an 'undercloud', for the hardware to be used…

Fair enough. I was totally convinced that Amazon had baremetal instances available, but now I cannot find anything, so that could probably be a figment of my imagination.

I believe at one point the GPU instances were being given direct hardware access to the GPU as virtualized GPUs weren't yet a thing. So the GPU part was sort of baremetal I guess.

Re: Metal as a Service

#83
post #82
post #40

Earlier quoted context omitted.

Fair enough. I was totally convinced that Amazon had baremetal instances available, but now I cannot find anything, so that could probably be a figment of my imagination.

I believe at one point the GPU instances were being given direct hardware access to the GPU as virtualized GPUs weren't yet a thing. So the GPU part was sort of baremetal I guess.

GPU instances are still Xen VMs, not bare metal.

Re: Metal as a Service

#84
Quickly went through the docs:

* why do they require a "cluster controller" for each subnet (or vlan)? This seems like a waste of resources and added complexity. Is this a limitation because it's easier to set up for sysadmins than to request for a DHCP relay?

* how bad is the security? It seems that you approve clusters interfaces but MAC spoofing could do a lot of harm here.

Edit: I saw that the doc tells you to add network interfaces to manage multiple clusters from a single controller. Assuming you do 802.1q this works but what about multi-dc setups? Isn't this more complicated than a simple relay?

Re: Metal as a Service

#85
post #72
post #44

Earlier quoted context omitted.

Maybe Canonical should stick to their core... ...and focus on Linux on the Desktop... instead of trying to be an "Everything" company. Get the core down solid and making money , then expand into other markets.

I agree Canonical should stick to their core, but it's not the desktop. It's cloud. They've demonstrated they do not have what it takes to make desktop net profitable for them. They make most of their money by selling support for their cloud stuff — this is what they should focus on. Desktop has done nothing but lose them money.

Well, Canonical could always make their own laptops with perfect driver support and charge a premium for that. I don't know why they're not. As of right now the only laptops that consistently work well with Linux/Ubuntu are Thinkpads and Thinkpads suck for e.g. gaming. No one except Microsoft can make money selling an OS - and they can only do it because they have a massive advantage in user training and software ecosystem. They tried to sue their way to victory with Phone, but have eventually settled for the fact that they'll have to sell hardware as well.

Re: Metal as a Service

#86
post #31

We spent around 6 weeks trying to wrangle Juju and MaaS into a working state in August 2013. Skimming through my notes we surmised the following. * Auto-enrollment of nodes was tough to get working. * Overlay and config management was weak and better handled by Puppet. Though Juju beans were touted as able to handle this. * Juju 1.13 and maas 1.3 do not support isolated juju environments in the same maas cluster. No…

Thanks for giving it a try. If you're ever thinking about trying it again, we (MAAS team) would be happy to help. Truth is that the problems that MAAS is trying to solve are hard , and it's taken us some time to solve them. We're spending a lot of time in this development cycle working on the robustness of the MAAS node lifecycle. MAAS 1.5 is significantly better than 1.3, and getting stronger all the time. Similarly…

Is MASS tightly integrated with Juju? I want to be able to use it at scale without JuJu.

Re: Metal as a Service

#87
post #31

Earlier quoted context omitted.

Thanks for giving it a try. If you're ever thinking about trying it again, we (MAAS team) would be happy to help. Truth is that the problems that MAAS is trying to solve are hard , and it's taken us some time to solve them. We're spending a lot of time in this development cycle working on the robustness of the MAAS node lifecycle. MAAS 1.5 is significantly better than 1.3, and getting stronger all the time. Similarly…

Is MASS tightly integrated with Juju? I want to be able to use it at scale without JuJu.

MaaS is not tightly integrated with Juju, and Juju is not needed to set it up.

Juju supports many backends, one of which is MaaS.

Re: Metal as a Service

#89

We spent around 6 weeks trying to wrangle Juju and MaaS into a working state in August 2013. Skimming through my notes we surmised the following. * Auto-enrollment of nodes was tough to get working. * Overlay and config management was weak and better handled by Puppet. Though Juju beans were touted as able to handle this. * Juju 1.13 and maas 1.3 do not support isolated juju environments in the same maas cluster. No…

On a somewhat related note, here's a couple of links I found when looking around for more info on maas and juju:

Virtme: a very promising start to get a proof of concept up and running -- sadly it appears to be abandoned?:

https://manage.jujucharms.com/~virtual-maasers/precise/virtm... http://javacruft.wordpress.com/2013/06/25/virtme/

A (partial) list of manual steps that try to achieve the same (with the goal of ending up with an openstack poc):

http://www.teale.de/tealeg/computing/cloud/kvm_maas_juju_ope...

YMMV etc.

Re: Metal as a Service

#90
post #73

Earlier quoted context omitted.

Where are you getting the stats that majority of the cloud is RHEL/CentOS? Published stats [1] show that Ubuntu dominates cloud deployments. [1] http://www.markshuttleworth.com/archives/1318

Yes, of course Mark Shuttleworth's personal blog is not bias (he's the owner of Canonical). Also, he's talking about deployments on Digital Ocean, ie. VM's. I'm talking about what actually makes the "cloud", ie. the "cloud". The "cloud" is built out of RHEL/Centos for the most part. Almost all the major "cloud" infrastructures have been built with RHEL/Centos. We can speculate why... but Red Hat has built a $1 billio…

At least HP's public cloud is based on Ubuntu as host: http://www.cloudpro.co.uk/cloud-essentials/public-cloud/1913...

I'd be surprised if they were the only ones.

DigitalOcean, Amazon, Microsoft(!) all list Ubuntu as the most popular VM for linux servers.

Can you point to stats or facts about RHEL deployments backing your point of view? I'm genuinely curious.

Post reply on HN