This is Devyani Kota, part of the RHGS team at RedHat, currently
to the Gluster storage plugin for cockpit-ovirt.
We have created a few mockups for the same, that are attached along with the
mail. We plan to add the 'Gluster' info under the Storage Tab listed on the
Under this "Gluster" Tab, we will be listing:
1. The information of the hosts in the cluster, labelling the host machine
which is the hosted-engine.
2. The volumes on every host, and their respective info like, the device
they are mounted on, the size of the disk that they occupy, etc.
The mockups listed give a clear picture of the concept, and a simple
on what we are trying to achieve.
Any reviews/suggestions on the same will be appreciated :)
Looking forward to the feedback.
Thanks and regards,
The project I was working on, foreman, has started using react.js and
redux for portions of the UI. I have done any work in this area before but
noticed that cockpit has a good number of jsx files. Has anyone set up
storybook to do dev work on cockpit?
Wondering how others do dev work on the image registry portion of cockpit.
Here's what I'm trying...
I have minishift running in a VM w/ the registry bits turned on and
accessible. Separate VM has my cockpit dev env set up but the "Image
Registry" tab says simply "Couldn't connect to server". Debugging I see
it's trying to use localhost but that there are a couple env vars that I
could potentially set. My attempts have not worked, though. It is also
calling kubectl I think so should I manually config that on the cockpit VM?
Many of the Cockpit folks are having a Hackfest in Karlsruhe, Germany
from the 26th of June until the 30th. You might have already heard about
this from other postings on this mailing list.
This is a targeted hackfest: VM and libvirt support in Cockpit is the
focus. If you do want to join in to work on the VM functionality, ping
us on IRC at #cockpit on Freenode or reply to this email.
It's likely that we'll be having another Hackfest in Autumn that will be
more broad, both in what we work on, and the people who decide to come.
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'm currently developing a package to set the display resolution/orientation/rate using Xrandr command suit. It's already working good but now I need to store my configs on X11 config file (in order to persist the config as mentioned here https://wiki.archlinux.org/index.php/xrandr#Configuration ).
My question is: what is the best way to manage files using cockpit ? I'm currently throwing bash commands for that and in my opinion it's not looking good.
as a next step for the cockpit-machines, I plan to implement the "Create
Before doing that, I would like to collect ideas, agreement on scope and
preferably on design.
The long term vision is support for (almost) all features as virt-manager
Definitely, path to this goal has to be splited into smaller steps,
starting with something generic enough but providing just the minimum and
The component will be reusable for both "New VM" and "Edit VM" flows.
Will be implemented as a wizard, user can navigate back and forth, maybe
even "jump" into a step of his choice.
Wizard can be canceled in every step.
All write operations are postponed until final "submit".
Optional "external provider" will be able to extend the wizard dialogs and
will handle the "Submit".
Wizard dialog 1: Basic props
- VM name
- qemu connection (whether session or system)
Wizard dialog 2: Disks
- single disk's params
Wizard dialog 3: Boot order
- cdrom iso file
- from an associated disk
Wizard dialog 4: Consoles
- select none or any combination from
- address and port can be specified, defaults provided
Wizard dialog 5: Summary
- All entered details are listed (tree-list component?)
- User can navigate back, cancel or submit
- User can select multiple existing disks and/or create multiple new ones
- "Networks" wizard dialog plus PXE boot
- "submit and run" functionality
- "Edit VM"
- cdrom iso from network source (URL)
Later on, new wizard dialogs can be added or existing ones extended.
So far I considered but rejected these other concepts:
- single complex dialog (no wizard, sort of "functionality grouping"
would be still required)
- "Edit" functionality mixed with the recent presentation components
(nightmare for more complex configuration)
I'm looking for feedback - e.g. UX, extensibility, scope or whatever to be
taken for consideration.
senior software engineer
Red Hat Czech