Skip to content

Conversation

mahadi99xy
Copy link
Collaborator

🚧 Suggest a change

A clear and concise description of what you are changing.

📝 Pre-merge checklist

Ready to merge? Do not merge until all checks are satisfied.

  • 💹 Have all required CI checks passed on the most recent commit?
  • ✒️ Is the PR title a valid and meaningful conventional-commit message? ie. type(scope): summary
  • 💥 Are breaking changes declared in the PR title in conventional-commit style? ie. type!(scope): summary
  • 🎨 Does new code follow the code style of this project?
  • 🔍 Has new code been spellchecked and linted?
  • 📖 Have docs been updated where necessary?
  • 💩 Have commits been checked for accidental file inclusions?

Copy link

github-actions bot commented Jul 4, 2025

✒️ PR Title Commitlint - ✔️ Lint success!

@beforan
Copy link
Collaborator

beforan commented Jul 8, 2025

I couldn't find an item in JIRA for this PR, so I'm not really sure I fully understand the context.

Do these endpoints really belong on the SubmissionsController?
What are these credentials used for and why do we need to set them programmatically?

I get that Minio have painted us into a corner with having to use the admin cli if we do want to do this stuff programmatically (I'm really mad the REST API for this is undocumented), but I still don't like it as an approach and I feel like we have to do a lot design wise to mitigate future issues.

This PR's implementation is obviously docker specific and relies on a bunch of stuff:

  • A container for the admin cli existing
  • knowing the container name upfront
  • Having rights to run docker exec from the app's container (including the docker socket being mounted)
  • Communicating all that to anyone who wants to deploy it in a different way to our sample compose files.

But we also know that within the next few months we will want these applications running in Kubernetes.

We should have a plan for what that looks like (sidecar that works like this does? run a Job via the k8s api?) and therefore what the code looks like for doing the cli stuff in multiple completely different environments.

It's also completely Minio specific which is fine for this implementation but not from a standard API point of view. So that's a small consideration (Captured in my other comments).

@@ -28,5 +29,8 @@ public interface IMinioHelper
Task<bool> BucketPolicySetPublic(string bucketName);

Task DeleteObject(string bucketName, string objectKey);
Task<MinIOOperationResult> CreateUserWithMcAsync(string accessKey, string secretKey);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Task<MinIOOperationResult> CreateUserWithMcAsync(string accessKey, string secretKey);
Task<MinIOOperationResult> CreateUserAsync(string accessKey, string secretKey);

WithMc is an implementation detail.

Arguably put that it's used in a doc comment to inform people how it works, but that should go on the implementation not the interface.

@@ -28,5 +29,8 @@ public interface IMinioHelper
Task<bool> BucketPolicySetPublic(string bucketName);

Task DeleteObject(string bucketName, string objectKey);
Task<MinIOOperationResult> CreateUserWithMcAsync(string accessKey, string secretKey);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Task<MinIOOperationResult> CreateUserWithMcAsync(string accessKey, string secretKey);
Task<MinIOOperationResult> CreateUserAsync(string accessKey, string secretKey);

WithMc is an implementation detail.

Arguably put that it's used in a doc comment to inform people how it works, but that should go on the implementation not the interface.

@@ -28,5 +29,8 @@ public interface IMinioHelper
Task<bool> BucketPolicySetPublic(string bucketName);

Task DeleteObject(string bucketName, string objectKey);
Task<MinIOOperationResult> CreateUserWithMcAsync(string accessKey, string secretKey);
Task<MinIOOperationResult> SetUserPolicyAsync(string accessKey, string policyName);
Task<MinIOOperationResult> RemoveUserWithMcAsync(string accessKey);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Task<MinIOOperationResult> RemoveUserWithMcAsync(string accessKey);
Task<MinIOOperationResult> RemoveUserAsync(string accessKey);

As above, WithMc is an implementation detail

Comment on lines +754 to +756
// Adjust container name based on your Docker Compose setup
var containerName = _minioSettings.ClientContainerName ?? "minio-client";
var dockerCommand = $"docker exec {containerName} {command}";
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this only works for docker, with some caveats:

  • We know the container name up front
  • This container (or environment) has access to the docker command, the docker socket (where this container is running), and permission to docker exec into the target container

We do know however that we are going to want to deploy this application on k8s at a minimum soon.

I guess just wanted to put it on the radar that we need to start designing for what this code looks like when we support both.

// Linux/macOS - use bash
return new ProcessStartInfo
{
FileName = "/bin/bash",
Copy link
Collaborator

@beforan beforan Jul 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fine for now but it should be noted that this limits the app to running in containers where bash isn't available.

e.g. If someone wanted to build their own alpine container image for this app, this would stop them.

/// </summary>
/// <param name="accessKey">Access Key identifier</param>
/// <param name="secretKey">Secret Key identifier</param>
[HttpPost("create-minio-secret/{accessKey}/{secretKey}")]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be on SubmissionController?

it's not directly about handling a Submission, and I'm not sure I fully know the context for the functionality.

The end point is very RPC. It's an action create-minio-secret whereas really a Minio secret should be a resource, and a route to create one would be something like POST /api/v1/minio-secret

But also it shouldn't have minio in the route because that's an implementation detail, and we intend this to be a standard API (unless this isn't part of the standard)

So maybe storage-secret or something? Though that's too general and unhelpful. Like I say, I don't really understand what this is for.

/// </summary>
/// <param name="accessKey">Access Key identifier</param>
/// <param name="policyName">Secret Key identifier</param>
[HttpPost("set-policy-minio-secret/{accessKey}/{policyName}")]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As above, not sure this should be on SubmissionController, and it shouldn't explicitly reference minio unless it's not intended to be part of the standard API.

/// Remove secret for minio
/// </summary>
/// <param name="accessKey">Access Key identifier</param>
[HttpPost("remove-minio-secret/{accessKey}")]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as other endpoints

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants