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/