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

Add new configuration option to disable ADP #11513

Merged
merged 5 commits into from
Feb 25, 2021

Conversation

mjkkirschner
Copy link
Member

@mjkkirschner mjkkirschner commented Feb 22, 2021

Purpose

  • Adds a configuration option for clients to use to disable ADP for dynamo and any other API access within the process.
  • Does some simple checks for invalid configuration options, as well as asserting that the disable call actually worked.
  • updates ADPSDK to 3.x and updates analytics.net to 2.11.1 binaries.

TODO:

- [ ] add test I found it's difficult to add a test here without refactoring the analyticsServices classes because static types cannot be mocked, and during testing we may not actually have the ADP core binaries around. Because we have tests in the ADP project, and the test here would basically just be asserting the configuration bool is set correctly, I'm thinking it's not worth it - open to suggestions though.

  • adpwrapper binary must be updated in this pr

Declarations

Check these if you believe they are true

  • The codebase is in a better state after this PR
  • Is documented according to the standards
  • The level of testing this PR includes is appropriate
  • User facing strings, if any, are extracted into *.resx files
  • All tests pass using the self-service CI.
  • Snapshot of UI changes, if any.
  • Changes to the API follow Semantic Versioning and are documented in the API Changes document.
  • This PR modifies some build requirements and the readme is updated

use it to call disable
raise warnings or throw if we fail to disable adp
…method

more logging at startup
update adp/analytics binaries
@mjkkirschner mjkkirschner changed the title WIP add new configuration option to disable ADP Add new configuration option to disable ADP Feb 23, 2021
@mjkkirschner mjkkirschner added PTAL Please Take A Look 👀 and removed WIP labels Feb 23, 2021
}
}

if (isHeadless)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I modified how late we bail out if isHeadless is true because some clients need to disable ADP and still use Dynamo as a headless runner.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you remind me, the isHeadless is set to true only when using command line, right? For Dynamo Player and GD, analytics is on because we are using Dynamo as a server.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe player does not use headless, I am not sure about GD.

@mjkkirschner
Copy link
Member Author

mjkkirschner commented Feb 23, 2021

@pinzart90 @aparajit-pratap - please see my note above on difficulties testing this - one approach I do think would work is to create an internal enum to record the state of the disable call - something like:

enum disableResult { success, failure, not_attempted} - then check this from a test, the issue is that during a test we can't guarantee we will have access to adp core, but we might still want to make sure the disable call was attempted.

what do you think?

Copy link
Contributor

@pinzart90 pinzart90 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comment ..then looks good


if (areAnalyticsDisabledFromConfig && disableADP)
{
throw new ConfigurationException("Incompatible configuration: could not start Dynamo with both [Analytics disabled] and [ADP disabled] config options enabled");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍🏻


if(IsTestMode && disableADP)
{
this.Logger.Log("Incompatible configuration: [IsTestMode] and [ADP disabled] ");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what does this case mean?

Copy link
Member Author

@mjkkirschner mjkkirschner Feb 25, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is the case where testmode is active (during most tests) and some test might try to disable ADP - but we can't guarantee that we have access to the core sdks in different testing scenarios, and I could not find a nice way to mock this dependency, so thought it would be valuable to log the case, because it's likely adp is not really disabled.

I forgot the most important part!!
Also - we don't initialize analytics in test mode, so downstream of this in AnalyticsService.Start() we break out if we're in test mode and don't even try to call disable.

Copy link
Contributor

@QilongTang QilongTang Feb 25, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is exactly what I was going to mention. We always bail out during test mode so I dont think ADP will be loaded at all. https://github.com/DynamoDS/Dynamo/blob/master/src/DynamoCore/Models/DynamoModel.cs#L1429 Do we really need this warning?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we don't need it - but I think it might help avoid wasted time. It would be nice if Dynamo provided feedback on incompatible options since to a client it's not obvious what headless and testmode actually control.

Copy link
Contributor

@QilongTang QilongTang Feb 25, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @mjkkirschner If that's the case, it seems this warning can be moved into beginning of AnalyticsService.Start(). What do you think?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, can do.

@QilongTang
Copy link
Contributor

Thank you. Looks good to me

@mjkkirschner mjkkirschner merged commit 2435479 into DynamoDS:master Feb 25, 2021
mjkkirschner added a commit to mjkkirschner/Dynamo that referenced this pull request Feb 25, 2021
* add new configuration option
use it to call disable
raise warnings or throw if we fail to disable adp

* modify analytics startup to check testmode and headless inside start method
more logging at startup
update adp/analytics binaries

* review comments

* review comments, unify name

* move test mode error log to analytics start

Co-authored-by: michael kirschner <[email protected]>
mjkkirschner added a commit that referenced this pull request Feb 25, 2021
* add new configuration option
use it to call disable
raise warnings or throw if we fail to disable adp

* modify analytics startup to check testmode and headless inside start method
more logging at startup
update adp/analytics binaries

* review comments

* review comments, unify name

* move test mode error log to analytics start

Co-authored-by: michael kirschner <[email protected]>

Co-authored-by: michael kirschner <[email protected]>
@aparajit-pratap
Copy link
Contributor

Why are these empty files added:
extern/Analytics.NET/AdpSDKCSharpWrapper.dll, ...

@mjkkirschner
Copy link
Member Author

@aparajit-pratap they are not empty or added - they are updated binaries:

  1. new adpsdk
  2. our updated wrapper

check the history of the files, it shows "empty file" since it was added, not sure why.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
PTAL Please Take A Look 👀
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants