Reactive roadmap

[Cory Johns]

On Tue, Mar 8, 2016 at 9:19 AM, Simon Davy <simon.davy at canonical.com> wrote:

> 1) Is there a roadmap for reactive? A target for a stable 1.0 release,
> or similar? We'd ideally like a stable base to build from before
> committing to use a new framework, having been (re)writing/maintaining
> charms for 4+ years now :)
>

The layered & reactive approach saw adoption more quickly than I expected,
which is both great and unfortunate for working out the kinks.  That said,
the core concepts of both aspects of this approach have been fairly stable,
with additions rather than breakages.  There is a 2.0 release of
charm-tools coming, to coincide with Juju 2.0, but again, the build process
should be backwards compatible.  There are some issues with charms.reactive
that may require incompatible changes to fix, but that would be for 2.0 and
the semantic version range that the base layer uses gives us flexibility
there, though that leads in to your next point.


> 2) Layer pinning. Right now, layers are evolving fast, and the lack of
> pinning to layer versions has caused charm builds to break from day to
> day. Is this a planned feature?
>

There has been quite a bit of discussion about this and I don't think
either side has swayed the other.  On the one hand, as you note, there is a
valid argument for needing to avoid breakage and in these early days,
layers are evolving quickly.

On the other hand, we want to strongly encourage charm authors to always
sync the layers and interfaces they use to take advantage of the
improvements and fixes from upstream, lest charms end up stagnating.  And
that means encouraging backward-compatibility in the layers.  To that end,
it has been suggested that layers be handled like interface protocols in
that, if you need to make an incompatible change, you can fork the layer
with a different name and both can coexist until one supplants the other.

Additionally, as Stuart pointed out with tongue-in-cheek, the local repo
can serve that purpose, and with charm-tools 2.0 that will become easier
with the pull-source command (https://github.com/juju/charm-tools/pull/125).


> 3) Downloading from the internet. This issue has been common in
> charmstore charms, and is discouraged, AIUI. But the same issue
> applies for layers, and possibly with more effect, due to a layer's
> composibility.  We simply can not utilise any layer that downloads
> things from github or similar, and I'm sure others are in a similar
> situation.


Again, as Stuart mentioned, this is actually *better* with layers than it
has been in the past, because layers encourage charm dependencies to be
bundled in the charm's wheelhouse, and layers can provide more consistent
adoption of best practices (it only needs to be done right once, instead of
every time).

(Note, though, that's there's an open issue with regards to some few Python
modules and network-restricted deployments:
https://github.com/juju/charm-tools/issues/117)


> We're aware of resources, but not convinced this is a
> scalable solution for layers, as it makes using a charm that has
> layers that require resources much more complex. So, some clarity in
> this area would be helpful.
>

I can't say that I understand why you think resources and layers would make
things more complicated.  They seem like they will work well together and
would solve the other half of charms in network-restricted environments
quite nicely.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160314/e4f0f869/attachment.html>