Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub's Metal Cloud

githubengineering.com

Post reply on HN
Print view View original

51–60 of 83 posts

Re: GitHub's Metal Cloud

#51

Post by tehbeard »

ktt wrote: post #36
castell wrote: post #21

The Hubot workflow sounds interesting. It seems more and more DevOps prefer it. Has someone first hand experience with such Hubot usage? Do you prefer such commands or would you want to write more informal short sentences?

Unfortunately most of the material on ChatOps currently covers only how to get Hubot to display cat pictures or other trivia [1]. Maybe it's because each company should create their own "chat API" but I'd also like to hear some real, inside "war stories". Does anyone knows what app does GitHub use for chats? Looks like a simple and elegant UI over Basecamp. [1]: http://hubot-script-catalog.herokuapp.com/

Going off Hubot's sourcecode, I'd guess campfire.

Re: GitHub's Metal Cloud

#52

Post by jssjr »

sargun wrote: post #2

This seems wrong to me. This was the state of the art ~3 years ago. Now, I feel like all of the machines should be provisioned already with an OS, and a basic image, and a orchestration system like CoreOS / Mesos / Docker should specialize them. IMHO, requiring hardware, or the entire machine should be exception, not the rule.

GitHub's physical infrastructure team doesn't dictate what technologies our engineers can run on our hardware. We are interested in providing reliable server resources in a easily consumable manner. If someone wants to provision hardware to run docker containers or similar, that's great!

We may eventually offer higher order infrastructure or platform services internally, but it's not our current focus.

Re: GitHub's Metal Cloud

#53

Post by stephenr »

wtbob wrote: post #50
ptype wrote: post #49

Why would a company like GitHub choose Ubuntu over Debian? The LTS policy?

I too would be interested in the answer. From my perspective, Debian is the server Linux distro par excellence , and in my experience the folks who choose Ubuntu have been devs who don't actually use Linux (e.g., the sorts who develop on a Mac or in a VM rather than on a personal Linux system). It's not really fair to Ubuntu, which is decent enough in its own way, but I tend to consider the choice of Ubuntu to be a b…

I agree with the main point you're trying to make, but the suggested examples you provide don't always hold true.

I'm pretty dedicated to Debian on the server, a good part of my business is providing infrastructure support and setup, and I work from a MacBook Pro.

Re: GitHub's Metal Cloud

#54

Post by SEJeff »

alpb wrote: post #4

> We've hacked together a Ruby script that retrieves a console screenshot via IPMI and checks the color in the image to determine if we've hit a failure or not. That's pretty funny yet sounds a lot familiar to many of us as every now and then we all do these sort of nasty hacks.

Vs just buying opengear console servers and something like conserver to get the actual text via serial like most large Unix environments (every job I've worked at) do. Then you can just scrape the text.

Re: GitHub's Metal Cloud

#56

Post by avar »

wtbob wrote: post #50
ptype wrote: post #49

Why would a company like GitHub choose Ubuntu over Debian? The LTS policy?

I too would be interested in the answer. From my perspective, Debian is the server Linux distro par excellence , and in my experience the folks who choose Ubuntu have been devs who don't actually use Linux (e.g., the sorts who develop on a Mac or in a VM rather than on a personal Linux system). It's not really fair to Ubuntu, which is decent enough in its own way, but I tend to consider the choice of Ubuntu to be a b…

Some choose it because Ubuntu, unlike Debian, has a guaranteed timely release cycle, and unlike Debian they have formalized LTS.

Re: GitHub's Metal Cloud

#57

Post by greggyb »

glenngillen wrote: post #33
jon-wood wrote: post #26

Earlier quoted context omitted.

I'm somewhat split. There's definite value in having a shared history of what people have done, but I prefer that to take the form of command line tools pushing status updates to Hipchat or whatever. You lose so much convineance by pretending Hipchat's chat box is a terminal, everything from command history to being able to quickly iterate over the contents of a file or set environment variables.

One of the most compelling aspects of it for me isn't so much the shared history, but just visibility of what people have done. It's a really effective way of transferring knowledge of how things are done. You can easily drop into the room and watch play-by-play how a given task is done.

If this is the goal, why not just have a script export the shell's history to a chat channel?

To me, a wiki would be even better, because you could retroactively include expository comments along with the command history.

Re: GitHub's Metal Cloud

#58

Post by samlambert »

stephenr wrote: post #20

These lines seem odd to me, maybe it's just the wording: > [gPanel] Deploying DNS via Heaven... > hubot is deploying dns/master (deadbeef) to production. > hubot's production deployment of dns/master (deadbeef) is done! (6s) Is this just an IMO odd use of the word "deploying" or does a DNS change really mean building and deploying a new package/image?

We can deploy DNS like an app. If we want to add hostnames manually we do it in git and deploy the DNS "app" via hubot.

Re: GitHub's Metal Cloud

#59

Post by mariojv »

A_Beer_Clinked wrote: post #19

Can anybody with experience of using Openstack Ironic[1] in this space comment on advantages of rolling your own liek GitHub? [1] https://wiki.openstack.org/wiki/Ironic

The OnMetal [1] team at Rackspace uses OpenStack Ironic.

It's saved us a lot of engineering time and let us offer the same interface as our VMs for provisioning baremetal machines with OpenStack Nova.

[1] http://www.rackspace.com/en-us/cloud/servers/onmetal

Re: GitHub's Metal Cloud

#60

Post by eLobato »

ymse wrote: post #32

Hardware provisioning is a dying art. I would love to see a modern-day xCAT[0] clone that's easy to install and configure and with proper multi-platform support. Foreman is half-way there, but AFAIK doesn't do BMC provisioning and discovery, which is a big deal. 0: https://github.com/xcat2/xcat-core/blob/master/docs/source/i...

Foreman does discovery [1] (PXE, PXE-less, segmented networks, through bootdisk) and handles BMC, I wrote the API in fact :)

http://theforeman.org/plugins/foreman_discovery/4.1/index.ht...

Maybe you were not aware because it's a plugin, we kind of have that problem in the Foreman community, plugins are not as visible as they should and they can contain key features.

Post reply on HN