Live data from Hacker News

Metal as a Service

maas.ubuntu.com

31–40 of 106 posts

Re: Metal as a Service

#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, Juju 1.18 and 1.19 are leaps ahead of 1.13 – the local provider is now in a workable state and gets used a lot internally.

We at Canonical eat our own dogfood as far as MAAS and Juju are concerned. We're using MAAS extensively in our DCs (though I don't think we use it for 100% of machines; I'm not privy to that knowledge) and the vast majority of our core services are deployed using Juju.

Re: Metal as a Service

#32
post #29

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…

I had a very similar experience when I tried it a few months before you.

Yeah, we were psyched to use it as a private cloud deployment tool and to manage some development environments. It represented a interesting middle ground between a container like setup (docker) and a distributed computing model like Storm/Disco.

A stack was run on it, however it lacked the polish, support and flexibility required to make it a platform worth investing in.

That is not to say that we thought the idea was bad but that it was nowhere near mature enough for production last year.

Given how Tahr has rolled out, we suspect most development effort was put into the mobile platform and a close integration of MaaS with the cloud in a box.

Re: Metal as a Service

#33
post #22

I bet someone in marketing at Canonical shit their pants watching the WWDC yesterday.

I don't think there is likely to be much confusion. Looks like this would be called "MAAS" or "Metal as a Service," never just "Metal."

TBH I thought this was announcing cloud based graphics rendering until I saw the Ubuntu domain.

Re: Metal as a Service

#34
While this may not be in a easily workable state right now, this is really awesome, now people can run their own clouds even easier. This removes some of the value-add (and associated costs) of various VPS providers and cloud offerings.

I currently manage one VPS that hosts multiple sites/apps that I work on, and it's not the worst thing ever, but it could be easier. Right now I still SSH in and restart services by hand, but a web interface would make that much easier to manage.

If they allow for extensible plugins, we could see an explosion of nagios-like functionality being developed, as well as even better free server monitoring resources.

Really looking forward to seeing this progress

Re: Metal as a Service

#36
post #29

Earlier quoted context omitted.

I had a very similar experience when I tried it a few months before you.

Yeah, we were psyched to use it as a private cloud deployment tool and to manage some development environments. It represented a interesting middle ground between a container like setup (docker) and a distributed computing model like Storm/Disco. A stack was run on it, however it lacked the polish, support and flexibility required to make it a platform worth investing in. That is not to say that we thought the idea w…

> Given how Tahr has rolled out, we suspect most development effort was put into the mobile platform and a close integration of MaaS with the cloud in a box.

You're incorrect about that, but the MAAS team did suffer some short staffing last year that left us behind the curve. We've now increased the number of people working on MAAS, which is what allowed us to get large chunks of work – like integrating CloudBase's work for allowing MAAS to provision Windows machines – relatively quickly.

Re: Metal as a Service

#37
post #9
post #4

This is an interesting concept and a good addition to all the IaaS offerings around. Just one year ago, while doing my Master's thesis, I pondered the possiblity of creating an IaaS that didn't involve virtual machines but physical servers instead. This should be great especially for high performance and special hardware needs. Next step would be all sorts of mixed blends between virtual and physical servers: real CP…

Is this so novel? Both Amazon and OpenStack can provision and manage baremetal instances.

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 by a higher level virtualized cloud.

[0] - https://wiki.openstack.org/wiki/Baremetal

[1] - https://wiki.openstack.org/wiki/Ironic

[2] - https://wiki.openstack.org/wiki/TripleO

Re: Metal as a Service

#38
post #4

This is an interesting concept and a good addition to all the IaaS offerings around. Just one year ago, while doing my Master's thesis, I pondered the possiblity of creating an IaaS that didn't involve virtual machines but physical servers instead. This should be great especially for high performance and special hardware needs. Next step would be all sorts of mixed blends between virtual and physical servers: real CP…

You've reinvented what we used to call dedicated servers. There is nothing new under the sun.

Might as well call it physicalization. :)

Re: Metal as a Service

#39
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…

Hey, thank you for developing it!

There were a lot of cool working parts such as the Juju-gui and the way that nodes could be tagged for different charms. Though the way that charms deployed at the command line sometimes didn't appear in the gui vexed us.

I like the idea of MaaS on the cloud in a box. A plug and play cloud has its uses though TechOps time is at a premium and rebuilding the stack unlikely.

We ended up investing more time instead into Jenkins and gave up on the distributed computing issue by using 64 core, 512GB RAM servers.

Re: Metal as a Service

#40
post #37
post #9

Earlier quoted context omitted.

Is this so novel? Both Amazon and OpenStack can provision and manage baremetal instances.

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.

Post reply on HN