Re: [openstack-dev] [fuel] Fuel API settings reference

2015-06-24 Thread Oleg Gelbukh
Please, note the blueprint I created for the documentation feature [1]. There is also a linked blueprint to create a configuration reference document [2]. I targeted the blueprint to 'future', as we most likely won't be able to fit it into 7.0 cycle. I will start working on spec for the reference

Re: [openstack-dev] [fuel] Fuel API settings reference

2015-06-17 Thread Oleg Gelbukh
As this topic is getting some traction, I will register corresponding blueprint in Fuel and try to decompose the work based on what Andrew proposed. -- Best regards, Oleg Gelbukh On Tue, Jun 16, 2015 at 3:54 PM, Oleg Gelbukh ogelb...@mirantis.com wrote: Andrew, I've also noticed that

Re: [openstack-dev] [fuel] Fuel API settings reference

2015-06-16 Thread Oleg Gelbukh
Andrew, I've also noticed that incompatible changes are being introduced in JSON schemas for different objects in almost every release. I hope that explicit reference that lists and explains all parameters will discourage such modifications, or at least will increase their visibility and allow to

[openstack-dev] [fuel] Fuel API settings reference

2015-06-15 Thread Oleg Gelbukh
Good day, fellow fuelers Fuel API is a powerful tool that allow for very fine tuning of deployment settings and parameters, and we all know that UI exposes only a fraction of the full range of attributes client can pass to Fuel installer. However, there are very little documentation that

Re: [openstack-dev] [fuel] Fuel API settings reference

2015-06-15 Thread Andrew Woodward
I think there is some desire to see more documentation around here as there are some odd interactions with parts of the data payload, and perhaps documenting these may improve some of them. I think the gaps in order of most used are: * node object create / update * environment networks ( the fact

Re: [openstack-dev] [fuel] Fuel API settings reference

2015-06-15 Thread Przemyslaw Kaminski
Well, I suggest continuing https://review.openstack.org/#/c/179051/ It basically requires to update docstrings of handler functions according to [1]. This way the documentation is as close to the code as possible. With some work one could add automatic generation of docs out of JSONSchema