Re: [openstack-dev] [stable-maint] acceptable changes for stable/icehouse

2015-01-06 Thread Thierry Carrez
John Griffith wrote:
 On Mon, Jan 5, 2015 at 4:39 PM, Jay S. Bryant
 jsbry...@electronicjungle.net wrote:
 All,

 We have been getting a number of non-security patches proposed to
 stable/icehouse for Cinder.  The cores were discussing what was ok to put
 into icehouse at this point in time and couldn't agree as to whether we were
 at the point of only accepting security changes.

 Appreciate advice on this topic.

 
 Hey Jay,
 
 Thanks for raising this, my understanding was that we were in fact
 security only mode now for Icehouse.  That being said I completely
 forgot that it's been that long already and I let some reviews slip
 myself just today in fact.  Thanks for pointing it out.

Icehouse is now 9-month old, so it is in phase II support (only
critical bugfixes and security patches are acceptable).

Reference: https://wiki.openstack.org/wiki/StableBranch#Support_phases

In case of doubt, you can ask stable-maint-core people for advice:
https://review.openstack.org/#/admin/groups/530,members

-- 
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][vpnaas] VPNaaS Subteam meeting Tuesday 1500 UTC meeting-4

2015-01-06 Thread Mathieu Rohon
Thanks Paul,

I'll be there!

Mathieu

On Mon, Jan 5, 2015 at 8:43 PM, Paul Michali (pcm) p...@cisco.com wrote:
 Since we took a break for two weeks and the meeting channel has changed, I
 figured I send a reminder.

 Please update the page for any agenda items you may have,

 Regards,


 PCM (Paul Michali)

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





 ___
 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 switching to the normal .ini format

2015-01-06 Thread Matthias Runge
On 05/01/15 19:27, Matthew Farina wrote:
 Switching to an ini format would likely be painful to impossible.
 
 Horizon is built on django which is where the settings.py format comes
 from. It's part of a django app.
 
 For more info see the django docs. The settings information is at
 https://docs.djangoproject.com/en/1.6/topics/settings/
 

Sorry, I fail to see, how this should be impossible, esp. if you look at
the linked patch; the rest of the stack uses such an .ini format, too.


Matthias
 On Thu, Dec 25, 2014 at 1:25 PM, Timur Sufiev tsuf...@mirantis.com
 mailto:tsuf...@mirantis.com wrote:
 
 Thomas,
 
 I could only point you to the Radomir's
 patch https://review.openstack.org/#/c/100521/
 
 It's still a work in progress, so you may ask him for more details.
 


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


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

2015-01-06 Thread Radomir Dopieralski
On 06/01/15 01:39, Tripp, Travis S wrote:
 What Radomir proposes looks like it would greatly ease the process I am still 
 going through to get the latest angular available to Horizon for current 
 development.  At the time of writing this, I’m still trying to get the 
 updated library through.  I hit a rather difficult workflow:
 
 
   1.  Packaged the latest into Xstatic-Angular-1.3.7
   2.  Submitted patch which deprecated the separate older 
 xstatic-angular-cookies and xstatic-angular-mock packages
   3.  Reviewed and approved (after correcting an initial mis-repackaging)
   4.  Radomir released to Pypi
 
 This was pretty easy and not too hard. Not too much to complain about.
 
 However, now, to get Horizon to use it, I have to get that into global 
 requirements.  Since I’m deprecating old packages I got stuck in a sort of 
 ugly dependency path.  I couldn’t remove the cookies and mock libraries from 
 the global requirements patch that added the new 1.3.7 package because of 
 horizon still referencing the deprecated packages.  And, when I did it 
 anyway, the integration tests failed due to horizon being dependent on 
 something not in global requirements.  So, now, as far as I can tell we have 
 to jump through the following hoops:
 
 
   1.  Global requirements patch to add angular 1.3.7
  *   Verify check / recheck fun
  *   Reviewed and approved
  *   Gate check / recheck fun
   2.  Horizon patch to update to angular 1.3.7 and remove deprecated mock and 
 cookies packages
  *   Verify check / recheck fun
  *   Reviewed and approved
  *   Gate check / recheck fun
   3.  Global requirements patch to remove deprecated mock and cookies
  *   Verify check / recheck fun
  *   Reviewed and approved
  *   Gate check / recheck fun
 
 Don’t get me wrong, I really do think the gate is brilliant and am all for a 
 review / approval process, but this does seem excessive for a UI library that 
 should only be used by Horizon. Is there some other reason that this should 
 have to go through global requirements?

You can do it much easier, since the current version of Angular already
packages what is in the deprecated modules. So just:

1. Patch Horizon to remove the xstatic dependencies to the mock and
cookies packages.
2. Patch global-requirements to remove them, and add newer Angular.
3. Patch Horizon to use the newer Angular.

-- 
Radomir Dopieralski

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


[openstack-dev] [nova]nova not work with eventlet 0.16.0

2015-01-06 Thread Eli Qiao

hi all ,
I set up nova environment with latest upstream code.
nova-compute can not boot up due to failed to load libvirt driver.
by further debugging. found that eventlet (0.16.0) remove util which is 
referenced by libvirt driver.

after I downgrade to (0.15.2) it works.

*0.15.2*

In [3]: print eventlet.__version__
0.15.2

In [5]: import eventlet.util

In [6]:

-
*0.16.0**
*

In [1]: import eventlet.util
---
ImportError   Traceback (most recent call last)
ipython-input-1-a23626d6f273 in module()
 1 import eventlet.util

ImportError: No module named util

In [3]: import eventlet

In [4]: print eventlet.__version__
0.16.0

In [5]:




In [1]: import nova.virt.libvirt.LibvirtDriver
---
ImportError   Traceback (most recent call last)
ipython-input-1-2bdce28fc3dd in module()
 1 import nova.virt.libvirt.LibvirtDriver

/opt/stack/nova/nova/virt/libvirt/__init__.py in module()
 13 #under the License.
 14
--- 15 from nova.virt.libvirt import driver
 16
 17 LibvirtDriver = driver.LibvirtDriver

/opt/stack/nova/nova/virt/libvirt/driver.py in module()
 96 from nova.virt.libvirt import dmcrypt
 97 from nova.virt.libvirt import firewall as libvirt_firewall
--- 98 from nova.virt.libvirt import host
 99 from nova.virt.libvirt import imagebackend
100 from nova.virt.libvirt import imagecache

/opt/stack/nova/nova/virt/libvirt/host.py in module()
 37 from eventlet import patcher
 38 from eventlet import tpool
--- 39 from eventlet import util as eventlet_util
 40
 41 from nova import exception

ImportError: cannot import name util

In [2]: import eventlet

In [3]: from eventlet import util
---
ImportError   Traceback (most recent call last)
ipython-input-3-f6f91e4749eb in module()
 1 from eventlet import util

ImportError: cannot import name util

In [4]:

--
Thanks,
Eli (Li Yong) Qiao

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


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

2015-01-06 Thread Flavio Percoco

On 05/01/15 08:57 -0800, Morgan Fainberg wrote:




On Jan 5, 2015, at 08:07, Nikhil Komawar nikhil.koma...@rackspace.com wrote:

Based on the feedback received, we would like to avoid logging on the project 
channel. My take from the discussion was that it gives many a folks a feeling 
of informal platform to express their ideas freely in contrast to the meeting 
channels.

However, at the same time I would like to point out that using foul language in the open 
freenode channels is a bad practice. There are no admins monitoring our project channels 
however, those channels that are monitored have people kicked out on misbehavior.  The 
point being, no logging means freedom of thought for only the creative 
purposes; please do not take me any other way.

Thanks,
-Nikhil



I just want to point out that keystone has logging enabled for our channel and 
I do not see it as a hamper to creative discussion / open discussion. The 
logging is definitely of value. Also a lot of people will locally log a given 
irc channel, which largely nets the same result.

It is still not an official meeting, and we have heated debates at times, the 
logging let's us check back on things discussed outside of the official 
meetings. I do admit it is used less frequently than the meeting logs.


Fully agree... I don't see how enable logging should be a limitation
for freedom of thought. We've used it in Zaqar since day 0 and it's
bee of great help for all of us.

The logging does not remove the need of meetings where decisions and
more relevant/important topics are discussed.



From: Anita Kuno [ante...@anteaya.info]
Sent: Monday, January 05, 2015 10:42 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Glance] IRC logging


On 01/05/2015 06:42 AM, Cindy Pallares wrote:
Hi all,

I would like to re-open the discussion on IRC logging for the glance
channel. It was discussed on a meeting back in November[1], but it
didn't seem to have a lot of input from the community and it was not
discussed in the mailing list. A lot of information is exchanged through
the channel and it isn't accessible for people who occasionally come
into our channel from other projects, new contributors, and people who
don't want to be reached off-hours or don't have bouncers. Logging our
channel would  increase our community's transparency and make our
development discussions publicly accessible to contributors in all
time-zones and from other projects. It is very useful to look back on
the logs for previous discussions or as well as to refer people to
discussions or questions previously answered.


+2

Thanks for bringing this up :)

Flavio

--
@flaper87
Flavio Percoco


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


[openstack-dev] [Devstack][Neutron]Neutron with External DHCP server

2015-01-06 Thread foss geek
Dear All,

Is it possible to configure neutron to take VM ip from external DHCP server?

I am having All In One openstack env deployed using devstack icehouse. I am
looking for an option to integrate it with external DHCP server.

-- 
Thanks  Regards
E-Mail: thefossg...@gmail.com
IRC: neophy
Blog : http://lmohanphy.livejournal.com/
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] Cross-Project meeting, Tue January 6th, 21:00 UTC

2015-01-06 Thread Thierry Carrez
Dear PTLs, cross-project liaisons and anyone else interested,

We'll have a cross-project meeting today at 21:00 UTC, with the
following agenda:

* State of nova-network to neutron migration
* Discuss openstack-spec: log guidelines [1]
* Discuss openstack-spec: OSProfiler [2]
* Open discussion  announcements

[1] https://review.openstack.org/#/c/132552/
[2] https://review.openstack.org/#/c/134839/

See you there !

For more details on this meeting, please see:
https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting

-- 
Thierry Carrez (ttx)

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


[openstack-dev] [nova] microversion and backward incompatible changes on v2.1

2015-01-06 Thread Chen CH Ji

Hi
https://review.openstack.org/#/c/144995/ introduced a
backward incompatible change with mirco version support
and I think it's the microversion's purpose to enable v2.1
(v3) API to make those changes

The question is whether we should make bp for each change
for the API change? should we make a simple bp or go through the nova-spec
process? Thanks a lot

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [nova] Questions on pep8 F811 hacking check for microversion

2015-01-06 Thread Chen CH Ji

Based on nova-specs api-microversions.rst
we support following function definition format, but it violate the hacking
rule pep8 F811 because duplicate function definition
we should use #noqa for them , but considering microversion may live for
long time ,
keep adding #noqa may be a little bit ugly, can anyone suggest a good
solution for it ? thanks

   @api_version(min_version='2.1')
   def _version_specific_func(self, req, arg1):
  pass

   @api_version(min_version='2.5')
   def _version_specific_func(self, req, arg1):
  pass



Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0

2015-01-06 Thread Jay Pipes

Thanks Eli, please do file a bug on Launchpad with your information below.

Best,
-jay

On 01/06/2015 04:18 AM, Eli Qiao wrote:

hi all ,
I set up nova environment with latest upstream code.
nova-compute can not boot up due to failed to load libvirt driver.
by further debugging. found that eventlet (0.16.0) remove util which is
referenced by libvirt driver.
after I downgrade to (0.15.2) it works.

*0.15.2*

In [3]: print eventlet.__version__
0.15.2

In [5]: import eventlet.util

In [6]:

-
*0.16.0**
*

In [1]: import eventlet.util
---
ImportError   Traceback (most recent call last)
ipython-input-1-a23626d6f273 in module()
 1 import eventlet.util

ImportError: No module named util

In [3]: import eventlet

In [4]: print eventlet.__version__
0.16.0

In [5]:




In [1]: import nova.virt.libvirt.LibvirtDriver
---
ImportError   Traceback (most recent call last)
ipython-input-1-2bdce28fc3dd in module()
 1 import nova.virt.libvirt.LibvirtDriver

/opt/stack/nova/nova/virt/libvirt/__init__.py in module()
  13 #under the License.
  14
--- 15 from nova.virt.libvirt import driver
  16
  17 LibvirtDriver = driver.LibvirtDriver

/opt/stack/nova/nova/virt/libvirt/driver.py in module()
  96 from nova.virt.libvirt import dmcrypt
  97 from nova.virt.libvirt import firewall as libvirt_firewall
--- 98 from nova.virt.libvirt import host
  99 from nova.virt.libvirt import imagebackend
 100 from nova.virt.libvirt import imagecache

/opt/stack/nova/nova/virt/libvirt/host.py in module()
  37 from eventlet import patcher
  38 from eventlet import tpool
--- 39 from eventlet import util as eventlet_util
  40
  41 from nova import exception

ImportError: cannot import name util

In [2]: import eventlet

In [3]: from eventlet import util
---
ImportError   Traceback (most recent call last)
ipython-input-3-f6f91e4749eb in module()
 1 from eventlet import util

ImportError: cannot import name util

In [4]:

--
Thanks,
Eli (Li Yong) Qiao



___
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] Support for Amazon VPC APIs in OpenStack

2015-01-06 Thread Jay Pipes

On 01/06/2015 12:44 AM, Saju M wrote:

Hi,

I seen a blueprint which implement Amazon VPC APIs and Status is Abandoned
https://review.openstack.org/#/c/40071/

Have any plans to get it done in Kilo release ?
How can I change the Abandoned status ?.
Have any dependencies ?

Please let me know, So I can rebase it.


Hi Saju,

We'd need to see a nova-specs submission for this work, first. You could 
take much of the content from 
https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support for the 
content of the nova-spec submission, though you will want to change 
references to Quantum to Neutron :)


The nova-specs submission is covered here:

https://wiki.openstack.org/wiki/Blueprints#Nova

Note that due to it being late in the cycle, it will be unlikely to get 
a newly-submitted spec approved, but that does not mean you cannot work 
on code that implements the spec.


Best,
-jay

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


Re: [openstack-dev] [heat][oslo] heat unit tests mocking private parts of oslo.messaging

2015-01-06 Thread Jay Pipes

On 01/05/2015 06:03 PM, Doug Hellmann wrote:

As part of updating oslo.messaging to move it out of the oslo
namespace package I ran into some issues with heat. While debugging,
I tried running the heat unit tests using the modified version of
oslo.messaging and ran into test failures because the tests are
mocking private parts of the library that are moving to have new
names.


It's just never polite to mock someone's private parts.

Best,
-jay

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


Re: [openstack-dev] Problem installing devstack

2015-01-06 Thread Rajdeep Dua
Thanks for the responses RECLONE=yes worked for me.

On Tue, Jan 6, 2015 at 11:14 AM, Dr. Jens Rosenboom j.rosenb...@x-ion.de
wrote:

 Am 06/01/15 um 04:40 schrieb Rajdeep Dua:

  Getting this error while running stack.sh in devstack

 Could not find a version that satisfies the requirement
 SQLAlchemy=0.8.99,=0.9.99,=0.8.4,=0.9.7 (from
 keystone==2014.2.dev114)
 (from versions: 0.4.2p3, 0.4.7p1, 0.5.4p1, 0.5.4p2, 0.1.0, 0.1.1, 0.1.2,
 0.1.3, 0.1.4, 0.1.5, 0.1.6, 0.1.7, 0.2.0, 0.2.1, 0.2.2, 0.2.3, 0.2.4,
 0.2.5, 0.2.6, 0.2.7, 0.2.8, 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.3.5,
 0.3.6, 0.3.7, 0.3.8, 0.3.9, 0.3.10, 0.3.11, 0.4.0b1, 0.4.0b2, 0.4.0b3,
 0.4.0b4, 0.4.0b5, 0.4.0b6, 0.4.0, 0.4.1, 0.4.2a0, 0.4.2b0, 0.4.2, 0.4.3,
 0.4.4, 0.4.5, 0.4.6, 0.4.7, 0.4.8, 0.5.0b1, 0.5.0b2, 0.5.0b3, 0.5.0rc1,
 0.5.0rc2, 0.5.0rc3, 0.5.0rc4, 0.5.0, 0.5.1, 0.5.2, 0.5.3, 0.5.4, 0.5.5,
 0.5.6, 0.5.7, 0.5.8, 0.6b1, 0.6b2, 0.6b3, 0.6.0, 0.6.1, 0.6.2, 0.6.3,
 0.6.4, 0.6.5, 0.6.6, 0.6.7, 0.6.8, 0.6.9, 0.7.0, 0.7.1, 0.7.2, 0.7.3,
 0.7.4, 0.7.5, 0.7.6, 0.7.7, 0.7.8, 0.7.9, 0.7.10, 0.8.0b2, 0.8.0, 0.8.1,
 0.8.2, 0.8.3, 0.8.4, 0.8.5, 0.8.6, 0.8.7, 0.9.0, 0.9.1, 0.9.2, 0.9.3,
 0.9.4, 0.9.5, 0.9.6, 0.9.7, 0.9.8)
No distributions matching the version for
 SQLAlchemy=0.8.99,=0.9.99,=0.8.4,=0.9.7 (from
 keystone==2014.2.dev114)

 I saw a couple of bugs filed and patches going in.

 Please clarify if this is fixed and how to get the latest changes in.


 I would assume that you are trying to reuse an older devstack
 installation, as this bug should have been fixed a couple of weeks ago.

 However, running stack.sh by default does not update the source repos once
 they exist, so you can either add RECLONE=yes to your config or go
 manually through the repos in /opt/stack and update 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] [FUEL] Zabbix in HA mode

2015-01-06 Thread Jay Pipes

On 01/05/2015 04:05 PM, Andrew Woodward wrote:

snip  Secondly running monitoring on the cluster may
also result in the monitoring going offline if the cluster does, from
my own experience, not being able to see your monitoring is nearly
worse than having everything down and leads to lost precious moments
of downtime SLA.


Yep, this is exactly my experience as well. Excellent point.

-jay

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


Re: [openstack-dev] [nova] Questions on pep8 F811 hacking check for microversion

2015-01-06 Thread Alex Xu
2015-01-06 20:31 GMT+08:00 Jay Pipes jaypi...@gmail.com:

 On 01/06/2015 06:25 AM, Chen CH Ji wrote:

 Based on nova-specs api-microversions.rst
 we support following function definition format, but it violate the
 hacking rule pep8 F811 because duplicate function definition
 we should use #noqa for them , but considering microversion may live for
 long time ,
 keep adding #noqa may be a little bit ugly, can anyone suggest a good
 solution for it ? thanks

 @api_version(min_version='2.1')
 def _version_specific_func(self, req, arg1):
pass
  
 @api_version(min_version='2.5')
 def _version_specific_func(self, req, arg1):
pass


 Hey Kevin,

 This was actually one of my reservations about the proposed
 microversioning implementation -- i.e. having functions that are named
 exactly the same, only decorated with the microversioning notation. It
 kinda reminds me of the hell of debugging C++ code that uses STL: how does
 one easily know which method one is in when inside a debugger?

 That said, the only other technique we could try to use would be to not
 use a decorator and instead have a top-level dispatch function that would
 inspect the API microversion (only when the API version makes a difference
 to the output or input of that function) and then dispatch the call to a
 helper method that had the version in its name.

 So, for instance, let's say you are calling the controller's GET
 /$tenant/os-hosts method, which happens to get routed to the
 nova.api.openstack.compute.contrib.hosts.HostController.index() method.
 If you wanted to modify the result of that method and the API microversion
 is at 2.5, you might do something like:

  def index(self, req):
  req_api_ver = utils.get_max_requested_api_version(req)
  if req_api_ver == (2, 5):
  return self.index_2_5(req)
  return self.index_2_1(req)

  def index_2_5(self, req):
  results = self.index_2_1(req)
  # Replaces 'host' with 'host_name'
  for result in results:
  result['host_name'] = result['host']
  del result['host']
  return results

  def index_2_1(self, req):
  # Would be a rename of the existing index() method on
  # the controller

 Another option would be to use something like JSON-patch to determine the
 difference between two output schemas and automatically translate one to
 another... but that would be a huge effort.


Just JSON-patch only can resolve multiple-version of request/response, we
need handle semantic change also.

But I still think we need something like JSON-patch, it can avoid add new
method only for small request/response changing, like this patch
https://review.openstack.org/#/c/144995/3

I have propose before, we can try mapping the request/response into nova
object by json-schema automatically, the nova object will handle the
change. When the request/response changed, nothing will change in REST API
code. I wrote the POC before
https://github.com/soulxu/nova-v3-api-doc/commits/micro_ver_with_obj_auto_mapping
This is more easy to maintenance than JSON-patch(thinking about the case of
3.3 patch based on 3.2 patch based on 3.1 patch.)


 That's the only other way I can think of besides disabling F811, which I
 really would not recommend, since it's a valuable safeguard against
 duplicate function names (especially duplicated test methods).

 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] [nova] Questions on pep8 F811 hacking check for microversion

2015-01-06 Thread Jay Pipes

On 01/06/2015 06:25 AM, Chen CH Ji wrote:

Based on nova-specs api-microversions.rst
we support following function definition format, but it violate the
hacking rule pep8 F811 because duplicate function definition
we should use #noqa for them , but considering microversion may live for
long time ,
keep adding #noqa may be a little bit ugly, can anyone suggest a good
solution for it ? thanks

@api_version(min_version='2.1')
def _version_specific_func(self, req, arg1):
   pass
 
@api_version(min_version='2.5')
def _version_specific_func(self, req, arg1):
   pass


Hey Kevin,

This was actually one of my reservations about the proposed 
microversioning implementation -- i.e. having functions that are named 
exactly the same, only decorated with the microversioning notation. It 
kinda reminds me of the hell of debugging C++ code that uses STL: how 
does one easily know which method one is in when inside a debugger?


That said, the only other technique we could try to use would be to not 
use a decorator and instead have a top-level dispatch function that 
would inspect the API microversion (only when the API version makes a 
difference to the output or input of that function) and then dispatch 
the call to a helper method that had the version in its name.


So, for instance, let's say you are calling the controller's GET 
/$tenant/os-hosts method, which happens to get routed to the 
nova.api.openstack.compute.contrib.hosts.HostController.index() method. 
If you wanted to modify the result of that method and the API 
microversion is at 2.5, you might do something like:


 def index(self, req):
 req_api_ver = utils.get_max_requested_api_version(req)
 if req_api_ver == (2, 5):
 return self.index_2_5(req)
 return self.index_2_1(req)

 def index_2_5(self, req):
 results = self.index_2_1(req)
 # Replaces 'host' with 'host_name'
 for result in results:
 result['host_name'] = result['host']
 del result['host']
 return results

 def index_2_1(self, req):
 # Would be a rename of the existing index() method on
 # the controller

Another option would be to use something like JSON-patch to determine 
the difference between two output schemas and automatically translate 
one to another... but that would be a huge effort.


That's the only other way I can think of besides disabling F811, which I 
really would not recommend, since it's a valuable safeguard against 
duplicate function names (especially duplicated test methods).


Best,
-jay

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


Re: [openstack-dev] [nova] Questions on pep8 F811 hacking check for microversion

2015-01-06 Thread Daniel P. Berrange
On Tue, Jan 06, 2015 at 07:31:19AM -0500, Jay Pipes wrote:
 On 01/06/2015 06:25 AM, Chen CH Ji wrote:
 Based on nova-specs api-microversions.rst
 we support following function definition format, but it violate the
 hacking rule pep8 F811 because duplicate function definition
 we should use #noqa for them , but considering microversion may live for
 long time ,
 keep adding #noqa may be a little bit ugly, can anyone suggest a good
 solution for it ? thanks
 
 @api_version(min_version='2.1')
 def _version_specific_func(self, req, arg1):
pass
  
 @api_version(min_version='2.5')
 def _version_specific_func(self, req, arg1):
pass
 
 Hey Kevin,
 
 This was actually one of my reservations about the proposed microversioning
 implementation -- i.e. having functions that are named exactly the same,
 only decorated with the microversioning notation. It kinda reminds me of the
 hell of debugging C++ code that uses STL: how does one easily know which
 method one is in when inside a debugger?
 
 That said, the only other technique we could try to use would be to not use
 a decorator and instead have a top-level dispatch function that would
 inspect the API microversion (only when the API version makes a difference
 to the output or input of that function) and then dispatch the call to a
 helper method that had the version in its name.
 
 So, for instance, let's say you are calling the controller's GET
 /$tenant/os-hosts method, which happens to get routed to the
 nova.api.openstack.compute.contrib.hosts.HostController.index() method. If
 you wanted to modify the result of that method and the API microversion is
 at 2.5, you might do something like:
 
  def index(self, req):
  req_api_ver = utils.get_max_requested_api_version(req)
  if req_api_ver == (2, 5):
  return self.index_2_5(req)
  return self.index_2_1(req)
 
  def index_2_5(self, req):
  results = self.index_2_1(req)
  # Replaces 'host' with 'host_name'
  for result in results:
  result['host_name'] = result['host']
  del result['host']
  return results
 
  def index_2_1(self, req):
  # Would be a rename of the existing index() method on
  # the controller

Yes, I'd much prefer to see us use version numbers in the method names
like this and not have identically named methods. With some cleverness
we could perhaps avoid the need for the repetative 'index' impl and just
auto-detect the versioned method names when needed.

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

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


Re: [openstack-dev] [nova] Questions on pep8 F811 hacking check for microversion

2015-01-06 Thread Sean Dague
On 01/06/2015 06:25 AM, Chen CH Ji wrote:
 Based on nova-specs api-microversions.rst
 we support following function definition format, but it violate the
 hacking rule pep8 F811 because duplicate function definition
 we should use #noqa for them , but considering microversion may live for
 long time ,
 keep adding #noqa may be a little bit ugly, can anyone suggest a good
 solution for it ? thanks
 
   @api_version(min_version='2.1')
   def _version_specific_func(self, req, arg1):
  pass

   @api_version(min_version='2.5')
   def _version_specific_func(self, req, arg1):
  pass

Can you show the patch in question? (this is the only one I see -
https://review.openstack.org/#/c/144995/3/nova/api/openstack/compute/plugins/v3/hosts.py,cm)


We knew this was going to be an evolution. I think it was only ever
envisioned that @api_version would be used at the top level dispatch,
not 5 levels of private methods deep. The patch above does something
extremely unexpected, and not what I wanted to see out of this for sure.

-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] pip 6.0.6 breaking py2* jobs - bug 1407736

2015-01-06 Thread Ihar Hrachyshka


On 01/06/2015 03:09 AM, Matt Riedemann wrote:



On 1/5/2015 2:16 PM, Doug Hellmann wrote:


On Jan 5, 2015, at 12:22 PM, Doug Hellmann d...@doughellmann.com 
wrote:




On Jan 5, 2015, at 12:00 PM, Matt Riedemann 
mrie...@linux.vnet.ibm.com wrote:


There is a deprecation warning in pip 6.0.6 which is making the 
py26 (on stable branches) and py27 jobs hit subunit log sizes of 
over 50 MB which makes the job fail.


A logstash query shows this started happening around 1/3 which is 
when pip 6.0.6 was released. In Nova alone there are nearly 18 
million hits of the deprecation warning.


Should we temporarily block so that pip  6.0.6?

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


I think this is actually a change in pkg_resources (in the 
setuptools dist) [1], being triggered by stevedore using 
require=False to avoid checking dependencies when plugins are loaded.


Doug

[1] 
https://bitbucket.org/pypa/setuptools/commits/b1c7a311fb8e167d026126f557f849450b859502


After some discussion with Jason Coombs and dstufft, a version of 
setuptools with a split API to replace the deprecated option was 
released. I have a patch up to teach stevedore about the new methods[1].


Doug

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






--

Thanks,

Matt Riedemann


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



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



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



The stevedore patch was merged. Do we need a release of stevedore and 
a global-requirements update to then get the deprecation warnings 
fixed in nova (on master and stable/juno)?




I guess so. Also, Icehouse is affected too. I've checked Nova 
requirements.txt for Icehouse, and we don't cap steverore version, so a 
new release will be automatically propagated to all new jobs.


/Ihar

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


[openstack-dev] [stable] Stable check of openstack/keystone failed

2015-01-06 Thread Dolph Mathews
Both of these build failures should be fixed by:

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

(Thanks, Alan!)

On Tue, Jan 6, 2015 at 12:28 AM, A mailing list for the OpenStack Stable
Branch test reports. openstack-stable-ma...@lists.openstack.org wrote:

 Build failed.

 - periodic-keystone-docs-icehouse
 http://logs.openstack.org/periodic-stableperiodic-keystone-docs-icehouse/ac7970c/
 : FAILURE in 27s
 - periodic-keystone-python26-icehouse
 http://logs.openstack.org/periodic-stableperiodic-keystone-python26-icehouse/6f7ec11/
 : SUCCESS in 23m 03s
 - periodic-keystone-python27-icehouse
 http://logs.openstack.org/periodic-stableperiodic-keystone-python27-icehouse/527351e/
 : FAILURE in 41s
 - periodic-keystone-docs-juno
 http://logs.openstack.org/periodic-stableperiodic-keystone-docs-juno/6d4d68b/
 : SUCCESS in 5m 59s
 - periodic-keystone-python26-juno
 http://logs.openstack.org/periodic-stableperiodic-keystone-python26-juno/7517d87/
 : SUCCESS in 8m 24s
 - periodic-keystone-python27-juno
 http://logs.openstack.org/periodic-stableperiodic-keystone-python27-juno/727a389/
 : SUCCESS in 9m 40s

 ___
 Openstack-stable-maint mailing list
 openstack-stable-ma...@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint

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


Re: [openstack-dev] [cinder] [nova] [glance] Consistency in client side sorting

2015-01-06 Thread Duncan Thomas
I've got no strong preferences on which we go for, but agree they should be
consistent. The internal python library options should also be consistent.

On 5 January 2015 at 20:52, Mike Perez thin...@gmail.com wrote:

 On 09:13 Mon 05 Jan , Steven Kaufer wrote:
  Giving that each of these 3 clients will be supporting client-side
 sorting
  in kilo, it seems that we should get this implemented in a consistent
  manner.  It seems that the 2 options are either:
 
--sort-key key1 --sort-dir desc --sort-key key2 --sort-dir asc
--sort key1:asc,key2:desc
 
  Personally, I favor option 2 but IMO it is more important that these are
  made consistent.

 I like option 2 better.

 --
 Mike Perez

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




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


Re: [openstack-dev] [Openstack] [Devstack][Neutron]Neutron with External DHCP server

2015-01-06 Thread Erhan Ekici
Hi,

As far as I know, there is a spec and feature for external dhcp server
configuration but *just for ironic project* (bare metal installation).
Btw, I have not tested it yet.

http://specs.openstack.org/openstack/ironic-specs/specs/juno/support-external-dhcp.html

Erhan,





On Tue, Jan 6, 2015 at 1:04 PM, foss geek thefossg...@gmail.com wrote:

 Dear All,

 Is it possible to configure neutron to take VM ip from external DHCP
 server?

 I am having All In One openstack env deployed using devstack icehouse. I
 am looking for an option to integrate it with external DHCP server.

 --
 Thanks  Regards
 E-Mail: thefossg...@gmail.com
 IRC: neophy
 Blog : http://lmohanphy.livejournal.com/


 ___
 Mailing list:
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
 Post to : openst...@lists.openstack.org
 Unsubscribe :
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


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


Re: [openstack-dev] [Devstack][Neutron]Neutron with External DHCP server

2015-01-06 Thread Ihar Hrachyshka

On 01/06/2015 12:04 PM, foss geek wrote:

Dear All,

Is it possible to configure neutron to take VM ip from external DHCP 
server?


I am having All In One openstack env deployed using devstack icehouse. 
I am looking for an option to integrate it with external DHCP server.


At the moment, there is no way to achieve this, though the option was 
discussed as part of Pluggable IPAM effort that was approved for Kilo: 
http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/kilo/neutron-ipam.rst


Quoting the spec: Out-of-Scope Items [...] Pluggable DHCP would require 
a separate effort,

or must be addressed within the individual drivers.

/Ihar

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


[openstack-dev] stevedore 1.2.0 released

2015-01-06 Thread Doug Hellmann
The Oslo team is pleased to announce the release of
stevedore 1.2.0: Manage dynamic plugins for Python applications

This release includes an update to eliminate excessive deprecation
warnings generated by pkg_resources when plugins are loaded.

For more details, please see the git log history below and
 https://launchpad.net/python-stevedore/+milestone/1.2.0

Please report issues through launchpad:
 https://bugs.launchpad.net/python-stevedore



Changes in openstack/stevedore  1.1.0..1.2.0

37c94cd Use pkg_resources resolve() and require() instead of load()
9324bf0 Fix the README.rst file format for pypi
6027ff6 Workflow documentation is now in infra-manual
bbafbe9 Implement a __contains__ override for extension manager
f33adbe Update link to docs in README
a322d61 Bring doc build up to standard

  diffstat (except docs and test files):

 CONTRIBUTING.rst  |   2 +-
 README.rst|  12 +-
 setup.cfg |   4 +-
 stevedore/extension.py|  14 +-
 test-requirements.txt |   1 +
 54 files changed, 1792 insertions(+), 1734 deletions(-)

  Requirements updates:

 diff --git a/test-requirements.txt b/test-requirements.txt
 index 7f1e798..6075428 100644
 --- a/test-requirements.txt
 +++ b/test-requirements.txt
 @@ -11,0 +12 @@ oslotest=1.2.0  # Apache-2.0
 +oslosphinx=2.2.0  # Apache-2.0

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


[openstack-dev] oslo.i18n 1.2.0 release

2015-01-06 Thread Doug Hellmann
The Oslo team is pleased to announce the release of
oslo.i18n 1.2.0: oslo.i18n library

The primary reason for this release is to move the code
out of the oslo namespace package as part of
https://blueprints.launchpad.net/oslo-incubator/+spec/drop-namespace-packages

For more details, please see the git log history below and
 http://launchpad.net/oslo.i18n/+milestone/1.2.0

Please report issues through launchpad:
 http://bugs.launchpad.net/oslo.i18n



Changes in openstack/oslo.i18n  1.1.0..1.2.0

582c718 Correct the translation domain for loading messages
ba05e9a Move out of the oslo namespace package
c86629e Workflow documentation is now in infra-manual
53635ea Force code sample to be treated as python

  diffstat (except docs and test files):

 CONTRIBUTING.rst|   7 +-
 oslo/i18n/__init__.py   |  23 +-
 oslo/i18n/_factory.py   | 110 --
 oslo/i18n/_gettextutils.py  |  90 -
 oslo/i18n/_i18n.py  |  25 --
 oslo/i18n/_lazy.py  |  38 --
 oslo/i18n/_locale.py|  25 --
 oslo/i18n/_message.py   | 167 -
 oslo/i18n/_translate.py |  73 
 oslo/i18n/fixture.py|  54 +--
 oslo/i18n/log.py|  86 +
 oslo_i18n/__init__.py   |  16 +
 oslo_i18n/_factory.py   | 110 ++
 oslo_i18n/_gettextutils.py  |  90 +
 oslo_i18n/_i18n.py  |  25 ++
 oslo_i18n/_lazy.py  |  38 ++
 oslo_i18n/_locale.py|  25 ++
 oslo_i18n/_message.py   | 167 +
 oslo_i18n/_translate.py |  73 
 oslo_i18n/fixture.py|  65 
 oslo_i18n/log.py|  97 ++
 setup.cfg   |   2 +-
 tests/fakes.py  |  59 
 tests/test_factory.py   |  91 -
 tests/test_fixture.py   |   2 +-
 tests/test_gettextutils.py  | 128 ---
 tests/test_handler.py   |   4 +-
 tests/test_lazy.py  |  40 ---
 tests/test_locale_dir_variable.py   |  32 --
 tests/test_logging.py   |  42 ---
 tests/test_message.py   | 518 
 tests/test_public_api.py|   2 +-
 tests/test_translate.py |  44 ---
 tests/test_warning.py   |  61 
 tests/utils.py  |  42 ---
 tox.ini |   2 +-
 52 files changed, 2004 insertions(+), 1699 deletions(-)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Cross-Project meeting, Tue January 6th, 21:00 UTC

2015-01-06 Thread Sean Dague
On 01/06/2015 06:14 AM, Thierry Carrez wrote:
 Dear PTLs, cross-project liaisons and anyone else interested,
 
 We'll have a cross-project meeting today at 21:00 UTC, with the
 following agenda:
 
 * State of nova-network to neutron migration
 * Discuss openstack-spec: log guidelines [1]
 * Discuss openstack-spec: OSProfiler [2]
 * Open discussion  announcements
 
 [1] https://review.openstack.org/#/c/132552/
 [2] https://review.openstack.org/#/c/134839/

I took another spin on [1] this morning attempting to clear up the
confusing parts and dumping the security section for now (as it was kind
of a mismatch in structure for this document).

Hopefully it's good enough to go at this point.

-Sean

 
 See you there !
 
 For more details on this meeting, please see:
 https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting
 


-- 
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] [Fuel] update existing plugin and add new ones

2015-01-06 Thread samuel.bartel
Hello,

Actually there is two different fuel plugins git repositories. One in 
stackforge and the other in mirantis:
https://github.com/stackforge/fuel-plugins
https://github.com/Mirantis/fuel-plugins

it is a little bit confusing. Why needing two different repositories?

which one should be used in order to:
-add new plugin
-update/correct exisiting one (for example adding 7-mode and e-series support 
to cinder netapp plugin according to  
https://bugs.launchpad.net/fuel/+bug/1405186)
How are going to be manage version? There is a stable/6.0 branch from 
stackforge repo but not mirantis one

Regards,

Samuel Bartel
Orange




_

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

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

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


Re: [openstack-dev] [Ironic] mid-cycle details

2015-01-06 Thread Thierry Carrez
Devananda van der Veen wrote:
 Dates: Feb 3 - 5 (Tue - Thu) with a half day for those sticking around
 on Friday, Feb 6th.
 
 Location:
   Hewlett Packard Centre de Compétences
   5 Avenue Raymond Chanas
   38320 Eybens
   Grenoble, France

Could you please reference it on:
https://wiki.openstack.org/wiki/Sprints

Thanks!

-- 
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] [api] [sdk] Proposal to achieve consistency in client side sorting

2015-01-06 Thread Kevin L. Mitchell
On Tue, 2015-01-06 at 12:19 -0600, Anne Gentle wrote:
 I'm all for consistency. Sounds like a great case for the API Working
 Group to document. You can propose a patch describing the way we want
 sorting to work. 
 
 
 See https://review.openstack.org/#/q/project:openstack/api-wg,n,z

I really think that the API WG should be responsible for the REST API
only, TBH, and maybe for the Pythonic APIs.  Once we start talking about
CLI options, I think that's outside the API WG's perview, and we
probably should have that be up to CLI authors.  My thinking is that a
REST API and a Python API are both used by developers, where we have one
set of conventions; but when you start talking about CLI, you're really
talking about UX, and the rules there can be vastly different.

Now, my personal preference on the CLI side is that --sort key[:dir]
is the way to go, but I helped hash that out in the novaclient
implementation as a reviewer.  I also had suggestions about how it
should be transmitted in the REST API, but that had already been settled
at the blueprint phase; that may be something the API WG will want to
take up and review and provide guidance on now, though…
-- 
Kevin L. Mitchell kevin.mitch...@rackspace.com
Rackspace


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


Re: [openstack-dev] [Fuel] update existing plugin and add new ones

2015-01-06 Thread Christopher Aedo
Ah, bad paste, sorry.

All the details around developing and certifying a plug-in can be found here:
http://docs.mirantis.com/openstack/fuel/fuel-6.0/plugin-dev.html

-Christopher

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


[openstack-dev] [Keystone] LDAP Assignment Backend Use Survey

2015-01-06 Thread Morgan Fainberg
The Keystone team is evaluating the support of the LDAP Assignment backend 
within OpenStack and how it is used in deployments. The assignment backend 
covers “Projects/Tenants”, “Roles/Grants”, and in the case of SQL “Domains”.

There is a concern that the assignment backend implemented against LDAP is 
falling further and further behind the SQL implementation. To get a good read 
on the deployments and how the LDAP assignment backend is being used, the 
Keystone development team would appreciate feedback from the community.  Please 
fill out the following form and let us know if you are using LDAP Assignment, 
what it provides you that the SQL assignment backend is not providing, and the 
release of OpenStack (specifically Keystone) you are using.

http://goo.gl/forms/xz6xJQOQf5 http://goo.gl/forms/xz6xJQOQf5

This poll is only meant to get information on the use of the LDAP Assignment 
backend which only contains Projects/Tenants and Roles/Grants.

Cheers,
Morgan Fainberg

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


Re: [openstack-dev] [Octavia] Questions about the Octavia project

2015-01-06 Thread Phillip Toohill
Ill answer inline what I can, others can chime in to clear up anything and
answer the rest. 

On 1/6/15 10:38 AM, Andrew Hutchings and...@linuxjedi.co.uk wrote:

Hi,

I¹m looking into the Octavia project in relation to something my team are
working on inside HP and I have a bunch of questions.  I realise it is
early days for the project and some of these could be too low level at
this time.

Some of these questions come from the fact that I could not get the
documentation to compile and the docs site for Octavia is down.  The
v0.5-component-design.dot file crashes Graphviz 2.38 in every OS I tried
and unfortunately all my dev machines have that version or 2.36 which is
too low to render it correctly.  It also requires at least 5 extra
dependencies (Sphinx modules) to build the docs but doesn¹t try to
install them.

I¹ll guess I¹ll start from the most obvious question:

1. Octavia looks a lot like Libra but with integration into Neutron and
Barbican (both were planned for Libra) as well as few other changes.  So
the most obvious question is: why not just develop Libra for integration
with Neutron?
There was many discussions with many contributors that included HP,
Rackspace, Bluebox A10 etc.. In regards to this decision. In the docs we
should have links to the reasonings behind some of these.

Amphorae stuff:

2. I see a lot of building blocks for the controller and Amphorae but not
a lot about communication.  What protocol / method is to be used to
communicate to the Amphorae instances?
In the docs/specs the communication protocols are defined.

3. How are Amphorae instances to be spun up on-demand?  I see a reference
to Heat but not sure if that is why it is there

The specs define how this is to happen

4. There is mention of Docker in some of the deploy scripts.  Is this for
multi-tenancy or just separation of the Amphorae processes?
5. I take it Amphorae is designed to be single-AZ for now?

Load Balancing:

6. It seems like you are going to have SSL termination support and are
going to use HAProxy, which means that you will have unencrypted data
between the LB and web servers.  How do you plan to work around this
problem?
Not sure what the 'problem' is, ultimately its up to the user, but a
private network can be configured between the LB and Web server

Security:

7. Someone in the specification there is talk of a 1 minute cache of
security certificates.  How are you going to ensure that the cache will
actually erase that cache after the 1 minute?  Also why cache them at
all?  It seems to me to be a potential security risk

API:

8. More a comment than a question.  There is talk of using Pecan+WSME.
Libra had a 5K patch on top of WSME just to make it behave correctly with
Pecan and correct JSON specifications in certain situations, judging by
the planned API you will also hit those same situations.  I admit I¹ve
not looked at WSME for a year and there was an effort to strip it out of
Libra completely at one point.  So that one is mainly my 2c :)

Many thanks for your time.

Kind Regards
--
Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/




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


Re: [openstack-dev] [Fuel] update existing plugin and add new ones

2015-01-06 Thread Christopher Aedo
On Tue, Jan 6, 2015 at 7:00 AM,  samuel.bar...@orange.com wrote:
 Actually there is two different fuel plugins git repositories. One in
 stackforge and the other in mirantis:

 https://github.com/stackforge/fuel-plugins
Stackforge plug-ins - used for plug-ins developed by Fuel Core team.

 https://github.com/Mirantis/fuel-plugins
Mirantis plug-ins - used for plug-ins developed by Partner
Integrations and MOS teams.

 it is a little bit confusing. Why needing two different repositories?

Samuel, I agree, it is confusing.  From what I see the repo on
stackforge is the one that matters from the perspective of someone
building a new plugin.  For those just looking to download and use a
plug-in, the directory of certified and non-certified plug-ins for
Fuel will live here:
https://software.mirantis.com/download-mirantis-openstack-fuel-plug-ins/

All the details around developing and certifying a plug-in can be found here:
https://software.mirantis.com/download-mirantis-openstack-fuel-plug-ins/
Feedback on improving the docs is greatly appreciated!

 How are going to be manage version? There is a stable/6.0 branch from
 stackforge repo but not mirantis one
Since plugins are developed and built outside Fuel, the plugins have
their own versions (see metadata.yaml file).

I expect we will make things a little clearer in the weeks to come,
but please share your feedback and thoughts on how to make this work
better.  Thanks!

-Christopher

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


[openstack-dev] [Telco][NFV] Meeting Reminder - Wednesday January 7th @ 2200 UTC in #openstack-meeting

2015-01-06 Thread Steve Gordon
Hi all,

Just a reminder that the OpenStack Telco Working Group [1] will be meeting @ 
2200 UTC in #openstack-meeting on Wednesday January 7th. Draft agenda is 
available here:

https://etherpad.openstack.org/p/nfv-meeting-agenda

Please feel free to add items that you wish to discuss at the meeting.

Thanks,

Steve

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

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


Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0

2015-01-06 Thread Dr. Jens Rosenboom

Am 06/01/15 um 18:01 schrieb Daniel P. Berrange:

On Tue, Jan 06, 2015 at 05:36:38PM +0100, Ihar Hrachyshka wrote:

On 01/06/2015 05:33 PM, Daniel P. Berrange wrote:

On Tue, Jan 06, 2015 at 10:21:10AM -0600, Matt Riedemann wrote:

Odd...eventlet 0.16.0 was released on 12/30 and the eventlet.util import is
still in the libvirt host module, but this isn't blowing up in the Jenkins
runs, so what's different?  There isn't a version cap on eventlet in
global-requirements either.

When I pip install it in my dev env it still pulls in 0.15.2.

Likewise looking at a jenkins log from today it pulls in 0.15.2

   
http://logs.openstack.org/89/140089/3/check/gate-nova-python27/55b24ee/tox/py27-1.log

But the pypi page refers to 0.16.0

   https://pypi.python.org/pypi/eventlet/

?!?!?


Maybe some external dependency pulls in older version?


Ah, it seems my devpi/wheel caching setup was not seeing the new version.
When I forced a refresh in that, it pulled down 0.16.0 Wonder if the gate
has a similar cache refresh issue


As I noted in https://bugs.launchpad.net/nova/+bug/1407685/comments/3 
the pypi version of eventlet 0.16.0 does still include the old code, so 
you are only going to see this issue if you install eventlet from 
source. In particular most devstack issues will not see this issue until 
the pypi package is fixed.



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


Re: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon ode support

2015-01-06 Thread Carl Baldwin
Miguel,

Thanks again for taking this on.  I went looking for the rootwrap
daemon code today in gerrit and found it here [1].  I can allocate
some review cycles to help get this merged early in the cycle.  Please
keep us posted on your progress refreshing the code.

Carl

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

On Mon, Nov 10, 2014 at 2:05 AM, Miguel Angel Ajo Pelayo
majop...@redhat.com wrote:
 Thank you very much Armando,

 I updated the spec (which is missing the dev impact now) and I must rebase
 all the patches.  That may happen during tomorrow if I'm not missing
 anything.

 I will ping you back when it's ready.

 Sent from my Android phone using TouchDown (www.nitrodesk.com)


 -Original Message-
 From: Armando M. [arma...@gmail.com]
 Received: Saturday, 08 Nov 2014, 11:25
 To: OpenStack Development Mailing List (not for usage questions)
 [openstack-dev@lists.openstack.org]
 Subject: Re: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap
 daemon ode support


 Hi Miguel,

 Thanks for picking this up. Pull me in and I'd be happy to help!

 Cheers,
 Armando

 On 7 November 2014 10:05, Miguel Ángel Ajo majop...@redhat.com wrote:


 Hi Yorik,

I was talking with Mark Mcclain a minute ago here at the summit about
 this. And he told me that now at the start of the cycle looks like a good
 moment to merge the spec  the root wrap daemon bits, so we have a lot of
 headroom for testing during the next months.

We need to upgrade the spec [1] to the new Kilo format.

Do you have some time to do it?, I can allocate some time and do it
 right away.

 [1] https://review.openstack.org/#/c/93889/
 --
 Miguel Ángel Ajo
 Sent with Sparrow

 On Thursday, 24 de July de 2014 at 01:42, Miguel Angel Ajo Pelayo wrote:

 +1

 Sent from my Android phone using TouchDown (www.nitrodesk.com)


 -Original Message-
 From: Yuriy Taraday [yorik@gmail.com]
 Received: Thursday, 24 Jul 2014, 0:42
 To: OpenStack Development Mailing List [openstack-dev@lists.openstack.org]
 Subject: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon
 mode support


 Hello.

 I'd like to propose making a spec freeze exception for
 rootwrap-daemon-mode spec [1].

 Its goal is to save agents' execution time by using daemon mode for
 rootwrap and thus avoiding python interpreter startup time as well as sudo
 overhead for each call. Preliminary benchmark shows 10x+ speedup of the
 rootwrap interaction itself.

 This spec have a number of supporters from Neutron team (Carl and Miguel
 gave it their +2 and +1) and have all code waiting for review [2], [3], [4].
 The only thing that has been blocking its progress is Mark's -2 left when
 oslo.rootwrap spec hasn't been merged yet. Now that's not the case and code
 in oslo.rootwrap is steadily getting approved [5].

 [1] https://review.openstack.org/93889
 [2] https://review.openstack.org/82787
 [3] https://review.openstack.org/84667
 [4] https://review.openstack.org/107386
 [5]
 https://review.openstack.org/#/q/project:openstack/oslo.rootwrap+topic:bp/rootwrap-daemon-mode,n,z

 --

 Kind regards, Yuriy.
 ___
 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]nova not work with eventlet 0.16.0

2015-01-06 Thread Thomas Goirand
On 01/06/2015 09:56 PM, victor stinner wrote:
 Hi,
 
 I set up nova environment with latest upstream code.
 nova-compute can not boot up due to failed to load libvirt driver.
 by further debugging. found that eventlet (0.16.0) remove util which is
 referenced by libvirt driver.
 after I downgrade to (0.15.2) it works.
 
 Can you please try my following change?
 https://review.openstack.org/#/c/145335/
 
 It changes the libvirt driver to stop using the deprecated (and now removed) 
 eventlet.util module.
 
 Victor

Victor,

Could you also backport this to Juno?

Cheers,

Thomas


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


[openstack-dev] [nova] unit test migration failure specific to MySQL/MariaDB - 'uuid': used in a foreign key constraint 'block_device_mapping_instance_uuid_fkey'

2015-01-06 Thread Mike Bayer
Hello -

Victor Sergeyev and I are both observing the following test failure which 
occurs with all the tests underneath 
nova.tests.unit.db.test_migrations.TestNovaMigrationsMySQL.This is against 
master with a brand new tox environment and everything at the default.

It does not seem to be occurring on gates that run these tests and 
interestingly the tests seem to complete very quickly (under seven seconds) on 
the gate as well; the failures here take between 50-100 seconds to occur, not 
fully deterministically, and only on the MySQL backend; the Postgresql and 
SQLite versions of these tests pass.  I’m running against MariaDB server 
10.0.14 with Python 2.7.8 on Fedora 21.   

Below is the test just for test_walk_versions, but the warnings (not 
necessarily the failures themselves) here also occur for test_migration_267 as 
well as test_innodb_tables.

I’m still looking into what the cause of this is, I’d imagine it’s something 
related to newer MySQL versions or perhaps MariaDB vs. MySQL, I’m just putting 
it up here in case someone already knows what this is or has some clue to save 
me some time figuring it out.  I apologize if I’m just doing something dumb, 
I’ve only recently begun to run Nova’s test suite in full against all backends, 
so I haven’t yet put intelligent thought into this nor have I tried to yet look 
at the migration in question causing the problem.  Will do that next.


[mbayer@thinkpad nova]$ tox -e py27 -- 
nova.tests.unit.db.test_migrations.TestNovaMigrationsMySQL.test_walk_versions
py27 develop-inst-noop: /home/mbayer/dev/openstack/nova
py27 runtests: PYTHONHASHSEED='0'
py27 runtests: commands[0] | find . -type f -name *.pyc -delete
py27 runtests: commands[1] | bash tools/pretty_tox.sh 
nova.tests.unit.db.test_migrations.TestNovaMigrationsMySQL.test_walk_versions
running testr
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ${OS_TEST_PATH:-./nova/tests} 
--list 
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ${OS_TEST_PATH:-./nova/tests}  
--load-list /tmp/tmpw7zqhE

2015-01-06 18:28:12.913 32435 WARNING oslo.db.sqlalchemy.session 
[req-5cc6731f-00ef-43df-8aec-4914a44d12c5 ] MySQL SQL mode is '', consider 
enabling TRADITIONAL or STRICT_ALL_TABLES
{0} 
nova.tests.unit.db.test_migrations.TestNovaMigrationsMySQL.test_walk_versions 
[51.553131s] ... FAILED

Captured traceback:
~~~
Traceback (most recent call last):
  File nova/tests/unit/db/test_migrations.py, line 151, in 
test_walk_versions
self.walk_versions(self.snake_walk, self.downgrade)
  File 
/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/oslo/db/sqlalchemy/test_migrations.py,
 line 193, in walk_versions
self.migrate_up(version, with_data=True)
  File nova/tests/unit/db/test_migrations.py, line 148, in migrate_up
super(NovaMigrationsCheckers, self).migrate_up(version, with_data)
  File 
/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/oslo/db/sqlalchemy/test_migrations.py,
 line 263, in migrate_up
self.REPOSITORY, version)
  File 
/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/migrate/versioning/api.py,
 line 186, in upgrade
return _migrate(url, repository, version, upgrade=True, err=err, **opts)
  File string, line 2, in _migrate
  File 
/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/migrate/versioning/util/__init__.py,
 line 160, in with_engine
return f(*a, **kw)
  File 
/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/migrate/versioning/api.py,
 line 366, in _migrate
schema.runchange(ver, change, changeset.step)
  File 
/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/migrate/versioning/schema.py,
 line 93, in runchange
change.run(self.engine, step)
  File 
/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/migrate/versioning/script/py.py,
 line 148, in run
script_func(engine)
  File 
/home/mbayer/dev/openstack/nova/nova/db/sqlalchemy/migrate_repo/versions/267_instance_uuid_non_nullable.py,
 line 103, in upgrade
process_null_records(meta, scan=False)
  File 
/home/mbayer/dev/openstack/nova/nova/db/sqlalchemy/migrate_repo/versions/267_instance_uuid_non_nullable.py,
 line 89, in process_null_records
table.columns.uuid.alter(nullable=False)
  File 
/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/migrate/changeset/schema.py,
 line 534, in alter
return alter_column(self, *p, **k)
  File 
/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/migrate/changeset/schema.py,
 line 141, in 

[openstack-dev] [Nova] Etherpad for the Nova midcycle meetup

2015-01-06 Thread Michael Still
Heya,

https://etherpad.openstack.org/p/kilo-nova-midcycle is the etherpad
for the Nova midcycle meetup. I'd like to start collecting topics we'd
like to cover, and we'll sort them by priority later once we've
collected a few.

Thanks,
Michael

-- 
Rackspace Australia

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


[openstack-dev] taskflow 0.6.1 released

2015-01-06 Thread Joshua Harlow

The Oslo team is pleased to announce the release of:

taskflow 0.6.1: Taskflow structured state management library.

For more details, please see the git log history below and:

http://launchpad.net/taskflow/+milestone/0.6.1

Please report issues through launchpad:

http://bugs.launchpad.net/taskflow/

Changes in taskflow 0.6.0..0.6.1
---

69449ae Remove need to inherit/adjust netutils split
b52db18 Allow specifying the engine 'executor' as a string
2ed1ad9 Disallowing starting the executor when worker running
50c5441 Use a single shared queue for an executors lifecycle
49ac8ec Avoid creating a temporary list(s) for tree type
05518ca Update statement around stopwatch thread safety
d498fdb Register with 'ANY' in the cloned process
fce7afb Remove less than useful action_engine __str__
f897008 Ensure manager started/shutdown/joined and reset
f862775 Return the same namedtuple that the future module returns
6cb9a0c Add a simplistic hello world example
e841b5a Get event/notification sending working correctly
a170f4b Move the engine scoping test to its engines test folder
2a8fde1 Get the basics of a process executor working
dbc890f Correctly trigger 'on_exit' of starting/initial state
2b959da Add an example which shows how to send events out from tasks

Diffstat (except docs and test files)
-

taskflow/engines/action_engine/engine.py   | 113 +-
taskflow/engines/action_engine/executor.py | 429 
-

taskflow/engines/worker_based/engine.py|  34 +-
taskflow/engines/worker_based/executor.py  |  18 +-
taskflow/examples/alphabet_soup.py | 101 +
taskflow/examples/hello_world.py   | 110 ++
taskflow/examples/wbe_event_sender.py  | 148 +++
taskflow/types/fsm.py  |   7 +-
taskflow/types/timing.py   |   5 +-
taskflow/types/tree.py |   9 +-
taskflow/utils/async_utils.py  |  33 +-
taskflow/utils/lock_utils.py   |   9 +-
taskflow/utils/misc.py |  24 +-
taskflow/utils/threading_utils.py  |   7 +
26 files changed, 1517 insertions(+), 479 deletions(-)

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


Re: [openstack-dev] [oslo] Progress of the port to Python 3

2015-01-06 Thread Thomas Goirand
On 01/06/2015 05:51 PM, victor stinner wrote:
 Hi,
 
 I'm still working on porting OpenStack to Python 3.
 I'm fixing Python 3 issues in eventlet and I'm trying
 to replace eventlet with trollius in OpenStack. Two
 different and complementary ways to port OpenStack to Python 3.

Hi Victor,

Will you also work on moving away from python-memcache (eg: memcached)
and using pymemcache instead? I believe I shouted enough about this
being a major issue for the support of Python 3, but nothing is
happening here.

 I fixed some eventlet issues related to Python 3 and
 monkey-patching. My changes are part of eventlet 0.16 which was
 released the 2014-12-30. I tried this version with Oslo Messaging:
 with another fix in eventlet (threading.Condition) and a change in
 the zmq driver, only 3 tests are now failing (which is a great
 success for me).

Super cool! :)

Cheers,

Thomas Goirand (zigo)


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


[openstack-dev] [stable] Proposal to add Flavio Percoco to stable-maint-core

2015-01-06 Thread Adam Gandelman
Hiya-

Flavio has been actively involved in stable branch maintenance for as long
as I can remember, but it looks like his +2 abilities were removed after
the organizational changes made to the stable maintenance teams.  He has
expressed interest in continuing on with general stable maintenance and I
think his proven understanding of branch policies make him a valuable
contributor. I propose we add him to the stable-maint-core team.

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


Re: [openstack-dev] [stable] Proposal to add Flavio Percoco to stable-maint-core

2015-01-06 Thread Morgan Fainberg
+1

Flavio has always been a good gate keeper of stable across the board. 

Sent via mobile

 On Jan 6, 2015, at 11:32, Adam Gandelman ad...@ubuntu.com wrote:
 
 Hiya-
 
 Flavio has been actively involved in stable branch maintenance for as long as 
 I can remember, but it looks like his +2 abilities were removed after the 
 organizational changes made to the stable maintenance teams.  He has 
 expressed interest in continuing on with general stable maintenance and I 
 think his proven understanding of branch policies make him a valuable 
 contributor. I propose we add him to the stable-maint-core team.
 
 Cheers,
 Adam
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


[openstack-dev] [Neutron] client noauth deprecation

2015-01-06 Thread Kevin Benton
The option to disable keystone authentication in the neutron client was
marked for deprecation in August as part of a Keystone support upgrade.[1]

What was the reason for this? As far as I can tell, Neutron works fine in
the 'noauth' mode and there isn't a lot of code that tightly couples
neutron to Keystone that I can think of.


1.
https://github.com/openstack/python-neutronclient/commit/2203b013fb66808ef280eff0285318ce21d9bc67#diff-ba2e4fad85e66d9aabb6193f222fcc4cR438

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


[openstack-dev] [Cross Project][Log][Profiler] Specs are in review and need constructive feedback soonest

2015-01-06 Thread Rochelle Grober
The Cross Project team meeting discussed the following specs today:



 * Discuss openstack-spec: log guidelines [1]

 * Discuss openstack-spec: OSProfiler [2]

 * Open discussion  announcements



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

 [2] https://review.openstack.org/#/c/134839/

For [1], the log guidelines spec is likely to reach approval for merge by the 
next meeting on 1/13.  The spec has not been discussed on any mailing list for 
a while, so might be flying a bit under the radar.  This log guidelines spec is 
high level and states a number of best practices for developers when writing 
the logging chunks of their project code.  It also codifies the set of log 
levels: Error; Warning; Info; etc. and removes the AUDIT level.

Operators and others who hold an interest in this:  *PLEASE REVIEW [1] AND 
COMMENT ON THE REVIEW BY 1/13*  Lack of comments, as always, implies approval.  
If there is only light discussion of the spec, it will be approved.  If there 
is lively discussion, the discussion will move towards consensus before final 
approval.

The spec will then be used to expand the code review checklist so that its 
contents are enforced.

For [2], the OSProfiler spec is not as far along, but if you as an Ops (or 
interested developer) sees an issue or has a suggestion for improvement, you 
should also comment on this review.  The profiler already has code in use and 
is considered useful by a number of developers and some DevOps, which is why 
this spec and its review is being highlighted for this audience.

Ops, if you've never commented on a review before, don't let that hurdle stop 
you.  Check  out this page:  
http://docs.openstack.org/infra/manual/developers.html#code-review

It tells you how to post a review.  It doesn't tell you that you need get an 
account on Launchpad.net, but that info is here:
http://docs.openstack.org/infra/manual/developers.html#account-setup . I'm not 
sure if you have to be a member of OpenStack for commenting, but I'm sure folks 
will chime in if you do;-)

If working through these docs is hard for you, go out to IRC and folks will 
help get you started so you *can* comment on the reviews.

Also, if there is a section of the spec that you feel needs broader attention, 
start a discussion of it on the mailing list.  Please reference the review and 
the part of the spec you want to discuss, but put it out there on the mailing 
list so the issues/suggestions you have get addressed.

--Rocky


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


Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0

2015-01-06 Thread Eli Qiao


在 2015年01月07日 04:56, victor stinner 写道:

Hi,


I set up nova environment with latest upstream code.
nova-compute can not boot up due to failed to load libvirt driver.
by further debugging. found that eventlet (0.16.0) remove util which is
referenced by libvirt driver.
after I downgrade to (0.15.2) it works.

Can you please try my following change?
https://review.openstack.org/#/c/145335/

It changes the libvirt driver to stop using the deprecated (and now removed) 
eventlet.util module.

Victor
thanks victor, you response so quick, appreciate, I will get some time 
to verify it

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



--
Thanks,
Eli (Li Yong) Qiao


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


[openstack-dev] [nova][api]do we need to have a spec for all api related changes?

2015-01-06 Thread Eli Qiao

hi all:
I have a patch [1], just did slight changes on api, do I need to write a 
spec(kinds of wasting time to get approved)?
since api-microversion[2] is almost done, can we just feel free to add 
changes as micro-version api?

like bump version , write down changes in rest_api_version_history.rst

[1] https://review.openstack.org/#/c/144914/
[2] 
https://review.openstack.org/#/q/status:merged+project:openstack/nova+branch:master+topic:bp/api-microversions,n,z 



--
Thanks,
Eli (Li Yong) Qiao

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


Re: [openstack-dev] [api] [sdk] Proposal to achieve consistency in client side sorting

2015-01-06 Thread Everett Toews
On Jan 6, 2015, at 12:46 PM, Kevin L. Mitchell kevin.mitch...@rackspace.com 
wrote:

 On Tue, 2015-01-06 at 12:19 -0600, Anne Gentle wrote:
 I'm all for consistency. Sounds like a great case for the API Working
 Group to document. You can propose a patch describing the way we want
 sorting to work. 
 
 
 See https://review.openstack.org/#/q/project:openstack/api-wg,n,z
 
 I really think that the API WG should be responsible for the REST API
 only, TBH, and maybe for the Pythonic APIs.  Once we start talking about
 CLI options, I think that's outside the API WG's perview, and we
 probably should have that be up to CLI authors.  My thinking is that a
 REST API and a Python API are both used by developers, where we have one
 set of conventions; but when you start talking about CLI, you're really
 talking about UX, and the rules there can be vastly different.

Agreed. The scope [1] of the API WG is the HTTP (REST) API. 

We won’t be touching any language SDKs (one of which is referred to as Pythonic 
APIs above) or any CLIs.

Thanks,
Everett

[1] https://wiki.openstack.org/wiki/API_Working_Group#Scope
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Keystone] Etherpad for the Keystone midcycle meetup

2015-01-06 Thread Steve Martinelli
Howdy,

https://etherpad.openstack.org/p/kilo-keystone-midcycle is the etherpad
for the Keystone midcycle meetup. Similar to the Nova team, we should 
start
collecting topics to cover, and sort them by priority later once we've
collected a few.

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


[openstack-dev] [Refstack] Refstack mid cycle meet up in Santa Clara, CA Jan 12-14 2015

2015-01-06 Thread Rochelle Grober
Refstack is having its midcycle F2F meetup January 12-14, 2015 in Santa Clara, 
CA

Etherpad is:  https://etherpad.openstack.org/p/refstack-january-2015-midcycle

Everyone is welcome to join in, but please add your list to the etherpad if you 
will be attending in person.

We are hoping to do a sprint on getting the Refstack website back up and 
running, and are inviting local infra folks to suggest a session time and date 
for possibly doing this F2F, too.  We hope we can quickly identify what infra 
needs to make this happen, and get the site up and action items for what else 
is needed during the session.  The Refstack team is flexible in shifting 
sessions to accommodate the Infra team.

We also will be working on  the test UUID and would love any local QA team 
members to join for a session or two.

And, just to round this out, are there any Docs folks who might want to help 
for a session.  We promise at least one Refstack member dedicated to your 
needs;-)

There will be group dinners for those interested...

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


Re: [openstack-dev] [Openstack] [Devstack][Neutron]Neutron with External DHCP server

2015-01-06 Thread John Belamaric
We have a spec for implementing a DHCP relay agent [1], which would enable 
this.  We have implemented this, but it's not upstream (yet!). You would have 
to download our adapter [2] and dissect it to get the code from there, which 
may be pretty painful, because the package includes lots of changes related to 
our integration rather than just the relay.

The adapter uses ISC dhcrelay, but we had to patch it to add the link selection 
option. That code is also included with the adapter package, along with a build 
script for it.

[1] https://blueprints.launchpad.net/neutron/+spec/dhcp-relay
[2] https://www.infoblox.com/products/private-hybrid-cloud/openstack-adapter

From: Erhan Ekici erhan.ek...@gmail.commailto:erhan.ek...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, January 6, 2015 at 9:00 AM
To: foss geek thefossg...@gmail.commailto:thefossg...@gmail.com
Cc: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, 
openstack openst...@lists.openstack.orgmailto:openst...@lists.openstack.org
Subject: Re: [openstack-dev] [Openstack] [Devstack][Neutron]Neutron with 
External DHCP server

Hi,

As far as I know, there is a spec and feature for external dhcp server 
configuration but just for ironic project (bare metal installation).
Btw, I have not tested it yet.

http://specs.openstack.org/openstack/ironic-specs/specs/juno/support-external-dhcp.html

Erhan,





On Tue, Jan 6, 2015 at 1:04 PM, foss geek 
thefossg...@gmail.commailto:thefossg...@gmail.com wrote:
Dear All,

Is it possible to configure neutron to take VM ip from external DHCP server?

I am having All In One openstack env deployed using devstack icehouse. I am 
looking for an option to integrate it with external DHCP server.

--
Thanks  Regards
E-Mail: thefossg...@gmail.commailto:thefossg...@gmail.com
IRC: neophy
Blog : http://lmohanphy.livejournal.com/


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : 
openst...@lists.openstack.orgmailto:openst...@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


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


[openstack-dev] [kolla][tripleo] Announcing Kolla Milestone #2

2015-01-06 Thread Steven Dake
I'm pleased to announce the release of Kolla Milestone #2 available for 
immediate download from

https://github.com/stackforge/kolla/archive/version-m2.tar.gz.

Kolla is an effort to bring container deployment of OpenStack to TripleO.

This milestone brings several new features:

 * Integrated Neutron container

 * Integrated Ceilometer container

 * Integrated Horizon container

 * Integrated Zaqar container

 * Integrated Mongodb container


As can be seen from our list of updates, most of the work has been 
focused on updating the services we support to more fully deploy 
OpenStack.  Our huge feature this release is Neutron, which we would 
love people to test and use.


Instructions for running Kolla can be found with the software release in 
addition to our previous milestone #1 release at:

http://lists.openstack.org/pipermail/openstack-dev/2014-October/048970.html

Our milestone #3 and beyond will likely focus around tighter integration 
with TripleO.  For more details see:

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


[openstack-dev] [cinder bug commit] How to commit a bug which depends on another bug that have not been merged?

2015-01-06 Thread liuxinguo
Hi all,

* I have commit a bug and it is not yet merged. Now I want to commit 
another bug but this bug is depends on the previousapp:ds:previous one which 
have not been merged?
* So how should I do? Should I commit the latterapp:ds:latter bug 
directly or wait the previousapp:ds:previous bug to be merged?

Any input will be appreciated, thanks!

liu

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


Re: [openstack-dev] [nova][api]do we need to have a spec for all api related changes?

2015-01-06 Thread Alex Xu
2015-01-07 11:43 GMT+08:00 Eli Qiao ta...@linux.vnet.ibm.com:

  hi all:
 I have a patch [1], just did slight changes on api, do I need to write a
 spec(kinds of wasting time to get approved)?
 since api-microversion[2] is almost done, can we just feel free to add
 changes as micro-version api?


We definitely can't 'feel free' to change API even we have micro-version,
special for back-incompatibility change. The spec is for avoid we break the
API accidentally.



 like bump version , write down changes in rest_api_version_history.rst

 [1] https://review.openstack.org/#/c/144914/
 [2]
 https://review.openstack.org/#/q/status:merged+project:openstack/nova+branch:master+topic:bp/api-microversions,n,z

 --
 Thanks,
 Eli (Li Yong) Qiao


 ___
 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] [Keystone] Is anyone working on the following patch?

2015-01-06 Thread Ajaya Agrawal
https://review.openstack.org/#/c/113586/

Two of my patches depend on this patch.
https://review.openstack.org/#/c/113277/
https://review.openstack.org/#/c/110575/


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


Re: [openstack-dev] [api] [sdk] Proposal to achieve consistency in client side sorting

2015-01-06 Thread Rochelle Grober
Steven,

This sounds like a perfect place for a cross project spec.  It wouldn't have to 
be a big one, but all the projects would have a chance to review and the TC 
would oversee to ensure it gets proper review.

TCms, am I on point here?

--Rocky


From: Jay S. Bryant [mailto:jsbry...@electronicjungle.net]
Sent: Tuesday, January 06, 2015 10:41 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [api] [sdk] Proposal to achieve consistency in 
client side sorting

Steven,

Thank you for continuing to pursue this.  Adding this functionality and having 
it consistent will be a good thing.

The plan for Cinder looks good to me and is consistent with Mike and Duncan's 
input.

I look forward to seeing patches for Cinder.

Jay
On 01/06/2015 10:03 AM, Steven Kaufer wrote:

This is a follow up thread to [1]

In order to have consistency across clients, I am proposing that the client 
side sorting has the following syntax: --sort key[:direction]

Where the --sort parameter is comma-separated and is used to specify one or 
more sort keys and directions. The direction defaults to 'desc' for each sort 
key and the user can supply 'asc' to override.

For example:

  nova list --sort display_name
  nova list --sort display_name,vm_state
  nova list --sort display_name:asc,vm_state:asc

If approved, then the following changes are needed for glance and cinder (note 
that nova already uses this syntax):

  Cinder: Deprecate --sort_key and --sort_dir and add support for --sort
  Glance: Modify [2] to this new syntax

I have not verified how all other projects handle sorting, there may be other 
projects that would also need to be changed.

Thoughts?  Objections?

Also, if there is a more formal way to propose/review this standard please let 
me know.

[1] http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg42854.html
[2] https://review.openstack.org/#/c/120777/

Thanks,
Steven Kaufer



___

OpenStack-dev mailing list

OpenStack-dev@lists.openstack.orgmailto: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] [Manila]Rename driver mode

2015-01-06 Thread Li, Chen
Hi list,



After study  https://wiki.openstack.org/wiki/Manila/Kilo_Network_Spec

I’d like to change my proposal.



Since driver mode is actually decide by its network situation, how about:

  static_network_mode

  ⇨ No share server

  ⇨ import share server from other place



  dynamic_network_mode

  ⇨ flat network

  ⇨ segmented network

  o share server at the same subnet of share network

  o share server connect to tenant subnet using router



The usecase would like this:



enabled_backends=generic1,generic2,glusterfs1



[generic1]

driver=manila.share.drivers.generic.GenericShareDriver

mode=dynamic_network_mode

network=network1



[generic2]

driver=manila.share.drivers.generic.GenericShareDriver

mode=static_network_mode

enable_share_server=True

share_server=server1



[glusterfs1]

share_driver = manila.share.drivers.glusterfs.GlusterfsShareDriver

glusterfs_target = manila:/manila-volume0

mode=static_network_mode

enable_share_server=False



[network1]

plugin=manila.network.Neutron

network_type=flat

network=192.168.10.0

netmask=255.255.255.0

gateway=192.168.10.1

ip_range=192.168.10.50-192.168.10.99



[server1]

server_type=nova

is_deletable=False

id=x


From: Li, Chen [mailto:chen...@intel.com]
Sent: Tuesday, December 30, 2014 5:27 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Manila]Rename driver mode

Hi list,

There are two driver modes in manila currently, “multi_svm_mode” and 
“single_svm_mode”.

multi_svm_mode means usage of share-networks that contain network information 
for dynamic creation of share-servers (SVMs).
single_svm_mode means usage of predefined some endpoint, without need to 
provide share-network and without creation of share-servers (SVMs).

Currently, the name of driver mode describes how many servers the driver can 
handle.
For multi, it says that share driver can handle more than one server.
And,  if someone share server is just already exist from share driver, but it 
uses some server anyway with host address, username, password, NFS daemon, 
etc... are defined as works in single_svm mode too.

But, as a new user to manila, these names make me really confusing.
Because I thought the driver mode names describe how drivers works with 
share-servers.
I thought “multi-” and “single-” indicate the number of share-servers would 
been created when we create a share, if we are using the driver.
Obviously, my understanding is wrong.

When we’re working under driver generic, one share-server would be created for 
one share-network.
When we’re working under driver glusterfs, no share-server would be created at 
all.

I believe I would not be the only one who is making this mistake.
To make code more readable, I’d like to suggest to rename driver mode names.

Name them based on behavior but not ability.

I think three driver modes are needed:


-  dynamic_svm_mode :

  Usage of share-networks that contain network 
information for dynamic creation of share-servers (SVMs).

  This is how current generic driver works.

  Under this mode, driver manages share servers 
itself,  and share-server would be created and deleted with related shares.



-  static_svm_mode:   Using pre-create share servers.

  The case as 
https://review.openstack.org/#/c/144342/

  Under this mode, driver do not manage share 
servers, but work with them.



-  no_svm_mode:  the case as driver glusterfs working currently, no 
share-server would be created.


Thanks.
-chen


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


Re: [openstack-dev] [Neutron][L3] Stop agent scheduling without stopping sevices

2015-01-06 Thread Carl Baldwin
Itsuro,

It would be desirable to be able to be hide an agent from scheduling
but no one has stepped up to make this happen.  Come to think of it,
I'm not sure that a bug or blueprint has been filed yet to address it
though it is something that I've wanted for a little while now.

Carl

On Mon, Jan 5, 2015 at 4:13 PM, Itsuro ODA o...@valinux.co.jp wrote:
 Neutron experts,

 I want to stop scheduling to a specific {dhcp|l3}_agent without
 stopping router/dhcp services on it.
 I expected setting admin_state_up of the agent to False is met
 this demand. But this operation stops all services on the agent
 in actuality. (Is this behavior intended ? It seems there is no
 document for agent API.)

 I think admin_state_up of agents should affect only scheduling.
 If it is accepted I will submit a bug report and make a fix.

 Or should I propose a blueprint for adding function to stop
 agent's scheduling without stopping services on it ?

 I'd like to hear neutron experts' suggestions.

 Thanks.
 Itsuro Oda
 --
 Itsuro ODA o...@valinux.co.jp


 ___
 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] [api] [sdk] Proposal to achieve consistency in client side sorting

2015-01-06 Thread Anne Gentle
On Tue, Jan 6, 2015 at 10:03 AM, Steven Kaufer kau...@us.ibm.com wrote:

 This is a follow up thread to [1]

 In order to have consistency across clients, I am proposing that the
 client side sorting has the following syntax: --sort key[:direction]

 Where the --sort parameter is comma-separated and is used to specify one
 or more sort keys and directions. The direction defaults to 'desc' for each
 sort key and the user can supply 'asc' to override.

 For example:

   nova list --sort display_name
   nova list --sort display_name,vm_state
   nova list --sort display_name:asc,vm_state:asc

 If approved, then the following changes are needed for glance and cinder
 (note that nova already uses this syntax):

   Cinder: Deprecate --sort_key and --sort_dir and add support for --sort
   Glance: Modify [2] to this new syntax

 I have not verified how all other projects handle sorting, there may be
 other projects that would also need to be changed.

 Thoughts?  Objections?

 Also, if there is a more formal way to propose/review this standard please
 let me know.

I'm all for consistency. Sounds like a great case for the API Working Group
to document. You can propose a patch describing the way we want sorting to
work.

See https://review.openstack.org/#/q/project:openstack/api-wg,n,z

Anne




 [1]
 http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg42854.html
 [2] https://review.openstack.org/#/c/120777/

 Thanks,
 Steven Kaufer

 ___
 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][all] nova not work with eventlet 0.16.0

2015-01-06 Thread Sylvain Bauza

Maybe we should ask for cap eventlet to 0.15.2 in global-requirements ?

Adding the [all] tag as I think it's cross-project.

-Sylvain


Le 06/01/2015 18:01, Daniel P. Berrange a écrit :

On Tue, Jan 06, 2015 at 05:36:38PM +0100, Ihar Hrachyshka wrote:

On 01/06/2015 05:33 PM, Daniel P. Berrange wrote:

On Tue, Jan 06, 2015 at 10:21:10AM -0600, Matt Riedemann wrote:

Odd...eventlet 0.16.0 was released on 12/30 and the eventlet.util import is
still in the libvirt host module, but this isn't blowing up in the Jenkins
runs, so what's different?  There isn't a version cap on eventlet in
global-requirements either.

When I pip install it in my dev env it still pulls in 0.15.2.

Likewise looking at a jenkins log from today it pulls in 0.15.2

   
http://logs.openstack.org/89/140089/3/check/gate-nova-python27/55b24ee/tox/py27-1.log

But the pypi page refers to 0.16.0

   https://pypi.python.org/pypi/eventlet/

?!?!?


Maybe some external dependency pulls in older version?

Ah, it seems my devpi/wheel caching setup was not seeing the new version.
When I forced a refresh in that, it pulled down 0.16.0 Wonder if the gate
has a similar cache refresh issue

Regards,
Daniel



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


Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0

2015-01-06 Thread Matt Riedemann



On 1/6/2015 6:33 AM, Jay Pipes wrote:

Thanks Eli, please do file a bug on Launchpad with your information below.

Best,
-jay

On 01/06/2015 04:18 AM, Eli Qiao wrote:

hi all ,
I set up nova environment with latest upstream code.
nova-compute can not boot up due to failed to load libvirt driver.
by further debugging. found that eventlet (0.16.0) remove util which is
referenced by libvirt driver.
after I downgrade to (0.15.2) it works.

*0.15.2*

In [3]: print eventlet.__version__
0.15.2

In [5]: import eventlet.util

In [6]:

-

*0.16.0**
*

In [1]: import eventlet.util
---

ImportError   Traceback (most recent call
last)
ipython-input-1-a23626d6f273 in module()
 1 import eventlet.util

ImportError: No module named util

In [3]: import eventlet

In [4]: print eventlet.__version__
0.16.0

In [5]:




In [1]: import nova.virt.libvirt.LibvirtDriver
---

ImportError   Traceback (most recent call
last)
ipython-input-1-2bdce28fc3dd in module()
 1 import nova.virt.libvirt.LibvirtDriver

/opt/stack/nova/nova/virt/libvirt/__init__.py in module()
  13 #under the License.
  14
--- 15 from nova.virt.libvirt import driver
  16
  17 LibvirtDriver = driver.LibvirtDriver

/opt/stack/nova/nova/virt/libvirt/driver.py in module()
  96 from nova.virt.libvirt import dmcrypt
  97 from nova.virt.libvirt import firewall as libvirt_firewall
--- 98 from nova.virt.libvirt import host
  99 from nova.virt.libvirt import imagebackend
 100 from nova.virt.libvirt import imagecache

/opt/stack/nova/nova/virt/libvirt/host.py in module()
  37 from eventlet import patcher
  38 from eventlet import tpool
--- 39 from eventlet import util as eventlet_util
  40
  41 from nova import exception

ImportError: cannot import name util

In [2]: import eventlet

In [3]: from eventlet import util
---

ImportError   Traceback (most recent call
last)
ipython-input-3-f6f91e4749eb in module()
 1 from eventlet import util

ImportError: cannot import name util

In [4]:

--
Thanks,
Eli (Li Yong) Qiao



___
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



Odd...eventlet 0.16.0 was released on 12/30 and the eventlet.util import 
is still in the libvirt host module, but this isn't blowing up in the 
Jenkins runs, so what's different?  There isn't a version cap on 
eventlet in global-requirements either.


--

Thanks,

Matt Riedemann


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


[openstack-dev] [Telco] [NFV] Service function chaining

2015-01-06 Thread Yuriy.Babenko
Hi all, 

as discussed per last IRC meeting we prepared first thoughts on the 
requirements on Service Function Chaining (SFC) and relevant use-case. 

We have an etherpad for initial draft ideas. Later on we should move it to 
wiki. 

All comments are very welcome. 

https://etherpad.openstack.org/p/kKIqu2ipN6

Best, 
Yuriy 
Deutsche Telekom 

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


[openstack-dev] [nova] local and gate pep8 check comparsion

2015-01-06 Thread Chen CH Ji

I got following error in patch https://review.openstack.org/#/c/137009/
from Jenkins

2015-01-06 12:24:20.445 | ./nova/compute/manager.py:5325:13: N331  Use
LOG.warning due to compatibility with py3
2015-01-06 12:24:20.445 | ./nova/compute/manager.py:5726:13: N331  Use
LOG.warning due to compatibility with py3
2015-01-06 12:24:20.916 | ERROR: InvocationError:
'/home/jenkins/workspace/gate-nova-pep8/.tox/pep8/bin/flake8'

but I didn't get it either by ./run_test.sh -8 or tox -e pep8 in my local
test env, I am pretty sure I have the latest nova code so I think I should
get same result ?

Thanks a lot

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] pip 6.0.6 breaking py2* jobs - bug 1407736

2015-01-06 Thread Matt Riedemann



On 1/6/2015 7:27 AM, Ihar Hrachyshka wrote:


On 01/06/2015 03:09 AM, Matt Riedemann wrote:



On 1/5/2015 2:16 PM, Doug Hellmann wrote:


On Jan 5, 2015, at 12:22 PM, Doug Hellmann d...@doughellmann.com
wrote:



On Jan 5, 2015, at 12:00 PM, Matt Riedemann
mrie...@linux.vnet.ibm.com wrote:


There is a deprecation warning in pip 6.0.6 which is making the
py26 (on stable branches) and py27 jobs hit subunit log sizes of
over 50 MB which makes the job fail.

A logstash query shows this started happening around 1/3 which is
when pip 6.0.6 was released. In Nova alone there are nearly 18
million hits of the deprecation warning.

Should we temporarily block so that pip  6.0.6?

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


I think this is actually a change in pkg_resources (in the
setuptools dist) [1], being triggered by stevedore using
require=False to avoid checking dependencies when plugins are loaded.

Doug

[1]
https://bitbucket.org/pypa/setuptools/commits/b1c7a311fb8e167d026126f557f849450b859502



After some discussion with Jason Coombs and dstufft, a version of
setuptools with a split API to replace the deprecated option was
released. I have a patch up to teach stevedore about the new methods[1].

Doug

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






--

Thanks,

Matt Riedemann


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



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



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



The stevedore patch was merged. Do we need a release of stevedore and
a global-requirements update to then get the deprecation warnings
fixed in nova (on master and stable/juno)?



I guess so. Also, Icehouse is affected too. I've checked Nova
requirements.txt for Icehouse, and we don't cap steverore version, so a
new release will be automatically propagated to all new jobs.

/Ihar

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



I've closed the nova bug as a duplicate of the stevedore bug since the 
latest release of stevedore fixed the problem for my nova change on 
stable/juno, thanks Doug!


--

Thanks,

Matt Riedemann


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


Re: [openstack-dev] [nova][all] nova not work with eventlet 0.16.0

2015-01-06 Thread Sylvain Bauza


Le 06/01/2015 19:25, Sylvain Bauza a écrit :

Maybe we should ask for cap eventlet to 0.15.2 in global-requirements ?




My bad, there is already a change https://review.openstack.org/#/c/145023/

-S


Adding the [all] tag as I think it's cross-project.

-Sylvain


Le 06/01/2015 18:01, Daniel P. Berrange a écrit :

On Tue, Jan 06, 2015 at 05:36:38PM +0100, Ihar Hrachyshka wrote:

On 01/06/2015 05:33 PM, Daniel P. Berrange wrote:

On Tue, Jan 06, 2015 at 10:21:10AM -0600, Matt Riedemann wrote:
Odd...eventlet 0.16.0 was released on 12/30 and the eventlet.util 
import is
still in the libvirt host module, but this isn't blowing up in the 
Jenkins

runs, so what's different?  There isn't a version cap on eventlet in
global-requirements either.

When I pip install it in my dev env it still pulls in 0.15.2.

Likewise looking at a jenkins log from today it pulls in 0.15.2

http://logs.openstack.org/89/140089/3/check/gate-nova-python27/55b24ee/tox/py27-1.log

But the pypi page refers to 0.16.0

   https://pypi.python.org/pypi/eventlet/

?!?!?


Maybe some external dependency pulls in older version?
Ah, it seems my devpi/wheel caching setup was not seeing the new 
version.
When I forced a refresh in that, it pulled down 0.16.0 Wonder if the 
gate

has a similar cache refresh issue

Regards,
Daniel



___
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] [api] [sdk] Proposal to achieve consistency in client side sorting

2015-01-06 Thread Jay S. Bryant

Steven,

Thank you for continuing to pursue this.  Adding this functionality and 
having it consistent will be a good thing.


The plan for Cinder looks good to me and is consistent with Mike and 
Duncan's input.


I look forward to seeing patches for Cinder.

Jay

On 01/06/2015 10:03 AM, Steven Kaufer wrote:


This is a follow up thread to [1]

In order to have consistency across clients, I am proposing that the 
client side sorting has the following syntax: --sort key[:direction]


Where the --sort parameter is comma-separated and is used to specify 
one or more sort keys and directions. The direction defaults to 'desc' 
for each sort key and the user can supply 'asc' to override.


For example:

  nova list --sort display_name
  nova list --sort display_name,vm_state
  nova list --sort display_name:asc,vm_state:asc

If approved, then the following changes are needed for glance and 
cinder (note that nova already uses this syntax):


  Cinder: Deprecate --sort_key and --sort_dir and add support for --sort
  Glance: Modify [2] to this new syntax

I have not verified how all other projects handle sorting, there may 
be other projects that would also need to be changed.


Thoughts?  Objections?

Also, if there is a more formal way to propose/review this standard 
please let me know.


[1] 
http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg42854.html

[2] https://review.openstack.org/#/c/120777/

Thanks,
Steven Kaufer


___
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] [Octavia] Questions about the Octavia project

2015-01-06 Thread Andrew Hutchings
Hi,

I’m looking into the Octavia project in relation to something my team are 
working on inside HP and I have a bunch of questions.  I realise it is early 
days for the project and some of these could be too low level at this time.

Some of these questions come from the fact that I could not get the 
documentation to compile and the docs site for Octavia is down.  The 
v0.5-component-design.dot file crashes Graphviz 2.38 in every OS I tried and 
unfortunately all my dev machines have that version or 2.36 which is too low to 
render it correctly.  It also requires at least 5 extra dependencies (Sphinx 
modules) to build the docs but doesn’t try to install them.

I’ll guess I’ll start from the most obvious question:

1. Octavia looks a lot like Libra but with integration into Neutron and 
Barbican (both were planned for Libra) as well as few other changes.  So the 
most obvious question is: why not just develop Libra for integration with 
Neutron?

Amphorae stuff:

2. I see a lot of building blocks for the controller and Amphorae but not a lot 
about communication.  What protocol / method is to be used to communicate to 
the Amphorae instances?
3. How are Amphorae instances to be spun up on-demand?  I see a reference to 
Heat but not sure if that is why it is there
4. There is mention of Docker in some of the deploy scripts.  Is this for 
multi-tenancy or just separation of the Amphorae processes?
5. I take it Amphorae is designed to be single-AZ for now?

Load Balancing:

6. It seems like you are going to have SSL termination support and are going to 
use HAProxy, which means that you will have unencrypted data between the LB and 
web servers.  How do you plan to work around this problem?

Security:

7. Someone in the specification there is talk of a 1 minute cache of security 
certificates.  How are you going to ensure that the cache will actually erase 
that cache after the 1 minute?  Also why cache them at all?  It seems to me to 
be a potential security risk

API:

8. More a comment than a question.  There is talk of using Pecan+WSME.  Libra 
had a 5K patch on top of WSME just to make it behave correctly with Pecan and 
correct JSON specifications in certain situations, judging by the planned API 
you will also hit those same situations.  I admit I’ve not looked at WSME for a 
year and there was an effort to strip it out of Libra completely at one point.  
So that one is mainly my 2c :)

Many thanks for your time.

Kind Regards
--
Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/





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


[openstack-dev] [oslo] Progress of the port to Python 3

2015-01-06 Thread victor stinner
Hi,

I'm still working on porting OpenStack to Python 3. I'm fixing Python 3 issues 
in eventlet and I'm trying to replace eventlet with trollius in OpenStack. Two 
different and complementary ways to port OpenStack to Python 3.


I fixed some eventlet issues related to Python 3 and monkey-patching. My 
changes are part of eventlet 0.16 which was released the 2014-12-30. I tried 
this version with Oslo Messaging: with another fix in eventlet 
(threading.Condition) and a change in the zmq driver, only 3 tests are now 
failing (which is a great success for me).

See my Oslo Messaging change for more information:
https://review.openstack.org/#/c/145241/

It looks like eventlet 0.16 works much better with Python 3 and 
monkey-patching. You should try it on your own project! Tell me if you need 
help to fix issues.

--

About asyncio, I renamed my aiogreen project to aioeventlet (to make it 
more explicit that it is specific to eventlet). With the release 0.4, the API 
is now considered as stable.
http://aioeventlet.readthedocs.org/

Mehdi Abaakouk voted +2 on my Oslo Messaging patches to support trollius 
coroutines using aioeventlet project, but it looks that he's alone to review 
Oslo Messaging patches :-/ Anyway to approve my changes?

* Add an optional executor callback to dispatcher
  https://review.openstack.org/136652
* Add a new aioeventlet executor
  https://review.openstack.org/136653

By the way, my review to add aioeventlet dependency also waits for a review:

* Add aioeventlet dependency
  https://review.openstack.org/138750

Victor Stinner

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


[openstack-dev] [api] [sdk] Proposal to achieve consistency in client side sorting

2015-01-06 Thread Steven Kaufer


This is a follow up thread to [1]

In order to have consistency across clients, I am proposing that the client
side sorting has the following syntax: --sort key[:direction]

Where the --sort parameter is comma-separated and is used to specify one or
more sort keys and directions. The direction defaults to 'desc' for each
sort key and the user can supply 'asc' to override.

For example:

  nova list --sort display_name
  nova list --sort display_name,vm_state
  nova list --sort display_name:asc,vm_state:asc

If approved, then the following changes are needed for glance and cinder
(note that nova already uses this syntax):

  Cinder: Deprecate --sort_key and --sort_dir and add support for --sort
  Glance: Modify [2] to this new syntax

I have not verified how all other projects handle sorting, there may be
other projects that would also need to be changed.

Thoughts?  Objections?

Also, if there is a more formal way to propose/review this standard please
let me know.

[1]
http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg42854.html
[2] https://review.openstack.org/#/c/120777/

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


Re: [openstack-dev] [nova] local and gate pep8 check comparsion

2015-01-06 Thread Matt Riedemann



On 1/6/2015 10:21 AM, Chen CH Ji wrote:

I got following error in patch
https://review.openstack.org/#/c/137009/ from Jenkins

_2015-01-06 12:24:20.445_
http://logs.openstack.org/09/137009/2/check/gate-nova-pep8/b868ad8/console.html#_2015-01-06_12_24_20_445
 |
./nova/compute/manager.py:5325:13: N331  Use LOG.warning due to
compatibility with py3
_2015-01-06 12:24:20.445_
http://logs.openstack.org/09/137009/2/check/gate-nova-pep8/b868ad8/console.html#_2015-01-06_12_24_20_445
 |
./nova/compute/manager.py:5726:13: N331  Use LOG.warning due to
compatibility with py3
_2015-01-06 12:24:20.916_
http://logs.openstack.org/09/137009/2/check/gate-nova-pep8/b868ad8/console.html#_2015-01-06_12_24_20_916
 |
ERROR: InvocationError:
'/home/jenkins/workspace/gate-nova-pep8/.tox/pep8/bin/flake8'

but I didn't get it either by ./run_test.sh -8 or tox -e pep8 in my
local test env, I am pretty sure I have the latest nova code so I think
I should get same result ?

Thanks a lot

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
District, Beijing 100193, PRC


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



Stale venv?  Try tox -r -e pep8.

--

Thanks,

Matt Riedemann


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


Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0

2015-01-06 Thread Ihar Hrachyshka

On 01/06/2015 05:33 PM, Daniel P. Berrange wrote:

On Tue, Jan 06, 2015 at 10:21:10AM -0600, Matt Riedemann wrote:

Odd...eventlet 0.16.0 was released on 12/30 and the eventlet.util import is
still in the libvirt host module, but this isn't blowing up in the Jenkins
runs, so what's different?  There isn't a version cap on eventlet in
global-requirements either.

When I pip install it in my dev env it still pulls in 0.15.2.

Likewise looking at a jenkins log from today it pulls in 0.15.2

   
http://logs.openstack.org/89/140089/3/check/gate-nova-python27/55b24ee/tox/py27-1.log

But the pypi page refers to 0.16.0

   https://pypi.python.org/pypi/eventlet/

?!?!?

Regards,
Daniel


Maybe some external dependency pulls in older version?

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


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

2015-01-06 Thread Christopher Aedo
On Tue, Jan 6, 2015 at 2:49 AM, Flavio Percoco fla...@redhat.com wrote:
 Fully agree... I don't see how enable logging should be a limitation
 for freedom of thought. We've used it in Zaqar since day 0 and it's
 bee of great help for all of us.

 The logging does not remove the need of meetings where decisions and
 more relevant/important topics are discussed.

Wanted to second this as well.  I'm strongly in favor of logging -
looking through backlogs of chats on other channels has been very
helpful to me in the past, and it sure to help others in the future.
I don't think there is danger of anyone pointing to a logged IRC
conversation in this context as some statement of record.

-Christopher

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


Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0

2015-01-06 Thread Daniel P. Berrange
On Tue, Jan 06, 2015 at 10:21:10AM -0600, Matt Riedemann wrote:
 Odd...eventlet 0.16.0 was released on 12/30 and the eventlet.util import is
 still in the libvirt host module, but this isn't blowing up in the Jenkins
 runs, so what's different?  There isn't a version cap on eventlet in
 global-requirements either.

When I pip install it in my dev env it still pulls in 0.15.2.

Likewise looking at a jenkins log from today it pulls in 0.15.2

  
http://logs.openstack.org/89/140089/3/check/gate-nova-python27/55b24ee/tox/py27-1.log

But the pypi page refers to 0.16.0

  https://pypi.python.org/pypi/eventlet/

?!?!?

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

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


Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0

2015-01-06 Thread Daniel P. Berrange
On Tue, Jan 06, 2015 at 05:36:38PM +0100, Ihar Hrachyshka wrote:
 On 01/06/2015 05:33 PM, Daniel P. Berrange wrote:
 On Tue, Jan 06, 2015 at 10:21:10AM -0600, Matt Riedemann wrote:
 Odd...eventlet 0.16.0 was released on 12/30 and the eventlet.util import is
 still in the libvirt host module, but this isn't blowing up in the Jenkins
 runs, so what's different?  There isn't a version cap on eventlet in
 global-requirements either.
 When I pip install it in my dev env it still pulls in 0.15.2.
 
 Likewise looking at a jenkins log from today it pulls in 0.15.2
 

  http://logs.openstack.org/89/140089/3/check/gate-nova-python27/55b24ee/tox/py27-1.log
 
 But the pypi page refers to 0.16.0
 
https://pypi.python.org/pypi/eventlet/
 
 ?!?!?
 
 Maybe some external dependency pulls in older version?

Ah, it seems my devpi/wheel caching setup was not seeing the new version.
When I forced a refresh in that, it pulled down 0.16.0 Wonder if the gate
has a similar cache refresh issue

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] [horizon] static files handling, bower/

2015-01-06 Thread Lin Hua Cheng
Radomir,

The current version of Angular were using in Horizon still does not have
cookie and mock packages:
https://github.com/stackforge/xstatic-angular/tree/1.2.1.1/xstatic/pkg/angular/data

We still need to do it the long way:
1. Update the Angular version in global-requirements
2. Wait till it gets merge and propagate to horizon requirements
3. Remove references loading of mock and cookie packages in horizon and
horizon requirement
4. Remove mock and cookie from global-requirements.

-Lin

On Tue, Jan 6, 2015 at 1:00 AM, Radomir Dopieralski openst...@sheep.art.pl
wrote:

 On 06/01/15 01:39, Tripp, Travis S wrote:
  What Radomir proposes looks like it would greatly ease the process I am
 still going through to get the latest angular available to Horizon for
 current development.  At the time of writing this, I’m still trying to get
 the updated library through.  I hit a rather difficult workflow:
 
 
1.  Packaged the latest into Xstatic-Angular-1.3.7
2.  Submitted patch which deprecated the separate older
 xstatic-angular-cookies and xstatic-angular-mock packages
3.  Reviewed and approved (after correcting an initial mis-repackaging)
4.  Radomir released to Pypi
 
  This was pretty easy and not too hard. Not too much to complain about.
 
  However, now, to get Horizon to use it, I have to get that into global
 requirements.  Since I’m deprecating old packages I got stuck in a sort of
 ugly dependency path.  I couldn’t remove the cookies and mock libraries
 from the global requirements patch that added the new 1.3.7 package because
 of horizon still referencing the deprecated packages.  And, when I did it
 anyway, the integration tests failed due to horizon being dependent on
 something not in global requirements.  So, now, as far as I can tell we
 have to jump through the following hoops:
 
 
1.  Global requirements patch to add angular 1.3.7
   *   Verify check / recheck fun
   *   Reviewed and approved
   *   Gate check / recheck fun
2.  Horizon patch to update to angular 1.3.7 and remove deprecated
 mock and cookies packages
   *   Verify check / recheck fun
   *   Reviewed and approved
   *   Gate check / recheck fun
3.  Global requirements patch to remove deprecated mock and cookies
   *   Verify check / recheck fun
   *   Reviewed and approved
   *   Gate check / recheck fun
 
  Don’t get me wrong, I really do think the gate is brilliant and am all
 for a review / approval process, but this does seem excessive for a UI
 library that should only be used by Horizon. Is there some other reason
 that this should have to go through global requirements?

 You can do it much easier, since the current version of Angular already
 packages what is in the deprecated modules. So just:

 1. Patch Horizon to remove the xstatic dependencies to the mock and
 cookies packages.
 2. Patch global-requirements to remove them, and add newer Angular.
 3. Patch Horizon to use the newer Angular.

 --
 Radomir Dopieralski

 ___
 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] static files handling, bower/

2015-01-06 Thread Tripp, Travis S
Thanks, Radomir.

I originally started a patch on Horizon and was going to do that, but was
guided to update global requirements first.

I¹ll go ahead and redo that patch on Horizon.

-Travis

On 1/6/15, 2:00 AM, Radomir Dopieralski openst...@sheep.art.pl wrote:

On 06/01/15 01:39, Tripp, Travis S wrote:
 What Radomir proposes looks like it would greatly ease the process I am
still going through to get the latest angular available to Horizon for
current development.  At the time of writing this, I¹m still trying to
get the updated library through.  I hit a rather difficult workflow:
 
 
   1.  Packaged the latest into Xstatic-Angular-1.3.7
   2.  Submitted patch which deprecated the separate older
xstatic-angular-cookies and xstatic-angular-mock packages
   3.  Reviewed and approved (after correcting an initial
mis-repackaging)
   4.  Radomir released to Pypi
 
 This was pretty easy and not too hard. Not too much to complain about.
 
 However, now, to get Horizon to use it, I have to get that into global
requirements.  Since I¹m deprecating old packages I got stuck in a sort
of ugly dependency path.  I couldn¹t remove the cookies and mock
libraries from the global requirements patch that added the new 1.3.7
package because of horizon still referencing the deprecated packages.
And, when I did it anyway, the integration tests failed due to horizon
being dependent on something not in global requirements.  So, now, as
far as I can tell we have to jump through the following hoops:
 
 
   1.  Global requirements patch to add angular 1.3.7
  *   Verify check / recheck fun
  *   Reviewed and approved
  *   Gate check / recheck fun
   2.  Horizon patch to update to angular 1.3.7 and remove deprecated
mock and cookies packages
  *   Verify check / recheck fun
  *   Reviewed and approved
  *   Gate check / recheck fun
   3.  Global requirements patch to remove deprecated mock and cookies
  *   Verify check / recheck fun
  *   Reviewed and approved
  *   Gate check / recheck fun
 
 Don¹t get me wrong, I really do think the gate is brilliant and am all
for a review / approval process, but this does seem excessive for a UI
library that should only be used by Horizon. Is there some other reason
that this should have to go through global requirements?

You can do it much easier, since the current version of Angular already
packages what is in the deprecated modules. So just:

1. Patch Horizon to remove the xstatic dependencies to the mock and
cookies packages.
2. Patch global-requirements to remove them, and add newer Angular.
3. Patch Horizon to use the newer Angular.

-- 
Radomir Dopieralski

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


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


Re: [openstack-dev] oslo.i18n 1.2.0 release

2015-01-06 Thread Doug Hellmann
This release is causing problems with some of Heat’s WSGI code that accesses 
private classes in oslo.i18n. We’re working on a fix: 
https://review.openstack.org/#/c/145257


 On Jan 6, 2015, at 10:15 AM, Doug Hellmann d...@doughellmann.com wrote:
 
 The Oslo team is pleased to announce the release of
 oslo.i18n 1.2.0: oslo.i18n library
 
 The primary reason for this release is to move the code
 out of the oslo namespace package as part of
 https://blueprints.launchpad.net/oslo-incubator/+spec/drop-namespace-packages
 
 For more details, please see the git log history below and
 http://launchpad.net/oslo.i18n/+milestone/1.2.0
 
 Please report issues through launchpad:
 http://bugs.launchpad.net/oslo.i18n
 
 
 
 Changes in openstack/oslo.i18n  1.1.0..1.2.0
 
 582c718 Correct the translation domain for loading messages
 ba05e9a Move out of the oslo namespace package
 c86629e Workflow documentation is now in infra-manual
 53635ea Force code sample to be treated as python
 
  diffstat (except docs and test files):
 
 CONTRIBUTING.rst|   7 +-
 oslo/i18n/__init__.py   |  23 +-
 oslo/i18n/_factory.py   | 110 --
 oslo/i18n/_gettextutils.py  |  90 -
 oslo/i18n/_i18n.py  |  25 --
 oslo/i18n/_lazy.py  |  38 --
 oslo/i18n/_locale.py|  25 --
 oslo/i18n/_message.py   | 167 -
 oslo/i18n/_translate.py |  73 
 oslo/i18n/fixture.py|  54 +--
 oslo/i18n/log.py|  86 +
 oslo_i18n/__init__.py   |  16 +
 oslo_i18n/_factory.py   | 110 ++
 oslo_i18n/_gettextutils.py  |  90 +
 oslo_i18n/_i18n.py  |  25 ++
 oslo_i18n/_lazy.py  |  38 ++
 oslo_i18n/_locale.py|  25 ++
 oslo_i18n/_message.py   | 167 +
 oslo_i18n/_translate.py |  73 
 oslo_i18n/fixture.py|  65 
 oslo_i18n/log.py|  97 ++
 setup.cfg   |   2 +-
 tests/fakes.py  |  59 
 tests/test_factory.py   |  91 -
 tests/test_fixture.py   |   2 +-
 tests/test_gettextutils.py  | 128 ---
 tests/test_handler.py   |   4 +-
 tests/test_lazy.py  |  40 ---
 tests/test_locale_dir_variable.py   |  32 --
 tests/test_logging.py   |  42 ---
 tests/test_message.py   | 518 
 tests/test_public_api.py|   2 +-
 tests/test_translate.py |  44 ---
 tests/test_warning.py   |  61 
 tests/utils.py  |  42 ---
 tox.ini |   2 +-
 52 files changed, 2004 insertions(+), 1699 deletions(-)
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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


Re: [openstack-dev] [oslo] Progress of the port to Python 3

2015-01-06 Thread Jordan Pittier
Hi Victor.

Thanks for your effort. Did you read the ML thread [nova]nova not work
with eventlet 0.16.0 ? It looks important.

Jordan

On Tue, Jan 6, 2015 at 5:51 PM, victor stinner victor.stin...@enovance.com
wrote:

 Hi,

 I'm still working on porting OpenStack to Python 3. I'm fixing Python 3
 issues in eventlet and I'm trying to replace eventlet with trollius in
 OpenStack. Two different and complementary ways to port OpenStack to Python
 3.


 I fixed some eventlet issues related to Python 3 and monkey-patching. My
 changes are part of eventlet 0.16 which was released the 2014-12-30. I
 tried this version with Oslo Messaging: with another fix in eventlet
 (threading.Condition) and a change in the zmq driver, only 3 tests are now
 failing (which is a great success for me).

 See my Oslo Messaging change for more information:
 https://review.openstack.org/#/c/145241/

 It looks like eventlet 0.16 works much better with Python 3 and
 monkey-patching. You should try it on your own project! Tell me if you need
 help to fix issues.

 --

 About asyncio, I renamed my aiogreen project to aioeventlet (to make
 it more explicit that it is specific to eventlet). With the release 0.4,
 the API is now considered as stable.
 http://aioeventlet.readthedocs.org/

 Mehdi Abaakouk voted +2 on my Oslo Messaging patches to support trollius
 coroutines using aioeventlet project, but it looks that he's alone to
 review Oslo Messaging patches :-/ Anyway to approve my changes?

 * Add an optional executor callback to dispatcher
   https://review.openstack.org/136652
 * Add a new aioeventlet executor
   https://review.openstack.org/136653

 By the way, my review to add aioeventlet dependency also waits for a
 review:

 * Add aioeventlet dependency
   https://review.openstack.org/138750

 Victor Stinner

 ___
 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