I have a REST API that's running on localhost (flask app) that I'd like to
access with a cockpit plugin. I've done a few initial tests but I'm finding
it difficult to navigate the CORS and Content-Security-Policy - so before I
invest any more time in this, I thought I'd ask the dumb question first.
Is this goal achievable? Can a cockpit plugin access a REST API running on
the same host - if so, could someone provide some guidance, or point me at
I'm testing on Fedora, but the longer term goal is to use RHEL.
Any help appreciated!
here is a little update regarding Foreman and Cockpit integration:
[ The video shows a new "Cockpit" button in Foreman that opens
Cockpit on a host without having to log into Cockpit.
No changes to Cockpit were necessary for this integration, thanks to the
great work Peter has done earlier for a similar integration of Cockpit
My current hackish changes to Foreman are here:
As you can see, there is a lot of cheating going on. My next steps will
be to reduce the cheating and then look into how to involve the smart
proxy in this.
Cockpit's "Kubernetes" package has provided a web UI for managing
Kubernetes/OpenShift deployments for a long time. In the last year it also got
some initial support for showing KubeVirt VMs that run in OpenShift.
Since Red Hat's acquiring of CoreOS there are now *three* web UIs: OpenShift's
own "OpenShift Console", Tectonic, and Cockpit's "Cluster" dashboard. The first
two are meant to become one at some point  and currently see a lot of
development; i. e. Console/Tectonic/Quay will be *the* web UI for OpenShift
(including KubeVirt) soon. On the other hand, cockpit-kubernetes has been in
maintenance mode for a fair while now - both because of that merging effort,
and also because we haven't had (and still don't have) any development capacity
for it in the Cockpit team. It's also rather hard to maintain, being written in
a very old Angular version.
So long-term cockpit-kubernetes will go away. As a strawman I would propose to
still keep it in Fedora 29 (as it's past beta freeze already), but drop it from
Rawhide. Thus there will still be a supported cockpit-kubernetes package for
~ 1.5 more years.
cockpit-kubernetes also contains some support for KubeVirt. Apparently
community interest has waned on that, and we actually haven't been able to
build a recent kubevirt-enabled OpenShift image in four months --  were the
last attempts at fixing it. Thus we had to kick out kubevirt testing from
the openshift image , and we'll have to kick it off the openshift-prerelease
image as well if we need to rebuild it at some point. Once this happens, there
is no way how we can further support the KubeVirt bits in cockpit-kubernetes,
so I'd actually like to remove this from Fedora 29 already, in its current
Is there any interest from anyone to continue to maintain it? If so, then the
best course of action would be to split it off into a separate
cockpit-kubernetes upstream project, like we recently did with cockpit-ostree ,
and maintain it there (by a different group of people than the Cockpit core
team). Of course we will gladly help you to set this up.
 https://github.com/cockpit-project/cockpit/issues/9479 and https://github.com/cockpit-project/cockpit/pull/9638
soon the All Systems Go conference will happen in Berlin again , and a few
Cockpit hackers will be there (at least Stef, Lars, Sanne, and myself).
On the days before that (Tue Sep 25 to Thu Sep 27) we wanted to do a little
impromptu hackfest again in the Red Hat Berlin office .
So if you are working on a Cockpit related project and want to talk to us for
some help, discussing architecture, setting up CI, fixing your favourite pet
feature or bug, or just have a Falafel or whole-grain lemonade  with us, you
are welcome to join!
This is nothing formal, but please let us know in advance if/when you are going
to come, for capacity planning.
Thanks, and see you in Berlin soon!
 in some circles also known as "beer"