Hi, I think you are trying to use different IP allocation algorithm for a network based on some attribute of the network. network_type of the provider network specifies how layer2 network is segmented and ML2 type drivers are defined per network_type. I think it is different from your need.
IMO it looks better to introduce a new attribute to select IP allocation algorithm to "network" resource. The idea of Pluggable IP allocation algorithms exists for a long time in Neutron community but the progress is not good. Once pluggable mechanism is implemented, we need a way to map networks to IP allocation algorithms and this kind of new attribute is one possible choice. Thanks, Akihiro (2014/02/19 6:53), Sławek Kapłoński wrote: > Hello, > > Thanks for an answear. > I want to add own network type which will be very similiar to flat network (in > type_driver I think it will be the same) but will assign IPs to instances in > different way (not exactly with some L2 protocol). I want to add own network > because I want to have own name of this network that I can distinguish it. > Maybe there is other reason to do that. > > -- > Best regards > Sławek Kapłoński > > Dnia wtorek, 18 lutego 2014 10:08:50 piszesz: >> [Moving to -dev list] >> >> On Feb 18, 2014, at 9:12 AM, Sławek Kapłoński <sla...@kaplonski.pl> wrote: >>> Hello, >>> >>> I'm trying to make something with neutron and ML2 plugin. Now I need to >>> add my own external network type (as there are "Flat", "VLAN", "GRE" and >>> so on). I searched for manuals for that but I can't found anything. Can >>> someone of You explain me how I should do that? Is it enough to add own >>> type_driver and mechanism_driver to ML2? Or I should do something else >>> also? >> Hi Sławek: >> >> Can you explain more about what you’re looking to achieve here? I’m just >> curious how the existing TypeDrivers won’t cover your use case. ML2 was >> designed to remove segmentation management from the MechanismDrivers >> so they could all share segment types. Perhaps understanding what you’re >> trying to achieve would help better understand the approach to take here. >> >> Thanks, >> Kyle >> >>> Thanks in advance >>> -- >>> Sławek Kapłoński >>> sla...@kaplonski.pl >>> >>> _______________________________________________ >>> Mailing list: >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >>> Post to : openst...@lists.openstack.org >>> Unsubscribe : >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > _______________________________________________ > 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
