Open Stack

Hi Nachi,

Please see inline:

On Oct 8, 2013, at 10:42 AM, Nachi Ueno <nachi at ntti3.com> wrote:

> Hi Rudra
> 
> Thanks!
> 
> Some questions and comments
> 
> -  name and fq_name
> How we use name and fq_name ?
> IMO, we should prevent to use shorten name.
> 
[Rudra] 'name' meets all the current Neutron models like (network, subnet, etc). 
'fq_name' is a free string added for plugins to use in their own context. fq_name
hierarchy could be different in each plugin.
Example: 
name: test_policy
fq_name: [default-domain:test-project:test_policy]
while a different plugin may use it as
fq_name: [test-project:test_policy]

> - "src_ports": ["80-80"],
> For API consistency, we should use similar way of the security groups
> http://docs.openstack.org/api/openstack-network/2.0/content/POST_createSecGroupRule__security-group-rules_security-groups-ext.html
> 
[Rudra] This is a list of start and end ports. If source port ranges to be allowed 
are [100-200] and [1000-1200]. Security groups support only a single range.


> - PolicyRuleCreate
> Could you add more example if the action contains services.
> 
> "action_list": ["simple_action-pass"],
[Rudra] Will update the spec with more examples.

> 
> This spec is related with service framework discussion also.
> so I wanna know the detail and different with service framework.
> 
[Rudra] Could you please point me to the service framework spec/discussion. Thanks.


> it is also helpful if we could have full list of examples.
[Rudra] Will add more examples.

Cheers,
Rudra

> 
> Best
> Nachi
> 
> 
> 
> 
> 
> 2013/10/7 Rudra Rugge <rrugge at juniper.net>:
>> Hi Nachi,
>> 
>> I have split the spec for policy and VPN wiki served as a good reference point. Please review and provide comments:
>> https://wiki.openstack.org/wiki/Blueprint-policy-extensions-for-neutron
>> 
>> Thanks,
>> Rudra
>> 
>> On Oct 4, 2013, at 4:56 PM, Nachi Ueno <nachi at ntti3.com> wrote:
>> 
>>> 2013/10/4 Rudra Rugge <rrugge at juniper.net>:
>>>> Hi Nachi,
>>>> 
>>>> Inline response
>>>> 
>>>> On 10/4/13 12:54 PM, "Nachi Ueno" <nachi at ntti3.com> wrote:
>>>> 
>>>>> Hi Rudra
>>>>> 
>>>>> inline responded
>>>>> 
>>>>> 2013/10/4 Rudra Rugge <rrugge at juniper.net>:
>>>>>> Hi Nachi,
>>>>>> 
>>>>>> Thanks for reviewing the BP. Please see inline:
>>>>>> 
>>>>>> On 10/4/13 11:30 AM, "Nachi Ueno" <nachi at ntti3.com> wrote:
>>>>>> 
>>>>>>> Hi Rudra
>>>>>>> 
>>>>>>> Two comment from me
>>>>>>> 
>>>>>>> (1) IPAM and Network policy extension looks like independent extension.
>>>>>>> so IPAM part and Network policy should be divided for two blueprints.
>>>>>> 
>>>>>> [Rudra] I agree that these need to be split into two blueprints. I will
>>>>>> create another BP.
>>>>> 
>>>>> Thanks
>>>>> 
>>>>>>> 
>>>>>>> (2) The team IPAM is too general word. IMO we should use more specific
>>>>>>> word.
>>>>>>> How about SubnetGroup?
>>>>>> 
>>>>>> [Rudra] IPAM holds more information.
>>>>>>       - All DHCP attributes for this IPAM subnet
>>>>>>       - DNS server configuration
>>>>>>       - In future address allocation schemes
>>>>> 
>>>>> Actually, Neutron Subnet has dhcp, DNS, ip allocation schemes.
>>>>> If I understand your proposal correct, IPAM is a group of subnets
>>>>> for of which shares common parameters.
>>>>> Also, you can propose to extend existing subnet.
>>>> 
>>>> [Rudra] Neutron subnet requires a network as I understand. IPAM info
>>>> should not have such dependency. Similar to Amazon VPC model where all
>>>> IPAM information can be stored even if a a network is not created.
>>>> Association to networks can happen at a later time.
>>> 
>>> OK I got it. However IPAM is still too general word.
>>> Don't you have any alternatives?
>>> 
>>> Best
>>> Nachi
>>> 
>>>> Rudra
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>>>> 
>>>>>>> (3) Network Policy Resource
>>>>>>> I would like to know more details of this api
>>>>>>> 
>>>>>>> I would like to know resource definition and
>>>>>>> sample API request and response json.
>>>>>>> 
>>>>>>> (This is one example
>>>>>>> https://wiki.openstack.org/wiki/Quantum/VPNaaS )
>>>>>>> 
>>>>>>> Especially, I'm interested in src-addresses, dst-addresses, action-list
>>>>>>> properties.
>>>>>>> Also, how can we express any port in your API?
>>>>>> 
>>>>>> [Rudra] Will add the details of the resources and APIs after separating
>>>>>> the blueprint.
>>>>> 
>>>>> Thanks!
>>>>> 
>>>>> Best
>>>>> Nachi
>>>>> 
>>>>>> Regards,
>>>>>> Rudra
>>>>>> 
>>>>>>> 
>>>>>>> Best
>>>>>>> Nachi
>>>>>>> 
>>>>>>> 
>>>>>>> 2013/10/4 Rudra Rugge <rrugge at juniper.net>:
>>>>>>>> Hi All,
>>>>>>>> 
>>>>>>>> The link in the email was incorrect. Please follow the following link:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> https://blueprints.launchpad.net/neutron/+spec/ipam-policy-extensions-f
>>>>>>>> or
>>>>>>>> -neutron
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Rudra
>>>>>>>> 
>>>>>>>> On Oct 3, 2013, at 11:38 AM, Rudra Rugge <rrugge at juniper.net> wrote:
>>>>>>>> 
>>>>>>>> Hi All,
>>>>>>>> 
>>>>>>>> A blueprint has been registered to add IPAM and Policy
>>>>>>>> extensions to Neutron. Please review the blueprint and
>>>>>>>> the attached specification.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> https://blueprints.launchpad.net/neutron/+spec/juniper-contrail-ipam-po
>>>>>>>> li
>>>>>>>> cy-extensions-for-neutron
>>>>>>>> 
>>>>>>>> All comments are welcome.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Rudra
>>>>>>>> _______________________________________________
>>>>>>>> OpenStack-dev mailing list
>>>>>>>> OpenStack-dev at lists.openstack.org
>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> OpenStack-dev mailing list
>>>>>>>> OpenStack-dev at lists.openstack.org
>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> OpenStack-dev mailing list
>>>>>>> OpenStack-dev at lists.openstack.org
>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> OpenStack-dev mailing list
>>>>>> OpenStack-dev at lists.openstack.org
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>> 
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
>