----- Original Message -----
From: "Marius Vollmer" <marius.vollmer(a)redhat.com>
To: "Development discussion for the Cockpit Project"
Sent: Tuesday, November 17, 2015 2:59:51 AM
Subject: Re: Request for comment and suggestions on pyblk and Cockpit integration
Anne Mulhern <amulhern(a)redhat.com> writes:
> I'm looking for feedback on how Cockpit might be able to use these
> capabilities, and what Cockpit would require to make these
> capabilities accessible to it.
> If you can, could you take a look at the whitepaper here:
> We have discussed a lot of ways the info pyblk can generate could be
> served up to the user. For example, we could attach graphs (or
> pointers to the graphs) to journal entries. We could be more
> independent and instead have a facility to look up graphs by means of
> time-stamps. We can present diffs of graphs of the state of storage
> before and after a certain time.
> What do you think of any of this? Please let us know.
So, pyblk offers two new things, right?
- Better display of the storage 'hierarchy' by admitting that it is
actually a DAG and that nodes can have more than one parent
- Facilities for snapshotting configurations over time and comparing
Correct? Did I miss something big?
Yes, that's right, with the emphasis that it is not just display but comparison,
_everything_ made more sensible by using a DAG representation.
One thing that I subsequently realized that I failed to mention in the
document, is that some of pyblk's expressiveness comes from the powerful
networkx library that allows it to calculate graph isomorphisms in
a very flexible way. So, the graph comparisons can be made quite interesting,
but in large part because of this nice library (which in turns depends
to some extent on a bunch of C libraries).
Cockpit does quite a bit of storage hierarchy walking itself, and
currently it uses unsatisfying code full of case analysis. It would be
nice to generalize this.
Of course, there are dangers in generalizing, and Cockpit should always
strive to natively understand all the different kinds of storage
objects. However, showing a generic DAG is better than just showing
unknown things as "Other Devices". The code will be cleaner even for
the things Cockpit does know about.
Also, while Cockpit does allow navigation of the storage hierarchy, it
doesn't provide a good overview of it. That would be a valuable
The way to make the pyblk features accessible to Cockpit would be to
integrate pyblk with Storaged:
It might start out as a module that adds new StorageGraph interfaces to
all relevant objects, with Parents and Children properties.
I can take a more in-depth look at storaged and see how this would work.
If I have questions should I ask you or ....?
Investigating the history of storage configurations could probably be
added quite easily to the overview page. I think Storaged would also be
the right place to expose this to Cockpit.
As a more detailed comment, I think that looking at the device mapper
nodes is not the right level for LVM. Instead, we should look at the
'native' LVM objects, physical volumes, volume groups, pools, snapshots,
and logical volumes. This means that pyblk needs to know about LVM, but
if it doesn't, then it is much less useful for Cockpit, unfortunately.
This could be more or less complex. The current names shown are just
udev's DEVNAME and are not so informative, everybody agrees. Showing for
lvm the particularly names that dm uses would be absolutely straightforward.
But taking a plunge into showing whatever more complex relationships lvm
builds on top of dm would be another step. Currently, all operations rely
solely on information that can be extracted directly from sysfs or the
cockpit-devel mailing list