<div dir="ltr">Kapil,<div><br></div><div>Great points, and we covered some of these pre-planning steps with users at the Charmer Summit. What I came away with was the following, and it falls in alignment with your analysis as well:</div><div><br></div><div>Actions for doing Image Garbage Collection</div><div><div>Actions for doing Container Garbage Collection in blue/green deployment scenarios</div></div><div>Logspout based log shipping to start, with syslog and PAAS connectors (see: papertrail sub) as stretch goals</div><div>Auto-scale with Swarm when swarm config=true (no additional charm, no additional work on the end user. "magic")</div><div>Relation with private registry (pending) to alter behavior to always poll/pull from a PR</div><div>-Experimental- LibNetwork based layers to extend the behavior to include Weave, Calico, Flannel, Fan as options</div><div><br></div><div>These were 1:1 with what you outlined, and what our user base I was communicating with over the summit agreed upon. So really good tip in terms of what you want to see from the stack.</div><div><br></div><div>I'm still working through getting the spec put together, and working through some of the sample code for what this looks like in terms of how the layers will piece together, what lives where, and how many resulting charms we gain from the layers + subscribable events for consuming app containers charm layers.</div><div><br></div><div>All the best,</div><div><br></div><div>Charles</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><br></div><div>Charles Butler <<a href="mailto:charles.butler@canonical.com" target="_blank">charles.butler@canonical.com</a>> - Juju Charmer</div><div>Come see the future of datacenter orchestration: <a href="http://jujucharms.com" target="_blank">http://jujucharms.com</a></div></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Sep 15, 2015 at 8:17 PM, Kapil Thangavelu <span dir="ltr"><<a href="mailto:kapilt@gmail.com" target="_blank">kapilt@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Sep 15, 2015 at 9:25 AM, Charles Butler <span dir="ltr"><<a href="mailto:charles.butler@canonical.com" target="_blank">charles.butler@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">I see your concerns about layering, reactive, et-al. for introductory/new charmers. I however raise you a value proposition, and will speak to<div>the point we are generating the 'best practice' method, that we want to guide charmers down. The common feedback we've received from</div><div>authors is "I'm not as concerned with the overhead of learning, I just want you to tell me the best way to do it." While this represents a small</div><div>number from the overall community of people charming, we've delivered on this asked behavior. We're taking away some maintenance</div><div>burdens, and exposing a scaffolded framework to deliver your app containerized workload.<br></div></div></blockquote><div><br></div></span><div>That's fair, it feels pretty good as an intro to best practices guide for writing reactive style python charms working in an ecosystem with reuse and extensibility.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><br></div><div>While its arguably more complex than `curl <a href="http://get.docker.com" target="_blank">get.docker.com</a> | sh` - there are a few things happening here that should concern you already. </div><div><br></div><div>- You're not verifying the payload, and blindly executing it via a shell. This violates charm store policy, and is a black hole into whats happening </div><div>without tailing the unit logs. </div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><br></div><div>While the script is a replica of that installation method, (credit is given in the layer repository readme) it was deemed important to mimic </div><div>their recommended install - when you look at the ansible based docker charm and its divergent history + issue log.</div><div><br></div><div>The script has been modified to surface what the unit is doing via the newer `juju status-set` routines for clear visibility. And we get the </div><div>added benefit of supporting cent/debian out of the box with this method. The ownership burden is on us, the ~charmers that are maintaining </div><div>the docker layer. </div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><br></div><div>I appreciate the feedback though Kapil, and thanks for acknowledging the raise in knowledge to 'get started' - you're right its not as straight</div><div>forward as curling a bash script and piping to sudo. But we don't encourage that anyway :) We feel that you can learn and get productive with this</div><div>fairly quickly, with minimal knowledge of whats actually happening layers below. Just look at what states become exposed and take action.</div><div><br></div></div></div></blockquote><div><br></div></span><div>i think you misunderstood the download analogy, apt-get install docker is equivalent in this context or downloading over ssl with checksum and cert verification and pipe into shell. the concern and question was the best way to introduce folks to using juju with docker when the alternative is two lines of shell script. ie. the comparison for the nginx example an install hook.</div><div><br></div><div>apt-get install <a href="http://docker.io" target="_blank">docker.io</a></div><div><br></div><div>and a start hook</div><div><br></div>docker run -p 80:80 dockerfile/nginx -v html_dir:/var/www/html<span class=""><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div></div><div>Give it a spin and let us know if you've changed your opinion at all, and I'll be happy to talk/work through the concerns.</div></div></div></blockquote><div><br></div><div><br></div></span><div>as far as adoption goes, an easy on ramp up the learning curve matters. docker, terraform, packer, ansible, all great examples of that, and for onboarding people into writing charms that utilize docker i think that's its important as well to show the simplest thing that works. as a framework or layer for docker charms, i'd at least expect it handles some set of the common concerns germane to using docker across multiple hosts, swarm, networking, image gc, container gc, registry config, proxies, etc. as it is the docker example isn't really about docker, its an intro to reactive style python charm dev, but a docker guide of its own has value. if the target audience is those working on integration with an ecosystem of charms with lots of optional integrations and relations (openstack, bigdata, container eco) then the reactive style scales in complexity well but it doesn't really address atm anything wrt to docker usage concerns.</div><div><br></div><div>cheers,</div><div><br></div><div>-kapil</div><span class=""><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><span><font color="#888888"><div><br></div><div>- Charles</div><div><br></div><div><br></div></font></span></div></div><div class="gmail_extra"><span><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>Charles Butler <<a href="mailto:charles.butler@canonical.com" target="_blank">charles.butler@canonical.com</a>> - Juju Charmer</div><div>Come see the future of datacenter orchestration: <a href="http://jujucharms.com" target="_blank">http://jujucharms.com</a></div></div></div></div></div></div>
<br></span><div><div><div class="gmail_quote">On Tue, Sep 15, 2015 at 7:46 AM, Kapil Thangavelu <span dir="ltr"><<a href="mailto:kapilt@gmail.com" target="_blank">kapilt@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">i think participating in the burgeoning docker ecosystem is a worthwhile goal by making it easier to write charms that utilize docker. I do have some concerns though about the complexity of the layering that's taking place in the charm ecosystem. I've found that juju has been fairly hard to teach and adapt to real world usage and the layering of frameworks at the charm authoring level makes learning and productivity for new users even harder to achieve (ie those docs reference, charm helpers, reactive charm helpers, docker reactive 'layer', charm composition), all of which are fairly advanced concepts to a new user, and frankly is all of that nescessary to understand running a shell script <a href="https://github.com/juju-solutions/layer-docker/blob/master/scripts/install_docker.sh" target="_blank">https://github.com/juju-solutions/layer-docker/blob/master/scripts/install_docker.sh</a> which is effectively the jujuized version of (curl <a href="http://get.docker.com" target="_blank">get.docker.com</a> | sh) .. now say i want to configure an insecure registry or any other docker cli param i have to break apart the layer abstraction anyways. It does seem like a useful intro to some of the advanced/additional concepts in charm authoring ecosystem, but at the same time the burden seems high (ie. kiss violation) for how to run a docker container.<div><br></div><div>cheers,</div><div><br></div><div>Kapil</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Fri, Sep 11, 2015 at 11:40 AM, Charles Butler <span dir="ltr"><<a href="mailto:charles.butler@canonical.com" target="_blank">charles.butler@canonical.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div dir="ltr">If anyone here is interested in delivering Docker App Containers with Juju, mbruzek and I have put together some documents around a hot new process using composer layers and the reactive framework.<div><br></div><div>This is interesting because you the charm author will only be concerned with how to deliver your application layers logic. You don't need to worry about installing docker, or how to scaffold out a full charm boilerplate. This entire process reduces the total cost of ownership of the author to just managing their app layer + container.</div><div><br></div><div> <a href="https://github.com/juju/docs/pull/672" target="_blank">https://github.com/juju/docs/pull/672</a><br></div><div><br></div><div>And we've constructed/linked to an example charm using this process. There's probably holes in this document, and welcome feedback directly on the pull request to suss them out.</div><div><br></div><div><div><div><div dir="ltr"><div><div dir="ltr"><div>We're fully interested in receiving your feedback about this, as its important that we are properly engaging our users that are interested in delivering their dockerized app with Juju, and that we've given you the proper lessons to do so easily, and made the right decisions in tooling.</div><div><br></div><div>All the best,</div><div><br></div><div><br></div><div>Charles Butler <<a href="mailto:charles.butler@canonical.com" target="_blank">charles.butler@canonical.com</a>> - Juju Charmer</div><div>Come see the future of datacenter orchestration: <a href="http://jujucharms.com" target="_blank">http://jujucharms.com</a></div></div></div></div></div></div>
</div></div>
<br></div></div><span>--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div></div></div>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div>