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.
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.
[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/107833.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
