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:[email protected]] > Sent: Friday, 9 March 2012 11:25 AM > To: [email protected] > 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 > >
