[openstack-dev] [Neutron] Bug day

[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
   
   - 811 Open bugs 
   - 331 In-progress bugs
   



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

[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 
mailto:tnapier...@mirantis.com>> wrote:



On 06 Nov 2014, at 12:20, Przemyslaw Kaminski
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 







___
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 master monitoring

[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 
mailto:tnapier...@mirantis.com>> wrote:



On 06 Nov 2014, at 12:20, Przemyslaw Kaminski
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 







___
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] [Neutron] DB: transaction isolation and related questions

[Eugene Nikanorov]

Comments inline:

On Thu, Nov 20, 2014 at 4:34 AM, Jay Pipes  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 > > wrote:
>>
>>
>>  On Nov 19, 2014, at 3:47 PM, Ryan Moats >> > 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”.
>>>

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

[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

[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

[Thomas Goirand]

On 11/21/2014 01:51 PM, Richard Jones wrote:
> On 21 November 2014 16:12, Thomas Goirand  > 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

[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
 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 
> wrote:
>>
>>
>> On 06 Nov 2014, at 12:20, Przemyslaw Kaminski 
>> 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

[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

[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
 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
>  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 
>> wrote:
>>>
>>>
>>> On 06 Nov 2014, at 12:20, Przemyslaw Kaminski 
>>> 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

[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



On Fri, Nov 21, 2014 at 9:38 AM,  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

[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

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

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

[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  wrote:

>
>
> - Original Message -
> From: Chhavi Kant/TVM/TCS 
> 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

[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
 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
 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 
wrote:


On 06 Nov 2014, at 12:20, Przemyslaw Kaminski 
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

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

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

[Donald Stufft]

> On Nov 21, 2014, at 3:59 AM, Thomas Goirand  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

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

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

[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  wrote:
>> From: Doug Hellmann [d...@doughellmann.com] Thursday, November 20, 2014 3:51 
>> PM
>>> On Nov 20, 2014, at 8:12 AM, Sandy Walsh  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

[Doug Hellmann]

On Nov 20, 2014, at 4:39 PM, Matthew Treinish  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

[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 
mailto: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, 
mailto: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
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

_

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

[Doug Hellmann]

On Nov 21, 2014, at 4:56 AM, Thomas Goirand  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 
>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?

[Doug Hellmann]

On Nov 21, 2014, at 9:11 AM, Sandy Walsh  wrote:

>> From: Doug Hellmann [d...@doughellmann.com] Thursday, November 20, 2014 5:09 
>> PM
>> On Nov 20, 2014, at 3:40 PM, Sandy Walsh  wrote:
>>> From: Doug Hellmann [d...@doughellmann.com] Thursday, November 20, 2014 
>>> 3:51 PM
 On Nov 20, 2014, at 8:12 AM, Sandy Walsh  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

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

[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] [Fuel] Fuel extension with VXLAN support

[Andrew Woodward]

Samuel,

As Vladimir noted, moving the br-mgmt assignment will be covered by
https://blueprints.launchpad.net/fuel/+spec/advanced-networking


On Fri, Nov 21, 2014 at 6:22 AM,   wrote:
> 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 
> 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,  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
> 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
>
> _
>
> 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/cg

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

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

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

[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

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

[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

[Dmitry Pyzhov]

We have a request  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

[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

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

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

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

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

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

[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

[Donald Stufft]

> On Nov 21, 2014, at 11:32 AM, Jeremy Stanley  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

[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

[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

[Doug Hellmann]

On Nov 21, 2014, at 11:25 AM, Sean Dague  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

[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

[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

[Donald Stufft]

> On Nov 21, 2014, at 11:57 AM, Jeremy Stanley  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

[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

[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

[Davanum Srinivas]

Sounds good Doug.

-- dims

On Fri, Nov 21, 2014 at 12:07 PM, 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?
>
> 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

[Donald Stufft]

> On Nov 21, 2014, at 11:51 AM, Jeremy Stanley  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

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

[Tomasz Napierala]

> On 21 Nov 2014, at 17:15, Aleksandr Didenko  wrote:
> 
> 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).

I totally agree, but we need to remember to introduce tests in separate 
commits, otherwise loosing commit ID we would also lose tests ;)

Also I’m just wondering how do we keep upstream modules in our repo? They are 
not submodules, so how is it organized?

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

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

[Tomasz Napierala]

> On 21 Nov 2014, at 16:55, Dmitry Pyzhov  wrote:
> 
> We have a request 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.

I agree with the change, but it shouldn’t be high

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

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

[jordan pittier]

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.

>Using LOG.warn instead of LOG.warning
I am -1 on this. The part that comes after LOG. (LOG.warning, LOG.error, 
LOG.debug, etc) is the log level, it's not a verb. In syslog, the well-known 
log level is "warning" so the correct method to use here is, imo, log.warning().

Have you concidered submitting this hacking rules to the hacking project here : 
https://github.com/openstack-dev/hacking ? I am sure these new rules makes 
sense on other openstack projects.

Jordan  

- Original Message -
From: "Sahid Orentino Ferdjaoui" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Friday, November 21, 2014 5:57:14 PM
Subject: Re: [openstack-dev] [nova] Proposal new hacking rules

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

___
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

[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=ghanshyammann&metric=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

[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

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

[David Kranz]

+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=ghanshyammann&metric=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] [oslo] scheduling a review day

[Flavio Percoco]

On 21/11/14 12:07 -0500, 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?



I'll probably be AFK on December 4th and 5th, can it be on December
3rd ?

Either way, I'm in. I'll do my best to be there on the 4th if it can't
be changed.

Cheers,
Flavio


--
@flaper87
Flavio Percoco


pgpT4i5vkB5ge.pgp
Description: PGP signature
___
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

[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

[Thomas Goirand]

On 11/21/2014 10:38 PM, Doug Hellmann wrote:
> 
> On Nov 21, 2014, at 4:56 AM, Thomas Goirand  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 
>>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

[Matthew Treinish]

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.


> 
> >Using LOG.warn instead of LOG.warning
> I am -1 on this. The part that comes after LOG. (LOG.warning, LOG.error, 
> LOG.debug, etc) is the log level, it's not a verb. In syslog, the well-known 
> log level is "warning" so the correct method to use here is, imo, 
> log.warning().
> 
> Have you concidered submitting this hacking rules to the hacking project here 
> : https://github.com/openstack-dev/hacking ? I am sure these new rules makes 
> sense on other openstack projects.
> 
> Jordan  
> 
> - Original Message -
> From: "Sahid Orentino Ferdjaoui" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Sent: Friday, November 21, 2014 5:57:14 PM
> Subject: Re: [openstack-dev] [nova] Proposal new hacking rules
> 
> 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 ?
> 



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

[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] Status of Neutron IPv6 dual stack

[Harm Weites]

Hi,

We're running Juno since a few weeks now, is it now possible to go dual
stack with l3-routers or are there some pieces missing and should I wait
for Kilo?

-Harm

On 08/19/2014 07:08 PM, Dane Leblanc (leblancd) wrote:
>
> Hi Harm:
>
>  
>
> Unfortunately I haven’t had time to complete the changes yet. Even
> if/when these changes are completed, it’s unlikely that this blueprint
> will get approved for Juno, but I’ll see what I can do.
>
>  
>
> Thanks,
>
> Dane
>
>  
>
>  
>
> *From:*Harm Weites [mailto:h...@weites.com]
> *Sent:* Tuesday, August 19, 2014 12:53 PM
> *To:* openstack-dev@lists.openstack.org
> *Subject:* Re: [openstack-dev] Status of Neutron IPv6 dual stack
>
>  
>
> Thiago,
>
> My old setup was dual-stacked, simply using a flat linuxbridge. It's
> just that I now realy would like to separate multiple tenants using L3
> routers, which should be easy (dual stacked) to achieve once Dane's
> work is completed.
>
> Did you find the time to commit those required changes for that yet Dane?
>
> Regards,
> Harm
>
> op 16-08-14 23:33, Martinx - ジェームズ schreef:
>
> Guys,
>
>  
>
> Just for the record, I'm using IceHouse in a Dual-Stacked
> environment (with security groups working) but, Instance's IPv6
> address are static (no upstream SLAAC, arrived in Juno-2, I think)
> and the topology is `VLAN Provider Networks`, no Neutron L3
> Router. Where each VLAN have v4/v6 addrs, same upstream router
> (also dual-stacked - still no radvd enabled).
>
>  
>
> Looking forward to start testing L3 + IPv6 in K...
>
>  
>
> Best,
>
> Thiago
>
>  
>
> On 16 August 2014 16:21, Harm Weites  > wrote:
>
> Hi Dane,
>
> Thanks, that looks promising. Once support for multiple v6
> addresses on
> gateway ports is added I'll be happy to give this a go. Should it work
> just fine with an otherwise Icehouse based deployment?
>
> Regards,
> Harm
>
> op 16-08-14 20:31, Dane Leblanc (leblancd) schreef:
>
> > Hi Harm:
> >
> > Can you take a look at the following, which should address this:
> >   
>  https://blueprints.launchpad.net/neutron/+spec/multiple-ipv6-prefixes
> >
> > There are some diffs out for review for this blueprint:
> >https://review.openstack.org/#/c/113339/
> > but the change to support 1 V4 + multiple V6 addresses on a
> gateway port hasn't been added yet. I should be adding this soon.
> >
> > There was a request for a Juno feature freeze exception for this
> blueprint, but there's been no response, so this may not get
> approved until K release.
> >
> > -Dane
> >
> > -Original Message-
> > From: Harm Weites [mailto:h...@weites.com ]
> > Sent: Saturday, August 16, 2014 2:22 PM
> > To: openstack-dev@lists.openstack.org
> 
> > Subject: [openstack-dev] Status of Neutron IPv6 dual stack
> >
> > Hi,
> >
> > Given the work on [1] has been abandoned, I'm wondering what the
> current status of going dual stack is. Of course, given Neutron
> got something like that on it's roadmap.
> >
> > The initial BP [2] aimed for Havana and Icehouse, and I'm
> unaware of something similar to achieve a dual stack network. What
> are the options, if any? To my knowledge it all comes down to
> supporting multiple exterior interfaces (networks) on a l3-agent,
> which is currently limited to just 1: either IP4 or IP6.
> >
> > [1] https://review.openstack.org/#/c/77471/
> > [2]
> >
> 
> https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port
> >
> > Regards,
> > Harm
> >
> > ___
> > 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

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

[Doug Hellmann]

On Nov 21, 2014, at 1:53 PM, Thomas Goirand  wrote:

> On 11/21/2014 10:38 PM, Doug Hellmann wrote:
>> 
>> On Nov 21, 2014, at 4:56 AM, Thomas Goirand  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 
>>>   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

[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] [oslo] scheduling a review day

[Doug Hellmann]

On Nov 21, 2014, at 1:43 PM, Flavio Percoco  wrote:

> On 21/11/14 12:07 -0500, 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?
>> 
> 
> I'll probably be AFK on December 4th and 5th, can it be on December
> 3rd ?
> 
> Either way, I'm in. I'll do my best to be there on the 4th if it can't
> be changed.

I was trying to avoid overlapping with the infra team sprint on the 3rd because 
I was going to try to contribute there.

We could try a 2 day sprint, but I thought it might be easier to convince 
managers to let people do a single day and I’d like as many people on at the 
same time as we can get. Let’s see what some of the other cores say, and if we 
need to move it we’ll move it earlier.

Doug

> 
> Cheers,
> Flavio
> 
> 
> -- 
> @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

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



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 back

Re: [openstack-dev] [Zaqar][all] Getting rid of queues: Feedback needed

[Victoria Martínez de la Cruz]

Thanks for starting this Flavio! I'm also interested in hearing the
community opinion on this regard.

IMO this will be a complex but positive change since the concept of 'topic'
fit more the use cases Zaqar aims to cover.

Looking forward to hear your comments on this.

Thanks!

2014-11-17 10:43 GMT-03:00 Flavio Percoco :

> greed that it may be a good time to do so.
> The metadata field will still be k
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

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

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

[Joe Gordon]

On Tue, Nov 18, 2014 at 11:48 PM, Flavio Percoco  wrote:

> On 18/11/14 14:45 -0800, Joe Gordon wrote:
>
>>
>>
>> On Tue, Nov 18, 2014 at 10:58 AM, Clint Byrum  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

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

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

[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

[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

[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=ghanshyammann&metric=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

[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

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

[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

[Masayuki Igawa]

+1!

On 2014年11月22日(土) 3:29 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=ghanshyammann&metric=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

[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

[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

[Christopher Yeoh]

+1

Sent from my iPad

> On 22 Nov 2014, at 4:56 am, 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=ghanshyammann&metric=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

[Ken1 Ohmichi]

+1 :-)

Sent from my iPod

On 2014/11/22, at 7:56, Christopher Yeoh  wrote:

> +1
> 
> Sent from my iPad
> 
>> On 22 Nov 2014, at 4:56 am, 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=ghanshyammann&metric=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

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

[Mike Bayer]

> On Nov 21, 2014, at 7:35 PM, Kevin Benton  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 
. 
  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?

[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

[Robert Collins]

On 22 November 2014 08:11, Jeremy Stanley  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 
Distinguished Technologist
HP Converged Cloud

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