Skip to content

docs(uhpc014): add spec for implementing the openssh operator - #21

Draft
NucciTheBoss wants to merge 1 commit into
canonical:mainfrom
NucciTheBoss:nuccitheboss/uhpc014/openssh-operator
Draft

docs(uhpc014): add spec for implementing the openssh operator#21
NucciTheBoss wants to merge 1 commit into
canonical:mainfrom
NucciTheBoss:nuccitheboss/uhpc014/openssh-operator

Conversation

@NucciTheBoss

Copy link
Copy Markdown
Contributor

This specification provides an in-depth overview of the implementation for the new openssh operator and ssh-config integration interface implementation.

Signed-off-by: Jason C. Nucciarone <nuccitheboss@ubuntu.com>
@NucciTheBoss NucciTheBoss self-assigned this Jul 20, 2026
@NucciTheBoss NucciTheBoss added feature This pull request adds a new feature to the project Charmed HPC 2026.1 The resolution for this issue will be included in Charmed HPC 2026.1 labels Jul 20, 2026

@benschwaller benschwaller left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! Love the level of detail, could you discuss a bit your process of drafting this? Might be good to integrate for future specs.

Left minor thoughts about conf file naming and documentation.

command, the `openssh` operator must not stop or uninstall the `openssh` service when the operator
is removed with `juju remove-application`. The installation operations should also only ensure that
the `openssh-server` package is available, and only install the package if it is not present.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add something here how we will need to document what a user should understand about juju ssh and how these changes affect that?

in the *ssh_config.d* directory. The custom SSH configuration files will use the following naming scheme:

```text
/etc/ssh/ssh_config.d/<integration-name>-<integration-id-number>-<remote-app-name>.conf

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there any considerations around ordering the files? Openssh reads files in alphanumeric ordering. 01-new.conf gets read before 99-default.con for example. Should we be ordering these files in anyway so they have preference over juju or other conf files? Should we be checking for what files already exist in this directory?

Mutating the `port` property will update the port number that the `openssh`/`sshd` service
communicates over. By default, the SSH port number is set to `22`, but certain cluster admins
may want to change this to a different, non-standard port. When a new port number is set,
a new _port-override.conf_ configuration file will be created under *etc/ssh/ssh_config.d*:

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment about naming / ordering conventions as above, 99-default comes before port-override for example.


The `ssh-config` integration will be vendored as publishable `uv` workspace under the `pkg/` directory
in the `openssh` charm. The integration will enable applications such as SSSD to provide custom SSH
configuration to OpenSSH. It is expected that requirers - for example, SSSD - will provide the `openssh`

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems at odds with the mermaid chart where sssd is the provider and openssh is the requirer.

The `openssh` charm will provide a CC008-compliant Terraform module so that operator can be deployed with
Terraform and not only the Juju CLI. The `sssd-operator` provides an example of a CC008-compliant
Terraform module for a subordinate charm.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we have a documentation requirements line here? Spec out what information a user should need to know, what existing docs might need to change etc?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Charmed HPC 2026.1 The resolution for this issue will be included in Charmed HPC 2026.1 feature This pull request adds a new feature to the project

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants