Can't get a public IP

[odedpriva]

I'm starting the instance while mentioning a subnet_id in my kitchen.yml file.
on AWS management console I see that the instance was initialized using the proper subnet, but it didn't received an external IP.

the driver is trying to login on the internal IP ( this can be considered as a bug? )
.......... (server ready)
Waiting for 10.0.0.64:22...
Waiting for 10.0.0.64:22...
Waiting for 10.0.0.64:22...
Waiting for 10.0.0.64:22...

Am I'm missing something?

[sogos]

Is your subnet is configured to auto allocate a public IP ?
Le 5 oct. 2014 21:37, "Oded Priva" [email protected] a écrit :

I'm starting the instance while mentioning a subnet_id in my kitchen.yml
file.
on AWS management console I see that the instance was initialized using
the proper subnet, but it didn't received an external IP.

the driver is trying to login on the internal IP ( this can be considered
as a bug? )
.......... (server ready)
Waiting for 10.0.0.64:22...
Waiting for 10.0.0.64:22...
Waiting for 10.0.0.64:22...
Waiting for 10.0.0.64:22...

Am I'm missing something?

—
Reply to this email directly or view it on GitHub
#72.

[odedpriva]

No ..

Can I still get a public IP ?
Changing the default behavior to auto allocate a public IP is against our security policy ..

[sogos]

I think there is an option, yes
Le 5 oct. 2014 22:10, "Oded Priva" [email protected] a écrit :

No ..

Can I still get a public IP ?
Changing the default behavior to auto allocate a public IP is against our
security policy ..

—
Reply to this email directly or view it on GitHub
#72 (comment)
.

[sogos]

associate_public_ip: true
or specify your subnet_id

[squirvoid]

I seem to be having an issue as well with an instance being created without a public IP address using 0.8.0. I had to enable the subnet's auto-assign public IP address to use the EC2 driver.

driver:
  name: ec2
  associate_public_ip: true
  availability_zone: us-east-1a
  aws_ssh_key_id: blah
  username: ubuntu
  image_id: ami-9aaa1cf2
  flavor_id: t2.micro
  region: us-east-1
  security_group_ids:
    - sg-blah1
    - sg-blah2
  ssh_key: <%= File.expand_path('~/.ssh/blah.pem') %>
  subnet_id: subnet-blahblah
  tags: 
    Name: "test kitchen"

[3gcodes]

I'm having the same problem. I've specified the subnet_id although ours are not set to create public IP be default so I also set associate_public_ip: true. It does not associate a public IP.

[dtoubelis]

I can confirm that associate_public_ip: true has no effect when subnet option is specified. I think it internally requires a different API call in order to set it for the subnet. This is a showstopper for us as we cannot use this driver with amazon cloud for the moment.

[Fantus]

+1 would be really nice if "associate_public_ip" would work as expected

[integrid]

+1

[dtan4]

I'm having the same problem at edge version (abc4115)...
+1

[iiro]

+1

Same problem here...

[toddmichael]

+1 - running into this as well. thanks.

[pushent]

+1 same issue

[pushent]

oh - if your corporate security policy does allow it, the AWS subnet config item "Enable Auto-assign Public IP " will give you a workaround for now (tested):

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-ip-addressing.html#subnet-public-ip

[senilegenius]

+1 I also cannot get kitchen-ec2 to create a public IP.
I'm specifying subnet_id and don't get a public IP when setting "associate_public_ip: true" or when not setting associate_public_ip at all in my .kitchen.yml.
Anyone know of a fork that has implemented this? Not sure where to start looking to fix.

[dsavinkov]

Agree with @pushent. I think this is not an issue. I had the same kind of problem before, so in addition to associate_public_ip: true .kitchen.yml parameter - make sure your EC2 Subnet network config has Auto-assign Public IP:yes.

[squirvoid]

@dsavinkov I'm not sure the point of the feature then? Is it only to prevent an IP address from being assigned when auto-assign is on? It's perfectly normal to assign a public IP to a subnet where the auto-assign is off. I imagine that in subnets the auto-assign is generally off but it's useful to override that for a test environment when being able to connect to the instance directly and debug is useful.

[dtoubelis]

@dsavinkov It is always an issue when something is not working as intended. The associate_public_ip feature should either be removed or implemented properly.

[dsavinkov]

@squirvoid I believe all kitchen attributes should be "atomic" in terms of utilizing AWS API. By doing several things with one parameter configuration in general is getting blurred. On the other side I would agree with @dtoubelis that it might be better to reimplement/introduce parameter to control these kind of situations. AWS cli should be golden source of truth :)

[tyler-ball]

In the latest release of kitchen-ec2 (0.9.0) I updated to use the latest AWS SDK. As part of this, if you specify associate_public_ip_address: true that gets sent in the instance request tagged to the first network device. Will you see if that allows you to specify a public ip even if the subnet is not configured to do that?

[dsavinkov]

@tyler-ball that's great! I will try it out.

[dsavinkov]

Environment:

Dmitry-mbp:test ds$ chef gem list kitchen

*** LOCAL GEMS ***

kitchen-ec2 (0.9.0)
kitchen-vagrant (0.18.0)
test-kitchen (1.4.0)

in .kitchen.yml

subnet_id: subnet-XXXXXXXX  # auto-assign public IP = false
associate_public_ip_address: true   

During converging I get the following:

Dmitry-mbp:test ds$ kitchen converge test-machine
-----> Starting Kitchen (v1.4.0)
-----> Creating <test-machine>...
       Creating <>...
If you are not using an account that qualifies under the AWS
free-tier, you may be charged to run these suites. The charge
should be minimal, but neither Test Kitchen nor its maintainers
are responsible for your incurred costs.

>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: Failed to complete #create action: [Network interfaces and an instance-level subnet ID may not be specified on the same request]
>>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration
Dmitry-mbp:test ds$ 

@tyler-ball
According to this AWS CLI issue we can make it work if we can explicitly specify --network-interfaces and their settings.

[litjoco]

While reading through this discussion I would like to know if the associate_public_ip_address: replaces the associate_public_ip setting?
Or are these intended to serve different functions?
thank you

[yoshiwaan]

I get the same as @dsavinkov when using associate_public_ip_address.

When using the actual CLI to make an instance in a VPC, to get a public IP address a network interface needs to be defined and the subnet id that interface is created in defined as a part of that interface. You then must not specify the subnet id when creating the ec2 instance as the associated interface is used as well. The same is the case when using a CloudFormation template.

In terms of the code I would make it always define an interface if a subnet id is specified and let the associate_public_ip_address option decide if it should get an internet IP or not (the interface accepts this as true/false)

@litjoco I think this must be a typo in the help as associate_public_ip didn't seem to do anything. I would guess associate_public_ip_address is the correct entry.

[tyler-ball]

Oops! I introduced a regression when I changed it from associate_public_ip to associate_public_ip_address. I'm working on a PR now for that and I'll release a patch release with that fix.

I'm also looking into what happens if a subnet has auto assign public ip disabled and the user specifies associate_public_ip.

[dsavinkov]

@tyler-ball
It's never timing out. associate_public_ip: true and subnet_id has assign public ip disabled

...
Waited 30/300s for instance <i-XXXXXXXX> to become ready.
EC2 instance <i-XXXXXXXX> ready.
Waiting for SSH service on :22, retrying in 3 seconds
Waiting for SSH service on :22, retrying in 3 seconds
Waiting for SSH service on :22, retrying in 3 seconds
...

[tyler-ball]

@dsavinkov can you try my branch from #125 and see if it fixes your issue? It worked locally for me with a subnet that had public IP assignment disabled. I also fixed the config key name change that I accidently introduced.

[dsavinkov]

@tyler-ball
So I installed kitchen-ec2 from git tball/other_errors branch.

Dmitry-mbp:test ds$ chef gem list kitchen-ec2
*** LOCAL GEMS ***
kitchen-ec2 (0.10.0.dev.0)

1. kitchen.yml config:

...
subnet_id: subnet-XXXXXXXX # auto-assign IP = false OR even auto-assign IP = true
associate_public_ip: true
...

Output:

>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: Failed to complete #create action: [Network interfaces and an instance-level security groups may not be specified on the same request]
>>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration

2.With just subnet-id parameter:

...
subnet_id: subnet-XXXXXXXX # auto-assign IP = true 
...

I am running into connection timeout issue:

Waiting for SSH service on ec2-xx-xx-xx-xxx.xx-xxxx-x.compute.amazonaws.com:22, retrying in 3 seconds

I must be doing smth wrong. Let's wait for feedback from other folks..
/cc @yoshiwaan @litjoco @dtoubelis

[tyler-ball]

@dsavinkov Can you gist the output of your kitchen diagnose? And then add a require 'pry'; binding.pry statement right before instance_generator.rb line 73, and put the contents of the i variable into the gist? With associate_public_ip: true it should look something like

:placement => { :availability_zone => "eu-west-1a" },
:instance_type => "micro",
...,
:network_interfaces => [{
  :device_index => 0,
  :associate_public_ip_address => true,
  :subnet_id => "s-456"
}]

Specifically, :subnet_id should only be inside the :network_interfaces array.