Re: database-relation-join not invoked

[John Meinel]

It depends if your hook goes into 'error' state or 'blocked'.
Error should generally be avoided because it is a signal to Juju that you
can no longer make forward progress (generally meant to mean there is a
logic bug/typo/etc in your charm). With Error Juju may retry the hook that
failed but it will not run other hooks until error is cleared (juju
resolved)

Using 'status-set blocked [message]' you can report to the user that you
are missing a relation, but Juju will continue to fire other hooks as
normal.

John
=:->

On May 25, 2017 21:00, "Giuseppe Attardi"  wrote:

> I have written a charm for OpenStack Gnocchi.
> The service requires a postgresql database relation.
>
> The start hook fails, of course, because the relation is not set.
>
> I expected that, but I expected that when I issue
>
> juju add-relation gnocchi postgresql:db
>
> it will invoke the database-relation-joined hook, which does set the
> required parameter and then start would work.
> However the hook is not invoked: as a sanity check I set a juju-log
> message in it and it does not run at all.
>
> Is it correct to assume that add-relation will always trigger
> database-relation-join?
>
> A second question, I would like to avoid to start the service until the
> relation has been joined.
> What is the best way to test for the relation to be present?
>
> I tried with
>
> db=`relation-get -r database host`
>
> but it fails with:
>
> INFO start error: invalid value "database" for flag -r: invalid
> relation id
>
> I am using juju-2.1.2
>
> Thanks for the help.
>
> — Beppe Attardi
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Call for testers: preview of persistent storage support

[Andrew Wilkins]

On Fri, May 26, 2017 at 11:26 AM Patrizio Bassi 
wrote:

> Dear Andrew,
>  what about private clouds such as maas?
>

MAAS is a bit special, because the disks are physically attached to the
machines. If and when we support something like Ceph RBD natively inside
Juju, then that could be detached from one machine and attached to another.

The new storage commands should work with private OpenStack clouds.

Cheers,
Andrew


> Patrizio
>
> Il giorno mer 24 ma 2017 alle 03:38 Andrew Wilkins <
> andrew.wilk...@canonical.com> ha scritto:
>
>> Hi folks,
>>
>> One of the things we're working on for the 2.3 release (not 2.2!) is
>> persistent storage. What this means is the ability to detach storage from a
>> unit, and reattach it to another unit keeping the storage contents intact.
>> We would like to get some feedback before this all gets set in stone.
>>
>> With the changes, removing an application unit will detach storage rather
>> than destroy it as Juju currently does. The storage will then be available
>> for attaching to another unit using "juju attach-storage  "
>> or to a new application unit using "juju deploy  --attach-storage
>> "; or for removal using "juju remove-storage ".
>>
>> For example, I can deploy postgresql on AWS with EBS storage. If I remove
>> the postgresql application, I can add another and attach the storage to it:
>>
>> $ juju deploy postgresql --storage pgdata=100G,ebs
>> Located charm "cs:postgresql-148".
>> Deploying charm "cs:postgresql-148".
>> (wait for postgresql/0 to become active)
>>
>> $ juju remove-application postgresql
>> removing application postgresql
>> - will detach storage pgdata/0
>> (wait for postgresql/0 and machine 0 to be removed)
>>
>> $ juju deploy postgresql postgresql2 --attach-storage pgdata/0 --to
>> zone=
>> Located charm "cs:postgresql-148".
>> Deploying charm "cs:postgresql-148".
>> (wait for postgresql2/0 to become active)
>>
>> If you like, you can confirm for yourself that the data is persisted by
>> logging into the first machine and runing "sudo -u postgres psql", creating
>> some data, and then checking that it is still there from the second machine.
>>
>> (The --to zone=... is required due to a limitation that we will remove by
>> the time 2.3 is released. EBS volumes and EC2 instances must be created in
>> the same AZ, and that's not automatic yet. This is fixed by
>> https://github.com/juju/juju/pull/7378 which, at the time of writing
>> this email, has not yet been merged.)
>>
>> If you have any interest in these changes, please help us make them great
>> by testing out this early release:
>>
>> $ sudo snap install --channel=edge --classic juju-axw
>> $ /snap/bin/juju-axw.juju bootstrap ...
>>
>> The new/updated commands are:
>>  - juju attach-storage  
>>  - juju detach-storage 
>>  - juju remove-storage 
>>  - juju deploy  --attach-storage 
>>
>> (We'll also be adding --attach-storage to the "juju add-unit" command
>> soon.)
>>
>> Thank you!
>>
>> Cheers,
>> Andrew
>> --
>> Juju mailing list
>> j...@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
> --
>
> Patrizio Bassi
> www.patriziobassi.it
> http://piazzadelpopolo.patriziobassi.it
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Call for testers: preview of persistent storage support

[Andrew Wilkins]

On Fri, May 26, 2017 at 11:26 AM Patrizio Bassi 
wrote:

> Dear Andrew,
>  what about private clouds such as maas?
>

MAAS is a bit special, because the disks are physically attached to the
machines. If and when we support something like Ceph RBD natively inside
Juju, then that could be detached from one machine and attached to another.

The new storage commands should work with private OpenStack clouds.

Cheers,
Andrew


> Patrizio
>
> Il giorno mer 24 ma 2017 alle 03:38 Andrew Wilkins <
> andrew.wilk...@canonical.com> ha scritto:
>
>> Hi folks,
>>
>> One of the things we're working on for the 2.3 release (not 2.2!) is
>> persistent storage. What this means is the ability to detach storage from a
>> unit, and reattach it to another unit keeping the storage contents intact.
>> We would like to get some feedback before this all gets set in stone.
>>
>> With the changes, removing an application unit will detach storage rather
>> than destroy it as Juju currently does. The storage will then be available
>> for attaching to another unit using "juju attach-storage  "
>> or to a new application unit using "juju deploy  --attach-storage
>> "; or for removal using "juju remove-storage ".
>>
>> For example, I can deploy postgresql on AWS with EBS storage. If I remove
>> the postgresql application, I can add another and attach the storage to it:
>>
>> $ juju deploy postgresql --storage pgdata=100G,ebs
>> Located charm "cs:postgresql-148".
>> Deploying charm "cs:postgresql-148".
>> (wait for postgresql/0 to become active)
>>
>> $ juju remove-application postgresql
>> removing application postgresql
>> - will detach storage pgdata/0
>> (wait for postgresql/0 and machine 0 to be removed)
>>
>> $ juju deploy postgresql postgresql2 --attach-storage pgdata/0 --to
>> zone=
>> Located charm "cs:postgresql-148".
>> Deploying charm "cs:postgresql-148".
>> (wait for postgresql2/0 to become active)
>>
>> If you like, you can confirm for yourself that the data is persisted by
>> logging into the first machine and runing "sudo -u postgres psql", creating
>> some data, and then checking that it is still there from the second machine.
>>
>> (The --to zone=... is required due to a limitation that we will remove by
>> the time 2.3 is released. EBS volumes and EC2 instances must be created in
>> the same AZ, and that's not automatic yet. This is fixed by
>> https://github.com/juju/juju/pull/7378 which, at the time of writing
>> this email, has not yet been merged.)
>>
>> If you have any interest in these changes, please help us make them great
>> by testing out this early release:
>>
>> $ sudo snap install --channel=edge --classic juju-axw
>> $ /snap/bin/juju-axw.juju bootstrap ...
>>
>> The new/updated commands are:
>>  - juju attach-storage  
>>  - juju detach-storage 
>>  - juju remove-storage 
>>  - juju deploy  --attach-storage 
>>
>> (We'll also be adding --attach-storage to the "juju add-unit" command
>> soon.)
>>
>> Thank you!
>>
>> Cheers,
>> Andrew
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
> --
>
> Patrizio Bassi
> www.patriziobassi.it
> http://piazzadelpopolo.patriziobassi.it
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Call for testers: preview of persistent storage support

[Patrizio Bassi]

Dear Andrew,
 what about private clouds such as maas?

Patrizio

Il giorno mer 24 ma 2017 alle 03:38 Andrew Wilkins <
andrew.wilk...@canonical.com> ha scritto:

> Hi folks,
>
> One of the things we're working on for the 2.3 release (not 2.2!) is
> persistent storage. What this means is the ability to detach storage from a
> unit, and reattach it to another unit keeping the storage contents intact.
> We would like to get some feedback before this all gets set in stone.
>
> With the changes, removing an application unit will detach storage rather
> than destroy it as Juju currently does. The storage will then be available
> for attaching to another unit using "juju attach-storage  "
> or to a new application unit using "juju deploy  --attach-storage
> "; or for removal using "juju remove-storage ".
>
> For example, I can deploy postgresql on AWS with EBS storage. If I remove
> the postgresql application, I can add another and attach the storage to it:
>
> $ juju deploy postgresql --storage pgdata=100G,ebs
> Located charm "cs:postgresql-148".
> Deploying charm "cs:postgresql-148".
> (wait for postgresql/0 to become active)
>
> $ juju remove-application postgresql
> removing application postgresql
> - will detach storage pgdata/0
> (wait for postgresql/0 and machine 0 to be removed)
>
> $ juju deploy postgresql postgresql2 --attach-storage pgdata/0 --to
> zone=
> Located charm "cs:postgresql-148".
> Deploying charm "cs:postgresql-148".
> (wait for postgresql2/0 to become active)
>
> If you like, you can confirm for yourself that the data is persisted by
> logging into the first machine and runing "sudo -u postgres psql", creating
> some data, and then checking that it is still there from the second machine.
>
> (The --to zone=... is required due to a limitation that we will remove by
> the time 2.3 is released. EBS volumes and EC2 instances must be created in
> the same AZ, and that's not automatic yet. This is fixed by
> https://github.com/juju/juju/pull/7378 which, at the time of writing this
> email, has not yet been merged.)
>
> If you have any interest in these changes, please help us make them great
> by testing out this early release:
>
> $ sudo snap install --channel=edge --classic juju-axw
> $ /snap/bin/juju-axw.juju bootstrap ...
>
> The new/updated commands are:
>  - juju attach-storage  
>  - juju detach-storage 
>  - juju remove-storage 
>  - juju deploy  --attach-storage 
>
> (We'll also be adding --attach-storage to the "juju add-unit" command
> soon.)
>
> Thank you!
>
> Cheers,
> Andrew
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 

Patrizio Bassi
www.patriziobassi.it
http://piazzadelpopolo.patriziobassi.it
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Weekly Development Summary

[Andrew Wilkins]

Hi all,

It's been a busy week as we continue towards the 2.2-rc1 release. As Tim
said earlier in the week, the release will slip to next week as we continue
ironing out the kinks. One of the main things we've been focusing on this
week is improving scalability and resilience in large deployments, such as
JAAS.

One major issue [0] fixed is that if we overflow the transaction log
collection in Mongo, the controller will now automatically restart to get
all of the watchers back into the appropriate state. A new controller
config attribute, "max-txn-log-size", has been introduced, which allows you
to change the transaction log collection size from the default of 10MB.

Another critical fix is to prevent resource-get from blocking indefinitely
when fetching the resource fails [1]. Juju will now retry fetching
resources for a set number of attempts, and then abort if it continues to
fail, giving the operator a chance to fix the charm resources or charm code
itself.

Work is underway to run one log forwarding worker per model, instead of one
per controller as we have now. This will enable us to optimise the way in
which logs are managed, to improve scalability and performance. Having
per-model log forwarders will also enable future improvements to support
forwarding logs to cloud-specific logging facilities.

A handful of other notable fixes:
 - better validation of custom simplestreams metadata [2]
 - simplified mongo oplog size calculation, to prevent frequent mongo
restarts [3]
 - fixed an issue with add-storage, where the specified pool was not used
in some cases [4]
 - several fixes [5] [6] for model migration related to resources

Last week, Ian mentioned that there would be a snap forthcoming containing
a preview of storage improvements scheduled for the 2.3 release. This was
sent out earlier this week, and we're waiting for feedback. If you have a
moment, please try it out and let us know what you think. Next week we'll
aim to release an update to the snap, with the next bits: adding
--attach-storage to add-unit, and automatically placing VMs in the same AZ
as the attached volumes (at least for AWS).

Thanks for reading!

Cheers,
Andrew

---

Quick links:
  Work Pending: https://github.com/juju/juju/pulls
  Recent commits: https://github.com/juju/juju/commits/develop

[0] https://bugs.launchpad.net/juju/+bug/1692792
[1] https://bugs.launchpad.net/juju/+bug/1627127
[2] https://bugs.launchpad.net/juju/+bug/1690456
[3] https://bugs.launchpad.net/juju/+bug/1677592
[4] https://bugs.launchpad.net/juju/+bug/1692729
[5] https://bugs.launchpad.net/juju/+bug/1692610
[6] https://bugs.launchpad.net/juju/+bug/1692646
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: database-relation-join not invoked

[Tim Van Steenburgh]

On Thu, May 25, 2017 at 12:59 PM, Giuseppe Attardi  wrote:

> I have written a charm for OpenStack Gnocchi.
> The service requires a postgresql database relation.
>
> The start hook fails, of course, because the relation is not set.
>
> I expected that, but I expected that when I issue
>
> juju add-relation gnocchi postgresql:db
>
> it will invoke the database-relation-joined hook, which does set the
> required parameter and then start would work.
> However the hook is not invoked: as a sanity check I set a juju-log
> message in it and it does not run at all.
>
> Is it correct to assume that add-relation will always trigger
> database-relation-join?
>

Yes it will. Assuming your relation is named 'database', then the
database-relation-joined will be triggered when that relation is
established. For more help debugging you may need to post a link to your
code.


> A second question, I would like to avoid to start the service until the
> relation has been joined.
> What is the best way to test for the relation to be present?
>

You should start the service in the database-relation-changed hook handler,
once you have received all necessary relation data.


>
> I tried with
>
> db=`relation-get -r database host`
>
> but it fails with:
>
> INFO start error: invalid value "database" for flag -r: invalid
> relation id
>
> I am using juju-2.1.2
>
> Thanks for the help.
>
> — Beppe Attardi
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

database-relation-join not invoked

[Giuseppe Attardi]

I have written a charm for OpenStack Gnocchi.
The service requires a postgresql database relation.

The start hook fails, of course, because the relation is not set.

I expected that, but I expected that when I issue

juju add-relation gnocchi postgresql:db

it will invoke the database-relation-joined hook, which does set the required 
parameter and then start would work.
However the hook is not invoked: as a sanity check I set a juju-log message in 
it and it does not run at all.

Is it correct to assume that add-relation will always trigger 
database-relation-join?

A second question, I would like to avoid to start the service until the 
relation has been joined.
What is the best way to test for the relation to be present?

I tried with

db=`relation-get -r database host`

but it fails with:

INFO start error: invalid value "database" for flag -r: invalid 
relation id

I am using juju-2.1.2

Thanks for the help.

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

Re: Migrating charmhelpers to github

[Merlijn Sebrechts]

A big +1!

Launchpad was the reason why I didn't yet contribute to charmhelpers..

2017-05-25 14:57 GMT+02:00 James Page :

> Hi Charmers
>
> There has been a bubbling undercurrent of desire to move charmhelpers code
> hosting out of bazaar on Launchpad to git on github,com alongside other
> charm ecosystem development tooling.
>
> I'd like to get the code migrated over ASAP and then we can start enabling
> automatic PR testing and suchlike which we lack in LP at the moment.
>
> Anyone got any objections?
>
> This will of course impact anyone currently syncing charmhelpers into
> their charm, but that's not a hard problem to solve.
>
> Cheers
>
> James
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Migrating charmhelpers to github

[Charles Butler]

+1 from me as well.

I'll take webhook automation for the win, Alex.

All the best,

Charles

On Thu, May 25, 2017 at 7:58 AM James Page  wrote:

> Hi Charmers
>
> There has been a bubbling undercurrent of desire to move charmhelpers code
> hosting out of bazaar on Launchpad to git on github,com alongside other
> charm ecosystem development tooling.
>
> I'd like to get the code migrated over ASAP and then we can start enabling
> automatic PR testing and suchlike which we lack in LP at the moment.
>
> Anyone got any objections?
>
> This will of course impact anyone currently syncing charmhelpers into
> their charm, but that's not a hard problem to solve.
>
> Cheers
>
> James
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
conjure-up canonical-kubernetes | jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Migrating charmhelpers to github

[Tim Van Steenburgh]

+1 from me, especially since James is volunteering. :D  Thanks for getting
this ball rolling!

On Thu, May 25, 2017 at 8:57 AM, James Page  wrote:

> Hi Charmers
>
> There has been a bubbling undercurrent of desire to move charmhelpers code
> hosting out of bazaar on Launchpad to git on github,com alongside other
> charm ecosystem development tooling.
>
> I'd like to get the code migrated over ASAP and then we can start enabling
> automatic PR testing and suchlike which we lack in LP at the moment.
>
> Anyone got any objections?
>
> This will of course impact anyone currently syncing charmhelpers into
> their charm, but that's not a hard problem to solve.
>
> Cheers
>
> James
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Migrating charmhelpers to github

[Alex Kavanagh]

On Thu, May 25, 2017 at 2:17 PM, Adam Collard 
wrote:

> On Thu, 25 May 2017 at 14:14 Alex Kavanagh 
> wrote:
>
>> Hi James
>>
>> I'm a big +1 to this idea, but with one tiny reservation:  I have a
>> rather large merge-proposal regarding a refactor of the hosts + ports fetch
>> bug + refactor of the fetch code. It would be nice to get that in first
>> (but that's purely personal!)
>>
>> However, we'll lose the history of the project if/when it is moved; can
>> the existing project be 'closed' to new commits, but kept available for
>> history?
>>
>
> Hmm, why will we lose this history?
>
> I assume the plan is to convert history a la
> https://help.launchpad.net/Code/Git#Converting_from_Bazaar_to_Git
>

In that case, reservation withdrawn :)  (didn't know about that feature)

Thanks
Alex.


-- 
Alex Kavanagh - Software Engineer
Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Migrating charmhelpers to github

[Adam Collard]

On Thu, 25 May 2017 at 14:14 Alex Kavanagh 
wrote:

> Hi James
>
> I'm a big +1 to this idea, but with one tiny reservation:  I have a rather
> large merge-proposal regarding a refactor of the hosts + ports fetch bug +
> refactor of the fetch code. It would be nice to get that in first (but
> that's purely personal!)
>
> However, we'll lose the history of the project if/when it is moved; can
> the existing project be 'closed' to new commits, but kept available for
> history?
>

Hmm, why will we lose this history?

I assume the plan is to convert history a la
https://help.launchpad.net/Code/Git#Converting_from_Bazaar_to_Git
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Migrating charmhelpers to github

[Alex Kavanagh]

Hi James

I'm a big +1 to this idea, but with one tiny reservation:  I have a rather
large merge-proposal regarding a refactor of the hosts + ports fetch bug +
refactor of the fetch code. It would be nice to get that in first (but
that's purely personal!)

However, we'll lose the history of the project if/when it is moved; can the
existing project be 'closed' to new commits, but kept available for history?

Cheers
Alex.

On Thu, May 25, 2017 at 1:57 PM, James Page  wrote:

> Hi Charmers
>
> There has been a bubbling undercurrent of desire to move charmhelpers code
> hosting out of bazaar on Launchpad to git on github,com alongside other
> charm ecosystem development tooling.
>
> I'd like to get the code migrated over ASAP and then we can start enabling
> automatic PR testing and suchlike which we lack in LP at the moment.
>
> Anyone got any objections?
>
> This will of course impact anyone currently syncing charmhelpers into
> their charm, but that's not a hard problem to solve.
>
> Cheers
>
> James
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>


-- 
Alex Kavanagh - Software Engineer
Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Migrating charmhelpers to github

[James Page]

Hi Charmers

There has been a bubbling undercurrent of desire to move charmhelpers code
hosting out of bazaar on Launchpad to git on github,com alongside other
charm ecosystem development tooling.

I'd like to get the code migrated over ASAP and then we can start enabling
automatic PR testing and suchlike which we lack in LP at the moment.

Anyone got any objections?

This will of course impact anyone currently syncing charmhelpers into their
charm, but that's not a hard problem to solve.

Cheers

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