Thanks peeps for responding to Kris. Kris, I had offered a response – do you
need further information answered? It looks to me like all the questions have
been answered by others in the community. If not, feel free to respond and
I’ll answer the remainders.
Sean when your around and I am please ping me – it looks like you have the same
outlook problem as I do and have sort of figured out how to solve it. I’d like
to know how so I don’t have to top post or use gmail for the ml.
Regards
-steve
-----Original Message-----
From: "sean.k.moo...@intel.com" <sean.k.moo...@intel.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date: Tuesday, January 24, 2017 at 5:01 PM
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla-ansible] [kolla] Am I doing this wrong?
> -----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
