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 -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju