Hi,

I am trying out Qaz but on the first attempt I have gotten stuck when trying to use a cross account role that has an MFA set.

error: AssumeRoleTokenProviderNotSetError: assume role with MFA enabled, but AssumeRoleTokenProvider session option not set.

Credentials file looks like this:

[default]
aws_access_key_id = xxxxxxxxxxxxxxxxxxxxx
aws_secret_access_key = xxxxxxxxxxxxxxxxxxxxxxxxxx
[testaccount]
role_arn = arn:aws:iam::12345678910:role/xxxxxxx
source_profile = default
mfa_serial = arn:aws:iam::12345678910:mfa/jrudge

Not sure if this is a bug.

Thanks,
Jonathan

After heavy use of Qaz i've found that often time the AWS Cloudformation API request limit is hit. This due to qaz making excessive calls to AWS to track and print the deployment stages. Each stack is allocated it's own go routine, which when dealing with deployments of 8 or more stacks, can lead to dozens of requests per second.

To alleviate the load, I'm going to implement a service model for the output tail mechanism. That is, instead of each stack calling the API directly to requests it's deployment status for tailing, all requests will be passed to a channel and the tail requests executed in a linear manner. As this is just for printing output to the terminal, the impact is minimal.

Hi again @daidokoro,

I updated my local version of qaz to 0.81.3-beta from 0.81-beta and after adding notification-arns to the config.yml file I see notifications being published to my specified SNS topic.

I did however notice a change in the way in which qaz uses the credentials provider chain. I'm not sure what the problem could be, but here is the symptom:

I have my developer credentials in the ~/.aws/credentials file. These temporary credentials give me access to assume other roles - one of which is a 'stack builder' role that QAZ needs since
my developer credentials are not powerful enough to deploy stacks. During deployment (when calling qaz deploy or qaz update) I am setting my ENV variables to a different set of short lived credentials that I obtain through an aws sts assume-role call.

In version 0.81-beta qaz picks up the credentials from the environment variables.
version 0.81.3-beta does not pick up credentials from environment variables.

I'm getting this error from qaz when I try to redirect the AWS_SHARED_CREDENTIALS_FILE environment variable to a temp file that I am now storing my short lived stack builder credentials in.

QAZ throws the below error:
error: failed to fetch status for [myStack]: NoCredentialProviders: no valid providers in chain. Deprecated.
For verbose messaging see aws.Config.CredentialsChainVerboseErrors

Any thoughts?

I recently needed to add an AWS SSM Document to one of my CloudFormation Stacks managed by Qaz. Due to the use of the Jinja-style for variable syntax "{{ variable }}" in SSM documents as well I now get Gen-Time errors "function variable not defined". I know I could change the qaz delimiters by setting a different gen_time value in config.yml but this would lead to different settings in different projects which might confuse my collegues also working on my templates.

My first idea to workaround this was to implement a function rendering a "string" to "{{ string }}" at Gen-time but I would prefer using quotes if possible.

Does anyone know a better way to address this issue?

Given
$ qaz deploy -c my.yml -t vpc.json

If vpc is not defined as a stack within my.yml, we get a Go Panic and crash. Need to look at handling this error.

Planning to implement a tail command, to follow Cloudformation updates in realtime. Should be easy, just redirect the Verbose function.

Hey there:

One of the templates I'm deploying is quite large, about 67k. AWS requires that templates over around 50k first be uploaded to an s3 bucket, so I'm currently unable to deploy the template via qaz. I think it may be necessary to have qaz potentially create a bucket prior to deployments.

Thanks.

It would be nice to be able to set the notification arns for cloudformation create / update events. with the aws cli it's as easy as specifying some ARNs behind the --notification-arns like so:

https://docs.aws.amazon.com/cli/latest/reference/cloudformation/create-stack.html

--notification-arns (list)

The Simple Notification Service (SNS) topic ARNs to publish stack related events. You can find your SNS topic ARNs using the SNS console or your Command Line Interface (CLI).
Syntax:

"string" "string" ...

Would you be open to this? I'm thinking it should be in the config.yml as a property of the stack, something like:

region: us-east-1
project: my-project

stacks:
 my-stack:
    source: ./cloud-formation.yml
    parameters:
      - ParamOne: some-value
      - ParamTwo: anotherValue
    notification-arns:
      - arn:aws:sns:us-east-1:123456789012:MyCloudFormationEventSNSTopic
      - arn:aws:sns:us-east-1:123456789012:MyOtherCloudFormationEventSNSTopic

If there is already support for this I did not notice it in the documentation.

I'm quite sure after reading the docs how I'm supposed to handle environments.

If I want to have a different, say, VPC CIDR block for dev vs stage, how do I handle this?

Are stacks the "environments" ?

If that's the case, how do I template a CIDR block value based on the environment/stack? All the examples I see have hard coded references to .<stack name>.cidr

Initially didn't consider this as Qaz is able to write values from the config directly their respective locations in the template. However, given the issue of sensitive data, for eg. DB passwords and such. I believe I need to support parametrisation so the NoEcho Cloudformation flag can be implemented when needed.

I'm thinking a new keyword in config. So stack config would look like this:

stacks:
  rds:
    depends_on:
       - vpc
    
    parameters:
       - param_name: param_value

    cf:
      yourvalues: value

I'd be nice to support sprig functions inside templates.

One the major wants, to be able to invoke a lambda function, not just as a command but within a template.

Need to create functional unit tests .

Hi. This isn't really an issue with the existing application, but I wanted to bring up a possible use case. I currently use Ansible and a custom set of scripts to do largely the same thing that your excellent app appears to be doing here, with an emphasis on being able to automate the entirety of an application deployment, including pieces that must be done outside of Cloudformation.

This leads us to need to make subshell calls and/or run arbitrary scripts to make API calls. There are a variety of specific use cases, but for the most part they fall under two categories:

1. when we encounter functionality that is not yet or not fully implemented in Cloudformation.

In such cases, we generally fall back to using aws cli or a script using the SDK.

2. when we have to do steps in between a multi-stack deployment.

For example, I may build a stack that generates a KMS key and need to encrypt/inject something into user data in a subsequent stack. For such cases, our automation provides easy hooks to be able to run pre- and post-tasks.

One could definitely argue that both of these sorts of use cases are better solved with custom Cloudformation resources. For better or worse, we've thus far been reluctant to go down that path. I'm curious whether anyone has any thoughts as to whether allowing more-or-less arbitrary pre- and post-stack tasks would be a worthy addition to this app.

Cheers,

Need make binaries accessible to those not running Go locally. I need to setup a build/compile mechanism to update releases.

There needs to be a structured mechanism for logging and a method of triggering log levels.
I'm thinking a debug flag qaze --debug

To that end, I need to identify a good Go logging library that takes care of the log level mechanisms.

What I like about the AWS Web Console is the preview of changes before finally updating the stack. To get something similar using qaz, I have currently defined an alias function (zsh):

qaz-preview() {
  stack=$1
  answer=
  qaz change create update -s $stack && \
    qaz change desc update -s $stack && \
    vared -p "Apply changes? " answer
  case "$answer" in
    [Yy])
      qaz change execute update -s $stack
      ;;
    *)
      echo "Aborting."
      qaz change rm update -s $stack
      ;;
  esac
}

It creates a change set called "update", describes it and finally asks whether to proceed or not without leaving any artifacts.

I could try to implement this in qaz, as this seems a pretty convenient workflow for me, but there might also be advantages keeping the logic "outside" like this. Options might be to grep the description for replacement: "True" or to count the number of resources to be changed to print a summary before asking to proceed to emphasize on the complexity of the change. Of course this could also easily be implemented internally, but the question is what makes more sense.

For the internal implementation I would see at least two different ways:
a) extending the existing change command with a new subcommand, like qaz change workflow -s <stack>
b) adding an option to the update command, like qaz update -i <stack> with -i for "interactive" update (-p for "preview" might overlap with existing profile option)

Need to implement a command for creating, viewing, executing & removing change-sets.