-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
GCS artifact loading fails if key is a directory #1351
Comments
BTW, are there any files in that directory? What happens if you remove the training slash from the path? |
I also had this bug. apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: arguments-artifacts-
spec:
entrypoint: kubectl-input-artifact
arguments:
artifacts:
- name: kubectl
s3:
endpoint: storage.googleapis.com
bucket: gcp-public-data-landsat
key: LC08/01/044/034/LC08_L1GT_044034_20130330_20170310_01_T2
accessKeySecret:
name: argo-cred
key: accesskey
secretKeySecret:
name: argo-cred
key: secretkey
templates:
- name: kubectl-input-artifact
inputs:
artifacts:
- name: kubectl
path: /usr/local/bin/kubectl
container:
image: debian:9.4
command: [sh, -c]
args: ["ls -l {{inputs.artifacts.kubectl.path}}"] I get a different error: And I'm using argo Logs for failures (from stackdriver):
|
This error is from s3.IsDirectory in it's call to minioClient.ListObjectsV2 ListObjectsV2 is not supported by GCS interop API minioClient.ListObjects is supported by GCS, and it returns the same type. Would this work as a replacement in pkg/s3.IsDirectory? |
minioClient.ListObjectsV2 is not supported by GCS, causing the bug in argoproj/argo-workflows#1351
@bakennedy - it seems like it's expecting some kind of continuation token -- minio/minio@3ec4738 |
Meantime workaround - grab all the artifacts from the workflow and decompress them into a temporary folder, then repackage it back out as a single artifact:
|
minioClient.ListObjectsV2 is not supported by GCS, causing the bug in argoproj/argo-workflows#1351
Closed inadvertently via merge of argoproj/pkg#6. This needs to remain open until dependencies are updated |
@Downchuck thank you for the work around suggestion, and @jessesuen thanks for an expeditious merge! We're doing genre sequencer research, and using a lot of huge files. This will really help us out. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
BUG REPORT
What happened:
After switching from minio to GCS, workflows which tried to load "directory" from GCS as a artifact started to fail with message
failed to load artifacts: The specified key does not exist.
.What you expected to happen:
To be working the same way as minio does.
How to reproduce it (as minimally and precisely as possible):
Try to run this step on minio and then on GCS. Notice that the
key
is pointing to the "directory", not a specific file.Possible cause:
I believe this is caused by the fact that minio returns empty object when you try to access directory object.
GCS returns 404 =>
The specified key does not exist
.Anything else we need to know?:
Environment:
The text was updated successfully, but these errors were encountered: