Re: Hooks and interfaces!
an 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. >>> >> >> I'm actually working on a way to list all the charms that currently use a >> given layer. That way it's easy to not only find out how many charms are >> using layers but also be used to find examples of how to implement that >> 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.sebrec...@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 lay
Re: Hooks and interfaces!
ch 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. >> > > I'm actually working on a way to list all the charms that currently use a > given layer. That way it's easy to not only find out how many charms are > using layers but also be used to find examples of how to implement that > 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.sebrec...@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
Re: Hooks and interfaces!
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 <t...@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
Re: Hooks and interfaces!
gt; 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.sebrec...@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 <t...@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 ma
Re: Hooks and interfaces!
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.sebrec...@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
>
Re: Hooks and interfaces!
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 <t...@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
Hooks and interfaces!
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@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
