coreos / awscli Goto Github PK

Hi,
We are using the below command to download the image into the kube cluster and this has stopped working just from today. Can you please help and let us know what the issue is?

• /usr/bin/rkt run --net=host --volume=dns,kind=host,source=/etc/resolv.conf,readOnly=true --mount volume=dns,target=/etc/resolv.conf --volume=awsenv,kind=host,source=/var/run/coreos,readOnly=false --mount volume=awsenv,target=/var/run/coreos --trust-keys-from-https quay.io/coreos/awscli:master --exec=bash -- -c 'aws configure set s3.signature_version s3v4; aws s3 --region ap-southeast-2 cp s3://clusters//exported/stacks/control-plane/userdata-controller-6adf4cd927896e79d89029e5a963e8feb3deed2732cd50e936fea44c21a43688 /var/run/coreos/userdata-controller'
  image: error adding keys: openpgp: invalid argument: no armored data found
  Downloading signature: [=======================================] 473 B/473 B
  image: if you expected the signing key to change, try running:
  image: rkt trust --prefix "quay.io/coreos/awscli"
  run: openpgp: signature made by unknown entity

Hi!

I would like to use your docker file as a starting point for my own container project, but you don't have a licensed file specified in the repo. Technically this means that the files fall under default copyright and are not legal for others to use. Is this meant to be an open source project?

As part of my kube-aws setup I'm running on CoreOS 1235.12.0 (yes, I know it's old, different construction site!), and the follow command in the cloudinit script started producing errors:

/usr/bin/rkt run \
   --net=host \
   --volume=dns,kind=host,source=/etc/resolv.conf,readOnly=true --mount volume=dns,target=/etc/resolv.conf  \
   --volume=awsenv,kind=host,source=/var/run/coreos,readOnly=false --mount volume=awsenv,target=/var/run/coreos \
   --trust-keys-from-https \
   quay.io/coreos/awscli:master -- aws s3 --region $REGION  cp s3://xxxxxxxxxxxxxxxx/$USERDATA_FILE /var/run/coreos/

This breaks the complete startup of the instance, as the next command then of course won't work either:

exec /usr/bin/coreos-cloudinit --from-file /var/run/coreos/$USERDATA_FILE

I can reproduce this minimally with this:

$ sudo /usr/bin/rkt run --net=host --volume=dns,kind=host,source=/etc/resolv.conf,readOnly=true --mount volume=dns,target=/etc/resolv.conf --volume=awsenv,kind=host,source=/var/run/coreos,readOnly=false --mount volume=awsenv,target=/var/run/coreos --trust-keys-from-https quay.io/coreos/awscli:master -- aws
[  644.410459] awscli[6]: /bin/sh: can't open 'aws'

It still works with the 'latest' version, which is actually from a year ago:

$ sudo /usr/bin/rkt run --net=host --volume=dns,kind=host,source=/etc/resolv.conf,readOnly=true --mount volume=dns,target=/etc/resolv.conf --volume=awsenv,kind=host,source=/var/run/coreos,readOnly=false --mount volume=awsenv,target=/var/run/coreos --trust-keys-from-https quay.io/coreos/awscli:latest -- aws
[ 1640.167349] awscli[6]: usage: aws [options] <command> <subcommand> [<subcommand> ...] [parameters]
[ 1640.167910] awscli[6]: To see help text, you can run:
[ 1640.168309] awscli[6]:   aws help
[ 1640.168631] awscli[6]:   aws <command> help
[ 1640.168957] awscli[6]:   aws <command> <subcommand> help
[ 1640.169282] awscli[6]: aws: error: too few arguments

rkt image list gives:

ID			NAME					SIZE	IMPORT TIME	LAST USED
sha512-8b46b029b1f8	quay.io/coreos/awscli:master		197MiB	38 minutes ago	38 minutes ago
sha512-1ffd0864313d	quay.io/coreos/awscli:latest		196MiB	45 seconds ago	44 seconds ago

I think it makes sense to use the version of the awscli package itself (eg quay.io/coreos/awscli:1.11.167). Maybe include an additional coreos version tag as is done with the hyperkube image.

Is this project/image still alive? The awscli included is about 18 months out of date (still defaults to V2 auth) and there are pull requests #9 and #12 to update it from 7 and 3 months ago by @euank and @martinssipenko update the versions with no movement.

Is this still a going concern or better to fork or switch to a different image?

I believe in the past this repository had a manually triggered Jenkins job which would mirror master to latest as a sort of 'promotion' / 'release'.
Do you recall if that was the case and if there were any more details there @colhom?

We should likely set something like that up agian since latest is quite out of date at this point.

Note that we shouldn't mirror master quite yet since #15 should be resolved first to avoid regressions on latest.