Re: armhfentures

[Andrew Wilkins]

On Tue, Mar 15, 2016 at 4:47 AM Curtis Hovey-Canonical 
wrote:

> On Sat, Mar 12, 2016 at 2:26 PM, Michael Hudson-Doyle
>  wrote:
> > Yes, my advice would definitely be to not worry about fixing this. I
> hope to
> > have 1.6 in trusty (-updates BTW, not backports) within a week - just
> need
> > to get some time from the over subscribed people who can make it happen.
>
> Updates, not backports? great.
>
> I favour going to 1.6, but this doesn't solve the precise go 1.2
> compilation error. One option is to stop building precise agents in
> Lp. The process that created the centos agent could also make the
> precise agent. We still don't have a means to deliver armhf precise
> client via PPA.
>

Is it possible to package for precise on a trusty (or later) host? The Go
binaries from one will work on the other.


> --
> Curtis Hovey
> Canonical Cloud Development and Operations
> http://launchpad.net/~sinzui
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: armhfentures

[Curtis Hovey-Canonical]

On Sat, Mar 12, 2016 at 2:26 PM, Michael Hudson-Doyle
 wrote:
> Yes, my advice would definitely be to not worry about fixing this. I hope to
> have 1.6 in trusty (-updates BTW, not backports) within a week - just need
> to get some time from the over subscribed people who can make it happen.

Updates, not backports? great.

I favour going to 1.6, but this doesn't solve the precise go 1.2
compilation error. One option is to stop building precise agents in
Lp. The process that created the centos agent could also make the
precise agent. We still don't have a means to deliver armhf precise
client via PPA.


-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Reactive roadmap

[Mark Shuttleworth]

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

[Cory Johns]

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

[Simon Davy]

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

[John Meinel]

...


>
> > 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

[Stuart Bishop]

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