Open Stack

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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>