On 04/27/10 10:59, Dave Miner wrote:
On 04/21/10 09:16 PM, Bart Smaalders wrote:
As of 2010/03, we always create new boot environments
when doing an image-update, and never do so for
install, instead failing the operation should an action
tagged w/ reboot-needed be affected. We also always
create new boot environments for change-variant and
change-facet operations, and never for fix.
This needs work.
Agreed that we need to make the behavior consistent and offer more
flexibility.
Instead, I'd like to propose the following:
1) We support the creation of a new optional backup
boot environment before executing the operation
on the live image. Non-live images can easily
use snapshots for this; this option would have
no effect in the case that the operation creates
a new BE.
2) All image-modifying operations on a live image
would create a new boot environment only if needed.
This behavior could be altered via command line flags
to always create a new boot environment or to never
create one, failing instead if the operation needs
one.
pkg install
pkg fix
would both get the following new options:
[--backup-be]
[--backup-be-name name]
[--no-new-be | --always-new-be]
[--be-name name]
pkg image-update
pkg change-facet
pkg change-variant
would all get the following new options:
[--backup-be]
[--backup-be-name name]
[--no-new-be | --always-new-be]
So, to retain the current behavior,
invoke pkg install --no-new-be ....
invoke pkg image-update --always-new-be ...
pkg change-facet --always-new-be ...
pkg change-variant --always-new-be ...
- Bart
After thinking about this for a few days, the thing that troubles me is
having a default that offers no fairly direct way to get back to the
prior state. A case that concerns me is when installation or update of a
package drags in updated libraries that are depended upon by multiple
consumers, and incompatibilities result; if my priority was what I had
running before, how do I get back? Admittedly, we don't handle this
right now, but it seems to be something we should consider.
Ignoring the fact that such things should not occur w/ properly
published packages... reverting to a previous configuration can be
done via:
1) snapshot and rollback; remember, you can rollback immediately
on a live system. I do this all the time for testing.
2) creation of a backup BE
The proposal
here would appear to require foresight on my part to ensure I've got a
way out (either by having a pre-existing BE or requesting creation of a
backup BE made at the time). We don't necessarily have to go all the way
to creating a new BE, but a policy of retaining a snapshot from which we
can quickly re-create a BE would seem to be very helpful (and if/when we
have support for booting directly from snapshots, that seems even more
attractive).
The suggestion made elsewhere in the thread about having image-level
policy for this is something I also find attractive (and could swear I
mentioned when we kibitzed about this some months ago :-).
Dave
This gets very confusing, as the default policy would likely need to
be per subcommand.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[email protected] http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
