confirmed
On 04/02/2015 02:46 PM, Mike Perez wrote:
> Hello all,
>
> I'm announcing my candidacy for Cinder PTL for the Liberty release.
>
> I have contributed to block storage in OpenStack since Bexar back when things
> were within nova-volume, before Cinder, and the honor of serving as PTL for
confirmed
On 04/02/2015 12:36 PM, Adrian Otto wrote:
> I respectfully respect your support to continue as your Magnum PTL.
>
> Here are are my achievements and OpenStack experience and that make me the
> best choice for this role:
>
> * Founder of the OpenStack Containers Team
> * Established v
hi,
i'd like to announce my candidacy for PTL of Ceilometer.
as a quick introduction, i've been a contributor in OpenStack for the past few
years and for the majority of that time i've been primarily focused on
Ceilometer where i contribute regularly to the project with code[1] and
reviews[2]. i
Hello Everyone!
It’s been an exciting development cycle (Kilo) and it is now time to start
looking forward at Liberty and what that will hold. With that said, I’d
like to ask for the community’s support to continue as the Keystone PTL for
the Liberty release cycle.
I came to the table last cy
On 00:21 Tue 31 Mar , Rochelle Grober wrote:
> Top posting… I believe the main issue was a problem with snapshots that
> caused false negatives for most cinder drivers. But, that got fixed.
I don't know what you're talking about here. Are you saying there was an
issue with the Tempest tests t
On 14:14 Thu 02 Apr , Marcus Vinícius Ramires do Nascimento wrote:
> Hi Mike,
>
> I'm working on test coverage improvement for HDS/Hitachi drivers. As I
> talked to you in #openstack-cinder channel, I'm facing troubles with 3
> tests (apparently those fails are not related to the driver) and I
I would like to announce my candidacy for the Infrastructure PTL.
I have developed and operated the project infrastructure for several
years and have been honored to serve as the PTL for the Kilo cycle.
I was instrumental not only in creating the project gating system and
development process, but
Team, thanks for your input so far, I flashed out one more section, please take
a look and comment
https://docs.google.com/a/stackstorm.com/document/d/1Gy6V9YBt8W4llyErO_itHetkF1oNYv4ka-_5LdFKA18/edit#heading=h.n1jc8i9qhikt
DZ.
On Mar 25, 2015, at 9:41 AM, Dmitri Zimine wrote:
> Folks,
>
>
Hi stackers,
Recently, I started working on speeding up Rally cli.
What I understand immediately is that I don't understand why it takes
700-800ms
to just run "rally version" command and it is impossible hard task to find
what takes so much time just by reading the code.
I started playing with
On Thu, Apr 2, 2015 at 4:52 PM, Boris Pavlovic wrote:
> Hi stackers,
>
> Recently, I started working on speeding up Rally cli.
>
> What I understand immediately is that I don't understand why it takes
> 700-800ms
> to just run "rally version" command and it is impossible hard task to find
> what
A few of us have been looking for a way to perform software updates to
servers in a TripleO Heat/Puppet-based overcloud that avoids an
impedance mismatch with Heat concepts and how Heat runs its workflow. As
many talented TripleO-ers who have gone before can probably testify,
that's surprisingl
On 04/02/2015 04:31 PM, Morgan Fainberg wrote:
Hello Everyone!
It’s been an exciting development cycle (Kilo) and it is now time to
start looking forward at Liberty and what that will hold. With that
said, I’d like to ask for the community’s support to continue as the
Keystone PTL for the Li
On 04/02/2015 06:22 PM, Brant Knudson wrote:
> On Thu, Apr 2, 2015 at 4:52 PM, Boris Pavlovic wrote:
>
>> Hi stackers,
>>
>> Recently, I started working on speeding up Rally cli.
>>
>> What I understand immediately is that I don't understand why it takes
>> 700-800ms
>> to just run "rally versio
On 2015-04-02 19:32:52 -0400 (-0400), Adam Young wrote:
> Please vote for Morgan.
Please refrain from distributing campaign literature, placing
political advertising or soliciting votes within 25 meters of the
polling place. ;)
--
Jeremy Stanley
__
I'm not sure how to feel about this... Its clever...
It kind of feels like your really trying to be able to register 'actions' in
heat so that heat users can poke the vm's to do something... For example
"perform a chef run".
While using stack updates listed below could be made to work, is that
Hi all,
We are scheduled to publish 2014.2.3 on Thursday April 9th for
Ceilometer, Cinder, Glance, Heat, Horizon, Keystone, Neutron, Nova,
Sahara and Trove.
We'd appreciate anyone who could test the candidate 2014.2.3 tarballs, which
include all changes aside from any pending freeze exceptions:
hi there,
thanks for sharing this, I have a
On 04/03/2015 12:31 AM, Zane Bitter wrote:
A few of us have been looking for a way to perform software updates to
servers in a TripleO Heat/Puppet-based overcloud
[...]
Here's a trivial example of what this deployment might look like:
update_c
Hi,
This is regarding bug - https://bugs.launchpad.net/tempest/+bug/1436314
When Nova is configured to boot VM from volume only, current Tempest
integration tests will fails. We are not sure how feasible and valid this
configuration is for Nova and what are the use cases of this.
Before starting
Hi,
On Fri, Apr 3, 2015 at 1:31 AM, Zane Bitter wrote:
> A few of us have been looking for a way to perform software updates to
> servers in a TripleO Heat/Puppet-based overcloud that avoids an impedance
> mismatch with Heat concepts and how Heat runs its workflow. As many
> talented TripleO-ers
Hello Folks,
I'd like to request a freeze exception for the following changeset:
https://review.openstack.org/169844
I believe that's an unharmful change, I apologize for getting it under
review so late :)
Ivar.
__
OpenStac
101 - 120 of 120 matches
Mail list logo
