Cockpit modules repository

[Tiago Machado]

Hi all, 
we are currently using Cockpit (a lot) and we love it ! But there's one thing we miss about cockpit: modules from the community.
I think it would be great if we had a standard procedure to publish modules for cockpit on GitHub.
If everybody use, for example, a predefined name, like cockpit-module-contrib-MODULE_NAME it would be easier to create a repository of cockpit modules and then we could even add an interface for managing the installed modules, where you can download/remove modules.

I'm thinking about something similar to what we have on Node-RED ( https://github.com/node-red/node-red). There we have a standard name for external modules (node-red-contrib-NODE_NAME) and they could create a repo of node (https://flows.nodered.org/ ) where we already have more than 1500 modules (and counting). There's even an UI inside Node-RED where it's possible to manage and download new modules.

[Peter]

On 06/13/2017 04:45 PM, Tiago Machado wrote:
> Hi all,
> we are currently using Cockpit (a lot) and we love it ! But there's one thing we miss about cockpit: modules from the community.
> I think it would be great if we had a standard procedure to publish modules for cockpit on GitHub.
> If everybody use, for example, a predefined name, like cockpit-module-contrib-MODULE_NAME it would be easier to create a repository of cockpit modules and then we could even add an interface for managing the installed modules, where you can download/remove modules.
>
> I'm thinking about something similar to what we have on Node-RED ( https://github.com/node-red/node-red). There we have a standard name for external modules (node-red-contrib-NODE_NAME) and they could create a repo of node (https://flows.nodered.org/ ) where we already have more than 1500 modules (and counting). There's even an UI inside Node-RED where it's possible to manage and download new modules.

I agree that we need some way to make community modules easier to 
discover and use. I'm ok with setting a naming convention, though I 
think initially it might be good to start small. Maybe just a wiki page 
on our repo that people can add their modules to.

Another issue to consider is that a big part of what makes cockpit 
workable is the CI. So I think that part of having a good library of 
modules to chose from is going to be figuring out how to allow out of 
tree modules to best leverage what cockpit has for testing. If you have 
a module you'd be interested in working with us on to see how doable 
this is let us know.

[Tiago Machado]

I agree, 
I think a wiki page and a reference to it in the Git page is a good way to start small. There we can explain the standard structure that an external modules has to follow for making it easier to install. I don't know how we can manage some complications like, for example, the webpack build part for external modules.

I already have some modules, that we use internally in our company (we have a DisplayManager for setting the display ratio/resolution/orientation), an extension to the NetworkManager (with capabilities for establishing wi-fi connections) and I'm making more and more modules as soon as the need comes.
I could help with the wiki page but we have to discuss first how can we make it the easiest way for the future developers.

[Josh Berkus]

On 06/13/2017 10:47 PM, Peter wrote:
> On 06/13/2017 04:45 PM, Tiago Machado wrote:
> > Hi all,
> > we are currently using Cockpit (a lot) and we love it ! But there's
> > one thing we miss about cockpit: modules from the community.
> > I think it would be great if we had a standard procedure to publish
> > modules for cockpit on GitHub.
> > If everybody use, for example, a predefined name, like
> > cockpit-module-contrib-MODULE_NAME it would be easier to create a
> > repository of cockpit modules and then we could even add an interface
> > for managing the installed modules, where you can download/remove
> > modules.
> >
> > I'm thinking about something similar to what we have on Node-RED (
> > https://github.com/node-red/node-red). There we have a standard name
> > for external modules (node-red-contrib-NODE_NAME) and they could
> > create a repo of node (https://flows.nodered.org/ ) where we already
> > have more than 1500 modules (and counting). There's even an UI inside
> > Node-RED where it's possible to manage and download new modules.
>
> I agree that we need some way to make community modules easier to
> discover and use. I'm ok with setting a naming convention, though I
> think initially it might be good to start small. Maybe just a wiki page
> on our repo that people can add their modules to.
>
> Another issue to consider is that a big part of what makes cockpit
> workable is the CI. So I think that part of having a good library of
> modules to chose from is going to be figuring out how to allow out of
> tree modules to best leverage what cockpit has for testing. If you have
> a module you'd be interested in working with us on to see how doable
> this is let us know.

Well, if Cockpit modules could be containerized we could just plug them
into the FLIBS or CP, and we'd be ready to go.  But that won't work with
all Cockpit modules.

Maybe you should work with the Fedora folks on this?  Really it's Yet
Another Build Stream, but not in any way fundamentally different from
the others.  The main difficulty with that approach, of course, is that
you want to enable modules which don't work on Fedora (for example, an
Apt module or something for Mac).  But it would give us somewhere to start.

Mind you, this also means that you'll need a tool for installing modules
which is a bit more polished/testable than "un-tar to this directory".

[Tiago Machado]

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.

['Dominik Perpeet']

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 -- [e-mail]
> To unsubscribe send an email to [e-mail]