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
+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
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
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
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
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
_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
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
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
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
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
X 75244
>> >>214.782.7876 direct | bcl...@softlayer.com
>> >>
>> >>
>> >>-Original Message-
>> >>From: Baldwin, Carl (HPCS Neutron) [mailto:carl.bald...@hp.com]
>> >>Sent: Wednesday, August 28, 2013 3:04 PM
>> >&
e.
>
> The error message was still appearing when idle_timeout is set to 1 and the
> quantum API server did not work in my case.
>
> Could you perhaps share your conf file when applying this patch?
>
> Thanks.
>
>
>
> On Thu, Nov 21, 2013 at 3:34 AM, Carl Baldwin wrote:
eekly? I'll go read through the meeting log.
Carl Baldwin
On Thu, Nov 7, 2013 at 11:18 PM, Nachi Ueno wrote:
> Hi folks
>
> let's use #openstack-meeting on the meetings.
>
> I have also created an etherpad for this discussion
> (If you have any slide, p
Stephen, all,
I agree that there may be some opportunity to split things out a bit.
However, I'm not sure what the best way will be. I recall that Mark
mentioned breaking out the processes that handle API requests and RPC
from each other at the summit. Anyway, it is something that has been
discu
Sorry to have taken the discussion on a slight tangent. I meant only
to offer the solution as a stop-gap. I agree that the fundamental
problem should still be addressed.
On Tue, Dec 3, 2013 at 8:01 PM, Maru Newby wrote:
>
> On Dec 4, 2013, at 1:47 AM, Stephen Gran wrote:
>
>> On 03/12/13 16:08
other stop-gap solutions like what Maru
proposed in the original post.
Carl
On Wed, Dec 4, 2013 at 9:12 AM, Ashok Kumaran wrote:
>
>
>
> On Wed, Dec 4, 2013 at 8:30 PM, Maru Newby wrote:
>>
>>
>> On Dec 4, 2013, at 8:55 AM, Carl Baldwin wrote:
>>
>> &g
next logical step to scale. I'll give it
some thought today and possibly create a blueprint.
Carl
On Thu, Dec 5, 2013 at 7:13 AM, Maru Newby wrote:
>
> On Dec 5, 2013, at 6:43 AM, Carl Baldwin wrote:
>
>> I have offered up https://review.openstack.org/#/c/60082/ a
current upstream. I confirmed that with
current upstream code and the ML2 plugin only the parent process
consumes RPC messages. It is probably because this environment is
still using an older version of my multi-process API worker patch.
Still looking in to it.
Carl
On Thu, Dec 5, 2013 at 7:32 AM,
I think there may be some confusion between the two concepts: subnet
and allocation pool. You are right that an ipv4 subnet smaller than
/30 is not useable on a network.
However, this method is checking the validity of an allocation pool.
These pools should not include room for a gateway nor bro
ith a subnet of 255.255.255.255, so it got
> through somehow. I will look into that more tomorrow.
>
>
>
> Carl Baldwin wrote on 01/21/2014 05:27:49 PM:
>
> > From: Carl Baldwin
> > To: "OpenStack Development Mailing List (not for usage questions)"
> >
of the subnet.
>
>
>
> Carl Baldwin wrote on 01/21/2014 09:22:55 PM:
>
>> From: Carl Baldwin
>> To: OpenStack Development Mailing List
>> ,
>> Date: 01/21/2014 09:27 PM
>
>
>> Subject: Re: [openstack-dev] [neutron] Neutron should disallow /32 CIDR
I think I agree. The new check isn't adding much value and we could
debate for a long time whether /30 is useful and should be disallowed
or not. There are bigger fish to fry.
Carl
On Fri, Jan 24, 2014 at 10:43 AM, Paul Ward wrote:
> Given your obviously much more extensive understanding of ne
I have looked at the code that you posted. I am concerned that there
are db queries performed inside nested loops. The approach looks
sound from a functional perspective but I think these loops will run
very slowly and increase pressure on the db.
I tend to think that if a router has an extra rou
Paul,
I'm interesting in joining the discussion. UTC-7. Any word on when
this will take place?
Carl
On Mon, Feb 3, 2014 at 3:19 PM, Paul Michali wrote:
> I'd like to see if there is interest in discussing vendor plugins for L3
> services. The goal is to strive for consistency across vendor
>
Hi,
Good find. This looks like a duplicate of a bug that is in progress
[1]. Stephen Ma has a review up that addresses it [2].
Carl
[1] https://bugs.launchpad.net/neutron/+bug/1244853
[2] https://review.openstack.org/#/c/57954
On Thu, Feb 13, 2014 at 1:19 AM, shihanzhang wrote:
> Howdy folks
Aaron,
I was thinking the same thing recently with this patch [1]. Patch
sets 1-5 should have failed for any plugin besides ml2 yet some passed
and I wondered how that could happen. Kudos to those patches that
failed my patch sets correctly.
Carl
[1] https://review.openstack.org/#/c/72565/
On
Assaf,
It would be helpful if these notes were on the reviews [1]. I think
there are concerns in this email that I have not noticed in the
review. Maybe I missed them.
Carl
[1] https://blueprints.launchpad.net/neutron/+spec/l3-high-availability
On Mon, Feb 24, 2014 at 8:58 AM, Assaf Muller
Brian,
In shell it is correct to return 0 for success and non-zero for failure.
Carl
On Feb 26, 2014 10:54 AM, "Brian Haley" wrote:
> While trying to track down why Jenkins was handing out -1's in a Neutron
> patch,
> I was seeing errors in the devstack tests it runs. When I dug deeper it
> lo
Nachi,
Great! I'd been meaning to do something like this. I took yours and
tweaked it a bit to highlight failed Jenkins builds in red and grey
other Jenkins messages. Human reviews are left in blue.
javascript:(function(){
list = document.querySelectorAll('td.GJEA35ODGC');
for(i in lis
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
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
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
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
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
+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
+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
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
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
> 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
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]
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 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
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 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
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
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
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
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
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
+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 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
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
>>
>>
>>
Kyle,
Could you point to any information about the "pod" area? I would like
to do something with the DNS discussion. Will this area be
schedulable or first-come-first-served?
Carl
On Fri, Apr 25, 2014 at 7:17 AM, Kyle Mestery wrote:
> Hi everyone:
>
> I've pushed out the Neutron Design Summit
e flesh it out.
Carl Baldwin
Neutron L3 Subteam
[1] http://summit.openstack.org/cfp/details/403
[2] https://blueprints.launchpad.net/neutron/+spec/internal-dns-resolution
[3] https://blueprints.launchpad.net/nova/+spec/internal-dns-resolution
[4] https://blueprints.launchpad.net/neutron/+spec/ex
on in Atlanta
[2].
Cheers,
Carl Baldwin
Neutron L3 Subteam
[1] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam
[2] https://etherpad.openstack.org/p/juno-dns-neutron-nova-designate
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstac
.e. only at the qg-* interface within the
> Namespace router (NAT46 will happen here)), so, the old internet
> infrastructure will be able to reach a IPv6-Only project subnet using a well
> know FQDN DNS IPv4 entry...
>
> Best!
> Thiago
>
>
> On 29 April 2014 17:09, Carl
Is there a map, a list, or some other official reference? I may like
to use a pod for a cross-project discussion about DNS between Nova,
Neutron, and Designate. Not a big deal but it might be nice to know
more about what we're looking for when we get there.
Thanks,
Carl
On Tue, May 6, 2014 at 6
his in the
discussion then that may work out well.
Thanks,
Carl
[1] https://etherpad.openstack.org/p/juno-dns-neutron-nova-designate
[2] https://etherpad.openstack.org/p/DesignateAtlantaDesignSession
On Tue, May 6, 2014 at 8:58 AM, Joe Mcbride wrote:
>
> On 4/29/14, 3:09 PM, "Carl Baldwi
Vishal,
I have not yet had the chance to try to replicate this bug in my
environment. Will you file this as a bug? Gateway IPs on external
networks don't change much. In most environments there is never a
need to change the IP. However, if the API does not have a constraint
to prevent the cha
Tomorrow's meeting will be at 1500 UTC in #openstack-meeting-3. The
current agenda can be found on the subteam meeting page [1].
We will not hold a meeting next week during the summit.
Carl Baldwin
Neutron L3 Subteam
[1] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam#A
can this now be done on the backend somehow?
>
> On Tue, Mar 04, at 4:00 pm, Carl Baldwin wrote:
>
>> Nachi,
>>
>> Great! I'd been meaning to do something like this. I took yours and
>> tweaked it a bit to highlight failed Jenkins builds in red and grey
>
rning, and later on in the afternoon on Monday, if that
> suits.
>
> Graham
>
> On Tue, 2014-05-06 at 11:21 -0600, Carl Baldwin wrote:
>
>
> I have just updated my etherpad [1] with some proposed times. Not
> knowing much about the venue, I could only propose the &q
tyle.color='red'
> } else if(title.innerHTML.search('Jenkins|CI|Ryu|Testing|Mine')
>>= 0) {
> title.style.color='#66'
> } else {
> title.style.color='blue'
> }
> }
> })()
>
&
There was a question during my summit session on Friday at 4:00 about
providing diagrams. There are diagrams in the specification [2] that
show where IP addresses are used in the various external network
schemes. The first diagram, almost half-way down, shows the current
method which uses public
potential improvements to the current IPAM implementation in
Neutron. Please review the etherpad [2] from the pod discussion and
come join us at the meeting.
Carl Baldwin
Neutron L3 Subteam
[1] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam#Agenda
[2] https://etherpad.openstack.org/
Sławek,
There is some grass roots interest in improved IPAM within Neutron. This
feature of which you speak could be proposed as part of -- or a follow-on
to -- that work.
I have added this subject to the L3 subteam agenda [2] for tomorrow's
meeting as I announced earlier today [1]. There is a lo
If an IP is reserved for a tenant, should the tenant need to
explicitly ask for that specific IP to be allocated when creating a
floating ip or port? And it would pull from the regular pool if a
specific IP is not requested. Or, does the allocator just pull from
the tenant's reserved pool wheneve
Hi,
I found this message in my backlog from when I was at the summit.
Sorry for the delay in responding.
The "default SNAT" or "dynamic SNAT" use case is one of the last
details being worked in the DVR subteam. That may be why you do not
see any code around this in the patches that have been sub
;
>
>
> It's perhaps time we look at the patch and merge it. PUT on allocation pools
> have been a #TODO for about 2 years now!
>
>>
>>
>> thanks! marios
>>
>> [1] https://review.openstack.org/#/c/62042/
>>
>> >
>> > Mohammad
>
Paul,
On Fri, May 23, 2014 at 8:24 AM, Paul Michali (pcm) wrote:
> Hi,
>
> I’m working on a task for a BP to separate validation from persistence logic
> in L3 services code (VPN currently), so that providers can override/extend
> the validation logic (before persistence).
>
> So I’ve separated t
s review
>> stats for the past 90 days do not line up with current cores, and his
>> participation in general has dropped off. So I am proposing his
>> removal from neutron-core.
>>
>> Since we're losing a core team member, I'd like to propose Carl
>>
in-between
> (implied by the naming). The latter makes it clearer what the service driver
> is doing before and after. In both cases, the ABC for the service driver
> (VpnDriver) could have the default validation/precommit actions, and the
> service driver (IPsecVPNDriver) could opti
Does this make sense in Neutron? In my opinion it doesn't.
DNSaaS is external to Neutron and is independent. It serves DNS
requests that can come from the internet just as well as they can come
from VMs in the cloud (but through the network external to the cloud).
It can serve IPs for cloud res
e in the Network program. I'm getting
> suspicious of the programs for projects model if every new project
> incubating in seems to need a new program. Which isn't really a
> reflection on designate, but possibly on our program structure.
>
> -Sean
>
> On 05/28/2
ugh the non-DVR topics [1] first and then use the
remainder of the meeting for DVR.
Please double check your actions items from last week's meeting [2].
Carl Baldwin
Neutron L3 Subteam
[1] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam#Agenda
[2]
http://eavesdrop.openstack.org/meet
That is what I was not sure about, if they are currently one in the same.
Thanks for the link.
Carl
On May 28, 2014 2:47 PM, "Hayes, Graham" wrote:
> Sorry - not sure what happened there - as I was saying:
>
> The "Networking Program" is Neutron.
>
> https://wiki.openstack.org/wiki/Programs
>
>
>
> I am available for review/technical discussion/meeting.
>
>
>
>
>
> Thanks & regards,
>
> Keshava.A
>
>
>
> *From:* jcsf31...@gmail.com [mailto:jcsf31...@gmail.com]
> *Sent:* Thursday, May 29, 2014 9:14 AM
> *To:* openstack-dev@lists.opensta
This is very similar to IPAM... There is a space of possible ids or
addresses that can grow very large. We need to track the allocation
of individual ids or addresses from that space and be able to quickly
come up with a new allocations and recycle old ones. I've had this in
the back of my mind
l,
>
> The idea of in-memory storage was discussed for similar problem, but might
> not work for multiple server deployment.
> Some hybrid approach though may be used, I think.
>
> Thanks,
> Eugene.
>
>
> On Fri, May 30, 2014 at 8:53 PM, Carl Baldwin wrote:
>>
&
+1. After reading through this thread, I think that a blind --retries
N could be harmful and unwise given the current API definition. Users
that need a retry for an SSL error are going to get in to the habit of
adding --retries N to all their calls and they'll end up in trouble
because they reall
Paul,
I'm curious. Have you been able to update to a client using requests?
Has it solved your problem?
Carl
On Thu, May 29, 2014 at 11:15 AM, Paul Ward wrote:
> Yes, we're still on a code level that uses httplib2. I noticed that as
> well, but wasn't sure if that would really
> help here as
How does ovs handle tcp flows? Does it include stateful tracking of tcp --
as your wording below implies -- or does it do stateless inspection of
returning tcp packets? It appears it is the latter. This isn't the same
as providing a stateful ESTABLISHED feature. Many users may not fully
underst
Chuck,
I accidentally uploaded by local.conf changes to gerrit [1]. I
immediately abandoned them so that reviewers wouldn't waste time
thinking I was trying to get changes upstream. But, since they're up
there now, you could take a look.
I am currently running a multi-node devstack on a couple
when I clone devstack on my test machine, or when I browse
> https://github.com/openstack-dev/devstack/blob/master/samples/local.conf.
> I'm not referring to your changes, just the base code.
>
> Chuck
>
>
> On Jun 3, 2014, at 1:55 PM, Carl Baldwin
> mailto:c...@ec
IPAM stuff to discuss as well.
Carl Baldwin
Neutron L3 Subteam
[1] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam#Agenda
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ng it would be a separate process that would communicate over
> the RPC channel or something.
> memcached?
>
> Eugene.
>
>
> On Sat, May 31, 2014 at 2:27 AM, Carl Baldwin wrote:
>
>> Eugene,
>>
>> That was part of the "whole new set of complications" t
aster.
> Need to do a little bit more testing with real backends to make sure
> parameters are optimal.
>
> Thanks,
> Eugene.
>
>
> On Thu, Jun 5, 2014 at 12:29 AM, Carl Baldwin wrote:
>>
>> Yes, memcached is a candidate that looks promising. First things fir
Yes, I was able to book it for $114 a night with no prepayment. I had
to call. The agent found the block under Cisco and the date range.
Carl
On Wed, Jun 4, 2014 at 4:43 PM, Kyle Mestery wrote:
> I think it's even cheaper than that. Try calling the hotel to get the
> better rate, I think Carl
I have seen the Ryu team is involved and responsive to the community.
That goes a long way to support it as the reference implementation for
BPG speaking in Neutron. Thank you for your support. I'll look
forward to the API and documentation refinement
Let's be sure to document any work that need
I have it on my list to review today. Thanks, Paul.
Carl
On Fri, Jun 6, 2014 at 9:11 AM, Paul Michali (pcm) wrote:
> https://review.openstack.org/#/c/88406/
>
> Thanks!
>
>
> PCM (Paul Michali)
>
> MAIL …..…. p...@cisco.com
> IRC ……..… pcm_ (irc.freenode.com)
> TW ………... @pmichali
> GPG Key … 4
We'll meet tomorrow at the regular time in #openstack-meeting-3. The
agenda [1] is posted.
Carl Baldwin
Neutron L3 Subteam
[1] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam#Agenda
___
OpenStack-dev mailing list
OpenStac
A sprint in Lisbon sounds very good to me. I lived a while in Portugal and
Portuguese is my second language.
This is very short notice so it is probably not possible for me to make it
during this cycle. Don't count on me but if an event is scheduled in
Lisbon, I'd certainly want to give it a try
+1
On Fri, Mar 7, 2014 at 2:42 AM, Édouard Thuleau wrote:
> +1
> I though it must merge as experimental for IceHouse, to let the community
> tries it and stabilizes it during the Juno release. And for the Juno
> release, we will be able to announce it as stable.
>
> Furthermore, the next work, wi
e failing line + result code. I'm
>> not sure if we rely on stdout/stderr results at any time.
>>
>
> This is exactly one of the items Carl Baldwin has been investigating. Have
> you checked out his early work? [1]
>
> mark
>
> [1] https://review.openstack.org/#
All,
I was writing down a summary of all of this and decided to just do it
on an etherpad. Will you help me capture the big picture there? I'd
like to come up with some actions this week to try to address at least
part of the problem before Icehouse releases.
https://etherpad.openstack.org/p/ne
Tomorrow's meeting will be at 1500 UTC in #openstack-meeting-3. The
current agenda can be found at
https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam#Agenda
Watch out for your local daylight savings time shifts.
Carl
___
OpenStack-dev mailing
Right, the L3 agent does do this already. Agreed that the limiting
factor is the cumulative effect of the wrappers and executables' start
up overhead.
Carl
On Thu, Mar 13, 2014 at 9:47 AM, Brian Haley wrote:
> Aaron,
>
> I thought the l3-agent already did this if doing a "full sync"?
>
> _sync_
1 - 100 of 400 matches
Mail list logo
