[openstack-dev] [Nova] Core review request

2013-09-17 Thread Gary Kotton
Hi,
Can a core reviewer please look at https://review.openstack.org/#/c/45691/. The 
has one +2 and a number of +1's
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [QA] Nova API List for Missing Tempest Tests

2013-09-17 Thread Masayuki Igawa
Hi, Tempest developers

I have made:
 Nova API List for Missing Tempest Tests.
 
https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWc

This list shows what we should test. That is:
 * Nova has 250 APIs(not include v3 APIs).
 * 117 APIs are executed(maybe tested).
 * 73 APIs are not executed.
 * 60 APIs are not executed. But they maybe not need to test.
 - Because they are deprecated APIs such as nova-network and volume.

So I think we need more tempest test cases.
If this idea is acceptable, can you put your name to 'assignee' at your 
favorites,
and implement tempest tests.

Any comments are welcome.

Additional information:
 I made this API list with modification of nova's code that based on 
 https://review.openstack.org/#/c/25882/ (Abandoned).

Best Regards,
-- Masayuki Igawa



smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] python-simplejson 2.0.0 errors

2013-09-17 Thread Thomas Goirand
Thanks Monty for your reply.

On 09/16/2013 11:32 AM, Monty Taylor wrote:
 I suggest you add SKIP_PIP_INSTALL=1 to the debian/rules files on all of
 the OpenStack things you are packaging - I think it will make things
 like that go away - since you are processing depends at the apt side,
 there is no need to process them at the python level at runtime too.

Well, by adding SKIP_PIP_INSTALL, the risk is that I might not see a
missing dependency. Sometimes, I just forget one when parsing manually
the requirements.txt files in order to fix the Debian (build-)depends.
So, having pip trying to check for missing requirements is good for me
as it will show in the build log if something is downloaded, and even,
fail the build if done in a buildd (which has on purpose no network on
purpose).

Cheers,

Thomas


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] python-simplejson 2.0.0 errors

2013-09-17 Thread Thomas Goirand
On 09/16/2013 10:41 PM, Bhuvan Arumugam wrote:
 It's fun out of inter dependencies. Nova depends on python-glanceclient;
 python-glanceclient depends on warlock=1.0.1,2. warlock depends on
 jsonschema=0.7,2 (warlock 1.0.0). The latest warlock depends on newer
 jsonschema release (=0.7,3). To fix your issue, you may do one of
 following workaround:
 
 1. upgrade warlock to latest (sudo pip install warlock --upgrade)
 2. downgrade jsonschema to earlier release v1.3.0 (sudo pip uninstall
 jsonschema; sudo pip install jsonschema==1.3.0)
 3. install newer python-glanceclient. It depends on newer warlock (sudo
 pip install python-glanceclient --upgrade)
 
 References:
 https://github.com/openstack/python-glanceclient/blob/master/requirements.txt
 https://github.com/bcwaldon/warlock/blob/master/requirements.txt
 
 Thank you,
 Bhuvan

Thanks a lot for the above insightful comment. I will update both
warlock and glanceclient.

Cheers,

Thomas Goirand (zigo)


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Tuskar] All needed Tuskar metrics and alerts mapped to what Ceilometer supports

2013-09-17 Thread Ladislav Smola

Confirmation about the metrics of Hardware agent (Baremetal agent)
=

It is collecting:
- cpu, memoryspace, diskspace, network traffic (the same agent will be 
running on all services, collecting the same data)


It should be running on:
- the physical servers on which Glance, Cinder, Quantum, Swift, Nova 
compute node and Nova controller runs
- the network devices used in the OpenStack environment (switches, 
firewalls ...)


Supported metrics


* CPU utilisation for each CPU (percentage) (as cpu.util.1min, 
cpu.util.5min, cpu.util.15min )

* RAM utilisation (GB) (as memory.size.total, memory.size.used )
* Disk utilisation (GB) (as disk.size.total, disk.size.used)
* Incoming traffic for each NIC (Mbps) (as network.incoming.bytes)
* Outgoing traffic for each NIC (Mbps) (as network.outgoing.bytes)
- also track network.outgoing.errors, network.bandwidth.bytes
* Swap utilisation (GB)
- this should be part of Disk utilisation, we will just have to 
recognize the swap disk
* Number of currently running instances and the associated 
flavours(Ceilometer-Nova
  using instance:type and group_by resource_id) - This info will be 
queried from Overcloud Ceilometer


Missing metrics

* System load -- see /proc/loadavg (percentage)

as described here 
https://blueprints.launchpad.net/ceilometer/+spec/monitoring-physical-devices





On 09/16/2013 04:10 PM, Ladislav Smola wrote:

Hello,

this is follow up of T.Sedovic old email, trying to identify all 
metrics, we will need to track for Tuskar.
The Ceilometer API for Horizon is now in progress, so we have time to 
finish the list of metrics
and alarms we need. That may also raise the requests for some 
Ceilometer API optimization


This is meant for the open conversation, that will lead to the final list.


Measurements
=

The old list sent by tsedovic:
-

* CPU utilisation for each CPU (percentage) (Ceilometer-Nova as cpu_util)
* RAM utilisation (GB) (Ceilometer-Nova as memory)
- I do just assume, this is the used value and total value can be got 
from the service itself,

  needs confirmation
* Swap utilisation (GB) (Ceilometer-Nova as disk.ephemeral.size)
- I do just assume, this is the used value and total value can be got 
from the service itself,

  needs confirmation
* Disk utilisation (GB) (Ceilometer-Cinder as volume.size and 
Ceilometer-Swift as storage.objects.size)
- I do just assume, this is the used value and total value can be got 
from the service itself,

  needs confirmation
* System load -- see /proc/loadavg (percentage) (--)
* Incoming traffic for each NIC (Mbps) ( Ceilometer-Nova as 
network.incoming.bytes)
* Outgoing traffic for each NIC (Mbps) (Ceilometer-Nova as 
network.outgoing.bytes)
- It is connected to VM interface now, I do expect Baremetal 
agent(Hardware agent) will use NICs,

  needs confirmation
* Number of currently running instances and the associated 
flavours(Ceilometer-Nova

  using instance:type and group_by resource_id)


The additional meters used in wireframes
-

jcoufal could you add the additional measurements from the last 
wireframes?



The measurements the Ceilometer supports now
---

http://docs.openstack.org/developer/ceilometer/measurements.html

Feel free to include the others into wireframes jcoufal (I guess there 
will have to be different
overview pages for different Resource Classes, based on their service 
type)


I am in the process of finding out, whether all off this measurements 
will be also collected by the
Baremetal agent(Hardware agent). But I would say yes, from the 
description it has (except the VM

specific metrics like vcpusI guess)

The missing meters
-

We will have to probably implement these (meaning implementing a 
pollsters for the Baremetal

agent(Hardware agent), that will collect these metrics)

* System load -- see /proc/loadavg (percentage) (probably for all 
services?)


- Please add other Baremetal metrics you think we will need.


Alerts


Setting and Alarm
---

Simplified explanation of setting the alarm:
In order to have alerts, you have to set an alarm first. Alarm can 
contain any statistics query,
a threshold and an operator. (e.g. fire alarm when avg cpu_util  90% 
on all instances of project_1).
We can combine more alarms into one complex alarm. And you can browse 
alarms.

(There can be actions set up on alarm, but more about that later.)

Showing alerts
---

1. I would be bold enough to distinguish system-meter (e.g. similar to 
cpu_util  90%, are used
for Heat autoscaling). And user-defined-meter (the ones defined in 
UI). Will we show both in
the UI? Probably in different sections. System meters will require 
extra caution.


2. For the table view of alarms, I would see it as 

[openstack-dev] [Heat] question about stack updates, instance groups and wait conditions

2013-09-17 Thread Simon Pasquier

Hello,

I'm testing stack updates with instance group and wait conditions and 
I'd like to get feedback from the Heat community.


My template declares an instance group resource with size = N and a wait 
condition resource with count = N (N being passed as a parameter of the 
template). Each group's instance is calling cfn-signal (with a different 
id!) at the end of the user data script and my stack creates with no error.


Now when I update my stack to run N+X instances, the instance group gets 
updated with size=N+X but since the wait condition is deleted and 
recreated, the count value should either be updated to X or my existing 
instances should re-execute cfn-signal.


To cope with this situation, I've found 2 options:
1/ declare 2 parameters in my template: nb of instances (N for creation, 
N+X for update) and count of wait conditions (N for creation, X for 
update). See [1] for the details.
2/ declare only one parameter in my template (the size of the group) and 
leverage cfn-hup on the existing instances to re-execute cfn-signal. See 
[2] for the details.


The solution 1 is not really user-friendly and I found that solution 2 
is a bit complicated. Does anybody know a simpler way to achieve the 
same result?


Regards,

[1] http://paste.openstack.org/show/47142/
[2] http://paste.openstack.org/show/47148/
--
Simon Pasquier
Software Engineer
Bull, Architect of an Open World
Phone: + 33 4 76 29 71 49
http://www.bull.com

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] python-simplejson 2.0.0 errors

2013-09-17 Thread Monty Taylor


On 09/17/2013 08:06 AM, Thomas Goirand wrote:
 On 09/17/2013 06:52 PM, Thomas Goirand wrote:
 On 09/16/2013 10:41 PM, Bhuvan Arumugam wrote:
 It's fun out of inter dependencies. Nova depends on python-glanceclient;
 python-glanceclient depends on warlock=1.0.1,2. warlock depends on
 jsonschema=0.7,2 (warlock 1.0.0). The latest warlock depends on newer
 jsonschema release (=0.7,3). To fix your issue, you may do one of
 following workaround:

 1. upgrade warlock to latest (sudo pip install warlock --upgrade)
 2. downgrade jsonschema to earlier release v1.3.0 (sudo pip uninstall
 jsonschema; sudo pip install jsonschema==1.3.0)
 3. install newer python-glanceclient. It depends on newer warlock (sudo
 pip install python-glanceclient --upgrade)

 References:
 https://github.com/openstack/python-glanceclient/blob/master/requirements.txt
 https://github.com/bcwaldon/warlock/blob/master/requirements.txt

 Thank you,
 Bhuvan

 Thanks a lot for the above insightful comment. I will update both
 warlock and glanceclient.

 Cheers,

 Thomas Goirand (zigo)
 
 Hi,
 
 It appears that the problem was I didn't rebuild warlock and
 glanceclient on my Jenkins, therefore I had an old version in there (my
 Havana Jenkins package builder for Wheezy VM doesn't have build on git
 push activated yet), even though the packages were updated already.
 
 After rebuilding glanceclient and warlock, everything is back to
 working, and now there is not a single error in the the 8885 unit tests
 of Nova Havana b3.
 
 So, thanks a lot for the (very useful) hint!!!

WOOHOO!

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] Scheduler sub-group meeting on 9/17

2013-09-17 Thread Gary Kotton
Hi,
Don is on vacation. Lets try and have the meeting today.
Topics that come to mind:

 1.  https://etherpad.openstack.org/IceHouse-Nova-Scheduler-Sessions
*   We discussed this extensively last week. Are there any open issues 
related to this
 2.  Discuss resource tracking (alaski)
 3.  Discuss 
https://docs.google.com/document/d/1hQQGHId-z1A5LOipnBXFhsU3VAMQdSe-UXvL4VPY4ps/edit
 (Mike Spreitzer) [I am unable to access the document]
 4.  Open issues

Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [CI][Ceilometer] Please help to understand why migrations are (not?) working in gate-tempest-devstack-vm-full

2013-09-17 Thread Thierry Carrez
Jay Pipes wrote:
 [...]
 Any and all insight would be greatly appreciated.

Not really an insight, but looks like another occurrence of:
https://bugs.launchpad.net/ceilometer/+bug/1221580

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat] [scheduler] Bringing things together for Icehouse

2013-09-17 Thread Mike Spreitzer
Fixed, sorry.




From:   Gary Kotton gkot...@vmware.com
To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.org, 
Date:   09/17/2013 03:26 AM
Subject:Re: [openstack-dev] [heat] [scheduler] Bringing things 
together for Icehouse



Hi,
The document is locked.
Thanks
Gary

From: Mike Spreitzer mspre...@us.ibm.com
Reply-To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.org
Date: Tuesday, September 17, 2013 8:00 AM
To: OpenStack Development Mailing List openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [heat] [scheduler] Bringing things together 
for Icehouse

I have written a brief document, with pictures.  See 
https://docs.google.com/document/d/1hQQGHId-z1A5LOipnBXFhsU3VAMQdSe-UXvL4VPY4ps


Regards, 
Mike___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Tuskar] Tuskar Names Clarification Unification

2013-09-17 Thread Tomas Sedovic

On 09/17/2013 04:17 AM, Jaromir Coufal wrote:


On 2013/16/09 15:11, Tomas Sedovic wrote:

On 09/16/2013 05:50 PM, Jaromir Coufal wrote:

Hi,

after few days of gathering information, it looks that no more new ideas
appear there, so let's take the last round of voting for names which you
prefer. It's important for us to get on the same page.

https://etherpad.openstack.org/tuskar-naming

Thanks guys
-- Jarda


Thanks Jarda,

I was thinking we could do the voting during the weekly IRC meeting
(the bot has some cool voting capabilities).

Unfortunately, I've fallen ill and chances are I won't be able to
drive the meeting. If you folks want to self-organise and start the
vote, you have my blessing.

Otherwise, shall we do it on the IRC meeting after that?

T.

Sure Thomas, thanks for following the thread. We can try to
self-organize there, I might try to run it, just can you point me to bot
commands?

Get well soon


Thanks.

Here's the manual:

http://meetbot.debian.net/Manual.html

The most important commands are:

#startmeeting tuskar

#topic an item from the agenda

#info an item to be listed in the meeting minutes

#agreed whatever the people agreed to do

#action nick an action the person is supposed to take

#endmeeting

If you scroll to the last section of the Heat meeting page, they have 
some instructions on running the meetings:


https://wiki.openstack.org/wiki/Meetings/HeatAgenda



-- Jarda

[snip]



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] OpenStack Heat - Email deleted by mistake

2013-09-17 Thread GROSZ, Maty (Maty)
All,

Earlier this morning (Middle east time) we received an email regarding a Heat 
document that is kept within Google by openstack-dev mailing list.
I have deleted it by mistake (still waiting for the writer approval to open the 
document).
Can someone re-send this email to me?

Thanks,

Maty.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] Hyper-V meeting agenda

2013-09-17 Thread Peter Pouliot
Hi All,
Here is the agenda for today's Hyper-v meeting.


* Project update

* Server 2012R2 Testing

* Puppet module status



Cheers,

p

Peter J. Pouliot, CISSP
Senior SDET, OpenStack

Microsoft
New England Research  Development Center
One Memorial Drive,Cambridge, MA 02142
ppoul...@microsoft.commailto:ppoul...@microsoft.com | Tel: +1(857) 453 6436

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Tuskar] Tuskar Names Clarification Unification

2013-09-17 Thread Tomas Sedovic

On 09/17/2013 04:53 AM, Mike Spreitzer wrote:


  From: Jaromir Coufal jcou...@redhat.com
  To: openstack-dev@lists.openstack.org,
  Date: 09/16/2013 11:51 AM
  Subject: Re: [openstack-dev] [Tuskar] Tuskar Names Clarification 
Unification
 
  Hi,
 
  after few days of gathering information, it looks that no more new
  ideas appear there, so let's take the last round of voting for names
  which you prefer. It's important for us to get on the same page.

I am concerned that the proposals around the term 'rack' do not
recognize that there might be more than one layer in the organization.

Is it more important to get appropriately abstract and generic terms, or
is the desire to match common concrete terms?



So our thinking here is to work with a grouping of nodes in the same 
physical location, the same subnet and ideally the same hardware 
configuration.


This can be a physical rack, or what I believe you call a chassis (a 
group of servers inside the rack).


Regarding layers, I see two physical layers in play: a rack and a 
chassis. Could there be more?


The idea right now is that the Tuskar admins would choose their 
preferred granularity and just work on that level.


Do you think that's not sufficient?

T.


Regards,
Mike


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] OpenStack Heat - Email deleted by mistake

2013-09-17 Thread GROSZ, Maty (Maty)
Thank you very much!

From: Davanum Srinivas [mailto:dava...@gmail.com]
Sent: Tuesday, September 17, 2013 18:50
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] OpenStack Heat - Email deleted by mistake

You can always browse the mail archives - example - 
http://markmail.org/message/ipxidqilexo7pann

On Tue, Sep 17, 2013 at 11:30 AM, GROSZ, Maty (Maty) 
maty.gr...@alcatel-lucent.commailto:maty.gr...@alcatel-lucent.com wrote:
All,

Earlier this morning (Middle east time) we received an email regarding a Heat 
document that is kept within Google by openstack-dev mailing list.
I have deleted it by mistake (still waiting for the writer approval to open the 
document).
Can someone re-send this email to me?

Thanks,

Maty.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Davanum Srinivas :: http://davanum.wordpress.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [TRIPLEO] Two * +2's required now.

2013-09-17 Thread Robert Collins
Hi, for a while now TripleO has been running with just one +2, due to
small core team size; we're still a little small, but at the sprint
the question was raised about moving to 2 +2's to land changes
(ignoring trivial rebases that just need to be kicked etc).

There was consensus that this is ok, but we will need to be on top of
things to keep velocity up.

So - if you're in TripleO-core, please stop approving reviews unless
you're the second +2er. You may also want to allocate more time to do
reviews, as per-reviewer load will now be twice what it was.

Thanks!

-Rob

-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] OpenStack Hyper-V Meeting Minutes

2013-09-17 Thread Peter Pouliot
Hi All,

Here are the meeting minutes from today's Hyper-V meeting.

Meeting ended Tue Sep 17 16:49:51 2013 UTC.  Information about MeetBot at 
http://wiki.debian.org/MeetBot . (v 0.1.4)
Minutes:
http://eavesdrop.openstack.org/meetings/hyper_v/2013/hyper_v.2013-09-17-16.01.html
Minutes (text): 
http://eavesdrop.openstack.org/meetings/hyper_v/2013/hyper_v.2013-09-17-16.01.txt
Log:
http://eavesdrop.openstack.org/meetings/hyper_v/2013/hyper_v.2013-09-17-16.01.log.html


Peter J. Pouliot, CISSP
Senior SDET, OpenStack

Microsoft
New England Research  Development Center
One Memorial Drive,Cambridge, MA 02142
ppoul...@microsoft.commailto:ppoul...@microsoft.com | Tel: +1(857) 453 6436

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Raksha] Proposal for Raksha, a Data Protection As a Service project

2013-09-17 Thread Giri Basava
Dear All,

As a follow-up to the Rakshahttps://wiki.openstack.org/wiki/Raksha proposal, 
we checked in a “prototype” code into github.  Here are the links for the wiki 
and github source code…

   Raksha project wiki – http://wiki.openstack.com/wiki/raksha
   Raksha github:
◦  Raksha service - http://github.com/dpaas-raksha/raksha
◦  Raksha client – http://github.com/dpaas-raksha/python-client
◦  Raksha dashboard – http://github.com/dpaas-raksha/horizon
◦  Raksha devstack – http://github.com/dpaas-raksha/devstack

Finally, please also take a look at this short video that demonstrates the key 
features of Raksha.  Raksha Demohttp://www.youtube.com/watch?v=Tc8k_7BIaEc

Please note that this is still work in progress that requires integration with 
neutron and vm metadata backup etc

After the initial proposal of Raksha, there is an excellent dialog and feedback 
from the community…


1.   Better integration with Cinder backup APIs.

2.   Leverage TaskFlow

3.   Explore integration with Heat.

To address the above and any additional improvements, we would like the 
community to participate and contribute. Also here is a proposal for the 
Icehouse Design Summit Topic “http://summit.openstack.org/cfp/details/88” 
Looking forward to have a great dialog at the summit.

Regards,
Giri


From: Murali Balcha [mailto:murali.bal...@triliodata.com]
Sent: Wednesday, August 28, 2013 3:13 PM
To: openstack-dev@lists.openstack.org; openst...@list.openstack.org
Subject: [openstack-dev] Proposal for Raksha, a Data Protection As a Service 
project

Hello Stackers,
We would like to introduce a new project Raksha, a Data Protection As a Service 
(DPaaS) for OpenStack Cloud.
Raksha’s primary goal is to provide a comprehensive Data Protection for 
OpenStack by leveraging Nova, Swift, Glance and Cinder. Raksha has following 
key features:

1.   Provide an enterprise grade data protection for OpenStack based clouds

2.   Tenant administered backups and restores

3.   Application consistent backups

4.   Point In Time(PiT) full and incremental backups and restores

5.   Dedupe at source for efficient backups

6.   A job scheduler for periodic backups

7.   Noninvasive backup solution that does not require service interruption 
during backup window

You will find the rationale behind the need for Raksha in OpenStack in its 
Wiki. The wiki also has the preliminary design and the API description.  Some 
of the Raksha functionality may overlap with Nova and Cinder projects and as a 
community lets work together to coordinate the features among these projects. 
We would like to seek out early feedback so we can address as many issues as we 
can in the first code drop. We are hoping to enlist the OpenStack community 
help in making Raksha a part of OpenStack.
Raksha’s project resources:
Wiki: https://wiki.openstack.org/wiki/Raksha
Launchpad: https://launchpad.net/raksha
Github: https://github.com/DPaaS-Raksha/Raksha (We will upload a prototype code 
in few days)
If you want to talk to us, send an email to 
openstack-...@lists.launchpad.netmailto:openstack-...@lists.launchpad.net 
with [raksha] in the subject or use #openstack-raksha irc channel.

Best Regards,
Murali Balcha
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Savanna] error in cluster launch: instance count gets to three, status=waiting, before going to error status

2013-09-17 Thread kesten broughton
I have applied the proposed patch for the setattr launch error


I patch works, but the launch still fails.

The stack trace just says the creation failed.


127.0.0.1 - - [16/Sep/2013 12:21:20] POST
/v1.0/2c8b2627a169458e8ab875690a51eabd/clusters HTTP/1.1 202 1877
1.441746
2013-09-16 12:21:42.592 47355 WARNING savanna.service.instances [-]
Can't start cluster 'cluster-1' (reason: node cluster-1-workers-002
has error status)
2013-09-16 12:21:51.369 47355 ERROR savanna.context [-] Thread
'cluster-creating-057ae8f2-ce41-4508-9696-3affe064178d' fails with
exception: 'node cluster-1-workers-002 has error status'
2013-09-16 12:21:51.369 47355 TRACE savanna.context Traceback (most
recent call last):
2013-09-16 12:21:51.369 47355 TRACE savanna.context   File
/home/stack/savanna-venv/local/lib/python2.7/site-packages/savanna/context.py,
line 93, in wrapper
2013-09-16 12:21:51.369 47355 TRACE savanna.context func(*args, **kwargs)
2013-09-16 12:21:51.369 47355 TRACE savanna.context   File
/home/stack/savanna-venv/local/lib/python2.7/site-packages/savanna/service/api.py,
line 137, in _provision_cluster
2013-09-16 12:21:51.369 47355 TRACE savanna.context
i.create_cluster(cluster)
2013-09-16 12:21:51.369 47355 TRACE savanna.context   File
/home/stack/savanna-venv/local/lib/python2.7/site-packages/savanna/service/instances.py,
line 63, in create_cluster
2013-09-16 12:21:51.369 47355 TRACE savanna.context
_rollback_cluster_creation(cluster, ex)
2013-09-16 12:21:51.369 47355 TRACE savanna.context   File
/home/stack/savanna-venv/local/lib/python2.7/site-packages/savanna/openstack/common/excutils.py,
line 70, in __exit__
2013-09-16 12:21:51.369 47355 TRACE savanna.context
six.reraise(self.type_, self.value, self.tb)
2013-09-16 12:21:51.369 47355 TRACE savanna.context   File
/home/stack/savanna-venv/local/lib/python2.7/site-packages/savanna/service/instances.py,
line 45, in create_cluster
2013-09-16 12:21:51.369 47355 TRACE savanna.context cluster =
_await_instances(cluster)


complete details here: http://paste.openstack.org/show/47126/
I can see in horizon that it makes it past the waiting log message.

My suspicion is with volumes.attach() below since the output from the
cluster_create contains

volume_mount_prefix: /volumes/disk,


I am using the vmware machine as configured in the guide, but
locate /volumes/disk returns nothing.

--- here is instances.py where the exception is thrown

def create_cluster(cluster):
ctx = context.ctx()
try:
# create all instances
conductor.cluster_update(ctx, cluster, {status: Spawning})
LOG.info(g.format_cluster_status(cluster))
_create_instances(cluster)

# wait for all instances are up and accessible
cluster = conductor.cluster_update(ctx, cluster, {status:
Waiting})
LOG.info(g.format_cluster_status(cluster))
cluster = _await_instances(cluster)

# attach volumes
volumes.attach(cluster)

# prepare all instances
cluster = conductor.cluster_update(ctx, cluster,
   {status: Preparing})
LOG.info(g.format_cluster_status(cluster))

_configure_instances(cluster)

except Exception as ex:
LOG.warn(Can't start cluster '%s' (reason: %s), cluster.name, ex)

tips to debug?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] Change email address

2013-09-17 Thread Mike Spreitzer
Is it possible to change the email address I use in git and gerrit?  I 
think I started off with an inferior choice.  I have now taught LaunchPad 
and Gerrit that I have two email addresses.  The OpenStack Foundation 
appears a bit confused, but I'm hoping that's not critical.

I am stuck at the point on 
https://wiki.openstack.org/wiki/How_To_Contribute where it says, 
concerning signing the ICLA, Your full name and E-mail address will be 
public (...) and the latter needs to match the user.email in your Git 
configuration.  Gerrit knows that I have signed the ICLA, and will not 
let me sign it again (I can not even try, it is grayed out).  Would it be 
correct to clarify the text I quoted above to say that one of your Gerrit 
email addresses has to match the one in your Git configuration?

Thanks,
Mike___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [python-glanceclient] Review request

2013-09-17 Thread Eddie Sheffield
Hi,

Could I get some reviews on this patch? It's adding CLI support for using 
Glance V2 API from the client.

https://review.openstack.org/#/c/42741/

Thanks,

Eddie



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [nova] Review request

2013-09-17 Thread Eddie Sheffield
Hi all!

I have a patch up for allowing Nova to talk to Glance via either the V1 or V2 
API. This is currently blocked by the feature freeze, but if some folks could 
look at it so I can have it ready to roll when the freeze ends I'd really 
appreciate it!

https://review.openstack.org/#/c/46507/

Thanks,

Eddie



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [QA]Bug in tempest/scenario/manager.py, wrong tenant being used for the selected admin user.

2013-09-17 Thread Martinez, Castulo
Hi Guys,

I found what seems to be a bug in the tempest/scenario/manager.py module in 
Tempest.

In the credentials classmethod definition for the OrchestrationScenarioTest 
class (Line 637),

@classmethod
def credentials(cls):
username = cls.config.identity.admin_username
password = cls.config.identity.admin_password
tenant_name = cls.config.identity.tenant_name
return username, tenant_name, password

Looks like the following line:

tenant_name = cls.config.identity.tenant_name

Should be replaced by this one:

tenant_name = cls.config.identity.admin_tenant_name

Right now the script is trying to use the admin username and password with the 
wrong tenant name (a non admin one).
Should I open a bug for this? If so, can somebody instruct me how to do this?

Best Regards / Saludos!

Castulo J. Martinez
ISTQB Test Manager
QA Engineer | Q1st team @GDC
Intel | Security Engineering and Cloud Integration (SECI)
Office: +52.33.2282.4083 | iNet: 8286-4083
P Before printing consider your Environmental Responsibility!

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [QA]Bug in tempest/scenario/manager.py, wrong tenant being used for the selected admin user.

2013-09-17 Thread David Kranz

On 09/17/2013 04:30 PM, Martinez, Castulo wrote:


Hi Guys,

I found what seems to be a bug in the tempest/scenario/manager.py 
module in Tempest.


In the credentials classmethod definition for the 
OrchestrationScenarioTest class (Line 637),


@classmethod

*def* *credentials*(cls):

username *=* cls*.*config*.*identity*.*admin_username

password *=* cls*.*config*.*identity*.*admin_password

tenant_name *=* cls*.*config*.*identity*.*tenant_name

*return* username, tenant_name, password

Looks like the following line:

tenant_name *=* cls*.*config*.*identity*.*tenant_name

Should be replaced by this one:

tenant_name *=* cls*.*config*.*identity*.admin_*tenant_name

Right now the script is trying to use the admin username and password 
with the wrong tenant name (a non admin one).


Should I open a bug for this? If so, can somebody instruct me how to 
do this?



So the same appears in OrchestrationManager.__init__  and 
OfficialClientManager._get_orchestration_client.
I'ts strange because I would expect tests to be failing. I have cc'ed 
Steve Baker to see if he can shed light on this.


And you can file a tempest bug at this page: 
https://bugs.launchpad.net/tempest/+filebug


 -David
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Change email address, or, why I can't use github and will I be able to submit patches?

2013-09-17 Thread Anne Gentle
On Tue, Sep 17, 2013 at 4:41 PM, Mike Spreitzer mspre...@us.ibm.com wrote:

 I am working through the instructions at
 https://wiki.openstack.org/wiki/GerritWorkflow - and things are going OK,
 including installing ~/.ssh/id_rsa.pub at
 https://review.openstack.org/#/settings/ssh-keys, without any linebreaks
 in the middle nor at the end - except it fails at the point where I test my
 ability to use github:

 mjs9:~ mspreitz$ git config --list
 user.name=Mike
 user.email=mspre...@us.ibm.com
 core.editor=emacs

 mjs9:~ mspreitz$ ssh -T g...@github.com
 Warning: Permanently added the RSA host key for IP address
 '192.30.252.131' to the list of known hosts.
 Permission denied (publickey).


 What's going wrong here?


Github was experiencing issues earlier today. Nothing in our GerritWorkflow
requires ssh -T g...@github.com though. If you were able to do a git clone,
how did git review -s go for you?



 Thanks,
 Mike
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Anne Gentle
annegen...@justwriteclick.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Change email address

2013-09-17 Thread Jeremy Stanley
On 2013-09-17 15:20:48 -0400 (-0400), Mike Spreitzer wrote:
[...]
 Would it be correct to clarify the text I quoted above to say that
 one of your Gerrit email addresses has to match the one in your
 Git configuration?

The point of that, which admittedly I probably didn't capture
remarkably well when I wrote it, is that they must match *at the
time you sign the ICLA* but can be changed later. That part of the
document is specifically about the process of signing the ICLA, not
about ongoing use of Gerrit, and is therefore not particularly
applicable once you've completed that particular step.
-- 
Jeremy Stanley

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Change email address

2013-09-17 Thread Mike Spreitzer
Thanks Anne.  Since I have already signed the ICLA, my real question is 
about what has to be true on an on-going basis for me to do developer 
stuff like reviewing and submitting patches.

Thanks,
Mike___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Change email address, or, why I can't use github and will I be able to submit patches?

2013-09-17 Thread Mike Spreitzer
I am working through the instructions at 
https://wiki.openstack.org/wiki/GerritWorkflow - and things are going OK, 
including installing ~/.ssh/id_rsa.pub at 
https://review.openstack.org/#/settings/ssh-keys, without any linebreaks 
in the middle nor at the end - except it fails at the point where I test 
my ability to use github:

mjs9:~ mspreitz$ git config --list
user.name=Mike
user.email=mspre...@us.ibm.com
core.editor=emacs

mjs9:~ mspreitz$ ssh -T g...@github.com
Warning: Permanently added the RSA host key for IP address 
'192.30.252.131' to the list of known hosts.
Permission denied (publickey).


What's going wrong here?

Thanks,
Mike___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] FFE Request: Make RBD Usable for Ephemeral Storage

2013-09-17 Thread Mike Perez
Folks,

Currently in Havana development, RBD as ephemeral storage has serious
stability
and performance issues that makes the Ceph cluster a bottleneck for using an
image as a source.

Nova has to currently communicate with the external service Glance, which
has
to talk to the separate Ceph storage backend to fetch path information. The
entire image is then downloaded to local disk, and then imported from local
disk to RBD. This leaves a stability concern, especially with large images
for
the instance to be successfully created, due to unnecessary data pulling and
pushing for solutions like RBD.

Due to the fact we have to do a import from local disk to RBD, this can make
performance even slower than a normal backend filesystem since the import is
single threaded.

This can be eliminated by instead having Nova's RBD image backend utility
communicate directly with the Ceph backend to do a copy-on-write of the
image.
Not only does this greatly improve stability, but performance is drastically
improved by not having to do a full copy of the image. A lot of the code to
make this happen came from the RBD Cinder driver which has been stable and
merged for quite a while.

Bug: https://code.launchpad.net/bugs/1226351
Patch: https://review.openstack.org/#/c/46879/1

Thanks,
Mike Perez
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Ceilometer] Allow multiple projects (tenants) in the received kwargs for v2 queries

2013-09-17 Thread Pendergrass, Eric
I'm implementing a role based access control system where I'll use a list of
projects to determine which projects a user can query.  This project list
will come from an upstream filter based on roles associated with the user's
auth token.

 

In the current v2/meters/meter_id (Sample) code, the kwargs received are
{'project': u'10032339952700', 'meter': u'network.incoming.bytes'}.  This
indicates one project is received.

 

I'd like to increase the flexibility of some of the v2 API controllers by
allowing a list of projects to be received and subsequently sent to the
storage layer for use in filtering.

 

My questions are:

What do you think about this?

Can the 'project' key change to 'projects' to support this?

 

Any thoughts greatly appreciated.  If this sounds reasonable I'll put out a
blueprint for the change.

 

Thanks

Eric Pendergrass



smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] OpenStack Identity API Documentation Kudos

2013-09-17 Thread Miller, Mark M (EB SW Cloud - RD - Corvallis)
Hello to all you documenters,

I have spent the day reviewing the latest OpenStack Identity API documents and 
want to say that you have done a truly TERRIFIC job. The latest revisions are 
clear and complete.

Thank you,

Mark Miller
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Change email address, or, why I can't use github and will I be able to submit patches?

2013-09-17 Thread Mike Spreitzer
 From: Anne Gentle annegen...@justwriteclick.com
 To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.org, 
 Date: 09/17/2013 05:51 PM
 Subject: Re: [openstack-dev] Change email address, or, why I can't 
 use github and will I be able to submit patches?
 
 ...
 Github was experiencing issues earlier today. Nothing in our 
 GerritWorkflow requires ssh -T g...@github.com though. If you were 
 able to do a git clone, how did git review -s go for you? 

Both work.  So I guess I am in business.

Thanks!
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] FFE Request: Make RBD Usable for Ephemeral Storage

2013-09-17 Thread Zhi Yan Liu
On Wed, Sep 18, 2013 at 6:16 AM, Mike Perez thin...@gmail.com wrote:
 Folks,

 Currently in Havana development, RBD as ephemeral storage has serious
 stability
 and performance issues that makes the Ceph cluster a bottleneck for using an
 image as a source.

 Nova has to currently communicate with the external service Glance, which
 has
 to talk to the separate Ceph storage backend to fetch path information. The
 entire image is then downloaded to local disk, and then imported from local
 disk to RBD. This leaves a stability concern, especially with large images
 for
 the instance to be successfully created, due to unnecessary data pulling and
 pushing for solutions like RBD.

 Due to the fact we have to do a import from local disk to RBD, this can make
 performance even slower than a normal backend filesystem since the import is
 single threaded.

 This can be eliminated by instead having Nova's RBD image backend utility
 communicate directly with the Ceph backend to do a copy-on-write of the
 image.
 Not only does this greatly improve stability, but performance is drastically
 improved by not having to do a full copy of the image. A lot of the code to
 make this happen came from the RBD Cinder driver which has been stable and
 merged for quite a while.

 Bug: https://code.launchpad.net/bugs/1226351
 Patch: https://review.openstack.org/#/c/46879/1

 Thanks,
 Mike Perez

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Hi Mike Perez, folks,

I absolutely agree use zero-copy approach to prepare template image is
a good idea, such as CoW. But after check your patch I have some
concerns on the currently implementation.

Actually I had prepared some dedicated BPs [1][2] and a patch [3] to
cover such requirements and problems around zero-copy (aka your
'direct_fetch') image preparing, it been implemented as a framework
and allow other people realize such plug-ins for a particular image
storage backend/location. So I'd very like to invite you (and Josh
Durgin) to take a look on them, I believe (and welcome) your stuff
within #46879 around RBD image handling can be implemented as a
RBDImangeHandler plug-ins under my framework.

I consider above implementation is better, since framework code within
#33409 can handle most common logic such as plug-ins loading, image
handler selecting base on image location, image multiple location
supporting and etc.. And each particular image handler can just
implement such special methods easily and don't need to rebuild the
existed (and tested) part.

Of cause, with the production of new handlers we probably need add
more interfaces and pass more context data to the structure /
ImageHandler base class as needed,  we can talk this in irc.

[1] https://blueprints.launchpad.net/nova/+spec/image-multiple-location
[2] 
https://blueprints.launchpad.net/nova/+spec/effective-template-base-image-preparing
[3] https://review.openstack.org/#/c/33409/

thanks,
zhiyan

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] OpenStack Identity API Documentation Kudos

2013-09-17 Thread Dolph Mathews
On Tue, Sep 17, 2013 at 6:00 PM, Miller, Mark M (EB SW Cloud - RD -
Corvallis) mark.m.mil...@hp.com wrote:

Hello to all you documenters,

 ** **

 I have spent the day reviewing the latest OpenStack Identity API documents
 and want to say that you have done a truly TERRIFIC job. The latest
 revisions are clear and complete.


I'm glad someone is reading them :) I'll make sure to pass this on to those
responsible!


 

 ** **

 Thank you,

 ** **

 Mark Miller

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 

-Dolph
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Nova][vmware] VMwareAPI sub-team reviews update 2013-09-18

2013-09-17 Thread Shawn Hartsock
Greetings stackers!

We're headed to the Havana-rc1 release! I've been triaging bugs, and 
re-evaluating priorities as we come up on that new deadline. Here's the 
priority order I've come up with, feel free to pop into #openstack-vmware or 
attend our weekly vmwareapi subteam meeting if you want to help adjust these. 
I've also included a revamp of my very special fitness for review report 
below.

Ordered by priority:
* Critical/Critical https://bugs.launchpad.net/bugs/1226211 
https://review.openstack.org/46789 readiness:ready for core
* Medium/Critical https://bugs.launchpad.net/bugs/1223709 
https://review.openstack.org/46027 readiness:needs review
* Medium/Critical https://bugs.launchpad.net/bugs/1217541 
https://review.openstack.org/43621 readiness:needs review
* Medium/Critical https://bugs.launchpad.net/bugs/1216510 
https://review.openstack.org/43616 readiness:needs one more +2/approval
* High https://bugs.launchpad.net/bugs/1184807 
https://review.openstack.org/40298 readiness:ready for core
* High https://bugs.launchpad.net/bugs/1226052 
https://review.openstack.org/46730 readiness:ready for core
* High https://bugs.launchpad.net/bugs/1225002 
https://review.openstack.org/41977 readiness:ready for core
* High https://bugs.launchpad.net/bugs/1214850 
https://review.openstack.org/43270 readiness:needs review
* Medium https://bugs.launchpad.net/bugs/1215352 
https://review.openstack.org/43268 readiness:needs one more +2/approval
* Medium https://bugs.launchpad.net/bugs/1183654 
https://review.openstack.org/45203 readiness:needs revision
* Medium https://bugs.launchpad.net/bugs/1223074 
https://review.openstack.org/45864 readiness:needs review
* Medium https://bugs.launchpad.net/bugs/1216961 
https://review.openstack.org/43721 readiness:ready for core
* Medium https://bugs.launchpad.net/bugs/1180044 
https://review.openstack.org/43270 readiness:needs review
* Medium https://bugs.launchpad.net/bugs/1197041 
https://review.openstack.org/43621 readiness:needs review
* Medium https://bugs.launchpad.net/bugs/1199954 
https://review.openstack.org/46231 readiness:needs review
* Medium https://bugs.launchpad.net/bugs/1222349 
https://review.openstack.org/45570 readiness:needs one more +2/approval
* Medium https://bugs.launchpad.net/bugs/1171226 
https://review.openstack.org/43994 readiness:ready for core
* Low https://bugs.launchpad.net/bugs/1215958 
https://review.openstack.org/43665 readiness:needs review


Ordered by fitness for review:

needs one more +2/approval
* Medium https://bugs.launchpad.net/bugs/1215352 
https://review.openstack.org/43268
+2:1, +1:8, -1:0, -2:0  age: 15 days
* Medium https://bugs.launchpad.net/bugs/1222349 
https://review.openstack.org/45570
+2:1, +1:5, -1:0, -2:0  age: 9 days
* Medium/Critical https://bugs.launchpad.net/bugs/1216510 
https://review.openstack.org/43616
+2:1, +1:4, -1:0, -2:0  age: 2 days

ready for core
* High https://bugs.launchpad.net/bugs/1184807 
https://review.openstack.org/40298
+2:0, +1:5, -1:0, -2:0  age: 2 days
* Medium https://bugs.launchpad.net/bugs/1216961 
https://review.openstack.org/43721
+2:0, +1:6, -1:0, -2:0  age: 23 days
* High https://bugs.launchpad.net/bugs/1226052 
https://review.openstack.org/46730
+2:0, +1:3, -1:0, -2:0  age: 1 days
* High https://bugs.launchpad.net/bugs/1225002 
https://review.openstack.org/41977
+2:0, +1:5, -1:0, -2:0  age: 3 days
* Critical/Critical https://bugs.launchpad.net/bugs/1226211 
https://review.openstack.org/46789
+2:0, +1:5, -1:0, -2:0  age: 2 days
* Medium https://bugs.launchpad.net/bugs/1171226 
https://review.openstack.org/43994
+2:0, +1:5, -1:0, -2:0  age: 2 days

needs review
* Medium/Critical https://bugs.launchpad.net/bugs/1223709 
https://review.openstack.org/46027
+2:0, +1:3, -1:0, -2:0  age: 7 days
* Medium https://bugs.launchpad.net/bugs/1223074 
https://review.openstack.org/45864
+2:0, +1:0, -1:0, -2:0  age: 0 days
* Medium https://bugs.launchpad.net/bugs/1180044 
https://review.openstack.org/43270
+2:0, +1:1, -1:0, -2:0  age: 27 days
* Medium https://bugs.launchpad.net/bugs/1197041 
https://review.openstack.org/43621
+2:0, +1:1, -1:0, -2:0  age: 13 days
* Medium https://bugs.launchpad.net/bugs/1199954 
https://review.openstack.org/46231
+2:0, +1:2, -1:0, -2:0  age: 1 days
* Low https://bugs.launchpad.net/bugs/1215958 https://review.openstack.org/43665
+2:0, +1:3, -1:0, -2:0  age: 10 days
* Medium/Critical https://bugs.launchpad.net/bugs/1217541 
https://review.openstack.org/43621
+2:0, +1:1, -1:0, -2:0  age: 13 days
* High https://bugs.launchpad.net/bugs/1214850 
https://review.openstack.org/43270
+2:0, +1:1, -1:0, -2:0  age: 27 days

needs revision
* Medium https://bugs.launchpad.net/bugs/1183654 
https://review.openstack.org/45203
+2:0, +1:1, -1:1, -2:0  age: 13 days