Capabilities and slots

Jamie Strandboge jamie at canonical.com
Tue Jan 19 21:32:47 UTC 2016


On 01/19/2016 01:55 PM, Gustavo Niemeyer wrote:
> Hello snappy developers,
> 
> Zygmunt and I just finished a good meeting where we polished the design of the
> REST API and the Go interfaces, reflecting sprint agreements and the needs we've
> outlined in the last couple of weeks.
> 
> This will start to surface as pull requests in the repository imminently, if
> you're interested in more thoroughly reviewing those decisions. At a high-level,
> though, the interesting outcome is that we've settled down onto the following
> terminology and semantics.
> 
> Capabilities always have a providing snap and a consuming snap. Even those that
> may feel like they should come "from the system", are actually associated with a
> providing snap. That's consistent with our new view of the  world, where
> everything comes from a snap. At some point we may introduce a "defaulting"
> behavior where we allow omission of information to do what's most expected in a
> given context (e.g. "pin-13" refers to "canonical-pi2.pin-13") but for the time
> being we'll keep this explicit in the interest of getting the foundation right.
> 
> Capabilities and capability names are the way we talk about the providing side.
> The consuming side has capability slots, and capability slot names. Thus, when
> we say that "a snap has capabilities", we're implying it provides/offers
> features. When we say a snap has capability slots, we're implying it
> requires/consumes features. That asymmetry, originally suggested by Zygmunt,
> makes conversations, documentation, and APIs around capabilities much easier to
> understand.
> 
> We still need to map the consequences of these decisions and the original
> agreements onto the metadata files. I expect that to take place in the next
> couple of weeks.
> 
What about things that are pure permissions capabilities like
'container-management' (there are actually quite a few of these we agreed to at
the sprint)? AIUI, lxd and docker would consume this capability and provide a
'lxd' or 'docker' (respectively) capability that another snap could then
consume. Do we consider the OS snap the providing snap for
'container-management' or is something different going to happen?

-- 
Jamie Strandboge                 http://www.ubuntu.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20160119/1c17b248/attachment.pgp>


More information about the snappy-devel mailing list