Fwd: Storage server temporarily offline
An update from Github about the current outage. -- Forwarded message -- From: John Greet (GitHub Staff) Date: 19 August 2014 12:37 Subject: Re: Storage server temporarily offline To: Menno Smits Hi Menno, Sorry about that, we're working on restoring access to the file server your repository resides on. Status updates are being posted here: https://status.github.com If you're still unable to access the repository when our status is back to green please let us know. Thanks, John -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Mentored reviewers - ACTION needed by team leads
Hi folks The mentored reviewers spreadsheet [1] has seven people down as people who would like review mentors. I'd like the team leads now to make sure that the people on their teams have a mentor assigned. The purpose of the mentor is to "review the review". The idea here is that the mentored reviewer will do a code review, and then ping their mentor. The mentor looks over the code, and looks over the review and makes sure that the mentored reviewer raised the right concerns, suggested good things and generally covered the bases that needed to be covered. The mentor then adds their LGTM to the pull request. The idea here is to spread the knowledge of juju, but also to socialise within the team how we like code reviews done, and the things that raised to the developers. Over time the reviewers learn more about what is expected, and as such, tend to produce better code themselves as they know more what is going to be picked up at review time. Cheers, Tim [1] https://docs.google.com/a/canonical.com/spreadsheets/d/1v9KB6Y4r1bMLOyB1JEs-wj_jBAvsq6EglWssa4cOx9c/edit#gid=0 -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Landing bot restrictions
Be aware that I've seen JFDI used at least a couple of times over recent weeks on PRs that *were* related to fixing a CI blocker but the person was in too much of a hurry to add the appropriate __fixes-N__ comment. That accounts for at least some of the JFDI usage (but certainly not all of it). At any rate, we should surely be preferring the "fixes" comment over "JFDI" whenever a PR is related to a CI blocker fix. On 18 Aug 2014 15:46, "John Meinel" wrote: > If it gets abused to much we could probably restrict the JODI flag to team > owners, which would restrict it to the team leads. > > John > =:-> > On Aug 18, 2014 1:57 AM, "Tim Penhey" wrote: > >> Hi all, >> >> I'm sure everyone is aware of the landing bot changes that have gone in >> from CI. While these are painful now, they are helping us improve our >> test passing percentages. >> >> There was a pressure release valve added, the "JFDI" flag, to override >> the restrictions. >> >> I've seen this flag used more often than it really should. Please don't >> just add it because you think your branch is "really important". Please >> consult with your team lead before adding this flag. >> >> Cheers, >> Tim >> >> -- >> Juju-dev mailing list >> Juju-dev@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > > -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Juju stable 1.20.5 is released.
Thank you team for staying focused, addressing issues and driving this release! Also a special thank you to all the stakeholders who put in extra hours testing and reporting bugs. Juju is definitely better as a result of everyone's efforts over the past month. On Mon, Aug 18, 2014 at 1:09 PM, Curtis Hovey-Canonical < cur...@canonical.com> wrote: > juju-core 1.20.5 > > A new stable release of Juju, juju-core 1.20.5, is now available. > This release replaces 1.20.1. > > > Getting Juju > > juju-core 1.20.5 is available for utopic and backported to earlier > series in the following PPA: > > https://launchpad.net/~juju/+archive/stable > > > Noteworthy > > This releases addresses stability and performance issues. > > > Resolved issues > > * Juju is stripping underscore from options > Lp 1243827 > > * Juju api-endpoints cannot distinguish public and private addresses > Lp 1311227 > > * API server inaccessible for roughly 5 seconds after bootstrap > Lp 1351083 > > * Juju bootstrap in an existing environment destroys the environment > Lp 1340893 > > * The jujud on state server panic misses transaction in queue > Lp 1318366 > > * Juju machine agents suiciding > Lp 1345014 > > * Juju state server database is overly large > Lp 1344940 > > * Jujud rewrites /etc/init/juju-db.conf constantly > Lp 1349969 > > * Juju writes to mongo without an actual change occurring > Lp 1345832 > > * Talking to mongo can fail with "TCP i/o timeout" > Lp 1307434 > > * Bootstrap fails if /usr/lib/juju/bin/mongod doesn't already exist > Lp 1350700 > > * Support the new v4 signing format used by the new China region > Lp 1319475 > > * Azure: secondary state servers do not load balance API server port > Lp 1347371 > > * Network error causes tools download to fail > Lp 1349989 > > * Maas provider: allow users to specify network bridge interface. > Lp 1337091 > > * ppc64 architecture miss match for MAAS ppc64el > Lp 1349771 > > * MAAS provider uses dead instance address > Lp 1353442 > > * Juju bootstrap fails if kvm-ok not in path > Lp 1342747 > > * Juju-local needs new dep dbus -- specifically to work in lxc > Lp 1343301 > > * LXC clonetemplate lock can be left stale > Lp 1311668 > > * LXC deploys broken on precise > Lp 1350011 > > * LXC template fails to stop > Lp 1348386 > > * Distribution tarball has licensing problems that prevent > redistribution > Lp 1341589 > > > Finally > > We encourage everyone to subscribe the mailing list at > juju-...@lists.canonical.com, or join us on #juju-dev on freenode. > > > -- > Curtis Hovey > Canonical Cloud Development and Operations > http://launchpad.net/~sinzui > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > -- Alexis Bruemmer Juju Core Manager, Canonical Ltd. (503) 686-5018 alexis.bruem...@canonical.com -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Juju stable 1.20.5 is released.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Woo-hoo! Looking forward to these stability improvements. Aaron On 14-08-18 04:09 PM, Curtis Hovey-Canonical wrote: > juju-core 1.20.5 > > A new stable release of Juju, juju-core 1.20.5, is now available. > This release replaces 1.20.1. > > > Getting Juju > > juju-core 1.20.5 is available for utopic and backported to earlier > series in the following PPA: > > https://launchpad.net/~juju/+archive/stable > > > Noteworthy > > This releases addresses stability and performance issues. > > > Resolved issues > > * Juju is stripping underscore from options Lp 1243827 > > * Juju api-endpoints cannot distinguish public and private > addresses Lp 1311227 > > * API server inaccessible for roughly 5 seconds after bootstrap Lp > 1351083 > > * Juju bootstrap in an existing environment destroys the > environment Lp 1340893 > > * The jujud on state server panic misses transaction in queue Lp > 1318366 > > * Juju machine agents suiciding Lp 1345014 > > * Juju state server database is overly large Lp 1344940 > > * Jujud rewrites /etc/init/juju-db.conf constantly Lp 1349969 > > * Juju writes to mongo without an actual change occurring Lp > 1345832 > > * Talking to mongo can fail with "TCP i/o timeout" Lp 1307434 > > * Bootstrap fails if /usr/lib/juju/bin/mongod doesn't already > exist Lp 1350700 > > * Support the new v4 signing format used by the new China region Lp > 1319475 > > * Azure: secondary state servers do not load balance API server > port Lp 1347371 > > * Network error causes tools download to fail Lp 1349989 > > * Maas provider: allow users to specify network bridge interface. > Lp 1337091 > > * ppc64 architecture miss match for MAAS ppc64el Lp 1349771 > > * MAAS provider uses dead instance address Lp 1353442 > > * Juju bootstrap fails if kvm-ok not in path Lp 1342747 > > * Juju-local needs new dep dbus -- specifically to work in lxc Lp > 1343301 > > * LXC clonetemplate lock can be left stale Lp 1311668 > > * LXC deploys broken on precise Lp 1350011 > > * LXC template fails to stop Lp 1348386 > > * Distribution tarball has licensing problems that prevent > redistribution Lp 1341589 > > > Finally > > We encourage everyone to subscribe the mailing list at > juju-...@lists.canonical.com, or join us on #juju-dev on freenode. > > -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJT8l8XAAoJEK84cMOcf+9hMjQH/3XEsAzVIn3KNR7LxciywHi6 5kfOfsN9Axdp9f6RVy6Q5hig/86nUfANSzEun7lj81pkUJLymBSUXcdMNDb40Sib vp4L0Qhy07kNcHUFfivxAeMeelqLXxAwsI5d4xgysDzoMDR2qz4noOUdURxbJ1RE ErvZG3MoA2xL6Yip5oMMUUvbic/ttWjed7UfYdUBTPwADkLSts/b/70fruf2yyvi NSo1jn/u8rhSmf4hrlMZkKCBaQNxSS6OHfMYqyMCBhzSoWM+8b5tJm1UlAqbiuzI eIPtHMka/Ei1A05Yvx94qyl/bkxcohZEd1dFNEi49vEUU4pXWpjleA7MLwMgApk= =5XcA -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Juju stable 1.20.5 is released.
juju-core 1.20.5 A new stable release of Juju, juju-core 1.20.5, is now available. This release replaces 1.20.1. Getting Juju juju-core 1.20.5 is available for utopic and backported to earlier series in the following PPA: https://launchpad.net/~juju/+archive/stable Noteworthy This releases addresses stability and performance issues. Resolved issues * Juju is stripping underscore from options Lp 1243827 * Juju api-endpoints cannot distinguish public and private addresses Lp 1311227 * API server inaccessible for roughly 5 seconds after bootstrap Lp 1351083 * Juju bootstrap in an existing environment destroys the environment Lp 1340893 * The jujud on state server panic misses transaction in queue Lp 1318366 * Juju machine agents suiciding Lp 1345014 * Juju state server database is overly large Lp 1344940 * Jujud rewrites /etc/init/juju-db.conf constantly Lp 1349969 * Juju writes to mongo without an actual change occurring Lp 1345832 * Talking to mongo can fail with "TCP i/o timeout" Lp 1307434 * Bootstrap fails if /usr/lib/juju/bin/mongod doesn't already exist Lp 1350700 * Support the new v4 signing format used by the new China region Lp 1319475 * Azure: secondary state servers do not load balance API server port Lp 1347371 * Network error causes tools download to fail Lp 1349989 * Maas provider: allow users to specify network bridge interface. Lp 1337091 * ppc64 architecture miss match for MAAS ppc64el Lp 1349771 * MAAS provider uses dead instance address Lp 1353442 * Juju bootstrap fails if kvm-ok not in path Lp 1342747 * Juju-local needs new dep dbus -- specifically to work in lxc Lp 1343301 * LXC clonetemplate lock can be left stale Lp 1311668 * LXC deploys broken on precise Lp 1350011 * LXC template fails to stop Lp 1348386 * Distribution tarball has licensing problems that prevent redistribution Lp 1341589 Finally We encourage everyone to subscribe the mailing list at juju-...@lists.canonical.com, or join us on #juju-dev on freenode. -- Curtis Hovey Canonical Cloud Development and Operations http://launchpad.net/~sinzui -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: First customer pain point pull request - default-hook
I don't think I fully understand the proposal there. To have such a
"something-changed" hook, we ought to have a better mechanism to tell
*what* actually changed. In other words, we have a number of hooks
that imply a state transition or a specific notification ("install",
"start", "config-changed", "leader-elected" coming, etc). Simply
calling out the charm saying "stuff changed" feels like a bad
interface, both in performance terms (we *know* what changed) and in
user experience (how do people use that!?).
I understand the underlying problem William is trying to solve but the
current proposal doesn't seem like a complete solution on its own, and
it also seems to change the existing understanding of the model
completely. The proposed default-hooks is a trivial change to the
existing well known workflow.
On Sun, Aug 17, 2014 at 2:30 AM, John Meinel wrote:
> I'd just like to point out that William has thought long and hard about this
> problem, and what semantics make the most sense (does it get called for any
> hook, does it always get called, does it only get called when the hook
> doesn't exist, etc).
> I feel like had some really good decisions on it:
> https://docs.google.com/a/canonical.com/document/d/1V5G6v6WgSoNupCYcRmkPrFKvbfTGjd4DCUZkyUIpLcs/edit#
>
> default-hook sounds (IMO) like it may run into problems where we do logic
> based on whether a hook exists or not. There are hooks being designed like
> leader-election and address-changed that might have side effects, and
> default-hook should (probably?) not get called for those.
>
> I'd just like us to make sure that we actually think about (and document)
> what hooks will fall into this, and make sure that it always makes sense to
> rebuild the world on every possible hook (which is how charm writers will be
> implementing default-hook, IMO).
>
> John
> =:->
>
>
>
> On Sat, Aug 16, 2014 at 1:02 AM, Aaron Bentley
> wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 14-08-15 04:36 PM, Nate Finch wrote:
>> > There's new hook in town: default-hook. If it exists and a hook
>> > gets called that doesn't have a corresponding hook file,
>> > default-hook gets called with the name of the original hook as its
>> > first argument (arg[1]).
>> >
>> > That's it.
>>
>> Nice! Thank you.
>>
>> Aaron
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1
>>
>> iQEcBAEBAgAGBQJT7nVvAAoJEK84cMOcf+9h90UH/RMVabfJp4Ynkueh5XQiS6mD
>> TPWwY0FVHfpAWEIbnQTQpnmkhMzSOKIFy0fkkXkEx4jSUt6I+iNYXdu8T77mA38G
>> 7IZ7HAi+dAzRCrGTIZHsextrs5VpxhdzFJYOxL+TN5VUWYt+U+awSPFn0MlUZfAC
>> 5aUuV3p3KjlHByLNT7ob3eMzR2mwylP+AS/9UgiojbUOahlff/9y83dYqkCDYzih
>> C2rlwf0Wal12svu70ifggGKWcnF/eiwSm4TQjJsfMdCfw0gSg4ICgmIbWQ78OytJ
>> AM4UBk1/Ue94dUm3YP+lcgAqJCC9GW5HksCFN74Qr+4xcnuqYoCJJxpU5fBOTls=
>> =5YwW
>> -END PGP SIGNATURE-
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
--
gustavo @ http://niemeyer.net
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: First customer pain point pull request - default-hook
That doc implies a completely different style of authoring ie. rewrite then of most extant (95%) charms using symlinks to a single implementation. There are a minority that do indeed reconsider all current state from juju each hook invocation, in which case this level of optimization is useful, but its orthogonal to solving the tedium of current authors that the pull-request is addressing. -k On Sun, Aug 17, 2014 at 6:28 AM, John Meinel wrote: > The main problem with having a hook that just fires instead of the others > is that you end up firing a hook a whole bunch of times where it > essentially "does nothing" because it is still waiting for some other hook > for it to actually be ready. The "something-changed" proposal essentially > colapses the 10 calls to various hooks into a single firing. > > William has thought much more about it, so I'd like him to fill in any > details I've missed. > > John > =:-> > > > > On Sun, Aug 17, 2014 at 1:59 PM, Nate Finch > wrote: > >> That's an interesting document, but I feel like it doesn't really explain >> the problem it's trying to solve. >> >> Why does a single entry point cause a lot of boilerplate (I presume he >> means code boilerplate)? Isn't it just a switch on the name of the hook? >> What does it mean "when a new hook is introduced"? Doesn't the charm >> define what hooks it has? And wouldn't the aforementioned switch mean that >> any new hook (whatever that means) would be ignored the same way it would >> if the hook file wasn't there? >> >> Can someone explain to me what exactly the problem is? >> >> >> On Sun, Aug 17, 2014 at 1:30 AM, John Meinel >> wrote: >> >>> I'd just like to point out that William has thought long and hard about >>> this problem, and what semantics make the most sense (does it get called >>> for any hook, does it always get called, does it only get called when the >>> hook doesn't exist, etc). >>> I feel like had some really good decisions on it: >>> https://docs.google.com/a/canonical.com/document/d/1V5G6v6WgSoNupCYcRmkPrFKvbfTGjd4DCUZkyUIpLcs/edit# >>> >>> default-hook sounds (IMO) like it may run into problems where we do >>> logic based on whether a hook exists or not. There are hooks being designed >>> like leader-election and address-changed that might have side effects, and >>> default-hook should (probably?) not get called for those. >>> >>> I'd just like us to make sure that we actually think about (and >>> document) what hooks will fall into this, and make sure that it always >>> makes sense to rebuild the world on every possible hook (which is how charm >>> writers will be implementing default-hook, IMO). >>> >>> John >>> =:-> >>> >>> >>> >>> On Sat, Aug 16, 2014 at 1:02 AM, Aaron Bentley < >>> aaron.bent...@canonical.com> wrote: >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14-08-15 04:36 PM, Nate Finch wrote: > There's new hook in town: default-hook. If it exists and a hook > gets called that doesn't have a corresponding hook file, > default-hook gets called with the name of the original hook as its > first argument (arg[1]). > > That's it. Nice! Thank you. Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJT7nVvAAoJEK84cMOcf+9h90UH/RMVabfJp4Ynkueh5XQiS6mD TPWwY0FVHfpAWEIbnQTQpnmkhMzSOKIFy0fkkXkEx4jSUt6I+iNYXdu8T77mA38G 7IZ7HAi+dAzRCrGTIZHsextrs5VpxhdzFJYOxL+TN5VUWYt+U+awSPFn0MlUZfAC 5aUuV3p3KjlHByLNT7ob3eMzR2mwylP+AS/9UgiojbUOahlff/9y83dYqkCDYzih C2rlwf0Wal12svu70ifggGKWcnF/eiwSm4TQjJsfMdCfw0gSg4ICgmIbWQ78OytJ AM4UBk1/Ue94dUm3YP+lcgAqJCC9GW5HksCFN74Qr+4xcnuqYoCJJxpU5fBOTls= =5YwW -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev >>> >>> >>> -- >>> Juju-dev mailing list >>> Juju-dev@lists.ubuntu.com >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju-dev >>> >>> >> > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > > -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: First customer pain point pull request - default-hook
JUJU_HOOK_NAME seems like a nice alternative, given we've set a precedence of a "hook environment" and seeding environment variables for hook execution. I'm fine with this implementation as much as the current proposed one. On Mon, Aug 18, 2014 at 2:57 PM, Gustavo Niemeyer < gustavo.nieme...@canonical.com> wrote: > Rather than passing it as the first argument, I suggest introducing an > environment variable: $JUJU_HOOK_NAME. This would be set irrespective > of how the hook is being called, so that the same hook can be used > both as a symlink and as a default-hook, unchanged. It also means further > spawned processes get a chance to tell the context they're running under. > > On Fri, Aug 15, 2014 at 5:36 PM, Nate Finch > wrote: > > Just wanted to let people know that Moonstone is ramping up on the > customer > > pain points, even ahead of the full spec and prioritization. I had > talked > > to Jorge and Marco about what they thought was important, and they > pointed > > out a couple of low hanging fruit. This was one of them. > > > > Many charms these days only contain one real hook script, and the rest > are > > all just symlinks to the real one. (because no one wants to write 20 > > scripts) This is kind of a pain in the ass for charm writers, and > doesn't > > work well on Windows (Windows symlink support is terrible). So, why not > > just have a default hook that gets called if the real hook isn't there? > > That's what I implemented today: > > > > https://github.com/juju/juju/pull/528 > > > > There's new hook in town: default-hook. If it exists and a hook gets > called > > that doesn't have a corresponding hook file, default-hook gets called > with > > the name of the original hook as its first argument (arg[1]). > > > > That's it. > > > > If/when this PR is accepted, Marco is planning to update charmhelpers to > > make it automatically recognize when the default-hook is called, and get > the > > hook name from arg[1] instead of arg[0], so current scripts wouldn't even > > need to change - they'd just need the new charmhelpers, rename the one > true > > script to "default-hook", and delete all their symlinks. Bam. > > > > Moonstone is very excited to be working to make Juju easier for charm > > developers, and we'll see more improvements coming next week. > > > > -Nate > > > > -- > > Juju-dev mailing list > > Juju-dev@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/juju-dev > > > > > > -- > gustavo @ http://niemeyer.net > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: First customer pain point pull request - default-hook
Rather than passing it as the first argument, I suggest introducing an environment variable: $JUJU_HOOK_NAME. This would be set irrespective of how the hook is being called, so that the same hook can be used both as a symlink and as a default-hook, unchanged. It also means further spawned processes get a chance to tell the context they're running under. On Fri, Aug 15, 2014 at 5:36 PM, Nate Finch wrote: > Just wanted to let people know that Moonstone is ramping up on the customer > pain points, even ahead of the full spec and prioritization. I had talked > to Jorge and Marco about what they thought was important, and they pointed > out a couple of low hanging fruit. This was one of them. > > Many charms these days only contain one real hook script, and the rest are > all just symlinks to the real one. (because no one wants to write 20 > scripts) This is kind of a pain in the ass for charm writers, and doesn't > work well on Windows (Windows symlink support is terrible). So, why not > just have a default hook that gets called if the real hook isn't there? > That's what I implemented today: > > https://github.com/juju/juju/pull/528 > > There's new hook in town: default-hook. If it exists and a hook gets called > that doesn't have a corresponding hook file, default-hook gets called with > the name of the original hook as its first argument (arg[1]). > > That's it. > > If/when this PR is accepted, Marco is planning to update charmhelpers to > make it automatically recognize when the default-hook is called, and get the > hook name from arg[1] instead of arg[0], so current scripts wouldn't even > need to change - they'd just need the new charmhelpers, rename the one true > script to "default-hook", and delete all their symlinks. Bam. > > Moonstone is very excited to be working to make Juju easier for charm > developers, and we'll see more improvements coming next week. > > -Nate > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > -- gustavo @ http://niemeyer.net -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: First customer pain point pull request - default-hook
On Fri, Aug 15, 2014 at 4:36 PM, Nate Finch wrote: > There's new hook in town: default-hook. If it exists and a hook gets called > that doesn't have a corresponding hook file, default-hook gets called with > the name of the original hook as its first argument (arg[1]). I look forward to deleting sylinks in my charms. Oh, but maybe I cannot because older Juju's won't support this. This would be the first time I would write a charm that only works with newer Juju. -- Curtis Hovey Canonical Cloud Development and Operations http://launchpad.net/~sinzui -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
