Re: [openstack-dev] [kolla] Policy regarding template customisation
Yup, I am hoping to avoid all of these kinds of customizations if possible... But if we have to we'll probably have to make something like that. Or we'll just have to render out files for each host and serve it from the same REST endpoint, ya da ya da... -Josh Michał Jastrzębski wrote: However I think issue here is about files in /etc/kolla/config - so config overrides. I think one potential solution would be to have some sort of ansible task that would translate ansible vars to ini format and lay down files in /etc/kolla/config, but I think that's beyond scope of Kolla-Ansible. __ 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] [kolla] Policy regarding template customisation
On 30 January 2018 at 09:34, Joshua Harlow wrote: > I'm ok with #2, > > Though I would like to show an alternative that we have been experimenting > with that avoids the whole needs for a globals.yml and such files in the > first place (and feels more naturally inline with how ansible works IMHO). > > So short explanation first; we have this yaml format that describes all of > our clouds and there settings and such (and which servers belong in which > cloud and so on and so forth). We have then setup a REST server (small > gunicorn based one) that renders/serves this format into other formats. > > One of those other formats is one that is compatible with ansibles concept > of dynamic inventory [1] and that is the one we are trying to send into > kolla-ansible to get it to configure all the things (via typical mechanisms > such as hostvars and groupvars). > > An example of this rendering: > > https://gist.github.com/harlowja/9d7b57571a2290c315fc9a4bf2957dac (this is > dynamically generated from the other format, which is git version > controlled...). > > The goal here is that we can just render all the needed variables and such > for kolla-ansible (at a per-host basis if we have to) and avoid the need for > having a special globals.yml (per-cloud/environment) and per-host special > files in the first place. > > Was this kind of approach ever thought of? Well that totally works:) I routinely use inventory to override parts of globals (different iface per node). You could have [all:vars] section in inventory and set every variable usually set in globals there. However I think issue here is about files in /etc/kolla/config - so config overrides. I think one potential solution would be to have some sort of ansible task that would translate ansible vars to ini format and lay down files in /etc/kolla/config, but I think that's beyond scope of Kolla-Ansible. > > Perhaps I can go into more detail if it seems like one others may want to > follow > > [1]: http://docs.ansible.com/ansible/latest/intro_dynamic_inventory.html > > > Paul Bourke wrote: >> >> Hi all, >> >> I'd like to revisit our policy of not templating everything in >> kolla-ansible's template files. This is a policy that was set in place >> very early on in kolla-ansible's development, but I'm concerned we >> haven't been very consistent with it. This leads to confusion for >> contributors and operators - "should I template this and submit a patch, >> or do I need to start using my own config files?". >> >> The docs[0] are currently clear: >> >> "The Kolla upstream community does not want to place key/value pairs in >> the Ansible playbook configuration options that are not essential to >> obtaining a functional deployment." >> >> In practice though our templates contain many options that are not >> necessary, and plenty of patches have merged that while very useful to >> operators, are not necessary to an 'out of the box' deployment. >> >> So I'd like us to revisit the questions: >> >> 1) Is kolla-ansible attempting to be a 'batteries included' tool, which >> caters to operators via key/value config options? >> >> 2) Or, is it to be a solid reference implementation, where any degree of >> customisation implies a clear 'bring your own configs' type policy. >> >> If 1), then we should potentially: >> >> * Update ours docs to remove the referenced paragraph >> * Look at reorganising files like globals.yml into something more >> maintainable. >> >> If 2), >> >> * We should make it clear to reviewers that patches templating options >> that are non essential should not be accepted. >> * Encourage patches to strip down existing config files to an absolute >> minimum. >> * Make this policy more clear in docs / templates to avoid frustration >> on the part of operators. >> >> Thoughts? >> >> Thanks, >> -Paul >> >> [0] >> >> https://docs.openstack.org/kolla-ansible/latest/admin/deployment-philosophy.html#why-not-template-customization >> >> >> __ >> 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 > > > __ > 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 __ 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] [kolla] Policy regarding template customisation
I'm ok with #2, Though I would like to show an alternative that we have been experimenting with that avoids the whole needs for a globals.yml and such files in the first place (and feels more naturally inline with how ansible works IMHO). So short explanation first; we have this yaml format that describes all of our clouds and there settings and such (and which servers belong in which cloud and so on and so forth). We have then setup a REST server (small gunicorn based one) that renders/serves this format into other formats. One of those other formats is one that is compatible with ansibles concept of dynamic inventory [1] and that is the one we are trying to send into kolla-ansible to get it to configure all the things (via typical mechanisms such as hostvars and groupvars). An example of this rendering: https://gist.github.com/harlowja/9d7b57571a2290c315fc9a4bf2957dac (this is dynamically generated from the other format, which is git version controlled...). The goal here is that we can just render all the needed variables and such for kolla-ansible (at a per-host basis if we have to) and avoid the need for having a special globals.yml (per-cloud/environment) and per-host special files in the first place. Was this kind of approach ever thought of? Perhaps I can go into more detail if it seems like one others may want to follow [1]: http://docs.ansible.com/ansible/latest/intro_dynamic_inventory.html Paul Bourke wrote: Hi all, I'd like to revisit our policy of not templating everything in kolla-ansible's template files. This is a policy that was set in place very early on in kolla-ansible's development, but I'm concerned we haven't been very consistent with it. This leads to confusion for contributors and operators - "should I template this and submit a patch, or do I need to start using my own config files?". The docs[0] are currently clear: "The Kolla upstream community does not want to place key/value pairs in the Ansible playbook configuration options that are not essential to obtaining a functional deployment." In practice though our templates contain many options that are not necessary, and plenty of patches have merged that while very useful to operators, are not necessary to an 'out of the box' deployment. So I'd like us to revisit the questions: 1) Is kolla-ansible attempting to be a 'batteries included' tool, which caters to operators via key/value config options? 2) Or, is it to be a solid reference implementation, where any degree of customisation implies a clear 'bring your own configs' type policy. If 1), then we should potentially: * Update ours docs to remove the referenced paragraph * Look at reorganising files like globals.yml into something more maintainable. If 2), * We should make it clear to reviewers that patches templating options that are non essential should not be accepted. * Encourage patches to strip down existing config files to an absolute minimum. * Make this policy more clear in docs / templates to avoid frustration on the part of operators. Thoughts? Thanks, -Paul [0] https://docs.openstack.org/kolla-ansible/latest/admin/deployment-philosophy.html#why-not-template-customization __ 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 __ 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] [kolla] Policy regarding template customisation
Sometimes there are features that require different containers to be deployed, or different config files to be generated. These are things that cannot be done simply through merging a fixed set of config files. nova_compute_virt_type is an example of such a variable - various non-config tasks depend upon it. I guess the question is, for the supported values of kolla-ansible's variables, should a minimal working deployment also be supported? Does this logic inevitably lead to (1), or is it sustainable? Mark On 30 January 2018 at 12:54, Simon Leinen wrote: > Paul Bourke writes: > > So I think everyone is in agreement that it should be option 2. I'm > > leaning towards this also but I'm wondering how much of this makes > > things easier for us as developers rather than operators. > > > How committed this are we in practice? For example, if we take > > nova.conf[0], if we follow option 2, theoretically all alternate > > hypervisor options (vmware/xen/nova-fake) etc. should come out and be > > left to override files. As should options templating options such as > > metadata_workers, listen ports, etc. globals.yml could probably be > > half the size it currently is. But if we go this route how many > > operators will stick with kolla? [...] > > Operator here. I've been following this discussion. Background: We > have been using puppet-openstack combined with our own Puppet > "integration classes" for several years. All configuration parameters > are neatly in Hiera. So we're used to the "batteries-included" way that > Paul describes under (1). For various reasons, we are also looking at > new ways of provisioning our control plane, including Kolla. > > In hindsight, and in my personal opinion, while our previous approach > (1) has somehow felt like the proper way to do things, it hasn't really > paid off for us as an operator, and I would happily try approach (2). > > The perceived downside of (2) - or a perceived advantage of (1) - is > that in an ideal world, (1) isolates us from the arcane configuration > file details that the crazy devs of individual services come up with. > In practice, it turns out that (a) those files aren't rocket science (b) > as an operator you need to understand them anyway, at the latest when > you need to debug stuff, and (c) the deployment tool can easily become a > bottlenecks for deploying new features. > > This is why I'm happy to embrace the current Kolla philosophy (2). > Sorry if I'm just repeating arguments that led to its adoption in the > first place - I wasn't there when that happened. > -- > Simon. > > > Maybe it won't be a big deal, the issue currently is the line is > > blurred on what gets templated and what doesn't. > > __ > 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 > __ 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] [kolla] Policy regarding template customisation
On 30/01/18 12:54, Simon Leinen wrote: The perceived downside of (2) - or a perceived advantage of (1) - is that in an ideal world, (1) isolates us from the arcane configuration file details that the crazy devs of individual services come up with. In practice, it turns out that (a) those files aren't rocket science (b) as an operator you need to understand them anyway, Thanks very much for taking the time to provide input Simon, it's very valuable. I think you sum it up well, definitely approach (1) is easier to newcomers who want to get up and going quickly without having to read too much into the files they're customising. In reality anyone going beyond a demo environment will need to do so. __ 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] [kolla] Policy regarding template customisation
Paul Bourke writes: > So I think everyone is in agreement that it should be option 2. I'm > leaning towards this also but I'm wondering how much of this makes > things easier for us as developers rather than operators. > How committed this are we in practice? For example, if we take > nova.conf[0], if we follow option 2, theoretically all alternate > hypervisor options (vmware/xen/nova-fake) etc. should come out and be > left to override files. As should options templating options such as > metadata_workers, listen ports, etc. globals.yml could probably be > half the size it currently is. But if we go this route how many > operators will stick with kolla? [...] Operator here. I've been following this discussion. Background: We have been using puppet-openstack combined with our own Puppet "integration classes" for several years. All configuration parameters are neatly in Hiera. So we're used to the "batteries-included" way that Paul describes under (1). For various reasons, we are also looking at new ways of provisioning our control plane, including Kolla. In hindsight, and in my personal opinion, while our previous approach (1) has somehow felt like the proper way to do things, it hasn't really paid off for us as an operator, and I would happily try approach (2). The perceived downside of (2) - or a perceived advantage of (1) - is that in an ideal world, (1) isolates us from the arcane configuration file details that the crazy devs of individual services come up with. In practice, it turns out that (a) those files aren't rocket science (b) as an operator you need to understand them anyway, at the latest when you need to debug stuff, and (c) the deployment tool can easily become a bottlenecks for deploying new features. This is why I'm happy to embrace the current Kolla philosophy (2). Sorry if I'm just repeating arguments that led to its adoption in the first place - I wasn't there when that happened. -- Simon. > Maybe it won't be a big deal, the issue currently is the line is > blurred on what gets templated and what doesn't. __ 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] [kolla] Policy regarding template customisation
may be we could move those specific options / templates to sample overrides? Operators would move necessary pieces back to /etc/kolla/config . Just thinking of config plug-ins / third-party supported things. Thanks, Vlad On 01/30/2018 01:46 PM, Paul Bourke wrote: So I think everyone is in agreement that it should be option 2. I'm leaning towards this also but I'm wondering how much of this makes things easier for us as developers rather than operators. How committed this are we in practice? For example, if we take nova.conf[0], if we follow option 2, theoretically all alternate hypervisor options (vmware/xen/nova-fake) etc. should come out and be left to override files. As should options templating options such as metadata_workers, listen ports, etc. globals.yml could probably be half the size it currently is. But if we go this route how many operators will stick with kolla? Maybe it won't be a big deal, the issue currently is the line is blurred on what gets templated and what doesn't. On 30/01/18 01:04, Michał Jastrzębski wrote: Hey, So I'm also for option 2. There was big discussion in Atlanta about "how hard it is to keep configs up to date and remove deprecated options". merge_config makes it easier for us to handle this. With amount of services we support I don't think we have enough time to keep tabs on every config change across OpenStack. On 29 January 2018 at 08:03, Steven Dake (stdake) wrote: Agree, the “why” of this policy is stated here: https://docs.openstack.org/developer/kolla-ansible/deployment-philosophy.html Paul, I think your corrective actions sound good. Perhaps we should also reword “essential” to some other word that is more lenient. Cheers -steve From: Jeffrey Zhang Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Monday, January 29, 2018 at 7:14 AM To: "OpenStack Development Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [kolla] Policy regarding template customisation Thank Paul for pointing this out. for me, I prefer to consist with 2) There are thousands of configuration in OpenStack, it is hard for Kolla to add every key/value pair in playbooks. Currently, the merge_config is a more better solutions. On Mon, Jan 29, 2018 at 7:13 PM, Paul Bourke wrote: Hi all, I'd like to revisit our policy of not templating everything in kolla-ansible's template files. This is a policy that was set in place very early on in kolla-ansible's development, but I'm concerned we haven't been very consistent with it. This leads to confusion for contributors and operators - "should I template this and submit a patch, or do I need to start using my own config files?". The docs[0] are currently clear: "The Kolla upstream community does not want to place key/value pairs in the Ansible playbook configuration options that are not essential to obtaining a functional deployment." In practice though our templates contain many options that are not necessary, and plenty of patches have merged that while very useful to operators, are not necessary to an 'out of the box' deployment. So I'd like us to revisit the questions: 1) Is kolla-ansible attempting to be a 'batteries included' tool, which caters to operators via key/value config options? 2) Or, is it to be a solid reference implementation, where any degree of customisation implies a clear 'bring your own configs' type policy. If 1), then we should potentially: * Update ours docs to remove the referenced paragraph * Look at reorganising files like globals.yml into something more maintainable. If 2), * We should make it clear to reviewers that patches templating options that are non essential should not be accepted. * Encourage patches to strip down existing config files to an absolute minimum. * Make this policy more clear in docs / templates to avoid frustration on the part of operators. Thoughts? Thanks, -Paul [0] https://docs.openstack.org/kolla-ansible/latest/admin/deployment-philosophy.html#why-not-template-customization __ 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 -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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 __ OpenStack Development Mailing List (not
Re: [openstack-dev] [kolla] Policy regarding template customisation
So I think everyone is in agreement that it should be option 2. I'm leaning towards this also but I'm wondering how much of this makes things easier for us as developers rather than operators. How committed this are we in practice? For example, if we take nova.conf[0], if we follow option 2, theoretically all alternate hypervisor options (vmware/xen/nova-fake) etc. should come out and be left to override files. As should options templating options such as metadata_workers, listen ports, etc. globals.yml could probably be half the size it currently is. But if we go this route how many operators will stick with kolla? Maybe it won't be a big deal, the issue currently is the line is blurred on what gets templated and what doesn't. On 30/01/18 01:04, Michał Jastrzębski wrote: Hey, So I'm also for option 2. There was big discussion in Atlanta about "how hard it is to keep configs up to date and remove deprecated options". merge_config makes it easier for us to handle this. With amount of services we support I don't think we have enough time to keep tabs on every config change across OpenStack. On 29 January 2018 at 08:03, Steven Dake (stdake) wrote: Agree, the “why” of this policy is stated here: https://docs.openstack.org/developer/kolla-ansible/deployment-philosophy.html Paul, I think your corrective actions sound good. Perhaps we should also reword “essential” to some other word that is more lenient. Cheers -steve From: Jeffrey Zhang Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Monday, January 29, 2018 at 7:14 AM To: "OpenStack Development Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [kolla] Policy regarding template customisation Thank Paul for pointing this out. for me, I prefer to consist with 2) There are thousands of configuration in OpenStack, it is hard for Kolla to add every key/value pair in playbooks. Currently, the merge_config is a more better solutions. On Mon, Jan 29, 2018 at 7:13 PM, Paul Bourke wrote: Hi all, I'd like to revisit our policy of not templating everything in kolla-ansible's template files. This is a policy that was set in place very early on in kolla-ansible's development, but I'm concerned we haven't been very consistent with it. This leads to confusion for contributors and operators - "should I template this and submit a patch, or do I need to start using my own config files?". The docs[0] are currently clear: "The Kolla upstream community does not want to place key/value pairs in the Ansible playbook configuration options that are not essential to obtaining a functional deployment." In practice though our templates contain many options that are not necessary, and plenty of patches have merged that while very useful to operators, are not necessary to an 'out of the box' deployment. So I'd like us to revisit the questions: 1) Is kolla-ansible attempting to be a 'batteries included' tool, which caters to operators via key/value config options? 2) Or, is it to be a solid reference implementation, where any degree of customisation implies a clear 'bring your own configs' type policy. If 1), then we should potentially: * Update ours docs to remove the referenced paragraph * Look at reorganising files like globals.yml into something more maintainable. If 2), * We should make it clear to reviewers that patches templating options that are non essential should not be accepted. * Encourage patches to strip down existing config files to an absolute minimum. * Make this policy more clear in docs / templates to avoid frustration on the part of operators. Thoughts? Thanks, -Paul [0] https://docs.openstack.org/kolla-ansible/latest/admin/deployment-philosophy.html#why-not-template-customization __ 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 -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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 __ 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 __ 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] [kolla] Policy regarding template customisation
Hey, So I'm also for option 2. There was big discussion in Atlanta about "how hard it is to keep configs up to date and remove deprecated options". merge_config makes it easier for us to handle this. With amount of services we support I don't think we have enough time to keep tabs on every config change across OpenStack. On 29 January 2018 at 08:03, Steven Dake (stdake) wrote: > Agree, the “why” of this policy is stated here: > > https://docs.openstack.org/developer/kolla-ansible/deployment-philosophy.html > > > > Paul, I think your corrective actions sound good. Perhaps we should also > reword “essential” to some other word that is more lenient. > > > > Cheers > > -steve > > > > From: Jeffrey Zhang > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > > Date: Monday, January 29, 2018 at 7:14 AM > To: "OpenStack Development Mailing List (not for usage questions)" > > Subject: Re: [openstack-dev] [kolla] Policy regarding template customisation > > > > Thank Paul for pointing this out. > > > > for me, I prefer to consist with 2) > > > > There are thousands of configuration in OpenStack, it is hard for Kolla to > > add every key/value pair in playbooks. Currently, the merge_config is a more > > better solutions. > > > > > > > > > > On Mon, Jan 29, 2018 at 7:13 PM, Paul Bourke wrote: > > Hi all, > > I'd like to revisit our policy of not templating everything in > kolla-ansible's template files. This is a policy that was set in place very > early on in kolla-ansible's development, but I'm concerned we haven't been > very consistent with it. This leads to confusion for contributors and > operators - "should I template this and submit a patch, or do I need to > start using my own config files?". > > The docs[0] are currently clear: > > "The Kolla upstream community does not want to place key/value pairs in the > Ansible playbook configuration options that are not essential to obtaining a > functional deployment." > > In practice though our templates contain many options that are not > necessary, and plenty of patches have merged that while very useful to > operators, are not necessary to an 'out of the box' deployment. > > So I'd like us to revisit the questions: > > 1) Is kolla-ansible attempting to be a 'batteries included' tool, which > caters to operators via key/value config options? > > 2) Or, is it to be a solid reference implementation, where any degree of > customisation implies a clear 'bring your own configs' type policy. > > If 1), then we should potentially: > > * Update ours docs to remove the referenced paragraph > * Look at reorganising files like globals.yml into something more > maintainable. > > If 2), > > * We should make it clear to reviewers that patches templating options that > are non essential should not be accepted. > * Encourage patches to strip down existing config files to an absolute > minimum. > * Make this policy more clear in docs / templates to avoid frustration on > the part of operators. > > Thoughts? > > Thanks, > -Paul > > [0] > https://docs.openstack.org/kolla-ansible/latest/admin/deployment-philosophy.html#why-not-template-customization > > __ > 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 > > > > > > -- > > Regards, > > Jeffrey Zhang > > Blog: http://xcodest.me > > > __ > 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 > __ 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] [kolla] Policy regarding template customisation
Agree, the “why” of this policy is stated here: https://docs.openstack.org/developer/kolla-ansible/deployment-philosophy.html Paul, I think your corrective actions sound good. Perhaps we should also reword “essential” to some other word that is more lenient. Cheers -steve From: Jeffrey Zhang Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Monday, January 29, 2018 at 7:14 AM To: "OpenStack Development Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [kolla] Policy regarding template customisation Thank Paul for pointing this out. for me, I prefer to consist with 2) There are thousands of configuration in OpenStack, it is hard for Kolla to add every key/value pair in playbooks. Currently, the merge_config is a more better solutions. On Mon, Jan 29, 2018 at 7:13 PM, Paul Bourke mailto:paul.bou...@oracle.com>> wrote: Hi all, I'd like to revisit our policy of not templating everything in kolla-ansible's template files. This is a policy that was set in place very early on in kolla-ansible's development, but I'm concerned we haven't been very consistent with it. This leads to confusion for contributors and operators - "should I template this and submit a patch, or do I need to start using my own config files?". The docs[0] are currently clear: "The Kolla upstream community does not want to place key/value pairs in the Ansible playbook configuration options that are not essential to obtaining a functional deployment." In practice though our templates contain many options that are not necessary, and plenty of patches have merged that while very useful to operators, are not necessary to an 'out of the box' deployment. So I'd like us to revisit the questions: 1) Is kolla-ansible attempting to be a 'batteries included' tool, which caters to operators via key/value config options? 2) Or, is it to be a solid reference implementation, where any degree of customisation implies a clear 'bring your own configs' type policy. If 1), then we should potentially: * Update ours docs to remove the referenced paragraph * Look at reorganising files like globals.yml into something more maintainable. If 2), * We should make it clear to reviewers that patches templating options that are non essential should not be accepted. * Encourage patches to strip down existing config files to an absolute minimum. * Make this policy more clear in docs / templates to avoid frustration on the part of operators. Thoughts? Thanks, -Paul [0] https://docs.openstack.org/kolla-ansible/latest/admin/deployment-philosophy.html#why-not-template-customization __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards, Jeffrey Zhang Blog: http://xcodest.me<http://xcodest.me/> __ 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] [kolla] Policy regarding template customisation
I have to agree - I prefer the minimal approach of option 2. It keeps the kolla-ansible code base small and easy to understand. The required test matrix is therefore relatively small (although better coverage of services in CI would be good). Finally, the approach has allowed the project to move quickly and support deployment of many OpenStack projects. Customised options shouldn't be outlawed though. There are times when they are very useful and/or required: * some things that cannot be expressed in config files alone * some options apply to many/all services (sometimes with subtle differences in configuration) * some config files are not in a format that can be easily merged (HAProxy, dnsmasq, etc.) These should be the exception, rather than the rule, however. Mark On 29 January 2018 at 14:12, Jeffrey Zhang wrote: > Thank Paul for pointing this out. > > for me, I prefer to consist with 2) > > There are thousands of configuration in OpenStack, it is hard for Kolla to > add every key/value pair in playbooks. Currently, the merge_config is a > more > better solutions. > > > > > On Mon, Jan 29, 2018 at 7:13 PM, Paul Bourke > wrote: > >> Hi all, >> >> I'd like to revisit our policy of not templating everything in >> kolla-ansible's template files. This is a policy that was set in place very >> early on in kolla-ansible's development, but I'm concerned we haven't been >> very consistent with it. This leads to confusion for contributors and >> operators - "should I template this and submit a patch, or do I need to >> start using my own config files?". >> >> The docs[0] are currently clear: >> >> "The Kolla upstream community does not want to place key/value pairs in >> the Ansible playbook configuration options that are not essential to >> obtaining a functional deployment." >> >> In practice though our templates contain many options that are not >> necessary, and plenty of patches have merged that while very useful to >> operators, are not necessary to an 'out of the box' deployment. >> >> So I'd like us to revisit the questions: >> >> 1) Is kolla-ansible attempting to be a 'batteries included' tool, which >> caters to operators via key/value config options? >> >> 2) Or, is it to be a solid reference implementation, where any degree of >> customisation implies a clear 'bring your own configs' type policy. >> >> If 1), then we should potentially: >> >> * Update ours docs to remove the referenced paragraph >> * Look at reorganising files like globals.yml into something more >> maintainable. >> >> If 2), >> >> * We should make it clear to reviewers that patches templating options >> that are non essential should not be accepted. >> * Encourage patches to strip down existing config files to an absolute >> minimum. >> * Make this policy more clear in docs / templates to avoid frustration on >> the part of operators. >> >> Thoughts? >> >> Thanks, >> -Paul >> >> [0] https://docs.openstack.org/kolla-ansible/latest/admin/deploy >> ment-philosophy.html#why-not-template-customization >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Regards, > Jeffrey Zhang > Blog: http://xcodest.me > > __ > 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 > > __ 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] [kolla] Policy regarding template customisation
Thank Paul for pointing this out. for me, I prefer to consist with 2) There are thousands of configuration in OpenStack, it is hard for Kolla to add every key/value pair in playbooks. Currently, the merge_config is a more better solutions. On Mon, Jan 29, 2018 at 7:13 PM, Paul Bourke wrote: > Hi all, > > I'd like to revisit our policy of not templating everything in > kolla-ansible's template files. This is a policy that was set in place very > early on in kolla-ansible's development, but I'm concerned we haven't been > very consistent with it. This leads to confusion for contributors and > operators - "should I template this and submit a patch, or do I need to > start using my own config files?". > > The docs[0] are currently clear: > > "The Kolla upstream community does not want to place key/value pairs in > the Ansible playbook configuration options that are not essential to > obtaining a functional deployment." > > In practice though our templates contain many options that are not > necessary, and plenty of patches have merged that while very useful to > operators, are not necessary to an 'out of the box' deployment. > > So I'd like us to revisit the questions: > > 1) Is kolla-ansible attempting to be a 'batteries included' tool, which > caters to operators via key/value config options? > > 2) Or, is it to be a solid reference implementation, where any degree of > customisation implies a clear 'bring your own configs' type policy. > > If 1), then we should potentially: > > * Update ours docs to remove the referenced paragraph > * Look at reorganising files like globals.yml into something more > maintainable. > > If 2), > > * We should make it clear to reviewers that patches templating options > that are non essential should not be accepted. > * Encourage patches to strip down existing config files to an absolute > minimum. > * Make this policy more clear in docs / templates to avoid frustration on > the part of operators. > > Thoughts? > > Thanks, > -Paul > > [0] https://docs.openstack.org/kolla-ansible/latest/admin/deploy > ment-philosophy.html#why-not-template-customization > > __ > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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
[openstack-dev] [kolla] Policy regarding template customisation
Hi all, I'd like to revisit our policy of not templating everything in kolla-ansible's template files. This is a policy that was set in place very early on in kolla-ansible's development, but I'm concerned we haven't been very consistent with it. This leads to confusion for contributors and operators - "should I template this and submit a patch, or do I need to start using my own config files?". The docs[0] are currently clear: "The Kolla upstream community does not want to place key/value pairs in the Ansible playbook configuration options that are not essential to obtaining a functional deployment." In practice though our templates contain many options that are not necessary, and plenty of patches have merged that while very useful to operators, are not necessary to an 'out of the box' deployment. So I'd like us to revisit the questions: 1) Is kolla-ansible attempting to be a 'batteries included' tool, which caters to operators via key/value config options? 2) Or, is it to be a solid reference implementation, where any degree of customisation implies a clear 'bring your own configs' type policy. If 1), then we should potentially: * Update ours docs to remove the referenced paragraph * Look at reorganising files like globals.yml into something more maintainable. If 2), * We should make it clear to reviewers that patches templating options that are non essential should not be accepted. * Encourage patches to strip down existing config files to an absolute minimum. * Make this policy more clear in docs / templates to avoid frustration on the part of operators. Thoughts? Thanks, -Paul [0] https://docs.openstack.org/kolla-ansible/latest/admin/deployment-philosophy.html#why-not-template-customization __ 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
