date:20141205

On Tue, Nov 18, 2014 at 07:06:59AM -0500, Sean Dague wrote:
 Nova currently has 197 patches that have seen no activity in the last 4
 weeks (project:openstack/nova age:4weeks status:open).

On a somewhat related note, nova-specs currently has 17 specs
open against specs/juno, most with -2 votes. I think we should
just mass-abandon anything still touching the specs/juno directory.
If people cared about them still they would have submitted for
specs/kilo.

So any objection to killing everything in the list below:

+-+---+--+---+-+--+
| URL | Subject 
  | Created  | Tests | Reviews | Workflow |
+-+---+--+---+-+--+
| https://review.openstack.org/86938  | Add tasks to the v3 API 
  | 237 days |  1| -2  |  |
| https://review.openstack.org/88334  | Add support for USB controller  
  | 231 days |  1| -2  |  |
| https://review.openstack.org/89766  | Add useful metrics into utilization 
based scheduli... | 226 days |  1| -2  |  |
| https://review.openstack.org/90239  | Blueprint for Cinder Multi attach 
volumes | 224 days |  1| -2  |  |
| https://review.openstack.org/90647  | Add utilization based weighers on top 
of MetricsWe... | 221 days |  1| -2  |  |
| https://review.openstack.org/96543  | Smart Scheduler (Solver Scheduler) - 
Constraint ba... | 189 days |  1| -2  |  |
| https://review.openstack.org/97441  | Add nova spec for bp/isnot-operator 
  | 185 days |  1| -2  |  |
| https://review.openstack.org/99476  | Dedicate aggregates for specific 
tenants  | 176 days |  1| -2  |  |
| https://review.openstack.org/99576  | Add client token to CreateServer
  | 176 days |  1| -2  |  |
| https://review.openstack.org/101921 | Spec for Neutron migration feature  
  | 164 days |  1| -2  |  |
| https://review.openstack.org/103617 | Support Identity V3 API 
  | 157 days |  1| -1  |  |
| https://review.openstack.org/105385 | Leverage the features of IBM GPFS to 
store cached ... | 150 days |  1| -2  |  |
| https://review.openstack.org/108582 | Add ironic boot mode filters
  | 136 days |  1| -2  |  |
| https://review.openstack.org/110639 | Blueprint for the implementation of 
Nested Quota D... | 127 days |  1| -2  |  |
| https://review.openstack.org/111308 | Added VirtProperties object blueprint   
  | 125 days |  1| -2  |  |
| https://review.openstack.org/111745 | Improve instance boot time  
  | 122 days |  1| -2  |  |
| https://review.openstack.org/116280 | Add a new filter to implement project 
isolation fe... | 104 days |  1| -2  |  |
+-+---+--+---+-+--+


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [openstack-dev] [nova] policy on old / virtually abandoned patches

2014-12-05 Thread Matthew Oliver

I have a script that does 95% of what you want:

https://github.com/matthewoliver/swift_abandon_notifier

We are using it for swift reviews. At the moment the only thing it doesn't
do is actually abandon, it instead sends a warning email and waits n days
(2 weeks by default) for action, if it still turns up it adds it to a list
of abandoned changes.

Eg: http://abandoner.oliver.net.au

So anything that appears in that list can be abandoned by a core.

Feel free to use it (just uses a yaml file for configuration) and we can
all benefit from enhancements made ;)

Matt
On Dec 5, 2014 11:06 PM, Daniel P. Berrange berra...@redhat.com wrote:

 On Tue, Nov 18, 2014 at 07:06:59AM -0500, Sean Dague wrote:
  Nova currently has 197 patches that have seen no activity in the last 4
  weeks (project:openstack/nova age:4weeks status:open).

 On a somewhat related note, nova-specs currently has 17 specs
 open against specs/juno, most with -2 votes. I think we should
 just mass-abandon anything still touching the specs/juno directory.
 If people cared about them still they would have submitted for
 specs/kilo.

 So any objection to killing everything in the list below:


 +-+---+--+---+-+--+
 | URL | Subject
| Created  | Tests | Reviews | Workflow |

 +-+---+--+---+-+--+
 | https://review.openstack.org/86938  | Add tasks to the v3 API
  | 237 days |  1| -2  |  |
 | https://review.openstack.org/88334  | Add support for USB controller
 | 231 days |  1| -2  |  |
 | https://review.openstack.org/89766  | Add useful metrics into
 utilization based scheduli... | 226 days |  1| -2  |  |
 | https://review.openstack.org/90239  | Blueprint for Cinder Multi attach
 volumes | 224 days |  1| -2  |  |
 | https://review.openstack.org/90647  | Add utilization based weighers on
 top of MetricsWe... | 221 days |  1| -2  |  |
 | https://review.openstack.org/96543  | Smart Scheduler (Solver
 Scheduler) - Constraint ba... | 189 days |  1| -2  |  |
 | https://review.openstack.org/97441  | Add nova spec for
 bp/isnot-operator   | 185 days |  1| -2  |
 |
 | https://review.openstack.org/99476  | Dedicate aggregates for specific
 tenants  | 176 days |  1| -2  |  |
 | https://review.openstack.org/99576  | Add client token to CreateServer
 | 176 days |  1| -2  |  |
 | https://review.openstack.org/101921 | Spec for Neutron migration
 feature| 164 days |  1| -2  |  |
 | https://review.openstack.org/103617 | Support Identity V3 API
  | 157 days |  1| -1  |  |
 | https://review.openstack.org/105385 | Leverage the features of IBM GPFS
 to store cached ... | 150 days |  1| -2  |  |
 | https://review.openstack.org/108582 | Add ironic boot mode filters
 | 136 days |  1| -2  |  |
 | https://review.openstack.org/110639 | Blueprint for the implementation
 of Nested Quota D... | 127 days |  1| -2  |  |
 | https://review.openstack.org/111308 | Added VirtProperties object
 blueprint | 125 days |  1| -2  |  |
 | https://review.openstack.org/111745 | Improve instance boot time
 | 122 days |  1| -2  |  |
 | https://review.openstack.org/116280 | Add a new filter to implement
 project isolation fe... | 104 days |  1| -2  |  |

 +-+---+--+---+-+--+


 Regards,
 Daniel
 --
 |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
 :|
 |: http://libvirt.org  -o- http://virt-manager.org
 :|
 |: http://autobuild.org   -o- http://search.cpan.org/~danberr/
 :|
 |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc
 :|

 ___
 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] [all] OpenStack Bootstrapping Hour - Keystone - Friday Dec 5th 20:00 UTC (15:00 Americas/New_York)

On 12/05/2014 03:37 AM, Boris Bobrov wrote:
 On Thursday 04 December 2014 19:08:06 Sean Dague wrote:
 Sorry for the late announce, too much turkey and pie

 This Friday, Dec 5th, we'll be talking with Steve Martinelli and David
 Stanek about Keystone Authentication in OpenStack.
 
 Wiki page says that the event will be Friday Dec 5th - 19:00 UTC (15:00 
 Americas/New_York), while the subject in your mail has 20:00 UTC. Could you 
 please clarify that?

It's 20:00 UTC, sorry about that. With the DST switch it looks like
there was a bad copy/paste somewhere. Also the youtube link should give
you a real time countdown - https://www.youtube.com/watch?v=Th61TgUVnzU
to when it is.

-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

Re: [openstack-dev] [nova] policy on old / virtually abandoned patches

On Fri, Dec 05, 2014 at 11:16:28PM +1100, Matthew Oliver wrote:
 I have a script that does 95% of what you want:
 
 https://github.com/matthewoliver/swift_abandon_notifier
 
 We are using it for swift reviews. At the moment the only thing it doesn't
 do is actually abandon, it instead sends a warning email and waits n days
 (2 weeks by default) for action, if it still turns up it adds it to a list
 of abandoned changes.

Nova already has a similar script that does the abandon too, but both
yours  novas are based on activity / review feedback. I'm explicitly
considering abanadoning based on the file path for the spec.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository?

2014-12-05 Thread Ihar Hrachyshka

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 04/12/14 16:59, Vadivel Poonathan wrote:
 Hi Kyle and all,
 
 Was there any conclusion in the design summit or the meetings
 afterward about splitting the vendor plugins/drivers from the
 mainstream neutron and documentation of out-of-tree
 plugins/drivers?...

It's expected that the following spec that covers the plugins split to
be approved and implemented during Kilo:
https://review.openstack.org/134680

 
 Thanks, Vad --
 
 
 On Thu, Oct 23, 2014 at 11:27 AM, Kyle Mestery
 mest...@mestery.com mailto:mest...@mestery.com wrote:
 
 On Thu, Oct 23, 2014 at 12:35 PM, Vadivel Poonathan 
 vadivel.openst...@gmail.com mailto:vadivel.openst...@gmail.com 
 wrote:
 Hi Kyle and Anne,
 
 Thanks for the clarifications... understood and it makes sense.
 
 However, per my understanding, the drivers (aka plugins) are
 meant to be developed and supported by third-party vendors,
 outside of the OpenStack community, and they are supposed to work
 as plug-n-play... they are not part of the core OpenStack
 development, nor any of its components. If that is the case, then
 why should OpenStack community include and maintain them as part 
 of it, for every release?...  Wouldnt it be enough to limit the
 scope with the plugin framework and built-in drivers such as
 LinuxBridge or OVS etc?... not extending to commercial
 vendors?...  (It is just a curious question, forgive me if i
 missed something and correct me!).
 
 You haven't misunderstood anything, we're in the process of
 splitting these things out, and this will be a prime focus of the
 Neutron design summit track at the upcoming summit.
 
 Thanks, Kyle
 
 At the same time, IMHO, there must be some reference or a page
 within the
 scope of OpenStack documentation (not necessarily the core docs,
 but some
 wiki page or reference link or so - as Anne suggested) to
 mention
 the list
 of the drivers/plugins supported as of given release and may be
 an
 external
 link to know more details about the driver, if the link is
 provided by respective vendor.
 
 
 Anyway, besides my opinion, the wiki page similar to hypervisor
 driver would
 be good for now atleast, until the direction/policy level
 decision
 is made
 to maintain out-of-tree plugins/drivers.
 
 
 Thanks, Vad --
 
 
 
 
 On Thu, Oct 23, 2014 at 9:46 AM, Edgar Magana
 edgar.mag...@workday.com mailto:edgar.mag...@workday.com
 wrote:
 
 I second Anne’s and Kyle comments. Actually, I like very much
 the
 wiki
 part to provide some visibility for out-of-tree
 plugins/drivers
 but not into
 the official documentation.
 
 Thanks,
 
 Edgar
 
 From: Anne Gentle a...@openstack.org
 mailto:a...@openstack.org Reply-To: OpenStack Development
 Mailing List (not for usage
 questions)
 openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org
 Date: Thursday, October 23, 2014 at 8:51 AM To: Kyle Mestery
 mest...@mestery.com mailto:mest...@mestery.com Cc:
 OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Neutron] Neutron documentation
 to
 update
 about new vendor plugin, but without code in repository?
 
 
 
 On Thu, Oct 23, 2014 at 10:31 AM, Kyle Mestery
 mest...@mestery.com mailto:mest...@mestery.com
 wrote:
 
 Vad:
 
 The third-party CI is required for your upstream driver. I
 think what's different from my reading of this thread is the
 question of what is the requirement to have a driver listed
 in the upstream documentation which is not in the upstream
 codebase. To my
 knowledge,
 we haven't done this. Thus, IMHO, we should NOT be utilizing
 upstream
 documentation to document drivers which are themselves not
 upstream. When we split out the drivers which are currently
 upstream in
 neutron
 into a separate repo, they will still be upstream. So my
 opinion
 here
 is that if your driver is not upstream, it shouldn't be in
 the upstream documentation. But I'd like to hear others
 opinions as
 well.
 
 
 This is my sense as well.
 
 The hypervisor drivers are documented on the wiki, sometimes
 they're in-tree, sometimes they're not, but the state of
 testing is
 documented on
 the wiki. I think we could take this approach for network and
 storage drivers as well.
 
 https://wiki.openstack.org/wiki/HypervisorSupportMatrix
 
 Anne
 
 
 Thanks, Kyle
 
 On Thu, Oct 23, 2014 at 9:44 AM, Vadivel Poonathan 
 vadivel.openst...@gmail.com
 mailto:vadivel.openst...@gmail.com wrote:
 Kyle, Gentle reminder... when you get a chance!..
 
 Anne, In case, if i need to send it to different group or
 email-id
 to reach
 Kyle Mestery, pls. let me know. Thanks for your help.
 
 Regards, Vad --
 
 
 On Tue, Oct 21, 2014 at 8:51 AM, Vadivel Poonathan 
 vadivel.openst...@gmail.com
 mailto:vadivel.openst...@gmail.com wrote:
 
 Hi Kyle,
 
 Can you pls. comment on this discussion and confirm the
 requirements
 for getting out-of-tree mechanism_driver listed in the

[openstack-dev] [devstack] set -o nounset in devstack?

I got bit by another bug yesterday where there was a typo between
variables in the source tree. So I started down the process of set -o
nounset to see how bad it would be to prevent that in the future.

There are 2 major classes of issues where the code is functioning fine,
but is caught by nounset:

FOO=$(trueorfalse True $FOO)

if [[ -n $FOO ]]; ...


The trueorfalse issue can be fixed if we change the function to be:

function trueorfalse {
local xtrace=$(set +o | grep xtrace)
set +o xtrace
local default=$1
local testval=${!2+x}

[[ -z $testval ]]  { echo $default; return; }
[[ 0 no No NO false False FALSE =~ $testval ]]  { echo
False; return; }
[[ 1 yes Yes YES true True TRUE =~ $testval ]]  { echo True;
return; }
echo $default
$xtrace
}


FOO=$(trueorfalse True FOO)

... then works.

the -z and -n bits can be addressed with either FOO=${FOO:-} or an isset
function that interpolates. FOO=${FOO:-} actually feels better to me
because it's part of the spirit of things.

I've found a few bugs already even though I'm probably only about 20% to
a complete run working.


So... the question is, is this worth it? It's going to have fall out in
lesser used parts of the code where we don't catch things (like -o
errexit did). However it should help flush out a class of bugs in the
process.

Opinions from devstack contributors / users welcomed.

-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

Re: [openstack-dev] [nova] policy on old / virtually abandoned patches

2014-12-05 Thread Joe Gordon

On Dec 5, 2014 7:07 AM, Daniel P. Berrange berra...@redhat.com wrote:

 On Tue, Nov 18, 2014 at 07:06:59AM -0500, Sean Dague wrote:
  Nova currently has 197 patches that have seen no activity in the last 4
  weeks (project:openstack/nova age:4weeks status:open).

 On a somewhat related note, nova-specs currently has 17 specs
 open against specs/juno, most with -2 votes. I think we should
 just mass-abandon anything still touching the specs/juno directory.
 If people cared about them still they would have submitted for
 specs/kilo.

 So any objection to killing everything in the list below:

+1, makes sense to me.



+-+---+--+---+-+--+
 | URL | Subject
 | Created  | Tests | Reviews | Workflow |

+-+---+--+---+-+--+
 | https://review.openstack.org/86938  | Add tasks to the v3 API
 | 237 days |  1| -2  |  |
 | https://review.openstack.org/88334  | Add support for USB controller
| 231 days |  1| -2  |  |
 | https://review.openstack.org/89766  | Add useful metrics into
utilization based scheduli... | 226 days |  1| -2  |  |
 | https://review.openstack.org/90239  | Blueprint for Cinder Multi attach
volumes | 224 days |  1| -2  |  |
 | https://review.openstack.org/90647  | Add utilization based weighers on
top of MetricsWe... | 221 days |  1| -2  |  |
 | https://review.openstack.org/96543  | Smart Scheduler (Solver
Scheduler) - Constraint ba... | 189 days |  1| -2  |  |
 | https://review.openstack.org/97441  | Add nova spec for
bp/isnot-operator   | 185 days |  1| -2  |
|
 | https://review.openstack.org/99476  | Dedicate aggregates for specific
tenants  | 176 days |  1| -2  |  |
 | https://review.openstack.org/99576  | Add client token to CreateServer
| 176 days |  1| -2  |  |
 | https://review.openstack.org/101921 | Spec for Neutron migration
feature| 164 days |  1| -2  |  |
 | https://review.openstack.org/103617 | Support Identity V3 API
 | 157 days |  1| -1  |  |
 | https://review.openstack.org/105385 | Leverage the features of IBM GPFS
to store cached ... | 150 days |  1| -2  |  |
 | https://review.openstack.org/108582 | Add ironic boot mode filters
| 136 days |  1| -2  |  |
 | https://review.openstack.org/110639 | Blueprint for the implementation
of Nested Quota D... | 127 days |  1| -2  |  |
 | https://review.openstack.org/111308 | Added VirtProperties object
blueprint | 125 days |  1| -2  |  |
 | https://review.openstack.org/111745 | Improve instance boot time
| 122 days |  1| -2  |  |
 | https://review.openstack.org/116280 | Add a new filter to implement
project isolation fe... | 104 days |  1| -2  |  |

+-+---+--+---+-+--+


 Regards,
 Daniel
 --
 |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
:|
 |: http://libvirt.org  -o- http://virt-manager.org
:|
 |: http://autobuild.org   -o- http://search.cpan.org/~danberr/
:|
 |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc
:|

 ___
 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] policy on old / virtually abandoned patches

On 12/05/2014 08:05 AM, Joe Gordon wrote:
 
 On Dec 5, 2014 7:07 AM, Daniel P. Berrange berra...@redhat.com
 mailto:berra...@redhat.com wrote:

 On Tue, Nov 18, 2014 at 07:06:59AM -0500, Sean Dague wrote:
  Nova currently has 197 patches that have seen no activity in the last 4
  weeks (project:openstack/nova age:4weeks status:open).

 On a somewhat related note, nova-specs currently has 17 specs
 open against specs/juno, most with -2 votes. I think we should
 just mass-abandon anything still touching the specs/juno directory.
 If people cared about them still they would have submitted for
 specs/kilo.

 So any objection to killing everything in the list below:
 
 +1, makes sense to me.

Agreed. +1.

 


 +-+---+--+---+-+--+
 | URL | Subject   
| Created  | Tests | Reviews | Workflow |

 +-+---+--+---+-+--+
 | https://review.openstack.org/86938  | Add tasks to the v3 API   
| 237 days |  1| -2  |  |
 | https://review.openstack.org/88334  | Add support for USB
 controller| 231 days |  1| -2  |  |
 | https://review.openstack.org/89766  | Add useful metrics into
 utilization based scheduli... | 226 days |  1| -2  |  |
 | https://review.openstack.org/90239  | Blueprint for Cinder Multi
 attach volumes | 224 days |  1| -2  |  |
 | https://review.openstack.org/90647  | Add utilization based weighers
 on top of MetricsWe... | 221 days |  1| -2  |  |
 | https://review.openstack.org/96543  | Smart Scheduler (Solver
 Scheduler) - Constraint ba... | 189 days |  1| -2  |  |
 | https://review.openstack.org/97441  | Add nova spec for
 bp/isnot-operator   | 185 days |  1| -2  | 
 |
 | https://review.openstack.org/99476  | Dedicate aggregates for
 specific tenants  | 176 days |  1| -2  |  |
 | https://review.openstack.org/99576  | Add client token to
 CreateServer  | 176 days |  1| -2  |  |
 | https://review.openstack.org/101921 | Spec for Neutron migration
 feature| 164 days |  1| -2  |  |
 | https://review.openstack.org/103617 | Support Identity V3 API   
| 157 days |  1| -1  |  |
 | https://review.openstack.org/105385 | Leverage the features of IBM
 GPFS to store cached ... | 150 days |  1| -2  |  |
 | https://review.openstack.org/108582 | Add ironic boot mode filters 
 | 136 days |  1| -2  |  |
 | https://review.openstack.org/110639 | Blueprint for the
 implementation of Nested Quota D... | 127 days |  1| -2  | 
 |
 | https://review.openstack.org/111308 | Added VirtProperties object
 blueprint | 125 days |  1| -2  |  |
 | https://review.openstack.org/111745 | Improve instance boot time   
 | 122 days |  1| -2  |  |
 | https://review.openstack.org/116280 | Add a new filter to implement
 project isolation fe... | 104 days |  1| -2  |  |

 +-+---+--+---+-+--+


 Regards,
 Daniel
 --
 |: http://berrange.com  -o-   
 http://www.flickr.com/photos/dberrange/ :|
 |: http://libvirt.org  -o-   
  http://virt-manager.org :|
 |: http://autobuild.org   -o-   
  http://search.cpan.org/~danberr/ :|
 |: http://entangle-photo.org   -o- 
  http://live.gnome.org/gtk-vnc :|

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 mailto: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
 


-- 
Sean Dague
http://dague.net

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

[openstack-dev] [all] [tc] [PTL] Cascading vs. Cells – summit recap and move forward

2014-12-05 Thread joehuang

Dear all TC PTL,

In the 40 minutes cross-project summit session “Approaches for scaling out”[1],
almost 100 peoples attended the meeting, and the conclusion is that cells can
not cover the use cases and requirements which the OpenStack cascading
solution[2] aim to address, the background including use cases and requirements
is also described in the mail.

After the summit, we just ported the PoC[3] source code from IceHouse based to
Juno based.

Now, let's move forward:

The major task is to introduce new driver/agent to existing core projects, for
the core idea of cascading is to add Nova as the hypervisor backend of Nova,
Cinder as the block storage backend of Cinder, Neutron as the backend of
Neutron, Glance as one image location of Glance, Ceilometer as the store of
Ceilometer.
a). Need cross-program decision to run cascading as an incubated project mode
or register BP separately in each involved project. CI for cascading is quite
different from traditional test environment, at least 3 OpenStack instance
required for cross OpenStack networking test cases.
b). Volunteer as the cross project coordinator.
c). Volunteers for implementation and CI.

Background of OpenStack cascading vs cells:

1. Use cases
a). Vodafone use case[4](OpenStack summit speech video from 9'02 to 12'30 ),
establishing globally addressable tenants which result in efficient services
deployment.
b). Telefonica use case[5], create virtual DC( data center) cross multiple
physical DCs with seamless experience.
c). ETSI NFV use cases[6], especially use case #1, #2, #3, #5, #6, 8#. For NFV
cloud, it’s in nature the cloud will be distributed but inter-connected in many
data centers.

2.requirements
a). The operator has multiple sites cloud; each site can use one or multiple
vendor’s OpenStack distributions.
b). Each site with its own requirements and upgrade schedule while maintaining
standard OpenStack API
c). The multi-site cloud must provide unified resource management with global
Open API exposed, for example create virtual DC cross multiple physical DCs
with seamless experience.
Although a prosperity orchestration layer could be developed for the multi-site
cloud, but it's prosperity API in the north bound interface. The cloud
operators want the ecosystem friendly global open API for the mutli-site cloud
for global access.

3. What problems does cascading solve that cells doesn't cover:
OpenStack cascading solution is OpenStack orchestrate OpenStacks. The core
architecture idea of OpenStack cascading is to add Nova as the hypervisor
backend of Nova, Cinder as the block storage backend of Cinder, Neutron as the
backend of Neutron, Glance as one image location of Glance, Ceilometer as the
store of Ceilometer. Thus OpenStack is able to orchestrate OpenStacks (from
different vendor's distribution, or different version ) which may located in
different sites (or data centers ) through the OpenStack API, meanwhile the
cloud still expose OpenStack API as the north-bound API in the cloud level.

4. Why cells can’t do that:
Cells provide the scale out capability to Nova, but from the OpenStack as a
whole point of view, it’s still working like one OpenStack instance.
a). if Cells is deployed with shared Cinder, Neutron, Glance, Ceilometer. This
approach provides the multi-site cloud with one unified API endpoint and
unified resource management, but consolidation of multi-vendor/multi-version
OpenStack instances across one or more data centers cannot be fulfilled.
b). Each site installed one child cell and accompanied standalone Cinder,
Neutron(or Nova-network), Glance, Ceilometer. This approach makes
multi-vendor/multi-version OpenStack distribution co-existence in multi-site
seem to be feasible, but the requirement for unified API endpoint and unified
resource management cannot be fulfilled. Cross Neutron networking automation is
also missing, which should otherwise be done manually or use proprietary
orchestration layer.

For more information about cascading and cells, please refer to the discussion
thread before Paris Summit [7].

[1]Approaches for scaling out:
https://etherpad.openstack.org/p/kilo-crossproject-scale-out-openstack
[2]OpenStack cascading solution:
https://wiki.openstack.org/wiki/OpenStack_cascading_solution
[3]Cascading PoC: https://github.com/stackforge/tricircle
[4]Vodafone use case (9'02 to 12'30):
https://www.youtube.com/watch?v=-KOJYvhmxQI
[5]Telefonica use case:
http://www.telefonica.com/en/descargas/mwc/present_20140224.pdf
[6]ETSI NFV use cases:
http://www.etsi.org/deliver/etsi_gs/nfv/001_099/001/01.01.01_60/gs_nfv001v010101p.pdf
[7]Cascading thread before design summit:
http://openstack.10931.n7.nabble.com/all-tc-Multi-clouds-integration-by-OpenStack-cascading-td54115.html

Best Regards
Chaoyi Huang (joehuang)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org

[openstack-dev] [MagnetoDB] Intercycle release package versioning

2014-12-05 Thread Aleksei Chuprin (CS)

Hello everyone,

Because MagnetoDB project uses more frequent releases than other OpenStack 
projects, i propose use following versioning strategy for MagnetoDB packages:

1:2014.2-0ubuntu1
1:2014.2~rc2-0ubuntu1
1:2014.2~rc1-0ubuntu1
1:2014.2~b2-0ubuntu1
1:2014.2~b2.dev{MMDD}_{GIT_SHA1}-0ubuntu1
1:2014.2~b2.dev{MMDD}_{GIT_SHA1}-0ubuntu1
1:2014.2~b1-0ubuntu1

What do you think about this?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Spring cleaning nova-core

On Fri, Dec 05, 2014 at 11:05:28AM +1100, Michael Still wrote:
 One of the things that happens over time is that some of our core
 reviewers move on to other projects. This is a normal and healthy
 thing, especially as nova continues to spin out projects into other
 parts of OpenStack.
 
 However, it is important that our core reviewers be active, as it
 keeps them up to date with the current ways we approach development in
 Nova. I am therefore removing some no longer sufficiently active cores
 from the nova-core group.
 
 I’d like to thank the following people for their contributions over the years:
 
 * cbehrens: Chris Behrens
 * vishvananda: Vishvananda Ishaya
 * dan-prince: Dan Prince
 * belliott: Brian Elliott
 * p-draigbrady: Padraig Brady
 
 I’d love to see any of these cores return if they find their available
 time for code reviews increases.

What stats did you use to decide whether to cull these reviewers ? Looking
at the stats over a 6 month period, I think Padraig Brady is still having
a significant positive impact on Nova - on a par with both cerberus and
alaski who you've not proposing for cut. I think we should keep Padraig
on the team, but probably suggest cutting Markmc instead

  http://russellbryant.net/openstack-stats/nova-reviewers-180.txt

+-+++
|   Reviewer  | Reviews   -2  -1  +1  +2  +A+/- %  | 
Disagreements* |
+-+++
| berrange ** |1766   26 435  12 1293 35773.9% |  157 ( 
 8.9%)  |
| jaypipes ** |1359   11 378 436 534 13371.4%  |  109 ( 
 8.0%)  |
|   jogo **   |1053  131 326   7 589 35356.6%  |   47 ( 
 4.5%)  |
|   danms **  | 921   67 381  23 450 16751.4%  |   32 ( 
 3.5%)  |
|  oomichi ** | 8894 306  55 524 18265.1%  |   40 ( 
 4.5%)  |
|johngarbutt **   | 808  319 227  10 252 14532.4%  |   37 ( 
 4.6%)  |
|  mriedem ** | 642   27 279  25 311 13652.3%  |   17 ( 
 2.6%)  |
|  klmitch ** | 6061  90   2 513  7085.0%  |   67 ( 
11.1%)  |
| ndipanov ** | 588   19 179  10 380 11366.3%  |   62 ( 
10.5%)  |
|mikalstill **| 564   31  34   3 496 20788.5%  |   20 ( 
 3.5%)  |
|  cyeoh-0 ** | 546   12 207  30 297 10359.9%  |   35 ( 
 6.4%)  |
|  sdague **  | 511   23  89   6 393 22978.1%  |   25 ( 
 4.9%)  |
| russellb ** | 4656  83   0 376 15880.9%  |   23 ( 
 4.9%)  |
|  alaski **  | 4151  65  21 328 14984.1%  |   24 ( 
 5.8%)  |
| cerberus ** | 4056  25  48 326 10292.3%  |   33 ( 
 8.1%)  |
|   p-draigbrady **   | 3762  40   9 325  6488.8%  |   49 ( 
13.0%)  |
|  markmc **  | 2432  54   3 184  6977.0%  |   14 ( 
 5.8%)  |
| belliott ** | 2311  68   5 157  3570.1%  |   19 ( 
 8.2%)  |
|dan-prince **| 1782  48   9 119  2971.9%  |   11 ( 
 6.2%)  |
| cbehrens ** | 1322  49   2  79  1961.4%  |6 ( 
 4.5%)  |
|vishvananda **   |  540   5   3  46  1590.7%  |5 ( 
 9.3%)  |


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [openstack-dev] [Nova] Spring cleaning nova-core




On 12/5/2014 7:41 AM, Daniel P. Berrange wrote:

On Fri, Dec 05, 2014 at 11:05:28AM +1100, Michael Still wrote:

One of the things that happens over time is that some of our core
reviewers move on to other projects. This is a normal and healthy
thing, especially as nova continues to spin out projects into other
parts of OpenStack.

However, it is important that our core reviewers be active, as it
keeps them up to date with the current ways we approach development in
Nova. I am therefore removing some no longer sufficiently active cores
from the nova-core group.

I’d like to thank the following people for their contributions over the years:

* cbehrens: Chris Behrens
* vishvananda: Vishvananda Ishaya
* dan-prince: Dan Prince
* belliott: Brian Elliott
* p-draigbrady: Padraig Brady

I’d love to see any of these cores return if they find their available
time for code reviews increases.


What stats did you use to decide whether to cull these reviewers ? Looking
at the stats over a 6 month period, I think Padraig Brady is still having
a significant positive impact on Nova - on a par with both cerberus and
alaski who you've not proposing for cut. I think we should keep Padraig
on the team, but probably suggest cutting Markmc instead

   http://russellbryant.net/openstack-stats/nova-reviewers-180.txt

+-+++
|   Reviewer  | Reviews   -2  -1  +1  +2  +A+/- %  | 
Disagreements* |
+-+++
| berrange ** |1766   26 435  12 1293 35773.9% |  157 ( 
 8.9%)  |
| jaypipes ** |1359   11 378 436 534 13371.4%  |  109 ( 
 8.0%)  |
|   jogo **   |1053  131 326   7 589 35356.6%  |   47 ( 
 4.5%)  |
|   danms **  | 921   67 381  23 450 16751.4%  |   32 ( 
 3.5%)  |
|  oomichi ** | 8894 306  55 524 18265.1%  |   40 ( 
 4.5%)  |
|johngarbutt **   | 808  319 227  10 252 14532.4%  |   37 ( 
 4.6%)  |
|  mriedem ** | 642   27 279  25 311 13652.3%  |   17 ( 
 2.6%)  |
|  klmitch ** | 6061  90   2 513  7085.0%  |   67 ( 
11.1%)  |
| ndipanov ** | 588   19 179  10 380 11366.3%  |   62 ( 
10.5%)  |
|mikalstill **| 564   31  34   3 496 20788.5%  |   20 ( 
 3.5%)  |
|  cyeoh-0 ** | 546   12 207  30 297 10359.9%  |   35 ( 
 6.4%)  |
|  sdague **  | 511   23  89   6 393 22978.1%  |   25 ( 
 4.9%)  |
| russellb ** | 4656  83   0 376 15880.9%  |   23 ( 
 4.9%)  |
|  alaski **  | 4151  65  21 328 14984.1%  |   24 ( 
 5.8%)  |
| cerberus ** | 4056  25  48 326 10292.3%  |   33 ( 
 8.1%)  |
|   p-draigbrady **   | 3762  40   9 325  6488.8%  |   49 ( 
13.0%)  |
|  markmc **  | 2432  54   3 184  6977.0%  |   14 ( 
 5.8%)  |
| belliott ** | 2311  68   5 157  3570.1%  |   19 ( 
 8.2%)  |
|dan-prince **| 1782  48   9 119  2971.9%  |   11 ( 
 6.2%)  |
| cbehrens ** | 1322  49   2  79  1961.4%  |6 ( 
 4.5%)  |
|vishvananda **   |  540   5   3  46  1590.7%  |5 ( 
 9.3%)  |


Regards,
Daniel



FWIW, markmc is already off the list [1].

[1] https://review.openstack.org/#/admin/groups/25,members

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [Nova] Spring cleaning nova-core

2014-12-05 Thread Nikola Đipanov

On 12/05/2014 01:05 AM, Michael Still wrote:
 One of the things that happens over time is that some of our core
 reviewers move on to other projects. This is a normal and healthy
 thing, especially as nova continues to spin out projects into other
 parts of OpenStack.
 
 However, it is important that our core reviewers be active, as it
 keeps them up to date with the current ways we approach development in
 Nova. I am therefore removing some no longer sufficiently active cores
 from the nova-core group.
 
 I’d like to thank the following people for their contributions over the years:
 
 * cbehrens: Chris Behrens
 * vishvananda: Vishvananda Ishaya
 * dan-prince: Dan Prince
 * belliott: Brian Elliott
 * p-draigbrady: Padraig Brady
 

I am personally -1 on Padraig and Vish, especially Padraig. As one of
the coreutils maintainers - his contribution to Nova is invaluable
regardless whatever metrics you apply to his reviews makes him appear on
this list (hint - quality should really be the only one). Removing him
from core will probably not affect that, but I personally definitely
trust him to not vote +2 on the stuff he is not in touch with, and view
his +2 when I see them as a sign of thorough reviews. Also he has not
exactly been inactive lately by any measure.

Vish has not been active for some time now, but he is on IRC and in the
community still (as opposed to Chris for example), so not sure why do
this now.

N.


 I’d love to see any of these cores return if they find their available
 time for code reviews increases.
 
 Thanks,
 Michael
 


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

Re: [openstack-dev] [Nova] Spring cleaning nova-core

2014-12-05 Thread Sahid Orentino Ferdjaoui

On Fri, Dec 05, 2014 at 01:41:59PM +, Daniel P. Berrange wrote:
 On Fri, Dec 05, 2014 at 11:05:28AM +1100, Michael Still wrote:
  One of the things that happens over time is that some of our core
  reviewers move on to other projects. This is a normal and healthy
  thing, especially as nova continues to spin out projects into other
  parts of OpenStack.
  
  However, it is important that our core reviewers be active, as it
  keeps them up to date with the current ways we approach development in
  Nova. I am therefore removing some no longer sufficiently active cores
  from the nova-core group.
  
  I’d like to thank the following people for their contributions over the 
  years:
  
  * cbehrens: Chris Behrens
  * vishvananda: Vishvananda Ishaya
  * dan-prince: Dan Prince
  * belliott: Brian Elliott
  * p-draigbrady: Padraig Brady
  
  I’d love to see any of these cores return if they find their available
  time for code reviews increases.
 
 What stats did you use to decide whether to cull these reviewers ? Looking
 at the stats over a 6 month period, I think Padraig Brady is still having
 a significant positive impact on Nova - on a par with both cerberus and
 alaski who you've not proposing for cut. I think we should keep Padraig
 on the team, but probably suggest cutting Markmc instead
 
   http://russellbryant.net/openstack-stats/nova-reviewers-180.txt
 
 +-+++
 |   Reviewer  | Reviews   -2  -1  +1  +2  +A+/- %  | 
 Disagreements* |
 +-+++
 | berrange ** |1766   26 435  12 1293 35773.9% |  157 
 (  8.9%)  |
 | jaypipes ** |1359   11 378 436 534 13371.4%  |  109 
 (  8.0%)  |
 |   jogo **   |1053  131 326   7 589 35356.6%  |   47 
 (  4.5%)  |
 |   danms **  | 921   67 381  23 450 16751.4%  |   32 
 (  3.5%)  |
 |  oomichi ** | 8894 306  55 524 18265.1%  |   40 
 (  4.5%)  |
 |johngarbutt **   | 808  319 227  10 252 14532.4%  |   37 
 (  4.6%)  |
 |  mriedem ** | 642   27 279  25 311 13652.3%  |   17 
 (  2.6%)  |
 |  klmitch ** | 6061  90   2 513  7085.0%  |   67 
 ( 11.1%)  |
 | ndipanov ** | 588   19 179  10 380 11366.3%  |   62 
 ( 10.5%)  |
 |mikalstill **| 564   31  34   3 496 20788.5%  |   20 
 (  3.5%)  |
 |  cyeoh-0 ** | 546   12 207  30 297 10359.9%  |   35 
 (  6.4%)  |
 |  sdague **  | 511   23  89   6 393 22978.1%  |   25 
 (  4.9%)  |
 | russellb ** | 4656  83   0 376 15880.9%  |   23 
 (  4.9%)  |
 |  alaski **  | 4151  65  21 328 14984.1%  |   24 
 (  5.8%)  |
 | cerberus ** | 4056  25  48 326 10292.3%  |   33 
 (  8.1%)  |
 |   p-draigbrady **   | 3762  40   9 325  6488.8%  |   49 
 ( 13.0%)  |
 |  markmc **  | 2432  54   3 184  6977.0%  |   14 
 (  5.8%)  |
 | belliott ** | 2311  68   5 157  3570.1%  |   19 
 (  8.2%)  |
 |dan-prince **| 1782  48   9 119  2971.9%  |   11 
 (  6.2%)  |
 | cbehrens ** | 1322  49   2  79  1961.4%  |6 
 (  4.5%)  |
 |vishvananda **   |  540   5   3  46  1590.7%  |5 
 (  9.3%)  |
 

+1

Padraig gave to us several robust reviews on important topics. Lose him
will make more difficult the work on nova.

s.

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

Re: [openstack-dev] [Nova] Spring cleaning nova-core

On Fri, Dec 05, 2014 at 07:44:24AM -0600, Matt Riedemann wrote:
 
 
 On 12/5/2014 7:41 AM, Daniel P. Berrange wrote:
 On Fri, Dec 05, 2014 at 11:05:28AM +1100, Michael Still wrote:
 One of the things that happens over time is that some of our core
 reviewers move on to other projects. This is a normal and healthy
 thing, especially as nova continues to spin out projects into other
 parts of OpenStack.
 
 However, it is important that our core reviewers be active, as it
 keeps them up to date with the current ways we approach development in
 Nova. I am therefore removing some no longer sufficiently active cores
 from the nova-core group.
 
 I’d like to thank the following people for their contributions over the 
 years:
 
 * cbehrens: Chris Behrens
 * vishvananda: Vishvananda Ishaya
 * dan-prince: Dan Prince
 * belliott: Brian Elliott
 * p-draigbrady: Padraig Brady
 
 I’d love to see any of these cores return if they find their available
 time for code reviews increases.
 
 What stats did you use to decide whether to cull these reviewers ? Looking
 at the stats over a 6 month period, I think Padraig Brady is still having
 a significant positive impact on Nova - on a par with both cerberus and
 alaski who you've not proposing for cut. I think we should keep Padraig
 on the team, but probably suggest cutting Markmc instead
 
http://russellbryant.net/openstack-stats/nova-reviewers-180.txt
 
 +-+++
 |   Reviewer  | Reviews   -2  -1  +1  +2  +A+/- %  | 
 Disagreements* |
 +-+++
 | berrange ** |1766   26 435  12 1293 35773.9% |  
 157 (  8.9%)  |
 | jaypipes ** |1359   11 378 436 534 13371.4%  |  
 109 (  8.0%)  |
 |   jogo **   |1053  131 326   7 589 35356.6%  |   
 47 (  4.5%)  |
 |   danms **  | 921   67 381  23 450 16751.4%  |   
 32 (  3.5%)  |
 |  oomichi ** | 8894 306  55 524 18265.1%  |   
 40 (  4.5%)  |
 |johngarbutt **   | 808  319 227  10 252 14532.4%  |   
 37 (  4.6%)  |
 |  mriedem ** | 642   27 279  25 311 13652.3%  |   
 17 (  2.6%)  |
 |  klmitch ** | 6061  90   2 513  7085.0%  |   
 67 ( 11.1%)  |
 | ndipanov ** | 588   19 179  10 380 11366.3%  |   
 62 ( 10.5%)  |
 |mikalstill **| 564   31  34   3 496 20788.5%  |   
 20 (  3.5%)  |
 |  cyeoh-0 ** | 546   12 207  30 297 10359.9%  |   
 35 (  6.4%)  |
 |  sdague **  | 511   23  89   6 393 22978.1%  |   
 25 (  4.9%)  |
 | russellb ** | 4656  83   0 376 15880.9%  |   
 23 (  4.9%)  |
 |  alaski **  | 4151  65  21 328 14984.1%  |   
 24 (  5.8%)  |
 | cerberus ** | 4056  25  48 326 10292.3%  |   
 33 (  8.1%)  |
 |   p-draigbrady **   | 3762  40   9 325  6488.8%  |   
 49 ( 13.0%)  |
 |  markmc **  | 2432  54   3 184  6977.0%  |   
 14 (  5.8%)  |
 | belliott ** | 2311  68   5 157  3570.1%  |   
 19 (  8.2%)  |
 |dan-prince **| 1782  48   9 119  2971.9%  |   
 11 (  6.2%)  |
 | cbehrens ** | 1322  49   2  79  1961.4%  |
 6 (  4.5%)  |
 |vishvananda **   |  540   5   3  46  1590.7%  |
 5 (  9.3%)  |
 
 
 Regards,
 Daniel
 
 
 FWIW, markmc is already off the list [1].

Ah yes, must be that russell needs to update the config file for his script
to stop marking markmc as core.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells – summit recap and move forward

2014-12-05 Thread Davanum Srinivas

Joe,

Related to this topic, At the summit, there was a session on Cells v2
and following up on that there have been BP(s) filed in Nova
championed by Andrew -
https://review.openstack.org/#/q/owner:%22Andrew+Laski%22+status:open,n,z

thanks,
dims

On Fri, Dec 5, 2014 at 8:23 AM, joehuang joehu...@huawei.com wrote:
 Dear all  TC  PTL,

 In the 40 minutes cross-project summit session “Approaches for scaling 
 out”[1], almost 100 peoples attended the meeting, and the conclusion is that 
 cells can not cover the use cases and requirements which the OpenStack 
 cascading solution[2] aim to address, the background including use cases and 
 requirements is also described in the mail.

 After the summit, we just ported the PoC[3] source code from IceHouse based 
 to Juno based.

 Now, let's move forward:

 The major task is to introduce new driver/agent to existing core projects, 
 for the core idea of cascading is to add Nova as the hypervisor backend of 
 Nova, Cinder as the block storage backend of Cinder, Neutron as the backend 
 of Neutron, Glance as one image location of Glance, Ceilometer as the store 
 of Ceilometer.
 a). Need cross-program decision to run cascading as an incubated project mode 
 or register BP separately in each involved project. CI for cascading is quite 
 different from traditional test environment, at least 3 OpenStack instance 
 required for cross OpenStack networking test cases.
 b). Volunteer as the cross project coordinator.
 c). Volunteers for implementation and CI.

 Background of OpenStack cascading vs cells:

 1. Use cases
 a). Vodafone use case[4](OpenStack summit speech video from 9'02 to 12'30 
 ), establishing globally addressable tenants which result in efficient 
 services deployment.
 b). Telefonica use case[5], create virtual DC( data center) cross multiple 
 physical DCs with seamless experience.
 c). ETSI NFV use cases[6], especially use case #1, #2, #3, #5, #6, 8#. For 
 NFV cloud, it’s in nature the cloud will be distributed but inter-connected 
 in many data centers.

 2.requirements
 a). The operator has multiple sites cloud; each site can use one or multiple 
 vendor’s OpenStack distributions.
 b). Each site with its own requirements and upgrade schedule while 
 maintaining standard OpenStack API
 c). The multi-site cloud must provide unified resource management with global 
 Open API exposed, for example create virtual DC cross multiple physical DCs 
 with seamless experience.
 Although a prosperity orchestration layer could be developed for the 
 multi-site cloud, but it's prosperity API in the north bound interface. The 
 cloud operators want the ecosystem friendly global open API for the 
 mutli-site cloud for global access.

 3. What problems does cascading solve that cells doesn't cover:
 OpenStack cascading solution is OpenStack orchestrate OpenStacks. The core 
 architecture idea of OpenStack cascading is to add Nova as the hypervisor 
 backend of Nova, Cinder as the block storage backend of Cinder, Neutron as 
 the backend of Neutron, Glance as one image location of Glance, Ceilometer as 
 the store of Ceilometer. Thus OpenStack is able to orchestrate OpenStacks 
 (from different vendor's distribution, or different version ) which may 
 located in different sites (or data centers ) through the OpenStack API, 
 meanwhile the cloud still expose OpenStack API as the north-bound API in the 
 cloud level.

 4. Why cells can’t do that:
 Cells provide the scale out capability to Nova, but from the OpenStack as a 
 whole point of view, it’s still working like one OpenStack instance.
 a). if Cells is deployed with shared Cinder, Neutron, Glance, Ceilometer. 
 This approach provides the multi-site cloud with one unified API endpoint and 
 unified resource management, but consolidation of multi-vendor/multi-version 
 OpenStack instances across one or more data centers cannot be fulfilled.
 b). Each site installed one child cell and accompanied standalone Cinder, 
 Neutron(or Nova-network), Glance, Ceilometer. This approach makes 
 multi-vendor/multi-version OpenStack distribution co-existence in multi-site 
 seem to be feasible, but the requirement for unified API endpoint and unified 
 resource management cannot be fulfilled. Cross Neutron networking automation 
 is also missing, which should otherwise be done manually or use proprietary 
 orchestration layer.

 For more information about cascading and cells, please refer to the 
 discussion thread before Paris Summit [7].

 [1]Approaches for scaling out: 
 https://etherpad.openstack.org/p/kilo-crossproject-scale-out-openstack
 [2]OpenStack cascading solution: 
 https://wiki.openstack.org/wiki/OpenStack_cascading_solution
 [3]Cascading PoC: https://github.com/stackforge/tricircle
 [4]Vodafone use case (9'02 to 12'30): 
 https://www.youtube.com/watch?v=-KOJYvhmxQI
 [5]Telefonica use case: 
 http://www.telefonica.com/en/descargas/mwc/present_20140224.pdf
 [6]ETSI NFV use cases:

Re: [openstack-dev] [Nova] Spring cleaning nova-core

2014-12-05 Thread Brant Knudson

On Fri, Dec 5, 2014 at 7:56 AM, Daniel P. Berrange berra...@redhat.com
wrote:


  FWIW, markmc is already off the list [1].

 Ah yes, must be that russell needs to update the config file for his script
 to stop marking markmc as core.


 Regards,
 Daniel
 --



Anyone can do it: https://review.openstack.org/#/c/139637/

 - Brant



 |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
 :|
 |: http://libvirt.org  -o- http://virt-manager.org
 :|
 |: http://autobuild.org   -o- http://search.cpan.org/~danberr/
 :|
 |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc
 :|

 ___
 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] Session length on wiki.openstack.org

2014-12-05 Thread Jeremy Stanley

On 2014-12-04 18:37:48 -0700 (-0700), Carl Baldwin wrote:
 +1  I've been meaning to say something like this but never got
 around to it.  Thanks for speaking up.

https://storyboard.openstack.org/#!/story/1172753

I think Ryan said it might be a bug in the OpenID plug-in, but if so
he didn't put that comment in the bug.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Nova] Spring cleaning nova-core

2014-12-05 Thread Russell Bryant

On 12/05/2014 08:41 AM, Daniel P. Berrange wrote:
 On Fri, Dec 05, 2014 at 11:05:28AM +1100, Michael Still wrote:
 One of the things that happens over time is that some of our core
 reviewers move on to other projects. This is a normal and healthy
 thing, especially as nova continues to spin out projects into other
 parts of OpenStack.

 However, it is important that our core reviewers be active, as it
 keeps them up to date with the current ways we approach development in
 Nova. I am therefore removing some no longer sufficiently active cores
 from the nova-core group.

 I’d like to thank the following people for their contributions over the 
 years:

 * cbehrens: Chris Behrens
 * vishvananda: Vishvananda Ishaya
 * dan-prince: Dan Prince
 * belliott: Brian Elliott
 * p-draigbrady: Padraig Brady

 I’d love to see any of these cores return if they find their available
 time for code reviews increases.
 
 What stats did you use to decide whether to cull these reviewers ? Looking
 at the stats over a 6 month period, I think Padraig Brady is still having
 a significant positive impact on Nova - on a par with both cerberus and
 alaski who you've not proposing for cut. I think we should keep Padraig
 on the team, but probably suggest cutting Markmc instead
 
   http://russellbryant.net/openstack-stats/nova-reviewers-180.txt
 
 +-+++
 |   Reviewer  | Reviews   -2  -1  +1  +2  +A+/- %  | 
 Disagreements* |
 +-+++
 | berrange ** |1766   26 435  12 1293 35773.9% |  157 
 (  8.9%)  |
 | jaypipes ** |1359   11 378 436 534 13371.4%  |  109 
 (  8.0%)  |
 |   jogo **   |1053  131 326   7 589 35356.6%  |   47 
 (  4.5%)  |
 |   danms **  | 921   67 381  23 450 16751.4%  |   32 
 (  3.5%)  |
 |  oomichi ** | 8894 306  55 524 18265.1%  |   40 
 (  4.5%)  |
 |johngarbutt **   | 808  319 227  10 252 14532.4%  |   37 
 (  4.6%)  |
 |  mriedem ** | 642   27 279  25 311 13652.3%  |   17 
 (  2.6%)  |
 |  klmitch ** | 6061  90   2 513  7085.0%  |   67 
 ( 11.1%)  |
 | ndipanov ** | 588   19 179  10 380 11366.3%  |   62 
 ( 10.5%)  |
 |mikalstill **| 564   31  34   3 496 20788.5%  |   20 
 (  3.5%)  |
 |  cyeoh-0 ** | 546   12 207  30 297 10359.9%  |   35 
 (  6.4%)  |
 |  sdague **  | 511   23  89   6 393 22978.1%  |   25 
 (  4.9%)  |
 | russellb ** | 4656  83   0 376 15880.9%  |   23 
 (  4.9%)  |
 |  alaski **  | 4151  65  21 328 14984.1%  |   24 
 (  5.8%)  |
 | cerberus ** | 4056  25  48 326 10292.3%  |   33 
 (  8.1%)  |
 |   p-draigbrady **   | 3762  40   9 325  6488.8%  |   49 
 ( 13.0%)  |
 |  markmc **  | 2432  54   3 184  6977.0%  |   14 
 (  5.8%)  |
 | belliott ** | 2311  68   5 157  3570.1%  |   19 
 (  8.2%)  |
 |dan-prince **| 1782  48   9 119  2971.9%  |   11 
 (  6.2%)  |
 | cbehrens ** | 1322  49   2  79  1961.4%  |6 
 (  4.5%)  |
 |vishvananda **   |  540   5   3  46  1590.7%  |5 
 (  9.3%)  |
 

Yeah, I was pretty surprised to see pbrady on this list, as well.  The
above was 6 months, but even if you drop it to the most recent 3 months,
he's still active ...


 Reviews for the last 90 days in nova
 ** -- nova-core team member
 +-+---++
 |   Reviewer  | Reviews   -2  -1  +1  +2  +A+/- % | 
 Disagreements* |
 +-+---++
 | berrange ** | 708   13 145   1 549 20077.7% |   47 
 (  6.6%)  |
 |   jogo **   | 594   40 218   4 332 17456.6% |   27 
 (  4.5%)  |
 | jaypipes ** | 509   10 180  17 302  7762.7% |   33 
 (  6.5%)  |
 |  oomichi ** | 3921 136  10 245  7465.1% |6 
 (  1.5%)  |
 |   danms **  | 386   38 155  16 177  7750.0% |   16 
 (  4.1%)  |
 | ndipanov ** | 345   17 118   7 203  6160.9% |   32 
 (  9.3%)  |
 |  mriedem ** | 304   12 136  12 144  5651.3% |   12 
 (  3.9%)  |
 |  klmitch ** | 2811  42   0 238  1984.7% |   32 
 ( 11.4%)  |
 |  cyeoh-0 ** | 270   11 112  12 135  4754.4% |   13 
 (  4.8%)  |
 |mikalstill **| 2617   8   3 243 10694.3% |7 
 (  2.7%)

Re: [openstack-dev] [Fuel] Change diagnostic snapshot compression algoritm

2014-12-05 Thread Dmitry Pyzhov

I've moved the bug to 6.1. And I'm going to add it to our roadmap as a
separate item.

On Wed, Nov 26, 2014 at 1:31 PM, Mike Scherbakov mscherba...@mirantis.com
wrote:

 Can we put it as a work item for diagnostic snapshot improvements, so we
 won't forget about this in 6.1?


 On Tuesday, November 25, 2014, Dmitry Pyzhov dpyz...@mirantis.com wrote:

 Thank you all for your feedback. Request postponed to the next release.
 We will compare available solutions.

 On Mon, Nov 24, 2014 at 2:36 PM, Vladimir Kuklin vkuk...@mirantis.com
 wrote:

 guys, there is already pxz utility in ubuntu repos. let's test it

 On Mon, Nov 24, 2014 at 2:32 PM, Bartłomiej Piotrowski 
 bpiotrow...@mirantis.com wrote:

 On 24 Nov 2014, at 12:25, Matthew Mosesohn mmoses...@mirantis.com
 wrote:
  I did this exercise over many iterations during Docker container
  packing and found that as long as the data is under 1gb, it's going to
  compress really well with xz. Over 1gb and lrzip looks more attractive
  (but only on high memory systems). In reality, we're looking at log
  footprints from OpenStack environments on the order of 500mb to 2gb.
 
  xz is very slow on single-core systems with 1.5gb of memory, but it's
  quite a bit faster if you run it on a more powerful system. I've found
  level 4 compression to be the best compromise that works well enough
  that it's still far better than gzip. If increasing compression time
  by 3-5x is too much for you guys, why not just go to bzip? You'll
  still improve compression but be able to cut back on time.
 
  Best Regards,
  Matthew Mosesohn

 Alpha release of xz supports multithreading via -T (or —threads)
 parameter.
 We could also use pbzip2 instead of regular bzip to cut some time on
 multi-core
 systems.

 Regards,
 Bartłomiej Piotrowski
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Yours Faithfully,
 Vladimir Kuklin,
 Fuel Library Tech Lead,
 Mirantis, Inc.
 +7 (495) 640-49-04
 +7 (926) 702-39-68
 Skype kuklinvv
 45bk3, Vorontsovskaya Str.
 Moscow, Russia,
 www.mirantis.com http://www.mirantis.ru/
 www.mirantis.ru
 vkuk...@mirantis.com

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




 --
 Mike Scherbakov
 #mihgen



 ___
 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] [oslo] bug triage and review backlog sprint retrospective

2014-12-05 Thread Doug Hellmann

The Oslo team spent yesterday working on our backlog. We triaged all of our 
“New” bugs and re-triaged many of the other existing open bugs, closing some as 
obsolete or fixed. We reviewed many patches in the backlog as well, and landed 
quite a few. We did not clear as much of the backlog for our “big” libraries as 
I had hoped, but we still made good progress on the other libraries.

The oslo.db, oslo.messaging, and taskflow libraries all have quite large 
backlogs of reviews to be done. These libraries require some specialized 
knowledge, and so it was a little more difficult to include them in the bulk 
review sprint. I would like to schedule separate review days each of these 
libraries in turn. We will talk about this at the next team meeting and see if 
we can schedule the first for a few weeks from now.

We used https://etherpad.openstack.org/p/oslo-kilo-sprint for coordinating, and 
you’ll find more detailed notes there if you’re interested.

Thanks to everyone who participated!
Doug


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

Re: [openstack-dev] [OpenStack-Infra] [third-party]Time for Additional Meeting for third-party

2014-12-05 Thread Kurt Taylor

In my opinion, further discussion is needed. The proposal on the table is
to have 2 weekly meetings, one at the existing time of 1800UTC on Monday
and, also in the same week, to have another meeting at 0800 UTC on Tuesday.

Here are some of the problems that I see with this approach:

1. Meeting content: Having 2 meetings per week is more than is needed at
this stage of the working group. There just isn't enough meeting content to
justify having two meetings every week.

2. Decisions: Any decision made at one meeting will potentially be undone
at the next, or at least not fully explained. It will be difficult to keep
consistent direction with the overall work group.

3. Meeting chair(s): Currently we do not have a commitment for a long-term
chair of this new second weekly meeting. I will not be able to attend this
new meeting at the proposed time.

4. Current meeting time: I am not aware of anyone that likes the current
time of 1800 UTC on Monday. The current time is the main reason it is hard
for EU and APAC CI Operators to attend.

My proposal was to have only 1 meeting per week at alternating times, just
as other work groups have done to solve this problem. (See examples at:
https://wiki.openstack.org/wiki/Meetings)  I volunteered to chair, then ask
other CI Operators to chair as the meetings evolved. The meeting times
could be any between 1300-0300 UTC. That way, one week we are good for US
and Europe, the next week for APAC.

Kurt Taylor (krtaylor)


On Wed, Dec 3, 2014 at 11:10 PM, trinath.soman...@freescale.com 
trinath.soman...@freescale.com wrote:

 +1.

 --
 Trinath Somanchi - B39208
 trinath.soman...@freescale.com | extn: 4048

 -Original Message-
 From: Anita Kuno [mailto:ante...@anteaya.info]
 Sent: Thursday, December 04, 2014 3:55 AM
 To: openstack-in...@lists.openstack.org
 Subject: Re: [OpenStack-Infra] [openstack-dev] [third-party]Time for
 Additional Meeting for third-party

 On 12/03/2014 03:15 AM, Omri Marcovitch wrote:
  Hello Anteaya,
 
  A meeting between 8:00 - 16:00 UTC time will be great (Israel).
 
 
  Thanks
  Omri
 
  -Original Message-
  From: Joshua Hesketh [mailto:joshua.hesk...@rackspace.com]
  Sent: Wednesday, December 03, 2014 9:04 AM
  To: He, Yongli; OpenStack Development Mailing List (not for usage
  questions); openstack-in...@lists.openstack.org
  Subject: Re: [openstack-dev] [OpenStack-Infra] [third-party]Time for
  Additional Meeting for third-party
 
  Hey,
 
  0700 - 1000 UTC would work for me most weeks fwiw.
 
  Cheers,
  Josh
 
  Rackspace Australia
 
  On 12/3/14 11:17 AM, He, Yongli wrote:
  anteaya,
 
  UTC 7:00 AM to UTC9:00, or UTC11:30 to UTC13:00 is ideal time for china.
 
  if there is no time slot there, just pick up any time between UTC
  7:00 AM to UCT 13:00. ( UTC9:00 to UTC 11:30 is on road to home and
  dinner.)
 
  Yongi He
  -Original Message-
  From: Anita Kuno [mailto:ante...@anteaya.info]
  Sent: Tuesday, December 02, 2014 4:07 AM
  To: openstack Development Mailing List;
  openstack-in...@lists.openstack.org
  Subject: [openstack-dev] [third-party]Time for Additional Meeting for
  third-party
 
  One of the actions from the Kilo Third-Party CI summit session was to
 start up an additional meeting for CI operators to participate from
 non-North American time zones.
 
  Please reply to this email with times/days that would work for you. The
 current third party meeting is on Mondays at 1800 utc which works well
 since Infra meetings are on Tuesdays. If we could find a time that works
 for Europe and APAC that is also on Monday that would be ideal.
 
  Josh Hesketh has said he will try to be available for these meetings,
 he is in Australia.
 
  Let's get a sense of what days and timeframes work for those interested
 and then we can narrow it down and pick a channel.
 
  Thanks everyone,
  Anita.
 

 Okay first of all thanks to everyone who replied.

 Again, to clarify, the purpose of this thread has been to find a suitable
 additional third-party meeting time geared towards folks in EU and APAC. We
 live on a sphere, there is no time that will suit everyone.

 It looks like we are converging on 0800 UTC as a time and I am going to
 suggest Tuesdays. We have very little competition for space at that date
 + time combination so we can use #openstack-meeting (I have already
 booked the space on the wikipage).

 So barring further discussion, see you then!

 Thanks everyone,
 Anita.

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

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

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

[openstack-dev] [poppy] Kilo-2 Priorities

2014-12-05 Thread Amit Gandhi

Thanks everyone who attended the weekly meeting yesterday.

Great job in delivering on the kilo-1 deliverables for Poppy CDN.  
https://launchpad.net/poppy/+milestone/kilo-1

We were able to be dev complete the following items:
- The ability to configure a service containing domains, origins, caching 
rules, and restrictions with a CDN provider
- The ability to purge content from a CDN provider
- The ability to define flavors
- The ability to check the health of the system
- The following Transport drivers - Pecan
- The following Storage drivers - Cassandra
- The following DNS drivers - Rackspace Cloud DNS
- The following CDN providers - Akamai, Fastly, MaxCDN, Amazon CloudFront


As we move focus on to the Kilo-2 milestone,  lets put emphasis around testing, 
bug fixing, refactoring, and making the work done up to now reliable and well 
tested, before we move on to the next set of major features.

I have updated the kilo-2 milestone deliverables to reflect these goals. 
https://launchpad.net/poppy/+milestone/kilo-2

Thanks

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

Re: [openstack-dev] [tripleo] Managing no-mergepy template duplication

2014-12-05 Thread Dan Prince

On Wed, 2014-12-03 at 14:42 +0100, Tomas Sedovic wrote:
 On 12/03/2014 11:11 AM, Steven Hardy wrote:
  Hi all,
 
  Lately I've been spending more time looking at tripleo and doing some
  reviews. I'm particularly interested in helping the no-mergepy and
  subsequent puppet-software-config implementations mature (as well as
  improving overcloud updates via heat).
 
  Since Tomas's patch landed[1] to enable --no-mergepy in
  tripleo-heat-templates, it's become apparent that frequently patches are
  submitted which only update overcloud-source.yaml, so I've been trying to
  catch these and ask for a corresponding change to e.g controller.yaml.
 
 
 You beat me to this. Thanks for writing it up!
 
  This raises the following questions:
 
  1. Is it reasonable to -1 a patch and ask folks to update in both places?
 
 I'm in favour.
 
  2. How are we going to handle this duplication and divergence?


To follow this up we are getting in really bad shape with divergence
already. I found 3 missing sets of Rabbit, Keystone, and Neutron DVR
parameters which due to the merge window were properly ported into
overcloud-without-mergepy.yaml yet.

https://review.openstack.org/#/c/139649/ (missing Rabbit parameters)

https://review.openstack.org/#/c/139656/ (missing Keystone parameters)

https://review.openstack.org/#/c/139671/ (missing Neutron DVR
parameters)

We need to be very careful at this point not to continue merging things
into overcloud-source.yaml which don't have the equivalent bits for
overcloud-without-mergepy.yaml.

Dan

 
 I'm not sure we can. get_file doesn't handle structured data and I don't 
 know what else we can do. Maybe we could split out all SoftwareConfig 
 resources to separate files (like Dan did in [nova config])? But the 
 SoftwareDeployments, nova servers, etc. have a different structure.
 
 [nova config] https://review.openstack.org/#/c/130303/
 
  3. What's the status of getting gating CI on the --no-mergepy templates?
 
 Derek, can we add a job that's identical to 
 check-tripleo-ironic-overcloud-{f20,precise}-nonha except it passes 
 --no-mergepy to devtest.sh?
 
  4. What barriers exist (now that I've implemented[2] the eliding 
  functionality
  requested[3] for ResourceGroup) to moving to the --no-mergepy
  implementation by default?
 
 I'm about to post a patch that moves us from ResourceGroup to 
 AutoScalingGroup (for rolling updates), which is going to complicate 
 this a bit.
 
 Barring that, I think you've identified all the requirements: CI job, 
 parity between the merge/non-merge templates and a process that 
 maintains it going forward (or puts the old ones in a maintanence-only 
 mode).
 
 Anyone have anything else that's missing?
 
 
  Thanks for any clarification you can provide! :)
 
  Steve
 
  [1] https://review.openstack.org/#/c/123100/
  [2] https://review.openstack.org/#/c/128365/
  [3] https://review.openstack.org/#/c/123713/
 
  ___
  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] Spring cleaning nova-core

2014-12-05 Thread Joe Gordon

On Fri, Dec 5, 2014 at 4:39 PM, Russell Bryant rbry...@redhat.com wrote:

 On 12/05/2014 08:41 AM, Daniel P. Berrange wrote:
  On Fri, Dec 05, 2014 at 11:05:28AM +1100, Michael Still wrote:
  One of the things that happens over time is that some of our core
  reviewers move on to other projects. This is a normal and healthy
  thing, especially as nova continues to spin out projects into other
  parts of OpenStack.
 
  However, it is important that our core reviewers be active, as it
  keeps them up to date with the current ways we approach development in
  Nova. I am therefore removing some no longer sufficiently active cores
  from the nova-core group.
 
  I’d like to thank the following people for their contributions over the
 years:
 
  * cbehrens: Chris Behrens
  * vishvananda: Vishvananda Ishaya
  * dan-prince: Dan Prince
  * belliott: Brian Elliott
  * p-draigbrady: Padraig Brady
 
  I’d love to see any of these cores return if they find their available
  time for code reviews increases.
 
  What stats did you use to decide whether to cull these reviewers ?
 Looking
  at the stats over a 6 month period, I think Padraig Brady is still having
  a significant positive impact on Nova - on a par with both cerberus and
  alaski who you've not proposing for cut. I think we should keep Padraig
  on the team, but probably suggest cutting Markmc instead
 
http://russellbryant.net/openstack-stats/nova-reviewers-180.txt
 
 
 +-+++
  |   Reviewer  | Reviews   -2  -1  +1  +2  +A+/- %  |
 Disagreements* |
 
 +-+++
  | berrange ** |1766   26 435  12 1293 35773.9%
 |  157 (  8.9%)  |
  | jaypipes ** |1359   11 378 436 534 13371.4%
 |  109 (  8.0%)  |
  |   jogo **   |1053  131 326   7 589 35356.6%
 |   47 (  4.5%)  |
  |   danms **  | 921   67 381  23 450 16751.4%
 |   32 (  3.5%)  |
  |  oomichi ** | 8894 306  55 524 18265.1%
 |   40 (  4.5%)  |
  |johngarbutt **   | 808  319 227  10 252 14532.4%
 |   37 (  4.6%)  |
  |  mriedem ** | 642   27 279  25 311 13652.3%
 |   17 (  2.6%)  |
  |  klmitch ** | 6061  90   2 513  7085.0%
 |   67 ( 11.1%)  |
  | ndipanov ** | 588   19 179  10 380 11366.3%
 |   62 ( 10.5%)  |
  |mikalstill **| 564   31  34   3 496 20788.5%
 |   20 (  3.5%)  |
  |  cyeoh-0 ** | 546   12 207  30 297 10359.9%
 |   35 (  6.4%)  |
  |  sdague **  | 511   23  89   6 393 22978.1%
 |   25 (  4.9%)  |
  | russellb ** | 4656  83   0 376 15880.9%
 |   23 (  4.9%)  |
  |  alaski **  | 4151  65  21 328 14984.1%
 |   24 (  5.8%)  |
  | cerberus ** | 4056  25  48 326 10292.3%
 |   33 (  8.1%)  |
  |   p-draigbrady **   | 3762  40   9 325  6488.8%
 |   49 ( 13.0%)  |
  |  markmc **  | 2432  54   3 184  6977.0%
 |   14 (  5.8%)  |
  | belliott ** | 2311  68   5 157  3570.1%
 |   19 (  8.2%)  |
  |dan-prince **| 1782  48   9 119  2971.9%
 |   11 (  6.2%)  |
  | cbehrens ** | 1322  49   2  79  1961.4%
 |6 (  4.5%)  |
  |vishvananda **   |  540   5   3  46  1590.7%
 |5 (  9.3%)  |
 

 Yeah, I was pretty surprised to see pbrady on this list, as well.  The
 above was 6 months, but even if you drop it to the most recent 3 months,
 he's still active ...


As you are more then aware of, our policy for removing people from core is
to leave that up the the PTL (I believe you wrote that) [0]. And I don't
think numbers alone are a good metric for sorting out who to remove.  That
being said no matter what happens, with our fast track policy, if pbrady is
dropped it shouldn't be hard to re-add him.


[0]
https://wiki.openstack.org/wiki/Nova/CoreTeam#Adding_or_Removing_Members
https://wiki.openstack.org/wiki/Nova/CoreTeam#Adding_or_Removing_Members




  Reviews for the last 90 days in nova
  ** -- nova-core team member
 
 +-+---++
  |   Reviewer  | Reviews   -2  -1  +1  +2  +A+/- % |
 Disagreements* |
 
 +-+---++
  | berrange ** | 708   13 145   1 549 20077.7% |
  47 (  6.6%)  |
  |   jogo **   | 594   40 218   4 332 17456.6% |
  27 (  4.5%)  |
  | jaypipes ** | 509   10 180  17 302  7762.7% |
  33 (  6.5%)  |
  |  oomichi ** | 3921 136

Re: [openstack-dev] [Nova] Spring cleaning nova-core

2014-12-05 Thread Russell Bryant

On 12/05/2014 11:23 AM, Joe Gordon wrote:
 As you are more then aware of, our policy for removing people from core
 is to leave that up the the PTL (I believe you wrote that) [0]. And I
 don't think numbers alone are a good metric for sorting out who to
 remove.  That being said no matter what happens, with our fast track
 policy, if pbrady is dropped it shouldn't be hard to re-add him.

Yes, I'm aware of and not questioning the policy.  Usually drops are
pretty obvious.  This one wasn't.  It seems reasonable to discuss.
Maybe we don't have a common set of expectations.  Anyway, I'll follow
up in private.

-- 
Russell Bryant

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

Re: [openstack-dev] [nova] global or per-project specific ssl config options, or both?

2014-12-05 Thread Matthew Gilliard

I just put up a quick pre-weekend POC at
https://review.openstack.org/#/c/139672/ - comments welcome on that
patch.

Thanks :)

On Fri, Dec 5, 2014 at 10:07 AM, Matthew Gilliard
matthew.gilli...@gmail.com wrote:
 Hi Matt, Nova,

   I'll look into this.

 Gilliard

 On Thu, Dec 4, 2014 at 9:51 PM, Matt Riedemann
 mrie...@linux.vnet.ibm.com wrote:


 On 12/4/2014 6:02 AM, Davanum Srinivas wrote:

 +1 to @markmc's default is global value and override for project
 specific key suggestion.

 -- dims



 On Wed, Dec 3, 2014 at 11:57 PM, Matt Riedemann
 mrie...@linux.vnet.ibm.com wrote:

 I've posted this to the 12/4 nova meeting agenda but figured I'd
 socialize
 it here also.

 SSL options - do we make them per-project or global, or both? Neutron and
 Cinder have config-group specific SSL options in nova, Glance is using
 oslo
 sslutils global options since Juno which was contentious for a time in a
 separate review in Icehouse [1].

 Now [2] wants to break that out for Glance, but we also have a patch [3]
 for
 Keystone to use the global oslo SSL options, we should be consistent, but
 does that require a blueprint now?

 In the Icehouse patch, markmc suggested using a DictOpt where the default
 value is the global value, which could be coming from the oslo [ssl]
 group
 and then you could override that with a project-specific key, e.g.
 cinder,
 neutron, glance, keystone.

 [1] https://review.openstack.org/#/c/84522/
 [2] https://review.openstack.org/#/c/131066/
 [3] https://review.openstack.org/#/c/124296/

 --

 Thanks,

 Matt Riedemann


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





 The consensus in the nova meeting today, I think, was that we generally like
 the idea of the DictOpt with global oslo ssl as the default and then be able
 to configure that per-service if needed.

 Does anyone want to put up a POC on how that would work to see how ugly
 and/or usable that would be?  I haven't dug into the DictOpt stuff yet and
 am kind of time-constrained at the moment.


 --

 Thanks,

 Matt Riedemann


 ___
 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] Spring cleaning nova-core

2014-12-05 Thread Joe Gordon

On Dec 5, 2014 11:39 AM, Russell Bryant rbry...@redhat.com wrote:

 On 12/05/2014 11:23 AM, Joe Gordon wrote:
  As you are more then aware of, our policy for removing people from core
  is to leave that up the the PTL (I believe you wrote that) [0]. And I
  don't think numbers alone are a good metric for sorting out who to
  remove.  That being said no matter what happens, with our fast track
  policy, if pbrady is dropped it shouldn't be hard to re-add him.

 Yes, I'm aware of and not questioning the policy.  Usually drops are
 pretty obvious.  This one wasn't.  It seems reasonable to discuss.
 Maybe we don't have a common set of expectations.  Anyway, I'll follow
 up in private.


Agreed

 --
 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

Re: [openstack-dev] [neutron] - the setup of a DHCP sub-group

2014-12-05 Thread Chuck Carlino


On 11/26/2014 08:55 PM, Don Kehn wrote:
Sure, will try and gen to it over the holiday, do you have a link to 
the spec repo?



Hi Don,

Has there been any progress on a DHCP sub-group?

Regards,
Chuck


On Mon, Nov 24, 2014 at 3:27 PM, Carl Baldwin c...@ecbaldwin.net 
mailto:c...@ecbaldwin.net wrote:


Don,

Could the spec linked to your BP be moved to the specs repository?
I'm hesitant to start reading it as a google doc when I know I'm going
to want to make comments and ask questions.

Carl

On Thu, Nov 13, 2014 at 9:19 AM, Don Kehn dek...@gmail.com
mailto:dek...@gmail.com wrote:
 If this shows up twice sorry for the repeat:

 Armando, Carl:
 During the Summit, Armando and I had a very quick conversation
concern a
 blue print that I submitted,

https://blueprints.launchpad.net/neutron/+spec/dhcp-cpnr-integration
and
 Armando had mention the possibility of getting together a
sub-group tasked
 with DHCP Neutron concerns. I have talk with Infoblox folks (see
 https://blueprints.launchpad.net/neutron/+spec/neutron-ipam),
and everyone
 seems to be in agreement that there is synergy especially
concerning the
 development of a relay and potentially looking into how DHCP is
handled. In
 addition during the Fridays meetup session on DHCP that I gave
there seems
 to be some general interest by some of the operators as well.

 So what would be the formality in going forth to start a
sub-group and
 getting this underway?

 DeKehn



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


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




--

Don Kehn
303-442-0060


___
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] [devstack] set -o nounset in devstack?

2014-12-05 Thread Dean Troyer

On Fri, Dec 5, 2014 at 6:45 AM, Sean Dague s...@dague.net wrote:

 I got bit by another bug yesterday where there was a typo between
 variables in the source tree. So I started down the process of set -o
 nounset to see how bad it would be to prevent that in the future.


[...]


 The trueorfalse issue can be fixed if we change the function to be:

 function trueorfalse {
 local xtrace=$(set +o | grep xtrace)
 set +o xtrace
 local default=$1
 local testval=${!2+x}

 [[ -z $testval ]]  { echo $default; return; }


There should be an $xtrace in that return path


 [[ 0 no No NO false False FALSE =~ $testval ]]  { echo
 False; return; }
 [[ 1 yes Yes YES true True TRUE =~ $testval ]]  { echo True;
 return; }
 echo $default
 $xtrace
 }


 FOO=$(trueorfalse True FOO)

 ... then works.


I'm good with this.


 the -z and -n bits can be addressed with either FOO=${FOO:-} or an isset
 function that interpolates. FOO=${FOO:-} actually feels better to me
 because it's part of the spirit of things.


I think I agree, but we have a lot og is_*() functions so that wouldn't be
to far of a departure, I could be convinced either way I suppose.  This is
going to be the hard part of the cleanup and ongoing enforcement.


 So... the question is, is this worth it? It's going to have fall out in
 lesser used parts of the code where we don't catch things (like -o
 errexit did). However it should help flush out a class of bugs in the
 process.


This is going to be a long process to do the change, I think we will need
to bracket parts of the code as they get cleaned up to avoid regressions
slipping in.

dt

-- 

Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use Cases that led us to adopt this.

2014-12-05 Thread Stephen Balukoff

German-- but the point is that sharing apparently has no effect on the
number of permutations for status information. The only difference here is
that without sharing it's more work for the user to maintain and modify
trees of objects.

On Fri, Dec 5, 2014 at 9:36 AM, Eichberger, German german.eichber...@hp.com
 wrote:

  Hi Brandon + Stephen,



 Having all those permutations (and potentially testing them) made us lean
 against the sharing case in the first place. It’s just a lot of extra work
 for only a small number of our customers.



 German



 *From:* Stephen Balukoff [mailto:sbaluk...@bluebox.net]
 *Sent:* Thursday, December 04, 2014 9:17 PM

 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS -
 Use Cases that led us to adopt this.



 Hi Brandon,



 Yeah, in your example, member1 could potentially have 8 different statuses
 (and this is a small example!)...  If that member starts flapping, it means
 that every time it flaps there are 8 notifications being passed upstream.



 Note that this problem actually doesn't get any better if we're not
 sharing objects but are just duplicating them (ie. not sharing objects but
 the user makes references to the same back-end machine as 8 different
 members.)



 To be honest, I don't see sharing entities at many levels like this being
 the rule for most of our installations-- maybe a few percentage points of
 installations will do an excessive sharing of members, but I doubt it. So
 really, even though reporting status like this is likely to generate a
 pretty big tree of data, I don't think this is actually a problem, eh. And
 I don't see sharing entities actually reducing the workload of what needs
 to happen behind the scenes. (It just allows us to conceal more of this
 work from the user.)



 Stephen







 On Thu, Dec 4, 2014 at 4:05 PM, Brandon Logan brandon.lo...@rackspace.com
 wrote:

 Sorry it's taken me a while to respond to this.

 So I wasn't thinking about this correctly.  I was afraid you would have
 to pass in a full tree of parent child representations to /loadbalancers
 to update anything a load balancer it is associated to (including down
 to members).  However, after thinking about it, a user would just make
 an association call on each object.  For Example, associate member1 with
 pool1, associate pool1 with listener1, then associate loadbalancer1 with
 listener1.  Updating is just as simple as updating each entity.

 This does bring up another problem though.  If a listener can live on
 many load balancers, and a pool can live on many listeners, and a member
 can live on many pools, there's lot of permutations to keep track of for
 status.  you can't just link a member's status to a load balancer bc a
 member can exist on many pools under that load balancer, and each pool
 can exist under many listeners under that load balancer.  For example,
 say I have these:

 lb1
 lb2
 listener1
 listener2
 pool1
 pool2
 member1
 member2

 lb1 - [listener1, listener2]
 lb2 - [listener1]
 listener1 - [pool1, pool2]
 listener2 - [pool1]
 pool1 - [member1, member2]
 pool2 - [member1]

 member1 can now have a different statuses under pool1 and pool2.  since
 listener1 and listener2 both have pool1, this means member1 will now
 have a different status for listener1 - pool1 and listener2 - pool2
 combination.  And so forth for load balancers.

 Basically there's a lot of permutations and combinations to keep track
 of with this model for statuses.  Showing these in the body of load
 balancer details can get quite large.

 I hope this makes sense because my brain is ready to explode.

 Thanks,
 Brandon


 On Thu, 2014-11-27 at 08:52 +, Samuel Bercovici wrote:
  Brandon, can you please explain further (1) bellow?
 
  -Original Message-
  From: Brandon Logan [mailto:brandon.lo...@rackspace.com]
  Sent: Tuesday, November 25, 2014 12:23 AM
  To: openstack-dev@lists.openstack.org
  Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS -
 Use Cases that led us to adopt this.
 
  My impression is that the statuses of each entity will be shown on a
 detailed info request of a loadbalancer.  The root level objects would not
 have any statuses.  For example a user makes a GET request to
 /loadbalancers/{lb_id} and the status of every child of that load balancer
 is show in a status_tree json object.  For example:
 
  {name: loadbalancer1,
   status_tree:
{listeners:
  [{name: listener1, operating_status: ACTIVE,
default_pool:
  {name: pool1, status: ACTIVE,
   members:
 [{ip_address: 10.0.0.1, status: OFFLINE}]}}
 
  Sam, correct me if I am wrong.
 
  I generally like this idea.  I do have a few reservations with this:
 
  1) Creating and updating a load balancer requires a full tree
 configuration with the current extension/plugin logic in neutron.  Since
 updates will require a full tree, it means the

Re: [openstack-dev] [TripleO] Alternate meeting time

2014-12-05 Thread Clint Byrum

Excerpts from marios's message of 2014-12-04 02:40:23 -0800:
 On 04/12/14 11:40, James Polley wrote:
  Just taking a look at http://doodle.com/27ffgkdm5gxzr654 again - we've
  had 10 people respond so far. The winning time so far is Monday 2100UTC
  - 7 yes and one If I have to.
 
 for me it currently shows 1200 UTC as the preferred time.
 
 So to be clear, we are voting here for the alternate meeting. The
 'original' meeting is at 1900UTC. If in fact 2100UTC ends up being the
 most popular, what would be the point of an alternating meeting that is
 only 2 hours apart in time?
 

Actually that's a good point. I didn't really think about it before I
voted, but the regular time is perfect for me, so perhaps I should
remove my vote, and anyone else who does not need the alternate time
should consider doing so as well.

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

Re: [openstack-dev] [tripleo] Managing no-mergepy template duplication

2014-12-05 Thread Clint Byrum

Excerpts from Steven Hardy's message of 2014-12-04 01:09:18 -0800:
 On Wed, Dec 03, 2014 at 06:54:48PM -0800, Clint Byrum wrote:
  Excerpts from Dan Prince's message of 2014-12-03 18:35:15 -0800:
   On Wed, 2014-12-03 at 10:11 +, Steven Hardy wrote:
Hi all,

Lately I've been spending more time looking at tripleo and doing some
reviews. I'm particularly interested in helping the no-mergepy and
subsequent puppet-software-config implementations mature (as well as
improving overcloud updates via heat).

Since Tomas's patch landed[1] to enable --no-mergepy in
tripleo-heat-templates, it's become apparent that frequently patches are
submitted which only update overcloud-source.yaml, so I've been trying 
to
catch these and ask for a corresponding change to e.g controller.yaml.

This raises the following questions:

1. Is it reasonable to -1 a patch and ask folks to update in both 
places?
   
   Yes! In fact until we abandon merge.py we shouldn't land anything that
   doesn't make the change in both places. Probably more important to make
   sure things go into the new (no-mergepy) templates though.
   
2. How are we going to handle this duplication and divergence?
   
   Move as quickly as possible to the new without-mergepy varients? That is
   my vote anyways.
   
3. What's the status of getting gating CI on the --no-mergepy templates?
   
   Devtest already supports it by simply setting an option (which sets an
   ENV variable). Just need to update tripleo-ci to do that and then make
   the switch.
   
4. What barriers exist (now that I've implemented[2] the eliding 
functionality
requested[3] for ResourceGroup) to moving to the --no-mergepy
implementation by default?
   
   None that I know of.
   
  
  I concur with Dan. Elide was the last reason not to use this.
 
 That's great news! :)
 
  One thing to consider is that there is no actual upgrade path from
  non-autoscaling-group based clouds, to auto-scaling-group based
  templates. We should consider how we'll do that before making it the
  default. So, I suggest we discuss possible upgrade paths and then move
  forward with switching one of the CI jobs to using the new templates.
 
 This is probably going to be really hard :(
 
 The sort of pattern which might work is:
 
 1. Abandon mergepy based stack
 2. Have helper script to reformat abandon data into nomergepy based adopt
 data
 3. Adopt stack
 
 Unforunately there are several abandon/adopt bugs we'll have to fix if we
 decide this is the way to go (original author hasn't maintained it, but we
 can pick up the slack if it's on the critical path for TripleO).
 
 An alternative could be the external resource feature Angus is looking at:
 
 https://review.openstack.org/#/c/134848/
 
 This would be more limited (we just reference rather than manage the
 existing resources), but potentially safer.
 
 The main risk here is import (or subsequent update) operations becoming
 destructive and replacing things, but I guess to some extent this is a risk
 with any change to tripleo-heat-templates.
 

So you and I talked on IRC, but I want to socialize what we talked about
more.

The abandon/adopt pipeline is a bit broken in Heat and hasn't proven to be
as useful as I'd hoped when it was first specced out. It seems too broad,
and relies on any tools understanding how to morph a whole new format
(the abandon json).

With external_reference, the external upgrade process just needs to know
how to morph the template. So if we're combining 8 existing servers into
an autoscaling group, we just need to know how to make an autoscaling
group with 8 servers as the external reference ids. This is, I think,
the shortest path to a working solution, as I feel the external
reference work in Heat is relatively straight forward and the spec has
widescale agreement.

There was another approach I mentioned, which is that we can teach Heat
how to morph resources. So we could teach Heat that servers can be made
into autoscaling groups, and vice-versa. This is a whole new feature
though, and IMO, something that should be tackled _after_ we make it
work with the external_reference feature, as this is basically a
superset of what we'll do externally.

 Has any thought been given to upgrade CI testing?  I'm thinking grenade or
 grenade-style testing here where we test maintaing a deployed overcloud
 over an upgrade of (some subset of) changes.
 
 I know the upgrade testing thing will be hard, but to me it's a key
 requirement to mature heat-driven updates vs those driven by external
 tooling.

Upgrade testing is vital to the future of the project IMO. We really
haven't validated the image based update method upstream yet. In Helion,
we're using tripleo-ansible for updates, and that works great, but we
need to get that or something similar into the pipeline for the gate,
or every user who adopts will be left with a ton of work if they want
to

[openstack-dev] [nova] bug 1334398 and libvirt live snapshot support

In Juno we effectively disabled live snapshots with libvirt due to bug 
1334398 [1] failing the gate about 25% of the time.


I was going through the Juno release notes today and saw this as a known 
issue, which reminded me of it and was wondering if there is anything 
being done about it?


As I recall, it *works* but it wasn't working under the stress our 
check/gate system puts on that code path.


One thing I'm thinking is, couldn't we make this an experimental config 
option and by default it's disabled but we could run it in the 
experimental queue, or people could use it without having to patch the 
code to remove the artificial minimum version constraint put in the code.


Something like:

if CONF.libvirt.live_snapshot_supported:
   # do your thing

[1] https://bugs.launchpad.net/nova/+bug/1334398

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [nova] bug 1334398 and libvirt live snapshot support

On 12/05/2014 01:50 PM, Matt Riedemann wrote:
 In Juno we effectively disabled live snapshots with libvirt due to bug
 1334398 [1] failing the gate about 25% of the time.
 
 I was going through the Juno release notes today and saw this as a known
 issue, which reminded me of it and was wondering if there is anything
 being done about it?
 
 As I recall, it *works* but it wasn't working under the stress our
 check/gate system puts on that code path.
 
 One thing I'm thinking is, couldn't we make this an experimental config
 option and by default it's disabled but we could run it in the
 experimental queue, or people could use it without having to patch the
 code to remove the artificial minimum version constraint put in the code.
 
 Something like:
 
 if CONF.libvirt.live_snapshot_supported:
# do your thing
 
 [1] https://bugs.launchpad.net/nova/+bug/1334398

So, it works. If you aren't booting / shutting down guests at exactly
the same time as snapshotting. I believe cburgess said in IRC yesterday
he was going to take another look at it next week.

I'm happy to put this into dansmith's pattented [workarounds] config
group (coming soon to fix the qemu-convert bug). But I don't think this
should be a normal libvirt option.

-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

Re: [openstack-dev] [nova][docker][containers][qa] nova-docker CI failing a lot on unrelated nova patches

2014-12-05 Thread Ian Main

Sean Dague wrote:
 On 12/04/2014 05:38 PM, Matt Riedemann wrote:
  
  
  On 12/4/2014 4:06 PM, Michael Still wrote:
  +Eric and Ian
 
  On Fri, Dec 5, 2014 at 8:31 AM, Matt Riedemann
  mrie...@linux.vnet.ibm.com wrote:
  This came up in the nova meeting today, I've opened a bug [1] for it.
  Since
  this isn't maintained by infra we don't have log indexing so I can't use
  logstash to see how pervasive it us, but multiple people are
  reporting the
  same thing in IRC.
 
  Who is maintaining the nova-docker CI and can look at this?
 
  It also looks like the log format for the nova-docker CI is a bit
  weird, can
  that be cleaned up to be more consistent with other CI log results?
 
  [1] https://bugs.launchpad.net/nova-docker/+bug/1399443
 
  -- 
 
  Thanks,
 
  Matt Riedemann
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
  
  Also, according to the 3rd party CI requirements [1] I should see
  nova-docker CI in the third party wiki page [2] so I can get details on
  who to contact when this fails but that's not done.
  
  [1] http://ci.openstack.org/third_party.html#requirements
  [2] https://wiki.openstack.org/wiki/ThirdPartySystems
 
 It's not the 3rd party CI job we are talking about, it's the one in the
 check queue which is run by infra.
 
 But, more importantly, jobs in those queues need shepards that will fix
 them. Otherwise they will get deleted.
 
 Clarkb provided the fix for the log structure right now -
 https://review.openstack.org/#/c/139237/1 so at least it will look
 vaguely sane on failures
 
   -Sean

This is one of the reasons we might like to have this in nova core.  Otherwise
we will just keep addressing issues as they come up.  We would likely be
involved doing this if it were part of nova core anyway.

Ian

 -- 
 Sean Dague
 http://dague.net
 
 ___
 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] sqlalchemy-migrate vs alembic for new database

2014-12-05 Thread Andrew Laski

The cells v2 effort is going to be introducing a new database into 
Nova.  This has been an opportunity to rethink and approach a few things 
differently, including how we should handle migrations. There have been 
discussions for a long time now about switching over to alembic for 
migrations so I want to ask, should we start using alembic from the 
start for this new database?


The question was first raised by Dan Smith on 
https://review.openstack.org/#/c/135424/


I do have some concern about having two databases managed in two 
different ways, but if the details are well hidden behind a nova-manage 
command I'm not sure it will actually matter in practice.


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

Re: [openstack-dev] [nova] bug 1334398 and libvirt live snapshot support




On 12/5/2014 1:32 PM, Sean Dague wrote:

On 12/05/2014 01:50 PM, Matt Riedemann wrote:

In Juno we effectively disabled live snapshots with libvirt due to bug
1334398 [1] failing the gate about 25% of the time.

I was going through the Juno release notes today and saw this as a known
issue, which reminded me of it and was wondering if there is anything
being done about it?

As I recall, it *works* but it wasn't working under the stress our
check/gate system puts on that code path.

One thing I'm thinking is, couldn't we make this an experimental config
option and by default it's disabled but we could run it in the
experimental queue, or people could use it without having to patch the
code to remove the artificial minimum version constraint put in the code.

Something like:

if CONF.libvirt.live_snapshot_supported:
# do your thing

[1] https://bugs.launchpad.net/nova/+bug/1334398


So, it works. If you aren't booting / shutting down guests at exactly
the same time as snapshotting. I believe cburgess said in IRC yesterday
he was going to take another look at it next week.

I'm happy to put this into dansmith's pattented [workarounds] config
group (coming soon to fix the qemu-convert bug). But I don't think this
should be a normal libvirt option.

-Sean



Yeah the [workarounds] group is what got me thinking about it too as a 
config option, otherwise I think the idea of an [experimental] config 
group has come up before as a place to put 'not tested, here be dragons' 
type stuff.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [Nova] sqlalchemy-migrate vs alembic for new database




On 12/5/2014 1:45 PM, Andrew Laski wrote:

The cells v2 effort is going to be introducing a new database into
Nova.  This has been an opportunity to rethink and approach a few things
differently, including how we should handle migrations. There have been
discussions for a long time now about switching over to alembic for
migrations so I want to ask, should we start using alembic from the
start for this new database?

The question was first raised by Dan Smith on
https://review.openstack.org/#/c/135424/

I do have some concern about having two databases managed in two
different ways, but if the details are well hidden behind a nova-manage
command I'm not sure it will actually matter in practice.

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



I don't have experience with Alembic but I'd think we should use Alembic 
for the new database unless there is a compelling reason not to. Maybe 
we need Mike Bayer (or other oslo.db people) to give us an idea of what 
kinds of problems we might have with managing two databases with two 
different migration schemes.


But the last part you said is key for me, if we can abstract it well 
then hopefully it's not very painful.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [Nova] sqlalchemy-migrate vs alembic for new database

2014-12-05 Thread Johannes Erdfelt

On Fri, Dec 05, 2014, Andrew Laski andrew.la...@rackspace.com wrote:
 The cells v2 effort is going to be introducing a new database into
 Nova.  This has been an opportunity to rethink and approach a few
 things differently, including how we should handle migrations. There
 have been discussions for a long time now about switching over to
 alembic for migrations so I want to ask, should we start using
 alembic from the start for this new database?
 
 The question was first raised by Dan Smith on
 https://review.openstack.org/#/c/135424/
 
 I do have some concern about having two databases managed in two
 different ways, but if the details are well hidden behind a
 nova-manage command I'm not sure it will actually matter in
 practice.

This would be a good time for people to review my proposed spec:

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

Not only does it help operators but it also helps developers since all
they would need to do in the future is update the model and DDL
statements are generated based on comparing the running schema with the
model.

BTW, it uses Alembic under the hood for most of the heavy lifting.

JE


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

Re: [openstack-dev] [Nova] sqlalchemy-migrate vs alembic for new database

2014-12-05 Thread Sylvain Bauza



Le 05/12/2014 21:14, Matt Riedemann a écrit :



On 12/5/2014 1:45 PM, Andrew Laski wrote:

The cells v2 effort is going to be introducing a new database into
Nova.  This has been an opportunity to rethink and approach a few things
differently, including how we should handle migrations. There have been
discussions for a long time now about switching over to alembic for
migrations so I want to ask, should we start using alembic from the
start for this new database?

The question was first raised by Dan Smith on
https://review.openstack.org/#/c/135424/

I do have some concern about having two databases managed in two
different ways, but if the details are well hidden behind a nova-manage
command I'm not sure it will actually matter in practice.

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



I don't have experience with Alembic but I'd think we should use 
Alembic for the new database unless there is a compelling reason not 
to. Maybe we need Mike Bayer (or other oslo.db people) to give us an 
idea of what kinds of problems we might have with managing two 
databases with two different migration schemes.


But the last part you said is key for me, if we can abstract it well 
then hopefully it's not very painful.





I had some experience with Alembic in a previous Stackforge project and 
I'm definitely +1 on using it for the Cells V2 database.


We can just provide a nova-manage cell-db service that would facade the 
migration backend, whatever it is.




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

[openstack-dev] [[Openstack-dev] [Ironic] Ironic-conductor fails to start - AttributeError '_keepalive_evt'

2014-12-05 Thread Lohit Valleru

Hello All,

I am trying to deploy bare-metal nodes using openstack-ironic. It is a 2 -
node architecture with controller/keystone/mysql on a virtual machine, and
cinder/compute/nova network on a physical machine on a CentOS 7 environment.

openstack-ironic-common-2014.2-2.el7.centos.noarch
openstack-ironic-api-2014.2-2.el7.centos.noarch
openstack-ironic-conductor-2014.2-2.el7.centos.noarch

I have followed this document,
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#ipmi-support

and installed ironic. But when i start ironic-conductor, i get the below
error :

ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 TRACE
ironic.common.service
 ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 ERROR
ironic.common.service [-] Service error occurred when cleaning up the RPC
manager. Error: 'ConductorManager' object has no attribute '_keepalive_evt'
 ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 TRACE
ironic.common.service Traceback (most recent call last):
 ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 TRACE
ironic.common.service   File
/usr/lib/python2.7/site-packages/ironic/common/service.py, line 91, in
stop
 ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 TRACE
ironic.common.service self.manager.del_host()
ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 TRACE
ironic.common.service   File
/usr/lib/python2.7/site-packages/ironic/conductor/manager.py, line 235,
in del_host
 ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 TRACE
ironic.common.service self._keepalive_evt.set()
 hc004 ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 TRACE
ironic.common.service AttributeError: 'ConductorManager' object has no
attribute '_keepalive_evt'
 hc004 ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 TRACE
ironic.common.service
 hc004 ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 INFO
ironic.common.service [-] Stopped RPC server for service
ironic.conductor_manager on host hc004.

A look at the source code, tells me that it is something related to RPC
service being started/stopped.

Also, I cannot debug this more as - I do not see any logs being created
with respect to ironic.
Do i have to explicitly enable the logging properties in ironic.conf, or
are they expected to be working by default?

Here is the configuration from ironic.conf

#

[DEFAULT]
verbose=true
rabbit_host=172.18.246.104
auth_strategy=keystone
debug=true

[keystone_authtoken]
auth_host=172.18.246.104
auth_uri=http://172.18.246.104:5000/v2.0
admin_user=ironic
admin_password=
admin_tenant_name=service

[database]
connection = mysql://ironic:x@172.18.246.104/ironic?charset=utf8

[glance]
glance_host=172.18.246.104

#

I understand that i did not give neutron URL as required by the
documentation. The reason : that i have architecture limitations to install
neutron networking and would like to experiment if nova-network and dhcp
pxe server will server the purpose although i highly doubt that.

However, i wish to know if the above issue is anyway related to
non-existent neutron network, or if it is related to something else.

Please do let me know.

Thank you,

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

Re: [openstack-dev] [[Openstack-dev] [Ironic] Ironic-conductor fails to start - AttributeError '_keepalive_evt'

2014-12-05 Thread Devananda van der Veen

Hi Lohit,

In the future, please do not cross-post or copy-and-paste usage questions
on the development list. Since you posted this question on the general list
(*) -- which is exactly where you should post it -- I will respond there.

Regards,
Devananda

(*) http://lists.openstack.org/pipermail/openstack/2014-December/010698.html



On Fri Dec 05 2014 at 1:15:44 PM Lohit Valleru loh...@gwmail.gwu.edu
wrote:

 Hello All,

 I am trying to deploy bare-metal nodes using openstack-ironic. It is a 2 -
 node architecture with controller/keystone/mysql on a virtual machine, and
 cinder/compute/nova network on a physical machine on a CentOS 7 environment.

 openstack-ironic-common-2014.2-2.el7.centos.noarch
 openstack-ironic-api-2014.2-2.el7.centos.noarch
 openstack-ironic-conductor-2014.2-2.el7.centos.noarch

 I have followed this document,

 http://docs.openstack.org/developer/ironic/deploy/install-guide.html#ipmi-support

 and installed ironic. But when i start ironic-conductor, i get the below
 error :

 ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 TRACE
 ironic.common.service
  ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 ERROR
 ironic.common.service [-] Service error occurred when cleaning up the RPC
 manager. Error: 'ConductorManager' object has no attribute '_keepalive_evt'
  ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 TRACE
 ironic.common.service Traceback (most recent call last):
  ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 TRACE
 ironic.common.service   File
 /usr/lib/python2.7/site-packages/ironic/common/service.py, line 91, in
 stop
  ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 TRACE
 ironic.common.service self.manager.del_host()
 ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 TRACE
 ironic.common.service   File
 /usr/lib/python2.7/site-packages/ironic/conductor/manager.py, line 235,
 in del_host
  ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 TRACE
 ironic.common.service self._keepalive_evt.set()
  hc004 ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 TRACE
 ironic.common.service AttributeError: 'ConductorManager' object has no
 attribute '_keepalive_evt'
  hc004 ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 TRACE
 ironic.common.service
  hc004 ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 INFO
 ironic.common.service [-] Stopped RPC server for service
 ironic.conductor_manager on host hc004.

 A look at the source code, tells me that it is something related to RPC
 service being started/stopped.

 Also, I cannot debug this more as - I do not see any logs being created
 with respect to ironic.
 Do i have to explicitly enable the logging properties in ironic.conf, or
 are they expected to be working by default?

 Here is the configuration from ironic.conf

 #

 [DEFAULT]
 verbose=true
 rabbit_host=172.18.246.104
 auth_strategy=keystone
 debug=true

 [keystone_authtoken]
 auth_host=172.18.246.104
 auth_uri=http://172.18.246.104:5000/v2.0
 admin_user=ironic
 admin_password=
 admin_tenant_name=service

 [database]
 connection = mysql://ironic:x@172.18.246.104/ironic?charset=utf8

 [glance]
 glance_host=172.18.246.104

 #

 I understand that i did not give neutron URL as required by the
 documentation. The reason : that i have architecture limitations to install
 neutron networking and would like to experiment if nova-network and dhcp
 pxe server will server the purpose although i highly doubt that.

 However, i wish to know if the above issue is anyway related to
 non-existent neutron network, or if it is related to something else.

 Please do let me know.

 Thank you,

 Lohit
 ___
 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] sqlalchemy-migrate vs alembic for new database


 On Dec 5, 2014, at 3:14 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote:
 
 
 
 On 12/5/2014 1:45 PM, Andrew Laski wrote:
 The cells v2 effort is going to be introducing a new database into
 Nova.  This has been an opportunity to rethink and approach a few things
 differently, including how we should handle migrations. There have been
 discussions for a long time now about switching over to alembic for
 migrations so I want to ask, should we start using alembic from the
 start for this new database?
 
 The question was first raised by Dan Smith on
 https://review.openstack.org/#/c/135424/
 
 I do have some concern about having two databases managed in two
 different ways, but if the details are well hidden behind a nova-manage
 command I'm not sure it will actually matter in practice.
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 I don't have experience with Alembic but I'd think we should use Alembic for 
 the new database unless there is a compelling reason not to. Maybe we need 
 Mike Bayer (or other oslo.db people) to give us an idea of what kinds of 
 problems we might have with managing two databases with two different 
 migration schemes.
 
 But the last part you said is key for me, if we can abstract it well then 
 hopefully it's not very painful.

sqlalchemy-migrate doesn’t really have a dedicated maintainer anymore, AFAICT.  
It’s pretty much on stackforge life support.   So while the issue of merging 
together a project with migrate and alembic at the same time seems to be 
something for which there are some complexity and some competing ideas (I have 
one that’s pretty fancy, but I haven’t spec’ed or implemented it yet, so for 
now there are “wrappers” that run both), it sort of has to happen regardless.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] [ha] potential issue with implicit async-compatible mysql drivers

Hey list -

I’m posting this here just to get some ideas on what might be happening here, 
as it may or may not have some impact on Openstack if and when we move to MySQL 
drivers that are async-patchable, like MySQL-connector or PyMySQL.  I had a 
user post this issue a few days ago which I’ve since distilled into test cases 
for PyMySQL and MySQL-connector separately.   It uses gevent, not eventlet, so 
I’m not really sure if this applies.  But there’s plenty of very smart people 
here so if anyone can shed some light on what is actually happening here, that 
would help.

The program essentially illustrates code that performs several steps upon a 
connection, however if the greenlet is suddenly killed, the state from the 
connection, while damaged, is still being allowed to continue on in some way, 
and what’s super-catastrophic here is that you see a transaction actually being 
committed *without* all the statements proceeding on it. 

In my work with MySQL drivers, I’ve noted for years that they are all very, 
very bad at dealing with concurrency-related issues.  The whole “MySQL has gone 
away” and “commands out of sync” errors are ones that we’ve all just drowned 
in, and so often these are due to the driver getting mixed up due to concurrent 
use of a connection.  However this one seems more insidious.   Though at the 
same time, the script has some complexity happening (like a simplistic 
connection pool) and I’m not really sure where the core of the issue lies.

The script is at https://gist.github.com/zzzeek/d196fa91c40cb515365e and also 
below.  If you run it for a few seconds, go over to your MySQL command line and 
run this query:

SELECT * FROM table_b WHERE a_id not in (SELECT id FROM table_a) ORDER BY a_id 
DESC;

and what you’ll see is tons of rows in table_b where the “a_id” is zero 
(because cursor.lastrowid fails), but the *rows are committed*.   If you read 
the segment of code that does this, it should be impossible:

connection = pool.get()
rowid = execute_sql(
connection,
INSERT INTO table_a (data) VALUES (%s), (a,)
)

gevent.sleep(random.random() * 0.2)
 
try:
execute_sql(
connection,
INSERT INTO table_b (a_id, data) VALUES (%s, %s),
(rowid, b,)
)
 
connection.commit()
 
pool.return_conn(connection) 

except Exception:
connection.rollback()
pool.return_conn(connection)

so if the gevent.sleep() throws a timeout error, somehow we are getting thrown 
back in there, with the connection in an invalid state, but not invalid enough 
to commit.

If a simple check for “SELECT connection_id()” is added, this query fails and 
the whole issue is prevented.  Additionally, if you put a foreign key 
constraint on that b_table.a_id, then the issue is prevented, and you see that 
the constraint violation is happening all over the place within the commit() 
call.   The connection is being used such that its state just started after the 
gevent.sleep() call.  

Now, there’s also a very rudimental connection pool here.   That is also part 
of what’s going on.  If i try to run without the pool, the whole script just 
runs out of connections, fast, which suggests that this gevent timeout cleans 
itself up very, very badly.   However, SQLAlchemy’s pool works a lot like this 
one, so if folks here can tell me if the connection pool is doing something 
bad, then that’s key, because I need to make a comparable change in 
SQLAlchemy’s pool.   Otherwise I worry our eventlet use could have big problems 
under high load.





# -*- coding: utf-8 -*-
import gevent.monkey
gevent.monkey.patch_all()

import collections
import threading
import time
import random
import sys

import logging
logging.basicConfig()
log = logging.getLogger('foo')
log.setLevel(logging.DEBUG)

#import pymysql as dbapi
from mysql import connector as dbapi


class SimplePool(object):
def __init__(self):
self.checkedin = collections.deque([
self._connect() for i in range(50)
])
self.checkout_lock = threading.Lock()
self.checkin_lock = threading.Lock()

def _connect(self):
return dbapi.connect(
user=scott, passwd=tiger,
host=localhost, db=test)

def get(self):
with self.checkout_lock:
while not self.checkedin:
time.sleep(.1)
return self.checkedin.pop()

def return_conn(self, conn):
try:
conn.rollback()
except:
log.error(Exception during rollback, exc_info=True)
try:
conn.close()
except:
log.error(Exception during close, exc_info=True)

# recycle to a new connection
conn = self._connect()
with self.checkin_lock:

Re: [openstack-dev] [[Openstack-dev] [Ironic] Ironic-conductor fails to start - AttributeError '_keepalive_evt'

2014-12-05 Thread Lohit Valleru

I apologize. I was not sure about where to post the errors.

I will post to the general list from next time.

Thank you,

Lohit

On Friday, December 5, 2014, Devananda van der Veen devananda@gmail.com
wrote:

 Hi Lohit,

 In the future, please do not cross-post or copy-and-paste usage questions
 on the development list. Since you posted this question on the general list
 (*) -- which is exactly where you should post it -- I will respond there.

 Regards,
 Devananda

 (*)
 http://lists.openstack.org/pipermail/openstack/2014-December/010698.html



 On Fri Dec 05 2014 at 1:15:44 PM Lohit Valleru loh...@gwmail.gwu.edu
 javascript:_e(%7B%7D,'cvml','loh...@gwmail.gwu.edu'); wrote:

 Hello All,

 I am trying to deploy bare-metal nodes using openstack-ironic. It is a 2
 - node architecture with controller/keystone/mysql on a virtual machine,
 and cinder/compute/nova network on a physical machine on a CentOS 7
 environment.

 openstack-ironic-common-2014.2-2.el7.centos.noarch
 openstack-ironic-api-2014.2-2.el7.centos.noarch
 openstack-ironic-conductor-2014.2-2.el7.centos.noarch

 I have followed this document,

 http://docs.openstack.org/developer/ironic/deploy/install-guide.html#ipmi-support

 and installed ironic. But when i start ironic-conductor, i get the below
 error :

 ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 TRACE
 ironic.common.service
  ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 ERROR
 ironic.common.service [-] Service error occurred when cleaning up the RPC
 manager. Error: 'ConductorManager' object has no attribute '_keepalive_evt'
  ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 TRACE
 ironic.common.service Traceback (most recent call last):
  ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 TRACE
 ironic.common.service   File
 /usr/lib/python2.7/site-packages/ironic/common/service.py, line 91, in
 stop
  ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 TRACE
 ironic.common.service self.manager.del_host()
 ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 TRACE
 ironic.common.service   File
 /usr/lib/python2.7/site-packages/ironic/conductor/manager.py, line 235,
 in del_host
  ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 TRACE
 ironic.common.service self._keepalive_evt.set()
  hc004 ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 TRACE
 ironic.common.service AttributeError: 'ConductorManager' object has no
 attribute '_keepalive_evt'
  hc004 ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 TRACE
 ironic.common.service
  hc004 ironic-conductor[15997]: 2014-12-05 15:38:12.457 15997 INFO
 ironic.common.service [-] Stopped RPC server for service
 ironic.conductor_manager on host hc004.

 A look at the source code, tells me that it is something related to RPC
 service being started/stopped.

 Also, I cannot debug this more as - I do not see any logs being created
 with respect to ironic.
 Do i have to explicitly enable the logging properties in ironic.conf, or
 are they expected to be working by default?

 Here is the configuration from ironic.conf

 #

 [DEFAULT]
 verbose=true
 rabbit_host=172.18.246.104
 auth_strategy=keystone
 debug=true

 [keystone_authtoken]
 auth_host=172.18.246.104
 auth_uri=http://172.18.246.104:5000/v2.0
 admin_user=ironic
 admin_password=
 admin_tenant_name=service

 [database]
 connection = mysql://ironic:x@172.18.246.104/ironic?charset=utf8

 [glance]
 glance_host=172.18.246.104

 #

 I understand that i did not give neutron URL as required by the
 documentation. The reason : that i have architecture limitations to install
 neutron networking and would like to experiment if nova-network and dhcp
 pxe server will server the purpose although i highly doubt that.

 However, i wish to know if the above issue is anyway related to
 non-existent neutron network, or if it is related to something else.

 Please do let me know.

 Thank you,

 Lohit
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 javascript:_e(%7B%7D,'cvml','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] [Neutron] Core/Vendor code decomposition

2014-12-05 Thread Armando M.

Hi folks,

For a few weeks now the Neutron team has worked tirelessly on [1].

This initiative stems from the fact that as the project matures, evolution
of processes and contribution guidelines need to evolve with it. This is to
ensure that the project can keep on thriving in order to meet the needs of
an ever growing community.

The effort of documenting intentions, and fleshing out the various details
of the proposal is about to reach an end, and we'll soon kick the tires to
put the proposal into practice. Since the spec has grown pretty big, I'll
try to capture the tl;dr below.

If you have any comment please do not hesitate to raise them here and/or
reach out to us.

tl;dr 

From the Kilo release, we'll initiate a set of steps to change the
following areas:

   - Code structure: every plugin or driver that exists or wants to exist
   as part of Neutron project is decomposed in an slim vendor integration
   (which lives in the Neutron repo), plus a bulkier vendor library (which
   lives in an independent publicly available repo);
   - Contribution process: this extends to the following aspects:
  - Design and Development: the process is largely unchanged for the
  part that pertains the vendor integration; the maintainer team is fully
  auto governed for the design and development of the vendor library;
  - Testing and Continuous Integration: maintainers will be required to
  support their vendor integration with 3rd CI testing; the
requirements for
  3rd CI testing are largely unchanged;
  - Defect management: the process is largely unchanged, issues
  affecting the vendor library can be tracked with whichever
tool/process the
  maintainer see fit. In cases where vendor library fixes need to be
  reflected in the vendor integration, the usual OpenStack defect
management
  apply.
  - Documentation: there will be some changes to the way plugins and
  drivers are documented with the intention of promoting discoverability of
  the integrated solutions.
   - Adoption and transition plan: we strongly advise maintainers to stay
   abreast of the developments of this effort, as their code, their CI, etc
   will be affected. The core team will provide guidelines and support
   throughout this cycle the ensure a smooth transition.

To learn more, please refer to [1].

Many thanks,
Armando

[1] https://review.openstack.org/#/c/134680
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository?

2014-12-05 Thread Armando M.

For anyone who had an interest in following this thread, they might want to
have a look at [1], and [2] (which is the tl;dr version [1]).

HTH
Armando

[1] https://review.openstack.org/#/c/134680
[2]
http://lists.openstack.org/pipermail/openstack-dev/2014-December/052346.html
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ironic] reminder: alternate meeting time

2014-12-05 Thread Devananda van der Veen

This is a friendly reminder that our weekly IRC meetings have begun
alternating times every week to try to accommodate more of our contributors.

Next week's meeting will be at 0500 UTC Tuesday (9pm PST Monday) in the
#openstack-meeting-3 channel. Details, as always, are on the wiki [0].

Regards,
Devananda

[0] https://wiki.openstack.org/wiki/Meetings/Ironic
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Mike Bayer 20141205

1. Alembic release - I worked through some regressions introduced by Alembic 
0.7.0 and the subsequent 0.7.1 with the Neutron folks.  This started on Monday 
with https://review.openstack.org/#/c/137989/, and by Wednesday I had 
identified enough small regressions in 0.7.0 that I had to put 0.7.1 out, so 
that review got expedited with https://review.openstack.org/#/c/138998/ 
following from Neutron devs to continue fixing.   Version 0.7.1 includes the 
foreign key autogenerate support first proposed by Ann Kamyshnikova.  Changelog 
at http://alembic.readthedocs.org/en/latest/changelog.html#change-0.7.1.

2. MySQL driver stuff.   I have a SQLAlchemy user who is running some kind of 
heavy load with gevent and PyMySQL.  While this user is not openstack-specific, 
the thing he is doing is a lot like what we might be doing if and when we move 
our MySQL drivers to MySQL-connector-Python, which is compatible with eventlet 
in that it is pure Python and can be monkeypatched.The issue observed by 
this user applies to both PyMySQL and MySQL-connector, and I can reproduce it 
*without* using SQLAlchemy, though it does use a very makeshift connection pool 
designed to approximate what SQLAlchemy’s does.   The issue is scary because it 
illustrates Python code that should have been killed being invoked on a 
database connection that should have been dead, calling commit(), and then 
actually *succeeding* in committing only *part* of the data.   This is not an 
issue that impacts Openstack right now but if the same thing applies to 
eventlet, then this would definitely be something we’d need to worry about if 
we start using MySQL-connector in a high load scenario (which has been the 
plan) so I’ve forwarded my findings onto openstack-dev to see if anyone can 
help me understand it.  The intro + test case for this issue starts at 
http://lists.openstack.org/pipermail/openstack-dev/2014-December/052344.html. 

3. enginefacade - The engine facade as I described in 
https://review.openstack.org/#/c/125181/, which we also talked about on the 
Nova compute call this week, is now built!  I spent monday and tuesday on the 
buildout for this, and that can be seen and reviewed here: 
https://review.openstack.org/#/c/138215/  As of today I’m still nursing it 
through CI, as even with projects using the “legacy” APIs, they are still 
finding lots of little silly things that I keep having to fix (people calling 
the old EngineFacade with arguments I didn’t expect, people importing from 
oslo.db in an order I did not expect, etc).  While these consuming projects 
could be fixed to not have these little issues, for now I am trying to push 
everything to work as identically as possible to how it was earlier, when the 
new API is not explicitly invoked.   I’ll be continuing to get this to pass all 
tempest runs through next week.

For enginefacade I’d like the folks from the call to take a look, and in 
particular if Matthew Booth wants to look into it, this is ready to start being 
used for prototyping Nova with it.

4. Connectivity stuff - today I worked a bunch with Viktor Sergeyev who has 
been trying to fix an issue with MySQL OperationalErrors that are raised when 
the database is shut off entirely; in oslo.db we have logic that wraps all 
exceptions unconditionally, including that it identifies disconnect exceptions. 
 In the case where the DB throws a disconnect, and we loop around to “retry” 
this query in order to get it to reconnect, then that reconnect continues to 
fail, the second run doesn’t get wrapped.   So today I’ve fixed both the 
upstream issue for SQLAlchemy 1.0, and also made a series of adjustments to 
oslo.db to accommodate SQLAlchemy 1.0’s system correctly as well as to work 
around the issue when SQLAlchemy  1.0 is present.   That’s a three-series of 
patches that are unsurprisingly going to take some nursing to get through the 
gate, so I’ll be continuing with that next week.  This series starts at 
https://review.openstack.org/139725 https://review.openstack.org/139733 
https://review.openstack.org/139738 .

5. SQLA 1.0 stuff. - getting SQLAlchemy 1.0 close to release is becoming 
critical so I’ve been moving around issues and priorities to expedite this.  
There’s many stability enhancements oslo.db would benefit from as well as some 
major performance-related features that I’ve been planning all along to 
introduce to projects.   1.0 is very full of lots of changes that aren’t really 
being tested outside of my own CI, so getting something out the door on it is 
key, otherwise it will just be too different from 0.9 in order for people to 
have smooth upgrades.   I do run SQLA 1.0 in CI against a subset of Neutron, 
Nova, Keystone and Oslo tests so we should be in OK shape, but there is still a 
lot to go.  Work completed so far can be seen at 
http://docs.sqlalchemy.org/en/latest/changelog/migration_10.html.  


___
OpenStack-dev mailing list

Re: [openstack-dev] Mike Bayer 20141205