Glenn Lagasse wrote: > Hey Joe, > > * Joseph J VLcek (Joseph.Vlcek at Sun.COM) wrote: >> Glenn Lagasse wrote: >>> Hi Jan, >>> >>> * Jan Damborsky (Jan.Damborsky at Sun.COM) wrote: >>>> Keith Mitchell wrote: >>>>> All, >>>>> >>>>> In some discussions I had today, the issue came up of post-install >>>>> customization of the VM Constructor image. Current design flow >>>>> limits our customization options to installation of custom >>>>> packages - the user can install packages A, B, and C, but they >>>>> can't specify other parameters such as network settings, user >>>>> groups, etc. >>>>> >>>>> How can we support post-install non-package customizations? Could >>>>> this be done via SMF enhanced profile work? Using DC finalizer >>>>> scripts (into the AI image, prior to VM install)? In some other >>>>> manner? To make the VM constructor robust, I think we'll want more >>>>> than just the basics of package selection and VM settings. >>>> With respect to customization of created VM image, I am thinking if >>>> there might be another level of customization based on the scope of >>>> the project. >>>> >>>> Is it assumed that all customization will be done when image is >>>> constructed or will it be allowed to do some customization steps >>>> when VM image is used as a 'template' which might be instantiated/ >>>> deployed later on more than one guest system ? >>>> For instance, we might want to customize IP address/hostname/root >>>> password for each virtual machine created VM image will be deployed on. >>> For Phase 0, customization of the installed virtual machine is entirely >>> dependant on the capabilities to customize an AI client installation >>> (since we're going to use the AI client technology to perform the actual >>> installation). This means, that if you want to customize the install >>> you'll need to create an IPS package which contains your customizations >>> and you'll have to propogate that to the IPS repository you use for the >>> AI client installation. >>> >>> In later phases, it's possible that we'll provide for other ways of >>> customizing the installed image. For instance, if the AI image were to >>> carry a payload (TM via cpio instead of the current IPS) then you could >>> create a finalizer script that customizes the image during construction >>> and then gets propogated to the installation. >>> >> Glenn, >> >> I think we also need to consider allowing the user to config the VM when >> they boot it. Perhaps using Visual Panels. > > Once Visual Panels is fully-integrated and available, then I don't see > why we wouldn't support this. I doubt it'll be ready for Phase 1, but > that's purely based on the lack of information I see flowing out of that > project. If it is going to be available, then adding that in should be > as trivial as adding the visual panels package to the AI client package > manifest and if I understand things correctly, it'll pop up when the > client is first-booted on all it's own. > >> I don't mean a reboot when VMC is constructing the installed VDI. I mean >> after the user of the VM has imported the OFV into there VM and first >> boot it up. We should probably allow for customization then. >> >> I could envision many user may get the same VMC output and not all want >> the same configuration. > > Absolutely. For Phase 1, we'll allow whatever the AI client can provide > for. Visual Panels isn't yet available (to my knowledge) and so we > can't use it. Once it is, I expect we will. Ideally, I think we'll end > up wanting to support at least two use cases. One where the deployer > configures the things that a first-boot visual panels would configure > during the VM construction and the other where visual panels pops up > during first-boot and the user can set things the way he wants. > > Since we're just consuming AI client technology for this project, we're > not constraining anything going forward. As the AI client evolves, so > can VM Construction by just consuming the additional technology when it > becomes available (heck, some enhancements might come along for free > without any changes needed to VM construction depending on what they > are). > > Cheers, >
I agree with all point. I just think perhaps it should be in the "ultimate" functional spec. Then we define what we do for P1, P2.... Joe