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.
> 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.
sarah
