Testing app migration platform without automated pathway

Hi,

Recently, we started implementing the app migration assistant for our apps.
We are using the following approach/dependencies:

  1. OSGI dynamic dependencies: atlassian-app-cloud-migration-osgi v0.3.6
  2. CCMA v3.1.7
  3. feature flags migration-assistant.app-migration.feature is enabled in Confluence.
  4. Confluence server v7.10.2

We have the migration path already available online but when I create a new migration plan through the assistant UI, the migration cannot start due to missing automated pathway. Since we are still in the implementation phase, is there any way to test the migration platform without enabling the automated pathway or am I missing something here?

thanks

1 Like

Hi Behrouz,

As long as you have the followings in place, app migration platform lets you migrate apps.

  1. Have a listener implemented
  2. In AppAssessment flow, select ‘NeededInCloud’ - despite you have a path or not. And complete the flow once. This flow is not meant to be blocking at present, so you should be able to complete this.
  3. Make sure that App is installed on the cloudsite you would like to migrate too.

Also note that at present only those apps that have the same key on server and cloud can be migrate, so if serverAppKey and cloudAppKey are different then you can’t migrate.

Let me know if the above worked.

Regards,
Anshuman

Hi Anshuman,
Thanks for your reply,

I had followed the steps you mentioned above,

I also implemented both listeners interfaces available in migration OSGi and none of them worked. (AppCloudMigrationListenerV1, AppCloudMigrationListener)

I attach a video showing the steps I followed to create a migration plan here:

Regards,
Behrouz

Hi @AnshumanTiwari - was there anything else we needed to implement to be able to test? Currently, this was blocking our progress.

In case it is required, these are our related Atlassian Migration tickets - https://jira.atlassian.com/browse/MIG-464 (PDF) / https://jira.atlassian.com/browse/MIG-465 (Word)

Thanks, Thomas (K15t)

Hi @behrouz and @thomasr, from EAP, the completion of App Assessment is necessary for those migrations that have Apps involved.

Therefore, you need to make sure that every installed App should have a deterministic state either - ‘Needed in cloud’ or ‘Not needed in Cloud’ or ‘Use Alternative’. In App Assessment, please make sure that it is true for every app and then go through the flow.

Hi @AnshumanTiwari

The workaround you provided was working fine but after updating CCMA to v3.1.8, and the wanted apps for migration are not listed in the migration plan and the app migration listener not being called anymore.

Do you have any ideas about that?

Regards,
Behrouz

Hi @behrouz,

Please let me jump in here for my colleague. Generally we find that sometimes on the upgrade depending on how you’ve implemented the listener that a complete restart of Confluence Server will help to reset the apps. Or at least at a minimum restart your app after making sure CCMA is enabled.

Exactly which page are you referring to when you say

the wanted apps for migration are not listed in the migration plan

just so I can be sure about your issue.

Regards,
James.

Hi @jrichards
Thanks for your reply,

I also restarted the Confluence Server but it didn’t help.
The page Choose what to migrate in the previous version was showing the apps being migrated.

I attach screenshots of those pages.

Hi @behrouz,

It looks like you need to reset the dark feature flag to turn App Migration on. There should be a large orange banner at the top to let you know you’re running the EAP code.

Please follow the instruction in this step in the Getting Started Guide

Specifically,

  1. Go to <Confluence_URL>/admin/darkfeatures.action
  2. Scroll down and enter migration-assistant.app-migration.feature
  3. Click Save

This should activate the EAP App Migration features. You do not need to restart. (A restart will clear out the dark feature.) I also recommend reviewing the Getting Started page again because there might have been some changes since the last time you viewed it.

Regards,
James.

Hi @jrichards
thanks for the info,

After restarting the Confluence instance, the app listener was called.

There is still one issue with the mapping API which I have not been able to figure out yet.
The API doesn’t return the user mappings on either Cloud or Server.

I’m using the following APIs in server and cloud.

Server:

PaginatedMapping paginatedMapping = gateway.getPaginatedMapping(transferId, "identity:user", 100);
            while (paginatedMapping.next()) {
                Map<String, String> mappings = paginatedMapping.getMapping();
                ...
            }

Cloud:

GET request to this URL: https://my-site.atlassian.net/rest/atlassian-connect/1/migration/mapping/26925583-10bd-49fb-b67c-15fc2447a97b/page?namespace=identity:user

I tried with other namespaces like confluence:space and confluence:page and the API returned a map.

I can see that a new user gets added on the Cloud site after migration but it’s not available in the mapping API result.

Am I missing something here?

Regards,
Behrouz

Hello @behrouz,

Can I confirm that you are including the MIGRATION_TRACING_IDENTITY scope in the requests?

In server, you do this when implementing the listener

   @Override
    public Set<AccessScope> getDataAccessScopes() {
        return Stream.of(AccessScope.APP_DATA_OTHER, AccessScope.PRODUCT_DATA_OTHER, AccessScope.MIGRATION_TRACING_IDENTITY)
            .collect(Collectors.toCollection(HashSet::new));
    }

Also note that identity:user mappings are only kept for 5 days after a migration.

Regards,
James.

Hi @jrichards

yes I already added the MIGRATION_TRACING_IDENTITY scope to the listener as follows:

   @Override
    public Set<AccessScope> getDataAccessScopes() {
        return Stream.of(APP_DATA_OTHER, PRODUCT_DATA_OTHER, MIGRATION_TRACING_IDENTITY, MIGRATION_TRACING_PRODUCT)
                .collect(Collectors.toCollection(HashSet::new));
    }

In spite of a new user in the migration plan, the AppCloudMigrationGateway always returns an empty map for identity:user.

Hi @behrouz,

I’d like to understand the statement

In spite of a new user in the migration plan, the AppCloudMigrationGateway always returns an empty map for identity:user .

All users are not migrated every time, only the changes from the last migration. I’ll have to confirm this with a test, but if you migrate twice to the same cloud site, then the same users are not sent on the 2nd migration as they have already been uploaded.

Regards,
James.

Hi @jrichards
Thanks for your reply,

Actually, I was aware of that.
I don’t get the user identity mapping from the API in the listener when a user is being uploaded to the Cloud for the first time.

Regards,
Behrouz

Hi @jrichards,

if I understood this correctly it essentially makes the user mappings pointless for a lot of migrations:
I guess a lot of customers will migrate individual spaces. So I assume the first migrated space will also trigger a migration of the users. If an app’s feature is only used in another space that is migrated later on, doesn’t that mean that app’s migration code will never see the users at the time it has something to migrate?

To clarify this: Our app stores some data with user references in a space. If the migration code is invoked for another space not having such data, our migration code currently doesn’t do anything (because there’s nothing to migrate).

So we (and every other vendor with a similar use case) would need to add code to our app that stores the user mappings in a separate location just in case it might be required later on. This is not really ideal.

Can the migration platform be changed to provide such ‘global’ mappings in each partial migration?

Thanks,
Jens

Hi @jens,

I’ve checked with the team and I misunderstood what was happening. Each link between server and cloud is given a unique id (we call it a migrationScopeId) and this ties the mappings between server and cloud. So, when we get the transferId we look up the migrationScopeId and then request the mappings.

Can I ask you try again with a fresh new cloud instance? If it still fails, post the migrationId and I can check.

Thanks,
James.

Hi @jrichards

I did another migration with migrationId = 94fc2bb8-e35c-43ca-8b85-a1b9b1382668 with a new cloud instance and the user mapping was not still present.

Regards,
Behrouz

Hi,

We’d like to confirm that you’re selecting the user and groups option, and not just selecting users for selected spaces. identity:user mappings are only created if you specifically specify the users and groups option. We’re asking because we can’t see any user mappings being created in our logs for your migrationId.

The mappings are cumulative for each migration, so long as they haven’t been removed based on the time limits (e.g. user mappings are kept for 5 days) but you need to specifically send the users and groups, not just the spaces with associated users.

James.

Hi @jrichards

I just tested the scenario again today with the new release (v3.1.9) and the migration gateway seems to return the user mappings now.

thanks,
Behrouz

1 Like

Hi @behrouz,

Great to hear that you’ve got the mappings you were looking for. I want to confirm this question I asked because it means I might need to update to the documentation.

Thanks,
James.