Open Stack

On 8.9.2015 10:40, Steven Hardy wrote:
> 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

+1 for this one ^

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

Yeah i like the idea of more structure in placing the environment files. 
It seems like customization of deployment via those files is becoming 
common, so we might see more environment files appearing over time.

>
> What do folks think of this, is now a good time to start enforcing such a
> convention?

We'd probably need to do this at some point anyway, and sooner seems 
better than later :)


Apart from "cinder" and "neutron-ml2" directories, we could also have a 
"combined" (or sth similar) directory for env files which combine 
multiple other env files. The use case which i see is for extra 
pre-deployment configs which would be commonly used together. E.g. 
combining Neutron and Horizon extensions of a single vendor [4].

Maybe also a couple of other categories could be found like "network" 
(for things related mainly to network isolation) or "devel" [5].


Jirka

[4] 
https://review.openstack.org/#/c/213142/1/puppet/extraconfig/pre_deploy/controller/all-bigswitch.yaml
[5] 
https://github.com/openstack/tripleo-heat-templates/blob/master/environments/puppet-ceph-devel.yaml

>
> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>