[openstack-dev] [Group-Based-Policy] Service Chain Instance ownership

Ivar Lazzaro ivarlazzaro at gmail.com
Thu Mar 19 22:13:57 UTC 2015


Hello Folks,

[tl;dr]

On implicit chains, the Service Chain Instance ownership in GBP is
inconsistent, depending on the actor triggering the chain. Possible
solution is to have all the implicit SCI owned by an admin, or by the
provider of the chain. Any suggestion is welcome.

[boringpostwithexampleandstuff]

I've recently file a bug [0] regarding Service Chain Instance ownership,
and I would like to get some advice on how to proceed with it.

Let's take the following final state as an example:

PTG-A --->PRS-Chain--->PTG-B

PTG A is providing a PRS with a redirect action, which is consumed by
PTG-B. Reaching this state triggers an implicit SCI creation based on the
policy action.
The above state can be reached in multiple ways, some of them are:

- PTG-A provides PRS-Chain (which is already consumed by PTG-B);
- PTG-B consumes PRS-Chain (which is already provided by PTG-A);
- Redirect action is added to PRS-Chain (which is already provided and
consumed).

Depending on how that state is reached, in today's implementation the
tenant owning the SCI may be ultimately different! This is definitively a
problem, especially when PTG-A and PTG-B are owned by different tenants.
If having inconsistent behavior on the same state isn't bad enough, another
issue is that whoever triggers the SCI deletion should also own the SCI or
will get an exception! And this is definitively not part of the intent.
In short, we need to decide who has to own the chain instances (and with
them, the network services themselves). There are two main choices:

- An Admin owns them all. This will not impact the users' quota, and makes
it easier to bridge different tenants' networks (when needed/applicable).
The downside (?) is that the user will never see the SCI and will never be
able to control the services without admin permissions;

- The Provider is always the owner. This solution is trickier as far as
quota are concerned, especially when the services are created using VMs
(NFV). does the provider need to care about that? why has my VM limit
suddenly dropped to 0 now that I'm providing this cursed PRS? On the
upside, the provider can control and modify the service itself if he needs
to.

I personally am a fan of the first option, the user should only care about
the Intent, and not about this kind of details. But I would like to have
some insight from the community, especially from other projects that may
have had this issue and can *provide* (ahah) a bit of their wisdom :)

Thanks,
Ivar.

[0] https://bugs.launchpad.net/group-based-policy/+bug/1432816
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150319/ad70c876/attachment.html>


More information about the OpenStack-dev mailing list