Open Stack

> -----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