cockpit-devel January 2018

cockpit-devel@lists.fedorahosted.org

8 participants
8 discussions

Please stop including cockpit's bundled jquery
by Martin Pitt 29 Jan '18

29 Jan '18

Hello all, Our cockpit JS API documentation currently has some way outdated information about jQuery [1], suggesting that users of the Cockpit API should always load jQuery, and use the Cockpit bundled version. This hasn't been true for a long time, and was just forgotten to be cleaned up. Also, our examples did that, so people using them as a start for their own modules were also misled. The problem with this is that it makes the old jQuery version (2.2.5) part of Cockpit's public API. This is not necessary: the Cockpit API is completely independent of jQuery, and in fact many of our pages don't use jQuery at all. It also prevents us from updating jQuery to a current upstream version, as 3.0 changed quite a few things [2]. As a first step, I just cleaned up the documentation and examples to completely remove this [3]. Next we need to find out which external Cockpit pages use the bundled jQuery and make them stop doing that. In a lot of cases, it's fairly trivial to just completely drop jQuery in favor of standard functions like `document.getElementById()` or `addEventListener()`, and for the others the project should use their own jQuery version through npm as usual. I will go through Fedora, RHEL, and GitHub to search for these projects. Does anyone know about such projects? Please point them out to me! After that, we can update jQuery in Cockpit at last, and from then on treat it as an internal implementation detail instead of API. The same goes for PatternFly, but at least that was never documented as API nor being used in the examples - so I think we should be okay there. Thanks, Martin [1] http://cockpit-project.org/guide/latest/api-base1-jquery.html [2] https://jquery.com/upgrade-guide/3.0 [3] https://github.com/cockpit-project/cockpit/pull/8504/commits [4] https://github.com/cockpit-project/cockpit/pull/8505

1 0

Host Devices
by Marek Libra 27 Jan '18

27 Jan '18

Hi, I would like to renew the effort on Host Devices for Cockpit [1]. To move forward, let's implement it step by step while opening brand new PR picking just a subset of the already implemented functionality [1] while adjusted to generally acceptable form. Initial implementation would meet: - PCI support only - initially read-only: just the List of devices by their Class (according to [2]) - example: by Audio device, Ethernet Controller, etc - data source: sysfs - make use of backward-compatible lspci for data preprocessing (especially manipulation with HW database) - monitor for changes by listening kernel uevents Follow-ups will lead to [3] scope: - for pci, active actions are allowed for selected device classes, one PR per each: - (un)bind VFIO driver - configure SR-IOV network cards - vGPU configuration - additional view by Driver - What devices is the driver bound to? - additional view by IOMMU Groups - For server fine-tuning, what devices are within single IOMMU Group? - support for other buses, i.e. USB or SCSI - their views are independent on each other due to fundamental differences Please let me know your thoughts. Thanks, Marek [1] https://github.com/cockpit-project/cockpit/pull/5523 [2] http://pci-ids.ucw.cz/ [3] https://github.com/cockpit-project/cockpit/wiki/Feature:-Hardware-Devices -- Marek Libra senior software engineer Red Hat Czech <https://www.redhat.com>

4 8

Cockpit 160 released
by Martin Pitt 24 Jan '18

24 Jan '18

http://cockpit-project.org/blog/cockpit-160.html Cockpit is the modern Linux admin interface. We release regularly. Here are the release notes from version 160. Add kubevirt Virtual Machines overview -------------------------------------- kubevirt is a project for running KVM virtual machines in Kubernetes. Cockpit's "Cluster" (Kubernetes/OpenShift) dashboard can now show the status of these VMs in the new "Virtual Machines" menu entry. This only appears when kubevirt is installed and active: Screenshot: http://cockpit-project.org/images/kubernetes-kubevirt-list.png In the future this will be extended to also do operations on the VMs. Thanks to Jakub Niedermertl for this feature! Redesign package list on Software Updates page and show RHEL Errata ------------------------------------------------------------------- The table of available updates now looks and behaves much more consistently to other products that handle software packages, like Satellite and Welder: * It now only shows the first line of the description and number of fixed security issues or bugs in the table, and moves the full description and detailled bug/CVE lists into an expander. * It shows icons for the severity of the update, i. e. "security", "bug fix", or "enhancement". * On Red Hat operating systems it also shows the classification (https://access.redhat.com/security/updates/classification) of security updates and links to the corresponding Errata. * PackageKit often provides the update details in Markdown format. This now gets rendered properly instead of shown verbatim in text. Screenshots: http://cockpit-project.org/images/packagekit-errata.png http://cockpit-project.org/images/packagekit-markdown.png AppStream handling on Apps page ------------------------------- On Fedora, the Apps page now installs the `appstream-data` package when checking for new applications, which ships the AppStream metadata for discovering new Cockpit applications. This Cockpit version also adds AppStream metadata for its own `cockpit-sosreport` package (which is not installed by default). Once `appstream-data` gets updated again in Fedora, cockpit-sosreport will appear on the Apps page as an available extension. Change CPU graphs to use "100%" for a fully loaded multi-processor system ------------------------------------------------------------------------- Previously, the CPU graphs on the System, Dashboard, and Containers pages were calibrated to 100% for a single CPU core, so that the graph maxed out at e. g. 400% for a system with four busy CPU cores. Now it gets scaled so that "100%" means "all cores are fully busy", which is the behaviour of command line tools like `top`. Show storage, network, and other numbers with 3 digits of precision ------------------------------------------------------------------- Previously numbers like the free space on a storage device were shown with one fractional digit only, which led to overly imprecise numbers like "0.1 GiB". The new behaviour provices a more consistent accuracy regardless of the number's magnitude. Add an example bastion container -------------------------------- A bastion container provides Cockpit's web service without actually logging in to the machine on which it runs, but only connects to remote hosts via ssh: https://github.com/cockpit-project/cockpit/tree/master/containers/bastion This is not a ready-to-use product for now, but we encourage you to experiment with the example and give us feedback if you have such a use case. Get it ------ You can get Cockpit here: http://cockpit-project.org/running.html Cockpit 160 is available in Fedora 27: https://bodhi.fedoraproject.org/updates/cockpit-160-1.fc27 Or download the tarball here: https://github.com/cockpit-project/cockpit/releases/tag/160 Take care, Martin Pitt

1 0

Cockpit Applications in Containers
by Marius Vollmer 19 Jan '18

19 Jan '18

Hi, here are some brainstorming notes about what might come next regarding Cockpit apps. Any feedback highly appreciated! Cockpit can discover and install add-ons that come as RPMs or DEBs. Cockpit uses the regular AppStream mechanism for this that is also used by GNOME Software to discover and install Desktop "add-ons". Cockpit reads the "AppStream collection metadata" to discover available add-ons, and the RPMs and DEBs install small "AppStream upstream metadata" files into /usr/share that Cockpit reads to figure out what is installed. We also want to discover and install Cockpit add-ons that are in container images. The Desktop world has Flatpaks for this, and they are working on shipping Flatpaks as standard OCI container images. Flatpak also uses AppStream to describe individual images. Owen is working on "metastore", which should give us the equivalent of the "AppStream collection metadata" for container image registries. Once pulled, we can look at the labels and annotations of the images/containers to find the "AppStream upstream metadata". But how does a add-on in a container work? I would try this: - A container needs to be running before Cockpit takes note of it. Having just the image pulled to local storage means nothing. - When starting a session, the shell will find all running containers with a special label and "exec" a bridge in them (if the logged in user has enough permissions). - Implementation-wise, such a container is like a remote machine. URLs refer to it explicitly. Its packages don't need to be distinct from those of other containers. - UI-wise, their manifests and iframes are merged with those from the bridge that runs outside of any container. We could start by only allowing "dashboard"s in containers, that ought o be quite simple. - We can even extend this merging to real remote machines so that you get all dashboards from all your machines merged in your browser window. - In the "Applications" tool, we don't talk about "installing" applications that are in containers, but about "enabling" them. Enabling such a container means running it in its default way, and making sure it gets started on every boot. Somehow. - We could extend this terminology to RPM/DEB apps as well. "Enabling" an app makes its entry appear in Cockpit, "disabling" makes it go away. If that needs some more rpms or images or something else, that's an implementation detail. - The process of enabling something could talk more clearly about what will happen and let the user confirm this. Does this make sense?

2 1

Meet the first Cockpit application, Fleet Commander!
by Marius Vollmer 12 Jan '18

12 Jan '18

Hi, the Fleet Commander should now show up as a Cockpit application on Fedora 27 (and maybe elsewhere). Please try it out!

2 6

Cockpit 159 release
by Martin Pitt 11 Jan '18

11 Jan '18

http://cockpit-project.org/blog/cockpit-159.html Cockpit is the modern Linux admin interface. We release regularly. Here are the release notes from version 159. Configure data deduplication with VDO devices --------------------------------------------- The "Virtual Data Optimizer" is a new feature to eliminate duplication and add compression to block devices. This is mostly aimed at providing storage for virtual machines or object storage systems like Ceph. This is being developed upstream by the dm-vdo GitHub project (https://github.com/dm-vdo) It is currently available in RHEL 7.5 alpha (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/ht…) and expected to land in other distributions eventually. Cockpit's Storage page can now create and configure VDO devices. Video: https://www.youtube.com/watch?v=_iOYN4Y24aY Add serial console to virtual Machines page and redesign the Consoles tab ------------------------------------------------------------------------- The Machines page has offered in-browser and external VNC console access to virtual machines for some time. However, this does not work on "headless" virtual machines that don't provide a (virtual) graphics card and VNC libvirt device. The Consoles tab now offers a serial console for these kind of VMs to be able to administer them from Cockpit as well. This went along with a redesign of the Consoles tab to better fit the various types of consoles. Video: https://www.youtube.com/watch?v=nT2EA6wYkKI Thanks to Marek Libra for this feature! Show more error message details for VM failures on virtual Machines page ------------------------------------------------------------------------ Errors from virtual machine operations on the Storage page can now be expanded to show more details: Screenshot: http://cockpit-project.org/images/machines-error-expander.png Thanks to Marek Libra for this improvement! Get it ------ You can get Cockpit here: http://cockpit-project.org/running.html Cockpit 159 is available in Fedora 27: https://bodhi.fedoraproject.org/updates/cockpit-159-1.fc27 Or download the tarball here: https://github.com/cockpit-project/cockpit/releases/tag/159 Take care, Martin Pitt

1 0

Replace term.js-cockpit by xterm.js
by Marek Libra 09 Jan '18

09 Jan '18

Hi, I'm considering exposing the VM consoles we already have in Cockpit for their reuse by other projects, like ManageIQ or oVirt's VM Portal. One way to do it is moving them under the patternfly-react library [5], partially involving the patternfly community in their later development (and probably even design). The transition would be implemented step-by-step, starting with the serial console. The idea is to externalize VM serial console and underlying Terminal component and "reuse" them back in Cockpit. To do so, it makes sense to move from the term.js-cockpit fork to the maintained xterm.js [1], successor of [2]. Once this is done, other use of the term.js-cockpit will be similarly replaced to depend just on the single [1]. Benefits for Cockpit: - use of upstream-maintained library - leverage last (almost) 2 years of the xterm.js development - be aligned with other related projects on the design level (and drive it!) Disadvantages: - quite a lot of work in backporting term.js-cockpit patches to xterm.js - risks - bugs in already stabilized features might/will appear I've already implemented POC proving this is feasible and the components can provide reasonable wrapping/API. There's still a lot of work to be done, starting with porting of [3] to [1]. So, here's the question: is this something what makes sense even for Cockpit-maintainers? If so, is there already any experience (good/bad) in merging some of the [3] into any successor of [2]? The most important and maybe debatable seems to be [4]. Thanks for opinion, Marek [1] https://github.com/xtermjs/xterm.js [2] https://github.com/chjj/term.js [3] https://github.com/cockpit-project/term.js/commits/master [4] https://github.com/cockpit-project/term.js/commit/2eecc46a9657e0dbcdad5e9b1… [5] https://github.com/patternfly/patternfly-react -- Marek Libra senior software engineer Red Hat Czech <https://www.redhat.com>

3 2

Cockpit hackfest at devconf.cz
by Martin Pitt 08 Jan '18

08 Jan '18

Hello all, https://devconf.cz/ is approaching fast! As last year, we will host a Cockpit Hackfest community meetup again. Please come join us if you want to learn about how to create your own Cockpit pages, improve the existing ones, poke our brains about how to do stuff, or simply say hello. The preliminiary schedule [1] says that the hackfest will happen on Friday, January 26th, in room C236. This fits about 15 people. See you there! Pitti [1] https://docs.google.com/spreadsheets/d/1U5ie3mLBBbx-EuNRfR6Nbo74SN3ve_sPApV…

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

cockpit-devel January 2018