Unresolved resource dependencies [AutoscalingTarget] in the Resources block of the template

Rack (Version 2)
1

I’ve installed a brand new rack on the latest version, created a new app, and am trying to deploy the first release. I’m getting this error, and the deploy rolls back:

2019-04-27T20:03:38Z system/aws/cfm myapp-enterprise-myapp CREATE_IN_PROGRESS ServiceWorker
2019-04-27T20:03:38Z system/aws/cfm myapp-enterprise-myapp CREATE_IN_PROGRESS ServiceWeb
2019-04-27T20:03:38Z system/aws/cfm myapp-enterprise-myapp CREATE_IN_PROGRESS TimerSubmissionExpiration
2019-04-27T20:03:39Z system/aws/cfm myapp-enterprise-myapp CREATE_FAILED ServiceWorker Template format error: Unresolved resource dependencies [AutoscalingTarget] in the Resources block of the template
2019-04-27T20:03:39Z system/aws/cfm myapp-enterprise-myapp CREATE_FAILED ServiceWeb Template format error: Unresolved resource dependencies [AutoscalingTarget] in the Resources block of the template
2019-04-27T20:03:39Z system/aws/cfm myapp-enterprise-myapp-TimerSubmissionExpiration-1KYAKENP9K7QD CREATE_IN_PROGRESS myapp-enterprise-myapp-TimerSubmissionExpiration-1KYAKENP9K7QD User Initiated
2019-04-27T20:03:39Z system/aws/cfm myapp-enterprise-myapp CREATE_FAILED TimerSubmissionExpiration Resource creation cancelled
2019-04-27T20:03:40Z system/aws/cfm myapp-enterprise-myapp UPDATE_ROLLBACK_IN_PROGRESS myapp-enterprise-myapp The following resource(s) failed to create: [TimerSubmissionExpiration, ServiceWeb, ServiceWorker].
2019-04-27T20:03:44Z system/aws/cfm myapp-enterprise-myapp UPDATE_ROLLBACK_COMPLETE_CLEANUP_IN_PROGRESS myapp-enterprise-myapp
2019-04-27T20:03:44Z system/aws/cfm myapp-enterprise-myapp-TimerSubmissionExpiration-1KYAKENP9K7QD CREATE_IN_PROGRESS TaskDefinition
2019-04-27T20:03:45Z system/aws/cfm myapp-enterprise-myapp-TimerSubmissionExpiration-1KYAKENP9K7QD CREATE_IN_PROGRESS TaskDefinition Resource creation Initiated
2019-04-27T20:03:45Z system/aws/cfm myapp-enterprise-myapp-TimerSubmissionExpiration-1KYAKENP9K7QD CREATE_COMPLETE TaskDefinition
2019-04-27T20:03:46Z system/aws/cfm myapp-enterprise-myapp DELETE_COMPLETE ServiceWeb
2019-04-27T20:03:46Z system/aws/cfm myapp-enterprise-myapp DELETE_IN_PROGRESS RecordSetWebInternal
2019-04-27T20:03:46Z system/aws/cfm myapp-enterprise-myapp DELETE_IN_PROGRESS TimerSubmissionExpiration
2019-04-27T20:03:46Z system/aws/cfm myapp-enterprise-myapp DELETE_COMPLETE ServiceWorker
2019-04-27T20:03:46Z system/aws/cfm myapp-enterprise-myapp-TimerSubmissionExpiration-1KYAKENP9K7QD DELETE_IN_PROGRESS myapp-enterprise-myapp-TimerSubmissionExpiration-1KYAKENP9K7QD User Initiated
ERROR: rollback

My convox.yml:

services:
  web:
    ...
    scale:
      memory: 1024
      cpu: 512
      count: 0
      targets:
        cpu: 80
        memory: 90
        requests: 300

  worker:
    ...
    scale:
      memory: 1024
      cpu: 512
      count: 0
      targets:
        cpu: 80
        memory: 90

I guess something is going wrong with the AutoScaling for the first deploy, before any resources have been created. I guess I can remove the scale configuration on the first deployment, and then add it later. But it would be great if I didn’t need to do that.

Thanks!

2

Sorry, I forgot I was running this initial step with count: 0. The reason I do this is because the health check fails initially, because I haven’t set up the database yet. So I’ve been setting up the application with count: 0 to get a successful deployment, then running the database migrations, and then doing a final deployment to set the correct count and scaling options.

That explains the autoscaling error. I know this an edge case, but it would be nice to skip the autoscaling if count is set to 0. (I’m trying to automate a complete deployment with a single script.)

3

I was thinking that it might be useful if the convox.yml manifest could inherit from other manifests. My use case is having a convox.yml manifest with the main config, and a convox.initial.yml manifest that just overrides the scale section and sets count: 0, for the initial deploy. Maybe an extends: "<file"> option that you could put at the top.

Better Solution

But after thinking about it some more, I’ve found a much better solution.

My app uses the health_check gem for Rails, which provides some health check paths for different checks. If I make a GET request to /health, then it checks everything (Rails views, database connection, Redis, SMTP settings, sidekiq, etc.) But I can also request the /health/site path, so this only checks that the Rails app can boot, and views can render. This will return a successful response even if the database hasn’t been set up yet.

I’ve used dynamic configuration to make this health check path dynamic:

    health:
      path: ${HEALTH_CHECK_PATH}

During the initial setup, I set: HEALTH_CHECK_PATH=/health/site, and then I spin up all of the web containers successfully without worrying about the database.

Then I create the database and run the migrations. Finally, I run the following commands to upgrade the health check to a complete test:

convox env set --promote HEALTH_CHECK_PATH="/health"

So now I can script the entire setup process with a single convox.yml manifest. (This is incredibly useful for setting up temporary staging and dev environments.)

Hopefully this helps someone else!

1 Like