Hi Danek, My thoughts and responses are in-line.
I'd like to get together on Wednesday to work through this issue. Would 10 am PDT work for everyone? Thanks, -evan Danek Duvall wrote: > On Mon, Jun 15, 2009 at 11:35:13AM -0600, Evan Layton wrote: > >> Danek Duvall wrote: >>> Using the version of "entire" to detect a version mismatch isn't >>> particularly supportable, as the package itself may disappear as we settle >>> on a plan to get consolidations publishing pkg(5) packages natively. What >> This is what you, Ethan and I had discussed while I was out there in Menlo >> Park the week before last. I had thought that what you had suggested was >> that for now we use entire but going forward we would need support from IPS >> to give us the version similar to what we can get from '"entire" today. > > So on further reflection I think just using the list of package versions as > the comparison will be as good a check as any other. In some cases it may > be overly restrictive, but in time, we hope to greatly reduce, if not > eliminate that. Which packages are you referring to besides things like the zfs packages, and maybe tings like SUNWcsr etc? Plus wouldn't we also have to know about changes to not only the kernel but kernel modules, drivers etc? This is all information that while technically we could get we would probably need to know beforehand which packages to check which is not something we can do very feasibly. The appears to require us to duplicate work that IPS already does when doing an image-update. Having to do this same kind of check is a lot of overhead and duplicated effort that IPS could be doing for us and removes capabilities that IPS already provides in the form of the "entire" package. While you've said that is may not be available going forward something that provides this same type of information from IPS seems to be required. > >>> I would suggest instead is to ensure that the list of package versions in >>> the AI image is a subset of the package versions in the catalog of the >>> repository (or repositories) you're installing from. If you're feeling >>> exceptionally paranoid, you can check that the manifests of those packages >>> are identical. >> While we could do this it seams like a lot of checking that should really >> be done by IPS for us. If IPS is not going to give us something similar to >> what we can get from the "entire" package now then we'll need IPS to give >> us another way to determine this information. When that information is >> available we'll switchover to using that instead of "entire" > > We'll likely need to give you something for the paranoid check, but the > package version list is something you can likely do now. I really think we will need more than just this paranoid check part of things as we won't know all of the packages we may need to check. That information will have to come from IPS. > >>> Otherwise, it seems like a lot of support for a condition that you're not >>> technically supporting ... >> I'm not sure what's meant by support here. We have to have a way of >> determining the version and returning that information back to the user. > > I mean support for "leaving the reservation" and installing a version of > the OS that doesn't match what you've booted. There's no other reason to > have the zfs version marked anywhere, for instance. Ah ok, I see what you're getting at. The example of the zfs pool version isn't part of the version checking per say but is part of out best effort to do an install anyway. Even though the user is attempting to do an install the is not "supported" we want to make a best effort to do the install anyway but that doesn't guaranty that the install will be successful. -evan
