I don't feel too strongly either way. It seems like mechanism drivers will have distinct sets of variables, so having a common subsection name may be confusing. Plus I like the clarity of the type of the mechanism driver being in the section name rather than hidden in a type name.
Maybe we prepend ML2_MECH to that to make it clear that these are variables for mechanism drivers? Something like: [ML2_MECH_CISCO_NEXUS:<ipaddr> ... [ML2_MECH_ARISTA:<ipaddr>] ... As I said before, am fine with either of the proposals below too. Andre On Wed, Jun 19, 2013 at 8:59 AM, Rich Curran (rcurran) <[email protected]>wrote: > Hi All –**** > > ** ** > > Regarding the configuration (ml2_conf.ini) of mechanism devices. Cisco > defines external devices in our INI file like this:**** > > ** ** > > # Nexus Switch Format.**** > > # [NEXUS_SWITCH:<IP address of switch>]**** > > # <hostname>=<port> <- for cisco nexus devices a port would be in the form > “<slot>/<port#>”**** > > # ssh_port=<ssh port>**** > > # username=<credential username> <- used as login username to the switch** > ** > > # password=<credential password> <- password for that username**** > > ** ** > > Any thoughts on how we want to define this configuration info under ML2? * > *** > > ** ** > > The simplest solution is to have separate INI sections for each > vendor/device.**** > > Ex.**** > > [CISCO_NEXUS:<ipaddr>]**** > > Variables defined only for cisco nexus devices**** > > ** ** > > [ARISTA_XYZ]**** > > Whatever you want.**** > > ** ** > > Note that the cisco INI file can define more than one NEXUS_SWITCH section > (different IPs).**** > > ** ** > > We could think about creating more generic section headers but would need > a variable telling us what device owns that section.**** > > Ex.**** > > [ML2_MECH_DEVICE:<ip_addr>]**** > > variable1 =**** > > variable2 =**** > > type = cisco_nexus**** > > ** ** > > The cisco config.py file doesn’t have default values for these sections. > At init time we create a dictionary of these devices.**** > > ** ** > > Thoughts?**** > > ** ** > > Thanks,**** > > Rich**** > > ** ** > > ** ** > > ** ** > > ** ** > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
