On 02/29/2016 11:19 AM, Vladimir Kuklin wrote: > Hi Ivan > > Thanks for bringing this up. Frankly, I think that we hurried a little > bit by making our integration with upstream puppet manifests too > continuous. I would suppose that we used a little bit different technique. > > First of all, we need to have a set of stable Fuel commits against which > the changes to upstream manifests should be tested. Could you please > elaborate on whether we are doing this already? > > Secondly, we need to have FUEL CI working with a set of stable commits > of puppet openstack manifests which passed those upstream tests as we > should not have too much moving parts or we will get into situation > similar to requirements.txt updates when we have pypi updated with new > library, e.g. oslo-serialization. > > In this case, we will be able to do proper testing against frozen > code-base for each piece thus avoiding such issues while retaining fair > amount of integration with upstream puppet manifests for OpenStack. > > So what do you think?
IMO, what needs to happen, is Fuel to use a packaged version of these puppet scripts. This has numerous advantages: - the openstack.yaml repository would also point to the corresponding puppet stuff - the version of puppet-openstack would automatically match the one of the target installation, because it would be stored in the corresponding packaging repository - we wouldn't need to hack symlinks in /etc/puppet/modules - there would be no need to use rsync from the master node to the slave nodes, as the correct version of fuel-library would be installed in the IBP image by fuel-agent, making it automatically available What we shouldn't do though, is loose the continuous testing of upstream puppet-openstack modules, so we make sure they never break Fuel, otherwise we would discover issues too late. FYI, I have just finished uploading all of puppet-openstack Mitaka b1 tag (which in fact corresponds to b3, somehow) to Debian Experimental. This could be reused by Fuel. Cheers, Thomas Goirand (zigo) __________________________________________________________________________ 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