deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "marios@redhat.com" <mandr...@redhat.com>
Subject Re: including private addresses in CIMI address collection
Date Wed, 12 Jun 2013 08:29:47 GMT
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
> 
> 


Mime
View raw message