request for charm inclusion: tomcat-webapp

[Philip Brown]

will attempt to follow documentatoin to link my code branch in a sec...

[Cory Johns (johnsca)]

Philip,

Thank you for your submission!

It seems like these actions could reasonably be folded directly into the tomcat charm, but doing it this way certainly does give a good example of how an application-specific charm would use the interface, and it of course serves as a fall-back for prototyping or otherwise deploying uncharmed apps. Maybe once we have an example or two of application-specific charms, we could revisit folding this into the tomcat charm itself.

Charm proof doesn't raise any errors, but it does raise a warning about "categories" being deprecated in favor of "tags" which might be nice to address.

More critically, I see that you don't do any checksum or hash verification on the downloaded WAR file. There should be an option to provide a SHA checksum (and possibly to specify the checksum type) and the downloaded WAR should be verified against it to ensure that there was no corruption or malicious modification of the package in transit.

Finally, since you already have the action for installing and uninstalling the selected WAR, would it perhaps make sense to move the config options to be action parameters instead? This would allow you to deploy multiple different WARs by calling the install action repeatedly. Technically, you could do this currently by repeatedly changing the config value, but I think putting the params directly on the action makes it much more clear that you're performing an additive operation and thus provides a better UX.

Again, thank you for your contribution, and I look forward to working with you to address the checksum verification issue, as well as the other suggestions, to get this promulgated.

[Philip Brown (bolthole)]

Hello Cory,
Some thoughts on what you wrote.
First of all, the checksum sounds like a good idea. I'll implement that at some point.
As to the rest:
I think it should be separate from the tomcat charm for multiple reasons:

1. because if someone wants to run multiple apps on the same tomcat instance, i think it is cleaner to have 1 charm instance==1 app.
2. it isnt actually specific to tomcat, in principle :-} so really, the name should be changed. But if juju gets more webcontainer charms (and it really should. for example, jboss or something?) it could be used just the same way, I think

For the same reason as #1 above, I think having those parameters to actions, is a bad idea. I think there should be 1 unique charm for each unique app.

It sounds like you are suggesting that the same charm instance be used to deploy multiple apps, by means of calling the install action multiple times to the same location, but different options each time?

[Cory Johns (johnsca)]

Philip,

That was what I was suggesting, based on the current behavior (i.e., if you change the config option without first calling the uninstall action, it will deploy a second, third, etc. WAR).

I am generally +1 to one WAR per deployed service, but I would argue then that it makes more sense for this to be a base layer and not a charm on its own. If you're not familiar with the layered approach to charming, I suggest reading https://jujucharms.com/docs/devel/developer-layers and the other pages in that section of the dev docs. Essentially, this would serve as a starting point for other charm authors to build WAR-specific charms very easily, with a large benefit being that it would be very easy to see what a application a specific deployed service is running, because it will be tied to the charm.

In the layered paradigm, the config options would instead become layer options (see https://github.com/juju-solutions/layer-basic/blob/master/README.md#layer-options), and the charms that use this layer as their would only need to provide the icon, metadata.yaml, a couple of layer options, and a README.

I'm curious to hear your thoughts on this approach.

[Philip Brown (bolthole)]

disclaimer: I'm new to juju. That being said...

I'm not actually a big fan of layers.
It requires you to use a COMPLETELY DIFFERENT programming paradigm than the standard charm API.
Nasty.
Plus, the few examples of using it, are mostly in python.
I'm not a python programmer, so that's 2 strikes against it.
If I had the developer's ears a few years ago, I would have suggested you guys make the layers API identical in feel to the standard one. Perhaps with a standard inheritance and override type mechanism.
(ie: my charm's hooks/start script would functionally replaces the original hooks/start script)

but you guys didnt do that. So... ick :(

In contrast, the standard charm developer API is far easier to understand, and is relatively consistent.

As a long time programmer, it is far easier for me to grab an existing charm, tweak a line or two, and bang on it until it does what I want it to.

What you're suggesting would require that potential users jump through the hoops of

step 1: get the 'base layer' charm code.

step 2: try to understand what it is doing, wading through all the code there
  (i had to wade through multiple charms myself, to understand how I needed to interact with my own one small simple charm to work correctly)

step 3: write their own completely new charm, using a completely different code paradigm, to try to interact in the way the base layer expects me to.
A way that is wierd and completely foreign to 95% of sysadmins out there, who probably have years of experience writing shellscripts and are very comfortable with that.

Having to work in split-programming-brain mode like that, gives me a headache.
Speaking with my end-user cap on: reguardless of what happens with my tomcat-webapp submission, I will be strenuously avoiding anything that requires me to write a "layered charm" on top of others, to get done what I want.
I would rather write my own full charm from scratch.

For reference: I have a CS degree. I've done event driven programming before. I've done java programming. I've done X11 programming. ( no, really, X11 programing. actual X11/Xt/Xaw programming, not libgtk stuff :)
I've done Kernel Driver programming.

I can do all kinds of programming. but i do it ONE style at a time, and focus on the one style, to get the job done properly.
Mixing styles is icky.

[Cory Johns (johnsca)]

> It requires you to use a COMPLETELY DIFFERENT programming paradigm than the standard charm API.

It's different, yes, but it comes with a lot of benefits. And I think there is a fair amount of conceptual overlap personally; instead of reacting to hook life-cycle events, you react to states from the layers you extend, which are more granular and semantically meaningful to what you're actually trying to accomplish.

> I'm not a python programmer, so that's 2 strikes against it.

You can write reactive charms in any language, not just Python, though the tooling around Python is obviously the most polished. The Bash tooling is pretty decent, as well, and you can see an example at: https://github.com/juju-solutions/layer-openjdk/blob/master/reactive/openjdk.sh

There was also some community work for creating tooling for Rust, Go, and PowerShell.

> (ie: my charm's hooks/start script would functionally replaces the original hooks/start script)

You can use layering without using reactive and do exactly that. However, you'll quickly find that replacing entire hooks doesn't give you the granularity to really get all that much re-use out of the layers you're building on, and leads to more fragile code that breaks much more easily when the base layer / charm is updated. Additionally, it doesn't provide a way for the layers to be aware of each other and communicate, and you still run up against all of the subtle race conditions that coding hooks directly encounter. Were you aware that the install hook quite likely won't be the first hook to run? If you depend on multiple relations, or a relation and some required config, how do you handle the fact that those hooks can be called in any order?

There's nothing stopping you from writing charms without using reactive, and without using even layers, but we've developed these as solutions to a lot of very real problems that charm authors face.

> step 2: try to understand what it is doing, wading through all the code there

This sounds like a documentation problem with the base layer in question. The layer should clearly describe the states and layer options it uses in such a way that you really shouldn't need to dive in to the code to understand it. Granted, layers and reactive are a new paradigm, so there is still some failing in this regard and we're working to improve the tooling to make it less dependent on pure documentation, but even so I think it's much easier to come to understand a list of states and a few helper functions that a layer exposes to leverage that vs. having to understand everything that a charm is doing to extend it, or understand all of the intricacies in setting up all of your charm's dependencies when you really on care about the payload itself.

> I would rather write my own full charm from scratch.

That's perfectly fine. I was simply pointing out that this submission is really generic and makes an excellent candidate for a base layer that others could easily build upon and would be appreciated by the community as such. I do also worry that it might be a little *too* generic to stand fully on its own as a charm, as I would much prefer to see specific charms for specif...

[Philip Brown (bolthole)]

Thanks Cory,

as you imply, there seems to be a (very large) documentation problem :(

I would be interested in looking at layers again, when and if someone writes some decent, sh-centric documentation for it.

(and I was just using hooks/start as an example)

[Review Queue (review-queue)]

This item has failed automated testing! Results available here http://juju-ci.vapour.ws:8080/job/charm-bundle-test-lxc/2423/

[Launchpad Janitor (janitor)]

[Expired for Juju Charms Collection because there has been no activity for 60 days.]