Re: [openstack-dev] [rpm-packaging][chef][puppet][salt][openstack-ansible][HA][tripleo][kolla][fuel] Schema proposal for config file handling for services
Alex Schultz wrote: On Thu, Oct 13, 2016 at 3:27 AM, Thomas Bechtold wrote: On Tue, Oct 11, 2016 at 12:32:40PM -0600, Alex Schultz wrote: On Tue, Oct 11, 2016 at 1:39 AM, Thomas Bechtold wrote: Hi, On Mon, Oct 10, 2016 at 10:07:05AM -0600, Alex Schultz wrote: On Mon, Oct 10, 2016 at 5:03 AM, Thomas Bechtold wrote: Hi, in the rpm-packaging project we started to package the services and are currently discussing a possible schema for configuration files and snippets used by the systemd .service files (but this would also affect OCF resource agents). This affects packagers, endusers and config management systems (Chef, Puppet, Ansible, Salt, ...) so I want to discuss the proposal here on the list. This also affects deployment tools so you may want to include tripleo, kolla, fuel as they are downstream consumers and may have their own assumptions about how services are launched. Done. Most services (at least for SUSE and RDO) are using a single config (e.g. /etc/nova/nova.conf) when starting the service. Some services (e.g. neutron services like neutron-l3-agent) use multiple config files. There are multiple problems with that approach: - when using a config-mgmt-system, users may want to override a config option (for a feature that is not yet supported) but the config-mgmt-system will override the config later again. Just to chime in here from a puppet standpoint, this is not a problem because we provide a way for a user to add any extra options they wish using the provider so it always ends up in the correct configuration file. Does that also work if you need extra configuration files for 3rd party plugins (e.g. neutron plugins) ? I guess you could just copy the 3rd party config file content to the needed neutron config but that's ugly imo. Plugins also have their own .ini files and are handled differently. They get weird but we put the service configs in /etc/neutron/neutron.conf and agent configs get put in .ini files. So you put the config sections from the plugins into the neutron conf and mix things, right? Specifically for neutron, yes the service configs for plugins get put in neutron.conf but I believe they are in their own section. It seems not to have an issue with this. Each third party component for neutron may ship its config file to load into neutron-server when the component is used. You cannot handle the use case of those plugins shipping their own config files without some config-dir based mechanism. The use case is not going away any time soon, because of decisions made by neutron team respective to pluggability; decisions that are drastically different from what some other projects, like nova, made, which makes solutions working for nova not necessarily applying for neutron. The third party config file loading complexity is the original reason why --config-dir options were added to RDO neutron-server systemd unit files. Ihar __ 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] [rpm-packaging][chef][puppet][salt][openstack-ansible][HA][tripleo][kolla][fuel] Schema proposal for config file handling for services
On Thu, Oct 13, 2016 at 3:27 AM, Thomas Bechtold wrote: > On Tue, Oct 11, 2016 at 12:32:40PM -0600, Alex Schultz wrote: >> On Tue, Oct 11, 2016 at 1:39 AM, Thomas Bechtold wrote: >> > Hi, >> > >> > On Mon, Oct 10, 2016 at 10:07:05AM -0600, Alex Schultz wrote: >> >> On Mon, Oct 10, 2016 at 5:03 AM, Thomas Bechtold >> >> wrote: >> >> > Hi, >> >> > >> >> > in the rpm-packaging project we started to package the services and are >> >> > currently discussing a possible schema for configuration files and >> >> > snippets used by the systemd .service files (but this would also affect >> >> > OCF resource agents). >> >> > This affects packagers, endusers and config management systems (Chef, >> >> > Puppet, Ansible, Salt, ...) so I want to discuss the proposal here on >> >> > the list. >> >> >> >> This also affects deployment tools so you may want to include tripleo, >> >> kolla, fuel as they are downstream consumers and may have their own >> >> assumptions about how services are launched. >> > >> > Done. >> > >> >> > Most services (at least for SUSE and RDO) are using a single config >> >> > (e.g. /etc/nova/nova.conf) when starting the service. Some services >> >> > (e.g. neutron services like neutron-l3-agent) use multiple config files. >> >> > >> >> > There are multiple problems with that approach: >> >> > - when using a config-mgmt-system, users may want to override a config >> >> > option (for a feature that is not yet supported) but the >> >> > config-mgmt-system will override the config later again. >> >> >> >> Just to chime in here from a puppet standpoint, this is not a problem >> >> because we provide a way for a user to add any extra options they wish >> >> using the provider so it always ends up in the correct configuration >> >> file. >> > >> > Does that also work if you need extra configuration files for 3rd party >> > plugins (e.g. neutron plugins) ? I guess you could just copy the 3rd >> > party config file content to the needed neutron config but that's ugly imo. >> > >> >> Plugins also have their own .ini files and are handled differently. >> They get weird but we put the service configs in >> /etc/neutron/neutron.conf and agent configs get put in .ini files. > > So you put the config sections from the plugins into the neutron conf > and mix things, right? Specifically for neutron, yes the service configs for plugins get put in neutron.conf but I believe they are in their own section. It seems not to have an issue with this. > >> >> > - when users adjust /etc/$service/$service.conf and a release update is >> >> > done (e.g. mitaka->newton) /etc/$service/$service.conf wil not be >> >> > overridden. That's good because the user changed something but otoh the >> >> > file (with all it's config options and comments) is no longer correct. >> >> >> >> Depending on the configuration management tool, the 'default' options >> >> and comments may not even be there so I'm not sure this is actually >> >> that much of a concern. Also when you upgrade there is usually some >> >> sort of upgrade process that has to go along with your configuration >> >> management tool which should take care of this for you. So i'm not >> >> sure this needs to be a packaging concern. >> >> >> >> > - when config-mgmt-systems use templates for the $service.conf file, >> >> > updating theses templates is a lot of work. >> >> >> >> Yes which is why tools that don't use templates in the configuration >> >> management tool makes this a non-issue. I'm not sure this needs to be >> >> a concern of packagers as it's an issue with the configuration >> >> management tool of choice and many of these tools have switched away >> >> from templates or are currently handling this. If the configuration >> >> management tool doesn't support this or is suffering from this, simply >> >> adding conf.d support might help but then you also run into issues >> >> about ensuring things are removed and cleaned up. >> > >> > There *are* config-mgmt-tools still using templates. And having the >> > possibility to add config snippets simplifies the process here without >> > any downside for available solutions. Just don't use it if you don't >> > need it. >> > >> >> Yes there are but that's not a packaging concern other than providing >> a simple way to not have to deal with constantly managing >> $service.conf. I'm ok with a conf.d folder, but I guess that's more >> of a question for folks who have to manage those templates today as to >> what their prefered method is. Speaking from experience with a tool >> that we try not to use templates, my preference is still to have >> $service.conf but don't have it replaced on package update. > > Having $service.conf which is not replaced on package update is what is > proposed in this proposal (and is what distros already do). > And speaking as a Crowbar contributor (which uses templates in some > places), the conf.d/ directory would help a lot. Yea I'm ok with $service.conf and an empty conf.d/ directory.
Re: [openstack-dev] [rpm-packaging][chef][puppet][salt][openstack-ansible][HA][tripleo][kolla][fuel] Schema proposal for config file handling for services
On Tue, Oct 11, 2016 at 12:32:40PM -0600, Alex Schultz wrote: > On Tue, Oct 11, 2016 at 1:39 AM, Thomas Bechtold wrote: > > Hi, > > > > On Mon, Oct 10, 2016 at 10:07:05AM -0600, Alex Schultz wrote: > >> On Mon, Oct 10, 2016 at 5:03 AM, Thomas Bechtold > >> wrote: > >> > Hi, > >> > > >> > in the rpm-packaging project we started to package the services and are > >> > currently discussing a possible schema for configuration files and > >> > snippets used by the systemd .service files (but this would also affect > >> > OCF resource agents). > >> > This affects packagers, endusers and config management systems (Chef, > >> > Puppet, Ansible, Salt, ...) so I want to discuss the proposal here on > >> > the list. > >> > >> This also affects deployment tools so you may want to include tripleo, > >> kolla, fuel as they are downstream consumers and may have their own > >> assumptions about how services are launched. > > > > Done. > > > >> > Most services (at least for SUSE and RDO) are using a single config > >> > (e.g. /etc/nova/nova.conf) when starting the service. Some services > >> > (e.g. neutron services like neutron-l3-agent) use multiple config files. > >> > > >> > There are multiple problems with that approach: > >> > - when using a config-mgmt-system, users may want to override a config > >> > option (for a feature that is not yet supported) but the > >> > config-mgmt-system will override the config later again. > >> > >> Just to chime in here from a puppet standpoint, this is not a problem > >> because we provide a way for a user to add any extra options they wish > >> using the provider so it always ends up in the correct configuration > >> file. > > > > Does that also work if you need extra configuration files for 3rd party > > plugins (e.g. neutron plugins) ? I guess you could just copy the 3rd > > party config file content to the needed neutron config but that's ugly imo. > > > > Plugins also have their own .ini files and are handled differently. > They get weird but we put the service configs in > /etc/neutron/neutron.conf and agent configs get put in .ini files. So you put the config sections from the plugins into the neutron conf and mix things, right? > >> > - when users adjust /etc/$service/$service.conf and a release update is > >> > done (e.g. mitaka->newton) /etc/$service/$service.conf wil not be > >> > overridden. That's good because the user changed something but otoh the > >> > file (with all it's config options and comments) is no longer correct. > >> > >> Depending on the configuration management tool, the 'default' options > >> and comments may not even be there so I'm not sure this is actually > >> that much of a concern. Also when you upgrade there is usually some > >> sort of upgrade process that has to go along with your configuration > >> management tool which should take care of this for you. So i'm not > >> sure this needs to be a packaging concern. > >> > >> > - when config-mgmt-systems use templates for the $service.conf file, > >> > updating theses templates is a lot of work. > >> > >> Yes which is why tools that don't use templates in the configuration > >> management tool makes this a non-issue. I'm not sure this needs to be > >> a concern of packagers as it's an issue with the configuration > >> management tool of choice and many of these tools have switched away > >> from templates or are currently handling this. If the configuration > >> management tool doesn't support this or is suffering from this, simply > >> adding conf.d support might help but then you also run into issues > >> about ensuring things are removed and cleaned up. > > > > There *are* config-mgmt-tools still using templates. And having the > > possibility to add config snippets simplifies the process here without > > any downside for available solutions. Just don't use it if you don't > > need it. > > > > Yes there are but that's not a packaging concern other than providing > a simple way to not have to deal with constantly managing > $service.conf. I'm ok with a conf.d folder, but I guess that's more > of a question for folks who have to manage those templates today as to > what their prefered method is. Speaking from experience with a tool > that we try not to use templates, my preference is still to have > $service.conf but don't have it replaced on package update. Having $service.conf which is not replaced on package update is what is proposed in this proposal (and is what distros already do). And speaking as a Crowbar contributor (which uses templates in some places), the conf.d/ directory would help a lot. > > >> > - setting configuration options per service (let's say cinder-volume > >> > needs other config options than cinder-api) is not possible. > >> > >> So I agree this is more likely a real problem, but i'm not sure this > >> should be solved by packaging as this probably needs to be addressed > >> in upstream. Unless this is already a thing and it's just never been > >> properly i
Re: [openstack-dev] [rpm-packaging][chef][puppet][salt][openstack-ansible][HA][tripleo][kolla][fuel] Schema proposal for config file handling for services
Hi, On Tue, Oct 11, 2016 at 06:22:25PM +, Andrew Woodward wrote: [snipped] > > > So I agree this is more likely a real problem, but i'm not sure this > > > > > should be solved by packaging as this probably needs to be addressed > > > > > in upstream. Unless this is already a thing and it's just never been > > > > > properly implemented when deployed via packages. The issue I have with > > > > > only solving this via rpm packaging is that for tools that support > > > > > both rpms and debs this would lead to 2 different configuration > > > > > mechanisms. So I would vote not to do anything different then what > > > > > debs also do unless both packaging methods are updated at the same > > > > > time. > > > > > > > > Don't you have already a lot of different implementations for rpm > > > > vs. deb, different apache config dir styles, different package name, ... > > > > Improving the rpm side only if the deb side also changes is not going to > > > > work I think. > > > > > That isn't the issue here, both sides need to agree that this is a good > path forward and agree on some general structure here, and to a large > extent this is an upstream openstack issue to break the service configs > apart. As a config-mgmt-system collaborator, I can tell you that we have to > cover what ever deviation either side comes up with, and roughly gauging > what you are proposing to do here will have a massive impact to how we > configure services on RHEL derivatives which could easily take an entire > cycle for the Puppet team to implement support. Hm. Maybe you missunderstand the proposal. You would need to change absolutly *nothing*. Your config-mgmt-system would just work. And in addition, people/config-mgmt-systems which want to use snippets can simply do it. > If both sides aren't > supporting a similar structure, then things really start to become messy > for us, as we'd have multiple code paths to configure the two styles (and > all the issues that come from that). We can account for minor nuances in > the distros like package names, or config file locations quite easily, but > you are asking for us to put different config elements into entirely > different structures. I'm not asking you todo anything. The proposal is compatible with the solutions that are already available. Maybe as a small reminder - this proposal is from the rpm-packaging team which *unifies* the packaging for SUSE, RDO and Miranis. So it will be *simpler* for you because all theses distro will have the same package structure. > > > Do we have any examples or instances where an end user would > > > > > specifically want to configure two of the services in a conflicting > > > > > fashion? Or are there configuration options that fall into this > > > > > pattern? I thought the service specific items where in their own > > > > > configuration namespace to allow for such things. I would assume that > > > > > the bigger issue would be wanting to run two of the same service on > > > > > the same host with different configurations I would think that's where > > > > > something like containers would handle this case better than trying to > > > > > have multiple configuration files. > > > > > > > > In HA case you may want to set the hostname for all cinder-volumes to > > > > the same name but to something different for cinder-api (if both > > > > services run on the same host). I'm sure there are other examples. > > > > > > > > > > So here's the proposal to fix theses problems. The proposal is based on > > > > > > what RDO is already doing with neutron and extends it a bit. Let's do > > it > > > > > > for Nova as an example: > > > > > > > > > > > > - /usr/share/nova/nova-dist.conf > > > > > > This is the configuration file a distribution (openSUSE, RDO, ...) can > > > > > > modify. It must not be modified by endusers and will be overridden with > > > > > > package updates > > > Seems to be a normal process, I'm not against it. I like to have the full, > and commented out config in /etc/nova/nova.conf to reference as it's the > expected location (ie nova-dist.conf with everything commented out) but > that is my preference > > > > - /etc/nova/nova.conf > > > > > > This is an empty file . Users/config-mgmt-systems can modify it and it > > > > > > will not be overridden (if changed) with a package update. > > > > The mandatory user needs to edit these values or the service can't start > type (mostly credentials, uri for keystone, etc) should be set here and not > be hidden in the -dist.conf files. Sure. That's the intention. > > > > > > > > > > - /etc/nova/conf.d/common/ > > > > > > In this directory, config snippets can be added. By convention, > > > > > > config-mgmt-systems would install files starting with 100-XXX.conf, > > > > > > endusers would install files starting with 500-XXX.conf . Also this > > > > > > directory is used by all services (nova-api, nova-compute, ...). > > > > I'm against this, It makes no sense to config-mgmt-systems
Re: [openstack-dev] [rpm-packaging][chef][puppet][salt][openstack-ansible][HA][tripleo][kolla][fuel] Schema proposal for config file handling for services
Thomas, Kolla does not use systemd fies (bifrost may be different here – I am not certain). Kolla also does not use default configuration files that are shipped with distros. We find this model to be disruptive to reliable development. I get distros want to ship them and that’s fine by us. We just ignore them. What interests Kolla most is that binaries stay in the same place in the same packages. That said, if binaries are moved around, Kolla can deal with it. We adapt to our upstreams (in Kolla’s case tarballs.openstack.org, RDO, UCA, and many others ;). Regards -steve From: Thomas Bechtold Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Tuesday, October 11, 2016 at 12:39 AM To: "OpenStack Development Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [rpm-packaging][chef][puppet][salt][openstack-ansible][HA][tripleo][kolla][fuel] Schema proposal for config file handling for services Hi, On Mon, Oct 10, 2016 at 10:07:05AM -0600, Alex Schultz wrote: On Mon, Oct 10, 2016 at 5:03 AM, Thomas Bechtold mailto:tbecht...@suse.com>> wrote: > Hi, > > in the rpm-packaging project we started to package the services and are > currently discussing a possible schema for configuration files and > snippets used by the systemd .service files (but this would also affect > OCF resource agents). > This affects packagers, endusers and config management systems (Chef, > Puppet, Ansible, Salt, ...) so I want to discuss the proposal here on > the list. This also affects deployment tools so you may want to include tripleo, kolla, fuel as they are downstream consumers and may have their own assumptions about how services are launched. Done. > Most services (at least for SUSE and RDO) are using a single config > (e.g. /etc/nova/nova.conf) when starting the service. Some services > (e.g. neutron services like neutron-l3-agent) use multiple config files. > > There are multiple problems with that approach: > - when using a config-mgmt-system, users may want to override a config > option (for a feature that is not yet supported) but the > config-mgmt-system will override the config later again. Just to chime in here from a puppet standpoint, this is not a problem because we provide a way for a user to add any extra options they wish using the provider so it always ends up in the correct configuration file. Does that also work if you need extra configuration files for 3rd party plugins (e.g. neutron plugins) ? I guess you could just copy the 3rd party config file content to the needed neutron config but that's ugly imo. > - when users adjust /etc/$service/$service.conf and a release update is > done (e.g. mitaka->newton) /etc/$service/$service.conf wil not be > overridden. That's good because the user changed something but otoh the > file (with all it's config options and comments) is no longer correct. Depending on the configuration management tool, the 'default' options and comments may not even be there so I'm not sure this is actually that much of a concern. Also when you upgrade there is usually some sort of upgrade process that has to go along with your configuration management tool which should take care of this for you. So i'm not sure this needs to be a packaging concern. > - when config-mgmt-systems use templates for the $service.conf file, > updating theses templates is a lot of work. Yes which is why tools that don't use templates in the configuration management tool makes this a non-issue. I'm not sure this needs to be a concern of packagers as it's an issue with the configuration management tool of choice and many of these tools have switched away from templates or are currently handling this. If the configuration management tool doesn't support this or is suffering from this, simply adding conf.d support might help but then you also run into issues about ensuring things are removed and cleaned up. There *are* config-mgmt-tools still using templates. And having the possibility to add config snippets simplifies the process here without any downside for available solutions. Just don't use it if you don't need it. > - setting configuration options per service (let's say cinder-volume > needs other config options than cinder-api) is not possible. So I agree this is more likely a real problem, but i'm not sure this should be solved by packaging as this probably needs to be addressed in upstream. Unless this is already a thing and it's just never been properly implemented when deployed via packages. The issue I have with only solving this via rpm packaging is that for tools that support both rpms and debs this would lead to 2 different configuration mechanisms. So I would vote not to do anything different then what debs also do unless both packaging methods are
Re: [openstack-dev] [rpm-packaging][chef][puppet][salt][openstack-ansible][HA][tripleo][kolla][fuel] Schema proposal for config file handling for services
On Tue, Oct 11, 2016 at 11:32 AM, Alex Schultz wrote: > On Tue, Oct 11, 2016 at 1:39 AM, Thomas Bechtold wrote: >> Hi, >> >> On Mon, Oct 10, 2016 at 10:07:05AM -0600, Alex Schultz wrote: >>> On Mon, Oct 10, 2016 at 5:03 AM, Thomas Bechtold wrote: >>> > Hi, >>> > >>> > in the rpm-packaging project we started to package the services and are >>> > currently discussing a possible schema for configuration files and >>> > snippets used by the systemd .service files (but this would also affect >>> > OCF resource agents). >>> > This affects packagers, endusers and config management systems (Chef, >>> > Puppet, Ansible, Salt, ...) so I want to discuss the proposal here on >>> > the list. >>> >>> This also affects deployment tools so you may want to include tripleo, >>> kolla, fuel as they are downstream consumers and may have their own >>> assumptions about how services are launched. >> >> Done. >> >>> > Most services (at least for SUSE and RDO) are using a single config >>> > (e.g. /etc/nova/nova.conf) when starting the service. Some services >>> > (e.g. neutron services like neutron-l3-agent) use multiple config files. >>> > >>> > There are multiple problems with that approach: >>> > - when using a config-mgmt-system, users may want to override a config >>> > option (for a feature that is not yet supported) but the >>> > config-mgmt-system will override the config later again. >>> >>> Just to chime in here from a puppet standpoint, this is not a problem >>> because we provide a way for a user to add any extra options they wish >>> using the provider so it always ends up in the correct configuration >>> file. >> >> Does that also work if you need extra configuration files for 3rd party >> plugins (e.g. neutron plugins) ? I guess you could just copy the 3rd >> party config file content to the needed neutron config but that's ugly imo. >> > > Plugins also have their own .ini files and are handled differently. > They get weird but we put the service configs in > /etc/neutron/neutron.conf and agent configs get put in .ini files. > >>> > - when users adjust /etc/$service/$service.conf and a release update is >>> > done (e.g. mitaka->newton) /etc/$service/$service.conf wil not be >>> > overridden. That's good because the user changed something but otoh the >>> > file (with all it's config options and comments) is no longer correct. >>> >>> Depending on the configuration management tool, the 'default' options >>> and comments may not even be there so I'm not sure this is actually >>> that much of a concern. Also when you upgrade there is usually some >>> sort of upgrade process that has to go along with your configuration >>> management tool which should take care of this for you. So i'm not >>> sure this needs to be a packaging concern. >>> >>> > - when config-mgmt-systems use templates for the $service.conf file, >>> > updating theses templates is a lot of work. >>> >>> Yes which is why tools that don't use templates in the configuration >>> management tool makes this a non-issue. I'm not sure this needs to be >>> a concern of packagers as it's an issue with the configuration >>> management tool of choice and many of these tools have switched away >>> from templates or are currently handling this. If the configuration >>> management tool doesn't support this or is suffering from this, simply >>> adding conf.d support might help but then you also run into issues >>> about ensuring things are removed and cleaned up. >> >> There *are* config-mgmt-tools still using templates. And having the >> possibility to add config snippets simplifies the process here without >> any downside for available solutions. Just don't use it if you don't >> need it. >> > > Yes there are but that's not a packaging concern other than providing > a simple way to not have to deal with constantly managing > $service.conf. I'm ok with a conf.d folder, but I guess that's more > of a question for folks who have to manage those templates today as to > what their prefered method is. Speaking from experience with a tool > that we try not to use templates, my preference is still to have > $service.conf but don't have it replaced on package update. >From the perspective of Chef, we stopped using erubis templates for the service configs, adopting an attribute-driven config instead. This got rid of the impossible to manage, thousand line long templates, and gave us just what is needed to get the service off the ground. Moving to a snippets model is feasible from our point of view, but it doesn't make sense if only rpm does this and deb does not follow suit. Having to maintain different config models would result in having to maintain two lines of code to achieve the same desired result. > >>> > - setting configuration options per service (let's say cinder-volume >>> > needs other config options than cinder-api) is not possible. >>> >>> So I agree this is more likely a real problem, but i'm not sure this >>> should be solved by packaging as this pro
Re: [openstack-dev] [rpm-packaging][chef][puppet][salt][openstack-ansible][HA][tripleo][kolla][fuel] Schema proposal for config file handling for services
On Tue, Oct 11, 2016 at 1:39 AM, Thomas Bechtold wrote: > Hi, > > On Mon, Oct 10, 2016 at 10:07:05AM -0600, Alex Schultz wrote: >> On Mon, Oct 10, 2016 at 5:03 AM, Thomas Bechtold wrote: >> > Hi, >> > >> > in the rpm-packaging project we started to package the services and are >> > currently discussing a possible schema for configuration files and >> > snippets used by the systemd .service files (but this would also affect >> > OCF resource agents). >> > This affects packagers, endusers and config management systems (Chef, >> > Puppet, Ansible, Salt, ...) so I want to discuss the proposal here on >> > the list. >> >> This also affects deployment tools so you may want to include tripleo, >> kolla, fuel as they are downstream consumers and may have their own >> assumptions about how services are launched. > > Done. > >> > Most services (at least for SUSE and RDO) are using a single config >> > (e.g. /etc/nova/nova.conf) when starting the service. Some services >> > (e.g. neutron services like neutron-l3-agent) use multiple config files. >> > >> > There are multiple problems with that approach: >> > - when using a config-mgmt-system, users may want to override a config >> > option (for a feature that is not yet supported) but the >> > config-mgmt-system will override the config later again. >> >> Just to chime in here from a puppet standpoint, this is not a problem >> because we provide a way for a user to add any extra options they wish >> using the provider so it always ends up in the correct configuration >> file. > > Does that also work if you need extra configuration files for 3rd party > plugins (e.g. neutron plugins) ? I guess you could just copy the 3rd > party config file content to the needed neutron config but that's ugly imo. > Plugins also have their own .ini files and are handled differently. They get weird but we put the service configs in /etc/neutron/neutron.conf and agent configs get put in .ini files. >> > - when users adjust /etc/$service/$service.conf and a release update is >> > done (e.g. mitaka->newton) /etc/$service/$service.conf wil not be >> > overridden. That's good because the user changed something but otoh the >> > file (with all it's config options and comments) is no longer correct. >> >> Depending on the configuration management tool, the 'default' options >> and comments may not even be there so I'm not sure this is actually >> that much of a concern. Also when you upgrade there is usually some >> sort of upgrade process that has to go along with your configuration >> management tool which should take care of this for you. So i'm not >> sure this needs to be a packaging concern. >> >> > - when config-mgmt-systems use templates for the $service.conf file, >> > updating theses templates is a lot of work. >> >> Yes which is why tools that don't use templates in the configuration >> management tool makes this a non-issue. I'm not sure this needs to be >> a concern of packagers as it's an issue with the configuration >> management tool of choice and many of these tools have switched away >> from templates or are currently handling this. If the configuration >> management tool doesn't support this or is suffering from this, simply >> adding conf.d support might help but then you also run into issues >> about ensuring things are removed and cleaned up. > > There *are* config-mgmt-tools still using templates. And having the > possibility to add config snippets simplifies the process here without > any downside for available solutions. Just don't use it if you don't > need it. > Yes there are but that's not a packaging concern other than providing a simple way to not have to deal with constantly managing $service.conf. I'm ok with a conf.d folder, but I guess that's more of a question for folks who have to manage those templates today as to what their prefered method is. Speaking from experience with a tool that we try not to use templates, my preference is still to have $service.conf but don't have it replaced on package update. >> > - setting configuration options per service (let's say cinder-volume >> > needs other config options than cinder-api) is not possible. >> >> So I agree this is more likely a real problem, but i'm not sure this >> should be solved by packaging as this probably needs to be addressed >> in upstream. Unless this is already a thing and it's just never been >> properly implemented when deployed via packages. The issue I have with >> only solving this via rpm packaging is that for tools that support >> both rpms and debs this would lead to 2 different configuration >> mechanisms. So I would vote not to do anything different then what >> debs also do unless both packaging methods are updated at the same >> time. > > Don't you have already a lot of different implementations for rpm > vs. deb, different apache config dir styles, different package name, ... > Improving the rpm side only if the deb side also changes is not going to > work I think. Pack
Re: [openstack-dev] [rpm-packaging][chef][puppet][salt][openstack-ansible][HA][tripleo][kolla][fuel] Schema proposal for config file handling for services
On Tue, Oct 11, 2016 at 12:40 AM Thomas Bechtold wrote: > Hi, > > > > On Mon, Oct 10, 2016 at 10:07:05AM -0600, Alex Schultz wrote: > > > On Mon, Oct 10, 2016 at 5:03 AM, Thomas Bechtold > wrote: > > > > Hi, > > > > > > > > in the rpm-packaging project we started to package the services and are > > > > currently discussing a possible schema for configuration files and > > > > snippets used by the systemd .service files (but this would also affect > > > > OCF resource agents). > > > > This affects packagers, endusers and config management systems (Chef, > > > > Puppet, Ansible, Salt, ...) so I want to discuss the proposal here on > > > > the list. > > > > > > This also affects deployment tools so you may want to include tripleo, > > > kolla, fuel as they are downstream consumers and may have their own > > > assumptions about how services are launched. > > > > Done. > > > > > > Most services (at least for SUSE and RDO) are using a single config > > > > (e.g. /etc/nova/nova.conf) when starting the service. Some services > > > > (e.g. neutron services like neutron-l3-agent) use multiple config > files. > > > > > > > > There are multiple problems with that approach: > > > > - when using a config-mgmt-system, users may want to override a config > > > > option (for a feature that is not yet supported) but the > > > > config-mgmt-system will override the config later again. > > > > > > Just to chime in here from a puppet standpoint, this is not a problem > > > because we provide a way for a user to add any extra options they wish > > > using the provider so it always ends up in the correct configuration > > > file. > > > > Does that also work if you need extra configuration files for 3rd party > > plugins (e.g. neutron plugins) ? I guess you could just copy the 3rd > > party config file content to the needed neutron config but that's ugly imo. > > > > > > - when users adjust /etc/$service/$service.conf and a release update is > > > > done (e.g. mitaka->newton) /etc/$service/$service.conf wil not be > > > > overridden. That's good because the user changed something but otoh the > > > > file (with all it's config options and comments) is no longer correct. > > > > > > Depending on the configuration management tool, the 'default' options > > > and comments may not even be there so I'm not sure this is actually > > > that much of a concern. Also when you upgrade there is usually some > > > sort of upgrade process that has to go along with your configuration > > > management tool which should take care of this for you. So i'm not > > > sure this needs to be a packaging concern. > > > > > > > - when config-mgmt-systems use templates for the $service.conf file, > > > > updating theses templates is a lot of work. > > > > > > Yes which is why tools that don't use templates in the configuration > > > management tool makes this a non-issue. I'm not sure this needs to be > > > a concern of packagers as it's an issue with the configuration > > > management tool of choice and many of these tools have switched away > > > from templates or are currently handling this. If the configuration > > > management tool doesn't support this or is suffering from this, simply > > > adding conf.d support might help but then you also run into issues > > > about ensuring things are removed and cleaned up. > > > > There *are* config-mgmt-tools still using templates. And having the > > possibility to add config snippets simplifies the process here without > > any downside for available solutions. Just don't use it if you don't > > need it. > > > > > > - setting configuration options per service (let's say cinder-volume > > > > needs other config options than cinder-api) is not possible. > > > > > > So I agree this is more likely a real problem, but i'm not sure this > > > should be solved by packaging as this probably needs to be addressed > > > in upstream. Unless this is already a thing and it's just never been > > > properly implemented when deployed via packages. The issue I have with > > > only solving this via rpm packaging is that for tools that support > > > both rpms and debs this would lead to 2 different configuration > > > mechanisms. So I would vote not to do anything different then what > > > debs also do unless both packaging methods are updated at the same > > > time. > > > > Don't you have already a lot of different implementations for rpm > > vs. deb, different apache config dir styles, different package name, ... > > Improving the rpm side only if the deb side also changes is not going to > > work I think. > > That isn't the issue here, both sides need to agree that this is a good path forward and agree on some general structure here, and to a large extent this is an upstream openstack issue to break the service configs apart. As a config-mgmt-system collaborator, I can tell you that we have to cover what ever deviation either side comes up with, and roughly gauging what you are proposing to do here will have a massive
Re: [openstack-dev] [rpm-packaging][chef][puppet][salt][openstack-ansible][HA][tripleo][kolla][fuel] Schema proposal for config file handling for services
Hi, On Mon, Oct 10, 2016 at 10:07:05AM -0600, Alex Schultz wrote: > On Mon, Oct 10, 2016 at 5:03 AM, Thomas Bechtold wrote: > > Hi, > > > > in the rpm-packaging project we started to package the services and are > > currently discussing a possible schema for configuration files and > > snippets used by the systemd .service files (but this would also affect > > OCF resource agents). > > This affects packagers, endusers and config management systems (Chef, > > Puppet, Ansible, Salt, ...) so I want to discuss the proposal here on > > the list. > > This also affects deployment tools so you may want to include tripleo, > kolla, fuel as they are downstream consumers and may have their own > assumptions about how services are launched. Done. > > Most services (at least for SUSE and RDO) are using a single config > > (e.g. /etc/nova/nova.conf) when starting the service. Some services > > (e.g. neutron services like neutron-l3-agent) use multiple config files. > > > > There are multiple problems with that approach: > > - when using a config-mgmt-system, users may want to override a config > > option (for a feature that is not yet supported) but the > > config-mgmt-system will override the config later again. > > Just to chime in here from a puppet standpoint, this is not a problem > because we provide a way for a user to add any extra options they wish > using the provider so it always ends up in the correct configuration > file. Does that also work if you need extra configuration files for 3rd party plugins (e.g. neutron plugins) ? I guess you could just copy the 3rd party config file content to the needed neutron config but that's ugly imo. > > - when users adjust /etc/$service/$service.conf and a release update is > > done (e.g. mitaka->newton) /etc/$service/$service.conf wil not be > > overridden. That's good because the user changed something but otoh the > > file (with all it's config options and comments) is no longer correct. > > Depending on the configuration management tool, the 'default' options > and comments may not even be there so I'm not sure this is actually > that much of a concern. Also when you upgrade there is usually some > sort of upgrade process that has to go along with your configuration > management tool which should take care of this for you. So i'm not > sure this needs to be a packaging concern. > > > - when config-mgmt-systems use templates for the $service.conf file, > > updating theses templates is a lot of work. > > Yes which is why tools that don't use templates in the configuration > management tool makes this a non-issue. I'm not sure this needs to be > a concern of packagers as it's an issue with the configuration > management tool of choice and many of these tools have switched away > from templates or are currently handling this. If the configuration > management tool doesn't support this or is suffering from this, simply > adding conf.d support might help but then you also run into issues > about ensuring things are removed and cleaned up. There *are* config-mgmt-tools still using templates. And having the possibility to add config snippets simplifies the process here without any downside for available solutions. Just don't use it if you don't need it. > > - setting configuration options per service (let's say cinder-volume > > needs other config options than cinder-api) is not possible. > > So I agree this is more likely a real problem, but i'm not sure this > should be solved by packaging as this probably needs to be addressed > in upstream. Unless this is already a thing and it's just never been > properly implemented when deployed via packages. The issue I have with > only solving this via rpm packaging is that for tools that support > both rpms and debs this would lead to 2 different configuration > mechanisms. So I would vote not to do anything different then what > debs also do unless both packaging methods are updated at the same > time. Don't you have already a lot of different implementations for rpm vs. deb, different apache config dir styles, different package name, ... Improving the rpm side only if the deb side also changes is not going to work I think. > Do we have any examples or instances where an end user would > specifically want to configure two of the services in a conflicting > fashion? Or are there configuration options that fall into this > pattern? I thought the service specific items where in their own > configuration namespace to allow for such things. I would assume that > the bigger issue would be wanting to run two of the same service on > the same host with different configurations I would think that's where > something like containers would handle this case better than trying to > have multiple configuration files. In HA case you may want to set the hostname for all cinder-volumes to the same name but to something different for cinder-api (if both services run on the same host). I'm sure there are other examples. > > So
