Sarah Jelinek wrote: > Hi William, > > William Schumann wrote: >> Request for code review: 909 - Target Discovery must find Solaris >> instances in BEs >> >> Target Discovery must provide the disk devices containing Snap Boot >> Environments to the GUI so that user is informed of Solaris BEs on a >> disk. >> >> be_list() provides a list of Solaris Boot environments, but requires >> some preparation, since zpools must first be imported >> >> This code performs two workarounds: >> >> Workaround: INST_RELEASE, which contains release information, is >> missing from >> Caiman, and is in the process of being re-established. Code to read >> INST_RELEASE is conditionally coded >> >> Workaround: 'zpool status' is used to retrieve the disk device name >> holding the >> Solaris BE. The output of 'zpool status' was not designed to be >> parsed; the >> parsing of this output is perhaps unreliable. An outstanding CR >> exists to >> supply this functionality: >> 6667439 A parsable option for zpool status and zpool list is needed >> > Do we have a contract with the zfs folks to use the current output for > parsing? It is likely unreliable and was most likely arc'd as unstable > or private. A contract would at least provide us notification if > something changed in the output(theoretically anyway...). There is a > library, libzfs, with a zfs_status.c file that does allow checking > status via zpool_get_status(). This is possible more stable? >
We can't have a contract yet because we haven't arc'ed anything, which would be a prerequisite. We're using libzfs from libbe (and will be getting a contract or whatever when we get that far), so using those interfaces should be possible. Dave > thanks, > sarah > **** >> http://cr.opensolaris.org/~wmsch/bug-909/ >> http://defect.opensolaris.org/bz/show_bug.cgi?id=909 >> >> William >> >> > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
