Hook firing
Hi All, I am still a little confused as to when Juju decides to run hooks. Obviously hooks run when something changes. However, I see juju rujnning config-changed hooks at times when the configuration has not changed recently. So, I'd like to know how Juju decides to run the hooks and when? Any advice would be helpful, Thanks to everyone in advance, -- Best Wishes Darryl Weaver Openstack Solutions Architect, Canonical Desk: +44 (0)207 630 2400 ext 507516 Mobile: +44 (0)7720088049 GPG FPR: EA3F 3805 9347 87EC 9CBB 8C1E DADC 82C9 B16B 0403 -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Hook firing
On Wed, Sep 3, 2014 at 9:57 PM, Darryl Weaver darryl.wea...@canonical.com wrote: Hi All, I am still a little confused as to when Juju decides to run hooks. Obviously hooks run when something changes. However, I see juju rujnning config-changed hooks at times when the configuration has not changed recently. Hi Darryl, we've been seeing this too... So, I'd like to know how Juju decides to run the hooks and when? Simon was asking the same question on #juju the other day, apparently juju runs config-changed after a juju agent restart, but I don't know what's triggering that in our case. More at: http://irclogs.ubuntu.com/2014/09/01/%23juju.html#t15:20 Any advice would be helpful, Thanks to everyone in advance, -- Best Wishes Darryl Weaver Openstack Solutions Architect, Canonical Desk: +44 (0)207 630 2400 ext 507516 Mobile: +44 (0)7720088049 GPG FPR: EA3F 3805 9347 87EC 9CBB 8C1E DADC 82C9 B16B 0403 -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Hook firing
On 3 September 2014 13:12, Michael Nelson michael.nel...@canonical.com wrote: On Wed, Sep 3, 2014 at 9:57 PM, Darryl Weaver darryl.wea...@canonical.com wrote: Hi All, I am still a little confused as to when Juju decides to run hooks. Obviously hooks run when something changes. However, I see juju rujnning config-changed hooks at times when the configuration has not changed recently. Hi Darryl, we've been seeing this too... So, I'd like to know how Juju decides to run the hooks and when? Simon was asking the same question on #juju the other day, apparently juju runs config-changed after a juju agent restart, but I don't know what's triggering that in our case. More at: http://irclogs.ubuntu.com/2014/09/01/%23juju.html#t15:20 Also, at machine restart (which I suspect is due primarily to the agent restart case, of course). I don't know if there is a docs page that lists all this explicitly, but it would be nice is if there was, for reference. -- Simon -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Hook firing
Even if the config-changed hook was run when it was not supposed to, it shouldn't have caused any changed if values were not moved to anything different. If it did, then I believe we're having an idempotency problem there. Still, hooks running when they shouldn't is not what expected. On 09/03/2014 08:03 AM, Andreas Hasenack wrote: On Wed, Sep 3, 2014 at 10:00 AM, Simon Davy bloodearn...@gmail.com mailto:bloodearn...@gmail.com wrote: On 3 September 2014 13:42, Darryl Weaver darryl.wea...@canonical.com mailto:darryl.wea...@canonical.com wrote: Thanks the IRC logs are pretty helpful. We are seeing the same issue here at Sky, config-changed hook runs At random times. This is when there are no user changes to the Juju config and no reboots happening. It is possible the juju agent restarted, but I don't think so, but will have to collect some evidence first. Right, this is what I expect is happening to us, but tracking it is tricky. We only noticed because our charm has an implementation issue in that it tries to reuse an authtoken that has a 24hr expiry. It might be helpful if some one on juju-core could details if there are specific circumstances where the juju agent may restart? Look in /var/log/syslog and /var/log/upstart for evidence of this restart. Maybe it died, and then upstart will start it again to keep it running. -- José Antonio Rey -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Hook firing
Given CAP theorem any message can really only be at most once or at least once. You can never guarantee exactly only once. I'm sure juju is biased to the at least once for hooks (hence why it runs at agent restart because it hasn't been around to know for sure that nothing changed in the interim). So while there could be a bug, hooks should be written with a design that they may get called more than once for the same state. (At most once would mean that changes could occur that you never see, which is usually a far worse failure mode.) John =:- On Sep 3, 2014 6:39 PM, Simon Davy bloodearn...@gmail.com wrote: Arg, resending reply to list On 3 September 2014 14:27, José Antonio Rey j...@ubuntu.com wrote: Even if the config-changed hook was run when it was not supposed to, it shouldn't have caused any changed if values were not moved to anything different. If it did, then I believe we're having an idempotency problem there. I suspect this has been happening for a while, but unnoticed, as most case the hook will run fine. In our cases, an implementation issue with tokens that expire after a fixed period of 24hr were being reused (to fetch build assets from swift), so we noticed the run as it tripped an error state, which we have nagios alerts for. We are fixing our charms to not have this problem. But we raised the questions for 2 reasons: 1) We want to understand why it's happening. Its probably ok that it does happen, but it's the apparent randomness that is confusing. 2) If a charm has relied on juju's idempotency provisions exclusively, then a config-changed hook's implementation may *always* restart whatever server process the charm is managing even though nothing has actually changed (we specifically avoid this in our charms where possible). This could lead to unnecessary service wide restarts, which is undesirable in many circumstances, especially with no current way to control those. So yeah, we'd like to get to the bottom of the cause for 1), for our own understand the system, but perhaps 2) needs some consideration from juju-core. Thanks -- Simon -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: [Ecosystem-engineering] Proposal: New review queue and review process
I wanted to update everyone to let them know the first iteration of this review queue is out. While it's a very bare MVP it's the direction I'm taking the review queue in. I've written a blog post, http://marcoceppi.com/2014/09/a-new-charm-review-queue/ which outlines the features and the short term roadmap for the queue. There are still quite a few things which need to be implemented, mainly the top navigation does nothing and a few queues are empty but quite a few new items have showed up in the queue! Feedback, suggestions, comments, and pull requests welcome! Thanks, Marco Ceppi On Tue, Aug 26, 2014 at 4:34 PM, Cory Johns cory.jo...@canonical.com wrote: Marco, I just wanted to follow up and say that this proposal sounds great to me. The only addition I would make is clarifying what the logic is when there are conflicting reviews; e.g., if you mark something as TRIAGED (I don't suppose there's any possibility of getting a FIX ACCEPTED status added?) but I mark it as INCOMPLETE, does it get hidden / sorted down on the main review queue or not? In addition to having it formally defined, I also think it should be clearly and easily visible from the review queue itself; that is, there should be an obvious How Does This Work? link that displays all of this information for reviewers and reviewees alike to see. Thanks for working on this. I think this will be a definite improvement to the review process. - Cory On Mon, Aug 18, 2014 at 1:59 PM, Marco Ceppi marco.ce...@canonical.com wrote: Hi everyone, I'm going to jump right in with this email be briefly describing a short summary of the issues people have brought up around the review process and the review queue, then outline what my proposal to fix this is, outline the new process for feedback prior to implementation, finally listing actions left to implement this. The current review queue has been an indispensable tool for helping maintain the ecosystem as it is today and the code that the new review queue is built on shares a lot of the same logic/concept. However, since we've grown a lot in the last few years this is an attempt to help bullet proof the process as we move forward. # Issues One of the biggest feedback we've gotten from users lays along the lines of where is my charm in the review process and what are next actions. Currently, the review queue doesn't illuminate any next actions for a user. As queue times increase this can leave a poor user experience. Another feedback point we have seen recently are reviews being lost in the process. This is arguably the primary reason behind a revamp of the review queue and review process to ensure a submitted item for review does not get lost in the process. These are two primary examples, while a more exhaustive list exists these items have the most impact for users contributing to the ecosystem. # Solution in Development For the past two weeks I've been working on a replacement review queue which uses a lot of the initial code from the current review queue. A few major points: * Ingests all bugs and merges regardless of state, owner, or series * Tracks reviews once ingested * Decoupled from charmworld * API access * Detailed statistic gathering * Track reviews per user * Track merges from LaunchPad and Github * Priority sorting of reviews * Track multiple queues of work at once * Modular code base for extensiblity This is what has been done for the first version of the review queue which I plan to release this week for review. However, as the review queue is currently tracking ALL items (and not items for which only a charmer can take action against) we will need to update the review process for charmers and charm-contributors (Jr. Charmers) alike. Those proposed changes are outlined below: # Proposed review policy changes ## New Charms With the new review queue, charmers being assigned to the bug is no longer a requirement for it to appear in the queue. Any bug against the charms distribution which isn't targeted at a source package (charm) will be ingested. Currently, NEW and FIX COMMITTED charms appear in the queue. Going forward, LP statuses will have more effect on the queue. NEW status will appear in a separate queue. These are charms that are just being submitted. The new queue is designed to get first contact to that user faster. TRIAGED should be what a reviewer (who isn't a charmer) moves the bug status to if it passes an initial review FIX COMMITTED will indicate that the charm author has received review items and is ready for another review, INCOMPLETE or IN PROGRESS indicates that someone has reviewed the charm and it needs work to complete. FIX RELEASED when the charm has been promulgated. All other statuses indicate an abandoned/closed review. ### Proposed workflow 1. User submits a new charm by opening a bug
Getting the API server URL in workers
I'm working on moving all tools downloads to download from the API server. There will are a few APIs that return tools: - Upgrader.Tools - Client.FindTools - Provisioner.FindTools These APIs will need to return URLs pointing at the API server. I'm intending to change the facade constructors to take a parameter struct, and extend it with the API server's root URL (i.e. https://address:port/environment/uuid), where the address is the one used by the client to connect. Any reason I should not go ahead and do that? This will probably make it easier to slot in a Restarter or whatever as well. Cheers, Andrew -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Getting the API server URL in workers
It feels like this should be something that the API server is looking up in the database/some sort of query, not just munging a URL. I'm fine with having a Params struct, though I worry that it isn't really appropriate to be passing all possible Params to all facades. They already have a State connection, I'd like us to at least be designing the layering appropriately. I feel like state.State is intended to be where Knowledge resides. Why isn't what we want there? John =:- On Sep 3, 2014 6:03 PM, Andrew Wilkins andrew.wilk...@canonical.com wrote: I'm working on moving all tools downloads to download from the API server. There will are a few APIs that return tools: - Upgrader.Tools - Client.FindTools - Provisioner.FindTools These APIs will need to return URLs pointing at the API server. I'm intending to change the facade constructors to take a parameter struct, and extend it with the API server's root URL (i.e. https://address:port/environment/uuid), where the address is the one used by the client to connect. Any reason I should not go ahead and do that? This will probably make it easier to slot in a Restarter or whatever as well. Cheers, Andrew -- 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
Changing gocheck fetch url
Hey, It seems that gocheck is still updated from https://launchpad.net/gocheck. However, as you can see if you check the page the project has moved to github(https://github.com/go-check/check) and this results in us not having the latest updates. So far I've tried doing a global sed in a backup go/src directory and everything seems to be working fine test-wise. However we need to commit everything in the respective repositories for godeps to work correctly. Is there any particular way we should go about doing this? I can get patches ready for every particular repo if needed. Bogdan -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Getting the API server URL in workers
On Wed, Sep 3, 2014 at 4:49 PM, John Meinel j...@arbash-meinel.com wrote: It feels like this should be something that the API server is looking up in the database/some sort of query, not just munging a URL. I'm fine with having a Params struct, though I worry that it isn't really appropriate to be passing all possible Params to all facades. They already have a State connection, I'd like us to at least be designing the layering appropriately. I feel like state.State is intended to be where Knowledge resides. Why isn't what we want there? Yeah, constructing it based on the current known addresses of the state servers seems best. Do we maybe actually want a list of URLs where the tools are available? That'd be the HA thing to do, I suspect. Cheers William John =:- On Sep 3, 2014 6:03 PM, Andrew Wilkins andrew.wilk...@canonical.com wrote: I'm working on moving all tools downloads to download from the API server. There will are a few APIs that return tools: - Upgrader.Tools - Client.FindTools - Provisioner.FindTools These APIs will need to return URLs pointing at the API server. I'm intending to change the facade constructors to take a parameter struct, and extend it with the API server's root URL (i.e. https://address:port/environment/uuid), where the address is the one used by the client to connect. Any reason I should not go ahead and do that? This will probably make it easier to slot in a Restarter or whatever as well. Cheers, Andrew -- 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: Question about the start hook
Hi Tim, Great question, sorry it took me so long to get back to you. I have an assumption that all hooks run serially on a single unit regardless of service group, etc. However, I want to say I've seen some kind serialization between peers. I've cc'd the Juju core mailing list and the regular juju mailing list to help correct and clarify these statements and shed some light once and for all. Finally, once it's been known, I'll be updating the author docs to detail the execution pattern in detail. Thanks, Marco Ceppi On Sat, Aug 30, 2014 at 6:31 AM, Humphrey, Timothy L (RIS-DAY) timothy.humph...@lexisnexis.com wrote: Marco, Do you know the answer to my question, below? Or should I re-phase it? Tim -Original Message- From: jorge.cas...@gmail.com [mailto:jorge.cas...@gmail.com] On Behalf Of Jorge O. Castro Sent: Friday, August 29, 2014 10:18 AM To: Humphrey, Timothy L (RIS-DAY); Marco Ceppi Subject: Re: Question about the start hook That's a good question! CCing in Marco, who should know. On Fri, Aug 29, 2014 at 10:16 AM, Humphrey, Timothy L (RIS-DAY) timothy.humph...@lexisnexis.com wrote: Jorge, I am using juju charm to deploy to aws, an hpcc cluster, which is several instances that work together to complete some job. In my start hook, I'm copying files from S3 to each instance. And, once all files are copied to all instances, I perform an operation in my hpcc-cluster-relation-joined that tells the master instance that all files are copied to all instances. So, my question is, Do all instances complete the start hook before any instance begins the hpcc-cluster-relation-joined hook? Or is there a way to make this be true? Sincerely, Tim - The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message may be an attorney-client communication and/or work product and as such is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
A beginner's adventure in Charm authoring
I am working on writing a Juju charm to deploy the Discourse discussion forum software using their new docker image install process. This was my first charm, and I'm writing it in Go, because I like Go. This means I can't use the python charm helpers, but since I don't actually know what they do, that doesn't bother me much :) Also, it's a good test to see how hard it is to write the charm without the helpers. Now that I know all the quirks, I think my second charm would be a lot easier to write than my first. There's just a lot to ingest for that first charm. However, even this first charm was not that bad. Now, I have been working on Juju-core for a year, so I know how a lot of stuff works that outsiders would not. There were still some hurdles to cross, which I detail below, but most were just annoyances, not show stoppers. Sorry for the length and the randomness, this is based on notes taken as I was working on the charm in small chunks of time over several days. I started by looking at the Charm Walkthrough... this was actually a mistake, because that skips over some parts above it in the docs (namely metadata.yaml, /hooks, and config.yaml)... and I thought I was starting from the beginning and didn't see anything about those things, and so didn't think they were documented. This is partially my fault for not looking through the docs more carefully, but... maybe the walkthrough should talk about those things first? :) Have I mentioned how much I hate YAML? Is it possible to write the config in JSON or something instead? JSON's no picnic either, but at least it doesn't care about white space. I'd recommend TOML, but I doubt the conservative dev-ops people would go for it. Ideally we'd support all three (and other formats if people wanted). The docs on hook tools https://juju.ubuntu.com/docs/authors-hook-environment.html#hook-tools is missing one very important piece of information: hook tools are executables that exist in the $PATH on the machine where the unit is deployed ... it took me a while to understand that these were actual executables I could run from my hook's code and not like functions or something from somewhere (where?). We should document where the charm files are actually deployed on disk. I ended up figuring this out from one of the screenshots of charm debugging which had the path shown, but there were times when I just wanted to ssh into the machine and make sure the charm was deploying the stuff I thought it was deploying. Deploying a local charm is needlessly complex. Why do I need to create a special directory structure, move my code under there, set --repository and write local:foo and even then it has to go scanning through the directory, looking for a charm with the right name in the metadata.yaml. Why can't I just say deploy the charm in this directory? e.g. juju deploy --local=path Bam, done. The docs says the environment variables https://juju.ubuntu.com/docs/authors-hook-environment.html#environment-variables are always available except... they're not. They're not when I SSH into the machine. They're not set when I do juju debug-hooks either (at least before a hook fires). The reason this confused me is that most of these environment variables seem like they should be static, and could easily just be set all the time, so I sort of assumed they were. Now that I think about it, they really can't be set all the time, in the case of hulk-smashed charms, etc... but newbie charm authors won't be thinking of that. We should make it more clear that these environment variables are only available to the code running the hook when the hook is actively running. Why does the config file for juju-deploy --config need to have servicename: at the beginning of the file? Of course it's for that servicename, that's why I gave it to this deploy command. If there's no top-level value, just assume the whole thing is for this service. This took me a while to figure out... I sort of assumed the config file was just an easy shorthand so I didn't have to type a bunch of stuff out on the command line. It's really annoying to have to type the unit name for debug-hooks, rather than just the service. I don't care what unit, they're all the same, right? And if there's just one (which is most of the time when you're debugging), me telling you which unit is spurious anyway... just go to the only one that exists. Also, juju debug-hooks says you're supposed to give it the hook name, but it doesn't seem like that actually does anything. I can leave it off and it seems to have the exact same behavior. Juju debug-hooks is really confusing: When my install hook was broken, and I did juju debug-hooks unit install it brings me into a remote terminal prompt with zero information, no files in the local directory, and nothing else to tell me what to do. I went back to look at the docs and it said I had to run juju resolved --retry hook. So I exited out of the prompt
Copyright information in headers
Hi folks The question recently came up in reviews as to whether we should be updating the date in the copyright statement in the file header when we make a change to the code in that file. I sought clarification from Robie Basak, who previously had provided input on licensing issues and compliance for getting Juju included in trusty. Below is what he said. TL;DR; It doesn't really matter, we just need to agree on a policy. It is suggested though that we do update the date when we make a change. Agree? snip What's our policy for dates in copyright headers? // Copyright 2012, 2013 Canonical Ltd. // Licensed under the AGPLv3, see LICENCE file for details. From the point of view of acceptability for Ubuntu, it doesn't particularly matter, and I don't believe it'll cause any issue for us whatever you do here. I'll certainly be happy to upload whether or not you update the date. I'll try to explain my perspective on this, but I'm not entirely confident that there isn't something I'm missing for the broader picture, so note that I Am Not A Lawyer, etc. For the above, do we need to add 2014 if we modify the file this year? Or is the date just meant to be the year the file was first published? I think it's meant to be the sum of all the copyright claims on the file. So if you add some new code, you have a copyright claim on the new code in the newer year in which you made it. AIUI, the purpose of the date is that since copyright expires (theoretically, anyway), updating the date updates the copyright claim, which would give us more control in the (eventual) event that copyright expires. In practice, IMHO this is never going to matter since nobody is going to care about the copyright on a piece of software that is that old anyway. But I suppose laws could change, so the right thing to do would be to add a new year whenever you make a change in a new year on a per-file file basis. BTW, it's common to fold 2012, 2013, 2014 to just 2012-2014. But I don't particularly care for upload purposes. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Copyright information in headers
I think this is needless busy work, I vote that as long as there is a copyright header with _a_ year, that is sufficient. On Thu, Sep 4, 2014 at 7:50 AM, Ian Booth ian.bo...@canonical.com wrote: Hi folks The question recently came up in reviews as to whether we should be updating the date in the copyright statement in the file header when we make a change to the code in that file. I sought clarification from Robie Basak, who previously had provided input on licensing issues and compliance for getting Juju included in trusty. Below is what he said. TL;DR; It doesn't really matter, we just need to agree on a policy. It is suggested though that we do update the date when we make a change. Agree? snip What's our policy for dates in copyright headers? // Copyright 2012, 2013 Canonical Ltd. // Licensed under the AGPLv3, see LICENCE file for details. From the point of view of acceptability for Ubuntu, it doesn't particularly matter, and I don't believe it'll cause any issue for us whatever you do here. I'll certainly be happy to upload whether or not you update the date. I'll try to explain my perspective on this, but I'm not entirely confident that there isn't something I'm missing for the broader picture, so note that I Am Not A Lawyer, etc. For the above, do we need to add 2014 if we modify the file this year? Or is the date just meant to be the year the file was first published? I think it's meant to be the sum of all the copyright claims on the file. So if you add some new code, you have a copyright claim on the new code in the newer year in which you made it. AIUI, the purpose of the date is that since copyright expires (theoretically, anyway), updating the date updates the copyright claim, which would give us more control in the (eventual) event that copyright expires. In practice, IMHO this is never going to matter since nobody is going to care about the copyright on a piece of software that is that old anyway. But I suppose laws could change, so the right thing to do would be to add a new year whenever you make a change in a new year on a per-file file basis. BTW, it's common to fold 2012, 2013, 2014 to just 2012-2014. But I don't particularly care for upload purposes. -- 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: Copyright information in headers
I've been asking for updates in my reviews. I'm happy to stop if the consensus is we don't need to. Once we get an agreement on policy, let's put it in the style guide. On 04/09/14 09:55, Gustavo Niemeyer wrote: I suggest not updating it. Updates on the same line will conflict, and cause completely unnecessary headaches. These files are under revision control, so there are better proofs of when it was changed than just that header. Then, in a decade or two, if somebody cares, update them all at once. On Wed, Sep 3, 2014 at 6:50 PM, Ian Booth ian.bo...@canonical.com wrote: Hi folks The question recently came up in reviews as to whether we should be updating the date in the copyright statement in the file header when we make a change to the code in that file. I sought clarification from Robie Basak, who previously had provided input on licensing issues and compliance for getting Juju included in trusty. Below is what he said. TL;DR; It doesn't really matter, we just need to agree on a policy. It is suggested though that we do update the date when we make a change. Agree? snip What's our policy for dates in copyright headers? // Copyright 2012, 2013 Canonical Ltd. // Licensed under the AGPLv3, see LICENCE file for details. From the point of view of acceptability for Ubuntu, it doesn't particularly matter, and I don't believe it'll cause any issue for us whatever you do here. I'll certainly be happy to upload whether or not you update the date. I'll try to explain my perspective on this, but I'm not entirely confident that there isn't something I'm missing for the broader picture, so note that I Am Not A Lawyer, etc. For the above, do we need to add 2014 if we modify the file this year? Or is the date just meant to be the year the file was first published? I think it's meant to be the sum of all the copyright claims on the file. So if you add some new code, you have a copyright claim on the new code in the newer year in which you made it. AIUI, the purpose of the date is that since copyright expires (theoretically, anyway), updating the date updates the copyright claim, which would give us more control in the (eventual) event that copyright expires. In practice, IMHO this is never going to matter since nobody is going to care about the copyright on a piece of software that is that old anyway. But I suppose laws could change, so the right thing to do would be to add a new year whenever you make a change in a new year on a per-file file basis. BTW, it's common to fold 2012, 2013, 2014 to just 2012-2014. But I don't particularly care for upload purposes. -- 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: Getting the API server URL in workers
On Wed, Sep 3, 2014 at 11:37 PM, William Reade william.re...@canonical.com wrote: On Wed, Sep 3, 2014 at 4:49 PM, John Meinel j...@arbash-meinel.com wrote: It feels like this should be something that the API server is looking up in the database/some sort of query, not just munging a URL. I'm fine with having a Params struct, though I worry that it isn't really appropriate to be passing all possible Params to all facades. They already have a State connection, I'd like us to at least be designing the layering appropriately. I feel like state.State is intended to be where Knowledge resides. Why isn't what we want there? Yeah, constructing it based on the current known addresses of the state servers seems best. Do we maybe actually want a list of URLs where the tools are available? That'd be the HA thing to do, I suspect. There's one place we're doing that already, and that's in the cloud-init script. The other use of the tools URL is in the upgrader, where it doesn't really matter assuming it returns a URL to the same API server as returned the metadata. The client will be severed anyway, and reconnect and re-query and get another URL. Also, multiple URLs would be useless for older clients upgrading. Anyway, I'll have another dig at it. Cheers, Andrew Cheers William John =:- On Sep 3, 2014 6:03 PM, Andrew Wilkins andrew.wilk...@canonical.com wrote: I'm working on moving all tools downloads to download from the API server. There will are a few APIs that return tools: - Upgrader.Tools - Client.FindTools - Provisioner.FindTools These APIs will need to return URLs pointing at the API server. I'm intending to change the facade constructors to take a parameter struct, and extend it with the API server's root URL (i.e. https://address:port/environment/uuid), where the address is the one used by the client to connect. Any reason I should not go ahead and do that? This will probably make it easier to slot in a Restarter or whatever as well. Cheers, Andrew -- 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: Copyright information in headers
On Thu, Sep 4, 2014 at 5:50 AM, Ian Booth ian.bo...@canonical.com wrote: Hi folks The question recently came up in reviews as to whether we should be updating the date in the copyright statement in the file header when we make a change to the code in that file. I sought clarification from Robie Basak, who previously had provided input on licensing issues and compliance for getting Juju included in trusty. Below is what he said. TL;DR; It doesn't really matter, we just need to agree on a policy. It is suggested though that we do update the date when we make a change. Agree? snip What's our policy for dates in copyright headers? // Copyright 2012, 2013 Canonical Ltd. // Licensed under the AGPLv3, see LICENCE file for details. From the point of view of acceptability for Ubuntu, it doesn't particularly matter, and I don't believe it'll cause any issue for us whatever you do here. I'll certainly be happy to upload whether or not you update the date. I'll try to explain my perspective on this, but I'm not entirely confident that there isn't something I'm missing for the broader picture, so note that I Am Not A Lawyer, etc. For the above, do we need to add 2014 if we modify the file this year? Or is the date just meant to be the year the file was first published? I think it's meant to be the sum of all the copyright claims on the file. So if you add some new code, you have a copyright claim on the new code in the newer year in which you made it. AIUI, the purpose of the date is that since copyright expires (theoretically, anyway), updating the date updates the copyright claim, which would give us more control in the (eventual) event that copyright expires. In practice, IMHO this is never going to matter since nobody is going to care about the copyright on a piece of software that is that old anyway. But I suppose laws could change, so the right thing to do would be to add a new year whenever you make a change in a new year on a per-file file basis. BTW, it's common to fold 2012, 2013, 2014 to just 2012-2014. But I don't particularly care for upload purposes. Depending on the country, copyright notices require the first year of publication. I'm not aware of any that *require* the full range, but in some cases it is recommended to have it on ongoing works as a claim of authorship. As Gustavo says, we have this in revision control. We work in the open. Let's not get distracted with unnecessary work. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Question about the start hook
My understanding is that the proposed Leader spec is likely to help with this, as a leader unit could coordinate between its peers which one should work next. Otherwise, it is just up to the charm peer relation to coordinate anything like this. So in peer-relation-changed you could say that you want to perform the next step, but you are waiting for your other peers, etc. I think there is also a limitation that until everything has started and joined you don't actually know how many other units there are going to be. Though I think this is part of the it isn't truly knowable because something may fail to come up, you may add units at a later time, etc. I do think we could do a better job of exposing what we think the number of units will be real soon now. John =:- On Wed, Sep 3, 2014 at 11:16 PM, Marco Ceppi marco.ce...@canonical.com wrote: Hi Tim, Great question, sorry it took me so long to get back to you. I have an assumption that all hooks run serially on a single unit regardless of service group, etc. However, I want to say I've seen some kind serialization between peers. I've cc'd the Juju core mailing list and the regular juju mailing list to help correct and clarify these statements and shed some light once and for all. Finally, once it's been known, I'll be updating the author docs to detail the execution pattern in detail. Thanks, Marco Ceppi On Sat, Aug 30, 2014 at 6:31 AM, Humphrey, Timothy L (RIS-DAY) timothy.humph...@lexisnexis.com wrote: Marco, Do you know the answer to my question, below? Or should I re-phase it? Tim -Original Message- From: jorge.cas...@gmail.com [mailto:jorge.cas...@gmail.com] On Behalf Of Jorge O. Castro Sent: Friday, August 29, 2014 10:18 AM To: Humphrey, Timothy L (RIS-DAY); Marco Ceppi Subject: Re: Question about the start hook That's a good question! CCing in Marco, who should know. On Fri, Aug 29, 2014 at 10:16 AM, Humphrey, Timothy L (RIS-DAY) timothy.humph...@lexisnexis.com wrote: Jorge, I am using juju charm to deploy to aws, an hpcc cluster, which is several instances that work together to complete some job. In my start hook, I'm copying files from S3 to each instance. And, once all files are copied to all instances, I perform an operation in my hpcc-cluster-relation-joined that tells the master instance that all files are copied to all instances. So, my question is, Do all instances complete the start hook before any instance begins the hpcc-cluster-relation-joined hook? Or is there a way to make this be true? Sincerely, Tim - The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message may be an attorney-client communication and/or work product and as such is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. -- 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: my first charm
On Thu, Sep 4, 2014 at 3:46 AM, Eric Snow eric.s...@canonical.com wrote: Hi all, Here's a write-up on my experience writing a charm for the first time. In summary, it wasn't nearly as bad as I expected it to be. The docs were super useful (both the getting-started side of things and later for reference). There really wasn't a time that I got stuck for more than a minute or two (other than with bugs in the reviewboard charm). Thanks for writing this up. Keep in mind that I'm still rather unfamiliar with charming and likely have missed stuff, so take any criticisms with a grain of salt (though they may still represent common misconceptions). Also note that I have a few months under my belt with the juju code base and community, so I had some advantages that other first-time charmers might not enjoy. Also note that nearly all my experience was using local provider. I expect that if I had been using some remote provider (like EC2) the whole time, the experience would have been much more frustrating. I'll break down my experience below (doing my best from memory). The repo history [1] gives a vague look at how things progressed. Feel free to ask me all about it, particularly if anything is unclear or it feels like anything is missing from my story. -eric [1] starting at https://bitbucket.org/ericsnowcurrently/rb_oauth_extension/commits/91c32dc82d7318634e9428eec48e68a687089eba = Summary -- The reviewboard-oauth charm provides the rb_oauth reviewboard extension, both installing it and registering it. At first it was stand-alone, but I could tell something wasn't right with that approach and soon discovered about subordinate charms. The tricky part of the charm is thus when it's related to a reviewboard service (that's when we directly modify reviewboard's settings). Writing the hooks was pretty straight-forward. I took advantage of several existing charms (apache2, reviewboard, postgresql, django), frequently referring to them for examples of how to do stuff. Between those and the docs, it was relatively easy to figure out what to do and where to do it. The charm helpers (especially hookenv.py) were indispensable. Not only were they directly useful but the code there helped me understand how things fit together. While it's not the end of the world (and probably an improvement over yesteryear), writing the hooks involved what seemed to me like a lot of unnecessary boilerplate. In the end I took at stab at factoring out a lot of the boilerplate into external modules so that my actual top-level code was much more focused. The most frustrating part (in the mild sense of the word) was in managing the env/service lifecycle from the commandline, particularly where one of the charms is somewhat fragile. For example, it wasn't obvious how to remove a service that was in an error state. There is no --force option on juju remove-service and I didn't realize you may have to call juju resolved more than once. It wasn't until someone pointed that out that I was able to progress much (I was having to destroy-env and then bootstrap/deploy/relate/etc.). Overall, I found the experience of writing a charm to be pleasant and mostly snag-free. My charm is non-trivial, but still not all that complex, so my experience may or may not be all that representative. Furthermore, there is functionality that I did not add in new/existing hooks which I probably should at some point, so perhaps I would have had more trouble. However, I don't think that would have been the case. So again, writing my first charm was a good experience. My Charm -- https://jujucharms.com/~ericsnowcurrently/trusty/reviewboard-oauth/ https://jujucharms.com/~ericsnowcurrently/precise/reviewboard-oauth/ Repo -- https://bitbucket.org/ericsnowcurrently/rb_oauth_extension/src/default/charm/reviewboard-oauth/ (mercurial) (for the charm store: https://code.launchpad.net/~ericsnowcurrently/charms/trusty/reviewboard-oauth/trunk ) Helpful -- * the docs were great * the charm helpers (e.g. hookenv.py) made things much easier Could Be Better (mostly nitpicks) -- * it wasn't clear at first how config.yaml related to my deployed charm (though it became clear quickly) * I had to rely on a blog post (thanks Nate!) for an explanation on personal namespaces * regarding hooks, there's a lot of boilerplate that could probably be eliminated (see my final Charm abstraction) * the relationship between hooks and juju commands (e.g. deploy, set) could be clearer - the execution path from command to hook - the role of jujuc - which hooks are triggered by each command and in which order * interacting with related charms still isn't super clear to me * the lifecycle status of a charm isn't super clear (and certainly not well defined) from a
