On Aug 9, 2012, at 4:11 AM, "Koper, Dies" <di...@fast.au.fujitsu.com> wrote:
> Hi David, Marios, > > Sounds like what we are already doing for FGCP: > Realms are network segments (e.g. 192.168.1.0/24, 192.168.2.0/24, etc.) > into which you create your instance. > I mapped network segment creation to the create_firewall operation as in > FGCP the segments are fronted by a firewall. > > Regards, > Dies Koper > > >> -----Original Message----- >> From: mar...@redhat.com [mailto:mandr...@redhat.com] >> Sent: Thursday, 9 August 2012 6:03 PM >> To: dev@deltacloud.apache.org >> Cc: David Lutterkort; James Labocki >> Subject: Re: Launching into a VPC with the EC2 driver >> >> On 09/08/12 01:23, David Lutterkort wrote: >>> Hi, >>> >>> there are some people who would like to be able to launch instances > into >>> a specific subnet attached to their VPC in EC2. In looking at how to > do >>> this without going down the rathole of supporting everything related > to >>> VPC's, this is the plan I've come up with. >>> >>> The assumption is that users will set up VPC's and subnets outside > of >>> DC. Once they have subnets, they will show up as realms with the EC2 >>> driver. IOW, GET /realms will not only list availability zones like >>> us-east-1a, but also subnets in those AZ's, i.e. realms that will be >>> named something like us-east-1c:subnet-deadbeef; when launching an >>> instance into such a realm, the create_instance call will pass the >>> subnetID to AWS' RunInstances, rather than an AZ. >> >> Sounds good: just did a bit of AWS API scraping (haven't looked at > this >> 'till just now): >> >> * to launch an instance into a specific vpc you need: >> ==> subnet ID (fine - subnets show up as realms according to the plan >> above) >> ==> a private IP address from the subnet cidr block (we can expose the >> cidr block in our description of subnet/realm) >> ==> security group ID - doable in the sense that vpc security groups > are >> just like 'normal' security groups (i.e. our firewall collection) > except >> they have a 'vpc ID' - so we can just add to the model and return vpc >> security groups in the 'normal' security groups list. We can even go >> further and allow creation of these - but user would need to 'know' >> out-of-band the vpc ID for to use for creation of the group >> >> * Could we consider a 'create realm' function? i.e. create a new > subnet. >> If we have create realm, create (vpc) security group, then that would >> leave just the creation of the vpc itself. I think you are suggesting creating and configuring the VPC via deltacloud, is that correct? The users I have spoken with are not interested in using deltacloud to configure the VPC, they will use the AWS management console at this point. It would be great if it could be designed to allow this functionality in the future or even abstracted to a higher level concept that could be applied more generically to clouds. >> >> Strictly speaking - Realm is probably a better (logical) 'match' for > VPC >> - except we don't yet have any networking models for covering the >> subnets - hence (I assume) your logic for realm<==>subnet as the 'best >> fit' right now. I agree, if there is a way to configure simple networks within a realm without the network actually being the realm it would be nice, but I'm not sure how much of a change that would require. >> >> >> marios >> >>> >>> any objections to this ? No objections, thanks David! >>> >>> David >>> >>> >> >> > >
