Hi,
I think we are ready for rename, but need Matt's confirmation.
@mattray, since March 27 is the day to create havana-stable branch, I
think we have enough time to test/review renamed telemetry cookbook.
After renaming, I will open the rename-change in
openstack-infra/config project to review,
+1
Attending
--
Trinath Somanchi - B39208
trinath.soman...@freescale.com | extn: 4048
-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: Monday, March 10, 2014 9:30 PM
To: OpenStack Development Mailing List; openstack-infra
Subject: [OpenStack-Infra] [3rd party test
Hi Roey,
Thanks for the tip. I have made the change according to your suggestion and
fired off tests for overnight test. Will let you know in the morning if
this fixes the issue.
Thanks
-Sukhdev
On Mon, Mar 10, 2014 at 4:17 PM, Roey Chen wrote:
> Hi,
>
> Hope this could help,
>
> I've enc
We've gotten confirmation that the Sahara (formerly Savanna)
projects are ready to be renamed and are planning to do that on
fairly short notice, Wednesday (March 12th) at 12:00 UTC. I can
incorporate a rename for stackforge/cookbook-openstack-metering to
stackforge/cookbook-openstack-telemetry at
The Gerrit service on review.openstack.org will be unavailable
briefly on Wednesday, March 12 between 12:00 to 12:30 UTC:
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140312T12&am=30 >
This maintenance will cover renaming for Sahara (formerly Savanna)
projects and possibly also some
Hi,
Hope this could help,
I've encountered this issue myself not to long ago on Ubuntu 12.04 host,
it didn't happen again after messing with the Kernel Semaphore Limits
parameters [1]:
Adding this [2] line to `/etc/sysctl.conf` seems to do the trick.
- Roey
[1] http://paste.openstack.org/sh
Sean, John:
I’ve had a similar experience as Sukhdev… I had tried doing clean.sh on every
run, but that didn’t help prevent the tgt problem, and it doesn’t help recover
from it.
Sounds like the best option is to reset the VM for each run.
Thanks,
Dane
From: Sukhdev Kapur [mailto:sukhdevka...@g
On Mon, Mar 10, 2014 at 2:17 PM, Sukhdev Kapur wrote:
> I should have clarified. In my case it is identical - once it hits the
> failure, after that it is always 100% of time failure - i.e. every run
> fails after that.
>
> HTH
> -Sukhdev
>
>
>
> On Mon, Mar 10, 2014 at 12:00 PM, Dane Leblanc (leb
Hi Sean,
In my case, for every run, I do unstack.sh, clean.sh, sudo rm -rf devstack,
sudo rm -rf /opt/stack.
Then I go get everything fresh and stack.sh, and a full run of smoke tests
Few iterations of this sequence will get you into this condition. Once in
this condition - clean.sh and unstack.sh
I should have clarified. In my case it is identical - once it hits the
failure, after that it is always 100% of time failure - i.e. every run
fails after that.
HTH
-Sukhdev
On Mon, Mar 10, 2014 at 12:00 PM, Dane Leblanc (leblancd) <
lebla...@cisco.com> wrote:
> In my case, the base OS is 12.04
So, honestly, running stack.sh / unstack.sh that many times in a row
really isn't expected to work in my experience. You should at minimum be
doing ./clean.sh to try to reset the state further.
-Sean
On 03/10/2014 03:00 PM, Dane Leblanc (leblancd) wrote:
> In my case, the base OS is 12.04
In my case, the base OS is 12.04 Precise.
The problem is intermittent in that it takes maybe 15 to 20 cycles of
unstack/stack to get it into the failure mode, but once in the failure mode, it
appears that tgt daemon is 100% dead-in-the-water.
-Original Message-
From: Sean Dague [mailto:
Hi Sean,
All the failures I have seen are on Ubuntu 13.10. They are not always 100%.
Very intermittent. This failure occurs once after every 10-20 runsthat
is why I have not been able to nail it down :-):-)
Every time the error occurs - if reboot the VM it clears up and is good for
another 10-
Quick reminder that this is coming up tomorrow, Tuesday March 11th at 17:00 UTC.
I've tossed a skeleton etherpad up here now, I will be filling in with
last bug day notes this evening + tomorrow morning:
https://etherpad.openstack.org/p/cibugreview-march2014
--
Elizabeth Krumbach Joseph || Lyz
What base OS? A change was made there recently to better handle debian
because we believed (possibly incorrectly) that precise actually had
working init scripts.
It would be interesting to understand if this was a 100% failure, or
only intermittent, and what base OS it was on.
-Sean
On 0
Hi everyone,
The OpenStack Infrastructure (Infra) team is hosting our weekly
meeting tomorrow, Tuesday March 11th, at 19:00 UTC in
#openstack-meeting
Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is
welcome to to add agenda items)
Everyone inter
Hey Rafael,
If it helps any, I have noticed that this issue generally occurs after
several runs of tempest tests. I run all smoke tests. I have been always
suspicious that some new test got added which is not cleaning up
afterwards. Can you point me to which tempest test corresponds to
test_boot_
This looks very familiar
https://bugzilla.redhat.com/show_bug.cgi?id=848942
I'm not sure this is exactly the same bahavior, try turning debug messages
on by adding -d to the tgtd start.
I'm investigating a similar issue with tgt on test_boot_pattern test. It
turns out that the file written to t
I see the same issue. This issue has crept in during the latest flurry of
check-ins. I started noticing this issue a day or two before the Icehouse
Feature Freeze deadline.
I tried restarting tgt as well, but, it does not help.
However, rebooting the VM helps clear it up.
Has anybody else seen i
Hi Stackers,
We'll be having our second weekly Q&A/workshop session around third
party testing today at 14:00 EST / 18:00 UTC in #openstack-meeting on
Freenode IRC. See you all there.
Best,
-jay
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.o
I don't know if anyone can give me some troubleshooting advice with this issue.
I'm seeing an occasional problem whereby after several DevStack
unstack.sh/stack.sh cycles, the tgt daemon (tgtd) fails to start during Cinder
startup. Here's a snippet from the stack.sh log:
2014-03-10 07:09:45.21
21 matches
Mail list logo
