Making migrations common (and not scary)

[Stephen Gallagher]

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