Reactive roadmap

[Simon Davy]

Hi all

My team (Online Services at Canonical) maintains >20 private charms
for our services, plus a few charmstore charms.

Most of these charms are written with charmhelpers ansible support, or
with the Services framework. We would like to move towards
consolidating these approaches (as both have issues), and so have been
experimenting with reactive.

We like the ideas in reactive, especially the composition part, as
sharing common code between our charms has been very painful. Also,
the higher-level user-defined events that reactive provides is a
definite improvement over having to implement the lower level relation
dance semantics every time.

However, it's a fast moving target, and we have encountered some
issues.  So we have a couple of questions, that we haven't been able
to locate answers for in reactive docs (we may have missed some?).

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 :)

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?

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.  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.

Thanks for all the work on making charming better.

-- 
Simon