Hooks and interfaces!

Fri Feb 26 11:15:22 UTC 2016

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 <merlijn.sebrechts at gmail.com
> 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 <tom at analytical-labs.com>:
>
>> 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 <
>> merlijn.sebrechts at gmail.com> 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 <tom at analytical-labs.com>:
>>>
>>>> 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
>>>> Juju at lists.ubuntu.com
>>>> Modify settings or unsubscribe at:
>>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160226/52963768/attachment.html>