Brock Pytlik wrote: > jmr wrote: > >> Brock Pytlik wrote: >> >>> 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. >>> >> Pity - would have been nice to surface this in the UpdateManager GUI. >> One option would be to do the evaluate in the UMNotifier which runs >> periodically in the background to check for updates, then cache this >> data for the UM GUI to consume later on, would reduce startup and >> allow us to notify the user about these issues. >> > That would be fine by me. > >>> 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. >>> >> That's just a workaround until we get the list of packages directly >> from the API :) We agreed that this would not happen for the initial >> release. >> > ok :) Just wanted to be sure it wasn't what you were expecting to > continue to get. > >>> 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. >>> >> Its the size we want :( Tends to be more relevant for updates for users. >> > So how were you getting size quickly in the past? > >> [snip] >> >>>> 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. >>> >> Well what would be nice would be to have pkg refresh take an optional >> cache option so it would save off a single cache file of all the >> manifest data that is in lots of separate files. Then when we have an >> API to retrieve the inventory and with the existing one to get info >> objects they could take a boolean option to retrieve it from the cache >> or directly. That way you hide the details from the clients but make >> fetching the manifest data a lot faster. Its up to the clients to make >> sure refresh has been called with the cache option. >> >> If this isn't done we will end up generating a cache file using >> UMNotifier to do the work and have the client consume it if its >> available, but then we will have different code paths for consumig the >> cache or the API info objects :( >> >> > > I feel reasonably certain this isn't code that should live within the > API, but I could be convinced otherwise. I do think that adding this > kind of cacheing into the API, would be a task that lived down the road. > Also, if you wanted to, you could write the caching stuff inside the > API, and use it as you wanted to, if you think it really belongs inside > there. Personally, I think it's potentially dangerous to say things like > "the client will always call refresh appropriately before looking at the > cached data" without a programmatic way of enforcing such a constraint. > > Just to follow up on my own thoughts. I feel certain this shouldn't be part of the API. Whether it should be a change to our back end to allow fast retrieval of certain manifest information is a separate issue. I do think this isn't a question that the API should expose.
Brock > 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
