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

Re: [atomic-devel] Atomic tool + libdoug



On Thu, 2015-03-26 at 15:20 -0400, Colin Walters wrote:
> On Tue, Mar 17, 2015, at 11:36 AM, Pavel Odvody wrote:
> > Hello, 
> > 
> > I've integrated some portions of libdoug [1] into Atomic CLI, the source
> > tree can be found at [2].
> 
> Neat!  So...I think it's clear that we need a per-host story for updates
> of both images and containers that's higher level than just raw docker.
> 
> Something I struggle with though is *where* updates should occur.
I wrote some stories here:

https://docs.google.com/a/redhat.com/document/d/1KNyaoFTTWa70R_oZZy87qM_lylHsC7BsM-bj4tyA51A/

Generally, I've come to a conclusion that people don't seem to think
about the updates yet, they're too busy getting everything up and
running, and these problems will pop up later - that being said, I
believe that we should take the initiative to do the first step :)

> 
> The "atomic" command was primarily introduced to fill in for
> "super-privileged containers" - these are potentially host specific.
> 
> For example, I'm a system administrator running a cluster, but
> processes are crashing on one host.  I log in and use "atomic run $distro-tools"
> to pull down a tools container with strace/perf etc.
Yep, but now it does much more, think the interaction with LABELs, that
feature alone makes the images self-sufficient and self-describing - and
that is great UX since I don't have to switch to a browser and
copy&paste 4 lines long 'docker run ...' to get the thing I just pulled
running.

> Since /usr/bin/atomic pulled down that image, it should be responsible
> for updating it I'd say.
> 
> Whereas on the other hand, if I'm deploying containers via Kubernetes
> pod descriptions, I'd want to handle management on a higher level.

My idea on that was to make the update mechanism work also with k8s'
YAMLS/JSONS, since my impression from k8s was that it's about iterative
convergence to a certain state, w/o any concern whether the desired
state is actually correct (= most recent).

> 
> Probably a server like Pulp that supports promotion and defines
> which versions of containers get run by which hosts.  In that world
> then, libdoug is used by Pulp.
> 
> What do you think?
Interesting idea! That would be like our own little Kubernetes, master
defines what and where to run (Pulp) and slaves (Atomic Hosts) are
(re)deployed to match that definition?

> 
> Another concern I have is that /usr/bin/atomic is really new and I
> personally feel we need more tests/design before we add more features,
> but that shouldn't block discussion of features or coding either =)
> 

+1

I can add basic integration&regression test suites as a starter - but I
guess that those should actually stem from the design docs. 
I'll try to come up with (slightly opinionated :)) design doc over the
course of the weekend.

-- 
Pavel Odvody <podvody redhat com>
Software Engineer - EMEA ENG Developer Experience
5EC1 95C1 8E08 5BD9 9BBF 9241 3AFA 3A66 024F F68D
Red Hat Czech s.r.o., Purky┼łova 99/71, 612 45, Brno

Attachment: signature.asc
Description: This is a digitally signed message part


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