Open Stack

Hi Ivar, Thanks for bringing this up and my apologies for the late
response (although I noticed that you already provided a fix, so
thankfully you were not blocked ;-)). As discussed during the GBP IRC
meeting, my suggestion would also be to use the first option, and
create the service chain instances as admin. I agree that ideally it
would be nice for the users to at least be able to see the created
service chain instances, but that might require some kind of resource
level access control. We should deal with it as a separate
enhancement/feature.

Thanks,
~Sumit.



On Thu, Mar 19, 2015 at 3:13 PM, Ivar Lazzaro <ivarlazzaro at gmail.com> wrote:
> 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>