Very interesting idea, Tom! Something that might help for your use-case are layer options <https://github.com/juju-solutions/layer-basic/blob/master/README.md#layer-options>. They are a way for layers to pass build-time config options to layers below them.
Another thing that might be of interest is the payload concept <https://insights.ubuntu.com/2015/10/22/charming-2-0-now-with-100-more-awesome/> . If we find a great way to do this, we might be able to swap out a self-managed LAMP stack and replace it by a hosted LAMP solution that implements the same 'payload interface', taking the modularity of Juju even further... 2016-03-05 16:15 GMT+01:00 Tom Barber <[email protected]>: > Yeah I think that's about right. Currently saiku is subordinate of tomcat > so we're basically locked in, which in reality is fine as we've not tested > elsewhere but I like flexibility which is what juju relations offer. > > So it would be good to create a charm that maybe as Rick suggests provides > a resource and implements a webapp interface that means I don't have to > write a load of code to get it deployed on a bunch of different containers. > > I don't know much about the WordPress charm and that's php based but the > idea would be similar to this where you could front WordPress with httpd > nginx or haproxy just by swapping relations. > > Also for wars and stuff deploying them via actions is pretty grim as you > loose the visiblity of what's deployed where which the relations give you. > > At the end of the day. A war is an app in a zip file that needs a > container in exactly the same way my pdi charm requires a java interface to > function, it needs a j2ee container. > > Cheers > > Tom > On 5 Mar 2016 14:41, "Rick Harding" <[email protected]> wrote: > >> The Juju team is working on a feature called "juju resources" that can be >> used to provide a blob to a charm to be used in the deployment. It sounds >> like it might be interesting as a way to deliver the WAR file to the Tomcat >> charm. The current beta1 implemented the local version where you can >> defined and supply resources from your filesystem. Work is ongoing to be >> able to pull those from the charm store. >> >> See the resources section of the beta release notes. >> >> https://lists.ubuntu.com/archives/juju/2016-February/006618.html >> >> All that being said, it might be interesting for some layer for a web app >> resource where resources does some of the work you'd do in that layer. I'd >> be interested to know what others think there. >> >> On Sat, Mar 5, 2016 at 6:40 AM Tom Barber <[email protected]> >> wrote: >> >>> Okay so here's one I wanted to know if it made sense to people or not >>> now there are layers, interfaces etc. >>> >>> Take Saiku or any other WAR based webapp. Currently our app is a Tomcat >>> subordinate, which installs the WAR and a few other directories and just >>> sed-s a few files to set some variables. >>> >>> In this land of layers and interfaces, does it make sense to have a >>> webapp interface? I realise most of the current interfaces are for services >>> and not file archives, but, if I deploy Tomcat, Wildfly, Karaf I know that >>> (with a bit of tweaking) I can deploy a war to each of those and they >>> should behave pretty much the same. So does it make sense to have an >>> interface that lets me charm up my WAR file and then add a relation from >>> WAR <-> J2EE Container so I can just link them together and have Juju place >>> my WAR in the correct location? >>> >>> That way you can deploy on multiple services without having to do much, >>> if anything, to your code. >>> >>> Cheers >>> >>> Tom >>> -- >>> Juju mailing list >>> [email protected] >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju >>> >> > -- > Juju mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
