On 12/08/2015 11:47 PM, Ken'ichi Ohmichi wrote:
> Hi Sylvain,
>
> 2015-12-04 17:48 GMT+09:00 Sylvain Bauza <sba...@redhat.com>:
>>>
>>> That leaves the out-of-tree discussion about custom filters and how we
>>> could have a consistent behaviour given that. Should we accept something in
>>> a specific deployment while another deployment could 401 against it ? Mmm,
>>> bad to me IMHO.
>>
>> We can have code to check the out-of-tree filters didn't expose any same
>> hints with in-tree filter.
>>
>> Sure, and thank you for that, that was missing in the past. That said, there
>> are still some interoperability concerns, let me explain : as a cloud
>> operator, I'm now providing a custom filter (say MyAwesomeFilter) which does
>> the lookup for an hint called 'my_awesome_hint'.
>>
>> If we enforce a strict validation (and not allow to accept any hint) it
>> would mean that this cloud would accept a request with 'my_awesome_hint'
>> while another cloud which wouldn't be running MyAwesomeFilter would then
>> deny the same request.
>
> I am thinking the operator/vendor own filter should have some
> implementation code for registering its original hint to jsonschema to
> expose/validate available hints in the future.
> The way should be easy as possible so that they can implement the code easily.
> After that, we will be able to make the validation strict again.
Yeh, that was my thinking. As someone that did a lot of the jsonschema
work, is that something you could prototype?
-Sean
--
Sean Dague
http://dague.net
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
