Project Atomic is now sunset

The Atomic Host platform is now replaced by CoreOS. Users of Atomic Host are encouraged to join the CoreOS community on the Fedora CoreOS communication channels.

The documentation contained below and throughout this site has been retained for historical purposes, but can no longer be guaranteed to be accurate.

Project News

Atomic Workshop at DevConf.cz

Interested in Project Atomic? Looking to help make Fedora and CentOS Atomic Hosts even better? Join us for a half-day workshop at DevConf.cz in Brno on Saturday, 7 February 2015.

After lunch, we’ll meet to work on the Atomic Host Definition, plans for Fedora and CentOS Atomic Host, and projects that are essential to Project Atomic.

Full venue information can be found on the DevConf.cz site. We’ll be meeting after lunch to work until end of day. You might also want to check out the Cockpit Hackfest on Friday as well.

Planning for the Workshop will take place on the atomic-devel mailing list, and a final agenda will be posted the week of 2 February. Questions? Ping Joe Brockmeier (jzb at Red Hat), or ask on atomic-devel@projectatomic.io or in #atomic on Freenode.

View article »

Deploying a Containerized Gitlab Instance with Kubernetes

Back in November, I wrote about how to try out Kubernetes, the open source system for managing containerized applications across multiple hosts, using Atomic Hosts. In that post, I walked through a deployment of the Kubernetes project’s multicontainer Hello World application.

This time, I thought I’d explore running a more real-world application on Kubernetes, while looking into a few alternate methods of spinning up a Kubernetes cluster.

For the application, I picked Gitlab, an open source code collaboration platform that resembles and works like the popular Github service. I run a Gitlab instance internally here at work, and I wanted to explore moving that application from its current, virtual machine-based home, toward a shiny new containerized future.

Read More »

Improving Docker Error Messages

It is always amazing how small things can aggravate you. One of the biggest irritants I have with docker is how it has handled the --help option.

It was sending docker --help and docker COMMAND --help to stderr. This caused Red Hat’s Quality Engineering (QE) teams headaches since they wanted to automate testing for things like new options, or making sure the options in the man page matched those in the usage page.

QE would end up doing things like:

docker --help 2&>1 | cat ...

And it would never quite work correctly. Besides, a user running a command --help should not be considered an error.

But a far bigger irritant was when running a docker run command and mis-typing an option, like so:

docker run --itq rhel7 /bin/sh
flag provided but not defined: -itq

Usage: docker run [OPTIONS] IMAGE [COMMAND] [ARG...]

Run a command in a new container

  -a, --attach=[]            Attach to STDIN, STDOUT or STDERR.
  --add-host=[]              Add a custom host-to-IP mapping (host:ip)
  -c, --cpu-shares=0         CPU shares (relative weight)
  --cap-add=[]               Add Linux capabilities
...

The error message would scroll off the terminal window, and now I need to use the scroll bar to see what I screwed up.

Why did it show me the usage?

I know the usage, and if I want the usage I will type docker run --help.

Well, a patch I submitted a while ago just got merged to fix both issues. Now docker error messages will go to stderr, and usage messages will go to stdout.

Committing an error in the command line will now put out a message like the following:

docker run --itq rhel7 /bin/sh
flag provided but not defined: -itq

Try 'docker run --help' for more information.

This new behavior should be in docker-1.4.1. Enjoy!

As Eric S. Raymond said, every good work of software starts by scratching a developer’s personal itch.

View article »

Speak at Red Hat Summit: Proposals Due 7 January 2015

With just a few days into 2015, it may not seem like it – but Red Hat Summit and DevNation are just around the corner. The call for proposals is due to close on 7 January, and we’d like to encourage folks who are doing interesting things with Atomic and containers to submit proposals before the CfP closes.

We really want to hear from you, so if you’re working with Atomic and have something interesting to say – get those proposals in today! Whether you’re working with CentOS, Fedora, or RHEL Atomic Host, we’d like to hear from you.

If you’re submitting a proposal around Project Atomic, please drop me a line at jzb at RedHat.com – and feel free to ping me if you would like some help with the proposal or want to bounce a few ideas around. See you at Red Hat Summit in Boston!

View article »