deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Lutterkort <lut...@redhat.com>
Subject RE: using realms for vsys concept (FGCP driver implementation issue)
Date Mon, 12 Mar 2012 22:15:04 GMT
Hi Dies,

we could do that - I am not super excited about adding this sort of
hierarchy to realms, but don't see a better way to model vsys/network
either.

If we do that, what would the XML for realms look like ? I think we'd
need two additional flags on realms: one that indicates that it is
possible to create instances in a realm, and one that indicates whether
it is possible to create a sub-realm within an existing realm.

David

On Fri, 2012-03-09 at 12:15 +1100, Koper, Dies wrote:
> JClouds maps DeltaCloud Realms to a 'Location'. Locations have a
> 'parent' attribute: a Location can be a rack which is a child of a data
> centre (another Location instance), which is a child of a zone (another
> Location instance), which is a child of a provider (another Location
> instance).
> I wonder if such a structure could help us here:
> Network segments could be sub-realms of  vsys realms. This way a realm
> could be interpreted by the operation as applicable.
> 
> I'm not sure what 'realms' should return in this case: a flat list of
> parent and children realms, or only the children (with each child
> containing the id (and name?) of the parent)?
> 
> Cheers,
> Dies Koper
> 
> 
> > -----Original Message-----
> > From: David Lutterkort [mailto:lutter@redhat.com]
> > Sent: Friday, 9 March 2012 11:25 AM
> > To: dev@deltacloud.apache.org
> > Subject: Re: using realms for vsys concept (FGCP driver implementation
> > issue)
> > 
> > Hi Dies,
> > 
> > just very briefly some thoughts - would love to hear what others have
> to
> > say on the topic:
> > 
> > On Fri, 2012-03-09 at 08:56 +1100, Koper, Dies wrote:
> > 
> > > So my issue is, when the user adds a server instance or LB, they
> have to
> > > specify the id of the vsys they want to add it to. These resources
> are
> > > then scoped to that network segment; they can't move them to another
> > > vsys.
> > > So in that way it may fit the Realm concept.
> > 
> > I think realms is the closest we currently have in the API; so far,
> > we've only used featues to indicate optional additions to some calls
> > (like: you *can* pass user_data in when creating an instance), but for
> > some of the additional restrictions that FGPC poses, features might be
> > the right answer.
> > 
> > > 1. The above is not entirely correct: when the user creates a node
> or
> > > LB, they have to specify the network segment (i.e. id of vsys' DMZ
> or
> > > SECURE segment) it is to be added to, which is even more specific
> than
> > > the vsys. (*)
> > 
> > This is where a 'scoped_by_realm' feature on LB's might be the right
> way
> > to advertise to clients that something special is going on (assuming
> we
> > map vsys to realm)
> > 
> > > 2. Each vsys comes with a FW. There is no need to create it, and you
> > > cannot add any more: it has a one to one mapping to a vsys.
> > >     It has operations to add and delete rules and to do the NAT'ing
> of
> > > public IP addresses to nodes/LBs in the vsys.
> > >
> > > Should I consider mapping 'create_firewall' to FGCP's create-vsys
> API?
> > > Or introduce a realm creation operation? An additional snag for
> > > create_firewall is that FGCP's FW creation method does not include
> rule
> > > addition. You first need to create the FW, start it, and then you
> can
> > > add rules.
> > 
> > I think adding a 'create realm' operation would be cleaner. We'll need
> > to make sure that the OPTIONS request for realms indicates that realms
> > can be created, and that firewalls can not.
> > 
> > > So actually there are two concepts I need to map: vsys and network
> > > segment. The vsys id is required for adding additional storage
> volumes,
> > > while the network segment id is for adding instances and LBs.
> > > If we map network segments to Realms, that would work from an
> > > implementation point of view (as the driver can determine the vsys
> from
> > > the network segment id). But it may look confusing to the user that
> the
> > > API lets them add a volume to a network segment (even if it's called
> a
> > > Realm), e.g. vsys_a_dmz, and then see it appear in Realm
> vsys_a_secure1
> > > and vsys_a_secure2 as well.
> > 
> > Ugh .. that throws a big monkey-wrench into the whole vsys <-> realm
> > plan; what would we map networks to ? We _could_ map vsys to
> providers,
> > and network segments to realms, but that wouldn't let us add a clean
> > 'create vsys' operation.
> > 
> > Quite the pickle.
> > David
> > 
> > 
> 
> 




Mime
View raw message