Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrator to have a history only import option #2281

Closed
vanessalove opened this issue Jan 8, 2016 · 6 comments
Closed

Migrator to have a history only import option #2281

vanessalove opened this issue Jan 8, 2016 · 6 comments
Assignees
Labels
feature/migrator kind/enhancement This issue represents an enhancement we are committed to adding to Octopus as some time
Milestone

Comments

@vanessalove
Copy link
Contributor

We have a growing number of cases of the migrator not being able to import the history due to the time it takes, or having not imported data due to its rules and logic. Usually by the time the customer has informed us of this, or realized they are missing data, they have used 3.x for too long to risk changing primary data like projects, variables etc.

It would be great if we could have a flag for the migrator to only import history that doesn't exist. So projects, releases etc that do not exist within the 3.x instance would be created but if they do exist then they would be skipped instead of overwriting.

I have a bunch of sources for why this is relevant, but they aren't super specific to creating this. I have asked for a couple of databases so we could test their specific cases.

@vanessalove vanessalove added kind/enhancement This issue represents an enhancement we are committed to adding to Octopus as some time feature/migrator labels Jan 8, 2016
@vanessalove
Copy link
Contributor Author

This would also help for customers who have large histories but need a 3.x instance up and running, or they just dont have the power/memory/resources/infrastructure to do a full import at once. They could then import the history in workable chunks.

@robpearson robpearson self-assigned this Jan 12, 2016
@vanessalove
Copy link
Contributor Author

@zentron zentron assigned zentron and unassigned robpearson Jan 27, 2016
@zentron
Copy link

zentron commented Jan 27, 2016

Also Covers Issue in: #2283

@zentron
Copy link

zentron commented Jan 27, 2016

so new migrator arguments... something along the lines of
Octopus.Migrator.exe migrator --nologs --file ...: imports without touching the raw server log entries
and
Octopus.Migrator.exe migrator --onlylogs --file ...: imports only the raw server log entries

When importing, it will first need to also load all the server task document objects to cross reference with the database stored entries to ascertain what the new taskIds are that the logs need to save as.

At the moment these arguments will be exposed just through the command line.

@zentron
Copy link

zentron commented Feb 2, 2016

Release Note: Provide --nologs and --onlylogs option for migrator process to seperate loading raw task logs from main server data for increased performance

@zentron zentron added this to the 3.2.22 milestone Feb 2, 2016
@lock
Copy link

lock bot commented Nov 26, 2018

This thread has been automatically locked since there has not been any recent activity after it was closed. If you think you've found a related issue, please contact our support team so we can triage your issue, and make sure it's handled appropriately.

@lock lock bot locked as resolved and limited conversation to collaborators Nov 26, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature/migrator kind/enhancement This issue represents an enhancement we are committed to adding to Octopus as some time
Projects
None yet
Development

No branches or pull requests

3 participants