Open Stack

On 10/14/2013 02:52 AM, Marco Fornaro wrote:
> Hi Jay,
>
> Thanks for your answer
>
> BTW:
>
> About ”unecessarly complex” I do think more or less as you BUT
>
> It’s worth to mention that somebody in the list correctly answered:
> “we can have many networks, and the subnets within network can have
> overlap IPs.”

That actually is not related to my gripe :) Let me explain in a
different way (apologies to Robert Collins, as he's already read all
this in a separate conversation we've been having...)

My gripe really is that the Neutron API is overly cumbersome compared to
the previous networking API in Compute. I understand that there is more
functionality (and good functionality!) in Neutron. I just rue the fact
that the API has such a disconnected smell to it. Instead of dealing
with the network as a single entity, with multiple ip ranges from which
addresses are allocated, the API encourages a view of the subnet as
separate from the network itself. Instead of manually creating "routers"
in the API, the implementation could manage the router objects itself
and hide the implementation entirely.

For example, on the CLI level, instead of the existing series of:

quantum net-create net1
quantum router-create router1
quantum subnet-create net1 10.0.0.0/8 --name=private1
quantum subnet-create net1 172.20.1.0/20 --name=private2
quantum router-gateway-set router1 public
quantum router-interface-add router1 private1
quantum router-interface-add router1 private2

I would prefer something like this:

quantum net-create private 10.0.0.0/8
quantum net-add-cidr private 172.20.1.0/20
quantum net-connect private public --cidrs=all

The difference being:

a) Much fewer API calls (which also means that the implementation can
assure some level of transactional safety and atomicity between the
connective operations)
b) No mention of routers or gateways or interfaces -- the router itself
is an object of implementation. The API should hide it entirely.
c) If the tenant only wanted to set up a single private subnet (by far
the most common tenant use case, from my experience), the entire network
setup could be accomplished in a single call:

quantum net-create private 10.0.0.0/8 --connect-to=public

APIs that are complex and expose implementation details are prone to 
errors. Simpler APIs that hide those implementation details tend to be 
less abused and more understood.

Best,
-jay