Hi Subra,
On Sun, Dec 15, 2013 at 9:32 PM, Subrahmanyam Ongole <osm...@gmail.com> wrote:
> Hi Stephan
>
> Comments inline for redirect action. Perhaps we may want to discuss each
> section in different email threads.
>
>
> On Sun, Dec 15, 2013 at 8:49 AM, Stephen Wong <s3w...@midokura.com> wrote:
>>
>> Hi,
>>
>> During Thursday's group-policy meeting[1], there are several
>> policy-rules related issues which we agreed should be posted on the
>> mailing list to gather community comments / consensus. They are:
>>
>>
>>
>>
>> (3) Prasad asked for clarification on 'redirect' action, I propose to
>> add the following text to document regarding 'redirect' action:
>>
>> "'redirect' action is used to mirror traffic to other destinations
>> - destination can be another endpoint group, a service chain, a port,
>> or a network. Note that 'redirect' action type can be used with other
>> forwarding related action type such as 'security'; therefore, it is
>> entirely possible that one can specify {'security':'deny'} and still
>> do {'redirect':{'uuid-1', 'uuid-2'...}. Note that the destination
>> specified on the list CANNOT be the endpoint-group who provides this
>> policy. Also, in case of destination being another endpoint-group, the
>> policy of this new destination endpoint-group will still be applied"
>>
>> Please discuss.
>>
>
> a. In Neutron, I am not sure whether there is a way to get an object given a
> UUID without knowing the type of the object, be it a port, network or a
> specific type of Neutron service.
>
> I am less likely to err if uuid is qualified by a type or some human
> readable name.
Excellent point. I will add a type field for each redirect object.
Thanks for pointing it out.
>
> b. Is chain definition (how you build a chain of services) within the scope
> of Global policy BP? A chain may need to be more than an ordered list of
> UUIDs. It needs be a graph with branches anywhere in the chain. Each path
> could be considered as a separate chain as well.
Service chain as defined by the following:
https://docs.google.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit#
which is a Neutron object (service_graph is encapsulated inside
this object; see service_chain resource).
Thanks,
- Stephen
>
> Thanks
> Subra
>
>>
>>
>> I will gather all the feedback by Wednesday and update the
>> document before this coming Thursday's meeting.
>>
>> Thanks,
>> - Stephen
>>
>> [1]
>> http://eavesdrop.openstack.org/meetings/networking_policy/2013/networking_policy.2013-12-12-16.01.log.html
>> [2]
>> https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#heading=h.x1h06xqhlo1n
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
