peer relation without public interface

Tilman Baumann tilman.baumann at canonical.com
Fri Jan 13 16:44:32 UTC 2017


I thought about it a little and I do think a no-op interface purely for
peer discovery could actually help others with similar requiremrnts too.
Hence this https://github.com/tbaumann/charm-interface-peer-discovery

If there are no objections, I will try to get this published.


This is the charm that uses it https://github.com/tbaumann/iptables-peer-ssh


Any comments?


There is one thing that I don't like a lot, but might be normal.
Right now I need to unset the state at the end of my handler function.
I find that is bleeding dependencies of the interface into the main code.

I really like this idea
http://blog.ajkavanagh.me/2016/12/30/better-charm-interfaces/

hookenv.atexit() with a closure to clean up the state at the end of the
hook invocation seems like a very sensible thing to do.
But I also understand the resistance towards magic.
But then, this is something even the basic layer does...

I shall look into this next week...

Cheers and thanks
 Tilman

PS: github is down ATM. If you wonder why the links don't work.
I guess I should have used launchpad. Old habits die hard...

On 12.01.2017 21:17, Merlijn Sebrechts wrote:
> Hi Tilman
> 
> 
> I think it's best that you create your own interface layer to do this.
> Then include that interface layer in `layer.yaml` and the hooks should
> be created at build time.
> 
> More info on developing interface
> layers: https://jujucharms.com/docs/2.0/developer-layers-interfaces#writing-an-interface-layer
> 
> 
> 
> Regards
> Merlijn
> 
> 
> 
> 2017-01-11 14:23 GMT+01:00 Tilman Baumann <tilman.baumann at canonical.com
> <mailto:tilman.baumann at canonical.com>>:
> 
>     Hi,
> 
>     I'm writing a layered reactive-python charm which uses a peer relation
>     to know all units of the same application.
> 
>     However I don't seem to find a way to convince charm build to create the
>     ./hook/ files for this relation for me.
> 
>     If I do my metadata.yaml like this and include the interface in
>     layers.yaml then I get the hook files and the interface layer code gets
>     pulled in.
>     metadata.yaml
>     peers:
>       foobar:
>         interface: ceph
> 
> 
>     If I don't specify a interface or use my own name, then the hooks won't
>     be created. So my @hook handlers in the reactive code never see it.
> 
>     What is the general best practice for providing peer relations of a own
>     type in a layered charm?
> 
>     I suppose there is no reason why I can't put the code in a class based
>     off RelationBase like interface layers usually do? The code entry point
>     seems to the @hook decorators around the methods. I don't need to create
>     instances or anything like that, right?
> 
>     Cheers and Thanks
>      Tilman
> 
>     --
>     Juju mailing list
>     Juju at lists.ubuntu.com <mailto:Juju at lists.ubuntu.com>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/mailman/listinfo/juju
>     <https://lists.ubuntu.com/mailman/listinfo/juju>
> 
> 



More information about the Juju mailing list