On 01/14/10 08:38 AM, Jan Damborsky wrote:
> On 01/13/10 08:36 PM, Dave Miner wrote:
>> On 01/11/10 09:23 AM, Jan Damborsky wrote:
>>> On 01/ 7/10 08:51 PM, Dave Miner wrote:
>>>> On 01/ 7/10 09:11 AM, Jan Damborsky wrote:
>>>>>
>>>>>
>>>>> image provisioning
>>>>> ------------------
>>>>>
>>>>> If I understand correctly, separate AI image has to be provisioned
>>>>> for each install service to be created. I am thinking if this might
>>>>> be considered as a limitation by some users.
>>>>>
>>>>> As SXCE is to EOLed, couple of discussions happened with
>>>>> internal developers about switching to OpenSolaris and using AI. Some
>>>>> people asked about possibility to provision separate machine
>>>>> serving AI
>>>>> images
>>>>> and IPS repo while they would just provision install services on local
>>>>> machines (e.g. on the same subnet or site as test machines) and just
>>>>> associate
>>>>> install service with URL of remote AI image.
>>>>>
>>>>> The reasoning behind this scenario is that AI images don't require
>>>>> customization (thus could be shared by all install services serving
>>>>> the same build) and that process of provisioning AI image has visible
>>>>> cost
>>>>> (space, time).
>>>>>
>>>>> I am not sure if that could be accomplished by existing implementation
>>>>> of technologies AI consumes (it seems that at least wanboot would
>>>>> need to be
>>>>> enhanced to allow this), but I am wondering if this is something we
>>>>> could
>>>>> consider.
>>>>>
>>>>
>>>> Some of this thinking really comes from old experience with the
>>>> limitations of RARP and the need to break up the boot server from the
>>>> install server in order to scale. Once you go to a DHCP-based design
>>>> (or a client-driven design such as wanboot or bootable AI media) that
>>>> doesn't seem like an especially valid need. If you want to share an AI
>>>> service, you do so via DHCP or providing the manifest to the booted
>>>> system.
>>>
>>>
>>> If my understanding was correct, they were not afraid about scalability,
>>> but they were more interested in possibility to 'delegate' AI image
>>> management
>>> and deployment ('heavy-weight' part of install service provisioning) to
>>> separate
>>> entity and consume those previously deployed images when install service
>>> is created.
>>> The approach would be similar to the one used for IPS repositories.
>>>
>>
>> Again, I think the issue is lessened here - the boot images are not
>> especially large, and will likely get smaller as we do some further
>> package refactoring.
>
>
> I agree - making the images smaller to decrease deployment
> time and space would address those complaints.
>
>> Further, I'm not entirely convinced that we can effectively support
>> a model where the manifests are served independently from an image;
>> that would seem to exacerbate version compatibility problems that lurk
>> below the surface here - Ethan alluded to some of this in his comments.
>
> I agree. I was not proposing to logically separate the image from install
> service, but I was thinking about possibility to share one AI image by more
> than one install services. I think that version compatibility problem would
> not be exposed by this, since install service would still be bound to
> particular AI image.
>
I guess I'm trying to figure out what usages the multiple service per
image config allows that aren't done just as well (if not better) by
using criteria + manifests on a single service. In cases where multiple
users might wish to each create a service with a default manifest to use
on one (or a few) machines, I'd think it better for the users to provide
their own manifests and assign them to the affected machines using criteria.
Dave
