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 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.
That is a good point.
>
>> 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.
ok.
>
>>
>>>
>>> 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.
It seems like that is the case - I have looked at the cited document [1],
but to be honest I don't quite follow why UNDI in particular
is problematic.
[1] http://www.gnu.org/philosophy/udi.html
>
>>
>>
>>>
>>>>
>>>> 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.
You are right - GrubMenu DHCP option would not be needed -
pxegrub currently searches for menu.lst name specified
as (in that order until valid one is found):
* GrubMenu option (150)
* menu.lst.01<mac>
* menu.lst.<boot_file>
* boot/grub/menu.lst
>
> 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.
I agree.
Thank you,
Jan
