kozhukalov: I wasn't able to switch operating_system: "Ubuntu" to operating_system: "Debian" in openstack.yaml in nailgun, if do, then the UI stops working (ie: if I click on "Dashboard" then it doesn't work, and the UI is completely iresponsive after that).

zigo: we usually have several versions of modules on the master node (like /etc/puppet/v1, /etc/puppet/v2), but /etc/puppet/modules refers to the version that is used on the master node (for master node deployment). When puppet modules are rsynced on slaves for openstack deployment, nailgun by default uses /etc/puppet/modules, but also a particular version

kozhukalov: I've done what you've suggested, and added fuel-library to the IBP image (ie: in openstack.yaml, which in my case is debian.yaml until I get my changes upstreamed), meaning it's going to be there even without doing rsync.

kozhukalov: Now, since we can use package, I wonder how we could make it in a clean way so we store multiple versions of puppet-openstack. One way I thought about is having versionned puppet module, for example "puppet-module-nova-liberty" and "puppet-module-nova-mitaka", which would be stored in /usr/share/puppet/modules-available, with the normal update-alternatives stuff. The only issue is that this will force all of these modules to go through the Debian

FTP master NEW queue once per release, and they wont like me for that at all. Also, it doesn't really make sense to do such a thing to upload in Debian, since only a single version of OpenStack can be uploaded per Debian release. So probably that's something we should think only for the commercial version of the Fuel ISO image.

In the Fuel ISO, there's /etc/rsyslog.d/server.conf, which looks like very much CentOS centric to me, with such a thing as /var/log/message. So, there's that, and I also have the concern that rsyslog would open on a public interface, which would be a kind of security hole if it has a public IP address. So, I'm a little bit scared to have this default server.conf shipped directly in nailgun-common. I'm open for any suggestion...

>>> since only a single version of OpenStack can be uploaded per Debian release >>> that is still not a good reason to limit a user by only one release, because no matter on which OS you run fuel itself, it can be used to deploy openstack on various distributions, but you are right, let's leave this aside until we are ready to re-consider this

could someone point me to some resources on how to version a fuel plugin, ive read the Plugins wiki already; so all we need to do is change the version in metadata.yml and generate a new tag on the repo?