Thank you for the references! > -----Original Message----- > From: ext Ken'ichi Ohmichi [mailto:[email protected]] > Sent: Wednesday, August 19, 2015 2:48 AM ... > Is it difficult to make these properties upstream? > Vendor specific properties will make API different between clouds, and > that will make the interoperability difficult. > There was a defcore(interoperability) discussion also related to this: > http://lists.openstack.org/pipermail/defcore-committee/2015- > June/000849.html
I'm afraid that not all the currently used additional properties can be upstreamed as such (some of them contain e.g. references to vendor's own SW products) but we will probably discuss this possibility with the vendor in the future. > As the above mails, current schemas are blocking additional properties for > * (community devs) accidental additional properties without a new > microversion > * (interoperability) vendor-specific properties > > Technically, it is possible to relax this additional properties > validation on Tempest side because we have implemented similar feature > on Nova side[1]. > But before that, I'd like to know whether that is a right direction or not. > > Thanks > Ken Ohmichi > --- > [1]: https://review.openstack.org/#/c/193858/ IMO it is not a right direction to permanently relax additional properties validation (for the reasons mentioned above). Actually currently I have to update only the value of additionalProperties in few places. Of course, a common parameter like allow_additional_api_properties (or so) would ease the patching but let's see if somebody else is interested in it... -Viktor __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
