You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltacloud.apache.org by "Koper, Dies" <di...@fast.au.fujitsu.com> on 2012/03/08 22:56:46 UTC
using realms for vsys concept (FGCP driver implementation issue)
Hi,
I briefly discussed this topic with David on IRC and was advised to post
the question here to reach a wider audience and get more feedback.
I'm making a lot of progress with the FGCP implementation.
I am currently facing an issue that affects the implementation of
create_instance, firewalls, LBs and additional storage APIs.
With the FGCP, before creating nodes/LBs/additional storage, you have to
create a container called a virtual system ('vsys').
A vsys comes with a FW and helps to separate nodes into different
network segments (DMZ and optionally up to two SECURE segments).
The url below has an illustration of a vsys.
The nodes are placed in a DMZ (maybe for your web servers, fronted by a
LB) and secure zone (maybe your database). A FW connects the segments to
each other and the outside (if you add the FW rules to allow so). Users
can create as many vsys's as they like.
http://code.google.com/p/fgcp-client-api/
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.
Two further issues:
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. (*)
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.
(*)
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.
Any suggestions very welcome!
Cheers,
Dies Koper
RE: using realms for vsys concept (FGCP driver implementation issue)
Posted by "Koper, Dies" <di...@fast.au.fujitsu.com>.
Hi David,
> If we do that, what would the XML for realms look like ? I think we'd
With a flat structure:
<realms>
<realm href='http://localhost:3001/api/realms/vsys-a' id='vsys-a'>
<name>vsys-a</name>
<state>available</state>
</realm>
<realm href='http://localhost:3001/api/realms/vsys-a-DMZ'
id='vsys-a-DMZ'>
<name>vsys-a-DMZ</name>
<state>available</state>
<parent_id>vsys-a</parent_id>
</realm>
<realm href='http://localhost:3001/api/realms/vsys-a-SECURE1'
id='vsys-a-SECURE1'>
<name>vsys-a-DMZ</name>
<state>available</state>
<parent_id>vsys-a</parent_id>
</realm>
</realms>
The create_instance and create_loadbalancer operations would accept only
the latter two (the ones with a parent_id) while storage volumes would
accept any of the three.
Another (or additional) solution may be for the realm to have a scope
attribute (referring again to JClouds' Location) to describe what the
realm is scoped to:
<realms>
<realm href='http://localhost:3001/api/realms/vsys-a-DMZ'
id='vsys-a-DMZ'>
<name>vsys-a-DMZ</name>
<state>available</state>
<scope>network</scope>
</realm>
<realm href='http://localhost:3001/api/realms/vsys-a-SECURE1'
id='vsys-a-SECURE1'>
<name>vsys-a-DMZ</name>
<state>available</state>
<scope>network</scope>
</realm>
<realm href='http://localhost:3001/api/realms/vsys-a' id='vsys-a'>
<name>vsys-a</name>
<state>available</state>
<scope>system</scope>
</realm>
</realms>
The 'network' scope limits servers and LBs to that network realm. The
'system' scope (for lack of a better word, if provider specific values
are allowed 'system' or 'virtual system' would fit well for FGCP) limits
additional storage to that system (that set of instances).
On other providers, <scope> may be the complete 'provider', a single
'region' or a 'data centre' (=zone on EC2?).
What does the :limit attribute of Realms do btw? It's not well
documented and is set to :unlimited on most providers, 0 on EC2 if its
state is not 'available'.
> 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.
When creating a VSYS on FGCP, the network segments are created as part
of it:
The VSYS creation operation has two parameters, a (user picked) name and
VSYS descriptor id.
The id indicated the vsys template to base the vsys on. The template
defines the number of network tiers:
There is a vsys template for a 1 network tier skeleton, a 2 tier and a 3
tier.
So users can't create sub-realms on FGCP.
(The big advantage of vsys templates is that they can have images
assigned in their tiers. So one vsys creation action can give you a web
server in the DMZ, an application server in one secure network segment
and a database server instance in another).
I am not sure about the flags on Realm and if, and if so where, to have
an <actions> element with realm (vsys) create and delete operations.
Well, delete is trivial I suppose.
Cheers,
Dies Koper
> -----Original Message-----
> From: David Lutterkort [mailto:lutter@redhat.com]
> Sent: Tuesday, 13 March 2012 9:15 AM
> To: dev@deltacloud.apache.org
> Subject: RE: using realms for vsys concept (FGCP driver implementation
> issue)
>
> 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
> > >
> > >
> >
> >
>
>
>
RE: using realms for vsys concept (FGCP driver implementation issue)
Posted by David Lutterkort <lu...@redhat.com>.
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
> >
> >
>
>
RE: using realms for vsys concept (FGCP driver implementation issue)
Posted by "Koper, Dies" <di...@fast.au.fujitsu.com>.
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
>
>
Re: using realms for vsys concept (FGCP driver implementation issue)
Posted by David Lutterkort <lu...@redhat.com>.
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