On 04/28/10 10:27 PM, Bart Smaalders wrote:
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
I'm much less confident than you in the quality of package publishing
outside of our core repositories. I think our experiences with contrib
and others, while perhaps corrected in large part by more current depot
software, bear this out.
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
Yes, but in both cases your proposal would seem to require that I plan
ahead for this case. I'm arguing that pkg should protect the normal
user with snapshots being the default. Right now we take snapshots in
most cases, but also delete them on success.
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.
I'm not quite following why it would need to be per subcommand; why
wouldn't a "always retain the pre-write snapshot" policy applied to all
subcommands be appropriate?
Dave
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
