Open Stack

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.mooney at intel.com" <sean.k.mooney at intel.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Date: Tuesday, January 24, 2017 at 5:01 PM
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?

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