Re: Reactive roadmap
On 14/03/16 13:55, Simon Davy wrote: > Right, downloading at build time is a different problem. The issue is > that the layer might do something on the install hook, for example, > which downloads from the internet at run time, on the units. Such > things work fine in dev or for demos, but will fail in many production > environments. Resources, which are assets that can be published through the charm store for charms (like a specific JVM tarball, or JAR file) are a significant improvement in this. Also, during the Juju 2.x timeline we will separate the "build" phase from the "install" phase, enabling all the downloads to happen once only and be shared across multiple units on clouds that support snapshots. Mark -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Reactive roadmap
On Tue, Mar 8, 2016 at 9:19 AM, Simon Davy 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
Re: Reactive roadmap
On Mon, Mar 14, 2016 at 1:05 PM, John Meinel wrote: > ... > >> >> >> > 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. >> >> Yes, layers that do not work in network restricted environments are >> not useful to many people. I think you will find layers will improve >> things here. Layers only need to be written correctly once. And if >> they are broken, only fixed once. A big improvement over cargo culted >> code, where you could end up fixing essentially the same bug or adding >> the same feature several times. >> > > Layers themselves are a compile time thing, not a runtime thing, right? So > while the code in the layer might say "download some resource from github", > you the layer itself is only downloaded from github before it is published > into the charm store. Am I understanding this wrong? > > John > =:-> Right, downloading at build time is a different problem. The issue is that the layer might do something on the install hook, for example, which downloads from the internet at run time, on the units. Such things work fine in dev or for demos, but will fail in many production environments. -- Simon -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Reactive roadmap
... > > > 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. > > Yes, layers that do not work in network restricted environments are > not useful to many people. I think you will find layers will improve > things here. Layers only need to be written correctly once. And if > they are broken, only fixed once. A big improvement over cargo culted > code, where you could end up fixing essentially the same bug or adding > the same feature several times. > > Layers themselves are a compile time thing, not a runtime thing, right? So while the code in the layer might say "download some resource from github", you the layer itself is only downloaded from github before it is published into the charm store. Am I understanding this wrong? John =:-> -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Reactive roadmap
On 9 March 2016 at 01:19, Simon Davy wrote: > 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? You can pin the layers in your build environment - they are only unpinned if you are pulling them direct from the upstream branch. A tool like codetree could be used to checkout your dependencies with pinned versions allowing repeatable builds if you need that. Allowing you to deal with the accumulated breakage and incompatibilities in one huge indigestible chunk later, far too late to affect upstream changes ;) > 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. Yes, layers that do not work in network restricted environments are not useful to many people. I think you will find layers will improve things here. Layers only need to be written correctly once. And if they are broken, only fixed once. A big improvement over cargo culted code, where you could end up fixing essentially the same bug or adding the same feature several times. -- Stuart Bishop -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju