Re: [openstack-dev] [packaging] [puppet] how to deal with the rename of config files in neutron on upgrade?

2015-07-02 Thread Kevin Benton
Will the agent still consider/read the old configuration file?

That's up to the packagers. The agent reads whatever config files are
passed as args to the process.

On Thu, Jul 2, 2015 at 11:02 AM, Mathieu Gagné mga...@iweb.com wrote:

 Adding [puppet] tag to subject.

 On 2015-07-02 11:35 AM, Matt Riedemann wrote:
  This change in neutron [1] renames the linuxbridge and openvswitch
  plugin config files.  I'm familiar with the %config(noreplace) directive
  in rpm but I'm not sure if there is a special trick with rpm to rename a
  config file while not losing the changes in the config file during the
  upgrade.
 
  Is this just something that has to be handled with trickery in the %post
  macro where we merge the contents together if the old config file
  exists?  Would symbolic links help?
 
  Changes like this seem like a potential giant pain in the ass for
  packagers.
 

 And people maintaining configuration manager.
 Will the agent still consider/read the old configuration file?

 I'm not sure how we will be able to maintain compatibility without
 involving manual steps or potential misconfiguration. Furthermore, we
 have to consider upgrades.

 Neutron agent configuration files are already a mess in distribution
 packaging. Ok, I exaggerated the situation, it's only a mess with Ubuntu
 [2] where it thought it would be a great idea to read the agent config
 from ml2_conf.ini instead of ovs_neutron_plugin.ini like all the other
 distributions.

 Now as Puppet modules authors, should we just update the path to the
 configuration file and hope it's compatible with upstream packages?

  [1] https://review.openstack.org/#/c/195277/

 [2] https://gist.github.com/mgagne/e2e06f5a8cb283a81cab

 --
 Mathieu

 __
 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




-- 
Kevin Benton
__
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] [packaging] [puppet] how to deal with the rename of config files in neutron on upgrade?

2015-07-02 Thread Mathieu Gagné
Adding [puppet] tag to subject.

On 2015-07-02 11:35 AM, Matt Riedemann wrote:
 This change in neutron [1] renames the linuxbridge and openvswitch
 plugin config files.  I'm familiar with the %config(noreplace) directive
 in rpm but I'm not sure if there is a special trick with rpm to rename a
 config file while not losing the changes in the config file during the
 upgrade.
 
 Is this just something that has to be handled with trickery in the %post
 macro where we merge the contents together if the old config file
 exists?  Would symbolic links help?
 
 Changes like this seem like a potential giant pain in the ass for
 packagers.
 

And people maintaining configuration manager.
Will the agent still consider/read the old configuration file?

I'm not sure how we will be able to maintain compatibility without
involving manual steps or potential misconfiguration. Furthermore, we
have to consider upgrades.

Neutron agent configuration files are already a mess in distribution
packaging. Ok, I exaggerated the situation, it's only a mess with Ubuntu
[2] where it thought it would be a great idea to read the agent config
from ml2_conf.ini instead of ovs_neutron_plugin.ini like all the other
distributions.

Now as Puppet modules authors, should we just update the path to the
configuration file and hope it's compatible with upstream packages?

 [1] https://review.openstack.org/#/c/195277/

[2] https://gist.github.com/mgagne/e2e06f5a8cb283a81cab

-- 
Mathieu

__
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