On Mon, Mar 14, 2016 at 2:28 PM, Cory Johns wrote:
> 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
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
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
>
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
...
>
> > 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
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
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
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