Hi all, So, lately we're seeing an increasing number of patches adding integration for various third-party plugins, such as different neutron and cinder backends.
This is great to see, but it also poses the question of how we organize the user-visible interfaces to these things long term. Originally, I was hoping to land some Heat composability improvements[1] which would allow for tagging templates as providing a particular capability (such as "provides neutron ML2 plugin"), but this has stalled on some negative review feedback and isn't going to be implemented for Liberty. However, today looking at [2] and [3], (which both add t-h-t integration to enable neutron ML2 plugins), a simpler interim solution occured to me, which is just to make use of a suggested/mandatory naming convention. For example: environments/neutron-ml2-bigswitch.yaml environments/neutron-ml2-cisco-nexus-ucsm.yaml Or via directory structure: environments/neutron-ml2/bigswitch.yaml environments/neutron-ml2/cisco-nexus-ucsm.yaml This would require enforcement via code-review, but could potentially provide a much more intuitive interface for users when they go to create their cloud, and particularly it would make life much easier for any Ux to ask "choose which neutron-ml2 plugin you want", because the available options can simply be listed by looking at the available environment files? What do folks think of this, is now a good time to start enforcing such a convention? Steve [1] https://review.openstack.org/#/c/196656/ [2] https://review.openstack.org/#/c/213142/ [3] https://review.openstack.org/#/c/198754/ __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
