Description of problem:
Customers want to be able to extend their private cloud into a public cloud without compromising their privacy. Public clouds like Amazon support extending a private subnet into the public cloud using Virtual Private Cloud (VPC).
"Amazon Virtual Private Cloud enables you to create a virtual network in the AWS cloud."
VPC allows you to create a gateway to your own private network, e.g. private cloud, and hence extend your private cloud.
The ability to take advantage of this feature is a most have for some customers.
There are several user scenarios for VPC but one for large enterprises is extending a private network to the public cloud using VPC.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
This is currently being tracked as a feature request for a future release.
This is a requirement for at least one customer in order that they would use the product.
Just confirming this is on a products requirement doc
This sounds like a dandy feature. It's rather outside the bounds of what we currently view as audrey.
In terms of handling situations like your customer with the immediate need, we'd have to know more about the details of what they want, in order to assess it, but our goal has been to accomodate things like this by allowing users and/or SAs to write whatever scripts they need to set up things like vpns/vpcs, and then allow for driving those scripts with audrey.
I believe that it continues to be a project/product goal to do a more comprehensive job of managing that stuff. That will involve many components, probably including audrey, and won't happen until post 1.0.
I'm reassigning this to gblomquis for further comment, but I expect this will end up on the backlog for later.
So, most specifically for AWS, what's needed is to be able to pass the
"SubnetId" and "SecurityGroupId" attributes, and potentially
"PrivateIpAddress" to EC2's RunInstances() service:
Even if the user needs to enter in multiple mappings for the same
availability zone in the provider in order to get granularity they need
around launching instances with the right security and subnet
characteristics, that's better than not supporting this functionality at
all - it makes Aeolus a non-starter in supporting launching of instances
in a VPC or with a non-default security group.
making sure all the bugs are at the right version for future queries
Because this involves the call to RunInstances, I believe this would have to be done at the deltacloud ec2 driver level (Ec2Driver#create_instance).
I don't have a good idea of how we would make this information available to deltacloud (i.e., would the information specifying the need to be in a VPC originate in the deployableXML?). I also don't have a good idea for how we would make this generic enough to be in deltacloud (i.e., if this was specified in the deployableXML, how would this be interpreted for RHEV? V-Sphere?)
can you decide who actually owns this bug? I think it's a deltacloud issue.
adding to sprint tracker
Updating version to 1.0 (found in version)
Adding cloudforms-1.1? flag (replacing original version setting)
Mitch is to assess the level of customer demand for this feature.
Aeolus Config Server is end-of-life. This will never be implemented.