SDK Reference

[tmihoc (Teodora Mihoc)]

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

• Bundle
  • File <bundle>.yaml
• Charm
  • List of files in the charm project
  • The Juju execution flow for a charm
  • Charm taxonomy
    • 12-Factor app charm
  • Charm maturity
  • Charm development best practices
• Charmcraft
  • List of Charmcraft CLI commands
  • Charmcraft extension ‘flask-framework’
  • Charmcraft extension ‘django-framework’
  • Charmcraft extension ‘fastapi-framework’
  • Charmcraft deprecation notices
  • Charmcraft analyzers and linters
• Charmhub
• charm-relation-interfaces
• Event
  • List of events
  • Custom event
  • Charm lifecycle
• Extension
• jhack
• Library
  • Popular charm library index
• Ops
• Pebble
• Profile
• Promotion
• Publication
  • Reasons to publish your charm on Charmhub
• pytest-operator
• Revision
• Rockcraft
  • Rockcraft extension ‘flask-framework’
  • Rockcraft extension ‘django-framework’
  • Rockcraft extension ‘fastapi-framework’
• Scenario
  • Context
  • Event
  • State
• Status
• Storage
• StoredState: Uses, Limitations
• Testing
  • Interface tests
• YAML anchors and aliases

[bthomas (Balbir Thomas)]

Hi, Seems like there is link missing for a “Bundle Reference” section. I am not sure if this https://juju.is/docs/sdk/bundle-reference is up to date and would be the appropriate page to link to.

[tmihoc (Teodora Mihoc)]

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!

[bthomas (Balbir Thomas)]

@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.

[ppasotti (Pietro Pasotti)]

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?

[tmihoc (Teodora Mihoc)]

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.

[pengale]

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

[ppasotti (Pietro Pasotti)]

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.