Open Stack

On Tue, Jul 17, 2012 at 7:39 PM, Tomoe Sugihara <tomoe at midokura.com> wrote:

> 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


Actually, for Folsom-3 we are working on a blueprint (
https://blueprints.launchpad.net/quantum/+spec/quantum-l3-fwd-nat) to
support the simple L3 and NAT/Floating-IP forwarding available in Nova
(plus a bit more flexibility).

Dan



> but I'd like to know how this publ 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 at nicira.com>
> 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 at cn.ibm.com>
> > Date: 11 July 2012 19:10
> > Subject: Re: [Openstack] [Quantum] Public Network spec proposal
> > To: Salvatore Orlando <sorlando at nicira.com>
> > Cc: openstack-dev at lists.openstack.org
> >
> >
> > See inline comments.
> >
> > Thanks
> >
> >
> >
> > -----Salvatore Orlando <sorlando at nicira.com> wrote: -----
> > To: Yong Sheng Gong/China/IBM at IBMCN
> > From: Salvatore Orlando <sorlando at nicira.com>
> > Date: 07/12/2012 09:11AM
> > Cc: openstack-dev at lists.openstack.org
> > 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 at cn.ibm.com> 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 at lists.launchpad.net wrote:
> -----
> >> To: openstack <openstack at lists.launchpad.net>
> >> From: Salvatore Orlando
> >> Sent by: openstack-bounces+gongysh=cn.ibm.com at lists.launchpad.net
> >> 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 at lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~openstack
> >> More help   : https://help.launchpad.net/ListHelp
> >
> >
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to     : openstack at lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120719/737787eb/attachment.html>