Hi Alex, Currently we have puppet modules[0] to configure our software which has components on Openstack Controller, Cinder node and Nova node. As per document[1] we successfully tried out role specific configuration[2].
So, does it mean that if we have an overcloud image with our packages inbuilt and we call our configuration scripts using role specific configuration, we may not need puppet modules[0] ? Is it acceptable deployment method? [0] https://github.com/abhishek-kane/puppet-veritas-hyperscale [1] https://docs.openstack.org/developer/tripleo-docs/advanced_deployment/node_config.html [2] http://paste.openstack.org/show/611116/ Thanks, Dnyaneshwar On 5/30/17, 6:52 PM, "Alex Schultz" <aschu...@redhat.com<mailto:aschu...@redhat.com>> wrote: On Mon, May 29, 2017 at 5:05 AM, Dnyaneshwar Pawar <dnyaneshwar.pa...@veritas.com<mailto:dnyaneshwar.pa...@veritas.com>> wrote: Hi, I am tying to deploy a software on openstack controller on the overcloud. One way to do this is by modifying ‘overcloud image’ so that all packages of our software are added to image and then run overcloud deploy. Other way is to write heat template and puppet module which will deploy the required packages. Question: Which of above two approaches is better? Note: Configuration part of the software will be done via separate heat template and puppet module. Usually you do both. Depending on how the end user is expected to deploy, if they are using the TripleoPackages service[0] in their role, the puppet installation of the package won't actually work (we override the package provider to noop) so it needs to be in the images. That being said, usually there is also a bit of puppet that needs to be written to configure the end service and as a best practice (and for development purposes), it's a good idea to also capture the package in the manifest. Thanks, -Alex [0] https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/services/tripleo-packages.yaml Thanks and Regards, Dnyaneshwar __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org<mailto: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<mailto: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
