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. 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 think we're making a tradeoff of some minor flexibility that may have been present in a toolbox approach such as Jumpstart for substantial usability improvements. > 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 > I've looked at that bug in the past and I tend to think the issue here is more of a bug in how AI currently uses wanboot that combines with users not using the correct solution (services rather than manifests + criteria); I believe this proposal will support the actual requirement there, though some additional prototyping is in order to be sure of it. > >> >> 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 > Sigh; that bug's latest comment is disturbing. If they choose to implement a solution that doesn't use UNDI then we'll have to ignore them, or port that back in ourselves. Building boot loaders with hardware-specific drivers is a waste of time. > > >> >>> >>> 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. > Note that for that case we don't actually need the GrubMenu option; pxegrub already searches for that one if there's no menu specified. In fact, I'll likely propose to slightly enhance pxegrub so that we won't need GrubMenu at all. I suppose it would be reasonable to manage things this way if the user tells us not to manage DHCP in any way. I'll think about this a bit more. In reality, there's nothing to prevent one from doing this by hand if you want to, it's more a matter of what kind of variations the tools should support. Dave
