SDK Reference

Technical information - specifications, APIs, architecture, etc., related to the Charm SDK

Hi, Seems like there is link missing for a “Bundle Reference” section. I am not sure if this is up to date and would be the appropriate page to link to.

Hi @bthomas, it’s because it seems to me that the Bundle reference doc is not really a reference but rather a collection of how-to guides. So I’ve sorted it under How-to guides and am working to portion out the content in a more digestible form. At the end I’ll also change the url (with a redirect, of course) so it’s not confusing. Do let me know if you think otherwise, though—I’d be happy to discuss!

@tmihoc You are certainly right it does not read like a reference. The how-to’s are excellent (thank you). A reference will be useful too. It may be necessary to reach out to Juju and Operator Framework developers for a reference guide.

1 Like

Should we be linking Deferring Events: Details and Dilemmas here too? It’s very related to the “a Charm’s life” post we just added.

I also feel that it’s starting to feel disorganized to have a flat list of links in this page. Would it make sense to add some structure to it? Or maybe use the recently added support for Topic Pages for that?

The Deferring documents actually reads like an Explanation to me. Maybe the better thing to do would be to move A charm’s life to Explanation also.

I agree that the Deferrer’s Dilemma should stay in the Explanation section. It’s not written as a reference.

1 Like

As @rwcarlsen pointed out to me, it feels strange to have a big ops classes heading, with a collapsible list of code references pointing to readthedocs, and if you click on ops classes it will open up a page with again the same list.

We think it would be more useful to get rid of that header, that collapsible list, that ops classes page, and in the sdk reference page simply state:

For the API docs and the source, go to (link to readthedocs source).

The tools, entities, processes thing should take the spotlight.