[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [atomic-devel] Operating an Atomic fleet


Yes, I'll be in the meeting tomorrow.  On the server version, no intent to proscribe by saying F21, just happened to what I set up in a VM for testing a local VM fleet.  The takeaway is some external "full" server OS separate from the Atomic hosts.

-Matt M

On Mon, Jan 5, 2015 at 2:33 PM, Joe Brockmeier <jzb redhat com> wrote:
Bumping this since it came through right before the holidays. Also
suggesting we discuss at the CentOS Atomic SIG meeting tomorrow (14:30
UTC in #centos-devel). All good questions - we do need to address.

Matt - will you be able to attend?

On 12/23/2014 09:48 AM, Matt Micene wrote:
> Now that there's a fairly solid core build, I'd like to turn to the idea of
> operating intent for Atomic fleets.  The presumption is that an Atomic host
> on it's own running one off Docker containers isn't the central use case.
> Mainly this is for the Getting Started guide, but also to clarify some of
> the ideas that we're communicating.  I've noticed that there's some
> pointers to tools that don't ship in the core build (git and ansible for
> example), so how do we expect someone to manage their Atomic fleet?
> Here's some base questions that I think need commentary:
> 1) Core services run on the Atomic hosts - Kubernetes, fleet, etcd all run
> on the host not as containers on the host
> 2) Kubernetes has a master / minion relationship for scheduling - the
> minion definitions live on the Atomic hosts designated for work loads, the
> master definition and etcd live on:
>      a) a nominated Atomic host
>      -- or --
>      b) a Fedora 21 server designated as fleet manager

Or CentOS 7?

> 3) Cockpit multi-host is the standard way to manage an Atomic fleet, to
> include Kubernetes, fleet, Docker, etcd [once the appropriate modules are
> complete].
> Other thought, move the layered package POC to a first class effort?
> Adding packages in a supported manner could be useful for a operational
> model, I'm thinking of things like git, ansible, ipa-client, and other
> things pulled / turned down as too large or not enough requests.
> -Matt M

Joe Brockmeier | Principal Cloud & Storage Analyst
jzb redhat com | http://community.redhat.com/
Twitter: @jzb  | http://dissociatedpress.net/

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]