Open Stack

 > [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.bourke at oracle.com]
>> Sent: Tuesday, January 24, 2017 11:49 AM
>> To: OpenStack Development Mailing List (not for usage questions) <openstack-
>> dev at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>