(Migrated) 1.1 -> 2.0 Migration thoughts?

(This message has been automatically imported from the retired mailing list)

Hi,

since there’s been a lot of changes between 1.1 and 2.0 I’d like to
tackle the migration processes on several layers and would appreciate
your input on the matter - would be great if you could comment on the
ideas below given your practical experience with existing 1.1 environments.

Instructions

There will be a chapter in the documentation going through the migration
process step by step. This will be added as one of the first chapter in
2.0 docs so early users can give it a try as soon as possible.

zato migrate

A new command line extension is being develop as we speak. Essentially:

$ zato migrate /opt/zato/cluster1/load-balancer/
Migrated /opt/zato/cluster1/load-balancer from 1.1 to 2.0.0pre0.rev-9c9e147b
$

So one will give it a path and it will figure out what version a given
component is in and migrate everything that can be done automatically,
i.e. it will update server.conf or logging.conf

Alembic migrations

There’s a whole set of Alembic migrations added so that the ODB,
particincluding schema and new rows, can be migrated to 2.0

https://github.com/zatosource/zato/tree/master/code/alembic/versions

$ ./bin/alembic upgrade head
$

Manual steps

I’m sure there will be still some things to be performed manually - they
will be included in the migration instructions above.

Question is, do you think anything in particular should be given special
attention? What would you like for the migration process to take care of
as a priority?

thanks a lot,

I was unable to migrate easily from 1.1 to master, what I did in the end =
was to recreate the connections manually and put the services that I =
already had, for some reason the enmasse script never worked for me on =
1.1.

Do we already have a place where documentation for version 2 will be =
placed?

On Nov 19, 2014, at 11:52 AM, Dariusz Suchojad dsuch@zato.io wrote:
=20
=20
Hi,
=20
since there’s been a lot of changes between 1.1 and 2.0 I’d like to
tackle the migration processes on several layers and would appreciate
your input on the matter - would be great if you could comment on the
ideas below given your practical experience with existing 1.1 =
environments.
=20
Instructions

=20
There will be a chapter in the documentation going through the =
migration
process step by step. This will be added as one of the first chapter =
in
2.0 docs so early users can give it a try as soon as possible.
=20
zato migrate

=20
A new command line extension is being develop as we speak. =
Essentially:
=20
$ zato migrate /opt/zato/cluster1/load-balancer/
Migrated /opt/zato/cluster1/load-balancer from 1.1 to =
2.0.0pre0.rev-9c9e147b
$
=20
So one will give it a path and it will figure out what version a given
component is in and migrate everything that can be done automatically,
i.e. it will update server.conf or logging.conf
=20
Alembic migrations

=20
There’s a whole set of Alembic migrations added so that the ODB,
particincluding schema and new rows, can be migrated to 2.0
=20
https://github.com/zatosource/zato/tree/master/code/alembic/versions
=20
$ ./bin/alembic upgrade head
$
=20
Manual steps

=20
I’m sure there will be still some things to be performed manually - =
they
will be included in the migration instructions above.
=20
Question is, do you think anything in particular should be given =
special
attention? What would you like for the migration process to take care =
of
as a priority?
=20
thanks a lot,
=20
–=20
Dariusz Suchojad
=20
https://zato.io
ESB, SOA, REST, APIs and cloud integrations in Python

On 19/11/14 21:04, Ivan Villareal wrote:

I was unable to migrate easily from 1.1 to master,
what I did in the end was to recreate the connections manually
and put the services that I already had, for some reason the enmasse script never worked for me on 1.1.

Thanks Ivan - the thing here is that enmasse is meant more for moving
configuration across environments all of which are at the same version
rather between versions.

So enmasse 1.1 for 100% won’t be able to import objects into a 2.0
environment. The other way around may happen to work but there won’t be
any guarantees.

Let’s consider two examples.

  • You have a 1.1 environment you’d like to upgrade to 2.0
  • You have both 1.1 and 2.0 environments and would like to move config
    from 1.1 to 2.0

1.1 only

You need to perform the migration steps I outlined in the previous email

https://mailman-mail5.webfaction.com/pipermail/zato-discuss/2014-November/000698.html,
that is:

  • Migrate ODB
  • Run ‘zato migrate’
  • Remaining manual tasks

At that point your existing code will simply continue to run using the
same configuration as before - no enmasse is needed at all.

1.1 and 2.0

  • First migrate 1.1 to 2.0 as above
  • Now run enmasse on the newly upgraded environment, which at that point
    has just become 2.0, and use it to import objects to the other
    environment that was already at 2.0

I hope this clarifies the scope of the tools involved.

The tools will be much more consolidated once we have resource tagging
ready - the idea for 2.1 or 2.2 is that you will be able to attach
arbitrary tags to any resources, including services, and have them
exported or imported as a whole.

So you will have a tag ‘crm-release-392.1’ that will be attached to a
bunch of connections, user credentials, config files and so on and then
you will be able to move them, from command line, GUI or API, between
environments.

Though even then, I don’t think it will be easy to make it work across
servers running on different Zato releases.

But this will give you nicely a single place to manage all the aspects
of a given project, stream, activity, release or any other being your
development effort is placed under.

Do we already have a place where documentation for version 2 will be placed?

It will start appearing under https://zato.io/docs/2.0 beginning the
next week and it will be successively updated week by week.