Open Stack

Hi Rudra

2013/10/8 Rudra Rugge <rrugge at juniper.net>:
> 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]

so this is kind of id?

>> - "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.

Subnet.allocation_pools has range. so may be we should use this style.
http://docs.openstack.org/api/openstack-network/2.0/content/Concepts-d1e369.html#Network

[{"start":100, "end":200}, {"start":1000,"end":1200}

>
>> - 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.

This is BP.
https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering
We will have some IRC meeting after next neutron core meeting also.

Best
Nachi

>
>> 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
>>
>>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev