3rd party systems do need to test the patch rebased against master since
that's what OpenStack is testing. Otherwise, there are conditions where the
patch can fail in its current position but not rebased against master so it
will look like something is wrong with the 3rd party system. Similarly,
Hi,
For agent way to notify server regarding node specific info, you can leverage
the periodic state report that neutron agent sends to the neutron Server.
As an option, the ML2 Mechanism Driver can check that agent report and
depending on the
datapath_type, update vif_details.
This can be done
On Wed, Jul 9, 2014 at 1:54 PM, Jay Bryant jsbry...@electronicjungle.net
wrote:
I had been under the impression that all BPs we going to require a spec.
I, however, was made are in today's cinder meeting that we are only
requiring specs for changes that change the user's interaction with the
Hi Augus,
I agree with that 'trigger' should not be put in workbook. in current
implement, it's hard to get the execution context while schedule trigger.
Here is one bug to complain about missing context.
https://bugs.launchpad.net/mistral/+bug/1335758
Thanks,
Ray
On Tue, Jun 10, 2014 at 1:59
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/07/14 19:20, Clark Boylan wrote:
Before we get too far ahead of ourselves mysql-connector is not
hosted on pypi. Instead it is an external package link. We recently
managed to remove all packages that are hosted as external package
links
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12/07/14 03:17, Mike Bayer wrote:
On 7/11/14, 7:26 PM, Carl Baldwin wrote:
On Jul 11, 2014 5:32 PM, Vishvananda Ishaya
vishvana...@gmail.com
mailto:vishvana...@gmail.com wrote:
I have tried using pymysql in place of mysqldb and in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12/07/14 00:30, Vishvananda Ishaya wrote:
I have tried using pymysql in place of mysqldb and in real world
concurrency tests against cinder and nova it performs slower. I was
inspired by the mention of mysql-connector so I just tried that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12/07/14 02:49, Jay Pipes wrote:
On 07/11/2014 08:04 AM, Ihar Hrachyshka wrote: On 09/07/14 13:17,
Ihar Hrachyshka wrote:
Hi all,
Multiple projects are suffering from db lock timeouts due to
deadlocks deep in mysqldb library that we use
On 07/10/2014 02:44 PM, Richard Jones wrote:
On 10 July 2014 23:27, Mulcahy, Stephen stephen.mulc...@hp.com wrote:
When I last tested bandersnatch, it didn’t work well behind a proxy (in
fact most of the existing pypi mirroring tools suffered from the same
problem) – pypi-mirror has worked
On Mon, Jul 14, 2014 at 2:58 AM, Monty Taylor mord...@inaugust.com wrote:
On 07/10/2014 02:44 PM, Richard Jones wrote:
On 10 July 2014 23:27, Mulcahy, Stephen stephen.mulc...@hp.com wrote:
When I last tested bandersnatch, it didn’t work well behind a proxy (in
fact most of the existing
On Sun, Jul 13, 2014, at 02:36 PM, James Polley wrote:
We're also thinking about how we continue to offer the
pre-built wheels
for each of our build platforms. For infra, what I'm thinking
is:
On each mirror slave (We have one for each OS combo we use), do
something similar to:
pip
On 2014-07-13 00:09:11 -0700 (-0700), Kevin Benton wrote:
[...]
Does Zuul only cherry-pick the top commit of the proposed patch
instead of merging the proposed patch's branch into master (which
would merge all dependent patchsets)?
In an independent pipeline, Zuul tests the change as merged to
On Sun, Jul 13, 2014 at 8:01 AM, Dolph Mathews dolph.math...@gmail.com
wrote:
On Wed, Jul 9, 2014 at 1:54 PM, Jay Bryant jsbry...@electronicjungle.net
wrote:
I had been under the impression that all BPs we going to require a spec.
I, however, was made are in today's cinder meeting that we
On 14 Jul 2014, at 08:08, Gregory Haynes g...@greghaynes.net wrote:
On Sun, Jul 13, 2014, at 02:36 PM, James Polley wrote:
We're also thinking about how we continue to offer the pre-built wheels
for each of our build platforms. For infra, what I'm thinking is:
On each mirror
On Fri, Jul 11, 2014 at 4:41 PM, Brent Eagles beag...@redhat.com wrote:
Hi,
A bug titled Creating quantum L2 networks (without subnets) doesn't
work as expected (https://bugs.launchpad.net/nova/+bug/1039665) was
reported quite some time ago. Beyond the discussion in the bug report,
there
Yurly, thanks for your spec and code! I'll sync with Carl tomorrow on this
and see how we can proceed for Juno around this.
On Sat, Jul 12, 2014 at 10:00 AM, Carl Baldwin c...@ecbaldwin.net wrote:
+1 This spec had already been proposed quite some time ago. I'd like to
see this work get in
+1:)
On Sun, Jul 13, 2014 at 2:59 AM, Lucas Alvares Gomes
lucasago...@gmail.com wrote:
+1 !
On Fri, Jul 11, 2014 at 11:50 PM, Devananda van der Veen
devananda@gmail.com wrote:
Hi all!
While David (Shrews) only began working on Ironic in earnest four months
ago, he has been working on
+1:)
On Sun, Jul 13, 2014 at 3:00 AM, Lucas Alvares Gomes
lucasago...@gmail.com wrote:
+1 !
On Fri, Jul 11, 2014 at 11:50 PM, Devananda van der Veen
devananda@gmail.com wrote:
Hi all!
It's time to grow the team :)
Jim (jroll) started working with Ironic at the last mid-cycle, when
port with flexible ip address setting is necessary. I collected several use
cases:
1) when creating a port, we need to indicate that,
[A] binding to none of subnet(no ip address);
[B] binding to all subnets;
[C] binding to any subnet;
[D] binding to explicitly list of subnets,
My understanding is the main goal is to get a fully functional gantt working
before we do the split. This means we have to clean up the nova interfaces so
that all of the current scheduler functionality, including things like
aggregates and resource tracking, so that we can make the split and
On 07/14/2014 12:20 AM, Ihar Hrachyshka wrote:
On 11/07/14 19:20, Clark Boylan wrote:
That said there is at least one other pure python alternative,
PyMySQL. PyMySQL supports py3k and pypy. We should look at using
PyMySQL instead if we want to start with a reasonable path to
getting this in
21 matches
Mail list logo
