So charm interface docs can be had two ways. Fundamentally a doc here needs to capture the data and sequence flow between the two related services and then some descriptive narrative. The data flow as gustavo postulated could be captured via intermediary proxy charm, and i believe marco ceppi has done some work on such. An alternative that's a bit tied to the low level implementation but is also trivial, is simply a capture/report and annotation against the transaction log in juju against the two services related unit communication.
cheers, Kapil On Fri, Oct 4, 2013 at 6:52 AM, Nick Veitch <[email protected]>wrote: > On Fri, Oct 4, 2013 at 12:28 PM, Mark Shuttleworth <[email protected]> > wrote: > > > > I think we'll need the ability both to document the interface in a > particular charm, and to link to other charms > > interface docs from inside such documentation. > > It is easy enough to do that by using Markdown, since we already > render that. Do we want it as a separate file? In many ways, it > *could* just be part of a well-written README, but then it isn't so > obvious where the information actually is. > > -- > Juju mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
