I tend to agree that when the gate for a project is broken, nothing should
be merged for that project until the gate jobs are green again.
In the case of Neutron, making the job non voting only caused more bugs to
slip through, and that meant more works for the developer themselves, and
more headac
Hi Rudra,
In this blueprint what would be the plan for Neutron?
>From the specification it seems the scope is not limited to nova-network,
but includes Neutron as well, so you probably have a plan to forward the
VPC calls to Neutron.
The question here is whether you've considered implementing the
Hi,
I've been trying to spend some time adding a few (hopefully) useful test
scenarios for neutron.
I have never commited anything into tempest, so I would appreciate any
feedback on the approach I am taking.
I have the following goals:
1) enable test_006_check_tenant_network_connectivity for neu
As I said during the meeting, I am happy to support both as long as the
code churn is reasonably contained and the chances of strongswan support
introducing bugs into openswan driver are negligible.
Openswan should be the default solution, in muy opinion.
Salvatore
On 20 August 2013 00:15, Nach
The full suite of neutron tests is non voting; your jenkins job is failing
because of unit tests.
The reason for this failure, I believe, is the inability of querying
neutron ports by IP using a regex.
There is a blueprint for that already registered: allow filters to use
'like' operation of
sqlal
Hi,
We are removing the schema autogeneration capability from Neutron [1].
The patch however did not pass Torpedo tests on Smokestack; looking at the
logs it seems Firestack deploys Neutron but the db is empty, which is
consistent with firestack leveraging schema auto-generation capabilities.
I'
I am not entirely sure that any of the open source plugins available in the
neutron source tree currently provides the ability of ensuring security
groups through OVS flow management.
But I might be missing some out-of-tree plugin, of which I have little to
no knowledge.
To answer the initial ques
whenever I run devstack keystone falies to start because dogpile.cache is
not installed; this is easily solved by installing it, but I wonder if it
should be in requirements.txt
Also, since the cache appears to be disabled by default (and I'm not
enabling it in my localrc), I'm not sure why I am hi
Is the cache module enabled on the devstack gate? If not, it's definetely
an issue on my side - otherwise we would have known about this.
Salvatore
On 4 September 2013 15:23, Dolph Mathews wrote:
>
> On Wed, Sep 4, 2013 at 9:14 AM, Salvatore Orlando wrote:
>
>> whe
This plan makes a lot of sense to me.
With the staggering number of sub-projects in neutron it is impossible for
the stable team to cope with the load. Delegation and decentralisation is a
must and both sub-project maintainers and the stable team will benefit from
it.
Also, since patches can always
Regarding Jay's proposal, this would be tantamount to defining an API
action for retrieving instances, something currently being discussed here
[1].
The only comment I have is that I am not entirely surely whether using the
POST verb for operations which do no alter at all the server representation
Inline,
Salvatore
On 4 November 2015 at 15:11, Cory Benfield wrote:
>
> > On 4 Nov 2015, at 13:13, Salvatore Orlando
> wrote:
> >
> > Regarding Jay's proposal, this would be tantamount to defining an API
> action for retrieving instances, something currently bei
Arbitrary blobs are a powerful tools to circumvent limitations of an API,
as well as other constraints which might be imposed for versioning or
portability purposes.
The parameters that should end up in such blob are typically specific for
the target IPAM driver (to an extent they might even identi
It makes sense to have a single point were response pagination is made in
API processing, rather than scattering pagination across Nova REST
controllers; unfortunately if I am not really able to comment how feasible
that would be in Nova's WSGI framework.
However, I'd just like to add that there i
f any stakeholder.
If these information are needed for making scheduling decisions based on
network requirements, then it makes sense to expose this information also
at the API layer (I assume there also plans for making the scheduler
*seriously* network aware). However, this information
I only have some historical, anecdotal, and rapidly waning memory of
previous releases.
Nevertheless my feeling is that the process has been a success so far.
In past times it would not have been a surprise if a bug fell under the
radar until that well known brownish matter hit the proverbial fan.
The Neutron API dropped XML support quite some time ago.
Therefore specifying --request-format xml already produces an error.
Even if this parameter is already vestigial and should be abruptly
removed. We don't know whether anyone is using it. For instance one could
have a set of scripts that expl
Neutron has the ability already of sending an event as a REST call to
notify a third party that a port became active [1]
This is used by Nova to hold on booting instances until network has been
wired.
Perhaps kuryr could leverage this without having to tap into the AMQP bus,
as that would be implem
As for the notifier proposed above it is correct that neutron needs to be
changed. This should not be a massive amount of work. Today it works with
nova only pretty much because nova it's the only compute service it
interacts with.
The question brought aboud ping vs operational status is a very go
Hey! This sounds like bike-shedding & yak-shaving... totally my thing!
It is true that the Neutron model currently kind of forces a two-level
topology, with the external network being a sort of special case.
Regardless, this does not mean you cannot assign directly public IPs to
your instances - N
For what is worth neutron employs "resource trackers" which conceptually do
something similar to nova quota usage statistics.
Before starting any transaction that can potentially change usage for a
given resource, the quota enforcement mechanism checks for a "dirty" marker
on the resource tracker.
On 12 April 2016 at 15:48, Andrew Laski wrote:
>
>
> On Tue, Apr 5, 2016, at 09:57 AM, Ryan McNair wrote:
> > >It is believed that reservation help to to reserve a set of resources
> > >beforehand and hence eventually preventing any other upcoming request
> > >(serial or parallel) to exceed quota
On 21 April 2016 at 16:54, Boden Russell wrote:
> On 4/20/16 3:29 PM, Doug Hellmann wrote:
> > Yes, please, let's try to make that work and contribute upstream if we
> > need minor modifications, before we create something new.
>
> We can leverage the 'retrying' module (already in global requirem
There is a job which has been turned on again by mistake and I'm working on
ensuring it's put to sleep again (for good this time).
If you can avoid disabling the whole account it would be great as the same
credentials are used by the still-voting nova CI.
Cheers,
Salvatore
On 3 May 2016 at 10:47
The point raised by Matt for Nova applies to Neutron as well.
Neutron does not have strict deadlines for blueprint approval; however even
if in theory it would still be possible to achieve this for Mitaka, it is
rather unlikely since the number of blueprints already in the pipeline is
way more than
I tend to agree with Doug and Ryan's stance. If you need to pass 1000s of
network-id on a single request you're probably not doing things right on
the client side.
As Ryan suggested you can try and split the request in multiple requests
with acceptable URI lenght and send them in parallel; this wil
ost
> libraries just drop the payload for such cases.
>
Nevertheless, we're pretty much in control of that. We've already discussed
this, and doing so does not violate RFC7231, so it's ok from a protocol
perspective.
If needed, we can tweak the API request processing workflow for al
I agree with Armando that at the end of the day user requirements should
drive these decisions.
I think you did a good job in listing what are the pro and the cons of
choosing standalone plugin rather than a ML2 driver.
The most important point you made, in my opinion, concerns the ability of
supp
On 5 February 2016 at 04:12, Armando M. wrote:
>
>
> On 4 February 2016 at 08:22, John Belamaric
> wrote:
>
>>
>> > On Feb 4, 2016, at 11:09 AM, Carl Baldwin wrote:
>> >
>> > On Thu, Feb 4, 2016 at 7:23 AM, Pavel Bondar
>> wrote:
>> >> I am trying to bring more attention to [1] to make final d
On 5 February 2016 at 17:58, Neil Jerram wrote:
> On 05/02/16 16:31, Pavel Bondar wrote:
> > On 05.02.2016 12:28, Salvatore Orlando wrote:
> >>
> >>
> >> On 5 February 2016 at 04:12, Armando M. >> <mailto:arma...@gmail.com>> wrote:
> &
The difference lies in the process in my opinion.
If the switch is added into the migration path then we will tell operators
when to switch.
I was suggesting doing it manual because we just don't know if every
operator is happy about doing the switch when upgrading to Newton, but
perhaps it is just
Some comments inline.
Salvatore
On 6 July 2015 at 20:00, Paul Michali wrote:
> Hi,
>
> I have some urgent requests about migration that I'm hoping to get some
> info on. I'm working on a bug where I need to add two (related) fields to a
> table for VPNaaS. Here's the objectives related to migra
On 7 July 2015 at 14:00, Paul Michali wrote:
> Thanks Salvatore for the responses. See @PCM in-line...
>
>
>
> On Tue, Jul 7, 2015 at 6:14 AM Salvatore Orlando
> wrote:
>
>> Some comments inline.
>>
>> Salvatore
>>
>> On 6 July 2015 at 20:00,
et). Since the new code will rely on
>> these new fields, I'd like to populate them as part of the migration. I
>> think it would be more complicated to handle during operation.
>>
>> Does anyone have examples of how to do queries of objects, from the
>> migration up
I agree and I would make the switch as soon as possible. The graphite graph
you posted showed that since 6/28 the difference in failure rate is such
that isn't even statistically significant. However, spikes in failure rates
of the unstable job also suggest that you're starting to chase a moving
ta
Some pedant comments inline.
Salvatore
On 13 July 2015 at 23:29, Russell Bryant wrote:
> On 07/13/2015 05:08 PM, Kevin Benton wrote:
> > Thanks for the info. So the equivalent in neutron would be if we just
> > ensure backward compatible AMQP APIs, right?
>
> There's a few parts:
>
> 1) Backwar
Yes please.
This would be a good starting point.
I also think that the ability of editing it, as well as the value it could
be set to, should be constrained.
As you have surely noticed, there are several code path which rely on an
appropriate value being set in this attribute.
This means a user c
Some comments inline.
Salvatore
On 15 July 2015 at 10:24, Alex Xu wrote:
>
>
> 2015-07-15 5:14 GMT+08:00 Matt Riedemann :
>
>>
>>
>> On 7/14/2015 3:43 PM, Cale Rath wrote:
>>
>>> Hi,
>>>
>>> I created a patch to fail on the proxy call to Neutron for used limits,
>>> found here: https://review.o
Do you reckon that the process that led to creating a migration like [1]
should also be documented in devref?
That might be helplful for developers, unless that process is already
documented elsewhere.
Salvatore
[1] https://review.openstack.org/#/c/202013/1
On 15 July 2015 at 15:54, Mike Bayer
It is not possible to constrain this attribute to an enum, because there is
no fixed list of device owners. Nevertheless it's good to document know
device owners.
Likewise the API layer should have checks in place to ensure accidental
updates to this attributes do not impact control plane function
A few comments inline.
Generally speaking the only thing I'd like to remark is that this use case
makes sense independently of whether you are using overlay, or any other
"SDN" solution (whatever SDN means to you).
Also, please note that this thread is now split in two - there's a new
branch star
For my low-orbit perspective (I would have lied if I said 10,000 or 30,000
ft!) Kuryr's ultimate goal is to provide:
1) a container-oriented set of neutron plugins and drivers (you know the
ML2 driver, a l3 svc plugin, a lbaas driver, etc. etc.)
2) possibly (I'm not sure if that's the case) control
To the best of my knowledge Neutron is unable to enforce tenant quotas
using the tenant name; this should be "undocumented".
What Kevin suggests also goes in this direction, even if we have to be
careful as we're making assumptions on how tenant ids are represented (if
the deployment is not using K
More comments inline.
Salvatore
On 31 July 2015 at 01:47, Kevin Benton wrote:
> The issue is that the Neutron credentials might not have privileges to
> resolve the name to a UUID. I suppose we could just fail in that case.
>
>
As quota-update is usually restricted to admin users this should no
Kyle,
I can speak very little about the QoS branch, but from what I gather it is
mature enough to be merged back.
However, I believe the Pecan work is still incomplete as we need a solution
to run the RPC over AMQP server independently. Once we have that we can
start merging back what we have.
Sa
I have been hit by these failures as well.
I think you did well by bumping out that revert from the queue; I think it
simply cures the sympton possibly affecting correct operations of the
firewall service.
If we are looking at removing the sympton on the API job, than I'd skip the
failing tests whi
On 13 August 2015 at 09:50, John Garbutt wrote:
> On Wednesday, August 12, 2015, Thierry Carrez
> wrote:
>
>> Gary Kotton wrote:
>> >
>> > On 8/12/15, 12:12 AM, "Mike Perez" wrote:
>> >> On 15:39 Aug 11, Gary Kotton wrote:
>> >>> On 8/11/15, 6:09 PM, "Jay Pipes" wrote:
>> >>>
>> Are you s
my 0.02€ on the matter inline.
Regards,
Salvatore
On 18 August 2015 at 23:45, Mathieu Rohon wrote:
> hi brandon,
>
> thanks for your answer.
>
> my answers inline,
>
>
>
> On Tue, Aug 18, 2015 at 8:53 PM, Brandon Logan <
> brandon.lo...@rackspace.com> wrote:
>
>> So let me make sure I understa
The etherpad contains some complaints around DVR implementation that might
deserve furhter exploration.
However, as pointed out by Jay, the comments made leave very little room
for actionable items.
It would be great if the author(s) could fill in with more details.
Salvatore
On 19 August 2015 at
Hi Gal,
even if I've been a lurker so far, I'm interested in attending for learning
and contributing to it with my massive bug-injecting skills!
You said "virtual sprint" and "somewhere in september" - I think
"somewhere" refers to dates?
Anyway I am pretty much open to any date from September 7t
On 28 August 2015 at 16:57, Sean Dague wrote:
> On 08/28/2015 11:20 AM, Assaf Muller wrote:
> > To recap, we had three issues impacting the gate queue:
> >
> > 1) The neutron functional job has had a high failure rate for a while
> > now. Since it's impacting the gate,
> > I've removed it from th
currently in base.py
./neutron/newapi/hooks/ownership_validation.py:34: #
TODO(salvatore-orlando): consider whether this check can be folded
./neutron/newapi/app.py:40:#TODO(kevinbenton): error templates
./neutron/newapi/controllers/root.py:150:# TODO(kevinbenton): allow
fields a
It sounds like indeed that easyOVS covers what you're aiming too.
However, from what I gather there is still plenty to do in easy OVS, so
perhaps rather than starting a new toolset from scratch you might build on
the existing one.
Personally I'd welcome its adoption into the Neutron stadium as deb
f, or both.
Salvatore
On 22 September 2015 at 04:25, Ganesh Narayanan (ganeshna) <
ganes...@cisco.com> wrote:
> Another project for diagnosing OVS in Neutron:
>
> https://github.com/CiscoSystems/don
>
> Thanks,
> Ganesh
>
> From: Salvatore Orlando
> Reply-To: OpenStack
Random comments inline.
Salvatore
On 24 September 2015 at 14:05, Russell Bryant wrote:
> On 09/24/2015 01:17 AM, Amitabha Biswas wrote:
> > Hi everyone,
> >
> > I want to open up the discussion regarding how to support OVN
> > VTEP gateway deployment and its lifecycle in Neutron.
>
> Thanks a l
Or, since many OpenStack projects now use Pecan, we could fix this
ourselves as a thank you note to Pecan developers!
Salvatore
On 1 October 2015 at 21:08, Ryan Petrello
wrote:
> Yep, this definitely looks like a Python3-specific bug. If you'll open a
> ticket, I'll take a look as soon as I ge
Inline,
Salvatore
On 12 October 2015 at 10:23, Germy Lure wrote:
> Thank you, Kevin.
> So the community just divided the whole openstack into separate
> sub-projects(Nova,Neutron and etc.) but it's not taken into account that if
> those modules can work together with different versions. Yes?
>
Inline,
Salvatore
On 12 October 2015 at 09:29, Germy Lure wrote:
> Hi Kevin,
>
> *Thank you for your response. Periodic data checking is a popular and
> effective method to sync info. But there is no such a feature in Neutron.
> Right? Will the community merge it soon? And can we consider it wit
Hi Germy,
It seems that you're looking at solutions for ensuring consistency between
the "desired" configuration (Neutron), and the actual one (whatever is in
your backend) at startup.
This has been discussed several times in the past - not just for
synchronization at startup, but also for ensurin
This sounds like a pretty decent idea to me. Considering Neutron's patch
merge rate this activity should hopefully not take a consistent chunk of
your Friday.
It might also make sense to ask contributors to resume the habit of tagging
bugs with 'backport-potential' even if not in the RC period.
I
On 15 May 2015 at 00:19, Debojyoti Dutta wrote:
> Hi!
>
> It is a great pleasure to announce the development of a new project called
> Cognitive. Cognitive provides Machine Learning [1] as a Service that
> enables operators to offer next generation data science based services on
> top of their O
After putting the whole OpenStack networking contributors community through
almost 8 cycles of pedant comments and annoying "what if" questions, it is
probably time for me to relieve neutron contributors from this burden.
It has been a pleasure for me serving the Neutron community (or Quantum as
i
>From the bug Kevin reported it seems multiple dhcp agents per network have
been completely broken by the fix for bug #1345947, so a revert of patch
[1] (and stable backports) should probably be the first thing to do - if
nothing else because the original bug has not nearly the same level of
severi
I suspect a "BaaS" (Bridge-as-a-service) proposal is lurking in this thread.
While the idea of yet-another-aas is probably not desirable at this time,
it might be worth trying and understand - from an exclusively logical
perspective (ie: the API consumer point of view) - what would be the
differen
On 2 June 2015 at 23:59, Ian Cordasco wrote:
>
>
> On 6/2/15, 16:24, "Boris Pavlovic" wrote:
>
> >Hi stackers,
> >
> >
> >Issue
> >---
> >
> >
> >Projects are becoming bigger and bigger overtime.
> >More and more people would like to contribute code and usually core
> >reviewers
> >team can'
On 3 June 2015 at 07:12, John Griffith wrote:
>
>
> On Tue, Jun 2, 2015 at 7:19 PM, Ian Wienand wrote:
>
>> On 06/03/2015 07:24 AM, Boris Pavlovic wrote:
>>
>>> Really it's hard to find cores that understand whole project, but
>>> it's quite simple to find people that can maintain subsystems of
I'm not sure if you can test this behaviour on your own because it requires
the VMware plugin and the eventlet handling of backend response.
But the issue was manifesting and had to be fixed with this mega-hack [1].
The issue was not about several workers executing the same code - the
loopingcall
One reason for not sending the heartbeat from a separate greenthread could
be that the agent is already doing it [1].
The current proposed patch addresses the issue blindly - that is to say
before declaring an agent dead let's wait for some more time because it
could be stuck doing stuff. In that c
;
> > On Thu, Jun 4, 2015 at 11:52 AM, Carl Baldwin
> wrote:
> >
> > > Ann,
> > >
> > > Thanks for bringing this up. It has been on the shelf for a while now.
> > >
> > > Carl
> > >
> > > On Thu, Jun 4, 2015 at 8:54
Kevin,
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 the following scenario that can't be
> solved b
Jay is pretty much right.
In Neutron's case it is even more trivial. Somebody copied the extension
manager from Nova, and a sort of extension interface with this namespace.
And every neutron developer, including me felt compelled to filling that up
with something that resembled an XML namespace UR
As a further data point, Neutron has been trying to introduce
microversioning for a while, without success so far.
Given the sheer amount of backends the management layer integrates with,
and the constant need for the various subteams to "experiment" with the
API, the proposal [1] has probably som
Aloha!
As you know I pushed spec [1] during the Kilo lifecycle, but given the lazy
procrastinator that I am, I did not manage to complete in time for the
release.
This actually gave me a chance to realise that the spec that I pushed and
had approved did not make a lot of sense. Even worse, there
I am not able to say whether this works for Nova. Surely works for Neutron
- from a functional perspective at least.
I still don't know however whether this choice is the best way to proceed,
and perhaps you can help me understand better.
Role checks are always expressed through policy.json and c
As most of you already know, work is beginning to move forward on the
micro-versioned Neutron API, for which a specification is available at [1]
>From a practical perspective there is one non-negligible preliminary issue
that needs attention. then Neutron API URI prefix includes the full version
n
It is however interesting that both "lock wait timeouts" and "missing
savepoint" errors occur in operations pertaining the same table -
securitygroups in this case.
I wonder if the switch to pymysl has not actually uncovered some other bug
in Neutron.
I have no opposition to a revert, but since th
Gal,
thanks for this summery.
Some additional info inline.
Salvatore
On 12 June 2015 at 19:38, Gal Sagie wrote:
> Hello All,
>
> I wanted to share some of our next working items and hopefully get more
> people on board with the project.
> I personally would mentor any new comer that wants to g
On 12 June 2015 at 12:22, Sean Dague wrote:
> On 06/11/2015 06:03 PM, Salvatore Orlando wrote:
> > As most of you already know, work is beginning to move forward on the
> > micro-versioned Neutron API, for which a specification is available at
> [1]
> >
> > From a
On 12 June 2015 at 16:58, Henry Gessau wrote:
> On Thu, Jun 11, 2015, Salvatore Orlando wrote:
> > Finally, I received queries from several community members that would be
> keen
> > on helping supporting this microversioning effort. I wonder if the PTL
> and the
> &g
On 16 June 2015 at 14:38, Lucas Alvares Gomes wrote:
> Hi
>
> >> So if our min_version is 2.1 and the max_version is 2.50. That means
> >> alternative implementations need implement all the 50 versions
> >> api...that sounds pain...
> >
> >
> > Yes, it's pain, but it's no different than someone w
On 16 June 2015 at 18:49, Carl Baldwin wrote:
> On Thu, Jun 11, 2015 at 2:45 PM, Salvatore Orlando
> wrote:
> > I have been then following a different approach. And a set of patches,
> > including a devref one [2], if up for review [3]. This hardly completes
> the
> >
Some more comments inline.
Salvatore
On 16 June 2015 at 19:00, Carl Baldwin wrote:
> On Tue, Jun 16, 2015 at 12:33 AM, Kevin Benton wrote:
> >>Do these kinds of test even make sense? And are they feasible at all? I
> >> doubt we have any framework for injecting anything in neutron code under
>
As you are probably aware an api-wg guideline for microversioning is under
review [1]
Needless to say, neutron developers interested in this work should have a
look at [1] - if nothing else because we need to ensure we are aligned -
and influence the guideline were appropriate.
Experimental APIs a
I see Kyle's point that this is not something in-scope for liberty at this
stage.
However, on the other hand I would rather avoid having multiple agents on
the compute node performing various tasks in an un-coordinated way (well,
actually relying on neutron-server coordination).
QoS is an example
Anyway, if you want to print t-shirts once legal is cleared, here's a
vintage football idea [1].
Little and pointless trivia fact: Como calcio was sponsored for a few years
in the 80s by Mita copiers - now known as Kyocera.
Salvatore
[1]
http://www.calciocomo1907.it/images/news/thumbnails/Mattei%
On 25 June 2015 at 16:08, John Davidge (jodavidg)
wrote:
> Hi all,
>
> Recent neutron third party CI issues have got me thinking again about a
> topic which we discussed in Vancouver:
>
> Should any Third Party CI have voting rights for neutron patches in
> gerrit?
>
Why should this be a deci
> Edgar
>
> From: Salvatore Orlando
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> Date: Thursday, June 25, 2015 at 7:59 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> Subject: Re: [openstack-dev] [openstack
Hi,
since the quota enforcement patches for the 'better-quotas' blueprint did
not merge by liberty-1, and I forgot to resubmit the already-approved kilo
spec [1], I have submitted a RFE to comply with the process agreed for
Liberty [2].
As the policy [3] does not explicitly state that the submit
On 11 February 2016 at 20:17, John Belamaric
wrote:
>
> On Feb 11, 2016, at 12:04 PM, Armando M. wrote:
>
>
>
> On 11 February 2016 at 07:01, John Belamaric
> wrote:
>
>>
>>
>>
>> It is only internal implementation changes.
>>
>
> That's not entirely true, is it? There are config variables to c
On 3 March 2016 at 10:38, Ihar Hrachyshka wrote:
> Kevin Benton wrote:
>
> Hi,
>>
>> I know this has come up in the past, but some folks in the infra channel
>> brought up the topic of changing the default security groups to allow all
>> traffic.
>>
>> They had a few reasons for this that I will
On 7 March 2016 at 10:54, Gary Kotton wrote:
> There are a number of issues here:
>
>1. The create returns additional values, for example the binding:vnic_type,
>whilst the get does not
>
> This is probably a consequence of fixing the behaviour mismatch between
create and get.
>
>1.
Some thoughts inline.
Salvatore
On 11 March 2016 at 23:15, Carl Baldwin wrote:
> Hi,
>
> I have started to get into coding [1] for the Neutron routed networks
> specification [2].
>
> This spec proposes a new association between network segments and
> subnets. This affects how IPAM needs to wo
Indeed the VMware plugins were not using resource tracking (they know that
my code should not be trusted!)
I think this bears however another question that we need to answer... it is
likely that some change broke quota enforcement for plugins which do not
use usage tracking.
When I developed reser
I'm not sure if this was mentioned already throughout the thread, however
as I've been working a bit on quotas in the past I might have some
additional information:
- Looking at quotas it is worth distinguishing between management (eg::
resource limits per tenant and/or users), and enforcement (eg
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 best of my knowledge) and is functionally similar to
FORCERENEW.
Thi
On 28 January 2015 at 20:19, Brian Haley wrote:
> Hi Kevin,
>
> On 01/28/2015 03:50 AM, Kevin Benton wrote:
> > Hi,
> >
> > Approximately a year and a half ago, the default DHCP lease time in
> Neutron was
> > increased from 120 seconds to 86400 seconds.[1] This was done with the
> goal of
> > re
r when there's a failure case.
> So, how does one deploy external DHCP with Openstack?
>
> If Openstack hasn't assigned a IP address when DHCP is disabled for a
> network, can't port_update be done with the provider DHCP specified IP
> address to put the anti-spoofin
I reckon the blueprint [1] supersedes the one in the old wiki page you
found.
It lies in abandoned status as it did not make the release plan for Kilo. I
am sure the author and the other contributors working on it will resume it
for the next release.
Salvatore
[1] https://review.openstack.org/#/c
Hi,
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 will be unable to attend today's L3/IPAM meeting due to a conflict, so
here are some highlights from me on which your feedback is more than
welcome:
- I agr
On 13 February 2015 at 12:40, Rossella Sblendido
wrote:
>
>
> On 02/12/2015 02:36 PM, Salvatore Orlando wrote:
> > - I promised a non blocking algorithm for IP allocation. The one I was
> > developing was based on specifying the primary key on the ip_requests
> > t
301 - 400 of 472 matches
Mail list logo
