Hi there. I've been looking into a tricky point, and hope I can succeed
in expressing it clearly here...
I believe it is the case, even when using a committedly Neutron-based
networking implementation, that Nova is still involved a little bit in
the networking setup logic. Specifically I mean
Kevin Benton blak...@gmail.com writes:
What you are proposing sounds very reasonable. If I understand
correctly, the idea is to make Nova just create the TAP device and get
it attached to the VM and leave it 'unplugged'. This would work well
and might eliminate the need for some drivers. I
Ian Wells ijw.ubu...@cack.org.uk writes:
On 4 December 2014 at 08:00, Neil Jerram neil.jer...@metaswitch.com
wrote:
Kevin Benton blak...@gmail.com writes:
I was actually floating a slightly more radical option than that:
the
idea that there is a VIF type (VIF_TYPE_NOOP
Kevin Benton blak...@gmail.com writes:
I see the difference now.
The main concern I see with the NOOP type is that creating the virtual
interface could require different logic for certain hypervisors. In
that case Neutron would now have to know things about nova and to me
it seems like
Daniel P. Berrange berra...@redhat.com writes:
Failing that though, I could see a way to accomplish a similar thing
without a Neutron launched agent. If one of the VIF type binding
parameters were the name of a script, we could run that script on
plug unplug. So we'd have a finite number of
Hi Joe,
Joe Gordon joe.gord...@gmail.com writes:
In preparation, I put together a nova-specs dashboard:
https://review.openstack.org/141137
Joe Gordon joe.gord...@gmail.com writes:
On Mon, Dec 15, 2014 at 8:46 AM, Radoslav Gerganov
rgerga...@vmware.com wrote:
On 12/15/2014 12:54 PM, Neil Jerram wrote:
My Nova spec (https://review.openstack.org/#/c/130732/) does not
appear
on this dashboard, even
Hi all,
Following the approval for Neutron vendor code decomposition
(https://review.openstack.org/#/c/134680/), I just wanted to comment
that it appears to work fine to have an ML2 mechanism driver _entirely_
out of tree, so long as the vendor repository that provides the ML2
mechanism driver
Stefano Maffulli stef...@openstack.org writes:
On 12/09/2014 04:11 PM, by wrote:
[vad] how about the documentation in this case?... bcos it needs some
place to document (a short desc and a link to vendor page) or list these
kind of out-of-tree plugins/drivers... just to make the user aware
Maxime Leroy maxime.le...@6wind.com writes:
Ok, thank you for the details. I will look how to implement this feature.
Hi Maxime,
Did you have time yet to start looking at this? My team now has a use
case that could be met by using vif_plug_script, so I would be
happy to help with writing the
John Garbutt j...@johngarbutt.com writes:
Hi all,
With the release of kilo-1 we have frozen the approval of new specs for kilo.
This is to make sure we can focus on our agreed kilo priorities:
http://specs.openstack.org/openstack/nova-specs/priorities/kilo-priorities.html
As always, there
Hi all,
I'd like to request an exception for my Nova spec adding VIF_TYPE_TAP:
https://review.openstack.org/#/c/130732/
(Some history: This spec was previously approved as of Patch Set 7, but
with some requests for minor clarifications to the text. When I
uploaded Patch Sets 8 and 9, to make
Neil Jerram neil.jer...@metaswitch.com writes:
Hi Michael,
Michael Still mi...@stillhq.com writes:
For specs approved in Juno or Kilo, there is a fast track approval
process for Liberty. The steps to get your spec re-approved are:
- Copy your spec from the specs/oldrelease/approved
Davanum Srinivas dava...@gmail.com writes:
Neil,
yes, see example - https://review.openstack.org/#/c/155116/ - you file
against the /approved directory
Thanks!
Neil
__
OpenStack Development Mailing List (not for
Assaf Muller amul...@redhat.com writes:
Hello everyone,
Hi Assaf,
The use_namespaces option in the L3 and DHCP Neutron agents controls if you
can create multiple routers and DHCP networks managed by a single L3/DHCP
agent,
or if the agent manages only a single resource.
Are the setups
Assaf Muller amul...@redhat.com writes:
Hello everyone,
Hi Assaf,
The use_namespaces option in the L3 and DHCP Neutron agents controls if you
can create multiple routers and DHCP networks managed by a single L3/DHCP
agent,
or if the agent manages only a single resource.
Are the setups
Kevin Benton blak...@gmail.com writes:
This is a nice option for smaller deployments that didn't need the
complexity of NAT. From a custom L3 plugin perspective, it also
eliminated any single points of failure pretty easily since no NAT
state had to be distributed.
However, it was
Salvatore Orlando sorla...@nicira.com writes:
On 25 March 2015 at 17:36, Neil Jerram neil.jer...@metaswitch.com
wrote:
Kevin Benton blak...@gmail.com writes:
This is a nice option for smaller deployments that didn't need
the
complexity of NAT. From a custom L3
Salvatore Orlando sorla...@nicira.com writes:
Neutron is adding a new concept of subnet pool. [...]
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-allocation.html
I apologize for asking this question so long after this spec has been
proposed and discussed - but what is
Although we are past the non-priority deadline, I have been encouraged
to request this late exception for Project Calico's spec and code adding
VIF_TYPE_TAP to Nova.
https://review.openstack.org/#/c/130732/ (spec)
https://review.openstack.org/#/c/146914/ (code)
Why might you consider this?
- It
and steer would be appreciated, even if they're more of a
high level gut feel, than an exhaustive treatment.
Thanks,
Neil
On 16/04/15 15:12, Neil Jerram wrote:
I have a Neutron DHCP agent patch whose purpose is to launch dnsmasq
with options such that it works (= provides DHCP service) for TAP
On 01/05/15 11:44, John Garbutt wrote:
Hi,
In case you were unable to make yesterday's Nova meeting...
I was there, but still a bit shy and retiring... :-)
If you have a suggestion for a Nova design summit session, please
ensure you add it to before the next Nova meeting (7th May):
interfaces?
Thanks,
Neil
On 16/04/15 15:12, Neil Jerram wrote:
I have a Neutron DHCP agent patch whose purpose is to launch dnsmasq
with options such that it works (= provides DHCP service) for TAP
interfaces that are _not_ bridged to the DHCP interface (ns-XXX
Apologies for commenting so late, but I'm not clear on the concept of bringing
all possible backend projects back inside Neutron.
I think my question is similar to what Henry and Mathieu are getting at below -
viz:
We just recently decided to move a lot of vendor-specific ML2 mechanism
/pipermail/openstack-dev/2014-May/036336.html
[2] https://review.openstack.org/#/c/179953/
On Fri, May 1, 2015 at 8:22 AM, Neil Jerram neil.jer...@metaswitch.com wrote:
Thanks for your reply, Kevin, and sorry for the delay in following up.
On 21/04/15 09:40, Kevin Benton wrote:
Is it compatible
Is there a design for how ML2 mechanism drivers are supposed to cope
with the Neutron server forking?
What I'm currently seeing, with api_workers = 2, is:
- my mechanism driver gets instantiated and initialized, and immediately
kicks off some processing that involves communicating over the
?
Thanks,
Neil
The only time I ever saw anything executed by a child process was actual
API requests (e.g. the create_port method).
On Thu, May 7, 2015 at 6:08 AM, Neil Jerram neil.jer...@metaswitch.com
mailto:neil.jer...@metaswitch.com wrote:
Is there a design for how ML2
more than once, including the function spawned using eventlet.
The only time I ever saw anything executed by a child process was
actual API requests (e.g. the create_port method).
On Thu, May 7, 2015 at 6:08 AM, Neil Jerram
neil.jer...@metaswitch.com mailto:neil.jer
I was just looking at [1] and planning for 'Towards one Network Stack:
Part 2', on Thursday at 5pm. But I don't see the Part 1 of that in the
schedule. Has it got lost, and am I missing it somewhere?
Thanks,
Neil
[1]
On 12/05/15 12:19, Neil Jerram wrote:
I was just looking at [1] and planning for 'Towards one Network Stack:
Part 2', on Thursday at 5pm. But I don't see the Part 1 of that in the
schedule. Has it got lost, and am I missing it somewhere?
Ah, OK, I've found it now under 'Cross Project' here
://review.openstack.org/#/c/163178/
On 05/14/2015 11:29 AM, Neil Jerram wrote:
Hi all, this is about a problem I'm seeing with my Neutron ML2 mechanism
driver [1]. I'm expecting to see an update_port_postcommit call to
signal that the binding:host_id for a port is changing, but I don't see
that.
The scenario
Hi Thomas,
On 16/05/15 06:52, Thomas Goirand wrote:
On 05/15/2015 10:37 AM, neil.jer...@metaswitch.com wrote:
Out of interest, have you done this by re-releasing the Ubuntu
packaging? Or have you taken an independent approach?
Regards,
Neil
It's been since Folsom that I've released
On 14/05/15 20:23, Matt Riedemann wrote:
Regarding RHEL, I think this is a safe bet because in Kilo nova dropped
python 2.6 support and RHEL 6 doesn't have py26 so you'd be in trouble
running kilo+ nova on RHEL 6.x anyway.
I'm personally happy to hear this, because it is a pain supporting
On 14/05/15 16:04, Brian Haley wrote:
On 05/14/2015 05:29 AM, Neil Jerram wrote:
Hi all, this is about a problem I'm seeing with my Neutron ML2
mechanism driver
[1]. I'm expecting to see an update_port_postcommit call to signal
that the
binding:host_id for a port is changing, but I don't see
Hi all, this is about a problem I'm seeing with my Neutron ML2 mechanism
driver [1]. I'm expecting to see an update_port_postcommit call to
signal that the binding:host_id for a port is changing, but I don't see
that.
The scenario is launching a new instance in a cluster with two compute
Hi Matt,
I just re-read this thread, including your intro below. You might be
interested in what we're doing in the Calico project [1][2], as it uses
some of the same idea as the example you describe below, notably
importing TAP interface routes into bird and bird6.
[1]
Hi again Joe, (+ list)
On 11/04/15 02:00, joehuang wrote:
Hi, Neil,
See inline comments.
Best Regards
Chaoyi Huang
From: Neil Jerram [neil.jer...@metaswitch.com]
Sent: 09 April 2015 23:01
To: OpenStack Development Mailing List (not for usage
On 16/04/15 07:40, Dongfeng (C) wrote:
Hi Kyle,
I am currently contributing to integrating ONOS with OpenStack Neutron.
By ONOS do you mean http://onosproject.org/?
http://onosproject.org/ looks very nice, but it's not obvious to me what
the integration with OpenStack would be. Perhaps you
)
-Original Message-
From: Neil Jerram [mailto:neil.jer...@metaswitch.com]
Sent: Wednesday, April 15, 2015 9:46 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron] Neutron scaling datapoints?
Hi again Joe, (+ list)
On 11/04/15 02:00, joehuang wrote:
Hi, Neil,
See
I have a Neutron DHCP agent patch whose purpose is to launch dnsmasq
with options such that it works (= provides DHCP service) for TAP
interfaces that are _not_ bridged to the DHCP interface (ns-XXX). For
the sake of being concrete, this involves:
- creating the ns-XXX interface as a dummy,
On 17/04/15 17:16, Jay Pipes wrote:
On 04/10/2015 11:48 AM, Neil Jerram wrote:
What I imagine, though, is that the _source_ of the plugging information
could move from Nova to Neutron, so that future plugging-related code
changes are a matter for Neutron rather than for Nova. The plugging
On 17/04/15 17:24, Daniel P. Berrange wrote:
On Fri, Apr 17, 2015 at 12:16:25PM -0400, Jay Pipes wrote:
On 04/10/2015 11:48 AM, Neil Jerram wrote:
What I imagine, though, is that the _source_ of the plugging information
could move from Nova to Neutron, so that future plugging-related code
My team is working on experiments looking at how far the Neutron server
will scale, with increasing numbers of compute hosts and VMs. Does
anyone have any datapoints on this that they can share? Or any clever
hints?
I'm already aware of the following ones:
I think that people often mean different things by ACLs, so can you be
more precise?
Thanks,
Neil
From: Rich Wellner r...@objenv.com
Sent: 09 April 2015 01:29
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] Advice on a Neutron ACL
Hi Joe,
Many thanks for your reply!
On 09/04/15 03:34, joehuang wrote:
Hi, Neil,
From theoretic, Neutron is like a broadcast domain, for example, enforcement of DVR and security
group has to touch each regarding host where there is VM of this project resides. Even using SDN controller,
the
Hi Mike,
Many thanks for your reply!
On 08/04/15 17:56, Mike Spreitzer wrote:
Are you looking at scaling the numbers of tenants, Neutron routers, and
tenant networks as you scale hosts and guests? I think this is a
plausible way to grow. The compartmentalizations that comes with
growing
On 08/04/15 22:07, Michael Still wrote:
priorities and specs
===
I think the current spec process is starting to work well for us, and
that priorities was a success. We should continue with specs, but with
an attempt to analyse why so many approved specs don’t land [...]
My team has seen a problem that could be related: in a churn test where
VMs are created and terminated at a constant rate - but so that the
number of active VMs should remain roughly constant - the size of the
host and addn_hosts files keeps increasing.
In other words, it appears that the
and the Neutron
server. You might like to review that thread and see if it describes
any problems analogous to your DHCP one.
Regards,
Neil
On 08/06/15 17:53, Neil Jerram wrote:
My team has seen a problem that could be related: in a churn test where
VMs are created and terminated at a constant
On 08/06/15 18:22, Jay Pipes wrote:
On 06/05/2015 10:56 AM, Neil Jerram wrote:
I guess that's why the GNU autoconf/configure system has always advised
testing for particular wanted features, instead of looking at versions
and then relying on carnal knowledge to know what those versions imply
-infra.org/
[4] https://bugs.launchpad.net/mos/+filebug
On Mon, Jun 8, 2015 at 10:15 AM Neil Jerram
neil.jer...@metaswitch.com mailto:neil.jer...@metaswitch.com wrote:
Two further thoughts on this:
1. Another DHCP agent problem that my team noticed
On 04/06/15 22:54, Thomas Goirand wrote:
The init scripts used to be hard to maintain because they were many, but
since Debian Ubuntu are using automatic generation out of a tiny
template (with sysv-rc, systemd and upstart all supported), this is a
problem solved.
Ooh, that sounds like
Where are the source RPMs that correspond to the binary RPMs at
https://repos.fedorapeople.org/repos/openstack/openstack-kilo/el7/ ?
I guess that
https://repos.fedorapeople.org/repos/openstack/openstack-kilo/testing/source/
might be quite close - but the 'testing' in this URL suggests that
Many thanks, Haïkel, that looks like the information that my team needed.
Neil
On 03/06/15 11:18, Haïkel wrote:
Hi Neil,
We're already having this discussion on the downstream list.
RDO is currently moving packages publication for RHEL/CentOS over CentOS
mirrors. That's just a matter
On 09/06/15 15:28, Daniel P. Berrange wrote:
On Tue, Jun 09, 2015 at 03:07:51PM +0100, Neil Jerram wrote:
Secondly there is the VIF plug script idea, and it's here that the elephant
may be. I'm afraid that some of the interested people (including me) missed
it, but I heard that the core team
On 04/06/15 13:05, Neil Jerram wrote:
Hi John,
On 04/06/15 12:21, John Garbutt wrote:
Hi,
We had a great discussion at the summit around priorities:
https://etherpad.openstack.org/p/YVR-nova-liberty-priorities
I have made a stab at writing that up here, please to review if you
are interested
Hi John,
On 04/06/15 12:21, John Garbutt wrote:
Hi,
We had a great discussion at the summit around priorities:
https://etherpad.openstack.org/p/YVR-nova-liberty-priorities
I have made a stab at writing that up here, please to review if you
are interested:
On 05/06/15 12:32, Sean Dague wrote:
https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2/
This is really informative and useful, thanks.
A few comments / questions, with bits of your text in quotes:
Even figuring out what a cloud could do was pretty terrible. You could
On 22/06/15 15:11, Daniel P. Berrange wrote:
On Mon, Jun 22, 2015 at 11:28:35AM +0100, neil.jer...@metaswitch.com wrote:
It seems like we're possibly stuck now on the VIF plugin script spec [1];
there being core comments in apparently conflicting directions. I wonder if
it's still feasible
On 22/06/15 11:28, neil.jer...@metaswitch.com wrote:
It seems like we're possibly stuck now on the VIF plugin script spec [1];
there being core comments in apparently conflicting directions. I wonder if
it's still feasible for a version of this to land during Liberty?
[1]
Thanks Kris and Sam for your replies!
On 18/06/15 01:20, Kris G. Lindgren wrote:
On 6/17/15, 10:59 AM, Neil Jerram neil.jer...@metaswitch.com wrote:
On 17/06/15 16:17, Kris G. Lindgren wrote:
See inline.
Kris Lindgren
Senior Linux Systems
Hi Andreas,
On 26/06/15 14:04, Andreas Scheuring wrote:
Hi together,
for a new ml2 plugin I would like to pass over some data from neutron to
nova on port creation and update (exploiting port binding extension
[1]). For my prototype I thought of using one of the following response
dictionaries
On 11/06/15 10:47, changzhi wrote:
Hi, all.
I create a vm and it's neutron port's mac address is
fa:16:3e:3f:02:ff. I see fa:16:3e:3f:02:ff inside vm when I run
ifconfig eth0. Why does vm's tap device's mac address is
fe:16:3e:3f:02:ff? Why different between neutron port's mac address
and tap
Hi Carl et al.,
I see from [1] that L3 routed network segments are on the Neutron L3
subteam's roadmap for Liberty, and I wanted to say that I'm very
interested in this work, and - if there isn't someone else already -
happy to take the lead on making it happen.
I'm aware already of several
On 10/06/15 15:47, Andreas Scheuring wrote:
Hi Daniel, Neil and others,
I was thinking about introducing libvirt-network as a new vif type to
nova. It can be used when Neutron prepares a libvirt network for
attaching guests.
Would you see any general concerns with such an approach? Anything
is the TAP interface towards the VM. Does that answer
your question, and would that be possible with a libvirt network?
Thanks,
Neil
--
Ian.
On 10 June 2015 at 12:16, Neil Jerram neil.jer...@metaswitch.com
mailto:neil.jer...@metaswitch.com wrote:
On 10/06/15 15:47, Andreas
On 08/06/15 22:02, Kevin Benton wrote:
This depends on what initialize is supposed to be doing. If it's just a
one-time sync with a back-end, then I think calling it once in each
child process might not be what we want.
I left a comment on Terry's patch. I think we should just use the
Hi Kris,
Apologies in advance for questions that are probably really dumb - but
there are several points here that I don't understand.
On 17/06/15 03:44, Kris G. Lindgren wrote:
We are doing pretty much the same thing - but in a slightly different way.
We extended the nova scheduler to
Couple more dumb comments here - sorry that I'm processing this thread
backwards!
On 16/06/15 15:20, Jay Pipes wrote:
Adding -dev because of the reference to the Neutron Get me a network
spec. Also adding [nova] and [neutron] subject markers.
Comments inline, Kris.
On 05/22/2015 09:28 PM,
Hi Sam,
On 17/06/15 01:31, Sam Morrison wrote:
We at NeCTAR are starting the transition to neutron from nova-net and neutron
almost does what we want.
We have 10 “public networks and 10 “service networks and depending on which
compute node you land on you get attached to one of them.
In
[Sorry - unintentionally dropped -operators below; adding it back in
this copy.]
On 17/06/15 11:35, Neil Jerram wrote:
Hi Sam,
On 17/06/15 01:31, Sam Morrison wrote:
We at NeCTAR are starting the transition to neutron from nova-net and
neutron almost does what we want.
We have 10 “public
Hi Carl,
I know you said at the end of your message below to ping you on IRC, but
there are details here that I'm not sure about, and some suggestions
that I'd like to make, and I think it will be clearer to discuss those
in context. I hope that's OK.
On 11/06/15 17:26, Carl Baldwin wrote:
On 17/06/15 16:17, Kris G. Lindgren wrote:
See inline.
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy, LLC.
On 6/17/15, 5:12 AM, Neil Jerram neil.jer...@metaswitch.com wrote:
Hi Kris,
Apologies in advance for questions that are probably
Hi Gal,
Thanks for starting this thread, and I'm sorry not to have met you
during the summit.
Vancouver was my first summit, and I very much enjoyed it. My
reflection is that I came to the summit with two overall expectations,
of which one proved correct and one false.
The correct
On 29/05/15 14:41, Thierry Carrez wrote:
Hi everyone,
TL;DR:
- We propose to stop tagging coordinated point releases (like 2015.1.1)
- We continue maintaining stable branches as a trusted source of stable
updates for all projects though
[...]
I initially misunderstood your email as saying
On 01/06/15 14:23, Daniel P. Berrange wrote:
On Mon, Jun 01, 2015 at 09:44:24AM +0100, John Garbutt wrote:
On 29 May 2015 at 18:32, Neil Jerram neil.jer...@metaswitch.com wrote:
Hi all,
Per yesterday's IRC meeting [1], and discussion in Vancouver, Nova work is
being somewhat driven
On 01/06/15 17:45, Neil Jerram wrote:
Many thanks, John Dan. I'll start by drafting a summary of the work
that I'm aware of in this area, at
https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work.
OK, my first draft of this is now there at [1]. Please could folk with
VIF-related
Hi all,
Per yesterday's IRC meeting [1], and discussion in Vancouver, Nova work
is being somewhat driven by the etherpad at [2]. But this etherpad
doesn't have a section for libvirt / vif driver changes. The log at [1]
briefly touched on this, but moved on after noting that Dan PB had
Well, the bug discussion seems to point specifically to this dnsmasq fix:
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=9380ba70d67db6b69f817d8e318de5ba1e990b12
Neil
On 01/07/15 07:34, Daniel Comnea wrote:
Hi,
sorry for no feedback, i've been doing more and more test and
packagename or that will be too crazy?
Cheers,
Dani
On Wed, Jul 1, 2015 at 9:23 AM, Neil Jerram neil.jer...@metaswitch.com
mailto:neil.jer...@metaswitch.com wrote:
Well, the bug discussion seems to point specifically to this dnsmasq
fix:
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git
Hi there,
For my team's networking backend, we want to catch security group
updates in our ML2 mechanism driver code.
Currently we're doing this by monkey patching the AgentNotifierApi:
# This section monkeypatches the
AgentNotifierApi.security_groups_rule_updated
# method to ensure
Cool, thank you!
On 29/06/15 14:08, Gal Sagie wrote:
Yes, look at this patch: https://review.openstack.org/#/c/174588/
On Mon, Jun 29, 2015 at 3:42 PM, Neil Jerram neil.jer...@metaswitch.com
mailto:neil.jer...@metaswitch.com wrote:
Hi there,
For my team's networking backend, we want
Hi Jeremy,
On 30/06/15 17:45, Neil Jerram wrote:
On 30/06/15 16:14, Jeremy Stanley wrote:
On 2015-06-30 14:08:45 +0100 (+0100), Neil Jerram wrote:
[...]
I keep going back to Gerrit jobs that I've reviewed or commented
on, and finding that there have been other comments since mine
Apologies if this is an FAQ - I tried a quick search, but that didn't
find anything that looked both up to date and authoritative.
I keep going back to Gerrit jobs that I've reviewed or commented on, and
finding that there have been other comments since mine, but that Gerrit
didn't email me
On 30/06/15 14:33, Julien Danjou wrote:
On Tue, Jun 30 2015, Neil Jerram wrote:
Apologies if this is an FAQ - I tried a quick search, but that didn't find
anything that looked both up to date and authoritative.
I keep going back to Gerrit jobs that I've reviewed or commented on, and
finding
I'd like to announce networking-calico, a new project within the Neutron
stadium to provide OpenStack integration pieces for Project Calico
[1][2]. In a sentence, Calico is a backend that uses routing and
iptables to provide IP-level connectivity between VMs, instead of - as
most Neutron backends
No, still not, I'm afraid.
Original Message
From: Sean M. Collins
Sent: Tuesday, 18 August 2015 19:15
To: OpenStack Development Mailing List (not for usage questions)
Reply To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] New
On 17/08/15 18:47, Neil Jerram wrote:
I'd like to announce networking-calico [...]
Then the plan for networking-calico is that it will contain docs, an ML2
mechanism driver, a DHCP interface driver, and a Devstack plugin for
Calico. These aren't yet at [10], but I will be getting
FYI, I've raised the new RFE bug that I suggested below:
https://bugs.launchpad.net/neutron/+bug/1486649
Neil
On 18/08/15 23:22, Neil Jerram wrote:
Although the DHCP-related patches below are I think very close to mergeable,
Brian Haley on IRC queried what, process-wise, motivates
to approve that, and update the
patches to reference that bug instead.
Does that sound right?
Regards,
Neil
Original Message
From: Neil Jerram
Sent: Monday, 17 August 2015 18:47
To: OpenStack Development Mailing List (not for usage questions)
Reply To: OpenStack Development Mailing List
Can anyone recommend how best to make deb and rpm packages for a
networking-* project?
(Specifically, I mean for networking-calico, but I imagine, if there's a
best current practice, that it would apply to all such projects.)
I'm aware that there were recently some discussions on increased
late in the Liberty cycle, but if you can get Brian, Cedric and Carl to
review this and ensure they are onboard, this is the best way to move forward.
Ensuring the L3 team is ok with the direction would make me comfortable here.
Thanks!
Kyle
On Wed, Aug 19, 2015 at 9:42 AM, Neil Jerram
neil.jer
Hi Andreas,
Thanks for looking at this. I'm happy to say that Jeremy already
identified the problem, in a thread on openstack-infra [1], and I've
submitted a fix for it [2].
Regards,
Neil
[1]
http://lists.openstack.org/pipermail/openstack-infra/2015-August/003087.html
[2]
Thanks Sean, + Andreas for your similar reply...
Yes, I guess that could be it. My company's setup is Exchange, and the
IT folk here assure me that any spam emails would be in my Junk folder -
and the missing Gerrit emails aren't there. But, maybe that's not the
100% full story, for some
On 30/06/15 16:14, Jeremy Stanley wrote:
On 2015-06-30 14:08:45 +0100 (+0100), Neil Jerram wrote:
[...]
I keep going back to Gerrit jobs that I've reviewed or commented
on, and finding that there have been other comments since mine,
but that Gerrit didn't email me about.
[...]
Looking in our
On 21/07/15 15:45, Salvatore Orlando wrote:
On 21 July 2015 at 14:21, Neil Jerram neil.jer...@metaswitch.com
mailto:neil.jer...@metaswitch.com wrote:
You've probably seen Robert Kukura's comment on the related bug at
https://bugs.launchpad.net/neutron/+bug/1458890/comments/30
On 21/07/15 01:47, Assaf Muller wrote:
- Original Message -
I'm looking for feedback from anyone interest but, in particular, I'd
like feedback from the following people for varying perspectives:
Mark McClain (proposed alternate), John Belamaric (IPAM), Ryan Tidwell
(BGP), Neil
On 20/07/15 18:50, Ian Wells wrote:
On 20 July 2015 at 10:21, Neil Jerram neil.jer...@metaswitch.com
mailto:neil.jer...@metaswitch.com wrote:
Hi Ian,
On 20/07/15 18:00, Ian Wells wrote:
On 19 July 2015 at 03:46, Neil Jerram
neil.jer...@metaswitch.com
:
On Wed, Jul 15, 2015 at 10:54 AM, Neil Jerram
neil.jer...@metaswitch.com
mailto:neil.jer...@metaswitch.com wrote:
I've been reading available docs about the forthcoming
Neutron flavors framework, and am not yet sure I
understand what it means
Hi Neutron folk!
I'd like to give an update on and encourage wide review of my work on
a type of network that connects VMs through IP routing instead of
through bridging and tunneling at L2. I believe the core Neutron
pieces of this are now complete and ready for detailed review and
potential
1 - 100 of 297 matches
Mail list logo
