4 ms·

Cockpit itself is trying to be a "platform of sorts for modules to hook into. oVirt, for example, will install a cockpit plugin during installation of a hypervi

Cockpit itself is trying to be a "platform of sorts for modules to hook into. oVirt, for example, will install a cockpit plugin during installation of a hypervisor node allowing you to manage the local host or global cluster maintenance state and see how many VM's are running on the system (I would argue this is of limited benefit since you could just login to the oVirt Admin portal to do the same thing, but hey). So, yes, you're right - a lot of work still needs to be done, but Cockpit itself seems to be an adequate base, just need to add support for managing commonly needed services at least at a rudimentary level though (MySQL/PostgreSQL, Apache/Nginx/lighttpd, Postfix/Dovecot/exim/cyrus, etc).

evol262 9y ago
I'm the maintainer of the oVirt plugin. The real advantage of it is that it allows installation of hosted engine easily, and a 'single pane' overview of a host (oVirt Node status without using nodectl, etc) Since Cockpit wants to deal with dbus, the push is for other utilities (postfix, snmpd, etc) to publish relevant information over dbus, rather than teaching Cockpit the format of each and every configuration file on the system. I wrote the Tuned plugin for Cockpit, and I maintain the oVirt plugin. I gave a talk at Devconf about plugin development, which is extremely easy, but the Cockpit team is small. It's very easy to write plugins for it, but even easier if they expose dbus. That said, the cockpit API (http://cockpit-project.org/guide/latest/api-base1 http://cockpit-project.org/guide/latest/api-base1) makes handling files/processes from client-side Javascript in plugins simple. It's just that you'd need yet another config file parser...
- snuxoll 9y ago
  Never realized it was even possible to do a hosted engine deployment via Cockpit, that's certainly useful (I've always just used hosted-engine --deploy from the command line because that's how I've done it since the 3.x days). Do you have a link to a video of the presentation?
  - evol262 9y ago
    It was a workshop, but no videos that I'm aware of. It was essentially "here's how to use React to build a cockpit plugin from the ground up -- it's easy" I'm a Python/Go backend developer, mostly, but Cockpit is easy enough that even I can write plugins for it. The workshop basically walked through the git tags in https://github.com/evol262/cockpit-boilerplate https://github.com/evol262/cockpit-boilerplate cockpit-ovirt has a "Hosted Engine" tab which is an otopi parser. You'd find it to present exactly the same questions/options as "hosted-engine --deploy" in 4.0/4.1, with ansible and otopi deployments and a new UX in 4.2 which isn't a 1:1 representation of the questions asked. Once Hosted Engine is deployed, the oVirt cockpit plugin can show the complete status of the HE cluster, put nodes into local maintenance, the whole cluster into maintenance, etc.
INTPenis 9y ago
That's great. Before I tried cockpit I tried Kimchi which was also a sort of base for plugins, they had a libvirt plugin. But it was far from finished and required a lot of work. I ended up having to go to the terminal to solve things a lot of the time. So being a Fedora/RHEL fan I will definitely try cockpit with libvirt or ovirt and keep an eye on how it develops. But I also expect the same issues I saw with Kimchi, being forced back to the terminal to solve issues the gui can't do, or for some reason gets stuck on.

evol262 9y ago

I'm the maintainer of the oVirt plugin. The real advantage of it is that it allows installation of hosted engine easily, and a 'single pane' overview of a host (oVirt Node status without using nodectl, etc) Since Cockpit wants to deal with dbus, the push is for other utilities (postfix, snmpd, etc) to publish relevant information over dbus, rather than teaching Cockpit the format of each and every configuration file on the system. I wrote the Tuned plugin for Cockpit, and I maintain the oVirt plugin. I gave a talk at Devconf about plugin development, which is extremely easy, but the Cockpit team is small. It's very easy to write plugins for it, but even easier if they expose dbus. That said, the cockpit API (http://cockpit-project.org/guide/latest/api-base1 http://cockpit-project.org/guide/latest/api-base1) makes handling files/processes from client-side Javascript in plugins simple. It's just that you'd need yet another config file parser...

snuxoll 9y ago
Never realized it was even possible to do a hosted engine deployment via Cockpit, that's certainly useful (I've always just used hosted-engine --deploy from the command line because that's how I've done it since the 3.x days). Do you have a link to a video of the presentation?
- evol262 9y ago
  It was a workshop, but no videos that I'm aware of. It was essentially "here's how to use React to build a cockpit plugin from the ground up -- it's easy" I'm a Python/Go backend developer, mostly, but Cockpit is easy enough that even I can write plugins for it. The workshop basically walked through the git tags in https://github.com/evol262/cockpit-boilerplate https://github.com/evol262/cockpit-boilerplate cockpit-ovirt has a "Hosted Engine" tab which is an otopi parser. You'd find it to present exactly the same questions/options as "hosted-engine --deploy" in 4.0/4.1, with ansible and otopi deployments and a new UX in 4.2 which isn't a 1:1 representation of the questions asked. Once Hosted Engine is deployed, the oVirt cockpit plugin can show the complete status of the HE cluster, put nodes into local maintenance, the whole cluster into maintenance, etc.

INTPenis 9y ago

That's great. Before I tried cockpit I tried Kimchi which was also a sort of base for plugins, they had a libvirt plugin. But it was far from finished and required a lot of work. I ended up having to go to the terminal to solve things a lot of the time. So being a Fedora/RHEL fan I will definitely try cockpit with libvirt or ovirt and keep an eye on how it develops. But I also expect the same issues I saw with Kimchi, being forced back to the terminal to solve issues the gui can't do, or for some reason gets stuck on.