----- Original Message -----
> From: "Marius Vollmer" <[email protected]>
> To: "Development discussion for the Cockpit Project"
> <[email protected]>
> Sent: Tuesday, November 17, 2015 2:59:51 AM
> Subject: Re: Request for comment and suggestions on pyblk and Cockpit
> integration
>
> Anne Mulhern <[email protected]> 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?
Yes, that's right, with the emphasis that it is not just display but
comparison, storage,
_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
> 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.
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
udev database.
> _______________________________________________
> cockpit-devel mailing list
> [email protected]
> https://lists.fedorahosted.org/admin/lists/[email protected]
>
- mulhern
_______________________________________________
cockpit-devel mailing list
[email protected]
https://lists.fedorahosted.org/admin/lists/[email protected]
