I haven't heard from everyone yet on their availability but lets shoot for 10am PDT Wednesday. Here's the con-call info:
USA Toll-Free: 866-545-5227 USA Caller Paid/International Toll: 215-446-3648 ACCESS CODE: 1337371 Thanks! -evan Sarah Jelinek wrote: > Evan Layton wrote: >> 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? > > Works for me. > > sarah > ***** >> >> 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 >
