Thanks Merlijn I'm not just spouting complete nonsense then! ;)
Tom -------------- Director Meteorite.bi - Saiku Analytics Founder Tel: +44(0)5603641316 (Thanks to the Saiku community we reached our Kickstart <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/> goal, but you can always help by sponsoring the project <http://www.meteorite.bi/products/saiku/sponsorship>) On 26 February 2016 at 11:09, Merlijn Sebrechts <[email protected] > wrote: > Hi Tom > > > at which point apache2 does some funky stuff and allows my service to >> proxy through it, yet it doesn't > > > Jep, this is entirely the fault of the apache2 Charm. It says it > implements the http interface, but it actually implements a custom addition > on top of that interface. Interface layers solve this problem. I think the > apache2 Charm should be rewritten, including its interface protocols, but > that is a whole other discussion... > > So I guess the point i'm trying to get to is, if I look at the config line >> in provides.py I can clearly see what that requires, but how do I know >> which charms are compatible with it? >> > > You can't know that unless they use an interface layer. They *should* be > compatible, but this is not always the case... > > But if interfaces.juju.solutions said, here's your http interface >> layer(which it does) and here's everything that extends off it. At least at >> that point I'd have an understanding of which charms talk through that >> interface layer. >> > > You want to search an interface layer and then see all the Charms that > implement that interface layer? Good idea! I also think this would be > useful. > > 2016-02-26 11:38 GMT+01:00 Tom Barber <[email protected]>: > >> Hey Merlijn >> >> Thanks for the response(great presentation in Gent by the way). >> >> Having slept on it a bit, and poked around a bit more this morning I see >> that the http interface does implement the hooks, so I guess I'm just >> getting confused with hook execution in the new reactive layer. Currently >> its quite hard to find concrete examples, which is understandable given the >> fact its blazing a new train in charm development, not a complaint, merely >> a fact of life! :) >> >> So expanding upon that that a little, take haproxy and apache2, they both >> implement the reverseproxy interface, now in my charm I can use the http >> interface layer and provide the http interface so that haproxy and apache2 >> can consume it. >> >> And that is cool as hell because then all I do in my charm is: >> >> @when('website.available') >> def configure_website(website): >> log("starting hook") >> website.configure(port=8181) >> >> and haproxy knows what to do, and even I can see why in: >> https://github.com/juju-solutions/interface-http/blob/master/provides.py#L18 >> >> But, then say as a developer I want my charm to support haproxy and >> apache2, both just serve as reverseproxy. So, now technically speaking, >> from what I understand I should be able to: >> >> juju remove-relation haproxy gitlab >> >> juju add-relation apache2:reverseproxy gitlab >> >> and at which point apache2 does some funky stuff and allows my service to >> proxy through it, yet it doesn't, I guess its interface requires something >> more than the port and hostname. But from a developers point of view the >> interface is the same, and my when trigger is called anyway and it just >> fails, but without reporting an error as well. The problem I see is that >> these interfaces are very loosely defined within the charm. So as a >> developer of the apache charm I might say I'm going to implement the >> reverseproxy interface and require information x,y,z, where as haproxy only >> requires x,y. >> >> So I guess the point i'm trying to get to is, if I look at the config >> line in provides.py I can clearly see what that requires, but how do I know >> which charms are compatible with it? >> >> Your last comment about which charms implement which interface, I see the >> connects from: and connects to: but I don't think thats what I was after. I >> also accept I can look at various charms source to find the answer, but, >> what I wouild like to know as a developer and also as a user is, okay my >> charm works with haproxy via the http interface layer, but what else >> provides that service? And from the charm store UI I can't see that. But if >> interfaces.juju.solutions said, here's your http interface layer(which it >> does) and here's everything that extends off it. At least at that point I'd >> have an understanding of which charms talk through that interface layer. >> >> Hope some of that makes sense! >> >> Tom >> >> >> -------------- >> >> Director Meteorite.bi - Saiku Analytics Founder >> Tel: +44(0)5603641316 >> >> (Thanks to the Saiku community we reached our Kickstart >> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/> >> goal, but you can always help by sponsoring the project >> <http://www.meteorite.bi/products/saiku/sponsorship>) >> >> On 26 February 2016 at 09:50, Merlijn Sebrechts < >> [email protected]> wrote: >> >>> Hi Tom >>> >>> >>> First of all, thank you for sharing your experiences. The reactive >>> approach is quite new and feedback like this is very valuable. I understand >>> the frustration, I've had similar experiences with the reactive framework. >>> I think that there is still significant work needed in both `charm build` >>> and `charms.reactive` to help users debug problems. Sometimes, I've had to >>> dive in the code to figure out what was happening, and I don't think >>> everyone will be willing to do that. The Juju team is also working on >>> better documentation, and I'm positive that it will eventually catch up. >>> Feedback like yours helps them figure out where the pain-points are. >>> >>> Now for your questions. I think I have a pretty good grasp of how the >>> framework operates. For anyone closer to the code, feel free to chime in >>> and correct me where needed. >>> >>> Do I need a placeholder in the hooks directory? >>> >>> >>> Yes! and no... If reactive framework does not get called when a hook >>> runs, it cannot execute handlers. The placeholder calls the reactive >>> framework, the reactive framework executes the handler. However! You should >>> not have to add these placeholders manually. `charm build` creates >>> placeholders for all relationship hooks of all interfaces that a Charm has. >>> In your first implementation, *you did not use an interface layer, so >>> `charm build` did not know what placeholders it had to add*. So now >>> that you added the http interface layer, these placeholders should be >>> present, and the commented code should now work. Please note that this is >>> *not >>> recommended.* All handeling of relationship hooks should happen in the >>> interface layer. This interface layer then communicates with other layers >>> using states. >>> >>> I think a lot of people will make similar mistakes. The `charm build` >>> tool should throw warnings to let you know that something is wrong. Feel >>> free to submit a feature request for this. >>> >>> how to find out what charms implement what layers. >>> >>> >>> I'll make it a bit more specific: *Find out what charms implement what >>> interfaces.* >>> >>> The short answer is that `metadata.yaml` specifies what interfaces are >>> implemented. >>> >>> *An interface is a protocol* of how two Charms communicate. If two >>> Charms implement the same interface, they should be able to communicate >>> with each other. Juju uses metadata.yaml to know if two Charms have the >>> same interface. Layers are more or less separate from this. *A layer >>> contains an implementation of an interface protocol.* The layer >>> contains code that manages the relationship on both sides. This way, you >>> are 100% sure that each side of the relationship implements the exact same >>> protocol. However, it is not required that both sides of a relationship use >>> that implementation. They can have their own implementation. This is fine >>> as long as the protocol stays the same. >>> >>> In the Charm store, you can see what interfaces a Charm implements in >>> the bar on the right. This also shows what other Charms implement that same >>> interface. https://jujucharms.com/haproxy/trusty/16/ >>> >>> >>> >>> >>> Kind regards >>> Merlijn Sebrechts >>> >>> 2016-02-26 1:34 GMT+01:00 Tom Barber <[email protected]>: >>> >>>> Hello folks, >>>> >>>> This is not a complaint more a story of how this afternoon has gone. >>>> >>>> I'm writing a gitlab charm, in doing so marco suggested that we add >>>> some hooks to optionally offload some of the services, like web server and >>>> database elsewhere should the user desire. Very sane plan, I thought. >>>> >>>> So today I figured I'd work out how to plugin another webserver over >>>> the top. The charm is a new layered job that extends the basic layer and >>>> not much more. Because of a curiosity about getting used to python, I have >>>> recently been writing code in Juju in Python, I realise this slows me down >>>> as most examples are in bash but its a good way to learn. >>>> >>>> Out of the box Gitlab claims to support Apache2 and Nginx but to me it >>>> basically looks like a standard reverse proxy although I'm yet to test it >>>> in anger. So i figured I'd slap apache2 next to it and see how we got on. >>>> We didn't. For some reason I am yet to fathom this block of now commented >>>> code never seemed to fire: >>>> https://github.com/OSBI/layer-gitlab/blob/master/reactive/gitlabhooks.py#L14 >>>> >>>> >>>> Am I missing something in reactive charms? If I juju debug-hooks and >>>> copied the code into the website-relation-changed hook it ran fine. >>>> >>>> Anyway, after a few hours messing around trying to figure that out and >>>> giving up I realised after just randomly googling there was an http >>>> interface that did a similar job. Low and behold 10 minutes later with >>>> haproxy and one @when('website.available') method it seemed to be >>>> configuring itself with haproxy just fine. >>>> >>>> So here's the question. I'm all up for reactive charm stuff, but am I >>>> missing something with hook triggering? Do I need a placeholder still in >>>> the hooks directory? It appears not, but I'm not sure. >>>> >>>> Also, and more importantly going forward after much digging around to >>>> find interfaces.juju.solution is there, or will there be a way to find out >>>> what charms implement what layers. For example, I now seem to have found >>>> out that haproxy loves the http interface, but apache2 is yet to go >>>> reactive, so I guess I'm stuck with hooks for that if I chose to use it, >>>> but, without looking at the code, I don't know that. It would be great, >>>> would it not, to expose that type of stuff. I'm sure its all in the >>>> pipeline and you'll tell me its coming shortly, but I figure the feedback >>>> might prove useful to someone. Also from an interface point of view, whilst >>>> listing the supported interfaces in a charm in the charm store would be >>>> great, what i would love, if it does not already exist, is for me to say, >>>> okay, I need a reverseproxy through the http interface, what charms are >>>> available that allow me to do that? Is it just haproxy, or are there >>>> others. This information is key to easy (for those outside of canonical) >>>> charm development. >>>> >>>> Thanks and keep up the cool stuff in Juju 2. >>>> >>>> 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
