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®ression 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