<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 19, 2016 at 7:32 PM, Jamie Strandboge <span dir="ltr"><<a href="mailto:jamie@canonical.com" target="_blank">jamie@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 class=""><div class="h5"><span style="color:rgb(34,34,34)">What about things that are pure permissions capabilities like</span><br></div></div>
'container-management' (there are actually quite a few of these we agreed to at<br>
the sprint)? AIUI, lxd and docker would consume this capability and provide a<br>
'lxd' or 'docker' (respectively) capability that another snap could then<br>
consume. Do we consider the OS snap the providing snap for<br>
'container-management' or is something different going to happen?<br></blockquote><div><br></div><div>Mapping that to the new language, the ubuntu-core snap will offer a container-management capability, and the docker snap will consume it via a container-management capability slot, </div><div><br></div><div>With that said, I'd try to pick a new name for "contrainer-management" due to the ambiguity there. What docker arguably does is to "manage containers", so it's reasonable to expect it to provide that capability instead of consuming it, but what you're referring to AIUI is about the low-level OS access necessary for _being_ a manager. In either case, that's an unrelated issue we can easily solve by tweaking that name. </div><div><br></div><div><br></div></div><div class="gmail_signature">gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a></div>
</div></div>