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

[Sumit Naiksatam]

On Wed, Dec 3, 2014 at 9:07 PM, Adam Young  wrote:
> On 12/03/2014 06:24 PM, Sukhdev Kapur wrote:
>
> Congratulations Henry and Kevin. It has always been pleasure working with
> you guys.
>
>
> If I may express my opinion, Bob's contribution to ML2 has been quite
> substantial. The kind of stability ML2 has achieved makes a statement of his
> dedication to this work. I have worked very closely with Bob on several
> issues and co-chaired ML2-Subteam with him and have developed tremendous
> respect for his dedication.
> Reading his email reply makes me believe he wants to continue to contribute
> as core developer. Therefore, I would like to take an opportunity to appeal
> to the core team to consider granting him his wish - i.e. vote -1 on his
> removal.
>
> If I might venture an outside voice in support of Bob:  you don't want to
> chase away the continuity.  Yes, sometimes the day job makes us focus on
> things other than upstream work for a while, but I would say that you should
> err on the side of keeping someone that is otherwise still engaged.
> Especially when that core has been as fundamental on a project as I know Bob
> to have been on Quantumer Neutron.

I would definitely echo the above sentiments; Bob has continually made
valuable design contributions to ML2 and Neutron that go beyond the
review count metric. Kindly consider keeping him as a part of the core
team.

That said, a big +1 to both, Henry and Kevin, as additions to the core
team! Welcome!!

Thanks,
~Sumit.

>
>
>
>
>
>
> regards..
> -Sukhdev
>
>
>
>
>
>
> On Wed, Dec 3, 2014 at 11:48 AM, Edgar Magana 
> wrote:
>>
>> I give +2 to Henry and Kevin. So, Congratulations Folks!
>> I have been working with both of them and great quality reviews are always
>> coming out from them.
>>
>> Many thanks to Nachi and Bob for their hard work!
>>
>> Edgar
>>
>> On 12/2/14, 7:59 AM, "Kyle Mestery"  wrote:
>>
>> >Now that we're in the thick of working hard on Kilo deliverables, I'd
>> >like to make some changes to the neutron core team. Reviews are the
>> >most important part of being a core reviewer, so we need to ensure
>> >cores are doing reviews. The stats for the 180 day period [1] indicate
>> >some changes are needed for cores who are no longer reviewing.
>> >
>> >First of all, I'm proposing we remove Bob Kukura and Nachi Ueno from
>> >neutron-core. Bob and Nachi have been core members for a while now.
>> >They have contributed to Neutron over the years in reviews, code and
>> >leading sub-teams. I'd like to thank them for all that they have done
>> >over the years. I'd also like to propose that should they start
>> >reviewing more going forward the core team looks to fast track them
>> >back into neutron-core. But for now, their review stats place them
>> >below the rest of the team for 180 days.
>> >
>> >As part of the changes, I'd also like to propose two new members to
>> >neutron-core: Henry Gessau and Kevin Benton. Both Henry and Kevin have
>> >been very active in reviews, meetings, and code for a while now. Henry
>> >lead the DB team which fixed Neutron DB migrations during Juno. Kevin
>> >has been actively working across all of Neutron, he's done some great
>> >work on security fixes and stability fixes in particular. Their
>> >comments in reviews are insightful and they have helped to onboard new
>> >reviewers and taken the time to work with people on their patches.
>> >
>> >Existing neutron cores, please vote +1/-1 for the addition of Henry
>> >and Kevin to the core team.
>> >
>> >Thanks!
>> >Kyle
>> >
>> >[1] http://stackalytics.com/report/contribution/neutron-group/180
>> >
>> >___
>> >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] [Neutron] [Devstack] Devstack quantun-agent vlan error

[Nader Lahouti]

What do you have for tunnel_types in ml2_conf.ini?

On Wed, Dec 3, 2014 at 12:31 PM, Daniel Nobusada 
wrote:

> Hi guys,
>
> I'm using Devstack with vlan on the parameter Q_ML2_TENANT_NETWORK_TYPE
> and while stacking, the quantun-agent (q-agt) breaks. I'm running it on an
> Ubuntu Server 14.04.
>
> For more details, here's my local.conf: http://pastebin.com/4scBGtpf.
> The error that I recieve is the following: http://pastebin.com/TLq0safe
>
> Could anyone help me?
>
> Thanks in advance,
> Daniel Nobusada
>
> ___
> 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] [Heat] Convergence proof-of-concept showdown

[Zane Bitter]

On 01/12/14 02:02, Anant Patil wrote:

On GitHub:https://github.com/anantpatil/heat-convergence-poc


I'm trying to review this code at the moment, and finding some stuff I 
don't understand:


https://github.com/anantpatil/heat-convergence-poc/blob/master/heat/engine/stack.py#L911-L916

This appears to loop through all of the resources *prior* to kicking off 
any actual updates to check if the resource will change. This is 
impossible to do in general, since a resource may obtain a property 
value from an attribute of another resource and there is no way to know 
whether an update to said other resource would cause a change in the 
attribute value.


In addition, no attempt to catch UpdateReplace is made. Although that 
looks like a simple fix, I'm now worried about the level to which this 
code has been tested.



I'm also trying to wrap my head around how resources are cleaned up in 
dependency order. If I understand correctly, you store in the 
ResourceGraph table the dependencies between various resource names in 
the current template (presumably there could also be some left around 
from previous templates too?). For each resource name there may be a 
number of rows in the Resource table, each with an incrementing version. 
As far as I can tell though, there's nowhere that the dependency graph 
for _previous_ templates is persisted? So if the dependency order 
changes in the template we have no way of knowing the correct order to 
clean up in any more? (There's not even a mechanism to associate a 
resource version with a particular template, which might be one avenue 
by which to recover the dependencies.)


I think this is an important case we need to be able to handle, so I 
added a scenario to my test framework to exercise it and discovered that 
my implementation was also buggy. Here's the fix: 
https://github.com/zaneb/heat-convergence-prototype/commit/786f367210ca0acf9eb22bea78fd9d51941b0e40




It was difficult, for me personally, to completely understand Zane's PoC
and how it would lay the foundation for aforementioned design goals. It
would be very helpful to have Zane's understanding here. I could
understand that there are ideas like async message passing and notifying
the parent which we also subscribe to.


So I guess the thing to note is that there are essentially two parts to 
my Poc:
1) A simulation framework that takes what will be in the final 
implementation multiple tasks running in parallel in separate processes 
and talking to a database, and replaces it with an event loop that runs 
the tasks sequentially in a single process with an in-memory data store. 
I could have built a more realistic simulator using Celery or something, 
but I preferred this way as it offers deterministic tests.

2) A toy implementation of Heat on top of this framework.

The files map roughly to Heat something like this:

converge.engine   -> heat.engine.service
converge.stack-> heat.engine.stack
converge.resource -> heat.engine.resource
converge.template -> heat.engine.template
converge.dependencies -> actually is heat.engine.dependencies
converge.sync_point   -> no equivalent
converge.converger-> no equivalent (this is convergence "worker")
converge.reality  -> represents the actual OpenStack services

For convenience, I just use the @asynchronous decorator to turn an 
ordinary method call into a simulated message.


The concept is essentially as follows:
At the start of a stack update (creates and deletes are also just 
updates) we create any new resources in the DB calculate the dependency 
graph for the update from the data in the DB and template. This graph is 
the same one used by updates in Heat currently, so it contains both the 
forward and reverse (cleanup) dependencies. The stack update then kicks 
off checks of all the leaf nodes, passing the pre-calculated dependency 
graph.


Each resource check may result in a call to the create(), update() or 
delete() methods of a Resource plugin. The resource also reads any 
attributes that will be required from it. Once this is complete, it 
triggers any dependent resources that are ready, or updates a SyncPoint 
in the database if there are dependent resources that have multiple 
requirements. The message triggering the next resource will contain the 
dependency graph again, as well as the RefIds and required attributes of 
any resources it depends on.


The new dependencies thus created are added to the resource itself in 
the database at the time it is checked, allowing it to record the 
changes caused by a requirement being unexpectedly replaced without 
needing a global lock on anything.


When cleaning up resources, we also endeavour to remove any that are 
successfully deleted from the dependencies graph.


Each traversal has a unique ID that is both stored in the stack and 
passed down through the resource check triggers. (At present this is the 
template ID, but it may make more sense to have a unique ID since old 

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

[Adam Young]

On 12/03/2014 06:24 PM, Sukhdev Kapur wrote:
Congratulations Henry and Kevin. It has always been pleasure working 
with you guys.



If I may express my opinion, Bob's contribution to ML2 has been quite 
substantial. The kind of stability ML2 has achieved makes a statement 
of his dedication to this work. I have worked very closely with Bob on 
several issues and co-chaired ML2-Subteam with him and have developed 
tremendous respect for his dedication.
Reading his email reply makes me believe he wants to continue to 
contribute as core developer. Therefore, I would like to take an 
opportunity to appeal to the core team to consider granting him his 
wish - i.e. vote -1 on his removal.
If I might venture an outside voice in support of Bob:  you don't want 
to chase away the continuity.  Yes, sometimes the day job makes us focus 
on things other than upstream work for a while, but I would say that you 
should err on the side of keeping someone that is otherwise still 
engaged.  Especially when that core has been as fundamental on a project 
as I know Bob to have been on Quantumer Neutron.







regards..
-Sukhdev






On Wed, Dec 3, 2014 at 11:48 AM, Edgar Magana 
mailto:edgar.mag...@workday.com>> wrote:


I give +2 to Henry and Kevin. So, Congratulations Folks!
I have been working with both of them and great quality reviews
are always
coming out from them.

Many thanks to Nachi and Bob for their hard work!

Edgar

On 12/2/14, 7:59 AM, "Kyle Mestery" mailto:mest...@mestery.com>> wrote:

>Now that we're in the thick of working hard on Kilo deliverables, I'd
>like to make some changes to the neutron core team. Reviews are the
>most important part of being a core reviewer, so we need to ensure
>cores are doing reviews. The stats for the 180 day period [1]
indicate
>some changes are needed for cores who are no longer reviewing.
>
>First of all, I'm proposing we remove Bob Kukura and Nachi Ueno from
>neutron-core. Bob and Nachi have been core members for a while now.
>They have contributed to Neutron over the years in reviews, code and
>leading sub-teams. I'd like to thank them for all that they have done
>over the years. I'd also like to propose that should they start
>reviewing more going forward the core team looks to fast track them
>back into neutron-core. But for now, their review stats place them
>below the rest of the team for 180 days.
>
>As part of the changes, I'd also like to propose two new members to
>neutron-core: Henry Gessau and Kevin Benton. Both Henry and Kevin
have
>been very active in reviews, meetings, and code for a while now.
Henry
>lead the DB team which fixed Neutron DB migrations during Juno. Kevin
>has been actively working across all of Neutron, he's done some great
>work on security fixes and stability fixes in particular. Their
>comments in reviews are insightful and they have helped to
onboard new
>reviewers and taken the time to work with people on their patches.
>
>Existing neutron cores, please vote +1/-1 for the addition of Henry
>and Kevin to the core team.
>
>Thanks!
>Kyle
>
>[1] http://stackalytics.com/report/contribution/neutron-group/180
>
>___
>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] [nova] global or per-project specific ssl config options, or both?

[Matt Riedemann]

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


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


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


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


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

--

Thanks,

Matt Riedemann


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

[openstack-dev] [TripleO] Do we want to remove Nova-bm support?

[Steve Kowalik]

Hi all,

I'm becoming increasingly concerned about all of the code paths
in tripleo-incubator that check $USE_IRONIC -eq 0 -- that is, use
nova-baremetal rather than Ironic. We do not check nova-bm support in
CI, haven't for at least a month, and I'm concerned that parts of it
may be slowly bit-rotting.

I think our documentation is fairly clear that nova-baremetal is
deprecated and Ironic is the way forward, and I know it flies in the
face of backwards-compatibility, but do we want to bite the bullet and
remove nova-bm support?

Cheers,
-- 
Steve
Oh, in case you got covered in that Repulsion Gel, here's some advice
the lab boys gave me: [paper rustling] DO NOT get covered in the
Repulsion Gel.
 - Cave Johnson, CEO of Aperture Science

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

[openstack-dev] [nova] NUMA Cells

[Michael Still]

Hi,

so just having read a bunch of the libvirt driver numa code, I have a
concern. At first I thought it was a little thing, but I am starting
to think its more of a big deal...

We use the term "cells" to describe numa cells. However, that term has
a specific meaning in nova, and I worry that overloading the term is
confusing.

(Yes, I know the numa people had it first, but hey).

So, what do people think about trying to move the numa code to use
something like "numa cell" or "numacell" based on context?

Michael

-- 
Rackspace Australia

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

Re: [openstack-dev] [Ceilometer]Unit test failed on branch stable/icehouse

[sam song]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dina,

As you say, it is caused by legacy .pyc files. I remove them all and
all tests are passed.

Thanks
Sam

On 12/03/2014 05:47 PM, Dina Belova wrote:
> have unit tests failing in the new just cloned reposi
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iQEcBAEBAgAGBQJUf97iAAoJEPDWvv0r0XeRovYH/3/N3XYMeXBT+EEZ25D4xy3N
7JMZzJhR01isuPL3koY6pMoP8hBSfSd0Fb7fD5fIZiUcuwzLvsUA2rl2CvBnb9HK
TZMhasLGUdfWtvIz01NAO8/8kMN22e/yKa4vrtdeVaxEvVTE3pzoe6XihSQQDZ4j
oiuHjgKIBNERS/5BPSHnYEnIfOhDo+bykEmB6TYn+HfLZmOKozpcx7sXvVKf32Pr
EbuOQHBBLQYaIGRAQshqrNIihGFvY10KKfp2t4I1fM1g5DLqLQ3Ud0rb52E8FlQo
yPhge/A6H/qIdOTSVi9VpPpWXVP6BdMFkPiRH2MBIgejbmgaTxOeDxMqbOenPQc=
=WhO0
-END PGP SIGNATURE-

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

Re: [openstack-dev] [glance] Deprecating osprofiler option 'enabled' in favour of 'profiler_enabled'

[Nikhil Komawar]

Don't care either way, let's be consistent with other projects and raise this 
concern in next weekly cross-project meeting [1] to see what "all" of the 
projects mutually agree on. If there is no consensus, let's stick to what we 
have.

@Louis: Can you please add that to the agenda of the cross-project meeting?

[1] https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting

Thanks,
-Nikhil


From: Ian Cordasco [ian.corda...@rackspace.com]
Sent: Tuesday, December 02, 2014 10:32 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance] Deprecating osprofiler option 'enabled' 
in favour of 'profiler_enabled'

Except for the fact that the person who implemented this was told to
change the option name in other projects because it conflicted with a
different option. We can keep this if we’re worried about being too
obvious (to the point of becoming the Department of Redundancy Department)
with our naming. I don’t think other projects will be very happy having to
change their naming especially if the original name was already a problem.

On 12/2/14, 06:12, "Zhi Yan Liu"  wrote:

>I totally agreed to make it to be consistent cross all projects, so I
>propose to change other projects.
>
>But I think keeping it as-it is clear enough for both developer and
>operator/configuration, for example:
>
>[profiler]
>enable = True
>
>instead of:
>
>[profiler]
>profiler_enable = True
>
>Tbh, the "profiler" prefix is redundant to me still from the
>perspective of operator/configuration.
>
>zhiyan
>
>
>On Tue, Dec 2, 2014 at 7:44 PM, Louis Taylor  wrote:
>> On Tue, Dec 02, 2014 at 12:16:44PM +0800, Zhi Yan Liu wrote:
>>> Why not change other services instead of glance? I see one reason is
>>> "glance is the only one service use this option name", but to me one
>>> reason to keep it as-it in glance is that original name makes more
>>> sense due to the option already under "profiler" group, adding
>>> "profiler" prefix to it is really redundant, imo, and in other
>>> existing config group there's no one go this naming way. Then in the
>>> code we can just use a clear way:
>>>
>>> CONF.profiler.enabled
>>>
>>> instead of:
>>>
>>> CONF.profiler.profiler_enabled
>>>
>>> thanks,
>>> zhiyan
>>
>> I agree this looks nicer in the code. However, the primary consumer of
>>this
>> option is someone editing it in the configuration files. In this case, I
>> believe having something more verbose and consistent is better than the
>>Glance
>> code being slightly more elegant.
>>
>> One name or the other doesn't make all that much difference, but
>>consistency in
>> how we turn osprofiler on and off across projects would be best.
>>
>> - Louis
>>
>> ___
>> 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] [tripleo] Managing no-mergepy template duplication

[Clint Byrum]

Excerpts from Dan Prince's message of 2014-12-03 18:35:15 -0800:
> On Wed, 2014-12-03 at 10:11 +, Steven Hardy wrote:
> > Hi all,
> > 
> > Lately I've been spending more time looking at tripleo and doing some
> > reviews. I'm particularly interested in helping the no-mergepy and
> > subsequent puppet-software-config implementations mature (as well as
> > improving overcloud updates via heat).
> > 
> > Since Tomas's patch landed[1] to enable --no-mergepy in
> > tripleo-heat-templates, it's become apparent that frequently patches are
> > submitted which only update overcloud-source.yaml, so I've been trying to
> > catch these and ask for a corresponding change to e.g controller.yaml.
> > 
> > This raises the following questions:
> > 
> > 1. Is it reasonable to -1 a patch and ask folks to update in both places?
> 
> Yes! In fact until we abandon merge.py we shouldn't land anything that
> doesn't make the change in both places. Probably more important to make
> sure things go into the new (no-mergepy) templates though.
> 
> > 2. How are we going to handle this duplication and divergence?
> 
> Move as quickly as possible to the new without-mergepy varients? That is
> my vote anyways.
> 
> > 3. What's the status of getting gating CI on the --no-mergepy templates?
> 
> Devtest already supports it by simply setting an option (which sets an
> ENV variable). Just need to update tripleo-ci to do that and then make
> the switch.
> 
> > 4. What barriers exist (now that I've implemented[2] the eliding 
> > functionality
> > requested[3] for ResourceGroup) to moving to the --no-mergepy
> > implementation by default?
> 
> None that I know of.
> 

I concur with Dan. Elide was the last reason not to use this.

One thing to consider is that there is no actual upgrade path from
non-autoscaling-group based clouds, to auto-scaling-group based
templates. We should consider how we'll do that before making it the
default. So, I suggest we discuss possible upgrade paths and then move
forward with switching one of the CI jobs to using the new templates.

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

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

[Dan Prince]

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

Yes! In fact until we abandon merge.py we shouldn't land anything that
doesn't make the change in both places. Probably more important to make
sure things go into the new (no-mergepy) templates though.

> 2. How are we going to handle this duplication and divergence?

Move as quickly as possible to the new without-mergepy varients? That is
my vote anyways.

> 3. What's the status of getting gating CI on the --no-mergepy templates?

Devtest already supports it by simply setting an option (which sets an
ENV variable). Just need to update tripleo-ci to do that and then make
the switch.

> 4. What barriers exist (now that I've implemented[2] the eliding functionality
> requested[3] for ResourceGroup) to moving to the --no-mergepy
> implementation by default?

None that I know of.

> 
> Thanks for any clarification you can provide! :)
> 
> Steve
> 
> [1] https://review.openstack.org/#/c/123100/
> [2] https://review.openstack.org/#/c/128365/
> [3] https://review.openstack.org/#/c/123713/
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] How to get openstack bugs data for research?

[Jesus M. Gonzalez-Barahona]

You can download a database dump with (hopefully) information for all
Launchpad tickets corresponding to OpenStack, already organized and
ready to be queried:

http://activity.openstack.org/dash/browser/data/db/tickets.mysql.7z

(linked from
http://activity.openstack.org/dash/browser/data_sources.html )

It is a 7z-zipped file with includes a MySQL dump of the actual
database, produced by Bicho (one of the tools in MetricsGrimoire). It is
updated daily.

You can just feed it to MySQL, and start to do your queries. There is
some information about Bicho and the database schema used at

https://github.com/MetricsGrimoire/Bicho/wiki

https://github.com/MetricsGrimoire/Bicho/wiki/Database-Schema

Please, let me know if you need further info.

Saludos,

Jesus.

On Wed, 2014-12-03 at 20:20 +0800, zfx0...@gmail.com wrote:
> Hi, all
> 
> 
> I am a graduate student in Peking University, our lab do some research
> on open source projects. 
> This is our introduction: https://passion-lab.org/
> 
> 
> Now we need openstack issues data for research, I found the issues
> list: https://bugs.launchpad.net/openstack/
> I want to download the openstack issues data, Could anyone tell me how
> to download the data? Or is there some link or API for download the
> data?
> 
> 
> And I found 9464  bugs in https://bugs.launchpad.net/openstack/ ，is
> this all? why so few?
> 
> 
> Many thanks!
> 
> 
> Beat regards,
> Feixue, Zhang
> 
> 
> 
> __
> zfx0...@gmail.com
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Bitergia: http://bitergia.com
/me at Twitter: https://twitter.com/jgbarah


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

Re: [openstack-dev] [OpenStack-Dev] Config Options and OSLO libs

[John Griffith]

On Wed, Dec 3, 2014 at 2:18 PM, Sean Dague  wrote:
> On 12/03/2014 03:58 PM, Morgan Fainberg wrote:
>> Hi John,
>>
>> Let me say first off that I 100% agree with the value of the sample config 
>> being in-tree. Keystone has not removed it due to similar feedback I’ve 
>> received. However, the issue is that *gating* on config changes for all 
>> libraries that are included in the sample config is just a process that 
>> leads to this frustration / breakage. I have thought about this, and I think 
>> the right answer is two fold:
>>
>> 1) immediately stop gating on sample config changes. I know the cinder team 
>> uses it as a “did we break some compat” and “are you changing config” in a 
>> patch that could adversely affect deployers/other systems. I don’t think 
>> you’re going to win the “don’t change config values in libraries we don’t 
>> control” (or even controlled by a separate project) argument. It’s very hard 
>> to release an updated oslo lib, clients, or keystonemiddleware.
>>
>> 2) Implement a check (I think I have a way of doing this, I’ll run it by 
>> Doug Hellman and you on IRC) that is programatically checking *only* for 
>> in-tree config values.
>>
>> Alternative: A non-voting gate job that says “config has changed” [should be 
>> *really* easy to add] so at least you know the config has changed.
>>
>> This should likely be something easy to get through the door (either the 
>> programatic one or the simple non-voting job). This however, needs the infra 
>> team buy-in as acceptable.
>>
>> I know that most projects have moved away from gating on this since we now 
>> consume a lot of libraries that provide config options that the individual 
>> server-projects don’t control (it is the reason Keystone doesn’t gate 
>> explicitly on this).
>
> So I think there is a better way. The end game here is you want an up to
> date sample config in your tree.
>
> Ok, so as a post merge figure out if you need a config change, and if so
> proposal bot that back in. Better yet, publish these somewhere on the
> web so people can browse samples. Maybe even for a few different kinds
> of configs.

The above is what we're going to do (in conjunction with a MileStone
check), thanks for the great input Sean and Morgan.

>
> Make it part of the release checklist for a milestone that the tool
> which generates the config is run manually and make sure that the in
> tree config is up to date. Which might mean in master it's behind a bit,
> but at least it will be right for any releases.
>
> -Sean
>
>
>>
>> Just my quick $0.002 on the topic,
>> —Morgan
>>
>>> On Dec 3, 2014, at 12:44 PM, John Griffith  wrote:
>>>
>>> Hey,
>>>
>>> So this is a long running topic, but I want to bring it up again.
>>> First, YES Cinder is still running a sample.conf.  A lot of Operators
>>> spoke up and provided feedback that this was valuable and they
>>> objected strongly to taking it away.  That being said we're going to
>>> go the route of removing it from our unit tests and
>>> generating/publishing periodically outside of tests.
>>>
>>> That being said, one of the things that's driving me crazy and
>>> breaking things on a regular basis is other OpenStack libs having a
>>> high rate of change of config options.  This revolves around things
>>> like fixing typos in the comments, reformatting of text etc.  All of
>>> these things are good in the long run, but I wonder if we could
>>> consider batching these sorts of efforts and communicating them?
>>>
>>> The other issue that we hit today was a flat out removal of an option
>>> in the oslo.messaging lib with no deprecation.  This patch here [1]
>>> does a number of things that are probably great in terms of clean up
>>> and housekeeping, but now that we're all in on shared/common libs I
>>> think we should be a bit more careful about the changes we make.  Also
>>> to me the commit message doesn't really make it easy for me to search
>>> git logs to try and figure out what happened when things blew up.
>>>
>>> Anyway, just wanted to send a note out asking people to keep in mind
>>> the impact of conf changes, and a gentle reminder about depreciation
>>> periods for the removal of options.
>>>
>>> [1]: 
>>> https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586
>>>
>>> ___
>>> 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
>>
>
>
> --
> 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

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

[Sukhdev Kapur]

Congratulations Henry and Kevin. It has always been pleasure working with
you guys.


If I may express my opinion, Bob's contribution to ML2 has been quite
substantial. The kind of stability ML2 has achieved makes a statement of
his dedication to this work. I have worked very closely with Bob on several
issues and co-chaired ML2-Subteam with him and have developed tremendous
respect for his dedication.
Reading his email reply makes me believe he wants to continue to contribute
as core developer. Therefore, I would like to take an opportunity to appeal
to the core team to consider granting him his wish - i.e. vote -1 on his
removal.

regards..
-Sukhdev






On Wed, Dec 3, 2014 at 11:48 AM, Edgar Magana 
wrote:

> I give +2 to Henry and Kevin. So, Congratulations Folks!
> I have been working with both of them and great quality reviews are always
> coming out from them.
>
> Many thanks to Nachi and Bob for their hard work!
>
> Edgar
>
> On 12/2/14, 7:59 AM, "Kyle Mestery"  wrote:
>
> >Now that we're in the thick of working hard on Kilo deliverables, I'd
> >like to make some changes to the neutron core team. Reviews are the
> >most important part of being a core reviewer, so we need to ensure
> >cores are doing reviews. The stats for the 180 day period [1] indicate
> >some changes are needed for cores who are no longer reviewing.
> >
> >First of all, I'm proposing we remove Bob Kukura and Nachi Ueno from
> >neutron-core. Bob and Nachi have been core members for a while now.
> >They have contributed to Neutron over the years in reviews, code and
> >leading sub-teams. I'd like to thank them for all that they have done
> >over the years. I'd also like to propose that should they start
> >reviewing more going forward the core team looks to fast track them
> >back into neutron-core. But for now, their review stats place them
> >below the rest of the team for 180 days.
> >
> >As part of the changes, I'd also like to propose two new members to
> >neutron-core: Henry Gessau and Kevin Benton. Both Henry and Kevin have
> >been very active in reviews, meetings, and code for a while now. Henry
> >lead the DB team which fixed Neutron DB migrations during Juno. Kevin
> >has been actively working across all of Neutron, he's done some great
> >work on security fixes and stability fixes in particular. Their
> >comments in reviews are insightful and they have helped to onboard new
> >reviewers and taken the time to work with people on their patches.
> >
> >Existing neutron cores, please vote +1/-1 for the addition of Henry
> >and Kevin to the core team.
> >
> >Thanks!
> >Kyle
> >
> >[1] http://stackalytics.com/report/contribution/neutron-group/180
> >
> >___
> >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] [Compute][Nova] Mid-cycle meetup details for kilo

[Michael Still]

Sigh, sorry. It is of course the Kilo meetup:

https://www.eventbrite.com.au/e/openstack-nova-kilo-mid-cycle-developer-meetup-tickets-14767182039

Michael

On Thu, Dec 4, 2014 at 10:16 AM, Michael Still  wrote:
> I've just created the signup page for this event. Its here:
>
> https://www.eventbrite.com.au/e/openstack-nova-juno-mid-cycle-developer-meetup-tickets-14767182039
>
> Cheers,
> Michael
>
> On Wed, Oct 15, 2014 at 3:45 PM, Michael Still  wrote:
>> Hi.
>>
>> I am pleased to announce details for the Kilo Compute mid-cycle
>> meetup, but first some background about how we got here.
>>
>> Two companies actively involved in OpenStack came forward with offers
>> to host the Compute meetup. However, one of those companies has
>> gracefully decided to wait until the L release because of the cold
>> conditions are their proposed location (think several feet of snow).
>>
>> So instead, we're left with California!
>>
>> The mid-cycle meetup will be from 26 to 28 January 2015, at the VMWare
>> offices in Palo Alto California.
>>
>> Thanks for VMWare for stepping up and offering to host. It sure does
>> make my life easy.
>>
>> More details will be forthcoming closer to the event, but I wanted to
>> give people as much notice as possible about dates and location so
>> they can start negotiating travel if they want to come.
>>
>> Cheers,
>> Michael
>>
>> --
>> Rackspace Australia
>
>
>
> --
> Rackspace Australia



-- 
Rackspace Australia

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

Re: [openstack-dev] [Compute][Nova] Mid-cycle meetup details for kilo

[Michael Still]

I've just created the signup page for this event. Its here:

https://www.eventbrite.com.au/e/openstack-nova-juno-mid-cycle-developer-meetup-tickets-14767182039

Cheers,
Michael

On Wed, Oct 15, 2014 at 3:45 PM, Michael Still  wrote:
> Hi.
>
> I am pleased to announce details for the Kilo Compute mid-cycle
> meetup, but first some background about how we got here.
>
> Two companies actively involved in OpenStack came forward with offers
> to host the Compute meetup. However, one of those companies has
> gracefully decided to wait until the L release because of the cold
> conditions are their proposed location (think several feet of snow).
>
> So instead, we're left with California!
>
> The mid-cycle meetup will be from 26 to 28 January 2015, at the VMWare
> offices in Palo Alto California.
>
> Thanks for VMWare for stepping up and offering to host. It sure does
> make my life easy.
>
> More details will be forthcoming closer to the event, but I wanted to
> give people as much notice as possible about dates and location so
> they can start negotiating travel if they want to come.
>
> Cheers,
> Michael
>
> --
> Rackspace Australia



-- 
Rackspace Australia

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

[openstack-dev] [Neutron] [RFC] Floating IP idea solicitation and collaboration

[Ryan Clevenger]

Hi,

At Rackspace, we have a need to create a higher level networking service 
primarily for the purpose of creating a Floating IP solution in our 
environment. The current solutions for Floating IPs, being tied to plugin 
implementations, does not meet our needs at scale for the following reasons:

1. Limited endpoint H/A mainly targeting failover only and not multi-active 
endpoints,
2. Lack of noisy neighbor and DDOS mitigation,
3. IP fragmentation (with cells, public connectivity is terminated inside each 
cell leading to fragmentation and IP stranding when cell CPU/Memory use doesn't 
line up with allocated IP blocks. Abstracting public connectivity away from 
nova installations allows for much more efficient use of those precious IPv4 
blocks).
4. Diversity in transit (multiple encapsulation and transit types on a per 
floating ip basis).

We realize that network infrastructures are often unique and such a solution 
would likely diverge from provider to provider. However, we would love to 
collaborate with the community to see if such a project could be built that 
would meet the needs of providers at scale. We believe that, at its core, this 
solution would boil down to terminating north<->south traffic temporarily at a 
massively horizontally scalable centralized core and then encapsulating traffic 
east<->west to a specific host based on the association setup via the current 
L3 router's extension's 'floatingips' resource.

Our current idea, involves using Open vSwitch for header rewriting and tunnel 
encapsulation combined with a set of Ryu applications for management:

https://i.imgur.com/bivSdcC.png

The Ryu application uses Ryu's BGP support to announce up to the Public Routing 
layer individual floating ips (/32's or /128's) which are then summarized and 
announced to the rest of the datacenter. If a particular floating ip is 
experiencing unusually large traffic (DDOS, slashdot effect, etc.), the Ryu 
application could change the announcements up to the Public layer to shift that 
traffic to dedicated hosts setup for that purpose. It also announces a single 
/32 "Tunnel Endpoint" ip downstream to the TunnelNet Routing system which 
provides transit to and from the cells and their hypervisors. Since traffic 
from either direction can then end up on any of the FLIP hosts, a simple flow 
table to modify the MAC and IP in either the SRC or DST fields (depending on 
traffic direction) allows the system to be completely stateless. We have proven 
this out (with static routing and flows) to work reliably in a small lab setup.

On the hypervisor side, we currently plumb networks into separate OVS bridges. 
Another Ryu application would control the bridge that handles overlay 
networking to selectively divert traffic destined for the default gateway up to 
the FLIP NAT systems, taking into account any configured logical routing and 
local L2 traffic to pass out into the existing overlay fabric undisturbed.

Adding in support for L2VPN EVPN 
(https://tools.ietf.org/html/draft-ietf-l2vpn-evpn-11) and L2VPN EVPN Overlay 
(https://tools.ietf.org/html/draft-sd-l2vpn-evpn-overlay-03) to the Ryu BGP 
speaker will allow the hypervisor side Ryu application to advertise up to the 
FLIP system reachability information to take into account VM failover, 
live-migrate, and supported encapsulation types. We believe that decoupling the 
tunnel endpoint discovery from the control plane (Nova/Neutron) will provide 
for a more robust solution as well as allow for use outside of openstack if 
desired.




Ryan Clevenger
Manager, Cloud Engineering - US
m: 678.548.7261
e: ryan.cleven...@rackspace.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] alembic 0.7.1 will break neutron's "heal" feature which assumes a fixed set of potential autogenerate types

[Salvatore Orlando]

Thanks Mike,

I already gave your patch a +2. when the gate is broken there's no time for
nitpicking - those can come with a followup patch.
The patch is now spinning again against jenkins checks. As soon as it's
done we'll send it through the gate - and hopefully get a promotion for it.

Salvatore

On 3 December 2014 at 23:17, Mike Bayer  wrote:

> So folks, I had to put Alembic 0.7.1 out as I realized that the “batch”
> mode was being turned on for autogenerate across the board in 0.7.0, and
> that was not the plan.
>
> So it is now out, and the builds are failing due to
> https://launchpad.net/bugs/1397796.
>
> There’s some nits happening on the review
> https://review.openstack.org/#/c/137989/, so I’m hoping someone with some
> Neutron cred adjust the patch to their liking and get it merged.I’m
> just the messenger on this.
>
> - mike
>
>
>
> On Dec 1, 2014, at 5:43 PM, Salvatore Orlando  wrote:
>
> Thanks Mike!
>
> I've left some comments on the patch.
> Just out of curiosity, since now alembic can autogenerate foreign keys,
> are we be able to remove the logic for identifying foreign keys to
> add/remove [1]?
>
> Salvatore
>
> [1]
> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/migration/alembic_migrations/heal_script.py#n205
>
>
> On 1 December 2014 at 20:35, Mike Bayer  wrote:
>
>> hey neutron -
>>
>> Just an FYI, I’ve added https://review.openstack.org/#/c/137989/ /
>> https://launchpad.net/bugs/1397796 to refer to an issue in neutron’s
>> “heal” script that is going to start failing when I put out Alembic 0.7.1,
>> which is potentially later today / this week.
>>
>> The issue is pretty straightforward,  Alembic 0.7.1 is adding foreign key
>> autogenerate (and really, could add more types of autogenerate at any
>> time), and as these new commands are revealed within the
>> execute_alembic_command(), they are not accounted for, so it fails.   I’d
>> recommend folks try to push this one through or otherwise decide how this
>> issue (which should be expected to occur many more times) should be handled.
>>
>> Just a heads up in case you start seeing builds failing!
>>
>> - mike
>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

[Kevin Benton]

What you are proposing sounds very reasonable. If I understand correctly,
the idea is to make Nova just create the TAP device and get it attached to
the VM and leave it 'unplugged'. This would work well and might eliminate
the need for some drivers. I see no reason to block adding a VIF type that
does this.

However, there is a good reason that the VIF type for some OVS-based
deployments require this type of setup. The vSwitches are connected to a
central controller using openflow (or ovsdb) which configures forwarding
rules/etc. Therefore they don't have any agents running on the compute
nodes from the Neutron side to perform the step of getting the interface
plugged into the vSwitch in the first place. For this reason, we will still
need both types of VIFs.


> 1 .When the port is created in the Neutron DB, and handled (bound etc.)
   by the plugin and/or mechanism driver, the TAP device name is already
   present at that time.

This is backwards. The tap device name is derived from the port ID, so the
port has already been created in Neutron at that point. It is just unbound.
The steps are roughly as follows: Nova calls neutron for a port, Nova
creates/plugs VIF based on port, Nova updates port on Neutron, Neutron
binds the port and notifies agent/plugin/whatever to finish the plumbing,
Neutron notifies Nova that port is active, Nova unfreezes the VM.

None of that should be affected by what you are proposing. The only
difference is that your Neutron agent would also perform the 'plugging'
operation.

For your second point, scanning the integration bridge for new ports is
currently used now, but that's an implementation detail of the reference
OVS driver. It doesn't block your work directly since OVS wouldn't use your
NOOP VIF type anyway.


Cheers,
Kevin Benton

On Wed, Dec 3, 2014 at 8:08 AM, Neil Jerram 
wrote:

> Hi there.  I've been looking into a tricky point, and hope I can succeed
> in expressing it clearly here...
>
> I believe it is the case, even when using a committedly Neutron-based
> networking implementation, that Nova is still involved a little bit in
> the networking setup logic.  Specifically I mean the plug() and unplug()
> operations, whose implementations are provided by *VIFDriver classes for
> the various possible hypervisors.
>
> For example, for the libvirt hypervisor, LibvirtGenericVIFDriver
> typically implements plug() by calling create_tap_dev() to create the
> TAP device, and then plugging into some form of L2 bridge.
>
> Does this logic actually have to be in Nova?  For a Neutron-based
> networking implementation, it seems to me that it should also be
> possible to do this in a Neutron agent (obviously running on the compute
> node concerned), and that - if so - that would be preferable because it
> would enable more Neutron-based experimentation without having to modify
> any Nova code.
>
> Specifically, therefore, I wonder if we could/should add a "do-nothing"
> value to the set of Nova VIF types (VIF_TYPE_NOOP?), and implement
> plug()/unplug() for that value to do nothing at all, leaving all setup
> to the Neutron agent?  And then hopefully it should never be necessary
> to introduce further Nova VIF type support ever again...
>
> Am I missing something that really makes that not fly?  Two possible
> objections occurs to me, as follows, but I think they're both
> surmountable.
>
> 1. When the port is created in the Neutron DB, and handled (bound etc.)
>by the plugin and/or mechanism driver, the TAP device name is already
>present at that time.
>
>I think this is still OK because Neutron knows anyway what the TAP
>device name _will_ be, even if the actual TAP device hasn't been
>created yet.
>
> 2. With some agent implementations, there isn't a direct instruction,
>from the plugin to the agent, to say "now look after this VM /
>port".  Instead the agents polls the OS for new TAP devices
>appearing.  Clearly, then, if there isn't something other than the
>agent that creates the TAP device, any logic in the agent will never
>be triggered.
>
>This is certain a problem.  For new networking experimentation,
>however, we can write agent code that is directly instructed by the
>plugin, and hence (a) doesn't need to poll (b) doesn't require the
>TAP device to have been previously created by Nova - which I'd argue
>is preferable.
>
> Thoughts?
>
> (FYI my context is that I've been working on a networking implementation
> where the TAP device to/from a VM should _not_ be plugged into a bridge
> - and for that I've had to make a Nova change even though my team's aim
> was to do the whole thing in Neutron.
>
> I've proposed a spec for the Nova change that plugs a TAP interface
> without bridging it (https://review.openstack.org/#/c/130732/), but that
> set me wondering about this wider question of whether such Nova changes
> should still be necessary...)
>
> Many thanks,
>  Neil
>
> 

Re: [openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon

[Aaron Sahlin]

I would be happy with either the two proposed solutions (both 
improvements over the what we have now).
Any thoughts on combining them?   Only close if esc or 'x' is clicked, 
but also warn them if data was entered.




On 12/3/2014 7:21 AM, Rob Cresswell (rcresswe) wrote:
+1 to changing the behaviour to 'static'. Modal inside a modal is 
potentially slightly more useful, but looks messy and inconsistent, 
which I think outweighs the functionality.


Rob


On 2 Dec 2014, at 12:21, Timur Sufiev > wrote:



Hello, Horizoneers and UX-ers!

The default behavior of modals in Horizon (defined in turn by 
Bootstrap defaults) regarding their closing is to simply close the 
modal once user clicks somewhere outside of it (on the backdrop 
element below and around the modal). This is not very convenient for 
the modal forms containing a lot of input - when it is closed without 
a warning all the data the user has already provided is lost. Keeping 
this in mind, I've made a patch [1] changing default Bootstrap 
'modal_backdrop' parameter to 'static', which means that forms are 
not closed once the user clicks on a backdrop, while it's still 
possible to close them by pressing 'Esc' or clicking on the 'X' link 
at the top right border of the form. Also the patch [1] allows to 
customize this behavior (between 'true'-current one/'false' - no 
backdrop element/'static') on a per-form basis.


What I didn't know at the moment I was uploading my patch is that 
David Lyle had been working on a similar solution [2] some time ago. 
It's a bit more elaborate than mine: if the user has already filled 
some some inputs in the form, then a confirmation dialog is shown, 
otherwise the form is silently dismissed as it happens now.


The whole point of writing about this in the ML is to gather opinions 
which approach is better:

* stick to the current behavior;
* change the default behavior to 'static';
* use the David's solution with confirmation dialog (once it'll be 
rebased to the current codebase).


What do you think?

[1] https://review.openstack.org/#/c/113206/
[2] https://review.openstack.org/#/c/23037/

P.S. I remember that I promised to write this email a week ago, but 
better late than never :).


--
Timur Sufiev
___
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] [OpenStack-Infra] [third-party]Time for Additional Meeting for third-party

[Anita Kuno]

Whoops too many mailing lists.


 Forwarded Message 
Subject: Re: [OpenStack-Infra] [openstack-dev] [third-party]Time for
Additional Meeting for  third-party
Date: Wed, 03 Dec 2014 17:25:05 -0500
From: Anita Kuno 
To: openstack-in...@lists.openstack.org

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

Okay first of all thanks to everyone who replied.

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

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

So barring further discussion, see you then!

Thanks everyone,
Anita.



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

Re: [openstack-dev] [oslo] oslo.messaging config option deprecation

[Joshua Harlow]

Ben Nemec wrote:

On 12/03/2014 02:45 PM, Sean Dague wrote:

So this -
https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586
was clearly a violation of our 1 cycle for deprecation of config options.

I think that should be reverted, an oops release put out to fix it, and
then deprecate for 1.6.


+1.  That was definitely a no-no.


If oslo libraries are going to include config options, they have to
follow the same config deprecation as that's a contract that projects
project up. Otherwise we need to rethink the ability for libraries to
use oslo config (which, honestly is worth rethinking).


I don't see how that would help with this sort of thing.  Instead of one
project mistakenly removing an undeprecated opt, you would have dozens
potentially making the same error, which would also then make their
available configuration options inconsistent with all of the other
projects using oslo.messaging.  That way lies madness.


Isn't this the way most other libraries that don't use oslo.config 
operate? Aka, the API they expose would follow deprecation strategies 
that libraries/apps commonly use. It has always been sort of 
tricky/hidden (IMHO) that the usage of oslo.config is really a part of 
those libraries public API.


Example that shows what people might do:

# Using oslo-config as the API
def a(cfg):
  if cfg.b:
print("hi")

# Using an actual kwarg
def a(b=False):
  if b:
print("hi")

Now to deprecate the kwarg using function there needs to be some kind of 
warning logged when 'b' is provided that recommends the new name (say 
'c'); this is similar to what the oslo-config using API also has to do 
but I feel it's less obvious and easier to break; since it isn't clear 
from the function definition this is happening since the function still 
gets just a 'cfg' object, and this just gets worse if u continue passing 
around the cfg object to other functions/methods/classes...


Basically the only way to really know that someone is using 'cfg.b' is 
by grepping for it (which makes the API very malleable, for better or 
worse; it also seems to make it harder to use tools like sphinx that can 
interpret function pydocs to denote functions that have depreciations 
and such...).


IMHO it doesn't seem like the larger pypi/python world has gone to mad 
(aka those projects, apps, libraries, others that haven't used oslo.config)?


But maybe I missed all the mad people or I'm in the crowd that is mad 
and I can't tell ;) To me the inconsistency that you state is a 
policy/people problem and need not be addressed always by oslo.config 
(but could just be addressed at say review time).


I know not everyone agrees with this, but it's useful to think of 
different ways and at least think about them...





___
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] alembic 0.7.1 will break neutron's "heal" feature which assumes a fixed set of potential autogenerate types

[Mike Bayer]

So folks, I had to put Alembic 0.7.1 out as I realized that the “batch” mode 
was being turned on for autogenerate across the board in 0.7.0, and that was 
not the plan.

So it is now out, and the builds are failing due to 
https://launchpad.net/bugs/1397796 .

There’s some nits happening on the review  
https://review.openstack.org/#/c/137989/ 
, so I’m hoping someone with some 
Neutron cred adjust the patch to their liking and get it merged.I’m just 
the messenger on this. 

- mike



> On Dec 1, 2014, at 5:43 PM, Salvatore Orlando  wrote:
> 
> Thanks Mike!
> 
> I've left some comments on the patch.
> Just out of curiosity, since now alembic can autogenerate foreign keys, are 
> we be able to remove the logic for identifying foreign keys to add/remove [1]?
> 
> Salvatore
> 
> [1] 
> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/migration/alembic_migrations/heal_script.py#n205
>  
> 
>  
> 
> On 1 December 2014 at 20:35, Mike Bayer  > wrote:
> hey neutron -
> 
> Just an FYI, I’ve added https://review.openstack.org/#/c/137989/ 
>  / 
> https://launchpad.net/bugs/1397796  to 
> refer to an issue in neutron’s “heal” script that is going to start failing 
> when I put out Alembic 0.7.1, which is potentially later today / this week.
> 
> The issue is pretty straightforward,  Alembic 0.7.1 is adding foreign key 
> autogenerate (and really, could add more types of autogenerate at any time), 
> and as these new commands are revealed within the execute_alembic_command(), 
> they are not accounted for, so it fails.   I’d recommend folks try to push 
> this one through or otherwise decide how this issue (which should be expected 
> to occur many more times) should be handled.
> 
> Just a heads up in case you start seeing builds failing!
> 
> - mike
> 
> 
> 
> ___
> 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] [OpenStack-Dev] Config Options and OSLO libs

[Morgan Fainberg]

> On Dec 3, 2014, at 1:18 PM, Sean Dague  wrote:
> 
> On 12/03/2014 03:58 PM, Morgan Fainberg wrote:
>> Hi John,
>> 
>> Let me say first off that I 100% agree with the value of the sample config 
>> being in-tree. Keystone has not removed it due to similar feedback I’ve 
>> received. However, the issue is that *gating* on config changes for all 
>> libraries that are included in the sample config is just a process that 
>> leads to this frustration / breakage. I have thought about this, and I think 
>> the right answer is two fold:
>> 
>> 1) immediately stop gating on sample config changes. I know the cinder team 
>> uses it as a “did we break some compat” and “are you changing config” in a 
>> patch that could adversely affect deployers/other systems. I don’t think 
>> you’re going to win the “don’t change config values in libraries we don’t 
>> control” (or even controlled by a separate project) argument. It’s very hard 
>> to release an updated oslo lib, clients, or keystonemiddleware.
>> 
>> 2) Implement a check (I think I have a way of doing this, I’ll run it by 
>> Doug Hellman and you on IRC) that is programatically checking *only* for 
>> in-tree config values.
>> 
>> Alternative: A non-voting gate job that says “config has changed” [should be 
>> *really* easy to add] so at least you know the config has changed.
>> 
>> This should likely be something easy to get through the door (either the 
>> programatic one or the simple non-voting job). This however, needs the infra 
>> team buy-in as acceptable.
>> 
>> I know that most projects have moved away from gating on this since we now 
>> consume a lot of libraries that provide config options that the individual 
>> server-projects don’t control (it is the reason Keystone doesn’t gate 
>> explicitly on this).
> 
> So I think there is a better way. The end game here is you want an up to
> date sample config in your tree.
> 
> Ok, so as a post merge figure out if you need a config change, and if so
> proposal bot that back in. Better yet, publish these somewhere on the
> web so people can browse samples. Maybe even for a few different kinds
> of configs.
> 
> Make it part of the release checklist for a milestone that the tool
> which generates the config is run manually and make sure that the in
> tree config is up to date. Which might mean in master it's behind a bit,
> but at least it will be right for any releases.
> 

This is actually what Keystone does. But last time I talked to John they used 
it for review of config changes purposes. I’m happy to be corrected and I’m a 
big advocate of “it’s part of the release checklist”.

—Morgan

>   -Sean
> 
> 
>> 
>> Just my quick $0.002 on the topic,
>> —Morgan
>> 
>>> On Dec 3, 2014, at 12:44 PM, John Griffith  wrote:
>>> 
>>> Hey,
>>> 
>>> So this is a long running topic, but I want to bring it up again.
>>> First, YES Cinder is still running a sample.conf.  A lot of Operators
>>> spoke up and provided feedback that this was valuable and they
>>> objected strongly to taking it away.  That being said we're going to
>>> go the route of removing it from our unit tests and
>>> generating/publishing periodically outside of tests.
>>> 
>>> That being said, one of the things that's driving me crazy and
>>> breaking things on a regular basis is other OpenStack libs having a
>>> high rate of change of config options.  This revolves around things
>>> like fixing typos in the comments, reformatting of text etc.  All of
>>> these things are good in the long run, but I wonder if we could
>>> consider batching these sorts of efforts and communicating them?
>>> 
>>> The other issue that we hit today was a flat out removal of an option
>>> in the oslo.messaging lib with no deprecation.  This patch here [1]
>>> does a number of things that are probably great in terms of clean up
>>> and housekeeping, but now that we're all in on shared/common libs I
>>> think we should be a bit more careful about the changes we make.  Also
>>> to me the commit message doesn't really make it easy for me to search
>>> git logs to try and figure out what happened when things blew up.
>>> 
>>> Anyway, just wanted to send a note out asking people to keep in mind
>>> the impact of conf changes, and a gentle reminder about depreciation
>>> periods for the removal of options.
>>> 
>>> [1]: 
>>> https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586
>>> 
>>> ___
>>> 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 
>> 
>> 
> 
> 
> -- 
> Sean Dague
> http://dague.net 

Re: [openstack-dev] [OpenStack-Dev] Config Options and OSLO libs

[Sean Dague]

On 12/03/2014 03:58 PM, Morgan Fainberg wrote:
> Hi John,
> 
> Let me say first off that I 100% agree with the value of the sample config 
> being in-tree. Keystone has not removed it due to similar feedback I’ve 
> received. However, the issue is that *gating* on config changes for all 
> libraries that are included in the sample config is just a process that leads 
> to this frustration / breakage. I have thought about this, and I think the 
> right answer is two fold:
> 
> 1) immediately stop gating on sample config changes. I know the cinder team 
> uses it as a “did we break some compat” and “are you changing config” in a 
> patch that could adversely affect deployers/other systems. I don’t think 
> you’re going to win the “don’t change config values in libraries we don’t 
> control” (or even controlled by a separate project) argument. It’s very hard 
> to release an updated oslo lib, clients, or keystonemiddleware.
> 
> 2) Implement a check (I think I have a way of doing this, I’ll run it by Doug 
> Hellman and you on IRC) that is programatically checking *only* for in-tree 
> config values.
> 
> Alternative: A non-voting gate job that says “config has changed” [should be 
> *really* easy to add] so at least you know the config has changed.
> 
> This should likely be something easy to get through the door (either the 
> programatic one or the simple non-voting job). This however, needs the infra 
> team buy-in as acceptable.
> 
> I know that most projects have moved away from gating on this since we now 
> consume a lot of libraries that provide config options that the individual 
> server-projects don’t control (it is the reason Keystone doesn’t gate 
> explicitly on this).

So I think there is a better way. The end game here is you want an up to
date sample config in your tree.

Ok, so as a post merge figure out if you need a config change, and if so
proposal bot that back in. Better yet, publish these somewhere on the
web so people can browse samples. Maybe even for a few different kinds
of configs.

Make it part of the release checklist for a milestone that the tool
which generates the config is run manually and make sure that the in
tree config is up to date. Which might mean in master it's behind a bit,
but at least it will be right for any releases.

-Sean


> 
> Just my quick $0.002 on the topic,
> —Morgan
> 
>> On Dec 3, 2014, at 12:44 PM, John Griffith  wrote:
>>
>> Hey,
>>
>> So this is a long running topic, but I want to bring it up again.
>> First, YES Cinder is still running a sample.conf.  A lot of Operators
>> spoke up and provided feedback that this was valuable and they
>> objected strongly to taking it away.  That being said we're going to
>> go the route of removing it from our unit tests and
>> generating/publishing periodically outside of tests.
>>
>> That being said, one of the things that's driving me crazy and
>> breaking things on a regular basis is other OpenStack libs having a
>> high rate of change of config options.  This revolves around things
>> like fixing typos in the comments, reformatting of text etc.  All of
>> these things are good in the long run, but I wonder if we could
>> consider batching these sorts of efforts and communicating them?
>>
>> The other issue that we hit today was a flat out removal of an option
>> in the oslo.messaging lib with no deprecation.  This patch here [1]
>> does a number of things that are probably great in terms of clean up
>> and housekeeping, but now that we're all in on shared/common libs I
>> think we should be a bit more careful about the changes we make.  Also
>> to me the commit message doesn't really make it easy for me to search
>> git logs to try and figure out what happened when things blew up.
>>
>> Anyway, just wanted to send a note out asking people to keep in mind
>> the impact of conf changes, and a gentle reminder about depreciation
>> periods for the removal of options.
>>
>> [1]: 
>> https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586
>>
>> ___
>> 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
> 


-- 
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] [oslo] oslo.messaging config option deprecation

[Ben Nemec]

On 12/03/2014 02:45 PM, Sean Dague wrote:
> So this -
> https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586
> was clearly a violation of our 1 cycle for deprecation of config options.
> 
> I think that should be reverted, an oops release put out to fix it, and
> then deprecate for 1.6.

+1.  That was definitely a no-no.

> 
> If oslo libraries are going to include config options, they have to
> follow the same config deprecation as that's a contract that projects
> project up. Otherwise we need to rethink the ability for libraries to
> use oslo config (which, honestly is worth rethinking).

I don't see how that would help with this sort of thing.  Instead of one
project mistakenly removing an undeprecated opt, you would have dozens
potentially making the same error, which would also then make their
available configuration options inconsistent with all of the other
projects using oslo.messaging.  That way lies madness.


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

Re: [openstack-dev] [Manila] Manila project use-cases

[Ben Swartzlander]

Reply to Valeriy below and to Marc further below...


On 12/03/2014 02:39 AM, Valeriy Ponomaryov wrote:
According to (2) - yes, analog of Cinder's "manage/unmanage" is not 
implemented in Manila yet.


Manage/unmanage is a feature I'm very interested in seeing in Manila. I 
suspect it will be harder to get right in Manila than it was for Cinder, 
however, and more importantly, getting it right will depend a lot on the 
work that's going on right now to support pools and driver modes. For 
Manila core it won't actually be that much work but for individual 
drivers, implementing manage/unmanage can be a huge amount of work, so 
we should try to define the semantics of manage/unmanage at the project 
level to strike a good balance between usefulness to administrators and 
making it practical to implement.


On Wed, Dec 3, 2014 at 9:03 AM, Marc Koderer > wrote:


Hi Valeriy,

thanks for feedback. My answers see below.

Am 02.12.2014 um 16:44 schrieb Valeriy Ponomaryov
mailto:vponomar...@mirantis.com>>:

> Hello Marc,
>
> Here, I tried to cover mentioned use cases with "implemented or
not" notes:
>
> 1) Implemented, but details of implementation are different for
different share drivers.
> 2) Not clear for me. If you mean possibility to mount one share
to any amount of VMs, then yes.

That means you have an existing shared volume in your storage
system and import
it to manila (like cinder manage). I guess this is not implemented
yet.

> 3) Nova is used only in one case - Generic Driver that uses
Cinder volumes. So, it can be said, that Manila interface does
allow to use "flat" network and a share driver just should have
implementation for it. I will assume you mean usage of generic
driver and possibility to mount shares to different machines
except Nova VMs. - In that case network architecture should allow
to make connection in general. If it is allowed, then should not
be any problems with mount to any machine. Just access-allow
operations should be performed.

This point was actually a copy from the wiki [1]. I just removed
the Bare-metal point
since for me it doesn’t matter whether the infrastructure service
is a Bare-metal machine or not.

> 4) Access can be shared, but it is not as flexible as could be
wanted. Owner of a share can grant access to all, and if there is
network connectivity between user and share host, then user will
be able to mount having provided access.

Also a copy from the wiki.

> 5) Manila can not remove some "mount" of some share, it can
remove access for possibility to mount in general. So, looks like
not implemented.
> 6) Implemented.
> 7) Not implemented yet.
> 8) No "cloning", but we have snapshot-approach as for volumes in
cinder.

Regards
Marc

>
> Regards,
> Valeriy Ponomaryov
> Mirantis
>
> On Tue, Dec 2, 2014 at 4:22 PM, Marc Koderer mailto:m...@koderer.com>> wrote:
> Hello Manila Team,
>
> We identified use cases for Manila during an internal workshop
> with our operators. I would like to share them with you and
> update the wiki [1] since it seems to be outdated.
>
> Before that I would like to gather feedback and you might help me
> with identifying things that aren’t implemented yet.
>
> Our list:
>
>  1.) Create a share and use it in a tenant
>  Initial creation of a shared storage volume and assign it
to several VM’s



This is the basic use case for Manila and I hope it's obvious that this 
works.



>  2.) Assign an preexisting share to a VM with Manila
>  Import an existing Share with data and it to several VM’s
in case of
>  migrating an existing production - services to Openstack.



Covered above.


>  3.) External consumption of a share
>  Accommodate and provide mechanisms for last-mile
consumption of shares by
>  consumers of the service that aren't mediated by Nova.



Depending on how you look at this, it either already works or it's out 
of scope for Manila. Now that we're looking at mount automation we may 
be more involved in this area, but nothing about Manila prevents the use 
of shares by something other than nova.



>  4.) Cross Tenant sharing
>  Coordinate shares across tenants



As above, this is considered out of scope, but we believe it's easy to 
make this work with no changes to Manila.



>  5.) Detach a share and don’t destroy data (deactivate)
>  Share is flagged as inactive and data are not destroyed for
later
>  usage or in case of legal requirements.



Can't this be achieved by simply removing all access? By default, the 
shares manila creates are not accessible to anyone. Access must be 
granted explicitly.



>  6.) Unassign and delete data of a share
>  Destr

Re: [openstack-dev] [OpenStack-Dev] Config Options and OSLO libs

[Morgan Fainberg]

Hi John,

Let me say first off that I 100% agree with the value of the sample config 
being in-tree. Keystone has not removed it due to similar feedback I’ve 
received. However, the issue is that *gating* on config changes for all 
libraries that are included in the sample config is just a process that leads 
to this frustration / breakage. I have thought about this, and I think the 
right answer is two fold:

1) immediately stop gating on sample config changes. I know the cinder team 
uses it as a “did we break some compat” and “are you changing config” in a 
patch that could adversely affect deployers/other systems. I don’t think you’re 
going to win the “don’t change config values in libraries we don’t control” (or 
even controlled by a separate project) argument. It’s very hard to release an 
updated oslo lib, clients, or keystonemiddleware.

2) Implement a check (I think I have a way of doing this, I’ll run it by Doug 
Hellman and you on IRC) that is programatically checking *only* for in-tree 
config values.

Alternative: A non-voting gate job that says “config has changed” [should be 
*really* easy to add] so at least you know the config has changed.

This should likely be something easy to get through the door (either the 
programatic one or the simple non-voting job). This however, needs the infra 
team buy-in as acceptable.

I know that most projects have moved away from gating on this since we now 
consume a lot of libraries that provide config options that the individual 
server-projects don’t control (it is the reason Keystone doesn’t gate 
explicitly on this).

Just my quick $0.002 on the topic,
—Morgan

> On Dec 3, 2014, at 12:44 PM, John Griffith  wrote:
> 
> Hey,
> 
> So this is a long running topic, but I want to bring it up again.
> First, YES Cinder is still running a sample.conf.  A lot of Operators
> spoke up and provided feedback that this was valuable and they
> objected strongly to taking it away.  That being said we're going to
> go the route of removing it from our unit tests and
> generating/publishing periodically outside of tests.
> 
> That being said, one of the things that's driving me crazy and
> breaking things on a regular basis is other OpenStack libs having a
> high rate of change of config options.  This revolves around things
> like fixing typos in the comments, reformatting of text etc.  All of
> these things are good in the long run, but I wonder if we could
> consider batching these sorts of efforts and communicating them?
> 
> The other issue that we hit today was a flat out removal of an option
> in the oslo.messaging lib with no deprecation.  This patch here [1]
> does a number of things that are probably great in terms of clean up
> and housekeeping, but now that we're all in on shared/common libs I
> think we should be a bit more careful about the changes we make.  Also
> to me the commit message doesn't really make it easy for me to search
> git logs to try and figure out what happened when things blew up.
> 
> Anyway, just wanted to send a note out asking people to keep in mind
> the impact of conf changes, and a gentle reminder about depreciation
> periods for the removal of options.
> 
> [1]: 
> https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586
> 
> ___
> 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] [third-party] Third-party CI account creation is now self-serve

[Anita Kuno]

As of now third-party CI account creation is now self-serve. I think
this makes everybody happy.

What does this mean?

Well for a new third-party account this means you follow the new
process, outlined here:
http://ci.openstack.org/third_party.html#creating-a-service-account

If you don't have enough information from these docs, please contact the
infra team then we will work on a patch once you learn what you needed,
to fill in the holes for others.

If you currently have a third-party CI account on Gerrit, this is what
will happen with your account:
http://ci.openstack.org/third_party.html#permissions-on-your-third-party-system

Short story is we will be moving voting accounts into project specific
voting groups. Your voting rights will not change, but will be directly
managed by project release groups.
Non voting accounts will be removed from the now redundant Third-Party
CI group and otherwise will not be changed.

If you are a member of a -release group for a project currently
receiving third-party CI votes, you will find that you have access to
manage membership in a new group in Gerrit called -ci.  To
allow a CI system to vote on your project, add it to the -ci
group, and to disable voting on your project, remove them from that group.

We hope you are as excited about this change as we are.

Let us know if you have questions, do try to work with third-party
project representatives as much as you can.

Thank you,
Anita.

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

[openstack-dev] [oslo] oslo.messaging config option deprecation

[Sean Dague]

So this -
https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586
was clearly a violation of our 1 cycle for deprecation of config options.

I think that should be reverted, an oops release put out to fix it, and
then deprecate for 1.6.

If oslo libraries are going to include config options, they have to
follow the same config deprecation as that's a contract that projects
project up. Otherwise we need to rethink the ability for libraries to
use oslo config (which, honestly is worth rethinking).

-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] [OpenStack-Dev] Config Options and OSLO libs

[John Griffith]

Hey,

So this is a long running topic, but I want to bring it up again.
First, YES Cinder is still running a sample.conf.  A lot of Operators
spoke up and provided feedback that this was valuable and they
objected strongly to taking it away.  That being said we're going to
go the route of removing it from our unit tests and
generating/publishing periodically outside of tests.

That being said, one of the things that's driving me crazy and
breaking things on a regular basis is other OpenStack libs having a
high rate of change of config options.  This revolves around things
like fixing typos in the comments, reformatting of text etc.  All of
these things are good in the long run, but I wonder if we could
consider batching these sorts of efforts and communicating them?

The other issue that we hit today was a flat out removal of an option
in the oslo.messaging lib with no deprecation.  This patch here [1]
does a number of things that are probably great in terms of clean up
and housekeeping, but now that we're all in on shared/common libs I
think we should be a bit more careful about the changes we make.  Also
to me the commit message doesn't really make it easy for me to search
git logs to try and figure out what happened when things blew up.

Anyway, just wanted to send a note out asking people to keep in mind
the impact of conf changes, and a gentle reminder about depreciation
periods for the removal of options.

[1]: 
https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586

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

[openstack-dev] [Neutron] [Devstack] Devstack quantun-agent vlan error

[Daniel Nobusada]

Hi guys,

I'm using Devstack with vlan on the parameter Q_ML2_TENANT_NETWORK_TYPE and
while stacking, the quantun-agent (q-agt) breaks. I'm running it on an
Ubuntu Server 14.04.

For more details, here's my local.conf: http://pastebin.com/4scBGtpf.
The error that I recieve is the following: http://pastebin.com/TLq0safe

Could anyone help me?

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

Re: [openstack-dev] [diskimage-builder] Tracing levels for scripts (119023)

[Chris Jones]

Hi

> On 3 Dec 2014, at 18:41, Clint Byrum  wrote:
> 
> What if the patch is reworked to leave the current trace-all-the-time
> mode in place, and we iterate on each script to make tracing conditional
> as we add proper logging?

+1

Cheers,
--
Chris Jones

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

Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

[Matthias Runge]

On 03/12/14 20:22, Alan Pevec wrote:
>> Horizon
>> standing-after-freeze translation update, coming on Dec 3
> 
> This is now posted https://review.openstack.org/138798
> David, Matthias, I'd appreciate one of you to have a quick look before
> approving.
> 
> Cheers,
> Alan
> 
Alan, thanks for the heads-up here. Approved.

Matthias


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

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

[Edgar Magana]

I give +2 to Henry and Kevin. So, Congratulations Folks!
I have been working with both of them and great quality reviews are always
coming out from them.

Many thanks to Nachi and Bob for their hard work!

Edgar

On 12/2/14, 7:59 AM, "Kyle Mestery"  wrote:

>Now that we're in the thick of working hard on Kilo deliverables, I'd
>like to make some changes to the neutron core team. Reviews are the
>most important part of being a core reviewer, so we need to ensure
>cores are doing reviews. The stats for the 180 day period [1] indicate
>some changes are needed for cores who are no longer reviewing.
>
>First of all, I'm proposing we remove Bob Kukura and Nachi Ueno from
>neutron-core. Bob and Nachi have been core members for a while now.
>They have contributed to Neutron over the years in reviews, code and
>leading sub-teams. I'd like to thank them for all that they have done
>over the years. I'd also like to propose that should they start
>reviewing more going forward the core team looks to fast track them
>back into neutron-core. But for now, their review stats place them
>below the rest of the team for 180 days.
>
>As part of the changes, I'd also like to propose two new members to
>neutron-core: Henry Gessau and Kevin Benton. Both Henry and Kevin have
>been very active in reviews, meetings, and code for a while now. Henry
>lead the DB team which fixed Neutron DB migrations during Juno. Kevin
>has been actively working across all of Neutron, he's done some great
>work on security fixes and stability fixes in particular. Their
>comments in reviews are insightful and they have helped to onboard new
>reviewers and taken the time to work with people on their patches.
>
>Existing neutron cores, please vote +1/-1 for the addition of Henry
>and Kevin to the core team.
>
>Thanks!
>Kyle
>
>[1] http://stackalytics.com/report/contribution/neutron-group/180
>
>___
>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] [stable] Exception proposals for 2014.2.1

[Alan Pevec]

>> Neutron
>> https://review.openstack.org/136294 - default SNAT, see review for
>> details, I cannot distil 1liner :)
> -1: I would rather fix the doc to match behavior, than change behavior
> to match the doc and lose people that were relying on it.

Consensus is not to merge this and keep behavior.

>> https://review.openstack.org/136275 - self-contained to the vendor
>> code, extensively tested in several deployments
> +0: Feels a bit large for a last-minute exception.

Kyle, Ihar, I'd like to see +2 from Neutron stable-maint before
approving exception.


Cheers,
Alan

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

Re: [openstack-dev] [Ironic] A mascot for Ironic

[Lucas Alvares Gomes]

Hi,

Poll is closed! Everyone please welcome: Pixie Boots, the new Ironic mascot!

Thanks for everyone that voted!

Cheers,
Lucas

On Mon, Dec 1, 2014 at 4:47 PM, Lucas Alvares Gomes 
wrote:

> Ah forgot to say,
>
> Please add your launchpad ID on the Name Field. And I will close the poll
> on Wednesday at 18:00 UTC (I think it's enough time to everyone take a look
> at it)
>
> Cheers,
> Lucas
>
> On Mon, Dec 1, 2014 at 4:44 PM, Lucas Alvares Gomes  > wrote:
>
>> Hi all,
>>
>> I'm sorry for the long delay on this I've been dragged into some other
>> stuff :) But anyway, now it's time
>>
>> I've asked the core Ironic team to narrow down the name options (we had
>> too many, thanks to everyone that contributed) the list of finalists is in
>> the poll right here: http://doodle.com/9h4ncgx4etkyfgdw. So please vote
>> and help us choose the best name for the new mascot!
>>
>> Cheers,
>> Lucas
>>
>> On Tue, Nov 18, 2014 at 7:44 PM, Nathan Kinder 
>> wrote:
>>
>>>
>>>
>>> On 11/16/2014 10:51 AM, David Shrewsbury wrote:
>>> >
>>> >> On Nov 16, 2014, at 8:57 AM, Chris K >> >> > wrote:
>>> >>
>>> >> How cute.
>>> >>
>>> >> maybe we could call him bear-thoven.
>>> >>
>>> >> Chris
>>> >>
>>> >
>>> > I like Blaze Bearly, lead singer for Ironic Maiden.  :)
>>> >
>>> > https://en.wikipedia.org/wiki/Blaze_Bayley
>>>
>>> Good call!  I never thought I'd see a Blaze Bayley reference on this
>>> list. :) Just watch out for imposters...
>>>
>>> http://en.wikipedia.org/wiki/Slow_Riot_for_New_Zer%C3%B8_Kanada#BBF3
>>>
>>> >
>>> >
>>> >>
>>> >> On Sun, Nov 16, 2014 at 5:14 AM, Lucas Alvares Gomes
>>> >> mailto:lucasago...@gmail.com>> wrote:
>>> >>
>>> >> Hi Ironickers,
>>> >>
>>> >> I was thinking this weekend: All the cool projects does have a
>>> mascot
>>> >> so I thought that we could have one for Ironic too.
>>> >>
>>> >> The idea about what the mascot would be was easy because the RAX
>>> guys
>>> >> put "bear metal" their presentation[1] and that totally rocks! So
>>> I
>>> >> drew a bear. It also needed an instrument, at first I thought
>>> about a
>>> >> guitar, but drums is actually my favorite instrument so I drew a
>>> pair
>>> >> of drumsticks instead.
>>> >>
>>> >> The drawing thing wasn't that hard, the problem was to digitalize
>>> it.
>>> >> So I scanned the thing and went to youtube to watch some tutorials
>>> >> about gimp and inkspace to learn how to vectorize it. Magic, it
>>> >> worked!
>>> >>
>>> >> Attached in the email there's the original draw, the vectorized
>>> >> version without colors and the final version of it (with colors).
>>> >>
>>> >> Of course, I know some people does have better skills than I do,
>>> so I
>>> >> also attached the inkspace file of the final version in case
>>> people
>>> >> want to tweak it :)
>>> >>
>>> >> So, what you guys think about making this little drummer bear the
>>> >> mascot of the Ironic project?
>>> >>
>>> >> Ahh he also needs a name. So please send some suggestions and we
>>> can
>>> >> vote on the best name for him.
>>> >>
>>> >> [1] http://www.youtube.com/watch?v=2Oi2T2pSGDU#t=90
>>> >>
>>> >> Lucas
>>> >>
>>> >> ___
>>> >> 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] [stable] Exception proposals for 2014.2.1

[Alan Pevec]

> Horizon
> standing-after-freeze translation update, coming on Dec 3

This is now posted https://review.openstack.org/138798
David, Matthias, I'd appreciate one of you to have a quick look before
approving.

Cheers,
Alan

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

Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

[Alan Pevec]

2014-12-02 17:15 GMT+01:00 Jay S. Bryant :
>> Cinder
>> https://review.openstack.org/137537 - small change and limited to the
>> VMWare driver
>
> +1 I think this is fine to make an exception for.

one more Cinder exception proposal was added in StableJuno etherpad
* https://review.openstack.org/#/c/138526/ (This is currently the
master version but I will be proposing to stable/juno as soon as it is
approved in Master)  The Brocade FS San Lookup facility is currently
broken and this revert is necessary to get it working again.

Jay, what's the status there, I see master change failed in gate?

Cheers,
Alan

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

Re: [openstack-dev] [nova] [libvirt] enabling per node filtering of mempage sizes

[Mooney, Sean K]

Hi Daniel thanks for your feedback.

After reading up a little more 
http://docs.openstack.org/openstack-ops/content/scaling.html#segragation_methods
I now understand your original suggestion.

I believe that if the operator  associates the aggregate directly to the flavor
As you suggested that yes this will cover my use case too as the tenant is 
selecting availability zones
Not host aggregates.

Sorry I had misconstrued the relationship between availability zones and host 
aggregates.
I believed that there was a one to one mapping ,so when you select an 
availability zone you were
Selecting the host aggregate directly.

Regards
Sean.

> -Original Message-
> From: Daniel P. Berrange [mailto:berra...@redhat.com]
> Sent: Wednesday, December 03, 2014 1:38 PM
> To: Mooney, Sean K
> Cc: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [nova] [libvirt] enabling per node 
> filtering of mempage sizes
> 
> On Wed, Dec 03, 2014 at 01:28:36PM +, Mooney, Sean K wrote:
> > Hi
> >
> > Unfortunately a flavor + aggregate is not enough for our use case as 
> > it is still
> possible for the tenant to misconfigure a vm.
> >
> > The edge case not covered by flavor + aggregate that we are trying 
> > to prevent
> is as follows.
> >
> > The operator creates an aggregate containing the  nodes that require 
> > all VMs
> to use large pages.
> > The operator creates flavors with and without memory backing specified.
> >
> > The tenant selects the aggregate containing nodes that only supports
> hugepages and a flavor that requires small or any.
> > Or
> > The tenant selects a flavor that requires small or any and does not 
> > select an
> aggregate.
> 
> The tenant isn't responsible for selecting the aggregate. The operator 
> should be associating the aggregate directly to the flavour. So the 
> tenant merely has to select the right flavour.
> 
> Regards,
> Daniel
> --
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o- http://virt-manager.org :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [diskimage-builder] Tracing levels for scripts (119023)

[Clint Byrum]

Excerpts from Chris Jones's message of 2014-12-03 02:47:30 -0800:
> Hi
> 
> I am very sympathetic to this view. We have a patch in hand that improves the 
> situation. We also have disagreement about the ideal situation.
> 
> I +2'd Ian's patch because it makes things work better than they do now. If 
> we can arrive at an ideal solution later, great, but the more I think about 
> logging from a multitude of bash scripts, and tricks like XTRACE_FD, the more 
> I think it's crazy and we should just incrementally improve the non-trace 
> logging as a separate exercise, leaving working tracing for true debugging 
> situations.
> 

Forgive me, I am not pushing for an ideal situation, but I don't want a
regression.

Running without -x right now has authors xtracing as a rule. Meaning
that the moment this merges, the amount of output goes to almost nil
compared to what it is now.

Basically this is just more of the same OpenStack wrong-headed idea, "you
have to run in DEBUG logging mode to be able to understand any issue".

I'm totally willing to compromise on the ideal for something that is
good enough, but I'm saying this is not good enough _if_ it turns off
tracing for all scripts.

What if the patch is reworked to leave the current trace-all-the-time
mode in place, and we iterate on each script to make tracing conditional
as we add proper logging?

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

Re: [openstack-dev] [nova] Can the Kilo nova controller conduct the Juno compute nodes

[Matt Riedemann]

On 12/3/2014 3:49 AM, Li Junhong wrote:

Hi Joe,

Thank you for your confirmative answer and the wonderful gate testing
pipeline.

On Wed, Dec 3, 2014 at 5:38 PM, Joe Gordon mailto:joe.gord...@gmail.com>> wrote:



On Wed, Dec 3, 2014 at 11:09 AM, Li Junhong mailto:lijh.h...@gmail.com>> wrote:

Hi All,

Is it possible for Kilo nova controller to control the Juno
compute nodes? Is this scenario supported naturally by the nova
mechanism in the design and codes level?


Yes,

We gate on making sure we can run Kilo nova with Juno compute nodes.



--
Best Regards!

Junhong, Li

___
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




--
Best Regards!

Junhong, Li


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



FYI, there are also documented upgrade plans now [1].

http://docs.openstack.org/developer/nova/devref/upgrade.html

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [Fuel][Nailgun] Web framework

[Fox, Kevin M]

Choosing the right instrument for the job in an open source community involves 
choosing technologies that the community is familiar/comfortable with as well, 
as it will allow you access to a greater pool of developers.

With that in mind then, I'd add:
Pro Pecan, blessed by the OpenStack community, con Flask, not.

Kevin

From: Nikolay Markov [nmar...@mirantis.com]
Sent: Wednesday, December 03, 2014 9:00 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Fuel][Nailgun] Web framework

I didn't participate in that discussion, but here are topics on Flask
cons from your link. I added some comments.

- Cons
- db transactions a little trickier to manage, but possible  #
what is trickier? Flask uses pure SQLalchemy or a very thin wrapper
- JSON built-in but not XML # the only one I agree with, but does
Pecan have it?
- some issues, not updated in a while  # last commit was 3 days ago
- No Python 3 support  # full Python 3 support fro a year or so already
- Not WebOb  # can it even be considered as a con?

I'm not trying to argue with you or community principles, I'm just
trying to choose the right instrument for the job.

On Wed, Dec 3, 2014 at 7:41 PM, Jay Pipes  wrote:
> On 12/03/2014 10:53 AM, Nikolay Markov wrote:
>>>
>>> However, the OpenStack community is also about a shared set of tools,
>>> development methodologies, and common perspectives.
>>
>>
>> I completely agree with you, Jay, but the same principle may be
>> applied much wider. Why Openstack Community decided to use its own
>> unstable project instead of existing solution, which is widely used in
>> Python community? To avoid being a team player? Or, at least, why it's
>> recommended way even if it doesn't provide the same features other
>> frameworks have for a long time already? I mean, there is no doubt
>> everyone would use stable and technically advanced tool, but imposing
>> everyone to use it by force with a simple hope that it'll become
>> better from this is usually a bad approach.
>
>
> This conversation was had a long time ago, was thoroughly thought-out and
> discussed at prior summits and the ML:
>
> https://etherpad.openstack.org/p/grizzly-common-wsgi-frameworks
> https://etherpad.openstack.org/p/havana-common-wsgi
>
> I think it's unfair to suggest that the OpenStack community decided "to use
> its own unstable project instead of existing solution".
>
>
> Best,
> -jay
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Best regards,
Nick Markov

___
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] Changes to the core team

[Akihiro Motoki]

+1 for Kevin and Henry. Thanks for your continuous efforts so far and
it would be great additions to our community.

I also would like to say great thanks to Bob and Nachi.
It would be really nice if we see their activities in reviews soon.
We already understand your contributions and skills, so
I believe you all can be back cores even though what is the conclusion
(as nova team usually does).

Thanks,
Akihiro



On Wed, Dec 3, 2014 at 12:59 AM, Kyle Mestery  wrote:
> Now that we're in the thick of working hard on Kilo deliverables, I'd
> like to make some changes to the neutron core team. Reviews are the
> most important part of being a core reviewer, so we need to ensure
> cores are doing reviews. The stats for the 180 day period [1] indicate
> some changes are needed for cores who are no longer reviewing.
>
> First of all, I'm proposing we remove Bob Kukura and Nachi Ueno from
> neutron-core. Bob and Nachi have been core members for a while now.
> They have contributed to Neutron over the years in reviews, code and
> leading sub-teams. I'd like to thank them for all that they have done
> over the years. I'd also like to propose that should they start
> reviewing more going forward the core team looks to fast track them
> back into neutron-core. But for now, their review stats place them
> below the rest of the team for 180 days.
>
> As part of the changes, I'd also like to propose two new members to
> neutron-core: Henry Gessau and Kevin Benton. Both Henry and Kevin have
> been very active in reviews, meetings, and code for a while now. Henry
> lead the DB team which fixed Neutron DB migrations during Juno. Kevin
> has been actively working across all of Neutron, he's done some great
> work on security fixes and stability fixes in particular. Their
> comments in reviews are insightful and they have helped to onboard new
> reviewers and taken the time to work with people on their patches.
>
> Existing neutron cores, please vote +1/-1 for the addition of Henry
> and Kevin to the core team.
>
> Thanks!
> Kyle
>
> [1] http://stackalytics.com/report/contribution/neutron-group/180
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Akihiro Motoki 

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

Re: [openstack-dev] [Fuel][Nailgun] Web framework

[Ryan Petrello]

I've left some comments/corrections in this document re: pecan and what is
supports.

On 12/03/14 07:58 PM, Nikolay Markov wrote:
> A month or two ago I started gathering differencies between Flask and
> Pecan, let's take a look at technical details. Maybe there are some
> things that are already fixed in current versions of Pecan, feel free
> to comment. 
> https://docs.google.com/document/d/1QR7YphyfN64m-e9b5rKC_U8bMtx4zjfW943BfLTqTao/edit?usp=sharing
> 
> On Wed, Dec 3, 2014 at 6:53 PM, Nikolay Markov  wrote:
> >> However, the OpenStack community is also about a shared set of tools,
> >> development methodologies, and common perspectives.
> >
> > I completely agree with you, Jay, but the same principle may be
> > applied much wider. Why Openstack Community decided to use its own
> > unstable project instead of existing solution, which is widely used in
> > Python community? To avoid being a team player? Or, at least, why it's
> > recommended way even if it doesn't provide the same features other
> > frameworks have for a long time already? I mean, there is no doubt
> > everyone would use stable and technically advanced tool, but imposing
> > everyone to use it by force with a simple hope that it'll become
> > better from this is usually a bad approach.
> >
> > I personally would surely contribute to Pecan in case we decide to use
> > it and there will be some gaps and uncovered cases. I'm just curious,
> > does it worth it?
> >
> > On Wed, Dec 3, 2014 at 6:32 PM, Jay Pipes  wrote:
> >> On 12/03/2014 10:16 AM, Nikolay Markov wrote:
> >>>
> >>> It would be great to look at some obvious points where Pecan is better
> >>> than Flask despite of the fact that it's used by the community. I
> >>> still don't see a single and I don't think the principle "jump from
> >>> the cliff if everyone does" works well in such cases.
> >>
> >>
> >> This is part of why the Fuel development team is viewed as not working with
> >> the OpenStack community in many ways. The Fuel team is doing a remarkable
> >> job in changing previously-all-internal-to-Mirantis communication patterns
> >> to instead be on a transparent basis in the mailing lists and on IRC. I
> >> sincerely applaud the Fuel team for that.
> >>
> >> However, the OpenStack community is also about a shared set of tools,
> >> development methodologies, and common perspectives. It's expected that when
> >> you have an OpenStack REST API project, that you try to use the tools that
> >> the shared community uses, builds, and supports. Otherwise, you aren't 
> >> being
> >> a team player.
> >>
> >> In the past, certain teams have chosen to use something other than Pecan 
> >> due
> >> to technical reasons. For example, Zaqar's team chose to use the Falcon
> >> framework instead of the Pecan framework. Zaqar, like Swift, is a data API,
> >> not a control API, and raw performance is critical to the project's API
> >> endpoint). This is, incidentally, why the Swift team chose to use its swob
> >> framework over Webob (which Pecan uses).
> >>
> >> However, the reason that these were chosen was definitely not "it doesn't
> >> support the coding patterns I like". There's something that comes from 
> >> being
> >> a team player. And one of those things is "going with the flow" when there
> >> isn't a real technical reason not to. All of us can and do find things we
> >> don't like about *all* of the projects that we work on. The difference
> >> between team players and non-team players is that team players strongly
> >> weigh their decisions and opinions based on what the team is doing and how
> >> the team can improve.
> >>
> >> Best,
> >>
> >> -jay
> >>
> >> ___
> >> OpenStack-dev mailing list
> >> OpenStack-dev@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > --
> > Best regards,
> > Nick Markov
> 
> 
> 
> -- 
> Best regards,
> Nick Markov
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Ryan Petrello
Senior Developer, DreamHost
ryan.petre...@dreamhost.com

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

Re: [openstack-dev] [Fuel][Nailgun] Web framework

[Fox, Kevin M]

+1. Well said. I second the applauding of the Fuel's development team's for 
their changing of their communications patterns (that's never easy) and also 
the desire for closer integration with the rest of the OpenStack community.

From: Jay Pipes [jaypi...@gmail.com]
Sent: Wednesday, December 03, 2014 7:32 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Fuel][Nailgun] Web framework

On 12/03/2014 10:16 AM, Nikolay Markov wrote:
> It would be great to look at some obvious points where Pecan is better
> than Flask despite of the fact that it's used by the community. I
> still don't see a single and I don't think the principle "jump from
> the cliff if everyone does" works well in such cases.

This is part of why the Fuel development team is viewed as not working
with the OpenStack community in many ways. The Fuel team is doing a
remarkable job in changing previously-all-internal-to-Mirantis
communication patterns to instead be on a transparent basis in the
mailing lists and on IRC. I sincerely applaud the Fuel team for that.

However, the OpenStack community is also about a shared set of tools,
development methodologies, and common perspectives. It's expected that
when you have an OpenStack REST API project, that you try to use the
tools that the shared community uses, builds, and supports. Otherwise,
you aren't being a team player.

In the past, certain teams have chosen to use something other than Pecan
due to technical reasons. For example, Zaqar's team chose to use the
Falcon framework instead of the Pecan framework. Zaqar, like Swift, is a
data API, not a control API, and raw performance is critical to the
project's API endpoint). This is, incidentally, why the Swift team chose
to use its swob framework over Webob (which Pecan uses).

However, the reason that these were chosen was definitely not "it
doesn't support the coding patterns I like". There's something that
comes from being a team player. And one of those things is "going with
the flow" when there isn't a real technical reason not to. All of us can
and do find things we don't like about *all* of the projects that we
work on. The difference between team players and non-team players is
that team players strongly weigh their decisions and opinions based on
what the team is doing and how the team can improve.

Best,
-jay

___
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][Nailgun] Web framework

[Nikolay Markov]

I didn't participate in that discussion, but here are topics on Flask
cons from your link. I added some comments.

- Cons
- db transactions a little trickier to manage, but possible  #
what is trickier? Flask uses pure SQLalchemy or a very thin wrapper
- JSON built-in but not XML # the only one I agree with, but does
Pecan have it?
- some issues, not updated in a while  # last commit was 3 days ago
- No Python 3 support  # full Python 3 support fro a year or so already
- Not WebOb  # can it even be considered as a con?

I'm not trying to argue with you or community principles, I'm just
trying to choose the right instrument for the job.

On Wed, Dec 3, 2014 at 7:41 PM, Jay Pipes  wrote:
> On 12/03/2014 10:53 AM, Nikolay Markov wrote:
>>>
>>> However, the OpenStack community is also about a shared set of tools,
>>> development methodologies, and common perspectives.
>>
>>
>> I completely agree with you, Jay, but the same principle may be
>> applied much wider. Why Openstack Community decided to use its own
>> unstable project instead of existing solution, which is widely used in
>> Python community? To avoid being a team player? Or, at least, why it's
>> recommended way even if it doesn't provide the same features other
>> frameworks have for a long time already? I mean, there is no doubt
>> everyone would use stable and technically advanced tool, but imposing
>> everyone to use it by force with a simple hope that it'll become
>> better from this is usually a bad approach.
>
>
> This conversation was had a long time ago, was thoroughly thought-out and
> discussed at prior summits and the ML:
>
> https://etherpad.openstack.org/p/grizzly-common-wsgi-frameworks
> https://etherpad.openstack.org/p/havana-common-wsgi
>
> I think it's unfair to suggest that the OpenStack community decided "to use
> its own unstable project instead of existing solution".
>
>
> Best,
> -jay
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Best regards,
Nick Markov

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

Re: [openstack-dev] [Fuel][Nailgun] Web framework

[Jay Pipes]

On 12/03/2014 10:53 AM, Nikolay Markov wrote:

However, the OpenStack community is also about a shared set of tools,
development methodologies, and common perspectives.


I completely agree with you, Jay, but the same principle may be
applied much wider. Why Openstack Community decided to use its own
unstable project instead of existing solution, which is widely used in
Python community? To avoid being a team player? Or, at least, why it's
recommended way even if it doesn't provide the same features other
frameworks have for a long time already? I mean, there is no doubt
everyone would use stable and technically advanced tool, but imposing
everyone to use it by force with a simple hope that it'll become
better from this is usually a bad approach.


This conversation was had a long time ago, was thoroughly thought-out 
and discussed at prior summits and the ML:


https://etherpad.openstack.org/p/grizzly-common-wsgi-frameworks
https://etherpad.openstack.org/p/havana-common-wsgi

I think it's unfair to suggest that the OpenStack community decided "to 
use its own unstable project instead of existing solution".


Best,
-jay

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

Re: [openstack-dev] [Infra] Infra-manual documentation Sprint, December 1-2

[Elizabeth K. Joseph]

On Fri, Nov 7, 2014 at 5:57 AM, Elizabeth K. Joseph
 wrote:
> The OpenStack Infrastructure team will be hosting a virtual sprint in
> the Freenode IRC channel #openstack-sprint for the Infrastructure User
> Manual on December 1st starting at 15:00 UTC and going for 48 hours.

Thanks to everyone who participated in our online documentation sprint
this week!

We made major progress with our manual (published here:
http://docs.openstack.org/infra/manual/) and hope this push for core
content will help us continue to refine and update the content for
this valuable community resource moving forward.

Now, some numbers:

Sprint start:
Patches open for review: 10
Patches merged in repo history: 13

Sprint end:
Patches open for review: 3 (plus 2 WIP)
See: 
https://review.openstack.org/#/q/status:open+project:openstack-infra/infra-manual,n,z

Patches merged during sprint: 30
See: 
https://review.openstack.org/#/q/status:merged+project:openstack-infra/infra-manual,n,z

Reviews: Over 200
See http://stackalytics.com/?module=infra-manual&release=kilo

We also have 16 patches for documentation in flight that were
initiated or reviewed elsewhere in the openstack-infra project during
this sprint, including the important reorganization of the git-review
documentation. See:
https://review.openstack.org/#/q/status:open+file:%255E.*%255C.rst+project:%255Eopenstack-infra/.*,n,z

Sprint participants (sorted chronologically by reviews): Elizabeth
Krumbach Joseph, Andreas Jaeger, James E. Blair, Anita Kuno, Clark
Boylan, Spencer Krum, Jeremy Stanley, Doug Hellmann, Khai Do, Antoine
Musso, Stefano Maffulli, Thierry Carrez and Yolanda Robla

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

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

Re: [openstack-dev] [all] bugs with paste pipelines and multiple projects and upgrading

[Sean Dague]

On 12/03/2014 10:57 AM, Lance Bragstad wrote:
> 
> 
> On Wed, Dec 3, 2014 at 9:18 AM, Sean Dague  > wrote:
> 
> We've hit two interesting issues this week around multiple projects
> installing into the paste pipeline of a server.
> 
> 1) the pkg_resources explosion in grenade. Basically ceilometer modified
> swift paste.ini to add it's own code into swift (that's part of normal
> ceilometer install in devstack -
> https://github.com/openstack-dev/devstack/blob/master/lib/swift#L376-L381
> 
> This meant when we upgraded and started swift, it turns out that we're
> actually running old ceilometer code. A requirements mismatch caused an
> explosion (which we've since worked around), however demonstrates a
> clear problem with installing code in another project's pipeline.
> 
> 2) keystone is having issues dropping XML api support. It turns out that
> parts of it's paste pipeline are actually provided by keystone
> middleware, which means that keystone can't provide a sane "this is not
> supported" message in a proxy class for older paste config files.
> 
> 
> I made an attempt to capture some of the information on the specific
> grenade case we were hitting for XML removal in a bug report [1]. We can
> keep the classes in keystone/middleware/core.py as a workaround for now
> with essentially another deprecation message, but at some point we
> should pull the plug on defining XmlBodyMiddleware in our
> keystone-paste.ini [2] as it won't do anything anyway and shouldn't be
> in the configuration. Since this deals with a configuration change, this
> could "always" break a customer. What criteria should we follow for
> cases like this? 
> 
> From visiting with Sean in -qa, typically service configurations don't
> change for the grenade target on upgrade, but if we have to make a
> change on upgrade (to clean out old cruft for example), how do we go
> about that? 

Add content here -
https://github.com/openstack-dev/grenade/tree/master/from-juno

Note: you'll get a -2 unless you provide a link to Release Notes
somewhere that highlights this as an Upgrade Impact for users for the
next release.

-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] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

[Neil Jerram]

Hi there.  I've been looking into a tricky point, and hope I can succeed
in expressing it clearly here...

I believe it is the case, even when using a committedly Neutron-based
networking implementation, that Nova is still involved a little bit in
the networking setup logic.  Specifically I mean the plug() and unplug()
operations, whose implementations are provided by *VIFDriver classes for
the various possible hypervisors.

For example, for the libvirt hypervisor, LibvirtGenericVIFDriver
typically implements plug() by calling create_tap_dev() to create the
TAP device, and then plugging into some form of L2 bridge.

Does this logic actually have to be in Nova?  For a Neutron-based
networking implementation, it seems to me that it should also be
possible to do this in a Neutron agent (obviously running on the compute
node concerned), and that - if so - that would be preferable because it
would enable more Neutron-based experimentation without having to modify
any Nova code.

Specifically, therefore, I wonder if we could/should add a "do-nothing"
value to the set of Nova VIF types (VIF_TYPE_NOOP?), and implement
plug()/unplug() for that value to do nothing at all, leaving all setup
to the Neutron agent?  And then hopefully it should never be necessary
to introduce further Nova VIF type support ever again...

Am I missing something that really makes that not fly?  Two possible
objections occurs to me, as follows, but I think they're both
surmountable.

1. When the port is created in the Neutron DB, and handled (bound etc.)
   by the plugin and/or mechanism driver, the TAP device name is already
   present at that time.

   I think this is still OK because Neutron knows anyway what the TAP
   device name _will_ be, even if the actual TAP device hasn't been
   created yet.

2. With some agent implementations, there isn't a direct instruction,
   from the plugin to the agent, to say "now look after this VM /
   port".  Instead the agents polls the OS for new TAP devices
   appearing.  Clearly, then, if there isn't something other than the
   agent that creates the TAP device, any logic in the agent will never
   be triggered.

   This is certain a problem.  For new networking experimentation,
   however, we can write agent code that is directly instructed by the
   plugin, and hence (a) doesn't need to poll (b) doesn't require the
   TAP device to have been previously created by Nova - which I'd argue
   is preferable.

Thoughts?

(FYI my context is that I've been working on a networking implementation
where the TAP device to/from a VM should _not_ be plugged into a bridge
- and for that I've had to make a Nova change even though my team's aim
was to do the whole thing in Neutron.

I've proposed a spec for the Nova change that plugs a TAP interface
without bridging it (https://review.openstack.org/#/c/130732/), but that
set me wondering about this wider question of whether such Nova changes
should still be necessary...)

Many thanks,
 Neil

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

Re: [openstack-dev] [Fuel][Nailgun] Web framework

[Nikolay Markov]

A month or two ago I started gathering differencies between Flask and
Pecan, let's take a look at technical details. Maybe there are some
things that are already fixed in current versions of Pecan, feel free
to comment. 
https://docs.google.com/document/d/1QR7YphyfN64m-e9b5rKC_U8bMtx4zjfW943BfLTqTao/edit?usp=sharing

On Wed, Dec 3, 2014 at 6:53 PM, Nikolay Markov  wrote:
>> However, the OpenStack community is also about a shared set of tools,
>> development methodologies, and common perspectives.
>
> I completely agree with you, Jay, but the same principle may be
> applied much wider. Why Openstack Community decided to use its own
> unstable project instead of existing solution, which is widely used in
> Python community? To avoid being a team player? Or, at least, why it's
> recommended way even if it doesn't provide the same features other
> frameworks have for a long time already? I mean, there is no doubt
> everyone would use stable and technically advanced tool, but imposing
> everyone to use it by force with a simple hope that it'll become
> better from this is usually a bad approach.
>
> I personally would surely contribute to Pecan in case we decide to use
> it and there will be some gaps and uncovered cases. I'm just curious,
> does it worth it?
>
> On Wed, Dec 3, 2014 at 6:32 PM, Jay Pipes  wrote:
>> On 12/03/2014 10:16 AM, Nikolay Markov wrote:
>>>
>>> It would be great to look at some obvious points where Pecan is better
>>> than Flask despite of the fact that it's used by the community. I
>>> still don't see a single and I don't think the principle "jump from
>>> the cliff if everyone does" works well in such cases.
>>
>>
>> This is part of why the Fuel development team is viewed as not working with
>> the OpenStack community in many ways. The Fuel team is doing a remarkable
>> job in changing previously-all-internal-to-Mirantis communication patterns
>> to instead be on a transparent basis in the mailing lists and on IRC. I
>> sincerely applaud the Fuel team for that.
>>
>> However, the OpenStack community is also about a shared set of tools,
>> development methodologies, and common perspectives. It's expected that when
>> you have an OpenStack REST API project, that you try to use the tools that
>> the shared community uses, builds, and supports. Otherwise, you aren't being
>> a team player.
>>
>> In the past, certain teams have chosen to use something other than Pecan due
>> to technical reasons. For example, Zaqar's team chose to use the Falcon
>> framework instead of the Pecan framework. Zaqar, like Swift, is a data API,
>> not a control API, and raw performance is critical to the project's API
>> endpoint). This is, incidentally, why the Swift team chose to use its swob
>> framework over Webob (which Pecan uses).
>>
>> However, the reason that these were chosen was definitely not "it doesn't
>> support the coding patterns I like". There's something that comes from being
>> a team player. And one of those things is "going with the flow" when there
>> isn't a real technical reason not to. All of us can and do find things we
>> don't like about *all* of the projects that we work on. The difference
>> between team players and non-team players is that team players strongly
>> weigh their decisions and opinions based on what the team is doing and how
>> the team can improve.
>>
>> Best,
>>
>> -jay
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Best regards,
> Nick Markov



-- 
Best regards,
Nick Markov

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

Re: [openstack-dev] [all] bugs with paste pipelines and multiple projects and upgrading

[Lance Bragstad]

On Wed, Dec 3, 2014 at 9:18 AM, Sean Dague  wrote:

> We've hit two interesting issues this week around multiple projects
> installing into the paste pipeline of a server.
>
> 1) the pkg_resources explosion in grenade. Basically ceilometer modified
> swift paste.ini to add it's own code into swift (that's part of normal
> ceilometer install in devstack -
> https://github.com/openstack-dev/devstack/blob/master/lib/swift#L376-L381
>
> This meant when we upgraded and started swift, it turns out that we're
> actually running old ceilometer code. A requirements mismatch caused an
> explosion (which we've since worked around), however demonstrates a
> clear problem with installing code in another project's pipeline.
>
> 2) keystone is having issues dropping XML api support. It turns out that
> parts of it's paste pipeline are actually provided by keystone
> middleware, which means that keystone can't provide a sane "this is not
> supported" message in a proxy class for older paste config files.
>
>
I made an attempt to capture some of the information on the specific
grenade case we were hitting for XML removal in a bug report [1]. We can
keep the classes in keystone/middleware/core.py as a workaround for now
with essentially another deprecation message, but at some point we should
pull the plug on defining XmlBodyMiddleware in our keystone-paste.ini [2]
as it won't do anything anyway and shouldn't be in the configuration. Since
this deals with a configuration change, this could "always" break a
customer. What criteria should we follow for cases like this?

>From visiting with Sean in -qa, typically service configurations don't
change for the grenade target on upgrade, but if we have to make a change
on upgrade (to clean out old cruft for example), how do we go about that?

[1] https://bugs.launchpad.net/grenade/+bug/1398833
[2]
https://github.com/openstack/keystone/blob/d82a3caa329e9b42c588e28f694bf847261d63d1/etc/keystone-paste.ini#L15-L22



> I'm wondering if we need to be a lot more strict about paste
> manipulations, and require that all classes in the paste pipeline are
> owned by the project in question. They could be proxy classes to
> external code, but at least that would allow the project to smooth out
> upgrades. Otherwise everything with code in the paste.ini needs to be
> atomically upgraded, and we're trying to get away from atomic upgrades.
>
> -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

[openstack-dev] [QA] Meeting Thursday December 4th at 17:00 UTC

[Matthew Treinish]

Hi everyone,

Just a quick reminder that the weekly OpenStack QA team IRC meeting will be
tomorrow Thursday, December 4th at 17:00 UTC in the #openstack-meeting
channel.

The agenda for tomorrow's meeting can be found here:
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting
Anyone is welcome to add an item to the agenda.

It's also worth noting that a few weeks ago we started having a regular
dedicated Devstack topic during the meetings. So if anyone is interested in
Devstack development please join the meetings to be a part of the discussion.

To help people figure out what time 17:00 UTC is in other timezones tomorrow's
meeting will be at:

12:00 EST
02:00 JST
03:30 ACDT
18:00 CET
11:00 CST
9:00 PST

-Matt Treinish


pgpj86dQUX0_a.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][Nailgun] Web framework

[Nikolay Markov]

> However, the OpenStack community is also about a shared set of tools,
> development methodologies, and common perspectives.

I completely agree with you, Jay, but the same principle may be
applied much wider. Why Openstack Community decided to use its own
unstable project instead of existing solution, which is widely used in
Python community? To avoid being a team player? Or, at least, why it's
recommended way even if it doesn't provide the same features other
frameworks have for a long time already? I mean, there is no doubt
everyone would use stable and technically advanced tool, but imposing
everyone to use it by force with a simple hope that it'll become
better from this is usually a bad approach.

I personally would surely contribute to Pecan in case we decide to use
it and there will be some gaps and uncovered cases. I'm just curious,
does it worth it?

On Wed, Dec 3, 2014 at 6:32 PM, Jay Pipes  wrote:
> On 12/03/2014 10:16 AM, Nikolay Markov wrote:
>>
>> It would be great to look at some obvious points where Pecan is better
>> than Flask despite of the fact that it's used by the community. I
>> still don't see a single and I don't think the principle "jump from
>> the cliff if everyone does" works well in such cases.
>
>
> This is part of why the Fuel development team is viewed as not working with
> the OpenStack community in many ways. The Fuel team is doing a remarkable
> job in changing previously-all-internal-to-Mirantis communication patterns
> to instead be on a transparent basis in the mailing lists and on IRC. I
> sincerely applaud the Fuel team for that.
>
> However, the OpenStack community is also about a shared set of tools,
> development methodologies, and common perspectives. It's expected that when
> you have an OpenStack REST API project, that you try to use the tools that
> the shared community uses, builds, and supports. Otherwise, you aren't being
> a team player.
>
> In the past, certain teams have chosen to use something other than Pecan due
> to technical reasons. For example, Zaqar's team chose to use the Falcon
> framework instead of the Pecan framework. Zaqar, like Swift, is a data API,
> not a control API, and raw performance is critical to the project's API
> endpoint). This is, incidentally, why the Swift team chose to use its swob
> framework over Webob (which Pecan uses).
>
> However, the reason that these were chosen was definitely not "it doesn't
> support the coding patterns I like". There's something that comes from being
> a team player. And one of those things is "going with the flow" when there
> isn't a real technical reason not to. All of us can and do find things we
> don't like about *all* of the projects that we work on. The difference
> between team players and non-team players is that team players strongly
> weigh their decisions and opinions based on what the team is doing and how
> the team can improve.
>
> Best,
>
> -jay
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Best regards,
Nick Markov

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

[openstack-dev] [NFV][Telco] Use case discussion

[Calum Loudon]

Hello all

Unfortunately, my complete inability to process daylight savings time changes
meant I was one hour late for today's TelcoWG meeting so couldn't participate
in the discussion of use cases, including the one I submitted on Session Border
Control.  Thanks to eavesdrop.openstack.org I've been able to catch up.

Just to chip in to the discussion, I agree entirely that we should try to keep
the wiki vendor neutral, but at the same time I think use cases based on real
world implementations (which could of course be open source rather than from a
vendor) are more powerful illustrations for the Dev community of why particular 
bps are needed than the more abstract presentation of use cases in the ETSI
docs, which are aimed at a different purpose.  I don't think it's particularly
convincing or compelling as a developer to hear that some theoretical
implementation of a network function you may have never heard of might need
feature X, whereas understanding that there are real products out there that
genuinely depend on it brings the requirement home.  One of the goals of this
group is to help the rest of the OpenStack community understand NFV, and I
think concrete beats abstract for that.

However, as Steve noted, I did try to draw out general characteristics and 
relate them to specific gaps and requirements and I think that's important to
try to draw as much as possible that is general and vendor-neutral from specific
cases.

Someone asked about ability to test; I imagine most people in this group will
know of the OPNFV initiative, and they are working to put together test 
frameworks
and cases which may include real VNFs, including this specific Perimeta example.

regards

Calum

Calum Loudon 
Director, Architecture
+44 (0)208 366 1177
 
METASWITCH NETWORKS 
THE BRAINS OF THE NEW GLOBAL NETWORK
www.metaswitch.com




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

Re: [openstack-dev] [qa] branchless tempest and the use of 'all' for extensions in tempest.conf

[Matthew Treinish]

On Wed, Dec 03, 2014 at 09:43:41AM -0500, David Kranz wrote:
> A recent proposed test to tempest was making explicit calls to the nova
> extension discovery api rather than using test.requires_ext. The reason was
> because we configure tempest.conf in the gate as 'all' for extensions, and
> the test involved an extension that was new in Juno. So the icehouse run
> failed. Since the methodology of branchless tempest requires that new conf
> flags be added for new features, we should stop having devstack configure
> with 'all'. Does any one disagree with that, or have a better solution?
> 


There is a BP in progress for doing this:

https://blueprints.launchpad.net/tempest/+spec/branchless-tempest-extensions

The patches are in progress here:

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

and

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


The solution is that we use 'all' on master devstack, but we want to have a
static list set for the stable branch devstacks. Until the bp is finished
patches that add tests which use new extensions will be blocked.

-Matt Treinish


pgpnY5WSbiKxr.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][Nailgun] Web framework

[Jay Pipes]

On 12/03/2014 10:16 AM, Nikolay Markov wrote:

It would be great to look at some obvious points where Pecan is better
than Flask despite of the fact that it's used by the community. I
still don't see a single and I don't think the principle "jump from
the cliff if everyone does" works well in such cases.


This is part of why the Fuel development team is viewed as not working 
with the OpenStack community in many ways. The Fuel team is doing a 
remarkable job in changing previously-all-internal-to-Mirantis 
communication patterns to instead be on a transparent basis in the 
mailing lists and on IRC. I sincerely applaud the Fuel team for that.


However, the OpenStack community is also about a shared set of tools, 
development methodologies, and common perspectives. It's expected that 
when you have an OpenStack REST API project, that you try to use the 
tools that the shared community uses, builds, and supports. Otherwise, 
you aren't being a team player.


In the past, certain teams have chosen to use something other than Pecan 
due to technical reasons. For example, Zaqar's team chose to use the 
Falcon framework instead of the Pecan framework. Zaqar, like Swift, is a 
data API, not a control API, and raw performance is critical to the 
project's API endpoint). This is, incidentally, why the Swift team chose 
to use its swob framework over Webob (which Pecan uses).


However, the reason that these were chosen was definitely not "it 
doesn't support the coding patterns I like". There's something that 
comes from being a team player. And one of those things is "going with 
the flow" when there isn't a real technical reason not to. All of us can 
and do find things we don't like about *all* of the projects that we 
work on. The difference between team players and non-team players is 
that team players strongly weigh their decisions and opinions based on 
what the team is doing and how the team can improve.


Best,
-jay

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

[openstack-dev] [all] bugs with paste pipelines and multiple projects and upgrading

[Sean Dague]

We've hit two interesting issues this week around multiple projects
installing into the paste pipeline of a server.

1) the pkg_resources explosion in grenade. Basically ceilometer modified
swift paste.ini to add it's own code into swift (that's part of normal
ceilometer install in devstack -
https://github.com/openstack-dev/devstack/blob/master/lib/swift#L376-L381

This meant when we upgraded and started swift, it turns out that we're
actually running old ceilometer code. A requirements mismatch caused an
explosion (which we've since worked around), however demonstrates a
clear problem with installing code in another project's pipeline.

2) keystone is having issues dropping XML api support. It turns out that
parts of it's paste pipeline are actually provided by keystone
middleware, which means that keystone can't provide a sane "this is not
supported" message in a proxy class for older paste config files.


I'm wondering if we need to be a lot more strict about paste
manipulations, and require that all classes in the paste pipeline are
owned by the project in question. They could be proxy classes to
external code, but at least that would allow the project to smooth out
upgrades. Otherwise everything with code in the paste.ini needs to be
atomically upgraded, and we're trying to get away from atomic upgrades.

-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] [Fuel][Nailgun] Web framework

[Roman Prykhodchenko]

Being able to make some impact on Pecan is an advantage for sure. But there are 
other aspects in choosing a web framework and I’d rather discuss them.
Let’s not think about what is used in other OpenStack projects for a moment and 
discuss technical details.


> On 03 Dec 2014, at 15:53, Jay Pipes  wrote:
> 
> On 12/03/2014 09:35 AM, Sebastian Kalinowski wrote:
>> I think that as a part of OpenStack community we should stick with
>> Pecan and because of the same reason we can have a bigger impact how
>> future versions of Pecan will look.
> 
> Yes, this. ++
> 
> -jay
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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] [Fuel][Nailgun] Web framework

[Nikolay Markov]

It would be great to look at some obvious points where Pecan is better
than Flask despite of the fact that it's used by the community. I
still don't see a single and I don't think the principle "jump from
the cliff if everyone does" works well in such cases.

On Wed, Dec 3, 2014 at 5:53 PM, Jay Pipes  wrote:
> On 12/03/2014 09:35 AM, Sebastian Kalinowski wrote:
>>
>> I think that as a part of OpenStack community we should stick with
>> Pecan and because of the same reason we can have a bigger impact how
>> future versions of Pecan will look.
>
>
> Yes, this. ++
>
> -jay
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Best regards,
Nick Markov

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

Re: [openstack-dev] [Fuel][Nailgun] Web framework

[Jay Pipes]

On 12/03/2014 09:35 AM, Sebastian Kalinowski wrote:

I think that as a part of OpenStack community we should stick with
Pecan and because of the same reason we can have a bigger impact how
future versions of Pecan will look.


Yes, this. ++

-jay

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

[openstack-dev] [qa] branchless tempest and the use of 'all' for extensions in tempest.conf

[David Kranz]

A recent proposed test to tempest was making explicit calls to the nova 
extension discovery api rather than using test.requires_ext. The reason 
was because we configure tempest.conf in the gate as 'all' for 
extensions, and the test involved an extension that was new in Juno. So 
the icehouse run failed. Since the methodology of branchless tempest 
requires that new conf flags be added for new features, we should stop 
having devstack configure with 'all'. Does any one disagree with that, 
or have a better solution?


 -David

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

[openstack-dev] oslo.db 1.2.0 released

[Victor Sergeyev]

Hello Folks

The Oslo team is pleased to announce the release of oslo.db 1.2.0.

This release includes several bug fixes as well as many other changes:

$ git log --abbrev-commit --pretty=oneline --no-merges 1.1.0..1.2.0
f740e3b Imported Translations from Transifex
ca1ad56 Make test_models pass on py3
549ba15 Repair include_object to accommodate new objects
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
b6d363d Add info on how to run unit tests
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

Thanks Doug Hellmann, Joshua Harlow, Mike Bayer, Oleksii Chuprykov, Roman
Podoliaka for contributing to this release.

For more details, please see the git log history below and
https://launchpad.net/oslo.db/+milestone/1.2.0
Please report issues through launchpad: https://launchpad.net/oslo.db


  diffstat (except docs and test files):

 CONTRIBUTING.rst   | 39 +++
 .../locale/en_GB/LC_MESSAGES/oslo.db-log-info.po   |  8 ++--
 oslo.db/locale/fr/LC_MESSAGES/oslo.db-log-error.po | 56
++
 oslo.db/locale/fr/LC_MESSAGES/oslo.db-log-info.po  | 33 +
 .../locale/fr/LC_MESSAGES/oslo.db-log-warning.po   | 40 
 oslo/db/sqlalchemy/exc_filters.py  | 21 ++--
 oslo/db/sqlalchemy/session.py  | 10 ++--
 oslo/db/sqlalchemy/test_migrations.py  |  2 +-
 oslo/db/sqlalchemy/utils.py|  3 +-
 requirements.txt   |  1 +
 test-requirements-py2.txt  |  2 +-
 test-requirements-py3.txt  |  2 +-
 tests/sqlalchemy/test_exc_filters.py   | 13 +
 tests/sqlalchemy/test_migrations.py|  7 ++-
 tests/sqlalchemy/test_models.py| 31 +---
 15 files changed, 233 insertions(+), 35 deletions(-)

  Requirements updates:

 diff --git a/requirements.txt b/requirements.txt
 index cc50660..f8a0d8c 100644
 --- a/requirements.txt
 +++ b/requirements.txt
 @@ -4,0 +5 @@
 +pbr>=0.6,!=0.7,<1.0
 diff --git a/test-requirements-py2.txt b/test-requirements-py2.txt
 index 13cea90..ac5c18a 100644
 --- a/test-requirements-py2.txt
 +++ b/test-requirements-py2.txt
 @@ -19 +19 @@ testscenarios>=0.4
 -testtools>=0.9.36
 +testtools>=0.9.36,!=1.2.0
 diff --git a/test-requirements-py3.txt b/test-requirements-py3.txt
 index 4f195da..58b9a3d 100644
 --- a/test-requirements-py3.txt
 +++ b/test-requirements-py3.txt
 @@ -18 +18 @@ testscenarios>=0.4
 -testtools>=0.9.36
 +testtools>=0.9.36,!=1.2.0
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Nailgun] Web framework

[Roman Prykhodchenko]

I don’t have an opinion for now but do have some thoughts instead.

We use Pecan in Ironic.
I could say that it’s pretty nice when one needs to make something simple but 
requires some manual job to be done in more or less sophisticated cases.
On the other hand we have that the Pecan team is quire agile and open to other 
developers so we were able to merge our patches without any problems.

However, if there is a framework that fits Nailgun's needs without being 
patched, that may be easier for us to just use it.

There’s a political side of the question as well but I’d rather touch it only 
if both Flask and Pecan have the same pros and cons.


- romcheg

> On 03 Dec 2014, at 14:22, Przemyslaw Kaminski  wrote:
> 
> Yeah, didn't notice that. Honestly, I'd prefer both to be accessible as 
> instance attributes just like in [1] but it's more of taste I guess.
> 
> [1] 
> http://tornado.readthedocs.org/en/latest/web.html#tornado.web.RequestHandler.request
>  
> 
> 
> P.
> 
> On 12/03/2014 02:03 PM, Sebastian Kalinowski wrote:
>> 
>> 2014-12-03 13:47 GMT+01:00 Igor Kalnitsky > >:
>> > I don't like that Flask uses a global request object [3].
>> 
>> Przemyslaw, actually Pecan does use global objects too. BTW, what's
>> wrong with global objects? They are thread-safe in both Pecan and
>> Flask.
>> 
>> To be fair, Pecan could also pass request and response explicit to method [1]
>> 
>> [1] http://pecan.readthedocs.org/en/latest/contextlocals.html 
>> 
>> 
>> 
>> ___
>> 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



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] [Fuel][Nailgun] Web framework

[Sebastian Kalinowski]

I never used Flask and Pecan personally so I can only rely from what I saw
in this thread and in both projects docs.
I don't have strong opinion, just want to share some thoughts.

I think that as a part of OpenStack community we should stick with Pecan
and because of the same reason
we can have a bigger impact how future versions of Pecan will look.

If we will choose Flask I see is that we not only need to choose a
framework, but also decide which
extension will be used to provide REST support (I do not like that we just
assume "flask-restful will be used").

To be honest right now I'm more convinced that we should choose Pecan.


2014-12-03 14:22 GMT+01:00 Nikolay Markov :

> Dear colleagues,
>
> We surely may take into account the beauty of the code in both cases
> (as for me, Pecan loses here, too) and argue about global objects and
> stuff, but I'm trying to look at amount of men and time we need to
> move to one of these frameworks.
>

Agree that we should look on the man-hours for implementation, but I think
that it is as
important as all the small things like global object etc. since they could
make future development
painful or pleasant.


> I wouldn't say our API is badly designed, nevertheless Pecan still has
> a lot of issues needed to be fixed by hand. We don't want to spend
> much time to this task, because it is mostly the matter of convenience
> and simplicity for developers, it changes nothing in features or
> customer-facing behavior.
>
> And if we take in account the amount of hours we need to move, based
> on my experience Flask definitely wins here.
>

Cannot we reuse the PoC ([1]) with Pecan that was created? There was a lot
of work put into that piece of code.

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

Re: [openstack-dev] oslo.concurrency 0.3.0 released

[Doug Hellmann]

On Dec 2, 2014, at 7:48 PM, Matt Riedemann  wrote:

> 
> 
> On 12/2/2014 12:33 PM, Ben Nemec wrote:
>> We've discovered a couple of problems as a result of this release.  pep8
>> in most/all of the projects using oslo.concurrency is failing due to the
>> move out of the oslo namespace package and the fact that hacking doesn't
>> know how to handle it, and nova unit tests are failing due to a problem
>> with the way some mocking was done.
>> 
>> Fixes for both of these problems are in progress and should hopefully be
>> available soon.
>> 
>> -Ben
>> 
>> On 12/02/2014 10:29 AM, Ben Nemec wrote:
>>> The Oslo team is pleased to announce the release of oslo.concurrency 0.3.0.
>>> 
>>> This release includes a number of fixes for problems found during the
>>> initial adoptions of the library, as well as some functionality
>>> improvements.
>>> 
>>> For more details, please see the git log history below and
>>> https://launchpad.net/oslo.concurrency/+milestone/0.3.0
>>> 
>>>  Please report issues through launchpad:
>>> https://launchpad.net/oslo.concurrency
>>> 
>>> openstack/oslo.concurrency  0.2.0..HEAD
>>> 
>>> 54c84da Add external lock fixture
>>> 19f07c6 Add a TODO for retrying pull request #20
>>> 46c836e Allow the lock delay to be provided
>>> 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 docs and test files):
>>> 
>>>  .gitignore |   1 +
>>>  .testr.conf|   2 +-
>>>  README.rst |   4 +-
>>>  .../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  |  76 +++
>>>  oslo_concurrency/lockutils.py  | 502 ++
>>>  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 
>>>  requirements-py3.txt   |   1 +
>>>  requirements.txt   |   1 +
>>>  setup.cfg  |   9 +-
>>>  tests/test_lockutils.py| 575
>>> 
>>>  tests/test_processutils.py | 519
>>> +++
>>>  tests/test_warning.py  |  29 ++
>>>  tests/unit/__init__.py |   0
>>>  tests/unit/test_lockutils.py   | 543
>>> ---
>>>  tests/unit/test_lockutils_eventlet.py  |  59 ---
>>>  tests/unit/test_processutils.py| 518 --
>>>  tox.ini|   8 +-
>>>  42 files changed, 3515 insertions(+), 2135 deletions(-)
>>> 
>>>   Requirements updates:
>>> 
>>>  diff --git a/requirements-py3.txt b/requirements-py3.txt
>>>  index b1a8722..a27b434 100644
>>>  --- a/requirements-py3.txt
>>>  +++ b/requirements-py3.txt
>>>  @@ -13,0 +14 @@ six>=1.7.0
>>>  +retrying>=1.2.2,!=1.3.0 # Apache-2.0
>>>  diff --git a/requirements.txt b/requirements.txt
>>>  index b1a8722..a27b434 100644
>>>  --- a/requirements.txt
>>>  +++ b/requirements.txt
>>>  @@ -13,0 +14 @@ six>=1.7.0
>>>  +retrying>=1.2.2,!=1.3.0 # Apache-2.0
>>> 
>> 
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> Was a bug reported for the nov

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

[Kyle Mestery]

Mathieu:

The peer review proposal was NOT about removing core reviewers, that
is very clear in the proposal. The peer review proposal was about
deciding as a team what it means to be a core reviewer, and ensuring
core reviewers are doing that. I still plan to do try out the peer
review process in the coming weeks. But even with that process,
reviews are the main thing a core reviewer must be doing. If you're
not doing reviews upstream, especially for long stretches, you're not
really a core reviewer.

Thanks,
Kyle

On Wed, Dec 3, 2014 at 4:41 AM, Mathieu Rohon  wrote:
> Hi all,
>
> It seems that a process with a survey for neutron core
> election/removal was about to take place [1]. Has it been applied for
> this proposal?
> This proposal has been hardly discussed during neutron meetings
> [2][3]. Many cores agree that the number of reviews shouldn't be the
> only metrics. And this statement is reflected in the Survey Questions.
> So I'm surprised to see such a proposal based on stackalitics figures.
>
> [1]https://etherpad.openstack.org/p/neutron-peer-review
> [2]http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-10-13-21.02.log.html
> [3]http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-10-21-14.00.log.html
>
> On Wed, Dec 3, 2014 at 9:44 AM, Oleg Bondarev  wrote:
>> +1! Congrats, Henry and Kevin!
>>
>> On Tue, Dec 2, 2014 at 6:59 PM, Kyle Mestery  wrote:
>>>
>>> Now that we're in the thick of working hard on Kilo deliverables, I'd
>>> like to make some changes to the neutron core team. Reviews are the
>>> most important part of being a core reviewer, so we need to ensure
>>> cores are doing reviews. The stats for the 180 day period [1] indicate
>>> some changes are needed for cores who are no longer reviewing.
>>>
>>> First of all, I'm proposing we remove Bob Kukura and Nachi Ueno from
>>> neutron-core. Bob and Nachi have been core members for a while now.
>>> They have contributed to Neutron over the years in reviews, code and
>>> leading sub-teams. I'd like to thank them for all that they have done
>>> over the years. I'd also like to propose that should they start
>>> reviewing more going forward the core team looks to fast track them
>>> back into neutron-core. But for now, their review stats place them
>>> below the rest of the team for 180 days.
>>>
>>> As part of the changes, I'd also like to propose two new members to
>>> neutron-core: Henry Gessau and Kevin Benton. Both Henry and Kevin have
>>> been very active in reviews, meetings, and code for a while now. Henry
>>> lead the DB team which fixed Neutron DB migrations during Juno. Kevin
>>> has been actively working across all of Neutron, he's done some great
>>> work on security fixes and stability fixes in particular. Their
>>> comments in reviews are insightful and they have helped to onboard new
>>> reviewers and taken the time to work with people on their patches.
>>>
>>> Existing neutron cores, please vote +1/-1 for the addition of Henry
>>> and Kevin to the core team.
>>>
>>> Thanks!
>>> Kyle
>>>
>>> [1] http://stackalytics.com/report/contribution/neutron-group/180
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Nova][Cinder] Operations: adding new nodes in "disabled" state, allowed for test tenant only

[Ivan Kolodyazhny]

Hi Mike,

We've got the similar option in Cinder too:
https://github.com/openstack/cinder/blob/master/cinder/db/api.py#L58


Regards,
Ivan Kolodyazhny

On Wed, Dec 3, 2014 at 3:31 PM, Mike Scherbakov 
wrote:

> Hi all,
> enable_new_services in nova.conf seems to allow add new compute nodes in
> disabled state:
>
> https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L507-L508,
> so it would allow to check everything first, before allowing production
> workloads host a VM on it. I've filed a bug to Fuel to use this by default
> when we scale up the env (add more computes) [1].
>
> A few questions:
>
>1. can we somehow enable compute service for test tenant first? So
>cloud administrator would be able to run test VMs on the node, and after
>ensuring that everything is fine - to enable service for all tenants
>2. What about Cinder? Is there a similar option / ability?
>3. What about other OpenStack projects?
>
> What is your opinion, how we should approach the problem (if there is a
> problem)?
>
> [1] https://bugs.launchpad.net/fuel/+bug/1398817
> --
> Mike Scherbakov
> #mihgen
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] [libvirt] enabling per node filtering of mempage sizes

[Daniel P. Berrange]

On Wed, Dec 03, 2014 at 01:28:36PM +, Mooney, Sean K wrote:
> Hi 
> 
> Unfortunately a flavor + aggregate is not enough for our use case as it is 
> still possible for the tenant to misconfigure a vm.
> 
> The edge case not covered by flavor + aggregate that we are trying to prevent 
> is as follows.
> 
> The operator creates an aggregate containing the  nodes that require all VMs 
> to use large pages.
> The operator creates flavors with and without memory backing specified.
> 
> The tenant selects the aggregate containing nodes that only supports 
> hugepages and a flavor that requires small or any.
> Or 
> The tenant selects a flavor that requires small or any and does not select an 
> aggregate.

The tenant isn't responsible for selecting the aggregate. The operator
should be associating the aggregate directly to the flavour. So the
tenant merely has to select the right flavour.

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

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

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

[Tomas Sedovic]

On 12/03/2014 11:11 AM, Steven Hardy wrote:

Hi all,

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

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



You beat me to this. Thanks for writing it up!


This raises the following questions:

1. Is it reasonable to -1 a patch and ask folks to update in both places?


I'm in favour.


2. How are we going to handle this duplication and divergence?


I'm not sure we can. get_file doesn't handle structured data and I don't 
know what else we can do. Maybe we could split out all SoftwareConfig 
resources to separate files (like Dan did in [nova config])? But the 
SoftwareDeployments, nova servers, etc. have a different structure.


[nova config] https://review.openstack.org/#/c/130303/


3. What's the status of getting gating CI on the --no-mergepy templates?


Derek, can we add a job that's identical to 
"check-tripleo-ironic-overcloud-{f20,precise}-nonha" except it passes 
"--no-mergepy" to devtest.sh?



4. What barriers exist (now that I've implemented[2] the eliding functionality
requested[3] for ResourceGroup) to moving to the --no-mergepy
implementation by default?


I'm about to post a patch that moves us from ResourceGroup to 
AutoScalingGroup (for rolling updates), which is going to complicate 
this a bit.


Barring that, I think you've identified all the requirements: CI job, 
parity between the merge/non-merge templates and a process that 
maintains it going forward (or puts the old ones in a maintanence-only 
mode).


Anyone have anything else that's missing?



Thanks for any clarification you can provide! :)

Steve

[1] https://review.openstack.org/#/c/123100/
[2] https://review.openstack.org/#/c/128365/
[3] https://review.openstack.org/#/c/123713/

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





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

[openstack-dev] [Nova][Cinder] Operations: adding new nodes in "disabled" state, allowed for test tenant only

[Mike Scherbakov]

Hi all,
enable_new_services in nova.conf seems to allow add new compute nodes in
disabled state:
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L507-L508,
so it would allow to check everything first, before allowing production
workloads host a VM on it. I've filed a bug to Fuel to use this by default
when we scale up the env (add more computes) [1].

A few questions:

   1. can we somehow enable compute service for test tenant first? So cloud
   administrator would be able to run test VMs on the node, and after ensuring
   that everything is fine - to enable service for all tenants
   2. What about Cinder? Is there a similar option / ability?
   3. What about other OpenStack projects?

What is your opinion, how we should approach the problem (if there is a
problem)?

[1] https://bugs.launchpad.net/fuel/+bug/1398817
-- 
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] [nova] [libvirt] enabling per node filtering of mempage sizes

[Mooney, Sean K]

Hi 

Unfortunately a flavor + aggregate is not enough for our use case as it is 
still possible for the tenant to misconfigure a vm.

The edge case not covered by flavor + aggregate that we are trying to prevent 
is as follows.

The operator creates an aggregate containing the  nodes that require all VMs to 
use large pages.
The operator creates flavors with and without memory backing specified.

The tenant selects the aggregate containing nodes that only supports hugepages 
and a flavor that requires small or any.
Or 
The tenant selects a flavor that requires small or any and does not select an 
aggregate.

In both cases because the nodes may have non huge page memory available, it is 
possible to schedule
A vm that will not use large pages to a node that requires large pages to be 
used.

If this happens the behavior is undefined.
The vm may boot and have not network connectivity in the case of vhost-user
The vm may fail to boot  or it may boot in some other error state.

It would be possible however to introduce a new filter 
(AggregateMemoryBackingFilter)

The AggregateMemoryBackingFilter would work as follows.
The AggregateMemoryBackingFilter  will compare the extra specifications 
associated with the instance and enforces the constraints set in the aggregate 
metadata.

A new MemoryBacking attribute will be added to the aggregate metadata.
The MemoryBacking  attribute can be set to 1 or more of the flowing: 
small,large,4,2048,1048576
Syntax is SizeA,SizeB e.g. 2048,1048576

If small is set then host will only be passed if the vm requests small or 4k 
pages.
If large is set then host will only be passed if the vm requests  2MB or 1GB.
If the MemoryBacking element is not set for an aggregate the 
AggregateMemoryBackingFilter  will pass all hosts

With this new filter the (flavor or image properties) + aggregate approach 
would work for all driver not just libvirt.

If this alternative is preferred I can resubmit as a new blueprint and mark the 
old blueprint as superseded.

Regards 
Sean.

-Original Message-
From: Daniel P. Berrange [mailto:berra...@redhat.com] 
Sent: Wednesday, December 3, 2014 10:13 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] [libvirt] enabling per node filtering of 
mempage sizes

On Wed, Dec 03, 2014 at 10:03:06AM +0100, Sahid Orentino Ferdjaoui wrote:
> On Tue, Dec 02, 2014 at 07:44:23PM +, Mooney, Sean K wrote:
> > Hi all
> > 
> > I have submitted a small blueprint to allow filtering of available 
> > memory pages Reported by libvirt.
> 
> Can you address this with aggregate? this will also avoid to do 
> something specific in the driver libvirt. Which will have to be 
> extended to other drivers at the end.

Agreed, I think you can address this by setting up host aggregates and then 
using setting the desired page size on the flavour.

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

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

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

Re: [openstack-dev] [Fuel][Nailgun] Web framework

[Nikolay Markov]

Dear colleagues,

We surely may take into account the beauty of the code in both cases
(as for me, Pecan loses here, too) and argue about global objects and
stuff, but I'm trying to look at amount of men and time we need to
move to one of these frameworks.

I wouldn't say our API is badly designed, nevertheless Pecan still has
a lot of issues needed to be fixed by hand. We don't want to spend
much time to this task, because it is mostly the matter of convenience
and simplicity for developers, it changes nothing in features or
customer-facing behavior.

And if we take in account the amount of hours we need to move, based
on my experience Flask definitely wins here.

On Wed, Dec 3, 2014 at 4:03 PM, Sebastian Kalinowski
 wrote:
>
> 2014-12-03 13:47 GMT+01:00 Igor Kalnitsky :
>>
>> > I don't like that Flask uses a global request object [3].
>>
>> Przemyslaw, actually Pecan does use global objects too. BTW, what's
>> wrong with global objects? They are thread-safe in both Pecan and
>> Flask.
>
>
> To be fair, Pecan could also pass request and response explicit to method
> [1]
>
> [1] http://pecan.readthedocs.org/en/latest/contextlocals.html
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Nick Markov

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

Re: [openstack-dev] How to get openstack bugs data for research?

[Angelo Matarazzo]

Hi,
you could take a look at Stackalytics and how this website communicates 
with launchpad.


https://wiki.openstack.org/wiki/Stackalytics/HowToRun

Best,
Angelo

On 03/12/2014 13:41, Louis Taylor wrote:

On Wed, Dec 03, 2014 at 08:20:45PM +0800, zfx0...@gmail.com wrote:

Hi, all

I am a graduate student in Peking University, our lab do some research on open 
source projects.
This is our introduction: https://passion-lab.org/

Now we need openstack issues data for research, I found the issues list: 
https://bugs.launchpad.net/openstack/
I want to download the openstack issues data, Could anyone tell me how to 
download the data? Or is there some link or API for download the data?

And I found 9464  bugs in https://bugs.launchpad.net/openstack/ ??is this all? 
why so few?

That is the number of currently open bugs. There are 47733 bugs including
closed ones. Launchpad has an API [1], which can probably list the bugs filed
against a project.

[1] https://help.launchpad.net/API


___
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] [ux] Changing how the modals are closed in Horizon

[Rob Cresswell (rcresswe)]

+1 to changing the behaviour to ‘static'. Modal inside a modal is potentially 
slightly more useful, but looks messy and inconsistent, which I think outweighs 
the functionality.

Rob


On 2 Dec 2014, at 12:21, Timur Sufiev 
mailto:tsuf...@mirantis.com>> wrote:

Hello, Horizoneers and UX-ers!

The default behavior of modals in Horizon (defined in turn by Bootstrap 
defaults) regarding their closing is to simply close the modal once user clicks 
somewhere outside of it (on the backdrop element below and around the modal). 
This is not very convenient for the modal forms containing a lot of input - 
when it is closed without a warning all the data the user has already provided 
is lost. Keeping this in mind, I've made a patch [1] changing default Bootstrap 
'modal_backdrop' parameter to 'static', which means that forms are not closed 
once the user clicks on a backdrop, while it's still possible to close them by 
pressing 'Esc' or clicking on the 'X' link at the top right border of the form. 
Also the patch [1] allows to customize this behavior (between 'true'-current 
one/'false' - no backdrop element/'static') on a per-form basis.

What I didn't know at the moment I was uploading my patch is that David Lyle 
had been working on a similar solution [2] some time ago. It's a bit more 
elaborate than mine: if the user has already filled some some inputs in the 
form, then a confirmation dialog is shown, otherwise the form is silently 
dismissed as it happens now.

The whole point of writing about this in the ML is to gather opinions which 
approach is better:
* stick to the current behavior;
* change the default behavior to 'static';
* use the David's solution with confirmation dialog (once it'll be rebased to 
the current codebase).

What do you think?

[1] https://review.openstack.org/#/c/113206/
[2] https://review.openstack.org/#/c/23037/

P.S. I remember that I promised to write this email a week ago, but better late 
than never :).

--
Timur Sufiev
___
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][Nailgun] Web framework

[Przemyslaw Kaminski]

Yeah, didn't notice that. Honestly, I'd prefer both to be accessible as 
instance attributes just like in [1] but it's more of taste I guess.


[1] 
http://tornado.readthedocs.org/en/latest/web.html#tornado.web.RequestHandler.request


P.

On 12/03/2014 02:03 PM, Sebastian Kalinowski wrote:


2014-12-03 13:47 GMT+01:00 Igor Kalnitsky >:


> I don't like that Flask uses a global request object [3].

Przemyslaw, actually Pecan does use global objects too. BTW, what's
wrong with global objects? They are thread-safe in both Pecan and
Flask.


To be fair, Pecan could also pass request and response explicit to 
method [1]


[1] http://pecan.readthedocs.org/en/latest/contextlocals.html


___
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][Nailgun] Web framework

[Sebastian Kalinowski]

2014-12-03 13:47 GMT+01:00 Igor Kalnitsky :

> > I don't like that Flask uses a global request object [3].
>
> Przemyslaw, actually Pecan does use global objects too. BTW, what's
> wrong with global objects? They are thread-safe in both Pecan and
> Flask.
>

To be fair, Pecan could also pass request and response explicit to method
[1]

[1] http://pecan.readthedocs.org/en/latest/contextlocals.html
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Nailgun] Web framework

[Igor Kalnitsky]

> I don't like that Flask uses a global request object [3].

Przemyslaw, actually Pecan does use global objects too. BTW, what's
wrong with global objects? They are thread-safe in both Pecan and
Flask.

> IMHO documentation is better written, and described a lot of possibilities of 
> modification

I disagree. Flask has rich documentation and more flexible, while
Pecan forces us to use only its patterns and code organization. There
are no possibilities to avoid this.

I'm afraid with Pecan we will have to rewrite a lot of code.

On Wed, Dec 3, 2014 at 2:21 PM, Kamil Sambor  wrote:
> Additionaly  to what Przemek wrote, also Pecan is released more often, IMHO
> documentation is better written, and described a lot of possibilities of
> modification, also as Lukasz wrote in previous thread that Pecan is used in
> openstack.
>
> So I'm also for Pecan
>
> Best regards,
> Kamil S.
>
> On Wed, Dec 3, 2014 at 12:45 PM, Przemyslaw Kaminski
>  wrote:
>>
>> The only useful paradigm to write in Flask is MethodView's for me [1]
>> because decorators seem hard to refactor for large projects. Please look at
>> adding URLs -- one has to additionally specify methods to match those from
>> the MethodView -- this is code duplication and looks ugly.
>>
>> It seems though that Fask-RESTful [2] fixes this but then we're dependent
>> on 2 projects.
>>
>> I don't like that Flask uses a global request object [3]. From Flask
>> documentation
>>
>> "Basically you can completely ignore that this is the case unless you are
>> doing something like unit testing. You will notice that code which depends
>> on a request object will suddenly break because there is no request object.
>> The solution is creating a request object yourself and binding it to the
>> context."
>>
>> Yeah, let's make testing even harder...
>>
>> Pecan looks better in respect of RESTful services [4].
>> POST parameters are cleanly passed as arguments to the post method. It
>> also provides custom JSON serialization hooks [5] so we can forget about
>> explicit serialization in handlers.
>>
>> So from these 2 choices I'm for Pecan.
>>
>> [1] http://flask.pocoo.org/docs/0.10/views/#method-views-for-apis
>> [2] https://flask-restful.readthedocs.org/en/0.3.0/
>> [3] http://flask.pocoo.org/docs/0.10/quickstart/#accessing-request-data
>> [4] http://pecan.readthedocs.org/en/latest/rest.html
>> [5] http://pecan.readthedocs.org/en/latest/jsonify.html
>>
>>
>> P.
>>
>>
>> On 12/03/2014 10:57 AM, Alexander Kislitsky wrote:
>>
>> We had used Flask in the fuel-stats. It was easy and pleasant and all
>> project requirements was satisfied. And I saw difficulties and workarounds
>> with Pecan, when Nick integrated it into Nailgun.
>> So +1 for Flask.
>>
>>
>> On Tue, Dec 2, 2014 at 11:00 PM, Nikolay Markov 
>> wrote:
>>>
>>> Michael, we already solved all issues I described, and I just don't
>>> want to solve them once again after moving to another framework. Also,
>>> I think, nothing of these wishes contradicts with good API design.
>>>
>>> On Tue, Dec 2, 2014 at 10:49 PM, Michael Krotscheck
>>>  wrote:
>>> > This sounds more like you need to pay off technical debt and clean up
>>> > your
>>> > API.
>>> >
>>> > Michael
>>> >
>>> > On Tue Dec 02 2014 at 10:58:43 AM Nikolay Markov 
>>> > wrote:
>>> >>
>>> >> Hello all,
>>> >>
>>> >> I actually tried to use Pecan and even created a couple of PoCs, but
>>> >> there due to historical reasons of how our API is organized it will
>>> >> take much more time to implement all workarounds we need to issues
>>> >> Pecan doesn't solve out of the box, like working with non-RESTful
>>> >> URLs, reverse URL lookup, returning custom body in 404 response,
>>> >> wrapping errors to JSON automatically, etc.
>>> >>
>>> >> As far as I see, each OpenStack project implements its own workarounds
>>> >> for these issues, but still it requires much less men and hours for us
>>> >> to move to Flask-Restful instead of Pecan, because all these problems
>>> >> are already solved there.
>>> >>
>>> >> BTW, I know a lot of pretty big projects using Flask (it's the second
>>> >> most popular Web framework after Django in Python Web community), they
>>> >> even have their own "hall of fame":
>>> >> http://flask.pocoo.org/community/poweredby/ .
>>> >>
>>> >> On Tue, Dec 2, 2014 at 7:13 PM, Ryan Brown  wrote:
>>> >> > On 12/02/2014 09:55 AM, Igor Kalnitsky wrote:
>>> >> >> Hi, Sebastian,
>>> >> >>
>>> >> >> Thank you for raising this topic again.
>>> >> >>
>>> >> >> [snip]
>>> >> >>
>>> >> >> Personally, I'd like to use Flask instead of Pecan, because first
>>> >> >> one
>>> >> >> is more production-ready tool and I like its design. But I believe
>>> >> >> this should be resolved by voting.
>>> >> >>
>>> >> >> Thanks,
>>> >> >> Igor
>>> >> >>
>>> >> >> On Tue, Dec 2, 2014 at 4:19 PM, Sebastian Kalinowski
>>> >> >>  wrote:
>>> >> >>> Hi all,
>>> >> >>>
>>> >> >>> [snip explanation+history]
>>> >> >>>
>>> >> >>> Best,
>>> >> >>> Sebastian
>>> >> >
>>> >> > Given that Peca

Re: [openstack-dev] How to get openstack bugs data for research?

[Louis Taylor]

On Wed, Dec 03, 2014 at 08:20:45PM +0800, zfx0...@gmail.com wrote:
> Hi, all
> 
> I am a graduate student in Peking University, our lab do some research on 
> open source projects. 
> This is our introduction: https://passion-lab.org/
> 
> Now we need openstack issues data for research, I found the issues list: 
> https://bugs.launchpad.net/openstack/
> I want to download the openstack issues data, Could anyone tell me how to 
> download the data? Or is there some link or API for download the data?
> 
> And I found 9464  bugs in https://bugs.launchpad.net/openstack/ ??is this 
> all? why so few?

That is the number of currently open bugs. There are 47733 bugs including
closed ones. Launchpad has an API [1], which can probably list the bugs filed
against a project.

[1] https://help.launchpad.net/API


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

[openstack-dev] [python-novaclient] Status of novaclient V3

[Andrey Kurilin]

Thank for answers.
I sent a patch to novaclient : https://review.openstack.org/#/c/138694/

On Wed, Dec 3, 2014 at 1:59 PM, Christopher Yeoh > wrote:

>
>
>
> On 3 Dec 2014, at 10:00 pm, Joe Gordon  > wrote:
>
>
>
> On Tue, Dec 2, 2014 at 5:21 PM, Andrey Kurilin  > wrote:
>
>> Hi!
>>
>> While working on fixing wrong import in novaclient v3 shell, I have found
>> that a lot of commands, which are listed in V3 shell(novaclient.v3.shell),
>> are broken, because appropriate managers are missed from V3
>> client(novaclient.V3.client.Client).
>>
>> Template of error is "ERROR (AttributeError): 'Client' object has no
>> attribute ''", where  can be "floating_ip_pools",
>> "floating_ip", "security_groups", "dns_entries" and etc.
>>
>> I know that novaclient V3 is not finished yet, and I guess it will be not
>> finished. So the main question is:
>>  What we should do with implemented code of novaclient V3 ? Should it be
>> ported to novaclient V2.1 or it can be removed?
>>
>
> I think it can be removed, as we are not going forward with the V3 API.
> But I will defer to Christopher Yeoh/Ken’ichi Ohmichi for the details.
>
>
>
> I think it can all just be removed now. We're going to need to enhance
> nova client to understand micro versions instead. But for now v2.1 should
> look just like v2
>
> Chris
>
>
>
>>
>>
>> --
>> Best regards,
>> Andrey Kurilin.
>>
>> ___
>> 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
>
>


-- 
Best regards,
Andrey Kurilin.


-- 
Best regards,
Andrey Kurilin.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Nailgun] Web framework

[Kamil Sambor]

Additionaly  to what Przemek wrote, also Pecan is released more often, IMHO
documentation is better written, and described a lot of possibilities of
modification, also as Lukasz wrote in previous thread that Pecan is used in
openstack.

So I'm also for Pecan

Best regards,
Kamil S.

On Wed, Dec 3, 2014 at 12:45 PM, Przemyslaw Kaminski  wrote:

>  The only useful paradigm to write in Flask is MethodView's for me [1]
> because decorators seem hard to refactor for large projects. Please look at
> adding URLs -- one has to additionally specify methods to match those from
> the MethodView -- this is code duplication and looks ugly.
>
> It seems though that Fask-RESTful [2] fixes this but then we're dependent
> on 2 projects.
>
> I don't like that Flask uses a global request object [3]. From Flask
> documentation
>
> "Basically you can completely ignore that this is the case unless you are
> doing something like unit testing. You will notice that code which depends
> on a request object will suddenly break because there is no request object.
> The solution is creating a request object yourself and binding it to the
> context."
>
> Yeah, let's make testing even harder...
>
> Pecan looks better in respect of RESTful services [4].
> POST parameters are cleanly passed as arguments to the post method. It
> also provides custom JSON serialization hooks [5] so we can forget about
> explicit serialization in handlers.
>
> So from these 2 choices I'm for Pecan.
>
> [1] http://flask.pocoo.org/docs/0.10/views/#method-views-for-apis
> [2] https://flask-restful.readthedocs.org/en/0.3.0/
> [3] http://flask.pocoo.org/docs/0.10/quickstart/#accessing-request-data
> [4] http://pecan.readthedocs.org/en/latest/rest.html
> [5] http://pecan.readthedocs.org/en/latest/jsonify.html
>
>
> P.
>
>
> On 12/03/2014 10:57 AM, Alexander Kislitsky wrote:
>
>  We had used Flask in the fuel-stats. It was easy and pleasant and all
> project requirements was satisfied. And I saw difficulties and workarounds
> with Pecan, when Nick integrated it into Nailgun.
> So +1 for Flask.
>
>
> On Tue, Dec 2, 2014 at 11:00 PM, Nikolay Markov 
> wrote:
>
>> Michael, we already solved all issues I described, and I just don't
>> want to solve them once again after moving to another framework. Also,
>> I think, nothing of these wishes contradicts with good API design.
>>
>> On Tue, Dec 2, 2014 at 10:49 PM, Michael Krotscheck
>>  wrote:
>> > This sounds more like you need to pay off technical debt and clean up
>> your
>> > API.
>> >
>> > Michael
>> >
>> > On Tue Dec 02 2014 at 10:58:43 AM Nikolay Markov 
>> > wrote:
>> >>
>> >> Hello all,
>> >>
>> >> I actually tried to use Pecan and even created a couple of PoCs, but
>> >> there due to historical reasons of how our API is organized it will
>> >> take much more time to implement all workarounds we need to issues
>> >> Pecan doesn't solve out of the box, like working with non-RESTful
>> >> URLs, reverse URL lookup, returning custom body in 404 response,
>> >> wrapping errors to JSON automatically, etc.
>> >>
>> >> As far as I see, each OpenStack project implements its own workarounds
>> >> for these issues, but still it requires much less men and hours for us
>> >> to move to Flask-Restful instead of Pecan, because all these problems
>> >> are already solved there.
>> >>
>> >> BTW, I know a lot of pretty big projects using Flask (it's the second
>> >> most popular Web framework after Django in Python Web community), they
>> >> even have their own "hall of fame":
>> >> http://flask.pocoo.org/community/poweredby/ .
>> >>
>> >> On Tue, Dec 2, 2014 at 7:13 PM, Ryan Brown  wrote:
>> >> > On 12/02/2014 09:55 AM, Igor Kalnitsky wrote:
>> >> >> Hi, Sebastian,
>> >> >>
>> >> >> Thank you for raising this topic again.
>> >> >>
>> >> >> [snip]
>> >> >>
>> >> >> Personally, I'd like to use Flask instead of Pecan, because first
>> one
>> >> >> is more production-ready tool and I like its design. But I believe
>> >> >> this should be resolved by voting.
>> >> >>
>> >> >> Thanks,
>> >> >> Igor
>> >> >>
>> >> >> On Tue, Dec 2, 2014 at 4:19 PM, Sebastian Kalinowski
>> >> >>  wrote:
>> >> >>> Hi all,
>> >> >>>
>> >> >>> [snip explanation+history]
>> >> >>>
>> >> >>> Best,
>> >> >>> Sebastian
>> >> >
>> >> > Given that Pecan is used for other OpenStack projects and has plenty
>> of
>> >> > builtin functionality (REST support, sessions, etc) I'd prefer it
>> for a
>> >> > number of reasons.
>> >> >
>> >> > 1) Wouldn't have to pull in plugins for standard (in Pecan) things
>> >> > 2) Pecan is built for high traffic, where Flask is aimed at much
>> smaller
>> >> > projects
>> >> > 3) Already used by other OpenStack projects, so common patterns can
>> be
>> >> > reused as oslo libs
>> >> >
>> >> > Of course, the Flask community seems larger (though the average flask
>> >> > project seems pretty small).
>> >> >
>> >> > I'm not sure what determines "production readiness", but it seems to
>> me
>> >> > like Fuel developers fall more in Pecan

[openstack-dev] How to get openstack bugs data for research?

[zfx0...@gmail.com]

Hi, all

I am a graduate student in Peking University, our lab do some research on open 
source projects. 
This is our introduction: https://passion-lab.org/

Now we need openstack issues data for research, I found the issues list: 
https://bugs.launchpad.net/openstack/
I want to download the openstack issues data, Could anyone tell me how to 
download the data? Or is there some link or API for download the data?

And I found 9464  bugs in https://bugs.launchpad.net/openstack/ ，is this all? 
why so few?

Many thanks!

Beat regards,
Feixue, Zhang



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

[openstack-dev] [Neutron] DVR Slides from Paris Summit

[Andreas Scheuring]

Hi, 
is there a way to get access to the slides from the DVR session of the
Paris summit? Unfortunately the slides in the video are not readable. 

Speakers were Swaminathan Vasudevan, Jack McCann, Vivekanandan,
Narasimhan, Rajeev Grover, Michael Smith. So maybe one of you can post
them on slideshare or somewhere else? That would be great.

This is the link to the related video

https://www.openstack.org/summit/openstack-paris-summit-2014/session-videos/presentation/architectural-overview-of-distributed-virtual-routers-in-openstack-neutron



Thanks

-- 
Andreas 
(irc: scheuran)




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

Re: [openstack-dev] [python-novaclient] Status of novaclient V3

[Christopher Yeoh]

> On 3 Dec 2014, at 10:00 pm, Joe Gordon  wrote:
> 
> 
> 
>> On Tue, Dec 2, 2014 at 5:21 PM, Andrey Kurilin  wrote:
>> Hi!
>> 
>> While working on fixing wrong import in novaclient v3 shell, I have found 
>> that a lot of commands, which are listed in V3 shell(novaclient.v3.shell), 
>> are broken, because appropriate managers are missed from V3 
>> client(novaclient.V3.client.Client).
>> 
>> Template of error is "ERROR (AttributeError): 'Client' object has no 
>> attribute ''", where  can be "floating_ip_pools", "floating_ip", 
>> "security_groups", "dns_entries" and etc.
>> 
>> I know that novaclient V3 is not finished yet, and I guess it will be not 
>> finished. So the main question is:
>>  What we should do with implemented code of novaclient V3 ? Should it be 
>> ported to novaclient V2.1 or it can be removed?
> 
> I think it can be removed, as we are not going forward with the V3 API. But I 
> will defer to Christopher Yeoh/Ken’ichi Ohmichi for the details.


I think it can all just be removed now. We're going to need to enhance nova 
client to understand micro versions instead. But for now v2.1 should look just 
like v2

Chris

>  
>> 
>> 
>> -- 
>> Best regards,
>> Andrey Kurilin.
>> 
>> ___
>> 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][Nailgun] Web framework

[Przemyslaw Kaminski]

The only useful paradigm to write in Flask is MethodView's for me [1] 
because decorators seem hard to refactor for large projects. Please look 
at adding URLs -- one has to additionally specify methods to match those 
from the MethodView -- this is code duplication and looks ugly.


It seems though that Fask-RESTful [2] fixes this but then we're 
dependent on 2 projects.


I don't like that Flask uses a global request object [3]. From Flask 
documentation


"Basically you can completely ignore that this is the case unless you 
are doing something like unit testing. You will notice that code which 
depends on a request object will suddenly break because there is no 
request object. The solution is creating a request object yourself and 
binding it to the context."


Yeah, let's make testing even harder...

Pecan looks better in respect of RESTful services [4].
POST parameters are cleanly passed as arguments to the post method. It 
also provides custom JSON serialization hooks [5] so we can forget about 
explicit serialization in handlers.


So from these 2 choices I'm for Pecan.

[1] http://flask.pocoo.org/docs/0.10/views/#method-views-for-apis
[2] https://flask-restful.readthedocs.org/en/0.3.0/
[3] http://flask.pocoo.org/docs/0.10/quickstart/#accessing-request-data
[4] http://pecan.readthedocs.org/en/latest/rest.html
[5] http://pecan.readthedocs.org/en/latest/jsonify.html


P.

On 12/03/2014 10:57 AM, Alexander Kislitsky wrote:
We had used Flask in the fuel-stats. It was easy and pleasant and all 
project requirements was satisfied. And I saw difficulties and 
workarounds with Pecan, when Nick integrated it into Nailgun.

So +1 for Flask.


On Tue, Dec 2, 2014 at 11:00 PM, Nikolay Markov > wrote:


Michael, we already solved all issues I described, and I just don't
want to solve them once again after moving to another framework. Also,
I think, nothing of these wishes contradicts with good API design.

On Tue, Dec 2, 2014 at 10:49 PM, Michael Krotscheck
mailto:krotsch...@gmail.com>> wrote:
> This sounds more like you need to pay off technical debt and
clean up your
> API.
>
> Michael
>
> On Tue Dec 02 2014 at 10:58:43 AM Nikolay Markov
mailto:nmar...@mirantis.com>>
> wrote:
>>
>> Hello all,
>>
>> I actually tried to use Pecan and even created a couple of
PoCs, but
>> there due to historical reasons of how our API is organized it will
>> take much more time to implement all workarounds we need to issues
>> Pecan doesn't solve out of the box, like working with non-RESTful
>> URLs, reverse URL lookup, returning custom body in 404 response,
>> wrapping errors to JSON automatically, etc.
>>
>> As far as I see, each OpenStack project implements its own
workarounds
>> for these issues, but still it requires much less men and hours
for us
>> to move to Flask-Restful instead of Pecan, because all these
problems
>> are already solved there.
>>
>> BTW, I know a lot of pretty big projects using Flask (it's the
second
>> most popular Web framework after Django in Python Web
community), they
>> even have their own "hall of fame":
>> http://flask.pocoo.org/community/poweredby/ .
>>
>> On Tue, Dec 2, 2014 at 7:13 PM, Ryan Brown mailto:rybr...@redhat.com>> wrote:
>> > On 12/02/2014 09:55 AM, Igor Kalnitsky wrote:
>> >> Hi, Sebastian,
>> >>
>> >> Thank you for raising this topic again.
>> >>
>> >> [snip]
>> >>
>> >> Personally, I'd like to use Flask instead of Pecan, because
first one
>> >> is more production-ready tool and I like its design. But I
believe
>> >> this should be resolved by voting.
>> >>
>> >> Thanks,
>> >> Igor
>> >>
>> >> On Tue, Dec 2, 2014 at 4:19 PM, Sebastian Kalinowski
>> >> mailto:skalinow...@mirantis.com>>
wrote:
>> >>> Hi all,
>> >>>
>> >>> [snip explanation+history]
>> >>>
>> >>> Best,
>> >>> Sebastian
>> >
>> > Given that Pecan is used for other OpenStack projects and has
plenty of
>> > builtin functionality (REST support, sessions, etc) I'd
prefer it for a
>> > number of reasons.
>> >
>> > 1) Wouldn't have to pull in plugins for standard (in Pecan)
things
>> > 2) Pecan is built for high traffic, where Flask is aimed at
much smaller
>> > projects
>> > 3) Already used by other OpenStack projects, so common
patterns can be
>> > reused as oslo libs
>> >
>> > Of course, the Flask community seems larger (though the
average flask
>> > project seems pretty small).
>> >
>> > I'm not sure what determines "production readiness", but it
seems to me
>> > like Fuel developers fall more in Pecan's target audience than in
>> > Flask's.
>> >
>> > My $0.02,
>> > Ryan
>> >
>> > --
>> > Ryan Brown / Software En

Re: [openstack-dev] [python-novaclient] Status of novaclient V3

[Joe Gordon]

On Tue, Dec 2, 2014 at 5:21 PM, Andrey Kurilin 
wrote:

> Hi!
>
> While working on fixing wrong import in novaclient v3 shell, I have found
> that a lot of commands, which are listed in V3 shell(novaclient.v3.shell),
> are broken, because appropriate managers are missed from V3
> client(novaclient.V3.client.Client).
>
> Template of error is "ERROR (AttributeError): 'Client' object has no
> attribute ''", where  can be "floating_ip_pools",
> "floating_ip", "security_groups", "dns_entries" and etc.
>
> I know that novaclient V3 is not finished yet, and I guess it will be not
> finished. So the main question is:
>  What we should do with implemented code of novaclient V3 ? Should it be
> ported to novaclient V2.1 or it can be removed?
>

I think it can be removed, as we are not going forward with the V3 API. But
I will defer to Christopher Yeoh/Ken’ichi Ohmichi for the details.


>
>
> --
> Best regards,
> Andrey Kurilin.
>
> ___
> 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] [stable] Exception proposals for 2014.2.1

[Flavio Percoco]

On 03/12/14 11:02 +0100, Thierry Carrez wrote:

Doug Hellmann wrote:


On Dec 2, 2014, at 5:41 PM, Alan Pevec  wrote:


General: cap Oslo and client library versions - sync from
openstack/requirements stable/juno, would be good to include in
the release.
https://review.openstack.org/#/q/status:open+branch:stable/juno+topic:openstack/requirements,n,z


+2,



let's keep all deps in sync. Those updates do not break anything
for existing users.


Just spotted it, there is now proposal to revert caps in Juno:

https://review.openstack.org/138546

Doug, shall we stop merging caps to projects in Juno?


Today we found that when we have caps in place that do not overlap with the 
versions used in master, we can’t upgrade services one at a time on a host 
running multiple services. We didn’t have this problem between icehouse and 
juno because I used the same cap values for both releases, so we didn’t trigger 
any problems with grenade.

One solution is to undo the caps and then add caps when we discover issues in 
new versions of libraries and stable branches. Another is to require 
applications to work with “old” versions of libraries and degrade their feature 
set, so that we can keep the lower bounds overlapping.

In retrospect, this issue with caps was obvious, but I don’t remember it being 
raise in the planning. As Sean pointed out on IRC today, we should have someone 
write a spec for changing the way we deal with requirements so we can think 
about it before deciding what to do.

After the releases today, the “no more alpha versions for Oslo” ship has 
sailed. Removing the caps will at least let us move ahead while we figure out 
what to do for stable branches.


Yes, looks like we need to think a bit deeper about it, and at the very
least not ship them in the point release.

+2 on the requirements revert.


I just read this and I agree.

The same thing applies for the cap planned for glance_store, which I
had already -2'd.

Cheers,
Fla

--
@flaper87
Flavio Percoco


pgpXnms9xJcPt.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] [stable] Exception proposals for 2014.2.1

[Flavio Percoco]

On 02/12/14 14:22 +0100, Alan Pevec wrote:

Hi all,

here are exception proposal I have collected when preparing for the
2014.2.1 release,
stable-maint members please have a look!


General: cap Oslo and client library versions - sync from
openstack/requirements stable/juno, would be good to include in the
release.
https://review.openstack.org/#/q/status:open+branch:stable/juno+topic:openstack/requirements,n,z


+2

[snip]


Cinder
https://review.openstack.org/137537 - small change and limited to the
VMWare driver

+2


Glance
https://review.openstack.org/137704 - glance_store is backward
compatible, but not sure about forcing version bump on stable
https://review.openstack.org/137862 - Disable osprofiler by default to
prevent upgrade issues, disabled by default in other services


+2 to both

[snip]

Cheers,
Flavio

--
@flaper87
Flavio Percoco


pgprfgIIZkiMY.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] [neutron] force_gateway_on_subnet, please don't deprecate

[Miguel Ángel Ajo]

I will spend some time on it during tonight/weekend to make sure
it’s removed and that we have reference implementation working at once.

I propose following the bug fix way, as it’s a tiny change.

https://bugs.launchpad.net/neutron/+bug/1398768

@amuller, I’m not sure I understand why does it need to be covered in the 
dhcp-agent side. Pushing extra routes to guest-vms?, I think we don’t cover the 
case of instances connected to an external network where we provide dhcp, but 
we may do that if we are or if we start covering that case anytime.


Miguel Ángel Ajo


On Tuesday, 2 de December de 2014 at 15:48, Ihar Hrachyshka wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>  
> On 01/12/14 21:19, Kyle Mestery wrote:
> > On Mon, Dec 1, 2014 at 6:12 AM, Assaf Muller  > (mailto:amul...@redhat.com)>
> > wrote:
> > >  
> > >  
> > > - Original Message -
> > > >  
> > > > My proposal here, is, _let’s not deprecate this setting_, as
> > > > it’s a valid use case of a gateway configuration, and let’s
> > > > provide it on the reference implementation.
> > > >  
> > >  
> > >  
> > > I agree. As long as the reference implementation works with the
> > > setting off there's no need to deprecate it. I still think the
> > > default should be set to True though.
> > >  
> > > Keep in mind that the DHCP agent will need changes as well.
> > ++ to both suggestions Assaf. Thanks for bringing this up Miguel!
> >  
>  
>  
> Miguel, how about sending a patch that removes deprecation warning
> from the help text then?
>  
> >  
> > Kyle
> >  
> > > >  
> > > > TL;DR
> > > >  
> > > > I’ve been looking at this yesterday, during a test deployment  
> > > > on a site where they provide external connectivity with the  
> > > > gateway outside subnet.
> > > >  
> > > > And I needed to switch it of, to actually be able to have any
> > > > external connectivity.
> > > >  
> > > > https://github.com/openstack/neutron/blob/master/etc/neutron.conf#L121
> This is handled by providing an on-link route to the gateway first,
> > > > and then adding the default gateway.
> > > >  
> > > > It looks to me very interesting (not only because it’s the only
> > > > way to work on that specific site [2][3][4]), because you can
> > > > dynamically wire RIPE blocks to your server, without needing to
> > > > use an specific IP for external routing or broadcast purposes,
> > > > and instead use the full block in openstack.
> > > >  
> > > >  
> > > > I have a tiny patch to support this on the neutron l3-agent [1]
> > > > I yet need to add the logic to check “gateway outside subnet”,
> > > > then add the “onlink” route.
> > > >  
> > > >  
> > > > [1]
> > > >  
> > > > diff --git a/neutron/agent/linux/interface.py  
> > > > b/neutron/agent/linux/interface.py index 538527b..5a9f186
> > > > 100644 --- a/neutron/agent/linux/interface.py +++
> > > > b/neutron/agent/linux/interface.py @@ -116,15 +116,16 @@ class
> > > > LinuxInterfaceDriver(object): namespace=namespace, ip=ip_cidr)
> > > >  
> > > > - if gateway: - device.route.add_gateway(gateway) -  
> > > > new_onlink_routes = set(s['cidr'] for s in extra_subnets) + if
> > > > gateway: + new_onlink_routes.update([gateway])  
> > > > existing_onlink_routes =
> > > > set(device.route.list_onlink_routes()) for route in
> > > > new_onlink_routes - existing_onlink_routes:  
> > > > device.route.add_onlink_route(route) for route in
> > > > existing_onlink_routes - new_onlink_routes:  
> > > > device.route.delete_onlink_route(route) + if gateway: +
> > > > device.route.add_gateway(gateway)
> > > >  
> > > > def delete_conntrack_state(self, root_helper, namespace, ip):  
> > > > """Delete conntrack state associated with an IP address.
> > > >  
> > > > [2] http://www.soyoustart.com/ [3] http://www.ovh.co.uk/ [4]
> > > > http://www.kimsufi.com/
> > > >  
> > > >  
> > > > Miguel Ángel Ajo
> > > >  
> > > >  
> > > >  
> > > >  
> > > > ___ OpenStack-dev
> > > > mailing list OpenStack-dev@lists.openstack.org 
> > > > (mailto:OpenStack-dev@lists.openstack.org)  
> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > > >  
> > >  
> > >  
> > >  
> ___
> > > OpenStack-dev mailing list OpenStack-dev@lists.openstack.org 
> > > (mailto:OpenStack-dev@lists.openstack.org)  
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >  
> >  
> >  
> > ___ OpenStack-dev
> > mailing list OpenStack-dev@lists.openstack.org 
> > (mailto:OpenStack-dev@lists.openstack.org)  
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >  
>  
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
>  
> iQEcBAEBCgAGBQJUfdEsAAoJEC5aWaUY1u57a4QIANjx/wOJJKlHJ1kiE5DQ80La
> WP5DYwWj64MA+pDXPoE18+JZEV+7igHD7zeKb8pua4Ql+X/EDbLG5GK1ry4EV5RC
> uKnO2tht/bLfrniirqoOcL5TqybW86ZP4TLtTzV1PdAQBNGoOaRU8pox5oAkZOmm
> FrFVtBqoMtUAM

Re: [openstack-dev] [diskimage-builder] Tracing levels for scripts (119023)

[Chris Jones]

Hi

I am very sympathetic to this view. We have a patch in hand that improves the 
situation. We also have disagreement about the ideal situation.

I +2'd Ian's patch because it makes things work better than they do now. If we 
can arrive at an ideal solution later, great, but the more I think about 
logging from a multitude of bash scripts, and tricks like XTRACE_FD, the more I 
think it's crazy and we should just incrementally improve the non-trace logging 
as a separate exercise, leaving working tracing for true debugging situations.

Cheers,
--
Chris Jones

> On 3 Dec 2014, at 05:00, Ian Wienand  wrote:
> 
>> On 12/03/2014 09:30 AM, Clint Byrum wrote:
>> I for one find the idea of printing every cp, cat, echo and ls command out
>> rather frustratingly verbose when scanning logs from a normal run.
> 
> I for one find this ongoing discussion over a flag whose own help says
> "-x -- turn on tracing" not doing the blindly obvious thing of turning
> on tracing and the seeming inability to reach to a conclusion on a
> posted review over 3 months a troubling narrative for potential
> consumers of diskimage-builder.
> 
> -i
> 
> ___
> 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] Changes to the core team

[Mathieu Rohon]

Hi all,

It seems that a process with a survey for neutron core
election/removal was about to take place [1]. Has it been applied for
this proposal?
This proposal has been hardly discussed during neutron meetings
[2][3]. Many cores agree that the number of reviews shouldn't be the
only metrics. And this statement is reflected in the Survey Questions.
So I'm surprised to see such a proposal based on stackalitics figures.

[1]https://etherpad.openstack.org/p/neutron-peer-review
[2]http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-10-13-21.02.log.html
[3]http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-10-21-14.00.log.html

On Wed, Dec 3, 2014 at 9:44 AM, Oleg Bondarev  wrote:
> +1! Congrats, Henry and Kevin!
>
> On Tue, Dec 2, 2014 at 6:59 PM, Kyle Mestery  wrote:
>>
>> Now that we're in the thick of working hard on Kilo deliverables, I'd
>> like to make some changes to the neutron core team. Reviews are the
>> most important part of being a core reviewer, so we need to ensure
>> cores are doing reviews. The stats for the 180 day period [1] indicate
>> some changes are needed for cores who are no longer reviewing.
>>
>> First of all, I'm proposing we remove Bob Kukura and Nachi Ueno from
>> neutron-core. Bob and Nachi have been core members for a while now.
>> They have contributed to Neutron over the years in reviews, code and
>> leading sub-teams. I'd like to thank them for all that they have done
>> over the years. I'd also like to propose that should they start
>> reviewing more going forward the core team looks to fast track them
>> back into neutron-core. But for now, their review stats place them
>> below the rest of the team for 180 days.
>>
>> As part of the changes, I'd also like to propose two new members to
>> neutron-core: Henry Gessau and Kevin Benton. Both Henry and Kevin have
>> been very active in reviews, meetings, and code for a while now. Henry
>> lead the DB team which fixed Neutron DB migrations during Juno. Kevin
>> has been actively working across all of Neutron, he's done some great
>> work on security fixes and stability fixes in particular. Their
>> comments in reviews are insightful and they have helped to onboard new
>> reviewers and taken the time to work with people on their patches.
>>
>> Existing neutron cores, please vote +1/-1 for the addition of Henry
>> and Kevin to the core team.
>>
>> Thanks!
>> Kyle
>>
>> [1] http://stackalytics.com/report/contribution/neutron-group/180
>>
>> ___
>> 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][Nailgun] Web framework

[Ivan Kliuk]

Well, I think if the general direction is to make Fuel using OpenStack 
tools and libraries as much as it's possible, that makes sense to use 
Pecan. Otherwise I'd prefer to swap web.py with Flask.


Sincerely yours,
Ivan Kliuk

On 12/2/14 16:55, Igor Kalnitsky wrote:

Hi, Sebastian,

Thank you for raising this topic again.

Yes, indeed, we need to move out from web.py as soon as possible and
there are a lot of reasons why we should do it. But this topic is not
about "Why", this topic is about "Flask or Pecan".

Well, currently Fuel uses both of this frameworks:

* OSTF is using Pecan
* Fuel Stats is using Flask

Personally, I'd like to use Flask instead of Pecan, because first one
is more production-ready tool and I like its design. But I believe
this should be resolved by voting.

Thanks,
Igor

On Tue, Dec 2, 2014 at 4:19 PM, Sebastian Kalinowski
 wrote:

Hi all,

Some time ago we had a discussion about moving Nailgun to new web framework
[1].

There was comparison [2] of two possible options: Pecan [3] and Flask [4].
We came to conclusion that we need to move Nailgun on some alive web
framework
instead of web.py [5] (some of the reasons: [6]) but there was no clear
agreement
on what framework (there were strong voices for Flask).

I would like to bring this topic up again so we could discuss with broader
audience and
make final decision what will be our next web framework.

I think that we should also consider to make that framework our "weapon of
choice" (or so
called standard) when creating new web services in Fuel.

Best,
Sebastian


[1] https://lists.launchpad.net/fuel-dev/msg01397.html
[2]
https://docs.google.com/a/mirantis.com/document/d/1QR7YphyfN64m-e9b5rKC_U8bMtx4zjfW943BfLTqTao/edit?usp=sharing
[3] http://www.pecanpy.org/
[4] http://flask.pocoo.org/
[5] http://webpy.org/
[6] https://lists.launchpad.net/fuel-dev/msg01501.html

___
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] Can the Kilo nova controller conduct the Juno compute nodes

[Joe Gordon]

On Wed, Dec 3, 2014 at 11:53 AM, Li Junhong  wrote:

> Hi Joe,
>
> Just want to confirm one more question, in the gate testing, is the
> neutron/cinder/glance Kilo or Juno. Or in another word, is the controller
> in gate testing an all-in-one controller?
>

Great question. In our current test neutron/cinder/glance are Kilo. But we
do want to support the case where neutron/cinder/glance are Juno, as you
should be able to upgrade each service independently. While we don't test
it, we design around that goal, so with some testing and bug fixing it
should work.


>
> On Wed, Dec 3, 2014 at 5:49 PM, Li Junhong  wrote:
>
>> Hi Joe,
>>
>> Thank you for your confirmative answer and the wonderful gate testing
>> pipeline.
>>
>> On Wed, Dec 3, 2014 at 5:38 PM, Joe Gordon  wrote:
>>
>>>
>>>
>>> On Wed, Dec 3, 2014 at 11:09 AM, Li Junhong  wrote:
>>>
 Hi All,

 Is it possible for Kilo nova controller to control the Juno compute
 nodes? Is this scenario supported naturally by the nova mechanism in the
 design and codes level?

>>>
>>> Yes,
>>>
>>> We gate on making sure we can run Kilo nova with Juno compute nodes.
>>>
>>>


 --
 Best Regards!
 
 Junhong, Li

 ___
 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
>>>
>>>
>>
>>
>> --
>> Best Regards!
>> 
>> Junhong, Li
>>
>
>
>
> --
> Best Regards!
> 
> Junhong, Li
>
> ___
> 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] Changes to the core team

[Miguel Ángel Ajo]

Congratulations to Henry and Kevin, very well deserved!,
keep up the good work! :)


Miguel Ángel Ajo


On Wednesday, 3 de December de 2014 at 09:44, Oleg Bondarev wrote:

> +1! Congrats, Henry and Kevin!
>  
> On Tue, Dec 2, 2014 at 6:59 PM, Kyle Mestery  (mailto:mest...@mestery.com)> wrote:
> > Now that we're in the thick of working hard on Kilo deliverables, I'd
> > like to make some changes to the neutron core team. Reviews are the
> > most important part of being a core reviewer, so we need to ensure
> > cores are doing reviews. The stats for the 180 day period [1] indicate
> > some changes are needed for cores who are no longer reviewing.
> >  
> > First of all, I'm proposing we remove Bob Kukura and Nachi Ueno from
> > neutron-core. Bob and Nachi have been core members for a while now.
> > They have contributed to Neutron over the years in reviews, code and
> > leading sub-teams. I'd like to thank them for all that they have done
> > over the years. I'd also like to propose that should they start
> > reviewing more going forward the core team looks to fast track them
> > back into neutron-core. But for now, their review stats place them
> > below the rest of the team for 180 days.
> >  
> > As part of the changes, I'd also like to propose two new members to
> > neutron-core: Henry Gessau and Kevin Benton. Both Henry and Kevin have
> > been very active in reviews, meetings, and code for a while now. Henry
> > lead the DB team which fixed Neutron DB migrations during Juno. Kevin
> > has been actively working across all of Neutron, he's done some great
> > work on security fixes and stability fixes in particular. Their
> > comments in reviews are insightful and they have helped to onboard new
> > reviewers and taken the time to work with people on their patches.
> >  
> > Existing neutron cores, please vote +1/-1 for the addition of Henry
> > and Kevin to the core team.
> >  
> > Thanks!
> > Kyle
> >  
> > [1] http://stackalytics.com/report/contribution/neutron-group/180
> >  
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org)
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>  
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org)
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>  
>  


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

Re: [openstack-dev] [nova] [libvirt] enabling per node filtering of mempage sizes

[Daniel P. Berrange]

On Wed, Dec 03, 2014 at 10:03:06AM +0100, Sahid Orentino Ferdjaoui wrote:
> On Tue, Dec 02, 2014 at 07:44:23PM +, Mooney, Sean K wrote:
> > Hi all
> > 
> > I have submitted a small blueprint to allow filtering of available memory 
> > pages 
> > Reported by libvirt.
> 
> Can you address this with aggregate? this will also avoid to do
> something specific in the driver libvirt. Which will have to be
> extended to other drivers at the end.

Agreed, I think you can address this by setting up host aggregates
and then using setting the desired page size on the flavour.

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

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

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

[Steven Hardy]

Hi all,

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

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

This raises the following questions:

1. Is it reasonable to -1 a patch and ask folks to update in both places?
2. How are we going to handle this duplication and divergence?
3. What's the status of getting gating CI on the --no-mergepy templates?
4. What barriers exist (now that I've implemented[2] the eliding functionality
requested[3] for ResourceGroup) to moving to the --no-mergepy
implementation by default?

Thanks for any clarification you can provide! :)

Steve

[1] https://review.openstack.org/#/c/123100/
[2] https://review.openstack.org/#/c/128365/
[3] https://review.openstack.org/#/c/123713/

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

Re: [openstack-dev] [neutron] Private external network

[Kevin Benton]

There is a current blueprint under discussion[1] which would have covered
the external network access control as well, however it looks like the
scope is going to have to be reduced for this cycle so it will be limited
to shared networks if it's accepted at all.

1. https://review.openstack.org/#/c/132661/

On Wed, Dec 3, 2014 at 1:59 AM, Andrew Ruthven  wrote:

> Hi,
>
> I'm picking up this thread from a few months ago, as I have a
> requirement for a private external network and after doing some testing
> today came to the conclusion that this isn't currently possible. Rats.
>
> On Tue, 2014-10-14 at 17:42 +, A, Keshava wrote:
> > Hi,
> >
> > Across these private External network/tenant :: floating IP can be
> > shared ?
>
> I would think not. The external network and associated floating IPs
> should only be accessible by the tenant (or tenants?) which are granted
> to use it.
>
> At a guess that tenants thought above is where the RBAC considerations
> come in.
>
> Does anyone have any pointers to the previous discussions on this? The
> BP [0] which Édouard linked to states it was untargetted due to
> community discussions but has no links or other references to those
> discussions.
>
> Cheers,
> Andrew
>
> [0]
>
> https://blueprints.launchpad.net/neutron/+spec/sharing-model-for-external-networks
>
>
> --
> Andrew Ruthven, Wellington, New Zealand
> and...@etc.gen.nz | linux.conf.au 2015
>   New Zealand's only Cloud:   |  BeAwesome in Auckland, NZ
> https://catalyst.net.nz/cloud | http://lca2015.linux.org.au
>
>
>
> ___
> 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] [stable] Exception proposals for 2014.2.1

[Thierry Carrez]

Doug Hellmann wrote:
> 
> On Dec 2, 2014, at 5:41 PM, Alan Pevec  wrote:
> 
 General: cap Oslo and client library versions - sync from
 openstack/requirements stable/juno, would be good to include in
 the release.
 https://review.openstack.org/#/q/status:open+branch:stable/juno+topic:openstack/requirements,n,z
>>>
>>> +2,

>>> let's keep all deps in sync. Those updates do not break anything
>>> for existing users.
>>
>> Just spotted it, there is now proposal to revert caps in Juno:
>>
>> https://review.openstack.org/138546
>>
>> Doug, shall we stop merging caps to projects in Juno?
> 
> Today we found that when we have caps in place that do not overlap with the 
> versions used in master, we can’t upgrade services one at a time on a host 
> running multiple services. We didn’t have this problem between icehouse and 
> juno because I used the same cap values for both releases, so we didn’t 
> trigger any problems with grenade.
> 
> One solution is to undo the caps and then add caps when we discover issues in 
> new versions of libraries and stable branches. Another is to require 
> applications to work with “old” versions of libraries and degrade their 
> feature set, so that we can keep the lower bounds overlapping.
> 
> In retrospect, this issue with caps was obvious, but I don’t remember it 
> being raise in the planning. As Sean pointed out on IRC today, we should have 
> someone write a spec for changing the way we deal with requirements so we can 
> think about it before deciding what to do.
> 
> After the releases today, the “no more alpha versions for Oslo” ship has 
> sailed. Removing the caps will at least let us move ahead while we figure out 
> what to do for stable branches.

Yes, looks like we need to think a bit deeper about it, and at the very
least not ship them in the point release.

+2 on the requirements revert.

-- 
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] [neutron] Private external network

[Andrew Ruthven]

Hi,

I'm picking up this thread from a few months ago, as I have a
requirement for a private external network and after doing some testing
today came to the conclusion that this isn't currently possible. Rats.

On Tue, 2014-10-14 at 17:42 +, A, Keshava wrote:
> Hi,
> 
> Across these private External network/tenant :: floating IP can be
> shared ? 

I would think not. The external network and associated floating IPs
should only be accessible by the tenant (or tenants?) which are granted
to use it.

At a guess that tenants thought above is where the RBAC considerations
come in.

Does anyone have any pointers to the previous discussions on this? The
BP [0] which Édouard linked to states it was untargetted due to
community discussions but has no links or other references to those
discussions. 

Cheers,
Andrew

[0]
https://blueprints.launchpad.net/neutron/+spec/sharing-model-for-external-networks


-- 
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz | linux.conf.au 2015 
  New Zealand's only Cloud:   |  BeAwesome in Auckland, NZ
https://catalyst.net.nz/cloud | http://lca2015.linux.org.au



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