the dependency of storaged on UDisks is itching me a bit. It should
work very well with it, but I think it should also work without it, I'd
We are not far away from that goal, actually. Here is what I have in
- Add "Device" property to LogicalVolume. Then clients can work with
logical volumes without UDisks.
- Add PhysicalVolume objects, with "Device" etc properties and "Remove"
etc methods. Make PhysicalVolumeBlock point to it instead of the
- Change VolumeGroupCreate and AddDevice methods to take /dev/foo
devices instead of UDisks object paths.
- Add VolumeGroupCreateFromUDisksPath etc.
- Add UdisksBlock properties to LogicalVolume and PhysicalVolume that
point to the UDisks objects.
- Have our own Job interface.
- Just watch whether UDisks is running, but don't start it.
What do you think?
UDisks2-2.1.1 in cockpit-deps has been superseded by udisks2-2.1.2 in
Fedora 20, so we can't create new images currently.
Storaged is _this_ close to be able to replace the patch, so instead of
porting the old LVM2 patch forward, I have just removed the now useless
udisks2 package from cockpit-deps.
I spoke to Colin (since he wanted to look at that this week) and Patrick
earlier today about what we need to do for Networks in the immediate
future, based on the feedback from Russ:
* Regular connections (and changing the details of those)
* See how the connection is doing (performance+errors)
It's also important that the design supports at least 4 ports or more
(as in 4 cards or a card with 4 ports).
I've put some initial designs up here:
Let me know what you think, if there is anything missing, if something
that is unclear, or just plain wrong.
UDisks2 has trouble with thinly provisioned logical volumes in Fedora
20, which also affects storaged and Cockpit in delicate ways, so this is
a little heads up.
Basically, UDisks2 doesn't always create a D-Bus object for the block
device of a thin volume. (And it sometimes creates one erroneously for
Cockpit used to rely on the existence of a block device object to
determine whether or not a volume was active or inactive. When UDisks2
doesn't create these objects reliable, this becomes unreliable and we
might see a "inactive" volume in the UI that is in fact active. Trying
to activate such a volume doesn't work and things are just weird.
Initially I thought we just work around the bug with some udev hackery,
but the final fix isn't really clear to me yet, so maybe the hack will
just make the mess bigger.
Instead, I have made storaged and Cockpit more robust: A active volume
without a block device object is now labelled as "active, but
unsupported" and you can't do anything with it.
Luckily, deactivating and then reactivating a volume will make it
visible to UDisks2, and I am going to use that workaround in the test
suite for now.
I'm curious if and how Cockpit handles mounting of NFS/CIFS and other
non-device stuff. AFAIK UDisks2 supports only mounting of block devices.
Do I miss something?
E.g. people might be interested in mounting remote filesystem and/or
watching their /tmp (on tmpfs) growing and getting alert when it fills up.
before switching off for the rest of the year, a little status. I have
three branches pending in this order:
- wip/permanent-dashboard, pull request #170.
Stores the list of machines on the machine running cockpit-ws, with
the usual notifications, etc. Can discovers machines via OpenSLP.
A gross hack to enable the "manage" button for all machines on the
dashboard. It's ugly but better than the status-quo, IMO.
A 'wizard' kind of thing that can synchronize user accounts from one
machine to another. This is very raw.
If someone wants to review these, please start at the top.
Have a great holiday!
On 12/21/2013 01:48 PM, Allan Day wrote:
> Hey Andreas!
> Andreas Nilsson <lists(a)andreasn.se> wrote:
>> Lots of open questions so far, but a bit of a start at least.
>> Feel free to fill out Objectives you think needs to be covered, or leave
>> comments on the design so far under Comments or here on the list.
> Looks good. I've got some ideas here for some objectives. I thought
> you might want to look over them before I stick them on the wiki.
That list looks good to me.