I bet someone in marketing at Canonical shit their pants watching the WWDC yesterday.
Er, why? Apple stopped caring about the cloud and traditional server market a while back.
Because Apple used the word Metal to name one of their new APIs?
Metal as a Service
21–30 of 106 posts
Re: Metal as a Service
#22I 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."
Re: Metal as a Service
#23Re: Metal as a Service
#24I bet someone in marketing at Canonical shit their pants watching the WWDC yesterday.
If you're referring to the use of Metal in the name, I doubt it. It is a different market. Canonical isn't out to make millions from a highly focused tool that gets a large amount of its value from being free for anyone to use, forever.
A similar situation happened when Apple adopted the name Launchpad for one of their services.
Re: Metal as a Service
#25I bet someone in marketing at Canonical shit their pants watching the WWDC yesterday.
The OP might have stumbled upon this while searching the web for apple's metal, if that's the case it shows that the naming collision could be a good way to have people discover the product unexpectedly.
Re: Metal as a Service
#26OVH uses something like this for all of their newer server offerings.
Re: Metal as a Service
#27We 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 idea what version it is at now.
* Juju charms "local provider" is potentially very compelling but wasn't in a workable state.
In the end we abandoned it.
Re: Metal as a Service
#28Earlier quoted context omitted.
I wonder why they chose to use Intel NUC for this. It has dire price/performance. I built a cluster (see http://rwmj.wordpress.com/?s=cluster ) recently, and I used AMD hardware for it because (as of right now) the performance is unbeatable for the price. I have a 32 core cluster that cost me £1300 including everything except a metal box to put it in.
That's pretty cool. One of the goals for the orangebox was being robust and compact enough to throw in a suitcase and fly to a conference. The nucs win on compactness, and also via intel's vpro/amt can do remote power management (ie. ipmi light).
Nice -- didn't know that Intel now had a serious remote management offering. These AMD mobos do wake-on-LAN, and that's it. They don't even have serial BIOS.
Re: Metal as a Service
#29We 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.
Re: Metal as a Service
#30This 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.
[deleted]