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 - https://github.com/dotnet/aspire/pull/875 Minio - https://github.com/dotnet/aspire/pull/1800 ActiveMQ - https://github.com/dotnet/aspire/pull/4094 Apache Pulsar - https://github.com/dotnet/aspire/pull/4146 Redis stack - https://github.com/dotnet/aspire/pull/5479 SurrealDB - https://github.com/dotnet/aspire/pull/5721 Supabase - https://github.com/dotnet/aspire/issues/4271

Issues:

EdgeDB - https://github.com/dotnet/aspire/issues/4082 Hashicorp Vault - https://github.com/dotnet/aspire/issues/4753 KrakenD - https://github.com/dotnet/aspire/issues/5452

[aaronpowell]

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

• LocalStack - https://github.com/dotnet/aspire/pull/875
• Minio - https://github.com/dotnet/aspire/pull/1800
• ActiveMQ - https://github.com/dotnet/aspire/pull/4094
• Apache Pulsar - https://github.com/dotnet/aspire/pull/4146
• SurrealDB - https://github.com/dotnet/aspire/pull/5721
• Supabase - https://github.com/dotnet/aspire/issues/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 https://github.com/dotnet/aspire/pull/5786
• KafkaFlow Component https://github.com/dotnet/aspire/issues/1280
• Marten https://github.com/dotnet/aspire/issues/4887
• Hazelcast https://github.com/dotnet/aspire/issues/4794
• PgVector https://github.com/dotnet/aspire/issues/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.