Open Stack

Bryan,

I spent some time looking into the proper way to document configuration
options in OpenStack.  There's a configuration reference that's part of the
openstack-manuals project.  It'll take some time to figure out the best way
of contributing to that.

But for now I added a section to our docs detailing the most important
options for Congress.  All the rest of the config options are common to
most OpenStack projects.  We should document those too, but for the time
being I think we've got the most important part in place.

Here's the change in review, if you want to comment.
https://review.openstack.org/#/c/324732/

If you'd rather just have the Congress-specific config options, here's the
text from that change.
As Masahito said, everything has a default value, so all of these are
optional for you to include in the configuration file.  In practice,
though, you should always provide the ``drivers`` option, since otherwise
you won't be able to create any datasources.

Quick request: Could you give us feedback around whether an empty default
value for ``drivers`` makes sense, or whether it would be (much) better for
the default to be all of the drivers that exist in Congress?

<begin text>

The options most important to Congress are described below, all of which
appear under the [DEFAULT] section of the configuration file.

``drivers``
    The list of permitted datasource drivers.  Default is the empty list.
    The list is a comma separated list of Python class paths. For example:
    drivers =
congress.datasources.neutronv2_driver.NeutronV2Driver,congress.datasources.glancev2_driver.GlanceV2Driver

``datasource_sync_period``
    The number of seconds to wait between synchronizing datasource config
    from the database.  Default is 0.

``enable_execute_action``
    Whether or not congress will execute actions.  If false, Congress will
    never execute any actions to do manual reactive enforcement, even if
there
    are policy statements that say actions should be executed and the
    conditions of those actions become true.  Default is True.

One of Congress's new experimental features is distributing its services
across multiple services and even hosts.  Here are the options for using
that feature.

``distributed_architecture``
    Whether to enable the distributed architecture.  Don't set it to true in
    before Newton release since the new architecture is still under
    development as of Newton.  Default is false.

``node_id``
    Unique ID of this Congress instance.  Can be any string.  Useful if
    you want to create multiple, distributed instances of Congress.

Here are the most often-used, but standard OpenStack options.  These
are specified in the [DEFAULT] section of the configuration file.

``auth_strategy``
    Method for authenticating Congress users.
    Can be assigned to either 'keystone' meaning that the user must provide
    Keystone credentials or to 'noauth' meaning that no authentication is
    required.  Default is 'keystone'.

``verbose``
    Controls whether the INFO-level of logging is enabled.  If false,
logging
    level will be set to WARNING.  Default is false.  Deprecated.

``debug``
    Whether or not the DEBUG-level of logging is enabled. Default is false.

<end text>


Tim

On Tue, May 31, 2016 at 10:18 AM Tim Hinrichs <tim at styra.com> wrote:

> We should add a section to our docs that details the config option names,
> their descriptions, and which ones are required.  We should backport that
> to mitaka and maybe liberty.
>
> Tim
>
> On Mon, May 30, 2016 at 12:49 AM Masahito MUROI <
> muroi.masahito at lab.ntt.co.jp> wrote:
>
>> Hi Bryan,
>>
>>
>> On 2016/05/28 2:52, Bryan Sullivan wrote:
>> > Masahito,
>> >
>> > Sorry, I'm not quite clear on the guidance. Sounds like you're saying
>> > all options will be defaulted by Oslo.config if not set in the
>> > congress.conf file. That's OK, if I understood.
>> you're right.
>>
>> >
>> > It's clear to me that some will be deployment-specific.
>> >
>> > But what I am asking is where is the spec for:
>> > - what congress.conf fields are supported i.e. defined for possible
>> > setting in a release
>> Your generated congress.conf has a list of all supported config fields.
>>
>> > - which fields are mandatory to be set (or Congress will simply not
>> work)
>> > - which fields are not mandatory, but must be set for some specific
>> > purpose, which right now is unclear
>> Without deployment-specific configs, IIRC what you need to change from
>> default only is "drivers" fields to run Congress with default setting.
>>
>> >
>> > I'm hoping the answer isn't "go look at the code"! That won't work for
>> > end-users, who are looking to use Congress but not decipher the
>> > meaning/importance of specific fields from the code.
>> I guess your generated config has the purpose of each config fields.
>>
>> If you expect the spec means documents like [1], unfortunately Congress
>> doesn't have these kind of document now.
>>
>> [1] http://docs.openstack.org/mitaka/config-reference/
>>
>> best regards,
>> Masahito
>>
>> >
>> > Thanks,
>> > Bryan Sullivan
>> >
>> >> From: muroi.masahito at lab.ntt.co.jp
>> >> Date: Fri, 27 May 2016 15:40:31 +0900
>> >> To: openstack-dev at lists.openstack.org
>> >> Subject: Re: [openstack-dev] [congress] Spec for congress.conf
>> >>
>> >> Hi Bryan,
>> >>
>> >> Oslo.config that Congress uses to manage config sets each fields to
>> >> default value if you don't specify your configured values in
>> >> congress.conf. In that meaning, all config is option/required.
>> >>
>> >> In my experience, config values differing from each deployment, like ip
>> >> address and so on, have to be configured, but others might be
>> configured
>> >> when you want Congress to run with different behaviors.
>> >>
>> >> best regard,
>> >> Masahito
>> >>
>> >> On 2016/05/27 3:36, SULLIVAN, BRYAN L wrote:
>> >> > Hi Congress team,
>> >> >
>> >> >
>> >> >
>> >> > Quick question for anyone. Is there a spec for fields in
>> congress.conf
>> >> > file? As of Liberty this has to be tox-generated but I need to know
>> >> > which conf values are required vs optional. The generated sample
>> output
>> >> > doesn't clarify that. This is for the Puppet Module and JuJu Charm I
>> am
>> >> > developing with the help of RedHat and Canonical in OPNFV. I should
>> have
>> >> > Congress installed by default (for the RDO and JuJu installers) in
>> the
>> >> > OPNFV Colorado release in the next couple of weeks, and the
>> >> > congress.conf file settings are an open question. The Puppet module
>> will
>> >> > also be used to create a Fuel plugin for installation.
>> >> >
>> >> >
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Bryan Sullivan | AT&T
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >
>> __________________________________________________________________________
>> >> > 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
>> >> >
>> >>
>> >>
>> >> --
>> >> 室井 雅仁(Masahito MUROI)
>> >> Software Innovation Center, NTT
>> >> Tel: +81-422-59-4539
>> >>
>> >>
>> >>
>> >>
>> __________________________________________________________________________
>> >> 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
>> >
>>
>>
>> --
>> 室井 雅仁(Masahito MUROI)
>> Software Innovation Center, NTT
>> Tel: +81-422-59-4539
>>
>>
>>
>> __________________________________________________________________________
>> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160602/ae19ea6e/attachment.html>