On Tue, Mar 8, 2016 at 9:19 AM, Simon Davy <simon.d...@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.
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
