[openstack-dev] [Neutron] Bug day

2014-11-21 Thread Eugene Nikanorov
Hi neutron folks!

Today we've decided to conduct bug triaging day.
We have more than one thousand bugs needing their state to be checked.
So everyone is welcome to participate!

The goals of bug triaging day are:
1) Decrease the number of New bugs.
Possible 'resolution' would be:
 - confirm bug. If you see the issue in the code, or you can reproduce it
 - mark as Incomplete. Bug description doesn't contain sufficient
information to triage the bug.
 - mark as Invalid. Not a bug, or we're not going to fix it.
 - mark as duplicate. If you know that other bug filed earlier is
describing the same issue.
 - mark as Fix committed if you know that the issue was fixed. It's good if
you could provide a link to corresponding review.

2) Check the Open and In progress bugs.
If the last activity on the bug happened more than a month ago - it makes
sense sometimes to bring it back to 'New'.
By activity I mean comments in the bug, actively maintained patch on
review, and such.

Of course feel free to assign a bug to yourself if you know how and going
to fix it.

Some statistics:

   - 85 New bugs
   https://bugs.launchpad.net/neutron/+bugs?search=Searchfield.status=New
   - 811 Open bugs https://bugs.launchpad.net/neutron/+bugs
   - 331 In-progress bugs
   
https://bugs.launchpad.net/neutron/+bugs?search=Searchfield.status=In+Progress


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


Re: [openstack-dev] [Fuel] fuel master monitoring

2014-11-21 Thread Przemyslaw Kaminski
I have nothing against using some 3rd party service. But I thought this 
was to be small -- disk monitoring only  notifying the user, not stats 
collecting. That's why I added the code to Fuel codebase. If you want 
external service you need to remember about such details as, say, 
duplicate settings (database credentials at least) and I thought this 
was an overkill for such simple functionality. Also, for a 3rd party 
service, notification injecting code still needs to be written as a 
plugin -- that's why I also don't think Ruby is a good idea :)


So in the end I don't know if we'll have that much less code with a 3rd 
party service. But if you want a statistics collector then maybe it's OK.


I found some Python services that might suit us:

https://github.com/google/grr
https://github.com/BrightcoveOS/Diamond

P.

On 11/20/2014 09:13 PM, Dmitriy Shulyak wrote:

Guys, maybe we can use existing software, for example Sensu [1]?
Maybe i am wrong, but i dont like the idea to start writing our 
small monitoring applications..
Also something well designed and extendable can be reused for 
statistic collector



1. https://github.com/sensu

On Wed, Nov 12, 2014 at 12:47 PM, Tomasz Napierala 
tnapier...@mirantis.com mailto:tnapier...@mirantis.com wrote:



On 06 Nov 2014, at 12:20, Przemyslaw Kaminski
pkamin...@mirantis.com mailto:pkamin...@mirantis.com wrote:

 I didn't mean a robust monitoring system, just something
simpler. Notifications is a good idea for FuelWeb.

I’m all for that, but if we add it, we need to document ways to
clean up space.
We could also add some kind of simple job to remove rotated logs,
obsolete spanshots, etc., but this is out of scope for 6.0 I guess.

Regards,
--
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com mailto:tnapier...@mirantis.com







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




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


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


Re: [openstack-dev] [Fuel] fuel master monitoring

2014-11-21 Thread Przemyslaw Kaminski

BTW, there's also Monit

http://mmonit.com/monit/

(though it's in C) that looks quite nice. Some config examples:

http://omgitsmgp.com/2013/09/07/a-monit-primer/

P.

On 11/20/2014 09:13 PM, Dmitriy Shulyak wrote:

Guys, maybe we can use existing software, for example Sensu [1]?
Maybe i am wrong, but i dont like the idea to start writing our 
small monitoring applications..
Also something well designed and extendable can be reused for 
statistic collector



1. https://github.com/sensu

On Wed, Nov 12, 2014 at 12:47 PM, Tomasz Napierala 
tnapier...@mirantis.com mailto:tnapier...@mirantis.com wrote:



On 06 Nov 2014, at 12:20, Przemyslaw Kaminski
pkamin...@mirantis.com mailto:pkamin...@mirantis.com wrote:

 I didn't mean a robust monitoring system, just something
simpler. Notifications is a good idea for FuelWeb.

I’m all for that, but if we add it, we need to document ways to
clean up space.
We could also add some kind of simple job to remove rotated logs,
obsolete spanshots, etc., but this is out of scope for 6.0 I guess.

Regards,
--
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com mailto:tnapier...@mirantis.com







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




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


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


Re: [openstack-dev] [Neutron] DB: transaction isolation and related questions

2014-11-21 Thread Eugene Nikanorov
Comments inline:

On Thu, Nov 20, 2014 at 4:34 AM, Jay Pipes jaypi...@gmail.com wrote:



 So while the SELECTs may return different data on successive calls when
 you use the READ COMMITTED isolation level, the UPDATE statements will
 continue to return 0 rows affected **if they attempt to change rows that
 have been changed since the start of the transaction**

 The reason that changing the isolation level to READ COMMITTED appears to
 work for the code in question:

 https://github.com/openstack/neutron/blob/master/neutron/
 plugins/ml2/drivers/helpers.py#L98

 is likely because the SELECT ... LIMIT 1 query is returning a different
 row on successive attempts (though since there is no ORDER BY on the query,
 the returned row of the query is entirely unpredictable (line 112)). Since
 data from that returned row is used in the UPDATE statement (line 118 and
 124), *different* rows are actually being changed by successive UPDATE
 statements.


Not really, we're updating the same row we've selected. It's ensured
by 'raw_segment'
which actually contains 'gre_id' (or similar) attribute.
So in each iteration we're working with the same row, but in different
iterations READ COMMITTED allows us to see different data and hence work
with a different row.



 What this means is that for this *very particular* case, setting the
 transaction isolation level to READ COMMITTTED will work presumably most of
 the time on MySQL, but it's not an appropriate solution for the generalized
 problem domain of the SELECT FOR UPDATE. If you need to issue a SELECT and
 an UPDATE in a retry loop, and you are attempting to update the same row or
 rows (for instance, in the quota reservation or resource allocation
 scenarios), this solution will not work, even with READ COMMITTED. This is
 why I say it's not really appropriate, and a better general solution is to
 use separate transactions for each loop in the retry mechanic.


By saying 'this solution will not work' what issues do you mean what
exactly?
Btw, I agree on using separate transaction for each loop, the problem is
that transaction is usually not 'local' to the method where the retry loop
resides.



 The issue is about doing the retry within a single transaction. That's not
 what I recommend doing. I recommend instead doing short separate
 transactions instead of long-lived, multi-statement transactions and
 relying on the behaviour of the DB's isolation level (default or otherwise)
 to solve the problem of reading changes to a record that you intend to
 update.


 instead of long-lived, multi-statement transactions - that's really what
would require quite large code redesign.
So far finding a way to bring retry logic upper to the stack of nesting
transactions seems more appropriate.

Thanks,
Eugene.


 Cheers,
 -jay

  Also, thanks Clint for clarification about example scenario described by
 Mike Bayer.
 Initially the issue was discovered with concurrent tests on multi master
 environment with galera as a DB backend.

 Thanks,
 Eugene

 On Thu, Nov 20, 2014 at 12:20 AM, Mike Bayer mba...@redhat.com
 mailto:mba...@redhat.com wrote:


  On Nov 19, 2014, at 3:47 PM, Ryan Moats rmo...@us.ibm.com
 mailto:rmo...@us.ibm.com wrote:

 
 BTW, I view your examples from oslo as helping make my argument for
 me (and I don't think that was your intent :) )


 I disagree with that as IMHO the differences in producing MM in the
 app layer against arbitrary backends (Postgresql vs. DB2 vs. MariaDB
 vs. ???)  will incur a lot more “bifurcation” than a system that
 targets only a handful of existing MM solutions.  The example I
 referred to in oslo.db is dealing with distinct, non MM backends.
 That level of DB-specific code and more is a given if we are
 building a MM system against multiple backends generically.

 It’s not possible to say which approach would be better or worse at
 the level of “how much database specific application logic do we
 need”, though in my experience, no matter what one is trying to do,
 the answer is always, “tons”; we’re dealing not just with databases
 but also Python drivers that have a vast amount of differences in
 behaviors, at every level.On top of all of that, hand-rolled MM
 adds just that much more application code to be developed and
 maintained, which also claims it will do a better job than mature
 (ish?) database systems designed to do the same job against a
 specific backend.




   My reason for asking this question here is that if the community
   wants to consider #2, then these problems are the place to start
   crafting that solution - if we solve the conflicts inherent
 with the
   two conncurrent thread scenarios, then I think we will find that
   we've solved the multi-master problem essentially for free”.
 
  Maybe I’m missing something, if we learn how to write out a row
 such
  that a concurrent transaction 

Re: [openstack-dev] [Fuel] fuel master monitoring

2014-11-21 Thread Dmitriy Shulyak
  I have nothing against using some 3rd party service. But I thought this
 was to be small -- disk monitoring only  notifying the user, not stats
 collecting. That's why I added the code to Fuel codebase. If you want
 external service you need to remember about such details as, say, duplicate
 settings (database credentials at least) and I thought this was an overkill
 for such simple functionality.


Yes, it will be much more complex than simple daemon that creates
notifications but our application is operating in isolated containers, and
most of the resources cant be discovered from any particular container. So
if we will want to extend it, with another task, like monitoring pool of
dhcp addresses - we will end up with some kindof server-agent architecture,
and this is a lot of work to do

Also, for a 3rd party service, notification injecting code still needs to
 be written as a plugin -- that's why I also don't think Ruby is a good idea
 :)

 Afaik there is a way to write python plugins for sensu, but if there is
monitoring app  in python, that have friendly support for extensions, I am
+1 for python


 So in the end I don't know if we'll have that much less code with a 3rd
 party service. But if you want a statistics collector then maybe it's OK.

 I think that monitoring application is fits there, and we kindof already
introducing our whell for collecting
statistic from openstack. I would like to know what guys who was working on
stats in 6.0 thinking about it. So it is TBD
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] A true cross-project weekly meeting

2014-11-21 Thread Flavio Percoco

On 20/11/14 09:04 -0500, Russell Bryant wrote:

On 11/20/2014 08:55 AM, Thierry Carrez wrote:

This is mostly a cosmetic change: update the messaging around that
meeting to make it more obvious that it's not purely about the
integrated release and that it is appropriate to put other types of
cross-project issues on the agenda. Let me know on this thread if that
sounds like a good idea, and we'll make the final call at next week
meeting :)


+1 :-)


This sounds like a good idea.

--
@flaper87
Flavio Percoco


pgp5ulVWt7car.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-21 Thread Thomas Goirand
On 11/21/2014 01:51 PM, Richard Jones wrote:
 On 21 November 2014 16:12, Thomas Goirand z...@debian.org
 mailto:z...@debian.org wrote:
 
 On 11/21/2014 10:52 AM, Richard Jones wrote:
  On 11/18/2014 04:22 PM, Radomir Dopieralski wrote:
   If we use Bower, we don't need to use Xstatic. It would be pure
   overhead. Bower already takes care of tracking releases and 
 versions,
   and of bundling the files. All we need is a simple line in the
   settings.py telling Django where it puts all the files -- we don't
   really need Xstatic just for that. The packagers can then take 
 those
   Bower packages and turn them into system packages, and just 
 add/change
   the paths in settings.py to where they put the files. All in one
   place.
 
  The issue is that there's often not just a single path, but a full
  directory structure to address. That is easily managed with a Debian
  xstatic package, not sure how it would be with Bower.
 
 
  I'm not sure what the difference is (unless it's just related to the
  Debian-specific historical issue you raise below). xstatic and bower are
  remarkably similar a directory to be packaged and some meta-data
  describing it.
 
 Let me explain again then.
 
 Let's say there's python-xstatic-foo, and libjs-foo in Debian. If the
 directory structure of libjs-foo is very different from xstatic-foo, I
 can address that issue with symlinks within the xstatic package. Just
 changing the BASE_DIR may not be enough, as libjs-foo may have files
 organized in a very different way than in the upstream package for foo.
 
 
 OK, so python-xstatic-foo can depend on libjs-foo and just symlink, fair
 enough. I'm still not sure what makes bower unique in this respect,

I was under the impression that I wouldn't be able to do the same
symlink thing with Bower. If I am, then great!

 although it'd be nice to avoid creating additional packages just to
 symlink things around for bower, which I think is what you're getting at.

Just to make sure: we're not moving away from the current already
existing xstatic packages are we?

Also, yes, if I can avoid to have a bower package, that'd be great. But
not sure how. It worked with the XStatic packages, and my main concern
about switching to bower is exactly that: how is it going to work
compared to XStatic stuff.

  Again; bower is not npm! Jasmine is a command-line program which is
  packaged by npm. Bower packages bundles of stuff that are included in
  web applications. bower itself, a command-line tool, is packaged by npm,
  but itself manages other packages which are not command-line things, but
  just bundles of css, javascript, images, fonts, etc. that are resources
  for web applications to use.
 
 Sure. But how do I download a bower package then?
 
 I'm not sure I understand the meaning behind this question. bower
 install angular downloads a bower package called angular.

Isn't there is a simple URL that I may use with wget? I don't really
want to use bower directly, I just would like to have a look to the
content of the bower package.

Thomas


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


Re: [openstack-dev] [Fuel] fuel master monitoring

2014-11-21 Thread Matthew Mosesohn
I'm okay with Sensu or Monit, just as long as the results of
monitoring can be represented in a web UI and has a configurable
option for email alerting. Tight integration with Fuel Web is a
nice-to-have (via AMQP perhaps), but anything that can solve our
out-of-disk scenario is ideal. I did my best to tune our logging and
logs rotation, but monitoring is the most sensible approach.

-Matthew

On Fri, Nov 21, 2014 at 12:21 PM, Przemyslaw Kaminski
pkamin...@mirantis.com wrote:
 BTW, there's also Monit

 http://mmonit.com/monit/

 (though it's in C) that looks quite nice. Some config examples:

 http://omgitsmgp.com/2013/09/07/a-monit-primer/

 P.

 On 11/20/2014 09:13 PM, Dmitriy Shulyak wrote:

 Guys, maybe we can use existing software, for example Sensu [1]?
 Maybe i am wrong, but i dont like the idea to start writing our small
 monitoring applications..
 Also something well designed and extendable can be reused for statistic
 collector


 1. https://github.com/sensu

 On Wed, Nov 12, 2014 at 12:47 PM, Tomasz Napierala tnapier...@mirantis.com
 wrote:


 On 06 Nov 2014, at 12:20, Przemyslaw Kaminski pkamin...@mirantis.com
 wrote:

  I didn't mean a robust monitoring system, just something simpler.
  Notifications is a good idea for FuelWeb.

 I’m all for that, but if we add it, we need to document ways to clean up
 space.
 We could also add some kind of simple job to remove rotated logs, obsolete
 spanshots, etc., but this is out of scope for 6.0 I guess.

 Regards,
 --
 Tomasz 'Zen' Napierala
 Sr. OpenStack Engineer
 tnapier...@mirantis.com







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




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



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


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


[openstack-dev] [Fuel] Fuel extension with VXLAN support

2014-11-21 Thread samuel.bartel
Hello,

I have a question regarding  futur vxlan support implementation in fuel and the 
corresponding blueprint.
Actually in the blueprint description there is nothing specify about the bridge 
used for vxlan traffic. In the previous implementation abandoned on gerrit the 
br-mgmt was assigned for the mesh role similary to what is done for gre 
segmentation.
Can we consider to add a dedicated bridge for vxlan in order to have the 
capacity to not mix admin and vxlan (and optionnaly monitoring with zabbix) 
traffics on the same physical interface

Regards

Samuel Bartel
IRC  #samuelbartel


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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


Re: [openstack-dev] [Fuel] fuel master monitoring

2014-11-21 Thread Igor Kalnitsky
I heard about Monit a lot of good reviews, but unfortunately it looks
like Monit doesn't support plugins and doesn't provide API. It may be
a stumbling block if one day we decide to go deeper in monitoring
task.

On Fri, Nov 21, 2014 at 11:01 AM, Matthew Mosesohn
mmoses...@mirantis.com wrote:
 I'm okay with Sensu or Monit, just as long as the results of
 monitoring can be represented in a web UI and has a configurable
 option for email alerting. Tight integration with Fuel Web is a
 nice-to-have (via AMQP perhaps), but anything that can solve our
 out-of-disk scenario is ideal. I did my best to tune our logging and
 logs rotation, but monitoring is the most sensible approach.

 -Matthew

 On Fri, Nov 21, 2014 at 12:21 PM, Przemyslaw Kaminski
 pkamin...@mirantis.com wrote:
 BTW, there's also Monit

 http://mmonit.com/monit/

 (though it's in C) that looks quite nice. Some config examples:

 http://omgitsmgp.com/2013/09/07/a-monit-primer/

 P.

 On 11/20/2014 09:13 PM, Dmitriy Shulyak wrote:

 Guys, maybe we can use existing software, for example Sensu [1]?
 Maybe i am wrong, but i dont like the idea to start writing our small
 monitoring applications..
 Also something well designed and extendable can be reused for statistic
 collector


 1. https://github.com/sensu

 On Wed, Nov 12, 2014 at 12:47 PM, Tomasz Napierala tnapier...@mirantis.com
 wrote:


 On 06 Nov 2014, at 12:20, Przemyslaw Kaminski pkamin...@mirantis.com
 wrote:

  I didn't mean a robust monitoring system, just something simpler.
  Notifications is a good idea for FuelWeb.

 I’m all for that, but if we add it, we need to document ways to clean up
 space.
 We could also add some kind of simple job to remove rotated logs, obsolete
 spanshots, etc., but this is out of scope for 6.0 I guess.

 Regards,
 --
 Tomasz 'Zen' Napierala
 Sr. OpenStack Engineer
 tnapier...@mirantis.com







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




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



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


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

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


Re: [openstack-dev] [Murano] - puka dependency

2014-11-21 Thread Stan Lagun
Hi,

It seems that you are using very old version of Murano because puka
dependency was dropped several releases ago.
Please see https://launchpad.net/murano for links to an up to date code and
documentation

Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis

sla...@mirantis.com

On Fri, Nov 21, 2014 at 9:38 AM, raghavendra@accenture.com wrote:

  Hi All,



 I am new to Murano trying to implement on Openstack Juno with Ubuntu 14.04
 LTS version. However It needs puka 0.7 as dependency.

 I would appreciate any help with the build guides. I also find Github
 prompts for username and password while I try installing packages.







 Warm Regards,

 *Raghavendra Lad*



 --

 This message is for the designated recipient only and may contain
 privileged, proprietary, or otherwise confidential information. If you have
 received it in error, please notify the sender immediately and delete the
 original. Any other use of the e-mail by you is prohibited. Where allowed
 by local law, electronic communications with Accenture and its affiliates,
 including e-mail and instant messaging (including content), may be scanned
 by our systems for the purposes of information security and assessment of
 internal compliance with Accenture policy.

 __

 www.accenture.com

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


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


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-21 Thread Radomir Dopieralski
On 21/11/14 06:12, Thomas Goirand wrote:

 Let's say there's python-xstatic-foo, and libjs-foo in Debian. If the
 directory structure of libjs-foo is very different from xstatic-foo, I
 can address that issue with symlinks within the xstatic package. Just
 changing the BASE_DIR may not be enough, as libjs-foo may have files
 organized in a very different way than in the upstream package for foo.

You can do it without xstatic even more easily, without having to muck
around with symlinks. Django has this STATICFILES_DIRS setting variable,
that you can set, that lets you specify on what URL each static
directory should be available. For instance, I use it currently to work
around the issue with jquery-ui changing directory structure between
versions:

if xstatic.main.XStatic(xstatic.pkg.jquery_ui).version.startswith('1.10.'):
# The 1.10.x versions already contain the 'ui' directory.
STATICFILES_DIRS.append(
('horizon/lib/jquery-ui',
 xstatic.main.XStatic(xstatic.pkg.jquery_ui).base_dir))
else:
# Newer versions dropped the directory, add it to keep the path the
same.
STATICFILES_DIRS.append(
('horizon/lib/jquery-ui/ui',
 xstatic.main.XStatic(xstatic.pkg.jquery_ui).base_dir))

But in your Debian package, you can completely drop xstatic and just use
absolute paths to the filesystem explicitly.

-- 
Radomir Dopieralski

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


[openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

2014-11-21 Thread Thomas Goirand
Hi,

Trying to rebuild Neutron Juno in Sid, I get so many of these failures:

Traceback (most recent call last):
  File
/home/zigo/sources/openstack/juno/neutron/build-area/neutron-2014.2/neutron/tests/unit/agent/linux/test_ovs_lib.py,
line 137, in setUp
super(OVS_Lib_Test, self).setUp()
  File
/home/zigo/sources/openstack/juno/neutron/build-area/neutron-2014.2/neutron/tests/base.py,
line 128, in setUp
self.setup_rpc_mocks()
  File
/home/zigo/sources/openstack/juno/neutron/build-area/neutron-2014.2/neutron/tests/base.py,
line 150, in setup_rpc_mocks
self.messaging_conf = messaging_conffixture.ConfFixture(CONF)
  File /usr/lib/python2.7/dist-packages/oslo/messaging/conffixture.py,
line 48, in __init__
'oslo.messaging._drivers.impl_rabbit', 'rabbit_opts')
  File /usr/lib/python2.7/dist-packages/oslo/messaging/conffixture.py,
line 24, in _import_opts
__import__(module)
  File
/usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py,
line 420, in module
class Connection(object):
  File
/usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py,
line 497, in Connection
sslv3: ssl.PROTOCOL_SSLv3
AttributeError: 'module' object has no attribute 'PROTOCOL_SSLv3'

Having a deeper look into the issue, I saw the following changelog in
Python 2.7 (this was uploaded 3 days ago in Sid):

  * Allow building and testing without SSLv3 support (Kurt Roeckx).
Closes: #768611.

Having a closer look at oslo.messaging reveals this in
oslo/messaging/_drivers/impl_rabbit.py:

_SSL_PROTOCOLS = {
tlsv1: ssl.PROTOCOL_TLSv1,
sslv23: ssl.PROTOCOL_SSLv23,
sslv3: ssl.PROTOCOL_SSLv3
}

Removing the last line (which makes the PROTOCOL_SSLv3 not used anymore)
fixed the build of Neutron.

Obviously, what happened in Debian is that Kurt Roeckx, the maintainer
of openssl, removed support for SSLv3, because of potential security
issues (downgrade attacks), which were revealed by the infamous POODLE bug.

Obviously also, we shall remove PROTOCOL_SSLv3 from one of the possible
options in oslo.messaging.

I thought this deserved explanations so that the review here can be
understood better:
https://review.openstack.org/136278

This should also be backported to the Icehouse and Juno releases. My
package for Sid has already been updated with this patch, and I will ask
for an unblock by the Debian release team, so that oslo.messaging
migrates to Jessie. I'm about to also do the work for oslo.messaging
1.4.1 in Experimental.

Cheers,

Thomas Goirand (zigo)

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


Re: [openstack-dev] [all] A true cross-project weekly meeting

2014-11-21 Thread Thierry Carrez
Eoghan Glynn wrote:
 +1 to involving the liaisons more directly
 
 -1 to the meeting size growing too large for productive real-time
communication on IRC
 
 IME, there's a practical limit on the number of *active* participants
 in an IRC meeting. Not sure what that magic threshold is, but I suspect
 not much higher than 25.

I really don't expect 25 people to actively discuss a given topic. It
happened in the past in that meeting, in what I call town hall
discussions, where the chair is generally after a wide range of feedback
to get the temperature reading on a specific issue. But most issues
raised usually crystallize into 4-8 active participants. Much like
design summit sessions :)

 So given that we're in an era of fretting about the scalability
 challenges facing cross-project concerns, I'd hate to paint ourselves
 into a corner with another cross-project scalability challenge.
 
 How about the agenda each week includes a specific invitation to a
 subset of the liaisons, based on relevance?
 
 (e.g. the week there's a CI brownout, request all the QA liaisons attend;
  whereas the week that the docs team launch a new contribution workflow,
  request that all the docs liaisons are present).
 
 Possibly with a standing invite to the release-mgmt liaison (or PTL)?

CPLs would be invited, but this is extremely optional to them (like it
is for everyone else). It also reduces the need to attend for the PTL --
they can ask one of their CPLs to represent the project on a particular
issue. It's really not as if all PTLs were always showing up to that
meeting anyway.

 Of course, as you say, the meeting is otherwise open-as-open-can-be.

Right, and I think that's the critical point -- we are not really
changing the nature of the meeting here, we are just changing the
messaging around it to make sure cross-project liaisons know they are
welcome to participate and/or propose topics to discuss on the agenda.
Vocal people were already participating, the new messaging is just
reaching out to the shy ones.

I think we can give it a try -- if we realize this ends up being
non-productive or way too crowded, we can revisit. Let's iterate and
fail fast.

-- 
Thierry Carrez (ttx)

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


Re: [openstack-dev] Installing multinode(control node)--[any_updates]

2014-11-21 Thread Vineet Menon
HI,

Are you trying to install devstack? or actual deployment version of
openstack?

Basically, control nodes need everything except n-cpu, AFAIK.

Regards,

Vineet Menon


On 20 November 2014 08:55, Chhavi Kant/TVM/TCS chhavi.k...@tcs.com wrote:



 - Original Message -
 From: Chhavi Kant/TVM/TCS chhavi.k...@tcs.com
 To: openstack-dev@lists.openstack.org
 Sent: Wed, 19 Nov 2014 16:32:55 +0530 (IST)
 Subject: [openstack-dev] Installing multinode(control node)

 Hi,

 I want to install multinode in openstack, i need some guidence on what
 all are the services that i need to enable for installing control node.
 Attached is the localrc.

 --
 Thanks  Regards

 Chhavi Kant

 =-=-=

 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


 --
 Thanks  Regards

 Chhavi Kant


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


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


Re: [openstack-dev] [Fuel] fuel master monitoring

2014-11-21 Thread Przemyslaw Kaminski

There's also OpenStack's monasca-agent:

https://github.com/stackforge/monasca-agent

We could try to run it standalone (without Monasca API), add a plugin 
for it that checks disk and sends notification straight to Fuel DB and 
omits generating Forwarder requests. Or set up a fake API though both 
ways seem a bit hackish.


I wasn't aware that we want email notifications too?

P.

On 11/21/2014 10:35 AM, Igor Kalnitsky wrote:

I heard about Monit a lot of good reviews, but unfortunately it looks
like Monit doesn't support plugins and doesn't provide API. It may be
a stumbling block if one day we decide to go deeper in monitoring
task.

On Fri, Nov 21, 2014 at 11:01 AM, Matthew Mosesohn
mmoses...@mirantis.com wrote:

I'm okay with Sensu or Monit, just as long as the results of
monitoring can be represented in a web UI and has a configurable
option for email alerting. Tight integration with Fuel Web is a
nice-to-have (via AMQP perhaps), but anything that can solve our
out-of-disk scenario is ideal. I did my best to tune our logging and
logs rotation, but monitoring is the most sensible approach.

-Matthew

On Fri, Nov 21, 2014 at 12:21 PM, Przemyslaw Kaminski
pkamin...@mirantis.com wrote:

BTW, there's also Monit

http://mmonit.com/monit/

(though it's in C) that looks quite nice. Some config examples:

http://omgitsmgp.com/2013/09/07/a-monit-primer/

P.

On 11/20/2014 09:13 PM, Dmitriy Shulyak wrote:

Guys, maybe we can use existing software, for example Sensu [1]?
Maybe i am wrong, but i dont like the idea to start writing our small
monitoring applications..
Also something well designed and extendable can be reused for statistic
collector


1. https://github.com/sensu

On Wed, Nov 12, 2014 at 12:47 PM, Tomasz Napierala tnapier...@mirantis.com
wrote:


On 06 Nov 2014, at 12:20, Przemyslaw Kaminski pkamin...@mirantis.com
wrote:


I didn't mean a robust monitoring system, just something simpler.
Notifications is a good idea for FuelWeb.

I’m all for that, but if we add it, we need to document ways to clean up
space.
We could also add some kind of simple job to remove rotated logs, obsolete
spanshots, etc., but this is out of scope for 6.0 I guess.

Regards,
--
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapier...@mirantis.com







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




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



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


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

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



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


Re: [openstack-dev] [Fuel] Fuel extension with VXLAN support

2014-11-21 Thread Vladimir Kuklin
Hi, Samuel

I think the case that you are talking about is an ability to use arbitrary
interfaces for different purposes. AFAIK, this use case is covered by
https://blueprints.launchpad.net/fuel/+spec/advanced-networking blueprint.

On Fri, Nov 21, 2014 at 12:04 PM, samuel.bar...@orange.com wrote:

  Hello,



 I have a question regarding  futur vxlan support implementation in fuel
 and the corresponding blueprint.

 Actually in the blueprint description there is nothing specify about the
 bridge used for vxlan traffic. In the previous implementation abandoned on
 gerrit the br-mgmt was assigned for the mesh role similary to what is done
 for gre segmentation.

 Can we consider to add a dedicated bridge for vxlan in order to have the
 capacity to not mix admin and vxlan (and optionnaly monitoring with zabbix)
 traffics on the same physical interface



 Regards



 Samuel Bartel

 IRC  #samuelbartel



 _

 Ce message et ses pieces jointes peuvent contenir des informations 
 confidentielles ou privilegiees et ne doivent donc
 pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
 ce message par erreur, veuillez le signaler
 a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
 electroniques etant susceptibles d'alteration,
 Orange decline toute responsabilite si ce message a ete altere, deforme ou 
 falsifie. Merci.

 This message and its attachments may contain confidential or privileged 
 information that may be protected by law;
 they should not be distributed, used or copied without authorisation.
 If you have received this email in error, please notify the sender and delete 
 this message and its attachments.
 As emails may be altered, Orange is not liable for messages that have been 
 modified, changed or falsified.
 Thank you.


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




-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
45bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com http://www.mirantis.ru/
www.mirantis.ru
vkuk...@mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Fuel] Fuel extension with VXLAN support

2014-11-21 Thread Mike Scherbakov
Samuel, Vladimir,
I see a little issue with blueprint and real use cases.

Currently we do not collect use cases. Can we start doing this in some
section of whether design doc, or in blueprint itself? We've got linux
bonds, vxlan, multiple ranges for mgmt network, etc.

On Fri, Nov 21, 2014 at 2:26 PM, Vladimir Kuklin vkuk...@mirantis.com
wrote:

 Hi, Samuel

 I think the case that you are talking about is an ability to use arbitrary
 interfaces for different purposes. AFAIK, this use case is covered by
 https://blueprints.launchpad.net/fuel/+spec/advanced-networking blueprint.

 On Fri, Nov 21, 2014 at 12:04 PM, samuel.bar...@orange.com wrote:

  Hello,



 I have a question regarding  futur vxlan support implementation in fuel
 and the corresponding blueprint.

 Actually in the blueprint description there is nothing specify about the
 bridge used for vxlan traffic. In the previous implementation abandoned on
 gerrit the br-mgmt was assigned for the mesh role similary to what is done
 for gre segmentation.

 Can we consider to add a dedicated bridge for vxlan in order to have the
 capacity to not mix admin and vxlan (and optionnaly monitoring with zabbix)
 traffics on the same physical interface



 Regards



 Samuel Bartel

 IRC  #samuelbartel



 _

 Ce message et ses pieces jointes peuvent contenir des informations 
 confidentielles ou privilegiees et ne doivent donc
 pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
 ce message par erreur, veuillez le signaler
 a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
 electroniques etant susceptibles d'alteration,
 Orange decline toute responsabilite si ce message a ete altere, deforme ou 
 falsifie. Merci.

 This message and its attachments may contain confidential or privileged 
 information that may be protected by law;
 they should not be distributed, used or copied without authorisation.
 If you have received this email in error, please notify the sender and 
 delete this message and its attachments.
 As emails may be altered, Orange is not liable for messages that have been 
 modified, changed or falsified.
 Thank you.


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




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

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




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


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-21 Thread Donald Stufft

 On Nov 21, 2014, at 3:59 AM, Thomas Goirand z...@debian.org wrote:
 
 
 I'm not sure I understand the meaning behind this question. bower
 install angular downloads a bower package called angular.
 
 Isn't there is a simple URL that I may use with wget? I don't really
 want to use bower directly, I just would like to have a look to the
 content of the bower package.

You can’t. Bower doesn’t have “traditional” packages where you take a
directory and archive it using tar/zip/whatever and then upload it to
some repo. Bower has a registry which maps names to git URLs and then
the bower CLI looks up that mapping, fetches the git repository and then
uses that as the input to the “look at metadata and do stuff with files”
part of the package manager instead of the output of an un-unarchival
command.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


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


Re: [openstack-dev] [all] A true cross-project weekly meeting

2014-11-21 Thread Sean Dague
On 11/21/2014 04:58 AM, Thierry Carrez wrote:
 Eoghan Glynn wrote:
 +1 to involving the liaisons more directly

 -1 to the meeting size growing too large for productive real-time
communication on IRC

 IME, there's a practical limit on the number of *active* participants
 in an IRC meeting. Not sure what that magic threshold is, but I suspect
 not much higher than 25.
 I really don't expect 25 people to actively discuss a given topic. It
 happened in the past in that meeting, in what I call town hall
 discussions, where the chair is generally after a wide range of feedback
 to get the temperature reading on a specific issue. But most issues
 raised usually crystallize into 4-8 active participants. Much like
 design summit sessions :)

 So given that we're in an era of fretting about the scalability
 challenges facing cross-project concerns, I'd hate to paint ourselves
 into a corner with another cross-project scalability challenge.

 How about the agenda each week includes a specific invitation to a
 subset of the liaisons, based on relevance?

 (e.g. the week there's a CI brownout, request all the QA liaisons attend;
  whereas the week that the docs team launch a new contribution workflow,
  request that all the docs liaisons are present).

 Possibly with a standing invite to the release-mgmt liaison (or PTL)?
 CPLs would be invited, but this is extremely optional to them (like it
 is for everyone else). It also reduces the need to attend for the PTL --
 they can ask one of their CPLs to represent the project on a particular
 issue. It's really not as if all PTLs were always showing up to that
 meeting anyway.

 Of course, as you say, the meeting is otherwise open-as-open-can-be.
 Right, and I think that's the critical point -- we are not really
 changing the nature of the meeting here, we are just changing the
 messaging around it to make sure cross-project liaisons know they are
 welcome to participate and/or propose topics to discuss on the agenda.
 Vocal people were already participating, the new messaging is just
 reaching out to the shy ones.

 I think we can give it a try -- if we realize this ends up being
 non-productive or way too crowded, we can revisit. Let's iterate and
 fail fast.

Right, agreed. This has always been an open meeting. Now we're just
setting the tone that the primary mission for this Open Meeting is
OpenStack as a whole things, where existing comms channels aren't
sufficient to handle the situation in the narrow. I look forward to
there being a forum primarily about discussing and addressing those
larger issues, and hopefully making a place where we provide
opportunities for people that want to get involved in OpenStack as a
whole to know what the issues are and jump in to help.

-Sean

-- 
Sean Dague
http://dague.net




signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Where should Schema files live?

2014-11-21 Thread Sandy Walsh

From: Eoghan Glynn [egl...@redhat.com] Thursday, November 20, 2014 5:34 PM

Some questions/observations inline.

 Hey y'all,

 To avoid cross-posting, please inform your -infra / -operations buddies 
 about this post.

 We've just started thinking about where notification schema files should 
 live and how they should be deployed. Kind of a tricky problem.  We could 
 really use your input on this problem ...

 The assumptions:
 1. Schema files will be text files. They'll live in their own git repo 
 (stackforge for now, ideally oslo eventually).
 2. Unit tests will need access to these files for local dev
 3. Gating tests will need access to these files for integration tests
 4. Many different services are going to want to access these files during 
 staging and production.
 5. There are going to be many different versions of these files. There are 
 going to be a lot of schema updates.

 Some problems / options:
 a. Unlike Python, there is no simple pip install for text files. No version 
 control per se. Basically whatever we pull from the repo. The problem with a 
 git clone is we need to tweak config files to point to a directory and 
 that's a pain for gating tests and CD. Could we assume a symlink to some 
 well-known location?
 a': I suppose we could make a python installer for them, but that's a 
 pain for other language consumers.

Would it be unfair to push that burden onto the writers of clients
in other languages?

i.e. OpenStack, being largely python-centric, would take responsibility
for both:

  1. Maintaining the text versions of the schema in-tree (e.g. as json)

and:

  2. Producing a python-specific installer based on #1

whereas, the first Java-based consumer of these schema would take
#1 and package it up in their native format, i.e. as a jar or
OSGi bundle.

Certainly an option. My gut says it will lead to abandoned/fragmented efforts.
If I was a ruby developer, would I want to take on the burden of maintaining 
yet another package? 
I think we need to treat this data as a form of API and there it's our 
responsibility to make easily consumable. 

(I'm not hard-line on this, again, just my gut feeling)

 b. In production, each openstack service could expose the schema files via 
 their REST API, but that doesn't help gating tests or unit tests. Also, this 
 means every service will need to support exposing schema files. Big 
 coordination problem.

I kind of liked this schemaURL endpoint idea when it was first
mooted at summit.

The attraction for me was that it would allow the consumer of the
notifications always have access to the actual version of schema
currently used on the emitter side, independent of the (possibly
out-of-date) version of the schema that the consumer has itself
installed locally via a static dependency.

However IIRC there were also concerns expressed about the churn
during some future rolling upgrades - i.e. if some instances of
the nova-api schemaURL endpoint are still serving out the old
schema, after others in the same deployment have already been
updated to emit the new notification version.

Yeah, I like this idea too. In the production / staging phase this seems like 
the best route. The local dev / testing situation seems to be the real tough 
nut to crack. 

WRT rolling upgrades we have to ensure we update the service catalog first, the 
rest should be fine. 

 c. In production, We could add an endpoint to the Keystone Service Catalog 
 to each schema file. This could come from a separate metadata-like service. 
 Again, yet-another-service to deploy and make highly available.

Also to {puppetize|chef|ansible|...}-ize.

Yeah, agreed, we probably don't want to do down that road.

Which is kinda unfortunate since it's the lowest impact on other projects. 

 d. Should we make separate distro packages? Install to a well known location 
 all the time? This would work for local dev and integration testing and we 
 could fall back on B and C for production distribution. Of course, this will 
 likely require people to add a new distro repo. Is that a concern?

Quick clarification ... when you say distro packages, do you mean
Linux-distro-specific package formats such as .rpm or .deb?

Yep. 

Cheers,
Eoghan

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


Re: [openstack-dev] Where should Schema files live?

2014-11-21 Thread Sandy Walsh
From: Doug Hellmann [d...@doughellmann.com] Thursday, November 20, 2014 5:09 PM
On Nov 20, 2014, at 3:40 PM, Sandy Walsh sandy.wa...@rackspace.com wrote:
 From: Doug Hellmann [d...@doughellmann.com] Thursday, November 20, 2014 3:51 
 PM
 On Nov 20, 2014, at 8:12 AM, Sandy Walsh sandy.wa...@rackspace.com wrote:
 The assumptions:
 1. Schema files will be text files. They'll live in their own git repo 
 (stackforge for now, ideally oslo eventually).
 Why wouldn’t they live in the repo of the application that generates the 
 notification, like we do with the database schema and APIs defined by those 
 apps?

 That would mean downstream consumers (potentially in different languages) 
 would need to pull all repos and extract just the schema parts. A separate 
 repo would make it more accessible.

OK, fair. Could we address that by publishing the schemas for an app in a tar 
ball using a post merge job?

That's something to consider. At first blush it feels a little clunky to pull 
all projects to extract schemas whenever any of the projects change. 

But there is something to be said about having the schema files next to the 
code that going to generate the data. 

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


Re: [openstack-dev] [Oslo] Stable Compat jobs on Oslo Libraries

2014-11-21 Thread Doug Hellmann

On Nov 20, 2014, at 4:39 PM, Matthew Treinish mtrein...@kortar.org wrote:

 
 Hi everyone,
 
 Earlier today https://review.openstack.org/136017 merged which adds stable
 compat jobs to most of the oslo libraries. This was done in reaction to 2
 separate incidents in the past 2 days where both oslo.vmware and taskflow 
 landed
 changes that added new requirements which weren't in stable/icehouse global
 requirements. This broke all the stable/icehouse dsvm jobs, which basically
 blocked stable backports to icehouse, juno as well as all tempest and
 devstack-gate changes. (among other things)
 
 So in the short-term for future changes that add new requirements the
 requirements have to be added to stable global requirements before they change
 will be able to land on master. This has been the policy for all the libraries
 that installed from git on stable branches (the client libs have stable compat
 jobs for this reason) but was just not being enforced on oslo libs prior to
 136017.

Are the jobs smart enough to realize that if a library wasn’t being used in a 
given stable branch, we don’t need to worry about adding requirements? For 
example, most of the libraries weren’t used in Icehouse so we shouldn’t need to 
ensure that new dependencies they add are compatible with the existing icehouse 
dependencies.

Doug


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


Re: [openstack-dev] [Fuel] Fuel extension with VXLAN support

2014-11-21 Thread samuel.bartel
Mike,

It sounds to be a good idea in order to indentify issues with blueprint and 
real uses cases.
A doc can be a good media to share on this subject.
Were you talking of this one  User stories: 
https://docs.google.com/a/mirantis.com/document/d/1iWeuXzV4-muLK3Nfx2IH8WI6yrawOXM5ZBqMCE5ZLzc/edit?

Or should we create a new one?


From: Mike Scherbakov [mailto:mscherba...@mirantis.com]
Sent: vendredi 21 novembre 2014 12:52
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Fuel] Fuel extension with VXLAN support

Samuel, Vladimir,
I see a little issue with blueprint and real use cases.

Currently we do not collect use cases. Can we start doing this in some section 
of whether design doc, or in blueprint itself? We've got linux bonds, vxlan, 
multiple ranges for mgmt network, etc.

On Fri, Nov 21, 2014 at 2:26 PM, Vladimir Kuklin 
vkuk...@mirantis.commailto:vkuk...@mirantis.com wrote:
Hi, Samuel

I think the case that you are talking about is an ability to use arbitrary 
interfaces for different purposes. AFAIK, this use case is covered by 
https://blueprints.launchpad.net/fuel/+spec/advanced-networking blueprint.

On Fri, Nov 21, 2014 at 12:04 PM, 
samuel.bar...@orange.commailto:samuel.bar...@orange.com wrote:
Hello,

I have a question regarding  futur vxlan support implementation in fuel and the 
corresponding blueprint.
Actually in the blueprint description there is nothing specify about the bridge 
used for vxlan traffic. In the previous implementation abandoned on gerrit the 
br-mgmt was assigned for the mesh role similary to what is done for gre 
segmentation.
Can we consider to add a dedicated bridge for vxlan in order to have the 
capacity to not mix admin and vxlan (and optionnaly monitoring with zabbix) 
traffics on the same physical interface

Regards

Samuel Bartel
IRC  #samuelbartel


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.

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



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

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



--
Mike Scherbakov
#mihgen

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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


Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

2014-11-21 Thread Doug Hellmann

On Nov 21, 2014, at 4:56 AM, Thomas Goirand z...@debian.org wrote:

 Hi,
 
 Trying to rebuild Neutron Juno in Sid, I get so many of these failures:
 
 Traceback (most recent call last):
  File
 /home/zigo/sources/openstack/juno/neutron/build-area/neutron-2014.2/neutron/tests/unit/agent/linux/test_ovs_lib.py,
 line 137, in setUp
super(OVS_Lib_Test, self).setUp()
  File
 /home/zigo/sources/openstack/juno/neutron/build-area/neutron-2014.2/neutron/tests/base.py,
 line 128, in setUp
self.setup_rpc_mocks()
  File
 /home/zigo/sources/openstack/juno/neutron/build-area/neutron-2014.2/neutron/tests/base.py,
 line 150, in setup_rpc_mocks
self.messaging_conf = messaging_conffixture.ConfFixture(CONF)
  File /usr/lib/python2.7/dist-packages/oslo/messaging/conffixture.py,
 line 48, in __init__
'oslo.messaging._drivers.impl_rabbit', 'rabbit_opts')
  File /usr/lib/python2.7/dist-packages/oslo/messaging/conffixture.py,
 line 24, in _import_opts
__import__(module)
  File
 /usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py,
 line 420, in module
class Connection(object):
  File
 /usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py,
 line 497, in Connection
sslv3: ssl.PROTOCOL_SSLv3
 AttributeError: 'module' object has no attribute 'PROTOCOL_SSLv3'
 
 Having a deeper look into the issue, I saw the following changelog in
 Python 2.7 (this was uploaded 3 days ago in Sid):
 
  * Allow building and testing without SSLv3 support (Kurt Roeckx).
Closes: #768611.
 
 Having a closer look at oslo.messaging reveals this in
 oslo/messaging/_drivers/impl_rabbit.py:
 
_SSL_PROTOCOLS = {
tlsv1: ssl.PROTOCOL_TLSv1,
sslv23: ssl.PROTOCOL_SSLv23,
sslv3: ssl.PROTOCOL_SSLv3
}
 
 Removing the last line (which makes the PROTOCOL_SSLv3 not used anymore)
 fixed the build of Neutron.
 
 Obviously, what happened in Debian is that Kurt Roeckx, the maintainer
 of openssl, removed support for SSLv3, because of potential security
 issues (downgrade attacks), which were revealed by the infamous POODLE bug.
 
 Obviously also, we shall remove PROTOCOL_SSLv3 from one of the possible
 options in oslo.messaging.
 
 I thought this deserved explanations so that the review here can be
 understood better:
 https://review.openstack.org/136278

The patch drops support entirely, but as Brant points out that isn’t 
backwards-compatible. I’d be interested to hear from the security team about 
whether the security issues trump the backwards compatibility issues here or if 
we should maintain optional support (that is, allow v3 if we detect that we can 
use it because the symbol is present). 

Thomas, can you get one or two of the security team to comment on the patch?

Doug

 
 This should also be backported to the Icehouse and Juno releases. My
 package for Sid has already been updated with this patch, and I will ask
 for an unblock by the Debian release team, so that oslo.messaging
 migrates to Jessie. I'm about to also do the work for oslo.messaging
 1.4.1 in Experimental.
 
 Cheers,
 
 Thomas Goirand (zigo)
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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


Re: [openstack-dev] Where should Schema files live?

2014-11-21 Thread Doug Hellmann

On Nov 21, 2014, at 9:11 AM, Sandy Walsh sandy.wa...@rackspace.com wrote:

 From: Doug Hellmann [d...@doughellmann.com] Thursday, November 20, 2014 5:09 
 PM
 On Nov 20, 2014, at 3:40 PM, Sandy Walsh sandy.wa...@rackspace.com wrote:
 From: Doug Hellmann [d...@doughellmann.com] Thursday, November 20, 2014 
 3:51 PM
 On Nov 20, 2014, at 8:12 AM, Sandy Walsh sandy.wa...@rackspace.com wrote:
 The assumptions:
 1. Schema files will be text files. They'll live in their own git repo 
 (stackforge for now, ideally oslo eventually).
 Why wouldn’t they live in the repo of the application that generates the 
 notification, like we do with the database schema and APIs defined by 
 those apps?
 
 That would mean downstream consumers (potentially in different languages) 
 would need to pull all repos and extract just the schema parts. A separate 
 repo would make it more accessible.
 
 OK, fair. Could we address that by publishing the schemas for an app in a 
 tar ball using a post merge job?
 
 That's something to consider. At first blush it feels a little clunky to pull 
 all projects to extract schemas whenever any of the projects change. 

Oh, that’s not what I meant. I meant that there would be a separate package for 
each project’s schema(s). We could have a meta package that we build, too, but 
I was thinking of bundling them separately.

 
 But there is something to be said about having the schema files next to the 
 code that going to generate the data. 

It feels like it would be easier to keep them in sync that way. It would let us 
gate on that being the case, for example, without having to stage commits in 
multiple repositories.

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


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


Re: [openstack-dev] [all] A true cross-project weekly meeting

2014-11-21 Thread Eoghan Glynn


 Right, agreed. This has always been an open meeting.

Yes of course, as I said up-thread.

This is a central plank of our 4 Opens principle[1], which should
apply across the board to all community meetings related to the
OpenStack project.

All project meetings are held in public IRC channels and recorded.

Cheers,
Eoghan

[1] https://wiki.openstack.org/wiki/Open

 Now we're just
 setting the tone that the primary mission for this Open Meeting is
 OpenStack as a whole things, where existing comms channels aren't
 sufficient to handle the situation in the narrow. I look forward to
 there being a forum primarily about discussing and addressing those
 larger issues, and hopefully making a place where we provide
 opportunities for people that want to get involved in OpenStack as a
 whole to know what the issues are and jump in to help.
 
 -Sean
 
 --
 Sean Dague
 http://dague.net
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

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


Re: [openstack-dev] Where should Schema files live?

2014-11-21 Thread Eoghan Glynn


  Why wouldn’t they live in the repo of the application that generates the
  notification, like we do with the database schema and APIs defined by
  those apps?
 
  That would mean downstream consumers (potentially in different languages)
  would need to pull all repos and extract just the schema parts. A
  separate repo would make it more accessible.
 
 OK, fair. Could we address that by publishing the schemas for an app in a
 tar ball using a post merge job?
 
 That's something to consider. At first blush it feels a little clunky to pull
 all projects to extract schemas whenever any of the projects change.
 
 But there is something to be said about having the schema files next to the
 code that going to generate the data.

My initial read of Doug's proposal was for a tarball of the project's schemas
to be published somewhere out-of-tree, e.g. to tarballs.openstack.org, via a
post-merge git hook or some-such.

Not 100% sure that's a correct interpretation of the proposal, but it would
avoid the need for the consumer projects to pull the repos of the emitter
projects. 

Cheers,
Eoghan

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


Re: [openstack-dev] [Rally] Question on periodic task

2014-11-21 Thread Boris Pavlovic
Ajay,


We have this in our RoadMap:
https://github.com/stackforge/rally/blob/master/doc/feature_request/multi_scenarios_load_gen.rst

So, it's not yet supported out of box, but we really would like to have it
in upstream.

Are you interested in work on this direction?


Best regards,
Boris Pavlovic


On Fri, Nov 21, 2014 at 8:22 AM, Ajay Kalambur (akalambu) 
akala...@cisco.com wrote:

  Ok the action I wanted to perform was for HA I.e execute a scenario like
 VM boot and in parallel in a separate process , ssh and restart controller
 node for instance
 I thought periodic task would be useful for that. I guess I need to look
 at some other way of performing this
 Ajay


   From: Boris Pavlovic bpavlo...@mirantis.com
 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: Thursday, November 20, 2014 at 7:03 PM
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Rally] Question on periodic task

   Hi Ajay,


  I am not sure why you are looking that part at all.
 everything in openstack/common/* is oslo-incubator code.
 Actually that method is not used in Rally yet, except Rally as a Service
 part that doesn't work yet.

  As a scenario developer I think you should be able to find everything
 here:
  https://github.com/stackforge/rally/tree/master/rally/benchmark

  So I really don't the case when you need to pass something to periodic
 task.. It's not that task


  Best regards,
 Boris Pavlovic






 On Fri, Nov 21, 2014 at 3:36 AM, Ajay Kalambur (akalambu) 
 akala...@cisco.com wrote:

  Hi
 I have a question on
 /rally/openstack/common/periodic_task.py

  It looks like if I have a method decorated with @periodic_task my
 method would get scheduled in separate process every N seconds
 Now let us say we have a scenario and this periodic_task how does it work
 when concurrency=2 for instance

  Is the periodic task also scheduled in 2 separate process. I actually
 want only one periodic task process irrespective of concurrency count in
 scenario
 Also as a scenario developer how can I pass arguments into the periodic
 task


  Ajay


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



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


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


Re: [openstack-dev] [Nova] Tracking Kilo priorities

2014-11-21 Thread Alessandro Pilotti
Hi,

Not seeing any driver (Hyper-V, VMWare, etc) related priority in this etherpad
worries me a bit.


My concern is mostly related to the fact that we have in Nova a significative
number of driver related blueprints code already under review for Kilo and we
are already drifting into the old familiar “Nova rebase hell” at the very
beginning of the cycle. :-)

The Nova core team is obviously doing everything possible to make everybody
happy, I surely have no complains in the amount of effort put into the
reviewing machine, but the total effort required seems simply hopelessly
overwhelming for a single centralized team and lower priority features / bugs
will suffer. 

Looking at the pending reviews count, a significative non trivial amount of the
patches is related to the drivers (see stats below) but since driver blueprints
and bugs are very rarely prioritized, I suspect that we might end up with
another upstream release with inadeguate support for most hypervisors beside
the “blessed” libvirt / KVM, resulting in a lot of blueprints and bug fixes
postponed to the next release.

The last discussion on this ML [1] on splitting the divers from Nova had a lot
of consensus, no more than two months ago. I wonder why wasn’t this discussed
further, for example at the design summit?

In Hyper-V we averted this crisis by simply focusing on the downstream stable
branches (e.g. [2] for Juno), where we reached the quality, stability and
feature levels that we wanted [3], leaving the upstream driver code as a simple
“take it or leave it” best effort code that we surely don’t advise any of our
users to even bother with. Every single line of code that we produce and merge
downstream is obviously also sent upstream for review and eventually merged
there as well, but we don’t necessarily worry anymore about the fact that it
takes months for this to happen, even if we still put a lot of effort into it.

At this stage, since the drivers are a completely partitioned and independent
subset of Nova, the real umbilical cord that prevents a driver maintainer team
to simply leave the Nova project and continue on StackForge is the third party
CI system support, which with all its limitations it's still an amazing
achievement. 
In particular third party CIs are extremely important from a hypervisor
perspective to make sure that Nova changes don't cause regressions in the
drivers (more than the other way around). This means that realistically, for a
driver, leaving Nova and even going back through the Stackforge purgatory is
simply not an option, unless there is a highly unrealistical consensus in still
mantaining a voting CI in Nova for what would become an external driver
resulting from a schism.

Please consider this just as a constructive discussion for the greater good of
the whole OpenStack community [4] :-)

Thanks,

Alessandro


Quick stats showing open reviews (please forgive the simplifications):

All Nova (master):  657

All nova/virt:  208

nova/virt/hyperv:   31
nova/virt/libvirt:  80
nova/virt/vmwareapi:63
nova/virt/xenapi:   28

Values have been obtained with the following very basic query, not considering
overlapping patches, unit tests, etc:

gerrymander changes -p openstack/nova $PATH --status open --branch master -m 
json \ 
python -c import sys; import json; print 
len(json.load(sys.stdin)[0]['table']['content'])


[1] Last Nova drivers split discussion: 
http://lists.openstack.org/pipermail/openstack-dev/2014-September/044872.html
[2] Stable Hyper-V downstream Juno branch: 
https://github.com/cloudbase/nova/tree/2014.1.2-cloudbase-release
[3] Extensive downstream Hyper-V Tempest tests: 
http://www.cloudbase.it/openstack-on-hyper-v-release-testing/
[4] http://whatsthepont.files.wordpress.com/2012/02/20120212-223344.jpg




 On 20 Nov 2014, at 11:17, Michael Still mi...@stillhq.com wrote:
 
 Hi,
 
 as discussed at the summit, we want to do a better job of tracking the
 progress of work on our priorities for Kilo. To that end, we have
 agreed to discuss the current state of these at each nova meeting.
 
 I have created this etherpad:
 
   https://etherpad.openstack.org/p/kilo-nova-priorities-tracking
 
 If you are the owner of a priority, please ensure it lists the reviews
 you currently require before the meeting tomorrow. If you could limit
 your entry to less than five reviews, that would be good.
 
 Thanks,
 Michael
 
 -- 
 Rackspace Australia
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


Re: [openstack-dev] Where should Schema files live?

2014-11-21 Thread Eoghan Glynn


  Some problems / options:
  a. Unlike Python, there is no simple pip install for text files. No
  version control per se. Basically whatever we pull from the repo. The
  problem with a git clone is we need to tweak config files to point to a
  directory and that's a pain for gating tests and CD. Could we assume a
  symlink to some well-known location?
  a': I suppose we could make a python installer for them, but that's a
  pain for other language consumers.
 
 Would it be unfair to push that burden onto the writers of clients
 in other languages?
 
 i.e. OpenStack, being largely python-centric, would take responsibility
 for both:
 
   1. Maintaining the text versions of the schema in-tree (e.g. as json)
 
 and:
 
   2. Producing a python-specific installer based on #1
 
 whereas, the first Java-based consumer of these schema would take
 #1 and package it up in their native format, i.e. as a jar or
 OSGi bundle.
 
 Certainly an option. My gut says it will lead to abandoned/fragmented
 efforts.
 If I was a ruby developer, would I want to take on the burden of maintaining
 yet another package?
 I think we need to treat this data as a form of API and there it's our
 responsibility to make easily consumable.
 
 (I'm not hard-line on this, again, just my gut feeling)

OK, that's fair.

[snip]
  d. Should we make separate distro packages? Install to a well known
  location all the time? This would work for local dev and integration
  testing and we could fall back on B and C for production distribution. Of
  course, this will likely require people to add a new distro repo. Is that
  a concern?
 
 Quick clarification ... when you say distro packages, do you mean
 Linux-distro-specific package formats such as .rpm or .deb?
 
 Yep.

So that would indeed work, but just to sound a small note of caution
that keeping an oft-changing package (assumption #5) up-to-date for
fedora20/21  epel6/7, or precise/trusty, would involve some work.

I don't know much about the Debian/Ubuntu packaging pipeline, in
particular how it could be automated.

But in my small experience of Fedora/EL packaging, the process is
somewhat resistant to many fine-grained updates.

Cheers,
Eoghan

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


Re: [openstack-dev] [Oslo] Stable Compat jobs on Oslo Libraries

2014-11-21 Thread Matthew Treinish
On Fri, Nov 21, 2014 at 09:20:40AM -0500, Doug Hellmann wrote:
 
 On Nov 20, 2014, at 4:39 PM, Matthew Treinish mtrein...@kortar.org wrote:
 
  
  Hi everyone,
  
  Earlier today https://review.openstack.org/136017 merged which adds stable
  compat jobs to most of the oslo libraries. This was done in reaction to 2
  separate incidents in the past 2 days where both oslo.vmware and taskflow 
  landed
  changes that added new requirements which weren't in stable/icehouse global
  requirements. This broke all the stable/icehouse dsvm jobs, which basically
  blocked stable backports to icehouse, juno as well as all tempest and
  devstack-gate changes. (among other things)
  
  So in the short-term for future changes that add new requirements the
  requirements have to be added to stable global requirements before they 
  change
  will be able to land on master. This has been the policy for all the 
  libraries
  that installed from git on stable branches (the client libs have stable 
  compat
  jobs for this reason) but was just not being enforced on oslo libs prior to
  136017.
 
 Are the jobs smart enough to realize that if a library wasn’t being used in a 
 given stable branch, we don’t need to worry about adding requirements? For 
 example, most of the libraries weren’t used in Icehouse so we shouldn’t need 
 to ensure that new dependencies they add are compatible with the existing 
 icehouse dependencies.
 

If the library isn't being used on a branch then nothing on that branch will
break when a requirement is added, because nothing is trying to install the
library with the new requirement. But thinking about this, I just realized that
the stable-compat job template I added to all the libs doesn't discriminate
between icehouse and juno so you'll be running extra jobs for no reason on those
libraries which weren't used in icehouse. A good follow-up patch would probably
be to stop using the template on those and just manually add the juno jobs to
those libraries. (or make a separate template for just juno and use that
instead)

-Matt Treinish


pgp1yfWC8Qt_X.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Fuel] fuel master monitoring

2014-11-21 Thread Fox, Kevin M
How about this?
https://wiki.openstack.org/wiki/Monasca

Kevin


From: Dmitriy Shulyak
Sent: Friday, November 21, 2014 12:57:45 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Fuel] fuel master monitoring


I have nothing against using some 3rd party service. But I thought this was to 
be small -- disk monitoring only  notifying the user, not stats collecting. 
That's why I added the code to Fuel codebase. If you want external service you 
need to remember about such details as, say, duplicate settings (database 
credentials at least) and I thought this was an overkill for such simple 
functionality.

Yes, it will be much more complex than simple daemon that creates notifications 
but our application is operating in isolated containers, and most of the 
resources cant be discovered from any particular container. So if we will want 
to extend it, with another task, like monitoring pool of dhcp addresses - we 
will end up with some kindof server-agent architecture, and this is a lot of 
work to do

Also, for a 3rd party service, notification injecting code still needs to be 
written as a plugin -- that's why I also don't think Ruby is a good idea :)

Afaik there is a way to write python plugins for sensu, but if there is 
monitoring app  in python, that have friendly support for extensions, I am +1 
for python

So in the end I don't know if we'll have that much less code with a 3rd party 
service. But if you want a statistics collector then maybe it's OK.

I think that monitoring application is fits there, and we kindof already 
introducing our whell for collecting
statistic from openstack. I would like to know what guys who was working on 
stats in 6.0 thinking about it. So it is TBD

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


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

2014-11-21 Thread Dmitry Pyzhov
We have a request https://bugs.launchpad.net/fuel/+bug/1394487 for change
compression from gz to xz. This simple change halfs our snapshots. Does
anyone has any objections? Otherwise we will include this change in 6.0
release.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] Doc Bug Triage Day - results

2014-11-21 Thread Anne Gentle
Hi all,
Yesterday we held an all-day doc bug triage day, triaging bugs in both
openstack-manuals and openstack-api-site on Launchpad. And some even walked
around in related projects with a docs tag. Stretching our legs.

Here are some positive results:

27 triaged for openstack-api-site (3 have someone assigned already) [1]
5 low-hanging-fruit for openstack-api-site

88 triaged for openstack-manuals  (21 have someone assigned already) [2]
20 low-hanging-fruit for openstack-manuals

One low-hanging-fruit doc bug lasted only a couple of hours before it was
fixed and merged! There are about 12 doc bug fixes in review today.

Since Wed Oct 29 we've gone from 454 bugs to 396 in openstack-manuals. We
now have 115 doc bugs triaged, meaning the fix is explained in the doc bug
itself. Let's go squash those! Thanks to all who participated. Look for
another one scheduled in December.

Thanks,
Anne

1. http://bit.ly/api-site-triaged  no one assigned, also
2. http://bit.ly/doc-site-triaged  no one assigned, also
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Fuel] We lost some commits during upstream puppet manifests merge

2014-11-21 Thread Aleksandr Didenko
Hi,

following our docs/workflow plus writing rspec tests for every new option
we add/modify in our manifests could help with regressions. For example:

   - we add new keystone config option in openstack::keystone class -
   keystone_config {'cache/backend': value = 'keystone.cache.memcache_pool';}
   - we create new test for openstack::keystone class, something like this:
  - should
  
contain_keystone_config(cache/backend).with_value('keystone.cache.memcache_pool')

So with such test, if for some reason we lose
keystone_config(cache/backend) option, 'rake spec' would alert us about
it right away and we'll get -1 from CI. Of course we should also
implement 'rake spec' CI gate for this.

But from the other hand, if someone changes option in manifests and updates
rspec tests accordingly, then such commit will pass 'rake spec' test and we
can still lose some specific option.

 We should speed up development of some modular testing framework that
will check that corresponding change affects only particular pieces.

Such test would not catch this particular regressions with keystone_config
{'cache/backend': value = 'keystone.cache.memcache_pool';}, because even
with regression (i.e. dogpile backend) keystone was working OK. It has
passed several BVTs and custom system tests, because 'dogpile' cache
backend was working just fine while all memcached servers are up and
running. So it looks like we need some kind of tests that will ensure that
particular config options (or particular puppet resources) have some
particular values (like backend = keystone.cache.memcache_pool in [cache]
block of keystone.conf).

So I would go with rspec testing for specific resources but I would write
them in 'openstack' module. Those tests should check that needed
(nova/cinder/keystone/glance)_config resources have needed values in the
puppet catalog. Since we're not going to sync 'openstack' module with the
upstream, such tests will remain intact until we change them, and they
won't be affected by other modules sync/merge (keystone, cinder, nova, etc).

--
Regards,
Aleksandr Didenko


On Wed, Nov 19, 2014 at 5:45 PM, Vladimir Kuklin vkuk...@mirantis.com
wrote:

 Fuelers

 I am writing that we had a really sad incident - we noticed that after we
 merged upstream keystone module we lost modifications (Change-Id:
 Idfe4b54caa0d96a93e93bfff12d8b6216f83e2f1
 https://review.openstack.org/#/q/Idfe4b54caa0d96a93e93bfff12d8b6216f83e2f1,n,z)
 for memcached dogpile driver which are crucial for us. And here I can see 2
 problems:

 1) how can we ensure that we did not lose anything else?
 2) how can we ensure that this will never happen again?

 Sadly, it seems that the first question implies that we recheck all the
 upstream merge/adaptation commits by hand and check that we did not lose
 anything.

 Regarding question number 2 we do already have established process for
 upstream code merge:
 http://docs.mirantis.com/fuel-dev/develop/module_structure.html#contributing-to-existing-fuel-library-modules.
 It seems that this process had  not been established when keystone code was
 reviewed. I see two ways here:

 1) We should enforce code review workflow and specifically say that
 upstream merges can be accepted only after we have 2 '+2s' from core
 reviewers after they recheck that corresponding change does not introduce
 any regressions.
 2) We should speed up development of some modular testing framework that
 will check that corresponding change affects only particular pieces. It
 seems much easier if we split deployment into stages (oh my, I am again
 talking about granular deployment feature) and each particular commit
 affects only one of the stages, so that we can see the difference and catch
 regressions eariler.





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

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


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


[openstack-dev] [oslo] proposed library releases for next week

2014-11-21 Thread Doug Hellmann
We have a backlog of changes in many of the Oslo libraries, so I would like to 
cut releases early next week. Please look over the list below and speak up if 
there are known issues that would prevent us from releasing these libs on 
Monday or Tuesday of next week. Patches still in the review queue can wait for 
the next batch of releases, so let’s focus on what’s in already.

Doug


openstack/cliff  1.8.0..HEAD (new release: 1.9.0)

f6e9bbd print the real error cmd argument
a5fd24d Updated from global requirements

openstack/oslo.concurrency  0.2.0..HEAD (new release: 0.3.0)

3bda65c Allow for providing a customized semaphore container
656f908 Move locale files to proper place
faa30f8 Flesh out the README
bca4a0d Move out of the oslo namespace package
58de317 Improve testing in py3 environment
fa52a63 Only modify autoindex.rst if it exists
63e618b Imported Translations from Transifex
d5ea62c lockutils-wrapper cleanup
78ba143 Don't use variables that aren't initialized

openstack/oslo.config 1.4.0..HEAD (new release: 1.5.0)

7ab3326 Updated from global requirements
c81dc30 Updated from global requirements
4a15ea3 Fix class constant indentation
5d5faeb Updated from global requirements
d6b0ee6 Activate pep8 check that _ is imported
73635ef Updated from global requirements
cf94a51 Updated from global requirements
e906e74 Updated from global requirements
0a7abd0 Add some guidance for group names
e0ad7fa delay formatting debug log message
f7c54d9 Check config default value is correct type
41770ad Report permission denied when parsing config
5ada833 Fix docs example using generator config files
e82f6bb Updated from global requirements
fa458ee do not use colons in section titles
2af57e5 Stop using intersphinx
a736da3 Fixed typo in docstring for _get_config_dirs
ba6486a Update contributing instructions
70fc459 Add missing newline to stderr output when argument value is wrong

openstack/oslo.db  1.1.0..HEAD (new release: 1.2.0)

10e8d15 Add table name to foreign keys diff
ddd11df Updated from global requirements
2269848 Handle Galera deadlock on SELECT FOR UPDATE
4b2058b Add exception filter for _sqlite_dupe_key_error
7f755bf Ensure is_backend_avail() doesn't leave open connections
c54d3a9 Updated from global requirements
2099177 Add pbr to installation requirements
135701b Fix python3.x scoping issues with removed 'de’ variable

openstack/oslo.i18n  1.0.0..HEAD (new release: 1.1.0)

5a163eb Imported Translations from Transifex
1fc63ac Add note for integration modules in libraries
2fe3f73 Activate pep8 check that _ is imported
d67767b Add pbr to installation requirements
3583c89 Updated from global requirements
497f8d3 Updated from global requirements
624c52c Remove extraneous vim editor configuration comments
9b6a9c2 Make clear in docs to use _LE() when using LOG.exception()
999a112 Support building wheels (PEP-427)
47c5d73 Imported Translations from Transifex
3041689 Fix coverage testing
04752ee Imported Translations from Transifex
26edee1 Use same indentation in doc/source/usage
12f14da Imported Translations from Transifex
c9f2b63 Imported Translations from Transifex
af4fc2c Updated from global requirements
efbe658 Remove unused/mutable default args
f721da7 Fixes a small syntax error in the doc examples
0624f8d Work toward Python 3.4 support and testing

openstack/oslo.messaging  1.4.1..HEAD (new release: 1.5.0)

a5ffc62 Updated from global requirements
ee6a729 Imported Translations from Transifex
973301a rabbit: uses kombu instead of builtin stuffs
d9d04fb Allows to overriding oslotest environ var
0d49793 Create ZeroMQ Context per socket
7306680 Remove unuseful param of the ConnectionContext
442d8b9 Updated from global requirements
5aadc56 Add basic tests for 0mq matchmakers
7ea4147 Updated from global requirements
37e5e2a Fix tiny typo in server.py
10eb120 Switch to oslo.middleware
a3ca0e5 Updated from global requirements
6f76039 Activate pep8 check that _ is imported
f43fe66 Enable user authentication in the AMQP 1.0 driver
f74014a Documentation anomaly in TransportURL parse classmethod
f61f7c5 Don't put the message payload into warning log
70910e0 Updated from global requirements
6857db1 Add pbr to installation requirements
0088ac9 Updated from global requirements
f1afac4 Add driver independent functional tests
a476b2e Imported Translations from Transifex
db2709e zmq: Remove dead code
a87aa3e Updated from global requirements
3dd6a23 Finish transition to oslo.i18n
969847d Imported Translations from Transifex
63a5f1c Imported Translations from Transifex
1640cc1 qpid: Always auto-delete queue of DirectConsumer
6b405b9 Updated from global requirements
d4e64d8 Imported Translations from Transifex
487bbf5 Enable oslo.i18n for oslo.messaging
8d242bd Switch to oslo.serialization
f378009 Cleanup listener after stopping rpc server
5fd9845 Updated from global requirements
ed88623 Track the attempted method when raising UnsupportedVersion
93283f2 fix memory leak for function _safe_log
2478675 Stop using importutils 

Re: [openstack-dev] [oslo] proposed library releases for next week

2014-11-21 Thread Sean Dague
On 11/21/2014 11:19 AM, Doug Hellmann wrote:
 We have a backlog of changes in many of the Oslo libraries, so I would like 
 to cut releases early next week. Please look over the list below and speak up 
 if there are known issues that would prevent us from releasing these libs on 
 Monday or Tuesday of next week. Patches still in the review queue can wait 
 for the next batch of releases, so let’s focus on what’s in already.

Given that the short change logs are pretty hard to parse, would it be
possible to also provide the diffstat of each release, as well as the
actual requirements diff (which seems to be a non negligible amount of
the changes, and the one with terrible change strings).

I think that with the oslo.db last release the changelog didn't really
express clearly enough what was changing.

 
 Doug
 
 
 openstack/cliff  1.8.0..HEAD (new release: 1.9.0)
 
 f6e9bbd print the real error cmd argument
 a5fd24d Updated from global requirements
 
 openstack/oslo.concurrency  0.2.0..HEAD (new release: 0.3.0)
 
 3bda65c Allow for providing a customized semaphore container
 656f908 Move locale files to proper place
 faa30f8 Flesh out the README
 bca4a0d Move out of the oslo namespace package
 58de317 Improve testing in py3 environment
 fa52a63 Only modify autoindex.rst if it exists
 63e618b Imported Translations from Transifex
 d5ea62c lockutils-wrapper cleanup
 78ba143 Don't use variables that aren't initialized
 
 openstack/oslo.config 1.4.0..HEAD (new release: 1.5.0)
 
 7ab3326 Updated from global requirements
 c81dc30 Updated from global requirements
 4a15ea3 Fix class constant indentation
 5d5faeb Updated from global requirements
 d6b0ee6 Activate pep8 check that _ is imported
 73635ef Updated from global requirements
 cf94a51 Updated from global requirements
 e906e74 Updated from global requirements
 0a7abd0 Add some guidance for group names
 e0ad7fa delay formatting debug log message
 f7c54d9 Check config default value is correct type
 41770ad Report permission denied when parsing config
 5ada833 Fix docs example using generator config files
 e82f6bb Updated from global requirements
 fa458ee do not use colons in section titles
 2af57e5 Stop using intersphinx
 a736da3 Fixed typo in docstring for _get_config_dirs
 ba6486a Update contributing instructions
 70fc459 Add missing newline to stderr output when argument value is wrong
 
 openstack/oslo.db  1.1.0..HEAD (new release: 1.2.0)
 
 10e8d15 Add table name to foreign keys diff
 ddd11df Updated from global requirements
 2269848 Handle Galera deadlock on SELECT FOR UPDATE
 4b2058b Add exception filter for _sqlite_dupe_key_error
 7f755bf Ensure is_backend_avail() doesn't leave open connections
 c54d3a9 Updated from global requirements
 2099177 Add pbr to installation requirements
 135701b Fix python3.x scoping issues with removed 'de’ variable
 
 openstack/oslo.i18n  1.0.0..HEAD (new release: 1.1.0)
 
 5a163eb Imported Translations from Transifex
 1fc63ac Add note for integration modules in libraries
 2fe3f73 Activate pep8 check that _ is imported
 d67767b Add pbr to installation requirements
 3583c89 Updated from global requirements
 497f8d3 Updated from global requirements
 624c52c Remove extraneous vim editor configuration comments
 9b6a9c2 Make clear in docs to use _LE() when using LOG.exception()
 999a112 Support building wheels (PEP-427)
 47c5d73 Imported Translations from Transifex
 3041689 Fix coverage testing
 04752ee Imported Translations from Transifex
 26edee1 Use same indentation in doc/source/usage
 12f14da Imported Translations from Transifex
 c9f2b63 Imported Translations from Transifex
 af4fc2c Updated from global requirements
 efbe658 Remove unused/mutable default args
 f721da7 Fixes a small syntax error in the doc examples
 0624f8d Work toward Python 3.4 support and testing
 
 openstack/oslo.messaging  1.4.1..HEAD (new release: 1.5.0)
 
 a5ffc62 Updated from global requirements
 ee6a729 Imported Translations from Transifex
 973301a rabbit: uses kombu instead of builtin stuffs
 d9d04fb Allows to overriding oslotest environ var
 0d49793 Create ZeroMQ Context per socket
 7306680 Remove unuseful param of the ConnectionContext
 442d8b9 Updated from global requirements
 5aadc56 Add basic tests for 0mq matchmakers
 7ea4147 Updated from global requirements
 37e5e2a Fix tiny typo in server.py
 10eb120 Switch to oslo.middleware
 a3ca0e5 Updated from global requirements
 6f76039 Activate pep8 check that _ is imported
 f43fe66 Enable user authentication in the AMQP 1.0 driver
 f74014a Documentation anomaly in TransportURL parse classmethod
 f61f7c5 Don't put the message payload into warning log
 70910e0 Updated from global requirements
 6857db1 Add pbr to installation requirements
 0088ac9 Updated from global requirements
 f1afac4 Add driver independent functional tests
 a476b2e Imported Translations from Transifex
 db2709e zmq: Remove dead code
 a87aa3e Updated from global requirements
 3dd6a23 Finish transition to oslo.i18n
 969847d Imported 

Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-21 Thread Jeremy Stanley
On 2014-11-21 07:31:36 -0500 (-0500), Donald Stufft wrote:
 You can’t. Bower doesn’t have “traditional” packages where you take a
 directory and archive it using tar/zip/whatever and then upload it to
 some repo. Bower has a registry which maps names to git URLs and then
 the bower CLI looks up that mapping, fetches the git repository and then
 uses that as the input to the “look at metadata and do stuff with files”
 part of the package manager instead of the output of an un-unarchival
 command.

This raises interesting free software philosophy/license
questions... how do I redistribute (or even examine) the source of
a bower-managed package? Is there a way without actually
reverse-engineering the toolchain?
-- 
Jeremy Stanley

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


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-21 Thread Donald Stufft

 On Nov 21, 2014, at 11:32 AM, Jeremy Stanley fu...@yuggoth.org wrote:
 
 On 2014-11-21 07:31:36 -0500 (-0500), Donald Stufft wrote:
 You can’t. Bower doesn’t have “traditional” packages where you take a
 directory and archive it using tar/zip/whatever and then upload it to
 some repo. Bower has a registry which maps names to git URLs and then
 the bower CLI looks up that mapping, fetches the git repository and then
 uses that as the input to the “look at metadata and do stuff with files”
 part of the package manager instead of the output of an un-unarchival
 command.
 
 This raises interesting free software philosophy/license
 questions... how do I redistribute (or even examine) the source of
 a bower-managed package? Is there a way without actually
 reverse-engineering the toolchain?

Well it’s a git repository, so you could just clone it and look at it.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


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


Re: [openstack-dev] wsme is missing dep on ipaddr

2014-11-21 Thread Jeremy Stanley
On 2014-11-20 21:12:33 -0600 (-0600), Matthew Thode wrote:
 https://github.com/stackforge/wsme/blob/0.6.2/setup.py (also in master)
[...]

Your message is terse so I'm not sure whether you're asking a
question, but:

if sys.version_info[:2]  (3, 3):
install_requires += ('ipaddr',)

That should pull in ipaddr on Python earlier than 3.3. If you were
running into an ipaddr-related issue with WSME 0.6.2 then it was
likely the problem described at:

http://lists.openstack.org/pipermail/openstack-dev/2014-November/051058.html

The current versions should now be fine in that regard.
-- 
Jeremy Stanley

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


Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

2014-11-21 Thread Jeremy Stanley
On 2014-11-21 09:38:00 -0500 (-0500), Doug Hellmann wrote:
 The patch drops support entirely, but as Brant points out that
 isn’t backwards-compatible. I’d be interested to hear from the
 security team about whether the security issues trump the
 backwards compatibility issues here or if we should maintain
 optional support (that is, allow v3 if we detect that we can use
 it because the symbol is present). 
 
 Thomas, can you get one or two of the security team to comment on
 the patch?

The discussion in https://launchpad.net/bugs/1381365 is relevant to
this topic.
-- 
Jeremy Stanley

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


Re: [openstack-dev] [oslo] proposed library releases for next week

2014-11-21 Thread Doug Hellmann

On Nov 21, 2014, at 11:25 AM, Sean Dague s...@dague.net wrote:

 On 11/21/2014 11:19 AM, Doug Hellmann wrote:
 We have a backlog of changes in many of the Oslo libraries, so I would like 
 to cut releases early next week. Please look over the list below and speak 
 up if there are known issues that would prevent us from releasing these libs 
 on Monday or Tuesday of next week. Patches still in the review queue can 
 wait for the next batch of releases, so let’s focus on what’s in already.
 
 Given that the short change logs are pretty hard to parse, would it be
 possible to also provide the diffstat of each release, as well as the
 actual requirements diff (which seems to be a non negligible amount of
 the changes, and the one with terrible change strings).
 
 I think that with the oslo.db last release the changelog didn't really
 express clearly enough what was changing.

Yeah, I’ve been looking for ways to improve the release notes. In this case I 
expected the library maintainers to know what the changes meant, but more 
detail is better. The report comes from a script in 
openstack/oslo-incubator/tools, which I’ve been updating this morning 
(https://review.openstack.org/#/c/136401/). If anyone has suggestions for other 
info to add, please let me know.

Doug



openstack/cliff  1.8.0..HEAD

f6e9bbd print the real error cmd argument
a5fd24d Updated from global requirements

  diffstat (except test files):

 cliff/commandmanager.py| 3 ++-
 requirements.txt   | 2 +-
 3 files changed, 5 insertions(+), 2 deletions(-)

  Requirements updates:

 diff --git a/requirements.txt b/requirements.txt
 index 4d3ccc9..bf06e82 100644
 --- a/requirements.txt
 +++ b/requirements.txt
 @@ -10 +10 @@ six=1.7.0
 -stevedore=0.14
 +stevedore=1.1.0  # Apache-2.0

openstack/oslo.concurrency  0.2.0..HEAD

3bda65c Allow for providing a customized semaphore container
656f908 Move locale files to proper place
faa30f8 Flesh out the README
bca4a0d Move out of the oslo namespace package
58de317 Improve testing in py3 environment
fa52a63 Only modify autoindex.rst if it exists
63e618b Imported Translations from Transifex
d5ea62c lockutils-wrapper cleanup
78ba143 Don't use variables that aren't initialized

  diffstat (except test files):

 .gitignore |   1 +
 README.rst |   4 +-
 doc/source/conf.py |  23 +-
 .../locale/en_GB/LC_MESSAGES/oslo.concurrency.po   |  16 +-
 oslo.concurrency/locale/oslo.concurrency.pot   |  16 +-
 oslo/concurrency/__init__.py   |  29 ++
 oslo/concurrency/_i18n.py  |  32 --
 oslo/concurrency/fixture/__init__.py   |  13 +
 oslo/concurrency/fixture/lockutils.py  |  51 --
 oslo/concurrency/lockutils.py  | 376 --
 oslo/concurrency/openstack/__init__.py |   0
 oslo/concurrency/openstack/common/__init__.py  |   0
 oslo/concurrency/openstack/common/fileutils.py | 146 --
 oslo/concurrency/opts.py   |  45 --
 oslo/concurrency/processutils.py   | 340 
 oslo_concurrency/__init__.py   |   0
 oslo_concurrency/_i18n.py  |  32 ++
 oslo_concurrency/fixture/__init__.py   |   0
 oslo_concurrency/fixture/lockutils.py  |  51 ++
 oslo_concurrency/lockutils.py  | 423 +++
 oslo_concurrency/openstack/__init__.py |   0
 oslo_concurrency/openstack/common/__init__.py  |   0
 oslo_concurrency/openstack/common/fileutils.py | 146 ++
 oslo_concurrency/opts.py   |  45 ++
 oslo_concurrency/processutils.py   | 340 
 setup.cfg  |   9 +-
 tox.ini|   8 +-
 40 files changed, 3385 insertions(+), 2135 deletions(-)

  Requirements updates:

openstack/oslo.config  1.4.0..HEAD

7ab3326 Updated from global requirements
c81dc30 Updated from global requirements
4a15ea3 Fix class constant indentation
5d5faeb Updated from global requirements
d6b0ee6 Activate pep8 check that _ is imported
73635ef Updated from global requirements
cf94a51 Updated from global requirements
e906e74 Updated from global requirements
0a7abd0 Add some guidance for group names
e0ad7fa delay formatting debug log message
f7c54d9 Check config default value is correct type
41770ad Report permission denied when parsing config
5ada833 Fix docs example using generator config files
e82f6bb Updated from global requirements
fa458ee do not use colons in section titles
2af57e5 Stop using intersphinx
a736da3 Fixed typo in docstring for _get_config_dirs
ba6486a Update contributing instructions
70fc459 Add missing newline to stderr output when argument value is wrong

  diffstat (except test files):

 CONTRIBUTING.rst

Re: [openstack-dev] [nova] Proposal new hacking rules

2014-11-21 Thread Sahid Orentino Ferdjaoui
On Thu, Nov 20, 2014 at 02:00:11PM -0800, Joe Gordon wrote:
 On Thu, Nov 20, 2014 at 9:49 AM, Sahid Orentino Ferdjaoui 
 sahid.ferdja...@redhat.com wrote:
 
  This is something we can call nitpiking or low priority.
 
 
 This all seems like nitpicking for very little value. I think there are
 better things we can be focusing on instead of thinking of new ways to nit
 pick. So I am -1 on all of these.

Yes as written this is low priority but something necessary for a
project like Nova it is.

Considered that I feel sad to take your time. Can I suggest you to
take no notice of this and let's others developers working on Nova too
do this job ?

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


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-21 Thread Jeremy Stanley
On 2014-11-21 11:39:00 -0500 (-0500), Donald Stufft wrote:
 Well it’s a git repository, so you could just clone it and look at
 it.

Aha, your earlier description made it sound like Bower was a file
registry mapping to various random contents from a bunch of revision
control repositories to assemble any one package. If Bower packages
generally map back to one repository per package (even if there are
multiple packages per repository) then that seems much more sane to
deal with.
-- 
Jeremy Stanley

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


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-21 Thread Donald Stufft

 On Nov 21, 2014, at 11:57 AM, Jeremy Stanley fu...@yuggoth.org wrote:
 
 On 2014-11-21 11:39:00 -0500 (-0500), Donald Stufft wrote:
 Well it’s a git repository, so you could just clone it and look at
 it.
 
 Aha, your earlier description made it sound like Bower was a file
 registry mapping to various random contents from a bunch of revision
 control repositories to assemble any one package. If Bower packages
 generally map back to one repository per package (even if there are
 multiple packages per repository) then that seems much more sane to
 deal with.
 -- 
 Jeremy Stanley
 

Yea sorry, the bower registry (aka bower PyPI) is a mapping of name: git URL.


---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


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


[openstack-dev] [oslo] scheduling a review day

2014-11-21 Thread Doug Hellmann
We have a bit of a backlog in the Oslo review queue. Before we add a bunch of 
new reviews for Kilo work, I’d like to see if we can clear some of the existing 
reviews. One idea I had was setting aside a “review day”, where we spend a work 
day on reviews together, coordinating and doing fast turn-arounds via IRC. 

I know most of the team works on projects other than Oslo, including 
company-focused work, so I don’t think we want to try to go more than a day and 
that we would need time to coordinate other schedules to allow the time. How 
many people could/would participate in a review day like this on 4 December?

Doug


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


Re: [openstack-dev] [oslo] scheduling a review day

2014-11-21 Thread Julien Danjou
On Fri, Nov 21 2014, Doug Hellmann wrote:

 We have a bit of a backlog in the Oslo review queue. Before we add a bunch of
 new reviews for Kilo work, I’d like to see if we can clear some of the 
 existing
 reviews. One idea I had was setting aside a “review day”, where we spend a 
 work
 day on reviews together, coordinating and doing fast turn-arounds via IRC.

 I know most of the team works on projects other than Oslo, including
 company-focused work, so I don’t think we want to try to go more than a day 
 and
 that we would need time to coordinate other schedules to allow the time. How
 many people could/would participate in a review day like this on 4 December?

✋

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


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


Re: [openstack-dev] [oslo] scheduling a review day

2014-11-21 Thread Davanum Srinivas
Sounds good Doug.

-- dims

On Fri, Nov 21, 2014 at 12:07 PM, Doug Hellmann d...@doughellmann.com wrote:
 We have a bit of a backlog in the Oslo review queue. Before we add a bunch of 
 new reviews for Kilo work, I’d like to see if we can clear some of the 
 existing reviews. One idea I had was setting aside a “review day”, where we 
 spend a work day on reviews together, coordinating and doing fast 
 turn-arounds via IRC.

 I know most of the team works on projects other than Oslo, including 
 company-focused work, so I don’t think we want to try to go more than a day 
 and that we would need time to coordinate other schedules to allow the time. 
 How many people could/would participate in a review day like this on 4 
 December?

 Doug


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



-- 
Davanum Srinivas :: https://twitter.com/dims

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


Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

2014-11-21 Thread Donald Stufft

 On Nov 21, 2014, at 11:51 AM, Jeremy Stanley fu...@yuggoth.org wrote:
 
 On 2014-11-21 09:38:00 -0500 (-0500), Doug Hellmann wrote:
 The patch drops support entirely, but as Brant points out that
 isn’t backwards-compatible. I’d be interested to hear from the
 security team about whether the security issues trump the
 backwards compatibility issues here or if we should maintain
 optional support (that is, allow v3 if we detect that we can use
 it because the symbol is present). 
 
 Thomas, can you get one or two of the security team to comment on
 the patch?
 
 The discussion in https://launchpad.net/bugs/1381365 is relevant to
 this topic.
 -- 
 Jeremy Stanley
 

Death to SSLv3 IMO.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


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


[openstack-dev] [QA][Tempest] Proposing Ghanshyam Mann for Tempest Core

2014-11-21 Thread Matthew Treinish

Hi Everyone,

I'd like to propose we add Ghanshyam Mann (gmann) to the tempest core team. Over
the past couple of cycles Ghanshyam has been actively engaged in the Tempest
community. Ghanshyam has had one of the highest review counts on Tempest for
the past cycle, and he has consistently been providing reviews that have been
of consistently high quality that show insight into both the project internals
and it's future direction. I feel that Ghanshyam will make an excellent addition
to the core team.

As per the usual, if the current Tempest core team members would please vote +1
or -1(veto) to the nomination when you get a chance. We'll keep the polls open
for 5 days or until everyone has voted.

Thanks,

Matt Treinish

References:

https://review.openstack.org/#/q/reviewer:%22Ghanshyam+Mann+%253Cghanshyam.mann%2540nectechnologies.in%253E%22,n,z

http://stackalytics.com/?user_id=ghanshyammannmetric=marks



pgpimsNJi9SSk.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Proposal new hacking rules

2014-11-21 Thread Joe Gordon
On Fri, Nov 21, 2014 at 8:57 AM, Sahid Orentino Ferdjaoui 
sahid.ferdja...@redhat.com wrote:

 On Thu, Nov 20, 2014 at 02:00:11PM -0800, Joe Gordon wrote:
  On Thu, Nov 20, 2014 at 9:49 AM, Sahid Orentino Ferdjaoui 
  sahid.ferdja...@redhat.com wrote:
 
   This is something we can call nitpiking or low priority.
  
 
  This all seems like nitpicking for very little value. I think there are
  better things we can be focusing on instead of thinking of new ways to
 nit
  pick. So I am -1 on all of these.

 Yes as written this is low priority but something necessary for a
 project like Nova it is.


Why do you think this is necessary?


 Considered that I feel sad to take your time. Can I suggest you to
 take no notice of this and let's others developers working on Nova too
 do this job ?


As the maintainer of openstack-dev/hacking and as a nova core, I don't
think this is worth doing at all. Nova already has enough on its plate and
doesn't need extra code to review.


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

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


[openstack-dev] [neutron] L3 agent restructuring notes

2014-11-21 Thread Paul Michali (pcm)
Hi,

I talked to Carl today to discuss the L3 agent restructuring and the change set 
I had published (https://review.openstack.org/#/c/135392/), which was trying to 
identify/exposing what is needed for the loading of device drivers and the 
variation therein. I wasn’t sure how we’d do the separation of the agents and 
wanted to discuss the options and brainstorm on some ideas on how to do this.

We had a very good talk and here are some notes of what we were thinking (Carl, 
chime in, if I missed anything or I’m interpreting them differently):

First step could be to create a service abstract class, and then child classes 
for the various services to use these as “observers/subscribers” to the L3 
agent. The base class would have no-operation methods for each action that the 
L3 agent could notify about, and the child classes could (later) hold service 
specific logic. The base class would include a “register” method, so that a 
service can register for notification from the L3 agent (mapping to these 
methods created). The child classes would do service specific loading of device 
drivers.

Currently, the L3 agent (and VPN agent) load the device drivers for services. 
What can be done in this first step, is, instead of doing the load, a service 
object can be created. This object would do the loading and register with the 
L3 agent for notifications.


Second step could be to populate the child services’ notification handlers, for 
any methods of interest to those services. Involves taking methods that are in 
the various agent classes and move them into the new service child classes, and 
adapt as needed.


Third step could be to create a abstract factory (or factory method), which the 
L3 agent would call at startup, instead of it creating the service instances. 
This factory would determine what services are enabled (one way is to see if 
service_provider config entry for the service type), and then create the 
service instance, which in turn would load the device driver and register with 
the L3 agent. This way, the L3 agent no longer knows about the services.

This would imply no longer having separate VPN agent process, and instead, all 
the service instances would be created by the factory. It would change the way 
DevStack would start up things (e.g. only starting up the L3 agent process).


Fourth step (optional) could be to create new config file entries so that a 
common device driver loader could be created, instead of service specific 
loaders. This is more of a post refactor cleanup activity.

Some other thoughts:

Should strive to keep the config and start-up the same initially (and as much 
as possible).
Initially, the services will get an L3 agent passed in on create, but in the 
future, a router instance can be provided to the service.
Using ABC for observer, so that services only have to implement the desired 
methods of interest.
Thoughts were to do notification handlers (step 2) before factory (step 3), so 
that service is extracted, before changing startup.
Hope that gives an idea of what we were thinking about for this chinese finger 
puzzle (https://www.youtube.com/watch?v=k8BSiyDs0nw)

Regards,


PCM (Paul Michali)

MAIL …..…. p...@cisco.com
IRC ……..… pc_m (irc.freenode.com)
TW ………... @pmichali
GPG Key … 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83






signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

2014-11-21 Thread Thomas Goirand
On 11/21/2014 10:38 PM, Doug Hellmann wrote:
 
 On Nov 21, 2014, at 4:56 AM, Thomas Goirand z...@debian.org wrote:
 
 Hi,

 Trying to rebuild Neutron Juno in Sid, I get so many of these failures:

 Traceback (most recent call last):
  File
 /home/zigo/sources/openstack/juno/neutron/build-area/neutron-2014.2/neutron/tests/unit/agent/linux/test_ovs_lib.py,
 line 137, in setUp
super(OVS_Lib_Test, self).setUp()
  File
 /home/zigo/sources/openstack/juno/neutron/build-area/neutron-2014.2/neutron/tests/base.py,
 line 128, in setUp
self.setup_rpc_mocks()
  File
 /home/zigo/sources/openstack/juno/neutron/build-area/neutron-2014.2/neutron/tests/base.py,
 line 150, in setup_rpc_mocks
self.messaging_conf = messaging_conffixture.ConfFixture(CONF)
  File /usr/lib/python2.7/dist-packages/oslo/messaging/conffixture.py,
 line 48, in __init__
'oslo.messaging._drivers.impl_rabbit', 'rabbit_opts')
  File /usr/lib/python2.7/dist-packages/oslo/messaging/conffixture.py,
 line 24, in _import_opts
__import__(module)
  File
 /usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py,
 line 420, in module
class Connection(object):
  File
 /usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py,
 line 497, in Connection
sslv3: ssl.PROTOCOL_SSLv3
 AttributeError: 'module' object has no attribute 'PROTOCOL_SSLv3'

 Having a deeper look into the issue, I saw the following changelog in
 Python 2.7 (this was uploaded 3 days ago in Sid):

  * Allow building and testing without SSLv3 support (Kurt Roeckx).
Closes: #768611.

 Having a closer look at oslo.messaging reveals this in
 oslo/messaging/_drivers/impl_rabbit.py:

_SSL_PROTOCOLS = {
tlsv1: ssl.PROTOCOL_TLSv1,
sslv23: ssl.PROTOCOL_SSLv23,
sslv3: ssl.PROTOCOL_SSLv3
}

 Removing the last line (which makes the PROTOCOL_SSLv3 not used anymore)
 fixed the build of Neutron.

 Obviously, what happened in Debian is that Kurt Roeckx, the maintainer
 of openssl, removed support for SSLv3, because of potential security
 issues (downgrade attacks), which were revealed by the infamous POODLE bug.

 Obviously also, we shall remove PROTOCOL_SSLv3 from one of the possible
 options in oslo.messaging.

 I thought this deserved explanations so that the review here can be
 understood better:
 https://review.openstack.org/136278
 
 The patch drops support entirely, but as Brant points out that isn’t 
 backwards-compatible. I’d be interested to hear from the security team about 
 whether the security issues trump the backwards compatibility issues here or 
 if we should maintain optional support (that is, allow v3 if we detect that 
 we can use it because the symbol is present). 
 
 Thomas, can you get one or two of the security team to comment on the patch?
 
 Doug

Do you mean the Debian security team? Or the OpenStack one?

For Debian, what happened is that Kurt, who maintains OpenSSL in Debian,
simply disabled it. He sent a patch for Python to make build and work
without SSLv3 support in OpenSSL. So I believe that in Debian, we want
SSLv3 to be completely gone. It is my view as well that we shouldn't
continue to support it at all.

Also, SSLv3 is in oslo-incubator (in all branches, including master,
stable/juno and stable/icehouse). We should remove it completely from
there as well, or at least allow it to work without it in Python (that
is, without ssl.PROTOCOL_SSLv3 being defined).

I don't really mind if we continue to allow it, but at least we should
move fast to have oslo-incubator fixed. I will need to do something fast
for Icehouse in Sid/Jessie, as we're in freeze mode. Best would be to
have the issue resolved before the next point release (currently set for
May 14 2015).

Cheers,

Thomas Goirand (zigo)


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


Re: [openstack-dev] [nova] Proposal new hacking rules

2014-11-21 Thread Matthew Treinish
On Fri, Nov 21, 2014 at 10:30:59AM -0800, Joe Gordon wrote:
 On Fri, Nov 21, 2014 at 8:57 AM, Sahid Orentino Ferdjaoui 
 sahid.ferdja...@redhat.com wrote:
 
  On Thu, Nov 20, 2014 at 02:00:11PM -0800, Joe Gordon wrote:
   On Thu, Nov 20, 2014 at 9:49 AM, Sahid Orentino Ferdjaoui 
   sahid.ferdja...@redhat.com wrote:
  
This is something we can call nitpiking or low priority.
   
  
   This all seems like nitpicking for very little value. I think there are
   better things we can be focusing on instead of thinking of new ways to
  nit
   pick. So I am -1 on all of these.
 
  Yes as written this is low priority but something necessary for a
  project like Nova it is.
 
 
 Why do you think this is necessary?
 
 
  Considered that I feel sad to take your time. Can I suggest you to
  take no notice of this and let's others developers working on Nova too
  do this job ?
 
 
 As the maintainer of openstack-dev/hacking and as a nova core, I don't
 think this is worth doing at all. Nova already has enough on its plate and
 doesn't need extra code to review.
 

I tend to agree, also hacking rules are there to reduce the mental load of
reviewers so that they have less to worry about doing a review. Honestly, none
of these proposals seem like anything a reviewer should ever worry about in the
first place, let alone a reason to -1 a patch. (either automatically with a rule
or manually)


pgp89v3VuxZ0N.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

2014-11-21 Thread Doug Hellmann

On Nov 21, 2014, at 1:53 PM, Thomas Goirand tho...@goirand.fr wrote:

 On 11/21/2014 10:38 PM, Doug Hellmann wrote:
 
 On Nov 21, 2014, at 4:56 AM, Thomas Goirand z...@debian.org wrote:
 
 Hi,
 
 Trying to rebuild Neutron Juno in Sid, I get so many of these failures:
 
 Traceback (most recent call last):
 File
 /home/zigo/sources/openstack/juno/neutron/build-area/neutron-2014.2/neutron/tests/unit/agent/linux/test_ovs_lib.py,
 line 137, in setUp
   super(OVS_Lib_Test, self).setUp()
 File
 /home/zigo/sources/openstack/juno/neutron/build-area/neutron-2014.2/neutron/tests/base.py,
 line 128, in setUp
   self.setup_rpc_mocks()
 File
 /home/zigo/sources/openstack/juno/neutron/build-area/neutron-2014.2/neutron/tests/base.py,
 line 150, in setup_rpc_mocks
   self.messaging_conf = messaging_conffixture.ConfFixture(CONF)
 File /usr/lib/python2.7/dist-packages/oslo/messaging/conffixture.py,
 line 48, in __init__
   'oslo.messaging._drivers.impl_rabbit', 'rabbit_opts')
 File /usr/lib/python2.7/dist-packages/oslo/messaging/conffixture.py,
 line 24, in _import_opts
   __import__(module)
 File
 /usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py,
 line 420, in module
   class Connection(object):
 File
 /usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py,
 line 497, in Connection
   sslv3: ssl.PROTOCOL_SSLv3
 AttributeError: 'module' object has no attribute 'PROTOCOL_SSLv3'
 
 Having a deeper look into the issue, I saw the following changelog in
 Python 2.7 (this was uploaded 3 days ago in Sid):
 
 * Allow building and testing without SSLv3 support (Kurt Roeckx).
   Closes: #768611.
 
 Having a closer look at oslo.messaging reveals this in
 oslo/messaging/_drivers/impl_rabbit.py:
 
   _SSL_PROTOCOLS = {
   tlsv1: ssl.PROTOCOL_TLSv1,
   sslv23: ssl.PROTOCOL_SSLv23,
   sslv3: ssl.PROTOCOL_SSLv3
   }
 
 Removing the last line (which makes the PROTOCOL_SSLv3 not used anymore)
 fixed the build of Neutron.
 
 Obviously, what happened in Debian is that Kurt Roeckx, the maintainer
 of openssl, removed support for SSLv3, because of potential security
 issues (downgrade attacks), which were revealed by the infamous POODLE bug.
 
 Obviously also, we shall remove PROTOCOL_SSLv3 from one of the possible
 options in oslo.messaging.
 
 I thought this deserved explanations so that the review here can be
 understood better:
 https://review.openstack.org/136278
 
 The patch drops support entirely, but as Brant points out that isn’t 
 backwards-compatible. I’d be interested to hear from the security team about 
 whether the security issues trump the backwards compatibility issues here or 
 if we should maintain optional support (that is, allow v3 if we detect that 
 we can use it because the symbol is present). 
 
 Thomas, can you get one or two of the security team to comment on the patch?
 
 Doug
 
 Do you mean the Debian security team? Or the OpenStack one?

Sorry, I meant the OpenStack team.

 
 For Debian, what happened is that Kurt, who maintains OpenSSL in Debian,
 simply disabled it. He sent a patch for Python to make build and work
 without SSLv3 support in OpenSSL. So I believe that in Debian, we want
 SSLv3 to be completely gone. It is my view as well that we shouldn't
 continue to support it at all.
 
 Also, SSLv3 is in oslo-incubator (in all branches, including master,
 stable/juno and stable/icehouse). We should remove it completely from
 there as well, or at least allow it to work without it in Python (that
 is, without ssl.PROTOCOL_SSLv3 being defined).

We’re in the process of removing sslutils from the incubator entirely. 
https://review.openstack.org/#/c/126505/

 
 I don't really mind if we continue to allow it, but at least we should
 move fast to have oslo-incubator fixed. I will need to do something fast
 for Icehouse in Sid/Jessie, as we're in freeze mode. Best would be to
 have the issue resolved before the next point release (currently set for
 May 14 2015).

Sure. See my comments on your current review for what I think we need to do to 
handle the backwards-compatibility issues more clearly.

Doug

 
 Cheers,
 
 Thomas Goirand (zigo)
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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


Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

2014-11-21 Thread Jeremy Stanley
On 2014-11-21 12:31:08 -0500 (-0500), Donald Stufft wrote:
 Death to SSLv3 IMO.

Sure, we should avoid releasing new versions of things which assume
SSLv3 support is present in underlying libraries/platforms (it's
unclear to me why anyone even thought it was good to make that
configurable to this degree in openstack-common, but it probably
dates back to before the nova common split). But what we're talking
about here is fixing a deployability/usability bug where the
software is assuming the presence of something removed from a
dependency on some platform. I'd rather not conflate it with
knee-jerk SSLv3 Bad rhetoric which risks giving casual readers the
impression there's some vulnerability here.

Ceasing to assume the presence of SSLv3 support is a safe choice for
the software in question. Forcing changes to stable branches for
this should be taken on its merits as a normal bug, and not
prioritized because of any perceived security impact.
-- 
Jeremy Stanley


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


Re: [openstack-dev] [Neutron] DB: transaction isolation and related questions

2014-11-21 Thread Jay Pipes
Eugene, I just spent about an hour playing around with an example 
scenario in both MySQL and PostgreSQL using READ COMMITTED and 
REPEATABLE READ isolation levels. The scenario I used had a single row 
being updated, with a loop and a check on rows affected.


*You are 100% correct that setting the transaction isolation level to 
READ COMMITTED works in the retry loop*.


I stand corrected, and humbled :) Please accept my apologies.

One thing I did note, though, is that changing the isolation level of an 
*already-started transaction* does not change the current transaction's 
isolation level -- the new isolation level only takes effect once the 
previously started transaction is committed or rolled back. So, on line 
107 in your proposed patch here:


https://review.openstack.org/#/c/129288/5/neutron/plugins/ml2/drivers/helpers.py

From what I could find out in my research, the setting of the isolation 
level needs to be done *outside* of the session.begin() call, otherwise 
the isolation level will not take effect until that transaction is 
committed or rolled back. Of course, if SQLAlchemy is doing some 
auto-commit or something in the session, then you may not see this 
affect, but I certainly was able to see this in my testing in mysql 
client sessions... so I'm a little perplexed as to how your code works 
on already-started transactions. The documentation on the MySQL site 
backs up what I observed:


http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html

...the statement sets the default transaction level for all subsequent 
transactions performed within the current session.


All the best, and thanks for the informative lesson of the week!
-jay

On 11/21/2014 03:24 AM, Eugene Nikanorov wrote:

Comments inline:

On Thu, Nov 20, 2014 at 4:34 AM, Jay Pipes jaypi...@gmail.com
mailto:jaypi...@gmail.com wrote:



So while the SELECTs may return different data on successive calls
when you use the READ COMMITTED isolation level, the UPDATE
statements will continue to return 0 rows affected **if they attempt
to change rows that have been changed since the start of the
transaction**

The reason that changing the isolation level to READ COMMITTED
appears to work for the code in question:


https://github.com/openstack/__neutron/blob/master/neutron/__plugins/ml2/drivers/helpers.__py#L98

https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/helpers.py#L98

is likely because the SELECT ... LIMIT 1 query is returning a
different row on successive attempts (though since there is no ORDER
BY on the query, the returned row of the query is entirely
unpredictable (line 112)). Since data from that returned row is used
in the UPDATE statement (line 118 and 124), *different* rows are
actually being changed by successive UPDATE statements.


Not really, we're updating the same row we've selected. It's ensured by
'raw_segment' which actually contains 'gre_id' (or similar) attribute.
So in each iteration we're working with the same row, but in different
iterations READ COMMITTED allows us to see different data and hence work
with a different row.


What this means is that for this *very particular* case, setting the
transaction isolation level to READ COMMITTTED will work presumably
most of the time on MySQL, but it's not an appropriate solution for
the generalized problem domain of the SELECT FOR UPDATE. If you need
to issue a SELECT and an UPDATE in a retry loop, and you are
attempting to update the same row or rows (for instance, in the
quota reservation or resource allocation scenarios), this solution
will not work, even with READ COMMITTED. This is why I say it's not
really appropriate, and a better general solution is to use separate
transactions for each loop in the retry mechanic.

By saying 'this solution will not work' what issues do you mean what
exactly?
Btw, I agree on using separate transaction for each loop, the problem is
that transaction is usually not 'local' to the method where the retry
loop resides.



The issue is about doing the retry within a single transaction.
That's not what I recommend doing. I recommend instead doing short
separate transactions instead of long-lived, multi-statement
transactions and relying on the behaviour of the DB's isolation
level (default or otherwise) to solve the problem of reading
changes to a record that you intend to update.

 instead of long-lived, multi-statement transactions - that's really
what would require quite large code redesign.
So far finding a way to bring retry logic upper to the stack of nesting
transactions seems more appropriate.

Thanks,
Eugene.


Cheers,
-jay

Also, thanks Clint for clarification about example scenario
described by
Mike Bayer.
Initially the issue was discovered with concurrent tests on
multi master
environment with galera as 

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

2014-11-21 Thread Stephen Balukoff
I think the idea was to implement 1:1 initially to reduce the amount of
code and operational complexity we'd have to deal with in initial revisions
of LBaaS v2. Many to many can be simulated in this scenario, though it does
shift the burden of maintenance to the end user. It does greatly simplify
the initial code for v2, in any case, though.

Did we ever agree to allowing listeners to be shared among load balancers?
I think that still might be a N:1 relationship even in our latest models.

There's also the difficulty introduced by supporting different flavors:
 Since flavors are essentially an association between a load balancer
object and a driver (with parameters), once flavors are introduced, any
sub-objects of a given load balancer objects must necessarily be purely
logical until they are associated with a load balancer.  I know there was
talk of forcing these objects to be sub-objects of a load balancer which
can't be accessed independently of the load balancer (which would have much
the same effect as what you discuss: State / status only make sense once
logical objects have an instantiation somewhere.) However, the currently
proposed API treats most objects as root objects, which breaks this
paradigm.

How we handle status and updates once there's an instantiation of these
logical objects is where we start getting into real complexity.

It seems to me there's a lot of complexity introduced when we allow a lot
of many to many relationships without a whole lot of benefit in real-world
deployment scenarios. In most cases, objects are not going to be shared,
and in those cases with sufficiently complicated deployments in which
shared objects could be used, the user is likely to be sophisticated enough
and skilled enough to manage updating what are essentially copies of
objects, and would likely have an opinion about how individual failures
should be handled which wouldn't necessarily coincide with what we
developers of the system would assume. That is to say, allowing too many
many to many relationships feels like a solution to a problem that doesn't
really exist, and introduces a lot of unnecessary complexity.

In any case, though, I feel like we should walk before we run: Implementing
1:1 initially is a good idea to get us rolling. Whether we then implement
1:N or M:N after that is another question entirely. But in any case, it
seems like a bad idea to try to start with M:N.

Stephen


On Thu, Nov 20, 2014 at 4:52 AM, Samuel Bercovici samu...@radware.com
wrote:

 Hi,

 Per discussion I had at OpenStack Summit/Paris with Brandon and Doug, I
 would like to remind everyone why we choose to follow a model where pools
 and listeners are shared (many to many relationships).

 Use Cases:
 1. The same application is being exposed via different LB objects.
 For example: users coming from the internal private organization
 network, have an LB1(private_VIP) -- Listener1(TLS) --Pool1 and user
 coming from the internet, have LB2(public_vip)--Listener1(TLS)--Pool1.
 This may also happen to support ipv4 and ipv6: LB_v4(ipv4_VIP) --
 Listener1(TLS) --Pool1 and LB_v6(ipv6_VIP) -- Listener1(TLS) --Pool1
 The operator would like to be able to manage the pool membership in cases
 of updates and error in a single place.

 2. The same group of servers is being used via different listeners
 optionally also connected to different LB objects.
 For example: users coming from the internal private organization
 network, have an LB1(private_VIP) -- Listener1(HTTP) --Pool1 and user
 coming from the internet, have LB2(public_vip)--Listener2(TLS)--Pool1.
 The LBs may use different flavors as LB2 needs TLS termination and may
 prefer a different stronger flavor.
 The operator would like to be able to manage the pool membership in cases
 of updates and error in a single place.

 3. The same group of servers is being used in several different
 L7_Policies connected to a listener. Such listener may be reused as in use
 case 1.
 For example: LB1(VIP1)--Listener_L7(TLS)
 |
 +--L7_Policy1(rules..)--Pool1
 |
 +--L7_Policy2(rules..)--Pool2
 |
 +--L7_Policy3(rules..)--Pool1
 |

 +--L7_Policy3(rules..)--Reject


 I think that the key issue handling correctly the provisioning state
 and the operation state in a many to many model.
 This is an issue as we have attached status fields to each and every
 object in the model.
 A side effect of the above is that to understand the
 provisioning/operation status one needs to check many different objects.

 To remedy this, I would like to turn all objects besides the LB to be
 logical objects. This means that the only place to manage the status/state
 will be on the LB object.
 Such status should be 

Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-21 Thread Fox, Kevin M
Simply having a git repository does not imply that its source.

In fact, if its considered compiled (minified), I'm thinking the debian rules 
would prevent sourcing from it?

Thanks,
Kevin

From: Donald Stufft [don...@stufft.io]
Sent: Friday, November 21, 2014 8:39 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Horizon] the future of angularjs development  
in Horizon

 On Nov 21, 2014, at 11:32 AM, Jeremy Stanley fu...@yuggoth.org wrote:

 On 2014-11-21 07:31:36 -0500 (-0500), Donald Stufft wrote:
 You can’t. Bower doesn’t have “traditional” packages where you take a
 directory and archive it using tar/zip/whatever and then upload it to
 some repo. Bower has a registry which maps names to git URLs and then
 the bower CLI looks up that mapping, fetches the git repository and then
 uses that as the input to the “look at metadata and do stuff with files”
 part of the package manager instead of the output of an un-unarchival
 command.

 This raises interesting free software philosophy/license
 questions... how do I redistribute (or even examine) the source of
 a bower-managed package? Is there a way without actually
 reverse-engineering the toolchain?

Well it’s a git repository, so you could just clone it and look at it.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


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

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


Re: [openstack-dev] [all] Scale out bug-triage by making it easier for people to contribute

2014-11-21 Thread Joe Gordon
On Tue, Nov 18, 2014 at 11:48 PM, Flavio Percoco fla...@redhat.com wrote:

 On 18/11/14 14:45 -0800, Joe Gordon wrote:



 On Tue, Nov 18, 2014 at 10:58 AM, Clint Byrum cl...@fewbar.com wrote:

Excerpts from Flavio Percoco's message of 2014-11-17 08:46:19 -0800:
 Greetings,

 Regardless of how big/small bugs backlog is for each project, I
 believe this is a common, annoying and difficult problem. At the oslo
 meeting today, we're talking about how to address our bug triage
 process and I proposed something that I've seen done in other
 communities (rust-language [0]) that I consider useful and a good
 option for OpenStack too.

 The process consist in a bot that sends an email to every *volunteer*
 with 10 bugs to review/triage for the week. Each volunteer follows
 the
 triage standards, applies tags and provides information on whether
 the
 bug is still valid or not. The volunteer doesn't have to fix the bug,
 just triage it.

 In openstack, we could have a job that does this and then have people
 from each team volunteer to help with triage. The benefits I see are:

 * Interested folks don't have to go through the list and filter the
 bugs they want to triage. The bot should be smart enough to pick the
 oldest, most critical, etc.

 * It's a totally opt-in process and volunteers can obviously ignore
 emails if they don't have time that week.

 * It helps scaling out the triage process without poking people
 around
 and without having to do a call for volunteers every
 meeting/cycle/etc

 The above doesn't solve the problme completely but just like reviews,
 it'd be an optional, completely opt-in process that people can sign
 up
 for.


My experience in Ubuntu, where we encouraged non-developers to triage
bugs, was that non-developers often ask the wrong questions and
sometimes even harm the process by putting something in the wrong
priority or state because of a lack of deep understanding.

Triage in a hospital is done by experienced nurses and doctors working
together, not triagers. This is because it may not always be obvious
to somebody just how important a problem is. We have the same set of
problems. The most important thing is that developers see it as an
important task and take part. New volunteers should be getting involved
at every level, not just bug triage.


 ++, nice analogy.

 Another problem I have seen, is we need to constantly re-triage bugs, as
 just
 because a bug was marked as confirmed 6 months ago doesn't mean it is
 still
 valid.


 Ideally, the script will take care of this. Bugs that haven't been
 update for more than N months will fall into the to-triage pool for
 re-triage.


I am willing to sign up and give this a try.



 Flavio





I think the best approach to this, like reviews, is to have a place
where users can go to drive the triage workload to 0. For instance, the
ubuntu server team had this report for triage:

http://reqorts.qa.ubuntu.com/reports/ubuntu-server/triage-report.html

Sadly, it looks like they're overwhelmed or have abandoned the effort
(I hope this doesn't say something about Ubuntu server itself..), but
the basic process was to move bugs off these lists. I'm sure if we ask
nice the author of that code will share it with us and we could adapt
it for OpenStack projects.

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



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



 --
 @flaper87
 Flavio Percoco

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


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


Re: [openstack-dev] [Neutron] DB: transaction isolation and related questions

2014-11-21 Thread Mike Bayer
regardless, I’d still very much prefer isolation being set here in an explicit 
fashion and on a per-transaction basis, rather than across the board, if a 
method is known to require it.   The advantage of this is that the isolation 
level in general can be changed without any risk of the individual method’s 
isolation level changing, because it is explicit.  It also serves as a document 
as to the intricacies of a certain method.

I’d favor adding markers for isolation level into my decorators outlined in 
https://review.openstack.org/#/c/125181/.   The system will be tailored in such 
a way that it is settable on a per-backend basis, or otherwise in some agnostic 
fashion, either:


@sql.writer(mysql_isolation=‘READ COMMITTED’)
def some_api_method(context):

or:

@sql.writer(effective_isolation=‘READ COMMITTED')
def some_api_method(context):

where in the latter case, steps will be taken behind the scenes on a 
per-dialect basis to ensure the effect is present as much as possible, else (if 
say using SQLite) a warning would be emitted.

I believe if we can set this up in a visible and explicit way it will be a lot 
more robust for those methods which contain retry logic that is sensitive to 
isolation level.




 On Nov 21, 2014, at 2:35 PM, Jay Pipes jaypi...@gmail.com wrote:
 
 Eugene, I just spent about an hour playing around with an example scenario in 
 both MySQL and PostgreSQL using READ COMMITTED and REPEATABLE READ isolation 
 levels. The scenario I used had a single row being updated, with a loop and a 
 check on rows affected.
 
 *You are 100% correct that setting the transaction isolation level to READ 
 COMMITTED works in the retry loop*.
 
 I stand corrected, and humbled :) Please accept my apologies.
 
 One thing I did note, though, is that changing the isolation level of an 
 *already-started transaction* does not change the current transaction's 
 isolation level -- the new isolation level only takes effect once the 
 previously started transaction is committed or rolled back. So, on line 107 
 in your proposed patch here:
 
 https://review.openstack.org/#/c/129288/5/neutron/plugins/ml2/drivers/helpers.py
 
 From what I could find out in my research, the setting of the isolation level 
 needs to be done *outside* of the session.begin() call, otherwise the 
 isolation level will not take effect until that transaction is committed or 
 rolled back. Of course, if SQLAlchemy is doing some auto-commit or something 
 in the session, then you may not see this affect, but I certainly was able to 
 see this in my testing in mysql client sessions... so I'm a little perplexed 
 as to how your code works on already-started transactions. The documentation 
 on the MySQL site backs up what I observed:
 
 http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html
 
 ...the statement sets the default transaction level for all subsequent 
 transactions performed within the current session.
 
 All the best, and thanks for the informative lesson of the week!
 -jay
 
 On 11/21/2014 03:24 AM, Eugene Nikanorov wrote:
 Comments inline:
 
 On Thu, Nov 20, 2014 at 4:34 AM, Jay Pipes jaypi...@gmail.com
 mailto:jaypi...@gmail.com wrote:
 
 
 
So while the SELECTs may return different data on successive calls
when you use the READ COMMITTED isolation level, the UPDATE
statements will continue to return 0 rows affected **if they attempt
to change rows that have been changed since the start of the
transaction**
 
The reason that changing the isolation level to READ COMMITTED
appears to work for the code in question:
 

 https://github.com/openstack/__neutron/blob/master/neutron/__plugins/ml2/drivers/helpers.__py#L98

 https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/helpers.py#L98
 
is likely because the SELECT ... LIMIT 1 query is returning a
different row on successive attempts (though since there is no ORDER
BY on the query, the returned row of the query is entirely
unpredictable (line 112)). Since data from that returned row is used
in the UPDATE statement (line 118 and 124), *different* rows are
actually being changed by successive UPDATE statements.
 
 
 Not really, we're updating the same row we've selected. It's ensured by
 'raw_segment' which actually contains 'gre_id' (or similar) attribute.
 So in each iteration we're working with the same row, but in different
 iterations READ COMMITTED allows us to see different data and hence work
 with a different row.
 
 
What this means is that for this *very particular* case, setting the
transaction isolation level to READ COMMITTTED will work presumably
most of the time on MySQL, but it's not an appropriate solution for
the generalized problem domain of the SELECT FOR UPDATE. If you need
to issue a SELECT and an UPDATE in a retry loop, and you are
attempting to update the same row or rows (for instance, in the
quota reservation or resource 

Re: [openstack-dev] [Neutron] DB: transaction isolation and related questions

2014-11-21 Thread Eugene Nikanorov


 *You are 100% correct that setting the transaction isolation level to READ
 COMMITTED works in the retry loop*.

 I stand corrected, and humbled :) Please accept my apologies.

Thanks for letting me know :)



 One thing I did note, though, is that changing the isolation level of an
 *already-started transaction* does not change the current transaction's
 isolation level -- the new isolation level only takes effect once the
 previously started transaction is committed or rolled back. So, on line 107
 in your proposed patch here:

 https://review.openstack.org/#/c/129288/5/neutron/plugins/
 ml2/drivers/helpers.py

 From what I could find out in my research, the setting of the isolation
 level needs to be done *outside* of the session.begin() call, otherwise the
 isolation level will not take effect until that transaction is committed or
 rolled back.


You're right. Apparently I've misread sqlalchemy docs at some point. Now I
see I've understood them incorrectly.
Also, from some sqlalchemy code inspection I thought that default engine
isolation level is restored after current transaction is committed, but
it's not so as well.



 Of course, if SQLAlchemy is doing some auto-commit or something in the
 session, then you may not see this affect, but I certainly was able to see
 this in my testing in mysql client sessions... so I'm a little perplexed as
 to how your code works on already-started transactions. The documentation
 on the MySQL site backs up what I observed:

 http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html

 ...the statement sets the default transaction level for all subsequent
 transactions performed within the current session.


That basically means that my patch effectively changes isolation level of
every connection that happens to be used for the session.


 All the best, and thanks for the informative lesson of the week!


Thank you for getting to the very bottom of it! :)

Eugene.

-jay


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


[openstack-dev] Alembic 0.7.0 - hitting Pypi potentially Sunday night

2014-11-21 Thread Mike Bayer
Hi all -

I’d like to announce / give a prominent heads up that Alembic 0.7.0 is ready 
for release.  Over the past several weeks I’ve completed the initial 
implementations for two critical features, SQLite migrations and multiple 
branch/ merge support, as well as merged over a dozen bug fixes and smaller 
features.This release is probably the most dramatic set of changes Alembic 
has had since some early refactorings long before Openstack was making use of 
it, and as such I think it’s appropriate to make sure that this is anticipated.

Given that I’ve seen some grumbling about other projects recently releasing on 
weekends, assuming no new issues are found, I hope to release Alembic 0.7.0 on 
Sunday night or Monday.I have run a subset of Openstack related tests as is 
part of my usual continuous environment, including all of oslo.db (there’s one 
test fix for oslo.db pending) as well as Neutron’s 
“neutron.tests.unit.db.test_migration” which if I understand it correctly 
exercises Alembic considerably.

Version 0.7.0 includes a lot of tweaks and enhancements in the usual 
“autogenerate” category as well as to some operational directives, but most 
prominently includes multiple branch mode, a series of new commands and some 
changes to existing commands, as well as “batch mode” which is geared towards 
SQLite. The SQLite batch mode enhancement exists as a new operational 
directive and series of behaviors that are optional, so code which doesn’t make 
explicit use of it will not be exposed to the new code.  However the multiple 
branch/merge support involves a fundamental rewrite of the versioning system 
from the ground up.  It was implemented in such a way that there should be no 
backwards-compatibility problems of any kind - existing environments, script 
templates, migration scripts, and alembic_version tables will continue to work 
in the exact same manner as they did before, in the absence of using the newer 
branch features which introduces some mild changes to the workflow when used.   
But the system does run on a new set of algorithms for which the currently 
supported use case of a “single linear stream of revisions” is the so-called 
“degenerate” case (an odd term for me to use as I am so not a math person).   

The release does not yet include two new features that I’d like to get in a 
subsequent release, maybe even 0.7.1 if things go smoothly, including Ann 
Kamyshnikova’s foreign key constraint autogeneration feature and a separate 
autogeneration feature for primary key constraints.

To those out there wondering what steps to take, here they are:

1. read about the new features, particularly the branch support, and please let 
me know of any red flags/concerns you might have over the coming 
implementation, at 
http://alembic.readthedocs.org/en/latest/tutorial.html#running-batch-migrations-for-sqlite-and-other-databases
 and 
http://alembic.readthedocs.org/en/latest/tutorial.html#working-with-branches.

2. if your project uses Alembic already (I know Neutron does but I’m not sure 
who else yet), fire up a tox environment and install Alembic from master at 
https://github.com/zzzeek/alembic/, run the tests and please alert me to any 
breakages.

3. Keep a lookout for the release, and

4. don’t panic!   I’ve really tried to test this to a huge extent and if there 
are problems, I can fix them quickly.

thanks all for reading!

0.7 changelog: 
http://alembic.readthedocs.org/en/latest/changelog.html#change-0.7.0



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


Re: [openstack-dev] [QA][Tempest] Proposing Ghanshyam Mann for Tempest Core

2014-11-21 Thread Sean Dague
+1

On 11/21/2014 01:26 PM, Matthew Treinish wrote:
 
 Hi Everyone,
 
 I'd like to propose we add Ghanshyam Mann (gmann) to the tempest core team. 
 Over
 the past couple of cycles Ghanshyam has been actively engaged in the Tempest
 community. Ghanshyam has had one of the highest review counts on Tempest for
 the past cycle, and he has consistently been providing reviews that have been
 of consistently high quality that show insight into both the project internals
 and it's future direction. I feel that Ghanshyam will make an excellent 
 addition
 to the core team.
 
 As per the usual, if the current Tempest core team members would please vote 
 +1
 or -1(veto) to the nomination when you get a chance. We'll keep the polls open
 for 5 days or until everyone has voted.
 
 Thanks,
 
 Matt Treinish
 
 References:
 
 https://review.openstack.org/#/q/reviewer:%22Ghanshyam+Mann+%253Cghanshyam.mann%2540nectechnologies.in%253E%22,n,z
 
 http://stackalytics.com/?user_id=ghanshyammannmetric=marks
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova] Proposal new hacking rules

2014-11-21 Thread Sean Dague
On 11/21/2014 01:52 PM, Matthew Treinish wrote:
 On Fri, Nov 21, 2014 at 07:15:49PM +0100, jordan pittier wrote:
 Hey,
 I am not a Nova developer but I still have an opinion.

 Using boolean assertions
 I like what you propose. We should use and enforce the assert* that best 
 matches the intention. It's about semantic and the more precise we are, the 
 better.

 Using same order of arguments in equality assertions
 Why not. But I don't know how we can write a Hacking rule for this. So you 
 may fix all the occurrences for this now, but it might get back in the 
 future.
 
 Ok I'll bite, besides the enforceability issue which you pointed out, it just
 doesn't make any sense, you're asserting 2 things are equal: (A == B) == (B 
 == A)
 and I honestly feel that it goes beyond nitpicking because of that. 
 
 It's also a fallacy that there will always be an observed value and an
 expected value. For example:
 
   self.assertEqual(method_a(), method_b())
 
 Which one is observed and which one is expected? I think this proposal is just
 reading into the parameter names a bit too much.

If you are using assertEqual with 2 variable values... you are doing
your test wrong.

I was originally in your camp. But honestly, the error message provided
to the user does say expected and observed, and teaching everyone that
you have to ignore the error message is a much harder thing to do than
flip the code to conform to it, creating less confusion.

-Sean

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

2014-11-21 Thread Richard Jones
All the bower components I've used have included full source alongside any
minified versions.

On Sat, 22 Nov 2014 07:40 Fox, Kevin M kevin@pnnl.gov wrote:

 Simply having a git repository does not imply that its source.

 In fact, if its considered compiled (minified), I'm thinking the debian
 rules would prevent sourcing from it?

 Thanks,
 Kevin
 
 From: Donald Stufft [don...@stufft.io]
 Sent: Friday, November 21, 2014 8:39 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Horizon] the future of angularjs
 development  in Horizon

  On Nov 21, 2014, at 11:32 AM, Jeremy Stanley fu...@yuggoth.org wrote:
 
  On 2014-11-21 07:31:36 -0500 (-0500), Donald Stufft wrote:
  You can’t. Bower doesn’t have “traditional” packages where you take a
  directory and archive it using tar/zip/whatever and then upload it to
  some repo. Bower has a registry which maps names to git URLs and then
  the bower CLI looks up that mapping, fetches the git repository and then
  uses that as the input to the “look at metadata and do stuff with files”
  part of the package manager instead of the output of an un-unarchival
  command.
 
  This raises interesting free software philosophy/license
  questions... how do I redistribute (or even examine) the source of
  a bower-managed package? Is there a way without actually
  reverse-engineering the toolchain?

 Well it’s a git repository, so you could just clone it and look at it.

 ---
 Donald Stufft
 PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


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

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

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


Re: [openstack-dev] [all] OpenStack Bootstrapping Hour: Debugging in the Gate - Friday Nov 21st 20:00 UTC (15:00 Americas/New_York)

2014-11-21 Thread Sean Dague
On 11/18/2014 12:11 PM, Sean Dague wrote:
 This Friday's Bootstrapping Hour will be on Debugging in the Gate -
 https://wiki.openstack.org/wiki/BootstrappingHour/Debugging_Gate#Debugging_in_the_Gate
 
 The etherpad has the discussions notes I'll be using for it -
 https://etherpad.openstack.org/p/obh-debugging-openstack-gate
 
 For folks that can't make the event synchronously, it will be recorded
 and posted on youtube shortly after the event. Also, feel free to add to
 the Questions section at the end of the etherpad (with name please in
 case I want to get clarification prior to the broadcast). Will make sure
 to try to answer all questions written down during the broadcast.
 
   -Sean
 

The video is now up on youtube - https://www.youtube.com/watch?v=fowBDdLGBlU

Enjoy your weekend all.

-Sean

-- 
Sean Dague
http://dague.net

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


Re: [openstack-dev] [QA][Tempest] Proposing Ghanshyam Mann for Tempest Core

2014-11-21 Thread Masayuki Igawa
+1!

On 2014年11月22日(土) 3:29 Matthew Treinish mtrein...@kortar.org wrote:


 Hi Everyone,

 I'd like to propose we add Ghanshyam Mann (gmann) to the tempest core
 team. Over
 the past couple of cycles Ghanshyam has been actively engaged in the
 Tempest
 community. Ghanshyam has had one of the highest review counts on Tempest
 for
 the past cycle, and he has consistently been providing reviews that have
 been
 of consistently high quality that show insight into both the project
 internals
 and it's future direction. I feel that Ghanshyam will make an excellent
 addition
 to the core team.

 As per the usual, if the current Tempest core team members would please
 vote +1
 or -1(veto) to the nomination when you get a chance. We'll keep the polls
 open
 for 5 days or until everyone has voted.

 Thanks,

 Matt Treinish

 References:

 https://review.openstack.org/#/q/reviewer:%22Ghanshyam+Mann+
 %253Cghanshyam.mann%2540nectechnologies.in%253E%22,n,z

 http://stackalytics.com/?user_id=ghanshyammannmetric=marks

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

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


Re: [openstack-dev] [nova] Proposal new hacking rules

2014-11-21 Thread Matthew Treinish
On Fri, Nov 21, 2014 at 04:15:07PM -0500, Sean Dague wrote:
 On 11/21/2014 01:52 PM, Matthew Treinish wrote:
  On Fri, Nov 21, 2014 at 07:15:49PM +0100, jordan pittier wrote:
  Hey,
  I am not a Nova developer but I still have an opinion.
 
  Using boolean assertions
  I like what you propose. We should use and enforce the assert* that best 
  matches the intention. It's about semantic and the more precise we are, 
  the better.
 
  Using same order of arguments in equality assertions
  Why not. But I don't know how we can write a Hacking rule for this. So you 
  may fix all the occurrences for this now, but it might get back in the 
  future.
  
  Ok I'll bite, besides the enforceability issue which you pointed out, it 
  just
  doesn't make any sense, you're asserting 2 things are equal: (A == B) == (B 
  == A)
  and I honestly feel that it goes beyond nitpicking because of that. 
  
  It's also a fallacy that there will always be an observed value and an
  expected value. For example:
  
self.assertEqual(method_a(), method_b())
  
  Which one is observed and which one is expected? I think this proposal is 
  just
  reading into the parameter names a bit too much.
 
 If you are using assertEqual with 2 variable values... you are doing
 your test wrong.
 
 I was originally in your camp. But honestly, the error message provided
 to the user does say expected and observed, and teaching everyone that
 you have to ignore the error message is a much harder thing to do than
 flip the code to conform to it, creating less confusion.
 

Uhm, no it doesn't, the default error message is A != B. [1][2][3] (both with
unittest and testtools) If the error message was like that, then sure saying
one way was right over the other would be fine, (assuming you didn't specify a
different error message) but, that's not what it does.


[1] 
https://github.com/testing-cabal/testtools/blob/master/testtools/testcase.py#L340
[2] 
https://github.com/testing-cabal/testtools/blob/master/testtools/matchers/_basic.py#L85
 
[3] https://hg.python.org/cpython/file/301d62ef5c0b/Lib/unittest/case.py#l508


pgp9OcDwSQb6e.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] wsme is missing dep on ipaddr

2014-11-21 Thread Matthew Thode
On 11/21/2014 10:42 AM, Jeremy Stanley wrote:
 On 2014-11-20 21:12:33 -0600 (-0600), Matthew Thode wrote:
 https://github.com/stackforge/wsme/blob/0.6.2/setup.py (also in master)
 [...]
 
 Your message is terse so I'm not sure whether you're asking a
 question, but:
 
 if sys.version_info[:2]  (3, 3):
 install_requires += ('ipaddr',)
 
 That should pull in ipaddr on Python earlier than 3.3. If you were
 running into an ipaddr-related issue with WSME 0.6.2 then it was
 likely the problem described at:
 
 http://lists.openstack.org/pipermail/openstack-dev/2014-November/051058.html
 
 The current versions should now be fine in that regard.
 

Ah, must have totally missed that, thanks :D

-- 
-- Matthew Thode

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


Re: [openstack-dev] [QA][Tempest] Proposing Ghanshyam Mann for Tempest Core

2014-11-21 Thread Christopher Yeoh
+1

Sent from my iPad

 On 22 Nov 2014, at 4:56 am, Matthew Treinish mtrein...@kortar.org wrote:
 
 
 Hi Everyone,
 
 I'd like to propose we add Ghanshyam Mann (gmann) to the tempest core team. 
 Over
 the past couple of cycles Ghanshyam has been actively engaged in the Tempest
 community. Ghanshyam has had one of the highest review counts on Tempest for
 the past cycle, and he has consistently been providing reviews that have been
 of consistently high quality that show insight into both the project internals
 and it's future direction. I feel that Ghanshyam will make an excellent 
 addition
 to the core team.
 
 As per the usual, if the current Tempest core team members would please vote 
 +1
 or -1(veto) to the nomination when you get a chance. We'll keep the polls open
 for 5 days or until everyone has voted.
 
 Thanks,
 
 Matt Treinish
 
 References:
 
 https://review.openstack.org/#/q/reviewer:%22Ghanshyam+Mann+%253Cghanshyam.mann%2540nectechnologies.in%253E%22,n,z
 
 http://stackalytics.com/?user_id=ghanshyammannmetric=marks
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


Re: [openstack-dev] [QA][Tempest] Proposing Ghanshyam Mann for Tempest Core

2014-11-21 Thread Ken1 Ohmichi
+1 :-)

Sent from my iPod

On 2014/11/22, at 7:56, Christopher Yeoh cbky...@gmail.com wrote:

 +1
 
 Sent from my iPad
 
 On 22 Nov 2014, at 4:56 am, Matthew Treinish mtrein...@kortar.org wrote:
 
 
 Hi Everyone,
 
 I'd like to propose we add Ghanshyam Mann (gmann) to the tempest core team. 
 Over
 the past couple of cycles Ghanshyam has been actively engaged in the Tempest
 community. Ghanshyam has had one of the highest review counts on Tempest for
 the past cycle, and he has consistently been providing reviews that have been
 of consistently high quality that show insight into both the project 
 internals
 and it's future direction. I feel that Ghanshyam will make an excellent 
 addition
 to the core team.
 
 As per the usual, if the current Tempest core team members would please vote 
 +1
 or -1(veto) to the nomination when you get a chance. We'll keep the polls 
 open
 for 5 days or until everyone has voted.
 
 Thanks,
 
 Matt Treinish
 
 References:
 
 https://review.openstack.org/#/q/reviewer:%22Ghanshyam+Mann+%253Cghanshyam.mann%2540nectechnologies.in%253E%22,n,z
 
 http://stackalytics.com/?user_id=ghanshyammannmetric=marks
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


Re: [openstack-dev] Alembic 0.7.0 - hitting Pypi potentially Sunday night

2014-11-21 Thread Kevin Benton
This is great! I'm not sure if you have been following some of the
discussion about the separation of vendor drivers in Neutron, but one of
the things we decided was to leave the vendor data models in the main repo
so we have a nice linear migration.
It looks like branching support may solve our problem. However, looking
through the docs I didn't notice anything about where the migration
definitions need to live. Can migrations be sourced from multiple locations
easily?

is the so-called “degenerate” case (an odd term for me to use as I am so
not a math person).

I was always under the impression we used that term to make the person that
came up with the original use-case feel bad. :-)



On Fri, Nov 21, 2014 at 1:10 PM, Mike Bayer mba...@redhat.com wrote:

 Hi all -

 I’d like to announce / give a prominent heads up that Alembic 0.7.0 is
 ready for release.  Over the past several weeks I’ve completed the initial
 implementations for two critical features, SQLite migrations and multiple
 branch/ merge support, as well as merged over a dozen bug fixes and smaller
 features.This release is probably the most dramatic set of changes
 Alembic has had since some early refactorings long before Openstack was
 making use of it, and as such I think it’s appropriate to make sure that
 this is anticipated.

 Given that I’ve seen some grumbling about other projects recently
 releasing on weekends, assuming no new issues are found, I hope to release
 Alembic 0.7.0 on Sunday night or Monday.I have run a subset of
 Openstack related tests as is part of my usual continuous environment,
 including all of oslo.db (there’s one test fix for oslo.db pending) as well
 as Neutron’s “neutron.tests.unit.db.test_migration” which if I understand
 it correctly exercises Alembic considerably.

 Version 0.7.0 includes a lot of tweaks and enhancements in the usual
 “autogenerate” category as well as to some operational directives, but most
 prominently includes multiple branch mode, a series of new commands and
 some changes to existing commands, as well as “batch mode” which is geared
 towards SQLite. The SQLite batch mode enhancement exists as a new
 operational directive and series of behaviors that are optional, so code
 which doesn’t make explicit use of it will not be exposed to the new code.
 However the multiple branch/merge support involves a fundamental rewrite of
 the versioning system from the ground up.  It was implemented in such a way
 that there should be no backwards-compatibility problems of any kind -
 existing environments, script templates, migration scripts, and
 alembic_version tables will continue to work in the exact same manner as
 they did before, in the absence of using the newer branch features which
 introduces some mild changes to the workflow when used.   But the system
 does run on a new set of algorithms for which the currently supported use
 case of a “single linear stream of revisions” is the so-called “degenerate”
 case (an odd term for me to use as I am so not a math person).

 The release does not yet include two new features that I’d like to get in
 a subsequent release, maybe even 0.7.1 if things go smoothly, including Ann
 Kamyshnikova’s foreign key constraint autogeneration feature and a separate
 autogeneration feature for primary key constraints.

 To those out there wondering what steps to take, here they are:

 1. read about the new features, particularly the branch support, and
 please let me know of any red flags/concerns you might have over the coming
 implementation, at
 http://alembic.readthedocs.org/en/latest/tutorial.html#running-batch-migrations-for-sqlite-and-other-databases
 and
 http://alembic.readthedocs.org/en/latest/tutorial.html#working-with-branches
 .

 2. if your project uses Alembic already (I know Neutron does but I’m not
 sure who else yet), fire up a tox environment and install Alembic from
 master at https://github.com/zzzeek/alembic/, run the tests and please
 alert me to any breakages.

 3. Keep a lookout for the release, and

 4. don’t panic!   I’ve really tried to test this to a huge extent and if
 there are problems, I can fix them quickly.

 thanks all for reading!

 0.7 changelog:
 http://alembic.readthedocs.org/en/latest/changelog.html#change-0.7.0



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




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


Re: [openstack-dev] Alembic 0.7.0 - hitting Pypi potentially Sunday night

2014-11-21 Thread Mike Bayer

 On Nov 21, 2014, at 7:35 PM, Kevin Benton blak...@gmail.com wrote:
 
 This is great! I'm not sure if you have been following some of the discussion 
 about the separation of vendor drivers in Neutron, but one of the things we 
 decided was to leave the vendor data models in the main repo so we have a 
 nice linear migration.
 It looks like branching support may solve our problem. However, looking 
 through the docs I didn't notice anything about where the migration 
 definitions need to live. Can migrations be sourced from multiple locations 
 easily?

that’s another TODO, which is  
https://bitbucket.org/zzzeek/alembic/issue/124/multiple-versions-directories 
https://bitbucket.org/zzzeek/alembic/issue/124/multiple-versions-directories. 
  Skip down to the bottom comments as for the longest time I wasn’t really 
getting how this would work b.c. the multiple branch thing wasn’t in place.

Without that issue and even without the branching thing, you can, right now, 
have multiple alembic environments entirely separately, sharing only the 
alembic.ini file, in which you refer to each environment by name, which is what 
I was getting at in this issue up earlier.   Within one database they can have 
separate alembic_version tables using version_table_name.  That means that each 
environment has its own set of revisions entirely independent of each other, so 
if there are cross dependencies between these streams, then this approach 
doesn’t work.

With multiple branches in one revision stream as is provided with the new 
feature, now you have the ability to have cross-dependencies between these 
streams, if needed.   But that means they need to share the env.py since that’s 
the invocation for them, and needs to be able to run any of those scripts.

Having a single env.py as we do now, and just being able to put the actual 
revision files in multiple places, is very easy, even for Sunday, if we say 
that we can stick with the single base script_directory, one env.py and one 
home base, and then just load the actual revision files from multiple places.   
This would be trivial.



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


[openstack-dev] [Fuel] Fuel Plugins, First look; Whats Next?

2014-11-21 Thread Andrew Woodward
So as part of the pumphouse integration, I've started poking around
the Plugin Arch implementation as an attempt to plug it into the fuel
master.

This would require that the plugin install a container, and some
scripts into the master node.

First look:
I've looked over the fuel plugins spec [1] and see that the install
script was removed from rev 15 -16 (line 134) This creates problems
do to the need of installing the container, and scripts so I've
created a bug [2] for this so that we can allow for an install script
to be executed prior to HCF for 6.0.

Looking into the implementation of the install routine [3] to
implement [2], I see that the fuelclient is extracting the tar blindly
(more on that at #3) on the executor system that fuelclient is being
executed from. Problems with this include 1) the fuelclient may not
root be privileged (like in Mirantis OpenStack Express) 2) the
fuelclient may not be running on the same system as nailgun 3) we are
just calling .extractall on the tarball, this means that we haven't
done any validation on the files coming out of the tarball. We need to
validate that 3.a) the tarball was actually encoded with the right
base path 3.b) that the tasks.yaml file is validated and all the noted
scripts are found. Really, the install of the plugin should be handled
by the nailgun side to help with 1,2.

Whats next?
There are many parts of PA that need to be extended, I think that
these are the ones that we must tackle next to cover the most cases
a) plugin packaging: it appears that non of the core plugins (those
in fuel-plugins) are bundled into the iso.
b) plugin signing: we cant have core plugins with out some method of
testing, certifying, and signing them so that we can know that they
are trusted.

with the help of granular roles:
c) the ability to replace or add new granular roles
d) the ability to add or modify real roles

with the help of advanced networks:
e) add new network roles

At some point soon, we also need to discuss making it easier to find a
catalog of modules and pull them from it, but this is less important
than the above

[1] 
https://review.openstack.org/#/c/125608/15..16/specs/6.0/cinder-neutron-plugins-in-fuel.rst
[2] https://bugs.launchpad.net/fuel/+bug/1395228
[3] 
https://github.com/stackforge/fuel-web/blob/master/fuelclient/fuelclient/objects/plugins.py#L49

-- 
Andrew
Mirantis
Ceph community

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


Re: [openstack-dev] No PROTOCOL_SSLv3 in Python 2.7 in Sid since 3 days

2014-11-21 Thread Robert Collins
On 22 November 2014 08:11, Jeremy Stanley fu...@yuggoth.org wrote:
 On 2014-11-21 12:31:08 -0500 (-0500), Donald Stufft wrote:
 Death to SSLv3 IMO.

 Sure, we should avoid releasing new versions of things which assume
 SSLv3 support is present in underlying libraries/platforms (it's
 unclear to me why anyone even thought it was good to make that
 configurable to this degree in openstack-common, but it probably
 dates back to before the nova common split). But what we're talking
 about here is fixing a deployability/usability bug where the
 software is assuming the presence of something removed from a
 dependency on some platform. I'd rather not conflate it with
 knee-jerk SSLv3 Bad rhetoric which risks giving casual readers the
 impression there's some vulnerability here.

 Ceasing to assume the presence of SSLv3 support is a safe choice for
 the software in question. Forcing changes to stable branches for
 this should be taken on its merits as a normal bug, and not
 prioritized because of any perceived security impact.

Given the persistent risks of downgrade attacks, I think this does
actually qualify as a security issue: not that its breaking,but that
SSLv3 is advertised and accepted anywhere.

The lines two lower:
try:
_SSL_PROTOCOLS[sslv2] = ssl.PROTOCOL_SSLv2
except AttributeError:
pass

Are even more concerning!

That said, code like:
https://github.com/mpaladin/python-amqpclt/blob/master/amqpclt/kombu.py#L101

is truely egregious!

:)

-Rob

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

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