ing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
:
> On Mon, Jul 07, 2014 at 11:01:52PM PDT, Kevin Benton wrote:
> > I can lead it, but I'm not sure if there is anything new to discuss since
> > the QoS spec is still under review.
> > Did you have any specific agenda items that you wanted to cover?
>
> Ah. The QoS IRC
__
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
If I understand correctly, you are having it comment when there is a
retrigger due to an internal CI failure? If so, please don't do this
because it makes the Gerrit reviews very noisy and it provides nothing
relevant to the contributor submitting the patch.
Nobody wants a CI to report that it has
For log storage I would definitely start with compression since these are
just plain text. Make sure you enable gzip decompression in your web server
software so people can still view the log files in their browser.
Before spending tons of disk space on log storage, I would also have it
purge logs
at patch will merge into master, since
> the upstream gate already does that.
>
> Hope that helps,
> -jay
>
> On Thu, Jul 3, 2014 at 11:31 AM, Jay Pipes > <mailto:jaypi...@gmail.com>> wrote:
>>
>> On 07/03/2014 02:10 PM, Kevin Benton wrote:
>>
We might as well note here on the list that the entire QoS extension has
been pushed out to K so there definitely isn't a reason for a meeting now.
:-)
On Tue, Jul 08, 2014 at 02:15:58AM EDT, Kevin Benton wrote:
> I think at this point the discussion is mostly contained in the review f
This bug is also affecting Ryu and the Big Switch CI.
There is a patch to bump the version requirement for alembic linked in the
bug report that should fix it. It we can't get that merged we may have to
revert the healing patch.
https://bugs.launchpad.net/bugs/1342507
On Jul 16, 2014 9:27 AM, "tri
gt; -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Reviving the old thread.
>
> On 17/06/14 11:23, Kevin Benton wrote:
> > Hi Ihar,
> >
> > What is the reason to breakup neutron into so many packages? A
> > quick disk usage stat shows the plugins directory
__
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>OpenStack-dev@lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >___
> >OpenStack-dev mailing list
> >OpenStack-dev@lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ther
> scenarios ?
>
> Thanks!
>
> Peng Gu
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Kevin Benton
lip.tooh...@rackspace.com> wrote:
> It was for more of a potential use to query another service. Don't think
> well go this route though, but was curious why it was one of the only
> values not populated even though there's a field for it.
>
> From: Kevin Benton
> Reply-
While the long term fix is a bump up in the requirements, a workaround
suggested for the 3rd party CI systems is to force an upgrade of alembic
before running devstack. This will allow the setup to work so that patch
isn't a high priority.
--
Kevin Benton
On Fri, Jul 18, 2014 at 9:22 AM,
Neutron has not call other services' API by using the
> token.
>
>
>
> If the underlying agent or plugin wants to use the token, then the
> requirement will be asked by somebody.
>
>
>
> BR
>
>
>
> Joe
>
>
> --
(other than the logs of course) could be used in
a third-party system?
Thanks
1.
http://logs.openstack.org/64/83664/17/check/gate-neutron-python27/db29f20/console.html.gz
On Sun, Jul 13, 2014 at 3:36 PM, Jeremy Stanley wrote:
> On 2014-07-13 00:09:11 -0700 (-0700), Kevin Benton wr
router.
--
Kevin Benton
On Tue, Jul 22, 2014 at 6:55 AM, Ricardo Carrillo Cruz <
ricardo.carrillo.c...@gmail.com> wrote:
> Hello guys
>
> I have the following network setup at home:
>
> [openstack instances] -> [neutron router] -> [ [home router] [vp
code.
Cheers
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
rather than a bug to me.
>
> As an alternative, could you try configuring your router with the static
> route so that it would send an icmp redirect to the neutron router?
>
> Carl
> On Jul 22, 2014 11:23 AM, "Kevin Benton" wrote:
>
>> The issue (if I understa
would be required.
Is exposing that ref in a known format/location something the infra team
might consider?
Thanks
On Tue, Jul 22, 2014 at 4:16 PM, Jeremy Stanley wrote:
> On 2014-07-21 11:36:43 -0700 (-0700), Kevin Benton wrote:
> > I see. So then back to my other question, is it p
ck-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Using the UPDATE WHERE statement you described is referred to as optimistic
locking. [1]
https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/The_CMP_Engine-Optimistic_Locking.html
On Wed, Jul 30, 2014 at 10:30 AM, Jay Pipes wrote:
> On 07/30/2014 10:05 AM, Kevin Benton wr
to update the record will fail if another user updates the record
first."
Did I misinterpret how your approach works?
On Wed, Jul 30, 2014 at 11:07 AM, Jay Pipes wrote:
> On 07/30/2014 10:53 AM, Kevin Benton wrote:
>
>> Using the UPDATE WHERE statement you described i
ied deep in the SQL engine internals where they belong. :-)
On Jul 30, 2014 2:00 PM, "Jay Pipes" wrote:
> On 07/30/2014 12:21 PM, Kevin Benton wrote:
>
>> Maybe I misunderstood your approach then.
>>
>> I though you were suggesting where a node performs an "UPDA
GBP work. If that's
the case, it could be contained in the CLI or possibly introduced in
another extension if it requires too much complexity in the client.
Cheers,
--
Kevin Benton
On Jul 30, 2014 12:25 PM, "Mandeep Dhami" wrote:
> Hi Ryan:
>
> As I stated in the patch r
It seems like this is precisely what the functional test setup was designed
to handle. Is there a reason you don't want to run them as functional tests
instead of unit tests?
As functional tests, nobody would need new prereqs just to make it through
unit tests and anyone that wants to do the full
serivcevm server or nova.
>
> thnaks,
>
>
> On Sun, Jul 20, 2014 at 12:14:54AM -0700,
> Kevin Benton wrote:
>
> > That makes sense. Shouldn't we wait for something to require it before
> > adding it though?
> >
> >
> > On Sat, J
understand this new "endpoint" terminology?
>
> Best,
> -jay
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
1341268
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ware of the EPG right at the outset, then that is
>> even better.
>>
>> I have also noted your suggestion on clarifying the "endpoint"
>> terminology. This was already done in one of the patches you had
>> reviewed earlier, and will do that in t
urpose
of a Keystone endpoint.
On Aug 5, 2014 3:53 PM, "Jay Pipes" wrote:
> On 08/05/2014 05:22 PM, Kevin Benton wrote:
>
>> >Is anyone listening to what I'm saying? The term "endpoint" is obtuse
>> and completely disregards the existing denotation o
Juno. Juno hardly seems to be the appropriate time to
> > introduce a new not-so-stable API; Juno is the time to address all the
> > gaps [0] and hit feature and performance parity with nova-network.
> >
> >
> > [0]
> >
> https://wiki.openstack.org/wiki/Govern
It sounds to me like you are describing how a developer uses Keystone, not
a user. My reference to 'application deployer' was to someone trying to run
something like a mail server on an openstack cloud.
On Aug 6, 2014 7:07 AM, "Russell Bryant" wrote:
> On 08/05/2014 06:13
; On Wed, Aug 6, 2014 at 4:12 PM, Kevin Benton wrote:
>
>> Are there any parity features you are aware of that aren't receiving
>> adequate developer/reviewer time? I'm not aware of any parity features that
>> are in a place where throwing more engineers at them is
e the word 'template'
since this was clearly already in use by Horizon?
On Aug 6, 2014 9:24 AM, "Jay Pipes" wrote:
> On 08/06/2014 02:12 AM, Kevin Benton wrote:
>
>> Given that, pointing to the Nova parity work seems a bit like a red
>> herring. This new API is bei
Hi Aaron,
These are good questions, but can we move this to a different thread
labeled "what is the point of group policy?"
I don't want to derail this one again and we should stick to Salvatore's
options about the way to move forward with these code changes.
On Aug 6, 2014 12:42 PM, "Aaron Rosen
>I believe the referential security group rules solve this problem (unless
I'm not understanding):
I think the disconnect is that you are comparing the way to current mapping
driver implements things for the reference implementation with the existing
APIs. Under this light, it's not going to look
g a
>>>> policy between them.
>>>>
>>>
>>> Would you mind proposing how this is done in the Group policy api? From
>>> what I can tell in the new proposed api you'd need to map both of these
>>> groups to different endpoints i.e networks.
>>>
>>>>
>>>>
>>>> Ryan Moats
>>>>
>>>>
>>>> Best,
>>>
>>> Aaron
>>>
>>>> ___
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev@lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
gt; On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton wrote:
>>
>>> I believe the referential security group rules solve this problem (unless
>>>> I'm not understanding):
>>>>
>>>
>>> I think the disconnect is that you are comparin
ly to continue.
>
> Best,
> -jay
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
wrote:
>
>
>
> On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton wrote:
>
>> >I believe the referential security group rules solve this problem
>> (unless I'm not understanding):
>>
>> I think the disconnect is that you are comparing the way to curr
ed decision.
>
> Just reading free form text, how are we expected to do that? At least I
> can't!
>
> My 2c.
> Armando
>
>
> On 6 August 2014 15:03, Aaron Rosen wrote:
>
>>
>>
>>
>> On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton wrote:
&
he allowed IP addresses. If
you tried to enforce this at the router you would be violating that
specification because devices in the same subnet would be able to
communicate on those blocked ports.
On Wed, Aug 6, 2014 at 5:00 PM, Aaron Rosen wrote:
>
> On Wed, Aug 6, 2014 at 3:35 PM, Kevin Ben
ts of the security group.
On Wed, Aug 6, 2014 at 5:39 PM, Aaron Rosen wrote:
>
>
>
> On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton wrote:
>
>> >Given this information I don't see any reason why the backend system
>> couldn't do enforcement at the logic
hers.
>
> Bottom line, I go back to what I said in a previous email: the Nova and
> Neutron development teams need to do a much better job in being directly
> involved in each other's spec discussions and design conversations.
>
> Best,
> -jay
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I prefer merged because moving it to a separate project blocks it from
enforcing policy on the current API (including calls between service
plugins).
On Wed, Aug 6, 2014 at 4:56 PM, Armando M. wrote:
>
> On 6 August 2014 15:47, Kevin Benton wrote:
>
>> I think we should me
security groups API, you are forcing it to be
implemented there.
On Wed, Aug 6, 2014 at 6:06 PM, Aaron Rosen wrote:
>
>
>
> On Wed, Aug 6, 2014 at 4:46 PM, Kevin Benton wrote:
>
>> That's the point. By using security groups, you are forcing a certain
>> kind of enfo
foundations of the project is a risk to
> GBP as well as Neutron itself.
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Kev
INI module with a pointer to the file, the section name, the
key, and the value with a notification to restart the service.
On Wed, Aug 6, 2014 at 7:40 PM, Aaron Rosen wrote:
>
> On Wed, Aug 6, 2014 at 5:27 PM, Kevin Benton wrote:
>
>> Web tier can communicate with anything excep
the model we have:
>
>
> "With the latter, a mapping driver could determine that communication
> between these two hosts can be prevented by using an ACL on a router or a
> switch, which doesn't violate the user's intent and buys a performance
> improvement and works with po
I'll let someone else explain the current GBP API because I'm not working
on that. I'm just trying to convince you of the value of declarative
network configuration.
On Thu, Aug 7, 2014 at 12:02 PM, Aaron Rosen wrote:
>
>
>
> On Thu, Aug 7, 2014 at 9:54 AM, Kevin Bento
n make the
optimization to not actually sort the whole list if you just need the first
of the largest two elements.
The former is analogous to the security groups API, and the latter to the
GBP API.
On Aug 7, 2014 4:00 PM, "Aaron Rosen" wrote:
>
>
>
> On Thu, Aug 7, 2014 at 12:08
e questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Kevin Benton
__
OpenStack Development Mailing Li
___
> 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
>
--
Kevin Benton
___
that if implemented correctly there could be uses for it outside of the
>
> inspector use case. We look forward to any feedback.
>
>
> Sam (sambetts)
>
> __
> OpenStack Development Mailing List (not for usage quest
>If we add our own database for internal stuff, we go back to the same
problem of allowing bad design.
I'm not sure I understand what you are saying here. A JSON blob that only
one driver knows how to interpret is worse than a vendor table. They both
are specific to one driver but at least with a
___
> 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
>
--
Kevin Benton
___
ling List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Kevin Benton
__
OpenStack Deve
There is something that isn't clear to me from your patch and based on your
description of the workflow below. It sounds like you are following the basic
L3 to ToR topology so each rack is a broadcast domain. If that’s the case, each
rack should be a Neutron network and the mapping should be bet
ge questions)
>>> > Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>>
>>>
>>> _______
complishes the same thing without any upstream
changes, that will be the best way to go.
Perhaps we can merge your approach (config via ssh) with mine (getting the
'baremetal' ports wired up for real connectivity) so we don't need upstream
changes.
1. https://review.openstack.org/#/c/24
gent does its normal logic to get the traffic onto the right VLAN/VXLAN/GRE/whatever.On Nov 26, 2015, at 2:56 AM, Vasyl Saienko <vsaie...@mirantis.com> wrote:Hello Kevin,I've added some pictures that illustrates how it works with HW switch and with VMs on devstack. On Wed, Nov 25, 2015 a
_
> 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
>
--
Kevin Benton
_
27; concept, particularly in the context of
> networking. Changing to a different term is just silly.
>
> But I haven't looked into the history. Perhaps there's some reason we
> need to anyway.
>
> Neil
>
>
> _
/neutron/+bug/1503428
> [4]
> http://lists.openstack.org/pipermail/openstack-dev/2013-November/020457.html
> [5]
> http://lists.openstack.org/pipermail/openstack-dev/2013-December/021083.html
> [6]
> http://lists.openstack.org/pipermail/openstack-dev/2015-November/080816.htm
>
> _
is whole renaming proposal apparently stems from an internal
confusion in keystone?
None of this matters. It was decided a long time ago to use 'project' and
the other projects have switched.
On Fri, Dec 4, 2015 at 10:23 AM, Neil Jerram
wrote:
> On 04/12/15 18:03, Kevin Benton wro
I liked using the meeting for it because it was a nice way for everyone to
get a snapshot of where each thing was at.
On Dec 7, 2015 3:14 PM, "Armando M." wrote:
> Hi neutrinos,
>
> During today's meeting [1] we went through the outstanding blueprints, but
> we only managed to look at a little ov
ect:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Kevin Benton
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.opensta
at it is here :) But I was just curious why it is like
> that.
> Thanks.
>
> --
> Pozdrawiam / Best regards
> Sławek Kapłoński
> sla...@kaplonski.pl
>
> Dnia Wednesday 09 of December 2015 09:55:36 Kevin Benton pisze:
> > It does not appear to be used. I suspect m
How is that different than "neutron port-list
--network-id=" ?
On Mon, May 16, 2016 at 1:38 AM, zhi wrote:
> hi, all
>
> Many times we want to get one network's usage. Like this command:
> "neutron get-network-usage". We can get how many ports were used in this
> network. Besides, we can get
>a) Deleting network's last segment will be prevented. Every network should have
at least one segment to let the port to bind.
This seems a bit arbitrary to me. If a segment is limited to a small part
of the datacenter, it being able to bind for one section of the datacenter
and not the rest is no
+1 for both
On Tue, May 17, 2016 at 5:57 AM, Kyle Mestery wrote:
> +1 (Also +1 for Cedric).
>
> On Tue, May 17, 2016 at 6:07 AM, Ihar Hrachyshka
> wrote:
> > Hi stable-maint-core and all,
> >
> > I would like to propose Brian for neutron specific stable team.
> >
> > His stats for neutron stabl
Yeah, no meetings in #openstack-neutron please. It leaves us nowhere to
discuss development stuff during that hour.
On Tue, May 17, 2016 at 2:54 AM, Miguel Angel Ajo Pelayo <
majop...@redhat.com> wrote:
> I agree, let's try to find a timeslot that works.
>
> using #openstack-neutron with the meet
we will auto remove the
network owned ports.
On Tue, May 17, 2016 at 12:29 PM, Carl Baldwin wrote:
> On Tue, May 17, 2016 at 10:56 AM, Kevin Benton wrote:
> >>a) Deleting network's last segment will be prevented. Every network
> should
> >> have at least one
I'm leaning towards option A because it keeps things cleanly separated.
Also, if a cloud is using a plugin that supports segments, an operator
could use the new API for everything (including single segment networks) so
it shouldn't be that unfriendly.
However...
>If there's some other option that
g/#/c/317358
>
> HongHui Xiao(肖宏辉) PMP®
>
>
> From: Carl Baldwin
> To: OpenStack Development Mailing List
>
> Date: 05/18/2016 11:50
> Subject:Re: [openstack-dev] [Neutron][ML2][Routed Networks]
>
>
>
>
> On May 17, 2016 2:18 PM, "
se meetings anymore, I'm sorry for the
> inconvenience.
>
> Please find the summary here:
>
>
> http://eavesdrop.openstack.org/meetings/network_common_flow_classifier/2016/network_common_flow_classifier.2016-05-17-17.02.html
>
> On Tue, May 17, 2016 at 8:10 PM, Kevin Benton wrote
be worth adding in
just to eliminate the extra steps.
On Wed, May 18, 2016 at 12:11 PM, Brandon Logan wrote:
> On Tue, 2016-05-17 at 13:29 -0700, Kevin Benton wrote:
> > I'm leaning towards option A because it keeps things cleanly
> > separated. Also, if a cloud is using a p
ldwin" wrote:
>
> >On Fri, May 20, 2016 at 1:44 PM, Brandon Logan
> > wrote:
> >> On Thu, 2016-05-19 at 14:16 -0600, Carl Baldwin wrote:
> >>> On Wed, May 18, 2016 at 1:36 PM, Kevin Benton
> wrote:
> >>> >>I may have wrongly assumed th
I've found that the issue is that if you interrupt with ctrl-C it won't
write the profile. However, sending it a SIGTERM with the 'kill' command
did the trick when I was using cprofile. I think oslo service calls os.exit
right on SIGINT so the profiler doesn't get a chance to write out.
On May 23,
The linux bridge agent does support using multiple VXLAN groups. You can
specify a prefix for 'vxlan_group' and the VNIs will be spread across the
multicast addresses in that prefix.[1]
The only difference between that and what your RFE proposes is specific
control over which multicast address is
www.facebook.com/ultimumtechnologies/timeline> | google+
> <https://plus.google.com/+Ultimumtechnologies001/posts>
>
> 2016-06-06 9:36 GMT+02:00 Kevin Benton :
>
>> The linux bridge agent does support using multiple VXLAN groups. You can
>> specify a prefix for
The L3 agent will plug ports into things, but it doesn't know anything
about wiring them up for the appropriate VXLAN/VLAN/whatever. That's all
very l2 specific logic and dependent on if using linuxbridge/ovs/etc.
Think of the l3 agent just like it is Nova wiring up VMs. It plugs them in
and then
I think we want to be careful about allowing every extension to be
configurable by the operator because plugins might expect certain
extensions to be loaded since they are defined in code. I suppose we could
have a way that it is just disabled at the API level but all of the code is
still loaded, b
Polling should be fine. get_port operations a relatively cheap operation
for Neutron.
Maybe for the future we can have a more pluggable version of the nova
callback notifier we have in Neutron like Salvatore pointed out.
On Fri, Jun 10, 2016 at 7:49 AM, Mohammad Banikazemi wrote:
> Hi Neil,
>
>
miss some critical logs.
> Thanks
> Gary
>
> From: Kevin Benton
> Reply-To: OpenStack List
> Date: Saturday, June 11, 2016 at 1:13 AM
> To: OpenStack List
>
> Subject: Re: [openstack-dev] [Kuryr] [Neutron] Waiting until Neutron Port
> isActive
>
> Polling
The other issue with pinging is that it could even be a false positive. A
ping might stop working before everything is actually setup (e.g.
forwarding entries on other hosts, etc). An explicit status field on the
data model avoids assumptions.
On Jun 11, 2016 16:42, "Antoni Segura Puimedon" <
toni+
+1. Neutron should already be able to tell Nova which bridge to use for an
OVS port.[1] For the Linux bridge implementation it's a matter of creating
vlan interfaces and plugging them into bridges like regular VM ports, which
is all the responsibility of the L2 agent. We shouldn't need any changes
Strategy 1 is being pitched to make it easier to implement with the current
internals of the Neutron OVS agent (using integration bridge plugging
events). I'm not sure that's better architecturally long term because the
OVS agent has to have logic to wire up patch ports for the sub-interfaces
anywa
Tue, Jun 14, 2016 at 02:10:52AM -0700, Kevin Benton wrote:
> > Strategy 1 is being pitched to make it easier to implement with the
> current
> > internals of the Neutron OVS agent (using integration bridge plugging
> > events). I'm not sure that's better architect
Yep, and both strategies depend on that "create if not exists" logic so it
makes sense to at least get that implemented while we continue to argue
about which strategy to use.
On Jun 14, 2016 02:43, "Daniel P. Berrange" wrote:
> On Tue, Jun 14, 2016 at 02:35:57AM -0
Jun 14, 2016 at 9:49 AM, Peters, Rawlin
wrote:
> On Tuesday, June 14, 2016 3:43 AM, Daniel P. Berrange (berra...@redhat.com)
> wrote:
> >
> > On Tue, Jun 14, 2016 at 02:35:57AM -0700, Kevin Benton wrote:
> > > In strategy 2 we just pass 1 bridge name to Nova. That'
gic to guess which bridges connected by patch
ports 'belong' to trunk ports because we weren't explicit anywhere.
On Wed, Jun 15, 2016 at 11:01 AM, Peters, Rawlin
wrote:
> On Tuesday, June 14, 2016 6:27 PM, Kevin Benton (ke...@benton.pub) wrote:
> > >which generates an
The VM is paused until the 'up' notification to give the Neutron backend
time to wire up the port.
On Tue, Jun 28, 2016 at 7:59 PM, wrote:
> Hi guys:
>
> As we know, nova will interacts with neutron for port creating and
> configuration while creating VM.
>
> In the method /nova/virt/libvirt/dr
I'm not aware of any issues. Perhaps you can propose a patch to just change
the default in Neutron to that interface and people can -1 if there are any
concerns.
On Tue, Mar 29, 2016 at 4:32 PM, Inessa Vasilevskaya <
ivasilevsk...@mirantis.com> wrote:
> Hi all,
>
> I spent some time researching t
Welcome! \o/
On Fri, Apr 1, 2016 at 12:04 PM, Carl Baldwin wrote:
> Welcome, Assaf!
>
> On Thu, Mar 31, 2016 at 6:48 PM, Armando M. wrote:
> > Hi folks,
> >
> > Assaf's tenacity is a great asset for the Neutron team at large. I
> believe
> > that the drivers team would benefit from that tenacit
Or if you don't like floating IPs, it means you can have floating IPs
available to only one tenant you dislike. :)
On Fri, Apr 1, 2016 at 11:39 AM, Monty Taylor wrote:
> On 04/01/2016 12:00 PM, Fox, Kevin M wrote:
>
>> And with external rbac in mitaka, you can finally have private floating
>> ip
The main barrier to this is that we need to stop using the
'external_network_bridge = br-ex' option for the L3 agent and define a
bridge mapping on the L2 agent. Otherwise the external network is treated
as a special case and the VMs won't actually be able to get wired into the
external network.
O
Try depending on I2a10a8f15cdd5a144b172ee44fc3efd9b95d5b7e
On Thu, Apr 7, 2016 at 8:02 PM, Hongbin Lu wrote:
>
>
> > -Original Message-
> > From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
> > Sent: April-07-16 12:04 PM
> > To: OpenStack Development Mailing List (not for usage question
I don't know if my vote counts in this area, but +1!
On Thu, Apr 7, 2016 at 11:33 PM, Oleg Bondarev
wrote:
> +1, thanks Hirofumi!
>
> On Fri, Apr 8, 2016 at 7:34 AM, Akihiro Motoki wrote:
>
>> Hi Neutrinos,
>>
>> As the API Lieutenant of Neutron team,
>> I would like to propose Hirofumi Ichihar
201 - 300 of 844 matches
Mail list logo
