Define a sharing model for external networks

Registered by Salvatore Orlando on 2013-05-16

As suggested in the discussion for bug 1165002, we are filing this blueprint for implementing a different approach concerning sharing of external networks.

Quoting Dan Wendlandt:
" I can see a desire to want to only expose certain external networks to certain tenants, but that was not the goal of the original design. I can see tracking this as a change we may want to do in the future, but I don't think we should track it as a bug, as it required non-trivial discussion around the right way to expose more flexible control of external networks, which to me suggests a blueprint."

Blueprint information

Status:
Complete
Approver:
Mark McClain
Priority:
Undefined
Drafter:
Salvatore Orlando
Direction:
Approved
Assignee:
Salvatore Orlando
Definition:
Obsolete
Series goal:
None
Implementation:
Not started
Milestone target:
None
Completed by
Salvatore Orlando on 2014-02-17

Related branches

Sprints

Whiteboard

---- Update 2013-08-12 ----
Untargeting as the community is proposing alternative approaches which might be more complete
---- End update --

There are two ways of approaching this problem:
1) Define a access delegation model for quantum, so that the tenant who owns a resource can specify which tenants are allowed to access that resource and how (GET/PUT/DELETE).
2) Leverage the current simple model of network sharing, and introduce a concept of 'shared external network'

While the approach #1 is surely interesting, it is probably not ideal to go down that route. There a lot of open questions, ranging from interactions with keystone, to changes needed into the data model, from security concerns about tenant being able to illicitly gain access to other tenant's resource, to relationships between access level on object wit the access level on a parent object (for instance does it make sense to grant another tenant read access to a port without granting read access to a network?)

To cut a long story short, approach #1 looks like a rabbit hole; also so far there has been no push from the user community in this direction

Approach #2 instead sounds more promising.
The differences between an external and a shared network are:
1) A gateway can be set only an ext net
2) Floating IPs can be created only on ext nets
3) Regular tenants have read only access to external networks, where as they have RW access to shared networks

Introducing a concept of 'shared external' network, 'standard' external networks will not enjoy of property #3.
In order to be visible to all tenants, they will have to be declared 'shared' too.
Note: as of today it is also possible to create a 'shared external' network, but the 'shared' setting won't change the behaviour of the network.

A 'shared external' network will behave exactly like 'external' networks today.

In order to ensure backward compatibility, a database migration will be required to set all the networks currently configured as shared as 'shared external'.

As a consequence some plugins (eg: nicira) will need to be aware of this change since they have different code paths for external networks.

------
UPDATE 2013-07-22
As no particular interested has been detected on this bp, I am proposing to untarget it from Havana.

(?)

Work Items