<div dir="ltr">Hello Jay,<div><br></div><div style>I agree with you.</div><div style>In open contrail what we have done is there is no need to provision logical routers.</div><div style>1. create multiple networks</div><div style>
2. create policy of who can talk to whom.</div><div style><br></div><div style>We are proposing a extension called network policy which is used influence traffic between the networks.</div><div style><a href="https://docs.google.com/document/d/1MEKx0InFlbsG7EyErCK4VOvxJwTj-LhVD9Zk14hQYOM/edit">https://docs.google.com/document/d/1MEKx0InFlbsG7EyErCK4VOvxJwTj-LhVD9Zk14hQYOM/edit</a><br>
</div><div style><br></div><div style>We are also working on design which will do auto address management.</div><div style><br></div><div style>with these two features you could get what you want.</div><div style><br></div>
<div style><br></div><div style>Regards</div><div style>-Harshad</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Oct 14, 2013 at 6:26 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 10/14/2013 02:52 AM, Marco Fornaro wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Jay,<br>
<br>
Thanks for your answer<br>
<br>
BTW:<br>
<br>
About ”unecessarly complex” I do think more or less as you BUT<br>
<br>
It’s worth to mention that somebody in the list correctly answered:<br>
“we can have many networks, and the subnets within network can have<br>
overlap IPs.”<br>
</blockquote>
<br></div>
That actually is not related to my gripe :) Let me explain in a<br>
different way (apologies to Robert Collins, as he's already read all<br>
this in a separate conversation we've been having...)<br>
<br>
My gripe really is that the Neutron API is overly cumbersome compared to<br>
the previous networking API in Compute. I understand that there is more<br>
functionality (and good functionality!) in Neutron. I just rue the fact<br>
that the API has such a disconnected smell to it. Instead of dealing<br>
with the network as a single entity, with multiple ip ranges from which<br>
addresses are allocated, the API encourages a view of the subnet as<br>
separate from the network itself. Instead of manually creating "routers"<br>
in the API, the implementation could manage the router objects itself<br>
and hide the implementation entirely.<br>
<br>
For example, on the CLI level, instead of the existing series of:<br>
<br>
quantum net-create net1<br>
quantum router-create router1<br>
quantum subnet-create net1 <a href="http://10.0.0.0/8" target="_blank">10.0.0.0/8</a> --name=private1<br>
quantum subnet-create net1 <a href="http://172.20.1.0/20" target="_blank">172.20.1.0/20</a> --name=private2<br>
quantum router-gateway-set router1 public<br>
quantum router-interface-add router1 private1<br>
quantum router-interface-add router1 private2<br>
<br>
I would prefer something like this:<br>
<br>
quantum net-create private <a href="http://10.0.0.0/8" target="_blank">10.0.0.0/8</a><br>
quantum net-add-cidr private <a href="http://172.20.1.0/20" target="_blank">172.20.1.0/20</a><br>
quantum net-connect private public --cidrs=all<br>
<br>
The difference being:<br>
<br>
a) Much fewer API calls (which also means that the implementation can<br>
assure some level of transactional safety and atomicity between the<br>
connective operations)<br>
b) No mention of routers or gateways or interfaces -- the router itself<br>
is an object of implementation. The API should hide it entirely.<br>
c) If the tenant only wanted to set up a single private subnet (by far<br>
the most common tenant use case, from my experience), the entire network<br>
setup could be accomplished in a single call:<br>
<br>
quantum net-create private <a href="http://10.0.0.0/8" target="_blank">10.0.0.0/8</a> --connect-to=public<br>
<br>
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.<br>
<br>
Best,<br>
-jay<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack</a><br>
Post to : <a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack</a><br>
</div></div></blockquote></div><br></div>