<div dir="ltr">Andreas,<div><br></div><div>I would advocate for NOT moving flagmappings files to individual project repositories. Having worked out recently how configuration tables are generated and was able to generate them myself I considered how to improve the process in relation to using the existing oslo.config generation tools.</div><div><br></div><div>The primary reason for not moving the flagmappings file is you are then dependent on the projects review cycle (and processes) to get these changes approved. This includes the load on the gate, and applicable +2 by cores (which on major projects have their own priorities for features) etc. I would not like to see documentation generation data dependent on all applicable projects.</div><div><br></div><div>I see the bigger issue is the current process for generating the config guides including the frequency and accuracy during the cycle.</div><div><br></div><div>In a nutshell, it's a huge pull process, where at some time somebody runs the tools which pulls in all projects, and dependencies and uses a doc specific version to identify all the config options, merge with flagmappings and produce configuration tables.</div><div><br></div><div>Ideally, a more optimal means is to create a push process, that is, if any configuration settings changes within a project during a commit, this data change is pushed, so that the documentation can be updated accordingly when applicable. Nice in theory, in practice it's more complex. Some high level thoughts on the process.</div><div><br></div><div>Some projects now can generate a sample configuration file (tox -egenconfig). In Oslo we are hoping to increase this usage, and use the developer docs as a place to store these files within a project repo.</div><div>Leveraging this existing functionality, if we could detect a change in the sample configuration file during a review commit, then we have the notification process (keystone already has a bot that does this) that is the basic information trigger of a new change needed in docs for config.</div><div>Now, what is that change of configuration is more complex, and it would seem a logical necessity to use a neutral format (e.g. yaml) to record the parsed configuration options, and enable this format to be saved somewhere/somehow. This becomes both the input to the oslo.config generator (i.e. we effectively take current functionality and split it into two parts, the parsing of configuration options into yaml format, and the generation of sample config files, and developer docs sphinx extensions using the yaml format. The yaml data also forms the basis of data for the configuration guide. </div><div>One may argue why break up the oslo.config work because it's working, well because the inputs are used to generate multiple forms of documentation and at present only some forms are being used.</div><div><br></div><div>I am certainly not familiar with the infra work for bots, and how within a gate to create, propose and commit work of a produced yaml file, or change in yaml file.</div><div><br></div><div>It does seem like this could be a lot of work, but it's the foundation of converging the work the documentation team does with tools that exist for the development side, as well as reducing the tool complexity that exists in doc tools now.</div><div><br></div><div><br></div><div>Regards</div><div><br></div><div>Ronald <br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div><div style="font-family:arial;font-size:small">Ronald Bradford</div><div style="font-family:arial;font-size:small"><br></div><span style="color:rgb(102,102,102)">Web Site: </span><a style="color:rgb(102,102,102)" href="http://ronaldbradford.com/" target="_blank">http://ronaldbradford.com</a><br style="color:rgb(102,102,102)">
<span style="color:rgb(102,102,102)">LinkedIn: </span><a style="color:rgb(102,102,102)" href="http://www.linkedin.com/in/ronaldbradford" target="_blank">http://www.linkedin.com/in/ronaldbradford</a><br><span style="color:rgb(102,102,102)">Twitter: </span><a style="color:rgb(102,102,102)" href="http://twitter.com/ronaldbradford" target="_blank">@RonaldBradford</a><br>
<span style="color:rgb(102,102,102)">Skype: RonaldBradford</span><div><span style="color:rgb(102,102,102)">GTalk: Ronald.Bradford<br></span><div><span style="color:rgb(102,102,102)">IRC: rbradfor<br></span><br></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, May 10, 2016 at 9:34 AM, sohan sangwan <span dir="ltr"><<a href="mailto:sohaninfo@gmail.com" target="_blank">sohaninfo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi Andreas,<br><br></div>Thank you for your response.<br><br>I have around 10 years work experience. I have got work experience in database internals, enterprise search engine, and data visulizations. I have earlier worked on Open Source Projects like PostgreSQL and MySQL. <br><br>I am currently working on OpenStack technology in my company . I do have interest in Identity and access management (IAM). I am very much interested to support Single Sign-On for multiple(OpenStack) clouds in Horizon. <br><br></div>I am also interested to improve OpenStack documentations. While configuring Keystone for Federations I faced many issues. After successful configurations I realized that the documentation of OpenStack has a scope for improvement.<br><br><div><br></div><div>Thanks and regards,<br></div><div>Sohan<br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 10, 2016 at 4:44 PM, Andreas Jaeger <span dir="ltr"><<a href="mailto:aj@suse.com" target="_blank">aj@suse.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 2016-05-10 11:10, sohan sangwan wrote:<br>
> Hi Andreas,<br>
><br>
</span><span>> Thank you for your email.<br>
><br>
> I do not know current Config Reference creation works.<br>
><br>
> I am sorry I do not understand all the requirements. I would be happy if<br>
> I could be assigned some small task.<br>
> I woul be glad to do that so that I could also learn.<br>
><br>
> Appreicate your help!<br>
><br>
<br>
</span>Sohan, plesae tell us a bit more about you and how you want to help and<br>
I hope that then somebody can propose a few projects.<br>
<br>
Also, read the current specs and discussion on the mailing list - and<br>
speak up where you want to help,<br>
<br>
Andreas<br>
<span><font color="#888888">--<br>
</font></span><div><div> Andreas Jaeger aj@{<a href="http://suse.com" rel="noreferrer" target="_blank">suse.com</a>,<a href="http://opensuse.org" rel="noreferrer" target="_blank">opensuse.org</a>} Twitter: jaegerandi<br>
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany<br>
GF: Felix Imendörffer, Jane Smithard, Graham Norton,<br>
HRB 21284 (AG Nürnberg)<br>
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126<br>
<br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-docs mailing list<br>
<a href="mailto:OpenStack-docs@lists.openstack.org">OpenStack-docs@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs</a><br>
<br></blockquote></div><br></div>