Open Stack

Indeed, "public" in our context means "shared among several tenants". We
are not dealing with tenant access to the Internet or direct association of
VIF to public IP addresses.

The basic model is still the 'guest network' model. This blueprint, for
which some code is already available on gerrit, just addresses the authZ
work necessary for ensuring multiple tenants can share the same network
object.

Salvatore

On 19 July 2012 17:03, Tomoe Sugihara <tomoe at midokura.com> wrote:

> Hi Dan,
>
> On Thu, Jul 19, 2012 at 11:58 PM, Dan Wendlandt <dan at nicira.com> wrote:
> >
> >
> > 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).
>
> Thanks for the info. This is very good to know.
> Now I'm assuming that *public* network just as the legacy network
> still get private IP prefix and they can have floating ip associated.
> Let me know if I'm missing something.
>
> Thanks,
> Tomoe
>
>
> >
> > 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/92f4ec33/attachment-0001.html>