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:
https://mulhern.fedorapeople.org/pyblk_rfc.pdf ?
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
them
Correct? Did I miss something big?
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
addition.
The way to make the pyblk features accessible to Cockpit would be to
integrate pyblk with Storaged:
https://github.com/storaged-project/storaged[1]
It might start out as a module that adds new StorageGraph interfaces to
all relevant objects, with Parents and Children properties.
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.