-
Notifications
You must be signed in to change notification settings - Fork 142
Support running native Ollama #978
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
Conversation
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.
Pull Request Overview
This PR adds support for running Ollama natively as an executable resource in addition to the existing container-based approach. It introduces OllamaExecutableResource alongside a new IOllamaResource interface to support both execution modes uniformly.
Key changes:
- Introduced
IOllamaResourceinterface to abstract common Ollama resource functionality - Added
OllamaExecutableResourcefor running Ollama as a native executable process - Updated extension methods and tests to work with both container and executable resources
Reviewed Changes
Copilot reviewed 14 out of 14 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| tests/CommunityToolkit.Aspire.Hosting.Ollama.Tests/CommunityToolkit.Aspire.Hosting.Ollama.Tests.csproj | Updated project reference to use example AppHost instead of test-specific AppHost |
| tests/CommunityToolkit.Aspire.Hosting.Ollama.Tests/AppHostTests.cs | Refactored tests to validate both container and executable Ollama resources using IOllamaResource |
| tests/CommunityToolkit.Aspire.Hosting.Ollama.Tests/AddOllamaTests.cs | Removed extraneous blank line |
| tests/CommunityToolkit.Aspire.Hosting.Ollama.Tests/AddOllamaLocalTests.cs | Added comprehensive test coverage for AddOllamaLocal functionality |
| src/CommunityToolkit.Aspire.Hosting.Ollama/OpenWebUIResource.cs | Updated to use IOllamaResource interface instead of concrete OllamaResource type |
| src/CommunityToolkit.Aspire.Hosting.Ollama/OllamaResourceBuilderExtensions.cs | Added AddOllamaLocal method and refactored shared command logic to support both resource types |
| src/CommunityToolkit.Aspire.Hosting.Ollama/OllamaResourceBuilderExtensions.OpenWebUI.cs | Fixed Open WebUI URL generation to properly handle both resource types using ReferenceExpressionBuilder |
| src/CommunityToolkit.Aspire.Hosting.Ollama/OllamaResourceBuilderExtensions.Model.cs | Updated model extension methods to accept IOllamaResource instead of concrete type |
| src/CommunityToolkit.Aspire.Hosting.Ollama/OllamaResource.cs | Implements IOllamaResource interface with inherited documentation |
| src/CommunityToolkit.Aspire.Hosting.Ollama/OllamaModelResource.cs | Updated to reference IOllamaResource as parent type |
| src/CommunityToolkit.Aspire.Hosting.Ollama/OllamaExecutableResource.cs | New executable resource implementation for running Ollama natively |
| src/CommunityToolkit.Aspire.Hosting.Ollama/IOllamaResource.cs | New interface defining common Ollama resource contract |
| examples/ollama/CommunityToolkit.Aspire.Hosting.Ollama.AppHost/Program.cs | Updated example to demonstrate AddOllamaLocal usage |
| .github/actions/setup-runtimes-caching/action.yml | Added Ollama installation step to CI workflow |
tests/CommunityToolkit.Aspire.Hosting.Ollama.Tests/AddOllamaLocalTests.cs
Outdated
Show resolved
Hide resolved
tests/CommunityToolkit.Aspire.Hosting.Ollama.Tests/AddOllamaLocalTests.cs
Outdated
Show resolved
Hide resolved
|
@dotnet-policy-service agree |
aaronpowell
left a 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.
Some API changes/suggestions and it looks like we have test failures going on
| - uses: ai-action/setup-ollama@v1 | ||
| name: Setup Ollama | ||
| if: ${{ inputs.name == 'Full' || contains(inputs.name, 'Hosting.Ollama') }} | ||
| with: | ||
| version: 0.11.8 |
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 it's best that we set it up on all Ollama tests runs, as we should do CI on both the container and non-container versions of Ollama
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 agree, to avoid any extra workflow/actions setup on non-ollama tests I felt like this was as specific as I could get. The AppHostTests that test both container/non-container versions live in a single test project (CommunityToolkit.Aspire.Hosting.Ollama.Tests)
|
|
||
| var ollama = builder.AddOllama("ollama") | ||
| .WithDataVolume() | ||
| var ollama = builder.AddOllamaLocal("ollama", targetPort: 11435) |
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.
Can you make this a separate resource in the app host so we can have both resources demoed
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.
Both Ollama and Ollama local resources exist in this example AppHost (ollama2-named resource is added to builder on line 9). This example previously registered two Ollama (container) resource, I just made one now use local.
Is there another way you want this example modified to demo both container and local options?
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.
Sorry, you're right, I totally forgot that was the case
| /// </remarks> | ||
| /// <param name="name">The name of the resource.</param> | ||
| /// <param name="command">The command to execute.</param> | ||
| public class OllamaExecutableResource(string name, string command) : ExecutableResource(name, command, string.Empty), IOllamaResource |
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.
Shouldn't command be hard coded?
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.
Sure thing! Mainly I was following how other executable resources (like Java) were setup where the command name was passed in from the builder/extension method:
Aspire/src/CommunityToolkit.Aspire.Hosting.Java/JavaAppHostingExtension.Executable.cs
Line 42 in ca68bd4
| var resource = new JavaAppExecutableResource(name, "java", workingDirectory); |
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 right - I wouldn't follow the Java one, it was one of the first ones and the patterns have a evolved since then
src/CommunityToolkit.Aspire.Hosting.Ollama/OllamaResourceBuilderExtensions.cs
Show resolved
Hide resolved
src/CommunityToolkit.Aspire.Hosting.Ollama/OllamaResourceBuilderExtensions.cs
Show resolved
Hide resolved
| <ProjectReference Include="..\..\src\CommunityToolkit.Aspire.OllamaSharp\CommunityToolkit.Aspire.OllamaSharp.csproj" /> | ||
| <ProjectReference Include="..\CommunityToolkit.Aspire.Testing\CommunityToolkit.Aspire.Testing.csproj" /> | ||
| <ProjectReference Include="..\..\tests-app-hosts\Ollama.AppHost\Ollama.AppHost.csproj" /> | ||
| <ProjectReference Include="..\..\examples\ollama\CommunityToolkit.Aspire.Hosting.Ollama.AppHost\CommunityToolkit.Aspire.Hosting.Ollama.AppHost.csproj" /> |
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 need to use the custom app host because running on the github actions infra keeps causing memory issues.
…ama command in resource and exclude ollama local from manifest
Thanks for taking a look @aaronpowell! I've updated this with some of your feedback suggestions, including switching the Hosting.Ollama.Tests to point back to that |
Closes #608
Adds
OllamaExecutableResourceto theCommunityToolkit.Aspire.Hosting.Ollamahosting integration for running ollama natively as Aspire resourcesPR Checklist
Breaking changes are here mainly in updating
OllamaResourceproperties and generic constraints to use a newIOllamaResourceinterfaceOther information
ollama(using the ai-action/setup-ollama action)AppHostTeststo useexamples/ollamaapphost project; from the looks of it, it appeared Ollama AppHost tests were the only one not using anexamples/project