Tracking Issue For migrate integration from dotnet/aspire repo

[Alirexaa]

We're looking to migrate some of the integrations from the .NET Aspire repo.

There is some open PRs like #5786 , #5721 in aspire repo that should move to this repo.

@aaronpowell @davidfowl, Could you please list other integrations that should move to this repo and update the issue description?

[aaronpowell]

One thing we need to be mindful of when looking to migrate integration proposals from the dotnet/aspire repo is to do it in a sustainable and maintainable way. Every integration that is added to the Community Toolkit comes with a maintenance cost, so we need to ensure that we plan for that by looking who is going to own it and be responsible to keeping it up to date.

[davidfowl]

Right, we shouldn't be accepting integrations that aren't going to be maintained. That said, here are a list of issues and PRs that should be up for consideration:

LocalStack - dotnet/aspire#875
Minio - dotnet/aspire#1800
ActiveMQ - dotnet/aspire#4094
Apache Pulsar - dotnet/aspire#4146
Redis stack - dotnet/aspire#5479
SurrealDB - dotnet/aspire#5721
Supabase - dotnet/aspire#4271

Issues:

EdgeDB - dotnet/aspire#4082
Hashicorp Vault - dotnet/aspire#4753
KrakenD - dotnet/aspire#5452

[aaronpowell]

Here's a list that's previously been brought to my attention (and overlaps with those one that you've noted):

• LocalStack - Integrate LocalStack for Developing AWS Applications Locally dotnet/aspire#875
• Minio - Add Minio To Aspire dotnet/aspire#1800
• ActiveMQ - ActiveMQ classic hosting dotnet/aspire#4094
• Apache Pulsar - feat: support Aspire.Hosting.Apache.Pulsar dotnet/aspire#4146
• SurrealDB - feat: add surrealdb component dotnet/aspire#5721
• Supabase - Request: Supabase  dotnet/aspire#4271

Here's my observation of these ones:

• LocalStack: Given the AWS nature of it, I'm apprehensive until there's some decisions about the Aspire.AWS.* work that has been started in the dotnet/aspire repo
• MinIO: Similar concerns as above (it looks like an AWS component with abstraction), it's also lacking tests and a sample, so it'd take a bit more work to be ready to onboard
• ActiveMQ: Easy adopt, needs a sample. Only barrier is that it uses the VolumeNameGenerator class via a linked include so if that's not public (since the PR was created) we'll either have to copy it or find another solution (ie - can it be made public in a future Aspire release)
• Apache Pulsar: Easy adopt, very well implemented. Also uses VolumeNameGenerator though
• SurrealDB: Needs some tests + sample, but looks like a simple addition
• Superbase: Happy for the issue to be directed across. Given I've never used Superbase (or Firebase for that matter) personally so I'd be the wrong person to try and tackle it as an integration, but fine with someone contributing it

[Alirexaa]

There is anothor list that @davidfowl did not mention but I think this repo is place for that:

• Meilisearch Meilisearch integration dotnet/aspire#5786
• KafkaFlow Component KafkaFlow Component support on Aspire dotnet/aspire#1280
• Marten Support Marten as postgres client componet dotnet/aspire#4887
• Hazelcast Add Hazelcast Hosting Component dotnet/aspire#4794
• PgVector Add support for PgVector extension to postgres resource dotnet/aspire#3052

Meilisearch PR is already completed and I could move it here.
@davidfowl I could close Meilisearch PR in dotnet/aspire repo and bring all work here, do you agree?

[Alirexaa]

Another thing should i mention that in dotnet/aspire repo we use netaspireci.azurecr.io container registery for e2e testing (Docker Hub has a rate limit on how often requests can be made from an IP).

Do we use the same container registry or we should do something else?

[aaronpowell]

Another thing should i mention that in dotnet/aspire repo we use netaspireci.azurecr.io container registery for e2e testing (Docker Hub has a rate limit on how often requests can be made from an IP).

Do we use the same container registry or we should do something else?

What does it need to use from a container registry to do the tests? Is it publishing container images? We may be able to use GitHub Packages for that.

[Alirexaa]

In tests we just change the registry of the container to the mirror registry and keep the image and tag without change.
For example docker.io/library/redis:7.0 will be netaspireci.azurecr.io/library/redis:7.0.
I wonder how we can have same behavior with github container registry?
For more detail see aspire docs:
https://github.com/dotnet/aspire/blob/main/docs%2Fupdating-container-registry.md

[aaronpowell]

The link says that this is in place to work around a rate limiting issue with pulling images from the docker.io registry and it may not be a problem that we'll hit as we're unlikely to run the same volume of builds.

Also, we can (and do, but don't do it well) cache container images with GitHub Actions (see https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows) so until it becomes a problem, we don't need to work around it.

[anoordover]

I've move ActiveMQ to the community toolkit as proposed in other "issues": #273.
When should something be part of the CommunityToolkit?

[aaronpowell]

When should something be part of the CommunityToolkit?

We should get something more clearly written up on when something would be a candidate for the Community Toolkit and when it's not.

Simply put, new integrations should be proposed in the Community Toolkit and not the dotnet/aspire repo. But that doesn't mean that everything would be a candidate for the toolkit, after all, we have finite amount of capacity to support everything, so some general thoughts I have are:

• Is it broadly useful to people building with Aspire? If it's super niche and only going to be used by you, it's not likely a good candidate.
• Does it fit with the problem space that Aspire operates in? Aspire is designed to improve the developer inner loop, especially for distributed applications, so the integration should fit in that.
• Does the company/OSS project the integration is for want to create/manage it themselves? For example, RavenDB was proposed early on, but they would prefer to ship it in their tool stack, so having an integration here doesn't make sense.

[NapalmCodes]

I am the author of the KrakenD integration (component) mentioned above. I am curious if it’s relevant to migrate or not given some of the criteria mentioned. That said, I have not seen many options for API Gateway integrations in Aspire which is a common design pattern for microservice based architectures.

I also completely understand the maintenance burden too. So with that said, what is the process here? Should a proposal issue be written to discuss community interest etc?

[aaronpowell]

API gateways pose an interesting question on whether they are the kind of thing you would have an Aspire integration for or not. We did have Azure API Management proposed (#59 was the issue) and decided against it, you can read the why there.

From my (limited) knowledge of KrakenD, the arguments aren't really the same since it's not an Azure service, but I still feel like the notion of this would introduce a level of complexity that would have me cautious about it as an Aspire integration.

[NapalmCodes]

I hear what you are saying, however there are cases where you might want this locally to reproduce things like token exchange or header augmentation etc. If you use this for rate limiting, api keys, caching, etc. I think there is a compelling use case to supplement the local development experience. It’s kind of a necessary evil for specific microservice designs.

[aaronpowell]

I can see how it would be valuable in a dev workflow, otherwise you're never truly testing/developing the app under the conditions that users are using it, and as such, run the risk of "works on my machine" but nowhere else.

Rather than overloading this issue, if you think KrakenD is something you'd want to contribute to the toolkit, let's spin up a new issue on it (as I have some thoughts on design/features/etc.). But at the same time, I want others to not feel any pressure to have their integrations in the toolkit or that we're trying to be a gatekeeper to integrations.

[maranmaran]

• Apache Pulsar - feat: support Aspire.Hosting.Apache.Pulsar dotnet/aspire#4146

Should I move pulsar integration? @aaronpowell

Apache Pulsar: Easy adopt, very well implemented. Also uses VolumeNameGenerator though

I'd have to update on guidance about VolumeNameGenerator, care to elaborate or we can take it in the follow-up PR?

[aaronpowell]

• Apache Pulsar - feat: support Aspire.Hosting.Apache.Pulsar dotnet/aspire#4146

Should I move pulsar integration? @aaronpowell

Happy to review it as a contribution. Make sure you check out the contributor guide on how to set it up in the repo.

Apache Pulsar: Easy adopt, very well implemented. Also uses VolumeNameGenerator though

I'd have to update on guidance about VolumeNameGenerator, care to elaborate or we can take it in the follow-up PR?

We have a copy of that file in the repo in a shared location that you can add into projects. Check out https://github.com/CommunityToolkit/Aspire/blob/main/src/CommunityToolkit.Aspire.Hosting.ActiveMQ/CommunityToolkit.Aspire.Hosting.ActiveMQ.csproj#L8-L10

[NapalmCodes]

I can see how it would be valuable in a dev workflow, otherwise you're never truly testing/developing the app under the conditions that users are using it, and as such, run the risk of "works on my machine" but nowhere else.

Rather than overloading this issue, if you think KrakenD is something you'd want to contribute to the toolkit, let's spin up a new issue on it (as I have some thoughts on design/features/etc.). But at the same time, I want others to not feel any pressure to have their integrations in the toolkit or that we're trying to be a gatekeeper to integrations.

Submitted #328