The neutron API now supports compare and swap updates with an If-Match
header so the race condition can be avoided.
https://bugs.launchpad.net/neutron/+bug/1703234
On Fri, Jun 1, 2018, 04:57 Rabi Mishra wrote:
>
> On Fri, Jun 1, 2018 at 3:57 PM, Lajos Katona
> wrote:
>
>> Hi,
>>
>> Could some
> Changes that were proposed by Tatiana, just let save current flexability.
>
> [1] https://github.com/openstack/neutron/blob/stable/pike/
> neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L907
>
> 2018-03-19 16:24 GMT+03:00 Kevin Benton :
>
>> Di
You can run as many neutron server processes as you want in an
active/active setup.
On Tue, Mar 20, 2018, 18:35 Frank Wang wrote:
> Hi All,
> As far as I know, neutron-server only can be a single node, In order
> to improve the reliability of the system, Does it support the main backup
> or
at done.
>
> Currently, we don't use the prevent ARP spoofing option
> (prevent_arp_spoofing = False) and honestly I don't understand why this
> option is enabled as default in private networks. Each such network belongs
> to one user, who controls all instances. Who would decide to perform
Do you need to spoof arbitrary addresses? If not (i.e. a set you know ahead
of time), you can put entries in the allowed_address_pairs field of the
port that will allow you to send traffic using other MAC/IPs.
On Mar 19, 2018 8:42 PM, "Vadim Ponomarev" wrote:
Hi,
I support, that is a problem. I
+1! ... even though I haven't been around. :)
On Wed, Nov 29, 2017 at 1:21 PM, Miguel Lavalle wrote:
> Hi Neutron Team,
>
> I want to nominate Slawek Kaplonski (irc: slaweq) to Neutron core. Slawek
> has been an active contributor to the project since the Mitaka cycle. He
> has been instrumental
Oh, I suppose it depends on what you mean by "ovs" in this context. The
Neutron OVS agent shouldn't trigger any flow losses, but restarted the OVS
vswitchd process may do that.
On Sat, Oct 7, 2017 at 2:31 AM, Sean Dague wrote:
> On 10/06/2017 07:23 PM, Kevin Benton wrote:
>The neutron story is mixed on accessable upgrade, because at least in some
cases, like ovs, upgrade might trigger a network tear down / rebuild that
generates an outage (though typically a pretty small one).
This shouldn't happen. If it does it should be reported as a bug. All
existing OVS flows
https://photos.app.goo.gl/Aqa51E2aVkv5b4ah1
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/l
+1
On Tue, Sep 12, 2017 at 8:50 PM, Sławek Kapłoński
wrote:
> +1
>
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
>
>
>
>
> > Wiadomość napisana przez Miguel Lavalle w dniu
> 12.09.2017, o godz. 17:23:
> >
> > Dear Neutrinos,
> >
> > Our social event will take place on Thursday Sep
"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [neutron]OVS connection tracking cleanup
>
> Hi Kevin
> Thanks for your response it was about 50 vms
> Ajay
>
>
>
> On Sep 11,
The biggest improvement will be switching to native netlink calls:
https://review.openstack.org/#/c/470912/
How many VMs were on a single compute node?
On Mon, Sep 11, 2017 at 9:15 AM, Ajay Kalambur (akalambu) <
akala...@cisco.com> wrote:
> Hi
> I am performing a scale test and I see that after
me, Thierry, or Doug Hellmann.
Cheers,
Kevin Benton
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin
dictionaries with fewer than 10 keys and values
with small strings or lists of only a few entries, making the copy
operations cheap.
If we did want to get rid of the copy operation, it would probably be
quicker to add a new decorator that doesn't copy and then slowly opt into
for each func
; > (some of fields are actually unused right now. eg. tenant_id)
> > on AFTER_DELETE, we only need "id" field of the resource.
> > in feature we want to use PRECOMMIT_xxx events as well. necessary
> > fields are same as AFTER_xxx.
> >
> > > Dragon flow fo
Hello everyone,
With the help of Miguel we have a tentative schedule in the PTG. Please
check the etherpad and if there is anything missing you wanted to see
discussed, please reach out to me or Miguel right away to get it added.
Cheers,
Kevin Benton
On Thu, Jul 27, 2017 at 9:53 PM, Kevin
On 04.09.2017 15:01, Kevin Benton wrote:
>
>> Yes, unfortunately I didn't make it back to the patch in time to adjust
>> devstack to dump all of the configuration into one file (instead of
>> /etc/neutron/neutron.conf /etc/neutron/plugins/ml2.conf etc).
>>
>
> Yo
n
files a regression.
+1. That would make an upgrade nightmare. In my earlier email I didn't mean
to imply that was the only way forward. I was just curious if it still
broke when everything was in one file.
On Tue, Sep 5, 2017 at 7:01 AM, Ihar Hrachyshka wrote:
> On Mon, Sep 4, 2017 at 8:07
Did you look into setting config files in an env var? That seemed like the
best bet given that #2 is out.
On Mon, Sep 4, 2017 at 8:19 AM, Mohammed Naser wrote:
> On Mon, Sep 4, 2017 at 11:07 AM, Kevin Benton wrote:
> > #2 would be preferable as well just because we have so many
Due to the US holiday I will not be around to run it.
Cheers,
Kevin Benton
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
wrote:
> On Mon, Sep 4, 2017 at 10:40 AM, Mohammed Naser
> wrote:
> > On Mon, Sep 4, 2017 at 9:01 AM, Kevin Benton wrote:
> >> Yes, unfortunately I didn't make it back to the patch in time to adjust
> >> devstack to dump all of the configuration into one file (instea
g (e.g. ml2_conf.ini).
On Mon, Sep 4, 2017 at 7:40 AM, Mohammed Naser wrote:
> On Mon, Sep 4, 2017 at 9:01 AM, Kevin Benton wrote:
> > Yes, unfortunately I didn't make it back to the patch in time to adjust
> > devstack to dump all of the configuration into one file (instead of
&g
Yes, unfortunately I didn't make it back to the patch in time to adjust
devstack to dump all of the configuration into one file (instead of
/etc/neutron/neutron.conf /etc/neutron/plugins/ml2.conf etc). I did test
locally with my dev environment around the time that RPC server patch went
in, but the
Hi everyone,
I'm canceling the drivers meeting today to allow everyone to focus on fixes
for Pike.
Let me or Armando know right away if you have have any fixes that need to
go into RC2 since he has prepared the RC2 release patch already.
Cheers,
Kevin B
This is just the code simulating the conntrack entries that would be
created by real traffic in a production system, right?
On Wed, Aug 9, 2017 at 11:46 AM, Jakub Libosvar wrote:
> On 09/08/2017 18:23, Jeremy Stanley wrote:
> > On 2017-08-09 15:29:04 +0200 (+0200), Jakub Libosvar wrote:
> > [...
This change looks good to me since it's quite small. Make sure you leave
feedback on Armando's release patch to update the hash for the this repo
before Thursday.
On Tue, Aug 8, 2017 at 8:16 AM, wrote:
> Hi PTL/all,
>
> I would like to request an exception for inclusion in Pike, of MPLS/GRE
> su
Yeah, the FFE process applies to stadium projects as well.
On Tue, Aug 8, 2017 at 8:07 AM, wrote:
> Hi Kevin,
>
> Am I right to assume this applies to stadium projects as well ?
> (since they now are all under cycle-with-milestones)
>
> -Thomas
>
>
> Kevin Benton, 2
I think this is okay. It's been a long standing bug and the patch has is
very close to ready.
On Thu, Aug 3, 2017 at 4:26 PM, Swaminathan Vasudevan
wrote:
>
> Hi PTL/all,I would like to request an exception for inclusion of
> https://bugs.launchpad.net/neutron/+bug/1583694for Pike.
>
> This fix
Based on feedback from Brian, this patch is close to ready so we should be
able to land it. It also proposes a limited risk to existing deployments
not using the new agent mode.
On Thu, Aug 3, 2017 at 4:26 PM, Swaminathan Vasudevan
wrote:
>
>
>
> Hi PTL/all,
> I would like to request an exceptio
Granted:
http://eavesdrop.openstack.org/meetings/neutron_drivers/2017/neutron_drivers.2017-08-03-22.02.log.html
On Fri, Jul 28, 2017 at 11:50 AM, Ihar Hrachyshka
wrote:
> Hi PTL/all,
>
> I would like to request an exception for inclusion of net-mtu-enh API
> extension (with ML2 implementation) f
t;https://review.openstack.org/#/c/418862/> - Functional test
> 09.<https://review.openstack.org/#/c/482886/> - API test
> 10.<https://review.openstack.org/#/c/396116/> - Devstack plugin
>
> Best regards,
>
>
> Yushiro FURUKAWA
>
> Fro
Granted:
http://eavesdrop.openstack.org/meetings/neutron_drivers/2017/neutron_drivers.2017-08-03-22.02.log.html
On Tue, Aug 1, 2017 at 12:19 AM, Takashi Yamamoto
wrote:
> On Tue, Aug 1, 2017 at 8:01 AM, Takashi Yamamoto
> wrote:
> > hi,
> >
> > I'm not sure if changes like this requires an FFE,
Granted:
http://eavesdrop.openstack.org/meetings/neutron_drivers/2017/neutron_drivers.2017-08-03-22.02.log.html
On Tue, Aug 1, 2017 at 12:44 PM, Miguel Lavalle wrote:
> Hi PTL/all
>
> I want to request an exception to include the dns_domain for ports
> extension in the Pike release.
>
> The exte
change in focus for many
companies we haven't seen a lot of new contributors with enough time for a
core reviewer load.
* Tooling for review backlog. I did adjust the auto-abandon script a bit
but there is no automated process yet to help keep this under contro
,
Kevin Benton
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Maybe we could just ban search engines from indexing the releases using
robots.txt once they go EOL. That would solve the problem of losing old
information for people that still need it while preventing people stumbling
onto old docs when they search for something.
On Fri, Jul 28, 2017 at 12:39 PM
+1 to remove during Queens if we don't get maintainers.
On Thu, Jul 27, 2017 at 6:31 PM, Takashi Yamamoto
wrote:
> hi,
>
> some of drivers in neutron-vpnaas don't have maintainers. [1]
> unless someone steps up, we might end up with removing those drivers.
>
> especially, VyattaIPsecDriver will
Hi all,
If you are planning on attending the PTG and the Neutron sessions, please
add your name to the etherpad[1] so we can get a rough size estimate.
1. https://etherpad.openstack.org/p/neutron-queens-ptg
Cheers,
Kevin Benton
Thank you. That's exactly what we needed.
On Wed, Jul 26, 2017 at 8:57 AM, Jeremy Stanley wrote:
> On 2017-07-26 03:04:42 + (+), hoan...@vn.fujitsu.com wrote:
> > We are recently trying to propose a Netlink solution [1] in order
> > to improve performance for Neutron's Security Group.
>
If I understand the main issue with using regular callbacks, it's mainly
just that the flavor assignment itself is in a callback, right?
If so, couldn't we solve the problem by just moving flavor assignment to an
explicit call before emitting the callbacks? Or would that still result in
other orde
Yeah, the networking guide does include configuration for some of the
sub-projects (e.g. BGP is at [1]). For the remaining ones there is work
that needs to be done because their docs live in wiki pages.
1.
https://docs.openstack.org/ocata/networking-guide/config-bgp-dynamic-routing.html
On Sun,
Yeah, I was just thinking it makes it more explicit that we haven't just
skipped doing an admin guide for a particular project.
On Sun, Jul 23, 2017 at 1:18 AM, Andreas Jaeger wrote:
> On 07/22/2017 11:44 PM, Kevin Benton wrote:
>
>> Could we just put a placeholder in those s
Could we just put a placeholder in those subprojects /admin directories
that redirects to the networking guide?
On Sat, Jul 22, 2017 at 10:50 AM, Doug Hellmann
wrote:
> Excerpts from Akihiro Motoki's message of 2017-07-23 02:13:40 +0900:
> > Hi,
> >
> > I have a question on admin/ document relat
dor agnostic as you can
get).
On Wed, Jul 19, 2017 at 3:31 AM, Stephen Finucane
wrote:
> On Thu, 2017-07-13 at 07:54 -0600, Kevin Benton wrote:
> > On Thu, Jul 13, 2017 at 7:26 AM, Stephen Finucane
> wrote:
> >
> > > os-vif has been integrated into nova since the newt
subnets
visible by default in our default policy.json at the same time.
Does anyone have any objections to making external subnets visible by
default?
1. https://review.openstack.org/#/c/476094/
Cheers,
Kevin Benton
Some of the stuff like '802.1qbh' isn't particularly vendor specific so I'm
not sure who will host it and a repo just for that seems like a bit much.
Should we just bite the bullet and convert them in the nova tree or put
them in os-vif?
On Thu, Jul 13, 2017 at 7:26 AM, Stephen Finucane
wrote:
the attachement, and more logs can be found at
> https://bugs.launchpad.net/neutron/+bug/1697243
>
>
> On 6/23 16:43, Kevin Benton wrote:
>
> Can you provide your ml2_conf.ini values you are using?
>
> On Thu, Jun 22, 2017 at 7:06 AM, Margin Hu wrote:
>
>> thanks.
gt; rpm -qa | grep openvswitch
> openvswitch-2.6.1-4.1.git20161206.el7.x86_64
> python-openvswitch-2.6.1-4.1.git20161206.el7.noarch
> openstack-neutron-openvswitch-10.0.1-1.el7.noarch
>
>
>
> On 6/22 9:53, Kevin Benton wrote:
>
> Rules to allow aren't setup until the port
Rules to allow aren't setup until the port is wired and it calls the
functions like this:
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L602-L606
On Wed, Jun 21, 2017 at 4:49 PM, Margin Hu wrote:
> Hi Guys,
>
> I have a questi
Some context here:
http://lists.openstack.org/pipermail/openstack-dev/2017-April/115200.html
On Wed, Jun 21, 2017 at 2:33 AM, Thomas Morin
wrote:
> Hi Akihiro,
>
> While I understand the motivation to move these dashboards from
> openstack/horizon, what is the reason to prefer a distinct repo fo
gt;
> Of course, we need to add the ability to report any regression on
> that. I think unit tests will help and we can also work on a
> functional test based on a fake non-DB core plugin.
>
> Regards,
> Édouard.
>
> On Tue, Jun 20, 2017 at 12:09 AM, Kevin Benton wrote:
> > The
vif_details has always been a bag of goodies for mech drivers to pack in
information relevant to wiring up the vif_type. This sounds like a pretty
standard addition so I don't see any blockers.
On Tue, Jun 20, 2017 at 9:16 AM, Alonso Hernandez, Rodolfo <
rodolfo.alonso.hernan...@intel.com> wrote:
pi.context_manager.writer.using(context):
>
> secgroup_db = (
>
> super(NsxV3Plugin, self).create_security_group(…
>
>
>
> The rules are not populated. The db_api.context_manager.writer.using is
> what is causing the problem
The issue is mainly developer resources. Everyone currently working
upstream doesn't have the bandwidth to keep adding/reviewing the layers of
interfaces to make the DB optional that go untested. (None of the projects
that would use them run a CI system that reports results on Neutron
patches.)
I
Thanks. Maybe this would be a good opportunity to just have people start
putting everything in neutron.conf if they want to switch to wsgi.
On Mon, Jun 19, 2017 at 12:21 AM, Matthew Treinish
wrote:
> On Mon, Jun 19, 2017 at 12:09:12AM -0700, Kevin Benton wrote:
> > I've been worki
I've been working on Victor's patch a bit. One thing that isn't clear to me
is how we can get the neutron.conf options loaded when using WSGI. How are
other projects doing this?
On Fri, Jun 2, 2017 at 7:44 AM, Emilien Macchi wrote:
> On Thu, Jun 1, 2017 at 10:28 PM, Morales, Victor
> wrote:
> >
Do you mean the callback event for AFTER_CREATE is missing the rules when
it's for default security groups?
On Sun, Jun 18, 2017 at 4:44 AM, Gary Kotton wrote:
> Hi,
> That patch looks good. We still have an issue in that the create security
> groups does not return the list of the default rules
No, it currently does not. As we implement
https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch that
will change, but that won't be available until Pike or Queens.
On Thu, Jun 15, 2017 at 5:47 AM, wrote:
> Hello,
>
>
>
>
>
>
>
> I am looking to improve the database load distributio
t for this seems to be that operators are already
breaking consistency using other scripts, etc so we shouldn't care.
On Fri, Jun 9, 2017 at 6:03 AM, Paul Belanger wrote:
> On Fri, Jun 09, 2017 at 05:20:03AM -0700, Kevin Benton wrote:
> > This was an intentional decision. One of the
This was an intentional decision. One of the goals of OpenStack is to
provide consistency across different clouds and configurable defaults for
new tenants default rules hurts consistency.
If I write a script to boot up a workload on one OpenStack cloud that
allows everything by default and it doe
Can you file a bug against Neutron and reference it here?
On Thu, Jun 8, 2017 at 8:28 AM, Ricardo Noriega De Soto wrote:
> There is actually a bunch of patches waiting to be reviewed and approved.
>
> Please, we'd need core reviewers to jump in.
>
> I'd like to thank Gary for all his support and
I think this was meant to fix it. https://review.openstack.org/#/c/471512/
On Wed, Jun 7, 2017 at 4:51 AM, Gary Kotton wrote:
> Hi,
>
> It seems that the pep8 is broken due to https://github.com/openstack/
> requirements/commit/99fae827973465147359cc7032c83003802612a7
>
> Should we revert this?
Hi,
Due to a conflict today I am canceling the drivers meeting.
Cheers,
Kevin Benton
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
mplement this suggestion.
>
> On Fri, May 26, 2017 at 7:01 PM, Kevin Benton wrote:
>
>> Just triggering a status change should just be handled as a port update
>> on the agent side which shouldn't interrupt any existing flows. So an l3
>> agent reboot should be safe in
Just triggering a status change should just be handled as a port update on
the agent side which shouldn't interrupt any existing flows. So an l3 agent
reboot should be safe in this case.
On May 26, 2017 6:06 AM, "Anil Venkata" wrote:
> On Fri, May 26, 2017 at 6:14 PM, K
Perhaps when the L3 agent starts up we can have it explicitly set the port
status to DOWN for all of the HA ports on that node. Then we are guaranteed
that when they go to ACTIVE it will be because the L2 agent has wired the
ports.
On Fri, May 26, 2017 at 5:27 AM, Anil Venkata
wrote:
> This is r
Is it being dropped by iptables? Check the following:
* Your VM using the correct IPv6 address assigned to it by Neutron
* The security group associated with the port allows outbound IPv6 traffic
* ensure bridge-nf-call-ip6tables is set to 1 in the kernel of the compute
node
On Thu, May 25, 2017
from users.
1.
https://github.com/openstack/neutron-lib/blob/ca299b8e47fdd5030dda596fd779beb3e5bea6cf/neutron_lib/api/definitions/network.py#L43
On Fri, May 19, 2017 at 3:27 PM, Armando M. wrote:
>
>
> On 19 May 2017 at 14:54, Clark Boylan wrote:
>
>> On Fri, May 19, 2017
Hi,
There will be no neutron team meeting today due to a conflict on my end.
If you have any announcements, please direct them to the mailing list. Ask
any questions about bugs or blueprints in the #openstack-neutron channel.
Cheers,
Kevin Benton
I think we just need someone to volunteer to do the work to expose it as
metadata to the VM in Nova.
On May 22, 2017 1:27 PM, "Robert Li (baoli)" wrote:
> Hi Levi,
>
>
>
> Thanks for the info. I noticed that support in the nova code, but was
> wondering why something similar is not available for
Can you file a patch to adjust tox.ini of l2gw to make it the same as the
others?
On May 22, 2017 7:35 AM, "Ricardo Noriega De Soto"
wrote:
> Hello guys,
>
> I'm trying to enable some tempest tests into puppet-openstack-integration
> project. I basically did the same procedure as with other Neut
rnal networks. So the only way to
distinguish which floating IP to translate to is which router the traffic
is being directed to by the instance, which requires router interfaces.
Cheers
On Fri, May 19, 2017 at 3:29 PM, Zane Bitter wrote:
> On 19/05/17 17:03, Kevin Benton wrote:
>
>>
.
If this is a burning point for you as an operator, consider looking into
Dragonflow, which now has support for distributed SNAT.
Cheers,
Kevin Benton
__
OpenStack Development Mailing List (not for usage questions)
Unsubs
r's perspective available
in etherpad
1. https://bugs.launchpad.net/neutron/+bug/1692126
2. https://bugs.launchpad.net/neutron/+bug/1692128
3. https://bugs.launchpad.net/neutron/+bug/1692130
4. https://bugs.launchpad.net/neutron/+bug/1692131
Also, keep an eye out for the
summary of the closely related session "Making Neutron easy for people who
want basic Networking" from Sukhdev if your topics were covered that
session.
1. https://bugs.launchpad.net/neutron/+bug/1692133
2. https://bugs.launch
ecify port+IP?
On Fri, May 19, 2017 at 2:13 PM, Monty Taylor wrote:
> On 05/19/2017 04:03 PM, Kevin Benton wrote:
>
>> I split this conversation off of the "Is the pendulum swinging on PaaS
>> layers?" thread [1] to discuss some improvements we can make to Neutron
>&g
Started a new Neutron-specific thread so we can get some stuff turned into
improvements in Neutron from this:
http://lists.openstack.org/pipermail/openstack-dev/2017-May/117112.html
On Fri, May 19, 2017 at 1:05 PM, Zane Bitter wrote:
> On 19/05/17 15:06, Kevin Benton wrote:
>
>> Do
s://bugs.launchpad.net/heat/+bug/1626634 - These seems similar to
1626607. Can we just expose the interfaces/router a floating IP is
depending on explicitly in the API for you to fix these? If not, what can
we do to help here?
1. http://lists.openstack.org/pipermail/openstack-dev/2017-May/117106.htm
>Don't even get me started on Neutron.[2]
It seems to me the conclusion to that thread was that the majority of your
issues stemmed from the fact that we had poor documentation at the time. A
major component of the complaints resulted from you misunderstanding the
difference between networks/subn
See message below from Miguel for details on the neutron social.
Dear Neutrinos,
We have a plan for tomorrow night, Wednesday 10th at 7pm. We are going to
meet at UNO Pizzeria and Grill, 731 Boylston Street Boston, MA 02116, phone
number (617) 267-8554. This location is a very easy walk of less
ollowing our past tradition, we should have Neutron dinner while we are
> all in Boston.
>
> Miguel has few places in mind. I would propose that we nominate him as the
> dinner organizer lieutenant.
>
>
>
> Miguel, I hope you will take us to some cool place.
>
>
>
>
Thanks for all of your contributions. Good luck in your new role!
Cheers
On Thu, May 4, 2017 at 9:52 AM, Rossella Sblendido
wrote:
> Hi all,
>
> I've moved to a new position recently and despite my best intentions I
> was not able to devote to Neutron as much time and energy as I wanted.
> It's
Hi all,
I'm canceling the drivers meeting May 4th and 11th to avoid discussion of
new features until after the summit when we have collected user/operator
feedback.
Cheers,
Kevin Benton
__
OpenStack Development Mailing
Thanks for all of your work. Come back soon. ;)
On Apr 28, 2017 05:02, "Miguel Angel Ajo Pelayo"
wrote:
>
> Hi everybody,
>
> Some of you already know, but I wanted to make it official.
>
> Recently I moved to work on the networking-ovn component,
> and OVS/OVN itself, and while I'll
patches that are fixes for high/critical bugs, approved
> blueprints and RFE. You can find it here [1] under "Gerrit Dashboard links"
>
> cheers,
>
> Rossella
>
> [1] http://status.openstack.org/reviews/
>
> On 04/18/2017 12:45 AM, Kevin Benton wrote:
> > H
Hi,
If you are a Neutron developer attending the Boston summit, please add your
name to the etherpad here so we can plan a Neutron social and easily
coordinate in person meetings:
https://etherpad.openstack.org/p/neutron-boston-summit-attendees
Cheers,
Kevin Benton
FWIW mine just came through yesterday.
On Wed, Apr 19, 2017 at 12:13 PM, Jay S Bryant wrote:
> All,
>
> For those of you haven't received an e-mail, check the inbox you use for
> Gerrit. You can verify what that is by going to review.openstack.org ,
> click your name, go to settings, the e-mail
Whenever you want to work on the second patch you would need to first
checkout the latest version of the first patch and then cherry-pick the
later patch on top of it. That way when you update the second one it won't
affect the first patch.
The -R flag can also be used to prevent unexpected rebase
hand.
Cheers,
Kevin Benton
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I haven't received one either.
Perhaps Monty has simply embraced the 'cattle not pets' approach and we
were the unlucky ones. :)
On Apr 12, 2017 07:49, "Lance Bragstad" wrote:
>
> On Wed, Apr 12, 2017 at 9:42 AM, Amrith Kumar
> wrote:
>
>> Hmm, all the cool kids didn’t receive the email but I
I would strongly recommend that you don't build anything based on these
messages. The contents change from release to release since this is an
internal API between the agents and the server.
On Apr 6, 2017 00:48, "Sam" wrote:
> Thank you, use debug option will also help us to get detail of RPC
>
I think 'a' is probably the way to go since we can mainly rely on existing
horizon guides for creating new dashboard repos.
On Apr 10, 2017 08:11, "Akihiro Motoki" wrote:
> Hi neutrinos (and horizoners),
>
> As the title says, where would we like to have horizon dashboard for
> neutron stadium p
onfused change https://review.openstack.org/#/c/452539/ is
> about switching for new facade, does the master branch fails the same?
>
>
>
> On Mon, Apr 3, 2017 at 8:35 AM Gary Kotton wrote:
>
> Yes, sorry my bad for not adding it - http://logs.openstack.org/39/
> 452539/2/check/ga
e Neutron server's DHCP
> scheduling, with
>
> self._supported_extension_aliases.remove("dhcp_agent_
> scheduler")
>
> ?
>
> Thanks,
> Neil
>
>
> On Fri, Mar 31, 2017 at 12:52 AM Kevin Benton wrote:
>
>> Hi,
>>
Hello all,
This is just a quick reminder that the team meeting will be at the old time
today of 2100 UTC in openstack-meeting due to the revert if the alteration.
Cheers
__
OpenStack Development Mailing List (not for usage qu
Do you have a link to a traceback?
On Apr 2, 2017 09:25, "Gary Kotton" wrote:
> Hi,
>
> The change https://review.openstack.org/#/c/402750/ has broken the
> vmware-nsx plugin. I am not sure if this has had effect on any other
> decomposed plugins.
>
> One of the issues that we have is when we cr
the
> nf_conntrack_proto_gre kernel module is not loaded. Among the loaded kernel
> modules the only ones bearing the ‘nf_conntrack’ prefix are the following:
>
>
>
> - nf_conntrack
>
> - nf_conntrack_ipv4
>
> - nf_conntrfack_ipv6
>
,
see [3].
1. https://review.openstack.org/452009
2. https://github.com/openstack/neutron/blob/4ed53a880714fd33280064c58e6f91
b9ecd3823e/neutron/api/rpc/handlers/dhcp_rpc.py#L292-L294
3. https://docs.openstack.org/developer/neutron/devref/
provisioning_blocks.html
Cheers,
Kevin Benton
deciding
what features are feasible for the platform.
1.
http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
Cheers,
Kevin Benton
__
OpenStack Development Mailing List (not for usage questions
Do you have the nf_conntrack_proto_gre kernel module loaded on the network
node?
On Wed, Mar 29, 2017 at 4:37 PM, Anil Rao wrote:
> Strangely enough, there is no problem when I make use of a VxLAN tunnel to
> communicate between the VM (inside the cloud) and an external machine. In
> this case,
1 - 100 of 844 matches
Mail list logo
