[openstack-dev] sw process

[Tracy Jones]

Folks – we have gotten into a couple of loose habits in our mad dash to beta 1 
that we need to tighten up on.  I’ve asked Ryan to set geritt up to fail 
reviews when the commit id does not contain one of the following, so please add 
them to your commit.  In addition please make your commit message useful and 
with enough detail that the reviewer knows what he/she is reviewing.

Implements-Story: XXX
Fixes-Bug: YYY

Other issues

Do not +2 your own patch .  We won’t enforce this unless we need to, but don’t 
do it

Reviewed pushed on master and containing multiple changes

You should create a branch to hold your work and name it something that makes 
sense.  This branch should ONLY contain this work.  When you checkin your code 
it makes it much easier for the reviewer to understand what you are doing.  If 
you have work that is dependent on other work, create a dependency on your 
branch

I.e. Git checkout –b branch name  where branch name is bug/1234 or 
implement-ui-validation

This is the openstack workflow – which talks about how to do dependencies, 
rebating etc.  It’s a pretty good guide.

https://wiki.openstack.org/wiki/Gerrit_Workflow#Normal_Workflow


Anyone have other guides they want to share on a good workflow?



Let me know if you have comments or suggestions.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] sw process

[Tracy Jones]

SORRY – please ignore that email – it was clearly internal…… I used the wrong 
ML  (blush)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] call for help with nova bug management

[Tracy Jones]

Hi Folks - I’ve offered to help Russell out with managing nova’s bug queue.  
The charter of this is as follows

Triage the 125 new bugs
Ensure that the critical bugs are assigned properly and are making progress

Once this part is done we will shift our focus to things like
Bugs in incomplete state with no update by the reporter - they should be set to 
invalid if they requester does not update them in a timely manner.
Bugs which say they are in progress but no progress is being made.   If a bug 
is assigned and simply being ignored we should remove the assignment so others 
can grab it and work on it

The bug triage policy is defined here https://wiki.openstack.org/wiki/BugTriage


What can you do???  First I need a group of folks to volunteer to help with 1 
and 2.  I will start a weekly IRC meeting where we work on the triage and check 
progress on critical (or even high) prio bugs.  If you can help out, please 
sign up at the end of this etherpad and include your timezone.  Once I have a 
few people to help i will schedule the meeting at a time that I hope is 
convenient for all.

https://etherpad.openstack.org/p/nova-bug-management

Thanks in advance for your help.

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

Re: [openstack-dev] call for help with nova bug management

[Tracy Jones]

So i have been rather underwhelmed in the enthusiastic response to help out :-)



So far only wendar and johnthetubaguy have signed up.   I was hoping for at 
least 3-5 people to help with the initial triage.  Please sign up this week if 
you can help and i’ll schedule the meetings starting next week




On Feb 14, 2014, at 2:16 PM, Tracy Jones tjo...@vmware.com wrote:

 Hi Folks - I’ve offered to help Russell out with managing nova’s bug queue.  
 The charter of this is as follows
 
 Triage the 125 new bugs
 Ensure that the critical bugs are assigned properly and are making progress
 
 Once this part is done we will shift our focus to things like
 Bugs in incomplete state with no update by the reporter - they should be set 
 to invalid if they requester does not update them in a timely manner.
 Bugs which say they are in progress but no progress is being made.   If a bug 
 is assigned and simply being ignored we should remove the assignment so 
 others can grab it and work on it
 
 The bug triage policy is defined here 
 https://wiki.openstack.org/wiki/BugTriage
 
 
 What can you do???  First I need a group of folks to volunteer to help with 1 
 and 2.  I will start a weekly IRC meeting where we work on the triage and 
 check progress on critical (or even high) prio bugs.  If you can help out, 
 please sign up at the end of this etherpad and include your timezone.  Once I 
 have a few people to help i will schedule the meeting at a time that I hope 
 is convenient for all.
 
 https://etherpad.openstack.org/p/nova-bug-management
 
 Thanks in advance for your help.
 
 Tracy

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

[openstack-dev] Nova Bug Scrub meeting

[Tracy Jones]

Hi all - i have set up the nova bug scrub meeting for Wednesdays at 1630 UTC in 
the #openstack-meeting-3 IRC channel


The first meeting will be all about triaging the 117 un-triaged bugs (here).  


https://wiki.openstack.org/wiki/Meetings/NovaBugScrub#Weekly_OpenStack_Nova_Bug_Scrub_Meeting


Weekly on Wednesday at 1630 UTC
IRC channel: #openstack-meeting-3
Chair (to contact for more information): Tracy Jones
See Meetings/NovaBugScrub for an agenda


Come join the fun!

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

[openstack-dev] Bug Triage - Woo Hoo!!

[Tracy Jones]

Hi Folks -   We had our 1st Bug Scrub meeting and it was a great success.  We 
concentrated on tagging all of the untagged bugs with appropriate tags.  The 
work is not complete, so if you would like to help out - please take a look 
here and tag away.


This table shows the official tags we are using, along with owners, count of 
un-triaged bugs, and count of triaged bugs.  Please scan this list for your 
name and do the following

1.  are you the right owner?  If not let me know
2.  triage your New bugs - there are instructions here
3.  please do this at least weekly if not more.


If you see a NO OWNER for an area you would like to own, please let me know.   
I’m looking for volunteers - we only need 5 more people to cover everything

Once we reach FF our focus moves from BP to bugs so you’ll be hearing from me 
more and more until we release icehouse.  :-D



Tag Owner   New Not-New
wat russellb48  617
network  arosen 16  47
libvirt  kchamart   15  90
testing NO OWNER10  38
compute  melwitt7   51
cellscomstud5   12
ec2 NO OWNER5   27
volumes  ndipanov   4   12
api  cyeoh  3   84
console NO OWNER3   5
db   dripton2   46
docker   ewindisch  2   16
lxc  zul2   3
oslo allison2   7
baremetaldevananda  1   38
hyper-v  alexpilotti1   17
novaclient   alaski 1   0
conductordansmith   0   3
nova-manage NO OWNER0   8
postgresql   dripton0   0
rootwrap ttx0   1
scheduler   NO OWNER0   9
unified-objects  dansmith   0   0
vmware   hartsocks  0   64
xenserverjohnthetubaguy 0   44
127 1239



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

[openstack-dev] [Nova] FFE Request: Image Cache Aging

[Tracy Jones]

Hi - Please consider the image cache aging BP for FFE 
(https://review.openstack.org/#/c/56416/)

This is the last of several patches (already merged) that implement image cache 
cleanup for the vmware driver.  This patch solves a significant customer pain 
point as it removes unused images from their datastore.  Without this patch 
their datastore can become unnecessarily full.  In addition to the customer 
benefit from this patch it

1.  has a turn off switch 
2.  if fully contained within the vmware driver
3.  has gone through functional testing with our internal QA team 

ndipanov has been good enough to say he will review the patch, so we would ask 
for one additional core sponsor for this FFE.

Thanks

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

[openstack-dev] [nova] Getting close to RC1....

[Tracy Jones]

Folks - we are getting close to RC next week and therefore will start closing 
down the churn.  Bugs that are not merged by Monday @8am EDT (12pm UTC)  will 
be moved out of RC1 and pushed to icehouse-rc-potential.  Only those bugs which 
are 

a.  regression
b.  highest priority issues (as decided by russellb)

will be reviewed after that time.

The current list for RC1 is 

Bug report  Importance  AssigneeStatus
#1195947VM re-scheduler mechanism will cause BDM-volumes conflict   
Highwingwj  In Progress
#1246201Live migration fails when the instance has a config-drive   
HighMichael Still   In Progress
#1269418nova rescue doesn't put VM into RESCUE status on vmware 
HighGary Kotton In Progress
#1274129host-update --maintenance enable regression for vmware VCDriver 
HighGary Kotton In Progress
#1290403Hyper-V agent does not enable disk metrics for individual disks 
HighClaudiu BeluIn Progress
#1290540neutron_admin_tenant_name deprecation warning is wrong  
HighRobert Collins  In Progress
#1290807Resize on vCenter failed because of _VM_REFS_CACHE  
HighFeng Xi Yan In Progress
#1294102VMware: get_object_properties may not return any objects
HighGary Kotton In Progress
#1180040Race condition in attaching/detaching volumes when compute 
manager is unreachable   Medium  Nikola Đipanov  In Progress


The rest will be deferred to Juno.

Please let me know if you have questions or comments

Tracy


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

Re: [openstack-dev] [nova] An analysis of code review in Nova

[Tracy Jones]

I agree that the oslo integration does not depend on the spawn reflector and we 
have been asked to do this before doing anything else by the core team.  I 
would like to get the spawn refactor in ASAP - as mentioned in the BP

1.  pull out the inner methods and add tests for them
2.  fix the complex branching

https://blueprints.launchpad.net/nova/+spec/vmware-spawn-refactor

I believe these 3 items are under work already by Shawn, Vui, Gary, and Ryan.


The the oslo integration can happen immediately after - or even in parallel, 
but i think it will go easier once the spawn refactor is complete.


On Mar 24, 2014, at 11:24 AM, Shawn Hartsock harts...@acm.org wrote:

 I fully support 
 https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%23/c/70175/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=fysbO8%2FBLtC%2B0WXqPRtZjP%2BFTxUY74FYnj8tkYiMlD4%3D%0Am=kdu06OR%2BhUFnE048i3EIYluW%2FTZVQ2x8i%2FgCgVHF9U4%3D%0As=ecab500da1e8acaeaceecfd2df28c2c7ab6a82725202a4fecbc3b04d949b3a62
  but I fail to
 see why the spawn-refactor should depend on that. There are only 13
 lines touched that are related. These two tasks could be completed
 more or less in parallel.
 
 On Mon, Mar 24, 2014 at 4:57 AM, Gary Kotton gkot...@vmware.com wrote:
 Regarding the spawn there are a number of patches up for review at the
 moment - they are all mutually exclusive and hopefully will make the
 process a lot smoother.
 https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%23/q/topic:bp/vmware-spawn-refactor%2Cn%2Czk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=fysbO8%2FBLtC%2B0WXqPRtZjP%2BFTxUY74FYnj8tkYiMlD4%3D%0Am=kdu06OR%2BhUFnE048i3EIYluW%2FTZVQ2x8i%2FgCgVHF9U4%3D%0As=91ea5fa587f87ee0e8cd7993ec9b5deba54c1d67f6e4c261ba6bf8df0921fb94
 In addition to this we have a patch up for review with the OSLO
 integration - 
 https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%23/c/70175/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=fysbO8%2FBLtC%2B0WXqPRtZjP%2BFTxUY74FYnj8tkYiMlD4%3D%0Am=kdu06OR%2BhUFnE048i3EIYluW%2FTZVQ2x8i%2FgCgVHF9U4%3D%0As=ecab500da1e8acaeaceecfd2df28c2c7ab6a82725202a4fecbc3b04d949b3a62
  (ideally it would be
 best that this gets in first)
 Thanks
 Gary
 
 On 3/22/14 8:03 PM, Chris Behrens cbehr...@codestud.com wrote:
 
 I'd like to get spawn broken up sooner rather than later, personally. It
 has additional benefits of being able to do better orchestration of
 builds from conductor, etc.
 
 On Mar 14, 2014, at 3:58 PM, Dan Smith d...@danplanet.com wrote:
 
 Just to answer this point, despite the review latency, please don't be
 tempted to think one big change will get in quicker than a series of
 little, easy to review, changes. All changes are not equal. A large
 change often scares me away to easier to review patches.
 
 Seems like, for Juno-1, it would be worth cancelling all non-urgent
 bug fixes, and doing the refactoring we need.
 
 I think the aim here should be better (and easier to understand) unit
 test coverage. Thats a great way to drive good code structure.
 
 Review latency will be directly affected by how good the refactoring
 changes are staged. If they are small, on-topic and easy to validate,
 they will go quickly. They should be linearized unless there are some
 places where multiple sequences of changes make sense (i.e. refactoring
 a single file that results in no changes required to others).
 
 As John says, if it's just a big change everything patch, or a ton of
 smaller ones that don't fit a plan or process, then it will be slow and
 painful (for everyone).
 
 +1 sounds like a good first step is to move to oslo.vmware
 
 I'm not sure whether I think that refactoring spawn would be better done
 first or second. My gut tells me that doing spawn first would mean that
 we could more easily validate the oslo refactors because (a) spawn is
 impossible to follow right now and (b) refactoring it to smaller methods
 should be fairly easy. The tests for spawn are equally hard to follow
 and refactoring it first would yield a bunch of more unit-y tests that
 would help us follow the oslo refactoring.
 
 However, it sounds like the osloificastion has maybe already started and
 that refactoring spawn will have to take a backseat to that.
 
 --Dan
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 
 https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi
 -bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar
 =eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=q5RejnjmrSIFg0K7ua
 AZbKHVqAKLHnVAB98J%2BszOfhw%3D%0As=1629f4e9008260c5f8ea577da1bdc69388dbe
 fa3646803244df992a31d94bc96
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
 bin/mailman/listinfo/openstack-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=e
 

Re: [openstack-dev] [Nova] VMWare Mine Sweeper, Congrats!

[Tracy Jones]

Yes - we are going to change that.   I know it's annoying. 

Sent from my iPhone

 On Oct 21, 2013, at 5:14 PM, Michael Still mi...@stillhq.com wrote:
 
 This is super cool. Thanks!
 
 One piece of feedback -- would it be possible to get the results as
 something other than a tarball? Downloading the entire tarball to read
 one log is slightly annoying.
 
 Thanks,
 Michael
 
 On Sat, Oct 19, 2013 at 9:29 AM, Sreeram Yerrapragada
 syerraprag...@vmware.com wrote:
 We had some infrastructure issues in the morning and went back to silent
 mode. I just re-triggered tempest run for your patchset. Also note that
 until we stabilize our CI infrastructure you would only be seeing postings
 from vmware minesweeper for passed builds. For failed build we will manually
 update it on the review.
 
 Thanks
 Sreeram
 
 
 From: Yaguang Tang yaguang.t...@canonical.com
 To: OpenStack Development Mailing List openstack-dev@lists.openstack.org
 Sent: Friday, October 18, 2013 8:59:19 AM
 Subject: Re: [openstack-dev] [Nova] VMWare Mine Sweeper, Congrats!
 
 
 How can I enable or trigger Mine Sweeper for VMware related patches?  I have
 update a patch about VMware driver today
 https://review.openstack.org/#/c/51793/ . but haven't seen any posting
 results .
 
 
 2013/10/18 Sean Dague s...@dague.net
 
 On 10/17/2013 02:29 PM, Dan Smith wrote:
 
 This system is running tempest against a VMWare deployment and posting
 the results publicly.  This is really great progress.  It will go a long
 way in helping reviewers be more confident in changes to this driver.
 
 
 This is huge progress, congrats and thanks to the VMware team for making
 this happen! There is really no substitute for the value this will
 provide for overall quality.
 
 
 Agreed. Nice job guys! It's super cool to now see SmokeStack and Mine
 Sweeper posting back on patches.
 
 Tip of the hat to the VMWare team for pulling this together so quickly.
 
-Sean
 
 --
 Sean Dague
 http://dague.net
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 --
 Tang Yaguang
 
 Canonical Ltd. | www.ubuntu.com | www.canonical.com
 Mobile:  +86 152 1094 6968
 gpg key: 0x187F664F
 
 
 ___
 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
 
 
 
 -- 
 Rackspace Australia
 
 ___
 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

[openstack-dev] iso8601 filling up nova logs

[Tracy Jones]

My nova logs are full of this - is it ok if I make a change to the default log 
level to set iso8601 to WARN?

2:39:54.683 DEBUG iso8601.iso8601 [-] Parsed 2013-11-06T06:38:00Z into 
{'tz_sign': None, 'second_fraction': None, 'hour': u'06', 'tz_hour': None, 
'month': u'11', 'timezone': u'Z', 'second': u'00', 'tz_minute': None, 'year': 
u'2013', 'separator': u'T', 'day': u'06', 'minute': u'38'} with default 
timezone iso8601.iso8601.Utc object at 0x2adcc90 from (pid=14941) parse_date 
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:166
2013-11-05 22:39:54.684 DEBUG iso8601.iso8601 [-] Got u'2013' for 'year' with 
default None from (pid=14941) to_int 
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
2013-11-05 22:39:54.684 DEBUG iso8601.iso8601 [-] Got u'11' for 'month' with 
default None from (pid=14941) to_int 
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
2013-11-05 22:39:54.684 DEBUG iso8601.iso8601 [-] Got u'06' for 'day' with 
default None from (pid=14941) to_int 
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
2013-11-05 22:39:54.685 DEBUG iso8601.iso8601 [-] Got u'06' for 'hour' with 
default None from (pid=14941) to_int 
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
2013-11-05 22:39:54.685 DEBUG iso8601.iso8601 [-] Got u'38' for 'minute' with 
default None from (pid=14941) to_int 
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
2013-11-05 22:39:54.685 DEBUG iso8601.iso8601 [-] Got u'00' for 'second' with 
default None from (pid=14941) to_int 
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
2013-11-05 22:39:54.686 DEBUG iso8601.iso8601 [-] Parsed 2013-11-0

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

Re: [openstack-dev] [Nova] Configuration validation

[Tracy Jones]

I had envisioned this as a standalone tool which would be run after an initial 
deployment to validate the config.  I like the idea of hooking it into an 
existing framework - but i agree that we certainly don’t want to slow things 
down.  I wonder if we could use some sort of cookie to track when we validated 
the config and only revalidate when needed.  As i get further in the BP i’ll 
investigate these options.

Tracy

On Nov 11, 2013, at 4:31 AM, Gary Kotton gkot...@vmware.com wrote:

 Hi,
 I think that John has a very valid point. My understanding from the
 session was that this should be a stand alone tool that will also work
 across services, that is, if neutron is configured then it will check that
 the neutron credentials are correct.
 Thanks
 Gary
 
 On 11/11/13 1:55 PM, John Garbutt j...@johngarbutt.com wrote:
 
 I like the idea of a more general config validation phase to help
 people when first starting out.
 
 My worry is that it would slow down the starting back up of servers
 for people deploying their code using CI, where the have already
 verified their configuration. But maybe its so fast I don't care, but
 I just felt I should raise that.
 
 John
 
 On 11 November 2013 11:44, Nikola Đipanov ndipa...@redhat.com wrote:
 Hey all,
 
 During the summit session on the the VMWare driver roadmap, a topic of
 validating the passed configuration prior to starting services came up
 (see [1] for more detail on how it's connected to that specific topic).
 
 Several ideas were thrown around during the session mostly documented in
 [1].
 
 There are a few more cases when something like this could be useful (see
 bug [2] and related patch [3]), and I was wondering if a slightly
 different approach might be useful. For example use an already existing
 validation hook in the service class [4] to call into a validation
 framework that will potentially stop the service with proper
 logging/notifications. The obvious benefit would be that there is no
 pre-run required from the user, and the danger of running a
 misconfigured stack is smaller.
 
 Since there is already a blueprint raised based on the etherpad [1]- I
 am bringing this up here so that we can agree on the approach, before
 raising another one to solve the same problem.
 
 Thanks,
 
 Nikola
 
 [1] https://etherpad.openstack.org/p/T4tQMQf5uS
 [2] https://bugs.launchpad.net/nova/+bug/1243614
 [3] https://review.openstack.org/#/c/53303/
 [4] 
 http://git.openstack.org/cgit/openstack/nova/tree/nova/service.py#n283
 
 ___
 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
 
 ___
 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] [Nova] Configuration validation

[Tracy Jones]

Thanks folks for the interesting suggestions on this topic!  I’ll b updating 
the BP this week with this and other info i am gathering. 

Please let me know if you are interested in being involved in brainstorming on 
this issue and I will set up an irc meeting to discuss it further

On Nov 11, 2013, at 3:08 PM, Mark McLoughlin mar...@redhat.com wrote:

 Hi Nikola,
 
 On Mon, 2013-11-11 at 12:44 +0100, Nikola Đipanov wrote:
 Hey all,
 
 During the summit session on the the VMWare driver roadmap, a topic of
 validating the passed configuration prior to starting services came up
 (see [1] for more detail on how it's connected to that specific topic).
 
 Several ideas were thrown around during the session mostly documented in
 [1].
 
 There are a few more cases when something like this could be useful (see
 bug [2] and related patch [3]), and I was wondering if a slightly
 different approach might be useful. For example use an already existing
 validation hook in the service class [4] to call into a validation
 framework that will potentially stop the service with proper
 logging/notifications. The obvious benefit would be that there is no
 pre-run required from the user, and the danger of running a
 misconfigured stack is smaller.
 
 One thing worth trying would be to encode the validation rules in the
 config option declaration.
 
 Some rules could be straightforward, like:
 
 opts = [
  StrOpt('foo_url',
 validate_rule=cfg.MatchesRegexp('(git|http)://')),
 ]
 
 but the rule you describe is more complex e.g.
 
 def validate_proxy_url(conf, group, key, value):
if not conf.vnc_enabled:
return
if conf.ssl_only and value.startswith(http://;):
raise ValueError('ssl_only option detected, but ...')
 
 opts = [
  StrOpt('novncproxy_base_url',
 validate_rule=validate_proxy_url),
  ...
 ]
 
 I'm not sure I love this yet, but it's worth experimenting with.
 
 Mark.
 
 
 ___
 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] [Nova] Configuration validation

[Tracy Jones]

Oleg - this is great!  I tried to find you on IRC to recommend we put this on a 
etherpad so several of us can collaborate together on requirements and 
brainstorming.  

On Nov 18, 2013, at 10:54 AM, Oleg Gelbukh ogelb...@mirantis.com wrote:

 Hi,
 
 I summarized a list of requirements to the config validation framework from 
 this thread and other sources, including IRC discussions so far:
 
 https://gist.github.com/ogelbukh/7533029
 
 Seems like we have 2 work items here, one being extension which adds more 
 complex flags types to Oslo.config, and the other is standalone service for 
 stateful validation of cfg across services. We're working on design for such 
 service in frame of Rubick project.
 
 I'd really appreciate any help with prioritization of requirements from the 
 list above.
 
 --
 Best regards,
 Oleg Gelbukh
 Mirantis Labs
 
  To be fair, we test only the subset that is set via devstack on the
  stable side. That should be a common subset, but it is far from fully
  comprehensive. Nova has over 600 config variables, so additional tooling
  here would be goodness.
 
 I'm surely not arguing against additional testing of config stuff, I'm
 just saying I'm not sure there's an upgrade impact here. What we care
 about across upgrades is that the conf stays legit. A set of offline
 tests that look at the config shouldn't have anything useful to verify
 or report, other than just this thingy is now deprecated, beware!
 
 If we care about validating that reviewers didn't let some config
 element be removed that wasn't already deprecated, that's something that
 needs visibility into the two ends of the upgrade. I would think grenade
 would be the place to do this since it has both hashes, and I definitely
 think that could be instrumented easily. However, I don't think that has
 much overlap with the config checker thing that was discussed at summit,
 simply because it requires visibility into two trees.
 
 --Dan
 
 
 ___
 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

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

[openstack-dev] [nova] remote debugging

[Tracy Jones]

Hi Folks - i am trying to add a patch to enable remote debugging in the nova 
services.  I can make this work very simply, but it requires a change to 
monkey_patching - i.e.

eventlet.monkey_patch(os=False, select=True, socket=True, thread=False,
  time=True, psycopg=True)

I’m working with some folks from the debugger vendor (pycharm) on why this is 
needed.   However - i’ve been using it with nova-compute for a month or so and 
do not see any issues which changing the monkey-patching.  Since this is done 
only when someone wants to use the debugger - is making this change so bad?

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

Re: [openstack-dev] [nova] remote debugging

[Tracy Jones]

Thanks Yatin - that is the change I am proposing in my patch


On Nov 25, 2013, at 9:09 AM, yatin kumbhare yatinkumbh...@gmail.com wrote:

 Hi,
 
 http://debugopenstack.blogspot.in/
 
 I have done Openstack remote debugging with eclipse and pydev.
 
 only change is to exclude python thread library from monkey patch at service 
 start up.
 
 Regards,
 Yatin
 
 
 On Mon, Nov 25, 2013 at 9:10 PM, Russell Bryant rbry...@redhat.com wrote:
 On 11/25/2013 10:28 AM, Tracy Jones wrote:
  Hi Folks - i am trying to add a patch to enable remote debugging in the
  nova services.  I can make this work very simply, but it requires a
  change to monkey_patching - i.e.
 
  eventlet.monkey_patch(os=False, select=True, socket=True, thread=False,
time=True, psycopg=True)
 
  I’m working with some folks from the debugger vendor (pycharm) on why
  this is needed.   However - i’ve been using it with nova-compute for a
  month or so and do not see any issues which changing the
  monkey-patching.  Since this is done only when someone wants to use the
  debugger - is making this change so bad?
 
   https://review.openstack.org/56287
 
 Last I looked at the review, it wasn't known that thread=False was
 specifically what was needed IIRC  That's good progress and is a bit
 less surprising than the change before.
 
 I suppose if the options that enable this come with a giant warning,
 it'd be OK.  Something like:
 
   WARNING: Using this option changes how Nova uses the eventlet
   library to support async IO. This could result in failures that do
   not occur under normal opreation. Use at your own risk.
 
 --
 Russell Bryant
 
 ___
 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

[openstack-dev] [nova][vmwareapi] Spawn Refactor progress

[Tracy Jones]

Our phase 1 of spawn refactor merged a week or 2 ago and we are hard at work on 
phase 2 and 3.  The patch set has been posted.  Here is the list in order to 
review for your convenience

not a refactor by a trivial fix to clean up some code before the refactor
https://review.openstack.org/#/c/99238

Phase 2 - these are ready for review
https://review.openstack.org/#/c/98285 (DatastorePath class)
https://review.openstack.org/#/c/99427 (Datatore classs)
https://review.openstack.org/#/c/87002 (get_image_properties)

Phase 3 - This set is still undergoing some further decomposition. But early 
(even just high level) comments on the approach, the extent/granularity of the 
unit testing will be most welcome.
Also, trying to break the big patch into smaller self-contained ones is turning 
out to be quite a challenge. Recommendations on how we can do this sanely most 
appreciated as well.
https://review.openstack.org/#/c/98322 (image fetching/processing/use)


Related review -
https://review.openstack.org/#/c/98529/ (somewhat orthogonal, more like a bit 
of new feature, but came out of the get_image_properties work is the 
descriptor-based validation of fields in the VMwareImage object)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][vmwareapi] minesweeper status

[Tracy Jones]

Hi Folks - Minesweeper ran into some trouble  about a week ago with some 
checkins on tempest, devstack, and some internal issues.  We were down off and 
on for a week - mostly off.  Going forward I'll be more proactive about 
informing you all of these types of issues.  Currently minesweeper is up and 
running and has caught up the the backlog of changes in the queue.  We are in 
the process of re-triggering some of the patches we aborted when we were 
bringing the system back online.  Our CI team is currently addressing an issue 
with rechecks which should be resolved shortly.  For up to date information 
please see our wiki

https://wiki.openstack.org/wiki/NovaVMware/Minesweeper/Status


Tracy

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

[openstack-dev] [nova] nova bug scrub web page

[Tracy Jones]

Hi Folks - I have taken a script from the infra folks and jogo, made some 
tweaks and have put it into a web page.  Please see it here 
http://54.201.139.117/demo.html


This is all of the new, confirmed, triaged, and in progress bugs that we have 
in nova as of a couple of hours ago.  I have added ways to search it, sort it, 
and filter it based on

1.  All bugs
2.  Bugs that have not been updated in the last 30 days
3.  Bugs that have never been updated
4.  Bugs in progress
5.  Bugs without owners.


I chose this as they are things I was interested in seeing, but there are 
obviously a lot of other things I can do here.  I plan on adding a cron job to 
update the data ever hour or so.  Take a look and let me know if your have 
feedback.

Tracy


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

[openstack-dev] [nova] nova bug scrub web page (updated)

[Tracy Jones]

I've updated the page with some of the ideas jogo floated by me today

http://54.201.139.117/demo.html

Once I have the code in decent shape I will post to git so other projects can 
make use of it if they would like (aka Neutron) ;-)

Please let me know if you have questions or comments.

BTW - The additional Review Status column shows the number of reviews merged, 
abandoned or new to allow me to filter on all merged and all abandoned.


Tracy

From: Tracy Jones tjo...@vmware.commailto:tjo...@vmware.com
Date: Thursday, July 3, 2014 at 2:00 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [nova] nova bug scrub web page

Hi Folks - I have taken a script from the infra folks and jogo, made some 
tweaks and have put it into a web page.  Please see it here 
http://54.201.139.117/demo.html


This is all of the new, confirmed, triaged, and in progress bugs that we have 
in nova as of a couple of hours ago.  I have added ways to search it, sort it, 
and filter it based on

1.  All bugs
2.  Bugs that have not been updated in the last 30 days
3.  Bugs that have never been updated
4.  Bugs in progress
5.  Bugs without owners.


I chose this as they are things I was interested in seeing, but there are 
obviously a lot of other things I can do here.  I plan on adding a cron job to 
update the data ever hour or so.  Take a look and let me know if your have 
feedback.

Tracy


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

[openstack-dev] [nova] bug discussion at mid cycle meet up

[Tracy Jones]

At the mid-cycle meet-up yesterday we spent some time looking at our bug 
dashboard (http://54.201.139.117/nova-bugs.html) and talking about things we 
can do to help focus on bugs.  We came up with the following ideas.  I’d like 
folks to weigh in on these i if you have some ideas or concerns.


1.  Start auto-abandoning bugs that have not been touched (I.e. Updated) in the 
last 60 days.We would have something (a bot?) that would look at bugs that 
have not been updated (nor their review updated) in the last 60 days.  The bug 
would be set to the “new” state and the assignee would be removed.  This would 
cause the bug to be re-triaged and would be up for someone else to pick up.

2.  Also - when a bug has all abandoned reviews, we should automatically set 
the bug to new and remove the assignee.

3.  We have bugs that are really not bugs but features, or performance issues.  
They really should be a BP not a bug, but we don’t want these things to fall 
off the radar so they are bugs… But we don’t really know what to do with them.  
Should they be closed?  Should they have a different category – like feature 
request??  Perhaps they should just be wish list??

4.  We should  have more frequent and focused bug days.  For example every 
Monday have a bug day where we focus on 1 area (like api or compute or 
networking for example) and work on moving new bugs to configured, or confirmed 
bugs to triaged.  I’ll talk with Michael about when to schedule the 1st 
“focused” bug day and what area to address.


In generate we need to tighten up the definition of triaged and confirmed.  
Bugs should move from New - Confirmed - Triaged - In Progress.  JayPipes has 
updated the wiki to clarify this.

  *   Confirmed means someone has looked at the bug, saw there was enough into 
to start to diagnose, and agreed it sounds like a bug.
  *   Triaged means someone has analyzed the bug and can propose a solution 
(not necessarily a patch).  If the person is not going to fix it, they should 
update the bug with the proposal and move the bug into Triaged.

If we do implement 1 and 2 I’m hoping the infra team can help – I think dims 
volunteered ;-)

I made a note to add review stats to the bug page to make it easier to see how 
far along a bug is in review




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

[openstack-dev] [nova] bug status and our 1st Bug Day for Juno

[Tracy Jones]

Hi Folks - I spoke with Michael at the summit about bug management for Juno.   
Other than tagging the untagged bugs each week, I will also be driving a top 
ten list of bugs at the nova meeting.  The meeting is every Wednesday for 1/2 
hour at 1630 UTC.  Attendance has dropped off since the end of icehouse - in 
fact no one attended at all yesterday.  Im guessing people are focused on BP 
right now - but losing focus on bugs is a bad idea.

Nova currently has about 1200  bugs open (new, triaged, confirmed, in progress).
Of those, 556 have no owner (46%) which (usually) mean they are not being 
worked on.

 I will be gathering better stats over the next week or so, but my sense is 
that we need to focus a bit more on bugs.  To that end, I would like to propose 
a Bug Day on next Wedesday 6/4.

Bug day is a day that (regardless of time zone), people spend time on either 
fixing or reviewing bugs.

During that day we work on bugs and review bugs

We hang out on  #openstack-bugday

We admire our progress on http://status.openstack.org/bugday/

In terms of today's top ten bugs.  This week we have 1 regression from havana 
which is not assigned to anyone.

https://bugs.launchpad.net/nova/+bug/1299517


Please let me know if you have questions of comments

Tracy









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

[openstack-dev] [nova] Bug Day on 6/4

[Tracy Jones]

Hi Folks - nova is going to have a bug day on Wednesday, 6/4.  During that day 
we are asking people to take a break from feature work and help fix and/or 
review bugs for the day.We hang out on  #openstack-bugday

We admire our progress on 
http://status.openstack.org/bugdayhttps://urldefense.proofpoint.com/v1/url?u=http://status.openstack.org/bugdayk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=fysbO8%2FBLtC%2B0WXqPRtZjP%2BFTxUY74FYnj8tkYiMlD4%3D%0Am=S73IpachtrvTi7l2who3rTtVqVL4YyssltEYbyzuFRY%3D%0As=2f6643baaebbfb870112501d62945fc0ef35d7c7aff80c6a01d36acfbc0f959e/


Please help out -  Here are some handy links



  *   All Nova Bugs: https://bugs.launchpad.net/nova
  *   Bugs that have gone stale: 
https://bugs.launchpad.net/nova/+bugs?orderby=date_last_updatedfield.status%3Alist=INPROGRESSassignee_option=any
  *   Untriaged 
Bugshttps://bugs.launchpad.net/nova/+bugs?field.searchtext=orderby=-importancesearch=Searchfield.status%3Alist=NEWassignee_option=anyfield.assignee=field.bug_reporter=field.bug_commenter=field.subscriber=field.structural_subscriber=field.tag=field.tags_combinator=ANYfield.has_cve.used=field.omit_dupes.used=field.omit_dupes=onfield.affects_me.used=field.has_patch.used=field.has_branches.used=field.has_branches=onfield.has_no_branches.used=field.has_no_branches=onfield.has_blueprints.used=field.has_blueprints=onfield.has_no_blueprints.used=field.has_no_blueprints=on
  *   Critical 
Bugshttps://bugs.launchpad.net/nova/+bugs?field.searchtext=orderby=-importancesearch=Searchfield.status%3Alist=NEWfield.status%3Alist=CONFIRMEDfield.status%3Alist=TRIAGEDfield.status%3Alist=INCOMPLETE_WITH_RESPONSEfield.status%3Alist=INCOMPLETE_WITHOUT_RESPONSEfield.importance%3Alist=CRITICALassignee_option=anyfield.assignee=field.bug_reporter=field.bug_commenter=field.subscriber=field.structural_subscriber=field.tag=field.tags_combinator=ANYfield.has_cve.used=field.omit_dupes.used=field.omit_dupes=onfield.affects_me.used=field.has_patch.used=field.has_branches.used=field.has_branches=onfield.has_no_branches.used=field.has_no_branches=onfield.has_blueprints.used=field.has_blueprints=onfield.has_no_blueprints.used=field.has_no_blueprints=on
  *   Bugs without 
ownershttps://bugs.launchpad.net/nova/+bugs?field.searchtext=orderby=-importancesearch=Searchfield.status%3Alist=NEWfield.status%3Alist=CONFIRMEDfield.status%3Alist=TRIAGEDfield.status%3Alist=INPROGRESSassignee_option=nonefield.assignee=field.bug_reporter=field.bug_commenter=field.subscriber=field.structural_subscriber=field.tag=field.tags_combinator=ANYfield.has_cve.used=field.omit_dupes.used=field.omit_dupes=onfield.affects_me.used=field.has_patch.used=field.has_branches.used=field.has_branches=onfield.has_no_branches.used=field.has_no_branches=onfield.has_blueprints.used=field.has_blueprints=onfield.has_no_blueprints.used=field.has_no_blueprints=on
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] interests

[Tracy Jones]

If you have not updated the interest sheet (or if your interest has changed) 
please do so TODAY.  Let your top 3 interests on the interest tab of the 
spreadsheet.


https://docs.google.com/a/vmware.com/spreadsheets/d/1w01Z5J_XvTjbWBvPJ3SgzaQ9nXzOxSVVTGDjQtxAMZA/edit#gid=0


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

[openstack-dev] VMwareAPI sub-team reviews update 2013-09-30

[Tracy Jones]

 Low https://bugs.launchpad.net/bugs/1218593 ready for core




Meeting info:
 * https://wiki.openstack.org/wiki/Meetings/VMwareAPI
 * If anything is missing, please ping me so I can check it
 * the vmwareapi team hangs out in #openstack-vmware if you need to chat.

Happy stacking!

# Tracy Jones (tjones)

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

Re: [openstack-dev] [nova] Proposal to add Melanie Witt to nova-core

[Tracy Jones]

I’m not core - but Melanie has always been very helpful with me on bug triage 
issues [ when I was doing that consistently ;-) ]

+1




On 4/30/15, 4:30 AM, John Garbutt j...@johngarbutt.com wrote:

Hi,

I propose we add Melanie to nova-core.

She has been consistently doing great quality code reviews[1],
alongside a wide array of other really valuable contributions to the
Nova project.

Please respond with comments, +1s, or objections within one week.

Many thanks,
John

[1] https://review.openstack.org/#/dashboard/4690

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][vmware] CI results show up about a week late, if at all

[Tracy Jones]

Just FYI the VMware NSX CI job is back up and running!  We have added more 
resources and doing more updates so we can remain stable and timely.  Thanks 
for your patience

Tracy


From: Tracy Jones <tjo...@vmware.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Thursday, March 16, 2017 at 11:50 PM
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [nova][vmware] CI results show up about a week 
late, if at all

Yes unfortunately I am aware of it and we are struggling to correct it.  We 
recently have some new infrastructure that we can add to help with this.  I 
have a meeting early next week with the team to make this available and I hope 
for a quickish resolution.  I’ll update you here with the plan.

In addition to adding infra, we are also looking to add some periodic “health 
check” patches to alert us when things are going awry.

We have people online but they are in china and Bulgaria – so it does not help 
during the US timezone.  I’ll ask more folks in the US to hang out (including 
me) and you can always ping me directly 
(tjo...@vmware.com)<mailto:tjo...@vmware.com)>.

Tracy
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][vmware] CI results show up about a week late, if at all

[Tracy Jones]

Yes unfortunately I am aware of it and we are struggling to correct it.  We 
recently have some new infrastructure that we can add to help with this.  I 
have a meeting early next week with the team to make this available and I hope 
for a quickish resolution.  I’ll update you here with the plan.

In addition to adding infra, we are also looking to add some periodic “health 
check” patches to alert us when things are going awry.

We have people online but they are in china and Bulgaria – so it does not help 
during the US timezone.  I’ll ask more folks in the US to hang out (including 
me) and you can always ping me directly 
(tjo...@vmware.com).

Tracy
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] VMware Voting CI

[Tracy Jones]

Hi Sean – this was done in error and we have just fixed it.  Sorry for the 
confusion.

Tracy


Begin forwarded message:
From: Sean McGinnis >
Subject: [openstack-dev] VMware Voting CI
Date: May 3, 2017 at 7:06:55 AM PDT
To: 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Hey everyone,
I'm looking for some background on the VMware NSX CI. Specifically,
why this CI is enabled for voting.
We had discussed whether to have "stable" CI's vote in the Cinder
project a while back, and other than potentially some benefit in
doing scripted reporting, we couldn't really think of a good
reason to have third party CI voting.
This CI account, however, appears to be used for multiple projects.
I think it got voting rights via a different project. I'm just
wondering if there is still a valid reason for that.
I think this has come up before, and to be clear, it does not block
anything when there ends up a -1 from this CI. The issue I have
with it is when looking in a summary list of patches, even if Jenkins
has voted +1, if the VMware NSX CI has failed, it ends up with a big
ol' red -1 in the Verified column, making it look like there is an
issue with the patch. Which likely means unless someone is
specifically interested in that patch, they will see the red -1 and
move on.
Does anyone have the background as to why this CI has voting rights,
and whether it should still have them?
Thanks,
Sean (smcginnis)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev