Containerization should be possible, especially with system containers.
You may find the current work on server applications interesting (trello
[0], or a current demo video [1]). One of the core aspects is that these
extend Cockpit without being part of Cockpit. Like Josh said, we don't
want to reinvent things here, so Cockpit should pull viable content from
other sources, e.g. by leveraging AppStream and system containers.
In the end you can share a cockpit package by dropping a few files in
the right place (e.g. /usr/share/cockpit/mypackage), but lasting success
usually requires maintenance. Towards that end we're currently looking
at out of tree packages and how to make CI work with that conveniently
and both ways: test new versions against Cockpit and notify Cockpit if
changes there break an out of tree package. More about that on this list
once there's a proof of concept.
-Dominik
[0]
https://trello.com/c/EMHMHFVp/486-epic-server-applications
[1]
https://www.youtube.com/watch?v=ieVTvY38SNk
On 06/19/2017 09:28 PM, Tiago Machado wrote:
I don't know how we can "containerize" the modules in
an easy way. We have to make it easier for the modules developers and avoid "rocket
science" as much as possible at the module end point.
Regarding the compatibility issue we could have a "works on" tag to describe
which module works or not for each system, I think it would perfectly accepted for the
cockpit users (since they will know that those modules are from the community). I can
imagine that at the beginning we would have very system-specific modules but they will get
generic as the time goes by.
About the installing tool, I was thinking on something like this when I mentioned a
possible UI inside Cockpit to manage external modules in the future.
_______________________________________________
cockpit-devel mailing list -- cockpit-devel(a)lists.fedorahosted.org
To unsubscribe send an email to cockpit-devel-leave(a)lists.fedorahosted.org