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 <[email protected]> wrote: > 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 > understand justifications for them. > > -- > Best regards, > Oleg Gelbukh > > On Mon, Jun 15, 2015 at 4:21 PM, Andrew Woodward <[email protected]> > wrote: > >> 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 that metadata cant be updated kills me) >> * environment settings (the separate api for hidden and non kills me) >> * release update >> * role add/update >> >> After these are updated I think we can move on to common but less used >> * node interface assignment >> * node disk assignment >> >> >> >> On Mon, Jun 15, 2015 at 8:09 AM Oleg Gelbukh <[email protected]> >> wrote: >> >>> 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 explains what settings >>> are accepted by Fuel objects, what are they meanings and what is their >>> syntax. There is a main reference document for API [1], but it does give >>> almost no insight into payload of parameters that every entity accepts. >>> Which are they and what they for seems to be mostly scattered as a tribal >>> knowledge. >>> >>> I would like to understand if there is a need in such a document among >>> developers and deployers who consume Fuel API? Or might be there is already >>> such document or effort to create it going on? >>> >>> -- >>> Best regards, >>> Oleg Gelbukh >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> -- >> -- >> Andrew Woodward >> Mirantis >> Fuel Community Ambassador >> Ceph Community >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
