Hi Nachi, Please see inline:
On Oct 8, 2013, at 10:42 AM, Nachi Ueno <na...@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 <rru...@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 <na...@ntti3.com> wrote: >> >>> 2013/10/4 Rudra Rugge <rru...@juniper.net>: >>>> Hi Nachi, >>>> >>>> Inline response >>>> >>>> On 10/4/13 12:54 PM, "Nachi Ueno" <na...@ntti3.com> wrote: >>>> >>>>> Hi Rudra >>>>> >>>>> inline responded >>>>> >>>>> 2013/10/4 Rudra Rugge <rru...@juniper.net>: >>>>>> Hi Nachi, >>>>>> >>>>>> Thanks for reviewing the BP. Please see inline: >>>>>> >>>>>> On 10/4/13 11:30 AM, "Nachi Ueno" <na...@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 <rru...@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 <rru...@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@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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev