----------
> *From:* Kevin Benton [blak...@gmail.com]
> *Sent:* Thursday, July 30, 2015 4:22 PM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [nova, cinder, neutron] quota-update
> tenant-name bug
>
>
mance of them
> can take the hit.
>
> Thanks,
> Kevin
>
> ----------
> *From:* Kevin Benton
> *Sent:* Wednesday, July 29, 2015 10:44:49 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [nova,
ill the case on master? If not,
> which version of OpenStack addressed that?
>
> Thanks,
> Bruno
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lis
like a non-starter...
>
> Ryan
>
> Kevin Benton wrote on 07/28/2015 02:15:13 AM:
>
> [snip]
>
> > I would rather see something to reference a group of subnets that
> > can be used for floating IP allocation and port creation in lieu of
> > a network ID than the
82-L85
> [5]
> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L78
> [6]
> https://github.com/openstack/neutron/blob/master/neutron/agent/linux/dhcp.py#L293-L302
>
> On Wed, Jul 1, 2015 at 11:28 AM, Shraddha Pandhe <
> spandhe.openst...@gmail.com>
tion in lieu of a network ID
than the technical debt that conditionally redefining a network will bring.
On Mon, Jul 27, 2015 at 8:55 PM, Carl Baldwin wrote:
> On Jul 23, 2015 6:04 PM, "Kevin Benton" wrote:
> >
> > > IOW, I don't think what I
> > proposed in a
If it's a VM, Nova sets the binding host id. That field is set by the
system using the port. It's not a way to move ports around.
On Jul 26, 2015 20:33, "于洁" <16189...@qq.com> wrote:
> Hi all,
>
> Recently I used the parameter binding:host_id to create port, trying to
> allocate the port to a spe
ause the
network actually carries them. If you attach a VM to that network it can
arp for them and all because it is an L2 network.
On Jul 23, 2015 5:09 PM, "Carl Baldwin" wrote:
> On Thu, Jul 23, 2015 at 1:45 PM, Kevin Benton wrote:
> >>We ran in to this long ago.
> >
"Carl Baldwin" wrote:
> On Wed, Jul 22, 2015 at 3:00 PM, Kevin Benton wrote:
> > I proposed the port scheduling RFE to deal with the part about selecting
> a
> > network that is appropriate for the port based on provided hints and
> > host_id. [1]
>
&
s picked for a port I think we
just need to rely on a scheduler filter that limits the migration to where
that network is available.
On Jul 23, 2015 8:28 AM, "Carl Baldwin" wrote:
> On Wed, Jul 22, 2015 at 3:00 PM, Kevin Benton wrote:
> >>It seems to me that the existence of
The issue with the availability zone solution is that we now force
availability zones in Nova to be constrained to network configuration. In
the L3 ToR/no overlay configuration, this means every rack is its own
availability zone. This is pretty annoying for users to deal with because
they have to c
>Ultimately, we need to match up the host scheduled by Nova to the
addresses available to that host. We could do this by delaying
address assignment until after host binding or we could do it by
including segment information from Neutron during scheduling. The
latter has the advantage that we can
rks to handle these scenarios.
Cheers,
Kevin Benton
On 21/07/15 15:45, Salvatore Orlando wrote:
> On 21 July 2015 at 14:21, Neil Jerram <mailto:neil.jer...@metaswitch.com>> wrote:
>
>
> You've probably seen Robert Kukura's comment on the related bug at
>
tatically-configured TOR, where cloud-init
> is used to pass in the (external, unchangeable) VLAN configuration to the
> bare metal instance.
>
> -Deva
>
>
>
>> Unless an operator specifically configures a baremetal node to be vlan
>> trunk.
>>
>> Sam Sto
ged to the VM/bare metal.
On Jul 17, 2015 11:47 AM, "Jim Rollenhagen" wrote:
> On Fri, Jul 17, 2015 at 10:56:36AM -0600, Kevin Benton wrote:
> > Check out my comments on the review. Only Neutron knows whether or not an
> > instance needs to do manual tagging based on th
__
> > 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/op
stent state.
>
> Salvatore
>
>
> On 16 July 2015 at 07:51, Kevin Benton wrote:
>
>> I'm guessing Salvatore might just be suggesting that we restrict users
>> from populating values that have special meaning (e.g. l3 agent router
>> interface ports). I
usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development
search the blueprint about this point in launchpad.net
> , and got nothing, then register one at:
> https://blueprints.launchpad.net/neutron/+spec/security-group-mac-rule
>
>
> ------
> Yan Xing'an
>
>
> *From:* Kevin Benton
> *Date:* 20
rg?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>>
Oh, no I didn't. By the time I got around to it I saw 264 and figured that
would cover the issue.
On Mon, Jul 13, 2015 at 7:33 PM, Robert Collins
wrote:
> On 10 July 2015 at 22:07, Kevin Benton wrote:
> > No prob. The fixes for Neutron were relatively trivial.
> > https://
ions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Kevin Benton
__
OpenStack Development Mailing List (not f
; have a say in what is merged there. Now it should be more in line with
> his actual position in the project.
>
> Good work, Miguel!
>
> On 07/06/2015 01:02 PM, Kevin Benton wrote:
> > Hello!
> >
> > As the Lieutenant of the built-in control plane[1], I am proposin
Thanks for the info. So the equivalent in neutron would be if we just
ensure backward compatible AMQP APIs, right?
On Mon, Jul 13, 2015 at 7:33 AM, Russell Bryant wrote:
> On 07/13/2015 04:09 AM, Kevin Benton wrote:
> >>because you won't have to run Neutron agents on comp
> 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
_
1466ac
>
> https://github.com/Metaswitch/calico/commit/4ecaf3568af52ef9cc29662a3b94672540056f05
>
> But still it seems a shame if this is needed.
>
> Neil
>
>
> On 07/07/15 22:32, Kevin Benton wrote:
>
>> How often does this happen? Is it on every call? If not
anually. I'm hoping we'll have the same for
> Liberty, but I'm not sure if anyone has tried it out recently.
>
> All of the things discussed here sound like good things to work on. I
> actually thought a group was going to work on versioned objects for
> Kilo, but th
10 July 2015 at 20:50, Kevin Benton wrote:
> > Thanks. I didn't realize it was already breaking everything. I thought it
> > might have been stuck in requirements bump patch somewhere.
> >
> >>Thats fixed in 1.1.0. So you should be able to unwind that. If you need a
28 AM, Robert Collins
wrote:
> On 10 July 2015 at 20:23, Kevin Benton wrote:
> > How do we test to see what is failing in each project with the new
> version?
>
> Look at any CI failure in the last 5 hours or so.
>
> Or run tox :).
>
> > Also, I'm responsi
a
non-deterministic order in < py34 which leads to leftover monkey patches.
These caused completely unrelated unit tests to randomly and inexplicably
explode later. More details here:
https://github.com/openstack/neutron/commit/1b60df85ba3ad442c2e4e7e52538e1b9a1bf9378
Cheers,
Kevin Benton
On Fri
a way of checking that there aren't still any open transactions,
> when update_port_postcommit is called?
>
> Thanks,
> Neil
>
>
> On 07/07/15 15:57, Kevin Benton wrote:
>
>> It sounds like something is starting a transaction before calling
>> update_port
ns)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: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.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
/contribution/neutron/60
http://stackalytics.com/report/contribution/neutron/90
--
Kevin Benton
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
x27;s compatible with upstream packages?
>
> > [1] https://review.openstack.org/#/c/195277/
>
> [2] https://gist.github.com/mgagne/e2e06f5a8cb283a81cab
>
> --
> Mathieu
>
> __
> OpenStack Development Mail
ot;
wrote:
>
> On Jun 30, 2015, at 11:22 PM, Kevin Benton wrote:
>
> Hi,
>
> We have had at least two breaking changes merge this week for out-of-tree
> drivers/plugins. These are just the two I noticed that broke the Big Switch
> CI (the one I keep an eye on since I had set it
hird party drivers should basically never import anything
from the neutron namespace.
On Tue, Jun 30, 2015 at 11:58 PM, Ihar Hrachyshka
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 07/01/2015 08:22 AM, Kevin Benton wrote:
> > Hi,
> >
> > We h
lugin maintainers this is just the way things
work?
--
Kevin Benton
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstac
IT Limited
> +64 4 803 2264
> --
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/c
cp/agent.py#L82-L87
> [2]
> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L349
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-re
ugs.launchpad.net/neutron/+bug/1460222
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstac
Hi, creating rbac entries by non-admins will be controlled by policy.json.
So you can enable it or disable it there.
> Also is the action access_as_external available now ?
Not yet. The code is still under review.
On Thu, Jun 25, 2015 at 10:15 AM, Assaf Muller wrote:
> I'll defer to Kevin, the
exactly?,
>
> What are the implications of having this enabled by default?
>
> Cheers,
> Miguel Ángel
>
>
> Kevin Benton wrote:
>
>
> I'd like to resurrect this thread. The patch has been sitting for quite a
> while.
>
> Since it doesn't modify
>> No doubt +1.
>>
>> On 06/12/2015 09:44 PM, Kevin Benton wrote:
>> > Hello!
>> >
>> > As the Lieutenant of the built-in control plane[1], I would like
>> > Rossella Sblendido to be a member of the control plane core
>> > reviewer team
e dhcp opts API or a
config value.
If anyone has any concerns with that, please comment on the patch.
Cheers,
Kevin Benton
On Mon, Apr 20, 2015 at 11:05 AM, Sean M. Collins
wrote:
> Hi,
>
> In the following patch, I had a question about setting the IPXE tag by
> default.
>
>
ote:
>> > Although I am not on your list I would like to add my +1! Yamamoto
>> > shows great attention to detail in code reviews and frequently
>> > finds real issues that were not spotted by others.
>> >
>> > On Thu, Jun 11, 2015, Kevin Benton wrote:
>
Ok. So if I understand it correctly, every update operation we do could
result in a deadlock then? Or is it just ones with "where" criteria that
became invalid.
On Tue, Jun 16, 2015 at 8:58 PM, Carl Baldwin wrote:
> On Tue, Jun 16, 2015 at 5:17 PM, Kevin Benton wrote:
> >
ot spot before
> as we
> > were relying on a sort of implicit locking triggered by the fact that
> some
> > parts of Mysql-Python were implemented in C.
>
> ++
>
> Carl
>
> __
> OpenStack Developmen
I think you will have to contend with DBDeadlock
errors when we switch to the new SQL driver anyway. From what I've
observed, it seems that if someone is holding a lock on a table and you try
to grab it, pymsql immediately throws a deadlock exception.
Cheers,
Kevin Benton
On Thu, Jun 11, 2015
ook something like:
>
> idx = len(gateways) % ip
> gateway = gateways[idx]
>
>
> This is just one idea. I am open to more ideas.
>
>
>
>
> On Thu, Jun 11, 2015 at 3:10 PM, Kevin Benton wrote:
>
>> What gateway address do you give to regular clients via
-group/30
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
What gateway address do you give to regular clients via dhcp when you have
multiple?
On Jun 11, 2015 12:29 PM, "Shraddha Pandhe"
wrote:
>
> Hi,
> Currently, the Subnets in Neutron and Nova-Network only support one
gateway. For provider networks in large data centers, quite often, the
architecture
things in these areas recently so I would like to hear from you
specifically.
1.
http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy
2. http://stackalytics.com/report/contribution/neutron-group/90
Cheers
--
Kevin Benton
395
>
> Thanks,
> --
> Emilien Macchi
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstac
t 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 Development Ma
n Tue, Jun 9, 2015 at 12:33 PM, Carl Baldwin wrote:
> On Mon, Jun 8, 2015 at 3:52 PM, Kevin Benton wrote:
> > There is a bug in security groups here:
> > https://bugs.launchpad.net/neutron/+bug/1359523
> >
> > In the example scenario, it's caused by conntrack
ere anyway).
>
> I think a patch for blanking out those namespace is a great low hanging
> fruit for new contributors.
> But on the other hand I'm pretty sure Kevin is wiping them out as a part
> of the Pecan refactor.
>
> Salvatore
>
> On 9 June 2015 at 20:3
I heard rumors that Oracle was going to introduce XML-as-a-service to
OpenStack to make it enterprise-grade. If that's the case, we'll be ahead
of everyone with our namespaces.
On Jun 9, 2015 12:04 PM, "Brandon Logan"
wrote:
> I believe XML support got removed from the API last cycle.
> _
f-order
notifications might not be any good.
On Tue, Jun 9, 2015 at 3:34 AM, Neil Jerram
wrote:
> On 09/06/15 01:15, Kevin Benton wrote:
>
>> I'm having difficulty reproducing the issue. The bug that Neil
>> referenced (https://bugs.launchpad.net/neutron/+bug/1192381) looks li
of a run when it happens.
Cheers,
Kevin Benton
Here is the patch:
diff --git a/neutron/agent/dhcp_agent.py b/neutron/agent/dhcp_agent.py
index 71c9709..9b9b637 100644
--- a/neutron/agent/dhcp_agent.py
+++ b/neutron/agent/dhcp_agent.py
@@ -71,6 +71,7 @@ class DhcpAgent(manager.Manager):
60cffa60/host
>> >>
>> >>
>> >>
>> --addn-hosts=/var/lib/neutron/dhcp/2fb7de9d-d6df-481f-acca-2f7860cffa60/addn_hosts
>> >>
>> >>
>> >>
>> --dhcp-optsfile=/var/lib/neutron/dhcp/2fb7de9d-d6df-481f-acca-2f7860cffa60/opts
>>
n,
>
> On 8 June 2015 at 23:52, Kevin Benton wrote:
>
>> There is a bug in security groups here:
>> https://bugs.launchpad.net/neutron/+bug/1359523
>>
>> In the example scenario, it's caused by conntrack zones not being
>> isolated. But it also applies to t
gy code to
check for routers and router interfaces to see if two IPs can communicate
without NAT. However, if we end up with the concept of address-scopes, it
just becomes a simple address scope comparison.
Implement address scopes.
Chee
(I just think they're not really made to work
>> together!).
>> Regardless, I did not spent too much time on it, because I thought that
>> the multiple workers code might have been rewritten anyway by the pecan
>> switch activities you're doing.
>>
>
rue
> local_ip = 10.10.3.8
> bridge_mappings = physnet1:br-data
>
> [agent]
> tunnel_types = gre
> l2_population = False
>
>
> [securitygroup]
> firewall_driver =
> neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
> end ml2_conf
state_report thread can't get the control for
> too long, since there is no prioritization of greenthreads.
>
> Eugene.
>
> On Sun, Jun 7, 2015 at 8:24 PM, Kevin Benton wrote:
>
>> I understand now. So the issue is that the report_state greenthread is
>> ju
a server-side involvement, which could
>> actually be a lot of requests saturating the RPC pool.
>>
>> On the other hand, how could we use this theory to explain why this issue
>> tend to occur when the agent is restarted?
>> Also, Eugene, what do you mean by stating that
r email
that implied this break only affects requirements.txt?
On Jun 7, 2015 4:10 PM, "Robert Collins" wrote:
> On 5 June 2015 at 04:54, Kevin Benton wrote:
> > +1. I had setup a CI for a third-party plugin and the easiest thing to
> do to
> > make sure it was running
___
> 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
__
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
GYTcAkGjkM2QmAnS+uoztU5vm4QRkLgGcDCz29eQ5ufA=
> =6bUu
> -END PGP SIGNATURE-
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.or
perhaps it makes sense to have it down until it
> finishes synchronisation.
>
> Salvatore
>
> [1]
> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/agent/l3/agent.py#n587
>
> On 4 June 2015 at 16:16, Kevin Benton wrote:
>
>> Why don't we put the agent hea
Why don't we put the agent heartbeat into a separate greenthread on the
agent so it continues to send updates even when it's busy processing
changes?
On Jun 4, 2015 2:56 AM, "Anna Kamyshnikova"
wrote:
> Hi, neutrons!
>
> Some time ago I discovered a bug for l3 agent rescheduling [1]. When there
>
t; Thanks for your response...
>
> On 08/05/15 08:43, Kevin Benton wrote:
>
>> I'm not sure I understand the behavior you are seeing. When your
>> mechanism driver gets initialized and kicks off processing, all of that
>> should be happening in the parent PID. I don't k
n/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/
is really a simple way to solve the problem of that
> dnsmasq will lose lease if restarted, and we have put this patch to our
> production (public cloud), it works well.
>
> Thanks!
> Wei
>
> 2015-05-28 6:39 GMT+08:00 Kevin Benton :
>
>> >Looking at [1], I don't see
+1
On May 28, 2015 8:44 AM, "Doug Wiegley"
wrote:
> +1
>
> Doug
>
>
> On May 28, 2015, at 7:42 AM, Kyle Mestery wrote:
>
> Folks, I'd like to propose Assaf Muller to be a member of the Neutron core
> reviewer team. Assaf has been a long time contributor in Neutron, and he's
> also recently becom
__
> 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
___
er one up for review. But it doesn't really
matter because the lease DB is the easy way to go.
On Wed, May 27, 2015 at 4:57 AM, Ihar Hrachyshka
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 05/26/2015 11:53 PM, Kevin Benton wrote:
> >> Actually, th
/2015q2/009570.html
On Tue, May 26, 2015 at 3:02 PM, Kevin Benton wrote:
> >As long as we confirm that the severity of this bug is accurately represented
> in the bug report, then this is the first thing we should do. However,
> see below. We tried this and did not encounter the e
evert the stable backports while
> we
> > work on fixing this in the master branch.
>
> I think we can propose the reverts but until we confirm the severity
> of this bug, I don't want them to merge.
>
> Carl
>
> _
ay 2015 at 06:57, Ihar Hrachyshka wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On 05/26/2015 04:35 AM, Kevin Benton wrote:
>> > Hi,
>> >
>> > A recent change[1] to pass '--dhcp-authoritative' to dnsmasq has
>>
ed because I wrote it. :)
It's really up to what you think is cleaner to back-port.
On Tue, May 26, 2015 at 6:57 AM, Ihar Hrachyshka
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 05/26/2015 04:35 AM, Kevin Benton wrote:
> > Hi,
> >
> > A re
s.org.uk/dnsmasq/docs/dnsmasq-man.html
On Mon, May 25, 2015 at 7:44 PM, Doug Wiegley
wrote:
> Option 4, turn off authoritative if we don’t want NAK’s?
>
> doug
>
> On May 25, 2015, at 7:35 PM, Kevin Benton wrote:
>
> Hi,
>
> A recent change[1] to pass '--d
en the second approach is that dnsmasq wouldn't persist
leases to a database.
I'm looking for feedback on how we want to go forward with this in a
back-port friendly manner.
Cheers,
Kevin Benton
1.
https://review.openstack.org/#/q/Ieff0236670c1403b5d79ad8e50d7574c1b694e34,n,z
2. https:/
ck.org?subject: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
Don't forget to pay your tab. This event isn't sponsored! :)
Cheers,
Kevin Benton
On May 17, 2015 1:19 PM, "Kevin Benton" wrote:
> If you didn't get a chance to rsvp, don't worry about it. You don't need
> an rsvp to show up. I was just using it to es
If you didn't get a chance to rsvp, don't worry about it. You don't need an
rsvp to show up. I was just using it to estimate the size of our party.
On May 16, 2015 9:24 PM, "Kevin Benton" wrote:
> Hi everybody!
>
> I got us a place for Monday night at
Hi everybody!
I got us a place for Monday night at 8pm.
Here is the link:
http://www.yelp.com/biz/yaggers-downtown-restaurant-and-sports-bar-vancouver
Don't forget to show up, they are opening the restaurant just for us!
On May 12, 2015 2:16 PM, "Kevin Benton" wrote:
>
_____
> 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 Ben
There isn't anything in neutron at this point that does that. I think the
assumption so far is that you could rate limit at your load balancer or
whatever distributes requests to neutron servers.
On May 14, 2015 5:26 PM, "Tidwell, Ryan" wrote:
> I was batting around some ideas regarding IPAM fun
ack 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
__
would need to
make a reservation for. Then I will announce the location over the weekend
on this same thread.
http://lockwaittimeoutexceeded.rsvpify.com/
Cheers,
Kevin Benton
__
OpenStack Development Mailing List (not for
code that isn't causing problems.
>
> Chris
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://
ribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Kevin Benton
__
OpenStack Development Mailing List (not for usage questions)
m/drivers/neutrondb_ipam/driver.py
> line 50
> [4] http://pastebin.com/n0AqhC5x
> [5] http://pastebin.com/BDBAXFy9
> [6] http://logs.openstack.org/36/153236/
>
> __
> OpenStack Development Mailing List (not f
ubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Kevin Benton
__
OpenStack Development Mailing List (not for usage que
Is it compatible with overlapping IPs? i.e. Will it give two different VMs
the same IP address if the reservations are setup that way?
If not, this approach won't work for many use cases so I think you will
probably just have to write a new DHCP agent that operates in this
distributed fashion.
I h
n the face of what a ton of people are asking and
> >> even begging for. FlatDHCP is perfect for the 80% case. The extra
> >> complexity of the additional things if you don't actually need them
> >> is irresponsible.
> >
> > I think we're at a philosophi
f the deployer/admins.
> > Until you abstract some of that complexity out of the deployment
> > path, either through good coding, useful templates, configuration and
> > management tools, etc., you're going to continue to get pushback from
> > the devops and they will contin
Oh, and what version?
On Apr 18, 2015 7:41 PM, "Kevin Benton" wrote:
> I suspect a refactor or something has caused references to stale data to
> be kept in scope. My proposal to store pictures of cats with each router
> was not accepted so there shouldn't be anything ta
I suspect a refactor or something has caused references to stale data to be
kept in scope. My proposal to store pictures of cats with each router was
not accepted so there shouldn't be anything taking up that much memory. :)
Can you provide some more details to help reproduce the issue?
How many
401 - 500 of 844 matches
Mail list logo
