Re: database-relation-join not invoked
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
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
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
Re: database-relation-join not invoked
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
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
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
+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
+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
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
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
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
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