New Charm: Hectane

Bug #1504375 reported by Nathan Osman
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Juju Charms Collection
Fix Released
Undecided
Unassigned

Bug Description

Hectane is a lightweight SMTP client written in Go. Please view the README in the branch for more information about the application and how to deploy the charm. The branch also includes tests.

Revision history for this message
Charles Butler (lazypower) wrote :

Greetings Nathan,

Thank you for your submission of the Hectane charm to the Juju Charm store! I've taken a look at the Hectane charm, and I have the following notes:

Your charm passes proof, and the included bundled tests. This is a great first step during the review process. I especially enjoyed that you bundled an amulet test suite with the charm. I see nothing inherently bad about how the charm is written.

I do have some minor suggestions for improvements to the overall charm however:

As this is an API, its completely reasonable to host the service behind a load balancer, and horizontally scale the daemon. This is a fairly trivial modification by implementing a provides: relation, using the http interface. This will allow you instant connections to the Apache2, HAPROXY, and NGINX (non-recommended) charms.

Furthermore, you may wish to explore adding a relation to hectane to provide the API credentials (username,password, endpoint) to other applications via relationship by defining your own interface. eg:

provides:
    email-api:
        interface: hectane

This will allow consumers of the hectane charm to relate to it, and get credentials so their workload can consume the hectane email api with no additional configuration on their part.

I would also like to see more comprehensive test coverage in terms of passing in a self signed certificate, and username/password - then verification through the amulet test. A general rule of thumb is: if you have a configuration option, it should be exercised in the amulet test.

Additionally, I see that you've inlined the github release URLS and HASH's, this is fine for now, but it would probably be a better idea to move this as a config option. This allows users who may be behind an EGRESS firewall to point to a payload behind their firewall, and their proper HASHSUM. It also eases updates when a new release comes along, and the user can upgrade via config.

I've promulgated the hectane charm, and you can view its Lauchpad project here: https://code.launchpad.net/~charmers/charms/precise/hectane/trunk
and monitor for charm bugs here:
https://bugs.launchpad.net/charms/+source/hectane

Thanks a ton for the submission, and congratulations on making it into the charm store!

Changed in charms:
status: New → Fix Released
Revision history for this message
Charles Butler (lazypower) wrote :

additionally the charm is deployable now as:

juju deploy cs:precise/hectane

Sorry about the follow up, all the best!

Revision history for this message
Nathan Osman (george-edison55) wrote :

Thanks for reviewing the charm!

I'm hoping to release a new version of the application soon so I'll update the charm as well. I completely understand why someone might want to use a load balancer since the API can receive emails a lot faster than it can send them. I will also add tests for authentication / TLS since those are likely to be commonly used options.

When creating the charm, I wasn't sure whether I should be creating a new interface or not. Hectane clearly documents the API, but it is not a recognized standard by any means, so it would be the only charm providing the interface (for the foreseeable future). As long as the HTTP(S) port is exposed, other charms can connect to it directly. But if you think it should provide a relationship, I'll implement one.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.