[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-install-discuss
Subject:    Re: [install-discuss] Request for input,
From:       Sarah Jelinek <Sarah.Jelinek () Sun ! COM>
Date:       2006-06-29 15:11:36
Message-ID: 44A3EDA8.4020100 () sun ! com
[Download RAW message or body]

Hi Peter,

Peter Tribble wrote:
> On Wed, 2006-06-28 at 22:50, Sarah Jelinek wrote:
>   
>> Does this help?
>>     
>
> Indeed it does. Thanks!
>
>   
>>> Ack. Buzzwords. Seriously, what do the bits in the breakdown mean?
>>>   
>>>       
>> Fair comments and questions. I will try to map your thoughts to our 
>> breakdown:
>>     
>>> I have my own mental model of how installation works:
>>>
>>> Hardware Inventory
>>>  - install destination
>>>   
>>>       
>> Target discovery for hardware inventory.  Target instantiation depending 
>> on what type of install and what the user chooses. Targets can be things 
>> like disks, zones, diskless systems, VM partitions(Xen, LDoms). A target 
>> is anything we expect to have to lay bits down on.
>>     
>
> Ah right. I hadn't quite expanded my mental model to include
> Xen, LDOMs, VMware etc.
>
>   
>>>  - KVM configuration
>>>   
>>>       
>> This is currently part of the sysid stuff in current Solaris install. 
>> This was kdmconfig.  Not sure this is needed any more for x86 with the 
>> new Xorg server. Never needed this for sparc(as far as I know).
>>     
>
> Depends. My experience is that this is erratic. I have a sparc and
> x86 system that generate a working X server configuration, but both
> make suboptimal resolution choices. And I'm seeing keyboard
> misidentification reasonably often too.
>
>   
As Dave said, file bugs. This helps us to track the deficiencies. I am 
not really an expert in this area, but it sounds like we need to allow 
for maybe customization from the defaults in this area during install?
>>  The 
>> sysid config stuff isn't consider a part of the core engine capability 
>> with Caiman.  We consider the sysconfig stuff to be separate from the 
>> core engine. system configuration is something that should be available 
>> to users at all times, and the install system configuration is really a 
>> special case of the general stuff.
>>     
>
> I consider this to be a mistake. Configuration is a core
> component of the installation process, so should be treated
> as such. Making it available at other times is fine.
>
>   
You have seen the subsequent email thread on this.
>>> System Configuration
>>>  - disk partitioning, raid
>>>   
>>>       
>> This is something we consider separate from the core engine. If you look 
>> at the arch diagram that was sent out you see it listed as the 
>> 'Partition Manager'. This is considered something we will keep separable 
>> from the core engine and is a tool that will be available for general 
>> use as well. The Engine will have to invoke and reap data from it, but 
>> not do the work itself.
>>     
>
> There are two steps here. I see the first level (fdisk, if
> you like) as your partition manager earlier on. I see the
> second level (format, newfs [zpool, zfs]) as being integrated
> into the installer.
>
>   
Yes, agreed.
>>>  - network etc configuration
>>>   
>>>       
>> We consider the sysconfig stuff to be separate from the core engine. 
>> system configuration is something that should be available to users at 
>> all times, and the install system configuration is really a special case 
>> of the general stuff. I don't think we have a specific idea of what 
>> might be different for install time configuration as opposed to general 
>> system configuration but the separation of configuration from install is 
>> our intended direction.
>>     
>
> I think this is a mistake. I would prefer to see it done as
> an integral part of the installer, and then that re-used later.
>
> I don't see the installer as just for installation, either. Certain
> parts of it you're unlikely to run later (target selection), but
> I would expect further software and configuration management to use
> the installation engine.
>   
As Dave noted, this is most likely true. Ultimately with Caiman and with 
the other work going on simultaneously with things like system 
configuration and software inventory management the tools we are 
developing and the architecture we are intending for Caiman will result 
in a 'normilization' of the tools for both install and non-install 
cases. If you want to think of these tools as part of the Caiman 
installer that is reasonable. One of the biggest issues we have today 
with Solaris install is the implementation and tight coupling of these 
types of tools in the current installer, and the constant need to update 
the installer when things change, due to duplication of functionality.
>>> Software selection
>>>  - source
>>>   
>>>       
>> Repository discovery. We want to have 'repository of stuff' to choose 
>> for installation.
>>     
>
> So - disk, nfs, ftp, http, download the lot from opensolaris.org?
> Even nicer: iso image on a local disk.
>
>   
Yes.
>>>  - profile
>>>   
>>>       
>> Not sure what you mean here. Profile of  current system? Profile of 
>> software available?
>>     
>
> Install profile, like jumpstart. Certainly the way I think
> about it is that the interactive prompts up to this point
> generate what is essentially a jumpstart profile and sysidcfg
> file, and then the instllation runs from those. Even better
> if it saves them somewhere so that you can simply use them
> for jumpstart later. (Or even the ability to generate a
> valid sysidcfg file and jumpstart porofile from an installed
> system.)
>
> But generally this is the step where you choose what bits
> you want installed. Generally needs a lot of improvement.
> (Who wants to pick packages - why not supply a desktop
> profile, or a web server profile, or even download a list
> of profiles from the repository server to pick from?)
>
>   
Yep, you are correct. We do this badly right now. This would be what we 
called 'customization of bits' in the engine functionality.

> One point here is that I would like the interactive installer
> and jumpstart to converge.
>
>   
Converge in what way?
>>>  - conflict resolution
>>>   
>>>       
>> Verification. Software verification is what this means in terms of the 
>> engine.
>>     
>
> Actually, I would hope this step goes away. If there are
> conflicts to resolve, the previous step hasn't done its job.
>
>   
Good point.
>>> Software installation
>>>  - slurp bits to disk
>>>
>>>       
>> Bit mover.
>>     
>
> Some software/package management system or other?
>
>   
Possibly both. We are not limiting ourselves to anything at this point, 
we have to be compatible to some extent so I suppose this will be an 
area of some change and extending as we go along.
>>> and I'm having trouble mapping this to the breakdown given.
>>>
>>> What does target mean? What are we observing? What are we
>>> generating metadata about? What is being extended?
>>>   
>>>       
>> -Target: is just the thing we are going to lay bits down on. Disks, 
>> zones, VM partition, raid 5, diskless...
>>     
>
> I think there needs to be slightly more care taken to
> distinguish between the various possibilities. There are
> still a few possible layers. (A zone, a disk, a partition,
> a mirror, a slice - all are slightly different layers,
> and some include other layers.) Ultimately you get down
> to a filesystem to which bits are written, but I get the
> feeling that you're using target at a slightly higher level.
>
>   
Yes, I suppose its fair to say we are using target at a higher level. 
You are right, it does get down to the fs on which bits are written, but 
the 'target environment' of the install is at a higher level than that. 
I agree that we need to be careful to clearly distinguish between the 
various target possibilities. The list I gave  you is a high level 
breakdown. As we move forward with design we will be more clearly 
enumerating those types of targets we will and need to support.

>> -Observability: is a general term meant to allow observability in to the 
>> installation process itself. Debugging install problems is difficult 
>> today, we want to make this easier.
>>     
>
> For you, or the user? Ideally the user wouldn't have to.
>
> Do we have ideas as to what sort of install problems are
> typically encountered?
>
>   
Mostly for us,but in some cases I suppose for customers. Debugging in 
install today is difficult for developers. We would like to change this.

Types of issues... for example, with zones upgrade we have a situation 
where we install missing pkgs at the beginning of the upgrade, then go 
to patch the features in. This results in a partial patching of some of 
the features and can result in a mismatch between some modules. 
Debugging this was hard to do and enabling the engine to provide more 
observability would have been helpful.
>> -Metadata generation: is intended to convey the ability to produce a 
>> snapshot of the current installed image for use in installing other 
>> systems if a user should want to do this.
>>     
>
> Generate a jumpstart profile? From either the installation, or
> a system you want to replicate at a later time.
>
> Actually, there's another possibility, which is to run the installer
> interactively without doing an installation and generate the profile
> from that. You could play around with this quite a lot to get just
> the system you want.
>
>   
Excellent idea!
> (You could even go from this to generating a custom CD image that
> could be used to install such a system.)
>
>   
Exactly. These types of things are where we are headed.
> I've played with several idea in this area myself.
>
>   
>> -Extensibility: We want an engine that is extensible to allow us to add 
>> new capabilities without too much pain. Today adding new stuff causes us 
>> a lot of pain.
>>     
>
> Oh, absolutely. However, I think that some ideas of the sorts
> of capabilities that might come along later would be good, or
> you end up with a horrible framework that compromises the
> design, and simplicity has to be a key attribute.
>
> Thanks again,
>
>   
Thank you for all your detailed review and ideas. This is excellent.

sarah

_______________________________________________
install-discuss mailing list
install-discuss@opensolaris.org
http://opensolaris.org/mailman/listinfo/install-discuss
[prev in list] [next in list] [prev in thread] [next in thread]