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.
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.
>
> Installing to a fresh BE will be simple to implement. It's
> essentially what we already do as the first step in creating the
> Indiana CD image:
>
> pkg image-create -F \
> -a opensolaris.org=http://pkg.opensolaris.org:80 <your path here>
> pkg -R <your path here> install ...
>
I think I need to catch up on more of the specifics of the pkg
terminology, but what does <your path here> really represent?
1) Is it the temporary mountpoint for the FS tree that the new BE contains?
2) Is it some other 'image creation' area that the image is created in
before the the BE is populated?
I'd prefer 2, since I'd rather not have to have diskspace to 'create' an
image just to then install it.
Eitherway, while those 2 commands will install a fresh BE, it's still
not exactly the same as running AI, or JS on the new BE.
-Kyle
