Can't specify security groups in AWS vm_types

[mtekel]

In new cloud config for AWS, in vm_types, security_groups in cloud_properties are ignored. Other settings like iam_instance_profile or elbs are read and applied correctly. Nevertheless, when you do specify security_groups under a network definition in networks, they are read and applied correctly.

This means that to apply security groups to some VMs, you need to create artificial network definition (along everything that this brings - e.g. ensuring separate address ranges). It would be better if security_groups definition worked under vm_types - like it is documented:
https://bosh.io/docs/cloud-config.html#vm-types - "CPI specific" link for AWS links to https://bosh.io/docs/aws-cpi.html#resource-pools .

Resource pools do support specifying security groups (added in cloudfoundry/bosh-aws-cpi-release#28), but it seems the same feature is missing when using vm_types & cloud config.

BOSH version 255.8

[cppforlife]

are using aws cpi 46+?

Sent from my iPhone

On May 3, 2016, at 8:27 AM, mtekel [email protected] wrote:

In new cloud config for AWS, in vm_types, security_groups in cloud_properties are ignored. Other settings like iam_instance_profile or elbs are read and applied correctly. Nevertheless, when you do specify security_groups under a network definition in networks, they are read and applied correctly.

This means that to apply security groups to some VMs, you need to create artificial network definition (along everything that this brings - e.g. ensuring separate address ranges). It would be better if security_groups definition worked under vm_types - like it is documented:
https://bosh.io/docs/cloud-config.html#vm-types - "CPI specific" link for AWS links to https://bosh.io/docs/aws-cpi.html#resource-pools .

Resource pools do support specifying security groups (added in cloudfoundry/bosh-aws-cpi-release#28), but it seems the same feature is missing when using vm_types & cloud config.

BOSH version 255.8

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[mtekel]

We used 44. I guess that explains it...