Yesterday, I got looking at another option that I had completely
forgotten about. It is "allow_overlapping_ips", set in neutron.conf
and defaults to False. It appears that when it is False, Neutron
doesn't allow any overlapping IPs throughout the deployment, across
all networks. My guess is that
On Mon, Mar 23, 2015 at 4:23 PM, Kevin Benton wrote:
> How would you represent that you want the last address in a /26 network if
> you don't know what address range you are getting? 0.0.0.63? That seems
> pretty confusing when the resulting address turns out to be 192.168.10.191.
>
>>It isn't a n
On Mon, Mar 23, 2015 at 8:52 AM, John Belamaric wrote:
>
> On 3/21/15, 9:10 AM, "Salvatore Orlando" wrote:
>
> If we feel a need for specifying the relative position of gateway address
> and allocation pools when creating a subnet from a pool which will pick a
> CIDR from its prefixes, then the i
out the network part? Am I alone in this?
Carl
On Fri, Mar 20, 2015 at 3:34 PM, Kevin Benton wrote:
> What if we just call it 'address_index' and make it an integer representing
> the offset from the network start address?
>
> On Fri, Mar 20, 2015 at 12:39 PM, Carl Baldwin w
On Mon, Mar 23, 2015 at 9:03 AM, Salvatore Orlando wrote:
>> Actually, I don't see this as a big deal or a failure. In fact, it may be
>> quite common and useful for a given driver to store some state in its own
>> tables (like the reference driver is doing). The primary goal is to enable
>> alter
On Mon, Mar 23, 2015 at 12:04 PM, John Davidge (jodavidg)
wrote:
> The above blueprint outlines an admin-configurable global default pool to
> be used in the case of a user calling subnet-create without specifying a
> CIDR or subnet-pool ID. If the OpenStack environment has been made
> PD-capable
On Wed, Mar 18, 2015 at 8:15 AM, Sean M. Collins wrote:
> On Wed, Mar 18, 2015 at 06:45:59AM PDT, John Davidge (jodavidg) wrote:
>> In the IPv6 meeting yesterday you mentioned doing this
>> with an extension rather than modifying the core API. Could you go into
>> some detail about how you see thi
On Mon, Mar 23, 2015 at 9:52 AM, Salvatore Orlando wrote:
> I think the goal of subnet pools is to use these environments as "units of
> isolations" and ensure no overlapping CIDRs there. However, since there is
> no way to identify such environments at the API layers, API clients will
> need to b
On Mon, Mar 23, 2015 at 8:56 AM, John Belamaric wrote:
>
>
> On 3/22/15, 8:05 PM, "Ian Wells" wrote:
>
>
> Seems to me that an address pool corresponds to a network area that you can
> route across (because routing only works over a network with unique
> addresses and that's what an address pool
On Fri, Mar 20, 2015 at 1:48 PM, Jay Pipes wrote:
> I actually don't think the API URI structure should acknowledge if there is
> or is not a window of time that is involved in some action. Instead, whether
> or not the API call returns a 202 Accepted or a 201 Created should be
> sufficient for co
On Fri, Mar 20, 2015 at 1:34 PM, Jay Pipes wrote:
> How is 0.0.0.1 a host address? That isn't a valid IP address, AFAIK.
It isn't a valid *IP* address without the network part. However, it
can be referred to as the "host address on the network" or the host
part of the IP address.
Carl
On Fri, Mar 20, 2015 at 12:31 PM, Jay Pipes wrote:
> This is a question purely out of curiousity. Why is Neutron averse to the
> concept of using tenants as natural ways of dividing up the cloud -- which
> at its core means "multi-tenant", on-demand computing and networking?
>From what I've heard
On Fri, Mar 20, 2015 at 1:09 PM, Dean Troyer wrote:
> Template is totally the wrong word. It is a host address without a network.
> The prefix is there for the same purpose, to OR it back into a network
> address.
>
> I just want us to stop inventing things that already exist. You want to
> spec
On Fri, Mar 20, 2015 at 1:07 PM, Jay Pipes wrote:
> On 03/20/2015 02:51 PM, Carl Baldwin wrote:
>>
>> On Fri, Mar 20, 2015 at 12:18 PM, Jay Pipes wrote:
>>>
>>> What about this instead?
>>>
>>> POST /v2.0/subnets
>>>
>>>
+1 Would like to hear feedback hoping that deprecation is viable.
Carl
On Fri, Mar 20, 2015 at 12:57 PM, Assaf Muller wrote:
> Hello everyone,
>
> 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/D
On Fri, Mar 20, 2015 at 12:58 PM, Dean Troyer wrote:
>> I thought about doing *s but in the world of Classless Inter-Domain
>> Routing where not all networks are /24, /16, or /8 it seemed a bit
>> imprecise. But, maybe that doesn't matter.
>
>
> So do a CIDR host address: 0.0.0.1/24 can be merge
On Fri, Mar 20, 2015 at 12:18 PM, Jay Pipes wrote:
>> 2) Is the action of creating a subnet from a pool better realized as a
>> different way of creating a subnet, or should there be some sort of
>> "pool action"? Eg.:
>>
>> POST /subnet_pools/my_pool_id/subnet
>> {'prefix_len': 24}
>>
>> which wo
On Fri, Mar 20, 2015 at 12:18 PM, Jay Pipes wrote:
> What about this instead?
>
> POST /v2.0/subnets
>
> {
> 'network_id': 'meh',
> 'gateway_ip_template': '*.*.*.1'
> 'prefix_len': 24,
> 'pool_id': 'some_pool'
> }
>
> At least that way it's clear the gateway attribute is not an IP, but a
>
On Mar 15, 2015 6:42 PM, "Salvatore Orlando"
> * the ML2 plugin overrides several methods from the base "db" class. From
what I gather from unit tests results, we have not yet refactored it. I
think to provide users something usable in Kilo we should ensure the ML2
plugin at least works with the IP
Here is an update from our discussion this morning in IRC [1]. The
discussion involved mainly Pavel, Salvatore, and me.
We first discussed testing the integration of Salvatore's work [2] on
the reference driver with Pavel's work to load a driver [3] and
refactor the db_base_plugin [4]. Pavel wil
On Tue, Mar 10, 2015 at 12:06 PM, Ryan Moats wrote:
> While I'd personally like to see this be restricted (Carl's position), I
> know
> of at least one existence proof where management applications are doing
> precisely what Gabriel is suggesting - reusing the same address range to
> minimize the
On Wed, Mar 11, 2015 at 2:54 PM, John Belamaric wrote:
> I was proposing that the reference driver not support it either, and we
> only handle that use case via the non-pluggable implementation in Kilo,
> waiting until Liberty to handle it in the pluggable implementation.
> However, I don't think
3/12/15, 12:46 AM, "Carl Baldwin" wrote:
>
>
>>When talking with external IPAM to get a subnet, Neutron will pass
>>both the cidr as the primary identifier and the subnet_id as an
>>alternate identifier. External systems that do not allow overlap can
>>
>
On Tue, Mar 10, 2015 at 12:24 PM, Salvatore Orlando wrote:
> I guess that frustration has now become part of the norm for Openstack.
> It is not the first time I frustrate people because I ask to reconsider
> decisions approved in specifications.
I'm okay revisiting decisions. It is just the tim
On Tue, Mar 10, 2015 at 11:34 AM, Gabriel Bezerra
wrote:
> Em 10.03.2015 14:24, Carl Baldwin escreveu:
> I'd vote for allowing against such restriction, but throwing an error in
> case of creating a router between the subnets.
>
> I can imagine a tenant running mult
On Tue, Mar 10, 2015 at 12:53 AM, Miguel Ángel Ajo wrote:
> a) What if the subnet pools go into an external network, so, the gateway is
> predefined and external, we may want to be able to specify it, we could
> assume the convention that we’re going to expect the gateway to be on the
> first IP
On Mon, Mar 9, 2015 at 5:34 PM, Tidwell, Ryan wrote:
> With implicit allocations, the thinking is that this is where a subnet is
> created in a backward-compatible way with no subnetpool_id and the subnets
> API’s continue to work as they always have.
Correct.
> In the case of a specific subnet
dresses between tenants and support the isolation
of these address spaces. The IPAM rework will support this.
Carl Baldwin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@list
Honestly, I'm a little frustrated that this is coming up now when we
tried very hard to discuss this during the spec review and we thought
we got to a resolution. It seems a little late to go back to the
drawing board.
On Mon, Mar 9, 2015 at 7:05 AM, Salvatore Orlando wrote:
> The problem with t
+1
On Mar 4, 2015 12:44 PM, "Kyle Mestery" wrote:
> I'd like to propose that we add Ihar Hrachyshka to the Neutron core
> reviewer team. Ihar has been doing a great job reviewing in Neutron as
> evidence by his stats [1]. Ihar is the Oslo liaison for Neutron, he's been
> doing a great job keeping
jOn Mon, Feb 23, 2015 at 5:07 AM, Salvatore Orlando wrote:
> Lazy-Stacker summary:
> I am doing some work on Neutron IPAM code for IP Allocation, and I need to
> found whether it's better to use db locking queries (SELECT ... FOR UPDATE)
> or some sort of non-blocking algorithm.
> Some measures su
It doesn't support this at this time. There are no current plans to
make it work. I'm curious to know how you would like for this to work
in your deployment.
Carl
On Tue, Feb 24, 2015 at 11:32 AM, NAPIERALA, MARIA H wrote:
> Does Neutron router support ECMP across multiple static routes to the
On Thu, Feb 19, 2015 at 7:45 PM, Mike Bayer wrote:
> So, option “A”, they call engine.dispose() the moment they’re in a fork, the
> activity upon requesting a connection from the pool is: look in pool, no
> connections present, create a connection and return it.
FWIW, this is what Neutron does:
On Thu, Feb 12, 2015 at 6:36 AM, Salvatore Orlando wrote:
> - I agree with Carl that the IPAM driver should not have explicit code paths
> for autoaddress subnets, such as DHCPv6 stateless ones. In that case, the
> consumer of the driver will generate the address and then to the IPAM driver
> that
On Feb 13, 2015 5:54 AM, "Salvatore Orlando" wrote:
> - Considering an alternative to availability ranges. Pre-generation of IP
entries is unpractical (think IPv6), so that's not an option.
Unfortunately, I have not yet explored in detail this route.
The availability range stuff is hard. I was
I must have archived this on accident. Sorry to not respond earlier.
Comments inline...
On Feb 12, 2015 6:40 AM, "Salvatore Orlando" wrote:
> I have updated the patch; albeit not complete yet it's kind of closer to
be an allocator decent enough to replace the built-in logic.
I hope to look at i
On Feb 10, 2015 2:36 AM, "Wilence Yao" wrote:
>
>
> Hi all,
> After OpenStack Juno, floating ip is handled by dvr, but SNAT is still
handled by l3agent on network node. The distributed SNAT is in future plans
for DVR. In my opinion, SNAT can move to DVR as well as floating ip. I have
searched in
On Wed, Jan 28, 2015 at 9:52 AM, Salvatore Orlando wrote:
> The patch Kevin points out increased the lease to 24 hours (which I agree is
> as arbitrary as 2 minutes, 8 minutes, or 1 century) because it introduced
> use of DHCPRELEASE message in the agent, which is supported by dnsmasq (to
> the be
3111
>>
>> Thanks Kevin. I added more info to it, but don't think the patch
>> proposed there
>> is correct. Something in the iptables manager defer_apply() code isn't
>> quite right.
>>
>> -Brian
>>
>>
>>
I think this warrants a bug report. Could you file one with what you
know so far?
Carl
On Wed, Jan 21, 2015 at 2:24 PM, Brian Haley wrote:
> On 01/21/2015 02:29 PM, Xavier León wrote:
>> On Tue, Jan 20, 2015 at 10:32 PM, Brian Haley wrote:
>>> On 01/20/2015 09:20 AM, Xavier León wrote:
Hi
+1
On Thu, Jan 15, 2015 at 3:31 PM, Kyle Mestery wrote:
> The last time we looked at core reviewer stats was in December [1]. In
> looking at the current stats, I'm going to propose some changes to the core
> team. Reviews are the most important part of being a core reviewer, so we
> need to ensu
I added a link to @Jack's post to the ML to the bug report [1]. I am
willing to support @Itsuro with reviews of the implementation and am
willing to consult if you need and would like to ping me.
Carl
[1] https://bugs.launchpad.net/neutron/+bug/1408488
On Thu, Jan 8, 2015 at 7:49 AM, McCann, Ja
On Wed, Jan 7, 2015 at 9:25 PM, Kevin Benton wrote:
> If the new requirement is expressed in the neutron packages for the distro,
> wouldn't it be transparent to the operators?
I think the difficulty first lies with the distros. If the required
new version isn't in an older version of the distro
Miguel,
Thanks again for taking this on. I went looking for the rootwrap
daemon code today in gerrit and found it here [1]. I can allocate
some review cycles to help get this merged early in the cycle. Please
keep us posted on your progress refreshing the code.
Carl
[1] https://review.opensta
Itsuro,
It would be desirable to be able to be hide an agent from scheduling
but no one has stepped up to make this happen. Come to think of it,
I'm not sure that a bug or blueprint has been filed yet to address it
though it is something that I've wanted for a little while now.
Carl
On Mon, Jan
On Tue, Dec 30, 2014 at 11:24 AM, Jeremy Stanley wrote:
> On 2014-12-30 12:31:35 -0500 (-0500), David Kranz wrote:
> [...]
>> 1. This is really a UI issue, and one that is experienced by many.
>> What is desired is an option to look at different revisions of the
>> patch that show only what the au
On Tue, Dec 30, 2014 at 9:37 AM, Jeremy Stanley wrote:
> On 2014-12-30 09:46:35 -0500 (-0500), David Kranz wrote:
> [...]
>> Can some one explain when we should *not* use -R after doing 'git
>> commit --amend'?
> [...]
>
> In the standard workflow this should never be necessary. The default
> beha
The L3 sub team meeting [1] will not be held until the 8th of January,
2015. Enjoy your time off. I will try to move some of the
refactoring patches along as I can but will be down to minimal hours.
Carl
[1] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam
__
On Tue, Dec 16, 2014 at 10:32 AM, Thomas Maddox
wrote:
> Hey all,
>
> It seems I missed the Kilo proposal deadline for Neutron, unfortunately, but
> I still wanted to propose this spec for Neutron and get feedback/approval,
> sooner rather than later, so I can begin working on an implementation, e
We also spent a half day progressing the Ipam work and made a plan to move
forward.
Carl
On Dec 10, 2014 4:16 PM, "Kyle Mestery" wrote:
> The Neutron mid-cycle [1] is now complete, I wanted to let everyone know
> how it went. Thanks to all who attended, we got a lot done. I admit to
> being skep
On Tue, Dec 9, 2014 at 3:33 AM, Miguel Ángel Ajo wrote:
>
> Hi all!
>
> It would be great if you could use this thread to post hot reviews on
> stuff
> that it’s being worked out during the mid-cycle, where others from different
> timezones could participate.
I think we've used the etherpad [1]
> availability.
>
>
>
> Ryan Clevenger
> Manager, Cloud Engineering - US
> m: 678.548.7261
> e: ryan.cleven...@rackspace.com
>
> ________
> From: Carl Baldwin [c...@ecbaldwin.net]
> Sent: Sunday, December 07, 201
For the next few weeks, we'll be tackling L3 agent restructuring [1]
in earnest. This will require some heavy lifting, especially
initially, in the l3_agent.py file. Because of this, I'd like to ask
that we not approve any non-critical changes to the L3 agent that are
unrelated to this restructur
Ryan,
I have been working with the L3 sub team in this direction. Progress has
been slow because of other priorities but we have made some. I have
written a blueprint detailing some changes needed to the code to enable the
flexibility to one day run glaring ups on an l3 routed network [1]. Jaim
+1 I've been meaning to say something like this but never got around
to it. Thanks for speaking up.
On Thu, Dec 4, 2014 at 6:03 PM, Tony Breeds wrote:
> Hello Wiki masters,
> Is there anyway to extend the session length on the wiki? In my current
> work flow I login to the wiki do work and
+1 from me for all the changes. I appreciate the work from all four
of these excellent contributors. I'm happy to welcome Henry and Kevin
as new core reviewers. I also look forward to continuing to work with
Nachi and Bob as important members of the community.
Carl
On Tue, Dec 2, 2014 at 8:59
Don,
Could the spec linked to your BP be moved to the specs repository?
I'm hesitant to start reading it as a google doc when I know I'm going
to want to make comments and ask questions.
Carl
On Thu, Nov 13, 2014 at 9:19 AM, Don Kehn wrote:
> If this shows up twice sorry for the repeat:
>
> Arm
Paul, I worked much of this in to my blueprint [1].
Carl
[1]
https://review.openstack.org/#/c/131535/4/specs/kilo/restructure-l3-agent.rst
On Fri, Nov 21, 2014 at 11:48 AM, Paul Michali (pcm) wrote:
> Hi,
>
> I talked to Carl today to discuss the L3 agent restructuring and the change
> set I h
The Neutron L3 team will meet [1] tomorrow at the regular time. I'd
like to discuss the progress of the functional tests for the L3 agent
to see how we can get that on track. I don't think we need to wait
for the BP to merge before get something going.
We will likely not have a meeting next week
On Tue, Nov 18, 2014 at 7:39 AM, Jeremy Stanley wrote:
> This has come up before... if you don't want to see stale patches
> you can use Gerrit queries or custom dashboards to only show you
> patches with recent activity. If all patches older than some
> specific date get abandoned, then that impa
At the recent summit, we held a session about debt repayment in the
Neutron agents [1]. Some work was identified for the L2 agent. We
had a discussion in the Neutron meeting today about bootstrapping that
work.
The first order of business will be to generate a blueprint
specification for the wor
+1. I always hesitate to abandon someone's patch because it is so
personal. The auto-expire is impersonal and procedural. I agree that
1 week is too soon. Give it at least a month.
Abandoned patches that have some importance shouldn't ever really be
lost. They should be linked to bug reports
On Thu, Nov 13, 2014 at 1:00 PM, Salvatore Orlando wrote:
> No worries,
>
> you get one day off over the weekend. And you also get to choose if it's
> saturday or sunday.
I didn't think it was going to be a whole day.
> Salvatore
>
> On 13 November 2014 20:05, Kevin Benton wrote:
>>
>> December
Reminder that the L3 subteam meeting will be tomorrow at 1500 UTC.
Remember that daylight savings time may have ended since the last
meeting and the meeting will come an hour earlier.
I'd like to talk about the subjects discussed at the summit.
Specifically, we had design sessions about paying dow
Hi Chuck,
I should probably chime in since I made the initial comment in the
first place. I hate to derail the progress you've made with the
blueprint you have up now but this is worth some discussion.
On Wed, Nov 12, 2014 at 3:38 PM, Chuck Carlino wrote:
> It has been proposed that both issues
I don't think I know the precise answer to your question. My best guess is
that floating ips were one of the initial core L3 features implemented
before other advanced services existed. Implementing them in this way may
have been the path of least resistance at the time.
Are you suggesting a cha
https://etherpad.openstack.org/p/odl-neutron-plugin
On Mon, Nov 3, 2014 at 4:05 AM, Richard Woo wrote:
> Hi, what is etherpad link for opendaylight neutron plugin design session?
>
> http://kilodesignsummit.sched.org/event/5a430f46842e9239ea6c29a69cbe4e84#.VFdhdPTF-0E
>
> Thanks,
>
> Richard
>
>
> etherpad[3] to share ideas and agree with session schedule. I propose
> Wednesday afternoon.
>
> If Carl Baldwin is agree, we can talk about it also during the open
> discussion of today's L3 subteam meeting.
>
> [1]: https://review.openstack.org/#/c/125401/
> [
> 2]:
On Tue, Oct 28, 2014 at 3:07 PM, Rohit Agarwalla (roagarwa)
wrote:
> Agreed. The way I'm thinking about this is that tenants shouldn't care what
> the underlying implementation is - L2 or L3. As long as the connectivity
> requirements are met using the model/API, end users should be fine.
> The da
On Tue, Oct 28, 2014 at 2:01 PM, Kevin Benton wrote:
> I think the simplest use case is just that a provider doesn't want to deal
> with extending L2 domains all over their datacenter.
This is similar to a goal behind [1] and [2]. I'm trying to figure
out where the commonalities and differences
I think I'd suggest opening a new bug for FWaaS since it is a
different component with different code. It doesn't seem natural to
extend the scope of this bug to include it.
Carl
On Mon, Oct 27, 2014 at 9:50 AM, Itzik Brown wrote:
>
> - Original Message -
>> From:
On Mon, Oct 27, 2014 at 6:34 AM, Simon Pasquier wrote:
> Hello Itzik,
> This has been discussed lately on this ML. Please see
> https://bugs.launchpad.net/neutron/+bug/1335375.
This is a good example that any create, update, or delete of a SG rule
can expose this issue. This bug only mentions de
On Fri, Oct 24, 2014 at 6:17 AM, Salvatore Orlando wrote:
> Assigning a distinct ct zone to each port sounds more scalable. This should
> keep the number of zones per host
Agree that zones could be a good solution to this problem. +1 to zone
/ port for scalability. Though it will take a bit mor
+1
It would be great to know where to go in the airport and what to ask
for for a good 1 - 1.5 week prepaid GSM data plan.
Carl
On Fri, Oct 24, 2014 at 11:01 AM, Mathieu Gagné wrote:
> On 2014-10-14 11:35 AM, Adrien Cunin wrote:
>>
>> Hi everyone,
>>
>> Inspired by the travels tips published fo
Miguel Ángel,
On Thu, Oct 23, 2014 at 5:56 AM, Miguel Angel Ajo Pelayo
wrote:
> Temporarily removing this entry doesn't seem like a good solution
> to me as we can't really know how long do we need to remove this rule to
> induce the connection to close at both ends (it will only close if any
> n
Hi Elena,
On Thu, Oct 23, 2014 at 4:22 AM, Elena Ezhova wrote:
> Kill the connection using conntrack
>
> The problem here is that it is sometimes impossible to tell which
> connection should be killed. For example there may be two instances running
> in different namespaces that have th
I just had a conflict come up. I won't be able to make it to the meeting.
I wanted to announce that IPAM is very likely topic for a design
session at the summit. I will spend some time reviewing the old
etherpads starting here [1] since the topic was set aside early in
Juno.
Carl
[1] https://e
>
> Thanks,
> Kyle
>
> [1] https://wiki.openstack.org/wiki/NeutronSubTeams
>
> On Mon, Oct 13, 2014 at 2:41 PM, Carl Baldwin wrote:
>> Kyle,
>>
>> This works for me. My only comment is that linking sub team pages
>> from the Neutron meeting page served a du
Kyle,
This works for me. My only comment is that linking sub team pages
from the Neutron meeting page served a dual purpose. It attached it
to the agenda -- which is now deprecated -- and it served as sort of
an anchor for the sub team in to the Neutron team on the wiki. At
least for the L3 sub
The Neutron L3 Subteam will meet tomorrow at the regular time and
place. The agenda and details are posted [1].
I think the RC1 ship will have sailed for most potential fixes by then
so I'd like to take some time during the meeting tomorrow to chat
about the work that is coming up for Kilo. Ther
On Wed, Sep 24, 2014 at 11:05 AM, David Stanek wrote:
>
>
> On Wed, Sep 24, 2014 at 11:42 AM, Dean Troyer wrote:
>>
>> On Tue, Sep 23, 2014 at 5:18 PM, Jay Pipes wrote:
>>>
>>> Yes, I'd be willing to head up the working group... or at least
>>> participate in it.
>>
>>
>> I'll bring an API consu
I have a conflict today. Keep working on RC1.
Carl
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Hi,
Neutron would like to move the distributed virtual router (DVR)
tempest job, currently in the experimental queue, to the check queue
[1]. It will still be non-voting for the time being. Could infra
have a look? We feel that running this on all Neutron patches is
important to maintain the st
Hi,
There is current work in review to use conntrack to terminate these
connections [1][2] much like you suggested. I hope to get this in to
RC1 but it needs another iteration.
For Kilo, I'd like to explore stateless forwarding for floating ips.
Since conntrack is the root of the security issue
I think there could be some discussion about the validity of this as a
bug report vs a feature enhancement. Personally, I think I could be
talked in to accepting a small change to address this "bug" but I
won't try to speak for everyone.
This bug report [1] -- linked by devvesa to the bug report
_ha" condition.
>
> Xu Han
>
>
>
> On 09/04/2014 06:06 AM, Carl Baldwin wrote:
>
> It should be noted that "send_arp_for_ha" is a configuration option
> that preceded the more recent in-progress work to add VRRP controlled
> HA to Neutron's router. The opt
It should be noted that "send_arp_for_ha" is a configuration option
that preceded the more recent in-progress work to add VRRP controlled
HA to Neutron's router. The option was added, I believe, to cause the
router to send (default) 3 GARPs to the external gateway if the router
was removed from on
Kyle,
These are three good ones. I've been reviewing the HA ones and have had an
eye on the other two.
1300 is a bit early but I'll plan to be there.
Carl
On Aug 26, 2014 4:04 PM, "Kyle Mestery" wrote:
> I'd like to propose a meeting at 1300UTC on Thursday in
> #openstack-meeting-3 to discuss
I put this in the review but will repeat it here. +1 to adding the
dependency with the tests that you've written to require it when those
tests have been reviewed and accepted. I don't have an objection to
adding requests-mock as a test-requirement.
Carl
On Fri, Aug 22, 2014 at 12:50 PM, Paul M
The Neutron L3 Subteam will meet tomorrow at the regular time in
#openstack-meeting-3. The agenda [1] is posted, please update as
needed.
Carl
[1] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam#Agenda
___
OpenStack-dev mailing list
OpenSt
Hi all,
This is intended for those readers interested in reviewing and soon
merging the HA routers implementation for Juno. Assaf Muller has
written a blog [1] about this new feature which serves as a good
overview. It will be useful for reviewers to get up to speed and I
recommend reading it be
The Neutron L3 Subteam will meet tomorrow at the regular time in
#openstack-meeting-3. The agenda [1] is posted, please update as
needed.
Carl
[1] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam#Agenda
___
OpenStack-dev mailing list
OpenSt
+1
On Wed, Aug 13, 2014 at 8:05 AM, Kyle Mestery wrote:
> Per this week's Neutron meeting [1], it was decided that offering a
> rotating meeting slot for the weekly Neutron meeting would be a good
> thing. This will allow for a much easier time for people in
> Asia/Pacific timezones, as well as f
kazuhiro MIYASHITA,
I have done a lot of thinking about this. I have a blueprint on hold
until Kilo for Neutron/Designate integration [1].
However, my blueprint doesn't quite address what you are going after
here. An assumption that I have made is that Designate is an external
or internet facin
Apologies for the late notice...
The Neutron L3 Subteam will meet tomorrow at the regular time in
#openstack-meeting-3. The agenda [1] is posted, please update as needed.
Carl
[1] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam#Agenda
___
v).
> It fixed this problem for me.
>
> Regards,
> Alexei
>
>
> On 05/08/14 23:00, Carl Baldwin wrote:
>>
>> Hi,
>>
>> I noticed this yesterday afternoon. I tried to run pep8 and unit
>> tests on a patch I was going to submit. It failed with an error
Hi,
I noticed this yesterday afternoon. I tried to run pep8 and unit
tests on a patch I was going to submit. It failed with an error that
no package satisfying oslo.config could be found [1]. I went to pypi
and saw that the version appears to be available [2] but still
couldn't install it.
I t
I have a spec proposal in play that crosses the Nova/Neutron boundary.
I split it in to two specs: a nova spec [1] and a Neutron spec [2].
There is a little duplication between the two at a high level but not
in the details. Each of the specs references the other at various
spots in the text and
Armando's point #2 is a good one. I see that we should have raised
awareness of this more than we did. The bulk of the discussion and
the development work moved over to the oslo team and I focused energy
on other things. What I didn't realize was that the importance of
this work to Neutron did n
Kyle,
Let me know if I can help resolve the concerns around rootwrap. I
think in this case, the return on investment could be high with a
relatively low investment.
Carl
On Wed, Jul 30, 2014 at 11:52 AM, Kyle Mestery wrote:
> I wanted to send an email to let everyone know where we're at in the
201 - 300 of 400 matches
Mail list logo
