On 02/03/2011 10:51 AM, Peter Doherty wrote:
> On Feb 3, 2011, at 10:35 , Stephen Gallagher wrote:
>> - From the earlier points of the discussion, schema migration is planned
>> for upgrades from 2.0.0 to future versions. It's only something that was
>> left out of the alpha/beta process because things were still in churn
>> and those releases were never intended to be in production. Once 2.0.0
>> is baked, obviously the upgrade path will need to be clean.
> Is there a plan to include the ability for users of 1.2 to migrate to
> 2.0?
> I'd consider setting up and using 1.2 right now if I know that I can
> migrate to 2.0 when the stable release comes out.

This is a use case that we have in mind. v1 is treated as an external DS
This migration is planned through the migrate-ds + SSSD or special page
to migrate passwords. The v1 and v2 schemas are drastically different
but v1 just has users and groups and migrate-ds script takes care of it.
This is well covered in the migration guide.

The in place update are planned starting v2 meaning that either the bits
just can be refreshed on each of the replicas gradually (if schema or
related logic is not affected) or will require a rolling upgrade. The
rolling upgrade is needed for the cases when there are schema changes
and newer replicas can't talk to the old replicas due to potential data
corruption cause by schema mismatch. The rolling upgrade procedure will
effectively cause a split of the domain. Replicas that still carry old
bits and schema will talk to each other and updated replicas will talk
to each other. The rolling upgrade procedure fill involve updating
replicas one by one so that they move from one set to another. Finally
when all replicas are updated they all will be talking to each other
again. The changes caused by the client and administrative activity will
be propagated to the set of updated replicas as any new converted
replica will carry the chunk of changes it already knows about.

Upgrades are very complex procedures especially in the replicated
environments. There is no silver bullet technology that will make things
simple. We though this part through but do not plan supporting rolling
upgrades till the next version of IPA (probably 2.1). The foundation for
such approach is there. But the tools to actually update in place are
not yet implemented. They are a part of the subsequent release.

> -Peter
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.

Looking to carve out IT costs?

Freeipa-users mailing list

Reply via email to