---
# System prepended metadata

title: Charm Design

---

## Charm Design

### Managing charm application configuration and integration data

Use `pydantic`.

### When to use objects versus namespaces for charm functionality

Thoughts:

1. Should avoid passing references to the charm object where necessary as it creates a complicated dependency tree that makes it difficult to refactor charms due to expected API.
  a. E.g. no `MyObject(charm: MyCharm)` willy nilly.
  b. Service/charm workload management should not be objects unless necessary.

## Charm Dependencies

`hpc-libs` - generic libraries for building HPC charms.
`slurmutils` - dedicated package for handling Slurm configuration files. Includes some utilities such as calculating range and strides for Slurm hostname syntax.
`slurm-ops` - framework for managing Slurm services on machine charms.


Things we really need to do:

1. Improve how we surface errors to users. `update_status` clobbers error messages set by other event handlers.
  a. Could use developer documentation that explains how `refresh` works and when it should be called.

Wish list action items (incremental improvements):

1. We need developer documentation that explain how our dependencies work.
  a. Too much black magic with how "conditions" and `hpc-libs` interfaces work.
  b. Define what is the expected interface for conditions.
  c. Explain how and when conditions are called within a charm.
  d. Explain the purpose of `slurm-ops` and what it's responsibility is.
  e. Explain the purpose of `hpc-libs` and what it's responsibility.
2. Refactor existing functions so that they don't accept `charm: ops.CharmBase` as an argument. They should accept only the data that they need, not the whole charm object.
3. Determine where exceptions "could be" allowed for passing `charm: ops.CharmBase`. E.g. _config.py_, _state.py_, _interfaces.py_, etc.
4. Experiment with using pydantic for managing charm configuration and integration data to see what works and what sucks.
