Re: [Openstack] Fwd: [Quantum] Public Network spec proposal

2012-07-19 Thread Dan Wendlandt 
On Tue, Jul 17, 2012 at 7:39 PM, Tomoe Sugihara to...@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 sorla...@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 gong...@cn.ibm.com
  Date: 11 July 2012 19:10
  Subject: Re: [Openstack] [Quantum] Public Network spec proposal
  To: Salvatore Orlando sorla...@nicira.com
  Cc: openstack-...@lists.openstack.org
 
 
  See inline comments.
 
  Thanks
 
 
 
  -Salvatore Orlando sorla...@nicira.com wrote: -
  To: Yong Sheng Gong/China/IBM@IBMCN
  From: Salvatore Orlando sorla...@nicira.com
  Date: 07/12/2012 09:11AM
  Cc: openstack-...@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 gong...@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

Re: [Openstack] Fwd: [Quantum] Public Network spec proposal

2012-07-19 Thread Tomoe Sugihara 
Hi Dan,

On Thu, Jul 19, 2012 at 11:58 PM, Dan Wendlandt d...@nicira.com wrote:


 On Tue, Jul 17, 2012 at 7:39 PM, Tomoe Sugihara to...@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 sorla...@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 gong...@cn.ibm.com
  Date: 11 July 2012 19:10
  Subject: Re: [Openstack] [Quantum] Public Network spec proposal
  To: Salvatore Orlando sorla...@nicira.com
  Cc: openstack-...@lists.openstack.org
 
 
  See inline comments.
 
  Thanks
 
 
 
  -Salvatore Orlando sorla...@nicira.com wrote: -
  To: Yong Sheng Gong/China/IBM@IBMCN
  From: Salvatore Orlando sorla...@nicira.com
  Date: 07/12/2012 09:11AM
  Cc: openstack-...@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 gong...@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?

Re: [Openstack] Fwd: [Quantum] Public Network spec proposal

2012-07-17 Thread Salvatore Orlando 
Gary,
I think your are making a very good point here.
It is true that the way in which the proposed design (and related patch in
gerrit) addresses only the 'model' problem at the API layer.
I think it is outside of the scope of this blueprint how the plugins, and
then more specifically their agents, should then react to a public
network as opposed to a private one.

I reckon Bob's part II' of the provider network problem is moving in the
right direction for addressing this problem by having an extension that
adds an attribute which will let the plugin implements the network
differently according to their nature (for instance flat vs
tagged). Another approach would be that plugins might leverage the public
attribute and automatically activate anti-spoofing rules on interfaces
attached to such networks. In both cases, it is my opinion that we can
address this problem with a separate blueprint.

Salvatore

On 14 July 2012 23:10, Gary Kotton gkot...@redhat.com wrote:

 **
 On 07/12/2012 06:39 PM, Salvatore Orlando wrote:

 Thank you again for your feedback.

  On the discussion about two or three-way logic, I understand Yong's
 point of being able to fetch public and private networks in one call, but I
 also I agree with Endre that using a boolean flag for something which is
 actually Yes/No/Whatever sounds confusing and is different by what the
 Openstack CLI usually does.

  Hence, if we have a large agreement on the need of being able to specify
 whether we want public networks, private networks or both, I'd go for the
 approach #3 in the design proposal, as suggested by Gary, and the CLI
 option would became something like --network_type={public|private|both}.

  On the agent issue raised by Gary - I'm afraid I don't understand. Gary,
 could you please elaborate more?


 The current implementation of the open source agents makes use of one
 network interface with the network isolation being done by vlan tagging. It
 may be required that a agent can connect to a public non secure network and
 a private secure network. The first layer of network isolation may be done
 by the physical network interfaces. The API that you are proposing enables
 the quantum service to provide the support, but what about the agents? Will
 the agents be able to differentiate between a private and public network.
 Taking this further will the agents be able to assign these networks to
 different network interfaces. Maybe it is not in the scope of the work that
 you are proposing.

 Thanks
 Gary




  Regards,
 Salvatore

 On 12 July 2012 05:37, Yong Sheng Gong gong...@cn.ibm.com wrote:


 If we just use one flag, it can represent just two values True or False.
 If we want to represent three values True, False or not specified, we have
 to use --public True or --public False or nothing at all.

 So it is a three-values logic.


 -openstack-bounces+gongysh=cn.ibm@lists.launchpad.net wrote:
 -
 To: openstack@lists.launchpad.net
 From: Endre Karlson
 Sent by: openstack-bounces+gongysh=cn.ibm@lists.launchpad.net
 Date: 07/12/2012 07:53PM
 Subject: [Openstack] Fwd: [Quantum] Public Network spec proposal


 Why not just --public or not ? Why do you need --public True ? That just
 adds confusion...

 Endre.


 2012/7/12 Gary Kotton gkot...@redhat.com

  Hi,
 1. Is this also applicable to the agents? Say for example a user wants
 to ensure that a public network is attached to network interface em1 and
 the private network attached to em2. Is this something that will be
 addressed by the blueprint?
 2. I prefer option #3. This seems to be a cleaner approach for the user
 interface.
 Thanks
 Gary


 On 07/12/2012 01:52 AM, Salvatore Orlando wrote:

  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@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp



 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp



 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Fwd: [Quantum] Public Network spec proposal

2012-07-17 Thread Salvatore Orlando 
Yong,

Regarding the comments you had on whether the owner of the public network
should own the ports attached on it as well, and kind of 'assign' them to
other tenants.
Although I recognize this as a viable approach, I do believe an approach in
which a tenant actually still owns the port even if it is on a public
network leads to a simpler model, as we won't need to add any attribute to
the existing model classes, and operations will still have the current
semantics. With the other approach, for instance, we would need to add an
attribute to port (something like 'assigned_to') and change the semantics
of index for ports in a way such that if net-id was a public network id it
should have returned the ports for which assigned-to matched the tenant,
instead of tenant-id.

On another note, the proposed approach allows for making the actual policy
enforce completely configurable. For instance, while by default we disallow
manipulation of mac and ips on public networks, the quantum admin can
change the policy by editing policy.json.
Similarly, the quantum administrators can decide that only a given subset
of users can plug VIFs into public networks, and it might also give to some
particular users, say power users the power of creating public networks.

Regards,
Salvatore

[fwd to openstack-dev - please ensure it is kept in the recipient list]





On 17 July 2012 15:04, Salvatore Orlando sorla...@nicira.com wrote:

 Gary,
 I think your are making a very good point here.
 It is true that the way in which the proposed design (and related patch in
 gerrit) addresses only the 'model' problem at the API layer.
 I think it is outside of the scope of this blueprint how the plugins, and
 then more specifically their agents, should then react to a public
 network as opposed to a private one.

 I reckon Bob's part II' of the provider network problem is moving in the
 right direction for addressing this problem by having an extension that
 adds an attribute which will let the plugin implements the network
 differently according to their nature (for instance flat vs
 tagged). Another approach would be that plugins might leverage the public
 attribute and automatically activate anti-spoofing rules on interfaces
 attached to such networks. In both cases, it is my opinion that we can
 address this problem with a separate blueprint.

 Salvatore

 On 14 July 2012 23:10, Gary Kotton gkot...@redhat.com wrote:

 **
 On 07/12/2012 06:39 PM, Salvatore Orlando wrote:

 Thank you again for your feedback.

  On the discussion about two or three-way logic, I understand Yong's
 point of being able to fetch public and private networks in one call, but I
 also I agree with Endre that using a boolean flag for something which is
 actually Yes/No/Whatever sounds confusing and is different by what the
 Openstack CLI usually does.

  Hence, if we have a large agreement on the need of being able to
 specify whether we want public networks, private networks or both, I'd go
 for the approach #3 in the design proposal, as suggested by Gary, and the
 CLI option would became something like --network_type={public|private|both}.

  On the agent issue raised by Gary - I'm afraid I don't understand.
 Gary, could you please elaborate more?


 The current implementation of the open source agents makes use of one
 network interface with the network isolation being done by vlan tagging. It
 may be required that a agent can connect to a public non secure network and
 a private secure network. The first layer of network isolation may be done
 by the physical network interfaces. The API that you are proposing enables
 the quantum service to provide the support, but what about the agents? Will
 the agents be able to differentiate between a private and public network.
 Taking this further will the agents be able to assign these networks to
 different network interfaces. Maybe it is not in the scope of the work that
 you are proposing.

 Thanks
 Gary




  Regards,
 Salvatore

 On 12 July 2012 05:37, Yong Sheng Gong gong...@cn.ibm.com wrote:


 If we just use one flag, it can represent just two values True or False.
 If we want to represent three values True, False or not specified, we have
 to use --public True or --public False or nothing at all.

 So it is a three-values logic.


 -openstack-bounces+gongysh=cn.ibm@lists.launchpad.net wrote:
 -
 To: openstack@lists.launchpad.net
 From: Endre Karlson
 Sent by: openstack-bounces+gongysh=cn.ibm@lists.launchpad.net
 Date: 07/12/2012 07:53PM
 Subject: [Openstack] Fwd: [Quantum] Public Network spec proposal


 Why not just --public or not ? Why do you need --public True ? That just
 adds confusion...

 Endre.


 2012/7/12 Gary Kotton gkot...@redhat.com

  Hi,
 1. Is this also applicable to the agents? Say for example a user wants
 to ensure that a public network is attached to network interface em1 and
 the private network attached to em2. Is this something that will be
 addressed by the blueprint?
 2

Re: [Openstack] Fwd: [Quantum] Public Network spec proposal

2012-07-17 Thread Tomoe Sugihara 
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 sorla...@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 gong...@cn.ibm.com
 Date: 11 July 2012 19:10
 Subject: Re: [Openstack] [Quantum] Public Network spec proposal
 To: Salvatore Orlando sorla...@nicira.com
 Cc: openstack-...@lists.openstack.org


 See inline comments.

 Thanks



 -Salvatore Orlando sorla...@nicira.com wrote: -
 To: Yong Sheng Gong/China/IBM@IBMCN
 From: Salvatore Orlando sorla...@nicira.com
 Date: 07/12/2012 09:11AM
 Cc: openstack-...@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 gong...@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

Re: [Openstack] Fwd: [Quantum] Public Network spec proposal

2012-07-15 Thread Gary Kotton 

On 07/12/2012 06:39 PM, Salvatore Orlando wrote:

Thank you again for your feedback.

On the discussion about two or three-way logic, I understand Yong's 
point of being able to fetch public and private networks in one call, 
but I also I agree with Endre that using a boolean flag for something 
which is actually Yes/No/Whatever sounds confusing and is different by 
what the Openstack CLI usually does.


Hence, if we have a large agreement on the need of being able to 
specify whether we want public networks, private networks or both, I'd 
go for the approach #3 in the design proposal, as suggested by Gary, 
and the CLI option would became something like 
--network_type={public|private|both}.


On the agent issue raised by Gary - I'm afraid I don't understand. 
Gary, could you please elaborate more?


The current implementation of the open source agents makes use of one 
network interface with the network isolation being done by vlan tagging. 
It may be required that a agent can connect to a public non secure 
network and a private secure network. The first layer of network 
isolation may be done by the physical network interfaces. The API that 
you are proposing enables the quantum service to provide the support, 
but what about the agents? Will the agents be able to differentiate 
between a private and public network. Taking this further will the 
agents be able to assign these networks to different network interfaces. 
Maybe it is not in the scope of the work that you are proposing.


Thanks
Gary




Regards,
Salvatore

On 12 July 2012 05:37, Yong Sheng Gong gong...@cn.ibm.com 
mailto:gong...@cn.ibm.com wrote:



If we just use one flag, it can represent just two values True or
False. If we want to represent three values True, False or not
specified, we have to use --public True or --public False or
nothing at all.

So it is a three-values logic.


-openstack-bounces+gongysh=cn.ibm@lists.launchpad.net
mailto:cn.ibm@lists.launchpad.net wrote: -
To: openstack@lists.launchpad.net
mailto:openstack@lists.launchpad.net
From: Endre Karlson
Sent by: openstack-bounces+gongysh=cn.ibm@lists.launchpad.net
mailto:openstack-bounces+gongysh=cn.ibm@lists.launchpad.net
Date: 07/12/2012 07:53PM
Subject: [Openstack] Fwd: [Quantum] Public Network spec proposal


Why not just --public or not ? Why do you need --public True ?
That just adds confusion...

Endre.


2012/7/12 Gary Kotton gkot...@redhat.com mailto:gkot...@redhat.com

Hi,
1. Is this also applicable to the agents? Say for example a
user wants to ensure that a public network is attached to
network interface em1 and the private network attached to em2.
Is this something that will be addressed by the blueprint?
2. I prefer option #3. This seems to be a cleaner approach for
the user interface.
Thanks
Gary


On 07/12/2012 01:52 AM, Salvatore Orlando wrote:

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
https://launchpad.net/%7Eopenstack

Post to : openstack@lists.launchpad.net
mailto:openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
https://launchpad.net/%7Eopenstack
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~openstack
https://launchpad.net/%7Eopenstack
Post to : openstack@lists.launchpad.net
mailto:openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
https://launchpad.net/%7Eopenstack
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~openstack
https://launchpad.net/%7Eopenstack
Post to : openstack@lists.launchpad.net
mailto:openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
https://launchpad.net/%7Eopenstack
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
https://launchpad.net/%7Eopenstack
Post to : openstack@lists.launchpad.net
mailto:openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
https://launchpad.net/%7Eopenstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Fwd: [Quantum] Public Network spec proposal

2012-07-12 Thread Endre Karlson 
Why not just --public or not ? Why do you need --public True ? That just
adds confusion...

Endre.


2012/7/12 Gary Kotton gkot...@redhat.com

 **
 Hi,
 1. Is this also applicable to the agents? Say for example a user wants to
 ensure that a public network is attached to network interface em1 and the
 private network attached to em2. Is this something that will be addressed
 by the blueprint?
 2. I prefer option #3. This seems to be a cleaner approach for the user
 interface.
 Thanks
 Gary


 On 07/12/2012 01:52 AM, Salvatore Orlando wrote:

 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@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp



 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Fwd: [Quantum] Public Network spec proposal

2012-07-12 Thread Yong Sheng Gong 
If we just use one flag, it can represent just two values True or False. If we want to represent three values True, False or not specified, we have to use --public True or --public False or nothing at all.So it is a three-values logic.-openstack-bounces+gongysh=cn.ibm@lists.launchpad.net wrote: -To: openstack@lists.launchpad.netFrom: Endre Karlson Sent by: openstack-bounces+gongysh=cn.ibm@lists.launchpad.netDate: 07/12/2012 07:53PMSubject: [Openstack] Fwd:  [Quantum] Public Network spec proposalWhy not just --public or not ? Why do you need --public True ? That just adds confusion...Endre.
2012/7/12 Gary Kotton gkot...@redhat.com


  

  
  
Hi,
1. Is this also applicable to the agents? Say for example a user
wants to ensure that a public network is attached to network
interface em1 and the private network attached to em2. Is this
something that will be addressed by the blueprint?
2. I prefer option #3. This seems to be a cleaner approach for the
user interface.
Thanks
Gary

On 07/12/2012 01:52 AM, Salvatore Orlando wrote:
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/~openstackPost to   : openstack@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstackMore help  : https://help.launchpad.net/ListHelp


  

___
Mailing list: https://launchpad.net/~openstack
Post to   : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help  : https://help.launchpad.net/ListHelp


___Mailing list: https://launchpad.net/~openstackPost to   : openstack@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstackMore help  : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Fwd: [Quantum] Public Network spec proposal

2012-07-12 Thread Salvatore Orlando 
Thank you again for your feedback.

On the discussion about two or three-way logic, I understand Yong's point
of being able to fetch public and private networks in one call, but I also
I agree with Endre that using a boolean flag for something which is
actually Yes/No/Whatever sounds confusing and is different by what the
Openstack CLI usually does.

Hence, if we have a large agreement on the need of being able to specify
whether we want public networks, private networks or both, I'd go for the
approach #3 in the design proposal, as suggested by Gary, and the CLI
option would became something like --network_type={public|private|both}.

On the agent issue raised by Gary - I'm afraid I don't understand. Gary,
could you please elaborate more?

Regards,
Salvatore

On 12 July 2012 05:37, Yong Sheng Gong gong...@cn.ibm.com wrote:


 If we just use one flag, it can represent just two values True or False.
 If we want to represent three values True, False or not specified, we have
 to use --public True or --public False or nothing at all.

 So it is a three-values logic.


 -openstack-bounces+gongysh=cn.ibm@lists.launchpad.net wrote: -
 To: openstack@lists.launchpad.net
 From: Endre Karlson **
 Sent by: openstack-bounces+gongysh=cn.ibm@lists.launchpad.net
 Date: 07/12/2012 07:53PM
 Subject: [Openstack] Fwd: [Quantum] Public Network spec proposal


 Why not just --public or not ? Why do you need --public True ? That just
 adds confusion...

 Endre.


 2012/7/12 Gary Kotton gkot...@redhat.com

 **
 Hi,
 1. Is this also applicable to the agents? Say for example a user wants to
 ensure that a public network is attached to network interface em1 and the
 private network attached to em2. Is this something that will be addressed
 by the blueprint?
 2. I prefer option #3. This seems to be a cleaner approach for the user
 interface.
 Thanks
 Gary


 On 07/12/2012 01:52 AM, Salvatore Orlando wrote:

 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@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp



 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp



 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp
 **

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] Fwd: [Quantum] Public Network spec proposal

2012-07-11 Thread Salvatore Orlando 
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 gong...@cn.ibm.com
Date: 11 July 2012 19:10
Subject: Re: [Openstack] [Quantum] Public Network spec proposal
To: Salvatore Orlando sorla...@nicira.com
Cc: openstack-...@lists.openstack.org


See inline comments.

Thanks



-Salvatore Orlando sorla...@nicira.com sorla...@nicira.com wrote:
-
To: Yong Sheng Gong/China/IBM@IBMCN
From: Salvatore Orlando sorla...@nicira.com sorla...@nicira.com
Date: 07/12/2012 09:11AM
Cc: openstack-...@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 gong...@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