Open Stack

On 08/25/2015 03:01 AM, Miguel Angel Ajo wrote:
> 
> 
> Doug Wiegley wrote:
>>>> In general, the fight in Neutron *has* to be about common
>>>> definitions of networking primitives that can be potentially
>>>> implemented by multiple backends whenever possible.  That's the
>>>> entire point of Neutron.  I get that it's hard, but that's the value
>>>> Neutron brings to the table.
>>> I think that everyone agrees with you on this point.
>>
>>
>> Including me.
>>
>> The tricky part comes when the speed of neutron adding to the api
>> bottlenecks other things, or when the abstractions just aren’t there
>> yet, because the technology in question isn’t mature enough. Do we
>> provide relief valves, knowing they will be abused as much as help, or
>> do we hold a hard line? These tags are a relief valve.
>>
>> I’m in favor of them, and I’m in favor of holding to the abstraction.
>> It seems there has to be a middle ground.
>>
>> Thanks,
>> doug
>>
> 
> 
> Just thinking out loud:
> 
> Probably trying to stem the tie, would it make sense to block api calls
> outside neutron core/api to grab such tags, with a big warning: "if you
> try to circunvent this, you will harm interoperability of openstack, and
> your plugin will be blocked in next neutron releases"..
> 
> They could go directly via SQL, but at least, they'd know they're doing
> the wrong thing, and risking a plugin ban, if that's a reasonable
> measure from our side.

I don't think it's worth the effort or complexity to work too hard at
actively preventing it, but anything that helps make it clear to people
that it's considered private data (to anything but the API and DB) would
be nice.  We should be thinking of the people that are intending to play
nice, and make it so they don't accidentally use something we don't
intend to be used.

That's something we can hash out during code review or follow-up patches.

-- 
Russell Bryant