Building Cockpit together

[giacomo (Giacomo Sanchietti)]

@dasois

IMHO and from my professional coding experience we definetly shouldn’t reinvent the wheel with a custom API for functions that already exist, especially under a shortage of participating developers and no integration tests on our side.

I couldn’t agree more: new code, new bugs! We tried to keep as much as possible close to upstream but after some months of study we were almost forced to rewrite many parts.
There are a couple of main reasons:

• Cockpit is “too much” for our users. Cockpit target is the experienced system administrator who needs/wants access to all system functions, while our target is the inexperienced system administrator (usually from the Windows world) who doesn’t know much about Linux. This is why we need more simplicity than flexibility guiding the user on doing the right configuration choices.
• There is no way to hack existing Cockpit page. Let’s see the hostname change as an example.
  Normally when clicking on the hostname, the user can enter the new name which is set using hostnamectl, then the admin must reconfigure all dependent services.
  In NethServer, after using hostnamectl we need to execute a bunch of scripts (events and templates) to propagate the configuration to the whole system.

@dasois

I discovered that the cockpit team already adressed the use-case of developing custom plugins/modules/pages with the starter-kit. It enables one to use the whole testing infrastructure…

I’d like to integrate the tests, but for now we couldn’t make it work.
I’m pretty sure that all the @dev_team would appreciate it!

@dasois

Is there already any progress regarding the communication with the cockpit team?

We discussed with the team some time ago (you can find some report here in the forum), but we had two different goals.
Since now, our real contribution to upstream was about discussions, some reported issues and the Italian translation.