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