Re: First customer pain point pull request - default-hook
On Fri, Aug 15, 2014 at 4:36 PM, Nate Finch nate.fi...@canonical.com 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
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 nate.fi...@canonical.com 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
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 j...@arbash-meinel.com 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 nate.fi...@canonical.com 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 j...@arbash-meinel.com 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
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 j...@arbash-meinel.com 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 -- 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 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: 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
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
Fwd: Storage server temporarily offline
An update from Github about the current outage. -- Forwarded message -- From: John Greet (GitHub Staff) supp...@github.com Date: 19 August 2014 12:37 Subject: Re: Storage server temporarily offline To: Menno Smits menno.sm...@canonical.com 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
