openstack team mailing list archive

[Tomoe Sugihara <tomoe@xxxxxxxxxxxx>]

Hi Salvatore,

I have a few questions regarding your proposal mostly related to L3 services.
I've read in another thread that L3 services are out of Quantum's scope for
Folsom, but I'd like to know how this public network model would work
with those services.


1. What are the assumptions for public networks?

 - How does VM on public network get internet connectivity? Would it
get private IP
   first and then floating IP associated with it just as legacy
nova+quantum network,
   or would public network get public IP connectivity directly?

 - What about the non-public networks? Would VMs on non-public
networks be able to
   get internet connectivity with floating ip and masquerading using
nova-network? Or
  they wouldn't get internet access because it's not public?


2. How ports in a public network for different tenants are isolated? or
not isolated at all?

 If I understand correctly, ports on the same quantum network should
get virtual L2
 connectivity (within a single broadcast domain). So I'm assuming that
ports on the same network
 are not isolated (unless security groups rules are enforced).
 But shouldn't those port be isolated? If so, wouldn't that cause semantic
change to quantum network?


Cheers,
Tomoe

On Thu, Jul 12, 2012 at 11:30 AM, Salvatore Orlando <sorlando@xxxxxxxxxx> wrote:
> Re-including openstack ML in the loop, as several Quantum contributors might
> not yet be registered to openstack-dev.
>
> Apologies for spamming.
>
> Salvatore
>
> ---------- Forwarded message ----------
> From: Yong Sheng Gong <gongysh@xxxxxxxxxx>
> Date: 11 July 2012 19:10
> Subject: Re: [Openstack] [Quantum] Public Network spec proposal
> To: Salvatore Orlando <sorlando@xxxxxxxxxx>
> Cc: openstack-dev@xxxxxxxxxxxxxxxxxxx
>
>
> See inline comments.
>
> Thanks
>
>
>
> -----Salvatore Orlando <sorlando@xxxxxxxxxx> wrote: -----
> To: Yong Sheng Gong/China/IBM@IBMCN
> From: Salvatore Orlando <sorlando@xxxxxxxxxx>
> Date: 07/12/2012 09:11AM
> Cc: openstack-dev@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Openstack] [Quantum] Public Network spec proposal
>
>
> Yong,
> thanks for your feedback. See my comments inline.
>
> Sorry for sending the previous email to the wrong list!
> Yong, thanks for fixing the recipients.
>
> On 11 July 2012 17:38, Yong Sheng Gong <gongysh@xxxxxxxxxx> wrote:
>>
>> Hi,
>> Thanks for the spec
>> Below is my understanding about it:
>>
>> About POST network:
>>
>> quantum net-create --tenant_id mynet --public True
>
>
> Sounds correct, but I think that the convention with boolean attributes is
> that if they're specified on the command line then they're true, otherwise
> false.
> so the above command could become:
>
> quantum net-create --tenant_id mynet --public
> [yong sheng gong] As you know, bool has just two values True or False, we
> should use three logic here, True, False or not specified.
> True mean we list only public networks, False means we show only private
> networks, not specified mean we don't care if the network is public or
> private.
>>
>>
>> About GET networks:
>>
>> qantum net-list --tenant_id myid
>> which should return all the networks owned by myid and public networks.
>> quantum net-list --tenant_id myid --public True
>> which should return only public networks.
>>
>> quantum net-list --tenant_id myid --public False
>> which should return  the non-public networks owned by myid.
>> quantum net-list
>> Which should return only public networks if there is no tenant_id in
>> context.
>
>
> I am still a bit undecided concerning the CLI syntax for this operation.
> My current thinking is:
>
> quantum net-list --tenant_id myid
> - return private networks for tenant my_id
> quantum net-list --public
> - return public networks (--tenant_id, if specified is ignored).
>
> The drawback is that we will need two calls for knowing all the networks,
> private and public, a tenant has access to. I have a similar dilemma in the
> filter discussion on the spec.
> What's your opinion?
> [yong sheng gong] with my three logics, we need only one call.
>
>>
>> About  subnets
>>
>> Only the public networks' owner can operate(create/list/show/update)
>> subnets for public network.
>
>
> Correct
>>
>> About create Port
>>
>> Public networks' owner can create port normally, I mean they can specify
>> fixed_ip, mac and other stuff.
>> Other tenant can create port under public network but he cannot specify
>> the fixed_ip, mac.  How fixed_ip and mac are populated?
>>
>> Are they still allocated auto just the same way when we create the normal
>> port?
>
>
> Correct, they are autogenerated.
>
>>
>> I think we can disallow other tenant to create port under public network.
>> If they need to use public network's ports, they can get them from public
>> network's owner.
>
>
> This would simplify a lot the authZ scenario. I am not sure whether this
> would work for our use cases.
> My concerns are:
> 1) If we restrict port creation to the owner of the network we would
> probably need the owner to "pre allocate" a number of ports for tenants to
> use
> [yong sheng gong] if not pre allocate, the port with specified ip will not
> work since customer tenant cannot create port with specified ip.
> 2) We should still allow the PUT operation to normal tenants, as they will
> set the device_id of the VM they've attached to the port.
> [yong sheng gong] Yes. PUT is should be allowed on device_id field of port
>
> Nevertheless, the proposed change to the design is valuable in my opinion,
> and I am very keen to hear what the other members of the community think of
> it.
>
>>
>> So the scenario looks like this:
>> 1. public owner creates public network
>> 2. public owner creates subnets under the public network
>> 3. public owner creates port,  with fixed_ip, mac and other stuff
>> populated.
>> 4. other tenant asks for using the port under the public network
>> 5. public owner assigns a port to the customer tenant
>
>
> Do you mean that in this step the ownership of the port object is give to
> the tenant?
> [Yong sheng gong] I think ownership is not given up. We just add one more
> field to record who is using this port. After that the 'quantum port-list
> --tenant_id' should also have --public options to show ports assigned to the
> tenant.
>
>>
>> 6. customer tenant associates its instance to the port. At this time, the
>> port's devise_id is populated
>>
>> With this scenario:
>> 1. nova integration
>> we can specify the ports when booting an instance.
>> so except nova boot --nic net-id=privatenetworkid,ipv4-ip=ip1
>> we have nova boot --nic port-id=portid.
>> where the portid can be a port under a public network and a port under a
>> private network.
>>
>> Thanks
>> Yong Sheng Gong
>>
>> -----openstack-bounces+gongysh=cn.ibm.com@xxxxxxxxxxxxxxxxxxx wrote: -----
>> To: openstack <openstack@xxxxxxxxxxxxxxxxxxx>
>> From: Salvatore Orlando
>> Sent by: openstack-bounces+gongysh=cn.ibm.com@xxxxxxxxxxxxxxxxxxx
>> Date: 07/12/2012 06:59AM
>> Subject: [Openstack] [Quantum] Public Network spec proposal
>>
>>
>> Hi,
>>
>> A proposal for the implementation of the public networks feature has been
>> published.
>> It can be reached from the quantum-v2-public-networks blueprint page [1].
>> Feedback is more than welcome!
>>
>> Regards,
>> Salvatore
>>
>> [1]:
>> https://blueprints.launchpad.net/quantum/+spec/quantum-v2-public-networks
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>