Re: [openstack-dev] [tripleo] Plugin integration and environment file naming
Looks good to me. Rob On 9/8/15, 4:40 AM, "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 > >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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Plugin integration and environment file naming
I like where this is going. I've been asked a number of times where to put things and we never had a solid convention. I like the idea of having that docced somewhere. I like either of the proposed solutions. My biggest concern is that they don't capture how you actually use them. I know that was the point of your e-mail; we don't yet have the Heat constructs in place for the templates to convey that information. What about if we adopt the directory structure model and strongly request a README.md file in there? It's similar to the image elements model. We could offer a template to fill out or leave it open ended, but the purpose would be to specify: - Installation instructions (e.g. "set the resource registry namespace for Blah to point to this file" or "use the corresponding environment file foo.yaml") - Parameters that can/should be specified via parameter_defaults. I'm not saying we add a ton of documentation in there that would be duplicate of the actual parameter definitions, but perhaps just a list of the parameter names. That way, a user can have an idea of what specifically to look for in the template parameter list itself. That should be all of the info that we'd like Heat to eventually provide and hold us over until those discussions are finished. On 09/08/2015 08:20 AM, Jiří Stránský wrote: On 8.9.2015 13:47, Jiří Stránský wrote: 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]. Ah i mixed up two things in this paragraph -- env files vs. extraconfig nested stacks. Not sure if we want to start namespacing the extraconfig bits in a parallel manner. E.g. "puppet/extraconfig/pre_deploy/controller/cinder", "puppet/extraconfig/pre_deploy/controller/neutron-ml2". It would be nice, especially if we're sort of able to map the extraconfig categories to env file categories most of the time. OTOH the directory nesting is getting quite deep there :) That was my thought too, that the nesting is getting a bit deep. I also don't think we should enforce the role in the directory structure as we've already seen instances of things that have to happen on both controller and compute. J. [4] https://review.openstack.org/#/c/213142/1/puppet/extraconfig/pre_deploy/controller/all-bigswitch.yaml __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Plugin integration and environment file naming
On 8.9.2015 13:47, Jiří Stránský wrote: 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]. Ah i mixed up two things in this paragraph -- env files vs. extraconfig nested stacks. Not sure if we want to start namespacing the extraconfig bits in a parallel manner. E.g. "puppet/extraconfig/pre_deploy/controller/cinder", "puppet/extraconfig/pre_deploy/controller/neutron-ml2". It would be nice, especially if we're sort of able to map the extraconfig categories to env file categories most of the time. OTOH the directory nesting is getting quite deep there :) J. [4] https://review.openstack.org/#/c/213142/1/puppet/extraconfig/pre_deploy/controller/all-bigswitch.yaml __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Plugin integration and environment file naming
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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
