here are some brainstorming notes about what might come next regarding
Cockpit apps. Any feedback highly appreciated!
Cockpit can discover and install add-ons that come as RPMs or DEBs.
Cockpit uses the regular AppStream mechanism for this that is also
used by GNOME Software to discover and install Desktop "add-ons".
Cockpit reads the "AppStream collection metadata" to discover
available add-ons, and the RPMs and DEBs install small "AppStream
upstream metadata" files into /usr/share that Cockpit reads to figure
out what is installed.
We also want to discover and install Cockpit add-ons that are in
container images. The Desktop world has Flatpaks for this, and they
are working on shipping Flatpaks as standard OCI container images.
Flatpak also uses AppStream to describe individual images. Owen is
working on "metastore", which should give us the equivalent of the
"AppStream collection metadata" for container image registries. Once
pulled, we can look at the labels and annotations of the
images/containers to find the "AppStream upstream metadata".
But how does a add-on in a container work?
I would try this:
- A container needs to be running before Cockpit takes note of it.
Having just the image pulled to local storage means nothing.
- When starting a session, the shell will find all running containers
with a special label and "exec" a bridge in them (if the logged in
user has enough permissions).
- Implementation-wise, such a container is like a remote machine.
URLs refer to it explicitly. Its packages don't need to be
distinct from those of other containers.
- UI-wise, their manifests and iframes are merged with those from the
bridge that runs outside of any container. We could start by only
allowing "dashboard"s in containers, that ought o be quite simple.
- We can even extend this merging to real remote machines so that you
get all dashboards from all your machines merged in your browser
- In the "Applications" tool, we don't talk about "installing"
applications that are in containers, but about "enabling" them.
Enabling such a container means running it in its default way, and
making sure it gets started on every boot. Somehow.
- We could extend this terminology to RPM/DEB apps as well.
"Enabling" an app makes its entry appear in Cockpit, "disabling"
makes it go away. If that needs some more rpms or images or
something else, that's an implementation detail.
- The process of enabling something could talk more clearly about
what will happen and let the user confirm this.
Does this make sense?
I'm considering exposing the VM consoles we already have in Cockpit for
their reuse by other projects, like ManageIQ or oVirt's VM Portal.
One way to do it is moving them under the patternfly-react library ,
partially involving the patternfly community in their later development
(and probably even design).
The transition would be implemented step-by-step, starting with the serial
The idea is to externalize VM serial console and underlying Terminal
component and "reuse" them back in Cockpit.
To do so, it makes sense to move from the term.js-cockpit fork to the
maintained xterm.js , successor of .
Once this is done, other use of the term.js-cockpit will be similarly
replaced to depend just on the single .
Benefits for Cockpit:
- use of upstream-maintained library
- leverage last (almost) 2 years of the xterm.js development
- be aligned with other related projects on the design level (and drive it!)
- quite a lot of work in backporting term.js-cockpit patches to xterm.js
- risks - bugs in already stabilized features might/will appear
I've already implemented POC proving this is feasible and the components
can provide reasonable wrapping/API.
There's still a lot of work to be done, starting with porting of  to .
So, here's the question: is this something what makes sense even for
If so, is there already any experience (good/bad) in merging some of the
 into any successor of ? The most important and maybe debatable seems
to be .
Thanks for opinion,
senior software engineer
Red Hat Czech
https://devconf.cz/ is approaching fast! As last year, we will host a Cockpit
Hackfest community meetup again. Please come join us if you want to learn about
how to create your own Cockpit pages, improve the existing ones, poke our
brains about how to do stuff, or simply say hello.
The preliminiary schedule  says that the hackfest will happen on Friday,
January 26th, in room C236. This fits about 15 people.
See you there!