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
> 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 <ke...@benton.pub>:
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
.
>
> 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 a M
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
+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
>
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 <s...@dague.net> wrote:
> On 10/06/2017 07:23 PM,
>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
+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
at 10:02 AM
> To: "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
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
to
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
g 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 function that we validate as 'side-effect free' on the inputs.
I hope that makes sense. Let me know if you have
> fields are same as AFTER_xxx.
> >
> > > Dragon flow folks seems to have their own spec.
> > >
> > > thanks,
> > >
> > > On Mon, Jul 31, 2017 at 02:10:07PM +0900,
> > > Takashi Yamamoto <yamam...@midokura.com> wrote:
>
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
Hi 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).
>>
>
, Sep 4, 2017 at 8:07 AM, Kevin Benton <ke...@benton.pub> wrote:
> > #2 would be preferable as well just because we have so many
> guides/distros
> > mentioning the different file locations. I'm not familiar with mod_wsgi
> > enough to know if it's possible.
> >
&g
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 <mna...@vexxhost.com> wrote:
> On Mon, Sep 4, 2017 at 11:07 AM, Kevin Benton <ke...@benton.pub> wrote:
> > #2 would be pr
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
mna...@vexxhost.com> wrote:
> On Mon, Sep 4, 2017 at 10:40 AM, Mohammed Naser <mna...@vexxhost.com>
> wrote:
> > On Mon, Sep 4, 2017 at 9:01 AM, Kevin Benton <ke...@benton.pub> wrote:
> >> Yes, unfortunately I didn't make it back to the patch in time to adjust
> &g
).
On Mon, Sep 4, 2017 at 7:40 AM, Mohammed Naser <mna...@vexxhost.com> wrote:
> On Mon, Sep 4, 2017 at 9:01 AM, Kevin Benton <ke...@benton.pub> wrote:
> > Yes, unfortunately I didn't make it back to the patch in time to adjust
> > devstack to dump all of the configura
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
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 Benton
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
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
Yeah, the FFE process applies to stadium projects as well.
On Tue, Aug 8, 2017 at 8:07 AM, <thomas.mo...@orange.com> 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
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
>
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
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
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
>
> From: Kev
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
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
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 control.
Cheers,
Kevin Benton
,
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
+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,
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
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
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 <a...@suse.com> wrote:
> On 07/22/2017 11:44 PM, Kevin Benton wrote:
>
>> Could we just put a pl
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
as you can
get).
On Wed, Jul 19, 2017 at 3:31 AM, Stephen Finucane <sfinu...@redhat.com>
wrote:
> On Thu, 2017-07-13 at 07:54 -0600, Kevin Benton wrote:
> > On Thu, Jul 13, 2017 at 7:26 AM, Stephen Finucane <sfinu...@redhat.com>
> wrote:
> >
> > > os-vif has bee
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
53.32.12
> you can check 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 &
e root cause ?
>
> 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
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
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
ing operations.
>
> 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 Bent
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:
i.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 <mtrein...@kortar.org>
wrote:
> On Mon, Jun 19, 2017 at 12:09:12AM -0700, Kevin Benton wrote:
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,
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
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
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 <pabelan...@redhat.com> wrote:
> On Fri, Jun 09, 2017 at 05:20:03AM -0700, Kevin Benton wrote:
> > This was an intentiona
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
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
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
>
>
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
th you. I will try to implement this suggestion.
>
> On Fri, May 26, 2017 at 7:01 PM, Kevin Benton <ke...@benton.pub> 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
26, 2017 at 6:14 PM, Kevin Benton <ke...@benton.pub> wrote:
>
>> 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 L
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
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
:
>
>> On Fri, May 19, 2017, at 02: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
>> > to
>> > make orchestra
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
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
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 <zbit...@redhat.com> wrote:
> On 19/05/17 17:03, Kevin Benton wrote:
>
>> I sp
erspective 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
Cheers,
Ke
.
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)
Unsubscribe
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.launchpad.net/neutron/+bug
+IP?
On Fri, May 19, 2017 at 2:13 PM, Monty Taylor <mord...@inaugust.com> 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
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 <zbit...@redhat.com> wrote:
> On 19/05/17 15:06, Kevin Ben
- 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.html
Cheers,
Kevin Benton
On Fri, May 19,
>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
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
t;
> Following 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
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 List
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
ay showing 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:
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
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
.
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
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
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
t; about switching for new facade, does the master branch fails the same?
>
>
>
> On Mon, Apr 3, 2017 at 8:35 AM Gary Kotton <gkot...@vmware.com> wrote:
>
> Yes, sorry my bad for not adding it - http://logs.openstack.org/39/
> 452539/2/check/gate-vmware-nsx-python27-ubuntu-xenial/
oyment disables the 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 <ke...@benton.pub>
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
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
ked the network node and 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_
,
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
for 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
1 - 100 of 830 matches
Mail list logo