On 08/14/2014 10:25 PM, Sylvain Bauza wrote:
Hi mikal,
Le 14 août 2014 01:49, Michael Still mi...@stillhq.com
mailto:mi...@stillhq.com a écrit :
So, there's been a lot of email in the last few days and I feel I am
not keeping up.
Sylvain, can you summarise for me what the plan is here?
Here you are:
I think we need update this into the OpenStack VMware support guide.
GuestId | Retail Name
Hi,
Recently I just read the code of oslo.i18n library,
The lazy translation idea is great!
But I found a question about gettext contextual markers
and plural form, such as pgettext and ungettext functions,
see [3].
It seems the two gettext functions are missing in the oslo.i18n
Great stuff, really happy to see Python 3 support.
- Original Message -
From: Steve Kowalik ste...@wedontsleep.org
To: openstack-dev@lists.openstack.org
Sent: Friday, 15 August, 2014 4:11:04 AM
Subject: [openstack-dev] [TripleO] Python 3 support in os-*-config
* os-apply-config
Hi
On 14 Aug 2014, at 19:48, Dugger, Donald D donald.d.dug...@intel.com wrote:
My experience with mics, no matter how good, In conference rooms is not good.
+1
The ubuntu dev summits went through several iterations of trying to make remote
participation effective, and I don't think we
Hi Oslo team,
I propose that we add Mike Bayer (zzzeek) to the oslo.db core reviewers team.
Mike is an author of SQLAlchemy, Alembic, Mako Templates and some
other stuff we use in OpenStack. Mike has been working on OpenStack
for a few months contributing a lot of good patches and code reviews
Hi, all.
I'd like to introduce an opensource project RACK (Real
ApplicationCentric Kernel).
We aim to achieve after the cloud application, which is application
intended for running on cloud, using it.
The present applications are designed at before the cloud. As those
applications are not
+1
On Fri, Aug 15, 2014 at 12:21 PM, Roman Podoliaka rpodoly...@mirantis.com
wrote:
Hi Oslo team,
I propose that we add Mike Bayer (zzzeek) to the oslo.db core reviewers
team.
Mike is an author of SQLAlchemy, Alembic, Mako Templates and some
other stuff we use in OpenStack. Mike has been
On Fri, Aug 15, 2014 at 06:53:41AM +1000, Michael Still wrote:
On Fri, Aug 15, 2014 at 6:37 AM, Dan Smith d...@danplanet.com wrote:
== Move Virt Drivers to use Objects (Juno Work) ==
I couldn't actually find any code out for review for this one apart
from
Le 15 août 2014 08:16, Nikola Đipanov ndipa...@redhat.com a écrit :
On 08/14/2014 10:25 PM, Sylvain Bauza wrote:
Hi mikal,
Le 14 août 2014 01:49, Michael Still mi...@stillhq.com
mailto:mi...@stillhq.com a écrit :
So, there's been a lot of email in the last few days and I feel I am
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 08/08/14 13:09, Osanai, Hisashi wrote:
Hi,
On Tuesday, August 05, 2014 8:57 PM, Ihar Hrachyshka wrote:
Thanks. To facilitate quicker backport, you may also propose
the patch for review yourself. It may take time before stable
maintainers
Can the default_volume_type be left empty and get the original None
type, so we don't have to create the volume type prior to running tempest
tests?
Andrew Kerr
OpenStack QA
Cloud Solutions Group
NetApp
On 8/14/14, 5:23 PM, Martin, Kurt Frederick (ESSN Storage MSDU)
kurt.f.mar...@hp.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
+1. [Not being an oslo core in any way,] I think Mike, with all his
prior experience and vision on where oslo.db should strive to, will be
a great addition to the core team.
/Ihar
On 15/08/14 10:21, Roman Podoliaka wrote:
Hi Oslo team,
I
Maybe we need to think about this from a distributed software perspective?
* Divide and Conquer?
Can we split the topics to create more manageable sub-groups? This way it's not
core-vs-non-core but intererested-vs-moderately-interested. (of course, this
is much the way the mailing list
On 08/15/2014 04:21 AM, Roman Podoliaka wrote:
Hi Oslo team,
I propose that we add Mike Bayer (zzzeek) to the oslo.db core reviewers team.
Mike is an author of SQLAlchemy, Alembic, Mako Templates and some
other stuff we use in OpenStack. Mike has been working on OpenStack
for a few months
On 08/15/2014 09:13 AM, Jay Pipes wrote:
On 08/15/2014 04:21 AM, Roman Podoliaka wrote:
Hi Oslo team,
I propose that we add Mike Bayer (zzzeek) to the oslo.db core
reviewers team.
Mike is an author of SQLAlchemy, Alembic, Mako Templates and some
other stuff we use in OpenStack. Mike has
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Some updates on the matter:
- - oslo-spec was approved with narrowed scope which is now 'enabled
mysqlconnector as an alternative in gate' instead of 'switch the
default db driver to mysqlconnector'. We'll revisit the switch part
the next cycle
Thoughts, rapidfire :)
In short, I think we should plan on backward compat unless some stubborn
technical problem gets in our way
I think backward compatibility is a good idea. We can make the
user/pass inputs for data objects optional (they are required
currently), maybe even gray them
On 08/14/2014 03:21 AM, Nikola Đipanov wrote:
On 08/13/2014 06:05 PM, Sylvain Bauza wrote:
Le 13/08/2014 12:21, Sylvain Bauza a écrit :
Le 12/08/2014 22:06, Sylvain Bauza a écrit :
Le 12/08/2014 18:54, Nikola Đipanov a écrit :
On 08/12/2014 04:49 PM, Sylvain Bauza wrote:
(sorry for
On Fri, Aug 15, 2014 at 6:39 AM, Kerr, Andrew andrew.k...@netapp.com
wrote:
Can the default_volume_type be left empty and get the original None
type, so we don't have to create the volume type prior to running tempest
tests?
Andrew Kerr
OpenStack QA
Cloud Solutions Group
NetApp
On
On Thu, Aug 14, 2014 at 3:21 AM, Malawade, Abhijeet
abhijeet.malaw...@nttdata.com wrote:
Hi all,
I am trying to use heat to create docker containers. I have configured
heat-docker plugin.
I am also able to create stack using heat successfully.
To start container on different host we
On 08/15/2014 08:20 AM, Russell Bryant wrote:
On 08/15/2014 09:13 AM, Jay Pipes wrote:
On 08/15/2014 04:21 AM, Roman Podoliaka wrote:
Hi Oslo team,
I propose that we add Mike Bayer (zzzeek) to the oslo.db core
reviewers team.
Mike is an author of SQLAlchemy, Alembic, Mako Templates and
thanks for the thoughts Trevor,
On 08/15/2014 09:32 AM, Trevor McKay wrote:
I think backward compatibility is a good idea. We can make the
user/pass inputs for data objects optional (they are required
currently), maybe even gray them out in the UI with a checkbox to turn
them on, or something
On 08/15/2014 02:30 AM, Dougal Matthews wrote:
Great stuff, really happy to see Python 3 support.
- Original Message -
From: Steve Kowalik ste...@wedontsleep.org
To: openstack-dev@lists.openstack.org
Sent: Friday, 15 August, 2014 4:11:04 AM
Subject: [openstack-dev] [TripleO] Python
On 2014-08-14 09:33:20 -0400 (-0400), Russell Bryant wrote:
[...]
Another issue is that some folks are just fundamentally opposed to
using Google
[...]
I think that's a shallow depiction of the issue. I'm sure *some*
people really do just avoid Google specifically, but a bigger
concern should
OpenStack is OpenStack. The use of openstack is also acceptable in our
development conversations.
OS or os is operating system. I am starting to see some people us OS or
os to mean OpenStack. This is confusing and also incorrect[0].
No alterations: When using OpenStack Marks, you shall never
On 2014-08-13 19:51:52 -0500 (-0500), Ben Nemec wrote:
[...]
make the check-tripleo job leave an actual vote rather than just a
comment.
[...]
That, as previously discussed, will require some design work in
Zuul. Gerrit uses a single field per account for verify votes, which
means that if you
No alterations: When using OpenStack Marks, you shall never vary the
spelling, hyphenation or spacing of the any portion of the marks.
Examples of Improper Display of an OpenStack Mark: Open-Stack; Open
Stack; OS Stack Examples of Proper Display of an OpenStack Mark:
OpenStack; OPENSTACK
- Original Message -
From: Anita Kuno ante...@anteaya.info
To: openStack Development Mailing List openstack-dev@lists.openstack.org
OpenStack is OpenStack. The use of openstack is also acceptable in our
development conversations.
OS or os is operating system. I am starting to see
On 2014-08-13 19:28:48 -0700 (-0700), Joe Gordon wrote:
We actually run out of nodes almost every day now (except
weekends), we have about 800 nodes, and hit that quota most days
[...]
It's worth noting that a lot of the recent exhaustion has been due
to OpenStack bugs impacting the providers
OS or os is operating system. I am starting to see some people us OS or
os to mean OpenStack. This is confusing and also incorrect[0].
Except in the nova API code, where 'os' means 'openstack'.
I too think that policing the use of abbreviations is silly. It's a
confusing abbreviation, but
Anita Kuno ante...@anteaya.info wrote on 08/15/2014 10:38:20 AM:
OpenStack is OpenStack. The use of openstack is also acceptable in our
development conversations.
OS or os is operating system. I am starting to see some people us OS or
os to mean OpenStack. This is confusing and also
The current DIB element support for downloading tarballs via
source-repository allows an entry in the following form:
name tar targetdir url
Today, this feature is currently used only by the mysql DIB element. You can
see how it's used here:
On 08/08/2014 08:42 AM, Nikola Đipanov wrote:
On 08/06/2014 07:54 PM, Jay Pipes wrote:
I bring this up on the mailing list because I think Liyi's patch offers
an interesting future direction to the way that we think about our retry
approach in Nova. Instead of having hard-coded or configurable
On 08/15/2014 11:00 AM, Mike Spreitzer wrote:
Anita Kuno ante...@anteaya.info wrote on 08/15/2014 10:38:20 AM:
OpenStack is OpenStack. The use of openstack is also acceptable in our
development conversations.
OS or os is operating system. I am starting to see some people us OS or
os to
On 8/14/2014 6:42 PM, Doug Hellmann wrote:
On Aug 14, 2014, at 4:41 PM, Joe Gordon
joe.gord...@gmail.commailto:joe.gord...@gmail.com wrote:
On Wed, Aug 13, 2014 at 12:24 PM, Doug Hellmann
d...@doughellmann.commailto:d...@doughellmann.com wrote:
On Aug 13, 2014, at 3:05 PM, Eoghan Glynn
On 15/08/14 16:12, Andrew Laski wrote:
On 08/08/2014 08:42 AM, Nikola Đipanov wrote:
On 08/06/2014 07:54 PM, Jay Pipes wrote:
I bring this up on the mailing list because I think Liyi's patch offers
an interesting future direction to the way that we think about our retry
approach in Nova.
I think the review time alone is a huge issue. Even worse, for the
most part, core reviewers are reviewing code for which they themselves
can't test because it requires proprietary hardware or software,
making the situation brittle at best. Having a separate git repository
which is gated by
But, if someone asked me what they should use for metering today,
I'd point them towards Monasca in a heartbeat.
FWIW my view is that Monasca is an interesting emerging project, with a
team accreting around it that seems to be interested in collaboration.
We've had ongoing discussions with
On 08/15/2014 11:43 AM, Matthew Booth wrote:
On 15/08/14 16:12, Andrew Laski wrote:
On 08/08/2014 08:42 AM, Nikola Đipanov wrote:
On 08/06/2014 07:54 PM, Jay Pipes wrote:
I bring this up on the mailing list because I think Liyi's patch offers
an interesting future direction to the way that
On Thu, Aug 14, 2014 at 12:09:26PM +0200, Salvatore Orlando wrote:
I think there will soon be a discussion regarding what the appropriate
location for plugin and drivers should be.
My personal feeling is that Neutron has simply reached the tipping point
where the high number of drivers and
John,
We’re running master on every patch set. What needs to be set in localrc?
Actually, I think I know what could be the issue (still need to confirm)
1. devstack-gate/devstack-vm-gate-wrap.sh configures localrc
2. We configuring the cinder backend in local.conf. We’re not
On Fri, Aug 15, 2014 at 10:29 AM, Asselin, Ramy ramy.asse...@hp.com wrote:
John,
We’re running master on every patch set. What needs to be set in localrc?
Actually, I think I know what could be the issue (still need to confirm)
1. devstack-gate/devstack-vm-gate-wrap.sh
On 08/15/2014 09:12 AM, Russell Bryant wrote:
On 08/15/2014 11:00 AM, Mike Spreitzer wrote:
Anita Kuno ante...@anteaya.info wrote on 08/15/2014 10:38:20 AM:
OpenStack is OpenStack. The use of openstack is also acceptable in our
development conversations.
OS or os is operating system. I am
Anita Kuno ante...@anteaya.info wrote on 08/15/2014 01:08:44 PM:
...
I think you hit the nail on the head here, Russell, it's fine in the
right context.
The definition of the right context however is somewhat elusive. I have
chosen (it is my own fault) to place myself in the area where the
On 08/15/2014 01:28 PM, Mike Spreitzer wrote:
Anita Kuno ante...@anteaya.info wrote on 08/15/2014 01:08:44 PM:
...
I think you hit the nail on the head here, Russell, it's fine in the
right context.
The definition of the right context however is somewhat elusive. I have
chosen (it is my
Hi, following up from last week's IRC meeting, I updated the Solum roadmap wiki
with items for consideration for Juno-3. Please mail back your
comments/suggestions, as well as we can discuss more in the next IRC and
finalize Juno release scope.
Wiki link:
Russell Bryant rbry...@redhat.com wrote on 08/15/2014 01:49:40 PM:
...
but surely when it comes to learning OpenStack itself, the OpenStack
community, dev processes, tools, etc this has got to be extremely
far down the list of barriers to entry.
No argument there. I am spending decimal
I really think we have much bigger fish to fry than to start policing
community shorthand where nearly every meeting and communication is typed.
That's just my two cents for what it's worth.
Mahalo,
Adam
*Adam Lawson*
AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware
On 08/15/2014 02:45 PM, Eric Windisch wrote:
I have proposed a _silent_ check for Nova for integration of the Docker
driver:
https://review.openstack.org/#/c/114547/
It has been established that this code cannot move back into Nova until
the tests are running and have a solid history
On 08/15/2014 02:53 PM, Russell Bryant wrote:
On 08/15/2014 02:45 PM, Eric Windisch wrote:
I have proposed a _silent_ check for Nova for integration of the Docker
driver:
https://review.openstack.org/#/c/114547/
It has been established that this code cannot move back into Nova until
Given resource concerns, maybe just adding it to the experimental
pipeline would be sufficient?
For clarity, the discussed patch is to promote an existing experimental job
to silent.
Regards -Eric
___
OpenStack-dev mailing list
Feature freeze is only a few weeks away (Sept 4). How about we just
leave it in experimental until after that big push? That seems pretty
reasonable.
Joe just proposed dropping a bunch of semi-useless largeops runs. Maybe
that leaves room to sneak this in? If the infra team is okay with it,
On Fri, Aug 15, 2014 at 11:55 AM, Russell Bryant rbry...@redhat.com wrote:
On 08/15/2014 02:53 PM, Russell Bryant wrote:
On 08/15/2014 02:45 PM, Eric Windisch wrote:
I have proposed a _silent_ check for Nova for integration of the Docker
driver:
Hi Everyone,
So as part of splitting out common functionality from tempest into a library [1]
we need to create a new repository. Which means we have the fun task of coming
up with something to name it. I'm personally thought we should call it:
- mesocyclone
Which has the advantage of being a
On Fri, Aug 15, 2014 at 8:20 AM, Jeremy Stanley fu...@yuggoth.org wrote:
On 2014-08-14 09:33:20 -0400 (-0400), Russell Bryant wrote:
[...]
Another issue is that some folks are just fundamentally opposed to
using Google
[...]
I think that's a shallow depiction of the issue. I'm sure
What about 'teapot' (as in the idiom 'tempest in a teapot'[1])
-Drew
[1] http://en.wikipedia.org/wiki/Tempest_in_a_teapot
On 08/15/2014 01:14 PM, Matthew Treinish wrote:
Hi Everyone,
So as part of splitting out common functionality from tempest into a library [1]
we need to create a new
I definitely agree that reviewer time is wasted reviewing changes. However,
I don't think moving them to a different repo with different cores is going
to make them less brittle without some very strict guidelines about what a
driver/plugin is allowed to do.
For example, without neutron core
We are putting a lot of effort into the Specs process. It seems like a
pity to let them go to waste after the features they describe are
implemented. Ideally, they should be part of the official
documentation. Many are too detailed to be a release note.
Should they be part of the patch,
On 08/15/2014 03:26 PM, Drew Fisher wrote:
What about 'teapot' (as in the idiom 'tempest in a teapot'[1])
-Drew
[1] http://en.wikipedia.org/wiki/Tempest_in_a_teapot
Though in this case it'd be teacup in tempest, I think?
There's also a TCup project [1] that uses tempest. So, you have
On Fri, Aug 15, 2014 at 8:17 AM, Sandy Walsh sandy.wa...@rackspace.com
wrote:
On 8/14/2014 6:42 PM, Doug Hellmann wrote:
On Aug 14, 2014, at 4:41 PM, Joe Gordon joe.gord...@gmail.com wrote:
On Wed, Aug 13, 2014 at 12:24 PM, Doug Hellmann d...@doughellmann.com
wrote:
On Aug 13,
The are still alive - http://specs.openstack.org/openstack/keystone-specs/
Regards,
Steve Martinelli
Software Developer - OpenStack
Keystone Core Member
Phone:
1-905-413-2851
E-mail: steve...@ca.ibm.com
8200 Warden Ave
Markham, ON L6G 1C7
Canada
From:
Adam Young ayo...@redhat.com
Excerpts from Brownell, Jonathan C (Corvallis)'s message of 2014-08-15 08:11:18
-0700:
The current DIB element support for downloading tarballs via
source-repository allows an entry in the following form:
name tar targetdir url
Today, this feature is currently used only by the mysql DIB
On Fri, Aug 15, 2014 at 2:47 PM, Adam Young ayo...@redhat.com wrote:
We are putting a lot of effort into the Specs process. It seems like a
pity to let them go to waste after the features they describe are
implemented. Ideally, they should be part of the official documentation.
Many are too
On Thu, Aug 14, 2014 at 4:02 PM, Eoghan Glynn egl...@redhat.com wrote:
Additional cross-project resources can be ponied up by the large
contributor companies, and existing cross-project resources are not
necessarily divertable on command.
Sure additional cross-project resources can
On Aug 15, 2014, at 3:18 AM, Peng Wu peng.e...@gmail.com wrote:
Hi,
Recently I just read the code of oslo.i18n library,
The lazy translation idea is great!
But I found a question about gettext contextual markers
and plural form, such as pgettext and ungettext functions,
see [3].
On Thu, Aug 14, 2014 at 4:02 PM, Eoghan Glynn egl...@redhat.com wrote:
Additional cross-project resources can be ponied up by the large
contributor companies, and existing cross-project resources are not
necessarily divertable on command.
Sure additional cross-project resources can
On Aug 15, 2014, at 9:29 AM, Ihar Hrachyshka ihrac...@redhat.com wrote:
Signed PGP part
Some updates on the matter:
- oslo-spec was approved with narrowed scope which is now 'enabled
mysqlconnector as an alternative in gate' instead of 'switch the
default db driver to mysqlconnector'.
Regarding the connection to release notes, it'd be useful to link from
official release note bullet points back to the corresponding spec on
specs.openstack.org to provide additional detail.
On Fri, Aug 15, 2014 at 2:58 PM, Anne Gentle a...@openstack.org wrote:
On Fri, Aug 15, 2014 at 2:47
On Aug 15, 2014, at 10:00 AM, Ben Nemec openst...@nemebean.com wrote:
On 08/15/2014 08:20 AM, Russell Bryant wrote:
On 08/15/2014 09:13 AM, Jay Pipes wrote:
On 08/15/2014 04:21 AM, Roman Podoliaka wrote:
Hi Oslo team,
I propose that we add Mike Bayer (zzzeek) to the oslo.db core
On Fri, Aug 15, 2014 at 3:11 PM, Dolph Mathews dolph.math...@gmail.com
wrote:
Regarding the connection to release notes, it'd be useful to link from
official release note bullet points back to the corresponding spec on
specs.openstack.org to provide additional detail.
I disagree, the people
-Original Message-
From: Doug Hellmann d...@doughellmann.com
Reply: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: August 15, 2014 at 13:29:15
To: Ben Nemec openst...@nemebean.com, OpenStack Development Mailing List
(not for usage
--Basically no shareable entities.
+1
That will make me insanely happy :-)
Regarding Listeners: I was assuming that a LoadBalancer would map to an haproxy
instance - and a listener would be part of that haproxy. But I heard Stephen
say that this so not so clear cut. So maybe listeners map to
Hi Harm
It’s highly unlikely that it would work with a current version of Neutron
(Icehouse was where the original effort went). I’ve just run out of cycles to
work on this. I know Sean Collins continues to drive this effort, and the
roadmap may have this BP (or a similar one) targeted for
OpenTest is a library for integrational and functional testing of
OpenStack cloud technology.
Sounds?
On Fri, Aug 15, 2014 at 10:48 PM, Russell Bryant rbry...@redhat.com wrote:
On 08/15/2014 03:26 PM, Drew Fisher wrote:
What about 'teapot' (as in the idiom 'tempest in a teapot'[1])
On 08/15/2014 03:14 PM, Matthew Treinish wrote:
Hi Everyone,
So as part of splitting out common functionality from tempest into a library [1]
we need to create a new repository. Which means we have the fun task of coming
up with something to name it. I'm personally thought we should call it:
On Aug 15, 2014, at 5:39 PM, Jay Pipes jaypi...@gmail.com wrote:
On 08/15/2014 03:14 PM, Matthew Treinish wrote:
Hi Everyone,
So as part of splitting out common functionality from tempest into a library
[1]
we need to create a new repository. Which means we have the fun task of
On Fri, Aug 15, 2014 at 4:31 PM, Jay Pipes jaypi...@gmail.com wrote:
current Tempest repository, into their own repo called
openstack-integration-tests or os-integration-tests.
I see what you did there...
+1 anyway
dt
Dean Troyer
dtro...@gmail.com
On Fri, Aug 15, 2014 at 7:28 PM, Daniel P. Berrange berra...@redhat.com wrote:
On Fri, Aug 15, 2014 at 06:53:41AM +1000, Michael Still wrote:
On Fri, Aug 15, 2014 at 6:37 AM, Dan Smith d...@danplanet.com wrote:
== Move Virt Drivers to use Objects (Juno Work) ==
I couldn't actually find any
Yeah, need details on that. Maybe he's talking about having haproxy
listen on many ips and ports, each one being a separate front end
section and in the haproxy config with each mapped to its own
default_backend.
Even if that is the case, the load balancer + listener woudl still make
up one of
Agreed. I think this should be in unless infra vetos it for load reasons.
Michael
On Sat, Aug 16, 2014 at 5:11 AM, Dan Smith d...@danplanet.com wrote:
Feature freeze is only a few weeks away (Sept 4). How about we just
leave it in experimental until after that big push? That seems pretty
The neutron full job is finally voting, and the first patch [1] has already
passed it in gate checks!
I've collected a few data points before it was switched to voting, and we
should probably expect a failure rate around 4%. This is not bad, but
neither great, and everybody's contribution will be
Eric,
Doug's correct - this looks like a bug in pecan that occurs when you subclass
both rest.RestController and hooks.HookController. I'm working on a bug fix as
On 2014-08-16 08:11:42 +1000 (+1000), Michael Still wrote:
Agreed. I think this should be in unless infra vetos it for load
reasons.
I don't think the Infra Team minds if you run reasonable jobs to
determine whether a candidate driver for a free-software backend is
suitable for inclusion into
Team,
I did a quick audit on the Neutron CI. Very sad results. Only few plugins
and drivers are running properly and testing all Neutron commits.
I created a report here:
https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugin
_and_Drivers
We will discuss the actions to take
On 2014-08-15 15:14:21 -0400 (-0400), Matthew Treinish wrote:
[...]
So as a first step I figured that I'd bring it up on the ML to see
if anyone had any other suggestions.
[...]
Twas a clever quibble. Here, a garment for it:
http://en.wikipedia.org/wiki/The_Tempest#Characters
Now I will
Hi Edgar,
Nice shot, to be the inquisitor is not necessarily a bad thing :)
I know some CIs are 'stuck' waiting for bugs to be fixed or certain patches
to be merged, but I was wondering if it is a requirement that CIs vote
*ALL* the Neutron patches. Some may have missed your call just because of
Correction
The right links are:
https://review.openstack.org/#/c/114629/
https://review.openstack.org/#/c/114393/
Not this one:
https://review.openstack.org/#/c/40296/
Edgar
On 8/15/14, 3:35 PM, Edgar Magana edgar.mag...@workday.com wrote:
Team,
I did a quick audit on the Neutron CI.
Ivar,
Very valid point. This is why I need clarification from those CI owner.
I will run a new test with a basic change in the Neutron DB code. That should
be covered by almost all CI systems.
Edgar
From: Ivar Lazzaro ivarlazz...@gmail.commailto:ivarlazz...@gmail.com
Reply-To: OpenStack
VMware minesweeper has filters which have been designed to cover the
largest possible subset of submissions without add unnecessary load to our
scarce resources for CI validation. This is probably why the analysis
reveals not all patches are covered.
Therefore our filters exclude neutral changes
That's great!
Also, I would suggest we decide on a 'standard' way for CI owners to
comunicate their CIs status (eg. MyCompany CI is not voting waiting for bug
#9001 to be fixed).
Using the ML for that may be confusing... What about an etherpad (linked
from [0]) or a dedicated section of [0]
On Aug 15, 2014, at 6:20 PM, Salvatore Orlando
sorla...@nicira.commailto:sorla...@nicira.com wrote:
The neutron full job is finally voting, and the first patch [1] has already
passed it in gate checks!
I've collected a few data points before it was switched to voting, and we
should probably
Looks like a good solution to me. If there are no philosophical objections to
it, I'll prepare a patch next week to make this happen.
-JB
-Original Message-
From: Clint Byrum [mailto:cl...@fewbar.com]
Sent: Friday, August 15, 2014 12:58 PM
To: openstack-dev
Subject: Re:
You didn't wait long enough for the Big Switch CI to reach your negative
test. :-)
Currently the CI system is backed by about 100 patches to push responses
out ~22 hours.
This does bring up an old discussion that was never resolved.
What is the minimum expected response time for CI systems?
On
Hi Edgar,
I am running the Nuage CI.
The Nuage CI has run and posted successfully the result for the first
review.
Because of infra issue(internet can be down, etc) we are running manually
the -1
-1 take some time away for developper and before doing a -1, I want to be
sure that it's a valid
Edgar:
For the Notes for the Cisco APIC, can you change the comment results are fake
to something like results are only valid for APIC-related commits? I think
this more accurately represents our current results (for reasons we chatted
about on another thread).
Thanks,
Dane
-Original
Also, you can add me as a contact person for the Cisco VPNaaS driver.
-Original Message-
From: Dane Leblanc (leblancd)
Sent: Friday, August 15, 2014 8:14 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [neutron] [third-party] What tests
Hi folks,
I'm OK with going with no shareable child entities (Listeners, Pools,
Members, TLS-related objects, L7-related objects, etc.). This will simplify
a lot of things (like status reporting), and we can probably safely work
under the assumption that any user who has a use case in which a
Hi, Edgar
MetapluginCI didn't run for document changes.
I changed filter so that CI run for ALL changes include documents.
Thanks,
Hirofumi
2014-08-16 7:35 GMT+09:00 Edgar Magana edgar.mag...@workday.com:
Team,
I did a quick audit on the Neutron CI. Very sad results. Only few plugins
and
+1 from me!!
On Fri, Aug 15, 2014 at 4:30 PM, Morgan Fainberg
morgan.fainb...@gmail.com wrote:
-Original Message-
From: Doug Hellmann d...@doughellmann.com
Reply: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: August 15, 2014 at
1 - 100 of 107 matches
Mail list logo
