> -----Original Message----- > From: Paul Bourke [mailto:paul.bou...@oracle.com] > Sent: Tuesday, January 24, 2017 11:49 AM > To: OpenStack Development Mailing List (not for usage questions) <openstack- > d...@lists.openstack.org> > Subject: Re: [openstack-dev] [kolla-ansible] [kolla] Am I doing this wrong? > > Ah, I think you may be misreading what Sean is saying there. What he means is > kolla-ansible provides the bare minimum config templates to make the service > work. To template every possible config option would be too much of a > maintenance burden on the project. > > Of course, users will want to customise these. But instead of modifying the > templates directly, we recommend you use the "config override" > mechanism [0] > > This has a number of benefits, the main one being that you can pick up new > releases of Kolla and not get stuck in merge hell, Ansible will pick up the > Kolla base > templates and merge them with user provided overrides. [Mooney, Sean K] paul is correct here, I did not intend to suggest that kolla-ansible should not Be used to generate and manage config files. I simply wanted to point out that where Customization is required to a config, it is preferable to use the config override mechanism When possible vs modifying the ansible templates directly. > > Wrt to the fact gathering, I understand your concern, we essentially have the > same > problem in our team. It can be raised again for further discussion, I'm sure > there's > other ways it can be solved. [Mooney, Sean K] I belive you are intended to be able to use the ansible --limit and --tags flags, To restrict the plays executed and node processed by a deploy and upgrade command. I have used the --tags flags successfully in the past, I have had less success with the --limit flag. In theory with the right combination of --limit and --tag you should be able to constrain the node On which facts are gathered to just those that would be modified e.g. 2-3 instead of hundreds. > > [0] > http://docs.openstack.org/developer/kolla-ansible/advanced- > configuration.html#openstack-service-configuration-in-kolla > > -Paul > > On 23/01/17 18:03, Kris G. Lindgren wrote: > > Hi Paul, > > > > > > > > Thanks for responding. > > > > > > > >> The fact gathering on every server is a compromise taken by Kolla to > > > >> work around limitations in Ansible. It works well for the majority of > > > >> situations; for more detail and potential improvements on this please > > > >> have a read of this post: > > > >> http://lists.openstack.org/pipermail/openstack-dev/2016-November/1078 > >> 33.html > > > > > > > > So my problem with this is the logging in to the compute nodes. While > > this may be fine for a smaller deployment. Logging into thousands, > > even hundreds, of nodes via ansible to gather facts, just to do a > > deployment against 2 or 3 of them is not tenable. Additionally, in > > our higher audited environments (pki/pci) will cause our auditors heartburn. > > > > > > > >> I'm not quite following you here, the config templates from > > > >> kolla-ansible are one of it's stronger pieces imo, they're reasonably > > > >> well tested and maintained. What leads you to believe they shouldn't > >> be > > > >> used? > > > >> > > > >> > * Certain parts of it are 'reference only' (the config tasks), > > > >> > are not recommended > > > >> > > > >> This is untrue - kolla-ansible is designed to stand up a stable and > > > >> usable OpenStack 'out of the box'. There are definitely gaps in the > > > >> operator type tasks as you've highlighted, but I would not call it > > > >> 'reference only'. > > > > > > > > http://eavesdrop.openstack.org/irclogs/%23openstack-kolla/%23openstack > > -kolla.2017-01-09.log.html#t2017-01-09T21:33:15 > > > > > > > > > > This is where we were told the config stuff was "reference only"? > > > > > > > > > ___________________________________________________________________ > > > > Kris Lindgren > > > > Senior Linux Systems Engineer > > > > GoDaddy > > > > > > > > > ____________________________________________________________________ > __ > > ____ 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
