Re: Adding security groups in resource_pools instead of networks


Marco Voelz
 

Dear Dmitriy,

thanks for the quick reply. See my response inline.

On 10/09/15 05:07, "Dmitriy Kalinin" <dkalinin(a)pivotal.io<mailto:dkalinin(a)pivotal.io>> wrote:

It's a bit unclear to me if you are proposing to security groups feature in the Director or in the OpenStack CPI specifically.

If in the OpenStack CPI, then I think it makes sense to pull in security groups config into resource pool's cloud_properties section. For example:

resource_pools:
- name: my-fancy-web
stemcell: { ... }
cloud_properties:
instance_type: m3.xlarge
security_groups: [web]

- name: my-fancy-worker
stemcell: { ... }
cloud_properties:
instance_type: m3.xlarge
security_groups: [worker]

This is exactly what I’m proposing to have. Add the feature to the Openstack CPI to specify security groups in resource_pools like in your example above.

will assign web to VMs of type my-fancy-web and worker to VMs of type my-fancy-worker. When resource pool's cloud_properties are changed, VMs will be recreated with new config. Like you point out there is a case of configure_networks, imho we can just raise an error in create_vm if both networks' cloud_properties specifies security groups and resource pool cp's specifies security_groups.

Throwing an error when security groups are specified in resource_pools as well as in networks seems like a great pragmatic solution, thanks. The problems with configure_networks still remain, though – see below.

If you are proposing changes in the Director, then I think it gets a bit more complicated. I'm not sure we have enough good usage patterns to figure out a good abstraction *yet* (e.g. Azure has two different types of security groups: network and vm, which imho makes a lot of sense).

I was just mentioning some changes in the director coding to resolve the configure_networks problem: This method needs some knowledge about the security groups defined by the resource_pool. Otherwise it will just remove those when it is called. Therefore, I wanted to add another parameter for the resource_pool security groups. If it makes sense to pull them out further across CPIs, we could do that. But from your comments about the Azure CPI I gather that this might be more work than I thought. So I will stick to adding a parameter for the Openstack CPI API then. Or is there another option I’m missing here?

Also if it's becoming a first class feature, may be BOSH at this point should be creating security groups automatically with certain rules and may be even with links generating these rules dynamically, etc.

This is actually true for a lot of things. If you take it to the extreme, bosh should be able to take templates e.g. from Heat or CloudFormation and set up my landscape before deploying things. But that might take it too far for now :)

Btw we are currently implementing first class support for AZs + links in the Director, so all of the bosh-director core classes are going through significant changes on global-net branch. Related to that I am actually thinking we split up resource pool config into two pieces: vm type and stemcell. With recent cloud config changes it would make it more sense to keep stemcell os/version in the deployment manifest (just like releases) and vm type with iaas specifics in the cloud config file.

I think it makes a lot of sense to keep the stemcell information in the manifest – the different things which get deployed might have their own lifecycle of adoption – although I would wish otherwise. The security group information would definitely be something which is specific to a deployment, so at least something specific to the resource_pools should remain in the release’s manifest.

Warm regards
Marco

Join cf-bosh@lists.cloudfoundry.org to automatically receive all group messages.