jmr wrote: > Brock - the first thing we do in the UpdateManager is get the list of > pkgs and state dic's that describe the packages using > img_obj.inventory(). As long as the data is available in the state dic > we can consume it. This would seem to be the right place to add a reboot > flag (could be an enum if there are a range of values based on severity > level). > > One issue I have at the minute is that the state dic contains an > incorporated flag which is great but its not updated so not so good. If > you just add a reboot flag to the state dictionary then we can grab that > too. This way the GUI's can leverage information coming back from the > API with minimal change. > I don't think this is a viable solution. I don't think I explained things clearly the first time, so let me try again. A package as a whole won't cause a reboot, a specific action within that package will. Whether or not that action is performed will depend on the version being upgraded from and to. So it doesn't make sense to make a package as reboot needed before the installation of that package has been evaluated.
Also, encoding a particular implementation of Image.inventory() (or the implementation of its state dictionary) which escapes past the API is, imo, the wrong thing to do as its exactly things like this that have caused problems in the past. More generally, that solution doesn't solve the problem of "installing these 6 packages will cause these 9 services to be restarted." The reason I'm a proponent of option 3 is that it allows us/package creators to add new services to be restarted without having to coordinate the change with the clients. When the clients are aware of specific actuators (I think that's the new term for things that let us know a reboot is needed, or to restart an smf service, etc...), they can notice a particular flag and present their UI accordingly. But, when a new flag is added they're not aware of, they can fall back to the string and severity level for a generic UI display. As a side note, if info is really slow because it's touching the disk, I can add a brief option, or a no-summaries option, or something like that so that the manifests (and the summaries) aren't retrieved from disk. Then the summary and size returned would simply be None. As for the incorporated flag, I don't have a clue what that is. In the GUI, is that indicated by the little green star thing? In any case, I'm not sure what it's purpose is, who's maintaining it, or whether it should go away. > One other problem I have at the minute is fetching info objects from the > api is painfully slow. So for instance I'd like to display the size of > the packages to upgrade in the treeview, but it takes over a second to > fetch each info object to get this data from the manifest, which is way > to slow for us. At the minute I just hide the size column and force the > user to click on the row to get the details, including size . Not ideal > but workable atm. What we really need is caching support on the client > for the info objects and the underlying manifest data. Other wise we > will end up doing the caching and that seems to be broken. > I would tend to say that caching information should be handled by the client according to their needs, since different clients might have vastly different cacheing protocols and needs, and to force a single one into the API, or make several available via the API seems the wrong direction to go to me. I'll admit I'm confused as to exactly what the problem is. I understand that info is slow since it must touch the disk to read the manifest, but how was that not the case before? Doesn't packagemanager currently have to read in each manifest from disk to get its summary and license anyway? I don't think the API should replace whatever cacheing system you were using to make that fast, I think it should replace those times when the package manager was directly reading the manifest from disk. Does that make sense? Brock > What do you think? > > JR > > for pkg, state in sorted(image_obj.inventory(all_known = True)): > while gtk.events_pending(): > gtk.main_iteration(False) > if state["upgradable"] and state["state"] == "installed": > pkg_upgradeable = pkg > if not state["upgradable"] and > image_obj.fmri_is_same_pkg(pkg_upgradeable, pkg): > count += 1 > # XXX: Would like to caputre if package for upgrade is > # incorporated, could then indicate this to user > # and take action when doing install to run image-update. > if state["incorporated"]: > incState = "Inc" > else: > incState = "--" > > Brock Pytlik wrote: > >> After talking with Bart this morning, I think we probably need to make a >> small change to the API structure. >> >> He pointed out that, shortly, we'll have a way of detecting when a >> reboot is needed to install a package, and installing it in an alternate >> image (if I understood him correctly), but there's currently no way of >> returning that information out past the API. He also suggested having >> way giving general messages to the users so that changes made behind the >> API which have UI implications can be passed on automatically to the >> clients without making them sync up. >> >> In general, I think the solution is to either change what plan_X >> returns, or add it to the plan description. In addition, I think we >> might want a way to hand back information for the user after execution. >> The situation I'm thinking of goes roughly like this for the gui: >> Uses tries to install package Foo. >> Packagemanager plans the install and notices that a reboot will be >> required and informs the user of this. >> User clicks ok, and the installation happens >> After installation, packagemanager shows a reminder to the user that >> they'll have to reboot in order to use this new package >> >> I think there are two design issues: where to pass the data around; what >> data to pass around. >> >> For the first, I think the right answer is to include it in the return >> values from plan_X and execute_plan, but I could be convinced the client >> should get it instead when asking for the plan description. >> >> As for the second issue, I've imagined three broad approaches. >> 1) Return a list/set of flags (like RebootNeeded) possibly along with >> their severity. I'm imagining 3? levels of severity, 3: very dangerous, >> used when a user is trying to do something we know to be bad (like >> creating an image at /); 2: caution: used when something out of the norm >> will happen, like a reboot being needed; 1: informational, other >> information which might be desired. >> 2) Return a block of text or a list of strings possibly along with a >> severity which should be presented to the user before proceeding. >> 3) A combination of 1 and 2. Return a list of flag, string, severity tuples. >> >> The advantage of 1 over 2 is that the UI has more freedom for choosing >> how to present the user with information. The disadvantage of 1 is that >> it forces the GUI to move in lockstep with the backend (something we're >> trying to decouple I think) so that it's ready when new flags are >> presented and knows what to do with them. Of course, 2 has the opposite >> strengths and weaknesses. It decouples changes in the back end from >> modifications to clients, but has the downside of putting some of the UI >> decisions into that code. >> >> My preference would be for 3. It has the advantage of allowing the GUI >> to present the user with a UI for a flag when it recognizes the flag, >> and fall back to simply displaying a string when it doesn't recognize >> the flag, which decouples the GUI from having to change whenever the >> back-end changes. This disadvantage to this approach that I can see is >> the added complexity in the initial coding for the client. >> >> If we go with option 1, severity probably isn't actually needed, since >> the GUI has knowledge of what the flags mean. If options 2 or 3 are >> chosen, I think severity is a necessity to help the clients with >> organizing and prioritizing the material. >> >> Thoughts, comments? >> >> Brock >> _______________________________________________ >> pkg-discuss mailing list >> [email protected] >> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss >> >> > > _______________________________________________ > pkg-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/pkg-discuss > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
