-
Notifications
You must be signed in to change notification settings - Fork 242
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 sample of container with persistent volume mount #52
Conversation
var sqlpassword = builder.Configuration["sqlpassword"] ?? | ||
throw new InvalidOperationException(""" | ||
A password for the local SQL Server container is not configured. | ||
Add one to the AppHost project's user secrets with the key 'sqlpassword', e.g. dotnet user-secrets set sqlpassword <password> | ||
"""); |
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 is to workaround our bug? Why not generate 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.
If you generate one each time, then the user created during the first run can't be logged in to during the subsequent runs. At least, that's what I saw.
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.
@mitchdenny does this align with your expectations of the SQL Server container?
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 is to workaround our bug?
But yes, in preview.1 you have to work around our bug of the generated passwords not meeting the complexity requirements. I had this originally doing Guid.NewGuid().ToString()
but found that I'd get database login errors on runs subsequent to the one the migrations are applied to.
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.
You know to get around the persistent password problem (generically) we could look at capturing and storing the generated password so that it is reused on subsequent executions of the AppHost. That way folks wouldn't need to worry about doing these config shenanigans (unless they really want to).
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 like the idea. I can see one challenge being that the logical place to store it would be user secrets but that requires mutating the AppHost project (it requires a property to be set to set the user secrets ID), and mutating the project file automatically while the app is running is probably not a great idea.
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.
Logged dotnet/aspire#1151
Co-authored-by: David Fowler <[email protected]>
I like this. It's a good approach to solving the persistent container issue. |
Fixes #44