I started down the path of making a python-neutronclient extension, but got
stuck on the lack of support for child resource extensions as described here
https://bugs.launchpad.net/python-neutronclient/+bug/1446428. I submitted a
bugfix here https://review.openstack.org/#/c/202597/?.
Amir
expect
return flights starting on Friday to be worse for the weekend of the 22nd, but
I don't have data on that.
Amir Sadoughi
From: Thierry Carrez [thie...@openstack.org]
Sent: Tuesday, September 23, 2014 9:54 AM
To: openstack-dev@lists.openstack.org
I agree with Kevin here. Just a note, don't bother with openvswitch and
linuxbridge plugins as they are marked for deletion this cycle, imminently
(already deprecated)[0].
Amir
[0]
http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-08-04-21.02.html
Announcements 2e.
Indeed a blueprint has been filed (on Launchpad, not neutron-specs) on this
already[0], but there has been no work on this as far as I can tell. I think it
would be worthwhile contribution.
Amir
[0] https://blueprints.launchpad.net/neutron/+spec/neutron-agent-soft-restart
for
non-tcp traffic. What about the ESTABLISHED feature? The blueprint specs refers
to tcp_flags=ack.
Or will that be supported through the source port matching extension which is
being promoted?
More comments inline.
On 3 June 2014 01:22, Amir Sadoughi
amir.sadou
logging, I don’t know if OVS is capable of it. If iptables in
Neutron does not currently support that feature, I don’t think Neutron should
explicitly support out-of-tree features.
Amir
On Jun 3, 2014, at 6:59 AM, CARVER, PAUL
pc2...@att.commailto:pc2...@att.com wrote:
Amir Sadoughi wrote
Carl,
You are correct in both distinctions. Like I mentioned to Paul, beyond explicit
configuration for the cloud operator, documentation and API validation for the
end user, is there anything specific you would like to see as a “warning label”?
Amir
On Jun 3, 2014, at 9:01 AM, Carl Baldwin
Hi all,
In the Neutron weekly meeting today[0], we discussed the ovs-firewall-driver
blueprint[1]. Moving forward, OVS features today will give us 80% of the
iptables security groups behavior. Specifically, OVS lacks connection tracking
so it won’t have a RELATED feature or stateful rules for
I know alembic is designed to be global, but could we extend it to track
multiple histories for a given database. In other words, various branches for
different namespaces on a single database. Would this feature ameliorate the
issues?
Amir
On Apr 15, 2014, at 8:24 AM, Kyle Mestery
Hi Vishal,
I’ve restarted my work on the blueprint last week now that Juno is open for
development and OVS 2.1.0 is available, targeting juno-1. My plan is to have a
working implementation available by the summit design discussion to make sure
we cover all our bases. Between the blueprint page
...@noironetworks.com wrote:
On Mon, Apr 7, 2014 at 11:01 AM, Amir Sadoughi
amir.sadou...@rackspace.commailto:amir.sadou...@rackspace.com wrote:
Hi Vishal,
I've restarted my work on the blueprint last week now that Juno is open for
development and OVS 2.1.0 is available, targeting juno-1. My plan is to have
Hi all,
In Rackspace's quark plugin (github.com/rackerlabs/quark), we’ve developed an
extension for MAC address ranges (MARs) as a top-level resource. Thus, the
Neutron service manages the MAC address allocation from a pool of ranges (as
opposed to randomly generating a MAC address). However,
Hi all,
I just want to make sure I understand the plan and its consequences. I’m on
board with the YAGNI principle of hardwiring mechanism drivers to return their
firewall_driver types for now.
However, after (A), (B), and (C) are completed, to allow for Open vSwitch-based
security groups
wrote:
Hi Amir
2014/1/16 Amir Sadoughi
amir.sadou...@rackspace.commailto:amir.sadou...@rackspace.com:
Hi all,
I just want to make sure I understand the plan and its consequences. I’m on
board with the YAGNI principle of hardwiring mechanism drivers to return their
firewall_driver types for now
neutron.tests.unit.ml2 (filtered, sorted):
http://paste.openstack.org/show/55375/
Amir
On Dec 12, 2013, at 4:48 PM, Amir Sadoughi amir.sadou...@rackspace.com wrote:
Mathieu,
Here are my results for running the unit tests for the agents.
I ran `tox -e cover
these
suggested additions. The security groups RPC API already has a field for
source-port-range-min and source-port-range-max so this change would only
affect the DB and frontend API.
I’m open to any and all feedback.
Thanks,
Amir Sadoughi
[1] e-mail thread on ovs-discuss mailing list.
http
of OpenStack meetings[2], Monday at 2000 UTC (right
before Neutron meeting) is open for #openstack-meeting. Looking forward to
continue the discussion there.
Thanks,
Amir Sadoughi
[1] https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_Dec_11.2C_2013
[2] https://wiki.openstack.org/wiki/Meetings
607134
255 7376%
...
Amir
On Dec 11, 2013, at 3:01 PM, Mathieu Rohon mathieu.ro...@gmail.com wrote:
the coverage is quite good on the ML2 plugin.
it looks like the biggest effort should be done on the ovs and lb agents, no?
On Wed, Dec 11, 2013 at 9:00 PM, Amir Sadoughi
Hi George,
I’m working on a blueprint to implement OVS flows for security groups.
https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver Currently,
neutron only implements security groups with iptables even when Open vSwitch is
used.
Amir
On Nov 27, 2013, at 1:29 PM, George
Yes, my work has been on ML2 with neutron-openvswitch-agent. I’m interested to
see what Jun Park has. I might have something ready before he is available
again, but would like to collaborate regardless.
Amir
On Nov 19, 2013, at 3:31 AM, Kanthi P
Hi Kanthi,
I’ve already started the implementation (prototype phase) of such a blueprint,
ovs-firewall-driver
https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver.
Amir
On Nov 18, 2013, at 4:26 PM, Kanthi P
pavuluri.kan...@gmail.commailto:pavuluri.kan...@gmail.com wrote:
Hi
21 matches
Mail list logo
