[Review Queue]: giraph, ibm-*, mongodb, odoo, ntp

[Kevin Monroe]

Hi friends!

Cory, Kostas, Pete, and I have 2 weeks worth of reviews to note:

Feb 23, 2017:

   -

   giraph
   -

  https://review.jujucharms.com/reviews/82
  -

  This has been on our radar for a few review cycles now.  We added a
  proper giraph interface so this charm no longer needs to hijack
the mahout
  relation :)
  -

  We suggested general charm fixes with the following PR:
  -

 https://github.com/panagiotisl/bigtop/pull/3
 -

  Pending further discussion with the author, this should sail through
  to the store once a new revision is released.
  -

   ibm-was-nd
   -

  https://review.jujucharms.com/reviews/40
  -

  Issue with terms prevents testing.  This can be fixed in the charm,
  but I also opened https://github.com/juju/charmstore-client/issues/118
  to get clarification on the error it caused and why it’s an issue
  -

  Additional issues with handling resource upgrades and with test were
  spotted from code review
  -

   mongodb
   -

  https://review.jujucharms.com/reviews/91
  -

  We run into two issues during review.
  -

 Tests were failing
 -

 The proposed for promulgation revision does not belong to one of
 the maintainers.
 -

  We will have to wait for the author’s and maintainers’ input.
  -

   Ibm-dsm-base
   -

  https://review.jujucharms.com/reviews/56
  -

  We found a couple of issues that need the author’s input.
  -

  Most importantly there was a default password used that raises
  security concerns.
  -

   Ibm-wxs-catalog
   -

  https://review.jujucharms.com/reviews/41
  -

  Small linter error
  -

  Test not marked as executable (isn’t automatically picked up by
  bundletester)


Feb 16, 2017:

   -

   odoo
   -

  https://review.jujucharms.com/reviews/23
  -

  Another ping put out to the author, as there is a provided PR which
  resolves the only issue blocking this review
  -

   ntp
   -

  https://review.jujucharms.com/reviews/85
  -

  Charm was already promulgated, so closed review
  -

   Ibm-xcat
   -

  https://review.jujucharms.com/reviews/38
  -

  During review a number of issues came up. Namely:
  -

 Dead code and assumptions on the unit networking
 -

 Tests failing, README improvements
 -

  We would like the author to review some of the issues reported.
  -

   Ibm-mobilefirst-server
   -

  https://review.jujucharms.com/reviews/39?revision=75
  -

  We did a quick review and spotted a couple of blockers
  -

 Use unpromulgated charms during tests and failing lint errors
 - We will need to wait for the author to address these issues


Find us in #juju on freenode with any questions/concerns. Thanks!
-Kevin
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju 2.1.0, and Conjure-up, are here!

[Simon Davy]

On Fri, Feb 24, 2017 at 11:14 AM, Andrew Wilkins <
andrew.wilk...@canonical.com> wrote:

> On Fri, Feb 24, 2017 at 6:51 PM Mark Shuttleworth  wrote:
>
>> On 24/02/17 11:30, Andrew Wilkins wrote:
>>
>> On Fri, Feb 24, 2017 at 6:15 PM Adam Collard 
>> wrote:
>>
>> On Fri, 24 Feb 2017 at 10:07 Adam Israel 
>> wrote:
>>
>> Thanks for calling this out, Simon! We should be shouting this from the
>> rooftops and celebrating in the streets.
>>
>>
>> Only if you also wave a big WARNING banner!
>>
>> I can definitely see value in pre-installing a bunch of things in your
>> LXD images as a way of speeding up the development/testing cycle, but doing
>> so might give you false confidence in your charm. It will become much
>> easier to forget to list a package that you need installing,  or to ensure
>> that you have the correct access (PPA credentials, or proxy details etc.)
>> and having your charm gracefully handle when those are missing.
>>
>> Juju promises charms encoding operations that can work across multiple
>> cloud providers, bare metal and containers please keep that in mind :)
>>
>>
>> Indeed, and this is the reason why it wasn't called out. We probably
>> should document it for power-users/charmers, but in general I wouldn't go
>> encouraging its use. Optimising for LXD is great for repeat deploys, but it
>> wouldn't be great if that leads to less attention to quality on the rest of
>> the providers.
>>
>> Anyway, I'm glad it's helping make charmers' lives easier!
>>
>>
>> We should call this out loudly because it helps people making charms.
>>
>> Those people are plenty smart enough to debug a failure if they forget a
>> dependency which was preinstalled in their dev images.
>>
>
> I was thinking about deployment times more than anything else. If you
> don't feel your user's pain, you're less likely to make it go away. But
> anyway, that can be fixed with automation as well (CI, as you say below).
>

​I agree there is a risk here. In my specific case, I judge the benefits to
outweigh the costs, by quite some margin.

But that judgment is specific to my use case, where layer-basic and IS'
basenode add significant package churn on every node[1] (increasing the
benefit), and we have a full mojo-based CI pipeline for bundle changes
(lowering the cost).

On a different tack all together, I think that reducing iteration time for
charm development is a *massive* win for users. Faster iterations mean
faster feature development and bug fixes, and more comprehensive testing
(as it costs less). I would estimate that iteration improvement would
outweigh the increased risk from a missing pre-installed package, but YMMV.


​[1] ok, so not every charm we deploy is layer based, but they are heading
that way...


Don't HIDE something that helps developers for fear of those developers
>> making mistakes, TEACH them to put CI or other out-of-band tests in place
>> anyway that will catch that every time.
>>
>
> FWIW, it wasn't intentionally hidden to start with, it was just missed. I
> made the changes primarily to support an external user who wanted to demo
> CentOS charms on LXD; the change also enabled custom images in general, and
> also slightly improved container startup time. Three birds, one stone; only
> one bird-hitting was reported ;)
>


​This is hugely appreciated. I reckon 95% of my deployments in the average
week are to lxd, so improvements to the lxd provider affect my velocity
considerably.

Thanks

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

Bug tracking for the OpenStack Charms

[James Page]

Hi All

As of yesterdays OpenStack charm release, we'll be tracking bugs for these
charms under the OpenStack Charms project group:

  https://launchpad.net/openstack-charms

rather than as part of the charms distro on Launchpad; each charm now has
its own project, which is part of the group so we can still report/query
collectively across the charm set for bugs and milestones.

All existing open bugs where migrated by raising a new Bug tasks on the new
project, and marking the old tasks under the Juju Charm Collection as
Invalid - so don't worry nothing got lost in the migration!

Cheers

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

Re: Juju 2.1.0, and Conjure-up, are here!

[Andrew Wilkins]

On Fri, Feb 24, 2017 at 6:51 PM Mark Shuttleworth  wrote:

> On 24/02/17 11:30, Andrew Wilkins wrote:
>
> On Fri, Feb 24, 2017 at 6:15 PM Adam Collard 
> wrote:
>
> On Fri, 24 Feb 2017 at 10:07 Adam Israel 
> wrote:
>
> Thanks for calling this out, Simon! We should be shouting this from the
> rooftops and celebrating in the streets.
>
>
> Only if you also wave a big WARNING banner!
>
> I can definitely see value in pre-installing a bunch of things in your LXD
> images as a way of speeding up the development/testing cycle, but doing so
> might give you false confidence in your charm. It will become much easier
> to forget to list a package that you need installing,  or to ensure that
> you have the correct access (PPA credentials, or proxy details etc.) and
> having your charm gracefully handle when those are missing.
>
> Juju promises charms encoding operations that can work across multiple
> cloud providers, bare metal and containers please keep that in mind :)
>
>
> Indeed, and this is the reason why it wasn't called out. We probably
> should document it for power-users/charmers, but in general I wouldn't go
> encouraging its use. Optimising for LXD is great for repeat deploys, but it
> wouldn't be great if that leads to less attention to quality on the rest of
> the providers.
>
> Anyway, I'm glad it's helping make charmers' lives easier!
>
>
> We should call this out loudly because it helps people making charms.
>
> Those people are plenty smart enough to debug a failure if they forget a
> dependency which was preinstalled in their dev images.
>

I was thinking about deployment times more than anything else. If you don't
feel your user's pain, you're less likely to make it go away. But anyway,
that can be fixed with automation as well (CI, as you say below).


> Don't HIDE something that helps developers for fear of those developers
> making mistakes, TEACH them to put CI or other out-of-band tests in place
> anyway that will catch that every time.
>

FWIW, it wasn't intentionally hidden to start with, it was just missed. I
made the changes primarily to support an external user who wanted to demo
CentOS charms on LXD; the change also enabled custom images in general, and
also slightly improved container startup time. Three birds, one stone; only
one bird-hitting was reported ;)

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

Re: Juju 2.1.0, and Conjure-up, are here!

[Andrew Wilkins]

On Fri, Feb 24, 2017 at 6:51 PM Mark Shuttleworth  wrote:

> On 24/02/17 11:30, Andrew Wilkins wrote:
>
> On Fri, Feb 24, 2017 at 6:15 PM Adam Collard 
> wrote:
>
> On Fri, 24 Feb 2017 at 10:07 Adam Israel 
> wrote:
>
> Thanks for calling this out, Simon! We should be shouting this from the
> rooftops and celebrating in the streets.
>
>
> Only if you also wave a big WARNING banner!
>
> I can definitely see value in pre-installing a bunch of things in your LXD
> images as a way of speeding up the development/testing cycle, but doing so
> might give you false confidence in your charm. It will become much easier
> to forget to list a package that you need installing,  or to ensure that
> you have the correct access (PPA credentials, or proxy details etc.) and
> having your charm gracefully handle when those are missing.
>
> Juju promises charms encoding operations that can work across multiple
> cloud providers, bare metal and containers please keep that in mind :)
>
>
> Indeed, and this is the reason why it wasn't called out. We probably
> should document it for power-users/charmers, but in general I wouldn't go
> encouraging its use. Optimising for LXD is great for repeat deploys, but it
> wouldn't be great if that leads to less attention to quality on the rest of
> the providers.
>
> Anyway, I'm glad it's helping make charmers' lives easier!
>
>
> We should call this out loudly because it helps people making charms.
>
> Those people are plenty smart enough to debug a failure if they forget a
> dependency which was preinstalled in their dev images.
>

I was thinking about deployment times more than anything else. If you don't
feel your user's pain, you're less likely to make it go away. But anyway,
that can be fixed with automation as well (CI, as you say below).


> Don't HIDE something that helps developers for fear of those developers
> making mistakes, TEACH them to put CI or other out-of-band tests in place
> anyway that will catch that every time.
>

FWIW, it wasn't intentionally hidden to start with, it was just missed. I
made the changes primarily to support an external user who wanted to demo
CentOS charms on LXD; the change also enabled custom images in general, and
also slightly improved container startup time. Three birds, one stone; only
one bird-hitting was reported ;)

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

Re: Juju 2.1.0, and Conjure-up, are here!

[Mark Shuttleworth]

On 24/02/17 11:30, Andrew Wilkins wrote:
> On Fri, Feb 24, 2017 at 6:15 PM Adam Collard
> > wrote:
>
> On Fri, 24 Feb 2017 at 10:07 Adam Israel
> > wrote:
>
> Thanks for calling this out, Simon! We should be shouting this
> from the rooftops and celebrating in the streets.
>
>
> Only if you also wave a big WARNING banner!
>
> I can definitely see value in pre-installing a bunch of things in
> your LXD images as a way of speeding up the development/testing
> cycle, but doing so might give you false confidence in your charm.
> It will become much easier to forget to list a package that you
> need installing,  or to ensure that you have the correct access
> (PPA credentials, or proxy details etc.) and having your charm
> gracefully handle when those are missing.
>
> Juju promises charms encoding operations that can work across
> multiple cloud providers, bare metal and containers please keep
> that in mind :)
>
>
> Indeed, and this is the reason why it wasn't called out. We probably
> should document it for power-users/charmers, but in general I wouldn't
> go encouraging its use. Optimising for LXD is great for repeat
> deploys, but it wouldn't be great if that leads to less attention to
> quality on the rest of the providers.
>  
> Anyway, I'm glad it's helping make charmers' lives easier!

We should call this out loudly because it helps people making charms.

Those people are plenty smart enough to debug a failure if they forget a
dependency which was preinstalled in their dev images.

Don't HIDE something that helps developers for fear of those developers
making mistakes, TEACH them to put CI or other out-of-band tests in
place anyway that will catch that every time.

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

Re: Juju 2.1.0, and Conjure-up, are here!

[Mark Shuttleworth]

On 24/02/17 11:30, Andrew Wilkins wrote:
> On Fri, Feb 24, 2017 at 6:15 PM Adam Collard
> > wrote:
>
> On Fri, 24 Feb 2017 at 10:07 Adam Israel
> > wrote:
>
> Thanks for calling this out, Simon! We should be shouting this
> from the rooftops and celebrating in the streets.
>
>
> Only if you also wave a big WARNING banner!
>
> I can definitely see value in pre-installing a bunch of things in
> your LXD images as a way of speeding up the development/testing
> cycle, but doing so might give you false confidence in your charm.
> It will become much easier to forget to list a package that you
> need installing,  or to ensure that you have the correct access
> (PPA credentials, or proxy details etc.) and having your charm
> gracefully handle when those are missing.
>
> Juju promises charms encoding operations that can work across
> multiple cloud providers, bare metal and containers please keep
> that in mind :)
>
>
> Indeed, and this is the reason why it wasn't called out. We probably
> should document it for power-users/charmers, but in general I wouldn't
> go encouraging its use. Optimising for LXD is great for repeat
> deploys, but it wouldn't be great if that leads to less attention to
> quality on the rest of the providers.
>  
> Anyway, I'm glad it's helping make charmers' lives easier!

We should call this out loudly because it helps people making charms.

Those people are plenty smart enough to debug a failure if they forget a
dependency which was preinstalled in their dev images.

Don't HIDE something that helps developers for fear of those developers
making mistakes, TEACH them to put CI or other out-of-band tests in
place anyway that will catch that every time.

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

Re: Juju 2.1.0, and Conjure-up, are here!

[Andrew Wilkins]

On Fri, Feb 24, 2017 at 6:15 PM Adam Collard 
wrote:

> On Fri, 24 Feb 2017 at 10:07 Adam Israel 
> wrote:
>
> Thanks for calling this out, Simon! We should be shouting this from the
> rooftops and celebrating in the streets.
>
>
> Only if you also wave a big WARNING banner!
>
> I can definitely see value in pre-installing a bunch of things in your LXD
> images as a way of speeding up the development/testing cycle, but doing so
> might give you false confidence in your charm. It will become much easier
> to forget to list a package that you need installing,  or to ensure that
> you have the correct access (PPA credentials, or proxy details etc.) and
> having your charm gracefully handle when those are missing.
>
> Juju promises charms encoding operations that can work across multiple
> cloud providers, bare metal and containers please keep that in mind :)
>

Indeed, and this is the reason why it wasn't called out. We probably should
document it for power-users/charmers, but in general I wouldn't go
encouraging its use. Optimising for LXD is great for repeat deploys, but it
wouldn't be great if that leads to less attention to quality on the rest of
the providers.

Anyway, I'm glad it's helping make charmers' lives easier!

Cheers,
Andrew


> On Fri, Feb 24, 2017 at 8:42 AM Stuart Bishop 
> wrote:
>
> On 23 February 2017 at 23:20, Simon Davy  wrote:
>
> > One thing that seems to have landed in 2.1, which is worth noting IMO, is
> > the local juju lxd image aliases.
> >
> > tl;dr: juju 2.1 now looks for the lxd image alias juju/$series/$arch in
> the
> > local lxd server, and uses that if it finds it.
> >
> > This is amazing. I can now build a local nightly image[1] that
> pre-installs
> > and pre-downloads a whole set of packages[2], and my local lxd units
> don't
> > have to install them when they spin up. Between layer-basic and Canonical
> > IS' basenode, for us that's about 111 packages that I don't need to
> install
> > on every machine in my 10 node bundle. Took my install hook times from
> 5min+
> > each to <1min, and probably halfs my initial deploy time, on average.
>
> Ooh, thanks for highlighting this! I've needed this feature for a long
> time for exactly the same reasons.
>
>
> > [2] my current nightly cron:
> > https://gist.github.com/bloodearnest/3474741411c4fdd6c2bb64d08dc75040
>
> /me starts stealing
>
> --
> Stuart Bishop 
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
> --
> Adam Israel, Software Engineer
> Canonical // Cloud DevOps // Juju // Ecosystem
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju 2.1.0, and Conjure-up, are here!

[Andrew Wilkins]

On Fri, Feb 24, 2017 at 6:15 PM Adam Collard 
wrote:

> On Fri, 24 Feb 2017 at 10:07 Adam Israel 
> wrote:
>
> Thanks for calling this out, Simon! We should be shouting this from the
> rooftops and celebrating in the streets.
>
>
> Only if you also wave a big WARNING banner!
>
> I can definitely see value in pre-installing a bunch of things in your LXD
> images as a way of speeding up the development/testing cycle, but doing so
> might give you false confidence in your charm. It will become much easier
> to forget to list a package that you need installing,  or to ensure that
> you have the correct access (PPA credentials, or proxy details etc.) and
> having your charm gracefully handle when those are missing.
>
> Juju promises charms encoding operations that can work across multiple
> cloud providers, bare metal and containers please keep that in mind :)
>

Indeed, and this is the reason why it wasn't called out. We probably should
document it for power-users/charmers, but in general I wouldn't go
encouraging its use. Optimising for LXD is great for repeat deploys, but it
wouldn't be great if that leads to less attention to quality on the rest of
the providers.

Anyway, I'm glad it's helping make charmers' lives easier!

Cheers,
Andrew


> On Fri, Feb 24, 2017 at 8:42 AM Stuart Bishop 
> wrote:
>
> On 23 February 2017 at 23:20, Simon Davy  wrote:
>
> > One thing that seems to have landed in 2.1, which is worth noting IMO, is
> > the local juju lxd image aliases.
> >
> > tl;dr: juju 2.1 now looks for the lxd image alias juju/$series/$arch in
> the
> > local lxd server, and uses that if it finds it.
> >
> > This is amazing. I can now build a local nightly image[1] that
> pre-installs
> > and pre-downloads a whole set of packages[2], and my local lxd units
> don't
> > have to install them when they spin up. Between layer-basic and Canonical
> > IS' basenode, for us that's about 111 packages that I don't need to
> install
> > on every machine in my 10 node bundle. Took my install hook times from
> 5min+
> > each to <1min, and probably halfs my initial deploy time, on average.
>
> Ooh, thanks for highlighting this! I've needed this feature for a long
> time for exactly the same reasons.
>
>
> > [2] my current nightly cron:
> > https://gist.github.com/bloodearnest/3474741411c4fdd6c2bb64d08dc75040
>
> /me starts stealing
>
> --
> Stuart Bishop 
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
> --
> Adam Israel, Software Engineer
> Canonical // Cloud DevOps // Juju // Ecosystem
> --
> 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
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Juju 2.1.0, and Conjure-up, are here!

[Adam Collard]

On Fri, 24 Feb 2017 at 10:07 Adam Israel  wrote:

> Thanks for calling this out, Simon! We should be shouting this from the
> rooftops and celebrating in the streets.
>

Only if you also wave a big WARNING banner!

I can definitely see value in pre-installing a bunch of things in your LXD
images as a way of speeding up the development/testing cycle, but doing so
might give you false confidence in your charm. It will become much easier
to forget to list a package that you need installing,  or to ensure that
you have the correct access (PPA credentials, or proxy details etc.) and
having your charm gracefully handle when those are missing.

Juju promises charms encoding operations that can work across multiple
cloud providers, bare metal and containers please keep that in mind :)


> On Fri, Feb 24, 2017 at 8:42 AM Stuart Bishop 
> wrote:
>
> On 23 February 2017 at 23:20, Simon Davy  wrote:
>
> > One thing that seems to have landed in 2.1, which is worth noting IMO, is
> > the local juju lxd image aliases.
> >
> > tl;dr: juju 2.1 now looks for the lxd image alias juju/$series/$arch in
> the
> > local lxd server, and uses that if it finds it.
> >
> > This is amazing. I can now build a local nightly image[1] that
> pre-installs
> > and pre-downloads a whole set of packages[2], and my local lxd units
> don't
> > have to install them when they spin up. Between layer-basic and Canonical
> > IS' basenode, for us that's about 111 packages that I don't need to
> install
> > on every machine in my 10 node bundle. Took my install hook times from
> 5min+
> > each to <1min, and probably halfs my initial deploy time, on average.
>
> Ooh, thanks for highlighting this! I've needed this feature for a long
> time for exactly the same reasons.
>
>
> > [2] my current nightly cron:
> > https://gist.github.com/bloodearnest/3474741411c4fdd6c2bb64d08dc75040
>
> /me starts stealing
>
> --
> Stuart Bishop 
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
> --
> Adam Israel, Software Engineer
> Canonical // Cloud DevOps // Juju // Ecosystem
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju 2.1.0, and Conjure-up, are here!

[Adam Collard]

On Fri, 24 Feb 2017 at 10:07 Adam Israel  wrote:

> Thanks for calling this out, Simon! We should be shouting this from the
> rooftops and celebrating in the streets.
>

Only if you also wave a big WARNING banner!

I can definitely see value in pre-installing a bunch of things in your LXD
images as a way of speeding up the development/testing cycle, but doing so
might give you false confidence in your charm. It will become much easier
to forget to list a package that you need installing,  or to ensure that
you have the correct access (PPA credentials, or proxy details etc.) and
having your charm gracefully handle when those are missing.

Juju promises charms encoding operations that can work across multiple
cloud providers, bare metal and containers please keep that in mind :)


> On Fri, Feb 24, 2017 at 8:42 AM Stuart Bishop 
> wrote:
>
> On 23 February 2017 at 23:20, Simon Davy  wrote:
>
> > One thing that seems to have landed in 2.1, which is worth noting IMO, is
> > the local juju lxd image aliases.
> >
> > tl;dr: juju 2.1 now looks for the lxd image alias juju/$series/$arch in
> the
> > local lxd server, and uses that if it finds it.
> >
> > This is amazing. I can now build a local nightly image[1] that
> pre-installs
> > and pre-downloads a whole set of packages[2], and my local lxd units
> don't
> > have to install them when they spin up. Between layer-basic and Canonical
> > IS' basenode, for us that's about 111 packages that I don't need to
> install
> > on every machine in my 10 node bundle. Took my install hook times from
> 5min+
> > each to <1min, and probably halfs my initial deploy time, on average.
>
> Ooh, thanks for highlighting this! I've needed this feature for a long
> time for exactly the same reasons.
>
>
> > [2] my current nightly cron:
> > https://gist.github.com/bloodearnest/3474741411c4fdd6c2bb64d08dc75040
>
> /me starts stealing
>
> --
> Stuart Bishop 
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
> --
> Adam Israel, Software Engineer
> Canonical // Cloud DevOps // Juju // Ecosystem
> --
> 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: Juju 2.1.0, and Conjure-up, are here!

[Adam Israel]

Thanks for calling this out, Simon! We should be shouting this from the
rooftops and celebrating in the streets.

On Fri, Feb 24, 2017 at 8:42 AM Stuart Bishop 
wrote:

> On 23 February 2017 at 23:20, Simon Davy  wrote:
>
> > One thing that seems to have landed in 2.1, which is worth noting IMO, is
> > the local juju lxd image aliases.
> >
> > tl;dr: juju 2.1 now looks for the lxd image alias juju/$series/$arch in
> the
> > local lxd server, and uses that if it finds it.
> >
> > This is amazing. I can now build a local nightly image[1] that
> pre-installs
> > and pre-downloads a whole set of packages[2], and my local lxd units
> don't
> > have to install them when they spin up. Between layer-basic and Canonical
> > IS' basenode, for us that's about 111 packages that I don't need to
> install
> > on every machine in my 10 node bundle. Took my install hook times from
> 5min+
> > each to <1min, and probably halfs my initial deploy time, on average.
>
> Ooh, thanks for highlighting this! I've needed this feature for a long
> time for exactly the same reasons.
>
>
> > [2] my current nightly cron:
> > https://gist.github.com/bloodearnest/3474741411c4fdd6c2bb64d08dc75040
>
> /me starts stealing
>
> --
> Stuart Bishop 
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Adam Israel, Software Engineer
Canonical // Cloud DevOps // Juju // Ecosystem
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju 2.1.0, and Conjure-up, are here!

[Adam Israel]

Thanks for calling this out, Simon! We should be shouting this from the
rooftops and celebrating in the streets.

On Fri, Feb 24, 2017 at 8:42 AM Stuart Bishop 
wrote:

> On 23 February 2017 at 23:20, Simon Davy  wrote:
>
> > One thing that seems to have landed in 2.1, which is worth noting IMO, is
> > the local juju lxd image aliases.
> >
> > tl;dr: juju 2.1 now looks for the lxd image alias juju/$series/$arch in
> the
> > local lxd server, and uses that if it finds it.
> >
> > This is amazing. I can now build a local nightly image[1] that
> pre-installs
> > and pre-downloads a whole set of packages[2], and my local lxd units
> don't
> > have to install them when they spin up. Between layer-basic and Canonical
> > IS' basenode, for us that's about 111 packages that I don't need to
> install
> > on every machine in my 10 node bundle. Took my install hook times from
> 5min+
> > each to <1min, and probably halfs my initial deploy time, on average.
>
> Ooh, thanks for highlighting this! I've needed this feature for a long
> time for exactly the same reasons.
>
>
> > [2] my current nightly cron:
> > https://gist.github.com/bloodearnest/3474741411c4fdd6c2bb64d08dc75040
>
> /me starts stealing
>
> --
> Stuart Bishop 
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Adam Israel, Software Engineer
Canonical // Cloud DevOps // Juju // Ecosystem
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: regression: restore-backup broken by recent commit

[John Meinel]

Is it possible for us to close more gracefully most of the time?

John
=:->

On Feb 24, 2017 08:27, "Tim Penhey"  wrote:

> OK, I think I got it now...
>
> This is all crazy, and it was a change due to the  gorilla/websocket
> change.
>
> So... what happens when there is a successful restore on the server side
> is that it calls os.Exit(...) which then has the pid 1 restart the agent.
> However from the API client, this is an abnormal closure.
>
> In the rpc layer, I capture a number of websocket close errors as
> "normal", but I missed the Abnormal closure case, which is 1006.
>
> I'll update, and repropose to devel.
>
> Hazaah.
>
> Tim
>
>
>
> On 24/02/17 16:17, Tim Penhey wrote:
>
>> Hi Curtis (also expanding to juju-dev),
>>
>> I have been looking into this issue. And the good news is that it
>> doesn't appear to be a real problem with gorilla/websocket at all, but
>> instead a change in timing showed an existing issue that hadn't surfaced
>> before.
>>
>> I'll be looking into that issue - where the restore command after
>> bootstrapping, doesn't appear to retry if it gets an error like "denied:
>> upgrade in progress".
>>
>> Secondly I tried to reproduce on lxd to find that there is an issue with
>> the rebootstrap and lxd - it just doesn't work.
>>
>> Then I tried with AWS, to mirror the CI test as close as possible. I
>> didn't hit the same timing issue as before, but instead got a different
>> failure with the mongo restore:
>>
>>   http://pastebin.ubuntu.com/24056766/
>>
>> I have no idea why juju.txns.stash failed but juju.txns and
>> juju.txns.logs succeeded.
>>
>> Also, a CI run of a develop revision just before the gorilla/websocket
>> reversion hit this:
>>
>> http://reports.vapour.ws/releases/4922/job/functional-ha-
>> backup-restore/attempt/5045#highlight
>>
>>
>> cannot create collection "txns": unauthorized mongo access: not
>> authorized on juju to execute command { create: "txns" }
>> (unauthorized access)
>>
>> Not sure why that is happening either. Seems that the restore of mongo
>> is incredibly fragile.
>>
>> Again, this shows errors in the restore code, but luckily it has nothing
>> to do with gorilla/websockets.
>>
>> Tim
>>
>> On 23/02/17 04:02, Curtis Hovey-Canonical wrote:
>>
>>> Hi Tim, et al.
>>>
>>> All the restore-backup tests in all the substrates failed with your
>>> recent gorilla socket commit. The restore-backup command is often
>>> fails when bootstrap or connection behaviours change. This new bug is
>>> definitely a connection failure while the client is driving a
>>> restore.
>>>
>>> We need the develop branch fixed. As the previous commit was blessed,
>>> as are certain 2.2-alpha1 was in very good shape before the gorilla
>>> change.
>>>
>>> Restore backup failed websocket: close 1006
>>> https://bugs.launchpad.net/juju/+bug/1666898
>>>
>>> As seen at
>>> http://reports.vapour.ws/releases/issue/5550dda7749a561097cf3d44
>>>
>>> All the restore-backup tests failed when testing commit
>>> https://github.com/juju/juju/commit/f06c3e96f4e438dc24a28d8e
>>> bf7d22c76fff47e2
>>>
>>>
>>> We see
>>> Initial model "default" added.
>>> 04:54:39 INFO juju.juju api.go:72 connecting to API addresses:
>>> [52.201.105.25:17070 172.31.15.167:17070]
>>> 04:54:39 INFO juju.api apiclient.go:569 connection established to
>>> "wss://52.201.105.25:17070/model/89bcc17c-9af9-4113-8417-718
>>> 47838f61a/api"
>>>
>>> ...
>>> 04:55:20 ERROR juju.api.backups restore.go:136 could not clean up
>>> after failed restore attempt: 
>>> 04:55:20 ERROR cmd supercommand.go:458 cannot perform restore: :
>>> codec.ReadHeader error: error receiving message: websocket: close 1006
>>> (abnormal closure): unexpected EOF
>>>
>>> This is seen in aws, prodstack, gce
>>>
>>>
>>>
>>>
>>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/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