Open Stack

Hello Jay,

I agree with you.
In open contrail what we have done is there is no need to provision logical
routers.
1. create multiple networks
2. create policy of who can talk to whom.

We are proposing a extension called network policy which is used influence
traffic between the networks.
https://docs.google.com/document/d/1MEKx0InFlbsG7EyErCK4VOvxJwTj-LhVD9Zk14hQYOM/edit

We are also working on design which will do auto address management.

with these two features you could get what you want.


Regards
-Harshad


On Mon, Oct 14, 2013 at 6:26 AM, Jay Pipes <jaypipes at gmail.com> wrote:

> 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
>
>
>
> ______________________________**_________________
> Mailing list: http://lists.openstack.org/**cgi-bin/mailman/listinfo/**
> openstack <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack>
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/**cgi-bin/mailman/listinfo/**
> openstack <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20131014/589b6879/attachment.html>