puppetlabs-aws icon indicating copy to clipboard operation
puppetlabs-aws copied to clipboard

elb_loadbalancer resource creation error

Open brahman81 opened this issue 8 years ago • 2 comments
trafficstars

We have multiple VPC's and an ec2 Classic environment in our account.

When creating a new ELB resource I am getting a failure when processing instances that are in an EC2 Classic ELB.

Error: Could not run: Puppet detected a problem with the information returned from AWS
when looking up elb_loadbalancer in ap-south-1. The specific error was:

The instance IDs 'i-foo, i-bar' do not exist

Rather than report on elb_loadbalancer resources in an inconsistent state we have exited.
This could be because some other process is modifying AWS at the same time.

The resource is defined as follows:

elb_loadbalancer { 'elb-name':
  ensure                  => present,
  region                  => 'us-east-1',
  subnets                 => ['subnet-name'],
  security_groups         => ['security-group-name'],
  listeners               => [
    {
      protocol              => 'HTTP',
      load_balancer_port    => 80,
      instance_protocol     => 'HTTP',
      instance_port         => 80,
    }
  ],
  tags                    => {
    'cost-center' => 'website',
  },
}

Some more information:

puppet resource --modulepath extra_modules/ --debug --trace elb_loadbalancer
Debug: Runtime environment: puppet_version=4.10.3, ruby_version=2.1.9, run_mode=user, default_encoding=UTF-8
Debug: Evicting cache entry for environment 'production'
Debug: Caching environment 'production' (ttl = 0 sec)
Debug: Fetching ELB instances
Debug: Calling for ELB descriptions in ap-south-1
Debug: Calling for ELB descriptions in eu-west-2
Debug: Calling for ELB descriptions in eu-west-1
Debug: Calling for ELB descriptions in ap-northeast-2
Debug: Calling for ELB descriptions in ap-northeast-1
Debug: Calling for ELB descriptions in sa-east-1
Debug: Calling for ELB descriptions in ca-central-1
Debug: Calling for ELB descriptions in ap-southeast-1
Debug: Calling for ELB descriptions in ap-southeast-2
Debug: Calling for ELB descriptions in eu-central-1
Debug: Calling for ELB descriptions in us-east-1
Debug: Generating load_balancer hash for elb-in-ec2-classic
Debug: Calling ec2_client to resolve instances: ["i-foo", "i-bar"]
Error: Could not run: Puppet detected a problem with the information returned from AWS
when looking up elb_loadbalancer in ap-south-1. The specific error was:

The instance IDs 'i-foo, i-bar' do not exist

Rather than report on elb_loadbalancer resources in an inconsistent state we have exited.
This could be because some other process is modifying AWS at the same time.
/etc/puppetlabs/code/extra_modules/aws/lib/puppet/provider/elb_loadbalancer/v2.rb:28:in `rescue in block (2 levels) in instances'
/etc/puppetlabs/code/extra_modules/aws/lib/puppet/provider/elb_loadbalancer/v2.rb:15:in `block (2 levels) in instances'
/etc/puppetlabs/code/extra_modules/aws/lib/puppet/provider/elb_loadbalancer/v2.rb:47:in `block (2 levels) in elbs'
/etc/puppetlabs/code/extra_modules/aws/lib/puppet/provider/elb_loadbalancer/v2.rb:46:in `each'
/etc/puppetlabs/code/extra_modules/aws/lib/puppet/provider/elb_loadbalancer/v2.rb:46:in `block in elbs'
/etc/puppetlabs/code/extra_modules/aws/lib/puppet/provider/elb_loadbalancer/v2.rb:39:in `collect'
/etc/puppetlabs/code/extra_modules/aws/lib/puppet/provider/elb_loadbalancer/v2.rb:39:in `elbs'
/etc/puppetlabs/code/extra_modules/aws/lib/puppet/provider/elb_loadbalancer/v2.rb:13:in `block in instances'
/etc/puppetlabs/code/extra_modules/aws/lib/puppet/provider/elb_loadbalancer/v2.rb:11:in `collect'
/etc/puppetlabs/code/extra_modules/aws/lib/puppet/provider/elb_loadbalancer/v2.rb:11:in `instances'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type.rb:1170:in `block in instances'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type.rb:1163:in `collect'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type.rb:1163:in `instances'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/indirector/resource/ral.rb:24:in `search'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/indirector/indirection.rb:269:in `search'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application/resource.rb:221:in `find_or_save_resources'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application/resource.rb:136:in `main'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application.rb:366:in `run_command'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application.rb:358:in `block in run'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util.rb:542:in `exit_on_fail'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application.rb:358:in `run'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:132:in `run'
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:72:in `execute'
/opt/puppetlabs/puppet/bin/puppet:5:in `<main>'

This looks to me like it's failing to send the correct region when calling ec2_client when dealing with an EC2 classic ELB.

Happy to provide further details if required.

brahman81 avatar Nov 06 '17 18:11 brahman81

Looks like the issue is when iterating over each region to get the instances in the elbs. In my case, An instance list from us-east-1 gets sent to self.ec2_instance_names_from_ids with the wrong region (ap-south-1).

My temporary fix is to hardcode the region either in an env var or in the puppetlabs_aws_configuration.ini config. As detailed Hardcode Region...

brahman81 avatar Nov 07 '17 14:11 brahman81

I am also receiving this error but with a slightly different error message. No matter what I enter into the resource, it is looking for an unknown instance id in ap-south-1. I agree with the original poster that the code is somehow ignoring the region.

Error: Could not run: Puppet detected a problem with the information returned from AWS
when looking up elb_loadbalancer in ap-south-1. The specific error was:

The instance ID 'i-06ca2e39251fe6770' does not exist

Rather than report on elb_loadbalancer resources in an inconsistent state we have exited.
This could be because some other process is modifying AWS at the same time.

bdelamatre avatar Nov 14 '17 00:11 bdelamatre