-
Notifications
You must be signed in to change notification settings - Fork 457
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 mongodb container and connection support #986
Add mongodb container and connection support #986
Conversation
@dotnet-policy-service agree company="Microsoft" |
src/Components/Aspire.MongoDB.Driver/Aspire.MongoDB.Driver.csproj
Outdated
Show resolved
Hide resolved
src/Components/Aspire.MongoDB.Driver/AspireMongoDbDriverExtensions.cs
Outdated
Show resolved
Hide resolved
4d9b309
to
850b587
Compare
5f7fd8a
to
b1be7c1
Compare
b1be7c1
to
c43b591
Compare
22c77d9
to
40d81ee
Compare
"MongoDB": { | ||
"type": "object", | ||
"properties": { | ||
"ConnectionString": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this the only setting worth exposing? There must be more 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @davidfowl !
I'll add more settings here.
Also, I've tried to add healthcheck support but the package AspNetCore.HealthChecks.MongoDb
is not restored by the configured package sources. Is there any problem to use this package here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The package will need to be added to our internal mirror.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've implemented a custom health check for that but if you prefer I can change it to use the package when it available.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use https://github.com/Xabaril/AspNetCore.Diagnostics.HealthChecks/tree/master/src/HealthChecks.MongoDb instead of implementing a custom health check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @eerhardt I've already tried to use this health check but the package is not available.
Please see the previous comments.
#986 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, sorry I missed that. The package needs to be mirrored to our trusted feed. I'm doing that now. It should be done in a few minutes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've changed to use the package, please review.
a0b42c3
to
74b9c9a
Compare
tests/Aspire.MongoDB.Driver.Tests/AspireMongoDbDriverExtensionsTests.cs
Outdated
Show resolved
Hide resolved
"MongoDB": { | ||
"type": "object", | ||
"properties": { | ||
"ConnectionString": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use https://github.com/Xabaril/AspNetCore.Diagnostics.HealthChecks/tree/master/src/HealthChecks.MongoDb instead of implementing a custom health check.
|
||
<PropertyGroup> | ||
<TargetFramework>$(NetCurrent)</TargetFramework> | ||
<NoWarn>CS8002;CS1591</NoWarn> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are these being suppressed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because the official MongoDB.Driver package doesn't have a strongly name and it causes compilation errors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've updated with the suggestion, can we close this one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jkotas @dsplaisted - are there any drawbacks/limitations/issues in .NET 8+ with using weak named assemblies?
One that @ericstj told me was:
CoreCLR will load any version of a weak named assembly. So even if you reference v2
, if v1
happens to be lying around the runtime will load it and you'll get crazy errors later.
Our guidance https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming is that people consider strong naming their libraries. Although adding one is a binary breaking change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CoreCLR will load any version of a weak named assembly. So even if you reference
v2
, ifv1
happens to be lying around the runtime will load it and you'll get crazy errors later.
I didn't know that was the case, I'm kind of surprised by that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with concerns about Aspire being the canary here. Feels more like it should be a more centrally coordinated change across the suite of .NET products than something we just start doing. Suppressing the warning (given it's just a compiler-level thing) seems fine for us.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feels more like it should be a more centrally coordinated change across the suite of .NET products than something we just start doing
I do not see what you would like to centrally coordinate. The strong name cannot be changed for anything existing, it would be breaking. The strong-name free world can be only enjoyed by brand new components, like Aspire.
If you do not want the Aspire to be first, it is ok. If the new components are not willing to do the jump, we will be stuck with strong naming forever for everything.
cc @davidfowl
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moving from ASP.NET Core 7 to ASP.NET Core 8 is a breaking change anyway though. Are you suggesting we wouldn't stop strong-naming those assemblies ever? We don't guarantee roll-forward across TFMs for apps works without recompilation.
That said, if the overall guidance is that new libraries targeting only modern .NET should not strong name their assemblies (and we update the docs to make that clearer), then I'm more inclined to try it in Aspire.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't guarantee roll-forward across TFMs for apps works without recompilation.
This applies to apps only, it does not apply to nuget packages. We do guarantee compatibility of public surface, so that packages targeting .NET 7 have a good chance of working on .NET 8.
Are you suggesting we wouldn't stop strong-naming those assemblies ever?
Never say never :-) .NET SDK and other tools do strong name matches in number of places. Removing strong name on existing assembly would break those tools when package targeting .NET 7 is used in .NET 8 app. We have not done analysis of what it would take to get all tools fixed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we update the docs to make that clearer
src/Components/Aspire.MongoDB.Driver/MongoDbHealthCheckSettings.cs
Outdated
Show resolved
Hide resolved
src/Components/Aspire.MongoDB.Driver/AspireMongoDbDriverExtensions.cs
Outdated
Show resolved
Hide resolved
src/Components/Aspire.MongoDB.Driver/AspireMongoDbDriverExtensions.cs
Outdated
Show resolved
Hide resolved
8cf20b3
to
fc7fc08
Compare
/// <summary> | ||
/// Gets or sets a integer value that indicates the MongoDB health check timeout in milliseconds. | ||
/// </summary> | ||
public int? HealthCheckTimeout { get; set; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have this is our other database components, for example Npgsql. I wonder if we should.
Thoughts, @roji @ajcvickers @AndriySvyryd?
src/Components/Aspire.MongoDB.Driver/AspireMongoDBDriverExtensions.cs
Outdated
Show resolved
Hide resolved
src/Components/Aspire.MongoDB.Driver/AspireMongoDBDriverExtensions.cs
Outdated
Show resolved
Hide resolved
src/Components/Aspire.MongoDB.Driver/AspireMongoDBDriverExtensions.cs
Outdated
Show resolved
Hide resolved
src/Components/Aspire.MongoDB.Driver/AspireMongoDBDriverExtensions.cs
Outdated
Show resolved
Hide resolved
tests/Aspire.MongoDB.Driver.Tests/AspireMongoDBDriverExtensionsTests.cs
Outdated
Show resolved
Hide resolved
private static void AddHealthCheck( | ||
this IHostApplicationBuilder builder, | ||
string connectionString, | ||
string healthCheckName, | ||
int? timeout) | ||
{ | ||
builder.TryAddHealthCheck( | ||
healthCheckName, | ||
healthCheck => healthCheck.AddMongoDb( | ||
connectionString, | ||
healthCheckName, | ||
null, | ||
null, | ||
timeout > 0 ? TimeSpan.FromMilliseconds(timeout.Value) : null)); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this worth having a separate method to just call 1 method? Why not inline this code up where this method is called?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've changed the place where the check if the healthcheck is enable is done, so now it makes sense to have a method to encapsulate all the logic related to the healthcheck feature.
Please, check gain.
protected override void SetHealthCheck(MongoDBSettings options, bool enabled) | ||
{ | ||
options.HealthCheckEnabled = enabled; | ||
options.HealthCheckTimeout = 10; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we have a better default if we feel the need to set this everywhere?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if it can be applied everywhere, the idea here is to set a very short timeout to mongo health checkt and and avoid the tests to wait the default mongoclient timeout (30000).
But what is your idea?
@ailtonguitar I pushed some changes. Please try to avoid force push if you can, I know it's your fork and you should do what pleases you with it, but I am afraid that is I do some changes they will be lost if you don't pay attention. It might also be nicer to understand the changes that you made overtime. And don't worry since we squash the commits before merging to main. |
@ailtonguitar While trying your PR I think I realize there is a flaw and a mismatch with the concept of "database". I believe you followed the pattern defined by the PostgreSQL component, and added an The issue with this model is that the current authentication only works with the "admin" database. If you try it you will see that passing anything else than "admin" as the database name will fail auth because the environment variables used are only defining a user for this db. Once I used "admin" and resolved the client for it, I could then call So right now it looks like the argument in |
@sebastienros I'm not sure that's right. I'm pretty sure this behavior is the same as all the other database hosting extensions. See #1170 for a report of the same behavior. The app is responsible for ensuring the specified database name exists so that the login can succeed. In the case of EF Core, it actually detects this state when you call |
…sTests.cs Co-authored-by: Eric Erhardt <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is getting pretty close to a mergeable state. @mitchdenny - are you good with the Hosting changes?
tests/testproject/TestProject.IntegrationServiceA/TestProject.IntegrationServiceA.csproj
Outdated
Show resolved
Hide resolved
src/Components/Aspire.MongoDB.Driver/AspireMongoDBDriverExtensions.cs
Outdated
Show resolved
Hide resolved
src/Components/Aspire.MongoDB.Driver/AspireMongoDBDriverExtensions.cs
Outdated
Show resolved
Hide resolved
builder.TryAddHealthCheck( | ||
healthCheckName, | ||
healthCheck => healthCheck.AddMongoDb( | ||
settings.ConnectionString, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally this should use the same IMongoClient instance that is registered in DI. See https://github.com/dotnet/aspire/blob/main/src/Components/README.md#health-checks.
Consider whether the Health Check should reuse the same client object registered in DI by the component or not. Reusing the same client object has the advantages of getting the same configuration, logging, etc during the health check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The AspNetCore.HealthChecks.MongoDb does not support to pass an IMongoClient instance.
It is only possible to pass the connection string or the MongoClientSettings
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've created a new PR to add support for receiving an IMongoClient instance when configuring the healthcheck
Co-authored-by: Eric Erhardt <[email protected]>
Co-authored-by: Eric Erhardt <[email protected]>
Co-authored-by: Eric Erhardt <[email protected]>
Co-authored-by: Eric Erhardt <[email protected]>
…roject.IntegrationServiceA.csproj Co-authored-by: Eric Erhardt <[email protected]>
I created a PR that will create the database in the docker container automatically, and uses I didn't want to push this change directly in case someone has other suggestions. Update: PR closed, not required anymore |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this looks good for an initial implementation.
Thanks @ailtonguitar for this great contribution.
If my only question needs a code change, we can follow up with a separate PR for it.
/// <summary> | ||
/// Gets or sets a integer value that indicates the MongoDB health check timeout in milliseconds. | ||
/// </summary> | ||
public int? HealthCheckTimeout { get; set; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may be a silly question, but if this isn't set, the health check never times out, right? How do we know if it is not healthy if the check never times out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that it will use the defined mongoclient timeout or the default value (30s).
@ailtonguitar - are you OK with the changes @sebastienros made? |
Hi @eerhardt ! Yes, fine by me! |
#694