Michal Pryc wrote: > Hello, > I am sending this e-mail to caiman-discuss as well to the pkg-discuss. > For people from the caiman-discuss, which didn't follow the thread, the > orignal message is at: > > http://mail.opensolaris.org/pipermail/pkg-discuss/2008-September/006334.html > > In short: > There is an requirement for packagemanager for 2008.11 to have simple > dialog which allows users to delete and switch between BE's created > during image-update. > > Screenshots from current working BE Management are at: > http://cr.opensolaris.org/~migi/be_admin_screenshots_v0/
I think these look good. However the wireframe shown at http://xdesign.sfbay.sun.com/projects/solaris/subprojects/package_mngt/UI_specs/ui_spec_phase2/html-mockup/index.htm differs slightly and I have some nits for the wireframe. On item #1 of "Manage Your Boot Environments" it states "User can set any other BE as the default" but doesn't indicate that this is really the active on reboot and that for this change to take place a reboot is required. On item #1 of the confirmation dialog the note stating that changes will happen on reboot makes it sounds like the BE's being deleted won't be deleted until the system is rebooted. It needs to be clear that the reboot only appiles to seting the active (or default) BE and that the BE deletes will happen immediately. > > Because packagemanager and IPS are back-published to all opensolaris > builds, those part needs to work with all versions of libbe and beadm. > That is why in addition to the first webrev, few things needed tweaking. > I have tested this code on builds 86, 94 and 98. > > What was changed? The descriptions will contains numbers e.g. {1-30}, > those numbers are line numbers for the beadmin.py: > http://cr.opensolaris.org/~migi/18_09_be_management_3201_misc_v1/src/gui/modules/beadmin.py.html > > The version beadm in build 86 was using "-f" flag instead of "-F" for > destroy action. Current webrev doesn't check for the opensolaris build > but it checks if output from help message contains only "[-f]" if yes > then it means that we should use "-f" in all other we should use "-F" as > this is new version of beadm {496-513, 153-154, 477-478}. This is safer > then checking for build number and assuming that user have proper > version of beadm and libbe. > > There was another change between build 86 and 98. The libbe.beList() > returns different format and different information. We are checking if > there was any error while getting the list of be's and if there was we > are preventing user to use BE management {392-405}. The older libbe > didn't have any error checking, so we are assuming that the list if correct. > > Another difference was with the dates of creation of be. The new libbe > contains such info within libbe.beList() but the older version didn't > have such information, so we are obtaining this from the zfs command > (but only when libbe didn't give us such info) {413, 417-433, 453-473} > > The whole webrev is at: > > http://cr.opensolaris.org/~migi/18_09_be_management_3201_misc_v1/ Looking at your newer version (v3) status_checkmark.png appears corrupted. I'm still somewhat inexperienced with python but as far as I can tell the rest looks OK. -evan > > Also during tests I have discovered that some dialogs are improperly > used by packagemanager.py (run without destroy) which prevented beadm to > work properly in some cases. This webrev fixes those. > > best > Michal Pryc > > > Ethan Quach wrote: >> Michal Pryc wrote: >>> Ethan Quach wrote: >>> >>>> Michal, >>>> >>>> beadmin.py: >>>> >>>> 447 - I would highly recommend against constructing this path. >>>> Use bee.get("root_ds") instead (we will likely implement a better api >>>> to get these elements in the future so that apps don't need to know these >>>> key names. We won't change the key names of course...) >>>> >>> The problem was to get the date of the creation of BE, I couldn't find >>> this through libbe so I need to make this trick of getting date of >>> creation snapshot. I the bee.get("root_ds") something introduced after >>> nevada 94? I can't get this value (It's always returning None). >>> >> Sigh. You're right, it wasn't added until build 96, which also added a >> "date" >> element which is what you're really after. Constructing this path >> shouldn't be >> done because its private, and it also won't work when we enable this code to >> work inside of zones. Perhaps we do the conditional here again, and >> *try* to >> get the "date" element, and if that fails, do what you have now. > > > _______________________________________________ > caiman-discuss mailing list > [EMAIL PROTECTED] > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
