Remove all dependencies from the migration-console stack #1043
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1043 +/- ##
=========================================
Coverage 80.55% 80.55%
Complexity 2736 2736
=========================================
Files 365 365
Lines 13614 13614
Branches 941 941
=========================================
Hits 10967 10967
Misses 2070 2070
Partials 577 577
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
I'm fine with the spirit of this change, though i'm a bit concerned with how this interacts with the SSM parameters dependencies since they would be added during deployment.
Have we tested with this PR on the first deployment in a new stage with concurrency set to a very high value?
There was a problem hiding this comment.
I'm fine with the spirit of this change, though i'm a bit concerned with how this interacts with the SSM parameters dependencies since they would be added during deployment.
Have we tested with this PR on the first deployment in a new stage with concurrency set to a very high value?
@AndreKurait does the jenkins job verify this behavior so manually checks aren't needed for this change?
| @@ -621,8 +621,7 @@ export class StackComposer { | |||
| }) | |||
| // To enable the Migration Console to make requests to other service endpoints with services, | |||
| // it must be deployed after any connected services | |||
| this.addDependentStacks(migrationConsoleStack, [captureProxyESStack, captureProxyStack, elasticsearchStack, | |||
| openSearchStack, osContainerStack, migrationStack, kafkaBrokerStack]) | |||
| this.addDependentStacks(migrationConsoleStack, [migrationStack]) | |||
There was a problem hiding this comment.
This seems like the correct list, I think we accidentally inverted the dependencies when this was first added.
There was a problem hiding this comment.
You can remove the comment above this as well. Originally when we used service connect to talk between ECS services, the Migration Console would need to be deployed after those services to have their service name mapping with service connect. We no longer user Service Connect I believe so that shouldn't block us.
The other concern I have is loading in environment variables. If we are still loading in environment variables from other stacks that create a source or target (not our import case) say in the opensearch container stack case, we wanted to be sure that endpoint existed and could be passed. This seems like something CDK may be smart enough to detect without manually doing it, but it would be nice to confirm that's the case if we still want to support that use case.
That means that the console can come up and be used for diagnostics if the other stacks/clusters don't properly deploy. Signed-off-by: Greg Schohn <[email protected]>
gregschohn
force-pushed
the
RemoveSourceAndProxyDependenciesFromMigrationConsoleCDK
branch
from
c5c2376
to
c332e1e
Compare
That means that the console can come up and be used for diagnostics if the other stacks/clusters don't properly deploy.
Description
This change allows the migration console to be deployed w/out any dependencies of other tasks that it's meant to interface with so that the console itself can be used as a diagnostic tool
Issues Resolved
https://opensearch.atlassian.net/browse/MIGRATIONS-2037
Is this a backport? If so, please add backport PR # and/or commits #
Testing
limited testing by redploying from my bootstrap box
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.