Re: Private Icons for a charm.
Is 'icons.svg' a typo? Because it needs to be 'icon.svg' in the charm (top level). Cheers Alex. On Thu, Oct 5, 2017 at 9:24 AM, Merlijn Sebrechts < merlijn.sebrec...@gmail.com> wrote: > bumping since the original was caught in the spam filter > > 2017-10-04 12:36 GMT+02:00 Michael Van Der Beek : > >> Hi All, >> >> >> >> I’ve created custom icons.svg for charms but in the juju gui it doesn’t >> show up. >> >> The url for the icon when I inspect the webpage looks like this. >> >> > filter>/model/f7872e93-5cbf-46dd-814b-2c63031686cd/charms? >> url=local:centos7/radius-27&icon=1 >> >> >> >> If use this url in a browser it works it brings up the icon. But in the >> juju webgui it shows up a generic icon. >> >> Is there a fix for this? >> >> >> >> I am currently starting the charm like this >> >> juju deploy /home/ubuntu/charms/radius --constraints mem=4G >> >> >> >> Regards, >> >> >> >> Michael >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/juju >> >> > > -- > 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
Re: set_state not setting the state immediately
Hi there
On Tue, Oct 3, 2017 at 1:34 PM, Konstantinos Tsakalozos <
kos.tsakalo...@canonical.com> wrote:
> Hi,
>
> It seems the reactive framework is flushing the states at the end of hook
> execution. This may surprise charm authors. Consider the following code:
>
> @when_not("initialized")
> def init():
> must_be_called_exactly_once()
> set_state("initialized")
>
> @when("initialized")
> @when_not("ready")
> def get_ready():
> this_call_fails()
> set_state("ready")
>
> As a charm author I would expect the "initialized" state set right after
> the must_be_called_exactly_once() is called. However, the framework is not
> persisting the "initialized" state at that point, and it moves on to
> trigger the get_ready(). Since this_call_fails() happens on
> the get_ready() method I would expect the "initialized" state to be set
> when the failure is resolved.
>
>
Yup, that can catch you out. As Stuart says, it's because either a hook
competes 'fully' or not at all, and so it rolls back (or rather doesn't
commit) the kv() store. So anything you put in kv() (from
charmhelpers.core.unitdata) also won't get committed. Also, if you flush
kv() yourself you'll mess with charms.reactive.
In this situation, I tend to use a file as a sentinel to flag that I've
really done something only once. Alternatively, one could use
charmhelpers.core.unitdata.Storage() directly and thus flush a separate
Storage() back to the 'disk'.
--
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: charmhelpers migration to github
re Engineer > >>> IRC (freenode): Dmitrii-Sh > >>> > >>> On Thu, Sep 21, 2017 at 12:02 PM, Merlijn Sebrechts < > >>> merlijn.sebrec...@gmail.com> wrote: > >>> > >>>> It depends on what you want to optimize the development workflow for. > I > >>>> think we need to optimize for easiness because a lot of contributors > >> will > >>>> be ops people who generally have a lot less experience with git and > >> github. > >>>> I for example have rebased once in my life, and this was only possible > >> with > >>>> Alex walking me through the process. > >>>> > >>>> *"Fork to private + PR + dirty fix commits" *is an easy workflow that > a > >>>> lot of people are familiar with and that works well with Github. If > you > >>>> want a cleaner commit history, you can always rebase or squash the PR > >>>> during merge using the Github UI: https://pasteboard.co/GLmTHnf.png. > >>>> > >>>> It's not ideal but it's a small price to pay for more contributors.. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> 2017-09-20 22:10 GMT+02:00 Alex Kavanagh >>> : > >>>> > >>>>> There's some interesting ideas in there, Dmitrii. Whatever workflow > we > >>>>> end up with needs to be consistent with the other workflow on the > juju > >>>>> namespace on github.com, which I'm guessing is a simple fork to > >> private > >>>>> + PR. > >>>>> > >>>>> I've used squashed commits on projects in the past, and they do lead > >> to a > >>>>> cleaner git history, which is nice; as you say, it's a bit like > >> gerrit. > >>>>> Unfortunately, it's not gerrit, so it's difficult (as the bugs > >> indicate) to > >>>>> get it to work like gerrit, if you want to preserve the PR history, > >> yet > >>>>> keep clean commits. Once it gets to a PR I think you're pretty much > >> stuck > >>>>> with the "GitHub way". > >>>>> > >>>>> Cheers > >>>>> Alex. > >>>>> > >>>>> On Wed, Sep 20, 2017 at 8:33 PM, Dmitrii Shcherbakov < > >>>>> dmitrii.shcherba...@canonical.com> wrote: > >>>>> > >>>>>>> I'm guessing that the development workflow will be to fork the > >> repo, > >>>>>> and do PRs from your own github version? > >>>>>> > >>>>>> In short, yes. > >>>>>> > >>>>>> 1. fork; > >>>>>> 2. clone locally; > >>>>>> 3. set up 2 remotes (1 for rebasing to upstream, 1 for pushing); > >>>>>> 4. create a branch, commit and push to your fork; > >>>>>> 5. create a PR. > >>>>>> > >>>>>>> I also guess that the contributing guide will need updating (it > >> talks > >>>>>> about bzr). > >>>>>> > >>>>>> I would also suggest PR workflow-related updates to that doc given > >> that > >>>>>> one cannot > >>>>>> > >>>>>> git rebase -i HEAD~ # amend, squash, add new commits etc. > >>>>>> and > >>>>>> git push # to a forked repo > >>>>>> > >>>>>> without doing a force push to update a pull request. In my view, > it's > >>>>>> good to keep the commit history clean instead of adding several > >> commits on > >>>>>> top without squashing them. Otherwise it quickly turns into: > >>>>>> > >>>>>> "an original commit message to make charm-helpers great > >>>>>> fixup commit to avoid a typo > >>>>>> hotfix to the fixup > >>>>>> final fix - will not happen again" > >>>>>> * closed a PR as a huge rebase is needed > >>>>>> > >>>>>> I would propose the following: > >>>>>> > >>>>>> > >>>>>> - using "push -f" only for private branches used for pull requests > >&g
Re: charmhelpers migration to github
There's some interesting ideas in there, Dmitrii. Whatever workflow we end up with needs to be consistent with the other workflow on the juju namespace on github.com, which I'm guessing is a simple fork to private + PR. I've used squashed commits on projects in the past, and they do lead to a cleaner git history, which is nice; as you say, it's a bit like gerrit. Unfortunately, it's not gerrit, so it's difficult (as the bugs indicate) to get it to work like gerrit, if you want to preserve the PR history, yet keep clean commits. Once it gets to a PR I think you're pretty much stuck with the "GitHub way". Cheers Alex. On Wed, Sep 20, 2017 at 8:33 PM, Dmitrii Shcherbakov < dmitrii.shcherba...@canonical.com> wrote: > > I'm guessing that the development workflow will be to fork the repo, and > do PRs from your own github version? > > In short, yes. > > 1. fork; > 2. clone locally; > 3. set up 2 remotes (1 for rebasing to upstream, 1 for pushing); > 4. create a branch, commit and push to your fork; > 5. create a PR. > > > I also guess that the contributing guide will need updating (it talks > about bzr). > > I would also suggest PR workflow-related updates to that doc given that > one cannot > > git rebase -i HEAD~ # amend, squash, add new commits etc. > and > git push # to a forked repo > > without doing a force push to update a pull request. In my view, it's good > to keep the commit history clean instead of adding several commits on top > without squashing them. Otherwise it quickly turns into: > > "an original commit message to make charm-helpers great > fixup commit to avoid a typo > hotfix to the fixup > final fix - will not happen again" > * closed a PR as a huge rebase is needed > > I would propose the following: > > >- using "push -f" only for private branches used for pull requests >https://help.github.com/articles/using-git-rebase-on- >the-command-line/#pushing-rebased-code-to-github > > <https://help.github.com/articles/using-git-rebase-on-the-command-line/#pushing-rebased-code-to-github> >- using git-pull-request: https://github.com/jd/git-pull-request which >updates PRs with push -f. >- following this workflow advice about branches: https://github.com/ >jd/git-pull-request#workflow-advice ><https://github.com/jd/git-pull-request#workflow-advice> > > Rationale: > >- https://blog.adamspiers.org/2015/03/24/why-and-how-to- >correctly-amend-github-pull-requests/ > > <https://blog.adamspiers.org/2015/03/24/why-and-how-to-correctly-amend-github-pull-requests/> >- https://softwareengineering.stackexchange.com/a/263172 >- https://blog.adamspiers.org/2017/08/16/squash-merging-and- >other-problems-with-github/ >- https://www.mail-archive.com/dri-devel@lists.sourceforge. >net/msg39091.html > > > More info in a gist. > https://gist.github.com/dshcherb/2c827ae945dc551da3681313294d6783 > > > Coming from the kernel-type patch-sending process ( > https://lwn.net/Articles/702177/, https://www.mail-archive.com/ > dri-de...@lists.sourceforge.net/msg39091.html) and gerrit ( > https://www.mediawiki.org/wiki/Gerrit/Tutorial#Comparing_patch_sets) I > find github's approach with fixup commits a little strange but > force-pushing with precautions even to a PR branch is not a silver bullet > of course. > > https://github.com/isaacs/github/issues/997 > https://github.com/isaacs/github/issues/999 > > It would be great to hear some feedback on this topic so that we are not > doing anything random and have a common workflow. > > Thanks in advance! > > Best Regards, > Dmitrii Shcherbakov > > Field Software Engineer > IRC (freenode): Dmitrii-Sh > > On Wed, Sep 20, 2017 at 4:14 PM, Alex Kavanagh < > alex.kavan...@canonical.com> wrote: > >> Great stuff; I can confirm that I'm in. I'm guessing that the >> development workflow will be to fork the repo, and do PRs from your own >> github version? >> >> I also guess that the contributing guide will need updating (it talks >> about bzr). I'm happy to do a PR for that if the workflow can be confirmed >> :) >> >> Cheers >> Alex. >> >> >> On Wed, Sep 20, 2017 at 12:59 PM, James Page >> wrote: >> >>> If you're a part of the charmers team on Launchpad you should now either >>> have access to approve pull requests + merge or you should have an invite >>> to join the team that can do this :-) >>> >>> If you don't have one PM me on freenode IRC with your github username. >>> &
Re: charmhelpers migration to github
Great stuff; I can confirm that I'm in. I'm guessing that the development workflow will be to fork the repo, and do PRs from your own github version? I also guess that the contributing guide will need updating (it talks about bzr). I'm happy to do a PR for that if the workflow can be confirmed :) Cheers Alex. On Wed, Sep 20, 2017 at 12:59 PM, James Page wrote: > If you're a part of the charmers team on Launchpad you should now either > have access to approve pull requests + merge or you should have an invite > to join the team that can do this :-) > > If you don't have one PM me on freenode IRC with your github username. > > On Wed, 20 Sep 2017 at 11:57 James Page wrote: > >> Hi All >> >> Heres a bit of a status update on migration activity: >> >> Code history migration completed >> Travis CI enabled for unit testing and linting with Py 2.7 and 3.4 >> Repo configured to not allow merges until Travis +1's >> >> TODO >> >> Make sure all members of the current team on launchpad are part of the >> charmhelpers team - that should be completed today >> Fixup charmhelpers sync tooling to work from github - this week (mainly >> used by OpenStack Charms team) >> Redirect lp:charm-helpers landings to github.com/juju/charm-helpers >> >> and the prize goes to Merlin for raising the first non-migration related >> pull request :-) >> >> >> On Tue, 19 Sep 2017 at 14:57 Bryan Quigley >> wrote: >> >>> From other projects I've seen moved, I'd much prefer if the Code section >>> (and any other sections not planned on being using anymore) were cleared >>> out on LP and then disabled. >>> >>> Thanks! >>> Bryan >>> >>> On Tue, Sep 19, 2017 at 9:42 AM, Marco Ceppi >>> wrote: >>> >>>> I've updated the launchpad description to highlight the change. Since >>>> there's bound to be processes still pointing at the lp branch, should we >>>> set it up as a mirror from git? >>>> >>>> On Tue, Sep 19, 2017 at 9:37 AM James Page >>>> wrote: >>>> >>>>> OK - step 1 completed; I've pushed fresh bzr->git migrated code to >>>>> >>>>>https://github.com/juju/charm-helpers >>>>> >>>>> Please don't land any further changes into the bzr branch as we'll >>>>> need to diverge from this point forwards. >>>>> >>>>> I will land a commit in lp:charm-helpers to point lost souls to the >>>>> new github.com location as part of the migration. >>>>> >>>>> >>>>> On Mon, 18 Sep 2017 at 14:15 Alex Kavanagh < >>>>> alex.kavan...@canonical.com> wrote: >>>>> >>>>>> I'm a +1 on this too. Let the good times roll. >>>>>> >>>>>> On Mon, Sep 18, 2017 at 11:22 AM, James Page >>>>>> wrote: >>>>>> >>>>>>> Resurrecting this thread; I think its a good time to push on with >>>>>>> this work - anyone have any objections to targeting this week to >>>>>>> complete >>>>>>> the migration? >>>>>>> >>>>>>> On Fri, 21 Jul 2017 at 19:55 David Ames >>>>>>> wrote: >>>>>>> >>>>>>>> On Fri, Jul 21, 2017 at 5:46 AM, James Page >>>>>>>> wrote: >>>>>>>> > Hi All >>>>>>>> > >>>>>>>> > Managed to find some time to test the bzr->git migration more, >>>>>>>> including >>>>>>>> > some tidy of committers and other general hygiene. >>>>>>>> > >>>>>>>> >https://github.com/juju/charm-helpers >>>>>>>> > >>>>>>>> > I think we're in a good position to plan for a switch - I >>>>>>>> appreciate there >>>>>>>> > are a number of open reviews against the bzr branch for >>>>>>>> charmhelpers so it >>>>>>>> > would be nice to get those landed where possible first. >>>>>>>> > >>>>>>>> > I can re-run the process at any time so we can pick when we want >>>>>>>> to actually >>>>>>>> > switch over. >>>>>>>
Re: charmhelpers migration to github
I'm a +1 on this too. Let the good times roll. On Mon, Sep 18, 2017 at 11:22 AM, James Page wrote: > Resurrecting this thread; I think its a good time to push on with this > work - anyone have any objections to targeting this week to complete the > migration? > > On Fri, 21 Jul 2017 at 19:55 David Ames wrote: > >> On Fri, Jul 21, 2017 at 5:46 AM, James Page >> wrote: >> > Hi All >> > >> > Managed to find some time to test the bzr->git migration more, including >> > some tidy of committers and other general hygiene. >> > >> >https://github.com/juju/charm-helpers >> > >> > I think we're in a good position to plan for a switch - I appreciate >> there >> > are a number of open reviews against the bzr branch for charmhelpers so >> it >> > would be nice to get those landed where possible first. >> > >> > I can re-run the process at any time so we can pick when we want to >> actually >> > switch over. >> > >> > Once we have migrated, we can push forward on travis setup etc... so >> that we >> > can automatically test pull requests. >> > >> > Cheers >> > >> > James >> >> I landed two of Alex's MPs today which fix unit test failures that >> would need to get pulled in. Other than that, the road is clear from >> the OpenStack Charm team. >> >> -- >> David Ames >> > > -- > 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
Re: How to use LXC local image for new machine
On Fri, Sep 1, 2017 at 11:47 AM, Stuart Bishop wrote: > On 1 September 2017 at 02:37, fengxia wrote: > > According to https://bugs.launchpad.net/juju/+bug/1650651, juju 2.1 > supports > > using local image if its alias is `juju/series/arch` format. > > > > So following this, I created a local image and gave it an alias of this > > format, but juju deploy will still download ubuntu-trusty before creating > > the container. > > I'm attaching the script I'm using, which is slightly modified from > the original version passed around and posted here. It might point you > to where your process is failing. I haven't done it manually myself. > Thanks Stuart; that looks really useful. Cheers Alex. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Juju Charmer application
+1 from me too. On Wed, Aug 30, 2017 at 11:14 AM, Frode Nordahl wrote: > Dear Juju community, > > I would like to officially apply for membership of the Juju ~charmers team. > > Through the course of the past year I have made contributions to the > OpenStack Charms and other Charm projects. I have also had the privilege of > meeting many of you in person, and have shared fruitful exchanges. I have > signed the Ubuntu Code of Conduct. > > Before playing around with Juju I have had a long career in tech from > which I have experience with both operations and development of system > level code. I particularly like having my code well tested to make sure it > keeps on running in the future. > > Some examples of my charm-related work: > https://github.com/openstack/charm-neutron-openvswitch/commit/ > 4ffbc2fe25400abf55719a370f3a2cd37f90c99d > https://github.com/openstack/charm-rabbitmq-server/commit/ > 08b10513c5725fb740382668c47fc769a6f2936c > https://github.com/marcoceppi/charm-mysql/commit/ > cefb77fafcd1ee36d4dc30c14d07aa857d5273a2 > https://github.com/marcoceppi/charm-mysql/commit/ > 1a8277855be4020b26121cb9d573cd150b6aa882 > https://github.com/openstack/charm-ceph-radosgw/commit/ > 7fa6639ab3fde7dc89131fb204f018fd4339e82f > https://github.com/openstack/charm-keystone/commit/ > 5de1770931e886732870da1909f08279a0b804b4 > https://github.com/openstack/charm-nova-cloud-controller/commit/ > 2eef644a5c1acb2675e94908c88182658fec4ac5 > https://github.com/openstack/charm-openstack-dashboard/commit/ > 8f3a93ac4e7102736da492a189144220312f93df > https://github.com/openstack/charm-swift-proxy/commit/ > 7c24ae81283710c830ab03f240ec9cc10dccd975 > > Launchpad ID: fnordahl > > -- > Frode Nordahl > > -- > 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
Re: designate-charm/designate-sink patch backport request
Hi Patrizio >From the looks of the bug report, it seems to have been backported to stable/ocata, but judging from your links, you're using stable/newton? This should probably get raised as a bug on the designate project to request the backport to stable/newton, so that the designate team can evaluate impact/etc. Best regards Alex. On Fri, Jun 23, 2017 at 3:34 PM, Patrizio Bassi wrote: > Hi All > > I'm using a juju-deployed openstack. Today i deployed Designate charm (#9) > which pulls and installs: > > *designate-sink/xenial,now 1:2.0.0-0ubuntu1 all [installed]* > > when using > juju config designate neutron-record-format='%( > hostname)s.%(project)s.%(zone)s' > the %project variable is set to 'None' because of https://github.com/ > openstack/designate/blob/stable/newton/designate/ > notification_handler/nova.py#L69 > > The sink daemon can't resolve the project name which defaults to None. > > This commit fixes the issue for nova and neutron hooks. > https://github.com/openstack/designate/commit/ > b23cae7b7839af2d2ed38c06a126f1e2a869ddd3 > > It would be great to backport to xenial stable, it looks safe. I applied > locally and it works flawlessy. > > I will be happy to test a new deb build if you want. > > Regards, have a nice weekend > > Patrizio > > -- > 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
Re: juju application stuck, cannot remove/scale out
On Mon, Aug 7, 2017 at 2:14 PM, Patrizio Bassi wrote: > Dear Alex, > > i didn't try further, but i'll let you know in case it happens again > Regards > Thanks Patrizio. I hope the testing continues well. Cheers Alex. > > Patrizio > > 2017-08-04 16:37 GMT+02:00 Alex Kavanagh : > >> Hi Patrizio >> >> Sorry you're hitting a charm problem with designate. Has the problem >> re-occurred with a remove-machine and add-unit? I'm doing quite a lot of >> work on the designate charm for the next release, and so would be >> interested if this is a problem we've already fixed (e.g. you could try >> juju deploy cs:~openstack-charmers-next/designate-36) but there's still >> some work going on with it. >> >> Thanks >> Alex >> >> On Fri, Aug 4, 2017 at 2:48 PM, Patrizio Bassi >> wrote: >> >>> Unfortunately i cannot fix the issue because it looks like a charm >>> problem >>> https://paste.ubuntu.com/25240017/ >>> >>> Patrizio >>> >>> >>> 2017-08-04 15:43 GMT+02:00 Tom Barber : >>> >>>> You need to mark it resolved and if that fails you can do juju resolved >>>> designate/0 --no-retry >>>> >>>> Once its hooks have cleared out it will disappear. >>>> >>>> Tom >>>> >>>> On Fri, Aug 4, 2017 at 2:33 PM, Patrizio Bassi < >>>> patrizio.ba...@gmail.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> i've deployed a designate charm with maas provider in a lxd container. >>>>> when i tried to remove (juju remove-application designate) it i got >>>>> the unit stuck with hook failed: "update-status" >>>>> >>>>> Debugging with lxc info in the host machine i found the container is >>>>> still alive and with running processes. >>>>> >>>>> now i cannot use add-unit nor remove it, it's just stuck. i rebooted >>>>> the container, no way. I used juju resolved designate/0, no way. >>>>> >>>>> How to fix this kind of problem? >>>>> Thank you >>>>> >>>>> Patrizio >>>>> >>>>> -- >>>>> Juju mailing list >>>>> Juju@lists.ubuntu.com >>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>>> an/listinfo/juju >>>>> >>>>> >>>> >>>> >>>> -- >>>> Tom Barber >>>> CTO Spicule LTD >>>> t...@spicule.co.uk >>>> >>>> http://spicule.co.uk >>>> >>>> @spiculeim <http://twitter.com/spiculeim> >>>> >>>> Schedule a meeting with me <http://meetme.so/spicule> >>>> >>>> GB: +44(0)5603641316 <+44%2056%200364%201316> >>>> US: +18448141689 <+1%20844-814-1689> >>>> >>>> <https://leanpub.com/juju-cookbook> >>>> >>> >>> >>> >>> >>> -- >>> Juju mailing list >>> Juju@lists.ubuntu.com >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>> an/listinfo/juju >>> >>> >> >> >> -- >> Alex Kavanagh - Software Engineer >> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd >> > > > > -- > > Patrizio Bassi > www.patriziobassi.it > http://piazzadelpopolo.patriziobassi.it > -- 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: juju application stuck, cannot remove/scale out
Hi Patrizio Sorry you're hitting a charm problem with designate. Has the problem re-occurred with a remove-machine and add-unit? I'm doing quite a lot of work on the designate charm for the next release, and so would be interested if this is a problem we've already fixed (e.g. you could try juju deploy cs:~openstack-charmers-next/designate-36) but there's still some work going on with it. Thanks Alex On Fri, Aug 4, 2017 at 2:48 PM, Patrizio Bassi wrote: > Unfortunately i cannot fix the issue because it looks like a charm problem > https://paste.ubuntu.com/25240017/ > > Patrizio > > > 2017-08-04 15:43 GMT+02:00 Tom Barber : > >> You need to mark it resolved and if that fails you can do juju resolved >> designate/0 --no-retry >> >> Once its hooks have cleared out it will disappear. >> >> Tom >> >> On Fri, Aug 4, 2017 at 2:33 PM, Patrizio Bassi >> wrote: >> >>> Hi, >>> >>> i've deployed a designate charm with maas provider in a lxd container. >>> when i tried to remove (juju remove-application designate) it i got the >>> unit stuck with hook failed: "update-status" >>> >>> Debugging with lxc info in the host machine i found the container is >>> still alive and with running processes. >>> >>> now i cannot use add-unit nor remove it, it's just stuck. i rebooted the >>> container, no way. I used juju resolved designate/0, no way. >>> >>> How to fix this kind of problem? >>> Thank you >>> >>> Patrizio >>> >>> -- >>> Juju mailing list >>> Juju@lists.ubuntu.com >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>> an/listinfo/juju >>> >>> >> >> >> -- >> Tom Barber >> CTO Spicule LTD >> t...@spicule.co.uk >> >> http://spicule.co.uk >> >> @spiculeim <http://twitter.com/spiculeim> >> >> Schedule a meeting with me <http://meetme.so/spicule> >> >> GB: +44(0)5603641316 <+44%2056%200364%201316> >> US: +18448141689 <+1%20844-814-1689> >> >> <https://leanpub.com/juju-cookbook> >> > > > > > -- > 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
Re: juju application stuck, cannot remove/scale out
Hi Patrizio What's the output of "juju debug-log -i unit-designate -n 1000" ? The last few lines should indicate why designate crashed on the update-status hook. To force remove the unit use: juju remove-machine --force where n is the machine number from juju status designate Hope that helps Alex. On Fri, Aug 4, 2017 at 2:33 PM, Patrizio Bassi wrote: > Hi, > > i've deployed a designate charm with maas provider in a lxd container. > when i tried to remove (juju remove-application designate) it i got the > unit stuck with hook failed: "update-status" > > Debugging with lxc info in the host machine i found the container is still > alive and with running processes. > > now i cannot use add-unit nor remove it, it's just stuck. i rebooted the > container, no way. I used juju resolved designate/0, no way. > > How to fix this kind of problem? > Thank you > > Patrizio > > -- > 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
Re: Is a set state called multiple times?
Hi fengxia
As Cory says, it's much better to think of the set_state() and
remove_state() as binary flags; in fact in the upcoming version, set_state
becomes set_flag() and remove_state() becomes remove_flag() -- although
the existing functions will still exist for backwards compatibility.
So a handler with a set of conditions built from flags (states) that
evaluates to 'true' will always run on EVERY invocation of the charm;
that's all of the charm hooks, plus relation hooks.
This can often lead to a charm 'doing too much' during a hook invocation if
you don't gate or otherwise detect that a charm doesn't need to do
something. I've had 'bugs' in the past where databases were set up
multiple times because I didn't gate (by using a flag/state) the 'have I
set up the database yet'. Just something to watch for.
Also, the update-status hook is a bit redundant now. To get equivalent
functionality without having to use a @hook('update-status') just use a
@when_not("never-set-update-status") and it will always run on every hook
invocation; it also means you can gate the 'update status' if certain other
things haven't happened.
And yes, in your example, you can use flags to 'make progress' in the charm
life-cycle by using them to only run a bit of functionality once. You can
always do them in cycles too!
Finally, remember that states are NOT shared amongst units of the same
application; they are unique to each individual unit. Juju is not aware
that the charm is using reactive states.
Hope this helps
Cheers
Alex.
On Thu, Jul 27, 2017 at 9:09 PM, fengxia wrote:
> Now thinking of it, I just realized that this concept of True state
> executing repeatedly is actually a good thing.
>
>
> In many cases, there is a need to query external resource for its status.
> This is often implemented as a polling loop. So in charm, I can implement
> it as
>
>
> @when("prep")
>
> def prep():
>
> # are we there yet?
>
> is_ready = prep_test()
>
> if is_ready:
>
> remove_state("prep")
>
> set_state("do.sth")
>
> @when("do.sth")
>
> def do_sth():
>
> # do this
>
> pass
>
>
> # move on
>
> remove_state("do.sth")
>
> set_state("next")
>
> On 07/27/2017 03:56 PM, Cory Johns wrote:
>
> fengxia,
>
> It's probably more enlightening to think of them as "flags" rather than
> states. (Indeed, the next release of charms.reactive will deprecate
> calling them states and will provide set_flag, remove_flag, etc. functions
> instead.)
>
> On Thu, Jul 27, 2017 at 3:29 PM, fengxia wrote:
>
>> Alex,
>>
>> Thank you for the detailed explanations and examples.
>>
>> After reading Tilman's and Cory's replies, I think the confusion is at
>> continuous evaluation (thus execution) of a True state. So a pair of @when
>> and @when_not will result in one of them being executed over and over
>> despite adding a remove_state("myself") in the @when block.
>>
>> I'm still trying to grasp the idea of this "state" instead of treating it
>> as an event handler.
>>
>> So for states, I usually draw a state machine diagram. In this case, it
>> feels rather unnatural that all True states will inherently loop to
>> themselves.
>>
>> But I don't what alternative is in charm's context.
>>
>> On 07/27/2017 04:13 AM, Alex Kavanagh wrote:
>>
>> Hi
>>
>> On Thu, Jul 27, 2017 at 2:37 AM, fengxia wrote:
>>
>>> Hi Juju,
>>>
>>> Once I set a state, set_state("here"), I want to make sure its @when
>>> will only be executed ONCE (when "here" from False->True).
>>>
>>> So my thought is to remove_state("here") in its @when("here") code
>>> block. If I don't, will this @when be called multiple times if I don't
>>> reset this state? What's the good practice here?
>>
>>
>> You have a couple of options here depending on the nature of the handler.
>>
>>
>>1. If, in the lifetime of the unit's existence, the handler only has
>>to execute ONCE. (and I mean EVER), then there is a @only_once decorator
>>that can be used. It can be used in combination with other decorators to
>>set up a condition, but it guarantees that the handler will only be called
>>once. However, what you probably want is ...
>>2. Use a @when_not('flag') and then set it the 'flag' in the body
Re: Is a set state called multiple times?
Hi
On Thu, Jul 27, 2017 at 2:37 AM, fengxia wrote:
> Hi Juju,
>
> Once I set a state, set_state("here"), I want to make sure its @when will
> only be executed ONCE (when "here" from False->True).
>
> So my thought is to remove_state("here") in its @when("here") code block.
> If I don't, will this @when be called multiple times if I don't reset this
> state? What's the good practice here?
You have a couple of options here depending on the nature of the handler.
1. If, in the lifetime of the unit's existence, the handler only has to
execute ONCE. (and I mean EVER), then there is a @only_once decorator that
can be used. It can be used in combination with other decorators to set up
a condition, but it guarantees that the handler will only be called once.
However, what you probably want is ...
2. Use a @when_not('flag') and then set it the 'flag' in the body of the
handler.
The first would look something like:
@when('some-condition-flag')
@only_once
def
do_something_only_once_when_some_condition_flag_is_set_for_the_first_time():
... do something once ...
The second treats a flag as a 'have I done this yet' condition, and allows
you to reset the flag at some other point in the charm's life cycle so that
you can do it again. 'installed' is a good example of this:
@when_not('installed-something')
def do_install_of_something():
... do the installation ...
# when it is fully successful, set the installed-something flag. Don't
set it early as
# if it errors, a future handler invocation may be able to continue the
installation.
set_state('installed-something')
@when(some other conditions indicating do an upgrade)
def do_upgrade():
... set upgrade sources, or other pre upgrade actions
remove_state('installed-something')
In this situation, hopefully you can see that we can re-use
'do_install_of_something()' when we do upgrades.
I think it's useful to think about states (flags) as being a 'memory' that
something has happened, and use them to either gate on not doing things
again, or to trigger the next action is a graph of actions that need to
take place to get the charm's payload to the desired operational state. I
tend to name them, and use them, to indicate when something has happened,
rather than when it hasn't, and so tend to use @when_not('some-flag') on
the handler that eventually sets that flag.
Hope that this helps.
Alex.
>
>
> --
> Feng xia
> Engineer
> Lenovo USA
>
> Phone: 5088011794
> fx...@lenovo.com
>
> Lenovo.com
> Twitter | Facebook | Instagram | Blogs | Forums
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/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
Re: How to count relations?
On Thu, Jun 8, 2017 at 2:38 PM, Cory Johns wrote:
> Alex,
>
> I should clarify, conv.scope should only be None if the class's scope is
> GLOBAL. Otherwise, it should be the name of the service or unit. If the
> scope is defined as SERVICE or UNIT and the conv.scope is None, it was a
> bug, yes (but let's work to get rid of the confusing idea of scopes and
> conversations anyway, instead).
>
Indeed. The fact that we have juju scopes and charms.reactive scopes
*is* confusing,
although the conversations metaphor does work well with 1-to-1, but then
breaks down on 1-to-many.
>
> On Wed, Jun 7, 2017 at 12:30 PM, Alex Kavanagh <
> alex.kavan...@canonical.com> wrote:
>
>>
>>
>> On Wed, Jun 7, 2017 at 4:44 PM, Cory Johns
>> wrote:
>>
>>> Alex beat me to it, but here's a marginally more complete example:
>>> https://gist.github.com/johnsca/a91cb5897d92dfb6741ee1a09d82b39b
>>>
>>> The key points are:
>>>
>>> * The interface needs to be UNIT scoped (because you care about
>>> individual units)
>>> * The joined handler sets a state for each unit that joins
>>> * The @when('rel.connected') predicate in the charm layer matches all
>>> units that have had that state set, so the set of conversations in the
>>> interface layer includes those units, and only those units. This is
>>> trivially all of the units in my example, but you could also set a
>>> different state in a -changed handler based on data sent by each remote
>>> unit, and the conversations would only include the units that had that
>>> specific state set when you matched that state using @when
>>>
>>> Alex: A conversation will always have a scope, so that list
>>> comprehension isn't necessary.
>>>
>>
>> Ah, interesting Cory. It must have been a bug then; I ran into a
>> situation where scope was None and had to filter it out; maybe I can remove
>> that check from the interface I wrote (manila-plugin).
>>
>> Thanks!
>> Alex.
>>
>>
>>> On Wed, Jun 7, 2017 at 11:38 AM, Alex Kavanagh <
>>> alex.kavan...@canonical.com> wrote:
>>>
>>>> Hi
>>>>
>>>> I'm assuming you are using charms.reactive; if not then look into
>>>> relation_ids command.
>>>>
>>>> In your interface, count the number of conversations that have a scope
>>>> set to something other than None. scope shouldn't be None, but I've had
>>>> cases where it has been (it may have been a bug):
>>>>
>>>> So in the provider.py RelationBase derived class, something along the
>>>> lines of:
>>>>
>>>> num = len([c for c in self.conversations() if c.scope])
>>>>
>>>> in a method would be a relatively simple way of doing it.
>>>>
>>>> (There may be better ways of doing this!)
>>>>
>>>> Cheers
>>>> Alex.
>>>>
>>>> On Wed, Jun 7, 2017 at 4:22 PM, fengxia wrote:
>>>>
>>>>> Hi Juju,
>>>>>
>>>>> I'm building two charms and linking them with one relation, one charm
>>>>> ("A") will provide and the other ("B") will require.
>>>>>
>>>>> The deployment will have one "A" and three "B"s. How do I know all
>>>>> three Bs have joined? I'm thinking to use a counter in A's relation, then
>>>>> at relation-joined hook by B to add this counter. But set_remote() and
>>>>> set_local() didn't work. Not sure what's the right way to achieve this?
>>>>>
>>>>>
>>>>> --
>>>>> Feng xia
>>>>> Engineer
>>>>> Lenovo USA
>>>>>
>>>>> Phone: 5088011794
>>>>> fx...@lenovo.com
>>>>>
>>>>> Lenovo.com
>>>>> Twitter | Facebook | Instagram | Blogs | Forums
>>>>> 9
>>>>>
>>>>>
>>>>> --
>>>>> Juju mailing list
>>>>> Juju@lists.ubuntu.com
>>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>>>> an/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/mailm
>>>> an/listinfo/juju
>>>>
>>>>
>>>
>>
>>
>> --
>> Alex Kavanagh - Software Engineer
>> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
>>
>
>
--
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: How to count relations?
On Wed, Jun 7, 2017 at 4:44 PM, Cory Johns wrote:
> Alex beat me to it, but here's a marginally more complete example:
> https://gist.github.com/johnsca/a91cb5897d92dfb6741ee1a09d82b39b
>
> The key points are:
>
> * The interface needs to be UNIT scoped (because you care about individual
> units)
> * The joined handler sets a state for each unit that joins
> * The @when('rel.connected') predicate in the charm layer matches all
> units that have had that state set, so the set of conversations in the
> interface layer includes those units, and only those units. This is
> trivially all of the units in my example, but you could also set a
> different state in a -changed handler based on data sent by each remote
> unit, and the conversations would only include the units that had that
> specific state set when you matched that state using @when
>
> Alex: A conversation will always have a scope, so that list comprehension
> isn't necessary.
>
Ah, interesting Cory. It must have been a bug then; I ran into a situation
where scope was None and had to filter it out; maybe I can remove that
check from the interface I wrote (manila-plugin).
Thanks!
Alex.
> On Wed, Jun 7, 2017 at 11:38 AM, Alex Kavanagh <
> alex.kavan...@canonical.com> wrote:
>
>> Hi
>>
>> I'm assuming you are using charms.reactive; if not then look into
>> relation_ids command.
>>
>> In your interface, count the number of conversations that have a scope
>> set to something other than None. scope shouldn't be None, but I've had
>> cases where it has been (it may have been a bug):
>>
>> So in the provider.py RelationBase derived class, something along the
>> lines of:
>>
>> num = len([c for c in self.conversations() if c.scope])
>>
>> in a method would be a relatively simple way of doing it.
>>
>> (There may be better ways of doing this!)
>>
>> Cheers
>> Alex.
>>
>> On Wed, Jun 7, 2017 at 4:22 PM, fengxia wrote:
>>
>>> Hi Juju,
>>>
>>> I'm building two charms and linking them with one relation, one charm
>>> ("A") will provide and the other ("B") will require.
>>>
>>> The deployment will have one "A" and three "B"s. How do I know all three
>>> Bs have joined? I'm thinking to use a counter in A's relation, then at
>>> relation-joined hook by B to add this counter. But set_remote() and
>>> set_local() didn't work. Not sure what's the right way to achieve this?
>>>
>>>
>>> --
>>> Feng xia
>>> Engineer
>>> Lenovo USA
>>>
>>> Phone: 5088011794
>>> fx...@lenovo.com
>>>
>>> Lenovo.com
>>> Twitter | Facebook | Instagram | Blogs | Forums
>>> 9
>>>
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/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/mailm
>> an/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
Re: How to count relations?
Hi
I'm assuming you are using charms.reactive; if not then look into
relation_ids command.
In your interface, count the number of conversations that have a scope set
to something other than None. scope shouldn't be None, but I've had cases
where it has been (it may have been a bug):
So in the provider.py RelationBase derived class, something along the lines
of:
num = len([c for c in self.conversations() if c.scope])
in a method would be a relatively simple way of doing it.
(There may be better ways of doing this!)
Cheers
Alex.
On Wed, Jun 7, 2017 at 4:22 PM, fengxia wrote:
> Hi Juju,
>
> I'm building two charms and linking them with one relation, one charm
> ("A") will provide and the other ("B") will require.
>
> The deployment will have one "A" and three "B"s. How do I know all three
> Bs have joined? I'm thinking to use a counter in A's relation, then at
> relation-joined hook by B to add this counter. But set_remote() and
> set_local() didn't work. Not sure what's the right way to achieve this?
>
>
> --
> Feng xia
> Engineer
> Lenovo USA
>
> Phone: 5088011794
> fx...@lenovo.com
>
> Lenovo.com
> Twitter | Facebook | Instagram | Blogs | Forums
> 9
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/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
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
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
Re: PROPOSAL: stop recording 'executing update-status hook'
>From a 'principle of least surprise', I think that this proposal is probably a bad idea. The main driver is to (I guess) reduce the volume of 'chat' between the controller and 100's or 1000's of charms, and the effect this has on the status log. However, my 'guess' is also probably wrong as it would continue to live in the debug log, which implies it is still being sent/received. I think it would be 'odd' for a status to be running, but not show up in the status or status log - this would be unexpected. My counter proposal is to have a toggle to disable 'update status' on a model and/or application level, and/or have the ability to reduce the frequency of the updates. However, the downside of reducing/eliminating update-status is that (I suspect) several charms rely on it to recover from errors (particularly) racy ones. Perhaps, this can be offset (during install) by usage of 'juju run ...' and the fixing the charms with the bugs? Another 'worry' is that if update-status is not reflected in 'juju-status' will the workload status be updated (i.e. showing problems, fixing problems, etc.)? Alex. On Mon, May 22, 2017 at 9:56 AM, Stuart Bishop wrote: > On 22 May 2017 at 14:36, Tim Penhey wrote: > > On 20/05/17 19:48, Merlijn Sebrechts wrote: > >> > >> On May 20, 2017 09:05, "John Meinel" >> <mailto:j...@arbash-meinel.com>> wrote: > >> > >> I would actually prefer if it shows up in 'juju status' but that we > >> suppress it from 'juju status-log' by default. > >> > >> > >> This is still very strange behavior. Why should this be default? Just > pipe > >> the output of juju status through grep and exclude update-status if > that is > >> really what you want. > >> > >> However, I would even argue that this isn't what you want in most > >> use-cases. "update-status" isn't seen as a special hook in > charms.reactive. > >> Anything can happen in that hook if the conditions are right. Ignoring > >> update-status will have unforeseen consequences... > > > > > > Hmm... there are (at least) two problems here. > > > > Firstly, update-status *should* be a special case hook, and it shouldn't > > take long. > > > > The purpose of the update-status hook was to provide a regular beat for > the > > charm to report on the workload status. Really it shouldn't be doing > other > > things. > > > > The fact that it is a periodic execution rather than being executed in > > response to model changes is the reason it isn't fitting so well into the > > regular status and status history updates. > > > > The changes to the workload status would still be shown in the history of > > the workload status, and the workload status is shown in the status > output. > > > > One way to limit the execution of the update-status hook call would be to > > put a hard timeout on it enforced by the agent. > > > > Thoughts? > > Unfortunately update-status got wired into charms.reactive like all > the other standard hooks, and just means 'do whatever still needs to > be done'. I think its too late to add timeouts or restrictions. But I > do think special casing it in the status history is needed. Anything > important will still end up in there due to workload status changes. > > -- > Stuart Bishop > > -- > Juju-dev mailing list > juju-...@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju-dev > -- 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: Normalizing output dir for charm build
Good work here, thanks Merlijn. My instinct is that, if we are changing behaviour, then the option probably needs to be mandatory so that affected tool chains actually break in a predictable way, rather than in an obscure "huh, what's going on here". So, I'm in agreement with Cory's proposal. Cheers Alex. On Wed, May 10, 2017 at 3:36 PM, Merlijn Sebrechts < merlijn.sebrec...@gmail.com> wrote: > * Drop the "builds" portion of the output directory (that was mainly to >> distinguish it from the series portion). >> > > We still need to distinguish the charms from `deps` and possibly from > `layers` and `interfaces`. > > This is my $JUJU_REPOSITORY: > > ├── charms > │ ├── builds > │ ├── deps > │ ├── interfaces > │ ├── layers > > > 2017-05-10 20:03 GMT+02:00 Cory Johns : > >> Started on https://github.com/juju/charm-tools/pull/320, I'd like to >> bring this discussion to the list. >> >> The output directory for charm build can vary in seemingly unpredictable >> ways depending on how it is called, the environment, and the charm's >> metadata.yaml contents. This is due to historical reasons, primarily with >> how Juju 1.x worked and how charm paths worked prior to the advent of >> multi-series charms. However, now that 2.x and multi-series support are >> standard, I would like to push for simplifying the output directory, based >> on Merlijn's PR. >> >> Specifically, I'd like to push for the following changes: >> >> * Drop the series portion of the output directory (we recommend providing >> the series in the charm's metadata, making it redundant in the path). >> * Drop the "builds" portion of the output directory (that was mainly to >> distinguish it from the series portion). >> * Drop the current directory as a fallback option for the output >> directory (it causes more confusion than it saves). >> >> Thus, charm build would always require an output directory to be given >> either via --output-dir (-o) or via the $JUJU_REPOSITORY environment >> variable, and would always put the built charm in $output_dir/$charm_name >> >> Obviously, this is not backwards compatible, and may affect automated >> build systems, but I think it would be easy to adjust for and simplify >> things for everyone concerned. >> >> Thoughts? Objections? >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/juju >> >> > > -- > 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
Re: Proposing Alex Kavanagh for ~charmers
Hi All Thanks for all of the +1's! I hope I can live up to them! :) Cheers Alex. On Thu, Apr 27, 2017 at 8:40 AM, Merlijn Sebrechts < merlijn.sebrec...@gmail.com> wrote: > Unofficial +1 > > 2017-04-26 11:52 GMT+02:00 James Page : > >> Hi Charmers >> >> I'd like to propose Alex (tinwood) for membership of charmers; he's >> worked extensively across the OpenStack charms, providing valuable reviews >> to the rest of the team, has been reviewing charm-helpers updates and has >> been instrumental in the OpenStack charms use of reactive and layers for >> building newer charms. >> >> He's also working as part of the team for Reactive 2.0. >> >> I think he'll be a valuable addition to the core charmers team! >> >> Cheers >> >> James >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/juju >> >> > > -- > 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
Re: Do states have namespace?
Hi On Tue, Apr 18, 2017 at 1:50 PM, fengxia wrote: > I did a quick experiment: > > 1. Created two layers in one charm, each layer has a few states, > set_state() can trigger @when defined in other layers. > > 2. Use the same set of states, now splitting them in two charms => @when > don't trigger anymore. > > So does this mean states have a namespace by the charm it belongs? States are stored on the individual instance of the charm. They are private and no other charm can see those states. Cheers Alex. > > > -- > Feng xia > Engineer > Lenovo USA > > Phone: 5088011794 > fx...@lenovo.com > > Lenovo.com > Twitter | Facebook | Instagram | Blogs | Forums > > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/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
Re: Juju charm hook vs. state
Hi
On Fri, Apr 14, 2017 at 8:19 PM, fengxia wrote:
> I'm learning charm development and confused about state vs. hook.
>
Welcome to charm authoring!
So, as you're probably starting to work out, hooks and states are different
things. I'll try to explain the difference.
Hooks:
At it's simplest, a hook is an executable in the 'hooks' directory of a
charm. The Juju agent that looks after the unit calls the 'hook'
executable at certain points during the lifetime of the charm. i.e. start,
install, config-changed, update-status, etc.
The hook executable can be a bash script, a python script or even (and
don't do this!) a compiled C binary. Anything that can be an executable
can be a hook.
States:
This is a concept that is associated only with the charms.reactive library.
i.e. you can write charms in Python without the charms.reactive library.
It isn't suggested that you do, because charms.reactive really, really
helps to simplify and ease the writing of charms.
Conceptually, I guess these are a bit harder to grab hold of. A state is
an indicator that a charm author (or interface author) sets when some
condition/state has been achieved. i.e. the software under control has
been installed, or a relation (interface in charms.reactive terminology)
has been connected, etc. This state is remembered between invocations of
the charm code.
Putting it together:
For any of the charm code to run (at all), Juju calls a hook executable in
the hooks directory.
For a charms.reactive charm, any of the hooks (usually) results in the same
charm code being loaded. Thus, from the perspective of a charms.reactive
based charm, all hooks are treated the same.
The charms.reactive library does support hooks (using a the @hook
decorator) and these are run before any reactive handlers (@when,
@when_not). The named hook decorator (@hook('update-status')) is run
according to the actual hook executable (in the hooks directory) that Juju
called. Then the conditions described by the reactive handlers (@when...)
are evaluated and any that are 'true' are executed. This continues until
no more handlers' conditions are true.
So, it's important to remember that for a charms.reactive type charm, any
and every hook that Juju calls could result in any of the reactive handlers
being called depending on the states that the charm has previous set (or
its interfaces).
So, on to your questions:
>
> I used @when_not("state.0") to mark the very first function that gets
> executed. In document it also says "install" hook will be the first to
> execute. Tried @hooks.hook("install") but it just failed at charm
> installation.
>
Okay, so with reactive handlers there is no 'first' function. Any handler
that has conditions that evaluate to 'true' will be run, and the ordering
should be considered arbitrary.
The named hook (if a @hook is used) will execute before reactive handlers.
>
> So what is the right way to determine the "entry" point in a charm? I mean
> the first function block that will be executed. I'm thinking to use chained
> state from that point on to guide execution process. Is this the right
> approach?
So the very first time a reactive charm is executed there will be no states
set. It's recommended to avoid using @hook decorators unless absolutely
necessary. Luckily, installation of the underlying software doesn't need
hooks!
The normal way is to to use a @when_not('installed') condition on the
handler that will either do, or at least kick off the installation, and
then set it when the installation is complete. Remember that every
reactive handler should be idempotent for the state conditions that it
handles.
So:
@when_not('installed')
def install_software():
... install the software ...
set_state('installed')
i.e. you are on the right approach!
Hope that this helps.
All the best
Alex.
>
> --
> Feng xia
> Engineer
> Lenovo USA
>
> Phone: 5088011794
> fx...@lenovo.com
>
> Lenovo.com
> Twitter | Facebook | Instagram | Blogs | Forums
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/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
Re: Multi-series charm authors: new functionality for comparing ubuntu versions
On Thu, Apr 13, 2017 at 10:13 PM, Colin Watson wrote: > On Thu, Apr 13, 2017 at 09:15:08PM +0100, Alex Kavanagh wrote: > > So instead of: > > > > if ubuntu_version > 'trusty': > > > > We do: > > > > cmp_version = CompareHostReleases(ubuntu_version) > > if cmp_version > 'trusty': > > > > This version of the code checks that ubuntu_version and 'trusty' strings > > are known releases and makes it easy to fix existing code. >, <, >=< <=, > > ==, != are all supported. > > I have déjà vu: I did exactly the same thing in lp:ubuntu-cdimage in > 2012. :-) I agree that this style makes things pretty nice for calling > code. > > The one problem I've had with it is that every so often somebody looks > at a bit of code and says "hey, isn't this going to break after 17.04?" > and then I have to explain that it's actually magically OK, which as > problems go is not really a bad one to have. > Good to know that I'm not totally going out on a limb with this approach! There was some criticism of leaving is as >, <, etc., the alternatives just seemed really clunky. There is the downside that people could miss it, but there wasn't a reasonable way of stopping people just using a regular string comparison. Thanks for the feedback / confirmation! > > -- > Colin Watson [cjwat...@ubuntu.com] > > -- > 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
Multi-series charm authors: new functionality for comparing ubuntu versions
Hi I just wanted to highlight some new functionality that has been added to charm-helpers [1] to make comparing Ubuntu versions more robust. In the OpenStack team, all of our charms are 'multi-series' in that a single charm support multiple versions of Ubuntu and multiple versions of OpenStack (often simultaneously). The code was using statements along the lines of: if ubuntu_version > 'trusty': The eagle-eyed amongst you will have noticed the impending y2k-type bug, with the (possible) imminent wrap from 'zesty' -> '???'. So we decided to fix this across our 30-odd charms and add a couple of functions to charm-helpers to aid in this. Firstly, charm-helpers.core.strutils.BasicStringComparator class is an abstract-ish class to be used as a base class for building a comparator of an ordered list. It provides __eq__, __ne__, __lt__ (and so on) comparisons for two strings. it also checks that the strings provided are in the defined list, which helps with mistyping of string literals. Then for the Ubuntu releases, the charmhelpers.core.host.CompareHostReleases class is used to compare two Ubuntu release for equality or 'earlier than' and 'later than;. So instead of: if ubuntu_version > 'trusty': We do: cmp_version = CompareHostReleases(ubuntu_version) if cmp_version > 'trusty': This version of the code checks that ubuntu_version and 'trusty' strings are known releases and makes it easy to fix existing code. >, <, >=< <=, ==, != are all supported. We did consider a number of approaches, but felt that this one was simple to retro-fit to existing charms and also spot in reviews going forward if they have been missed. Also, for charms in the OpenStack ecosystem, there is an additional comparator class: charmhelpers.contrib.openstack.utils.CompareOpenStackReleases which is used in the same way, but works with all of the OpenStack releases. Thus: cmp_os_release = CompareOpenStackReleases(os_release) if cmp_os_release > 'mitaka': We're now in the process of finalises the fixes to the OpenStack charms and they'll be in 'next' over the coming week. Thanks, and hope this is useful. Best Alex. [1] -- charm-helpers: https://launchpad.net/charm-helpers -- 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: normal charm to subordinate charm and now peer relation does not work
Hi Tilman
That's very useful. Based on your work I'm definitely going to explore the
interactions of all of these scopes!
Cheers
Alex.
On Fri, Jan 27, 2017 at 12:16 PM, Tilman Baumann <
tilman.baum...@canonical.com> wrote:
> OMG, I went way deep down the rabbit hole.
>
> I had to find charms.reactive.join() to find what the difference of the
> scopes really means.
>
> This kept me busy and questioning my sanity for two days:
> $ git diff
> diff --git a/peers.py b/peers.py
> index 976c0ad..93cda29 100644
> --- a/peers.py
> +++ b/peers.py
> @@ -12,7 +12,7 @@ from charms.reactive import scopes
>
>
> class PeerDiscovery(RelationBase):
> -scope = scopes.UNIT
> +scope = scopes.SERVICE
>
> class states(StateList):
> connected = State('{relation_name}.connected')
>
> Sometimes software engineering feels just like a farce. :)
>
>
> Cheers guys, I hope you where entertained.
> Tilman
>
> On 25.01.2017 16:54, Tilman Baumann wrote:
> > On 25.01.2017 15:49, Tilman Baumann wrote:
> >> On 25.01.2017 14:24, Tilman Baumann wrote:
> >>> On 25.01.2017 13:16, Stuart Bishop wrote:
> >>>> On 25 January 2017 at 18:43, Tilman Baumann
> >>>
> >>>> I don't know why your peer relation (with global scope) starts
> >>>> misbehaving after you add the container scoped juju-info relation to
> >>>> turn your charm into a subordinate. It might be helpful to inspect the
> >>>> peer relation with the hook environment tools to try to narrow down if
> >>>> the problem is with Juju, charms.reactive, or something else. Using
> >>>> debug-hooks, or 'juju run --unit foo/0 "relation-ids ssh-peers"' and
> >>>> 'juju run --unit foo/0 "relation-list -r ssh-peers:64"' if you haven't
> >>>> done this before.
> >>>
> >>> Thanks. That was the breakthrough hint.
> >>> [...]
> >>> It is either reactive or my charm code.
> >>
> >> Reactive.
> >>
> >> Shortened version of my debug interface code:
> >>
> >> @hook('{peers:peer-discovery}-relation-{joined,changed}')
> >> def changed(self):
> >> for conv in self.conversations():
> >> log("JujuInfoClient Conversation.serialize():
> >> {}".format(conv.__class__.serialize(conv)))
> >>
> >> I get:
> >> Conversation.serialize(): {'scope': 'iptables-peer-ssh/102',
> >> 'namespace': 'ssh-peers:105', 'units': ['iptables-peer-ssh/102']}
> >>
> >> I have to go deeper down the rabbit hole. But somehow the Conversations
> >> get initialised with bullshit.
> >>
> >> This would be a example of a correctly initialised conversion.
> >> {'scope': 'global', 'units': ['dokuwiki/25'], 'namespace':
> 'host-system'}
> >>
> >> I will go bare-metal with charmhelpers and see what I get there...
> >>
> >
> > charmhelpers.core.hookenv tools seem to perform as expected
> >
> > units = related_units()
> > for unit in units:
> > relation_get('private-address', unit)
> >
> > I will bodge up a workaround with that now in order to be able to
> > deploy. But surely there is something wrong in the way RelationBase gets
> > initialised...
> >
>
> --
> 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
Re: normal charm to subordinate charm and now peer relation does not work
On Wed, Jan 25, 2017 at 1:08 PM, Tilman Baumann < tilman.baum...@canonical.com> wrote: > > > On 25.01.2017 13:06, Alex Kavanagh wrote: > > Hi Tilman > > > > On Wed, Jan 25, 2017 at 11:43 AM, Tilman Baumann > > mailto:tilman.baum...@canonical.com>> > wrote: > > > > At this point I'm pretty sure that this is a bug or undocumented > > feature. > > > > > > The peer relation of a subordinate charm only has one conversation. > > Despite scope being 'global' in metadata.yaml and the RelationBase > class > > being scope = scope.UNIT. > > > > > > Shouldn't the metadata.yaml ALSO be 'unit' scope if you want individual > > conversations without sharing the data between all the subordinate > > units? global would imply that all of the relations have the same > > data? The subordinate to principal relation will be unit (anyway), but > > the peer is just like any other relation, except here it is between the > > subordinate's on multiple machines. > > The naming is quite confusing here. > There is a bug for that. https://bugs.launchpad.net/juju/+bug/1499900 > Container in this case means it 'converses' with the other services on > the same unit. Global means, it can talk to everything. > > This should really be unified. The naming in reactive seems more > intuitive. But in the end reactive is a layer on-top of charms, I guess > reactive should have stayed with the established nomenclature here. > Ah, yes, of course, the difference between charms.reactive conversation scopes and juju scopes. I can feel some experimentation and a new blog post coming on ... 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: normal charm to subordinate charm and now peer relation does not work
Hi Tilman On Wed, Jan 25, 2017 at 11:43 AM, Tilman Baumann < tilman.baum...@canonical.com> wrote: > At this point I'm pretty sure that this is a bug or undocumented feature. > > > The peer relation of a subordinate charm only has one conversation. > Despite scope being 'global' in metadata.yaml and the RelationBase class > being scope = scope.UNIT. > Shouldn't the metadata.yaml ALSO be 'unit' scope if you want individual conversations without sharing the data between all the subordinate units? global would imply that all of the relations have the same data? The subordinate to principal relation will be unit (anyway), but the peer is just like any other relation, except here it is between the subordinate's on multiple machines. Cheers Alex. > Either I'm wrong to expect this to work and subordinates are only > supposed to have container scopes. Then it is a dokufix and should be > caugt by charm proof. > > Or, it is a bug. I could not find the point in the code which could be > wrong here. If anyone points me to the right place I would not mind > working on a fix. In go or python. > > Thanks > Tilman > > > PS: File as bug in LP? > > > On 25.01.2017 11:00, Tilman Baumann wrote: > > On 24.01.2017 16:56, Alex Kavanagh wrote: > >> Hi Tilman > >> > >> (I'm not an expert here, but was staring at the docs) > >> > >> I suspect that your peers relationship should be unit if each peer needs > >> to have it's own conversation? Otherwise, with a global scope, every > >> peer will overwrite the other's information? At least I'm wondering if > >> that what the scopes mean: see > >> here: https://jujucharms.com/docs/2.0/developer-layers-interfaces > >> > >> If that's completely wrong, then a) sorry for the noise, and b) do tell, > >> as it will help me in my understanding of juju scopes. > > > > No I think this must generally be the direction I need to think towards. > > Any thought impulse in that direction can unlock the knot in my head. :) > > > > Thing is, my interface class is scope UNIT already. (GLOBAL and SERVICE > > definitely would be wrong I think) > > > > What hasn't really connected in my brain is how this relates to the > > scopes in metadata.yaml > > They have different values. I could only find documentation for global > > and container. Global apparently is the default. So that is what I set > > it to explicitly. I'm quite sure that I had tried it with 'container' > > too in one of the iterations of testing. > > > > I can't really see how the interface class scope could have changed. It > > was always scope.UNIT. So I'm going to dig through some code to > > understand the implications of scope in metadata.yaml... > > > > > > Thanks Ales > > Tilman > > > > -- > 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
Re: normal charm to subordinate charm and now peer relation does not work
Hi Tilman (I'm not an expert here, but was staring at the docs) I suspect that your peers relationship should be unit if each peer needs to have it's own conversation? Otherwise, with a global scope, every peer will overwrite the other's information? At least I'm wondering if that what the scopes mean: see here: https://jujucharms.com/docs/2.0/developer-layers-interfaces If that's completely wrong, then a) sorry for the noise, and b) do tell, as it will help me in my understanding of juju scopes. Cheers Alex. On Tue, Jan 24, 2017 at 3:46 PM, Tilman Baumann < tilman.baum...@canonical.com> wrote: > Any comments are appreciated. I'm stuck with this right now and I'm out > of ideas. > > Thanks > Tilman > > On 24.01.2017 14:44, Tilman Baumann wrote: > > [...] > > Any idea what could be happening here. > > I suspect something with the scopes. But they are now all set > > explicitly. Any changes in implicit behavior should not affect this. > > Am I expecting something from subordinate charms which they can not > provide? > > > > The ssh-peers-relation-* hooks are still called when a unit joins or > > leaves. But somehow it's information is not added to the conversation. > > Or rather, I think it replaces actually the currently visible single > > entry in there. > > -- > 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
Re: Proposal: display-name for charm metadata
Why not allow the display of the name to be case sensitive, but all usage to be case insensitive? So name is MySQL, but you can juju deploy mYSqL if you really wanted to. On Sat, Sep 24, 2016 at 2:50 PM, Marco Ceppi wrote: > Hey everyone, > > I know we're rocking towards 2.0 but this is a problem I've seen voiced a > few times now. To date, the `name` field in charm has always been > [a-z-0-9_-] where you can't end with `-#`. This makes sense, simple flat > names that are all lowercase make it easy to do `juju deploy wordpress` > instead of following branding guidelines of `juju deploy WordPress`. > > However, a lot of applications have very specific branding guidelines for > how their display name should be represented. Just a few for example: > > - WordPress > - NS1 > - MySQL > - PostgreSQL > > Today, in the charmstore each is rendered as: > > - Wordpress > - Ns1 > - Mysql > - Postgresql > > Very rarely do the display names in the charm store and the intended > branding of application align. I'd like to propose an optional field in the > charm metadata, `display-name` which would allow slightly more control over > charmstore display: > > ``` > name: ns1 > display-name: NS1 > ``` > > ``` > name: mysql > display-name: MySQL > ``` > > etc. This would lead to the store and other places across the Juju Charms > properties which referenced the Application, instead of the deployment > instructions, to use the display-name field (see attached). > > Curious opinions on this, repercussions of adding metadata fields, esp for > older versions of Juju, and if this is worth pursing. > > -- > 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
Re: Dynamically registering reactive handlers at runtime
Hi Merlijn On Thu, Feb 18, 2016 at 10:15 AM, Merlijn Sebrechts < merlijn.sebrec...@gmail.com> wrote: > > Thank you for your response, we did not realize this was the case, this > might come in handy! > > Now to get some clarification: If we have the following code: > > if some-condition: > @when(...) > def some_function(...): > ... > > and `some-condition` changes after the initial registration of handlers. > Will `some_function` be registered, or will this only happen during the > next hook run? > A new process is invoked for each 'run' of a hook, and so from the perspective of the Python script/program it is starting anew each time for each hook invocation (i.e. there is no 'server' handling hooks). Thus the @when(...) are registered every time a hook is called. So, if you register them dynamically, then they could be different during each hook invocation. Whether this is a good idea is debatable as the hooks registered would be determined by the state of the system as a whole which might make it tricky to debug, test, and reason about. > > The possible values for package-names are not known during build time. We > do know that _all_ queued packages have to be installed. Would it be > possible to have an `apt.installed.all` state? > Well, your own script sets the states, so yes; but I don't know enough about your use case to advise on that - I was more commenting on what's possible in Python. Cheers 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: Dynamically registering reactive handlers at runtime
On Thu, Feb 18, 2016 at 7:23 AM, Stuart Bishop
wrote:
> On 12 February 2016 at 22:55, Merlijn Sebrechts
> wrote:
> > Hi all
> >
> >
> > We have a layer that can install a number of different packages. It
> decides
> > at runtime which packages will be installed. This layer uses the `apt`
> layer
> > which sets a state `apt.installed.`.
> >
> > We want to react to this installed state, but we don't know what the
> > packagename will be beforehand. This gets decided at runtime. Therefore,
> we
> > can't put it in a @when() decorator.
> >
> > Is there a way to dynamically register handlers at runtime?
>
>From a Python perspective, there's nothing stopping you, at the top level
in the file, or in a function, doing:
if some-condition:
@when(...)
def some_function(...):
...
i.e. decorators don't have to be at the top level in a module/file - they
are essentially 'just' syntactic sugar for a function call on the defined
function.
@when(...)
def something():
is conceptually equivalent to:
def something():
...
when(...)(something)
However, I'd caution against dynamically defining the handlers, as it might
make the program/script less easy to reason about, test and debug.
I'm guessing that the possible values for packagename are known at build
time, so could you not just either list them all with their appropriate
handlers, or bundle them all into a single @when(...) if they share a
common handler?
e.g.
@when('apt.installed.packagename1')
def ...
@when('apt.installed.packagename2')
def ...
and/or
@when('apt.installed.packagename1', 'apt.installed.packagename2', ...)
def ...
Explicit tends to be more helpful than implicit. Hope this is useful
and/or helpful!
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
