<div dir="ltr">Bryan,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Here's the change in review, if you want to comment.</div><div><a href="https://review.openstack.org/#/c/324732/">https://review.openstack.org/#/c/324732/</a><br></div><div><br></div><div><div><span style="line-height:1.5">If you'd rather just have the Congress-specific config options, here's the text from that change.  </span></div><div><span style="line-height:1.5">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 </span><span style="line-height:1.5">otherwise you won't be able to create any datasources.  </span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">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?</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5"><begin text></span></div><div><br></div><div><span style="line-height:1.5">The options most important to Congress are described below, all of which</span><br></div><div>appear under the [DEFAULT] section of the configuration file.</div><div><br></div><div>``drivers``</div><div>    The list of permitted datasource drivers.  Default is the empty list.</div><div>    The list is a comma separated list of Python class paths. For example:</div><div>    drivers = congress.datasources.neutronv2_driver.NeutronV2Driver,congress.datasources.glancev2_driver.GlanceV2Driver</div><div><br></div><div>``datasource_sync_period``</div><div>    The number of seconds to wait between synchronizing datasource config</div><div>    from the database.  Default is 0.</div><div><br></div><div>``enable_execute_action``</div><div>    Whether or not congress will execute actions.  If false, Congress will</div><div>    never execute any actions to do manual reactive enforcement, even if there</div><div>    are policy statements that say actions should be executed and the</div><div>    conditions of those actions become true.  Default is True.</div><div><br></div><div>One of Congress's new experimental features is distributing its services</div><div>across multiple services and even hosts.  Here are the options for using</div><div>that feature.</div><div><br></div><div>``distributed_architecture``</div><div>    Whether to enable the distributed architecture.  Don't set it to true in</div><div>    before Newton release since the new architecture is still under</div><div>    development as of Newton.  Default is false.</div><div><br></div><div>``node_id``</div><div>    Unique ID of this Congress instance.  Can be any string.  Useful if</div><div>    you want to create multiple, distributed instances of Congress.</div><div><br></div><div>Here are the most often-used, but standard OpenStack options.  These</div><div>are specified in the [DEFAULT] section of the configuration file.</div><div><br></div><div>``auth_strategy``</div><div>    Method for authenticating Congress users.</div><div>    Can be assigned to either 'keystone' meaning that the user must provide</div><div>    Keystone credentials or to 'noauth' meaning that no authentication is</div><div>    required.  Default is 'keystone'.</div><div><br></div><div>``verbose``</div><div>    Controls whether the INFO-level of logging is enabled.  If false, logging</div><div>    level will be set to WARNING.  Default is false.  Deprecated.</div><div><br></div><div>``debug``</div><div>    Whether or not the DEBUG-level of logging is enabled. Default is false.</div></div><div><br></div><div><end text></div><div><br></div><div><br></div><div>Tim</div><div><br></div><div class="gmail_quote"><div dir="ltr">On Tue, May 31, 2016 at 10:18 AM Tim Hinrichs <<a href="mailto:tim@styra.com" target="_blank">tim@styra.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.</div><div dir="ltr"><div><br></div><div>Tim</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, May 30, 2016 at 12:49 AM Masahito MUROI <<a href="mailto:muroi.masahito@lab.ntt.co.jp" target="_blank">muroi.masahito@lab.ntt.co.jp</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Bryan,<br>
<br>
<br>
On 2016/05/28 2:52, Bryan Sullivan wrote:<br>
> Masahito,<br>
><br>
> Sorry, I'm not quite clear on the guidance. Sounds like you're saying<br>
> all options will be defaulted by Oslo.config if not set in the<br>
> congress.conf file. That's OK, if I understood.<br>
you're right.<br>
<br>
><br>
> It's clear to me that some will be deployment-specific.<br>
><br>
> But what I am asking is where is the spec for:<br>
> - what congress.conf fields are supported i.e. defined for possible<br>
> setting in a release<br>
Your generated congress.conf has a list of all supported config fields.<br>
<br>
> - which fields are mandatory to be set (or Congress will simply not work)<br>
> - which fields are not mandatory, but must be set for some specific<br>
> purpose, which right now is unclear<br>
Without deployment-specific configs, IIRC what you need to change from<br>
default only is "drivers" fields to run Congress with default setting.<br>
<br>
><br>
> I'm hoping the answer isn't "go look at the code"! That won't work for<br>
> end-users, who are looking to use Congress but not decipher the<br>
> meaning/importance of specific fields from the code.<br>
I guess your generated config has the purpose of each config fields.<br>
<br>
If you expect the spec means documents like [1], unfortunately Congress<br>
doesn't have these kind of document now.<br>
<br>
[1] <a href="http://docs.openstack.org/mitaka/config-reference/" rel="noreferrer" target="_blank">http://docs.openstack.org/mitaka/config-reference/</a><br>
<br>
best regards,<br>
Masahito<br>
<br>
><br>
> Thanks,<br>
> Bryan Sullivan<br>
><br>
>> From: <a href="mailto:muroi.masahito@lab.ntt.co.jp" target="_blank">muroi.masahito@lab.ntt.co.jp</a><br>
>> Date: Fri, 27 May 2016 15:40:31 +0900<br>
>> To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
>> Subject: Re: [openstack-dev] [congress] Spec for congress.conf<br>
>><br>
>> Hi Bryan,<br>
>><br>
>> Oslo.config that Congress uses to manage config sets each fields to<br>
>> default value if you don't specify your configured values in<br>
>> congress.conf. In that meaning, all config is option/required.<br>
>><br>
>> In my experience, config values differing from each deployment, like ip<br>
>> address and so on, have to be configured, but others might be configured<br>
>> when you want Congress to run with different behaviors.<br>
>><br>
>> best regard,<br>
>> Masahito<br>
>><br>
>> On 2016/05/27 3:36, SULLIVAN, BRYAN L wrote:<br>
>> > Hi Congress team,<br>
>> ><br>
>> ><br>
>> ><br>
>> > Quick question for anyone. Is there a spec for fields in congress.conf<br>
>> > file? As of Liberty this has to be tox-generated but I need to know<br>
>> > which conf values are required vs optional. The generated sample output<br>
>> > doesn't clarify that. This is for the Puppet Module and JuJu Charm I am<br>
>> > developing with the help of RedHat and Canonical in OPNFV. I should have<br>
>> > Congress installed by default (for the RDO and JuJu installers) in the<br>
>> > OPNFV Colorado release in the next couple of weeks, and the<br>
>> > congress.conf file settings are an open question. The Puppet module will<br>
>> > also be used to create a Fuel plugin for installation.<br>
>> ><br>
>> ><br>
>> ><br>
>> > Thanks,<br>
>> ><br>
>> > Bryan Sullivan | AT&T<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
> __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> ><br>
>><br>
>><br>
>> --<br>
>> 室井 雅仁(Masahito MUROI)<br>
>> Software Innovation Center, NTT<br>
>> Tel: +81-422-59-4539<br>
>><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
--<br>
室井 雅仁(Masahito MUROI)<br>
Software Innovation Center, NTT<br>
Tel: +81-422-59-4539<br>
<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></blockquote></div></div>