jan damborsky wrote:
>>>>
>>>> But if we create a second sparc service (say with build N+3, or N-3
>>>> for that matter), then clients trying to use the second sparc service
>>>> will get a mismatch still, right?
>>>
>>> It depends on how the second service is created:
>>>
>>> [1] installadm create-service -n service_2 -s <ai_iso_2> <ai_image_2>
>>>
>>> In this case, the only way how client could use service_2 is to
>>> associated
>>> it with this service explicitly by calling 'create-client'.
>>
>> But does a sparc create-service without the -i -c not create the
>> /etc/netboot/wanboot.conf file?
>
> For now /etc/netboot/wanboot.conf is always written for 'create-service'
> command even if it is called w/o -i -c. This is the reason why mismatch
> always happens once second service is created.
Thanks, this is good to know.
>
> The temporary fix suggests to 'lock' that file by the service which
> accessed it first and 'release' it once service along with AI image
> is deleted. I agree there are issues with this approach.
>
>>
>> DHCP config is totally secondary. A user who just moderately knows
>> what they are doing can subsequently manually add IP addresses
>> associated
>> with the service_2 macro created above.
>
> I am not sure we could expect the user to take care of this. My feeling
> is that if there are steps required which can't be either accomplished
> by installadm(1M) tools itself or by copy-paste of the output those tools
> produced we shouldn't support/allow such scenario.
I'm not suggesting that we're pushing anything to the user. I'm suggesting
that it's possible that a keen user could intentionly not issue -i -c,
knowing
he/she is going to manually do it later because they just want to.
>
>>
>>>
>>> service_1 will continue to be used by default (if 'create-client' is
>>> not
>>> called).
>>>
>>> Mismatch doesn't occur.
>>>
>>> [2] installadm create-service -n service_2 -i <IP_start_2> -c
>>> <IP_pool_size_2>
>>> -s <ai_iso_2> <ai_image_2>
>>>
>>> * /etc/netboot/wanboot.conf will still point to service_1 boot archive.
>>> * two disjoint sets of IP pools will be available
>>> one for service_1 associated with service_1 dhcp macro,
>>> one for service_2 associated with service_2 dhcp macro
>>>
>>> New client connected to the network would obtain boot archive from
>>> image_1,
>>> but I am not sure how DHCP server behaves in this situation - from
>>> which
>>> pool it will assign IP address ? Is this deterministic/supported
>>> scenario ?
>>
>> Nope, its random. A client can be given an IP of either pool.
>>
>> Its not a deterministic scenario. I've yelled about this before, but
>> its
>> apparently a designed usage case.
>
>
> Is it captured somewhere to take a look at ? To be honest,
> I am not sure how it might be useful for client since it
> is not known what it is going to boot.
You are preaching to the quire :-)
I think the usage scenarios are at the end of the design doc. In a
nut shell, from what I recall, the usage case was:
Admin wants to quickly set up 20 machines for his class. 10 machines
will be installed with X, 10 machines will be installed with Y. Admin
doesn't care which machines installs X and which installs Y. Admin
does two create-service calls, one for X and one for Y, each with their
own -i -c. Admin does "boot net" for all 20 machines. Done.
(And obviously from this bug, one of those sparc services will get a
mismatched boot archive ;-) )
Putting aside our opinion of its usefulness for a bit, I think a part
why we're here now is because this scenario is least worked properly
for x86. When sparc came along, we didn't reevaluate whether it
actually worked for sparc.
thanks,
-ethan
