-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon 25 Nov 2013 11:17:57 PM EST, David Timothy Strauss wrote:
(Pulled out of the meeting thread)
We've been talking about extended lifecycles as an admin-friendly
direction to take Fedora Server. But, I think we should consider
spending more resources better-supporting migrations to new
servers, including OS version bumps. Administrators often favor
long lifecycles because this process is usually tedious and
error-prone. The more we make this part of normal operations, the
more we make super-long lifecycles unnecessary.
It's probably ambitious for a first release, but it would be
amazing to have good tools for vacuuming over services, containers,
and VMs. The latter two already have tooling, but it would be super
cool to abstract it into a general utility for migrations. It could
enumerate migration-enabled resources. Integration with RPM
verification could list configuration that's not possible to
automatically migrate.
Migrations are a really difficult problem to solve, particularly when
dealing with Linux, since all of the subsystems on the OS are
developed more or less independently of each other. Not every project
agrees on the degree of backwards-compatibility or migration path that
they need to support.
Now, with that being said, I think we can use the "Roles" proposals
here to improve on this somewhat. We can try to set some rules for
compatibility and migration path on those roles that are declared
"Featured" in our parlance.
I'm not sure we want to "vacuum" these services up, exactly. But any
services that are registered with our (to be designed) role interface
should be possible to *reproduce* on the new system. I think we need
to keep this use-case in mind as we design the role API, so that it's
possible to use it to pull all of the necessary information back out
of an installed role to be used to seed a newly-deployed role. Then we
can focus our migration efforts on handling changes in the needs of
the API input instead of necessarily dealing with every service's
particular configurations directly.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlKUphMACgkQeiVVYja6o6O7OQCfehR4xAKZrdTHXWIMx8TSrt8X
4yAAn1skSfysfluPsU71JetqQfe7r3Mi
=fpSl
-----END PGP SIGNATURE-----