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