Not sure this is Deploy or OttoFMS question, it appears order the migrator tool operates on the files in alphabetical by file name. would there be any reason to want to perform this in a different order; by file size? I ran a successful migration using a second sub-deployment to batch the larger files together.
Watching this one too.
My preference is to have the file processed in the order I enter them into OttoDeploy. For example:
1). xx_DATA.fmp12 (Migration)
2). xx_DOCS.fmp12 (Migration)
3). xx_UI.fmp12 (Replace)
Jeff
Hey y’all,
OttoFMS runs all of the migrations in a sub-deployment in the order that they are entered in OttoDeploy and then it runs all of the installs in the order they are entered. If you want to double check the order they will run, the deployment JSON you can see in the copy deployment JSON window shows the specific order which we will run the migrations in.
Using concurrency will cause migrations to happen simultaneously, but they will be started in the order that they are entered in OttoDeploy.
I’m not sure if there is any reason to run these migrations in a specific order for the Data Migration tool, I don’t see why there would be.
Does that answer your question?
-Kyle
2 Likes
Order may help for some cases. Most likely by sub-deployments the potential of a larger file having issues vs a bunch of tiny files putting these first would fail quicker and extra work is avoided. Even in a small set of files I may still wish them to execute in a particular order. I get concurrency is the edge case.
Until we have toggle to keep all files off until all sub-deployments complete UI files must go last as that is what users will try to access if they see it, and other data files haven’t opened.
However not entirely true either we could have webhooks or dataAPI/oData hitting other files yet not all files are migrated and open.
The last sub-deployment should have the opposite of this to Open All files in deployment and the opposite of this to open additional files that may have been closed.
(It will be helpful in next version of FMS that we can prevent access via the console and hopefully adminAPI )
I’m glad I read this question! Now I can strategize concurrent migrations. So, in the case of a migration with multiple files, some of which are huge (30GBish) and others are small, have you observed a way to optimize speed. For example, is it better to run one big file at a time with smaller files, or Put the big ones next to each other?
This is a vital question for one of our clients (for whom we have not yet been able to implement OttoFMS/Deploy due to a continuing failure over one file).
The concurrency limit works by setting a limit on the number of files that can be migrated at a time. Once the limit is reached, other migrations are queued. They wait until one of the files that is in process completes, freeing up a spot.
If I had to guess I would say separating big files with smaller files would be best. But I think you would have to test.
You could also use sub deployments for another level of ordering and organization. But remember that subdeployment are atomic.
Todd
Good info. My 6file test had the two big files up first so it was interesting to see both of them growing at the same time. It’s good to know that even if one doesn’t order them by size, that once a file is done, another will take its place.