Probably that LOG statement is a line added for debugging purposes.
There are several probable causes for a floating ip being down. If you see
any traceback in the neutron server or l3-agent that will probably
immediately reveal the root cause.
On the other hand, lack of any traceback might indica
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
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
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
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
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
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.
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
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
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
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
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.
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 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
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
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:
> &
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
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
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 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
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
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
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.
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
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
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
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
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
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
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
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
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
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?
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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,
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
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
> 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
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
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%
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
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
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
>
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
> >
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 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 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
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
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
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
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
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
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
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
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
;
> > 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
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
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
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
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'
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
>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
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
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
On 7 May 2015 at 10:32, Miguel Ángel Ajo wrote:
> Gal, thank you very much for the update to the list, I believe it’s very
> helpful,
> I’ll add some inline notes.
>
> On Thursday, 7 de May de 2015 at 8:51, Gal Sagie wrote:
>
> Hello All,
>
> I think that the Neutron QoS effort is progressing int
Just like the Neutron plugin manager, also ML2 driver manager ensure
drivers are loaded only once regardless of the number of workers.
What Kevin did proves that drivers are correctly loaded before forking (I
reckon).
However, forking is something to be careful about especially when using
eventlet
Thanks Bob.
Two answers/comments below.
On 6 May 2015 at 14:59, Bob Melander (bmelande) wrote:
> Hi Salvatore,
>
> Two questions/remarks below.
>
> From: Salvatore Orlando
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
>
g will be more than happy to slap your
hands too.
> Thanks,
> Kevin
> ------
> *From:* Salvatore Orlando [sorla...@nicira.com]
> *Sent:* Tuesday, May 05, 2015 3:13 PM
> *To:* OpenStack Development Mailing List
> *Subject:* [openstack-dev] [neutron][api
I think Paul is correctly scoping this discussion in terms of APIs and
management layer.
For instance, it is true that dynamic routing support, and BGP support
might be a prerequisite for BGP VPNs, but it should be possible to have at
least an idea of how user and admin APIs for this VPN use case s
There have now been a few iterations on the specification for Neutron
micro-versioning [1].
It seems that no-one in the community opposes introducing versioning. In
particular API micro-versioning as implemented by Nova and Ironic seems a
decent way to evolve the API incrementally.
What the develo
Patch #153236 is introducing pluggable IPAM in the db base plugin class,
and default to it at the same time, I believe.
If the consensus is to default to IPAM driver then in order to satisfy
grenade requirements those migrations scripts should be run. There should
actually be a single script to be
I think the first workaround is the solution we're looking for as it better
reflects the fact that opencontrail is a db-less plugin.
I hope it will be the easier too, but you can never be too sure with
neutron unit tests.
Salvatore
On 4 May 2015 at 12:56, Pavel Bondar wrote:
> Hi Kevin,
>
> Tha
Among the OpenStack project of which I have some knowledge, none of them
uses any DDT library.
If you think there might be a library from which lbaas, neutron, or any
other openstack project might take advantage, we should consider it.
Salvatore
On 14 April 2015 at 20:33, Madhusudhan Kandadai <
m
At a first glance it seems run_ssh is disabled in gate tests [1]. I could
not find any nova job where it is enabled.
These tests are therefore skipped. For what is worth they might be broken
now. Sharing a traceback or filing a bug might help.
Salvatore
[1]
http://logs.openstack.org/81/159481/2/c
I believe German is referring to the case where a user performs an
operation on behalf of some other project to whom it bears no relationship.
In this case the user performing the operation authenticates with keystone
with a project_id which is not the one for which the operation is being
performed
On 24 April 2015 at 16:50, Chris Friesen
wrote:
> On 04/24/2015 07:26 AM, Salvatore Orlando wrote:
>
> If you think it might be beneficial to adjust tooling to that these
>> "contributions" get counted this is fine by me. I just wanted to point
>> out
On 24 April 2015 at 15:13, Kyle Mestery wrote:
> On Fri, Apr 24, 2015 at 4:06 AM, loy wolfe wrote:
>
>> It's already away from the original thread, so I start this new one,
>> also with some extra tag because I think it touch some corss-project
>> area.
>>
>> Original discuss and reference:
>> h
On 24 April 2015 at 14:11, Russell Bryant wrote:
> On 04/24/2015 07:21 AM, Amrith Kumar wrote:
> > We had a hypothesis about why +0 was rarely used (never conclusively
> > proved). Our hypothesis was that since Stackalytics didn't count +0's
> > it led to an increased propensity to -1 something.
1 - 100 of 472 matches
Mail list logo
