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

Create CollectDump Collection Rule Action #824

Merged

Conversation

kkeirstead
Copy link
Member

Includes one basic test for file system egress; open to including more if other tests are desired.

Closes #632

…ay be close to functional, but don't yet have tests to confirm that.
…uring out what needs to be pulled from existing tests and how to combine it to make a test that can collect a dump using ExecuteAsync.
…. Might end up waiting until Justin's change gets merged in for using IHost to get this resolved.
… the .dmp suffix and not entirely sure whether it's working correctly, but exciting to see it function. Code is currently a mess and needs to be refined and trimmed.
…hat the permanent one is not being written. Need to investigate how that actually happens.
…about how to best integrate with existing infrastructure.
…as hurting readability in tests. No functional changes.
…cified directory. Still need to do refactoring to better share code, and probably another test for azure blob egress.
…d egress provider due to built-in validation that is not used when running unit tests. Should enter PR soon.
…t build because of complaints about netcore2.1
@kkeirstead kkeirstead requested a review from a team as a code owner September 3, 2021 20:11
@@ -66,73 +58,7 @@ public Task DumpTest(DiagnosticPortConnectionMode mode, DumpType type)
using ResponseStreamHolder holder = await client.CaptureDumpAsync(processId, type);
Assert.NotNull(holder);

byte[] headerBuffer = new byte[64];
Copy link
Member Author

Choose a reason for hiding this comment

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

This has been moved to IDumpTestInterface


IProcessInfo processInfo = await _diagnosticServices.GetProcessAsync(new ProcessKey(endpointInfo.ProcessId), token);

string dumpFileName = DiagController.GenerateDumpFileName();
Copy link
Member

Choose a reason for hiding this comment

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

Avoid this kind of coupling. Consider a separate utility class for generating the name rather than making Dump actions depend on WebServer controllers.


string dumpFileName = DiagController.GenerateDumpFileName();

string dumpFilePath = "";
Copy link
Member

Choose a reason for hiding this comment

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

nit: string.Empty

@@ -214,7 +214,7 @@ public static IEnumerable<object[]> GetTfmsSupportingPortListener()
yield return new object[] { TargetFrameworkMoniker.Net60 };
}

private ServerEndpointInfoSource CreateServerSource(out string transportName, ServerEndpointInfoCallback callback = null)
internal ServerEndpointInfoSource CreateServerSource(out string transportName, ServerEndpointInfoCallback callback = null)
Copy link
Member

Choose a reason for hiding this comment

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

If these are useful as utility methods, refactor them to a separate class that can be used by multiple test classes. Test classes should not be calling to each other. Then the utility class can have public methods that are clearly meant to be consumed by other code.


namespace Microsoft.Diagnostics.Monitoring.Tool.FunctionalTests
{
public interface IDumpTestInterface
Copy link
Member

Choose a reason for hiding this comment

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

I think what you really want here is a static class.

{
services.ConfigureCollectionRules();
services.ConfigureEgress();

services.AddSingleton<EgressOperationQueue>();
Copy link
Member

Choose a reason for hiding this comment

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

Do we really need these dependencies? You are egressing directly from what I can see.


try
{
dumpFilePath = await SendToEgress(new EgressOperation(
Copy link
Member

Choose a reason for hiding this comment

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

Since we are going to have to egress from many other actions, it would be very useful if we had an egress facade that could be used by every action.

@kkeirstead
Copy link
Member Author

Currently still dealing with additional merge conflicts that are causing test failures; will push again once resolved.

kkeirstead and others added 5 commits September 8, 2021 10:10
…unding EndpointInfoSourceCallback and EndpointUtilities). Local tests are passing.
…leNotFound exceptions, so made some changes that bring this code to more closely resemble what's being done in the Egress tests. Tests still pass locally.

namespace Microsoft.Diagnostics.Monitoring.WebApi
{
public class Utilities
Copy link
Member

Choose a reason for hiding this comment

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

internal static class.

public const string ArtifactType_Trace = "trace";
public const string ArtifactType_Metrics = "collectmetrics";

internal static string GenerateDumpFileName()
Copy link
Member

Choose a reason for hiding this comment

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

Imo, internal classes with public methods are much better for this:

  • It is clear the methods are meant to be consumed by any caller but the class as a whole is an implementation detail
  • It gives room for true internal methods. Things designed to be called by tests or glue code between classes that shouldn't be called by just anyone
  • It makes it very easy to switch to a public api should that ever be desired.

private readonly IDumpService _dumpService;
private readonly IServiceProvider _serviceProvider;

internal const string egressPath = "EgressPath";
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
internal const string egressPath = "EgressPath";
internal const string EgressPathOutputValueName = "EgressPath";

@kkeirstead kkeirstead merged commit 2ad6b1d into dotnet:feature/triggers Sep 14, 2021
jander-msft added a commit that referenced this pull request Sep 17, 2021
* Initial collection rule options, validation, and unit tests. (#688)

* Generate action and trigger options in schema. (#706)

Generate action and trigger options in schema.
Add display name descriptions to these options.
Add defaults for the optional properties.

* Create `Execute` collection rule action  (#710)

* Basic implementation and registration of actions and triggers (#736)

Initial interfaces for collection rule triggers.
Implement empty action and trigger implementations.
Implement startup trigger with special interface denoting it is a startup trigger.
Rename action provider and trigger provider to descriptor.
Register action and trigger implementations with descriptors.

* Execute Action - Testing (#742)

* Update trigger interfaces with callback, start, and stop notions. (#760)

Update trigger interfaces with callback, start, and stop notions.
Refactor options providers into operations implementations.

* Refactor host building into helper method (#769)

* Refactor host building into helper method.

* Triggers - Action List Executor (#768)

* Implement collection rule pipeline, event counter trigger, and tests. (#825)

Implement collection rule pipeline and event counter trigger.
Add tests for collection rule pipeline with real and test triggers and actions.

* Create CollectDump Collection Rule Action (#824)

* Fix CollectionRulePipelineTests failure due to callback registration timing. (#854)

* Collection rule service, logging, and some functional tests (#852)

* Implement collection rule service for starting rules.
Add logging throughout collection rule system.
Add some functional tests for collection rule system.

* Refactor common parameters into CollectionRuleContext.

* Add safe cancellation.

* Add collection rule completion timeouts.

* Refactor logging event IDs into separate shareable class.

* Adjust temporary directory creation and log cleanup failures.

* Remove CollectionRulePipeline.StartAsync; replace with callback.
Add safe awaiting for start tasks and run tasks.
Add more logging and adjust some log levels.

* Replace TestCommon dependency with Xunit.Assert (#874)

Co-authored-by: dotnet-maestro[bot] <42748379+dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: kkeirstead <[email protected]>
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Wiktor Kopec <[email protected]>
Co-authored-by: Patrick Fenelon <[email protected]>
@kkeirstead kkeirstead deleted the kkeirstead/triggers/DumpAction branch November 7, 2022 16:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants