[Netstack] Exception in network-refactoring-l2 branch

[Sumit Naiksatam (snaiksat)]

Hi Ryu,

I am seeing the following exception when starting a VM, any clue as to
what might be going wrong in my setup?

Thanks,
~Sumit.

nova-compute.log:
2011-07-19 20:29:13,287 DEBUG nova.rpc [-] received
{u'_context_request_id': u'15OCH-PML6F3OL-761VR',
u'_context_read_deleted': False, u'args': {u'instance_id': 5,
u'request_spec': {u'instance_properties': {u'state_description':
u'scheduling', u'availability_zone': None, u'ramdisk_id': u'',
u'instance_type_id': 5, u'user_data': u'', u'vm_mode': None,
u'reservation_id': u'r-jyimozmu', u'root_device_name': None, u'user_id':
u'root', u'display_description': None, u'key_data': None, u'state': 0,
u'project_id': u'test01', u'metadata': {}, u'kernel_id': 812452923,
u'key_name': None, u'display_name': None, u'local_gb': 20, u'locked':
False, u'launch_time': u'2011-07-20T03:29:12Z', u'memory_mb': 2048,
u'vcpus': 1, u'image_ref': 1920976922, u'architecture': None,
u'os_type': None}, u'instance_type': {u'rxtx_quota': 0, u'deleted_at':
None, u'name': u'm1.small', u'deleted': False, u'created_at': None,
u'updated_at': None, u'memory_mb': 2048, u'vcpus': 1, u'rxtx_cap': 0,
u'extra_specs': {}, u'swap': 0, u'flavorid': 2, u'id': 5, u'local_gb':
20}, u'num_instances': 1, u'filter':
u'nova.scheduler.host_filter.InstanceTypeFilter', u'blob': None},
u'admin_password': None, u'injected_files': None, u'availability_zone':
None}, u'_context_is_admin': True, u'_context_timestamp':
u'2011-07-20T03:29:12Z', u'_context_user': u'root', u'method':
u'run_instance', u'_context_project': u'test01',
u'_context_remote_address': u'171.71.118.93'} from (pid=12768)
process_data
/root/sw/openstack/src/nova/network-refactoring-l2/nova/rpc.py:202
2011-07-19 20:29:13,288 DEBUG nova.rpc [-] unpacked context:
{'timestamp': u'2011-07-20T03:29:12Z', 'msg_id': None, 'remote_address':
u'171.71.118.93', 'project': u'test01', 'is_admin': True, 'user':
u'root', 'request_id': u'15OCH-PML6F3OL-761VR', 'read_deleted': False}
from (pid=12768) _unpack_context
/root/sw/openstack/src/nova/network-refactoring-l2/nova/rpc.py:451
2011-07-19 20:29:13,353 AUDIT nova.compute.manager [15OCH-PML6F3OL-761VR
root test01] instance 5: starting...
2011-07-19 20:29:13,527 DEBUG nova.rpc [-] Making asynchronous call on
network ... from (pid=12768) multicall
/root/sw/openstack/src/nova/network-refactoring-l2/nova/rpc.py:481
2011-07-19 20:29:13,528 DEBUG nova.rpc [-] MSG_ID is
4671af66587741978050ce73c54a3827 from (pid=12768) multicall
/root/sw/openstack/src/nova/network-refactoring-l2/nova/rpc.py:484
2011-07-19 20:29:14,065 ERROR nova [-] Exception during message handling
(nova): TRACE: Traceback (most recent call last):
(nova): TRACE:   File
"/root/sw/openstack/src/nova/network-refactoring-l2/nova/rpc.py", line
232, in _process_data
(nova): TRACE: rval = node_func(context=ctxt, **node_args)
(nova): TRACE:   File
"/root/sw/openstack/src/nova/network-refactoring-l2/nova/exception.py",
line 97, in wrapped
(nova): TRACE: return f(*args, **kw)
(nova): TRACE:   File
"/root/sw/openstack/src/nova/network-refactoring-l2/nova/compute/manager
.py", line 338, in run_instance
(nova): TRACE: self._run_instance(context, instance_id, **kwargs)
(nova): TRACE:   File
"/root/sw/openstack/src/nova/network-refactoring-l2/nova/compute/manager
.py", line 300, in _run_instance
(nova): TRACE: instance, vpn=is_vpn)
(nova): TRACE:   File
"/root/sw/openstack/src/nova/network-refactoring-l2/nova/network/api.py"
, line 144, in allocate_for_instance
(nova): TRACE: 'args': args})
(nova): TRACE:   File
"/root/sw/openstack/src/nova/network-refactoring-l2/nova/rpc.py", line
546, in call
(nova): TRACE: rv = list(rv)
(nova): TRACE:   File
"/root/sw/openstack/src/nova/network-refactoring-l2/nova/rpc.py", line
535, in wait
(nova): TRACE: raise result
(nova): TRACE: RemoteError: UnboundLocalError local variable 'ip'
referenced before assignment
(nova): TRACE: [u'Traceback (most recent call last):\n', u'  File
"/root/sw/openstack/src/nova/network-refactoring-l2/nova/rpc.py", line
232, in _process_data\nrval = node_func(context=ctxt,
**node_args)\n', u'  File
"/root/sw/openstack/src/nova/network-refactoring-l2/nova/network/manager
.py", line 384, in allocate_for_instance\nreturn
self.get_instance_nw_info(context, instance_id, type_id)\n', u'  File
"/root/sw/openstack/src/nova/network-refactoring-l2/nova/network/manager
.py", line 459, in get_instance_nw_info\ninfo[\'ip6s\'] =
[ip6_dict()]\n', u'  File
"/root/sw/openstack/src/nova/network-refactoring-l2/nova/network/manager
.py", line 439, in ip6_dict\nnetwork[\'project_id\']),\n', u'  File
"/root/sw/openstack/src/nova/network-refactoring-l2/nova/ipv6/api.py",
line 35, in to_global\nreturn IMPL.to_global(prefix, mac,
project_id)\n', u'  File
"/root/sw/openstack/src/nova/network-refactoring-l2/nova/ipv6/rfc2462.py
", line 30, in to_global\nmaskIP = netaddr.IPNetwork(prefix).ip\n',
u'  File
"/root/sw/openstack/src/nova/network-refactoring-l2/.nova-venv/lib/pytho
n2.6/

Re: [Netstack] Exception in network-refactoring-l2 branch

[Sumit Naiksatam (snaiksat)]

Thanks Deepak, Ryu, and Dan, for your timely responses. As Deepak
pointed out, there was a non-NULL value in the cidr_v6 column which was
creating this issue. Since the default behavior is to not process ipv6,
I did not think that the implementation would be looking at this value.
However, it seems like even in that case, the system does look at this.
Setting it to NULL helped get past this.

 

Thanks,

~Sumit.

 

From: Deepak N [mailto:dee...@thoughtworks.com] 
Sent: Tuesday, July 19, 2011 11:39 PM
To: Sumit Naiksatam (snaiksat)
Cc: Ishimoto, Ryu; netstack@lists.launchpad.net
Subject: Re: [Netstack] Exception in network-refactoring-l2 branch

 

Hi,

 

Noticed the exception "UnboundLocalError: local variable 'ip' referenced
before assignment" in the logs. Usually see this exception in netaddr
when cidr is invalid.

Just check if cidr_v6 of the network is not empty or in invalid format.
if you're not using v6 addresses you may need to disable ipv6 in your
setup.

 

On Wed, Jul 20, 2011 at 9:22 AM, Sumit Naiksatam (snaiksat)
 wrote:

Hi Ryu,

I am seeing the following exception when starting a VM, any clue as to
what might be going wrong in my setup?

Thanks,
~Sumit.

nova-compute.log:
2011-07-19 20:29:13,287 DEBUG nova.rpc [-] received
{u'_context_request_id': u'15OCH-PML6F3OL-761VR',
u'_context_read_deleted': False, u'args': {u'instance_id': 5,
u'request_spec': {u'instance_properties': {u'state_description':
u'scheduling', u'availability_zone': None, u'ramdisk_id': u'',
u'instance_type_id': 5, u'user_data': u'', u'vm_mode': None,
u'reservation_id': u'r-jyimozmu', u'root_device_name': None, u'user_id':
u'root', u'display_description': None, u'key_data': None, u'state': 0,
u'project_id': u'test01', u'metadata': {}, u'kernel_id': 812452923,
u'key_name': None, u'display_name': None, u'local_gb': 20, u'locked':
False, u'launch_time': u'2011-07-20T03:29:12Z', u'memory_mb': 2048,
u'vcpus': 1, u'image_ref': 1920976922, u'architecture': None,
u'os_type': None}, u'instance_type': {u'rxtx_quota': 0, u'deleted_at':
None, u'name': u'm1.small', u'deleted': False, u'created_at': None,
u'updated_at': None, u'memory_mb': 2048, u'vcpus': 1, u'rxtx_cap': 0,
u'extra_specs': {}, u'swap': 0, u'flavorid': 2, u'id': 5, u'local_gb':
20}, u'num_instances': 1, u'filter':
u'nova.scheduler.host_filter.InstanceTypeFilter', u'blob': None},
u'admin_password': None, u'injected_files': None, u'availability_zone':
None}, u'_context_is_admin': True, u'_context_timestamp':
u'2011-07-20T03:29:12Z', u'_context_user': u'root', u'method':
u'run_instance', u'_context_project': u'test01',
u'_context_remote_address': u'171.71.118.93'} from (pid=12768)
process_data
/root/sw/openstack/src/nova/network-refactoring-l2/nova/rpc.py:202
2011-07-19 20:29:13,288 DEBUG nova.rpc [-] unpacked context:
{'timestamp': u'2011-07-20T03:29:12Z', 'msg_id': None, 'remote_address':
u'171.71.118.93', 'project': u'test01', 'is_admin': True, 'user':
u'root', 'request_id': u'15OCH-PML6F3OL-761VR', 'read_deleted': False}
from (pid=12768) _unpack_context
/root/sw/openstack/src/nova/network-refactoring-l2/nova/rpc.py:451
2011-07-19 20:29:13,353 AUDIT nova.compute.manager [15OCH-PML6F3OL-761VR
root test01] instance 5: starting...
2011-07-19 20:29:13,527 DEBUG nova.rpc [-] Making asynchronous call on
network ... from (pid=12768) multicall
/root/sw/openstack/src/nova/network-refactoring-l2/nova/rpc.py:481
2011-07-19 20:29:13,528 DEBUG nova.rpc [-] MSG_ID is
4671af66587741978050ce73c54a3827 from (pid=12768) multicall
/root/sw/openstack/src/nova/network-refactoring-l2/nova/rpc.py:484
2011-07-19 20:29:14,065 ERROR nova [-] Exception during message handling
(nova): TRACE: Traceback (most recent call last):
(nova): TRACE:   File
"/root/sw/openstack/src/nova/network-refactoring-l2/nova/rpc.py", line
232, in _process_data
(nova): TRACE: rval = node_func(context=ctxt, **node_args)
(nova): TRACE:   File
"/root/sw/openstack/src/nova/network-refactoring-l2/nova/exception.py",
line 97, in wrapped
(nova): TRACE: return f(*args, **kw)
(nova): TRACE:   File
"/root/sw/openstack/src/nova/n

[Netstack] libvirt template (in network-refactoring-l2 branch)

[Sumit Naiksatam (snaiksat)]

Hi Ryu,

Wanted to point out a small change required in the 802.1Qbh template, it
should be:

 
 
 
 
 
 

Notice that the place holders should have a "'" around them, which is
missing in the current template.

I can make this change and checkin, or else if it's more convenient, you
can do it as well.

Thanks,
~Sumit.

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

[Netstack] "network-refactoring-l2" branch, and Quantum

[Sumit Naiksatam (snaiksat)]

Hi Ryu, Dan, and others involved,

I had some questions regarding how the code base in the
"network-refactoring-l2" branch currently works (or is supposed to) with
Quantum.

As I understand, eventually we want to get to a point where one should
be able to run the Quantum service instead of the nova-network service.
However, we are not there yet. Currently one still needs to run the
nova-network service in order to be able create the network on the nova
side of things. If this understanding is correct, here are few thoughts
and questions -

(1) How are you reconciling the network created within nova, with that
created in Quantum?

(2) The blueprint for this branch indicates that OpenStack APIs will be
implemented as extension APIs in Quantum. Do we have any documentation
on this API? (Also, I did not find any implementation in the Quantum
trunk, I am guessing we haven't done that yet, right?)

(3) There was earlier some talk about nova using an "administrative API"
to communicate with Quantum. Is that still the plan? In general, what is
the thinking around how nova would communicate with Quantum?

Thanks,
~Sumit. 

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

Re: [Netstack] "network-refactoring-l2" branch, and Quantum

[Sumit Naiksatam (snaiksat)]

Thanks Dan for your detailed response. My question was indeed based on
the understanding that the current nova network managers (in the network
service) do perform some L3/DHCP/VPN configurations apart from L2
configuration. As of today's implementation in the
network-refactoring-l2 branch, one would need to run the nova-network
service configured with either one of Flat/DHCP/VLANManagers even when
running Quantum as a separate service, right? If that is the case, how
does one correlate an entry in the network table in the nova database,
with a network created in Quantum? (I do realize that one could write a
different network manager within nova, but my question is more in the
context of what is available today.)

 

I am guessing that the current approach is to use the
Flat/DHCP/VLANManger to configure the L3/DHCP/VPN artifacts, and to use
Quantum to configure the L2 network (in cases where it's not a Linux
bridge). 

 

I was not necessarily trying to imply that the nova implementation (as
is in the network-refactoring-l2 branch today) interacts (i.e.
communicates) with Quantum. My question was more based on the earlier
point as to how the nova deployment would co-exist with Quantum (and any
other NetStack services), given that nova still maintains certain
network related information. (And while on that, nova has the notion of
a "user" and one or more "projects" associated with that user; how do
these map to the "tenant" in Quantum?)

 

But, I did also want to ask, as to what is the thinking around nova
communicating with Quantum (if required). You have rightly pointed out
"reporting the interface binding" as one of the cases when this might
need to be done. Another case wherein I think this might be relevant is
if the VIF driver (within nova virt layer) needs some information about
the network from Quantum. There would need to be a communication channel
between the VIF driver and Quantum to achieve this. I believe your
suggestion is that in any of these cases, the Quantum client library can
be used to communicate with the Quantum API (either core or extensions).

 

As for the part on APIs which was not clear in my email, yes I was
referring to the "nova-api (i.e. the OpenStack API) will expose
interface-ids as an API extension", as you point out. I believe, the
extension referred to here is on the nova API side (and not on the
Quantum side as my email seemed to suggest), right?

 

Thanks,

~Sumit.

 

From: Dan Wendlandt [mailto:d...@nicira.com] 
Sent: Sunday, July 24, 2011 10:46 PM
To: Sumit Naiksatam (snaiksat)
Cc: Ishimoto, Ryu; netstack@lists.launchpad.net
Subject: Re: "network-refactoring-l2" branch, and Quantum

 

Hi Sumit,

 

Very good questions.  I'll give you my take inline, and Ryu should jump
in as well :) 

 

Dan

On Sun, Jul 24, 2011 at 12:50 PM, Sumit Naiksatam (snaiksat)
 wrote:

Hi Ryu, Dan, and others involved,

I had some questions regarding how the code base in the
"network-refactoring-l2" branch currently works (or is supposed to) with
Quantum.

 

The network-refactoring-l2 branch itself doesn't actually interact with
Quantum.  It is really just a first step to providing more flexibility
within nova for how VM interfaces are created and plugged into a
"switch".  This will be very helpful for many people using Quantum, as
the existing nova code was hard-coded to use the Linux bridge.  

 


As I understand, eventually we want to get to a point where one
should
be able to run the Quantum service instead of the nova-network
service.

 

I actually don't think that's necessarily true.  The existing
nova-network service does many things beyond L2 networking, namely: 

 

- IP address management (melange project is targeting providing an
improved version of this)

- Network Node capabilities, including DHCP, L3 gateway, VPN, metadata
server, floating IP forwarding, etc (such functionality may grow to be
their own independent services, or an addon to Quantum in the future).  

- Network orchestration, in the sense that it automatically attaches
VIFs to networks based on config (vlan vs. flat manager) and project
assignment (donabe aims to become the primary mechanism for this type of
orchestration, though some simple behavior equivalent to the existing
flat/flatdhcp/vlan models may make sense to stay in nova for a while).  

 

There are some obvious next steps for D4:

- Ryu will continue the work to merge his work that makes sure that
other nova services retrieve network info via the API (not the DB).
This is a critical step. 

- We'll expose interface-ids via the nova API (likely as an extension)

- Troy's team will continue integrating the melange code with nova.  

- We'll probably create an alternate NetworkManager class (and
corresponding manager utility) that uses melange for IPAM, quantum for
L2 networks, and supports several d

Re: [Netstack] "network-refactoring-l2" branch, and Quantum

[Sumit Naiksatam (snaiksat)]

Thank Ryu, very nice explanation, and does fall in line with what I
could make from studying the current implementation. I will let Dan also
respond in case he has any more insight. Meanwhile, a few
comments/questions:

 

(1) Has anyone felt the need for Quantum to get notified when a
particular host joins or leaves a nova cluster? I can see this being
needed in the case where Quantum manages networking constructs (like
bridges, or vnics in the case of 802.1Qbh) on a per host basis. Any
thoughts around how this can be achieved (there is more than one way of
doing it, but I just want to if any work/thought has gone into this)?

 

(2)I am still not very clear as to how the "user" and "project" in
nova are related to the "tenant" in Quantum. Any clarifications would
help.

 

(3)Regarding nova communicating with Quantum, I agree with both the
options you have mentioned. I think we should keep the possibility open
for using either option. Even if we implement it in the VIF driver, I
guess it's fine if that particular VIF driver is Quantum-specific,
because you can always write another driver which relies on a different
network service, or source of information.

 

(4)This last one is probably not specific to nova-refactoring - Dan
mentioned the use of Quantum Client library as a possible way to
communicate between nova  and Quantum. Other nova services use AMQP to
exchange messages. I am just wondering if that is an option as well in
communicating between nova and Quantum.

 

Thanks,

~Sumit.

 

From: Ishimoto, Ryu [mailto:r...@midokura.jp] 
Sent: Monday, July 25, 2011 4:58 AM
To: Sumit Naiksatam (snaiksat)
Cc: Dan Wendlandt; netstack@lists.launchpad.net
Subject: Re: "network-refactoring-l2" branch, and Quantum

 

Hi Sumit,

 

Comments inline

Thanks Dan for your detailed response. My question was indeed
based on the understanding that the current nova network managers (in
the network service) do perform some L3/DHCP/VPN configurations apart
from L2 configuration. As of today's implementation in the
network-refactoring-l2 branch, one would need to run the nova-network
service configured with either one of Flat/DHCP/VLANManagers even when
running Quantum as a separate service, right? If that is the case, how
does one correlate an entry in the network table in the nova database,
with a network created in Quantum? (I do realize that one could write a
different network manager within nova, but my question is more in the
context of what is available today.)

 

Because Nova still relies on certain features provided by the Nova
network managers(like IP management), you have to run one of
Flat/DHCP/VlanManagers as a network service, or define your own manager.
I understand the confusion about the correlation between Networks in
Nova and Quantum, and I don't think this topic has been adequately
discussed, so might as well start here :-)  

 

The confusion comes from the fact that Nova Network includes both L3 and
L2 information.  As far as I understand it, when integrating with
Quantum, the L2 data is ignored.  However, since currently the IP
management is still being done by the network managers, for Quantum to
work with Nova L3 networking, these Network records must still exist to
act as subnets in which the VIFs get their IP addresses from.  This
means that Networks in Quantum and Nova are managed separately, and mean
different things.   Dan, please comment if you were thinking something
different.  

 

I am guessing that the current approach is to use the
Flat/DHCP/VLANManger to configure the L3/DHCP/VPN artifacts, and to use
Quantum to configure the L2 network (in cases where it's not a Linux
bridge).

 

The network host, when you run one of the existing Nova network
managers, still uses Linux bridge and VLAN to set up L2 connectivity.
This should be eventually refactored, but for now, one could extend the
NetworkManager class to setup L2 networking on the network host to match
that of the VIF plugins. 

 

 

But, I did also want to ask, as to what is the thinking around
nova communicating with Quantum (if required). You have rightly pointed
out "reporting the interface binding" as one of the cases when this
might need to be done. Another case wherein I think this might be
relevant is if the VIF driver (within nova virt layer) needs some
information about the network from Quantum. There would need to be a
communication channel between the VIF driver and Quantum to achieve
this. I believe your suggestion is that in any of these cases, the
Quantum client library can be used to communicate with the Quantum API
(either core or extensions).

 

I think we can do either:

*   Have the VIF driver directly communicate with Quantum to get the
relevant data at the time of 'plugging' in the VIF in the virt layer.
*   At the time in which the compute manager gets network
inform

Re: [Netstack] "network-refactoring-l2" branch, and Quantum

[Sumit Naiksatam (snaiksat)]

Thanks Troy for your prompt response.

 

Thanks for the clarification the relationship between the current notion
of "project" and "tenant". On that, how does one share a network between
multiple tenants/projects? To give a specific example, let's say we want
to model an enterprise with multiple departments such that some of the
departments can communicate with each other on certain networks, while
there are other networks dedicated to particular departments. In such a
case, would each department map to an individual tenant? If so, how
would a network be shared across more than one tenant?

 

Thanks,

~Sumit.

 

From: Troy Toman [mailto:troy.to...@rackspace.com] 
Sent: Monday, July 25, 2011 10:41 AM
To: Sumit Naiksatam (snaiksat)
Cc: Ishimoto, Ryu; 
Subject: Re: [Netstack] "network-refactoring-l2" branch, and Quantum

 

 

On Jul 25, 2011, at 12:30 PM, Sumit Naiksatam (snaiksat) wrote:





Thank Ryu, very nice explanation, and does fall in line with what I
could make from studying the current implementation. I will let Dan also
respond in case he has any more insight. Meanwhile, a few
comments/questions:

 

(1) Has anyone felt the need for Quantum to get notified when a
particular host joins or leaves a nova cluster? I can see this being
needed in the case where Quantum manages networking constructs (like
bridges, or vnics in the case of 802.1Qbh) on a per host basis. Any
thoughts around how this can be achieved (there is more than one way of
doing it, but I just want to if any work/thought has gone into this)?

 

I think this will be a requirement. We plan to look at some options
because, as you note, there are multiple ways to do this. My preference
which will need to be tested, would be to have Quantum listen to the
notifications from Nova. I like this because it keeps things
asynchronous. Another option is to have Nova explicitly manage this by
issuing "detach" commands as part of a VM cleanup. If detach is
implemented as an async call (quickly returns and then goes and
detaches), this could also work at scale. We haven't had a change to
fully vet either of these ideas (and there are other options also.)





 

(2)I am still not very clear as to how the "user" and "project" in
nova are related to the "tenant" in Quantum. Any clarifications would
help.

 

My understanding is that these are all converging as Nova integrates
with Keystone. There is the concept of tenant which will replace the
idea of projects going forward.





 

(3)Regarding nova communicating with Quantum, I agree with both the
options you have mentioned. I think we should keep the possibility open
for using either option. Even if we implement it in the VIF driver, I
guess it's fine if that particular VIF driver is Quantum-specific,
because you can always write another driver which relies on a different
network service, or source of information.

 

(4)This last one is probably not specific to nova-refactoring - Dan
mentioned the use of Quantum Client library as a possible way to
communicate between nova  and Quantum. Other nova services use AMQP to
exchange messages. I am just wondering if that is an option as well in
communicating between nova and Quantum.

 

Thanks,

~Sumit.

 

From: Ishimoto, Ryu [mailto:r...@midokura.jp] 
Sent: Monday, July 25, 2011 4:58 AM
To: Sumit Naiksatam (snaiksat)
Cc: Dan Wendlandt; netstack@lists.launchpad.net
Subject: Re: "network-refactoring-l2" branch, and Quantum

 

Hi Sumit,

 

Comments inline

Thanks Dan for your detailed response. My question was indeed
based on the understanding that the current nova network managers (in
the network service) do perform some L3/DHCP/VPN configurations apart
from L2 configuration. As of today's implementation in the
network-refactoring-l2 branch, one would need to run the nova-network
service configured with either one of Flat/DHCP/VLANManagers even when
running Quantum as a separate service, right? If that is the case, how
does one correlate an entry in the network table in the nova database,
with a network created in Quantum? (I do realize that one could write a
different network manager within nova, but my question is more in the
context of what is available today.)

 

Because Nova still relies on certain features provided by the Nova
network managers(like IP management), you have to run one of
Flat/DHCP/VlanManagers as a network service, or define your own manager.
I understand the confusion about the correlation between Networks in
Nova and Quantum, and I don't think this topic has been adequately
discussed, so might as well start here :-)  

 

The confusion comes from the fact that Nova Network includes both L3 and
L2 information.  As far as I understand it, when integrating with
Quantum, the L2 data is ignored.  However, since currently the IP
management is still being done by the network managers, for Quantum to
wor

Re: [Netstack] "network-refactoring-l2" branch, and Quantum

[Sumit Naiksatam (snaiksat)]

Thanks Dan. I just wanted to know what is the currently preferred method
of communication (given that in the long term it has scalability
implications). Your reasoning on using the RESTful interface to start
with makes sense to me.

 

From: Dan Wendlandt [mailto:d...@nicira.com] 
Sent: Monday, July 25, 2011 6:18 PM
To: Sumit Naiksatam (snaiksat)
Cc: Ishimoto, Ryu; netstack@lists.launchpad.net
Subject: Re: "network-refactoring-l2" branch, and Quantum

 

Hi Sumit, 

On Mon, Jul 25, 2011 at 10:30 AM, Sumit Naiksatam (snaiksat)
 wrote:

(4)This last one is probably not specific to nova-refactoring - Dan
mentioned the use of Quantum Client library as a possible way to
communicate between nova  and Quantum. Other nova services use AMQP to
exchange messages. I am just wondering if that is an option as well in
communicating between nova and Quantum.

 

That's a good question and one we've discussed internally as well.  My
understanding is that nova uses AMQP to communicate between its various
components (nova-api, nova-schedule, nova-network, nova-compute), but
currently communication to different stand-alone OpenStack services
(e.g., Glance) occur via well-defined RESTful web services.  This was
the starting point for the Quantum design based on comments made during
the design summit, and I think it is the right step (at least initially)
to cement Quantum as a stand-alone service.  That said, nothing would
prevent you from using AMQP to communicate between your Quantum plugin
and a plugin-specific agent that might be running on a hypervisor, since
this is entirely within the plugin.  Long term, I think AMQP could be
used more widely, but I'd prefer that we at least first focus on making
sure the RESTful interface is solid (adding things like authentication,
etc.) before looking at expanding.

 

Dan

 

 

 

Thanks,

~Sumit.

 

From: Ishimoto, Ryu [mailto:r...@midokura.jp] 
Sent: Monday, July 25, 2011 4:58 AM
    To: Sumit Naiksatam (snaiksat)
Cc: Dan Wendlandt; netstack@lists.launchpad.net


Subject: Re: "network-refactoring-l2" branch, and Quantum

 

Hi Sumit,

 

Comments inline

Thanks Dan for your detailed response. My question was
indeed based on the understanding that the current nova network managers
(in the network service) do perform some L3/DHCP/VPN configurations
apart from L2 configuration. As of today's implementation in the
network-refactoring-l2 branch, one would need to run the nova-network
service configured with either one of Flat/DHCP/VLANManagers even when
running Quantum as a separate service, right? If that is the case, how
does one correlate an entry in the network table in the nova database,
with a network created in Quantum? (I do realize that one could write a
different network manager within nova, but my question is more in the
context of what is available today.)

 

Because Nova still relies on certain features provided by the
Nova network managers(like IP management), you have to run one of
Flat/DHCP/VlanManagers as a network service, or define your own manager.
I understand the confusion about the correlation between Networks in
Nova and Quantum, and I don't think this topic has been adequately
discussed, so might as well start here :-)  

 

The confusion comes from the fact that Nova Network includes
both L3 and L2 information.  As far as I understand it, when integrating
with Quantum, the L2 data is ignored.  However, since currently the IP
management is still being done by the network managers, for Quantum to
work with Nova L3 networking, these Network records must still exist to
act as subnets in which the VIFs get their IP addresses from.  This
means that Networks in Quantum and Nova are managed separately, and mean
different things.   Dan, please comment if you were thinking something
different.  

 

I am guessing that the current approach is to use the
Flat/DHCP/VLANManger to configure the L3/DHCP/VPN artifacts, and to use
Quantum to configure the L2 network (in cases where it's not a Linux
bridge).

 

The network host, when you run one of the existing Nova network
managers, still uses Linux bridge and VLAN to set up L2 connectivity.
This should be eventually refactored, but for now, one could extend the
NetworkManager class to setup L2 networking on the network host to match
that of the VIF plugins. 

 

 

But, I did also want to ask, as to what is the thinking
around nova communicating with Quantum (if required). You have rightly
pointed out "reporting the interface binding" as one of the cases when
this might need to be done. Another case wherein I think this might be
relevant is if the VIF driver (within nova virt layer) needs some
information about the network 

Re: [Netstack] Aligning API implementation with specification

[Sumit Naiksatam (snaiksat)]

Thanks Salvatore for outlining the efforts around aligning the API.

 

As for the issue of synchronous versus asynchronous. I agree that
leaving it to the plugin to implement the behavior might be more
flexible and also alleviate the burden on the API framework
implementation. Having said that, each plugin that needs to implement
the asynchronous behavior will have to implement the asynchronous
mechanism, potentially leading to duplication of efforts across plugins
(and also bugs). I am sure you must have thought of this, but I am just
trying to bring out another data point to the table. As opposed to that,
if the implementation is in the API framework, then we would always
ensure asynchronous behavior.

 

I am also trying to understand the scheme you have proposed below. When
you talk about the "provisioning status", and that "this status should
be available through the API", do you envision a separate API to obtain
the status?

 

Thanks,

~Sumit.

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of Salvatore Orlando
Sent: Tuesday, August 02, 2011 9:40 AM
To: netstack@lists.launchpad.net
Subject: [Netstack] Aligning API implementation with specification

 

Hi, 

 

In order to finalize a "v1.0" for the Quantum API we are currently
reviewing its specification and implementation. 

 

The reviewed API specification is much closer to the Openstack API.
However, there are a few "corner cases": 

-  Get Attached Resource operation: if no attachment is plugged
into a port should we raise an error? 

-  Plugging an attachment in port whose state is 'DOWN'. I think
this should be disallowed, and an exception raised. What's your opinion?

 

The code currently diverges from the API. Realignment is being done in
the branch lp:~salvatore-orlando/quantum/quantum-api-aligment, linked to
bug #813433.

Also two other branches contain code which will contribute to realign
the API impl with its spec. One removes the "PortCount" attribute,
whereas the other introduces the NetworkNameExists fault, which can be
raised upon network create/update operations.

 

The next step will involve fixing accordingly unit tests and the client
library (which is going to hit trunk very soon). All of this will be
done within the api-alignment branch.

 

The final step is to take a decision wrt synchronous vs asynchronous
behaviour of the API. 

I sent an email a couple of days ago on this topic. I thought a little
bit more about it, and I think it is reasonable that the actual
behaviour depends on the particular plugin implementation. It does not
make a lot of sense to force something which is inherently synchronous
to be asynchronous. 

However, a concept of "provisioning status" is probably need for Quantum
resources, and this status should be available through the API. 

Enumeration for resource statuses could be similar to the power_mapping
enumeration in Openstack API. 

In this way a synchronous plugin could return resource whose state is
typically "ACTIVE", whereas an asynchronous plugin would return
resources whose state is usually "BUILD". 

API users will be aware of this, as the status of an operation will be
clearly documented in the API specification. On the other hand, the API
will refuse to execute operations on resource whose provisioning state
is not "ACTIVE". 

 

I would be more than happy to discuss these item during today's meeting.
My aim is to lock down the specification as soon as possible (end of the
week?), and then merge the alignment branch shortly after. 

 

Regards, 

Salvatore

 

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

Re: [Netstack] Tackling authN/authZ for Diablo-4

[Sumit Naiksatam (snaiksat)]

Thanks Salv for spelling out the deliverables on this topic.

 

On the point of the "simplified mode", I wasn't very clear on what you
meant by "Although in theory several users can be defined for a tenant,
we will assume that each user has the same administrative rights." Does
this mean that each of those users (in their "administrator" capacity)
would be able to share the network (i.e. more than one tenant plugging
interfaces into the same network)? I was trying to reconcile that with
the earlier statement on the "shared network model" which you mention is
not in scope for Diablo.

 

Thanks,

~Sumit.

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of Salvatore Orlando
Sent: Wednesday, August 03, 2011 7:22 AM
To: netstack@lists.launchpad.net
Subject: [Netstack] Tackling authN/authZ for Diablo-4

 

Hi, 

 

During yesterday's meeting we agreed that we needed to have some form of
authentication and authorization in Quantum for Diablo. 

We also agreed we will be doing Keystone integration (please correct me
if I'm wrong). 

 

I think we can safely say what we will NOT deliver for Diablo:

* Full RBAC model including the ability of specifying different
roles for tenants' user (e.g.: "Alice" is an administrator and can do
anything for tenant "A", whereas "Bob" is a simple user and can only
plug its own interface into networks owned by tenant "A")

* Shared network model, in which a tenant owns the network, but
other tenants can plug interfaces into it. This use case will be useful
for "public" and possibly "service" networks. 

 

What we will deliver can be summarized as follows:

* Simplified model: only one "administrator" user per tenant.
Although in theory several users can be defined for a tenant, we will
assume that each user has the same administrative rights. 

* Authentication service: users must authenticate before
submitting requests to Quantum API

o   The plan is to integrate Quantum with Keystone. The user will
authenticate with Keystone, which will return an authentication token,
which should be used for subsequent requests to Quantum API. 

Quantum API will validate this token with Keystone; I actually think we
could achieve this without adding a single line of code to Quantum.

* Object ownership verification: Before dispatching a call to a
plugin the Quantum service layer must verify that all the resources
involved are owned by the tenant submitting the request. 

o   This can be handled with an authZ middleware which will precede the
API app in the wsgi pipeline. Even if it could be handled within the API
layer, I reckon it will be better to keep it orthogonal. 

o   Interfaces being plugged in a port are the tricky bit: they are not
owned by Quantum. We will need to query nova in order to know whether a
tenant owns or not an interface. If I'm not wrong Dan will look after
this (quantum-manager blueprint in nova)

o   We would be happy to avoid storing information about object
ownership in the service layer and keep the database into the plugin.
For networks and ports, the existing plugin interface is probably
already good enough to return the appropriate ownership information.

 

I am freeing some work cycles to start tackling these issues. I should
be able to set aside 2-3 working days in the next two weeks. 

Mark, Dan, and other interested: please give me your feedback!

 

Salvatore

 

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

[Netstack] Quantum tenant <--> Nova ?

[Sumit Naiksatam (snaiksat)]

My apologies if this question has already been answered/discussed - what
is a tenant within Quantum mapped to in Nova? I noticed that Nova is
still refers to project-id and apparently uses that a tenant when
interfacing with Keystone. So does a Quantum tenant map to a Nova
project?

Thanks,
~Sumit.

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

Re: [Netstack] Quantum tenant <--> Nova ?

[Sumit Naiksatam (snaiksat)]

Thanks Salvatore for your prompt response. So I will take it that for
now that Quantum Tenant maps to a Nova Project (1:1). If anyone has more
clarity on this now, or in the future, I would appreciate a post to this
list.

Thanks,
~Sumit.

> -Original Message-
> From: Salvatore Orlando [mailto:salvatore.orla...@eu.citrix.com]
> Sent: Wednesday, August 24, 2011 3:15 AM
> To: Sumit Naiksatam (snaiksat); netstack@lists.launchpad.net
> Subject: RE: Quantum tenant <--> Nova ?
> 
> I haven't looked in detail at this issue yet, though I expected it
> would have been raised at some point.
> 
> Nova has a small module, called auth_shim, that maps back nova
projects
> to keystone tenants. I don't have code at hand at the moment, but I
> recall the association between tenant and projects was 1:1
> However, I think Vishy was working on a better integration between
Nova
> and Keystone, i.e.: getting rid of the shim, aiming at doing it by
> Diablo release. Unfortunately I haven't looked at this work recently.
> 
> Cheers,
> Salvatore
> 
> > -Original Message-
> > From: netstack-
> > bounces+salvatore.orlando=eu.citrix@lists.launchpad.net
> > [mailto:netstack-
> > bounces+salvatore.orlando=eu.citrix@lists.launchpad.net] On
> Behalf Of
> > Sumit Naiksatam (snaiksat)
> > Sent: 24 August 2011 11:00
> > To: netstack@lists.launchpad.net
> > Subject: [Netstack] Quantum tenant <--> Nova ?
> >
> > My apologies if this question has already been answered/discussed -
> what is
> > a tenant within Quantum mapped to in Nova? I noticed that Nova is
> still
> > refers to project-id and apparently uses that a tenant when
> interfacing with
> > Keystone. So does a Quantum tenant map to a Nova project?
> >
> > Thanks,
> > ~Sumit.
> >
> > --
> > Mailing list: https://launchpad.net/~netstack
> > Post to : netstack@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~netstack
> > More help   : https://help.launchpad.net/ListHelp

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

Re: [Netstack] D-4 drop delayed: cli appears broken in trunk

[Sumit Naiksatam (snaiksat)]

J I could do it, but I think someone like Tyler who has more familiarity
with the code can do a better job. On seeing this thread, I did reach
out to him and made that suggestion.

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of Salvatore Orlando
Sent: Friday, August 26, 2011 1:31 AM
To: Dan Wendlandt
Cc: netstack@lists.launchpad.net
Subject: Re: [Netstack] D-4 drop delayed: cli appears broken in trunk

 

It looks Sumit is still around J

 

From: Dan Wendlandt [mailto:d...@nicira.com] 
Sent: 26 August 2011 09:23
To: Salvatore Orlando
Cc: netstack@lists.launchpad.net
Subject: Re: [Netstack] D-4 drop delayed: cli appears broken in trunk

 

 

On Fri, Aug 26, 2011 at 1:06 AM, Salvatore Orlando
 wrote:

Sorry about the broken CLI. 

Without unit tests, I did some manual tests, but unfortunately it seems
my tests were not thorough enough.

 

The revised-cli branch is already updated for API v1.0, and has unit
tests which pass. 

As stated by Dan, a first review has already been done, and I'm
addressing his comments. I'm quite confident we can get it merged today.

 

Its a race to see how can get review #2 done lots of brownie points
to the winner!  :)  

 

 

Regards,

Salvatore

 

From:
netstack-bounces+salvatore.orlando=eu.citrix@lists.launchpad.net
[mailto:netstack-bounces+salvatore.orlando

=eu.citrix@lists.launchpad.net] On Behalf Of Dan Wendlandt
Sent: 26 August 2011 08:23
To: netstack@lists.launchpad.net
Subject: [Netstack] D-4 drop delayed: cli appears broken in
trunk

 

Hi folks,

 

Great work on all of the reviews folks.  

 

Unfortunately, with the flurry of activity, it seems like latest
API changes seem to have broken the cli in trunk.  Since the CLI is
currently the main way an outsider would currently play with Quantum, it
probably doesn't make much sense to create a D-4 drop were someone
cannot perform basic operations like creating a network.  

 

We could fix the current cli.py (the problems seem to be fairly
simple parameter renames), but I feel a better approach is probably just
to quickly review Salvatore's new CLI branch that is based on cheetah
templates, as that branch has unit tests that would have detected this
issue in the first place.  I have done a first review, but it would be
great if at least one other person could take a look at this sometime on
friday so we can get the code merged:
https://code.launchpad.net/~salvatore-orlando/quantum/quantum-cli-revise
d/+merge/72934

 

Thanks!

 

Dan

 

 




 

-- 
~~~
Dan Wendlandt 
Nicira Networks, Inc. 
www.nicira.com | www.openvswitch.org
Sr. Product Manager 
cell: 650-906-2650
~~~





 

-- 
~~~
Dan Wendlandt 
Nicira Networks, Inc. 
www.nicira.com | www.openvswitch.org
Sr. Product Manager 
cell: 650-906-2650
~~~

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

Re: [Netstack] D-4 drop delayed: cli appears broken in trunk

[Sumit Naiksatam (snaiksat)]

Done on the first count, not on the second J...thanks for pointing it
out...

 

From: Dan Wendlandt [mailto:d...@nicira.com] 
Sent: Friday, August 26, 2011 1:38 AM
To: Sumit Naiksatam (snaiksat)
Cc: Salvatore Orlando; netstack@lists.launchpad.net
Subject: Re: [Netstack] D-4 drop delayed: cli appears broken in trunk

 

 

On Fri, Aug 26, 2011 at 1:32 AM, Sumit Naiksatam (snaiksat)
 wrote:

J I could do it, but I think someone like Tyler who has more familiarity
with the code can do a better job. On seeing this thread, I did reach
out to him and made that suggestion.

 

Great.  And Sumit, you can also get some brownie points (though not as
many) for reviewing the much shorter OVS plugin patch :P  

 

https://code.launchpad.net/~danwent/quantum/lp834491/+merge/73002

 

If you haven't already, its probably worth making sure the Cisco plugin
wasn't similarly affected by the tweaked assumptions in the new API
code.  

 

Dan

 

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat <mailto:netstack-bounces%2Bsnaiksat>
=cisco@lists.launchpad.net] On Behalf Of Salvatore Orlando
Sent: Friday, August 26, 2011 1:31 AM
To: Dan Wendlandt


Cc: netstack@lists.launchpad.net
Subject: Re: [Netstack] D-4 drop delayed: cli appears broken in
trunk

 

It looks Sumit is still around J

 

From: Dan Wendlandt [mailto:d...@nicira.com] 
Sent: 26 August 2011 09:23
To: Salvatore Orlando
Cc: netstack@lists.launchpad.net
Subject: Re: [Netstack] D-4 drop delayed: cli appears broken in
trunk

 

 

On Fri, Aug 26, 2011 at 1:06 AM, Salvatore Orlando
 wrote:

Sorry about the broken CLI. 

Without unit tests, I did some manual tests, but unfortunately
it seems my tests were not thorough enough.

 

The revised-cli branch is already updated for API v1.0, and has
unit tests which pass. 

As stated by Dan, a first review has already been done, and I'm
addressing his comments. I'm quite confident we can get it merged today.

 

Its a race to see how can get review #2 done lots of brownie
points to the winner!  :)  

 

 

Regards,

Salvatore

 

From:
netstack-bounces+salvatore.orlando=eu.citrix@lists.launchpad.net
[mailto:netstack-bounces+salvatore.orlando
<mailto:netstack-bounces%2Bsalvatore.orlando>
=eu.citrix@lists.launchpad.net] On Behalf Of Dan Wendlandt
Sent: 26 August 2011 08:23
To: netstack@lists.launchpad.net
Subject: [Netstack] D-4 drop delayed: cli appears broken
in trunk

 

Hi folks,

 

Great work on all of the reviews folks.  

 

Unfortunately, with the flurry of activity, it seems
like latest API changes seem to have broken the cli in trunk.  Since the
CLI is currently the main way an outsider would currently play with
Quantum, it probably doesn't make much sense to create a D-4 drop were
someone cannot perform basic operations like creating a network.  

 

We could fix the current cli.py (the problems seem to be
fairly simple parameter renames), but I feel a better approach is
probably just to quickly review Salvatore's new CLI branch that is based
on cheetah templates, as that branch has unit tests that would have
detected this issue in the first place.  I have done a first review, but
it would be great if at least one other person could take a look at this
sometime on friday so we can get the code merged:
https://code.launchpad.net/~salvatore-orlando/quantum/quantum-cli-revise
d/+merge/72934

 

Thanks!

 

Dan

 

 




 

-- 
~~~
Dan Wendlandt 
Nicira Networks, Inc. 
www.nicira.com | www.openvswitch.org
Sr. Product Manager 
cell: 650-906-2650
~~~





 

-- 
~~~
Dan Wendlandt 
Nicira Networks, Inc. 
www.nicira.com | www.openvswitch.org
Sr. Product Manager 
cell: 650-906-2650
~~~





 

-- 
~~~
Dan Wendlandt 
Nicira Networks, Inc. 
www.nicira.com | www.openvswitch.org
Sr. Product Manager 
cell: 650-906-2650
~~~

-- 
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstac

Re: [Netstack] Proposing sessions for Openstack design summitq

[Sumit Naiksatam (snaiksat)]

Hi All,

 

Here are a few more issues which we think need to be tackled  -

 

* A framework for Rollback after Operation Failure, Troubleshooting &
Diagnostics:

The realization of the APIs supported by the Quantum service (such as
create_network, create_port) results in a series of steps in the plugin
implementation, and which often touch heterogeneous independent systems
(in the management plane). If one of these steps fails, it might be
required to rollback the entire operation or a part of it (depending on
the context of the operation).

It would be desirable to have the ability to define checkpoints in the
system such that in the event of a failure, one can rollback the state
of the system to previous checkpoint.

It's easier to achieve this functionality with a database since most
implementations support check pointing and rollback. However, a more
sophisticated framework will be required to handle other management
systems or devices which are touched by the plugin in order complete an
operation.

 

* Reservation Semantics (relevant to the discussion around L2 & L3 core
capabilities):

Neither Nova nor Quantum supports the reservation of resources. In order
to support certain use cases wherein the goal is to provide a necessary
level of QoS, it might be required to support a mechanism which will
support the advance reservation of resources, such that all of the
required resources are available at a designated time. (This is just one
use case, the requirement for reservation in general is well
understood.)

 

Scheduler interface exposed by Quantum  (relevant to the discussion
around L2 & L3 core capabilities):

While a meta-scheduler (which can perform multi-constrained decisions
based on availability of heterogeneous resources) is required (and is
being pursued in the context of the Scheduler Service), we also need a
normalized mechanism on the network service side to expose the
network-specific information to the meta-scheduler. This mechanism
should be fairly generic such that the meta-scheduler would not need to
have deep understanding of the underlying network realization.

 

* A Default Plugin Implementation based on Linux bridge (currently Linux
bridge is nova configuration, but bridge is a network artifact)

 

* A basic security-groups plugin based on Netfilter (currently Nova does
a lot of iptables configuration)

 

I would also be very interested in the asynchronous API discussions, so
kindly loop me in as well.

 

Thanks,

~Sumit.

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of Salvatore Orlando
Sent: Monday, September 19, 2011 8:36 AM
To: Ram Durairaj (radurair); netstack@lists.launchpad.net
Cc: Thierry Carrez
Subject: Re: [Netstack] Proposing sessions for Openstack design summitq

 

Hi Ram, 

 

Thanks for sharing your proposed sessions for the design summit.

I think that for this summit we will not be creating blueprints and them
propose them for "sprint" as we did for Diablo, but we should rather
propose sessions on the summit.openstack.org/sessions.

However, since we are going to have our own track, it will be good to
hear some organizational details from Thierry how many sessions we can
fit in it.

 

All the elements in your list make perfect sense for me. However, I'm
afraid I do not understand very well what do you mean by "Hybrid Cloud
Service Framework". Can you elaborate a bit more on this?

 

I think your list is not very far from mine, and we can probably merge
them as follows:

 

1.   L3 networking services (beyond IPAM) 

2.   Higher layer network services (L4/L7)

1.   Firewall and Security Groups

2.   Network Acceleration Services Insertion Framework 
LB, Symmetric services - Acceleration services and so on

3.   NAT

4.   VPN Access

3.   Quantum "Basic" Plugin

1.   Linux Bridge

2.   Solution supporting all hypervisor platforms including ESX/Hyper-V

4.   Hybrid Cloud Service Framework

5.   Quantum API v1.1

1.   Synchronous vs Asynchronous behaviour and concept of "Operational
Status"

2.   Improvements such as Filtering, Rate Limiting, Resource Links,
pagination

6.   Cloud Bridging APIs in Quantum

 

 

 

From: Ram Durairaj (radurair) [mailto:radur...@cisco.com] 
Sent: 19 September 2011 16:21
To: Salvatore Orlando; netstack@lists.launchpad.net
Cc: Thierry Carrez
Subject: RE: [Netstack] Proposing sessions for Openstack design summitq

 

Hello Salvatore and all:

 

We suppose to have a Netstack track...Its good to follow-up with Thierry
to group all the Net stack related blueprint and sessions in one track
for all the interested community participants to contribute and discuss.

 

In addition to the list, here are few more items from our side:

 

1.   L3 Service - As  a service as Quantum

2.   Hybrid Cloud Service Framework

3.   Network Acceleration Services Insertion Framework (LB,
Symmetric services - Acceleration 

Re: [Netstack] Proposing sessions for Openstack design summitq

[Sumit Naiksatam (snaiksat)]

Thanks Dan for your response. I think the rollback could/would happen at
different levels of abstraction, and how effectively it could be done
would depend on the context available at that level of abstraction. I do
like your idea of putting the onus of initiating  the rollback to a
different (possibly orchestration as you point out) service, it
definitely simplifies things. However, it's likely that some or all the
context has been lost when the higher level service decides to rollback.


 

To effectively target the rollback, I was thinking that the plugin would
be in the best position to know what steps it needs to rollback if it is
not able to support a particular call to an operation. In such a case,
it would be helpful to have a generic framework which all plugins can
use as a mechanism to rollback in case of failure. To give you an
example, let's say an operation create_foo() requires the steps A, B,
and C to be completed before an instance of resource "foo" is created.
If steps A & B are successful (which internally might result in some
device and system configurations) but C is not, then the plugin is not
able to create the instance of resource "foo". At this point, it will be
beneficial to have the knowledge to rollback steps A and B. Each plugin
implementation might come up with a way of doing this, but I think a
more generic framework might be beneficial to the community. 

 

I am also trying to extend this to discussion on Troubleshooting &
Diagnostics in general (cases where failures occur and rollback is not
done properly).

 

Based on your comments below, let me put a place holder for discussions
around "Quantum Scheduler Interface & Reservation Semantics". We can
roll this into a different session if there is an overlap.

 

Thanks,

~Sumit.

 

From: Dan Wendlandt [mailto:d...@nicira.com] 
Sent: Monday, September 19, 2011 12:16 PM
To: Sumit Naiksatam (snaiksat)
Cc: Salvatore Orlando; Ram Durairaj (radurair);
netstack@lists.launchpad.net
Subject: Re: [Netstack] Proposing sessions for Openstack design summitq

 

 

On Mon, Sep 19, 2011 at 10:22 AM, Sumit Naiksatam (snaiksat)
 wrote:

Hi All,

 

Here are a few more issues which we think need to be tackled  -

 

* A framework for Rollback after Operation Failure, Troubleshooting &
Diagnostics:

The realization of the APIs supported by the Quantum service (such as
create_network, create_port) results in a series of steps in the plugin
implementation, and which often touch heterogeneous independent systems
(in the management plane). If one of these steps fails, it might be
required to rollback the entire operation or a part of it (depending on
the context of the operation).

It would be desirable to have the ability to define checkpoints in the
system such that in the event of a failure, one can rollback the state
of the system to previous checkpoint.

It's easier to achieve this functionality with a database since most
implementations support check pointing and rollback. However, a more
sophisticated framework will be required to handle other management
systems or devices which are touched by the plugin in order complete an
operation.

 

Hi Sumit, 

 

Would such a mechanism would be specific to a particular plugin, or am I
misunderstanding what your are describing?  My thinking on this front
has been pretty simple:  the plugin is constantly trying to make the
virtual/physical switch configuration match the logical model exposed by
the API.  If the plugin is not able to achieve that, it would expose
this fact via the "operational status" (TBD in API v1.1).  The user of
the Quantum API (possibly an orchestration service) would then have the
option to detect the error and "roll-back" the logical model to a
previous state.   

 

 

* Reservation Semantics (relevant to the discussion around L2 &
L3 core capabilities):

Neither Nova nor Quantum supports the reservation of resources.
In order to support certain use cases wherein the goal is to provide a
necessary level of QoS, it might be required to support a mechanism
which will support the advance reservation of resources, such that all
of the required resources are available at a designated time. (This is
just one use case, the requirement for reservation in general is well
understood.)

 

Scheduler interface exposed by Quantum  (relevant to the
discussion around L2 & L3 core capabilities):

While a meta-scheduler (which can perform multi-constrained
decisions based on availability of heterogeneous resources) is required
(and is being pursued in the context of the Scheduler Service), we also
need a normalized mechanism on the network service side to expose the
network-specific information to the meta-scheduler. This mechanism
should be fairly generic such that the meta-scheduler would not need to
have deep understanding of the underlying network real

Re: [Netstack] Proposing sessions for Openstack design summitq

[Sumit Naiksatam (snaiksat)]

Thanks Dan.  I am pretty much in line with your thinking. 

 

From: Dan Wendlandt [mailto:d...@nicira.com] 
Sent: Monday, September 19, 2011 1:03 PM
To: Sumit Naiksatam (snaiksat)
Cc: Salvatore Orlando; Ram Durairaj (radurair);
netstack@lists.launchpad.net
Subject: Re: [Netstack] Proposing sessions for Openstack design summitq

 

Hi Sumit,

 

I definitely agree with there being different levels of roll-back.  I'm
curious, does this match your thinking? 

 

- rollback within the plugin:  if a plugin is unable to achieve a
configuration specified by the logical model, it may choose to roll back
one or more steps of the virtual/physical switch configuration it
performed.  However, the plugin does not rollback the actual logical
model.  Instead, the plugin exposes the fact that the logical
configuration could not be achieved by showing an error value for the
"operational status" of a network or port (inline with previous
discussions about async APIs). 

- rollback of logical operations:  an entity driving the Quantum API may
notice that the operational status of a port or network is down and
choose to roll back the logical configuration to a previous state (e.g.,
delete a created port).  Doing so requires understanding only the
logical model, not the plugin implementation.  

 

Dan

 

 

On Mon, Sep 19, 2011 at 12:49 PM, Sumit Naiksatam (snaiksat)
 wrote:

Thanks Dan for your response. I think the rollback could/would happen at
different levels of abstraction, and how effectively it could be done
would depend on the context available at that level of abstraction. I do
like your idea of putting the onus of initiating  the rollback to a
different (possibly orchestration as you point out) service, it
definitely simplifies things. However, it's likely that some or all the
context has been lost when the higher level service decides to rollback.


 

To effectively target the rollback, I was thinking that the plugin would
be in the best position to know what steps it needs to rollback if it is
not able to support a particular call to an operation. In such a case,
it would be helpful to have a generic framework which all plugins can
use as a mechanism to rollback in case of failure. To give you an
example, let's say an operation create_foo() requires the steps A, B,
and C to be completed before an instance of resource "foo" is created.
If steps A & B are successful (which internally might result in some
device and system configurations) but C is not, then the plugin is not
able to create the instance of resource "foo". At this point, it will be
beneficial to have the knowledge to rollback steps A and B. Each plugin
implementation might come up with a way of doing this, but I think a
more generic framework might be beneficial to the community. 

 

I am also trying to extend this to discussion on Troubleshooting &
Diagnostics in general (cases where failures occur and rollback is not
done properly).

 

Based on your comments below, let me put a place holder for discussions
around "Quantum Scheduler Interface & Reservation Semantics". We can
roll this into a different session if there is an overlap.

 

Thanks,

~Sumit.

 

From: Dan Wendlandt [mailto:d...@nicira.com] 
Sent: Monday, September 19, 2011 12:16 PM
To: Sumit Naiksatam (snaiksat)
Cc: Salvatore Orlando; Ram Durairaj (radurair);
netstack@lists.launchpad.net


Subject: Re: [Netstack] Proposing sessions for Openstack design summitq

 

 

On Mon, Sep 19, 2011 at 10:22 AM, Sumit Naiksatam (snaiksat)
 wrote:

Hi All,

 

Here are a few more issues which we think need to be tackled  -

 

* A framework for Rollback after Operation Failure, Troubleshooting &
Diagnostics:

The realization of the APIs supported by the Quantum service (such as
create_network, create_port) results in a series of steps in the plugin
implementation, and which often touch heterogeneous independent systems
(in the management plane). If one of these steps fails, it might be
required to rollback the entire operation or a part of it (depending on
the context of the operation).

It would be desirable to have the ability to define checkpoints in the
system such that in the event of a failure, one can rollback the state
of the system to previous checkpoint.

It's easier to achieve this functionality with a database since most
implementations support check pointing and rollback. However, a more
sophisticated framework will be required to handle other management
systems or devices which are touched by the plugin in order complete an
operation.

 

Hi Sumit, 

 

Would such a mechanism would be specific to a particular plugin, or am I
misunderstanding what your are describing?  My thinking on this front
has been pretty simple:  the plugin is constantly trying to make the
virtual/physical switch configuration match the logical model exposed by
the API.  If the plugin is not able to achieve that, it would expose
this f

Re: [Netstack] Quantum 2011.3 Diablo is out!

[Sumit Naiksatam (snaiksat)]

Hi Dan,

 

As always, great work. Here are some minor suggestions after a quick
read -

 

Page 2, 2.2.1, "At its core, Quantum control the network
connectivity..." --> controls

 

Page 2, 2.2.2 - "For an OpenStack service (e.g., Nova) to work with
Quantum, it must be modified to inform Quantum about individual
interface devices (e.g., Nova vNICs) that can be plugged into Quantum
networks."

 

Some readers might be mislead into reading this as a modification that
still remains to be done. Since this modification is already available
in Diablo release as far as Nova is concerned, maybe we should provide
that information.

 

Page 3, 2.2.3 - ``controller'' - quotation characters are mismatched.

 

Page 4, 3.1 - "we recommend that you use a recent version of Ubuntu, as
this is a well tested platform" - you can probably qualify this in
parentheses by saying that it has been known to work on RHEL.

 

Page 5, 3.6 - With regards to the CLI, do you want to say that this is
being executed from the same host on which Quantum is running (possibly
also state that the option exists to run the CLI remotely by providing
the Quantum server IP address)

 

Page 7, 4.2 - Could specify the flag names - 

--libvirt_vif_driver

--libvirt_vif_type

 

Page 7, 4.3 - "To enabled" --> enable

 

Page 8 - "This lets uses" --> user

 

A thought on the QuantumManager - I do agree that going forward, the
recommended way of getting Nova to work with Quantum should be by
configuring the QuantumManager as the network-manager. However, until
there are still some pending items left in the QuantumManager, would it
make sense to suggest that an option to using the QuantumManager would
be to use the FlatManager configuration, and create Quantum network and
ports separately?

 

Thanks,

~Sumit.

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of Dan Wendlandt
Sent: Sunday, September 25, 2011 10:12 PM
To: netstack@lists.launchpad.net
Subject: Re: [Netstack] Quantum 2011.3 Diablo is out!

 

Hi folks,

I finished a first cut at an "Administrator Guide" for Quantum
(attached), aimed at administrators who will be installing and running
Quantum.  Its pretty simple right now, but is hopefully enough to get
folks started playing with Quantum + Nova.  

It would be great if someone could take a quick look through the
document (attached) and see if anything jumps out as obviously wrong or
missing.  Hopefully we can get at least one other pair of eyes on it
tomorrow morning, then we can send an email out to the OpenStack list
still on Monday.

Right now, the doc does not include any plugin-specific documentation,
it just tells the user to look at the plugin documentation (e.g., a
README file).  To match the docs, the suggested set of topics to cover
in plugin documentation are: 
- any dependencies required by the plugin.
- editing required plugin config files, performing other plugin setup.
(e.g., installing agents)
- validating that the plugin is properly setup
- setting the appropriate vif-plugging flags for nova-compute

Thanks,

Dan

p.s.  I'll be working with Anne to get her thoughts on where we should
host the Quantum docs given the recent changes in where other OpenStack
projects are hosting their docs.  








From: Dan Wendlandt http://d...@nicira.com> >


Date: Fri, 23 Sep 2011 18:07:32 -0700

To: http://netstack@lists.launchpad.net> >


Subject: [Netstack] Quantum 2011.3 Diablo is out!

Hi netstack,

Its official, the first official Quantum release is
available for download:  https://launchpad.net/quantum/+milestone/2011.3

Thanks to everyone for final push to get the release
tested and out... definitely a team effort.  

We've come a very long way since the Diablo summit only
six short months ago and have a great foundation to build on in order to
reach production quality in the Essex timeframe.  

My plan is to hold off announcing the release to the
main OpenStack list until monday, so I can hopefully get a first cut of
the Administrator docs over the weekend so users have something to guide
them through their first experience with Quantum.  

Enjoy the weekend and hopefully we'll be able to dive
into some doc reviews next week, along with planning for the Essex
summit :) 

Dan









-- 
Mailing list: https://launchpad.net/~netstack
  

Post to : n

Re: [Netstack] Quantum 2011.3 Diablo is out!

[Sumit Naiksatam (snaiksat)]

Hi Dan,

 

We have been running the RHEL 6.1 Beta, but since it's Beta, I was not
sure that we want to mention that version number.

 

On the FlatManager configuration, the following can be added as a not in
either in 4.1 or 4.5:

 

"

In cases where one wants to configure the network by making API calls
explicitly to Quantum before bringing up the VM, it is also possible to
use Nova's FlatManager instead of QuantumManager. The following
configuration would need to be specified in the nova.conf file:

 

--network_manager=nova.network.manager.FlatManager

--flat_network_bridge=br100

--fixed_range=192.168.0.0/16

 

You will need to provide the bridge name since the FlatManager
configuration requires it, however you do not need to create that bridge
and it will not be used. As mentioned in the OpenStack documentation, in
the Flat Mode, the IP addresses for VM instances are grabbed from the
subnet, and then injected into the image on launch. Each instance
receives a fixed IP address from the pool of available addresses. The
configuration injection currently only works on Linux-style systems that
keep networking configuration in /etc/network/interfaces.

"

 

Thanks,

~Sumit.

 

From: Dan Wendlandt [mailto:d...@nicira.com] 
Sent: Monday, September 26, 2011 9:06 AM
To: Sumit Naiksatam (snaiksat)
Cc: netstack@lists.launchpad.net
Subject: Re: [Netstack] Quantum 2011.3 Diablo is out!

 

Thanks Sumit, great feedback.  Most comments I just applied, but I had a
couple questions/comments below.

Dan

On Mon, Sep 26, 2011 at 12:12 AM, Sumit Naiksatam (snaiksat)
 wrote:

 

Page 4, 3.1 - "we recommend that you use a recent version of Ubuntu, as
this is a well tested platform" - you can probably qualify this in
parentheses by saying that it has been known to work on RHEL.


I added a mention of RHEL as well.  Are there any specific versions I
should call out?  
 

 

A thought on the QuantumManager - I do agree that going forward,
the recommended way of getting Nova to work with Quantum should be by
configuring the QuantumManager as the network-manager. However, until
there are still some pending items left in the QuantumManager, would it
make sense to suggest that an option to using the QuantumManager would
be to use the FlatManager configuration, and create Quantum network and
ports separately?


Yeah, that's a good idea.  Could you do a quick write-up describing the
configuration steps required, since I haven't run things in this mode in
quite a while?  I think I remember seeing somewhere that they now
require the flat_network_bridge flag to be set?  Do you run this in a
mode where IPs are allocated from a single giant subnet, and thus, any
VM can be plugged into any network?  It would be good if you could
quickly call out the main benefits of this mode compared to
QuantumManager so we can help the reader of the docs understand when
they would use one mode or the other (it will also be a good guide to
what we need to improve with the Quantum manager).  Thanks!  
 

 

Thanks,

~Sumit.

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat <mailto:netstack-bounces%2Bsnaiksat>
=cisco@lists.launchpad.net] On Behalf Of Dan Wendlandt


Sent: Sunday, September 25, 2011 10:12 PM

To: netstack@lists.launchpad.net

Subject: Re: [Netstack] Quantum 2011.3 Diablo is out!

 

Hi folks,

I finished a first cut at an "Administrator Guide" for Quantum
(attached), aimed at administrators who will be installing and running
Quantum.  Its pretty simple right now, but is hopefully enough to get
folks started playing with Quantum + Nova.  

It would be great if someone could take a quick look through the
document (attached) and see if anything jumps out as obviously wrong or
missing.  Hopefully we can get at least one other pair of eyes on it
tomorrow morning, then we can send an email out to the OpenStack list
still on Monday.

Right now, the doc does not include any plugin-specific
documentation, it just tells the user to look at the plugin
documentation (e.g., a README file).  To match the docs, the suggested
set of topics to cover in plugin documentation are: 
- any dependencies required by the plugin.
- editing required plugin config files, performing other plugin
setup. (e.g., installing agents)
- validating that the plugin is properly setup
- setting the appropriate vif-plugging flags for nova-compute

Thanks,

Dan

p.s.  I'll be working with Anne to get her thoughts on where we
should host the Quantum docs given the recent changes in where other
OpenStack projects are hosting their docs.  







 

Re: [Netstack] Quantum 2011.3 Diablo is out!

[Sumit Naiksatam (snaiksat)]

Perfect Dan; yes Vif flags as described in Section 4.2.

 

From: Dan Wendlandt [mailto:d...@nicira.com] 
Sent: Monday, September 26, 2011 2:28 PM
To: Sumit Naiksatam (snaiksat)
Cc: netstack@lists.launchpad.net
Subject: Re: [Netstack] Quantum 2011.3 Diablo is out!

 

Thanks Sumit, I will turn this around quickly, then send an email out to
the main openstack list.  Two quick comments/follow-ups below. 

On Mon, Sep 26, 2011 at 1:19 PM, Sumit Naiksatam (snaiksat)
 wrote:

Hi Dan,

 

We have been running the RHEL 6.1 Beta, but since it's Beta, I was not
sure that we want to mention that version number.


Ok, I will say RHEL 6.x
 

 

On the FlatManager configuration, the following can be added as
a not in either in 4.1 or 4.5:

 

"

In cases where one wants to configure the network by making API
calls explicitly to Quantum before bringing up the VM, it is also
possible to use Nova's FlatManager instead of QuantumManager. The
following configuration would need to be specified in the nova.conf
file:

 

--network_manager=nova.network.manager.FlatManager

--flat_network_bridge=br100

--fixed_range=192.168.0.0/16

 

You will need to provide the bridge name since the FlatManager
configuration requires it, however you do not need to create that bridge
and it will not be used. As mentioned in the OpenStack documentation, in
the Flat Mode, the IP addresses for VM instances are grabbed from the
subnet, and then injected into the image on launch. Each instance
receives a fixed IP address from the pool of available addresses. The
configuration injection currently only works on Linux-style systems that
keep networking configuration in /etc/network/interfaces.

"


Great.  And just to confirm: you also must specify the appropriate
vif-plugging flags for your plugin, as described in section 4.2

Dan

 

 

Thanks,

~Sumit.

 

From: Dan Wendlandt [mailto:d...@nicira.com] 
Sent: Monday, September 26, 2011 9:06 AM
    To: Sumit Naiksatam (snaiksat)
Cc: netstack@lists.launchpad.net


Subject: Re: [Netstack] Quantum 2011.3 Diablo is out!

 

Thanks Sumit, great feedback.  Most comments I just applied, but
I had a couple questions/comments below.

Dan

On Mon, Sep 26, 2011 at 12:12 AM, Sumit Naiksatam (snaiksat)
 wrote:

 

Page 4, 3.1 - "we recommend that you use a recent version of
Ubuntu, as this is a well tested platform" - you can probably qualify
this in parentheses by saying that it has been known to work on RHEL.


I added a mention of RHEL as well.  Are there any specific
versions I should call out?  
 

 

A thought on the QuantumManager - I do agree that going
forward, the recommended way of getting Nova to work with Quantum should
be by configuring the QuantumManager as the network-manager. However,
until there are still some pending items left in the QuantumManager,
would it make sense to suggest that an option to using the
QuantumManager would be to use the FlatManager configuration, and create
Quantum network and ports separately?


Yeah, that's a good idea.  Could you do a quick write-up
describing the configuration steps required, since I haven't run things
in this mode in quite a while?  I think I remember seeing somewhere that
they now require the flat_network_bridge flag to be set?  Do you run
this in a mode where IPs are allocated from a single giant subnet, and
thus, any VM can be plugged into any network?  It would be good if you
could quickly call out the main benefits of this mode compared to
QuantumManager so we can help the reader of the docs understand when
they would use one mode or the other (it will also be a good guide to
what we need to improve with the Quantum manager).  Thanks!  
 

 

Thanks,

~Sumit.

 

From:
netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat <mailto:netstack-bounces%2Bsnaiksat>
=cisco@lists.launchpad.net] On Behalf Of Dan Wendlandt


Sent: Sunday, September 25, 2011 10:12 PM

To: netstack@lists.launchpad.net

Subject: Re: [Netstack] Quantum 2011.3 Diablo is out!

 

Hi folks,

I finished a first cut at an "Administrator Guide" for
Quantum (attached), aimed at administrators who will be installing and
running Quantum.  Its pretty simple right now, but is hopefully enough
to get folks started playing with Quantum + Nova.  

It would be great if someone could take a quick look
through the document (attached) and see if anything jumps 

Re: [Netstack] Quantum API 1.1 session - proposed agenda

[Sumit Naiksatam (snaiksat)]

Thanks Salvatore. I am fine on item 6 and will get back to you with more
info.

 

I am guessing that the discussion on item 2 will help to address the
asynchronous API requirements.

 

As a general suggestion on item 3, can we also consider having the
following attributes be a part of every quantum resource:

 

* label/tag - nullable string, but when set, helps to identify the
resource in a more user friendly way

 

* description - nullable string, or a dictionary - will help the plugin
to add additional information for the resource

 

Thanks,

~Sumit.

 

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of Salvatore Orlando
Sent: Friday, September 30, 2011 2:23 PM
To: netstack@lists.launchpad.net
Subject: [Netstack] Quantum API 1.1 session - proposed agenda

 

Hi Netstackers, 

 

It seems we will have an early start with Quantum API v1.1, Monday at
9.30.

 

The following is a proposal for an agenda that I've put together. 

It will be great to have your feedback.

 

1.   Quantum API v1.0 recap   (5 minutes)

2.   'operational status' for API resources (10 minutes)

3.   Improving usability of the Quantum API (10 minutes)

a.   Filters on query parameters

b.  Pagination for list responses

c.   Links (possibly version-independent) to resources

d.  Rate limiting

e.  Other proposals from the community

4.   Extending Quantum's core (10 minutes)
This topic is about finding the right balance between a small core with
many extensions (what we have currently) are a large core with little
extensions

5.   Improvements to the extensions framework (contributed by Ying -
10 minutes)

6.   API operation rollback (contributed by Sumit - 10 minutes)

 

Sumit and Ying: please let me know if the current allocation works fine
for you. I'm also putting together a few slides to drive the discussion.
So, If you have some slides as well, please let me have them so that I
can put everything together.

 

Salvatore

 

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

[Netstack] Etherpad for L3 Services Blueprint

[Sumit Naiksatam (snaiksat)]

http://etherpad.openstack.org/l3service

Thanks,
~Sumit.

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

Re: [Netstack] Review approval protocol (gerrit)

[Sumit Naiksatam (snaiksat)]

Hi Dan,

 

I have looked at the changes and they seem to be fine. Thanks for taking
care of this.

 

We will need to do more testing on this, and there are other changes as
well for which we will propose a merge soon from another branch. Until
then, this is fine on the trunk.

 

Since the branch was already merged (thanks Brad J), I could not +1/2,
but I added a comment.

 

Thanks,

~Sumit.

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of Dan Wendlandt
Sent: Saturday, October 15, 2011 9:59 PM
To: Brad Hall
Cc: netstack@lists.launchpad.net
Subject: Re: [Netstack] Review approval protocol (gerrit)

 

The net result is that the pep8 fixes I mentioned in my previous email
on in trunk already.   In one way, this is a good thing, as it means
that we can procede integrating other fixes into trunk as well.  On the
other hand, it means my untested changes to the cisco plugin are in
trunk, so it would be great if someone from the cisco team could test it
out ASAP to see if there were any regressions (we can always just
revert).

 

Dan

 

On Sat, Oct 15, 2011 at 9:39 PM, Brad Hall  wrote:

As the first one to completely mess this up (I clicked approve on a
review (+2) when there wasn't a (+1) yet) I figured I'd send out a
link describing the protocol in case anyone other than me missed this
in the documentation.

>From http://wiki.openstack.org/GerritJenkinsGithub:

Any Openstack developer may propose or comment on a change (including
voting +1/0/-1 on it). A vote of +2 is allowed from core reviewers,
but should only be used after another core member has voted +1 and
there are no outstanding -1 votes. If you're coming from Launchpad, a
+2 vote is equivalent to setting a merge prop status to "Approved".
OpenStack projects have a policy of requiring two core reviewers to
approve a patch.

Once a review receives one +2 vote, Jenkins will run the proposed
change and verify the merge. If Jenkins successfully tests the change,
and there are no -2 code review votes, the change will be
automatically merged into the repository.

...

The result of this is that if you +2 something before anyone else
reviewed it, it will just get submitted which violates our 2-reviewer
policy.  Ooops.  Sorry about that..

Thanks,
Brad

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





 

-- 
~~~
Dan Wendlandt 
Nicira Networks, Inc. 
www.nicira.com | www.openvswitch.org
Sr. Product Manager 
cell: 650-906-2650
~~~

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

Re: [Netstack] 'Basic VLAN' plugin - some thoughts

[Sumit Naiksatam (snaiksat)]

Hi Salvatore,

 

Thanks for starting this. A few comments/questions -

 

* You mention - "This model however implies that the Quantum plugin will
be doing not just the 'logical' plugging of the VIF/vNIC, but also the
'physical' plugging, which is not what happens today." May be I am not
reading this correctly, but the underlying plugin implementation today
does perform the physical plugging, right? So how would that be
different in the "basic plugin". Just want to make sure that I
understand you correctly.

 

* You mention - "Compute Manager invokes Network manager for allocating
networks for instance (compute.manager._make_network_info)". This step
would result in the creation on a Quantum network (with the allocation
of a VLAN), right?

 

* Per steps 2 to 6 in the workflow, I gather that the proposal is to
logically associate a VIF with a port first (but what is the trigger for
doing this; create_port()? invoked from where?), and the physical
plugging happens via the VIF driver. Is that correct? If so how will the
VIF ID be available to Quantum (since the VM is not up at that point)?

 

* You mention - "Given this workflow, it turns out that the operations
that the Basic VLAN plugin would performs are exactly the same as the
ones performed by the VIF driver." Per my understanding, the VIF driver
only creates the VIF configuration (including populating any information
on where the VIF would be connected to when it comes up). So I am a
little confused by the earlier statement that the operations are
"exactly the same".

 

* You mention - "Therefore a first potentially extremely simple
implementation of this plugin would consist of a simple 'VLAN ID'
tracker, as it will just provide the VIF driver the appropriate VLAN ID
to configure on each compute host." How will the plugin make the VLAN ID
available to the driver?

 

* You mention - "The ideal destination point would be ending up in a
situation in which we would not need anymore a VIF driver at all." I am
not sure I agree with this (unless of course my understanding for the
need of the VIF driver is incorrect). Isn't the VIF owned by compute
(nova)?

 

* I am not clear as to how the plug/unplug operations on a port are
going to be realized in the above proposal. Could you kindly elaborate?

 

Thanks,

~Sumit. 

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of Salvatore Orlando
Sent: Monday, October 17, 2011 6:55 AM
To: netstack@lists.launchpad.net
Subject: [Netstack] 'Basic VLAN' plugin - some thoughts

 

Hi all, 

 

I put some thoughts regarding the design and the implementation of this
plugin on a wiki page: http://wiki.openstack.org/Quantum-BasicVlanPlugin

Please let me have your feedback. If everything goes according to plan,
I plan to start implementing this plugin in two weeks' time.

 

Regards,

Salvatore

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

Re: [Netstack] Code coverage status

[Sumit Naiksatam (snaiksat)]

On that note, I would also like to nominate Rohit Agarwalla for membership. He 
participated & will continue to do so with code and review activities.

+1 for Edgar

Thanks,
~Sumit.

> -Original Message-
> From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
> [mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
> Behalf Of Brad Hall
> Sent: Tuesday, October 18, 2011 8:06 AM
> To: Dan Wendlandt
> Cc: netstack@lists.launchpad.net
> Subject: Re: [Netstack] Code coverage status
> 
> +1
> 
> On Tue, Oct 18, 2011 at 12:07 AM, Dan Wendlandt  wrote:
> > Thanks for the review Edgar.
> > Folks, since Edgar has been participating with both code + reviews,
> I'd like
> > to nominate him for membership as a core dev.  Please +1 if you
> agree.
> > Dan
> >
> > On Mon, Oct 17, 2011 at 11:15 PM, Edgar Magana (eperdomo)
> >  wrote:
> >>
> >> Hi Brad,
> >>
> >> Good job here... I already +1
> >>
> >> Edgar
> >>
> >> -Original Message-
> >> From: netstack-bounces+eperdomo=cisco@lists.launchpad.net
> >> [mailto:netstack-bounces+eperdomo=cisco@lists.launchpad.net] On
> >> Behalf Of Brad Hall
> >> Sent: Monday, October 17, 2011 11:11 PM
> >> To: netstack@lists.launchpad.net
> >> Subject: [Netstack] Code coverage status
> >>
> >> Hey Everyone,
> >>
> >> After this change goes in (https://review.openstack.org/#change,677
> >> [1]), you'll be able to generate code coverage numbers for our tests
> >> by using run_tests.sh -c.  We're actually doing fairly good so far
> >> (sorry, gmail screws up the font):
> >>
> >>
> >> Name                            Stmts   Miss  Cover   Missing
> >> -
> >> quantum                             0      0   100%
> >> quantum.api                        28      0   100%
> >> quantum.api.api_common             47      0   100%
> >> quantum.api.attachments            48      6    88%   63-64, 74-77
> >> quantum.api.faults                 43      0   100%
> >> quantum.api.networks               65      1    98%   143
> >> quantum.api.ports                  83      4    95%   126-127, 134-
> 135
> >> quantum.api.views                   0      0   100%
> >> quantum.api.views.attachments      10      0   100%
> >> quantum.api.views.networks         23      1    96%   58
> >> quantum.api.views.ports            13      0   100%
> >> quantum.cli_lib                   172     36    79%   86, 141-154,
> >> 184-185, 196-197, 210-211, 224-225, 237-238, 251-252, 264-266,
> >> 287-288, 302-303, 317-318, 330-331
> >> quantum.client                    146     14    90%   123-126,
> >> 132-135, 156, 164, 174, 188, 208-210, 232
> >> quantum.common                      0      0   100%
> >> quantum.common.config             112     75    33%   62-64, 74-90,
> >> 100-120, 131-179, 203-218, 248, 253-254, 283-284, 291-308
> >> quantum.common.exceptions          74     19    74%   55-61, 71-73,
> >> 159-170
> >> quantum.common.extensions         269     33    88%   69, 77, 85,
> 93,
> >> 102, 110-111, 119-120, 128-129, 137, 209, 212, 272-274, 338-343,
> >> 367-370, 379-382, 391-394, 439-443, 446-447, 459
> >> quantum.common.flags              135     67    50%   52-91, 94-97,
> >> 101, 104, 107, 113-122, 127, 130-132, 135-142, 153, 156-160, 182,
> 201,
> >> 203, 237-240
> >> quantum.common.utils              118     79    33%   51, 64-69,
> >> 79-81, 86-91, 95-103, 107-127, 131, 138-147, 152-153, 157-161, 168,
> >> 174-176, 180, 184-186, 190, 194-196, 203-205, 208-223, 226-227
> >> quantum.common.wsgi               243     66    73%   44-45, 48,
> >> 53-54, 61, 65-66, 70-73, 77-78, 102, 106, 110-114, 136, 181, 217,
> >> 228-241, 249-254, 267, 373-374, 413-414, 439-440, 497, 501-506,
> >> 509-512, 519-526
> >> quantum.db                          0      0   100%
> >> quantum.db.api                    136     11    92%   79-80, 94,
> >> 155-156, 196, 219, 226, 261, 266-267
> >> quantum.db.models                  51     13    75%   41, 44-45,
> >> 48-49, 53-54, 59-63, 84, 103
> >> quantum.manager                    36      5    86%   44, 56, 59,
> 61, 66
> >> quantum.plugins                     0      0   100%
> >> quantum.plugins.SamplePlugin      140     19    86%   43, 50, 57,
> 64,
> >> 71, 78, 84, 93, 99, 106, 113, 120, 125, 154, 166, 223, 299-300, 316
> >> quantum.quantum_plugin_base        47     14    70%   54, 70, 85,
> 103,
> >> 120, 139, 153, 169, 187, 206, 220, 232, 258, 260
> >> quantum.utils                      57     33    42%   43-49, 54-59,
> >> 63-80, 86-88
> >> -
> >> TOTAL                            2096    496    76%
> >> 
> --
> >> Ran 233 tests in 5.387s
> >>
> >> Thanks,
> >> Brad
> >>
> >> [1] Need another +1 for the review, btw.
> >>
> >> --
> >> Mailing list: https://launchpad.net/~netstack
> >> Post to     : netstack@lists.launchpad.net
> >> Unsubscribe : https://launch

Re: [Netstack] [Openstack] Announcing Nova subteams

[Sumit Naiksatam (snaiksat)]

Hi,

 

Following up on the topic of nova-network parity, we also wanted to
continue the discussion around how the proposed L3 service can be
leveraged to achieve this.

 

We have posted a very preliminary flow in the document here:
http://wiki.openstack.org/quantum-multi-switch-plugin?action=AttachFile&;
do=view&target=quantum-multiswitch-plugin-SumitNaiksatam.pdf

 

Kindly take a look and comment, we can also bring this up during the IRC
meeting today.

 

Thanks,

~Sumit.

 

From: openstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:openstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of Dan Wendlandt
Sent: Monday, October 17, 2011 6:08 PM
To: Trey Morris
Cc: openstack (openst...@lists.launchpad.net)
Subject: Re: [Openstack] Announcing Nova subteams

 

 

On Mon, Oct 17, 2011 at 3:14 PM, Trey Morris 
wrote:

I notices a gap -> networking

 

Noticed that as well :) 

 

During Essex the Quantum team will be making some non-trivial changes to
the nova network manager code to work better with Quantum (in fact, the
first review should hit tonight, I believe).  See below for more info.  

 

We definitely want to coordinate with anyone else who may be making
changes in this area.  I believe some of the work by the "Nova Feature
Parity Team" may fall in this bucket as well.   

 

Dan

 

Two main goals with Quantum in Essex are: 

1) create/improve functional, integration, and scale testing to support
targeted production deployments. 

2) provide "nova network parity" in that any use case possible with nova
networking should be possible with Quantum as well (there are currently
large gaps).

 

The basic model of integrating with Nova will be the same as in Diablo:
running Nova with a standard Network Manager will continue to work, but
running it with QuantumManager will leverage Quantum + Melange.  To
start, Quantum will just leverage the existing Nova "gateway"
implementation (DHCP, Floating IP, NAT, etc). , allowing them to be
"plugged" into Quantum networks just like Nova vNICs.  

 

Major areas for nova parity include: 

 

- DHCP integration: pretty simple, but requires some small changes to
generalize functionality in linux_net.py and changes to QuantumManager

 

- Floating IPs: the quantum manager class needs to implement the
floating IP python interface.  may need to tweak floating IP code in
manager.py to generalize it a bit so quantum can leverage it with
melange.  I think there's a good amount of work here, particularly if we
plan on using melange to store floating IP info. 

 

- L3 gateway + NAT: similar to what is required for DHCP.  

 

- Security groups:  security groups as implemented with iptables or
libvirt won't work with either of the existing Quantum plugins.  We'll
actually need a way of letting Quantum implement security groups as
well.  This will likely amount to generalizing the ec2 api
implementation to either be able to use a Nova implementation of
security groups, or forward requests to a Quantum security groups API. 

 

- cloudpipe VPN:  now that tenants can have multiple networks, with
QuantumManager we'll need to add an optional flag to specify that a VPN
VM should be spun up on a particular network.  I don't see a ton of work
here.

 

 

 

 

 

 

 

 

On Mon, Oct 17, 2011 at 12:56 AM, Vishvananda Ishaya
 wrote:

Hello Everyone,

 

I've been assimilating the plans from the design summit
into blueprints.  In the process i've noticed that we have a lot planned
for the next few months.  Some of these changes are quite large and
involve people from many different companies that are working on
openstack.  In order to facilitate feature work over the next few
months, I've decided to create a number of subteams.

 

There is too much work going on in nova to manage
everything in one large group, so for sanity's sake, I'm attempting to
break the work up into manageable chunks.  The subteam idea is
experimental.  We will try it for the first two milestones and
re-evaluate after e2 whether we need to make some further changes.

 

My vision is that each subteam is an open group where
interested parties can communicate and plan features.  Some of the teams
will initially be more research oriented, but ultimately these teams
will be focused on implementation.  Each team will have a 'lead' which
will function as a point of contact for the nova PTL.  I'm currently on
all of the teams, and I will do my best to keep track of work going on
in all parts, but I may need to depend on the lead for help with
scheduling and planning.

 

A rough outline of the teams responsibilities are:

 * Planning new features related to the specific area of
focus

 * Congealing plans into specific blueprints

 * Targeting blueprints to milestones

 *

Re: [Netstack] [Openstack] Announcing Nova subteams

[Sumit Naiksatam (snaiksat)]

Apologies for the incorrect link, the link should be:

http://wiki.openstack.org/l3-service?action=AttachFile&do=view&target=qu
antum-nova-parity-SumitNaiksatam-v3.pdf

 

 

From: Sumit Naiksatam (snaiksat) 
Sent: Tuesday, October 18, 2011 2:46 PM
To: 'Dan Wendlandt'; netstack@lists.launchpad.net
Subject: RE: [Openstack] Announcing Nova subteams

 

Hi,

 

Following up on the topic of nova-network parity, we also wanted to
continue the discussion around how the proposed L3 service can be
leveraged to achieve this.

 

We have posted a very preliminary flow in the document here:
http://wiki.openstack.org/quantum-multi-switch-plugin?action=AttachFile&;
do=view&target=quantum-multiswitch-plugin-SumitNaiksatam.pdf

 

Kindly take a look and comment, we can also bring this up during the IRC
meeting today.

 

Thanks,

~Sumit.

 

From: openstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:openstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of Dan Wendlandt
Sent: Monday, October 17, 2011 6:08 PM
To: Trey Morris
Cc: openstack (openst...@lists.launchpad.net)
Subject: Re: [Openstack] Announcing Nova subteams

 

 

On Mon, Oct 17, 2011 at 3:14 PM, Trey Morris 
wrote:

I notices a gap -> networking

 

Noticed that as well :) 

 

During Essex the Quantum team will be making some non-trivial changes to
the nova network manager code to work better with Quantum (in fact, the
first review should hit tonight, I believe).  See below for more info.  

 

We definitely want to coordinate with anyone else who may be making
changes in this area.  I believe some of the work by the "Nova Feature
Parity Team" may fall in this bucket as well.   

 

Dan

 

Two main goals with Quantum in Essex are: 

1) create/improve functional, integration, and scale testing to support
targeted production deployments. 

2) provide "nova network parity" in that any use case possible with nova
networking should be possible with Quantum as well (there are currently
large gaps).

 

The basic model of integrating with Nova will be the same as in Diablo:
running Nova with a standard Network Manager will continue to work, but
running it with QuantumManager will leverage Quantum + Melange.  To
start, Quantum will just leverage the existing Nova "gateway"
implementation (DHCP, Floating IP, NAT, etc). , allowing them to be
"plugged" into Quantum networks just like Nova vNICs.  

 

Major areas for nova parity include: 

 

- DHCP integration: pretty simple, but requires some small changes to
generalize functionality in linux_net.py and changes to QuantumManager

 

- Floating IPs: the quantum manager class needs to implement the
floating IP python interface.  may need to tweak floating IP code in
manager.py to generalize it a bit so quantum can leverage it with
melange.  I think there's a good amount of work here, particularly if we
plan on using melange to store floating IP info. 

 

- L3 gateway + NAT: similar to what is required for DHCP.  

 

- Security groups:  security groups as implemented with iptables or
libvirt won't work with either of the existing Quantum plugins.  We'll
actually need a way of letting Quantum implement security groups as
well.  This will likely amount to generalizing the ec2 api
implementation to either be able to use a Nova implementation of
security groups, or forward requests to a Quantum security groups API. 

 

- cloudpipe VPN:  now that tenants can have multiple networks, with
QuantumManager we'll need to add an optional flag to specify that a VPN
VM should be spun up on a particular network.  I don't see a ton of work
here.

 

 

 

 

 

 

 

 

On Mon, Oct 17, 2011 at 12:56 AM, Vishvananda Ishaya
 wrote:

Hello Everyone,

 

I've been assimilating the plans from the design summit
into blueprints.  In the process i've noticed that we have a lot planned
for the next few months.  Some of these changes are quite large and
involve people from many different companies that are working on
openstack.  In order to facilitate feature work over the next few
months, I've decided to create a number of subteams.

 

There is too much work going on in nova to manage
everything in one large group, so for sanity's sake, I'm attempting to
break the work up into manageable chunks.  The subteam idea is
experimental.  We will try it for the first two milestones and
re-evaluate after e2 whether we need to make some further changes.

 

My vision is that each subteam is an open group where
interested parties can communicate and plan features.  Some of the teams
will initially be more research oriented, but ultimately these teams
will be focused on implementation.  Each team will have a 'lead' which
will function as a point of contact for the nova PTL

Re: [Netstack] Changing the update_{network,port} calls

[Sumit Naiksatam (snaiksat)]

Hi Brad,

Thanks for starting this discussion. A quick note in the context of the
reference to the Cisco plugin in your email (and don't mean to distract
from the broader theme of the discussion), the changes will have to be
made in multiple interfaces & modules (since there is a hierarchy), not
just the top level plugin. We will probably need to coordinate on this
if/when we decide to make these changes.

Thanks,
~Sumit. 

> -Original Message-
> From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
> [mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
> Behalf Of Brad Hall
> Sent: Tuesday, October 18, 2011 1:42 PM
> To: netstack@lists.launchpad.net
> Subject: [Netstack] Changing the update_{network,port} calls
> 
> Hey Everyone,
> 
> Since the change to make the create() calls take a parameter of k/v
> pairs has gotten approval I wanted to propose a change to make the
> update calls do the same.  The review is here:
> https://review.openstack.org/#change,929 .. I've posted this review in
> order to get feedback and to have some code as a discussion starting
> point.
> 
> This has a few unfortunate consequences:
> 
> 1) Rename_net and set_port_state .. both of these are what we had for
> our "update" calls, except they weren't very generic ;)  I've changed
> the plugin interface to remove these calls and replace them with
> generic update_port.  This will break any plugins not in the tree :(
> 
> 2) The CLI will have to change.  Instead of "bin/cli rename_net 
>  foo" we'll have to do something like "bin/cli update_net 
>  name=foo".  Does that seem reasonable?  Looking for feedback
> here.
> 
> Salvatore has a proposal out for changing the API to be more like nova
> with a better deserialize that will (I think) do the same thing here.
> If I'm not mistaken we will still have to change the plugins so if we
> decide to go with his proposal we'll have to do this work anyways.
> 
> Also note that I didn't change the cisco plugins yet .. but I will.  I
> just wanted to see if people are OK with this before I go and do that
> since it is fairly time consuming.  Must be the shear number of tests!
> 
> Thanks,
> Brad
> 
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~netstack
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Netstack] Wiki page for operational status in Quantum API

[Sumit Naiksatam (snaiksat)]

Hi Salv, Echo Dan's suggestions and comments, great write-up.

 

Just a general comment (& this is a nit) - "Examples of situations in
which a resource might not be operative include faults, insufficient
capabilities in the physical or virtual switching layer, or simply, in
the case of ports, the fact that there's no attachment plugged into it
(i.e.: link down)."

 

How about we add the example of the resource being currently
provisioned, that to me seems to be the predominant use case for
providing this status.

 

On a slightly different note, there was also a suggestion to have a
label or tag per resource. Are we still planning to have that? It will
be helpful to have that attribute.

 

Thanks,

~Sumit. 

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of Salvatore Orlando
Sent: Thursday, October 20, 2011 2:49 AM
To: Dan Wendlandt
Cc: netstack@lists.launchpad.net
Subject: Re: [Netstack] Wiki page for operational status in Quantum API

 

Hi Dan,

Thanks for your feedback!

 

Replies inline.

 

From: Dan Wendlandt [mailto:d...@nicira.com] 
Sent: 20 October 2011 03:40
To: Salvatore Orlando
Cc: netstack@lists.launchpad.net
Subject: Re: [Netstack] Wiki page for operational status in Quantum API

 

 

On Wed, Oct 19, 2011 at 4:19 AM, Salvatore Orlando
 wrote:

Hi fellow netstackers,

 

As agreed during yesterday's meeting, here's a wiki page with the
specification for the operational status support in the API:
http://wiki.openstack.org/QuantumOpStatus

 

Great write-up Salvatore!  A couple comments/questions: 

 

- would another way of saying "Failures in Quantum Networks" be
"failures in implementing the logical Quantum network on the switching
infrastructure managed by the Quantum plugin"?  I usually think of the
term "Quantum network" as referring to a logical entity, which itself
cannot fail.  May just be a slightly different mental model. 

 

You're right. I'll fix the wording on the sentence.

 

- "Some plugins can immediately return with an error code".  Can you
elaborate on this?  I would have thought that a plugin would always
accept and perform any legal modification to the logical model.  The
plugin's ability to actually implement the logical model would be
exposed ONLY via the operational status.  How does this compare to your
thinking?   I think you point in bold is something we definitely agree
on, so I don't think we can be that far apart :) 

 

I think that what I wrote is not exactly what I meant. Yes the plugin
definitely accepts and performs any legal modification to the logical
model. Then when they propagate this change to the physical/virtual
switching layer, there might be errors, which cause the 'running'
configuration to be different from the 'logical' one. The operational
status is the only way in which this situation is exposed to users.

 

- I don't totally follow the diagram, though I'm not sure that is
critical :)  I agree with all of the text, I'm just not sure I
understand all of the boxes and arrows.  I would have expected the boxes
on the right side to be something that is contained within the plugin,
not as a separate element.  

 

I wanted to capture the difference between the logical and physical set
of objects. The box for the plugin should contain the logical model as
well, as you pointed out.

 

- The question of what enums to expose is interesting.  At the most
simple level, all the user cares about is "UP" or "DOWN".   I can think
of two reasons we may want to do more: 

1) The system believes the current state to be transient, and thus wants
to let the user know that a change without user action is expect.  This
seems to be the goal with something like "PROVISIONING".   

2) The system believes the user may be able to do something to fix the
problem.  For example, the attachment-id is not found, so perhaps the
user needs to correct the attachment-id, or make sure the VM with that
attachment-id is actually running.  

I'm not sure I understand difference between "DOWN" and "FAILED".
Thinking through various plugin scenarios, I think in practice it could
be hard to know when to use one versus the other as a developer.
Similarly, I'm not sure how the user interprets either field
differently.  One might try to have both a general "error" state and
more specific error states like "attachment-id" not found, but even that
can get tricky as it may be that an attachment-id is not found because
the plugin's connection to the switch is down, not because the
attachment-id actually doesn't exist.  

 

In my opinion a case for "DOWN" would be a port without an attachment
(or with a wrong attachment); on the other hand, a case for FAILED would
be the failure of a physical switch in the network or an hypervisor. 

I don't have very strong opinion on the set of possible operational
states. IMHO, having just UP and DOWN is fine for a start. We can
probably start with them and t

Re: [Netstack] Wiki page for operational status in Quantum API

[Sumit Naiksatam (snaiksat)]

Hi Salvatore/Dan, Yes, we can take a look a this. Salvatore we will sync
with you on a separate thread on how to go about it.

 

Thanks,

~Sumit.

 

From: Salvatore Orlando [mailto:salvatore.orla...@eu.citrix.com] 
Sent: Thursday, October 20, 2011 10:22 AM
To: Sumit Naiksatam (snaiksat); Dan Wendlandt
Cc: netstack@lists.launchpad.net
Subject: RE: [Netstack] Wiki page for operational status in Quantum API

 

Re label/tags: yes, I remember that, and I think it would be quite
useful as well.

Nevertheless, this wiki page was just for the operational status work
item. 

 

Sumit, do you reckon you or somebody else on your team might have some
spare cycles to spend on tags/labels?

 

Regards,

Salvatore

 

From: Sumit Naiksatam (snaiksat) [mailto:snaik...@cisco.com] 
Sent: 20 October 2011 17:22
To: Salvatore Orlando; Dan Wendlandt
Cc: netstack@lists.launchpad.net
Subject: RE: [Netstack] Wiki page for operational status in Quantum API

 

Hi Salv, Echo Dan's suggestions and comments, great write-up.

 

Just a general comment (& this is a nit) - "Examples of situations in
which a resource might not be operative include faults, insufficient
capabilities in the physical or virtual switching layer, or simply, in
the case of ports, the fact that there's no attachment plugged into it
(i.e.: link down)."

 

How about we add the example of the resource being currently
provisioned, that to me seems to be the predominant use case for
providing this status.

 

On a slightly different note, there was also a suggestion to have a
label or tag per resource. Are we still planning to have that? It will
be helpful to have that attribute.

 

Thanks,

~Sumit. 

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of Salvatore Orlando
Sent: Thursday, October 20, 2011 2:49 AM
To: Dan Wendlandt
Cc: netstack@lists.launchpad.net
Subject: Re: [Netstack] Wiki page for operational status in Quantum API

 

Hi Dan,

Thanks for your feedback!

 

Replies inline.

 

From: Dan Wendlandt [mailto:d...@nicira.com] 
Sent: 20 October 2011 03:40
To: Salvatore Orlando
Cc: netstack@lists.launchpad.net
Subject: Re: [Netstack] Wiki page for operational status in Quantum API

 

 

On Wed, Oct 19, 2011 at 4:19 AM, Salvatore Orlando
 wrote:

Hi fellow netstackers,

 

As agreed during yesterday's meeting, here's a wiki page with the
specification for the operational status support in the API:
http://wiki.openstack.org/QuantumOpStatus

 

Great write-up Salvatore!  A couple comments/questions: 

 

- would another way of saying "Failures in Quantum Networks" be
"failures in implementing the logical Quantum network on the switching
infrastructure managed by the Quantum plugin"?  I usually think of the
term "Quantum network" as referring to a logical entity, which itself
cannot fail.  May just be a slightly different mental model. 

 

You're right. I'll fix the wording on the sentence.

 

- "Some plugins can immediately return with an error code".  Can you
elaborate on this?  I would have thought that a plugin would always
accept and perform any legal modification to the logical model.  The
plugin's ability to actually implement the logical model would be
exposed ONLY via the operational status.  How does this compare to your
thinking?   I think you point in bold is something we definitely agree
on, so I don't think we can be that far apart :) 

 

I think that what I wrote is not exactly what I meant. Yes the plugin
definitely accepts and performs any legal modification to the logical
model. Then when they propagate this change to the physical/virtual
switching layer, there might be errors, which cause the 'running'
configuration to be different from the 'logical' one. The operational
status is the only way in which this situation is exposed to users.

 

- I don't totally follow the diagram, though I'm not sure that is
critical :)  I agree with all of the text, I'm just not sure I
understand all of the boxes and arrows.  I would have expected the boxes
on the right side to be something that is contained within the plugin,
not as a separate element.  

 

I wanted to capture the difference between the logical and physical set
of objects. The box for the plugin should contain the logical model as
well, as you pointed out.

 

- The question of what enums to expose is interesting.  At the most
simple level, all the user cares about is "UP" or "DOWN".   I can think
of two reasons we may want to do more: 

1) The system believes the current state to be transient, and thus wants
to let the user know that a change without user action is expect.  This
seems to be the goal with something like "PROVISIONING".   

2) The system believes the user may be able to do something to fix the
problem.  For example, the 

[Netstack] Requesting review

[Sumit Naiksatam (snaiksat)]

Hi All,

We have posted some tests and fixes in the Diablo code for review (this
is all within the Cisco plugin/extensions):
https://review.openstack.org/1070

We need one more person to review.

Thanks,
~Sumit.




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

Re: [Netstack] Howto retrieve a server's VIF

[Sumit Naiksatam (snaiksat)]

A quick comment (and not to distract from the theme of the thread), the UCS 
plugin does support plug and unplug operations.

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net 
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On Behalf Of 
Salvatore Orlando
Sent: Wednesday, November 09, 2011 4:53 AM
To: Joacim Halén; netstack@lists.launchpad.net
Subject: Re: [Netstack] Howto retrieve a server's VIF

 

Hi Joacim, 

Thanks for your interest in Quantum.

 

If you are using nova with the Quantum Network Manager (--network_manager = 
nova.network.quantum.manager), then the manager will take care of plugging the 
VIF into the network for you. In this case you will not have to explicitly 
perform a PUT on the attachment object.

If you are running  the Flat Manager instead, I think you can manually plug 
interfaces into Quantum networks using the API. However, I never tested this, 
and I think this approach might not work with the Cisco UCS plugin.

To this aim, you should be able to retrieve the VIF information from nova using 
the virtual_interface.py API extension module. This module is available in 
nova.api.openstack.contrib and defines an extension of the 'server' resource.  
Therefore if the extension is enabled, you should be able to query virtual 
interfaces using the Openstack API. The default path for extension modules is 
/var/lib/nova/extensions.

 

Let me know if this information helps you in any way.

 

Salvatore

 

From: netstack-bounces+salvatore.orlando=eu.citrix@lists.launchpad.net 
[mailto:netstack-bounces+salvatore.orlando=eu.citrix@lists.launchpad.net] 
On Behalf Of Joacim Halén
Sent: 09 November 2011 12:21
To: netstack@lists.launchpad.net
Subject: [Netstack] Howto retrieve a server's VIF

 

Hi,

 

I am working on a tool to remotely configure networks and servers using the 
Quantum API (restful)  and the Nova Compute Developer API (restful).  I now 
want to use the Quantum function 'Plug Attachment into Port' (documented in 

http://docs.openstack.org/incubation/openstack-network/developer/quantum-api-1.0/content/Put_Attachment.html
 

 ) to plug in a server into a created port. As I understand it I have to 
specify the identity of that server's VIF in the function call. However, I have 
not found any documentation describing how to retrieve the identities of a 
server's VIFs. How are the VIF identifiers meant to be retrieved through 
restful requests (either through Nova, Quantum or through some other 
interface)? 

 

Kind regards,

 

Joacim

 

 

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

Re: [Netstack] where did the common folder go?

[Sumit Naiksatam (snaiksat)]

Hi Edgar,

 

With the splitting of repos, I believe you will need the
python-quantumclient package and the quantum-common packages:

https://launchpad.net/ubuntu/+source/quantum/+index

 

Per my understanding, there is a common git repo for the client and the
common code:

https://github.com/openstack/python-quantumclient

 

Thanks,

~Sumit.

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of Edgar Magana (eperdomo)
Sent: Wednesday, February 01, 2012 6:40 PM
To: netstack@lists.launchpad.net
Subject: [Netstack] where did the common folder go?

 

Hi,

 

I just cloned quantum from github and I am not able anymore of starting
the quantum service:

 

#quantum$ bin/quantum-server 

Traceback (most recent call last):

  File "bin/quantum-server", line 22, in 

from quantum.server import main as server

  File "/home/eperdomo/openstack/quantum/quantum/server/__init__.py",
line 36, in 

from quantum import service

  File "/home/eperdomo/openstack/quantum/quantum/service.py", line 19,
in 

from quantum.common import config

ImportError: No module named common

 

I noticed that the commond folder is gone, si this part of the repo slit
between the client and the server?

It should be like that right?

 

Thanks,

 

Edgar

 

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

Re: [Netstack] where did the common folder go?

[Sumit Naiksatam (snaiksat)]

Hmmm...so will the location for the Ubuntu packages change? I got this
from Admin Document (actually it's an indirect reference).

 

So I guess the current tarballs are to be pulled from:

https://launchpad.net/quantum/essex/essex-3

 

And the packages will come later?

 

For working with the source I listed the Git repo for
python-quantumclient. I believe that is the right/current repo?!?

https://github.com/openstack/python-quantumclient

 

Thanks,

~Sumit.

 

From: Salvatore Orlando [mailto:salvatore.orla...@eu.citrix.com] 
Sent: Thursday, February 02, 2012 1:54 AM
To: Sumit Naiksatam (snaiksat); Edgar Magana (eperdomo);
netstack@lists.launchpad.net
Subject: RE: [Netstack] where did the common folder go?

 

Hi guys,

 

In my development environment I do things slightly differently, as I try
not to use packaged software, since I might end up doing changes in both
quantum and python-quantumclient (quantum relies on its code now).

I just have both repositories and when launching quantum (or unit tests)
I add python-quantumclient's home directory to the PYTHONPATH.

 

Frankly I'm not sure the packages linked by Sumit will still work after
E-3, due to the client-server split. New packages should be available
soon for most distros (I think they are already in debian unstable, not
sure about Ubuntu precise and Fedora).

 

Salvatore

 

From:
netstack-bounces+salvatore.orlando=eu.citrix@lists.launchpad.net
[mailto:netstack-bounces+salvatore.orlando=eu.citrix.com@lists.launchpad
.net] On Behalf Of Sumit Naiksatam (snaiksat)
Sent: 02 February 2012 03:15
To: Edgar Magana (eperdomo); netstack@lists.launchpad.net
Subject: Re: [Netstack] where did the common folder go?

 

Hi Edgar,

 

With the splitting of repos, I believe you will need the
python-quantumclient package and the quantum-common packages:

https://launchpad.net/ubuntu/+source/quantum/+index

 

Per my understanding, there is a common git repo for the client and the
common code:

https://github.com/openstack/python-quantumclient

 

Thanks,

~Sumit.

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of Edgar Magana (eperdomo)
Sent: Wednesday, February 01, 2012 6:40 PM
To: netstack@lists.launchpad.net
Subject: [Netstack] where did the common folder go?

 

Hi,

 

I just cloned quantum from github and I am not able anymore of starting
the quantum service:

 

#quantum$ bin/quantum-server 

Traceback (most recent call last):

  File "bin/quantum-server", line 22, in 

from quantum.server import main as server

  File "/home/eperdomo/openstack/quantum/quantum/server/__init__.py",
line 36, in 

from quantum import service

  File "/home/eperdomo/openstack/quantum/quantum/service.py", line 19,
in 

from quantum.common import config

ImportError: No module named common

 

I noticed that the commond folder is gone, si this part of the repo slit
between the client and the server?

It should be like that right?

 

Thanks,

 

Edgar

 

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

Re: [Netstack] VM creation error in Devstack

[Sumit Naiksatam (snaiksat)]

Hi Dan,

Thanks for the clarifying this, and also kudos for keeping the documentation in 
sync. While on this, is there a way to subscribe to changes in the Quantum 
documentation (or better still, subscribe the netstack mailer)? I think that 
might help to preempt these kind of issues. The general tendency is to read the 
documentation on the first setup, and not as often after that, thus missing 
some of these changes.

Thanks,
~Sumit.  

> -Original Message-
> From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
> [mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
> Behalf Of Dan Wendlandt
> Sent: Tuesday, February 07, 2012 8:36 PM
> To: Shweta Padubidri (shpadubi)
> Cc: netstack@lists.launchpad.net
> Subject: Re: [Netstack] VM creation error in Devstack
> 
> Hi Shweta,
> 
> Thanks for the detailed report, this is very helpful.
> 
> With some recent changes in nova, you can no longer specify the
> project "name" in the --project_id flag for a network.  You must
> specify the keystone "id".  This keystone id for the admin tenant
> would be "ba2436c876564ef985a094a4f71b61c2", and you can use the when
> you create a network with nova-manage.  See:
> http://docs.openstack.org/incubation/openstack-
> network/admin/content/Net-Create-dle455.html
> . Note: a recent change (in keystone?) meant that keystone ids
> switched from being integers to uuids, so the example in the docs
> should be updated to show an example with --project_id= .
> 
> Let me know if that helps.
> 
> Dan
> 
> On Tue, Feb 7, 2012 at 7:08 PM, Shweta Padubidri (shpadubi)
>  wrote:
> > Hi Dan,
> >
> > Thanks for the email.
> >
> > Sure, this is what I did. After the devstack install
> >
> > I created a vm in the default tenant
> > TENANT=
> > USERNAME=
> > . openrc
> > nova boot --flavor 1 --image eeb1801e-a143-4669-96e5-55f753ad26bd
> def_vm1
> >
> > The vm was created.
> >
> > Next I created a network in the admin tenant and then placed a vm in
> that network.
> >
> > nova-manage --flagfile=/opt/stack/nova/bin/nova.conf  network create
> --label=admin-net1 --fixed_range_v4=10.0.10.0/24 --project_id=admin --
> priority=1
> > TENANT=admin
> > USERNAME=admin
> > . openrc
> > nova boot --flavor 1 --image eeb1801e-a143-4669-96e5-55f753ad26bd --
> nic net-id=b1f828c1-d769-4aab-a77a-c999e3b49ecf admin_nw1_vm1
> >
> > So here is the tenant and the network list
> >
> > This is the tenant list
> > ~/devstack$ /opt/stack/keystone/bin/keystone-manage tenant list
> > ---
> > | Tenants                                                         |
> > ---
> > | id                               | name               | enabled |
> > ---
> > | ba2436c876564ef985a094a4f71b61c2 | admin              | True    |
> > | ea1170fdb1df4023aad9c39ff1b85a7d | demo               | True    |
> > | d6d48b0112eb47d48702a9c04ebcc98d | invisible_to_admin | True    |
> > ---
> >
> > This is the network list
> >
> > nova-manage --flagfile=/opt/stack/nova/bin/nova.conf  network
> quantum_list
> > uuid                                    project         priority
>    cidr_v4 , cidr_v6
> > 2012-02-07 18:54:11,091 DEBUG nova.utils [req-1bbf9dc4-2949-4f4f-
> ac33-cc9b5d854436 None None] backend  from '/opt/stack/nova/nova/db/sqlalchemy/api.pyc'> from (pid=6998)
> __get_backend /opt/stack/nova/nova/utils.py:589
> > 904bb84d-5d69-4146-8b44-83b01df786d9    None            None
>    10.0.0.0/24 , None
> > b1f828c1-d769-4aab-a77a-c999e3b49ecf    admin           1
>   10.0.10.0/24 , None
> >
> >
> > But this vm creation gave me the following error in the nova-compute
> logs
> >
> > 2012-02-07 18:03:34,554 ERROR nova.rpc [-] Exception during message
> handling
> > (nova.rpc): TRACE: Traceback (most recent call last):
> > (nova.rpc): TRACE:   File "/opt/stack/nova/nova/rpc/amqp.py", line
> 249, in _process_data
> > (nova.rpc): TRACE:     rval = node_func(context=ctxt, **node_args)
> > (nova.rpc): TRACE:   File "/opt/stack/nova/nova/exception.py", line
> 126, in wrapped
> > (nova.rpc): TRACE:     return f(*args, **kw)
> > (nova.rpc): TRACE:   File "/opt/stack/nova/nova/compute/manager.py",
> line 173, in decorated_function
> > (nova.rpc): TRACE:     self.add_instance_fault_from_exc(context,
> instance_uuid, e)
> > (nova.rpc): TRACE:   File "/usr/lib/python2.7/contextlib.py", line
> 24, in __exit__
> > (nova.rpc): TRACE:     self.gen.next()
> > (nova.rpc): TRACE:   File "/opt/stack/nova/nova/compute/manager.py",
> line 168, in decorated_function
> > (nova.rpc): TRACE:     return function(self, context, instance_uuid,
> *args, **kwargs)
> > (nova.rpc): TRACE:   File "/opt/stack/nova/nova/compute/manager.py",
> line 613, in run_instance
> > (nova.rpc): TRACE:     self._run_instance(context, instance_uuid,
> **kwarg

Re: [Netstack] important bug fix to review

[Sumit Naiksatam (snaiksat)]

Thanks Dan for the heads up; as mentioned on the IRC,  we are looking at
it. Also am signed up for the review.

 

~Sumit.

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of Dan Wendlandt
Sent: Tuesday, February 28, 2012 12:41 PM
To: netstack@lists.launchpad.net
Subject: [Netstack] important bug fix to review

 

Hi folks, please take a look at this review ASAP:
https://review.openstack.org/#change,4647

 

Basically, some plugins where not enforcing that a network was owned by
the tenant making the query.  

 

Also, Cisco plugin team.  The Cisco plugin uses another DB model, and
its unit tests weren't working for me, so I wasn't able to check if this
bug affects your plugin.  Please look into this ASAP. 

 

Dan




 

Commit Msg: 

 

 

 

Fix some plugins that don't check that nets + ports are owned by tenant

 

 

bug 942713  . This bug confuses
the validate_networks() method of
QuantumManager in Nova, causing it to believe that it is valid for a
tenant to plug into a particular network when in fact that network is
not



 

owned by the tenant, nor the "provider".

 

 

The patch also adds unit tests to confirm correct plugin behavior.

 

 

This patch fixes the issue for the Sample Plugin, the OVS plugin,
the Linux Bridge plugin, and the Ryu plugin, all of which has the
same DB model.  Validated the fix with the unit tests.

 

 


I couldn't run the unit tests for the NVP plugin standalone, but by
inspection, the code seems to handle this case.  I wasn't able to run
the Cisco plugin unit tests, and that code uses its own DB model, so I



 

am uncertain whether this issue exists in that plugin.

 

 

 

 

 

 

 

-- 
~~~
Dan Wendlandt 

Nicira Networks: www.nicira.com

twitter: danwendlandt
~~~

 

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

Re: [Netstack] [Openstack] PyCon 2012 Sprints update

[Sumit Naiksatam (snaiksat)]

Hi Michael,

Thanks for taking the lead on this. I was curious to know as to what the
agenda is on the following sprint topic:
"defining a first draft of an API for layer 3 networking support"

Is this discussion in the context of Nova or Quantum (probably both)?

While on that, I would like to draw your attention to a Quantum
blueprint proposal we have submitted a while back and have been actively
developing and discussing:
Blueprint: https://blueprints.launchpad.net/quantum/+spec/quantum-l3-api
More info on this Wiki: http://wiki.openstack.org/quantum-l3
Specification Document:
http://wiki.openstack.org/quantum-l3?action=AttachFile&do=view&target=qu
antum-l3-service-spec-SumitNaiksatam-4.pdf
Git repo (API framework implementation):
http://wiki.openstack.org/quantum-l3?action=AttachFile&do=view&target=qu
antum-l3-service-spec-SumitNaiksatam-4.pdf

Also, if it's available, could you kindly let us know what the OpenStack
Sprint schedule is?

Thanks,
~Sumit.


> -Original Message-
> From: openstack-bounces+snaiksat=cisco@lists.launchpad.net
> [mailto:openstack-bounces+snaiksat=cisco@lists.launchpad.net] On
> Behalf Of Michael Pittaro
> Sent: Sunday, March 11, 2012 11:12 AM
> To: Openstack list
> Subject: [Openstack] PyCon 2012 Sprints update
> 
> Just a reminder that OpenStack is  sprinting at PyCon 2012 in Santa
> Clara, CA starting tomorrow, March 12th.
> 
> You don't have to be a PyCon attendee to attend the sprints in
> person.  However, food was budgeted for conference attendees, so
> plan on bringing a bag lunch or buying lunch locally.
> 
> For sprint topics so far, we have:
> 
>  - solving the "not-file-injection" bootstrap of auth
>  - an effective and agreed upon method for supporting
>read-write metadata (plus or minus the auth concerns)
>  - finishing the RBAC work
>  - defining a first draft of an API for layer 3 networking support
>  - adding test coverage for eventlet in Nova
>  - finishing the Consolidate Testing Infrastructure blueprint
>  - Horizon improvements for Quantum support
>  - Python devstack (check it out on github)
> 
> There is a sprint page on the wiki at
> http://wiki.openstack.org/Sprints/PyCon2012
> 
> The main pycon sprint page is at
> https://us.pycon.org/2012/community/sprints/
> 
> Now's the time to add any other sprint topics to the wiki and review
> open bugs.
> 
> Docs have been lagging the release, so if anyone want's to work on
> documentation I can help with the docs workflow since I've been
> through it a few times.
> 
> mike
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openst...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Netstack] Mac address in quantum port

[Sumit Naiksatam (snaiksat)]

Hi Tomoe,

I don't think we, as a community, have discussed this requirement. In
general, for plugin-specific features, there is always an option to
expose/implement them as extensions. Check the section on API Extensions
here:
http://wiki.openstack.org/QuantumDevelopment

Thanks,
~Sumit.

> -Original Message-
> From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
> [mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
> Behalf Of Tomoe Sugihara
> Sent: Sunday, March 11, 2012 8:02 PM
> To: netstack@lists.launchpad.net
> Subject: [Netstack] Mac address in quantum port
> 
> Hi everyone,
> 
> I just looked at quantum code and leaned that quantum port doesn't
> care about the mac addresses.
> I think it's true that switch port doesn't necessarily have mac
> address in general, but normally switches learn mac addresses per
> port.
> So I thought it would be useful for some implementation of plugins,
> for example to optimize mac learning, to get mac address as a
> parameter for create port API.
> 
> Was there any related discussion about this? I'd appreciate any
> comments on this.
> 
> Cheers,
> Tomoe
> 
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~netstack
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Netstack] bug 948467 - agent root_helper

[Sumit Naiksatam (snaiksat)]

Hi Bob, Thanks for taking this up. Responses inline.

~Sumit.

> -Original Message-
> From: Robert Kukura [mailto:rkuk...@redhat.com]
> Sent: Tuesday, March 13, 2012 9:40 AM
> To: Sumit Naiksatam (snaiksat); Dan Wendlandt; Brad Hall;
> netstack@lists.launchpad.net
> Cc: Christopher Wright
> Subject: bug 948467 - agent root_helper
> 
> I intend to submit a patch today for RC1 so that the linuxbridge and
> openvswitch agents will no longer need to run as root. Instead, they
> will read a root_helper config variable and prepend that to the
> commands
> they execute, as nova does when it executes commands for which
> run_as_root is specified to nova.utils.execute(). Don't worry, I'm not
> pulling in nova.utils, just making minimal modifications to the
> single-file agent implementations.
> 
> I'd like to get buy-in from the plugin agent owners and any other
> interested parties before submitting this, and get consensus on a
> couple
> of choices:
> 
> 1) The default value for the root_helper could be "sudo" (as it is in
> nova), or could be empty. If the agent is already running as root,
then
> using sudo shouldn't hurt anything except for adding a tiny bit of
> overhead, so I'm inclined to put sudo in the .ini files for both
> plugins
> as the value for root_helper. In test situations where the user is not
> root but has unconstrained sudo privileges, it should no longer be
> necessary to run the agents as root. Any objection to defaulting to
> sudo?
> 

 In the LinuxBridge plugin README we do recommend running the
agent as sudo, so your suggestion is consistent. 

> 2) Running the agents with unconstrained sudo privileges is not much
> more secure than running them as root. One option is for
> packages/deployments to run the agents as users who only have the
> needed
> sudo privileges (we could ship a specific sudoers file for each
agent).
> But a more secure option is to use the rootwrap functionality from
> nova,
> since it filters on the entire command line using regular expressions.
> Unfortunately, nova's rootwrap is not currently extensible, so we'd
> need
> to copy it into quantum, renaming the executable from nova-rootwrap to
> quantum-rootwrap. This seems like a good candidate for
openstack-common
> in folsom, but for now copying would be necessary, and also would
avoid
> depending on nova. So I am intending to copy the rootwrap
> implementation
> from nova into quantum and modify it as necessary to support these two
> agents. This will involve adding bin/quantum-rootwrap and adding a
> couple of modules in the quantum/rootwrap namespace, all with no
> non-standard imports. Note that, just as in nova, rootwrap will not be
> used at all unless packages/deployments explicitly enable it by
> changing
> root_helper from "sudo" to "quantum-rootwrap". Is everyone OK with
this
> plan?
> 

 I do agree with the requirement for this, and your approach
seems a good one. However, I am a little jittery about this being
introduced late in the game. Would like to hear what the other folks
think. 

> 3) Would anyone object to adding a command line option to these two
> agents that causes them to log to a file as part of this patch? Or
> should that be handled separately?
> 

 Definitely a very good suggestion. I would tend to think this is
a separate patch though. 

> Please let me know if you have any questions or issues and whether you
> are on board with this as soon as possible, as I'm proceeding with the
> work.
> 
> 
> Thanks,
> 
> -Bob

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

Re: [Netstack] proposal for new quantum-core devs

[Sumit Naiksatam (snaiksat)]

+1 for all!

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of Debo Dutta (dedutta)
Sent: Tuesday, March 13, 2012 4:09 PM
To: Debo Dutta (dedutta); Dan Wendlandt; netstack@lists.launchpad.net
Subject: Re: [Netstack] proposal for new quantum-core devs

 

+1 for Bob Kurkura

+1 for Dave Lapsley 

+1 for Maru Newby

 

From: netstack-bounces+dedutta=cisco@lists.launchpad.net
[mailto:netstack-bounces+dedutta=cisco@lists.launchpad.net] On
Behalf Of Debo Dutta (dedutta)
Sent: Tuesday, March 13, 2012 4:02 PM
To: Dan Wendlandt; netstack@lists.launchpad.net
Subject: Re: [Netstack] proposal for new quantum-core devs

 

+1

 

From: netstack-bounces+dedutta=cisco@lists.launchpad.net
[mailto:netstack-bounces+dedutta=cisco@lists.launchpad.net] On
Behalf Of Dan Wendlandt
Sent: Tuesday, March 13, 2012 3:42 PM
To: netstack@lists.launchpad.net
Subject: [Netstack] proposal for new quantum-core devs

 

Hi folks,

 

We've been lucky to have a good number of new people contributing to
Quantum in the past few months, and so I wanted to start the process of
growing the quantum-core developer team.  

 

To this end, I nominate the following people for quantum core devs: 

 

Bob Kurkura

Dave Lapsley 

Maru Newby

 

All three have already helped significantly in terms of reviewing, and
have started contributing in terms of bug fixes and new capabilities.
If you are an existing core dev, please reply to this email with a +1
(in favor), +0 (abstain), -1 (not in favor) for EACH of them.  Please
reply sometime this week.  

 

This slate is just a first set of people to be nominated, and I think
there are several others who have started contributing recently that
would also be great core devs.  If you're interested, ask me or someone
else on the core team to nominate you.  We'll need to grow the core team
significantly to tackle the work ahead of us in Folsom.  Bring it on!

 

Dan

 

-- 
~~~
Dan Wendlandt 

Nicira Networks: www.nicira.com

twitter: danwendlandt
~~~

 

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

[Netstack] Merge is failing on quantum repo

[Sumit Naiksatam (snaiksat)]

Hi All,

It's failing with the following trace, and we are not sure what's
causing it:

Installing collected packages: quantum
  Running setup.py install for quantum

Installing quantum-linuxbridge-agent script to
/home/jenkins/workspace/gate-quantum-unittests/.tox/jenkins27/bin
Installing quantum-openvswitch-agent script to
/home/jenkins/workspace/gate-quantum-unittests/.tox/jenkins27/bin
Installing quantum-ryu-agent script to
/home/jenkins/workspace/gate-quantum-unittests/.tox/jenkins27/bin
Installing quantum-server script to
/home/jenkins/workspace/gate-quantum-unittests/.tox/jenkins27/bin
Successfully installed quantum
Cleaning up...
[TOX] ERROR: InvocationError: could not find executable 'nosetests'
 [tox summary]
_
[TOX] ERROR: jenkins27: commands failed
Build step 'Execute shell' marked build as failure
Notifying upstream projects of job completion
Finished: FAILURE

The change which is being merged in has nothing to do with tox. Any
pointers?

Thanks,
~Sumit.

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

Re: [Netstack] Merge is failing on quantum repo

[Sumit Naiksatam (snaiksat)]

Thanks Dan for your prompt attention. Plan sounds good, we will stay
tuned for any updates on this.

 

~Sumit.

 

From: Dan Wendlandt [mailto:d...@nicira.com] 
Sent: Thursday, March 15, 2012 11:53 PM
To: Sumit Naiksatam (snaiksat)
Cc: netstack@lists.launchpad.net; Thierry Carrez; Monty Taylor; James E.
Blair
Subject: Re: Merge is failing on quantum repo

 

Hi Sumit,

 

I don't expect that this is a problem with your commit in particular.  

 

I'm CC'ing Monty and James, as my best guess is that this is a backend
CI issue.  Here's the error: 

 

Successfully installed quantum
Cleaning up...
[TOX] ERROR: InvocationError: could not find executable 'nosetests'
 [tox summary]
_
[TOX] ERROR: jenkins27: commands failed
Build step 'Execute shell' marked build as failure
Notifying upstream projects of job completion
Finished: FAILURE
 
 
 
Full log at:
https://jenkins.openstack.org/job/gate-quantum-unittests/212/console

 

Looks like can't merge the two remaining fixes we need for RC1
(https://review.openstack.org/#change,5439,
https://review.openstack.org/#change,5433), so we'll have to delay RC1
until we can get them in.  

 

Other than a newly identified critical issue (i.e., an issue important
enough that if found in RC1 would cause us to issue an RC2), let's close
the repo for commits until these two changes get merged and and Thierry
can pull a milestone-proposed branch representing RC1.  Thanks, 

 

Dan

 

 

On Thu, Mar 15, 2012 at 11:12 PM, Sumit Naiksatam (snaiksat)
 wrote:

Hi All,

It's failing with the following trace, and we are not sure what's
causing it:

Installing collected packages: quantum
 Running setup.py install for quantum

   Installing quantum-linuxbridge-agent script to
/home/jenkins/workspace/gate-quantum-unittests/.tox/jenkins27/bin
   Installing quantum-openvswitch-agent script to
/home/jenkins/workspace/gate-quantum-unittests/.tox/jenkins27/bin
   Installing quantum-ryu-agent script to
/home/jenkins/workspace/gate-quantum-unittests/.tox/jenkins27/bin
   Installing quantum-server script to
/home/jenkins/workspace/gate-quantum-unittests/.tox/jenkins27/bin
Successfully installed quantum
Cleaning up...
[TOX] ERROR: InvocationError: could not find executable 'nosetests'
 [tox summary]
_
[TOX] ERROR: jenkins27: commands failed
Build step 'Execute shell' marked build as failure
Notifying upstream projects of job completion
Finished: FAILURE

The change which is being merged in has nothing to do with tox. Any
pointers?

Thanks,
~Sumit.





 

-- 
~~~
Dan Wendlandt 

Nicira Networks: www.nicira.com

twitter: danwendlandt
~~~

 

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

Re: [Netstack] Merge is failing on quantum repo

[Sumit Naiksatam (snaiksat)]

Thanks Monty, problem seems to have gone away. 

> -Original Message-
> From: Monty Taylor [mailto:mord...@inaugust.com]
> Sent: Friday, March 16, 2012 1:32 AM
> To: Dan Wendlandt
> Cc: Sumit Naiksatam (snaiksat); netstack@lists.launchpad.net; Thierry
> Carrez; James E. Blair
> Subject: Re: Merge is failing on quantum repo
> 
> On it.
> 
> On 03/15/2012 11:53 PM, Dan Wendlandt wrote:
> > Hi Sumit,
> >
> > I don't expect that this is a problem with your commit in
particular.
> >
> > I'm CC'ing Monty and James, as my best guess is that this is a
> backend
> > CI issue.  Here's the error:
> >
> > Successfully installed quantum
> > Cleaning up...
> > [TOX] ERROR: InvocationError: could not find executable 'nosetests'
> >  [tox summary]
> _
> > [TOX] ERROR: jenkins27: commands failed
> > Build step 'Execute shell' marked build as failure
> > Notifying upstream projects of job completion
> > Finished: FAILURE
> >
> >
> >
> > Full log at: https://jenkins.openstack.org/job/gate-quantum-
> unittests/212/console
> >
> >
> > Looks like can't merge the two remaining fixes we need for RC1
> > (https://review.openstack.org/#change,5439,
> > https://review.openstack.org/#change,5433), so we'll have to delay
> RC1
> > until we can get them in.
> >
> > Other than a newly identified critical issue (i.e., an issue
> important
> > enough that if found in RC1 would cause us to issue an RC2), let's
> close
> > the repo for commits until these two changes get merged and and
> Thierry
> > can pull a milestone-proposed branch representing RC1.  Thanks,
> >
> > Dan
> >
> >
> > On Thu, Mar 15, 2012 at 11:12 PM, Sumit Naiksatam (snaiksat)
> > mailto:snaik...@cisco.com>> wrote:
> >
> > Hi All,
> >
> > It's failing with the following trace, and we are not sure
what's
> > causing it:
> >
> > Installing collected packages: quantum
> >  Running setup.py install for quantum
> >
> >Installing quantum-linuxbridge-agent script to
> >
/home/jenkins/workspace/gate-quantum-unittests/.tox/jenkins27/bin
> >Installing quantum-openvswitch-agent script to
> >
/home/jenkins/workspace/gate-quantum-unittests/.tox/jenkins27/bin
> >Installing quantum-ryu-agent script to
> >
/home/jenkins/workspace/gate-quantum-unittests/.tox/jenkins27/bin
> >Installing quantum-server script to
> >
/home/jenkins/workspace/gate-quantum-unittests/.tox/jenkins27/bin
> > Successfully installed quantum
> > Cleaning up...
> > [TOX] ERROR: InvocationError: could not find executable
> 'nosetests'
> >  [tox summary]
> > _
> > [TOX] ERROR: jenkins27: commands failed
> > Build step 'Execute shell' marked build as failure
> > Notifying upstream projects of job completion
> > Finished: FAILURE
> >
> > The change which is being merged in has nothing to do with tox.
> Any
> > pointers?
> >
> > Thanks,
> > ~Sumit.
> >
> >
> >
> >
> > --
> > ~~~
> > Dan Wendlandt
> > Nicira Networks: www.nicira.com <http://www.nicira.com>
> > twitter: danwendlandt
> > ~~~
> >

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

Re: [Netstack] Fwd: [Openstack] Quantum 2012.1 RC1 available

[Sumit Naiksatam (snaiksat)]

Hi Ghe,

 

Thanks for this update. The Linux Bridge plugin also needs an agent. I would 
imagine that the packaging of that agent would be very similar to that of the 
openvswitch-agent, but I don't know enough on the packaging to say with any 
certainty.

 

Also, the Cisco plugin does not use an agent at this time, so no agent 
packaging is required there; just letting you know so that you don't have to 
spend your time exploring.

 

If I am not mistaken, the Ryu plugin also uses an agent.

 

Thanks,

~Sumit.

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net 
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On Behalf Of 
Ghe Rivero
Sent: Tuesday, March 20, 2012 1:17 PM
To: Dan Wendlandt
Cc: netstack@lists.launchpad.net
Subject: Re: [Netstack] Fwd: [Openstack] Quantum 2012.1 RC1 available

 

Hi,

Debian packages for quantum-rc1 are ready to install from unstable (sid) 
ditribution. Up to now, the binaries packages that can be installed for Debian 
are:

Quantum:

*   quantum-plugin-cisco 
*   quantum-plugin-linuxbridge
*   quantum-plugin-nicira
*   quantum-plugin-openvswitch 
*   quantum-plugin-openvswitch-agent 
*   quantum-plugin-ryu 
*   quantum-plugin-sample
*   quantum-server 

Python-quantumclient:

*   python-quantumclient
*   quantum-common

 

Before final release, just a few changes are expected

*plugins packages will be revised (I need to check if someone else 
beside openswitch needs an agent and how to handle it)
*   working default configurations using openvswitch/linuxbridge plugins

Thanks everyone for the great work in this release.

Ghe Rivero

On Tue, Mar 20, 2012 at 6:53 AM, Dan Wendlandt  wrote:

Not sure how many people might be on netstack but not the main openstack ML, 
but Thierry cut the official version of the Quantum RC1 today. 

 

I'm working with folks from Red Hat & Ubuntu to get binary packages based on 
the RC1 for final testing.  Any other distros that are interested, let me know!

 

Dan

 

-- Forwarded message --
From: Thierry Carrez 
Date: Mon, Mar 19, 2012 at 10:00 AM
Subject: [Openstack] Quantum 2012.1 RC1 available
To: "openst...@lists.launchpad.net" 


The first release candidate for Quantum 2012.1 ("Essex") is now
available at:

https://bugs.launchpad.net/quantum/+milestone/essex-rc1

Unless release-critical issues are found that warrant a release
candidate respin, this RC1 will be formally released as the 2012.1 final
version. You are therefore strongly encouraged to test and validate it.

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/quantum/+filebug

and tag it "essex-rc-potential" to bring it to Dan's attention.

The "master" branch of Quantum is now open for Folsom development,
feature freeze restrictions no longer apply.

NB: Quantum is not a core project for the Essex cycle, therefore it's
not part of OpenStack 2012.1 common release, scheduled for April 5.

--
Thierry Carrez (ttx)
Release Manager, OpenStack

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





 

-- 
~~~
Dan Wendlandt 

Nicira Networks: www.nicira.com

twitter: danwendlandt
~~~

 


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





 

-- 

Ghe Rivero
OpenStack & Distribution Engineer
www.stackops.com   |  ghe.riv...@stackops.com 
  | +34 625 63 45 23 | skype:ghe.rivero
 

  

 ADVERTENCIA LEGAL  
Le informamos, como destinatario de este mensaje, que el correo electrónico y 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción, por lo que STACKOPS TECHNOLOGIES S.L. no asume 
responsabilidad alguna por tales circunstancias. Si no consintiese en la 
utilización del correo electrónico o de las comunicaciones vía Internet le 
rogamos nos lo comunique y ponga en nuestro conocimiento de manera inmediata. 
Este mensaje va dirigido, de manera exclusiva, a su destinatario y contiene 
información confidencial y sujeta al secreto profesional, cuya divulgación no 
está permitida por la ley. En caso de haber recibido este mensaje por error, le 
rogamos que, de forma inmediata, nos lo comunique mediante correo electrónico 
remitido a nuestra atención y proceda a su eliminación, así como a la de 
cualquier documento adjunto al mismo. Asimismo,

Re: [Netstack] Fwd: [Openstack] Quantum 2012.1 RC1 available

[Sumit Naiksatam (snaiksat)]

Hi Tomasz,

 

Thanks for your note. I am not sure I completely understand the problems you 
are facing. Please note that the patch you have referred to introduces the 
VIF-driver for Quantum’s Linux Bridge plugin. The behavior of this is slightly 
different from the VIF driver that is used within Nova for plugging into a 
Linux bridge (when using a VLAN-NetworkManager). More responses inline.

 

Thanks,

~Sumit.

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net 
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On Behalf Of 
Tomasz Paszkowski
Sent: Tuesday, March 20, 2012 2:54 PM
To: netstack@lists.launchpad.net
Subject: Re: [Netstack] Fwd: [Openstack] Quantum 2012.1 RC1 available

 



as I wrote in bug report related to linux bridge and quantum in nova this code 
is broken in few places:

 

1)  tap devices for instances are set up (ip link set up) by quantum during 
creation and this is stoping libvirt from changing mac address of this 
interface which is breaking vm startup

 

 We have not seen issues with the VM startup. Could you kindly be a 
little more specific as to which MAC address needs to change, and is not 
getting changed?

 

2)  nova-network is not initializing bridge devices on startup and l3 
interfaces

 

 

 Did you run the Quantum Linux Bridge agent? The agent does this work, 
and it only happens when the first VM comes up on that network. 

 

3)  machine running instances after reboot is loosing all bridges and tap 
devices and there is no code which recreates this. 

 

 I have not tested this, but again, if you were running the Quantum 
Linux Bridge agent, the bridges should get created again. The tap devices are 
created in the VIF driver, so that only happens when Nova calls “plug” on VM 
start-up. 

 

problem 1 and 2 is resolved by code changes in nova and problem nr. 3 is 
addressed by adapting interface type bridge with quantum linux bridge 
integration.

 

patches are on launchpad https://bugs.launchpad.net/nova/+bug/941794

 

 

At the end in my opinion we don't need an agent for linux bridge integration.

 

 As I mentioned earlier, in order to fully support the Quantum 
attach/detach interface semantics, the interface-type has to be set to 
“ethernet” (so that tap devices can be used, and be added to the bridge only 
when attach is called, and vice versa), and the agent has to be run so that the 
per-host configuration is done correctly.  So the agent is needed. Of course, 
if there are any issues, those need to be fixed.


Dnia 20-03-2012 o godz. 22:29 "Sumit Naiksatam (snaiksat)"  
napisał(a):

Hi Ghe,

 

Thanks for this update. The Linux Bridge plugin also needs an agent. I 
would imagine that the packaging of that agent would be very similar to that of 
the openvswitch-agent, but I don’t know enough on the packaging to say with any 
certainty.

 

Also, the Cisco plugin does not use an agent at this time, so no agent 
packaging is required there; just letting you know so that you don’t have to 
spend your time exploring.

 

If I am not mistaken, the Ryu plugin also uses an agent.

 

Thanks,

~Sumit.

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net 
[mailto:netstack-bounces+snaiksat <mailto:netstack-bounces%2Bsnaiksat> 
=cisco@lists.launchpad.net] On Behalf Of Ghe Rivero
Sent: Tuesday, March 20, 2012 1:17 PM
To: Dan Wendlandt
Cc: netstack@lists.launchpad.net
Subject: Re: [Netstack] Fwd: [Openstack] Quantum 2012.1 RC1 available

 

Hi,

Debian packages for quantum-rc1 are ready to install from unstable 
(sid) ditribution. Up to now, the binaries packages that can be installed for 
Debian are:

Quantum:

*   quantum-plugin-cisco 
*   quantum-plugin-linuxbridge
*   quantum-plugin-nicira
*   quantum-plugin-openvswitch 
*   quantum-plugin-openvswitch-agent 
*   quantum-plugin-ryu 
*   quantum-plugin-sample
*   quantum-server 

Python-quantumclient:

*   python-quantumclient
*   quantum-common

 

Before final release, just a few changes are expected

*plugins packages will be revised (I need to check if someone 
else beside openswitch needs an agent and how to handle it)
*   working default configurations using openvswitch/linuxbridge 
plugins

Thanks everyone for the great work in this release.

Ghe Rivero

On Tue, Mar 20, 2012 at 6:53 AM, Dan Wendlandt  wrote:

Not sure how many people might be on netstack but not the main 
openstack ML, but Thierry cut the official version of the Quantum RC1 today. 

 

I'm working with folks from Red Hat & Ubuntu to get binary packages 
based on the RC1

Re: [Netstack] quantum community projects & folsom summit plans

[Sumit Naiksatam (snaiksat)]

Hi Deepak, and All,

I feel this is very good dimension to factor in while prioritizing which tasks 
to take up for Folsom - what are the consumers of the Quantum service asking 
for? Not to say that any, or all of what has already been mentioned in this 
thread is not driven by requirements; I am sure everything is very well thought 
out and merits consideration. But just trying to make a point that it would be 
nice to hear more from current/potential Quantum users as to what their burning 
needs are (probably restating the obvious, and pardon me! :-)).

Thanks,
~Sumit. 



> -Original Message-
> From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
> [mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
> Behalf Of Deepak Garg
> Sent: Tuesday, March 20, 2012 8:09 PM
> To: Edgar Magana (eperdomo)
> Cc: netstack@lists.launchpad.net
> Subject: Re: [Netstack] quantum community projects & folsom summit
> plans
> 
> HI All,
> 
> I didn't find IPv6 support in Dan's list of community and shiny
> projects.
> 
> a. Do we have complete IPv6 support -> all features working well in
> IPv6 with appropriate tests written for the same ?
> b. If not where does it lie in the priority list ?
> 
> I know that there is some demand for IPv6 in the cloud industry.
> 
> 
> Deepak
> 
> 
> 
> 
> On Wed, Mar 21, 2012 at 2:06 AM, Edgar Magana (eperdomo)
>  wrote:
> > Hi Folks,
> >
> >
> >
> > Last summit we presented a session about Network Services Insertion
> were the
> > community supported the fact of having some orchestration mechanisms
> to
> > incorporate L2 services within Quantum. In Essex our team implemented
> a
> > library to insert "In-path" network services under the Cisco PlugIn
> > (quantum/plugins/cisco/services). We would like to extend this
> > implementation covering the following aspects:
> >
> >
> >
> > -  Service insertion utility supporting all available PlugIns
> and
> > coming L3 features
> >
> > -  Moving the code from Quantum Server to Quantum Client
> >
> > -  Include "Out of path" network services (It could include
> some L3
> > functionality or not and that is the part that we would like to
> discuss)
> >
> > -  Any open ideas from the community.
> >
> > -  Removing the DB dependency (or not?)
> >
> >
> >
> > I already registered a brainstorming session to go over this points
> and find
> > out if the community is interested on this and how we can include
> more
> > available open services.
> >
> > This is the link of the proposal:
> > http://wiki.openstack.org/QuantumServicesInsertion
> >
> >
> >
> > I would like to hear your points of view about this and hopefully
> have a
> > great discussion during the summit if that is the case.
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Edgar
> >
> >
> >
> > From: netstack-bounces+eperdomo=cisco@lists.launchpad.net
> > [mailto:netstack-bounces+eperdomo=cisco@lists.launchpad.net] On
> Behalf
> > Of Dan Wendlandt
> > Sent: Tuesday, March 20, 2012 11:52 AM
> > To: hitesh wadekar
> > Cc: netstack@lists.launchpad.net
> > Subject: Re: [Netstack] quantum community projects & folsom summit
> plans
> >
> >
> >
> > Hi folks, I'd like to see some more responses to this thread, so we
> can make
> > sure that we as a community collectively decide on what are the most
> > important topics to cover at the summit.  Having buy-in from the
> whole team
> > is important, as we'll really need to focus our resources to
> accomplish what
> > we need to do to become core in Folsom.  Thanks!
> >
> >
> >
> > Dan
> >
> > On Tue, Mar 13, 2012 at 6:19 PM, hitesh wadekar
> 
> > wrote:
> >
> > Hi Dan,
> >
> > I completely agree with Salvatore comments on (Quantum has an awful
> lot of
> > potential, but to put in Dell's Rob Hirschfeld words: "potential
> means
> > you've got to keep working on it." (see his post on Quantum:
> > http://robhirschfeld.com/2012/02/08/quantum-network-virtualization-
> in-the-openstack-essex-release-2/))
> >
> > I would like to join NetStack team for fixing bugs and community
> projects
> >
> > As I am new to Quantum, hence I will start first to fix low hanging
> fruit
> > bugs. so that I will be acclimatized Quantum environment. once I
> build a
> > rapo then I will fully involve in you listed community projects.
> >
> >
> > Along this I would like to explore OVS and feature enhancement for it
> in
> > Quantum-plug in and  agent. While installing Quantum using DevStack I
> have
> > been encountering with OVS packaging issue for Ubuntu oneiric and
> this is
> > the existing bugs reported on Ubuntu launchpad. I feel we should
> handle such
> > issues in DevStack.
> >
> > Quantum is truly networking project, while working on this, I am 100%
> sure
> > that I will be enjoying to brush up and improve my networking skills.
> >
> > Thanks all for support. I am looking forward to guidance and
> encourage from
> > Netstack as well as OpenStack community.
> >
> > I am looking forward challenging an

Re: [Netstack] Fwd: [Openstack] Quantum 2012.1 RC1 available

[Sumit Naiksatam (snaiksat)]

Hi Tomasz,

A few points to note, and this might make things clearer:

* The gateway initialization happens in a separate driver (I am referring to 
the part of the code which you did not find), please take a look at the 
QuantumLinuxBridgeInterfaceDriver class inside:
nova/network/linux_net.py

* For the reboot scenario that you mention, I did not say that the tap devices 
are created in the agent, I mentioned that only the bridge is created. The tap 
devices are created in the VIF driver. That part of the code needs to execute 
when the VM is being revived.

* As for your suggestion on using the interface type bridge, that would work 
only if plug is called only once in the lifetime of a VM. Quantum tries to 
support semantics beyond that; one should be able to plug a VIF into a port, 
may be unplug at a later time, plug into a port on a separate network, and so 
on. One way to achieve this is by using the interface type ethernet (and that's 
where the agent comes into play, hence it's required).

Thanks,
~Sumit.


> -Original Message-
> From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
> [mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
> Behalf Of Tomasz Paszkowski
> Sent: Wednesday, March 21, 2012 12:13 AM
> To: netstack@lists.launchpad.net
> Subject: Re: [Netstack] Fwd: [Openstack] Quantum 2012.1 RC1 available
> 
> Hi,
> 
> Comments inline
> 
> On Wed, Mar 21, 2012 at 12:18 AM, Sumit Naiksatam (snaiksat)
>  wrote:
> >
> > Hi Tomasz,
> >
> >
> >
> > Thanks for your note. I am not sure I completely understand the
> problems you are facing. Please note that the patch you have referred
> to introduces the VIF-driver for Quantum's Linux Bridge plugin. The
> behavior of this is slightly different from the VIF driver that is used
> within Nova for plugging into a Linux bridge (when using a VLAN-
> NetworkManager). More responses inline.
> 
> VIF driver for Quantum's Linux bridge is already introduced in master:
> 
> ubuntu@vm-builder-2:~/build/nova/nova-
> 2012.1+git201203162209/nova/virt/libvirt$
> grep Quantum *
> vif.py:class QuantumLinuxBridgeVIFDriver(vif.VIFDriver):
> vif.py:"""VIF driver for Linux Bridge when running Quantum."""
> vif.py:
> linux_net.QuantumLinuxBridgeInterfaceDriver.create_tap_dev(dev)
> ubuntu@vm-builder-2:~/build/nova/nova-
> 2012.1+git201203162209/nova/network$
> grep Quantum *
> linux_net.py:# plugs interfaces using Linux Bridge when using
> QuantumManager
> linux_net.py:class
> QuantumLinuxBridgeInterfaceDriver(LinuxNetInterfaceDriver):
> linux_net.py:
> QuantumLinuxBridgeInterfaceDriver.create_tap_dev(dev, mac_address)
> 
> 
> >
> >
> >
> > Thanks,
> >
> > ~Sumit.
> >
> >
> >
> > From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
> [mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
> Behalf Of Tomasz Paszkowski
> > Sent: Tuesday, March 20, 2012 2:54 PM
> > To: netstack@lists.launchpad.net
> >
> >
> > Subject: Re: [Netstack] Fwd: [Openstack] Quantum 2012.1 RC1 available
> >
> >
> >
> >
> >
> > as I wrote in bug report related to linux bridge and quantum in nova
> this code is broken in few places:
> >
> >
> >
> > 1)  tap devices for instances are set up (ip link set up) by
> quantum during creation and this is stoping libvirt from changing mac
> address of this interface which is breaking vm startup
> >
> >
> >
> >  We have not seen issues with the VM startup. Could you kindly
> be a little more specific as to which MAC address needs to change, and
> is not getting changed?
> 
> 
> Hi,
> 
> Default template for libvirt for ethernet type interface is:
> 
> #for $nic in $nics
>     #if $vif_type == 'ethernet'
>         
>             
>             
>             
> 
> If we pass mac address within domain configuration libvirt is trying
> to set mac address on specified interface and this operation fails
> because it can't be performed on up interface (interface is beeing put
> up from nova code). This error stop libvirt from starting vm. Patch
> from http://paste.openstack.org/show/10976/ prevents setting this
> interface up.
> 
> 
> Op
> >
> >
> >
> > 2)  nova-network is not initializing bridge devices on startup
> and l3 interfaces
> >
> >
> >
> >
> >
> >  Did you run the Quantum Linux Bridge agent? The agent does
> this work, and it only happens when the first VM comes up on that
> network. 
> 
> 
> I can't find any code in linuxbridge_q

Re: [Netstack] quantum community projects & folsom summit plans

[Sumit Naiksatam (snaiksat)]

basically is whether Quantum
> needs to interact with the 'interface service' (nova compute in this
> case). We are currently avoiding this with VIF drivers and plugin
> agents. While I find the latter very useful (altough their current
> implementation does not look scalable at all to me), I would consider
> studying a solution for getting rid of the former, and maybe have
nova-
> compute expose some APIs (more at the RPC layer rather than at OS/EC2
> layer) that Quantum might use.
> 
> And finally, refactoring. The current split between quantum and
python-
> novaclient is not really optimal. It is my opinion the first goal
> should be to ensure python-quantumclient is not anymore a dependency
> for quantum.
> 
> Oh, and then there's the whole testing story...
> 
> Regards,
> Salvatore
> 
> > -Original Message-
> > From: netstack-
> > bounces+salvatore.orlando=eu.citrix@lists.launchpad.net
> > [mailto:netstack-
> > bounces+salvatore.orlando=eu.citrix@lists.launchpad.net] On
> Behalf Of
> > Troy Toman
> > Sent: 21 March 2012 15:05
> > To: netstack@lists.launchpad.net
> > Subject: Re: [Netstack] quantum community projects & folsom summit
> plans
> >
> > We would also like to cover some topics that relate to running
> Quantum at
> > scale. This would include API rate limiting and caching,
> understanding the
> > models for scaling out the service and where we should make things
> more
> > asynchronous (or not) to enable increased throughput.
> >
> > As far as votes for items already on Dan's list - Quantum/Melange
> > integration, Quantum/Nova rework, authn/authz are very important
from
> a
> > Rackspace perspective. We would love to dig into these further at
the
> > summit. We'll be increasing our dev participation across the board.
> So, we'll
> > have several people engaging on these topics.
> >
> > Troy
> >
> > On Mar 20, 2012, at 11:18 PM, Sumit Naiksatam (snaiksat) wrote:
> >
> > > Hi Deepak, and All,
> > >
> > > I feel this is very good dimension to factor in while prioritizing
> which tasks
> > to take up for Folsom - what are the consumers of the Quantum
service
> > asking for? Not to say that any, or all of what has already been
> mentioned in
> > this thread is not driven by requirements; I am sure everything is
> very well
> > thought out and merits consideration. But just trying to make a
point
> that it
> > would be nice to hear more from current/potential Quantum users as
to
> > what their burning needs are (probably restating the obvious, and
> pardon
> > me! :-)).
> > >
> > > Thanks,
> > > ~Sumit.
> > >
> > >
> > >
> > >> -Original Message-
> > >> From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
> > >> [mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net]
> On
> > >> Behalf Of Deepak Garg
> > >> Sent: Tuesday, March 20, 2012 8:09 PM
> > >> To: Edgar Magana (eperdomo)
> > >> Cc: netstack@lists.launchpad.net
> > >> Subject: Re: [Netstack] quantum community projects & folsom
summit
> > >> plans
> > >>
> > >> HI All,
> > >>
> > >> I didn't find IPv6 support in Dan's list of community and shiny
> > >> projects.
> > >>
> > >> a. Do we have complete IPv6 support -> all features working well
> in
> > >> IPv6 with appropriate tests written for the same ?
> > >> b. If not where does it lie in the priority list ?
> > >>
> > >> I know that there is some demand for IPv6 in the cloud industry.
> > >>
> > >>
> > >> Deepak
> > >>
> > >>
> > >>
> > >>
> > >> On Wed, Mar 21, 2012 at 2:06 AM, Edgar Magana (eperdomo)
> > >>  wrote:
> > >>> Hi Folks,
> > >>>
> > >>>
> > >>>
> > >>> Last summit we presented a session about Network Services
> Insertion
> > >> were the
> > >>> community supported the fact of having some orchestration
> > mechanisms
> > >> to
> > >>> incorporate L2 services within Quantum. In Essex our team
> > >>> implemented
> > >> a
> > >>> library to insert "In-path" network services under the Cisco
> PlugIn
> > >>> (quantum/plugins/cisco/services). We would like to extend this
> > &

[Netstack] Multinode Devstack with Quantum (was RE: Opensack + Devstack Tutorial)

[Sumit Naiksatam (snaiksat)]

Hi Dave,

Thanks for sharing this. I had been independently working on this a few
days back, and wanted to compare notes with you (I saw other emails as
well on this topic, hence thought it might be helpful to have a broader
discussion).

For the localrc files, 
* Would it be better to use HOST_IP_IFACE instead of just the HOST_IP.
stack.sh seems to derive the IP from the interface, so in case someone
is not using eth0 as their host interface, setting the HOST_IP_IFACE
might help to set the interface as well as the IP.
* On the Compute node, you have n-sch and quantum included. Are these
required to run on the Compute node? Shouldn't it just be n-cpu and
q-agt?

For the stack.sh script, since we are not starting glance on the Compute
node, I had to add the following:
git_clone $GLANCE_REPO $GLANCE_DIR $GLANCE_BRANCH

And since I was not running Quantum on the compute host, I had to do
something like this:
if is_service_enabled q-svc || is_service_enabled q-agt; then
# quantum
git_clone $QUANTUM_REPO $QUANTUM_DIR $QUANTUM_BRANCH
fi

so that the quantum repo gets pulled.

Please let me know your thoughts on the above.

Thanks,
~Sumit.

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of David Lapsley
Sent: Monday, March 12, 2012 5:12 PM
To: netstack@lists.launchpad.net
Subject: [Netstack] Opensack + Devstack Tutorial

Hello Netstackers!

Here is a presentation I gave last week on Single + Multi-node Devstack
+ Quantum deployment. It highlights a few gotchas, gives some sample
configurations, and also describes some high level architectural
features.

http://www.slideshare.net/delapsley1/opensack-quantum-devstack-tutorial

I have some pointers to scripts and patches that Debo and I have been
working on, and will also have some patches for multi-node out this
week.

I hope this is useful. Please let me know if you have any feedback or
questions.

Best regards,

Dave.

@davlaps

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

Re: [Netstack] [Bug 966079] [NEW] starting"plugins/linuxbridge/agent/linuxbridge_quantum_agent.py"failed: no such table: vlan_bindings

[Sumit Naiksatam (snaiksat)]

Hi Christian,

The in-memory database should be used only for running the tests.

As for the MySQL DB conf, I am guessing that you might have not created the 
quantum DB, or the right privileges are not being set on the tables. I am 
paraphrasing the following from the README file; if you follow these steps, I 
think this error will go away (note the database name suggested here is 
quantum_linux_bridge, and if you do use that name, make sure that you have the 
same name in the agent's conf file; both, the Quantum service and the agent 
have to refer to the same DB):

# -- Database config.

(Note: The plugin ships with a default SQLite in-memory database configuration,
 and can be used to run tests without performing the suggested DB config below.)

The Linux Bridge quantum plugin requires access to a mysql database in order
to store configuration and mappings that will be used by the agent. Here is
how to set up the database on the host that you will be running the quantum
service on.

MySQL should be installed on the host, and all plugins and clients
must be configured with access to the database.

To prep mysql, run:

$ mysql -u root -p -e "create database quantum_linux_bridge"

# log in to mysql service
$ mysql -u root -p
# The Linux Bridge Quantum agent running on each compute node must be able to
# make a mysql connection back to the main database server.
mysql> GRANT USAGE ON *.* to root@'yourremotehost' IDENTIFIED BY 'newpassword';
# force update of authorization changes
mysql> FLUSH PRIVILEGES;

(Note: If the remote connection fails to MySQL, you might need to add the IP 
address,
 and/or fully-qualified hostname, and/or unqualified hostname in the above 
GRANT sql
 command. Also, you might need to specify "ALL" instead of "USAGE".)

Thanks,
~Sumit.

> -Original Message-
> From: boun...@canonical.com [mailto:boun...@canonical.com] On Behalf Of
> Christian Berendt
> Sent: Tuesday, March 27, 2012 2:53 AM
> To: Sumit Naiksatam (snaiksat)
> Subject: [Bug 966079] [NEW]
> starting"plugins/linuxbridge/agent/linuxbridge_quantum_agent.py"failed:
> no such table: vlan_bindings
> 
> Public bug reported:
> 
> Not sure what's wrong, I Iconfigured the agent like described in README
> but the database seems to be empty after starting the agent. I can't
> find a hint how to setup the database for the agent correctly.
> 
> # cat /etc/quantum/plugins/linuxbridge/linuxbridge_conf.ini
> [VLANS]
> vlan_start=1000
> vlan_end=3000
> 
> [DATABASE]
> # Use the following when running the tests for the in-memory DB
> connection = sqlite
> # Uncomment the following for using the MySQL DB when actually running
> the plugin,
> # also remove the earlier sqlite connection configuration
> #connection = mysql
> #name = quantum
> #user = quantum
> #pass = testing
> #host = os0001.openstack.b1-systems.de
> # If you use a non-default port for the DB, change the following
> #port = 3306
> 
> [LINUX_BRIDGE]
> #this is the interface connected to the switch on your Quantum network
> physical_interface = eth0
> 
> [AGENT]
> #agent's polling interval in seconds
> polling_interval = 2
> # Change to "sudo quantum-rootwrap" to limit commands that can be run
> # as root.
> root_helper = sudo
> 
> # python /usr/bin/quantum-linuxbridge-agent -v
> /etc/quantum/plugins/linuxbridge/linuxbridge_conf.ini
> INFO:root:Connecting to sqlite DB
> INFO:root:Agent initialized successfully, now running...
> Traceback (most recent call last):
>   File "/usr/bin/quantum-linuxbridge-agent", line 9, in 
> load_entry_point('quantum==2012.1', 'console_scripts', 'quantum-
> linuxbridge-agent')()
>   File "/usr/lib64/python2.7/site-
> packages/quantum/plugins/linuxbridge/agent/linuxbridge_quantum_agent.py
> ", line 474, in main
> plugin.daemon_loop(conn)
>   File "/usr/lib64/python2.7/site-
> packages/quantum/plugins/linuxbridge/agent/linuxbridge_quantum_agent.py
> ", line 415, in daemon_loop
> old_port_bindings)
>   File "/usr/lib64/python2.7/site-
> packages/quantum/plugins/linuxbridge/agent/linuxbridge_quantum_agent.py
> ", line 362, in manage_networks_on_host
> cursor.execute("SELECT * FROM vlan_bindings")
> sqlite3.OperationalError: no such table: vlan_bindings
> 
> 
> for MySQL it's not working, too (connection to the new MySQL database
> is
> working fine):
> 
> 
> INFO:root:Connecting to database quantum on os0001.openstack.b1-
> systems.de
> INFO:root:Agent initialized successfully, now running...
> Traceback (most recent call last):
>   File "/usr/bin/quantum-linuxbridge-agent", line 9, in 
> load_entry_p

Re: [Netstack] Kickstart for Layer 3 discussions

[Sumit Naiksatam (snaiksat)]

Hi Willian, All,

 

Thanks for your thoughts on this. The discussions around L3 abstractions/API 
have been ongoing for a while now. To be precise, the discussions started 
during the Essex design summit, and we took action items away from the summit 
to work during the past few months.  Subsequently, a fair amount of thought and 
work have gone into this resulting in a blueprint: 
https://blueprints.launchpad.net/quantum/+spec/quantum-l3-api, wiki: 
http://wiki.openstack.org/quantum-l3 and, also a working framework which 
realizes this blueprint: 
https://github.com/CiscoSystems/quantum/tree/int/l3apiframework.

 

There has been good feedback around this from several folks, and I encourage 
others to comment as well so that we can have a good plan going into the summit.

 

Thanks,

~Sumit.

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net 
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On Behalf Of 
Willian Molinari
Sent: Thursday, March 29, 2012 12:50 PM
To: netstack@lists.launchpad.net
Subject: [Netstack] Kickstart for Layer 3 discussions

 

Æ!!

Hi folks,

I just want to start the discussions around the layer 3 on quantum.

We developed a plugin to handle firewalls and dhcps, but reading the melange 
spec I found that melange would handle DHCP too.

For firewall we have an agent to handle rules using python-iptables library on 
a different package installed on the firewall server and we're planning to 
implement routing tables as well.

These are our ideas on L3. What do you have in mind?

 

--
Willian Molinari
(a.k.a PotHix)

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

Re: [Netstack] Kickstart for Layer 3 discussions

[Sumit Naiksatam (snaiksat)]

Hi Juliano,

 

Just my thought - absolutely, you should; it will be great to have 
complementary ideas reinforcing the discussion. Is there a document available 
to read up on the firewall/dhcp work that you mention? And perhaps, you can 
also have a look at the references mentioned below, to see how your work can 
complement those?

 

Thanks,

~Sumit.

 

From: Juliano Martinez [mailto:juliano.marti...@locaweb.com.br] 
Sent: Thursday, March 29, 2012 3:33 PM
To: Sumit Naiksatam (snaiksat)
Cc: Willian Molinari; 
Subject: Re: [Netstack] Kickstart for Layer 3 discussions

 

Hi Sumit, 

 

I've been to Essex as well and it was great, aside of the that would be great 
to know if the scope of l3 will be only about routing. We've developed a good 
firewall automation ( focussed on linux firewalls for now ) and dhcp ( which 
sounds like melange will do the work ), so I'd like to know if we should keep 
in mind working on firewall and contribute this code to quantum project :D. 

 

[]'s

Juliano

 

On Mar 29, 2012, at 6:39 PM, Sumit Naiksatam (snaiksat) wrote:





Hi Willian, All,

 

Thanks for your thoughts on this. The discussions around L3 abstractions/API 
have been ongoing for a while now. To be precise, the discussions started 
during the Essex design summit, and we took action items away from the summit 
to work during the past few months.  Subsequently, a fair amount of thought and 
work have gone into this resulting in a blueprint: 
https://blueprints.launchpad.net/quantum/+spec/quantum-l3-api, wiki: 
http://wiki.openstack.org/quantum-l3 and, also a working framework which 
realizes this blueprint: 
https://github.com/CiscoSystems/quantum/tree/int/l3apiframework.

 

There has been good feedback around this from several folks, and I encourage 
others to comment as well so that we can have a good plan going into the summit.

 

Thanks,

~Sumit.

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net 
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On Behalf Of 
Willian Molinari
Sent: Thursday, March 29, 2012 12:50 PM
To: netstack@lists.launchpad.net
Subject: [Netstack] Kickstart for Layer 3 discussions

 

Æ!!

Hi folks,

I just want to start the discussions around the layer 3 on quantum.

We developed a plugin to handle firewalls and dhcps, but reading the melange 
spec I found that melange would handle DHCP too.

For firewall we have an agent to handle rules using python-iptables library on 
a different package installed on the firewall server and we're planning to 
implement routing tables as well.

These are our ideas on L3. What do you have in mind?

 

--
Willian Molinari
(a.k.a PotHix)

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

 

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

[Netstack] L3 Forwarding

[Sumit Naiksatam (snaiksat)]

Hi All,

Per the context setup by Dan in his email on the topic of Quantum L3
Forwarding, here is an addition we are making to the earlier proposal -
API/specification pertaining to creating and managing "targets". I have
updated the API specification with this addition and posted the new
version of the document online. As before, you can find it on the wiki:
http://wiki.openstack.org/quantum-l3 (please refer to the pdf attached
therein, version 5). The new additions are in Section 8 (in case you
want to go straight to those).
 
Following is a summary of the additions:
As you might have gleaned, the proposal until this point catered more to
the tenant/user aspects of the L3 discussion, however it did not address
the service-provider/operator aspects. Some of the feedback we have
received until now also points to the missing SP constructs.
 
The current thinking is that this missing SP aspect should be handled in
a generic way so as to be able to handle different types of L3 entities
like gateways, firewalls, etc. More specifically, in the context of the
current proposal, it amounts to introducing a SP API to manage
"targets". The key attribute when creating a "target" is the IP address
being assigned to this "target". Also note that the definition of the
"target" is in the context of a tenant (and also one or more routetables
for that tenant). Given this definition, the "target" has the following
attributes:
ID: UUID
Name: Public, Private, VPN, etc.
IP Address
Tenant_ID: The tenant for which this "target" is applicable
Routetable IDs: (Optional parameter) One or more routetable IDs
belonging to this tenant for which this target is valid. This provides
for more granular control of the "target " applicability (from a service
provider perspective, e.g. the "Private" target will map to different
end points with respect to different routetables for the same tenant).
 
To illustrate this better, let's take the example of the SP having to
configure an internet gateway for a particular tenant.  Let's say that
the tenant creates a subnet 10.0.0.0/24, and the SP uses the convention
of assigning the first IP in the subnet as a gateway (i.e. 10.0.0.1).
>From a logical model perspective, the SP would then create a "target"
with the following attributes:
ID : UUID-XYZ-1
Name: Public
IP Address: 10.0.0.1
Tenant_ID: UUID-Tenant-ABC
Routetable IDs: [UUID-Routetable-UVW-1]
 
The creation of this logical entity would result in the underlying SP
implementation mapping it to the requirement for the creation of a
gateway entity such that on the tenant network side it would have the
10.0.0.1 IP address, and it would have another interface to the public
network (with some PAT/NAT functionality).
 
Subsequently, the tenant creates a route in the routetable
UUID-Routetable-UVW-1,
Source: 10.0.0.0/24, Destination: default, Target: Public
 
When a VM is now instantiated with an interface on this subnet, the
default route for the packets going out of this interface will lead them
to the gateway 10.0.0.1. Exactly how the L2/L3 networking is setup to
handle this connectivity from the VM to the gateway is specific to that
particular deployment.
 
In the above case, the gateway could be a firewall, and which in turn
might be managed as a separate service. In that case, the SP would
correlate the above created logical "target" resource with a resource
created in that firewall service.
 
We are actively trying to make this a better/simpler proposal, and any
feedback/participation is very much welcome. Thanks in advance and stay
tuned for further iterations on this!
 
~Sumit.

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

Re: [Netstack] L3 Forwarding

[Sumit Naiksatam (snaiksat)]

Hi Jason,

Per the information published, Melange is an IPAM service (information 
repository for the network). Isn't that fundamentally different in function 
from the notion of L3 abstractions/constructs/model required to drive 
routing/forwarding? Reading the specification document referenced in the wiki 
will clarify this. Melange could be an IPAM service for the proposed L3 model 
(these are complementary).

Thanks,
~Sumit. 

> -Original Message-
> From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
> [mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
> Behalf Of Jason Kölker
> Sent: Monday, April 02, 2012 9:16 PM
> To: netstack@lists.launchpad.net
> Subject: Re: [Netstack] L3 Forwarding
> 
> On Mon, 2012-04-02 at 20:59 -0700, Sumit Naiksatam (snaiksat) wrote:
> > Following is a summary of the additions:
> > As you might have gleaned, the proposal until this point catered more
> to
> > the tenant/user aspects of the L3 discussion, however it did not
> address
> > the service-provider/operator aspects. Some of the feedback we have
> > received until now also points to the missing SP constructs.
> >
> > The current thinking is that this missing SP aspect should be handled
> in
> > a generic way so as to be able to handle different types of L3
> entities
> > like gateways, firewalls, etc. More specifically, in the context of
> the
> > current proposal, it amounts to introducing a SP API to manage
> > "targets". The key attribute when creating a "target" is the IP
> address
> > being assigned to this "target". Also note that the definition of the
> > "target" is in the context of a tenant (and also one or more
> routetables
> > for that tenant). Given this definition, the "target" has the
> following
> > attributes:
> > ID: UUID
> > Name: Public, Private, VPN, etc.
> > IP Address
> > Tenant_ID: The tenant for which this "target" is applicable
> > Routetable IDs: (Optional parameter) One or more routetable IDs
> > belonging to this tenant for which this target is valid. This
> provides
> > for more granular control of the "target " applicability (from a
> service
> > provider perspective, e.g. the "Private" target will map to different
> > end points with respect to different routetables for the same
> tenant).
> >
> > To illustrate this better, let's take the example of the SP having to
> > configure an internet gateway for a particular tenant.  Let's say
> that
> > the tenant creates a subnet 10.0.0.0/24, and the SP uses the
> convention
> > of assigning the first IP in the subnet as a gateway (i.e. 10.0.0.1).
> > >From a logical model perspective, the SP would then create a
> "target"
> > with the following attributes:
> > ID : UUID-XYZ-1
> > Name: Public
> > IP Address: 10.0.0.1
> > Tenant_ID: UUID-Tenant-ABC
> > Routetable IDs: [UUID-Routetable-UVW-1]
> >
> > The creation of this logical entity would result in the underlying SP
> > implementation mapping it to the requirement for the creation of a
> > gateway entity such that on the tenant network side it would have the
> > 10.0.0.1 IP address, and it would have another interface to the
> public
> > network (with some PAT/NAT functionality).
> >
> > Subsequently, the tenant creates a route in the routetable
> > UUID-Routetable-UVW-1,
> > Source: 10.0.0.0/24, Destination: default, Target: Public
> >
> > When a VM is now instantiated with an interface on this subnet, the
> > default route for the packets going out of this interface will lead
> them
> > to the gateway 10.0.0.1. Exactly how the L2/L3 networking is setup to
> > handle this connectivity from the VM to the gateway is specific to
> that
> > particular deployment.
> >
> > In the above case, the gateway could be a firewall, and which in turn
> > might be managed as a separate service. In that case, the SP would
> > correlate the above created logical "target" resource with a resource
> > created in that firewall service.
> >
> > We are actively trying to make this a better/simpler proposal, and
> any
> > feedback/participation is very much welcome. Thanks in advance and
> stay
> > tuned for further iterations on this!
> 
> I'm not saying melange is the right way to manage this, but could you
> elaborate the differences between this proposal and allocating an IP in
> melange for a device and creating a route entry for it?
> 
> Happy Hacking!
> 
> 7-11
> 
> 
> 
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~netstack
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Netstack] quantum essex-rc2 is out

[Sumit Naiksatam (snaiksat)]

Hi Dan,

 

On the documentation part, I can try to help to the extent I can. Please
let me know how I can pitch in.

 

Thanks,

~Sumit.

 

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of Dan Wendlandt
Sent: Tuesday, April 03, 2012 10:15 AM
To: netstack@lists.launchpad.net
Subject: [Netstack] quantum essex-rc2 is out

 

Hi team,

 

Quantum Essex RC2 is available:
https://launchpad.net/quantum/essex/essex-rc2

 

This will be the final build unless something very major pops up, as the
release is thursday.  

 

Its VERY important that we test on distros and work on documentation,
since this is how many of our users will experience Quantum.  If you're
putting all of your quantum cycles toward summit stuff, please take a
break to help out and make sure this release is high quality.  

 

I've been doing such testing on Ubuntu and Fedora and have been finding
important items that we need to clean up and or document. 

 

The Fedora work is documented here:
https://fedoraproject.org/wiki/Quantum  .  Bob and created some nice
scripts to automate many parts of the setup process.  

 

We've been working through various Ubuntu packaging issues, but last
night got to the point where the basic quantum and quantum-server
binaries could communicate using the FakePlugin.  Seems like there are
still issues around running the agents that need to be resolved though.
At a glance, it seems like the agents aren't even installed as binaries,
but I could be missing something.  

 

Here's a summary of the Ubuntu packages for those interested in testing:


 

So we have two main packages for quantum in Ubuntu, quantum-server and
python-quantumclient. The quantum-server package in Ubuntu contains the
quantum-server binaries. The python-quantumclient package contains the
quantum "client" (quantum). So it breaks down like this:

quantum-server - quantum-server binaries
quantum-common - Configuration files for quantum-server
plus /var/log/quantum, etc
python-quantum - python libaries for quantum-server and plugins
quantum-plugin-{cisco,nicira,openvswitch,ryu} - Plugin configuration
files.

 

As I also mentioned, we need to update the API guides and Admin Guides
to make sure they are accurate for the release.  If you have some cycles
to help, PLEASE contact me.  

 

Dan

 




 

-- 
~~~
Dan Wendlandt 

Nicira Networks: www.nicira.com

twitter: danwendlandt
~~~

 

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

Re: [Netstack] L3 Forwarding

[Sumit Naiksatam (snaiksat)]

Hi Troy,

Thanks for your response. Would you be able to point us to more information on 
the L3 constructs/abstractions you mention? That way we can unify the ideas and 
arrive at a richer model. We have looked at the Melange wiki and the pointers 
therein to the base API which is for storing and retrieving network 
information. However, this API does not seem to represent a L3 
routing/forwarding model which can drive the underlying implementation.

Thanks,
~Sumit. 

> -Original Message-
> From: Troy Toman [mailto:troy.to...@rackspace.com]
> Sent: Tuesday, April 03, 2012 5:56 AM
> To: Sumit Naiksatam (snaiksat)
> Cc: Jason Kölker; 
> Subject: Re: [Netstack] L3 Forwarding
> 
> 
> On Apr 3, 2012, at 12:24 AM, Sumit Naiksatam (snaiksat) wrote:
> 
> > Hi Jason,
> >
> > Per the information published, Melange is an IPAM service
> (information repository for the network). Isn't that fundamentally
> different in function from the notion of L3
> abstractions/constructs/model required to drive routing/forwarding?
> Reading the specification document referenced in the wiki will clarify
> this. Melange could be an IPAM service for the proposed L3 model (these
> are complementary).
> 
> Melange was built as a network information repository that initially
> focused on IPAM. One thing it does is manage IPs. But, it does have
> some fundamental L3 constructs/abstractions as well. Melange
> understands subnets, outside global/inside local relationships and
> routes, for instance. So, it provides a foundation for many L3
> services. I look forward to talking about how we can evolve this
> thinking at the summit.
> 
> Troy
> 
> >
> > Thanks,
> > ~Sumit.
> >
> >> -Original Message-
> >> From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
> >> [mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
> >> Behalf Of Jason Kölker
> >> Sent: Monday, April 02, 2012 9:16 PM
> >> To: netstack@lists.launchpad.net
> >> Subject: Re: [Netstack] L3 Forwarding
> >>
> >> On Mon, 2012-04-02 at 20:59 -0700, Sumit Naiksatam (snaiksat) wrote:
> >>> Following is a summary of the additions:
> >>> As you might have gleaned, the proposal until this point catered
> more
> >> to
> >>> the tenant/user aspects of the L3 discussion, however it did not
> >> address
> >>> the service-provider/operator aspects. Some of the feedback we have
> >>> received until now also points to the missing SP constructs.
> >>>
> >>> The current thinking is that this missing SP aspect should be
> handled
> >> in
> >>> a generic way so as to be able to handle different types of L3
> >> entities
> >>> like gateways, firewalls, etc. More specifically, in the context of
> >> the
> >>> current proposal, it amounts to introducing a SP API to manage
> >>> "targets". The key attribute when creating a "target" is the IP
> >> address
> >>> being assigned to this "target". Also note that the definition of
> the
> >>> "target" is in the context of a tenant (and also one or more
> >> routetables
> >>> for that tenant). Given this definition, the "target" has the
> >> following
> >>> attributes:
> >>> ID: UUID
> >>> Name: Public, Private, VPN, etc.
> >>> IP Address
> >>> Tenant_ID: The tenant for which this "target" is applicable
> >>> Routetable IDs: (Optional parameter) One or more routetable IDs
> >>> belonging to this tenant for which this target is valid. This
> >> provides
> >>> for more granular control of the "target " applicability (from a
> >> service
> >>> provider perspective, e.g. the "Private" target will map to
> different
> >>> end points with respect to different routetables for the same
> >> tenant).
> >>>
> >>> To illustrate this better, let's take the example of the SP having
> to
> >>> configure an internet gateway for a particular tenant.  Let's say
> >> that
> >>> the tenant creates a subnet 10.0.0.0/24, and the SP uses the
> >> convention
> >>> of assigning the first IP in the subnet as a gateway (i.e.
> 10.0.0.1).
> >>>> From a logical model perspective, the SP would then create a
> >> "target"
> >>> with the following attributes:
> >>> ID : UUID-XYZ-1
> >>> Name: Public
> >>&

Re: [Netstack] quantum essex-rc2 is out

[Sumit Naiksatam (snaiksat)]

Thanks Dan, let me go through these and sync up with you directly (to
avoid unnecessary noise on the mailer).

 

Thanks,

~Sumit.

 

From: Dan Wendlandt [mailto:d...@nicira.com] 
Sent: Tuesday, April 03, 2012 2:44 PM
To: Sumit Naiksatam (snaiksat)
Cc: netstack@lists.launchpad.net
Subject: Re: [Netstack] quantum essex-rc2 is out

 

Thanks Sumit, comments below.

 

Dan

On Tue, Apr 3, 2012 at 2:00 PM, Sumit Naiksatam (snaiksat)
 wrote:

Hi Dan,

 

On the documentation part, I can try to help to the extent I can. Please
let me know how I can pitch in.

 

- API v1.1 spec (diff from 1.0: op-status, filters, anything else?).
This will likely amount to copying and then modifying the 1.0 spec,
unless someone knows a better way.  

- Full review of the Administrator guide to detect any outdated or
missing content (should be minor given that we just had E-4). 

- Document non-plugin Fedora setup in Admin Guide:
https://fedoraproject.org/wiki/Quantum

- Document non-plugin Ubuntu setup in Admin Guide (no link currently) 

 

 

Non doc issues: 

- review and verify patch to fix quantum + devstack:
https://review.openstack.org/#change,6178

- Test with RC2 tarballs:
https://launchpad.net/quantum/+milestone/essex-rc2

- testing with fedora packaging (any plugin)

- testing with ubuntu packaging (any plugin) 

 

 

Thanks,

~Sumit.

 

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat <mailto:netstack-bounces%2Bsnaiksat>
=cisco@lists.launchpad.net] On Behalf Of Dan Wendlandt
Sent: Tuesday, April 03, 2012 10:15 AM
To: netstack@lists.launchpad.net
Subject: [Netstack] quantum essex-rc2 is out

 

Hi team,

 

Quantum Essex RC2 is available:
https://launchpad.net/quantum/essex/essex-rc2

 

This will be the final build unless something very major pops
up, as the release is thursday.  

 

Its VERY important that we test on distros and work on
documentation, since this is how many of our users will experience
Quantum.  If you're putting all of your quantum cycles toward summit
stuff, please take a break to help out and make sure this release is
high quality.  

 

I've been doing such testing on Ubuntu and Fedora and have been
finding important items that we need to clean up and or document. 

 

The Fedora work is documented here:
https://fedoraproject.org/wiki/Quantum  .  Bob and created some nice
scripts to automate many parts of the setup process.  

 

We've been working through various Ubuntu packaging issues, but
last night got to the point where the basic quantum and quantum-server
binaries could communicate using the FakePlugin.  Seems like there are
still issues around running the agents that need to be resolved though.
At a glance, it seems like the agents aren't even installed as binaries,
but I could be missing something.  

 

Here's a summary of the Ubuntu packages for those interested in
testing: 

 

So we have two main packages for quantum in Ubuntu,
quantum-server and
python-quantumclient. The quantum-server package in Ubuntu
contains the
quantum-server binaries. The python-quantumclient package
contains the
quantum "client" (quantum). So it breaks down like this:

quantum-server - quantum-server binaries
quantum-common - Configuration files for quantum-server
plus /var/log/quantum, etc
python-quantum - python libaries for quantum-server and plugins
quantum-plugin-{cisco,nicira,openvswitch,ryu} - Plugin
configuration
files.

 

As I also mentioned, we need to update the API guides and Admin
Guides to make sure they are accurate for the release.  If you have some
cycles to help, PLEASE contact me.  

 

Dan

 




 

-- 
~~~
Dan Wendlandt 

Nicira Networks: www.nicira.com

twitter: danwendlandt
~~~

 





 

-- 
~~~
Dan Wendlandt 

Nicira Networks: www.nicira.com

twitter: danwendlandt
~~~

 

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

Re: [Netstack] quantum community projects & folsom summit plans

[Sumit Naiksatam (snaiksat)]

Here's a thought - to the point on having to avoid churn in the nova
code (on account Quantum plugin specific VIFs), how about we try to
solve this issue via packaging? What if we have a separate Quantum nova
driver package which when deployed will install the VIF drivers in the
appropriate location(s). Existing location for the VIF drivers can be
used as an installation target (or some new convention can be set up).
But, in general, this approach will avoid having to adding/updating
VIF-driver code to nova every time a Quantum plugin requires it.

 

Note also that I am suggesting a separate driver package, and not as a
part of the Quantum server or client/common package since these drivers
are nova-specific and need to be installed only for nova and after nova
is installed.

 

Thanks,

~Sumit.

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of Dan Wendlandt
Sent: Wednesday, April 04, 2012 4:39 PM
To: Ryota MIBU
Cc: netstack@lists.launchpad.net
Subject: Re: [Netstack] quantum community projects & folsom summit plans

 

Thanks for your thoughts on this Ryota.  Some additional comments below.
Happy to chat more about it at the summit as well. 

On Tue, Apr 3, 2012 at 11:42 PM, Ryota MIBU 
wrote:

>
>However, I think the goal should be that code that is in Nova is not
specific to the plugin.  As we talked about
>earlier in the thread, you may need different types of vif-plugging to
attach to different types of switching
>technologies (e.g., OVS vs. bridge vs. VEPA/VNTAG), but I think that
different plugins that use the same switching
>technology should be able to use the same vif-plugging (for example,
there are several plugins that all use the OVS
>vif-plugging).  Our goal here should be to minimize churn in the Nova
codebase.

Yes, I checked the Cisco driver and the portprofile extension.
The Cisco driver seems to pass and retrieve the plugin-specific data
with PUT method.
I just thought that this kind of vif-plugging could be a general model
for plugins that work without "agent".
I agree with you that we should minimize churn in the Nova codebase.
But, I still feel that the "agent" model, especially polling, is not so
good.
Although there are many topics on the summit,
I hope that we could have discussion about vif-plugging changes.

 

One important thing to remember is that, there's no requirement that a
plugin runs an agent.  I believe at least two plugins already, don't use
agents at all, as they have other ways of remotely configuring the
switches when needed. 

 

I think the polling performed by some plugins (e.g., OVS) you mention is
actually really easy to remove by sending notifications to agents using
something like RabbitMQ.  This is something that's already planned for
Folsom.   

 

I think the issue of "agents" is more fundamental.  It may be that the
term "agent" is confusing, as it is really just code that runs as a
service on the hypervisor, just like nova-compute.  The question is
really whether there should be a single python process (all network
logic embedded in nova), or one for nova and one for quantum.  In a way,
having a quantum agent on the hypervisor is similar to what happens when
running nova-network in multi-host model.  

 

There are two key points here in my mind: 

1) We want to minimize network related code churn in Nova.  The vswitch
configuration supported by Quantum plugins will continue to grow over
time, and our goal should be that adding a new capability to a Quantum
plugin should rarely require Nova changes.  

2) Its likely that more advanced plugins need to make changes to the
vswitch at times other than vif-plug and vif-unplug.  For example,
consider that quantum already exposes the ability to put a port in
"admin down" (i.e., no packets forwarded) at any point if a tenant makes
an API request.  

 

It may be that having a more flexible vif-plugging mechanism is still
valuable despite these points, so let's chat more about it at the
summit.  Thanks again for your thoughts. 

 

 

Dan  

 

 




>   I think there is another sub topic, but I am not sure
yet.
>   I agree that a configurable VIF driver is much better.
>   For designing the configuration of vif-plugging, it is
required that we discuss the granularity of selecting
>VIF Driver.
>   Should The granularity of selecting VIF Driver be per
node, VM, or VIF?
>   Currently, VIF Driver would be configured in
nova-compute.conf.
>   This means that the granularity is per Hypervisor Node.
>   To be more flexible, we might consider the case where
VIF1 of VM1 connects to bridge and VIF2 of VM1 maps
>to a physical NIC
>   directly.
>   If so, it may raise another issue; how to determine
connection type of VIF.
>
>
>
>That's an interestin

Re: [Netstack] L3 Forwarding

[Sumit Naiksatam (snaiksat)]

Hi Troy, All,

Thanks for this pointer. Yes I agree, there are constructs in here like the 
subnet which can be leveraged by a L3 (forwarding) component implementation.
 
So just to build on this, and assuming that the IPAM component will be 
integrated into Quantum (btw, is that already decided?), the L3 forwarding 
component's realization can make calls to the IPAM component to store/retrieve 
information pertaining to the subnets, and possibly routes etc. Effectively, 
this IPAM interface can be used internally by the Quantum service, and/or other 
privileged entities (say, the nova service). 

However, we still need to have the L3 abstractions defined on the tenant/user 
side. For instance, take the example of the gateway IP address. Per the Melange 
API, a static route can be created, and requires a gateway IP address. This 
piece of information is more likely defined by the service provider. However, 
the tenant still needs to convey that a particular subnet's default route 
should be to, say, the public network. Hence, the tenant facing API needs to 
have the constructs to be able to express this. Here is a flow with some 
pseudo-calls:

User:create_route() -> Quantum-L3-API:create_route() -> 
Quantum-IPAM:store_route()

(1) User:create_route() conveys that a particular subnet (provides UUID) should 
have a default route to the public network.

(2) Quantum:L3-API:create_route() realizes the call in step (1) inside the 
Quantum service, and configures the underlying infrastructure such that VMs 
instantiated on this subnet will have a default route to the public network. 
While doing so it determines what the gateway IP address is for that default 
route.

(3) Quantum-IPAM:store_route() results in the gateway IP address determined in 
step (2) being stored in the IPAM, such that when a VM comes up, this 
information can be pulled from here.

Just wanted to spell this out; it is probably in line with what you are 
thinking as well?

Thanks,
~Sumit.

> -Original Message-
> From: Troy Toman [mailto:troy.to...@rackspace.com]
> Sent: Tuesday, April 03, 2012 3:28 PM
> To: Sumit Naiksatam (snaiksat)
> Cc: Jason Kölker; 
> Subject: Re: [Netstack] L3 Forwarding
> 
> Sumit,
> 
> You can see the latest Melange documentation here:
> 
> http://melange.readthedocs.org/en/latest/apidoc.html
> 
> There is a section on static routes and a call for creating a tenant
> subnet that I think are relevant. It does not fully implement a routing
> mechanism. But, may be useful for implementing an L3 service.
> 
> Troy
> 
> On Apr 3, 2012, at 4:41 PM, Sumit Naiksatam (snaiksat) wrote:
> 
> > Hi Troy,
> >
> > Thanks for your response. Would you be able to point us to more
> information on the L3 constructs/abstractions you mention? That way we
> can unify the ideas and arrive at a richer model. We have looked at the
> Melange wiki and the pointers therein to the base API which is for
> storing and retrieving network information. However, this API does not
> seem to represent a L3 routing/forwarding model which can drive the
> underlying implementation.
> >
> > Thanks,
> > ~Sumit.
> >
> >> -----Original Message-
> >> From: Troy Toman [mailto:troy.to...@rackspace.com]
> >> Sent: Tuesday, April 03, 2012 5:56 AM
> >> To: Sumit Naiksatam (snaiksat)
> >> Cc: Jason Kölker; 
> >> Subject: Re: [Netstack] L3 Forwarding
> >>
> >>
> >> On Apr 3, 2012, at 12:24 AM, Sumit Naiksatam (snaiksat) wrote:
> >>
> >>> Hi Jason,
> >>>
> >>> Per the information published, Melange is an IPAM service
> >> (information repository for the network). Isn't that fundamentally
> >> different in function from the notion of L3
> >> abstractions/constructs/model required to drive routing/forwarding?
> >> Reading the specification document referenced in the wiki will
> clarify
> >> this. Melange could be an IPAM service for the proposed L3 model
> (these
> >> are complementary).
> >>
> >> Melange was built as a network information repository that initially
> >> focused on IPAM. One thing it does is manage IPs. But, it does have
> >> some fundamental L3 constructs/abstractions as well. Melange
> >> understands subnets, outside global/inside local relationships and
> >> routes, for instance. So, it provides a foundation for many L3
> >> services. I look forward to talking about how we can evolve this
> >> thinking at the summit.
> >>
> >> Troy
> >>
> >>>
> >>> Thanks,
> >>> ~Sumit.
> >>>
> >>>> -Original Message-
> >>>> From: netstack-bo

Re: [Netstack] L3 Forwarding

[Sumit Naiksatam (snaiksat)]

Thanks Andi. Responses inline...

> -Original Message-
> From: andi abes [mailto:andi.a...@gmail.com]
> Sent: Wednesday, April 11, 2012 7:22 PM
> To: Dan Wendlandt
> Cc: Sumit Naiksatam (snaiksat); netstack@lists.launchpad.net
> Subject: Re: [Netstack] L3 Forwarding
> 
> A few (short) thoughts and questions:
> 
> * Might be useful to add a use case where a tenant brings their own
> network service. As Dan points out, a popular case is a load-balancer
> VM. Another interesting set of cases could be encountered in private
> cloud environments, where specialized network resources can be
> utilized as l3 services (e.g. physical firewalls), as long as quantum
> can be made aware of them
> 

 Yes good point. In general, there are probably at least three scenarios 
which need to be accounted for -
* A load balancer like service is provided by the Service Provider. E.g. Amazon 
provides Elastic Load Balancer service. In this case the service is being 
provided by the same entity which is also managing the other network 
infrastructure.
* A user wants to deploy his own service. E.g. User has a Load balancer VM and 
wants to use that to front end his server VMs.
* The service is offered by a 3rd party (it's neither the SP nor the user 
himself). This may not be relevant for all kinds of services, but this does 
introduce issues of access control.


> * There's some interesting verbiage in the Targets section:
> "
> This operation returns the list of all the targets which are available
> to this particular tenant. These will contain a list of system (i.e.
> SP-published targets), and there might be
> others which are published by other tenants.
> "
> Is the thought that the API to register and manage these targets is SP
> specific? Or would it be included in this API?

 The thinking on this has evolved from what is mentioned in this email 
thread. We want to make a distinction between target-types which are abstract, 
and targets which are realization of those target-types (actual entities). 
Target-types would be made available by a SP to the tenants (and would be 
specific to the tenant's context). Tenants would request creation of targets of 
a particular type. More details in the revised proposal here: 
http://wiki.openstack.org/quantum-l3?action=AttachFile&do=view&target=revised-quantum-l3-forwarding-model-sumitnaiksatam-2.pdf


> 
> * Authn ... in the face of multi-tenants. I realize that there are
> other threads on this, but it ties nicely with the targets discussion
> - how do tenants control which other tenants have access to the
> services they might be willing to "publish" as targets?

 Very good point. I was checking the Keystone use cases page, and I 
think a similar use case has been listed where a one tenant needs to perform 
some operation on behalf another tenant. So yes, we will need the support from 
Keystone.


> 
> 
> 
> a.
> 
> On Wed, Apr 11, 2012 at 5:09 PM, Dan Wendlandt  wrote:
> >
> >
> > On Mon, Apr 2, 2012 at 8:59 PM, Sumit Naiksatam (snaiksat)
> >  wrote:
> >>
> >> Hi All,
> >>
> >> Per the context setup by Dan in his email on the topic of Quantum L3
> >> Forwarding, here is an addition we are making to the earlier
> proposal -
> >> API/specification pertaining to creating and managing "targets". I
> have
> >> updated the API specification with this addition and posted the new
> >> version of the document online. As before, you can find it on the
> wiki:
> >> http://wiki.openstack.org/quantum-l3 (please refer to the pdf
> attached
> >> therein, version 5). The new additions are in Section 8 (in case you
> >> want to go straight to those).
> >>
> >> Following is a summary of the additions:
> >> As you might have gleaned, the proposal until this point catered
> more to
> >> the tenant/user aspects of the L3 discussion, however it did not
> address
> >> the service-provider/operator aspects. Some of the feedback we have
> >> received until now also points to the missing SP constructs.
> >>
> >> The current thinking is that this missing SP aspect should be
> handled in
> >> a generic way so as to be able to handle different types of L3
> entities
> >> like gateways, firewalls, etc. More specifically, in the context of
> the
> >> current proposal, it amounts to introducing a SP API to manage
> >> "targets". The key attribute when creating a "target" is the IP
> address
> >> being assigned to this "target". Also note that the definition of
> the
> >> "target" is in the context of a tenant (and als

Re: [Netstack] L3 Forwarding

[Sumit Naiksatam (snaiksat)]

Hi Dan, All,

 

I missed this one...I think I responded to another email in which you
had similar questions, but I noticed that the netstack mailer was not
copied on that (thanks for the feedback!).

 

Some responses/thoughts inline. Discussion to be continued on the white
board! J

 

I believe this session is still targeted for 3 PM, Tuesday. Updated
proposal here:

http://wiki.openstack.org/quantum-l3?action=AttachFile&do=view&target=re
vised-quantum-l3-forwarding-model-sumitnaiksatam-2.pdf 

 

Thanks,

~Sumit.

 

From: Dan Wendlandt [mailto:d...@nicira.com] 
Sent: Wednesday, April 11, 2012 2:09 PM
To: Sumit Naiksatam (snaiksat)
Cc: netstack@lists.launchpad.net; Brad Hall; Carl Perry
Subject: Re: L3 Forwarding

 

 

On Mon, Apr 2, 2012 at 8:59 PM, Sumit Naiksatam (snaiksat)
 wrote:

Hi All,

Per the context setup by Dan in his email on the topic of Quantum L3
Forwarding, here is an addition we are making to the earlier proposal -
API/specification pertaining to creating and managing "targets". I have
updated the API specification with this addition and posted the new
version of the document online. As before, you can find it on the wiki:
http://wiki.openstack.org/quantum-l3 (please refer to the pdf attached
therein, version 5). The new additions are in Section 8 (in case you
want to go straight to those).

Following is a summary of the additions:
As you might have gleaned, the proposal until this point catered more to
the tenant/user aspects of the L3 discussion, however it did not address
the service-provider/operator aspects. Some of the feedback we have
received until now also points to the missing SP constructs.

The current thinking is that this missing SP aspect should be handled in
a generic way so as to be able to handle different types of L3 entities
like gateways, firewalls, etc. More specifically, in the context of the
current proposal, it amounts to introducing a SP API to manage
"targets". The key attribute when creating a "target" is the IP address
being assigned to this "target". Also note that the definition of the
"target" is in the context of a tenant (and also one or more routetables
for that tenant). Given this definition, the "target" has the following
attributes:
ID: UUID
Name: Public, Private, VPN, etc.
IP Address
Tenant_ID: The tenant for which this "target" is applicable
Routetable IDs: (Optional parameter) One or more routetable IDs
belonging to this tenant for which this target is valid. This provides
for more granular control of the "target " applicability (from a service
provider perspective, e.g. the "Private" target will map to different
end points with respect to different routetables for the same tenant).

To illustrate this better, let's take the example of the SP having to
configure an internet gateway for a particular tenant.  Let's say that
the tenant creates a subnet 10.0.0.0/24, and the SP uses the convention
of assigning the first IP in the subnet as a gateway (i.e. 10.0.0.1).
>From a logical model perspective, the SP would then create a "target"
with the following attributes:
ID : UUID-XYZ-1
Name: Public
IP Address: 10.0.0.1
Tenant_ID: UUID-Tenant-ABC
Routetable IDs: [UUID-Routetable-UVW-1]

The creation of this logical entity would result in the underlying SP
implementation mapping it to the requirement for the creation of a
gateway entity such that on the tenant network side it would have the
10.0.0.1 IP address, and it would have another interface to the public
network (with some PAT/NAT functionality).

Subsequently, the tenant creates a route in the routetable
UUID-Routetable-UVW-1,
Source: 10.0.0.0/24, Destination: default, Target: Public

When a VM is now instantiated with an interface on this subnet, the
default route for the packets going out of this interface will lead them
to the gateway 10.0.0.1. Exactly how the L2/L3 networking is setup to
handle this connectivity from the VM to the gateway is specific to that
particular deployment.

 

I'm still trying to wrap my head around this exactly, so let me ask a
clarifying question:  Is a "Routetable" correspond to both a forwarding
rule in the L3-forwarding element, and the description of what routing
should be configured within the VM (e.g., default gateway)?  

 

 Yes, that is thinking. 

 

These two things are definitely related, though one thing I'm struggling
with is what happens if a user changes a route table after a VM has been
booted.  Is the assumption that the we can update such config on the VM?
Or that the state would be inconsistent?  

 

 We could take either approach, but it should be possible to
update the config as well, right? May be using shorter DHCP leases?


 

Also, how to I describe the routing config that should go inside a VM in
a scenario where I don't want Quantum to be performing the L3 forwarding
(e.g., I have a load-bala

[Netstack] L3/IPAM summit discussion follow-up...

[Sumit Naiksatam (snaiksat)]

Hi All,

Thanks for your feedback on the L3 (forwarding) proposal during the
summit and also prior to that. The action item coming out of the summit
session was to further discuss this with the Melange/IPAM team to
identify points of overlap and/or what are the additional requirements.
Accordingly, after focused discussions with many folks including Troy,
Jason, and Trey from the Melange team,  it seems that we are pretty much
on the same page in terms of what the L3 (forwarding) proposal wants to
achieve and how IPAM will support the data-store aspects of this.

There are constructs like the ip_block in (former) Melange which map to
the Subnet (in the L3 forwarding proposal). There are others like the
route-table and targets which might not have a direct mapping, and which
might need to be realized separately. These in turn might drive further
requirements on the IPAM component, but this will be clearer once we
start implementing the L3 forwarding proposal. Also, realizing the
target abstraction will need plugin-level support which might differ
based on the type of the target being realized and the underlying
network infrastructure. So the plan is to go forward with the
implementation of both IPAM and L3 route-table/target API, with both
going into the trunk branch. The work on L3 will hopefully drive any
further needs on the IPAM component.

Specifically on the ip_block/subnet construct, the current thought is to
call it a Subnet. Also, this is better modeled as a separate construct,
rather than an attribute in the virtual network resource, since we
should be able to model 1:n and n:1 relationships between L3 and L2
networks.

Please let us know if you have any further thoughts on this. If you
missed this session during the summit, the slides are posted here:
http://www.slideshare.net/sumit_naik/summit-prepquantuml3modelsumit9

Thanks,
~Sumit.

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

Re: [Netstack] Quantum agents

[Sumit Naiksatam (snaiksat)]

Hi Gary,

 

Thanks for taking up the work on improving the HA aspects of some of the
agents. (I will respond to your review request once I get a chance to
test the changes, but the diff looks good.)

 

I agree with your assessment that the factoring of common agent code is
probably a larger activity, and probably can be targeted as a separate
patch.

 

On your question regarding the need for an agent and if it can be done
in the VIF driver - the VIF driver is not actually an independent thread
of control, it gets executed as a part of the VM creation process. If a
VM's VIF had to be always plugged into the corresponding port only when
a VM was created, then I guess it would be fine to do the plugging from
with the VIF driver. However, we also want to be able to support the use
case that you can bring up the VM and then plug it into a port at a
later time, or unplug and plug into a different network. 

 

In general, there is also a thought that the VIF driver should be really
thin, and to the extent possible Quantum plugin-specific details should
be pulled out it.

 

Thanks,

~Sumit.

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of Gary Kotton
Sent: Wednesday, April 25, 2012 12:55 AM
To: netstack@lists.launchpad.net
Subject: [Netstack] Quantum agents

 

Hi,
Sorry for not being able to attend the IRC meeting - it was in the
middle of the night :)

Whilst I was working on the integration of Quantum into oVirt I
encountered a number of issues and challenges regarding the agents. Some
of the issues were discussed in yesterdays meeting namely:
1. High availability
2. Scalability

High Availability
I discovered that when the agent was unable to access the database it
would terminate on a exception. This has been addressed partially by
https://review.openstack.org/#/c/6744/ (thanks to Maru Newby for the
comments - updated, tested manullay for linuxbridge and ovs). I saw that
Maru opened a bug regarding agent unit tests (kudos). I have tested the
ovs agent and the linux bridge agent manually.
I have yet to update the RYU agent (Isaku Yamahata suggested that we
speak about this at the meeting). I think that we need to address this
across the board and not only in the agents, but also in the plugins.
The database access should be done via a common class that takes the
connectivity into account. I do not feel that this is part of the bug
fix above it is more of a system wide fix. 

Scalability
This is a recurring topic. I understand that from the summit the idea of
using AMQP came up. This still requires a "PUSH" from the plugin to the
specific agent. After dealing with the agents above I wonder if we
actually need the agents? Let me try and elaborate: when a VM is
deployed the VIF plugin (I think that that is the terminology) creates
the tap device, sets it to up and in the case of OVS notifies the
integration bridge of the tap device. In the background the agent is
running. When the agent discovers that the tap device exists and it
matches a attachment from the database it "plugs" the device in and
updates the database with the port status. 
Why not have the VIF plugin also do the interface plugin? This can and
may solve a large number of scalability issues mentioned. This will be
moving part of the logic from the agent to the VIF plugin. 
It would be intersting to know the rationale of the current
implementation.

Thanks
Gary

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

Re: [Netstack] L3/IPAM summit discussion follow-up...

[Sumit Naiksatam (snaiksat)]

> -Original Message-
> From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
> [mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
> Behalf Of Robert Kukura
> Sent: Tuesday, April 24, 2012 12:09 PM
> To: netstack@lists.launchpad.net
> Subject: Re: [Netstack] L3/IPAM summit discussion follow-up...
> 
> On 04/24/2012 10:12 AM, Sumit Naiksatam (snaiksat) wrote:
> > Hi All,
> >
> > Thanks for your feedback on the L3 (forwarding) proposal during the
> > summit and also prior to that. The action item coming out of the
> summit
> > session was to further discuss this with the Melange/IPAM team to
> > identify points of overlap and/or what are the additional
> requirements.
> > Accordingly, after focused discussions with many folks including
> Troy,
> > Jason, and Trey from the Melange team,  it seems that we are pretty
> much
> > on the same page in terms of what the L3 (forwarding) proposal wants
> to
> > achieve and how IPAM will support the data-store aspects of this.
> >
> > There are constructs like the ip_block in (former) Melange which map
> to
> > the Subnet (in the L3 forwarding proposal). There are others like
the
> > route-table and targets which might not have a direct mapping, and
> which
> > might need to be realized separately. These in turn might drive
> further
> > requirements on the IPAM component, but this will be clearer once we
> > start implementing the L3 forwarding proposal. Also, realizing the
> > target abstraction will need plugin-level support which might differ
> > based on the type of the target being realized and the underlying
> > network infrastructure. So the plan is to go forward with the
> > implementation of both IPAM and L3 route-table/target API, with both
> > going into the trunk branch. The work on L3 will hopefully drive any
> > further needs on the IPAM component.
> >
> > Specifically on the ip_block/subnet construct, the current thought
is
> to
> > call it a Subnet. Also, this is better modeled as a separate
> construct,
> > rather than an attribute in the virtual network resource, since we
> > should be able to model 1:n and n:1 relationships between L3 and L2
> > networks.
> >
> > Please let us know if you have any further thoughts on this. If you
> > missed this session during the summit, the slides are posted here:
> > http://www.slideshare.net/sumit_naik/summit-prepquantuml3modelsumit9
> >
> > Thanks,
> > ~Sumit.
> >
> 
> This all sounds reasonable to me, as far as it goes. I was at the
> quantum summit sessions and re-read the slides and proposal, but I'm
> still not at all clear on how the melange and L3-forwarding
> functionality will relate to quantum plugins:
> 
> 1) Is the merge of melange into quantum going to be pluggable, or is
> the
> IPAM implementation going to be built directly into quantum-server (or
> a
> separate server)?
> 
> 2) If the IPAM functionality is going to be pluggable, will this be
> part
> of the same plugin handling L2, or will it be a separate plugin that
> can
> be configured independently of the the L2 plugin?
> 
> 3) I expect that the L3-forwarding functionality will be pluggable.
> Will
> this be handled by the same plugin as L2 and/or IPAM, or as a separate
> L3 plugin?
> 
> Thanks,
> 
> -Bob

Hi Bob,

Those are good questions, and I am not completely clear on this as well
(I don't recall a discussion on this during the summit either). I
believe that the team implementing the IPAM functionality has a plan
around how to integrate this functionality, possibly as libraries which
the Quantum plugins can use?

On the implementation of the L3 functionality (with reference to our
proposal), our earlier suggestion was that it be implemented as a
separate plugin from that of a L2 plugin. It seemed like a more modular
approach with the advantage of being able to use different combination
of plugins. I do recall reading some concerns in this list around
ensuring the compatibility of L3 and L2 plugins. This is a valid
concern, however, plugin configuration is a cloud-operator/SP activity,
who will probably have good knowledge of the plugin behavior and hence
can ensure the configuration of compatible plugins. Of course, if one
wants to implement everything in the same plugin, that should still be
possible.

Thanks,
~Sumit.



> 
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~netstack
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Netstack] L3/IPAM summit discussion follow-up...

[Sumit Naiksatam (snaiksat)]

 

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of Dan Wendlandt
Sent: Tuesday, April 24, 2012 1:38 PM
To: Robert Kukura
Cc: netstack@lists.launchpad.net
Subject: Re: [Netstack] L3/IPAM summit discussion follow-up...

 

I think we're having a bit of a terminology clash here, at least
according to what I intended by the definitions posted on the etherpad:
http://etherpad.openstack.org/quantum-folsom .  The existing definitions
for "IPAM" and "L3 Forwarding" are below.  

 

 During the summit we called the proposal - "L3 Tenant-facing
Abstractions/Model". I don't recall any differences of opinion on this,
is everyone comfortable with this?  

 

I believe that at the end of Sumit's presentation we decided that his
proposal was a higher-level abstraction on top of our existing "IPAM"
plan from merging Melange. In particularly, the "route-table" was about
what routes that would be injected into the VM such that the VM would
have different next hops (route information injected into the VM is
within the scope of Melange IPAM).  I believe we concluded that these
route-tables were NOT about implementing "L3 forwarding" between two
different "L2 Quantum Networks".

 

 The route-tables (and the entries therein) are proposed as an
abstraction for the tenant to request forwarding between subnets (and
also to service-gateways, referred to as "targets"). The underlying
implementation (realizing the abstraction) could  implicitly/explicitly
map the subnets to L2 networks and achieve the L3 forwarding as
required. I believe this was fairly well understood. In that context, I
am having trouble understanding the above explanation.  

 

We talked separately about an "L3 forwarding" implementation, that would
allow pluggable implementations of a logical L3 forwarding element
capable of achieving nova-parity, namely: basic L3 forwarding, SNAT, and
DNAT (i.e., what is already implemented in linux_net.py).  This L3
forwarding element would be able to route between multiple Quantum L2
networks (one might call it a "router", but apparently that's
discouraged :P ).  

 

 It will be helpful if you can please point us to the
session/slides where this "L3 forwarding element" was discussed?


 

I'm REALLY hoping that we're all on the same page here, otherwise, we
may need to start back at square one :)

 

Dan

 

 

 

 - IP Address Management (IPAM): 

 * How virtual servers as allocated IP addresses based on their network
connectivity (http://en.wikipedia.org/wiki/IP_address_management)

 * Often includes other network identifiers that are also configured on
a virtual server, including MAC address, subnet mask gateways, routes,
DNS servers, etc. 

 * This type of functionality is currently provided by Melange, which
will be integrated into Quantum during Folsom. 

 * IPAM is needed even if VMs are only connected to L2 Quantum networks
(i.e., it does not required "L3 forwarding" or other logical features
described below).   

 * Note: this does NOT specify how these identifiers are "injected" into
the server itself (could be via disk injections, DHCP,
cloud-init+metadata, statically configured by admin)

 

 

- L3 Forwarding 

 * Quantum "networks" provide an L2 service model.  There are use cases
that require connecting virtual servers that are not on the same L2
network + subnets, and are therefore connected only by an element
performing L3 forwarding.  

 * Note: this L3 forwarding element is a logical abstraction.  We make
no statement how how it is implemented (e.g., by a VM appliance, a
physical router, or something else). 

 * These L3 forwarding elements would likely expose some kind of a
"routing table" to describe the rules used to forward between different
L2-subnets.  

 * A common use case is that an L2-network/subnet is a trust domain
(private tenant networks, tier of a web application), yet communication
is required between trust domains.  

 * We separate out firewall and NAT into a separate discussion, below.  

 * L3 forwarding has a dependency on understanding the IPAM data for a
particular subnet that it is connected to (e.g., network address/mask,
gateway address)  

 * Note: the primary focus of this is defining L3 forwarding between
endpoints WITHIN a Quantum deployment.  Connectivity between different
Quantum deployments, or to remote datacenters not running Quantum is
viewed many as a separate service (e.g., L3VPN-service). 

 

 

 

On Tue, Apr 24, 2012 at 12:08 PM, Robert Kukura 
wrote:

On 04/24/2012 10:12 AM, Sumit Naiksatam (snaiksat) wrote:
> Hi All,
>
> Thanks for your feedback on the L3 (forwarding) proposal during the
> summit and also prior to that. The action item coming out of the
summit
> session was

Re: [Netstack] Scalable Agents(https://blueprints.launchpad.net/quantum/+spec/scalable-agent-comms)

[Sumit Naiksatam (snaiksat)]

Hi Gary,

Thanks for initiating this. A couple of comments/questions -

1. Do we really need the VIF driver to communicate the agent's identity;
I am referring to the agent ID being sent by the VIF driver in the
message? In general, I am not sure if there is a need to have the VIF
driver send messages/notifications in the first place, but I perhaps
it's being included as a capability in the framework?

2. One model I was thinking of (which is kind of inline with the
existing agent implementations), is where the agents are smart, and they
know what to do in response to changes in the state of the logical
Quantum resources. In such cases, the Quantum plugin need not have to
keep track of sending a message to a particular agent. Instead, can we
have broadcast messages from the plugin to all the agents? If the plugin
has to unicast messages to specific agents, then it needs to maintain a
lot more state/topology information which should not be mandated for
this sole reason.

Thanks,
~Sumit.

> -Original Message-
> From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
> [mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
> Behalf Of Gary Kotton
> Sent: Wednesday, May 09, 2012 4:27 AM
> To: 
> Subject: [Netstack] Scalable
> Agents(https://blueprints.launchpad.net/quantum/+spec/scalable-agent-
> comms)
> 
> Hi,
> I have added a very high level description on how to address the
issue.
> This can be seen at:
>
https://docs.google.com/document/d/1MbcBA2Os4b98ybdgAw2qe_68R1NG6KMh8zd
> ZKgOlpvg/edit
> Comments will be greatly appreciated.
> Questions:
> 1. Do we want agents to be backward compatible (that is, still
maintain
> the polling code)
> 2. The generation of the Agent ID
> 3. Any other ideas or thoughts about the matter?
> I'd like to go ahead with a POC and implement this.
> Thanks
> Gary
> 
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~netstack
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Netstack] ScalableAgents(https://blueprints.launchpad.net/quantum/+spec/scalable-agent-comms)

[Sumit Naiksatam (snaiksat)]

t hand is that database polling
doesn't scale well.  The simple answer is for the plugin and agent to
communicate directly rather than through a database intermediary.
Adding RPC to the mix is an implementation detail, pure and simple, and
is not cost-free.  RPC introduces queue dependency that can be
problematic to debug and as we've seen in nova can cause performance
issues all its own.

 

I'm all for leaving us open going forward to introduce an RPC
dependency, but I think the most important thing is to create a clean
communication interface between plugin and agent.  The initial
implementation can be something simple (and relatively dependency free)
like secured http.  The semantics for implementing and debugging http
communication are well-known to all of us.  If and when RPC becomes
necessary, it will be straightforward to plug in a new transport driver.

 

Let's keep it simple - distributed computing is complicated enough!

 

Cheers,

 

 

Maru

 

On 2012-05-10, at 8:22 AM, Gary Kotton wrote:





Hi,
Below is a table that lists a number of options, a short description,
their advantages and disadvantages. Hopefully this can give an idea of
the scope and complexity.

Option

Description

Advantages

Disadvantages

1 .Agent driving data retrieval from plugin 

The agent maintains a list of tap devices. If there is a new tap device
then the agent will request the network information for this tap device
from the quantum plugin. In the case of the open source ovs and lb
(linuxbridge) plugins this is tap + 11 letters of the attachment id.
The agent will send an RCP update about the delta to the plugin. The
plugin will answer accordingly. For example if one or more tap devices
are detected then these are sent to the plugin. For each new tap device
the plugin will sent the network information (tags etc) and set the
database attachment as up. For deletion they will be removed (or set as
down).

Simple
Self contained in Quantum

If there is more than 1 attachment ID with the same prefix of 11
characters then this will not work (this currently is a bug)
The agent will still have to poll the network interfaces. 

2 .VIF driver driving retrieval from plugin

The VIF driver updates the plugin about a change, which inturn updates
the relevant agent (this was described in the link
https://docs.google.com/document/d/1MbcBA2Os4b98ybdgAw2qe_68R1NG6KMh8zd
)

Event driven.
No polling

VIF driver and agents will need to share communication channels

3. Plugin broadcasting

When the plugin receives a change it broadcasts the change to all of the
registered agents

Relatively simple

Lots of unnecessary messages to agents that do not need to deal with the
traffic


I think that option #1 is a good start. This can later be optimized to
option #2.

Thanks
Gary

On 05/10/2012 10:05 AM, Gary Kotton wrote: 

On 05/10/2012 12:55 AM, Sumit Naiksatam (snaiksat) wrote: 



Hi Gary, 

Thanks for initiating this. A couple of comments/questions - 

1. Do we really need the VIF driver to communicate the agent's identity;

I am referring to the agent ID being sent by the VIF driver in the 
message? In general, I am not sure if there is a need to have the VIF 
driver send messages/notifications in the first place, but I perhaps 
it's being included as a capability in the framework? 

At the moment the open source plugins are not aware of the agents. The
agents poll the data base for updates. The agent ID enables a agent to
regsiter with the plugin, this in trrun enables the plugin to send a
update to the specific agent. The update is initiated by the VIF driver.
In my opinion this does the following: 
1. updates the agents as soon as possible regarding a network change 
2. limits traffic on the network 
3. removes the database interface from the agents 



2. One model I was thinking of (which is kind of inline with the 
existing agent implementations), is where the agents are smart, and they

know what to do in response to changes in the state of the logical 
Quantum resources. In such cases, the Quantum plugin need not have to 
keep track of sending a message to a particular agent. Instead, can we 
have broadcast messages from the plugin to all the agents? If the plugin

has to unicast messages to specific agents, then it needs to maintain a 
lot more state/topology information which should not be mandated for 
this sole reason. 

I too thought about this option. In a sense the above proposal is an
optimization of what you mention. This comes at the cost of complexity.
The broadcast option is nice when the number of agents is small. When
this is large, then for each network update there will be
NUMBER_OF_AGENT messages sent for each update. The advantage of what you
mention is that the code is self contained in Quantum. 

It may be better to start with the broadcast and then deal with the
optimizations afterwards. 

Thanks 
Gary 




Thanks, 
~Sumit. 




-Original Message- 
From: netstack-b

Re: [Netstack] Fwd: [Openstack] [devstack/quantum] Configuration issue

[Sumit Naiksatam (snaiksat)]

This is probably not a devstack issue. The problem is with the LB
gateway driver wherein the IP address is trying to be set on a bridge
device which already has an IP address. The check for an existing bridge
is being performed, but the IP address is being set outside that check.
Ideally, this code should not have been invoked if the gateway was
already set. Something seems to have changed in the QuantumManager as
result of which this code is being invoked again. At any rate, I will
fix the LB gateway driver, and we will not see this.

 

Thanks,

~Sumit.

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of Gary Kotton
Sent: Monday, May 14, 2012 11:19 PM
To: 
Subject: [Netstack] Fwd: [Openstack] [devstack/quantum] Configuration
issue

 



 Original Message  

Subject: 

[Openstack] [devstack/quantum] Configuration issue

Date: 

Tue, 15 May 2012 09:00:52 +0300

From: 

Gary Kotton   

Reply-To: 

gkot...@redhat.com

Organization: 

Red Hat

To: 

openst...@lists.launchpad.net

 

Hi,
This morning I encountered a problem (which did not happen a few days 
ago :)). When devstack is launched, with quantum configured, the gateway

and bridge devices are created. This causes problems with quantum.
 
For example when devstack is up and running prior to deploying an 
instance we have:
 
brq744ec2f4-c0 Link encap:Ethernet  HWaddr fa:16:3e:03:a6:55
  inet addr:10.0.0.1  Bcast:0.0.0.0  Mask:255.255.255.0
  UP BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
 
gw-744ec2f4-c0 Link encap:Ethernet  HWaddr fa:16:3e:03:a6:55
  inet addr:10.0.0.1  Bcast:10.0.0.255  Mask:255.255.255.0
  UP BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:500
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
 
When an instance is deployed the following happens:
 
2012-05-15 01:59:18 DEBUG nova.utils 
[req-4d50ed10-46e1-406c-9074-dc45da860365 
df07eec326434b25800f3ebc17202fb3 2cafe0be4d7740098a89be39ffd1b72e] 
Running cmd (subprocess): sudo /usr/local/bin/nova-rootwrap ip address 
add 10.0.0.1/24 dev brq744ec2f4-c0 from (pid=4234) execute 
/opt/stack/nova/nova/utils.py:178
2012-05-15 01:59:18 DEBUG nova.utils 
[req-4d50ed10-46e1-406c-9074-dc45da860365 
df07eec326434b25800f3ebc17202fb3 2cafe0be4d7740098a89be39ffd1b72e] 
Result was 254 from (pid=4234) execute /opt/stack/nova/nova/utils.py:194
2012-05-15 01:59:18 ERROR nova.rpc.amqp 
[req-4d50ed10-46e1-406c-9074-dc45da860365 
df07eec326434b25800f3ebc17202fb3 2cafe0be4d7740098a89be39ffd1b72e] 
Exception during message handling
2012-05-15 01:59:18 TRACE nova.rpc.amqp Traceback (most recent call
last):
2012-05-15 01:59:18 TRACE nova.rpc.amqp   File 
"/opt/stack/nova/nova/rpc/amqp.py", line 263, in _process_data
2012-05-15 01:59:18 TRACE nova.rpc.amqp rval = 
node_func(context=ctxt, **node_args)
2012-05-15 01:59:18 TRACE nova.rpc.amqp   File 
"/opt/stack/nova/nova/network/quantum/manager.py", line 390, in 
allocate_for_instance
2012-05-15 01:59:18 TRACE nova.rpc.amqp network, vif_rec, 
network['net_tenant_id'])
2012-05-15 01:59:18 TRACE nova.rpc.amqp   File 
"/opt/stack/nova/nova/utils.py", line 880, in inner
2012-05-15 01:59:18 TRACE nova.rpc.amqp retval = f(*args, **kwargs)
2012-05-15 01:59:18 TRACE nova.rpc.amqp   File 
"/opt/stack/nova/nova/network/quantum/manager.py", line 501, in
enable_dhcp
2012-05-15 01:59:18 TRACE nova.rpc.amqp 
self.l3driver.initialize_gateway(network_ref)
2012-05-15 01:59:18 TRACE nova.rpc.amqp   File 
"/opt/stack/nova/nova/network/l3.py", line 98, in initialize_gateway
2012-05-15 01:59:18 TRACE nova.rpc.amqp 
gateway=(network_ref['gateway'] is not None))
2012-05-15 01:59:18 TRACE nova.rpc.amqp   File 
"/opt/stack/nova/nova/network/linux_net.py", line 900, in plug
2012-05-15 01:59:18 TRACE nova.rpc.amqp return 
_get_interface_driver().plug(network, mac_address, gateway)
2012-05-15 01:59:18 TRACE nova.rpc.amqp   File 
"/opt/stack/nova/nova/network/linux_net.py", line 1160, in plug
2012-05-15 01:59:18 TRACE nova.rpc.amqp run_as_root=True)
2012-05-15 01:59:18 TRACE nova.rpc.amqp   File 
"/opt/stack/nova/nova/utils.py", line 201, in execute
2012-05-15 01:59:18 TRACE nova.rpc.amqp cmd=' '.join(cmd))
2012-05-15 01:59:18 TRACE nova.rpc.amqp ProcessExecutionError: 
Unexpected error while running command.
2012-05-15 01:59:18 TRACE nova.rpc.amqp Command: sudo 
/usr/local/bin/nova-rootwrap ip address add 10.0.0.1/24 dev
brq744ec2f4-c0
2012-05-15 01:59:18 TRACE nova.rpc.amqp Exit code: 254
2012-05-15 01:59:18 TRACE nova.rpc.amqp Stdout: ''
2012-05-

Re: [Netstack] Fwd: [Openstack] [devstack/quantum] Configuration issue

[Sumit Naiksatam (snaiksat)]

The interesting data point here is that this only happens to the default
network created when the installation is done via DevStack. For all
network created subsequently I am not seeing this issue. I earlier
thought that this might have something to do with the exercises script
getting executed and possibly leaving a residue. However, in spite of
not running the exercises script I am still seeing this issue. It seems
that for some reason, the initialize_gateway() was getting called only
when a new VM was being created. But here it seems to be getting called
before that (thus leading to the creation of the bridge and the gateway
devices), not sure why. I am just trying to figure out how I can test
the fix with respect to the devstack setup (since this happens only on
installation)...

 

From: Dan Wendlandt [mailto:d...@nicira.com] 
Sent: Wednesday, May 16, 2012 7:55 AM
To: gkot...@redhat.com
Cc: Sumit Naiksatam (snaiksat); netstack@lists.launchpad.net
Subject: Re: [Netstack] Fwd: [Openstack] [devstack/quantum]
Configuration issue

 

 

On Wed, May 16, 2012 at 1:43 AM, Gary Kotton  wrote:

Thanks!
As far as I recall, and I may certain be wrong here, but in the past I
did not see the GW created until the first VM was deployed. Now I am
seeing the GW created when the various services are started. 

 

I have noticed this as well.  I'm not aware of any changes to
QuantumManager that had this affect, though its possible someone pushed
a change that I didn't notice.  I primarily use the OVS interface-driver
and didn't notice any issues, so I suspect Sumit is correct that we can
at least work around this with a change to the LB interface-driver (even
though the change that caused the issue was likely somewhere else).  

 

This is a good example of why we need Quantum integrated into devstack
commit-gating, as it will catch this type of complex integration issues.
Anyone have cycles to help push on this?  I'm unlikely to make much
progress on it in the next week or two due to the F-1 release.  

 

Dan

 

 

 

Thanks
Gary



On 05/16/2012 10:54 AM, Sumit Naiksatam (snaiksat) wrote: 

This is probably not a devstack issue. The problem is with the
LB gateway driver wherein the IP address is trying to be set on a bridge
device which already has an IP address. The check for an existing bridge
is being performed, but the IP address is being set outside that check.
Ideally, this code should not have been invoked if the gateway was
already set. Something seems to have changed in the QuantumManager as
result of which this code is being invoked again. At any rate, I will
fix the LB gateway driver, and we will not see this.

 

Thanks,

~Sumit.

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of Gary Kotton
Sent: Monday, May 14, 2012 11:19 PM
To: 
<mailto:netstack@lists.launchpad.net> 
Subject: [Netstack] Fwd: [Openstack] [devstack/quantum]
Configuration issue

 



 Original Message  

Subject: 

[Openstack] [devstack/quantum] Configuration issue

Date: 

Tue, 15 May 2012 09:00:52 +0300

From: 

Gary Kotton  <mailto:gkot...@redhat.com> 

Reply-To: 

gkot...@redhat.com

Organization: 

Red Hat

To: 

openst...@lists.launchpad.net

 

Hi,
This morning I encountered a problem (which did not happen a few
days 
ago :)). When devstack is launched, with quantum configured, the
gateway 
and bridge devices are created. This causes problems with
quantum.
 
For example when devstack is up and running prior to deploying
an 
instance we have:
 
brq744ec2f4-c0 Link encap:Ethernet  HWaddr fa:16:3e:03:a6:55
  inet addr:10.0.0.1  Bcast:0.0.0.0  Mask:255.255.255.0
  UP BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
 
gw-744ec2f4-c0 Link encap:Ethernet  HWaddr fa:16:3e:03:a6:55
  inet addr:10.0.0.1  Bcast:10.0.0.255
Mask:255.255.255.0
  UP BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:500
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
 
When an instance is deployed the following happens:
 
2012-05-15 01:59:18 DEBUG nova.utils 
[req-4d50ed10-46e1-406c-9074-dc45da860365 
df07eec326434b25800f3ebc17202fb3
2cafe0be4d7740098a89be39ffd1b72e] 
  

Re: [Netstack] proposing gary kotton for quantum-core

[Sumit Naiksatam (snaiksat)]

+1

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of Dan Wendlandt
Sent: Monday, June 04, 2012 10:18 AM
To: netstack@lists.launchpad.net
Subject: [Netstack] proposing gary kotton for quantum-core

 

Hi folks,

 

Gary (garyk on IRC) has been doing a lot of great work reviewing and
contributing code to Quantum, so I'd like to propose him as a core
member.  

 

If you are an existing core member, please respond with: +1, +0, or -1. 

 

I give him a +1.  


 

Dan

 

-- 
~~~
Dan Wendlandt 

Nicira, Inc: www.nicira.com

twitter: danwendlandt
~~~

 

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

Re: [Netstack] proposing Yong Sheng Gong for quantum-core

[Sumit Naiksatam (snaiksat)]

+1

 

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
Behalf Of Dan Wendlandt
Sent: Monday, June 04, 2012 6:18 PM
To: netstack@lists.launchpad.net
Subject: [Netstack] proposing Yong Sheng Gong for quantum-core

 

One more quantum core proposal.  Yong has also been doing a lot of great
review work already, and has been contributing to quantum +
python-quantumclient as well.  

 

+1 from me.

 

Dan




 

-- 
~~~
Dan Wendlandt 

Nicira, Inc: www.nicira.com

twitter: danwendlandt
~~~

 

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

Re: [Netstack] Reviews

[Sumit Naiksatam (snaiksat)]

Hi Gary,

As for #3 it might be an intermittent failure, console output says:

14:08:19  Build step 'Execute shell' marked build as failure
14:08:19  Looks like the node went offline during the build. Check the slave 
log for the details.

You probably want to kick off the build again (I am not sure if it retries 
automatically)?

Thanks,
~Sumit.

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net 
[netstack-bounces+snaiksat=cisco@lists.launchpad.net] on behalf of Gary 
Kotton [gkot...@redhat.com]
Sent: Sunday, June 17, 2012 7:42 AM
To: 
Subject: [Netstack] Reviews

Hi,
Can people please take a look at the following:

Critical:
1. https://review.openstack.org/#/c/8645/ - linux bridge agent does not work

Stable Essex Cherry Picks:
1. https://review.openstack.org/#/c/8646/ - Quantum Manager disassociate
floating-ips on instance delete
2. https://review.openstack.org/#/c/8647/ - Fix for Quantum LinuxBridge
Intf driver plug call (*** jenkins gives -1 - any ideas)
3. https://review.openstack.org/#/c/8648/ - return 404 for invalid api
version request
4. https://review.openstack.org/#/c/8649/ - Calling Super method from
QuantumPortAwareScheduler.__init__
5. https://review.openstack.org/#/c/8650/ - database connectivity issues
6. https://review.openstack.org/#/c/8651/ - Cisco plugin CLI call to
quantumclient CLI
7. https://review.openstack.org/#/c/8384/ - Bug 1007153

In addition to this if anyone else can think of any additional changes
that should be made for the stable essex version, for example
https://github.com/openstack/quantum/commit/438eda895c7e24113f116e503f36930c176ebe4d
(this is on my to do list)

Folsom:
1. https://review.openstack.org/#/c/8101/ - common configuration (my
kingdom for a horse!!)
2. https://review.openstack.org/#/c/8597/ - assign unique mac addresses

Thanks
Gary



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

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

[Netstack] Quantum pending reviews

[Sumit Naiksatam (snaiksat)]

Hi All,

As we head into the weekend, just wanted to take a stock of the pending reviews 
(it's my turn today :-)). 

** Quantum reviews: 
https://review.openstack.org/#/q/status:open+project:openstack/quantum,n,z

* https://review.openstack.org/#/c/8822/ - "Add simple file loggin to 
ovs_quantum_agent"
Status: Jenkins failed on this one and might be a transient failure. Armando, 
could you please check if you can trigger a build again?

* https://review.openstack.org/#/c/8650/ - "blueprint database-common bug 
995438"
Status: Needs two core reviews. I will review this one. Any other core devs 
want to sign up?

* https://review.openstack.org/#/c/8794/ - "IP Address allocation bug 1008029"
Status: This has gone through a few patches and has two core devs signed up. I 
will try to review this as well today.

* https://review.openstack.org/#/c/8800/ - "Remove paste configuration details 
to a seperate file"
Status: This has a pending comment, and action item is on me to verify it. Will 
do and respond.

* https://review.openstack.org/#/c/8556/ - "Bug #1012418 - quantum agent for 
OVS does not install properly on Xen XCP"
Status: This one has gone through some reviews and Juliano seems to have 
addressed some of the comments. 'Xen/XCP' experts - are we going ahead with 
this patch? 

* https://review.openstack.org/#/c/8736/ - "Cisco's unplug_iface refers to non 
existing exception"
Status: The patch has the fix, only waiting for a change in the commit header. 
Chinmay can you try doing a "git commit -a --amend" again, and edit the commit 
message to change "Bug id 1006226" to "Bug #1006226"?

** Quantum Client reviews: 
https://review.openstack.org/#/q/status:open+project:openstack/python-quantumclient,n,z
Nothing outstanding. Yay!!

Thanks,
~Sumit.

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

[Netstack] Quantum unassigned bugs

[Sumit Naiksatam (snaiksat)]

Hi All,

The following bugs are not assigned to anyone but are targeted for F2. Is 
anyone working, or wants to work, on them?

* https://bugs.launchpad.net/quantum/+bug/1014989 - "check foreign key 
ownership for port/subnet creation"

* https://bugs.launchpad.net/quantum/+bug/1007998 - "xml support for quantum v2 
API"

Thanks,
~Sumit.

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

Re: [Netstack] requirements for quantum plugins

[Sumit Naiksatam (snaiksat)]

I think it's fair to expect that, for a plugin to be in the community repo, it 
be maintained by at least one core dev. Also, in cases where a new plugin is 
being introduced by new contributors, at least one of them can be promoted to 
core dev (if none of the existing core devs take responsibility) on the merit 
of their contribution to that plugin (and of course with the understanding that 
they agree to fulfill the core dev responsibilities beyond just that plugin).

Thanks,
~Sumit.

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net 
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On Behalf Of 
Salvatore Orlando
Sent: Friday, June 29, 2012 12:54 AM
To: Dan Wendlandt
Cc: netstack@lists.launchpad.net
Subject: Re: [Netstack] requirements for quantum plugins

Hello Dan & netstack people,

replies inline.
On 29 June 2012 07:50, Dan Wendlandt mailto:d...@nicira.com>> 
wrote:
Hi folks,

Ryota from NEC sent an email to the list earlier tonight about pushing their 
NEC Quantum plugin (currently hosted outside of the main Quantum repo), into 
the main Quantum repo.  As some of you will recall, at the Folsom summit we 
talked a bit about whether plugins should be in core and if so, what the 
requirements would be around allowing a plugin to be in the main repo.

My personal feeling is that having plugins be part of a single centralized 
community repository is a good thing for a couple of reasons:
1) it simplifies and increases the sharing of code and ideas across different 
plugins.
2) it promotes a more cohesive community around quantum, encouraging people to 
contribute not only to their plugin, but to community projects as well.
3) it potentially makes it easier for someone to understand if a code change 
(e.g., at the db plugin base layer) breaks any particular plugin.

I agree on all the above points, however from waht I recall concerns were 
mainly around i) not well maintained plugins - which you address in this email, 
and ii) plugins for specific, non widely-available technologies.


However, for this approach to work, I think we need to make sure that at least 
one core quantum developer is committed to maintaining the plugin.  Why a core 
member?  Because being core represents a significant commitment to 
understanding the does and don'ts of Quantum, which that maintainer can help 
enforce with respect to the plugin code.  A core developer also presents a 
commit to the community as a whole, which means other core developers will be 
motivated to return the favor and reivew/fix issues within the plugin.

And, also such core dev will be a subject expert for the technology adopted by 
that particular plugin.


Obviously, we don't want these requirements to be so high that they discourage 
people from building and pushing plugin code to the main repo, because as I 
mentioned above, I think there are a lot of advantages to having plugins in a 
shared location.  The core dev might be the primary developer of the plugin 
itself, or it might be an existing core developer who is simply motivated to 
work with the existing developers to help make sure the plugin stays in good 
shape and questions on the ML or launchpad get answered in a reasonable fashion.

I think one possible idea would be to "promote" one of the commiters for each 
plugin to core dev. Hopefully this will encourage community engagement. 
However, we should also probably define some high-level criteria for deciding 
when a plugin should be removed from the main repo because it's not being 
maintained, as it might be the case of the Ryu plugin mentioned below.


At this point, I would think that all plugins in the repo meet these criteria, 
with the exception of the Ryu plugin, as we haven't really had much contact 
with those authors since the initial contribution.

What do others think about this topic?  What's the right trade-off?

Dan

--
~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~


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

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

Re: [Netstack] [Quantum] Starting a discussion on the official spec for v2 API

[Sumit Naiksatam (snaiksat)]

Hi All,

I second Gary's suggestion here for a network type attribute. I was curious to 
know why we moved away from the kwargs mechanism which we had earlier in the 
core API. That made it easier to pass any plugin-specific parameters which need 
not be core attributes, and not have to necessarily implement an extension for 
that.

Thanks,
~Sumit.



> -Original Message-
> From: netstack-bounces+snaiksat=cisco@lists.launchpad.net
> [mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On
> Behalf Of Gary Kotton
> Sent: Tuesday, July 17, 2012 2:33 AM
> To: netstack@lists.launchpad.net
> Subject: Re: [Netstack] [Quantum] Starting a discussion on the official spec
> for v2 API
> 
> On 07/17/2012 10:28 AM, Salvatore Orlando wrote:
> > Hello people of Quantum!
> > As the Folsom release approaches, it is time to gather together and
> > finalize the specification for the v2 API, so that the Openstack-doc
> > team might cast it in stone for the sake of the Quantum users!
> >
> > In order to make this happen, it looks like there are just a few bits
> > that needs to be agreed upon, and I think they can be summarized as
> > follows:
> > - 'name' attributes and whether they should be mandatory. It looks
> > like we all agree we want them, but it has to be decided whether
> >i) they should be unique or not.
> >ii) they should be mandatory or not.
> 
> Originally when I started to use Quantum I found it very awkward that the
> name was not unique. My understanding from the meeting last night was
> that it will no longer be mandatory for a network and does not need to be
> unique. I wrote a mail to the list this morning suggesting that we use
> description instead of name. Personally I think that this is a less binding 
> way
> of describing a network, subnet or port.
> 
> 
> > - 'public' attribute for networks. As we did not get negative feedback
> > on the proposal, I am going to assume nobody has strong opinions
> > against this decision.
> 
> I would have preferred network type as it is more generic. Nonetheless I do
> not have any strong objections to this.
> 
> > - security group API. We have a blueprint open and targeted to F-3
> > (https://blueprints.launchpad.net/quantum/+spec/quantum-security-
> groups).
> > Personally I do not feel it is a good idea at this stage proposing
> > them for the core v2 API in Folsom. Apart from the necessary
> > discussion concerning the APIs, we will need support across all the
> > plugins, which is hardly going to happen IMHO. If you have a different
> > opinion, this is the right thread to shout it!
> 
> I agree with you. I think that we still have a few road bumps to deal with. 
> For
> example when using devstack with Quantum V2 and the DHCP agent, the
> DHCP requests do not arrive at the dnsmasq interface ... I am trying to
> understand the reason for this. I have set the libvirt drivers to
> "LIBVIRT_FIREWALL_DRIVER=nova.virt.firewall.NoopFirewallDriver" Not sure
> if this is enough. Any help will be great.
> 
> > - NOTE: Leaving the security groups outside of Quantum core API
> > also means that we *must* ensure Quantum still allows Nova to use its
> > own firewall drivers.
> > - L3 features
> > (https://blueprints.launchpad.net/quantum/+spec/quantum-l3-fwd-nat):
> > among the various sub-blueprints in which this blueprint can be
> > broken, there's one concerning APIs. As I have not followed the
> > development of this particular blueprint, I'll leave it to Dan whether
> > L3 & NAT APIs should be part of Folsom core.
> >
> > From my perspective, the above list includes all the items concerning
> > the Quantum v2 API which have not yet stabilized. Please do let me
> > know if I forgot anything.
> >
> > Thanks and have a good day,
> > Salvatore
> >
> 
> 
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~netstack
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Netstack] [Quantum] plugin -> backend

[Sumit Naiksatam (snaiksat)]

Hi,

I believe there are two topics of discussion here, one of which is the 
terminology. The way things are implemented today, I agree that the “plugin” 
terminology seems a bit confusing. However, probably the bigger topic of 
discussion is what kind of a design is preferable, “backend” versus “plugin”? 
As Yong points out, today’s Quantum service completely relies on the plugin for 
providing all functionality, including functionality that is probably common 
across plugins (like state management of logical resources, IPAM, etc.). Going 
forward, would it make sense to push some of the common functionality into the 
Quantum service, and have plugins which actually behave like the name suggests?

Thanks,
~Sumit.

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net 
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On Behalf Of 
Yong Sheng Gong
Sent: Monday, July 30, 2012 7:05 PM
To: Willian Molinari
Cc: OpenStack Development Mailing List; netstack@lists.launchpad.net
Subject: Re: [Netstack] [Quantum] plugin -> backend

Hi,
Add it into openstack-dev and [quantum] into the subject.

Yes, 'backend' seems better than 'plugin' for our case here.

Our plugin is a must for quantum server to work,  while 'plugin' tends to make 
us think it will provide more functionalities if we plug it in.
And I don't think our plugin is 'pluggable backend'.  I prefer to call it 
'replaceable or configurable' 'backend' or 'dirver'.

Thanks
Yong Sheng Gong



-netstack-bounces+gongysh=cn.ibm@lists.launchpad.net
 wrote: -
To: "netstack@lists.launchpad.net" 

From: Willian Molinari
Sent by: 
netstack-bounces+gongysh=cn.ibm@lists.launchpad.net
Date: 07/31/2012 07:26AM
Subject: [Netstack] plugin -> backend
Æ!!

Hi folks!

I was concerned to bring the "plugins" discussion because it looks like a 
bikeshedding
and it probably was discussed before, but I think it will be beneficial at all.

What motivated me to bring the discussion was the Metaplugin implementation
(https://review.openstack.org/#/c/10181/) that looks like a quantum backend 
implementing
support for plugins.

When we first looked into quantum we thought that quantum plugin was following 
the same
concept of all other plugins (ie we should install a lot of plugins to enhance 
the application)
 but we found that this is not the concept of quantum plugins, talking to Dan 
about this at
the openstack summit I found the real concept of quantum plugins and I heard 
some people
saying that plugins should be something like a "pluggable backend", so why not 
to call the
plugin just "backend"?

Looks natural to have just one backend at time and this backend should handle 
multiple
plugins if needed (the metaplugin case).

Sorry for bringing a non-technical discussion like this but every time someone 
asks me to
explain what quantum does I need to show plugins as "backends" to make sense.

I'm the only guy that think it's confusing? :P

Just want to hear your ideas about this topic.
--
Willian Molinari
(a.k.a PotHix)
--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help   : https://help.launchpad.net/ListHelp
-- 
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help   : https://help.launchpad.net/ListHelp

Re: [Netstack] Multiple vNICs for Multiple networks.

[Sumit Naiksatam (snaiksat)]

Hi,

Yes, if you do not specify networks using the “–nic” option you will get a vnic 
on each of the public networks and one for each network belonging to that 
tenant. Using the “—nic net-id=uuid-xyz” option you can refer to specific 
networks on which you want the vnics.

Thanks,
~Sumit.

From: netstack-bounces+snaiksat=cisco@lists.launchpad.net 
[mailto:netstack-bounces+snaiksat=cisco@lists.launchpad.net] On Behalf Of 
Trinath Somanchi
Sent: Thursday, August 02, 2012 3:18 AM
To: openst...@lists.launchpad.net; 
Subject: [Netstack] Multiple vNICs for Multiple networks.

Hi-


I have installed Openstack+Quantum+OVS in two machines.

One Controller and the other as node.

I have created tenant specific/labeled and public labeled networks.

Upon bringing up instances in a tenant, I'm able to see 3 types of IP address 
for the instance. and Upon login into the instance, for "ifconfig -a" I'm able 
to see eth0,eth1 and eth2 interfaces.

But for ifconfig, only eth0 is shown. If I do "dhclient eth1", I'm able to get 
the ip address for the instance.

Is that for 'N' number of networks, instances get those many vNICs..?

Please help me understand the same.



--
Regards,
--
Trinath Somanchi,
+91 9866 235 130

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

[Netstack] FW: [openstack-dev] [Quantum] Proposing Mark McClain & Nachi Ueno for core dev

[Sumit Naiksatam (snaiksat)]

-Original Message-
From: Sumit Naiksatam (snaiksat) 
Sent: Wednesday, August 15, 2012 1:59 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Quantum] Proposing Mark McClain & Nachi Ueno for core 
dev

Hi All,

I feel Mark McClain (markmcclain) and Nachi Ueno have been doing great work in 
the Quantum project and would like to propose their names for the role of core 
devs in Quantum.

Thanks,
~Sumit.

___
OpenStack-dev mailing list
openstack-...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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