Sarah Jelinek wrote:
> Hi Kyle,
>
>
>> Dave Miner wrote:
>>
>>> Kyle McDonald wrote:
>>>
>>>> Tim Bradshaw wrote:
>>>>
>>>>> On 11 Mar 2008, at 22:42, Ken Gunderson wrote:
>>>>>
>>>>>
>>>>>
>>>>>> IMHO making "not optional" would be a _very_ bad move of epic
>>>>>> proportions (or hopefully I'm misunderstanding you). Sysadmins
>>>>>> should
>>>>>> have control over what is updated/graded, and when, not some
>>>>>> automatic
>>>>>> "non-optional" tool
>>>>>>
>>>>> I'm guessing what is meant is that Snap upgrade will be bundled so
>>>>> it won't be something you can optionally install. And perhaps
>>>>> all upgrade installs will use snap uograde rather than booting
>>>>> from media. That sounds to me like a very good thing. I've long
>>>>> argued that LU should be bundled this way - in particular the
>>>>> current status where you often need to add intrusive patches
>>>>> (requiring reboot, say) to even use LU is really bad.
>>>>>
>>>>>
>>>> I agree, I read it that way also. Automatically installing the snap
>>>> upgrade bits is good. Automatically using the bits to upgrade the
>>>> system is bad. I'm nearly positive it's the former.
>>>>
>>> It is the former.
>>>
>>> All updates will be done using the pkg tools and corresponding GUI,
>>> which presently have no policies or functionality for updating the
>>> system except at request of the user/administrator.
>>>
>>>
>>>>> Another thing that is really needed is snap/live *install* not
>>>>> upgrade, so you can do a Solaris install (specifically *not* an
>>>>> upgrade install) while the system is up.
>>>>>
>>>>>
>>>> This is the main thing I wanted look for in the requirements docs.
>>>> I don't do upgrades if I can help it. Fully automated JumpStarts
>>>> for me. With LU I've asked for a way to start with a blank BE, and
>>>> use the jumpstart rules/profiles, etc. to do an initial install,
>>>> and the response I've always gotten was "that's a good idea we
>>>> should do that." I haven't finished reading the docs on the web
>>>> page that was posted, but I'm hoping that that was already
>>>> incorporated into SnapUpgrade.
>>>>
>>>>
>>> That's not really Snap Upgrade's job, the way we're approaching
>>> things. Part of the reason it has a different name is because it is
>>> explicitly not Live Upgrade. It has some similar ideas and re-uses
>>> some terminology ("boot environment", though I dislike re-using it),
>>> but shares nothing else.
>>>
>> I know that AI would still be involved with this. I am looking to see
>> more if I'm going to run SU and ask it to call AI for me on the new
>> BE? or if I'm going to run AI, and it will call (or use a library
>> from) SU to do what it needs to do with the BE.
>>
> We were thinking of allowing both with AI. That is you can do an
> upgrade using SU or install in to an empty BE with the system booted
> from a net image. Or you can utilize the AI profiles to upgrade your
> BE's on your live system.
ok.
>> The former seems more like what LU would do if it could do an initial
>> jumpstart.
>> The latter sounds more like what you're describing here. One
>> question it brings to mind is: Will redirection to a BE be possible
>> on the command line, or will it have to be in the AI profile? I'd
>> rather not have to tweak the profile to run it on a BE instead of a
>> physical machine booting over the network.
>>
> Not quite sure what you are asking. I am assuming you are asking if to
> run the AI on a BE you have to specify that BE in the profile? I would
> assume yes. If you run SU from the command line then that is different
> and I assume it would be possible to specify the BE.
>
I'm saying I'd like to do the initial install with a
Begin/Profile/Finish combo, creating the first BE as I go (either by
default, or explicitly in the profile.)
Then later when I want to move the system to a fresh install of a new
version of Solaris, I'd like to be able to use the 'exact same' (without
modification) 'Begin/Profile/Finish' combo to install the alternate BE.
when run from the net boot image, I'd expect AI to process the profile
verbatim. But when run from the command line on an installed booted
system, I'd like to be able to point AI to the new BE without having to
change the profile.
In my case I imagine there'd be some flag env variable you could set in
the env, so that my begin script coudl dynamically adjust the profile to
adapt to the fact that we are installing into an Alt. BE, but I think
kthere are plenty of users who will have a collection of static profiles
they they'd prefer not to have to edit back and forth to use both ways.
I'm not sure that's any clearer, is it?
-Kyle
> sarah
>
