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.
I have also noticed bug 7152 which describes slightly modified use case:
7152 Requesting Ability For Multiple Services To Use One AI Sever OS Image
>
> Overall, I don't think this represents a significant limitation.
>
>> gPXE
>> ----
>>
>> That leads me to another point - the proposal currently operates with
>> technologies they are available and proposes to leverage them if needed.
>>
>> I am thinking if for x86 case we should take a look if gPXE could be
>> better alternative to pxegrub for booting the kernel and boot archive.
>> That would allow us to use other protocols than TFTP (namely HTTP).
>>
>> I am not sure what effort would be actually involved (it seems
>> it might not be trivial to make things work), just wanted to bring
>> that point up.
>>
>
> I'd like to have a discussion with the boot team around that. The
> upcoming GRUB 2 transition may or may not be planning to affect this.
I agree that the further discussion would be fruitful - looking at GRUB2,
it seems it currently does not have network support
http://grub.enbug.org/CurrentStatus
http://grub.enbug.org/TodoList
http://grub.enbug.org/CommandList
as well as that people contemplate about leveraging gPXE for that
goal:
https://savannah.gnu.org/task/?9245
>
>>
>> DHCP - install service macros
>> -----------------------------
>>
>> Document proposes to create DHCP service specific macros (with name
>> incorporating service name) for each service to be created:
>>
>> ...
>> - The DHCP macro names generated for each AI service will use a prefix
>> of "AI_" rather than the "dhcp_macro_" prefix that is currently
>> prepended.
>> ...
>>
>> Since the intent is to make AI as less dependent on DHCP as possible
>> and limit things AI need to configure with respect to DHCP,
>
> I'd like to *allow* it to be limited, but also to allow DHCP to be
> leveraged where desired.
>
>> I am thinking if those macros are needed or if we could avoid
>> creating them. Looking at the examples, they seem to be unused.
>>
>
> A deficiency in the examples that I need to correct. The idea is to
> allow inclusion of these macros to configure individual clients to
> specific, non-default services. So for client with MAC addr of
> 0:14:4f:9b:84:e0 you might have a macro that says:
>
> 0100144F9B84E0 Macro :Include=AI_osol-dev-117-i386:
I see - in order to manifest alternate approach I had in my mind,
DHCP configuration in this particular case might look like:
0100144F9B84E0 Macro
:BootServA=172.0.0.1:BootFile="0100144F9B84E0":GrubMenu="menu.lst.0100144F9B84E0"
where 0100144F9B84E0 and menu.lst.0100144F9B84E would be
symbolic links to os-dev-117-i386/boot/grub/pxegrub and
os-dev-117-i386/menu.lst respectively.
Thank you,
Jan
