On 01/ 8/10 07:02 PM, Ethan Quach wrote: > Dave, > > Overall looks good. Just a couple of questions/comments ... > > > 1. For AI servers running Osol, we've got known issues when the > AI images are put in shared datasets across BEs. So I'm wondering > if there's any reason why *not* to put the AI images in a non-shared > area by default. Because we're on zfs, there shouldn't be any > additional space cost across BEs...? >
I think that's what my proposed default (when the user doesn't specify a targetdir) of /export/auto_install/<svcname> does. Something else I'm missing? > 2. For the any-i386 service, if the pxegrub 2nd-stage loader comes > from some service (let's say the first x86 service that was created), > will its use to the load a kernel from all other install services that > are presented in the global grub menu always be compatible? I > thought that's a hole but am not 100% sure. > In general this shouldn't be a problem, it's just required to be a multiboot-compatible next stage that pxegrub loads. > (Note just to be aware, there currently is a bug in grub, 6785975, > that limits the of size the grub menu. The Evaluation doesn't really > give any indication that a fix to provide an un-limited sized menu > can be had.) > Need to see what pxegrub's limits are, I guess, but I'd imagine they're similar. Probably argues for some way to tag which services should be in the global menu (which I can see might be desired for other reasons). > > Update > ------------ > 3. One of the things that'd seem important, especially in the bi-weekly > build rollout environment, is that new services may want a copy of an > existing service's configuration (namely, the manifests and criteria > bank) particularly from the service serving the previous build. > Could this be achieved? > > In SXCE, when a new installation boot image is added to a server, > a script (the same script every build even) could be run to do a mass > re-add of clients; though this is different / not required in AI's model, > the result of this in SXCE is that the config is brought forward and > re-verified with the newly added install image. It seems here, we > need to provide a way to carry the config forward as well. > Yes, I agree this would be the desired behavior. The internal conversion to a create-service described in the last paragraph in example 3 probably is more like a clone and then update. > What is the behavior of update-service when updating a service > that is not aliased? If a new service isn't created in this case, I > think we need to re-validate the manifest/criteria config. > No, it wouldn't create a new service, so you're right that some validation would be needed. Dave
