Re: A (Very) Minimal Charm

[Katherine Cox-Buday]

Mark Shuttleworth  writes:

> We are already aligning things like terms and authentication so that
> charms and snaps can be delivered together, though, so perhaps all
> thats required is the ability to give the charm some say in update
> control of snaps.

Interesting, thanks, Mark.

-- 
Katherine

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: A (Very) Minimal Charm

[Free Ekanayaka]

>
> As a developer, with an xfs-backed
>

s/xfs/zfs/
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: A (Very) Minimal Charm

[Free Ekanayaka]

On 15 December 2016 at 07:59, John Meinel  wrote:

> Right, the issue for test/development iterations is that "machine
> requested to booted in cloud" for LXD is a lot closer to 10s. Especially if
> you set "enable-os-refresh-update: false" and "enable-os-upgrade: false",
> which are also likely to be set in a testing environment.
>

+1

To re-iterate what previously stated: the point is not production
deployments, but rather development and testing cycles. The experience will
be compared to things like docker & friends where the feedback look happens
in seconds, not minutes or dozens of seconds.

As a developer, with an xfs-backed local juju lxd provider and something
like apt-cacher-ng or deb-squid-proxy installed I expect and want "juju
deploy ubuntu" (or any other minimal reactive-based charm) to take seconds.
Anything less than that gets in the way of doing proper TDD.

Free
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: A (Very) Minimal Charm

[Mark Shuttleworth]

On 16/12/16 07:33, Katherine Cox-Buday wrote:
> Tim Penhey  writes:
>
>> Make sure you also run on LXD with a decent delay to the APT archive.
> Open question: is there any reason we shouldn't expect charm authors to take 
> a hard-right towards charms with snaps embedded as resources? I know one of 
> our long-standing conceptual problems is consistency across units which snaps 
> solves nicely.

We'll need to figure out the inherent tension between the way resources
are updated and the way snaps are updated. Resources are very similar to
snaps, but snaps are growing digital signatures that need to be
delivered together with the snap to prove integrity, and we don't want
to duplicate all that work. We are already aligning things like terms
and authentication so that charms and snaps can be delivered together,
though, so perhaps all thats required is the ability to give the charm
some say in update control of snaps.

Mark



-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev