<br><br><div class="gmail_quote">On Tue, Jul 17, 2012 at 7:39 PM, Tomoe Sugihara <span dir="ltr"><<a href="mailto:tomoe@midokura.com" target="_blank">tomoe@midokura.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Salvatore,<br>
<br>
I have a few questions regarding your proposal mostly related to L3 services.<br>
I've read in another thread that L3 services are out of Quantum's scope for<br>
Folsom</blockquote><div><br></div><div>Actually, for Folsom-3 we are working on a blueprint (<a href="https://blueprints.launchpad.net/quantum/+spec/quantum-l3-fwd-nat">https://blueprints.launchpad.net/quantum/+spec/quantum-l3-fwd-nat</a>) to support the simple L3 and NAT/Floating-IP forwarding available in Nova (plus a bit more flexibility). </div>
<div><br></div><div>Dan</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">but I'd like to know how this publ networks?<br>
<br>
- How does VM on public network get internet connectivity? Would it<br>
get private IP<br>
first and then floating IP associated with it just as legacy<br>
nova+quantum network,<br>
or would public network get public IP connectivity directly?<br>
<br>
- What about the non-public networks? Would VMs on non-public<br>
networks be able to<br>
get internet connectivity with floating ip and masquerading using<br>
nova-network? Or<br>
they wouldn't get internet access because it's not public?<br>
<br>
<br>
2. How ports in a public network for different tenants are isolated? or<br>
not isolated at all?<br>
<br>
If I understand correctly, ports on the same quantum network should<br>
get virtual L2<br>
connectivity (within a single broadcast domain). So I'm assuming that<br>
ports on the same network<br>
are not isolated (unless security groups rules are enforced).<br>
But shouldn't those port be isolated? If so, wouldn't that cause semantic<br>
change to quantum network?<br>
<br>
<br>
Cheers,<br>
Tomoe<br>
<div><div><br>
On Thu, Jul 12, 2012 at 11:30 AM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>> wrote:<br>
> Re-including openstack ML in the loop, as several Quantum contributors might<br>
> not yet be registered to openstack-dev.<br>
><br>
> Apologies for spamming.<br>
><br>
> Salvatore<br>
><br>
> ---------- Forwarded message ----------<br>
> From: Yong Sheng Gong <<a href="mailto:gongysh@cn.ibm.com" target="_blank">gongysh@cn.ibm.com</a>><br>
> Date: 11 July 2012 19:10<br>
> Subject: Re: [Openstack] [Quantum] Public Network spec proposal<br>
> To: Salvatore Orlando <<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>><br>
> Cc: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
><br>
><br>
> See inline comments.<br>
><br>
> Thanks<br>
><br>
><br>
><br>
> -----Salvatore Orlando <<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>> wrote: -----<br>
> To: Yong Sheng Gong/China/IBM@IBMCN<br>
> From: Salvatore Orlando <<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>><br>
> Date: 07/12/2012 09:11AM<br>
> Cc: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
> Subject: Re: [Openstack] [Quantum] Public Network spec proposal<br>
><br>
><br>
> Yong,<br>
> thanks for your feedback. See my comments inline.<br>
><br>
> Sorry for sending the previous email to the wrong list!<br>
> Yong, thanks for fixing the recipients.<br>
><br>
> On 11 July 2012 17:38, Yong Sheng Gong <<a href="mailto:gongysh@cn.ibm.com" target="_blank">gongysh@cn.ibm.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>> Thanks for the spec<br>
>> Below is my understanding about it:<br>
>><br>
>> About POST network:<br>
>><br>
>> quantum net-create --tenant_id mynet --public True<br>
><br>
><br>
> Sounds correct, but I think that the convention with boolean attributes is<br>
> that if they're specified on the command line then they're true, otherwise<br>
> false.<br>
> so the above command could become:<br>
><br>
> quantum net-create --tenant_id mynet --public<br>
> [yong sheng gong] As you know, bool has just two values True or False, we<br>
> should use three logic here, True, False or not specified.<br>
> True mean we list only public networks, False means we show only private<br>
> networks, not specified mean we don't care if the network is public or<br>
> private.<br>
>><br>
>><br>
>> About GET networks:<br>
>><br>
>> qantum net-list --tenant_id myid<br>
>> which should return all the networks owned by myid and public networks.<br>
>> quantum net-list --tenant_id myid --public True<br>
>> which should return only public networks.<br>
>><br>
>> quantum net-list --tenant_id myid --public False<br>
>> which should return the non-public networks owned by myid.<br>
>> quantum net-list<br>
>> Which should return only public networks if there is no tenant_id in<br>
>> context.<br>
><br>
><br>
> I am still a bit undecided concerning the CLI syntax for this operation.<br>
> My current thinking is:<br>
><br>
> quantum net-list --tenant_id myid<br>
> - return private networks for tenant my_id<br>
> quantum net-list --public<br>
> - return public networks (--tenant_id, if specified is ignored).<br>
><br>
> The drawback is that we will need two calls for knowing all the networks,<br>
> private and public, a tenant has access to. I have a similar dilemma in the<br>
> filter discussion on the spec.<br>
> What's your opinion?<br>
> [yong sheng gong] with my three logics, we need only one call.<br>
><br>
>><br>
>> About subnets<br>
>><br>
>> Only the public networks' owner can operate(create/list/show/update)<br>
>> subnets for public network.<br>
><br>
><br>
> Correct<br>
>><br>
>> About create Port<br>
>><br>
>> Public networks' owner can create port normally, I mean they can specify<br>
>> fixed_ip, mac and other stuff.<br>
>> Other tenant can create port under public network but he cannot specify<br>
>> the fixed_ip, mac. How fixed_ip and mac are populated?<br>
>><br>
>> Are they still allocated auto just the same way when we create the normal<br>
>> port?<br>
><br>
><br>
> Correct, they are autogenerated.<br>
><br>
>><br>
>> I think we can disallow other tenant to create port under public network.<br>
>> If they need to use public network's ports, they can get them from public<br>
>> network's owner.<br>
><br>
><br>
> This would simplify a lot the authZ scenario. I am not sure whether this<br>
> would work for our use cases.<br>
> My concerns are:<br>
> 1) If we restrict port creation to the owner of the network we would<br>
> probably need the owner to "pre allocate" a number of ports for tenants to<br>
> use<br>
> [yong sheng gong] if not pre allocate, the port with specified ip will not<br>
> work since customer tenant cannot create port with specified ip.<br>
> 2) We should still allow the PUT operation to normal tenants, as they will<br>
> set the device_id of the VM they've attached to the port.<br>
> [yong sheng gong] Yes. PUT is should be allowed on device_id field of port<br>
><br>
> Nevertheless, the proposed change to the design is valuable in my opinion,<br>
> and I am very keen to hear what the other members of the community think of<br>
> it.<br>
><br>
>><br>
>> So the scenario looks like this:<br>
>> 1. public owner creates public network<br>
>> 2. public owner creates subnets under the public network<br>
>> 3. public owner creates port, with fixed_ip, mac and other stuff<br>
>> populated.<br>
>> 4. other tenant asks for using the port under the public network<br>
>> 5. public owner assigns a port to the customer tenant<br>
><br>
><br>
> Do you mean that in this step the ownership of the port object is give to<br>
> the tenant?<br>
> [Yong sheng gong] I think ownership is not given up. We just add one more<br>
> field to record who is using this port. After that the 'quantum port-list<br>
> --tenant_id' should also have --public options to show ports assigned to the<br>
> tenant.<br>
><br>
>><br>
>> 6. customer tenant associates its instance to the port. At this time, the<br>
>> port's devise_id is populated<br>
>><br>
>> With this scenario:<br>
>> 1. nova integration<br>
>> we can specify the ports when booting an instance.<br>
>> so except nova boot --nic net-id=privatenetworkid,ipv4-ip=ip1<br>
>> we have nova boot --nic port-id=portid.<br>
>> where the portid can be a port under a public network and a port under a<br>
>> private network.<br>
>><br>
>> Thanks<br>
>> Yong Sheng Gong<br>
>><br>
>> -----openstack-bounces+gongysh=<a href="mailto:cn.ibm.com@lists.launchpad.net" target="_blank">cn.ibm.com@lists.launchpad.net</a> wrote: -----<br>
>> To: openstack <<a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a>><br>
>> From: Salvatore Orlando<br>
>> Sent by: openstack-bounces+gongysh=<a href="mailto:cn.ibm.com@lists.launchpad.net" target="_blank">cn.ibm.com@lists.launchpad.net</a><br>
>> Date: 07/12/2012 06:59AM<br>
>> Subject: [Openstack] [Quantum] Public Network spec proposal<br>
>><br>
>><br>
>> Hi,<br>
>><br>
>> A proposal for the implementation of the public networks feature has been<br>
>> published.<br>
>> It can be reached from the quantum-v2-public-networks blueprint page [1].<br>
>> Feedback is more than welcome!<br>
>><br>
>> Regards,<br>
>> Salvatore<br>
>><br>
>> [1]:<br>
>> <a href="https://blueprints.launchpad.net/quantum/+spec/quantum-v2-public-networks" target="_blank">https://blueprints.launchpad.net/quantum/+spec/quantum-v2-public-networks</a><br>
>> _______________________________________________<br>
>> Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>> Post to : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
>> Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>> More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
> Post to : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
> Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
> More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
><br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br><div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div><br>