Simon, You raise some very interesting questions and good points. I've also been developing charms with layers, run into some of these same issues, and developed a pragmatic approach that has helped me manage it pretty well so far. In a more mature layer/interface ecosystem, it might not be the optimal approach. I look forward to adapting my tactics as the ecosystem evolves.
On Tue, Mar 8, 2016 at 8:19 AM, Simon Davy <simon.d...@canonical.com> wrote: > 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 :) > I too would like to see and help the ecosystem mature. > 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? > For the time being, I've been avoiding upstream churn by vendoring all the layers and interfaces that my deployment uses. These are all subdirectories of a project that builds a bundle consisting of several charms, and also contains supporting end-to-end test data and CI scripts. With the most trivial of configuration changes, I can build, deploy and test these services by compiling source from development branches, installing from release tarballs or debian packages. This has been amazing for end-to-end testing, demos of features in development, as well as complex feature development where changes need to be coordinated across several services at once. Combined with the LXD provider, which is just amazingly fast on a xenial host, this project makes me very confident about researching "what if"-type scenarios about our deployment -- it doesn't take much at all to make minor changes to a charm and just go try something. That could be a configuration change, a different charm that provides the same interface, a feature branch or set of feature branches for the services -- anything, really. I manage the vendored layers and interfaces with "git subtree", which is really the only way I'd even consider vendoring. Subtree allows me to pull upstream layer & interface projects into mine, while retaining all the upstream revision history, and retaining the ability to continue to contribute to and pull from these upstream git repositories. Vendoring without this capability would be fraught with peril, requiring too much manual, tedious, error-prone work to work safely in my opinion. An interface or layer that starts as a project subdirectory out of a short-term need, can be easily refactored into something generally useful, and then pushed to a separate git repo with a "git subtree push", which then becomes the new upstream where I can collaborate with other charmers. This is how I started the local-monitors and nrpe-external-master interfaces. They began as an internal migration from an older charm example (which was ansible-based). I published them with 'git subtree push' once I felt they were suitable for general reuse. I'll admit there are some disadvantages to the vendoring approach. Unless I really pay attention to those upstreams, I might miss a useful bugfix or security improvement. That's also a challenge with pinning btw (which is effectively a cheap copy form of vendoring with references). It'd be nice if I could rely on a branch name to be stable but provide bugfixes. Completely vendoring upstreams with subtree could become unnecessary, needless overhead, if stable upstreams were common practice. I'd still probably want to pin upstream revisions though, just to have reproducible builds. > 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. > In such an environment, I think what you'd want to do is to mirror the upstream layer/interface projects from Github into git repositories that your egress policy allows. I could be wrong, but I think you'd then need to clone them locally from git and use filesystem paths for your layer & interface references for 'charm build' to work. It would be nice if we didn't need to collect them locally. Maybe there's a way now? > > Thanks for all the work on making charming better. > Same here, thanks for this stuff! > -- > Simon > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
