Re: [openstack-dev] [TripleO] nominating James Polley for tripleo-core

2015-01-15 Thread Alexis Lee
Clint Byrum said on Wed, Jan 14, 2015 at 10:14:45AM -0800:
 holidays. However, I believe James has demonstrated superb review skills
 and a commitment to the project that shows broad awareness of the
 project.

Big +1. Thanks for taking the time to meta-review, Clint.


Alexis
-- 
Nova Engineer, HP Cloud.  AKA lealexis, lxsli.

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


Re: [openstack-dev] About DVR limit

2015-01-15 Thread Vasudevan, Swaminathan (PNB Roseville)
Hi Joehuang,
Thanks for your input and description of the problem.
What you are stating is just have DVR functionality for East-West traffic and 
all North-South traffic should go through the Centralized Router.
The North-South distributed reduces the burden in the Centralized Node. We 
eventually need to get away from the centralized node model.
I am not sure why there would be a use case to go back to the centralized model.

We were even initially planning to distribute the SNAT, but we just left it 
there centralized just to support the legacy services such as VPN.
Once we have service insertion and service chaining then we can distribute the 
SNAT functionality.

If you have a use case and willing to work on it and contribute code upstream, 
please let me know.

Thanks
Swami

From: joehuang [mailto:joehu...@huawei.com]
Sent: Wednesday, January 14, 2015 7:07 PM
To: 龚永生; Vasudevan, Swaminathan (PNB Roseville)
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: RE: Re:RE: [openstack-dev] About DVR limit

Hello,

Yongseng, correct, your description is much more concise, we need a 
configuration:

east-west, DVR
south-north, legacy mode.

Best Regards
Chaoyi Huang ( Joe Huang )

From: 龚永生 [mailto:gong.yongsh...@99cloud.net]
Sent: Thursday, January 15, 2015 10:18 AM
To: Vasudevan, Swaminathan (PNB Roseville)
Cc: joehuang; OpenStack Development Mailing List (not for usage questions)
Subject: Re:RE: [openstack-dev] About DVR limit


Hi, Swami, Joehuang,
in dvr compute nodes, it is 1:1 NAT FIP, means the floatingip for VM, and  it 
is in the namespace of qrouter-.
but in dvr_snat node, it is 1:N NAT IP, it is for neutron router, and for the 
VMs which have no 1:1 FIP, implemented in namesapce snat-xxx.

Joehuang's case can be implemented in legacy mode, I.E. non DVR,
but for the east-west traffic, we should consider the DVR, So I think there is 
a case:
east-west, DVR
south-north, legacy mode.


Thanks
yong sheng gong


在 2015-01-14 13:40:32,Vasudevan, Swaminathan (PNB Roseville) 
swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.com 写道:
Hi Joehuang,
FIP today as of Juno can be both in centralized node (dvr_snat) and distributed 
“dvr” compute nodes.
Thanks
Swami

From: joehuang [mailto:joehu...@huawei.commailto:joehu...@huawei.com]
Sent: Tuesday, January 13, 2015 7:49 PM
To: OpenStack Development Mailing List (not for usage questions); 龚永生
Cc: Vasudevan, Swaminathan (PNB Roseville)
Subject: RE: [openstack-dev] About DVR limit

Hi, Swami,

I would like to know whether the FIP under DVR could be configured to 
distributed mode or central mode in Kilo, not find relevant information from 
http://specs.openstack.org/openstack/neutron-specs/.

For example, it will be helpful for following FIP use cases: 1) FIP will be 
addressed centrally by dedicated hardware 2) not all compute nodes have public 
address.

Best Regards
Chaoyi Huang ( Joe Huang )

From: Stamina than Valued an [mailto:souminat...@yahoo.com]
Sent: Wednesday, January 14, 2015 11:05 AM
To: 龚永生
Cc: swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.com; 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] About DVR limit

Hi yong Zheng,
Yes your understanding is right.
We only support ovs driver.
Regarding HA and multi network support, it will be available in kilo.

Public address consumption for north south traffic for compute node is also 
true. But to address this issue we do have a proposal that is worked out by the 
l3 sub team.

I hope this clarifies your doubts.

Please let me know if I can help you with anything else.

Thanks
Swami

Sent from my iPad

On Jan 13, 2015, at 6:01 PM, 龚永生 
gong.yongsh...@99cloud.netmailto:gong.yongsh...@99cloud.net wrote:
Hi,
 I am yong sheng gong, I want to know if the DVR has these limits besides the 
documented at http://docs.openstack.org/networking-guide/content/ha-dvr.html:

1. one subnet can be connected to DVR router only once, which is confirmed by 
BP https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr-multigateway
2. one network cannot have more than one subnet connecting to DVR routers


So the DVR limits the neutron model to:
one network has just one subnet, and one subnet cannot connect to more than one 
DVR routers.


ps.
req and limits documented at 
http://docs.openstack.org/networking-guide/content/ha-dvr.html::
 DVR requirements

*You must use the ML2 plug-in for Open VSwitch (OVS) to enable DVR.

*Be sure that your firewall or security groups allows UDP traffic over 
the VLAN, GRE, or VXLAN port to pass between the compute hosts.

 DVR limitations

*Distributed virtual router configurations work with the Open vSwitch 
Modular Layer 2 driver only for Juno.

*In order to enable true north-south bandwidth between hypervisors 
(compute nodes), you must use public IP addresses for every compute node and 
enable floating IPs.

*For now, based on the current 

Re: [openstack-dev] [oslo] why we have 2 sets of tests in oslo libraries

2015-01-15 Thread Doug Hellmann

 On Jan 15, 2015, at 12:01 PM, Doug Hellmann d...@doughellmann.com wrote:
 
 As part of the work on dropping the use of the oslo namespace [1], many of 
 our library repositories now have 2 sets of tests. One set is under the new 
 package (for example, “oslo_config/tests”), and uses the new import scheme 
 (“from oslo_config import cfg”). To protect against regressions in the old 
 public API, we have kept the original copies of the tests in a directory at 
 the top level of the repository using the old import names (“from oslo.config 
 import cfg”). The logic of most of the tests are identical now, aside from 
 differences in the imports.
 
 For new code, we only need to add tests in the new location inside the 
 library package (“oslo_config/tests”). New symbols do not need to work 
 through the old namespace, so using a new function or class may require 
 updating imports in a consuming project.
 
 The tests for the old public API should not be modified, except as we find 
 redundancy that we can delete for testing private symbols. I did clean up 
 some of the tests as I went along, but in a lot of cases it was faster to 
 just update the imports. After we have all of the libraries released, I plan 
 to spend more time going through the test suites and cleaning them up 
 carefully, but that’s not a high priority task.
 
 My goal is to be able to remove both the old namespace package and the 
 related tests during the next cycle. We will have to check adoption progress 
 as we get close to the end of Kilo to determine whether that is possible. 
 Liaisons, please assume that we’re going to try to do it and work on updating 
 all consuming projects.
 
 Doug
 

The missing footnote:
[1] 
https://blueprints.launchpad.net/oslo-incubator/+spec/drop-namespace-packages


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


Re: [openstack-dev] [horizon] function expressions vs function declarations in JavaScript

2015-01-15 Thread Aaron Sahlin
Just to expand a bit on Thai's response..   Make the changes to 
horizon/doc/source/contributing.rst and submit a patch, once that gets 
approval then

go update the wiki.

On 1/14/2015 3:49 PM, Thai Q Tran wrote:


Wow, that IS interesting. No process required, just modify 
/horizon/doc/source/contributing.rst and submit a patch.


-Matthew Farina m...@mattfarina.com wrote: -
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org

From: Matthew Farina m...@mattfarina.com
Date: 01/14/2015 12:20PM
Subject: Re: [openstack-dev] [horizon] function expressions vs 
function declarations in JavaScript


Thai, I'm still poking around at JavaScript things and did a little 
testing on function declarations vs function expressions. Seems 
Firefox is faster with function expressions by quite a bit at parse 
time. For reference see http://jsperf.com/mfer-function-types.


I'm not suggesting what we do. I'm just sharing a data point I found 
surprising.


I'm curious about the process for proposing changes to 
https://wiki.openstack.org/wiki/Horizon/Javascript. Is there any process?



On Wed, Jan 14, 2015 at 1:15 PM, Thai Q Tran tqt...@us.ibm.com 
mailto:tqt...@us.ibm.com wrote:



It was definitely an interesting the read, I never really noticed
the subtle difference. Since then I have also read a few other
thoughts on it.
For me, function declarations can get convoluted very fast if not
use correctly.
Surely, you should never define functions inside of an if
statement, and quite confusing to do it after a return statement.
But they do have their uses when used correctly.
I think it ultimately depends on what you are trying to do and
whether it make sense to use declarations vs expressions.
As long as people understand the difference, and take it
case-by-case, its not really something I'm going to mull over too
much.

-Matthew Farina m...@mattfarina.com
mailto:m...@mattfarina.com wrote: -
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
mailto:openstack-dev@lists.openstack.org
From: Matthew Farina m...@mattfarina.com
mailto:m...@mattfarina.com
Date: 01/14/2015 07:04AM
Subject: [openstack-dev] [horizon] function expressions vs
function declarations in JavaScript


JavaScript has multiple ways to deal with functions. There are
function declarations and function expressions (and named function
expressions).

In looking at some reviews and the current code I found some
inconsistencies which leads me to ask, is there any guidance for
handling this in Horizon? I noticed no documentation in
https://wiki.openstack.org/wiki/Horizon/Javascript.

Thanks,
Matt


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

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


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


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


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


Re: [openstack-dev] [TripleO] nominating James Polley for tripleo-core

2015-01-15 Thread Chuck Carlino

On 01/15/2015 08:49 AM, Alexis Lee wrote:

Clint Byrum said on Wed, Jan 14, 2015 at 10:14:45AM -0800:

holidays. However, I believe James has demonstrated superb review skills
and a commitment to the project that shows broad awareness of the
project.

Big +1. Thanks for taking the time to meta-review, Clint.


Alexis


I don't get a vote, but just wanted to point out James' excellent 
contributions in chasing down neutron issues.


Hmm, now that I've said it, I'm not entirely certain he'd have wanted me 
to :P


ChuckC

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


Re: [openstack-dev] [TripleO] Switching CI back to amd64

2015-01-15 Thread Dan Prince
On Wed, 2015-01-07 at 10:51 +, Derek Higgins wrote:
 Hi All,
 I intended to bring this up at this mornings meeting but the train I
 was on had no power sockets (and I had no battery) so sending to the
 list instead.
 
 We currently run our CI with on images built for i386, we took this
 decision a while back to save memory ( at the time is allowed us to move
 the amount of memory required in our VMs from 4G to 2G (exactly where in
 those bands the hard requirements are I don't know)
 
 Since then we have had to move back to 3G for the i386 VM as 2G was no
 longer enough so the saving in memory is no longer as dramatic.
 
 Now that the difference isn't as dramatic, I propose we switch back to
 amd64 (with 4G vms) in order to CI on what would be closer to a
 production deployment and before making the switch wanted to throw the
 idea out there for others to digest.
 
 This obviously would impact our capacity as we will have to reduce the
 number of testenvs per testenv hosts. Our capacity (in RH1 and roughly
 speaking) allows us to run about 1440 ci jobs per day. I believe we can
 make the switch and still keep capacity above 1200 with a few other changes
 1. Add some more testenv hosts, we have 2 unused hosts at the moment and
 we can probably take 2 of the compute nodes from the overcloud.
 2. Kill VM's at the end of each CI test (as opposed to leaving them
 running until the next CI test kills them), allowing us to more
 successfully overcommit on RAM
 3. maybe look into adding swap on the test env hosts, they don't
 currently have any, so over committing RAM is a problem the the OOM
 killer is handling from time to time (I only noticed this yesterday).
 
 The other benefit to doing this is that is we were to ever want to CI
 images build with packages (this has come up in previous meetings) we
 wouldn't need to provide i386 packages just for CI, while the rest of
 the world uses the amd64.

+1. I've been wishing we'd switch back to x86_64 for a while now. Even
if it takes a bit more space I think ultimately this makes thing a bit
easier on us so lets do it.

Dan

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



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


Re: [openstack-dev] [oslo.messaging] Performance testing. Initial steps.

2015-01-15 Thread Doug Hellmann

 On Jan 15, 2015, at 1:30 PM, Denis Makogon dmako...@mirantis.com wrote:
 
 Good day to All,
 
 The question that i’d like to raise here is not simple one, so i’d like to 
 involve as much readers as i can. I’d like to speak about oslo.messaging 
 performance testing. As community we’ve put lots of efforts in making 
 oslo.messaging widely used drivers stable as much as possible. Stability is a 
 good thing, but is it enough for saying “works well”? I’d say that it’s not.
 Since oslo.messaging uses driver-based messaging workflow, it makes sense to 
 dig into each driver and collect all required/possible performance metrics.
 First of all, it does make sense to figure out how to perform performance 
 testing, first that came into my mind is to simulate high load on one of 
 corresponding drivers. Here comes the question of how it can be accomplished 
 withing available oslo.messaging tools - high load on any driver can perform 
 an application that:
   • can populate multiple emitters(rpc clients) and consumers (rpc 
 servers).
   • can force clients to send messages of pre-defined number of messages 
 of any length.

That makes sense.

 Another thing is why do we need such thing. Profiling, performance testing 
 can improve the way in which our drivers were implemented. It can show us 
 actual “bottlenecks” in messaging process, in general. In some cases it does 
 make sense to figure out where problem takes its place - whether AMQP causes 
 messaging problems or certain driver that speaks to AMQP fails.
 Next thing that i want to discuss the architecture of profiling/performance 
 testing. As i can see it seemed to be a “good” way to add profiling code to 
 each driver. If there’s any objection or better solution, please bring them 
 to the light.

What sort of extra profiling code do you anticipate needing?

 Once we’d have final design for profiling we would need to figure out tools 
 for profiling. After searching over the web, i found pretty interesting topic 
 related to python profiling [1]. After certain investigations it does makes 
 sense discuss next profiling options(apply one or both):
   • Line-by-line timing and execution frequency with a profiler (there 
 are possible Pros and Cons, but i would say the per-line statistics is more 
 than appreciable at initial performance testing steps)
   • Memory/CPU consumption
 Metrics. The most useful metric for us is time, any time-based metric, since 
 it is very useful to know at which step or/and by whom delay/timeout caused, 
 for example, so as it said, we would be able to figure out whether AMQP or 
 driver fails to do what it was designed for.
 Before proposing spec i’d like to figure out any other requirements, use 
 cases and restrictions for messaging performance testing. Also, if there any 
 stories of success in boosting python performance - feel free to share it.

The metrics to measure depend on the goal. Do we think the messaging code is 
using too much memory? Is it too slow? Or is there something else causing 
concern?

 
 
 
 [1] http://www.huyng.com/posts/python-performance-analysis/
 
 Kind regards,
 Denis Makogon
 IRC: denis_makogon
 dmako...@mirantis.com
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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


[openstack-dev] [TripleO] Part two of core reviewer team -- pruning

2015-01-15 Thread Clint Byrum
Hello! Now that we've added James, I have some suggestions for members
that should be dropped.

I have communicated with some of these individuals and confirmed they
are not interested in continuing. So for posterity sake I'm noting
these two removals, effective immediately:

Tzu-mainn Chen
Imre Farkas

The following members have not submitted any reviews in 90 days, but I
wasn't able to contact them immediately. If you are on this list and
would like to stay or step down, please reply directly to me or on the
list. Since we still have data blips from the traditional December
break, I don't think we should think too much about the numbers beyond
this until next month.


Members with no reviews in 90 days:

Martyn Taylor
Radomir Dopieralski

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


Re: [openstack-dev] [TripleO] nominating James Polley for tripleo-core

2015-01-15 Thread Dan Prince
On Wed, 2015-01-14 at 10:14 -0800, Clint Byrum wrote:
 Hello! It has been a while since we expanded our review team. The
 numbers aren't easy to read with recent dips caused by the summit and
 holidays. However, I believe James has demonstrated superb review skills
 and a commitment to the project that shows broad awareness of the
 project.
 
 Below are the results of a meta-review I did, selecting recent reviews
 by James with comments and a final score. I didn't find any reviews by
 James that I objected to.
 
 https://review.openstack.org/#/c/133554/ -- Took charge and provided
 valuable feedback. +2
 https://review.openstack.org/#/c/114360/ -- Good -1 asking for better
 commit message and then timely follow-up +1 with positive comments for
 more improvement. +2
 https://review.openstack.org/#/c/138947/ -- Simpler review, +1'd on Dec.
 19 and no follow-up since. Allowing 2 weeks for holiday vacation, this
 is only really about 7 - 10 working days and acceptable. +2
 https://review.openstack.org/#/c/146731/ -- Very thoughtful -1 review of
 recent change with alternatives to the approach submitted as patches.
 https://review.openstack.org/#/c/139876/ -- Simpler review, +1'd in
 agreement with everyone else. +1
 https://review.openstack.org/#/c/142621/ -- Thoughtful +1 with
 consideration for other reviewers. +2
 https://review.openstack.org/#/c/113983/ -- Thorough spec review with
 grammar pedantry noted as something that would not prevent a positive
 review score. +2
 
 All current tripleo-core members are invited to vote at this time. Thank
 you!

+1

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



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


[openstack-dev] [oslo] why we have 2 sets of tests in oslo libraries

2015-01-15 Thread Doug Hellmann
As part of the work on dropping the use of the oslo namespace [1], many of our 
library repositories now have 2 sets of tests. One set is under the new package 
(for example, “oslo_config/tests”), and uses the new import scheme (“from 
oslo_config import cfg”). To protect against regressions in the old public API, 
we have kept the original copies of the tests in a directory at the top level 
of the repository using the old import names (“from oslo.config import cfg”). 
The logic of most of the tests are identical now, aside from differences in the 
imports.

For new code, we only need to add tests in the new location inside the library 
package (“oslo_config/tests”). New symbols do not need to work through the old 
namespace, so using a new function or class may require updating imports in a 
consuming project.

The tests for the old public API should not be modified, except as we find 
redundancy that we can delete for testing private symbols. I did clean up some 
of the tests as I went along, but in a lot of cases it was faster to just 
update the imports. After we have all of the libraries released, I plan to 
spend more time going through the test suites and cleaning them up carefully, 
but that’s not a high priority task.

My goal is to be able to remove both the old namespace package and the related 
tests during the next cycle. We will have to check adoption progress as we get 
close to the end of Kilo to determine whether that is possible. Liaisons, 
please assume that we’re going to try to do it and work on updating all 
consuming projects.

Doug


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


[openstack-dev] [oslo.messaging] Performance testing. Initial steps.

2015-01-15 Thread Denis Makogon
Good day to All,

The question that i’d like to raise here is not simple one, so i’d like to
involve as much readers as i can. I’d like to speak about
oslo.messaging performance
testing. As community we’ve put lots of efforts in making oslo.messaging
widely used drivers stable as much as possible. Stability is a good thing,
but is it enough for saying “works well”? I’d say that it’s not.

Since oslo.messaging uses driver-based messaging workflow, it makes sense
to dig into each driver and collect all required/possible performance
metrics.

First of all, it does make sense to figure out how to perform performance
testing, first that came into my mind is to simulate high load on one of
corresponding drivers. Here comes the question of how it can be
accomplished withing available oslo.messaging tools - high load on any
driver can perform an application that:

   - can populate multiple emitters(rpc clients) and consumers (rpc
   servers).
   - can force clients to send messages of pre-defined number of messages
   of any length.

Another thing is why do we need such thing. Profiling, performance testing
can improve the way in which our drivers were implemented. It can show us
actual “bottlenecks” in messaging process, in general. In some cases it
does make sense to figure out where problem takes its place - whether AMQP
causes messaging problems or certain driver that speaks to AMQP fails.

Next thing that i want to discuss the architecture of profiling/performance
testing. As i can see it seemed to be a “good” way to add profiling code to
each driver. If there’s any objection or better solution, please bring them
to the light.

Once we’d have final design for profiling we would need to figure out tools
for profiling. After searching over the web, i found pretty interesting
topic related to python profiling [1]. After certain investigations it does
makes sense discuss next profiling options(apply one or both):

   - Line-by-line timing and execution frequency with a profiler (there are
   possible Pros and Cons, but i would say the per-line statistics is more
   than appreciable at initial performance testing steps)
   - Memory/CPU consumption

Metrics. The most useful metric for us is time, any time-based metric,
since it is very useful to know at which step or/and by whom delay/timeout
caused, for example, so as it said, we would be able to figure out whether
AMQP or driver fails to do what it was designed for.

Before proposing spec i’d like to figure out any other requirements, use
cases and restrictions for messaging performance testing. Also, if there
any stories of success in boosting python performance - feel free to share
it.



[1] http://www.huyng.com/posts/python-performance-analysis/

Kind regards,

Denis Makogon

IRC: denis_makogon

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


Re: [openstack-dev] [TripleO] nominating James Polley for tripleo-core

2015-01-15 Thread Clint Byrum
In about 24 hours we've seen 9 core +1's, one non-core +1, and only one
dissenting opinion from James himself which I think we have properly
dismissed. With my nomination counting as an additional +1, that is 10,
which is 50% of the 20 cores active the last 90 days.

I believe this vote has carried. Please welcome James Polley to the
TripleO core reviewer team. :)

Excerpts from Clint Byrum's message of 2015-01-14 10:14:45 -0800:
 Hello! It has been a while since we expanded our review team. The
 numbers aren't easy to read with recent dips caused by the summit and
 holidays. However, I believe James has demonstrated superb review skills
 and a commitment to the project that shows broad awareness of the
 project.
 
 Below are the results of a meta-review I did, selecting recent reviews
 by James with comments and a final score. I didn't find any reviews by
 James that I objected to.
 
 https://review.openstack.org/#/c/133554/ -- Took charge and provided
 valuable feedback. +2
 https://review.openstack.org/#/c/114360/ -- Good -1 asking for better
 commit message and then timely follow-up +1 with positive comments for
 more improvement. +2
 https://review.openstack.org/#/c/138947/ -- Simpler review, +1'd on Dec.
 19 and no follow-up since. Allowing 2 weeks for holiday vacation, this
 is only really about 7 - 10 working days and acceptable. +2
 https://review.openstack.org/#/c/146731/ -- Very thoughtful -1 review of
 recent change with alternatives to the approach submitted as patches.
 https://review.openstack.org/#/c/139876/ -- Simpler review, +1'd in
 agreement with everyone else. +1
 https://review.openstack.org/#/c/142621/ -- Thoughtful +1 with
 consideration for other reviewers. +2
 https://review.openstack.org/#/c/113983/ -- Thorough spec review with
 grammar pedantry noted as something that would not prevent a positive
 review score. +2
 
 All current tripleo-core members are invited to vote at this time. Thank
 you!

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


Re: [openstack-dev] [nova] reckoning time for nova ec2 stack

2015-01-15 Thread Matt Riedemann



On 1/13/2015 9:27 PM, Matt Riedemann wrote:



On 1/13/2015 12:11 PM, Steven Hardy wrote:

On Tue, Jan 13, 2015 at 10:00:04AM -0600, Matt Riedemann wrote:

Looks like the fix we merged didn't actually fix the problem. I have
a patch
[1] to uncap the boto requirement on master and it's failing the ec2
tests
in tempest the same as before.


FWIW, I just re-tested and boto 2.35.1 works fine for me locally, if you
revert my patch it breaks again with Signature not provided errors (for
all ec2 API requests).

If you look at the failures in the log, it actually looks like a
different
problem:

EC2ResponseError: EC2ResponseError: 401 Unauthorized

This is not the same as the original error which rejected any request
inside the nova API before even calling keystone with a message like
this:

AuthFailure: Signature not provided

AFAICT this means my patch is working, and there's a different problem
affecting only a subset of the ec2 boto tests.

Steve

__

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



Yeah, new bug reported, looks like we're hitting 401 Unauthorized errors
when trying to create security groups in the test:

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



I have a debug patch up here to try and recreate the tempest failures 
with latest boto but using a nova debug change also to get more 
information when we fail.


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

--

Thanks,

Matt Riedemann


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


Re: [openstack-dev] [nova] Networks are not cleaned up in build failure

2015-01-15 Thread Andrew Laski


On 01/15/2015 09:33 AM, Brian Haley wrote:

On 01/14/2015 02:15 PM, Andrew Laski wrote:

On 01/14/2015 12:57 PM, Murray, Paul (HP Cloud) wrote:

Hi All,

I recently experienced failures getting images from Glance while spawning
instances. This step comes after building the networks in the guild sequence.
When the Glance failure occurred the instance was cleaned up and rescheduled
as expected, but the networks were not cleaned up. On investigation I found
that the cleanup code for the networks is in the compute manager’s
_/do_build_run/_instance() method as follows:

 # NOTE(comstud): Deallocate networks if the driver wants
 # us to do so.
 if self.driver.deallocate_networks_on_reschedule(instance):
 self._cleanup_allocated_networks(context, instance,
 requested_networks)

The default behavior in for the deallocate_networks_on_schedule() method
defined in ComputeDriver is:

 def deallocate_networks_on_reschedule(self, instance):
 Does the driver want networks deallocated on reschedule?
 return False

Only the Ironic driver over rides this method to return True, so I think this
means the networks will not be cleaned up for any other virt driver.

  


Is this really the desired behavior?


Yes.  Other than when using Ironic there is nothing specific to a particular
host in the networking setup.  This means it is not necessary to deallocate and
reallocate networks when an instance is rescheduled, so we can avoid the
unnecessary work of doing it.

That's either not true any more, or not true when DVR is enabled in Neutron,
since in this case the port['binding:host_id'] value has been initialized to a
compute node, and won't get updated when nova-conductor re-schedules the VM
elsewhere.

This causes the neutron port to stay on the original compute node, and any
neutron operations (like floatingip-associate) happen on the old port, leaving
the VM unreachable.


Gotcha.  Then we should be rebinding that port on a reschedule or go 
back to de/reallocating.  I'm assuming there's some way to handle the 
port being moved or resizes would be broken for the same reason.


If we do need to move back to de/reallocation of networks I think it 
would be better to remove the conditional nature of it and just do it.  
If the deallocate_networks_on_reschedule method defaults to True I don't 
see a case where it would be overridden by a driver given the 
information above.



If the instance goes to ERROR then the network will get cleaned up when the
instance is deleted.

I think we need to clean-up even in this case now too.

-Brian

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



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


Re: [openstack-dev] [TripleO] nominating James Polley for tripleo-core

2015-01-15 Thread Clint Byrum
Excerpts from Chuck Carlino's message of 2015-01-15 09:43:41 -0800:
 On 01/15/2015 08:49 AM, Alexis Lee wrote:
  Clint Byrum said on Wed, Jan 14, 2015 at 10:14:45AM -0800:
  holidays. However, I believe James has demonstrated superb review skills
  and a commitment to the project that shows broad awareness of the
  project.
  Big +1. Thanks for taking the time to meta-review, Clint.
 
 
  Alexis
 
 I don't get a vote, but just wanted to point out James' excellent 
 contributions in chasing down neutron issues.
 
 Hmm, now that I've said it, I'm not entirely certain he'd have wanted me 
 to :P
 

Awesome, so James is our Neutron person now. :)

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


[openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments

2015-01-15 Thread Vitaly Kramskikh
Folks,

I want to discuss possibility to add network verification status field for
environments. There are 2 reasons for this:

1) One of the most frequent reasons of deployment failure is wrong network
configuration. In the current UI network verification is completely
optional and sometimes users are even unaware that this feature exists. We
can warn the user before the start of deployment if network check failed of
wasn't performed.

2) Currently network verification status is partially tracked by status of
the last network verification task. Sometimes its results become stale, and
the UI removes the task. There are a few cases when the UI does this, like
changing network settings, adding a new node, etc (you can grep
removeFinishedNetworkTasks to see all the cases). This definitely should
be done on backend.

What is your opinion on this?

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


[openstack-dev] [gantt] Scheduler hangout for today

2015-01-15 Thread Don Dugger
This is the hangout to talk about Gantt issues today.

- Forwarded message from Google+ noreply-2054f...@plus.google.com -

Date: Thu, 15 Jan 2015 06:43:50 -0800 (PST)
From: Google+ noreply-2054f...@plus.google.com
To: n0...@n0ano.com
Subject: Don Dugger is inviting you to join his hangout

Join Don's hangout

Hangouts are a great new way to video chat on Google+.
- Video chat with up to 9 people
- Watch YouTube videos together


Join Google+ now to hang out with Don.

Join Google+: 
https://plus.google.com/_/notifications/emlink?emr=15764514854518710435emid=CIjpk5OelsMCFSHEQgodBSQAWApath=%2Fup%2F%3Fgpinv%3DAMIXal8mlqUxWdfR68cy0FCPOmDMthaOg2P8TwzAh8SiB7k64gUqAPcvPvN8PwJ-tK09p7v4d0p9KosmdP6fjdVCju646GE-2qH2u0l5M1o28JqWklHa2Dc%26gpsrc%3Dhonen%26skww%3D1%26rtsl%3D1%26continue%3Dhttps%253A%252F%252Fplus.google.com%252Fhangouts%252F_%252Fgrbckm5vx7sj5gihbhhmnbiclea%253Fhcb%253D1%2526hii%253D103683676109584436432%2526hit%253D1421332981848%2526hs%253D87%2526hio%253D116378663745799369569dt=1421333030577uob=13

Couldn't connect with Don? Start a hangout with him now:
https://plus.google.com/_/notifications/emlink?emr=15764514854518710435emid=CIjpk5OelsMCFSHEQgodBSQAWApath=%2Fup%2F%3Fgpinv%3DAMIXal8mlqUxWdfR68cy0FCPOmDMthaOg2P8TwzAh8SiB7k64gUqAPcvPvN8PwJ-tK09p7v4d0p9KosmdP6fjdVCju646GE-2qH2u0l5M1o28JqWklHa2Dc%26gpsrc%3Dhonen%26skww%3D1%26rtsl%3D1%26continue%3Dhttps%253A%252F%252Fplus.google.com%252F_%252Fnotifications%252Femlink%253Femr%253D15764514854518710435%2526emid%253DCIjpk5OelsMCFSHEQgodBSQAWA%2526path%253D%25252Fhangouts%2526dt%253D1421333030577%2526uob%253D13dt=1421333030577uob=13

Or download the Google+ mobile app to make sure you never miss another
hangout:
http://www.google.com/intl/en/+/learnmore/mobile/



Learn more about Google+: http://www.google.com/+/learnmore/




- End forwarded message -

-- 
Don Dugger
Censeo Toto nos in Kansa esse decisse. - D. Gale
n0...@n0ano.com
Ph: 303/443-3786

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


Re: [openstack-dev] [Nova]Why nova mounts FS for LXC container instead of libvirt?

2015-01-15 Thread Dmitry Guryanov

On 01/12/2015 06:35 PM, Daniel P. Berrange wrote:

On Mon, Jan 12, 2015 at 06:28:53PM +0300, Dmitry Guryanov wrote:

On 01/05/2015 02:30 PM, Daniel P. Berrange wrote:

On Tue, Dec 30, 2014 at 05:18:19PM +0300, Dmitry Guryanov wrote:

Hello,

Libvirt can create loop or nbd device for LXC container and mount it by
itself, for instance, you can add something like this to xml config:

filesystem type='file'
   driver type='loop' format='raw'/
   source file='/fedora-20-raw'/
   target dir='/'/
/filesystem

But nova mounts filesystem for container by itself. Is this because rhel-6
doesn't support filesystems with type='file' or there are some other reasons?

The support for mounting using NBD in OpenStack pre-dated the support
for doing this in Libvirt. In faact the reason I added this feature to
libvirt was precisely because OpenStack was doing this.

We haven't switched Nova over to use this new syntax yet though, because
that would imply a change to the min required libvirt version for LXC.
That said we should probably make such a change, because honestly no
one should be using LXC without using user namespaces, othewise their
cloud is horribly insecure. This would imply making the min libvirt for
LXC much much newer than it is today.


It's not very hard to replace mounting in nova with generating proper xml
config. Can we do it before kilo release? Are there any people, who use
openstack with LXC in production?

Looking at libvirt history, it would mean we mandate 1.0.6 as the min
libvirt for use with the LXC driver.

Regards,
Daniel


I've created RFC patches:

https://review.openstack.org/#/c/147535/
https://review.openstack.org/#/c/147534/
https://review.openstack.org/#/c/147533/


--
Dmitry Guryanov


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


Re: [openstack-dev] [nova][cinder][infra] Ceph CI status update

2015-01-15 Thread Matt Riedemann



On 12/16/2014 2:48 PM, Matt Riedemann wrote:



On 12/11/2014 10:36 AM, Jon Bernard wrote:

Heya, quick Ceph CI status update.  Once the test_volume_boot_pattern
was marked as skipped, only the revert_resize test was failing.  I have
submitted a patch to nova for this [1], and that yields an all green
ceph ci run [2].  So at the moment, and with my revert patch, we're in
good shape.

I will fix up that patch today so that it can be properly reviewed and
hopefully merged.  From there I'll submit a patch to infra to move the
job to the check queue as non-voting, and we can go from there.

[1] https://review.openstack.org/#/c/139693/
[2]
http://logs.openstack.org/93/139693/1/experimental/check-tempest-dsvm-full-ceph/12397fd/console.html


Cheers,



Jon,

Thanks, this is something I'm supposed to be tracking actually given the
Kilo priorities for the project, it's nice to know that someone is
already fixing this stuff. :)

I've reviewed https://review.openstack.org/#/c/139693/ so it's close,
just needs a small fix.



With Jon's fix [1] the ceph job on the experimental queue is passing now 
[2].


This is great to see.

I think there are still some skipped tests due to known bugs but those 
can be worked out now that we have a baseline.


I'd also like to move forward on getting this into the check queue, but 
remain non-voting for the time being until it's burned in a bit (to make 
sure there aren't any bad intermittent failures lurking in there).


[1] https://review.openstack.org/#/c/139693/
[2] 
http://logs.openstack.org/93/139693/9/experimental/check-tempest-dsvm-full-ceph/e97ba57/console.html


--

Thanks,

Matt Riedemann


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


Re: [openstack-dev] [nova][gate][stable] How eventlet 0.16.1 broke the gate

2015-01-15 Thread Jeremy Stanley
On 2015-01-15 08:44:58 -0500 (-0500), Sean Dague wrote:
[...]
 The other thing that happened was partial capping doesn't work,
 because something else moves forward and breaks you from below. So
 the patch will need to hit everything at once.

Right, and we _have_ to start using stable branches on all
clients/libraries to backport fixes as part of that. This means that
the stable branch management workflow is about to become pervasive
across some teams who were previously (blissfully?) ignorant of it.

 Unresolved entirely is the tertiary dependencies (not direct
 dependencies of any OpenStack project). That will need another
 mechanism to seed them before any installation happens.
[...]

I won't go so far as to call it intractable, but I took a stab at it
about a year ago and building the dependency graph properly to be
able to do a depth-first ordering is nontrivial (enough that after
about a week hacking on possible solutions I gave up and switched to
more productive tasks). The primary complications I ran into were
identifying setup_requires in transitive dependencies and dealing
with platform/version-specific dependencies. That said, there's a
very good chance that more recent improvements in setuptools, pip
and virtualenv could make this task easier.

 That's the things I can think off from the top of my head.

The implementation, from a devstack-gate perspective, is also going
to require a decision on whether we stick with stable/relname for
branches of libraries too or switch to some extended branch mapping
mechanism to be able to track stable/relnum branches for those. And
we're going to need more jobs to ensure that clients (specifically)
retain backward-compatibility from an appdev and end user
perspective since they'll no longer get any testing as server
dependencies on stable branches (due to being capped there).
-- 
Jeremy Stanley

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


Re: [openstack-dev] [Openstack-operators] The state of nova-network to neutron migration

2015-01-15 Thread matt
Will do.

On Thu, Jan 15, 2015 at 12:08 PM, Anita Kuno ante...@anteaya.info wrote:

 On 01/14/2015 01:06 PM, matt wrote:
  Hey Mike!
 
  Thanks for this info.  Super helpful to me at least.  I am very
 interested
  in hearing more about nova-network to neutron migrations.
 
  -Matt
 
 Hello Matt:

 Please start attending the weekly meetings:
 https://wiki.openstack.org/wiki/Meetings/Nova-nettoNeutronMigration
 follow the logs from it:
 http://eavesdrop.openstack.org/meetings/nova_net_to_neutron_migration/
 as well as the logs for the neutron weekly meeting:
 http://eavesdrop.openstack.org/meetings/networking/
 and the nova weekly meeting:
 http://eavesdrop.openstack.org/meetings/nova/

 After you have had a chance to update yourself, please ask any questions
 either at one of the above meetings or do email me.

 Thank you Matt,
 Anita.

  On Tue, Jan 13, 2015 at 1:53 PM, Michael Still mi...@stillhq.com
 wrote:
 
  Hi, I just wanted to make sure people know that a small group of us
  got together in a hallway at linux.conf.au 2015 to talk about this. It
  wasn't an attempt to exclude anyone, we just all happened to be in the
  same place at the same time.
 
  To that end, we made some notes from the chat, which are at
  https://etherpad.openstack.org/p/nova-network-migration-lca2015 .
  Specific points to note are that Angus Lees has volunteered to help
  Oleg with the spec for this, and that we'd very much like to see a
  discussion of this at the Nova midcycle meetup in a couple of weeks.
 
  I'd also like to call out that there's a link to the mailing list
  thread where we discussed CERN's concerns in the etherpad for
  reference as well.
 
  Cheers,
  Michael
 
  On Sat, Dec 20, 2014 at 3:59 AM, Anita Kuno ante...@anteaya.info
 wrote:
  Rather than waste your time making excuses let me state where we are
 and
  where I would like to get to, also sharing my thoughts about how you
 can
  get involved if you want to see this happen as badly as I have been
 told
  you do.
 
  Where we are:
  * a great deal of foundation work has been accomplished to achieve
  parity with nova-network and neutron to the extent that those involved
  are ready for migration plans to be formulated and be put in place
  * a summit session happened with notes and intentions[0]
  * people took responsibility and promptly got swamped with other
  responsibilities
  * spec deadlines arose and in neutron's case have passed
  * currently a neutron spec [1] is a work in progress (and it needs
  significant work still) and a nova spec is required and doesn't have a
  first draft or a champion
 
  Where I would like to get to:
  * I need people in addition to Oleg Bondarev to be available to
 help
  come up with ideas and words to describe them to create the specs in a
  very short amount of time (Oleg is doing great work and is a fabulous
  person, yay Oleg, he just can't do this alone)
  * specifically I need a contact on the nova side of this complex
  problem, similar to Oleg on the neutron side
  * we need to have a way for people involved with this effort to
 find
  each other, talk to each other and track progress
  * we need to have representation at both nova and neutron weekly
  meetings to communicate status and needs
 
  We are at K-2 and our current status is insufficient to expect this
 work
  will be accomplished by the end of K-3. I will be championing this
 work,
  in whatever state, so at least it doesn't fall off the map. If you
 would
  like to help this effort please get in contact. I will be thinking of
  ways to further this work and will be communicating to those who
  identify as affected by these decisions in the most effective methods
 of
  which I am capable.
 
  Thank you to all who have gotten us as far as well have gotten in this
  effort, it has been a long haul and you have all done great work. Let's
  keep going and finish this.
 
  Thank you,
  Anita.
 
  [0] https://etherpad.openstack.org/p/kilo-nova-nova-network-to-neutron
  [1] https://review.openstack.org/#/c/142456/
 
  ___
  OpenStack-operators mailing list
  openstack-operat...@lists.openstack.org
 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
 
 
 
  --
  Rackspace Australia
 
  ___
  OpenStack-operators mailing list
  openstack-operat...@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
 
 


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


Re: [openstack-dev] [TripleO] nominating James Polley for tripleo-core

2015-01-15 Thread Anita Kuno
On 01/16/2015 07:39 AM, Clint Byrum wrote:
 In about 24 hours we've seen 9 core +1's, one non-core +1, and only one
 dissenting opinion from James himself which I think we have properly
 dismissed. With my nomination counting as an additional +1, that is 10,
 which is 50% of the 20 cores active the last 90 days.
 
 I believe this vote has carried. Please welcome James Polley to the
 TripleO core reviewer team. :)

/me hands James is custodial mop and bucket

Congratulations James and my condolences. :D

Anita.
 
 Excerpts from Clint Byrum's message of 2015-01-14 10:14:45 -0800:
 Hello! It has been a while since we expanded our review team. The
 numbers aren't easy to read with recent dips caused by the summit and
 holidays. However, I believe James has demonstrated superb review skills
 and a commitment to the project that shows broad awareness of the
 project.

 Below are the results of a meta-review I did, selecting recent reviews
 by James with comments and a final score. I didn't find any reviews by
 James that I objected to.

 https://review.openstack.org/#/c/133554/ -- Took charge and provided
 valuable feedback. +2
 https://review.openstack.org/#/c/114360/ -- Good -1 asking for better
 commit message and then timely follow-up +1 with positive comments for
 more improvement. +2
 https://review.openstack.org/#/c/138947/ -- Simpler review, +1'd on Dec.
 19 and no follow-up since. Allowing 2 weeks for holiday vacation, this
 is only really about 7 - 10 working days and acceptable. +2
 https://review.openstack.org/#/c/146731/ -- Very thoughtful -1 review of
 recent change with alternatives to the approach submitted as patches.
 https://review.openstack.org/#/c/139876/ -- Simpler review, +1'd in
 agreement with everyone else. +1
 https://review.openstack.org/#/c/142621/ -- Thoughtful +1 with
 consideration for other reviewers. +2
 https://review.openstack.org/#/c/113983/ -- Thorough spec review with
 grammar pedantry noted as something that would not prevent a positive
 review score. +2

 All current tripleo-core members are invited to vote at this time. Thank
 you!
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


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


Re: [openstack-dev] [TripleO] nominating James Polley for tripleo-core

2015-01-15 Thread James Slagle
On Thu, Jan 15, 2015 at 1:39 PM, Clint Byrum cl...@fewbar.com wrote:
 In about 24 hours we've seen 9 core +1's, one non-core +1, and only one
 dissenting opinion from James himself which I think we have properly
 dismissed. With my nomination counting as an additional +1, that is 10,
 which is 50% of the 20 cores active the last 90 days.

 I believe this vote has carried. Please welcome James Polley to the
 TripleO core reviewer team. :)

I'm a little late to the party, but it was a +1 from me as well. James
has been doing really valuable reviews for a while now.

-- 
-- James Slagle
--

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


Re: [openstack-dev] [nova] Networks are not cleaned up in build failure

2015-01-15 Thread Brian Haley
On 01/15/2015 12:55 PM, Andrew Laski wrote:
 On 01/15/2015 09:33 AM, Brian Haley wrote:
 On 01/14/2015 02:15 PM, Andrew Laski wrote:
 On 01/14/2015 12:57 PM, Murray, Paul (HP Cloud) wrote:
 Hi All,

 I recently experienced failures getting images from Glance while spawning
 instances. This step comes after building the networks in the guild 
 sequence.
 When the Glance failure occurred the instance was cleaned up and 
 rescheduled
 as expected, but the networks were not cleaned up. On investigation I found
 that the cleanup code for the networks is in the compute manager’s
 _/do_build_run/_instance() method as follows:

  # NOTE(comstud): Deallocate networks if the driver wants
  # us to do so.
  if self.driver.deallocate_networks_on_reschedule(instance):
  self._cleanup_allocated_networks(context, instance,
  requested_networks)

 The default behavior in for the deallocate_networks_on_schedule() method
 defined in ComputeDriver is:

  def deallocate_networks_on_reschedule(self, instance):
  Does the driver want networks deallocated on reschedule?
  return False

 Only the Ironic driver over rides this method to return True, so I think 
 this
 means the networks will not be cleaned up for any other virt driver.

  
 Is this really the desired behavior?

 Yes.  Other than when using Ironic there is nothing specific to a particular
 host in the networking setup.  This means it is not necessary to deallocate 
 and
 reallocate networks when an instance is rescheduled, so we can avoid the
 unnecessary work of doing it.
 That's either not true any more, or not true when DVR is enabled in Neutron,
 since in this case the port['binding:host_id'] value has been initialized to 
 a
 compute node, and won't get updated when nova-conductor re-schedules the VM
 elsewhere.

 This causes the neutron port to stay on the original compute node, and any
 neutron operations (like floatingip-associate) happen on the old port, 
 leaving
 the VM unreachable.
 
 Gotcha.  Then we should be rebinding that port on a reschedule or go back to
 de/reallocating.  I'm assuming there's some way to handle the port being moved
 or resizes would be broken for the same reason.
 
 If we do need to move back to de/reallocation of networks I think it would be
 better to remove the conditional nature of it and just do it.  If the
 deallocate_networks_on_reschedule method defaults to True I don't see a case
 where it would be overridden by a driver given the information above.

Andrew,

I was able to run a test here on a multi-node setup with DVR enabled:

- Booted VM
- Associated floating IP
- Updated binding:host_id (as admin) using the neutron API:

  $ neutron port-update $port -- --binding:host_id=novacompute5

The port was correctly moved to the other compute node and the floating IP
configured.  So that showed me the agents all did the right thing as far as I
can tell.  I know Paul was looking at the nova code to try and update just this
field, I'll check-in with him regarding that so we can get a patch up soon.

-Brian

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


Re: [openstack-dev] [Openstack-operators] The state of nova-network to neutron migration

2015-01-15 Thread Anita Kuno
On 01/14/2015 01:06 PM, matt wrote:
 Hey Mike!
 
 Thanks for this info.  Super helpful to me at least.  I am very interested
 in hearing more about nova-network to neutron migrations.
 
 -Matt
 
Hello Matt:

Please start attending the weekly meetings:
https://wiki.openstack.org/wiki/Meetings/Nova-nettoNeutronMigration
follow the logs from it:
http://eavesdrop.openstack.org/meetings/nova_net_to_neutron_migration/
as well as the logs for the neutron weekly meeting:
http://eavesdrop.openstack.org/meetings/networking/
and the nova weekly meeting:
http://eavesdrop.openstack.org/meetings/nova/

After you have had a chance to update yourself, please ask any questions
either at one of the above meetings or do email me.

Thank you Matt,
Anita.

 On Tue, Jan 13, 2015 at 1:53 PM, Michael Still mi...@stillhq.com wrote:
 
 Hi, I just wanted to make sure people know that a small group of us
 got together in a hallway at linux.conf.au 2015 to talk about this. It
 wasn't an attempt to exclude anyone, we just all happened to be in the
 same place at the same time.

 To that end, we made some notes from the chat, which are at
 https://etherpad.openstack.org/p/nova-network-migration-lca2015 .
 Specific points to note are that Angus Lees has volunteered to help
 Oleg with the spec for this, and that we'd very much like to see a
 discussion of this at the Nova midcycle meetup in a couple of weeks.

 I'd also like to call out that there's a link to the mailing list
 thread where we discussed CERN's concerns in the etherpad for
 reference as well.

 Cheers,
 Michael

 On Sat, Dec 20, 2014 at 3:59 AM, Anita Kuno ante...@anteaya.info wrote:
 Rather than waste your time making excuses let me state where we are and
 where I would like to get to, also sharing my thoughts about how you can
 get involved if you want to see this happen as badly as I have been told
 you do.

 Where we are:
 * a great deal of foundation work has been accomplished to achieve
 parity with nova-network and neutron to the extent that those involved
 are ready for migration plans to be formulated and be put in place
 * a summit session happened with notes and intentions[0]
 * people took responsibility and promptly got swamped with other
 responsibilities
 * spec deadlines arose and in neutron's case have passed
 * currently a neutron spec [1] is a work in progress (and it needs
 significant work still) and a nova spec is required and doesn't have a
 first draft or a champion

 Where I would like to get to:
 * I need people in addition to Oleg Bondarev to be available to help
 come up with ideas and words to describe them to create the specs in a
 very short amount of time (Oleg is doing great work and is a fabulous
 person, yay Oleg, he just can't do this alone)
 * specifically I need a contact on the nova side of this complex
 problem, similar to Oleg on the neutron side
 * we need to have a way for people involved with this effort to find
 each other, talk to each other and track progress
 * we need to have representation at both nova and neutron weekly
 meetings to communicate status and needs

 We are at K-2 and our current status is insufficient to expect this work
 will be accomplished by the end of K-3. I will be championing this work,
 in whatever state, so at least it doesn't fall off the map. If you would
 like to help this effort please get in contact. I will be thinking of
 ways to further this work and will be communicating to those who
 identify as affected by these decisions in the most effective methods of
 which I am capable.

 Thank you to all who have gotten us as far as well have gotten in this
 effort, it has been a long haul and you have all done great work. Let's
 keep going and finish this.

 Thank you,
 Anita.

 [0] https://etherpad.openstack.org/p/kilo-nova-nova-network-to-neutron
 [1] https://review.openstack.org/#/c/142456/

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



 --
 Rackspace Australia

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

 


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


Re: [openstack-dev] [Fuel] Empty role - status

2015-01-15 Thread Andrew Woodward
[from another thread]
On Wed, Jan 14, 2015 at 2:24 AM, Igor Kalnitsky ikalnit...@mirantis.com wrote:

 Guys,

 We want to introduce an empty role as a basis for plugins. For
 instance, the user select nodes, assign empty role and names it
 somehow like CONTRAIL. In this step, vanilla fuel will just
 provision a node (since it's an empty role) and the plugin (in post
 hooks) can select all empty roles with node.name == CONTRAIL and
 deploy some stuff on that node.

 Obviously, it's hackish. But it's a simple approach that requires a
 minimum time. In future, we'll introduce pluggable roles, but that's
 another story.


So far from the review we simply added an role with a base OS, this
provides a nearly useless experience for plugin developers. This is
heavy on hacking even for plugin-devs

issues:
1) you get one role
2) you have to come up with some random way to identify nodes from
each other if you do. We can't set hostname, and node.name in the
nailgun is never in astute.yaml (which is a tech debt that we have
code to fix)
3) disk layout is fixed, and uselessly small, plugin-author will have
a lot of rework to do here
4) multiple plugins that need roles will effectively fight with each other

We can add roles in the releases API as it is, a plugin should be able
to leverage this, the only gap currently is [1] which is not an API
currently (new from granular deployments).

Because of this, it would be more useful to just call these API's
during installing the plugin. Worse case, the plugin author can do
this themselves if we add the install_script support [2]

[1] 
https://review.openstack.org/#/c/147230/2/nailgun/nailgun/orchestrator/graph_configuration.py
[2] https://review.openstack.org/#/c/137301/

On Thu, Jan 15, 2015 at 3:11 AM, Andrey Danin ada...@mirantis.com wrote:
 Answers inline.

 On Thu, Jan 15, 2015 at 1:21 AM, Evgeniy L e...@mirantis.com wrote:

 Hi,

 Empty role is ready [1], thanks to granular deployment feature
 I didn't have to hardcode some hacks in Astute again.

 But there are several things which I want to mention/discuss:

 1. in the patch you can see the name of the role and its description
 I would like to ask you to verify it and provide some other options if
 you
 have any
 2. we have a minor problem with the progress bar, we will figure out how
 to fix it in Astute with Vladimir S.
 3. and the biggest problem is an old bug [2], the bug is Ubuntu specific
 and it
 doesn't allow us to make efficient partitioning schema, e.g. it means
 that we
 cannot allocate root partition for all of the disks (provisioning will
 fail), the
 current workaround is to allocate root partition with minimal size
 (about 15G) and leave the rest of the space as is (unallocated). As
 far as I can see from the bug it's not so easy to fix the problem,
 actually
 image based provisioning fixes the problem, but it's not an option for
 the
 current release. Maybe you have some other ideas how to fix this
 problem?

 I would leave it as is - 15 GB. A user or plugin can adjust it for its
 needs.


 Thanks,

 [1] https://review.openstack.org/#/c/147230/
 [2] https://bugs.launchpad.net/fuel/+bug/1278964

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




 --
 Andrey Danin
 ada...@mirantis.com
 skype: gcon.monolake

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




-- 
Andrew
Mirantis
Ceph community

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


Re: [openstack-dev] [Openstack-operators] The state of nova-network to neutron migration

2015-01-15 Thread Kyle Mestery
On Thu, Jan 15, 2015 at 2:19 PM, Kris G. Lindgren klindg...@godaddy.com
wrote:

   Is the fact that neutron security groups don’t provide the same level
 of isolation as nova security groups on your guys radar?

  Specifically talking about:
 https://bugs.launchpad.net/neutron/+bug/1274034

 That bug is actually tracked by a BP as well which is approved and marked
as Kilo-2 [1].



  I am sure their are a few other thigns that nova is doing that neutron
 is currently not.


That may be true. The plan which was agreed to and executed on by the TC
during Juno is here [2]. If there are other features people want from
nova-network in neutron, I encourage them to file bugs or specs to track
them.

[1] https://blueprints.launchpad.net/neutron/+spec/arp-spoof-patch-ebtables
[2]
https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee/Neutron_Gap_Coverage



 Kris Lindgren
 Senior Linux Systems Engineer
 GoDaddy, LLC.

   From: matt m...@nycresistor.com
 Date: Thursday, January 15, 2015 at 1:10 PM
 To: Anita Kuno ante...@anteaya.info
 Cc: Angus Lees gusl...@gmail.com, OpenStack Development Mailing List 
 openstack-dev@lists.openstack.org, 
 openstack-operat...@lists.openstack.org 
 openstack-operat...@lists.openstack.org
 Subject: Re: [Openstack-operators] The state of nova-network to neutron
 migration

   Will do.

 On Thu, Jan 15, 2015 at 12:08 PM, Anita Kuno ante...@anteaya.info wrote:

 On 01/14/2015 01:06 PM, matt wrote:
  Hey Mike!
 
  Thanks for this info.  Super helpful to me at least.  I am very
 interested
  in hearing more about nova-network to neutron migrations.
 
  -Matt
 
 Hello Matt:

 Please start attending the weekly meetings:
 https://wiki.openstack.org/wiki/Meetings/Nova-nettoNeutronMigration
 follow the logs from it:
 http://eavesdrop.openstack.org/meetings/nova_net_to_neutron_migration/
 as well as the logs for the neutron weekly meeting:
 http://eavesdrop.openstack.org/meetings/networking/
 and the nova weekly meeting:
 http://eavesdrop.openstack.org/meetings/nova/

 After you have had a chance to update yourself, please ask any questions
 either at one of the above meetings or do email me.

 Thank you Matt,
 Anita.

  On Tue, Jan 13, 2015 at 1:53 PM, Michael Still mi...@stillhq.com
 wrote:
 
  Hi, I just wanted to make sure people know that a small group of us
  got together in a hallway at linux.conf.au 2015 to talk about this. It
  wasn't an attempt to exclude anyone, we just all happened to be in the
  same place at the same time.
 
  To that end, we made some notes from the chat, which are at
  https://etherpad.openstack.org/p/nova-network-migration-lca2015 .
  Specific points to note are that Angus Lees has volunteered to help
  Oleg with the spec for this, and that we'd very much like to see a
  discussion of this at the Nova midcycle meetup in a couple of weeks.
 
  I'd also like to call out that there's a link to the mailing list
  thread where we discussed CERN's concerns in the etherpad for
  reference as well.
 
  Cheers,
  Michael
 
  On Sat, Dec 20, 2014 at 3:59 AM, Anita Kuno ante...@anteaya.info
 wrote:
  Rather than waste your time making excuses let me state where we are
 and
  where I would like to get to, also sharing my thoughts about how you
 can
  get involved if you want to see this happen as badly as I have been
 told
  you do.
 
  Where we are:
  * a great deal of foundation work has been accomplished to achieve
  parity with nova-network and neutron to the extent that those involved
  are ready for migration plans to be formulated and be put in place
  * a summit session happened with notes and intentions[0]
  * people took responsibility and promptly got swamped with other
  responsibilities
  * spec deadlines arose and in neutron's case have passed
  * currently a neutron spec [1] is a work in progress (and it needs
  significant work still) and a nova spec is required and doesn't have a
  first draft or a champion
 
  Where I would like to get to:
  * I need people in addition to Oleg Bondarev to be available to
 help
  come up with ideas and words to describe them to create the specs in a
  very short amount of time (Oleg is doing great work and is a fabulous
  person, yay Oleg, he just can't do this alone)
  * specifically I need a contact on the nova side of this complex
  problem, similar to Oleg on the neutron side
  * we need to have a way for people involved with this effort to
 find
  each other, talk to each other and track progress
  * we need to have representation at both nova and neutron weekly
  meetings to communicate status and needs
 
  We are at K-2 and our current status is insufficient to expect this
 work
  will be accomplished by the end of K-3. I will be championing this
 work,
  in whatever state, so at least it doesn't fall off the map. If you
 would
  like to help this effort please get in contact. I will be thinking of
  ways to further this work and 

Re: [openstack-dev] [neutron] Changes to the core team

2015-01-15 Thread Anita Kuno
On 01/16/2015 11:31 AM, Kyle Mestery wrote:
 The last time we looked at core reviewer stats was in December [1]. In
 looking at the current stats, I'm going to propose some changes to the core
 team. Reviews are the most important part of being a core reviewer, so we
 need to ensure cores are doing reviews. The stats for the 90 day period [2]
 indicate some changes are needed for core reviewers who are no longer
 reviewing on pace with the other core reviewers.
 
 First of all, I'm removing Sumit Naiksatam from neutron-core. Sumit has
 been a core reviewer for a long time, and his past contributions are very
 much thanked by the entire OpenStack Neutron team. If Sumit jumps back in
 with thoughtful reviews in the future, we can look at getting him back as a
 Neutron core reviewer. But for now, his stats indicate he's not reviewing
 at a level consistent with the rest of the Neutron core reviewers.
 
 As part of the change, I'd like to propose Doug Wiegley as a new Neutron
 core reviewer. Doug has been actively reviewing code across not only all
 the Neutron projects, but also other projects such as infra. His help and
 work in the services split in December were the reason we were so
 successful in making that happen. Doug has also been instrumental in the
 Neutron LBaaS V2 rollout, as well as helping to merge code in the other
 neutron service repositories.
I don't have a vote here but I would like to echo Kyle's summary of the
value of Doug's work with infra with the services split effort. It
wouldn't have happened without Doug's patience, persistence and leadership.

Thanks,
Anita.
 
 I'd also like to take this time to remind everyone that reviewing code is a
 responsibility, in Neutron the same as other projects. And core reviewers
 are especially beholden to this responsibility. I'd also like to point out
 that +1/-1 reviews are very useful, and I encourage everyone to continue
 reviewing code even if you are not a core reviewer.
 
 Existing neutron cores, please vote +1/-1 for the addition of Doug to the
 core team.
 
 Thanks!
 Kyle
 
 [1]
 http://lists.openstack.org/pipermail/openstack-dev/2014-December/051986.html
 [2] http://russellbryant.net/openstack-stats/neutron-reviewers-90.txt
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


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


Re: [openstack-dev] [neutron] Changes to the core team

2015-01-15 Thread Kevin Benton
+1, without Doug's help fixing everything, the services split probably
wouldn't have happened.

On Thu, Jan 15, 2015 at 2:31 PM, Kyle Mestery mest...@mestery.com wrote:

 The last time we looked at core reviewer stats was in December [1]. In
 looking at the current stats, I'm going to propose some changes to the core
 team. Reviews are the most important part of being a core reviewer, so we
 need to ensure cores are doing reviews. The stats for the 90 day period [2]
 indicate some changes are needed for core reviewers who are no longer
 reviewing on pace with the other core reviewers.

 First of all, I'm removing Sumit Naiksatam from neutron-core. Sumit has
 been a core reviewer for a long time, and his past contributions are very
 much thanked by the entire OpenStack Neutron team. If Sumit jumps back in
 with thoughtful reviews in the future, we can look at getting him back as a
 Neutron core reviewer. But for now, his stats indicate he's not reviewing
 at a level consistent with the rest of the Neutron core reviewers.

 As part of the change, I'd like to propose Doug Wiegley as a new Neutron
 core reviewer. Doug has been actively reviewing code across not only all
 the Neutron projects, but also other projects such as infra. His help and
 work in the services split in December were the reason we were so
 successful in making that happen. Doug has also been instrumental in the
 Neutron LBaaS V2 rollout, as well as helping to merge code in the other
 neutron service repositories.

 I'd also like to take this time to remind everyone that reviewing code is
 a responsibility, in Neutron the same as other projects. And core reviewers
 are especially beholden to this responsibility. I'd also like to point out
 that +1/-1 reviews are very useful, and I encourage everyone to continue
 reviewing code even if you are not a core reviewer.

 Existing neutron cores, please vote +1/-1 for the addition of Doug to the
 core team.

 Thanks!
 Kyle

 [1]
 http://lists.openstack.org/pipermail/openstack-dev/2014-December/051986.html
 [2] http://russellbryant.net/openstack-stats/neutron-reviewers-90.txt

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




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


Re: [openstack-dev] [neutron] Changes to the core team

2015-01-15 Thread Maru Newby
+1 to Doug’s addition.  He’s been a workhorse in moving lbaas and the services 
split forward and his being able to finally merge code in the main repo should 
be a boon to our merge velocity.

Many thanks to Sumit for his long-serving dedication as a core reviewer.  I 
hope to see him return to the fold soon!


Maru

 On Jan 15, 2015, at 2:31 PM, Kyle Mestery mest...@mestery.com wrote:
 
 The last time we looked at core reviewer stats was in December [1]. In 
 looking at the current stats, I'm going to propose some changes to the core 
 team. Reviews are the most important part of being a core reviewer, so we 
 need to ensure cores are doing reviews. The stats for the 90 day period [2] 
 indicate some changes are needed for core reviewers who are no longer 
 reviewing on pace with the other core reviewers.
 
 First of all, I'm removing Sumit Naiksatam from neutron-core. Sumit has been 
 a core reviewer for a long time, and his past contributions are very much 
 thanked by the entire OpenStack Neutron team. If Sumit jumps back in with 
 thoughtful reviews in the future, we can look at getting him back as a 
 Neutron core reviewer. But for now, his stats indicate he's not reviewing at 
 a level consistent with the rest of the Neutron core reviewers.
 
 As part of the change, I'd like to propose Doug Wiegley as a new Neutron core 
 reviewer. Doug has been actively reviewing code across not only all the 
 Neutron projects, but also other projects such as infra. His help and work in 
 the services split in December were the reason we were so successful in 
 making that happen. Doug has also been instrumental in the Neutron LBaaS V2 
 rollout, as well as helping to merge code in the other neutron service 
 repositories.
 
 I'd also like to take this time to remind everyone that reviewing code is a 
 responsibility, in Neutron the same as other projects. And core reviewers are 
 especially beholden to this responsibility. I'd also like to point out that 
 +1/-1 reviews are very useful, and I encourage everyone to continue reviewing 
 code even if you are not a core reviewer.
 
 Existing neutron cores, please vote +1/-1 for the addition of Doug to the 
 core team.
 
 Thanks!
 Kyle
 
 [1] 
 http://lists.openstack.org/pipermail/openstack-dev/2014-December/051986.html
 [2] http://russellbryant.net/openstack-stats/neutron-reviewers-90.txt
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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


[openstack-dev] Running tox on Centos 6.5 with Python26

2015-01-15 Thread John Warren


Can someone tell me or point me to documentation about what the  
required yum and pip packages are to be able to run tox for glance,  
keystone, neutron, cinder and nova on Centos 6.5 with Python 2.6?  I  
looked at the openstack-infra/puppet-jenkins project and thought I  
installed everything in the slave.pp manifest, which presumably is  
sufficient to be able to run tox for all openstack projects, but when  
I try to run tox on nova (tox --recreate -epy26) I just get an error  
that indicates that no test cases were found.


Any help would be greatly appreciated.

John


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


[openstack-dev] [nova] [oslo] compare and swap progress

2015-01-15 Thread Mike Bayer
For those who haven’t seen it, I’d like to first share Jay Pipes’ unbelievably 
thorough blog post on Nova update concurrency, specifically as it relates to 
the issue of emitting an UPDATE on a locked” row without using SELECT..FOR 
UPDATE (as well as why we *can’t* keep using SELECT..FOR UPDATE).  Go read it, 
I’ll wait here:  

http://www.joinfu.com/2015/01/understanding-reservations-concurrency-locking-in-nova/


Got all that? OK.   There’ve been two patches so far I’m aware of to 
implement this within a key area in nova.  We have Jay’s and Matt Booth’s:

https://review.openstack.org/109837
https://review.openstack.org/141115

So what I want to do with either of those (Matt’s seems to be a little further 
along) is factor out all that UPDATE stuff, and make a nice oslo.db function 
that will:

1. emit an UPDATE statement that matches a row on a full set of attributes 
present in a given object “specimen”;

2. if exactly one row matched, retrieve the primary key of that row using as 
efficient a means as possible given the backend database and schema design;

3. return a persistent version of the given “specimen” as though it was just 
SELECTed from the database.

I have that ready to go, which most likely can be of use in many more scenarios 
than just this one.  I invite folks to take a look:

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

Example:

 specimen = MyModel(
y='y9', z='z5', x=6,
uuid='136254d5-3869-408f-9da7-190e0072641a'
)

result = session.query(MyModel).update_on_match(
specimen,
'uuid', 
values={'x': 9, 'z': 'z3'})

# result is now a persistent version of specimen (at the moment
# the same object) with all the new values.  the UPDATE statement 
guaranteed
# to match all of x, y, z and uuid.






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


Re: [openstack-dev] [horizon] static files handling, bower/

2015-01-15 Thread Michael Krotscheck

  I think Oracle's got enough money to support Node.js on SPARC.

 How is money relevant here?


Well, normally the argument I've received is We don't have the
time/resources/insert-other-fiscally-motivated-reason to support/work on
node. Ergo, money. But then, given Oracle's conduct around the whole Java
ridiculousness I'm not exactly favorably disposed towards anything or
anyone associated with them. They'd get a lot more respect if they
open-sourced Solaris.

Which actually reminds me of something: Infra only tests against Debian,
CentOS, and Fedora. It does not test Solaris. So, no offense, but I don't
care about your SPARC servers.

... that Node.js is an issue because we can not use it.  Not because we

don't WANT to use it.  This is an important distinction that you seem to
 have missed.


I haven't missed it, I just made the assumption that if someone wants to
use a tool, they would be busy porting that tool rather than arguing on a
list about it.

Case and point: I wanted to use javascript in OpenStack Infra, so I did a
ton of legwork to bring node, npm, bower, karma, jasmine, protractor, and
grunt into the infra toolchain.

 So let me reframe this argument a bit: If you refuse to allow us
  frontend developers to use node, npm, and bower, then I expect you to
  reciprocate and no longer use the python executable or pip to write your
  code, and you can only debug using wsgi. Since those fill equivalent
  roles in our various languages-du-jour, it seems like a perfectly fair
  exchange. Deal?

 I'm sorry, what?  Python is fully supported on Solaris (both x86 and
 SPARC).  This discussion has nothing whatsoever to do with the
 'language-du-jour'.


It has everything to do with it: There are javascript engineers that want
to use their tools, just like there are python engineers that want to user
their tools. You're saying we can't use javascript tools because of SPARC's
lack of support. I'm merely asking that our python engineers reciprocate
and abandon your own tools out of solidarity. After all, we're all in this
together, right?

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


[openstack-dev] [nova] Reminder of priority etherpad

2015-01-15 Thread Michael Still
Hi,

I know many of us are just coming back from holiday breaks -- I
certainly am. It came up in the nova meeting this morning that we've
stopped being so reliable at reviewing the priority review etherpad
when deciding what to review. So -- it would be cool if reviewers
(everyone, not just core) could make checking the state of priority
reviews on the etherpad as part of their review workflow.

The etherpad is at:

https://etherpad.openstack.org/p/kilo-nova-priorities-tracking

Thanks,
Michael

-- 
Rackspace Australia

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


[openstack-dev] [neutron] Changes to the core team

2015-01-15 Thread Kyle Mestery
The last time we looked at core reviewer stats was in December [1]. In
looking at the current stats, I'm going to propose some changes to the core
team. Reviews are the most important part of being a core reviewer, so we
need to ensure cores are doing reviews. The stats for the 90 day period [2]
indicate some changes are needed for core reviewers who are no longer
reviewing on pace with the other core reviewers.

First of all, I'm removing Sumit Naiksatam from neutron-core. Sumit has
been a core reviewer for a long time, and his past contributions are very
much thanked by the entire OpenStack Neutron team. If Sumit jumps back in
with thoughtful reviews in the future, we can look at getting him back as a
Neutron core reviewer. But for now, his stats indicate he's not reviewing
at a level consistent with the rest of the Neutron core reviewers.

As part of the change, I'd like to propose Doug Wiegley as a new Neutron
core reviewer. Doug has been actively reviewing code across not only all
the Neutron projects, but also other projects such as infra. His help and
work in the services split in December were the reason we were so
successful in making that happen. Doug has also been instrumental in the
Neutron LBaaS V2 rollout, as well as helping to merge code in the other
neutron service repositories.

I'd also like to take this time to remind everyone that reviewing code is a
responsibility, in Neutron the same as other projects. And core reviewers
are especially beholden to this responsibility. I'd also like to point out
that +1/-1 reviews are very useful, and I encourage everyone to continue
reviewing code even if you are not a core reviewer.

Existing neutron cores, please vote +1/-1 for the addition of Doug to the
core team.

Thanks!
Kyle

[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-December/051986.html
[2] http://russellbryant.net/openstack-stats/neutron-reviewers-90.txt
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] Resend: [nova] Request Spec Freeze Exception for Enhance iSCSI multipath/failover support

2015-01-15 Thread Tomoki Sekiyama
Michael,



These wasn't on the list of of exceptions at today's nova meeting. Please
add them.

On 1/8/15, 11:48 , Tomoki Sekiyama tomoki.sekiy...@hds.com wrote:
Hi,

I have submitted 2 nova-specs [1][2] related to Cinder volumes iSCSI
multipath/failover improvement.

These specs are both for enabling Cinder to pass multiple iSCSI paths to
Nova. [1] is for multipath use-case, where Nova will establish iSCSI
sessions to all the given paths. [2] is for failover use-case, where Nova
will try to establish alternative path when it fails to establish main
path.

These specs were blocked to wait for corresponding cinder-specs approval
[3][4], which are now approved. Please consider these specs for spec
freeze exception.

nova-specs:
[1] https://review.openstack.org/#/c/134299/
[2] https://review.openstack.org/#/c/137468/

cinder-specs:
[3] https://review.openstack.org/#/c/136500/
[4] https://review.openstack.org/#/c/131502/


Regards,
Tomoki Sekiyama


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


Re: [openstack-dev] [nova] reckoning time for nova ec2 stack

2015-01-15 Thread Steven Hardy
On Thu, Jan 15, 2015 at 04:49:37PM -0600, Matt Riedemann wrote:
 
 
 On 1/15/2015 11:40 AM, Matt Riedemann wrote:
 
 
 On 1/13/2015 9:27 PM, Matt Riedemann wrote:
 
 
 On 1/13/2015 12:11 PM, Steven Hardy wrote:
 On Tue, Jan 13, 2015 at 10:00:04AM -0600, Matt Riedemann wrote:
 Looks like the fix we merged didn't actually fix the problem. I have
 a patch
 [1] to uncap the boto requirement on master and it's failing the ec2
 tests
 in tempest the same as before.
 
 FWIW, I just re-tested and boto 2.35.1 works fine for me locally, if you
 revert my patch it breaks again with Signature not provided errors
 (for
 all ec2 API requests).
 
 If you look at the failures in the log, it actually looks like a
 different
 problem:
 
 EC2ResponseError: EC2ResponseError: 401 Unauthorized
 
 This is not the same as the original error which rejected any request
 inside the nova API before even calling keystone with a message like
 this:
 
 AuthFailure: Signature not provided
 
 AFAICT this means my patch is working, and there's a different problem
 affecting only a subset of the ec2 boto tests.
 
 Steve
 
 __
 
 
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 Yeah, new bug reported, looks like we're hitting 401 Unauthorized errors
 when trying to create security groups in the test:
 
 https://bugs.launchpad.net/nova/+bug/1410622
 
 
 I have a debug patch up here to try and recreate the tempest failures
 with latest boto but using a nova debug change also to get more
 information when we fail.
 
 https://review.openstack.org/#/c/147601/
 
 
 I finally narrowed this down to some code in keystone where it generates a
 signature and compares that to what nova is passing in on the request for
 ec2 credentials and they are different so keystone is rejecting the request
 with a 401.
 
 http://logs.openstack.org/01/147601/3/check/check-tempest-dsvm-full/96bb05e/logs/apache/keystone.txt.gz#_2015-01-15_22_00_27_046
 
 I'm assuming something needs to change in keystone to support the version 4
 format?

Keystone already supports the hmac v4 format, the code which creates the
signature keystone compares with that in the request actually lives in
keystoneclient:

https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/contrib/ec2/utils.py#L156

We have been bitten by a couple of bugs in the past where boto changed the
way it calculated the signature (presumably in a way compatible with AWS),
but generally that breaks all requests not just a specific one as in this
case (CreateSecurityGroup).

Interestingly, this seems to work OK for me locally, e.g using
euca-add-group, which AFAICS is the same API action the test is failing on:

-bash-4.2$ source /opt/stack/devstack/accrc/demo/demo
-bash-4.2$ euca-add-group --debug --description foo shtest2
2015-01-15 23:33:22,890 euca2ools [DEBUG]:Using access key provided by
client.
2015-01-15 23:33:22,890 euca2ools [DEBUG]:Using secret key provided by
client.
2015-01-15 23:33:22,890 euca2ools [DEBUG]:Method: POST
2015-01-15 23:33:22,890 euca2ools [DEBUG]:Path: /services/Cloud/
2015-01-15 23:33:22,890 euca2ools [DEBUG]:Data: 
2015-01-15 23:33:22,890 euca2ools [DEBUG]:Headers: {}
2015-01-15 23:33:22,891 euca2ools [DEBUG]:Host: 192.168.0.4
2015-01-15 23:33:22,891 euca2ools [DEBUG]:Port: 8773
2015-01-15 23:33:22,891 euca2ools [DEBUG]:Params: {'Action':
'CreateSecurityGroup', 'GroupName': 'shtest2', 'Version': '2009-11-30',
'GroupDescription': 'foo'}
2015-01-15 23:33:22,891 euca2ools [DEBUG]:establishing HTTP connection:
kwargs={'port': 8773, 'timeout': 70}
2015-01-15 23:33:22,891 euca2ools [DEBUG]:Token: None
2015-01-15 23:33:22,891 euca2ools [DEBUG]:CanonicalRequest:
POST
/services/Cloud/

host:192.168.0.4:8773
x-amz-date:20150115T233322Z

host;x-amz-date
a364b884b3e72160b8850f80c1b5b559011b38313da026d04dd60b745c0fd135
2015-01-15 23:33:22,892 euca2ools [DEBUG]:StringToSign:
AWS4-HMAC-SHA256
20150115T233322Z
20150115/168/192/aws4_request
6b751f8ad4ca1935c68a35f196928c1626d8fdb0ae4bf901050ab757649c9a9a
2015-01-15 23:33:22,892 euca2ools [DEBUG]:Signature:
3a0c741e4a8abf22d83ea8d909bb90e11627905338e42fdfaa51296fa5f2dd31
2015-01-15 23:33:22,892 euca2ools [DEBUG]:Final headers: {'Content-Length':
'84', 'User-Agent': 'Boto/2.35.1 Python/2.7.5
Linux/3.17.7-200.fc20.x86_64', 'Host': '192.168.0.4:8773', 'X-Amz-Date':
'20150115T233322Z', 'Content-Type': 'application/x-www-form-urlencoded;
charset=UTF-8', 'Authorization': 'AWS4-HMAC-SHA256
Credential=8943303abb374011be595587aa1fc986/20150115/168/192/aws4_request,SignedHeaders=host;x-amz-date,Signature=3a0c741e4a8abf22d83ea8d909bb90e11627905338e42fdfaa51296fa5f2dd31'}
2015-01-15 23:33:22,994 euca2ools [DEBUG]:Response headers: [('date', 'Thu,
15 Jan 2015 23:33:22 GMT'), ('content-length', '407'), ('content-type

Re: [openstack-dev] Resending: [nova] Request Spec Freeze Exception for: Remove direct nova DB/API access in Scheduler Filters

2015-01-15 Thread Michael Still
Thanks for this, I will add it to the list.

Michael

On Fri, Jan 16, 2015 at 11:00 AM, Ed Leafe e...@leafe.com wrote:
 I sent this at the beginning of the exception process, but it did not appear 
 on the list of exceptions mikal posted at today's nova meeting, so I'm 
 re-sending.

 Begin forwarded message:

 Date: January 8, 2015 at 8:50:57 AM CST
 From: Ed Leafe e...@leafe.com
 To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org) 
 openstack-dev@lists.openstack.org
 Subject: [openstack-dev] [nova] Request Spec Freeze Exception for: Remove 
 direct nova DB/API access in Scheduler Filters
 Reply-To: OpenStack Development Mailing List \(not for usage questions\) 
 openstack-dev@lists.openstack.org

 Signed PGP part
 Hi,

 This spec [1] has been on hold, as it was largely dependent on another
 spec [2] being approved first, as it has very similar requirements.
 Now that the latter has been approved, I am moving forward with the
 former. It is part of the scheduler cleanup effort that has been
 identified as a priority for Kilo.

 Thanks for your consideration!

 [1] https://review.openstack.org/#/c/138444/

 [2]
 https://github.com/openstack/nova-specs/blob/master/specs/kilo/approved/isolate-scheduler-db-aggregates.rst


 -- Ed Leafe


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



 -- Ed Leafe






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




-- 
Rackspace Australia

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


Re: [openstack-dev] [neutron] Changes to the core team

2015-01-15 Thread Edgar Magana
+1 For adding Doug as Core in Neutron!

I have seen his work on the services part and he is a great member of the 
OpenStack community!

Edgar

From: Kyle Mestery mest...@mestery.commailto:mest...@mestery.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, January 15, 2015 at 2:31 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron] Changes to the core team

The last time we looked at core reviewer stats was in December [1]. In looking 
at the current stats, I'm going to propose some changes to the core team. 
Reviews are the most important part of being a core reviewer, so we need to 
ensure cores are doing reviews. The stats for the 90 day period [2] indicate 
some changes are needed for core reviewers who are no longer reviewing on pace 
with the other core reviewers.

First of all, I'm removing Sumit Naiksatam from neutron-core. Sumit has been a 
core reviewer for a long time, and his past contributions are very much thanked 
by the entire OpenStack Neutron team. If Sumit jumps back in with thoughtful 
reviews in the future, we can look at getting him back as a Neutron core 
reviewer. But for now, his stats indicate he's not reviewing at a level 
consistent with the rest of the Neutron core reviewers.

As part of the change, I'd like to propose Doug Wiegley as a new Neutron core 
reviewer. Doug has been actively reviewing code across not only all the Neutron 
projects, but also other projects such as infra. His help and work in the 
services split in December were the reason we were so successful in making that 
happen. Doug has also been instrumental in the Neutron LBaaS V2 rollout, as 
well as helping to merge code in the other neutron service repositories.

I'd also like to take this time to remind everyone that reviewing code is a 
responsibility, in Neutron the same as other projects. And core reviewers are 
especially beholden to this responsibility. I'd also like to point out that 
+1/-1 reviews are very useful, and I encourage everyone to continue reviewing 
code even if you are not a core reviewer.

Existing neutron cores, please vote +1/-1 for the addition of Doug to the core 
team.

Thanks!
Kyle

[1] http://lists.openstack.org/pipermail/openstack-dev/2014-December/051986.html
[2] http://russellbryant.net/openstack-stats/neutron-reviewers-90.txt
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Keystone][Horizon] User self registration and management

2015-01-15 Thread Adrian Turjak
Hello David,

We are definitely assessing the option, although even switching Keystone
to be backed by an LDAP service might also work, and not be a switch to
a fully federated system. I believe Keystone has had LDAP support since
Havana, and that was an option we had looked at. It also might be a
terrible option, we don't know yet, and would still mean dealing with
LDAP directly anyway for user management.

What seems weird though with a federated Keystone system though is that
you still have to store role and group information in Keystone so that
has to be propagate through somehow, or be automated in some way still
via an external service.

We don't at present have any concrete plans, and until now a pressing
need to do so hasn't come up, although there were always plans to.

As for the VO roles blueprint, how likely is that to be merged into
master, and are there any implementations of it? I assume the VO
entities mentioned in the proposal would be in Keystone, yes?

We need a solution in the next few months (ideally sooner), but while
building a quick hack of a service along Keystone could likely be done
quickly.

Cheers,
-Adrian

On 15/01/15 21:20, David Chadwick wrote:
 Hi Adrian
 
 Morgan is right in saying that an external IdP would solve many of your
 user management problems, but then of course, you will be using
 federated keystone  which you seem reluctant to do :-) However, if you
 have an IdP under your full control then you can allow users to self
 register and reset their passwords.
 
 The next problem you will then face, is user authorisation - as opposed
 to user authentication. The VO roles blueprint that we have worked on
 addresses the authorisation problem. So when you are ready for this, let
 me know
 
 regards
 
 David
 
 On 15/01/2015 00:42, Morgan Fainberg wrote:

 On Jan 13, 2015, at 9:06 PM, Adrian Turjak adri...@catalyst.net.nz wrote:

 Hello openstack-dev,

 I'm wondering if there is any interest or need for an open-source user
 registration and management service for people using OpenStack.

 We're currently at a point where we need a way for users to sign up
 themselves, choose their own password, and request new users to be added
 to their project. There doesn't seem to be anything out there, and most
 vendors seem to have built their own systems to handle this or even
 their own dashboard systems that do.

 Horizon is built around the client tools, and your own personal token,
 so it can't handle creating new users. Plus Keystone doesn't really have
 any good way of handling temporary (unapproved) users and projects.

 The suggested approach seems to be to build a service to sit along
 Keystone, have it's own admin creds so it can create new users, and also
 store temp user data locally until the user is approved.

 Unless we can find a suitable solution for us quickly, we're likely to
 be developing such a service. It would ideally have a pluggable approval
 workflow, allowing new user requests, new project requests, creation of
 clients in external client database/ERP systems. Plus it would have a
 password reset-token system for having new users supply their password
 once they are approved, which would also allow existing users to request
 password resets.

 Part of our requirements are easy to integrate into Horizon, fitting
 neatly into the OpenStack ecosystem along other services, and being easy
 to update/alter once we have hierarchical multi-tenancy and if it makes
 some things easier.

 I've written up a proposal to help us define our requirements, and a
 copy of that is attached, and on etherpad:
 https://etherpad.openstack.org/p/User_Management_Service

 Plus I've attached a couple of diagrams, which are sadly not UML, but
 should give you some idea of two of the primary use cases.

 Is this useful to anyone? Is this entirely the wrong approach? If it is
 a useful service is there any interest in collaboration?

 Thanks for any feedback.

 Cheers,
 -Adrian Turjak

 I have an alternative recommendation (rather than using Keystone’s API and 
 user-management). Keystone’s user management is lacking a lot of features a 
 full fledged IDP (identity provider) would have. “Password reset”, “password 
 complexity”, “password reuse”, failed login locking, etc. I would recommend 
 that you implement this service to write to a full featured IDP (LDAP, 
 FreeIPA, Active Directory, etc) and have Keystone hook into that more-full 
 featured IDP. You might even find that the IDP selected has a lot of these 
 features built-in (and/or could be fronted in a horizon panel).

 This recommendation comes from past experience implementing almost exactly 
 this feature (and having it go through a number of incarnations). The 
 benefits of using a full-fledged IDP outweigh the ease of using the Keystone 
 API to manage users, especially since there is non-trivial engineering that 
 will go into the project.

 You could also utilize an IDP that can issue SAML assertions and go with a 

Re: [openstack-dev] [nova][gate][stable] How eventlet 0.16.1 broke the gate

2015-01-15 Thread Joe Gordon
On Fri, Jan 16, 2015 at 12:25 PM, Joe Gordon joe.gord...@gmail.com wrote:

 We can side step the dependency graphing and ordering issue by looking at
 the list of curently installed packages via pip freeze and not installing
 dependencies (pip install --no-deps)

 After looking into this further here are the known issues:

 * Partial capping won't work [0], so we need to pin all dependencies, we
 can generate this list per file via pip install -r and pip freeze, but
 this doesn't address the issue of apt-get vs pip install. For example in
 the stable gate we use suds 0.4.1 but only suds 0.4.0 is available via pip.
 * Not all packages are installed in are standard dsvm-tempest env, so
 using pip-freeze from that isn't enough
 * We need to run this per requirements file and move to using pip install
 --no-deps everywhere. As the global-requirements sync wouldn't work the
 first time since files don't list all transient dependencies yet.
 * We can still break if a package version is removed from pypi
 * in pip-freeze we sometimes install versions lower then our minimum
 version (python-libvirt!)


Exploring a few ideas here: https://review.openstack.org/#/c/147451/4




 [0]
 http://lists.openstack.org/pipermail/openstack-dev/2015-January/054156.html

 On Fri, Jan 16, 2015 at 5:07 AM, Jeremy Stanley fu...@yuggoth.org wrote:

 On 2015-01-15 08:44:58 -0500 (-0500), Sean Dague wrote:
 [...]
  The other thing that happened was partial capping doesn't work,
  because something else moves forward and breaks you from below. So
  the patch will need to hit everything at once.

 Right, and we _have_ to start using stable branches on all
 clients/libraries to backport fixes as part of that. This means that
 the stable branch management workflow is about to become pervasive
 across some teams who were previously (blissfully?) ignorant of it.

  Unresolved entirely is the tertiary dependencies (not direct
  dependencies of any OpenStack project). That will need another
  mechanism to seed them before any installation happens.
 [...]

 I won't go so far as to call it intractable, but I took a stab at it
 about a year ago and building the dependency graph properly to be
 able to do a depth-first ordering is nontrivial (enough that after
 about a week hacking on possible solutions I gave up and switched to
 more productive tasks). The primary complications I ran into were
 identifying setup_requires in transitive dependencies and dealing
 with platform/version-specific dependencies. That said, there's a
 very good chance that more recent improvements in setuptools, pip
 and virtualenv could make this task easier.

  That's the things I can think off from the top of my head.

 The implementation, from a devstack-gate perspective, is also going
 to require a decision on whether we stick with stable/relname for
 branches of libraries too or switch to some extended branch mapping
 mechanism to be able to track stable/relnum branches for those. And
 we're going to need more jobs to ensure that clients (specifically)
 retain backward-compatibility from an appdev and end user
 perspective since they'll no longer get any testing as server
 dependencies on stable branches (due to being capped there).
 --
 Jeremy Stanley

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



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


[openstack-dev] [Fuel] backport CI fixes for fuel-ostf stable branches

2015-01-15 Thread Aleksandra Fedorova
Hi, everyone,

to unify our CI setup for fuel-ostf repository we need to backport
fixes for run_test.sh script to all stable branches.

Sebastian created corresponding reviews:

6.0 https://review.openstack.org/147510/
5.1 https://review.openstack.org/147511/
5.0 https://review.openstack.org/147525/
4.1 https://review.openstack.org/147530/

These backports don't affect anything but the test run making it real
test run and not the empty placeholder. And with these patches merged
we will be able to use the same Jenkins job [1] for all branches.

Let's just merge them.

[1] https://review.fuel-infra.org/#/c/2035/

-- 
Aleksandra Fedorova
Fuel Devops Engineer
bookwar

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


Re: [openstack-dev] [nova][gate][stable] How eventlet 0.16.1 broke the gate

2015-01-15 Thread Sean Dague
On 01/15/2015 06:25 PM, Joe Gordon wrote:
 We can side step the dependency graphing and ordering issue by looking
 at the list of curently installed packages via pip freeze and not
 installing dependencies (pip install --no-deps)
 
 After looking into this further here are the known issues:
 
 * Partial capping won't work [0], so we need to pin all dependencies, we
 can generate this list per file via pip install -r and pip freeze,
 but this doesn't address the issue of apt-get vs pip install. For
 example in the stable gate we use suds 0.4.1 but only suds 0.4.0 is
 available via pip.
 * Not all packages are installed in are standard dsvm-tempest env, so
 using pip-freeze from that isn't enough
 * We need to run this per requirements file and move to using pip
 install --no-deps everywhere. As the global-requirements sync wouldn't
 work the first time since files don't list all transient dependencies yet.

So that's basically writing our own dependency system entirely, and
skipping pip's (vs. fudging around pip's issues). I expect that's going
to go poorly in the OpenStack ecosystem realm because a lot of very
repetitive manual analysis will need to be done on each project. And if
we want to bump a cap, regenerating all the graphs becomes another
manual process.

 * We can still break if a package version is removed from pypi
 * in pip-freeze we sometimes install versions lower then our minimum
 version (python-libvirt!)

That's because python-libvirt is not in any requirements.txt file, so
we're taking the system version.

-Sean

-- 
Sean Dague
http://dague.net

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


[openstack-dev] Resending: [nova] Request Spec Freeze Exception for: Remove direct nova DB/API access in Scheduler Filters

2015-01-15 Thread Ed Leafe
I sent this at the beginning of the exception process, but it did not appear on 
the list of exceptions mikal posted at today's nova meeting, so I'm re-sending.

 Begin forwarded message:
 
 Date: January 8, 2015 at 8:50:57 AM CST
 From: Ed Leafe e...@leafe.com
 To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org) 
 openstack-dev@lists.openstack.org
 Subject: [openstack-dev] [nova] Request Spec Freeze Exception for: Remove 
 direct nova DB/API access in Scheduler Filters
 Reply-To: OpenStack Development Mailing List \(not for usage questions\) 
 openstack-dev@lists.openstack.org
 
 Signed PGP part
 Hi,
 
 This spec [1] has been on hold, as it was largely dependent on another
 spec [2] being approved first, as it has very similar requirements.
 Now that the latter has been approved, I am moving forward with the
 former. It is part of the scheduler cleanup effort that has been
 identified as a priority for Kilo.
 
 Thanks for your consideration!
 
 [1] https://review.openstack.org/#/c/138444/
 
 [2]
 https://github.com/openstack/nova-specs/blob/master/specs/kilo/approved/isolate-scheduler-db-aggregates.rst
 
 
 -- Ed Leafe
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] reckoning time for nova ec2 stack

2015-01-15 Thread Matt Riedemann



On 1/15/2015 11:40 AM, Matt Riedemann wrote:



On 1/13/2015 9:27 PM, Matt Riedemann wrote:



On 1/13/2015 12:11 PM, Steven Hardy wrote:

On Tue, Jan 13, 2015 at 10:00:04AM -0600, Matt Riedemann wrote:

Looks like the fix we merged didn't actually fix the problem. I have
a patch
[1] to uncap the boto requirement on master and it's failing the ec2
tests
in tempest the same as before.


FWIW, I just re-tested and boto 2.35.1 works fine for me locally, if you
revert my patch it breaks again with Signature not provided errors
(for
all ec2 API requests).

If you look at the failures in the log, it actually looks like a
different
problem:

EC2ResponseError: EC2ResponseError: 401 Unauthorized

This is not the same as the original error which rejected any request
inside the nova API before even calling keystone with a message like
this:

AuthFailure: Signature not provided

AFAICT this means my patch is working, and there's a different problem
affecting only a subset of the ec2 boto tests.

Steve

__


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



Yeah, new bug reported, looks like we're hitting 401 Unauthorized errors
when trying to create security groups in the test:

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



I have a debug patch up here to try and recreate the tempest failures
with latest boto but using a nova debug change also to get more
information when we fail.

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



I finally narrowed this down to some code in keystone where it generates 
a signature and compares that to what nova is passing in on the request 
for ec2 credentials and they are different so keystone is rejecting the 
request with a 401.


http://logs.openstack.org/01/147601/3/check/check-tempest-dsvm-full/96bb05e/logs/apache/keystone.txt.gz#_2015-01-15_22_00_27_046

I'm assuming something needs to change in keystone to support the 
version 4 format?


--

Thanks,

Matt Riedemann


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


Re: [openstack-dev] [nova][gate][stable] How eventlet 0.16.1 broke the gate

2015-01-15 Thread Joe Gordon
We can side step the dependency graphing and ordering issue by looking at
the list of curently installed packages via pip freeze and not installing
dependencies (pip install --no-deps)

After looking into this further here are the known issues:

* Partial capping won't work [0], so we need to pin all dependencies, we
can generate this list per file via pip install -r and pip freeze, but
this doesn't address the issue of apt-get vs pip install. For example in
the stable gate we use suds 0.4.1 but only suds 0.4.0 is available via pip.
* Not all packages are installed in are standard dsvm-tempest env, so using
pip-freeze from that isn't enough
* We need to run this per requirements file and move to using pip install
--no-deps everywhere. As the global-requirements sync wouldn't work the
first time since files don't list all transient dependencies yet.
* We can still break if a package version is removed from pypi
* in pip-freeze we sometimes install versions lower then our minimum
version (python-libvirt!)



[0]
http://lists.openstack.org/pipermail/openstack-dev/2015-January/054156.html

On Fri, Jan 16, 2015 at 5:07 AM, Jeremy Stanley fu...@yuggoth.org wrote:

 On 2015-01-15 08:44:58 -0500 (-0500), Sean Dague wrote:
 [...]
  The other thing that happened was partial capping doesn't work,
  because something else moves forward and breaks you from below. So
  the patch will need to hit everything at once.

 Right, and we _have_ to start using stable branches on all
 clients/libraries to backport fixes as part of that. This means that
 the stable branch management workflow is about to become pervasive
 across some teams who were previously (blissfully?) ignorant of it.

  Unresolved entirely is the tertiary dependencies (not direct
  dependencies of any OpenStack project). That will need another
  mechanism to seed them before any installation happens.
 [...]

 I won't go so far as to call it intractable, but I took a stab at it
 about a year ago and building the dependency graph properly to be
 able to do a depth-first ordering is nontrivial (enough that after
 about a week hacking on possible solutions I gave up and switched to
 more productive tasks). The primary complications I ran into were
 identifying setup_requires in transitive dependencies and dealing
 with platform/version-specific dependencies. That said, there's a
 very good chance that more recent improvements in setuptools, pip
 and virtualenv could make this task easier.

  That's the things I can think off from the top of my head.

 The implementation, from a devstack-gate perspective, is also going
 to require a decision on whether we stick with stable/relname for
 branches of libraries too or switch to some extended branch mapping
 mechanism to be able to track stable/relnum branches for those. And
 we're going to need more jobs to ensure that clients (specifically)
 retain backward-compatibility from an appdev and end user
 perspective since they'll no longer get any testing as server
 dependencies on stable branches (due to being capped there).
 --
 Jeremy Stanley

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

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


Re: [openstack-dev] [neutron] Changes to the core team

2015-01-15 Thread Henry Gessau
On Thu, Jan 15, 2015, Kyle Mestery mest...@mestery.com wrote:
 As part of the change, I'd like to propose Doug Wiegley as a new Neutron core
 reviewer. Doug has been actively reviewing code across not only all the
 Neutron projects, but also other projects such as infra. His help and work in
 the services split in December were the reason we were so successful in making
 that happen. Doug has also been instrumental in the Neutron LBaaS V2 rollout,
 as well as helping to merge code in the other neutron service repositories.

+1 for Doug.


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


[openstack-dev] libvirt memory ballooning [nova]

2015-01-15 Thread Vikash Kumar
All,

   There is blueprint for enabling  libvirt memory ballooning
https://blueprints.launchpad.net/nova/+spec/libvirt-memory-ballooning in
openstack nova. I think for Hyper-V , its already in place. Can we discuss
about the design and implementation and target for L release?


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


[openstack-dev] How to debug test cases in Openstack

2015-01-15 Thread Abhishek Talwar/HYD/TCS
Hi,

I have been trying to debug the test cases in OpenStack, but I am not getting 
successful with it. So if someone can help me with that. The last response from 
the dev-list was to use  $ ./run_tests.sh -d [test module path] 
 but this gives bDb quit error.

So kindly help me this.
-- 
Thanks and Regards
Abhishek Talwar
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


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


[openstack-dev] [TEMPEST] Doubts regarding testing in OpenStack

2015-01-15 Thread Abhishek Talwar/HYD/TCS
Hi,

I am bit confused regarding the testing in OpenStack. The run_tests.sh script ( 
that is at the root of every component may it be nova,keystone etc ) , does it 
run only the unit tests covered under that component or it runs the test cases 
it tempest too (for ex scenario tests, api tests etc).

Please provide me some information regarding this. 


-- 
Thanks and Regards
Abhishek Talwar
Employee ID : 770072
Assistant System Engineer
Tata Consultancy Services,Gurgaon
India
Contact Details : +918377882003
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


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


[openstack-dev] [Fuel] [Scale] [UI] Improvements to handle 200+ nodes

2015-01-15 Thread Vitaly Kramskikh
Folks,

Currently Fuel UI can handle large amounts of nodes due to a recent
refactoring - rendering and operations with nodes became much faster. But
that large amount of nodes also requires UX improvement, I'd love to hear
your ideas and opinions on these proposals:

   1. Introduce compact node representation and let users switch between
   standart and compact view. Compact view will display only node name and
   status and will allow to display 4-8 nodes in a row instead of only one.
   2. Currently it is only possible to filter node by names. Filtering
   feature could be extended to allow filtering by other parameters: status,
   roles, manufacturer, RAM, disk space. There are 2 options (I'd like to hear
   which one you prefer):
  1. Form-based filter (beside a single input for name there will be
  controls for other parameters)
  2. Query language-based filter (like one used in Gerrit)
  3. Add ability to add arbitrary tags with values to nodes and also
   allow filtering by them.


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


Re: [openstack-dev] [Neutron][L3][Devstack] Bug during delete floating IPs?

2015-01-15 Thread Kevin Benton
We don't have asserts anywhere else. I don't think it makes sense to only
put a couple in.

On Sun, Jan 11, 2015 at 8:29 AM, Sunil Kumar su...@embrane.com wrote:

  Actually, I just noticed that a patch which has been pending review
 since Sep is not merged, and that actually fixes the root cause.

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

 Having said that, I think the code can definitely use some touching. If
 router_ids is not supposed to be None, it should be asserted (enforcing a
 contract with the plugin APIs!) instead of letting python crib about it.
 Also, the code in plugins/ml2/plugin.py should not even be call
 l3plugin.notify_routers_updated if the router_ids set is empty. I think
 assert also belongs there.

 -Sunil
 --
 *From:* Salvatore Orlando [sorla...@nicira.com]
 *Sent:* Sunday, January 11, 2015 7:25 AM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [Neutron][L3][Devstack] Bug during delete
 floating IPs?

   I think Kevin is right - the actual root cause lies in plugins for
 which disassociate_floating_ips returns None rather than an (empty)
 iterable.

  A quick check revealed that at least:
 neutron.plugins.embrane.base_plugin.EmbranePlugin

 neutron.plugions.cisco.service_plugins.cisco_router_plugin.CiscoRouterPlugin

  can return None in some circumstances.
 I reckon the plugins should be fixed.
 While Sunil's patch fixes the issue it does not make a lot of sense since
 it call notify_routers_updated with None for routers_id.
 I agree with his intention of making the ml2 plugin more robust, but in my
 opinion when router_ids is None or empty the notification method should
 probably not be called at all.

  Salvatore

 On 11 January 2015 at 12:02, Kevin Benton blak...@gmail.com wrote:

 That only seems to bury the root cause because router_ids shouldn't be
 none in this case with the reference L3 plugin.

  The ML2 plugin calls disassociate_floatingips with do_notify set to
 False so it should always be at least an empty set coming back.

  Which L3 plugin were you using? Perhaps the implementation of
 disassociate_floatingips was incorrect.

  On Sat, Jan 10, 2015 at 11:42 PM, Sunil Kumar su...@embrane.com wrote:

   This trivial patch fixes the tracebacks:

 $ cat disassociate_floating_ips.patch
 --- neutron/db/l3_db.py.orig2015-01-10 22:20:30.101506298 -0800
 +++ neutron/db/l3_db.py 2015-01-10 22:24:18.111479818 -0800
 @@ -1257,4 +1257,4 @@

  def notify_routers_updated(self, context, router_ids):
  super(L3_NAT_db_mixin, self).notify_routers_updated(
 -context, list(router_ids), 'disassociate_floatingips', {})
 +context, list(router_ids) if router_ids else None,
 'disassociate_floatingips', {})


 -Sunil
 --
 *From:* Sunil Kumar [su...@embrane.com]
 *Sent:* Saturday, January 10, 2015 7:07 PM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* [openstack-dev] [Neutron][L3][Devstack] Bug during delete
 floating IPs?

Not sure if its something seen by others. I hit this when I run
 tempest.scenario.test_network_basic_ops.TestNetworkBasicOps against master:

 2015-01-10 17:45:13.227 5350 DEBUG neutron.plugins.ml2.plugin
 [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f None] Deleting port
 e5deb014-0063-4d55-8ee3-5ba3524fee14 delete_port
 /opt/stack/new/neutron/neutron/plugins/ml2/plugin.py:995
 2015-01-10 17:45:13.228 5350 DEBUG neutron.openstack.common.lockutils
 [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f ] Created new semaphore
 db-access internal_lock
 /opt/stack/new/neutron/neutron/openstack/common/lockutils.py:206
 2015-01-10 17:45:13.228 5350 DEBUG neutron.openstack.common.lockutils
 [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f ] Acquired semaphore db-access
 lock /opt/stack/new/neutron/neutron/openstack/common/lockutils.py:229
 2015-01-10 17:45:13.252 5350 DEBUG neutron.plugins.ml2.plugin
 [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f None] Calling delete_port for
 e5deb014-0063-4d55-8ee3-5ba3524fee14 owned by network:floatingip
 delete_port /opt/stack/new/neutron/neutron/plugins/ml2/plugin.py:1043
 2015-01-10 17:45:13.254 5350 DEBUG neutron.openstack.common.lockutils
 [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f ] Releasing semaphore db-access
 lock /opt/stack/new/neutron/neutron/openstack/common/lockutils.py:238
 2015-01-10 17:45:13.282 5350 ERROR neutron.api.v2.resource
 [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f None] delete failed
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource Traceback
 (most recent call last):
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource   File
 /opt/stack/new/neutron/neutron/api/v2/resource.py, line 83, in resource
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource result =
 method(request=request, **args)
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource   File
 /opt/stack/new/neutron/neutron/api/v2/base.py, line 479, in delete
 

[openstack-dev] [Horizon] - Blueprint for Adding Version Information on the System Info Page

2015-01-15 Thread Yamini Sardana
Dear all,

I had raised a blueprint on Horizon for adding Version Information on the 
System Info Page. Its been a while and it is still in new state.

https://blueprints.launchpad.net/horizon/+spec/version-info-on-system-info-page

Please provide your thoughts on this and also if it can be implemented and 
targetted for kilo release.

Best Regards
Yamini Sardana
Tata Consultancy Services
Ground to 8th Floors, Building No. 1  2,
Skyview Corporate Park, Sector 74A,NH 8
Gurgaon - 122 004,Haryana
India
Ph:- +91 124 6213082
Mailto: yamini.sard...@tcs.com
Website: http://www.tcs.com

Experience certainty.   IT Services
Business Solutions
Consulting

=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


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


[openstack-dev] [nova][qa][pci] Intel PCI CI , testing method/env and test cases

2015-01-15 Thread yongli he

Hi, all

Intel PCI CI use  hardware machine to testing PCI,  there are some 
change to devstack, tempest

use Jerkins  dispatch task.

basic information:
* the topology:
log server ---  Jenkins server  node pool
* use devstack deploy testing env.

PCI CI 's  main problem is how to know pci information and how configure 
nova/tempest:
 1)  the test cases should know the  machine's  pci device 
information ( to checking the allocated pci does passed to vm)
 2)  how Jerkins  deliver these pci information  to 
nova/devstack/tempest


how Intel CI solve these problem:
  1)  Q:how the test cases know the allocated machine's  pci device 
information :
   A: each node might have different HW for PCI, different 
number of PCI devices so there is a configure file

   for each node storing the node's pci information.

   * test node local config file:
 pci.conf
pci_info=name:PCI_network_card,vendor_id:8086,product_id:1520,count:20; ...

   2) Q:  how Jekins  deliver pci information  to nova/devstack/tempest
A: Jekins  allocated a node for a pach set, then sent a 
scripts to :

*  configure the devstack
 then,  devstack configure the nova pci 
pci_passthrough_whitelist and alias
* exporting a env var storing the pci_info for tempest pci 
test cases ( this  need improve, of course)
  now the test case know everything to create  VM with PCI 
devices.


  What changed to devstack/tempest:
* devstack
   adding  insert_pci  to  devstack/functions-common
* tempest
adding linux utils to get pci device information from vm
adding routines to create pci flavor
https://github.com/intel-hw-ci/Intel-Openstack-Hardware-CI/blob/master/pci_tempest_patch/0001-Add-Intel-PCI-functions.patch

* test cases
https://github.com/intel-hw-ci/Intel-Openstack-Hardware-CI/tree/master/pci_testcases

What can be improvement and what is common( maybe into devstack/tempest)?
   * tempest use env variable  deliver information to tempest cases 
need improve, may be a config option
   * the pci information could be simplify by use interface name 
instead of  vendor_id/product_id

   * init_pci might be valuable to devstack
   * test cases:
   landing the test cases to nova function testing (pending):
 https://review.openstack.org/#/c/141270/
   trying put  some improved test case to tempest(rejected):
https://review.openstack.org/#/c/139000/

Regards
Yongli h...@intel.com

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


Re: [openstack-dev] [nova][ThirdPartyCI][PCI] Intel Third party Hardware based CI for PCI

2015-01-15 Thread yongli he

在 2015年01月13日 03:12, Kurt Taylor 写道:
The public link for your test logs should really be a host name 
instead of an IP address. That way if you have to change it again in 
the future, you won't have dead links in old comments. You may already 
know, but all of the requirements and recommendations are here: 
http://git.openstack.org/cgit/openstack-infra/system-config/tree/doc/source/third_party.rst

thanks very much, we does considering change to a dns name.

Yongli He


Kurt Taylor (krtaylor)

On Sun, Jan 11, 2015 at 11:18 PM, yongli he yongli...@intel.com 
mailto:yongli...@intel.com wrote:


在 2015年01月08日 10:31, yongli he 写道:
to make a more stable service we upgrade the networking device, 
then the log server address change to a new

IP address:  198.175.100.33

so  the sample log change to(replace the 192.55.68.190 to new
address):


http://198.175.100.33/143614/6/
http://198.175.100.33/139900/4
http://198.175.100.33/143372/3/
http://198.175.100.33/141995/6/
http://198.175.100.33/137715/13/
http://198.175.100.33/133269/14/

Yongli He



Hi,

Intel  set up a Hardware based Third Part CI.   it's already 
running sets of PCI test cases

for several  weeks (do not sent out comments, just log the result)
the log server and these test cases seems fairly stable now.   to
begin given comments  to nova
repository,  what other necessary work need to be address?

Details:
1. ThirdPartySystems
https://wiki.openstack.org/wiki/ThirdPartySystems Information
https://wiki.openstack.org/wiki/ThirdPartySystems/Intel-PCI-CI

2. a sample logs:
http://192.55.68.190/138795/6/

3. Test cases on github:

https://github.com/intel-hw-ci/Intel-Openstack-Hardware-CI/tree/master/pci_testcases



Thanks
Yongli He




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




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


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


Re: [openstack-dev] [neutron] Changes to the core team

2015-01-15 Thread Salvatore Orlando
I agree with the proposed changes.

I would also like to take a chance to thank Sumit for the effort he has put
in this project over several years - he has been in the core team since the
project's inception and has been a witness of all its developments - both
the good and the bad ones!

Salvatore

On 16 January 2015 at 04:38, Henry Gessau ges...@cisco.com wrote:

 On Thu, Jan 15, 2015, Kyle Mestery mest...@mestery.com wrote:
  As part of the change, I'd like to propose Doug Wiegley as a new Neutron
 core
  reviewer. Doug has been actively reviewing code across not only all the
  Neutron projects, but also other projects such as infra. His help and
 work in
  the services split in December were the reason we were so successful in
 making
  that happen. Doug has also been instrumental in the Neutron LBaaS V2
 rollout,
  as well as helping to merge code in the other neutron service
 repositories.

 +1 for Doug.


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

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


Re: [openstack-dev] [qa] Doubts regarding testing in OpenStack

2015-01-15 Thread Salvatore Orlando
You are right.

run_tests.sh simply runs unit tests which cover tempest's code itself.

In order to run the tests for the various OpenStack services, use tox.
In tox.ini there are several environments defined which run different sets
of tests.
When all you want to do is run just a specific test module or test case, it
is possible to use the 'all' environment. For instance, to run only
scenarios I usually do:

tox -eall -- tempest.scenario

Hope this helps,
Salvatore


On 16 January 2015 at 05:48, Abhishek Talwar/HYD/TCS 
abhishek.tal...@tcs.com wrote:

 Hi,

 I am bit confused regarding the testing in OpenStack. The run_tests.sh
 script ( that is at the root of every component may it be nova,keystone etc
 ) , does it run only the unit tests covered under that component or it runs
 the test cases it tempest too (for ex scenario tests, api tests etc).

 Please provide me some information regarding this.


 --
 Thanks and Regards
 Abhishek Talwar
 Employee ID : 770072
 Assistant System Engineer
 Tata Consultancy Services,Gurgaon
 India
 Contact Details : +918377882003

 =-=-=
 Notice: The information contained in this e-mail
 message and/or attachments to it may contain
 confidential or privileged information. If you are
 not the intended recipient, any dissemination, use,
 review, distribution, printing or copying of the
 information contained in this e-mail message
 and/or attachments to it are strictly prohibited. If
 you have received this communication in error,
 please notify us by reply e-mail or telephone and
 immediately and permanently delete the message
 and any attachments. Thank you


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


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


Re: [openstack-dev] [qa] Doubts regarding testing in OpenStack

2015-01-15 Thread Abhishek Talwar/HYD/TCS
Hi, 

Thanks a lot. I have some more doubts if you can please clear them too.



Q1. How can we debug
test cases in OpenStack ? (We can debug the code through import pdb
but the same doesn't work for test cases and we have a bdb quit
error)
Q2. Suppose I need
to add a test case in the tempest suite how can I do that ? Q3. Whenever we run 
run_tests.sh script where does it first hit and how does the tests cases start 
running ?Q4. As it is said
that tempest interacts only with the OpenStack Rest Api's , then how
are the test cases for the various clients run, by clients here I
mean the python-novaclient,keystoneclient etc. 




- Original Message -
From: Salvatore Orlando sorla...@nicira.com
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Sent: Fri, 16 Jan 2015 12:42:57 +0530 (IST)
Subject: Re: [openstack-dev] [qa] Doubts regarding testing in OpenStack

You are right.
run_tests.sh simply runs unit tests which cover tempest's code itself.
In order to run the tests for the various OpenStack services, use tox.In 
tox.ini there are several environments defined which run different sets of 
tests.When all you want to do is run just a specific test module or test case, 
it is possible to use the 'all' environment. For instance, to run only 
scenarios I usually do:
tox -eall -- tempest.scenario
Hope this helps,Salvatore


On 16 January 2015 at 05:48, Abhishek Talwar/HYD/TCS abhishek.tal...@tcs.com 
wrote:
Hi,

I am bit confused regarding the testing in OpenStack. The run_tests.sh script ( 
that is at the root of every component may it be nova,keystone etc ) , does it 
run only the unit tests covered under that component or it runs the test cases 
it tempest too (for ex scenario tests, api tests etc).

Please provide me some information regarding this. 


-- 
Thanks and Regards
Abhishek Talwar
Employee ID : 770072
Assistant System Engineer
Tata Consultancy Services,Gurgaon
India
Contact Details : +918377882003=-=-=

Notice: The information contained in this e-mail

message and/or attachments to it may contain 

confidential or privileged information. If you are 

not the intended recipient, any dissemination, use, 

review, distribution, printing or copying of the 

information contained in this e-mail message 

and/or attachments to it are strictly prohibited. If 

you have received this communication in error, 

please notify us by reply e-mail or telephone and 

immediately and permanently delete the message 

and any attachments. Thank you
__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Thanks and Regards
Abhishek Talwar
Employee ID : 770072
Assistant System Engineer
Tata Consultancy Services,Gurgaon
India
Contact Details : +918377882003__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [MagnetoDB] TTL feature for a row

2015-01-15 Thread Ajaya Agrawal
Hi guys,

I am referring to the blueprint:
https://blueprints.launchpad.net/magnetodb/+spec/row-expiration . We want
to provide our end users with ttl feature on a row in MagnetoDB.

As it stands today in cassandra, ttl is on a column basis rather than a row
basis. i.e. when you insert a row with an insert statement the ttl is
applied on all the columns. But when you update a row and use ttl there ttl
for only the columns present in SET clause of UPDATE statement.

for e.g if you have a USER table with schema (name text primary key, age
int) and you insert a row with statement INSERT INTO USER(name, age) values
('a', 1) and later update this with UPDATE USER USING TTL 10 set age=2
where name='a', then the age column will get updated and only the age
column will disappear after 10 seconds.


   - So in MagnetoDB if a user inserts data without ttl and later updates
   the same row with ttl and some updated column values then ttl is only
   applied on the updated columns. We should do an insert in this case to make
   the whole row disappear. Simlarly if the user inserts the data with a ttl
   but updates the data without ttl then we should fetch the ttl for the row
   and then update the row with remaining ttl for the row.
   - The same problem remains with the conditional update But it's more
   difficult to tackle without any locking mechanism.

The simplest solution is to allow ttl only in insert statement and let the
users know about this.

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


Re: [openstack-dev] [neutron] Changes to the core team

2015-01-15 Thread Armando M.
+1

On 15 January 2015 at 14:46, Edgar Magana edgar.mag...@workday.com wrote:

  +1 For adding Doug as Core in Neutron!

  I have seen his work on the services part and he is a great member of
 the OpenStack community!

  Edgar

   From: Kyle Mestery mest...@mestery.com
 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: Thursday, January 15, 2015 at 2:31 PM
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Subject: [openstack-dev] [neutron] Changes to the core team

The last time we looked at core reviewer stats was in December [1]. In
 looking at the current stats, I'm going to propose some changes to the core
 team. Reviews are the most important part of being a core reviewer, so we
 need to ensure cores are doing reviews. The stats for the 90 day period [2]
 indicate some changes are needed for core reviewers who are no longer
 reviewing on pace with the other core reviewers.

  First of all, I'm removing Sumit Naiksatam from neutron-core. Sumit has
 been a core reviewer for a long time, and his past contributions are very
 much thanked by the entire OpenStack Neutron team. If Sumit jumps back in
 with thoughtful reviews in the future, we can look at getting him back as a
 Neutron core reviewer. But for now, his stats indicate he's not reviewing
 at a level consistent with the rest of the Neutron core reviewers.

  As part of the change, I'd like to propose Doug Wiegley as a new Neutron
 core reviewer. Doug has been actively reviewing code across not only all
 the Neutron projects, but also other projects such as infra. His help and
 work in the services split in December were the reason we were so
 successful in making that happen. Doug has also been instrumental in the
 Neutron LBaaS V2 rollout, as well as helping to merge code in the other
 neutron service repositories.

 I'd also like to take this time to remind everyone that reviewing code is
 a responsibility, in Neutron the same as other projects. And core reviewers
 are especially beholden to this responsibility. I'd also like to point out
 that +1/-1 reviews are very useful, and I encourage everyone to continue
 reviewing code even if you are not a core reviewer.

 Existing neutron cores, please vote +1/-1 for the addition of Doug to the
 core team.

 Thanks!
 Kyle

 [1]
 http://lists.openstack.org/pipermail/openstack-dev/2014-December/051986.html
 [2] http://russellbryant.net/openstack-stats/neutron-reviewers-90.txt

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


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


[openstack-dev] [Murano][Heat][Mistral] Use and adoption of YAQL

2015-01-15 Thread Dmitri Zimine
Folks, 

We use YAQL in Mistral for referencing variables, expressing conditions, etc. 
Murano is using it extensively, I saw Heat folks thought of using it, at least 
once :) May be others...

We are learning that YAQL incredibly powerful comparing to alternatives like 
Jinja2 templates used  in salt / ansible. 

But with lack of documentation, it becomes one of adoption blockers to Mistral 
(we got very vocal user feedback on this).

This is pretty much all the docs I can offer our users on YAQL so far. Not 
much. 
http://yaql.readthedocs.org/en/latest/
https://github.com/ativelkov/yaql/blob/master/README.rst
https://murano.readthedocs.org/en/latest/murano_pl/murano_pl.html#yaql

Are there any plans to fix it? 

Are there interest from other projects to use YAQL? 

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


Re: [openstack-dev] [Fuel] Empty role - status

2015-01-15 Thread Andrew Woodward
On Thu, Jan 15, 2015 at 3:11 AM, Andrey Danin ada...@mirantis.com wrote:
 Answers inline.

 On Thu, Jan 15, 2015 at 1:21 AM, Evgeniy L e...@mirantis.com wrote:

 Hi,

 Empty role is ready [1], thanks to granular deployment feature
 I didn't have to hardcode some hacks in Astute again.

 But there are several things which I want to mention/discuss:

 1. in the patch you can see the name of the role and its description
 I would like to ask you to verify it and provide some other options if
 you
 have any
 2. we have a minor problem with the progress bar, we will figure out how
 to fix it in Astute with Vladimir S.
 3. and the biggest problem is an old bug [2], the bug is Ubuntu specific
 and it
 doesn't allow us to make efficient partitioning schema, e.g. it means
 that we
 cannot allocate root partition for all of the disks (provisioning will
 fail), the
 current workaround is to allocate root partition with minimal size
 (about 15G) and leave the rest of the space as is (unallocated). As
 far as I can see from the bug it's not so easy to fix the problem,
 actually
 image based provisioning fixes the problem, but it's not an option for
 the
 current release. Maybe you have some other ideas how to fix this
 problem?

 I would leave it as is - 15 GB. A user or plugin can adjust it for its
 needs.

Seriously? NO the 15G Min / Max 50G min for the OS allocation is too
small for a default value and not using the rest of the disk. While
the user may easily change this (by the way, most users don't they
expect better allocations), how do you expect the plugin-dev to deal
with this? The way this seams to push the plugin-dev is to do it
pre-deployment via code. We know already working with the disk
allocation is very painful, why are we pushing them to 'duplicate'
code. We need proper support of dynamically adding roles so they can
re-use our code

Is [2] the correct bug for the ubuntu OS volume issue? It's clearly
talking about small root disk values being wrong for all real
deployments.

I'll try to look for the proper bug w/regards to ubuntu OS, but the
gist is the limitation is that the OS volume can not span multiple
disks. The whole-disk allocator we use for ceph-osd should be proper
to work around this problem in a way.


 Thanks,

 [1] https://review.openstack.org/#/c/147230/
 [2] https://bugs.launchpad.net/fuel/+bug/1278964

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




 --
 Andrey Danin
 ada...@mirantis.com
 skype: gcon.monolake

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




-- 
Andrew
Mirantis
Ceph community

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


Re: [openstack-dev] [Openstack-operators] The state of nova-network to neutron migration

2015-01-15 Thread Anita Kuno
On 01/16/2015 09:19 AM, Kris G. Lindgren wrote:
 Is the fact that neutron security groups don’t provide the same level of 
 isolation as nova security groups on your guys radar?
 
 Specifically talking about:  https://bugs.launchpad.net/neutron/+bug/1274034
 
 I am sure their are a few other thigns that nova is doing that neutron is 
 currently not.
 
 
 Kris Lindgren
 Senior Linux Systems Engineer
 GoDaddy, LLC.
Can I convince you to attend the weekly nova-net to neutron migration
meeting and ensure that it is?

Thanks Kris,
Anita.
 
 From: matt m...@nycresistor.commailto:m...@nycresistor.com
 Date: Thursday, January 15, 2015 at 1:10 PM
 To: Anita Kuno ante...@anteaya.infomailto:ante...@anteaya.info
 Cc: Angus Lees gusl...@gmail.commailto:gusl...@gmail.com, OpenStack 
 Development Mailing List 
 openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org,
  
 openstack-operat...@lists.openstack.orgmailto:openstack-operat...@lists.openstack.org
  
 openstack-operat...@lists.openstack.orgmailto:openstack-operat...@lists.openstack.org
 Subject: Re: [Openstack-operators] The state of nova-network to neutron 
 migration
 
 Will do.
 
 On Thu, Jan 15, 2015 at 12:08 PM, Anita Kuno 
 ante...@anteaya.infomailto:ante...@anteaya.info wrote:
 On 01/14/2015 01:06 PM, matt wrote:
 Hey Mike!

 Thanks for this info.  Super helpful to me at least.  I am very interested
 in hearing more about nova-network to neutron migrations.

 -Matt

 Hello Matt:
 
 Please start attending the weekly meetings:
 https://wiki.openstack.org/wiki/Meetings/Nova-nettoNeutronMigration
 follow the logs from it:
 http://eavesdrop.openstack.org/meetings/nova_net_to_neutron_migration/
 as well as the logs for the neutron weekly meeting:
 http://eavesdrop.openstack.org/meetings/networking/
 and the nova weekly meeting:
 http://eavesdrop.openstack.org/meetings/nova/
 
 After you have had a chance to update yourself, please ask any questions
 either at one of the above meetings or do email me.
 
 Thank you Matt,
 Anita.
 
 On Tue, Jan 13, 2015 at 1:53 PM, Michael Still 
 mi...@stillhq.commailto:mi...@stillhq.com wrote:

 Hi, I just wanted to make sure people know that a small group of us
 got together in a hallway at linux.conf.auhttp://linux.conf.au 2015 to 
 talk about this. It
 wasn't an attempt to exclude anyone, we just all happened to be in the
 same place at the same time.

 To that end, we made some notes from the chat, which are at
 https://etherpad.openstack.org/p/nova-network-migration-lca2015 .
 Specific points to note are that Angus Lees has volunteered to help
 Oleg with the spec for this, and that we'd very much like to see a
 discussion of this at the Nova midcycle meetup in a couple of weeks.

 I'd also like to call out that there's a link to the mailing list
 thread where we discussed CERN's concerns in the etherpad for
 reference as well.

 Cheers,
 Michael

 On Sat, Dec 20, 2014 at 3:59 AM, Anita Kuno 
 ante...@anteaya.infomailto:ante...@anteaya.info wrote:
 Rather than waste your time making excuses let me state where we are and
 where I would like to get to, also sharing my thoughts about how you can
 get involved if you want to see this happen as badly as I have been told
 you do.

 Where we are:
 * a great deal of foundation work has been accomplished to achieve
 parity with nova-network and neutron to the extent that those involved
 are ready for migration plans to be formulated and be put in place
 * a summit session happened with notes and intentions[0]
 * people took responsibility and promptly got swamped with other
 responsibilities
 * spec deadlines arose and in neutron's case have passed
 * currently a neutron spec [1] is a work in progress (and it needs
 significant work still) and a nova spec is required and doesn't have a
 first draft or a champion

 Where I would like to get to:
 * I need people in addition to Oleg Bondarev to be available to help
 come up with ideas and words to describe them to create the specs in a
 very short amount of time (Oleg is doing great work and is a fabulous
 person, yay Oleg, he just can't do this alone)
 * specifically I need a contact on the nova side of this complex
 problem, similar to Oleg on the neutron side
 * we need to have a way for people involved with this effort to find
 each other, talk to each other and track progress
 * we need to have representation at both nova and neutron weekly
 meetings to communicate status and needs

 We are at K-2 and our current status is insufficient to expect this work
 will be accomplished by the end of K-3. I will be championing this work,
 in whatever state, so at least it doesn't fall off the map. If you would
 like to help this effort please get in contact. I will be thinking of
 ways to further this work and will be communicating to those who
 identify as affected by these decisions in the most effective methods of
 which I am capable.

 Thank 

Re: [openstack-dev] [Glance] IRC logging

2015-01-15 Thread Geoff O'Callaghan
On 13/01/2015 3:45 AM, Jeremy Stanley fu...@yuggoth.org wrote:

 There's really no way to _force_ official logging on all
 project-related channels. People who are opposed to the idea simply
 move their conversations to new channels. They'll straddle the line
 between somewhat official looking and official enough to require
 logging.

Yeah while this is true you can certainly work to achieve this goal and if
there are side conversations that aren't logged then so be it.

Irc logs can be a very valuable resource.

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


Re: [openstack-dev] Resend: [nova] Request Spec Freeze Exception for Enhance iSCSI multipath/failover support

2015-01-15 Thread Michael Still
Done.

Cheers,
Michael

On Fri, Jan 16, 2015 at 11:37 AM, Tomoki Sekiyama
tomoki.sekiy...@hds.com wrote:
 Michael,



 These wasn't on the list of of exceptions at today's nova meeting. Please
 add them.

 On 1/8/15, 11:48 , Tomoki Sekiyama tomoki.sekiy...@hds.com wrote:
Hi,

I have submitted 2 nova-specs [1][2] related to Cinder volumes iSCSI
multipath/failover improvement.

These specs are both for enabling Cinder to pass multiple iSCSI paths to
Nova. [1] is for multipath use-case, where Nova will establish iSCSI
sessions to all the given paths. [2] is for failover use-case, where Nova
will try to establish alternative path when it fails to establish main
path.

These specs were blocked to wait for corresponding cinder-specs approval
[3][4], which are now approved. Please consider these specs for spec
freeze exception.

nova-specs:
[1] https://review.openstack.org/#/c/134299/
[2] https://review.openstack.org/#/c/137468/

cinder-specs:
[3] https://review.openstack.org/#/c/136500/
[4] https://review.openstack.org/#/c/131502/


 Regards,
 Tomoki Sekiyama


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



-- 
Rackspace Australia

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


Re: [openstack-dev] Running tox on Centos 6.5 with Python26

2015-01-15 Thread Joe Gordon
On Fri, Jan 16, 2015 at 12:13 PM, John Warren jswar...@linux.vnet.ibm.com
wrote:


 Can someone tell me or point me to documentation about what the required
 yum and pip packages are to be able to run tox for glance, keystone,
 neutron, cinder and nova on Centos 6.5 with Python 2.6?  I looked at the
 openstack-infra/puppet-jenkins project and thought I installed everything
 in the slave.pp manifest, which presumably is sufficient to be able to run
 tox for all openstack projects, but when I try to run tox on nova (tox
 --recreate -epy26) I just get an error that indicates that no test cases
 were found.


trunk OpenStack services (nova, neutron, keystone, cinder etc.)  no longer
support python 26

http://lists.openstack.org/pipermail/openstack-dev/2014-November/051551.html
https://review.openstack.org/#/c/128736/



 Any help would be greatly appreciated.

 John


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

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


Re: [openstack-dev] About DVR limit

2015-01-15 Thread joehuang
Hi, Swami,

The use case for central south-north mode: 1) All compute nodes not connecting 
to external network directly 2) FIP/SNAT/VPN function  will be done centrally 
on hardware router.

New questions about “We were even initially planning to distribute the SNAT”

Do you mean: 1) Dynamic routing will be implemented before that, 2 ) Full 
distributed SNAT or only provide multi-SNAT network nodes

Best Regards
Chaoyi Huang ( Joe Huang )


From: Vasudevan, Swaminathan (PNB Roseville) 
[mailto:swaminathan.vasude...@hp.com]
Sent: Friday, January 16, 2015 12:56 AM
To: joehuang; 龚永生
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: RE: Re:RE: [openstack-dev] About DVR limit

Hi Joehuang,
Thanks for your input and description of the problem.
What you are stating is just have DVR functionality for East-West traffic and 
all North-South traffic should go through the Centralized Router.
The North-South distributed reduces the burden in the Centralized Node. We 
eventually need to get away from the centralized node model.
I am not sure why there would be a use case to go back to the centralized model.

We were even initially planning to distribute the SNAT, but we just left it 
there centralized just to support the legacy services such as VPN.
Once we have service insertion and service chaining then we can distribute the 
SNAT functionality.

If you have a use case and willing to work on it and contribute code upstream, 
please let me know.

Thanks
Swami

From: joehuang [mailto:joehu...@huawei.com]
Sent: Wednesday, January 14, 2015 7:07 PM
To: 龚永生; Vasudevan, Swaminathan (PNB Roseville)
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: RE: Re:RE: [openstack-dev] About DVR limit

Hello,

Yongseng, correct, your description is much more concise, we need a 
configuration:

east-west, DVR
south-north, legacy mode.

Best Regards
Chaoyi Huang ( Joe Huang )

From: 龚永生 [mailto:gong.yongsh...@99cloud.net]
Sent: Thursday, January 15, 2015 10:18 AM
To: Vasudevan, Swaminathan (PNB Roseville)
Cc: joehuang; OpenStack Development Mailing List (not for usage questions)
Subject: Re:RE: [openstack-dev] About DVR limit


Hi, Swami, Joehuang,
in dvr compute nodes, it is 1:1 NAT FIP, means the floatingip for VM, and  it 
is in the namespace of qrouter-.
but in dvr_snat node, it is 1:N NAT IP, it is for neutron router, and for the 
VMs which have no 1:1 FIP, implemented in namesapce snat-xxx.

Joehuang's case can be implemented in legacy mode, I.E. non DVR,
but for the east-west traffic, we should consider the DVR, So I think there is 
a case:
east-west, DVR
south-north, legacy mode.


Thanks
yong sheng gong


在 2015-01-14 13:40:32,Vasudevan, Swaminathan (PNB Roseville) 
swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.com 写道:
Hi Joehuang,
FIP today as of Juno can be both in centralized node (dvr_snat) and distributed 
“dvr” compute nodes.
Thanks
Swami

From: joehuang [mailto:joehu...@huawei.commailto:joehu...@huawei.com]
Sent: Tuesday, January 13, 2015 7:49 PM
To: OpenStack Development Mailing List (not for usage questions); 龚永生
Cc: Vasudevan, Swaminathan (PNB Roseville)
Subject: RE: [openstack-dev] About DVR limit

Hi, Swami,

I would like to know whether the FIP under DVR could be configured to 
distributed mode or central mode in Kilo, not find relevant information from 
http://specs.openstack.org/openstack/neutron-specs/.

For example, it will be helpful for following FIP use cases: 1) FIP will be 
addressed centrally by dedicated hardware 2) not all compute nodes have public 
address.

Best Regards
Chaoyi Huang ( Joe Huang )

From: Stamina than Valued an [mailto:souminat...@yahoo.com]
Sent: Wednesday, January 14, 2015 11:05 AM
To: 龚永生
Cc: swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.com; 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] About DVR limit

Hi yong Zheng,
Yes your understanding is right.
We only support ovs driver.
Regarding HA and multi network support, it will be available in kilo.

Public address consumption for north south traffic for compute node is also 
true. But to address this issue we do have a proposal that is worked out by the 
l3 sub team.

I hope this clarifies your doubts.

Please let me know if I can help you with anything else.

Thanks
Swami

Sent from my iPad

On Jan 13, 2015, at 6:01 PM, 龚永生 
gong.yongsh...@99cloud.netmailto:gong.yongsh...@99cloud.net wrote:
Hi,
 I am yong sheng gong, I want to know if the DVR has these limits besides the 
documented at http://docs.openstack.org/networking-guide/content/ha-dvr.html:

1. one subnet can be connected to DVR router only once, which is confirmed by 
BP https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr-multigateway
2. one network cannot have more than one subnet connecting to DVR routers


So the DVR limits the neutron model to:
one network has just one subnet, and one subnet cannot connect to more than one 

Re: [openstack-dev] [horizon] static files handling, bower/

2015-01-15 Thread Tihomir Trifonov
All we need is to have someone spend some time to make it possible to have
a common meta files(configs, package descriptions, etc.) so that they can
be interchangeable and used by both Bower and pip, e.g. some tool to sync
changes made in one config and adding it to another. Then - whoever prefers
Bower - will use Bower, that's mostly for development, and whoever prefers
pip - will use pip. Ideally, it seems fine to have the static files into
separate git repo(s), as it is now in XStatic.

I'll try to make an (incomplete or maybe not so correct) list of the stages
a static file goes through:

1. Development - all we need is versions of uncompressed js and css files.
We can

On Thu, Jan 15, 2015 at 12:05 AM, david.co...@oracle.com wrote:

 I won't stop to comment on this statement other than to say Javascript is
 quite relevant to Oracle, Oracle's customers, and Oracle's partners.

 Your argument is a boondoggle. Refusing to use node because your favorite
 platform doesn't support it is not the fault of node.js, it's the fault of
 the platform.


 Not to belabor the thread, but yes, of course JavaScript is very
 relevant to Oracle, Solaris, our customers/partners, etc. And that
 includes both client and server-side. As Drew stated, as of this moment
 we haven't yet made Node.js available on SPARC but I expect that to
 change in the future. But the question or potential concern remains as
 to whether adding a non-Python/pip build dependency makes sense.

 I'm not particularly well-versed in the Horizon build process so
 perhaps I'm way off base. But given that a distribution's Horizon build
 package embeds various JavaScript libraries to be used by the browser,
 how those libraries are obtained during the build process is an
 interesting build detail. I thought the intent of the XStatic work was
 to provide Python wrappers around the various JavaScript libraries so
 they could be pulled down via pip. Since there's already a Python
 requirements.txt file for versioning information, that seemed to be a
 nice way of indicating which versions of the JavaScript libraries could
 be used by Horizon and Python was used all the way through the build.

 I realize that it takes work to build the XStatic packages but given
 the Python packages are basically wrappers, it seems creating those and
 uploading them to pypi could be automated by using Bower and setup.py
 but perhaps translating the metadata isn't straightforward.


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




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


Re: [openstack-dev] [horizon] static files handling, bower/

2015-01-15 Thread Tihomir Trifonov
Ops, sent the prev mail before finishing it...

1. Development - all we need is versions of uncompressed js and css files.
We can use bower or pip requirements to get specific versions.
2. Testing - we need to do first some 'uglify'-ing tasks, using pyscss or
grunt and to run tests on that. Is is possible to have both configurations
for grunt and pyscss ?
3. Packaging - again - 'uglifyng' some scripts and css to make packages
contain ready for production static files.


This seems like quite work to prepare the whole environment, but will it
work for the needs we have?


On Thu, Jan 15, 2015 at 10:12 AM, Tihomir Trifonov t.trifo...@gmail.com
wrote:

 All we need is to have someone spend some time to make it possible to have
 a common meta files(configs, package descriptions, etc.) so that they can
 be interchangeable and used by both Bower and pip, e.g. some tool to sync
 changes made in one config and adding it to another. Then - whoever prefers
 Bower - will use Bower, that's mostly for development, and whoever prefers
 pip - will use pip. Ideally, it seems fine to have the static files into
 separate git repo(s), as it is now in XStatic.

 I'll try to make an (incomplete or maybe not so correct) list of the
 stages a static file goes through:

 1. Development - all we need is versions of uncompressed js and css files.
 We can

 On Thu, Jan 15, 2015 at 12:05 AM, david.co...@oracle.com wrote:

 I won't stop to comment on this statement other than to say Javascript is
 quite relevant to Oracle, Oracle's customers, and Oracle's partners.

 Your argument is a boondoggle. Refusing to use node because your favorite
 platform doesn't support it is not the fault of node.js, it's the fault
 of
 the platform.


 Not to belabor the thread, but yes, of course JavaScript is very
 relevant to Oracle, Solaris, our customers/partners, etc. And that
 includes both client and server-side. As Drew stated, as of this moment
 we haven't yet made Node.js available on SPARC but I expect that to
 change in the future. But the question or potential concern remains as
 to whether adding a non-Python/pip build dependency makes sense.

 I'm not particularly well-versed in the Horizon build process so
 perhaps I'm way off base. But given that a distribution's Horizon build
 package embeds various JavaScript libraries to be used by the browser,
 how those libraries are obtained during the build process is an
 interesting build detail. I thought the intent of the XStatic work was
 to provide Python wrappers around the various JavaScript libraries so
 they could be pulled down via pip. Since there's already a Python
 requirements.txt file for versioning information, that seemed to be a
 nice way of indicating which versions of the JavaScript libraries could
 be used by Horizon and Python was used all the way through the build.

 I realize that it takes work to build the XStatic packages but given
 the Python packages are basically wrappers, it seems creating those and
 uploading them to pypi could be automated by using Bower and setup.py
 but perhaps translating the metadata isn't straightforward.


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




 --
 Regards,
 Tihomir Trifonov




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


Re: [openstack-dev] [glance] Replication on image create

2015-01-15 Thread Flavio Percoco

On 14/01/15 05:46 -0700, Boden Russell wrote:



On 1/14/15 1:38 AM, Flavio Percoco wrote:

On 13/01/15 21:24 -0500, Jay Pipes wrote:

On 01/13/2015 04:55 PM, Boden Russell wrote:

Looking for some feedback from the glance dev team on a potential BP…


This is the solution that I would recommend. Frankly, this kind of
replication should be an async out-of-band process similar to
bittorrent. Just have bittorrent or rsync or whatever replicate the
image bits to a set of target locations and then call the
glanceclient.v2.client.images.add_location() method:

https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v2/images.py#L211


to add the URI of the replicated image bits.


It recently landed in Glance an async workers engine (?) that allows
for this kind of things to exists. For instance, it'll be used for
image introspection to extract information from images after they have
been *imported* into glance.

The right hooks that trigger this async workers maybe need to be
defined better but the infrastructure is there. Once that's more
solid, you'll be able to write your own plugin that will do that job
on every glance image import.



While I understand the motivation for suggesting the out of band
approach (async workers or separate process), my major concern here is
the additional processing required. In my particular scenario this would
require the out of band process to pull the image bits back down from
the remote location and then push them back up to the replication
locations. If the image size is decent, this could be a fairly expensive
operation. Moreover an out of band process (IMO) would make for a less
than optimal user experience as users would have to query the image
locations metadata to understand if the image has replicated yet.
Perhaps async workers improves this user experience a bit (can query
worker status), but it still seems cleaner (IMO) to have the replication
happen in-line with the image create flow.


That's one valid point of view, yes. However, you could also see it
this way. While should a user wait for the image to be available in
the three locations before he/she can use the image? The point of
replicating it - afaict based on what you said - is to have it
redundant and accessible from locations that are closer to some users.
If you make this part of the image creation process, you'd need to
wait until the images are fully replicated before you can actually use
it (which is not nice for users). If you instead use async workers,
you can make the image available as soon as one of the locations is
ready to serve the image.

As far as the transfering bits problem goes, the best way to avoid it
is to upload the bits offline (assuming you're using stores like http,
which doesn't have support for internal replication) and then add
locations to an image. This way, you'd have to upload the image bits N
times, where N is the number of replicast you want, instead of N+1
times, which includes the upload to one if the glance nodes.

I'm not saying the above is the ultimate solution and that glance
won't ever support this. However, it's worht noting that such
solutions are not considered bad practice whatsoever.

All that being said, it'd be very nice if you could open a spec on
this topic so we can discuss over the spec review and one of us (or
you) can implement it if we reach consensus.

Cheers,
Flavio





In a prototype I implemented #1 which can be done with no impact outside
of the store driver code itself.


I'm not entirely sure how you did that considering the http storage
backend is readonly. Are you saying you implemented the add() method
for the glance_store._drivers.http.Store class?


I was trying to generalize my use case to other glance store drivers,
but my generalization using the http store driver was obviously a poor
choice... My interest and PoC is based on the VMware datastore driver.


Let me ask more directly -- if we wanted to enhance the VMware datastore
driver to support replication (as I described in approach #1 of my
initial email) is this something the community would consider (assume
changes are contained to the VMware datastore driver), or would such an
enhancement be an uphill battle to get reviewed / merged?


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


--
@flaper87
Flavio Percoco


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


Re: [openstack-dev] [nova][gate][stable] How eventlet 0.16.1 broke the gate

2015-01-15 Thread ZhiQiang Fan
+1

how about the deep dependency? for example, we depends package A, and pin
it, but A-B-C, then B and C are not pined since they are not directly
depended, then what should we do? pin everything?

On Thu, Jan 15, 2015 at 5:35 PM, Joe Gordon joe.gord...@gmail.com wrote:

 Eventlet released 0.16.1 on 2015-01-14 [0], which removed a deprecated
 API that nova stable/* still used. This caused nova-compute in stable/juno
 and stable/icehouse to crash thus breaking grenade on master. In 24 hours
 this bug caused 671 grenade jobs to fail[1]!

 After some quick debugging of this cryptic error suppressing stacktrace
 [2] we got to the real stacktrace:
  File nova/virt/libvirt/__init__.py, line 15, in module

 from nova.virt.libvirt import driver
   File nova/virt/libvirt/driver.py, line 48, in module
 from eventlet import util as eventlet_util

 ImportError: cannot import name util [3]
 and capped the eventlet version on stable/* [4]

 As dependency bugs go this was a pretty typical one, so why am I writing
 this? Because we knew about this bug before it hit the gate, yet it was
 still an issue. The util module was removed in 0.16.0 but 'sneaked into'
 the build [5] so 0.16.1 fixed that. Before 0.16.1 was released this bug
 only impacted people who installed eventlet 0.16.0 from source and not from
 pip. Luckily someone did this and filed a bug [6] and a fix for this was
 landed on master on January 7th, and by the 10th the fix was backported to
 stable/juno and ready [7].  In the mean time, we had an unusually bad week
 dealing with new library versions; boto 2.35.0 was released and broke
 master and stable/juno [8] and sqlalchemy-migrate broke glance on master
 and stable as well [9].  And by the time these issues were fixed, and the
 tests would pass, eventlet 0.16.1 was already out. Unfortunately, there are
 a very small number of people who work on fixing dependency issues, some of
 them were traveling and the rest were over worked, so figuring out what
 went wrong with all the new packages came down to a handful of overworked
 people.

 So how could we have avoided this problem? By capping stable branch
 requirements so we only have to worry about uncapped dependencies on
 master. Capping stable branches has been previous discussed but no action
 has been taken. So going forward I propose we pin all requirements,
 including transitive, on stable branches. This way the release of new
 dependencies cannot automatically break stable branches and thus break
 grenade on master.

 I think we can implement this using `pip freeze` to get a list of all the
 installed libraries and `pip install -r --no-deps` to install the specific
 package versions.  I am not sure how best to handle package versions being
 removed from pypi though. Or at the very least we can cap requirements in
 global requirements and at least reduce the number of packages we install
 uncapped versions of.

 Thoughts?

 best,
 Joe

 [0] https://pypi.python.org/pypi/eventlet/0.16.1
 [1] http://status.openstack.org/elastic-recheck/#1410626
 [2]
 http://logs.openstack.org/98/115998/59/check/check-grenade-dsvm/e57eb40/logs/old/screen-n-cpu.txt.gz
 [3] http://paste.openstack.org/show/157558/
 [4]
 https://review.openstack.org/#/q/I4bbbeb5bf9c22ed36f5c9a74fec6b487d2c15697,n,z
 [5] https://github.com/eventlet/eventlet/releases/tag/v0.16.1
 [6] https://bugs.launchpad.net/nova/+bug/1407685
 [7]
 https://review.openstack.org/#/q/Idbb9d2b53829dae0e807cd1260dee3dce155d5f3,n,z
 [8] https://bugs.launchpad.net/nova/+bug/1408987
 [9] https://bugs.launchpad.net/glance/+bug/1410494

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




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


Re: [openstack-dev] [Fuel] Empty role - status

2015-01-15 Thread Andrey Danin
Answers inline.

On Thu, Jan 15, 2015 at 1:21 AM, Evgeniy L e...@mirantis.com wrote:

 Hi,

 Empty role is ready [1], thanks to granular deployment feature
 I didn't have to hardcode some hacks in Astute again.

 But there are several things which I want to mention/discuss:

 1. in the patch you can see the name of the role and its description
 I would like to ask you to verify it and provide some other options if
 you
 have any
 2. we have a minor problem with the progress bar, we will figure out how
 to fix it in Astute with Vladimir S.
 3. and the biggest problem is an old bug [2], the bug is Ubuntu specific
 and it
 doesn't allow us to make efficient partitioning schema, e.g. it means
 that we
 cannot allocate root partition for all of the disks (provisioning will
 fail), the
 current workaround is to allocate root partition with minimal size
 (about 15G) and leave the rest of the space as is (unallocated). As
 far as I can see from the bug it's not so easy to fix the problem,
 actually
 image based provisioning fixes the problem, but it's not an option for
 the
 current release. Maybe you have some other ideas how to fix this
 problem?

 I would leave it as is - 15 GB. A user or plugin can adjust it for its
needs.


 Thanks,

 [1] https://review.openstack.org/#/c/147230/
 [2] https://bugs.launchpad.net/fuel/+bug/1278964

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




-- 
Andrey Danin
ada...@mirantis.com
skype: gcon.monolake
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Fuel]When will fuel support centos 7?

2015-01-15 Thread me,apporc
Hi,

Do we have plan for centos 7 ?



Regards,

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


Re: [openstack-dev] [nova][gate][stable] How eventlet 0.16.1 broke the gate

2015-01-15 Thread Nikola Đipanov
On 01/15/2015 10:35 AM, Joe Gordon wrote:

 So how could we have avoided this problem? By capping stable branch
 requirements so we only have to worry about uncapped dependencies on
 master. Capping stable branches has been previous discussed but no
 action has been taken. So going forward I propose we pin all
 requirements, including transitive, on stable branches. This way the
 release of new dependencies cannot automatically break stable branches
 and thus break grenade on master.
 

This is an absolute must IMHO, including transitive dependencies,
because if they are not capped - they can cause other issues like bring
in additional deps a stable release is not even supposed to have, among
all the usual issues.

The problem as I understand it is that this breaks how we do upgrades
testing in the gate, AKA the granade job (all in a single VM, install
everything from pip). IMHO this is broken and needs to be fixed ASAP, if
capping breaks it.

N.


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


[openstack-dev] MagnetoDB kilo-1 milestone release

2015-01-15 Thread Ilya Sviridov
Hello openstackers,

MagnetoDB team is happy to announce the release of kilo-1 milestone [1]

This milestone we focused on operability and monitoring aspects of
MagnetoDB.

* Backup/Restore API has been introduced
* Monitoring API has been introduced and implemented for Cassandra
* The API URI format has been changed to split logically different
functionality and simplify deployment
* Updated documentation [2]

The bunch of bags have been fixed [1].

Thanks everyone for making it possible!

With best regards,
Ilya Sviridov

[1] https://launchpad.net/magnetodb/kilo/kilo-1
[2] https://magnetodb.readthedocs.org/en/2015.1.0b1/






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


Re: [openstack-dev] [horizon] static files handling, bower/

2015-01-15 Thread Radomir Dopieralski
On 14/01/15 23:05, david.co...@oracle.com wrote:
 I'm not particularly well-versed in the Horizon build process so
 perhaps I'm way off base. But given that a distribution's Horizon build
 package embeds various JavaScript libraries to be used by the browser,
 how those libraries are obtained during the build process is an
 interesting build detail. I thought the intent of the XStatic work was
 to provide Python wrappers around the various JavaScript libraries so
 they could be pulled down via pip. Since there's already a Python
 requirements.txt file for versioning information, that seemed to be a
 nice way of indicating which versions of the JavaScript libraries could
 be used by Horizon and Python was used all the way through the build.
 
 I realize that it takes work to build the XStatic packages but given
 the Python packages are basically wrappers, it seems creating those and
 uploading them to pypi could be automated by using Bower and setup.py
 but perhaps translating the metadata isn't straightforward.

This has actually been discussed. The problem is, that it adds
considerable complexity and some amount of work, while solves exactly
zero problems. You are just sweeping the node.js dependency under the
rug, because now, instead of being a direct dependency (for development)
of Horizon, it becomes a dependency (for building) of a package that
Horizon is dependent on. That doesn't solve anything, since all
distributions insist on building their own packages from sources, not
relying on pre-built binaries.

So what we settled on is a compromise. Horizon will not care *how* the
static files got there. Whether you put them there by hand, use Bower,
or install your distribution's packages -- Horizon doesn't care. And
neither do the tests written for Horizon, or the build scripts. They
just assume the files are where you configured them. Period. Let me
repeat that:

***You will not need Node.js or Bower to build and test Horizon.***

The packagers for different distributions will want to make packages for
the JavaScript and CSS libraries on their own anyways, and they will
want to test Horizon with those -- not with what Bower installs.

The only place where you will need Bower (but only for convenience, as
you may as well install everything manually or with your own scripts) is
the development machine. For convenience, we will keep the list of
dependencies in a format compatible with Bower -- but it's a simple JSON
file that can be read by any other tool or script, written in any language.

I hope that clears it.

-- 
Radomir Dopieralski

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


[openstack-dev] Concerns about Gnocchi's performance

2015-01-15 Thread 张灿
Hello,

I’m testing gnocchi to work with ceilometer these days and I have some concerns 
about its performance.

I noticed in the code, every time a measure gets updated, gnocchi first reads 
all the previous contents of that measure, updates the measure in memory and 
writes the updated contents as well as original contents back. IMHO, the 
overhead here could be very large. As an improvement, I propose we use some 
form of `seek` that only modifies the updated parts.

So I’d like to hear about your opinions, and if there’s already a solution, 
please point it to me.



Regards,
Can Zhang


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Concerns about Gnocchi's performance

2015-01-15 Thread Julien Danjou
On Thu, Jan 15 2015, 张灿 wrote:

Hi,

 I noticed in the code, every time a measure gets updated, gnocchi first reads
 all the previous contents of that measure, updates the measure in memory and
 writes the updated contents as well as original contents back. IMHO, the
 overhead here could be very large. As an improvement, I propose we use some
 form of `seek` that only modifies the updated parts.

Yep, that's the main downside of the use of the Carbonara based backend
in Gnocchi. But honestly, since it's download/upload are parallel and
the file size is quite small, sending a metric should be pretty fast in
most circumstances. Though that's sure it's gonna be faster with
backends where you just have to send the actual metrics (OpenTSDB or
InfluxDB likely).

 So I’d like to hear about your opinions, and if there’s already a
 solution, please point it to me.

I'd love to improve the backends you describe with some sort of `seek'
solution, unfortunately I don't think it'll be possible to do so using
Swift. Though it might be possible to do so using Ceph and the file
based backends, so maybe it'd be worth looking at that. Any help
appreciated!

-- 
Julien Danjou
# Free Software hacker
# http://julien.danjou.info


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


Re: [openstack-dev] Concerns about Gnocchi's performance

2015-01-15 Thread 张灿

 On Jan 15, 2015, at 18:46, Julien Danjou jul...@danjou.info wrote:
 
 Yep, that's the main downside of the use of the Carbonara based backend
 in Gnocchi. But honestly, since it's download/upload are parallel and
 the file size is quite small, sending a metric should be pretty fast in
 most circumstances. Though that's sure it's gonna be faster with
 backends where you just have to send the actual metrics (OpenTSDB or
 InfluxDB likely).
 

As a further question, how do you estimate the storage impact of a vm 
instance’s metrics? I’m not very sure about the `back_window` and `definition` 
part, could you clarify that for me?




Regards,
Can Zhang


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [nova][gate][stable] How eventlet 0.16.1 broke the gate

2015-01-15 Thread Joe Gordon
Eventlet released 0.16.1 on 2015-01-14 [0], which removed a deprecated API
that nova stable/* still used. This caused nova-compute in stable/juno and
stable/icehouse to crash thus breaking grenade on master. In 24 hours this
bug caused 671 grenade jobs to fail[1]!

After some quick debugging of this cryptic error suppressing stacktrace [2]
we got to the real stacktrace:
 File nova/virt/libvirt/__init__.py, line 15, in module

from nova.virt.libvirt import driver
  File nova/virt/libvirt/driver.py, line 48, in module
from eventlet import util as eventlet_util

ImportError: cannot import name util [3]
and capped the eventlet version on stable/* [4]

As dependency bugs go this was a pretty typical one, so why am I writing
this? Because we knew about this bug before it hit the gate, yet it was
still an issue. The util module was removed in 0.16.0 but 'sneaked into'
the build [5] so 0.16.1 fixed that. Before 0.16.1 was released this bug
only impacted people who installed eventlet 0.16.0 from source and not from
pip. Luckily someone did this and filed a bug [6] and a fix for this was
landed on master on January 7th, and by the 10th the fix was backported to
stable/juno and ready [7].  In the mean time, we had an unusually bad week
dealing with new library versions; boto 2.35.0 was released and broke
master and stable/juno [8] and sqlalchemy-migrate broke glance on master
and stable as well [9].  And by the time these issues were fixed, and the
tests would pass, eventlet 0.16.1 was already out. Unfortunately, there are
a very small number of people who work on fixing dependency issues, some of
them were traveling and the rest were over worked, so figuring out what
went wrong with all the new packages came down to a handful of overworked
people.

So how could we have avoided this problem? By capping stable branch
requirements so we only have to worry about uncapped dependencies on
master. Capping stable branches has been previous discussed but no action
has been taken. So going forward I propose we pin all requirements,
including transitive, on stable branches. This way the release of new
dependencies cannot automatically break stable branches and thus break
grenade on master.

I think we can implement this using `pip freeze` to get a list of all the
installed libraries and `pip install -r --no-deps` to install the specific
package versions.  I am not sure how best to handle package versions being
removed from pypi though. Or at the very least we can cap requirements in
global requirements and at least reduce the number of packages we install
uncapped versions of.

Thoughts?

best,
Joe

[0] https://pypi.python.org/pypi/eventlet/0.16.1
[1] http://status.openstack.org/elastic-recheck/#1410626
[2]
http://logs.openstack.org/98/115998/59/check/check-grenade-dsvm/e57eb40/logs/old/screen-n-cpu.txt.gz
[3] http://paste.openstack.org/show/157558/
[4]
https://review.openstack.org/#/q/I4bbbeb5bf9c22ed36f5c9a74fec6b487d2c15697,n,z
[5] https://github.com/eventlet/eventlet/releases/tag/v0.16.1
[6] https://bugs.launchpad.net/nova/+bug/1407685
[7]
https://review.openstack.org/#/q/Idbb9d2b53829dae0e807cd1260dee3dce155d5f3,n,z
[8] https://bugs.launchpad.net/nova/+bug/1408987
[9] https://bugs.launchpad.net/glance/+bug/1410494
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Openstack] Openstack Havana installation using devstack

2015-01-15 Thread Sean Dague
The stable/havana branch of devstack was deleted when the stable/havana
branches of the projects were end of lifed.

Even if you could reconstruct it, it wouldn't work, because various
dependencies would have upgraded to incompatible versions.

stable/icehouse is the oldest version of OpenStack that devstack supports.

On 01/15/2015 07:36 AM, abhishek jain wrote:
 I'm also facing the same trouble.
 
 On Jan 15, 2015 12:05 PM, masoom alam masoom.a...@gmail.com
 mailto:masoom.a...@gmail.com wrote:
 
 No 
 
 I want Havana purposefully. 
 
 Thanks
 
 On Thu, Jan 15, 2015 at 10:45 AM, iKhan ik.ibadk...@gmail.com
 mailto:ik.ibadk...@gmail.com wrote:
 
 Go with stable/icehouse then.
 
 On Thu Jan 15 2015 at 11:13:37 AM masoom alam
 masoom.a...@gmail.com mailto:masoom.a...@gmail.com wrote:
 
 Hi every one, 
 
 How can I install Openstack Havana using devstack. 
 
 The problem is that Havana branch does not exist on Github. 
 
 git clone https://github.com/openstack-dev/devstack.git -b
 stable/havana
 
 Please guide. 
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 OpenStack-dev-request@lists.__openstack.org?subject:__unsubscribe
 
 http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 
 http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 ___
 Mailing list:
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
 Post to : openst...@lists.openstack.org
 mailto:openst...@lists.openstack.org
 Unsubscribe :
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


-- 
Sean Dague
http://dague.net

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


Re: [openstack-dev] [Openstack] Openstack Havana installation using devstack

2015-01-15 Thread Ihar Hrachyshka

On 01/15/2015 01:42 PM, Sean Dague wrote:

The stable/havana branch of devstack was deleted when the stable/havana
branches of the projects were end of lifed.


That said, tag is still there: 
http://git.openstack.org/cgit/openstack-dev/devstack/tag/?id=havana-eol


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


Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI

2015-01-15 Thread Amit Das
Hi Eduard,

Can you put the logs or details for below comment:

it seems that sometimes Zuul gets stuck (sometimes in Looking for lost
 builds, sometimes doing nothing) and it misses notifications.


I guess, we too have been facing the same issue with Zuul.


Regards,
Amit
*CloudByte Inc.* http://www.cloudbyte.com/

On Thu, Jan 15, 2015 at 6:29 PM, Eduard Matei 
eduard.ma...@cloudfounders.com wrote:

 Hi,
 Just so i don't start another thread: it seems that sometimes Zuul gets
 stuck (sometimes in Looking for lost builds, sometimes doing nothing) and
 it misses notifications.
 I added a Jenkins timer job to restart it every 30 minutes. Is there a fix
 for this or something to change in config?

 Thanks,
 Eduard

 On Thu, Jan 15, 2015 at 2:56 PM, Eduard Matei 
 eduard.ma...@cloudfounders.com wrote:

 Hi Ramy,

 The issue with disconnect/abort no longer happens, so i guess it was some
 issues with networking.

 Regarding the ssh keys i finally used Jenkins Configuration Provider
 Plugin to inject ssh keys as a pre-build step, then i added a manual
 execution step to scp the logs to the server, so now everything appears to
 be working.

 Now for the REAL tests:
 looking at
 https://github.com/rasselin/os-ext-testing-data/blob/master/etc/jenkins_jobs/config/dsvm-cinder-driver.yaml.sample#L7
 it seems i need to put the code to install my third party libs in the
 pre_test_hook which appears in devstack-vm-gate-wrap.sh to be executing
 BEFORE installing devstack. The problem is we need our third party libs
 to be installed (actually configured) AFTER installing devstack, since they
 install on top of devstack and do some configuration on devstack.

 How could i integrate my code into devstack-vm-gate-wrap.sh so that my
 libs are installed after devstack but before running tempest.
 Also, as a side question, do i need to run all the test (since they
 already run in dsvm-tempest-full) or can i run only our internal
 functionality tests? (in this case i don't need devstack-vm-gate-wrap.sh
 and i can run custom code directly from jenkins job).

 Thanks,

 Eduard

 On Wed, Jan 14, 2015 at 6:49 PM, Asselin, Ramy ramy.asse...@hp.com
 wrote:

  Double check your ssh public/private key, authorized keys
 configuration in the slave  log server.

 They should all match up. No passwords should be requested.

 Try doing a manual scp as Jenkins user from the slave to the log server
 (as Jenkins user there too).



 Regarding manually setting up the publisher, I don’t know. Jenkins Job
 Builder configuration I referenced below should work correctly.



 Ramy



 *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
 *Sent:* Wednesday, January 14, 2015 6:56 AM

 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need
 help setting up CI



 Hi Ramy,



 I think i managed to setup SCP plugin and updated zuul.conf but it only
 uploads the console.html not the logs

 I have an SCP site pointing to the apache server and the root location
 is /srv/static, and in the dsvm job manually added a post-build step,
 Publish Artifacts to SCP Repository, with source: logs/** and destination
 logs/${LOG_PATH} and also checked Copy Console Log.



 The destination path is created, but it only contains console.html.



 I tried to manually scp the directory, but the jenkins user in the
 devstack_slave asks for a password when trying to ssh to apache server.



 Thanks,

 Eduard



 On Wed, Jan 14, 2015 at 10:40 AM, Eduard Matei 
 eduard.ma...@cloudfounders.com wrote:

  Thanks Ramy, i'll try to set it up manually.



 Meanwhile i found another problem: jobs are failing because of error or
 are being aborted.

 FATAL: java.io.IOException: Unexpected termination of the channel

 hudson.remoting.RequestAbortedException 
 http://stacktrace.jenkins-ci.org/search?query=hudson.remoting.RequestAbortedException:
  java.io.IOException: Unexpected termination of the channel



 Is this related to another warning i got:

 WARNING: devstack run took  15 minutes, this is a very slow node.



 Is there a timeout for how long a job is allowed to run?

 Most jobs take between 40 and 60 minutes, some are able to run 
 successfully, some are aborted or get this error.



 Hardware is Xeon E3-1220 Quad core 3.10 Ghz, 32 GB RAM and 3x 1TB sata HDD.

 Devstack slaves are configured as m1.large (4 vCPUs, 8 GB vRAM and 80 GB 
 vHDD).



 Thanks,

 Eduard



 On Tue, Jan 13, 2015 at 5:34 PM, Asselin, Ramy ramy.asse...@hp.com
 wrote:

  Hi Eduard,



 Apache logs server address is set here (should probably add some
 comment/doc for that)


 https://github.com/rasselin/os-ext-testing-data/blob/master/vars.sh.sample#L10



 Jenkins will get configured here:
 https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/templates/jenkins/be.certipost.hudson.plugin.SCPRepositoryPublisher.xml.erb

 Note that you need to restart Jenkins for those changes to take 

Re: [openstack-dev] [Fuel]When will fuel support centos 7?

2015-01-15 Thread Mike Scherbakov
CentOS 7 is not considered as essential / critical priority blueprint for
Fuel 6.1. There is a plan to support new version of CentOS, and I know some
folks started a research/move in this direction in some areas, such as
l23network puppet module for instance.

It would be great to see help to make it happen in Fuel 7.0, if not in 6.1.

On Thu, Jan 15, 2015 at 3:22 PM, Igor Kalnitsky ikalnit...@mirantis.com
wrote:

 Hi,

 Yes, we do have a plan for CentOS 7, but as far as I know it was
 postponed to MOS 7.0. That means we will not have Cent OS 7 in
 upcoming release.

 - Igor

 On Thu, Jan 15, 2015 at 1:16 PM, me,apporc appleorchard2...@gmail.com
 wrote:
  Hi,
 
  Do we have plan for centos 7 ?
 
 
 
  Regards,
 
  apporc
 
 
 
 __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

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




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


Re: [openstack-dev] [nova][gate][stable] How eventlet 0.16.1 broke the gate

2015-01-15 Thread Sean Dague
On 01/15/2015 05:21 AM, Nikola Đipanov wrote:
 On 01/15/2015 10:35 AM, Joe Gordon wrote:
 
 So how could we have avoided this problem? By capping stable branch
 requirements so we only have to worry about uncapped dependencies on
 master. Capping stable branches has been previous discussed but no
 action has been taken. So going forward I propose we pin all
 requirements, including transitive, on stable branches. This way the
 release of new dependencies cannot automatically break stable branches
 and thus break grenade on master.

 
 This is an absolute must IMHO, including transitive dependencies,
 because if they are not capped - they can cause other issues like bring
 in additional deps a stable release is not even supposed to have, among
 all the usual issues.
 
 The problem as I understand it is that this breaks how we do upgrades
 testing in the gate, AKA the granade job (all in a single VM, install
 everything from pip). IMHO this is broken and needs to be fixed ASAP, if
 capping breaks it.

That's a mis understanding of the last issue, grenade handles this fine.

The capping only caused a problem because we were upgrading components
in an incorrect issue: Swift upgrading before Ceilometer, even though
Ceilometer had middleware installed in Swift. Which meant that for
almost ever we were actually running new Swift with old Ceilometer
middleware.

That was fixed here - https://review.openstack.org/#/c/142075/

The policy decision to cap stable requirements was agreed to previously
(and at summit this year), it just needs someone to implement. This also
came up in this keystoneclient thread from last week -
http://lists.openstack.org/pipermail/openstack-dev/2015-January/054156.html

Volunteers welcomed.

-Sean

-- 
Sean Dague
http://dague.net

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


Re: [openstack-dev] [Fuel]When will fuel support centos 7?

2015-01-15 Thread Igor Kalnitsky
Hi,

Yes, we do have a plan for CentOS 7, but as far as I know it was
postponed to MOS 7.0. That means we will not have Cent OS 7 in
upcoming release.

- Igor

On Thu, Jan 15, 2015 at 1:16 PM, me,apporc appleorchard2...@gmail.com wrote:
 Hi,

 Do we have plan for centos 7 ?



 Regards,

 apporc


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


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


Re: [openstack-dev] [Openstack] Openstack Havana installation using devstack

2015-01-15 Thread abhishek jain
I'm also facing the same trouble.
On Jan 15, 2015 12:05 PM, masoom alam masoom.a...@gmail.com wrote:

 No

 I want Havana purposefully.

 Thanks

 On Thu, Jan 15, 2015 at 10:45 AM, iKhan ik.ibadk...@gmail.com wrote:

 Go with stable/icehouse then.

 On Thu Jan 15 2015 at 11:13:37 AM masoom alam masoom.a...@gmail.com
 wrote:

 Hi every one,

 How can I install Openstack Havana using devstack.

 The problem is that Havana branch does not exist on Github.

 git clone https://github.com/openstack-dev/devstack.git -b stable/havana

 Please guide.


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


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



 ___
 Mailing list:
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
 Post to : openst...@lists.openstack.org
 Unsubscribe :
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


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


Re: [openstack-dev] [Openstack] Openstack Havana installation using devstack

2015-01-15 Thread Denis Makogon
On Thu, Jan 15, 2015 at 2:36 PM, abhishek jain ashujain9...@gmail.com
wrote:

 I'm also facing the same trouble.
 On Jan 15, 2015 12:05 PM, masoom alam masoom.a...@gmail.com wrote:

 No

 I want Havana purposefully.

 Thanks

 On Thu, Jan 15, 2015 at 10:45 AM, iKhan ik.ibadk...@gmail.com wrote:

 Go with stable/icehouse then.

 On Thu Jan 15 2015 at 11:13:37 AM masoom alam masoom.a...@gmail.com
 wrote:

 Hi every one,

 How can I install Openstack Havana using devstack.

 The problem is that Havana branch does not exist on Github.

 git clone https://github.com/openstack-dev/devstack.git -b
 stable/havana

 Please guide.



Github is not what you might relay on. Feel free to use git.o.o
http://git.openstack.org/cgit/openstack-dev/devstack/



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



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



 ___
 Mailing list:
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
 Post to : openst...@lists.openstack.org
 Unsubscribe :
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


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



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


Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI

2015-01-15 Thread Eduard Matei
Hi Ramy,

The issue with disconnect/abort no longer happens, so i guess it was some
issues with networking.

Regarding the ssh keys i finally used Jenkins Configuration Provider Plugin
to inject ssh keys as a pre-build step, then i added a manual execution
step to scp the logs to the server, so now everything appears to be working.

Now for the REAL tests:
looking at
https://github.com/rasselin/os-ext-testing-data/blob/master/etc/jenkins_jobs/config/dsvm-cinder-driver.yaml.sample#L7
it seems i need to put the code to install my third party libs in the
pre_test_hook which appears in devstack-vm-gate-wrap.sh to be executing
BEFORE installing devstack. The problem is we need our third party libs
to be installed (actually configured) AFTER installing devstack, since they
install on top of devstack and do some configuration on devstack.

How could i integrate my code into devstack-vm-gate-wrap.sh so that my libs
are installed after devstack but before running tempest.
Also, as a side question, do i need to run all the test (since they already
run in dsvm-tempest-full) or can i run only our internal functionality
tests? (in this case i don't need devstack-vm-gate-wrap.sh and i can run
custom code directly from jenkins job).

Thanks,

Eduard

On Wed, Jan 14, 2015 at 6:49 PM, Asselin, Ramy ramy.asse...@hp.com wrote:

  Double check your ssh public/private key, authorized keys configuration
 in the slave  log server.

 They should all match up. No passwords should be requested.

 Try doing a manual scp as Jenkins user from the slave to the log server
 (as Jenkins user there too).



 Regarding manually setting up the publisher, I don’t know. Jenkins Job
 Builder configuration I referenced below should work correctly.



 Ramy



 *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
 *Sent:* Wednesday, January 14, 2015 6:56 AM

 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help
 setting up CI



 Hi Ramy,



 I think i managed to setup SCP plugin and updated zuul.conf but it only
 uploads the console.html not the logs

 I have an SCP site pointing to the apache server and the root location is
 /srv/static, and in the dsvm job manually added a post-build step, Publish
 Artifacts to SCP Repository, with source: logs/** and destination
 logs/${LOG_PATH} and also checked Copy Console Log.



 The destination path is created, but it only contains console.html.



 I tried to manually scp the directory, but the jenkins user in the
 devstack_slave asks for a password when trying to ssh to apache server.



 Thanks,

 Eduard



 On Wed, Jan 14, 2015 at 10:40 AM, Eduard Matei 
 eduard.ma...@cloudfounders.com wrote:

  Thanks Ramy, i'll try to set it up manually.



 Meanwhile i found another problem: jobs are failing because of error or
 are being aborted.

 FATAL: java.io.IOException: Unexpected termination of the channel

 hudson.remoting.RequestAbortedException 
 http://stacktrace.jenkins-ci.org/search?query=hudson.remoting.RequestAbortedException:
  java.io.IOException: Unexpected termination of the channel



 Is this related to another warning i got:

 WARNING: devstack run took  15 minutes, this is a very slow node.



 Is there a timeout for how long a job is allowed to run?

 Most jobs take between 40 and 60 minutes, some are able to run successfully, 
 some are aborted or get this error.



 Hardware is Xeon E3-1220 Quad core 3.10 Ghz, 32 GB RAM and 3x 1TB sata HDD.

 Devstack slaves are configured as m1.large (4 vCPUs, 8 GB vRAM and 80 GB 
 vHDD).



 Thanks,

 Eduard



 On Tue, Jan 13, 2015 at 5:34 PM, Asselin, Ramy ramy.asse...@hp.com
 wrote:

  Hi Eduard,



 Apache logs server address is set here (should probably add some
 comment/doc for that)


 https://github.com/rasselin/os-ext-testing-data/blob/master/vars.sh.sample#L10



 Jenkins will get configured here:
 https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/templates/jenkins/be.certipost.hudson.plugin.SCPRepositoryPublisher.xml.erb

 Note that you need to restart Jenkins for those changes to take effect.
 After it’s set, you can use the Jenkins UI to ‘test’ the connection.



 Jenkins Job Builder publishers are here:
 https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/templates/jenkins_job_builder/config/macros.yaml.erb#L110



 Use the publishers as shown here:


 https://github.com/rasselin/os-ext-testing-data/blob/master/etc/jenkins_jobs/config/dsvm-cinder-driver.yaml.sample#L7



 Zuul will then use this url when commenting in gerrit:
 https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/manifests/master.pp#L18





 Ramy



 *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
 *Sent:* Tuesday, January 13, 2015 2:31 AM


 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [OpenStack-Infra] 

Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI

2015-01-15 Thread Eduard Matei
Hi,
Just so i don't start another thread: it seems that sometimes Zuul gets
stuck (sometimes in Looking for lost builds, sometimes doing nothing) and
it misses notifications.
I added a Jenkins timer job to restart it every 30 minutes. Is there a fix
for this or something to change in config?

Thanks,
Eduard

On Thu, Jan 15, 2015 at 2:56 PM, Eduard Matei 
eduard.ma...@cloudfounders.com wrote:

 Hi Ramy,

 The issue with disconnect/abort no longer happens, so i guess it was some
 issues with networking.

 Regarding the ssh keys i finally used Jenkins Configuration Provider
 Plugin to inject ssh keys as a pre-build step, then i added a manual
 execution step to scp the logs to the server, so now everything appears to
 be working.

 Now for the REAL tests:
 looking at
 https://github.com/rasselin/os-ext-testing-data/blob/master/etc/jenkins_jobs/config/dsvm-cinder-driver.yaml.sample#L7
 it seems i need to put the code to install my third party libs in the
 pre_test_hook which appears in devstack-vm-gate-wrap.sh to be executing
 BEFORE installing devstack. The problem is we need our third party libs
 to be installed (actually configured) AFTER installing devstack, since they
 install on top of devstack and do some configuration on devstack.

 How could i integrate my code into devstack-vm-gate-wrap.sh so that my
 libs are installed after devstack but before running tempest.
 Also, as a side question, do i need to run all the test (since they
 already run in dsvm-tempest-full) or can i run only our internal
 functionality tests? (in this case i don't need devstack-vm-gate-wrap.sh
 and i can run custom code directly from jenkins job).

 Thanks,

 Eduard

 On Wed, Jan 14, 2015 at 6:49 PM, Asselin, Ramy ramy.asse...@hp.com
 wrote:

  Double check your ssh public/private key, authorized keys configuration
 in the slave  log server.

 They should all match up. No passwords should be requested.

 Try doing a manual scp as Jenkins user from the slave to the log server
 (as Jenkins user there too).



 Regarding manually setting up the publisher, I don’t know. Jenkins Job
 Builder configuration I referenced below should work correctly.



 Ramy



 *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
 *Sent:* Wednesday, January 14, 2015 6:56 AM

 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need
 help setting up CI



 Hi Ramy,



 I think i managed to setup SCP plugin and updated zuul.conf but it only
 uploads the console.html not the logs

 I have an SCP site pointing to the apache server and the root location is
 /srv/static, and in the dsvm job manually added a post-build step, Publish
 Artifacts to SCP Repository, with source: logs/** and destination
 logs/${LOG_PATH} and also checked Copy Console Log.



 The destination path is created, but it only contains console.html.



 I tried to manually scp the directory, but the jenkins user in the
 devstack_slave asks for a password when trying to ssh to apache server.



 Thanks,

 Eduard



 On Wed, Jan 14, 2015 at 10:40 AM, Eduard Matei 
 eduard.ma...@cloudfounders.com wrote:

  Thanks Ramy, i'll try to set it up manually.



 Meanwhile i found another problem: jobs are failing because of error or
 are being aborted.

 FATAL: java.io.IOException: Unexpected termination of the channel

 hudson.remoting.RequestAbortedException 
 http://stacktrace.jenkins-ci.org/search?query=hudson.remoting.RequestAbortedException:
  java.io.IOException: Unexpected termination of the channel



 Is this related to another warning i got:

 WARNING: devstack run took  15 minutes, this is a very slow node.



 Is there a timeout for how long a job is allowed to run?

 Most jobs take between 40 and 60 minutes, some are able to run successfully, 
 some are aborted or get this error.



 Hardware is Xeon E3-1220 Quad core 3.10 Ghz, 32 GB RAM and 3x 1TB sata HDD.

 Devstack slaves are configured as m1.large (4 vCPUs, 8 GB vRAM and 80 GB 
 vHDD).



 Thanks,

 Eduard



 On Tue, Jan 13, 2015 at 5:34 PM, Asselin, Ramy ramy.asse...@hp.com
 wrote:

  Hi Eduard,



 Apache logs server address is set here (should probably add some
 comment/doc for that)


 https://github.com/rasselin/os-ext-testing-data/blob/master/vars.sh.sample#L10



 Jenkins will get configured here:
 https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/templates/jenkins/be.certipost.hudson.plugin.SCPRepositoryPublisher.xml.erb

 Note that you need to restart Jenkins for those changes to take effect.
 After it’s set, you can use the Jenkins UI to ‘test’ the connection.



 Jenkins Job Builder publishers are here:
 https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/templates/jenkins_job_builder/config/macros.yaml.erb#L110



 Use the publishers as shown here:


 

Re: [openstack-dev] Concerns about Gnocchi's performance

2015-01-15 Thread Julien Danjou
On Thu, Jan 15 2015, 张灿 wrote:

 As a further question, how do you estimate the storage impact of a vm
 instance’s metrics? I’m not very sure about the `back_window` and `definition`
 part, could you clarify that for me?

That defines the number of measure (data points) that are stored for
each metric. The size of an actual metric depends on these parameters.
So depending on the granularity and the number of points, the size of a
metric can go from a few kilobytes to a few megabytes.

-- 
Julien Danjou
-- Free Software hacker
-- http://julien.danjou.info


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


Re: [openstack-dev] [nova][gate][stable] How eventlet 0.16.1 broke the gate

2015-01-15 Thread Sean Dague
On 01/15/2015 08:38 AM, Thierry Carrez wrote:
 Sean Dague wrote:
 The policy decision to cap stable requirements was agreed to previously
 (and at summit this year), it just needs someone to implement.
 
 +1
 
 We started to implement it (in Oslo libraries iirc) and then reverted
 because we encountered problems. We concluded a proper cross-project
 spec should be written so that we can try to anticipate issues better.
 
 I don't have a totally clear view of the issue(s) we encoutered last
 time, though. Could someone write a postmortem or point me to one ? Or
 was the upgrading components issue (fixed in
 https://review.openstack.org/#/c/142075/) the only problem ?

My recollection is the component upgrade order was a big problem, but
not the only one.

The other thing that happened was partial capping doesn't work, because
something else moves forward and breaks you from below. So the patch
will need to hit everything at once.

Unresolved entirely is the tertiary dependencies (not direct
dependencies of any OpenStack project). That will need another mechanism
to seed them before any installation happens.

Whether or not pip should be pinned is also a good question, especially
because pbr requires pip, so the install -U on pbr tends to uplift pip
even if it was previously downgraded.

That's the things I can think off from the top of my head.

-Sean

-- 
Sean Dague
http://dague.net

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


Re: [openstack-dev] [nova][gate][stable] How eventlet 0.16.1 broke the gate

2015-01-15 Thread Thierry Carrez
Sean Dague wrote:
 The policy decision to cap stable requirements was agreed to previously
 (and at summit this year), it just needs someone to implement.

+1

We started to implement it (in Oslo libraries iirc) and then reverted
because we encountered problems. We concluded a proper cross-project
spec should be written so that we can try to anticipate issues better.

I don't have a totally clear view of the issue(s) we encoutered last
time, though. Could someone write a postmortem or point me to one ? Or
was the upgrading components issue (fixed in
https://review.openstack.org/#/c/142075/) the only problem ?

-- 
Thierry Carrez (ttx)

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


Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI

2015-01-15 Thread Eduard Matei
Hi Amit,
This is the only logging i see:
2015-01-15 14:48:28,034 DEBUG zuul.Gerrit: Change Change 0x7fa0bac97a50
146404,10 status: NEW
2015-01-15 14:48:28,035 INFO zuul.Gerrit: Updating information for 146460,5
2015-01-15 14:51:07,851 DEBUG zuul.Gearman: Looking for lost builds
2015-01-15 14:56:07,852 DEBUG zuul.Gearman: Looking for lost builds
2015-01-15 15:01:00,627 DEBUG zuul.Scheduler: Prepare to exit
2015-01-15 15:01:00,627 DEBUG zuul.Scheduler: Waiting for exit
2015-01-15 15:01:00,627 DEBUG zuul.Scheduler: Run handler awake
2015-01-15 15:01:00,627 DEBUG zuul.Scheduler: Checking if all builds are
complete
2015-01-15 15:01:00,628 DEBUG zuul.Scheduler: All builds are complete
2015-01-15 15:01:00,628 DEBUG zuul.Scheduler: Exiting


At 15.01 it was restarted by jenkins and between 14:48 and 15:01 there was
a job that finished but Gerrit didn't post the results.

Eduard

On Thu, Jan 15, 2015 at 3:06 PM, Amit Das amit@cloudbyte.com wrote:

 Hi Eduard,

 Can you put the logs or details for below comment:

 it seems that sometimes Zuul gets stuck (sometimes in Looking for lost
 builds, sometimes doing nothing) and it misses notifications.


 I guess, we too have been facing the same issue with Zuul.


 Regards,
 Amit
 *CloudByte Inc.* http://www.cloudbyte.com/

 On Thu, Jan 15, 2015 at 6:29 PM, Eduard Matei 
 eduard.ma...@cloudfounders.com wrote:

 Hi,
 Just so i don't start another thread: it seems that sometimes Zuul gets
 stuck (sometimes in Looking for lost builds, sometimes doing nothing) and
 it misses notifications.
 I added a Jenkins timer job to restart it every 30 minutes. Is there a
 fix for this or something to change in config?

 Thanks,
 Eduard

 On Thu, Jan 15, 2015 at 2:56 PM, Eduard Matei 
 eduard.ma...@cloudfounders.com wrote:

 Hi Ramy,

 The issue with disconnect/abort no longer happens, so i guess it was
 some issues with networking.

 Regarding the ssh keys i finally used Jenkins Configuration Provider
 Plugin to inject ssh keys as a pre-build step, then i added a manual
 execution step to scp the logs to the server, so now everything appears to
 be working.

 Now for the REAL tests:
 looking at
 https://github.com/rasselin/os-ext-testing-data/blob/master/etc/jenkins_jobs/config/dsvm-cinder-driver.yaml.sample#L7
 it seems i need to put the code to install my third party libs in the
 pre_test_hook which appears in devstack-vm-gate-wrap.sh to be executing
 BEFORE installing devstack. The problem is we need our third party libs
 to be installed (actually configured) AFTER installing devstack, since they
 install on top of devstack and do some configuration on devstack.

 How could i integrate my code into devstack-vm-gate-wrap.sh so that my
 libs are installed after devstack but before running tempest.
 Also, as a side question, do i need to run all the test (since they
 already run in dsvm-tempest-full) or can i run only our internal
 functionality tests? (in this case i don't need devstack-vm-gate-wrap.sh
 and i can run custom code directly from jenkins job).

 Thanks,

 Eduard

 On Wed, Jan 14, 2015 at 6:49 PM, Asselin, Ramy ramy.asse...@hp.com
 wrote:

  Double check your ssh public/private key, authorized keys
 configuration in the slave  log server.

 They should all match up. No passwords should be requested.

 Try doing a manual scp as Jenkins user from the slave to the log server
 (as Jenkins user there too).



 Regarding manually setting up the publisher, I don’t know. Jenkins Job
 Builder configuration I referenced below should work correctly.



 Ramy



 *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
 *Sent:* Wednesday, January 14, 2015 6:56 AM

 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need
 help setting up CI



 Hi Ramy,



 I think i managed to setup SCP plugin and updated zuul.conf but it only
 uploads the console.html not the logs

 I have an SCP site pointing to the apache server and the root location
 is /srv/static, and in the dsvm job manually added a post-build step,
 Publish Artifacts to SCP Repository, with source: logs/** and destination
 logs/${LOG_PATH} and also checked Copy Console Log.



 The destination path is created, but it only contains console.html.



 I tried to manually scp the directory, but the jenkins user in the
 devstack_slave asks for a password when trying to ssh to apache server.



 Thanks,

 Eduard



 On Wed, Jan 14, 2015 at 10:40 AM, Eduard Matei 
 eduard.ma...@cloudfounders.com wrote:

  Thanks Ramy, i'll try to set it up manually.



 Meanwhile i found another problem: jobs are failing because of error or
 are being aborted.

 FATAL: java.io.IOException: Unexpected termination of the channel

 hudson.remoting.RequestAbortedException 
 http://stacktrace.jenkins-ci.org/search?query=hudson.remoting.RequestAbortedException:
  java.io.IOException: Unexpected termination of the channel



 Is this related to another warning i got:

 

Re: [openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments

2015-01-15 Thread Lukasz Oles
Big +1, it would save me a lot of debugging time :)

On Thu, Jan 15, 2015 at 5:20 PM, Vitaly Kramskikh
vkramsk...@mirantis.com wrote:
 Folks,

 I want to discuss possibility to add network verification status field for
 environments. There are 2 reasons for this:

 1) One of the most frequent reasons of deployment failure is wrong network
 configuration. In the current UI network verification is completely optional
 and sometimes users are even unaware that this feature exists. We can warn
 the user before the start of deployment if network check failed of wasn't
 performed.

 2) Currently network verification status is partially tracked by status of
 the last network verification task. Sometimes its results become stale, and
 the UI removes the task. There are a few cases when the UI does this, like
 changing network settings, adding a new node, etc (you can grep
 removeFinishedNetworkTasks to see all the cases). This definitely should
 be done on backend.

 What is your opinion on this?

 --
 Vitaly Kramskikh,
 Software Engineer,
 Mirantis, Inc.

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




-- 
Łukasz Oleś

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


Re: [openstack-dev] [API] Upgrading to API WG Recommendations

2015-01-15 Thread michael mccune

On 01/14/2015 08:40 PM, Ian Cordasco wrote:

The point was brought up that some recommendations that the working group
forms will be jarring for APIs to implement when going from vN.* to vN+1.0
for both developers and consumers. Client libraries often provide
compatibility (or upgrade-path) versions to help bridge the gap between
going from vN.* to vN+1.0. As a group, we’re looking for feedback from the
developers on the following topics:

- Does this seem preferable?


i think it's a really nice idea to have some sort of guidelines to 
assist with the development of compatibility version. i know i would use 
it =)



- Does it sound reasonable and maintainable?


good question, my fear would be that we would start strong but fade once 
more than a few versions were published. having a clear procedure for 
updating and maintaining the guidelines might help.



- Does it seem reasonable as a way of improving user experience and
upgradability?


for me, yes.


If you have a positive feeling for this idea, there are a couple
follow-ups:

- Should the API WG recommend a strategy for this versioning path?
- If so, should the versioning path work like:

   - vN.M - vN.99 - vN+1.0
 We would use .99 to indicate that you it’s compatible with vN.* but
also provides information/endpoints in vN+1)
   - or vN.M - vN+1.0 - vN+2.0
 In this case we would make N+1 be the compatibility version (perhaps
do not allow increments of the minor version) and N+2 would be the version
of the API that is fully in-compliance with the Working Group’s final
recommendations.


this is an interesting idea. i think it would be nice if we could 
develop something that would be a clear indication to developers exactly 
which version and capabilities an api is presenting.


of those two options, i'm leaning more towards the vN.99 approach.

thanks for bringing it up Ian!

mike


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


Re: [openstack-dev] [nova] Networks are not cleaned up in build failure

2015-01-15 Thread Brian Haley
On 01/14/2015 02:15 PM, Andrew Laski wrote:
 
 On 01/14/2015 12:57 PM, Murray, Paul (HP Cloud) wrote:

 Hi All, 

 I recently experienced failures getting images from Glance while spawning
 instances. This step comes after building the networks in the guild sequence.
 When the Glance failure occurred the instance was cleaned up and rescheduled
 as expected, but the networks were not cleaned up. On investigation I found
 that the cleanup code for the networks is in the compute manager’s
 _/do_build_run/_instance() method as follows:

 # NOTE(comstud): Deallocate networks if the driver wants
 # us to do so.
 if self.driver.deallocate_networks_on_reschedule(instance):
 self._cleanup_allocated_networks(context, instance,
 requested_networks)

 The default behavior in for the deallocate_networks_on_schedule() method
 defined in ComputeDriver is:

 def deallocate_networks_on_reschedule(self, instance):
 Does the driver want networks deallocated on reschedule?
 return False

 Only the Ironic driver over rides this method to return True, so I think this
 means the networks will not be cleaned up for any other virt driver.

  

 Is this really the desired behavior?

 
 Yes.  Other than when using Ironic there is nothing specific to a particular
 host in the networking setup.  This means it is not necessary to deallocate 
 and
 reallocate networks when an instance is rescheduled, so we can avoid the
 unnecessary work of doing it.

That's either not true any more, or not true when DVR is enabled in Neutron,
since in this case the port['binding:host_id'] value has been initialized to a
compute node, and won't get updated when nova-conductor re-schedules the VM
elsewhere.

This causes the neutron port to stay on the original compute node, and any
neutron operations (like floatingip-associate) happen on the old port, leaving
the VM unreachable.

 If the instance goes to ERROR then the network will get cleaned up when the
 instance is deleted.

I think we need to clean-up even in this case now too.

-Brian

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


[openstack-dev] [cinder] All Cinder Volume Drivers Must Have A Third Party CI by March 19, 2014

2015-01-15 Thread Mike Perez
*Note: A more detailed email about this has been sent to all Cinder
volume driver maintainers directly.*

In the Jan 14th 2015 16:00 UTC Cinder IRC meeting [1], it was agreed
by Cinder core and participating vendors that the deadline for vendors
to have a third party CI would be:

March 19th 2015

There are requirements set for OpenStack Third Party CI's [2]. In
addition Cinder third party CI's must:

1) Test all volume drivers your company has integrated in Cinder.
2) Test all fabrics your solution uses.

For example, if your company has two volume drivers in Cinder and they
both use ISCSI and FibreChannel, you would need to have a CI that
tests against four backends and reports the results for each backend,
for every Cinder upstream patch. To test we're using a subset of tests
in Tempest [6].

To get started, read OpenStack's third party testing documentation
[32]. There are a variety of solutions [3] that help setting up a CI,
third party mentoring meetings [4], and designated people to answer
questions with setting up a third party CI in the #openstack-cinder
room [5].

If a solution is not being tested in a CI system and reporting to
OpenStack gerrit Cinder patches by the deadline of March 19th 2015, a
volume driver could be removed from the Cinder repository as of the
Kilo release. Without a CI system, Cinder core is unable to verify
your driver works in the Kilo release of Cinder. We will make sure
OpenStack users are aware of this via the OpenStack users mailing list
and Kilo release notes.

Cinder third party CI's have been discussed throughout a variety of
ways last year:

* Cinder IRC Meetings: [1][9][10][11][12][13][14][15][16]
* Midcycle meetups: [17]
* OpenStack dev list: [18][19][20][21][22][23][24][25][26][27][28][29]
* Design summit sessions: [30][31]

If there is something not clear about this email, please email me
*directly* with your question. You can also reach me as thingee on
Freenode IRC in the #openstack-cinder channel. Again I want you all to
be successful in this, and take advantage of this testing you will
have with your product. Please communicate with me and reach out to
the team for help.

--
Mike Perez

[1] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-01-14-16.00.log.html#l-21
[2] - http://ci.openstack.org/third_party.html#requirements
[3] - 
https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Existing_CI_Solutions
[4] - https://wiki.openstack.org/wiki/Meetings/ThirdParty
[5] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Questions
[6] - 
https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_tests_do_I_use.3F
[7] - 
http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-12-10-16.00.log.html#l-471
[8] - 
http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-11-19-16.00.log.html#l-34
[9] - 
http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-29-16.00.log.html#l-224
[10] - 
http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-15-16.00.log.html#l-59
[11] - 
http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-08-16.00.log.html#l-17
[12] - 
http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-09-17-16.00.log.html#l-244
[13] - 
http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-07-02-16.01.log.html#l-141
[14] - 
http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-07-23-16.00.log.html#l-161
[15] - 
http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-06-18-16.02.log.html#l-255
[16] - 
http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-05-21-16.00.log.html#l-310
[17] - https://etherpad.openstack.org/p/cinder-meetup-summer-2014
[18] - 
http://lists.openstack.org/pipermail/openstack-dev/2014-September/045137.html
[19] - 
http://lists.openstack.org/pipermail/openstack-dev/2014-October/047673.html
[20] - http://lists.openstack.org/pipermail/openstack-dev/2014-July/039103.html
[21] - 
http://lists.openstack.org/pipermail/openstack-dev/2014-December/051957.html
[22] - 
http://lists.openstack.org/pipermail/openstack-dev/2014-August/043392.html
[23] - 
http://lists.openstack.org/pipermail/openstack-dev/2014-August/042672.html
[24] - 
http://lists.openstack.org/pipermail/openstack-dev/2014-August/041748.html
[25] - 
http://lists.openstack.org/pipermail/openstack-dev/2014-February/026999.html
[26] - http://lists.openstack.org/pipermail/openstack-dev/2014-March/028707.html
[27] - http://lists.openstack.org/pipermail/openstack-dev/2014-July/039057.html
[28] - 
http://lists.openstack.org/pipermail/openstack-dev/2014-February/027527.html
[29] - 
http://lists.openstack.org/pipermail/openstack-dev/2014-August/041704.html
[30] - 
https://etherpad.openstack.org/p/juno-cinder-3rd-party-cert-and-verification
[31] - http://junodesignsummit.sched.org/event/56eae44976e986f39c858d784344c7d0
[32] - http://ci.openstack.org/third_party.html

__