Building cockpit fully from source offline
by Ludwig Nussel
Hi,
So far the cockpit packages we have for openSUSE Tumbleweed use the
upstream release tarball. That means all web assets are prebuilt.
Therefore cannot be patched, it's almost like bundling binaries. So
I've tried to come up with a concept to be able to fully rebuild
cockpit.
In openSUSE a package build is fully unattended, automatic and has
no network access. That means all that nodejs stuff needs to be
available. When talking to other developers that touched Nodejs
before, they just recommended to tar up node_modules/. That's not
acceptable either IMO as it also would be just some magic tarball that
we don't really know how it was created.
So I wrote a PoC tool that parses package-lock.json instead. With
that information we know what upstream nodejs modules npm decided to
use and where to put them in node_modules/. That way we can have a
spec file that refers to all upstream sources properly and rebuild
node_modules/ from sources.
Here's the tool:
https://github.com/lnussel/nodejs-tarballs
And how cockpit it built in OBS:
https://build.opensuse.org/package/show/home:lnussel:branches:systemsmana...
The madness comes from the huge amount of tarballs. Apart from that
looks quite straight forward, doesn't it? :-)
The most annoying bit to fix was gyp as it tries to download nodejs
header files at build time. Sass also needs a patch as it doesn't
compile. ATM those patches have to be duplicated in cockpit modules
that are separate such as cockpit-podman.
Also, cockpit-podman wants to use bits of cockpit
(pkg/lib/patternfly) and the Makefile gets that from git if not
present. So I had to create a cockpit-devel subpackage that can be
consumed by cockpit-podman. Would that be something to consider for
upstream too? Ie install those files and probably a pkgconfig file
in cockpit, then check for that in the Makefiles of modules?
cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.com/
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
3 years, 7 months
Development of web applications around Cockpit API
by Vinícius Ferrão
Hello, I’m developing an application around Cockpit with my colleagues and I was wondering if there’s a way to consume Cockpit without our application being a plugin inside the Cockpit interface.
Our application is something like an HPC Cluster Manager, so it makes total sense to use Cockpit as the basis, there’s a lot of functionality built in, and the upstream development is just awesome. But as per consumer feedback it would be better to have a separate web interface instead of it being a plugin inside the Cockpit web interface.
I’m looking through the documentation and there’s the Cockpit API:
https://cockpit-project.org/guide/latest/development.html
I see that Cockpit can be embedded entirely in an external application, but this is not what we really want to do.
We want to do a new web interface, using IBM’s Carbon design guidelines with HPC in mind and not the system being managed, which is the vision of Cockpit as is. There’s this Deep Integration on the documentation and I think what we need is just this, but the documentation is lacking.
The point is: as today, is it viable to consume Cockpit with its API’s in a totally different frontend interface? So I can use things like: authentication, performance graphs, dashboards, user creation, logging, console terminal, etc?
Regards,
3 years, 7 months
