> [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.
Unfortunately it's not that simple, --limit by default will restrict
fact gathering to that node only, resulting in missing facts for
templates that require info about other nodes. Hence we have plays in to
explicity gather facts when limit is used. See
https://github.com/openstack/kolla-ansible/blob/master/ansible/site.yml#L15-L32
for info on this also. Perhaps we're overcomplicating it, might be worth
reaching out to people from Ansible for more info.
On 25/01/17 00:01, Mooney, Sean K wrote:
-----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
__________________________________________________________________________
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
