Hi Marios, > First impression is that I'd prefer to keep the separation between CIMI > and Deltacloud APIs - i.e. keep the Deltacloud drivers 'vanilla' API > with a mapping from what those return to the corresponding CIMI > entities. Furthermore, I don't see how a new method would help us here > since for a lot of cloud providers there is no API call which will > simply return the sum of all addresses that you own, whether public or > private, associated with a running vm or stand-alone. In other words > we'd still have to go down the route of: > > 1. Get the list of 'public' addresses - the 'stand-alone' ones that you > can query (like Elastic-IP addresses in EC2 for example) > 2. Query all instances and extract address information from those and > add it to the list from 1.
I suppose the new method would be mostly beneficial to FGCP, to lesser extend ROR and I don't know to what extend for other providers because of 2.: Querying all instances requires multiple calls to the backend (one to query the basic instance attributes, a separate one to retrieve the status, one for the initial password, one for the image's details (to know whether it's a Windows or unix machine, which determines whether the user name is administrator or root) and finally one to retrieve its public IP address. A new method could retrieve just the private IP addresses and add them to 1., without retrieving all the other instance attributes. > I say 'a lot of cloud providers' as I can't rule out the case of some > providers (FGCP?) allowing you to query ALL addresses as independent > entities (even 'private' addresses allocated to newly created VMs?). > Have you been able to survey the currently supported cloud provider APIs > to gain an understanding of what the case is here for the majority? For ROR and FGCP there is no API to query all addresses, I haven't checked other providers. > In other words, the 'AddressCollection' should only include those > addresses that are managed/created by the Consumer (i.e. with > 'allocation' attribute of 'dynamic') and not those created by the > Provider (i.e. 'allocation' ==> 'static') - since the latter are > transient, their lifecycle dependant on the resource to which they are > allocated (i.e. Machine). In fact, this last point IS made explicit in > the CIMI spec, 5.16.3 "Address": I think you make a good point. It's late now, I need a day to let it sink in. Regards, Dies Koper > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Wednesday, 12 June 2013 6:30 PM > To: [email protected] > Cc: Koper, Dies > Subject: Re: including private addresses in CIMI address collection > > On 11/06/13 14:47, Koper, Dies wrote: > > Hi Marios, Michal, > > > > Maybe this should belong in a JIRA, but as it's down.. > > > > Currently we are mapping CIMI addresses to DC addresses. > > DC addresses I believe only contain public IP addresses (publicly > > routable). > > Deltacloud: 2 Address related models: > > > /lib/deltacloud/models/address.rb > --> has 'id' and 'instance_id' attributes - 'id' is actually the IP > address and 'instance_id' is used to capture the association to an > instance, if any > > > /lib/deltacloud/models/instance_address.rb > --> 'address', 'port' and 'address_type' attributes - where > 'address_type' can be :mac | :ipv4 | :ipv6 | :hostname > > InstanceAddress only exists as part of an Instance - in which case it > is > assigned to the Instance 'public_address' or 'private_address' attribute > dependant on the information returned from the cloud provider. > > > According to CIMI, machines have network interfaces which have > > addresses. > > So if network interfaces have private (not publicly routable) IP > > addresses, we need to include them in the CIMI address collection, > > right? > > Yes, this sounds like what we'd have to do - but more on this in the > final note below. > > > > > We could implement this in two ways: > > If we want to map CIMI addresses to existing DC collections, we'd have > > to traverse through all instances and add the private IP addresses to > > the DC addresses collection. > > More efficient may be a new method in the drivers that directly builds > a > > collection of CIMI:Model:Address instances with both public and private > > IP addresses. Any suggestion for what that method could be called? > > > > > First impression is that I'd prefer to keep the separation between CIMI > and Deltacloud APIs - i.e. keep the Deltacloud drivers 'vanilla' API > with a mapping from what those return to the corresponding CIMI > entities. Furthermore, I don't see how a new method would help us here > since for a lot of cloud providers there is no API call which will > simply return the sum of all addresses that you own, whether public or > private, associated with a running vm or stand-alone. In other words > we'd still have to go down the route of: > > 1. Get the list of 'public' addresses - the 'stand-alone' ones that you > can query (like Elastic-IP addresses in EC2 for example) > 2. Query all instances and extract address information from those and > add it to the list from 1. > > I say 'a lot of cloud providers' as I can't rule out the case of some > providers (FGCP?) allowing you to query ALL addresses as independent > entities (even 'private' addresses allocated to newly created VMs?). > Have you been able to survey the currently supported cloud provider APIs > to gain an understanding of what the case is here for the majority? > > As a final note - I wonder if we need to revisit or at least discuss the > 'AddressCollection' with a mantis issue; if it is the case that most > providers out there don't report 'instance addresses' as part of the > global 'address collection' then perhaps we need to do the same in CIMI. > > In other words, the 'AddressCollection' should only include those > addresses that are managed/created by the Consumer (i.e. with > 'allocation' attribute of 'dynamic') and not those created by the > Provider (i.e. 'allocation' ==> 'static') - since the latter are > transient, their lifecycle dependant on the resource to which they are > allocated (i.e. Machine). In fact, this last point IS made explicit in > the CIMI spec, 5.16.3 "Address": > > "Addresses that are created by Providers on the Consumer's behalf shall > be deleted at the Provider's discretion. In particular, the Provider > shall delete Addresses that it created on behalf of the Consumer when > the resource that is using that Address is deleted or when the Address > becomes disassociated from the resource" > > marios > > > Regards, > > Dies Koper > > > > >
