On Fri, Aug 22, 2014 at 2:57 AM, Jay Pipes jaypi...@gmail.com wrote:
On 08/19/2014 11:28 PM, Robert Collins wrote:
On 20 August 2014 02:37, Jay Pipes jaypi...@gmail.com wrote:
...
I'd like to see more unification of implementations in TripleO - but I
still believe our basic principle of
Hi,
TripleO has a bridging script we use to register nodes with a baremetal
service (eg: Ironic or Nova-bm), called register-nodes, which given a
list of node descriptions (in JSON), will register them with the
appropriate baremetal service.
At the moment, if you run register-nodes a
Excerpts from Angus Salkeld's message of 2014-08-21 20:14:12 -0700:
On Fri, Aug 22, 2014 at 12:34 PM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Georgy Okrokvertskhov's message of 2014-08-20 13:14:28 -0700:
During last Atlanta summit there were couple discussions about
Application
On 21/08/14 18:05, Matthew Booth wrote:
[snip]
This seems to mean different things to different people. There's a list
here which contains some criteria for new commits:
[snip]
Any more of these?
There is also https://wiki.openstack.org/wiki/CodeReviewGuidelines
--
Radomir Dopieralski
Excerpts from Michael Chapman's message of 2014-08-21 23:30:44 -0700:
On Fri, Aug 22, 2014 at 2:57 AM, Jay Pipes jaypi...@gmail.com wrote:
On 08/19/2014 11:28 PM, Robert Collins wrote:
On 20 August 2014 02:37, Jay Pipes jaypi...@gmail.com wrote:
...
I'd like to see more unification
But I'm not sure the real problem to move the modules. My understanding is
- the ceilometer package has dependency with ceilometerclient so it is easy to
move them
- all callers for using the moved modules must change paths.
The modules you are talking about are part of Ceilometer's core
On 21 August 2014 18:47, Sergii Golovatiuk sgolovat...@mirantis.com wrote:
I think 15 minutes is not too bad. Additionally, it will reduce download
time and price for bandwidth. It's worth to leave lrzip for customers, as
upgrade is one time operation so user can wait for a while. For
Hi
When register-nodes blows up, is the error we get from Ironic sufficiently
unique that we can just consume it and move on?
I'm all for making the API more powerful wrt inspecting the current setup, but
I also like idempotency :)
Cheers,
--
Chris Jones
On 22 Aug 2014, at 07:32, Steve
On 08/20/2014 10:14 PM, Georgy Okrokvertskhov wrote:
During last Atlanta summit there were couple discussions about
Application Catalog and Application space projects in OpenStack. These
cross-project discussions occurred as a result of Murano incubation
request [1] during Icehouse cycle. On
On 22/08/14 17:35, Chris Jones wrote:
Hi
When register-nodes blows up, is the error we get from Ironic sufficiently
unique that we can just consume it and move on?
I'm all for making the API more powerful wrt inspecting the current setup, but
I also like idempotency :)
If the master nodes
Hi
Nice, sounds like a very good thing from an operator's perspective.
Cheers,
--
Chris Jones
On 22 Aug 2014, at 08:44, Steve Kowalik ste...@wedontsleep.org wrote:
On 22/08/14 17:35, Chris Jones wrote:
Hi
When register-nodes blows up, is the error we get from Ironic sufficiently
Thanks for your feedback.
No, I do not yet have code for it. Just wanted to get a feeling if such
a feature would get acceptance in the community.
But if that helps I can sit down and start some prototyping while I'm
preparing a blueprint spec in parallel.
The main part of the implementation
Dmitry, we already use lrzuntar in deploying Docker containers. Use a lower
compression ratio and it will decompress faster on virtual envs and it
takes under two mins on my virtual env.
Compress:
https://github.com/stackforge/fuel-main/blob/master/docker/module.mk#L27
Decompress:
+1
The agent number should be limited restrictly.
On Thu, Aug 21, 2014 at 8:56 AM, loy wolfe loywo...@gmail.com wrote:
On Wed, Aug 20, 2014 at 7:03 PM, Salvatore Orlando sorla...@nicira.com
wrote:
As the original thread had a completely different subject, I'm starting a
new one here.
On Thu, Aug 21, 2014 at 04:52:37PM -0500, Dolph Mathews wrote:
On Thu, Aug 21, 2014 at 11:53 AM, Daniel P. Berrange berra...@redhat.com
wrote:
On Thu, Aug 21, 2014 at 11:34:48AM -0500, Dolph Mathews wrote:
On Thu, Aug 21, 2014 at 11:21 AM, Daniel P. Berrange
berra...@redhat.com
On Thu, Aug 21, 2014 at 09:02:17AM -0700, Armando M. wrote:
Hi folks,
According to [1], we have ways to introduce external references to commit
messages.
These are useful to mark certain patches and their relevance in the context
of documentation, upgrades, etc.
I was wondering if it
Through my experience, RDO should be the most reliable way to do the
deployment.
Also, there're some more detailed installation scripts, like
https://github.com/ChaimaGhribi/OpenStack-Icehouse-Installation/blob/master/OpenStack-Icehouse-Installation.rst
.
Still, I think, as a developer, it would
Gordon, exactly. Moreover, I think percentage of failings is something
close to the 15-20% of all the runs - sometimes it passes for the change,
and next run on this exactly the same commit will be the failed for some
reason.
Thanks
Dina
On Thu, Aug 21, 2014 at 10:46 PM, gordon chung
I think 15 minutes is not too bad. Additionally, it will reduce download
time and price for bandwidth.
+1
But let's see if we can find some other solution still in 5.1 (hardlinks,
whatever else), and we obviously need to seriously address it in next
release.
Perhaps for 6 an option can be made
On Thu, Aug 21, 2014 at 05:05:04PM +0100, Matthew Booth wrote:
I would prefer that you didn't merge this.
i.e. The project is better off without it.
I'm not quite sure how you make that translation, I would interpret -2 as
meaning the project would be better off without a change.
FWIW, I've
hi,
On Wed, Aug 20, 2014 at 1:03 PM, Salvatore Orlando sorla...@nicira.com wrote:
As the original thread had a completely different subject, I'm starting a
new one here.
More specifically the aim of this thread is about:
1) Define when a service is best implemented with a service plugin or
TL;DR:
Let's create an Oslo projectgroup in Launchpad to track work across all
Oslo libraries. In library projects, let's use milestones connected to
published versions rather than the common milestones.
Long version:
As we graduate more Oslo libraries (which is awesome), tracking Oslo
work in
On Fri, Aug 22, 2014 at 10:49:51AM +0100, Steven Hardy wrote:
On Thu, Aug 21, 2014 at 05:05:04PM +0100, Matthew Booth wrote:
I also think it's worth explicitly documenting a few things we
might/should mention in a review, but which aren't a reason that the
project would be better off
Mike, others,
I believe Jesse was proposing an upgrade that downloads all the files
separately on the Fuel Master itself. This is a move that we've gone
away from since Fuel 2.0 because of intermittent issues with 3rd party
mirrors. It's often better to consume 1 large file that has everything
On Friday, August 22, 2014 2:55 PM, Dean Troyer wrote:
As one data point, the keystone middleware (auth_token) was just recently
moved out of keystoneclient
and into its own repo, partially because it had dependencies that otherwise
were not required for
pure client installations.
On Friday, August 22, 2014 4:15 PM, Nejc Saje wrote:
The modules you are talking about are part of Ceilometer's core
functionality, we can't move them to a completely separate code-tree
that is meant only for client functionality.
Thank you for the explanation! I understand your point of the
Sounds like a good plan going forward @ttx.
On Fri, Aug 22, 2014 at 5:59 AM, Thierry Carrez thie...@openstack.org wrote:
TL;DR:
Let's create an Oslo projectgroup in Launchpad to track work across all
Oslo libraries. In library projects, let's use milestones connected to
published versions
On 08/22/2014 11:59 AM, Thierry Carrez wrote:
TL;DR:
Let's create an Oslo projectgroup in Launchpad to track work across all
Oslo libraries. In library projects, let's use milestones connected to
published versions rather than the common milestones.
Long version:
As we graduate more Oslo
On 08/22/2014 01:30 AM, Michael Chapman wrote:
On Fri, Aug 22, 2014 at 2:57 AM, Jay Pipes jaypi...@gmail.com
mailto:jaypi...@gmail.com wrote:
On 08/19/2014 11:28 PM, Robert Collins wrote:
On 20 August 2014 02:37, Jay Pipes jaypi...@gmail.com
Earlier this week the freshness checks (the ones that required passing
results within 24 hrs for a change to go into the gate) were removed to
try to conserve nodes as we get to crunch time. The hopes were that
review teams had enough handle on what when code in their program got
into a state that
On Fri, Aug 22, 2014 at 07:09:10AM -0500, Sean Dague wrote:
Earlier this week the freshness checks (the ones that required passing
results within 24 hrs for a change to go into the gate) were removed to
try to conserve nodes as we get to crunch time. The hopes were that
review teams had enough
Hi everyone,
We all know being a project PTL is an extremely busy job. That's because
in our structure the PTL is responsible for almost everything in a project:
- Release management contact
- Work prioritization
- Keeping bugs under control
- Communicate about work being planned or done
- Make
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi all,
this week is quite bumpy for unit testing in gate. First, it was
upgrade to new 'tox' version that broke quite some branches.
And today new testtools 0.9.36 were released and were caught by gate,
which resulted in the following unit test
On Fri, Aug 22, 2014 at 4:53 PM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Angus Salkeld's message of 2014-08-21 20:14:12 -0700:
On Fri, Aug 22, 2014 at 12:34 PM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Georgy Okrokvertskhov's message of 2014-08-20 13:14:28
-0700:
Hey y'all,
We've started a screencast series on the StackTach.v3 dev efforts [1]. It's
still early-days, so subscribe to the playlist for updates.
The videos start with the StackTach/Ceilometer integration presentation at the
Hong Kong summit, which is useful for background and motivation but
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
UPD: probably pinning the version is really overkill here, and instead
we should fix affected branches. Among them: Havana for neutron,
Havana+Icehouse+Juno for Glance. Other projects may also be affected.
For Neutron, it should be handled by the
On 21/08/14 04:30, Thierry Carrez wrote:
Georgy Okrokvertskhov wrote:
During last Atlanta summit there were couple discussions about
Application Catalog and Application space projects in OpenStack. These
cross-project discussions occurred as a result of Murano incubation
request [1] during
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
[resending to include stable-maint.]
UPD: probably pinning the version is really overkill here, and instead
we should fix affected branches. Among them: Havana for neutron,
Havana+Icehouse+Juno for Glance. Other projects may also be affected.
For
On 08/22/2014 08:33 AM, Thierry Carrez wrote:
Hi everyone,
We all know being a project PTL is an extremely busy job. That's because
in our structure the PTL is responsible for almost everything in a project:
- Release management contact
- Work prioritization
- Keeping bugs under control
On 08/22/2014 09:40 AM, Russell Bryant wrote:
Another area worth calling out is a gate czar. Having someone who
understands infra and QA quite well and is regularly on top of the
status of the project in the gate is helpful and quite important.
Oops, you said this one, too. Anyway, +1.
--
On 08/22/2014 07:33 AM, Thierry Carrez wrote:
Hi everyone,
We all know being a project PTL is an extremely busy job. That's because
in our structure the PTL is responsible for almost everything in a project:
- Release management contact
- Work prioritization
- Keeping bugs under control
On Fri, Aug 22, 2014 at 02:33:27PM +0200, Thierry Carrez wrote:
Hi everyone,
We all know being a project PTL is an extremely busy job. That's because
in our structure the PTL is responsible for almost everything in a project:
- Release management contact
- Work prioritization
- Keeping
On 08/22/2014 02:33 PM, Thierry Carrez wrote:
Hi everyone,
We all know being a project PTL is an extremely busy job. That's because
in our structure the PTL is responsible for almost everything in a project:
- Release management contact
- Work prioritization
- Keeping bugs under control
Thank you for your response. Could this be done naturally with Openstack
neutron or have to be done manually outside neutron ? As we are expecting
to orchestrate hundreds of NFV with all similar network configuration,
programmability is another key element.
On Thu, Aug 21, 2014 at 3:52 PM,
Hi,
I couldn’t reproduce this issue either. I’ve tried on precise and on a fresh
trusty too, everything worked fine…
Cheers,
Ildikó
From: Dina Belova [mailto:dbel...@mirantis.com]
Sent: Friday, August 22, 2014 11:40 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject:
On 22/08/14 08:33, Thierry Carrez wrote:
Hi everyone,
We all know being a project PTL is an extremely busy job. That's because
in our structure the PTL is responsible for almost everything in a project:
- Release management contact
- Work prioritization
- Keeping bugs under control
-
Russell Bryant wrote:
On 08/22/2014 09:40 AM, Russell Bryant wrote:
Another area worth calling out is a gate czar. Having someone who
understands infra and QA quite well and is regularly on top of the
status of the project in the gate is helpful and quite important.
Oops, you said this
Daniel P. Berrange wrote:
On Fri, Aug 22, 2014 at 02:33:27PM +0200, Thierry Carrez wrote:
Hi everyone,
We all know being a project PTL is an extremely busy job. That's because
in our structure the PTL is responsible for almost everything in a project:
- Release management contact
- Work
Zane Bitter wrote:
On 22/08/14 08:33, Thierry Carrez wrote:
We also
still need someone to have the final say in case of deadlocked issues.
-1 we really don't.
I know we disagree on that :)
People say we don't have that many deadlocks in OpenStack for which the
PTL ultimate power is
On Tue, Jul 15, 2014 at 7:28 PM, Ian Wienand iwien...@redhat.com wrote:
On 07/15/2014 11:55 PM, Ken Giusti wrote:
Good to hear about epel's availability. But on the Ubuntu/Debian
side - is it possible to add the Qpid project's PPA to the config
project? From a quick 'grep' of the sources, it
I have no problem with the proposed change, so +1 from me. Doug's
probably the important one to hear from though, since you and he are the
ones who deal with this stuff the most. I think he's travelling today
so we'll see if he gets a chance to comment.
On 08/22/2014 04:59 AM, Thierry Carrez
At least for glance, the tox fix and the double setup problem are both
blocking the gate, so it isn't possible to fix cleanly, since both
issues need to be fixed in one commit - I think the correct thing is
to merge https://review.openstack.org/#/c/116267/ and give projects
time to fix up their
(response inline)
- Original Message -
From: Daniel P. Berrange berra...@redhat.com
To: Solly Ross sr...@redhat.com
Cc: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: Thursday, August 21, 2014 11:23:17 AM
Subject: Re:
On Fri, Aug 15, 2014 at 03:14:21PM -0400, 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
On Fri, Aug 22, 2014 at 11:32:31AM -0400, Solly Ross wrote:
(response inline)
- Original Message -
From: Daniel P. Berrange berra...@redhat.com
To: Solly Ross sr...@redhat.com
Cc: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
On 21 August 2014 19:39, gordon chung g...@live.ca wrote:
from the pov of a project that seems to be brought up constantly and maybe
it's my naivety, i don't really understand the fascination with branding and
the stigma people have placed on non-'openstack'/stackforge projects. it
can't be a
On Fri, 2014-08-22 at 11:01 -0400, Zane Bitter wrote:
I don't see that as something the wider OpenStack community needs to
dictate. We have a heavyweight election process for PTLs once every
cycle because that used to be the process for electing the TC. Now that
it no longer serves this
I would have to agree with Thomas.
Many organizations have already worked out strategies and have processes in
place to cover contributing to OpenStack which
Cover all official project. Contributing to additional non-OpenStack projects
may introduce additional barriers in large
Organizations
Dmitri,
Thanks for sharing this.
We discussed the details of what captured in the etherpad with the team today
and looks like folks support most of the ideas we came up with. Anyways, let’s
take a couple of days till the next team meeting on Monday to think it over,
discuss it all together
On 08/22/2014 08:33 AM, Thierry Carrez wrote:
Hi everyone,
We all know being a project PTL is an extremely busy job. That's because
in our structure the PTL is responsible for almost everything in a project:
- Release management contact
- Work prioritization
- Keeping bugs under control
-
On Fri, Aug 22, 2014 at 10:51 AM, Jay Pipes jaypi...@gmail.com wrote:
On 08/22/2014 08:33 AM, Thierry Carrez wrote:
Hi everyone,
We all know being a project PTL is an extremely busy job. That's because
in our structure the PTL is responsible for almost everything in a
project:
- Release
On Fri, Aug 22, 2014 at 9:51 PM, Sean Dague s...@dague.net wrote:
On 08/22/2014 01:30 AM, Michael Chapman wrote:
On Fri, Aug 22, 2014 at 2:57 AM, Jay Pipes jaypi...@gmail.com
mailto:jaypi...@gmail.com wrote:
On 08/19/2014 11:28 PM, Robert Collins wrote:
On 20 August
Many of us are still working on setting up and testing 3rd party ci for cinder
drivers.
None of them currently have gerrit +1/-1 voting, but I heard there's a plan to
disable those that are not working post-J3 (Please correct me if I
misunderstood).
However, Post-J3 is a great time to work on
On Fri, Aug 22, 2014, at 05:55 AM, Ihar Hrachyshka wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi all,
this week is quite bumpy for unit testing in gate. First, it was
upgrade to new 'tox' version that broke quite some branches.
I did a ton of work to make the tox upgrade go
On 22/08/14 12:45, Dolph Mathews wrote:
I'm all for getting a final decision, but a 'final' decision that has been
imposed from outside rather than internalised by the participants is...
rarely final.
The expectation of a PTL isn't to stomp around and make final decisions,
it's to step in when
It has been brought to my attention that Ironic uses the biggest hammer
in the IPMI toolbox to control chassis power:
https://git.openstack.org/cgit/openstack/ironic/tree/ironic/drivers/modules/ipminative.py#n142
Which is
ret = ipmicmd.set_power('off', wait)
This is the most abrupt form,
Comment inline.
On Aug 22, 2014, at 10:13 AM, Michael Chapman wop...@gmail.com wrote:
On Fri, Aug 22, 2014 at 9:51 PM, Sean Dague s...@dague.net wrote:
On 08/22/2014 01:30 AM, Michael Chapman wrote:
On Fri, Aug 22, 2014 at 2:57 AM, Jay Pipes jaypi...@gmail.com
On 08/22/2014 05:30 PM, Duncan Thomas wrote:
At least for glance, the tox fix and the double setup problem are both
blocking the gate, so it isn't possible to fix cleanly, since both
issues need to be fixed in one commit - I think the correct thing is
to merge
Excellent Job!
Thanks a lot, I have updated the wiki.
Edgar
From: Hemanth Ravi hemanthrav...@gmail.commailto:hemanthrav...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday,
Sorry my bad but I just changed.
Edgar
On 8/21/14, 2:13 PM, Dane Leblanc (leblancd) lebla...@cisco.com wrote:
Edgar:
I'm still seeing the comment Results are not accurate. Needs
clarification...
Dane
-Original Message-
From: Edgar Magana [mailto:edgar.mag...@workday.com]
Sent:
It may be easier for you, but it certainly isn't inside big companies,
e.g. HP have pretty broad approvals for contributing to (official)
openstack projects, where as individual approval may be needed to
contribute to none-openstack projects.
i was referring to a company bigger than hp...
On 08/22/2014 01:48 PM, Clint Byrum wrote:
It has been brought to my attention that Ironic uses the biggest hammer
in the IPMI toolbox to control chassis power:
https://git.openstack.org/cgit/openstack/ironic/tree/ironic/drivers/modules/ipminative.py#n142
Which is
ret =
I couldn’t reproduce this issue either. I’ve tried on precise and on a fresh
trusty too, everything worked fine…
fun
from the limited error message. it's because service path isn't found
(https://github.com/stackforge/wsme/blob/master/wsmeext/sphinxext.py#L133-L140)
and this code is returning
Excerpts from Jay Pipes's message of 2014-08-22 11:16:05 -0700:
On 08/22/2014 01:48 PM, Clint Byrum wrote:
It has been brought to my attention that Ironic uses the biggest hammer
in the IPMI toolbox to control chassis power:
Hi! Need to get the community to weigh in on this…
In Neutron there currently is no mock library for the Requests package. During
Icehouse, I created unit tests that used the httmock package (a context-library
based Requests mock). However, the community did not want me to add this to
global
Hi all -
I’ve spent many weeks on a series of patches for which the primary goal is to
provide very efficient patterns for tests that use databases and schemas within
those databases, including compatibility with parallel tests, transactional
testing, and scenario-driven testing (e.g. a test
We held the inaugural Heat mid-cycle meetup in Raleigh, North Carolina
this week. There were a dozen folks in attendance, and I think everyone
agreed that it was a very successful event. Notes from the meetup are on
the Etherpad here:
https://etherpad.openstack.org/p/heat-juno-midcycle-meetup
Hi,
Let me comment on the reasons why we’ve suggested adding Murano engine to
Orchestration program.
If we consider the previous Murano incubation discussions, we see that an
overlap with the Orchestration program was one of the TC’s concerns. We
also find that it was the Heat team that
On 08/22/2014 02:13 PM, Michael Chapman wrote:
We try to target puppet module master at upstream OpenStack master, but
without CI/CD we fall behind. The missing piece is building packages and
creating a local repo before doing the puppet run, which I'm working on
slowly as I want a single
Hi,
One of the things we've wanted for a while in some projects is a
completely separate database environment for each test when using MySQL.
To that end, I wrote a MySQL schema fixture that is in use in nodepool:
I put this in the review but will repeat it here. +1 to adding the
dependency with the tests that you've written to require it when those
tests have been reviewed and accepted. I don't have an objection to
adding requests-mock as a test-requirement.
Carl
On Fri, Aug 22, 2014 at 12:50 PM, Paul
Yes, you should be able to create a shared/external network within Neutron
to accomplish this.
On Fri, Aug 22, 2014 at 7:25 AM, Bao Wang bywan...@gmail.com wrote:
Thank you for your response. Could this be done naturally with Openstack
neutron or have to be done manually outside neutron ? As
On Fri, Aug 22, 2014 at 11:19 AM, Asselin, Ramy ramy.asse...@hp.com wrote:
Many of us are still working on setting up and testing 3rd party ci for
cinder drivers.
None of them currently have gerrit +1/-1 voting, but I heard there’s a
plan to “disable” those that are “not working” post-J3
On 23/08/14 00:09, Sean Dague wrote:
Earlier this week the freshness checks (the ones that required passing
results within 24 hrs for a change to go into the gate) were removed to
try to conserve nodes as we get to crunch time. The hopes were that
review teams had enough handle on what when
Here's an interesting fact about Zaqar (the project formerly known as
Marconi) that I hadn't thought about before this week: it's probably the
first OpenStack project where a major part of the API primarily faces
software running in the cloud rather than facing the user.
That is to say,
Over the past couple of release cycles, the TC has put together a fairly
comprehensive checklist for projects entering into incubation with a
view to being included in the integrated release. However, I'm not aware
of anything equivalent for projects that are becoming official (i.e.
moving to
Thanks Edgar for updating the APIC status!!!
Edgar and Kyle: *PLEASE NOTE** I need your understanding and
advice on the following:
We are still stuck with a problem stemming from a design limitation of Jenkins
that prevents us from being compliant with Neutron 3rd Party CI
/flame-on
Ok, this is funny to some of us in the community. The general populace of this
community is so against the idea of management that they will use the term for
a despotic dictator as a position name rather than manager. Sorry, but this
needed to be said.
/flame-off
Specific comments
Thanks for sending out, Arnaud. I added two to the etherpad for metadefs: the
glance client and related tempest patch.
Without the client, we can't get the related Horizon patches landed.
Glance Client: https://review.openstack.org/#/c/105231/
Tempest: https://review.openstack.org/113632/
Fungi (on irc) suggested the following option to run the tests without
reporting them to gerrit.
I’m still testing it out, but for the benefit of others using the “zuul” ci
approach, try the “silent” pipeline [1]
Thanks,
Ramy
On Fri, Aug 22, 2014 at 6:17 PM, Rochelle.RochelleGrober
rochelle.gro...@huawei.com wrote:
/flame-on
Ok, this is funny to some of us in the community. The general populace of
this community is so against the idea of management that they will use the
term for a despotic dictator as a
I think Anne makes some excellent points about the pattern being proposed being
unlikely to be commonly implemented across all the programs (or, at best, very
difficult). Let's not try to formalize another best practice that works many
times and force it to work every time. Here's an alternate
Excerpts from Steve Kowalik's message of 2014-08-22 06:32:04 +:
At the moment, if you run register-nodes a second time with the same
list of nodes, it will happily try and register them and then blow up
when Ironic or Nova-bm returns an error. If operators are going to
update their
On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery mest...@mestery.com wrote:
On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka ihrac...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 20/08/14 18:28, Salvatore Orlando wrote:
Some comments inline.
Salvatore
On 20 August
94 matches
Mail list logo
