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 <[email protected] > <mailto:[email protected]>>: > > 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 > [email protected] <mailto:[email protected]> > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > <https://lists.ubuntu.com/mailman/listinfo/juju> > > -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
