date:20150817

Hi,

I can't find any way to change the image size of the vm used for testing
(it's been created using nodepool-dib and managed by nodepoold).

Anyway, tests are still (randomly) failing with lvm error (Volume group
stack-volumes-lvmdriver-1 has insufficient free space (1023 extents):
1024 required.\n')

Any idea how to fix this?

Thanks,

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

[openstack-dev] [neutron][vmware][stable] vmware-nsx has no releases

2015-08-17 Thread Ihar Hrachyshka

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi VmWare folks,

I wonder whether we can get some actual release tags for stable/kilo
branch of the repo. Lack of any consumable tarballs does not help
packagers that want to just get the tarball from pypi and use it as a
base.

I tried to follow the dumb way of generating a tarball from github,
but pbr complains about lack of sdist or git when I call to 'setup.py
build'. Putting egg-info directory inside the tarball does not help.

I think it would be better for everyone if tags and tarballs came from
upstream.

I suspect other spinned-out neutron drivers could have the same
problem. Can we somehow make sure they are releasing deliverables and
not just git repo?

Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJV0c4PAAoJEC5aWaUY1u57M2cIALuH2MByojn7N1byCV4ctTal
NPsUTgFyzDEXSU1QSgobR6x1uP8hYBW2RSUqnh4tR+SoYz/vmF1IvwXl53tb3Jnq
4MTwXbom3xPgjUYsUep5TAhPglMXf4LwnTYejhqc78IOlNg7tAC0U/yA2ZitFhm2
5zWsec1zggsku4aIMCz06bFwgQHwYl57uHBB/iqO+fbRIGZLkcGrbjiucKIlQqsF
uv9GoymuwOEVjmTtooQBoVQ0J2f/yZYswcRBExbJU78eIP89+A2kDL9nA4fFFhCl
b5Yus6oJDn/XMaU8PWZ8TptWEOY3Z80wbCRZk27FNObSb6yLs+2ZS7Rge+ZCz5s=
=VP83
-END PGP SIGNATURE-

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

Re: [openstack-dev] [tricircle]Tricircle Liberty Midcycle Minisprint on Aug 17th 2015

2015-08-17 Thread Zhipeng Huang

Hi Team,

Thanks for attending the meeting and had a lively discussion on L2GW,
please find in the attachment for the meeting log.

Be noted that we will have the 2nd part of the meeting next Monday at the
same time. :)

On Mon, Aug 17, 2015 at 10:16 AM, Zhipeng Huang zhipengh...@gmail.com
wrote:

 Hi All,

 Joe has suggested to move the meeting earlier to UTC 0800, if there is no
 problem then we will have the meeting in about 6 hours :)

 On Fri, Aug 14, 2015 at 9:26 AM, Zhipeng Huang zhipengh...@gmail.com
 wrote:

 Hi Team,

 As discussed in the last meeting, we will hold a design sprint meeting on
 next Monday starting from UTC 1200 to discuss exclusively design problems
 and ideas. The meeting will happen at #openstack-tricircle so that we could
 discuss as long as we are awake without time limits :P

 The meeting info could be found at
 https://wiki.openstack.org/wiki/Meetings/Tricircle, please reply any
 topic you want to add to the agenda

 --
 Zhipeng (Howard) Huang

 Standard Engineer
 IT Standard  Patent/IT Prooduct Line
 Huawei Technologies Co,. Ltd
 Email: huangzhip...@huawei.com
 Office: Huawei Industrial Base, Longgang, Shenzhen

 (Previous)
 Research Assistant
 Mobile Ad-Hoc Network Lab, Calit2
 University of California, Irvine
 Email: zhipe...@uci.edu
 Office: Calit2 Building Room 2402

 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado




 --
 Zhipeng (Howard) Huang

 Standard Engineer
 IT Standard  Patent/IT Prooduct Line
 Huawei Technologies Co,. Ltd
 Email: huangzhip...@huawei.com
 Office: Huawei Industrial Base, Longgang, Shenzhen

 (Previous)
 Research Assistant
 Mobile Ad-Hoc Network Lab, Calit2
 University of California, Irvine
 Email: zhipe...@uci.edu
 Office: Calit2 Building Room 2402

 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado




-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard  Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado


Tricircle Liberty Midcycle.docx
Description: MS-Word 2007 document
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-deb] Devstack stable/juno fails to install

Hi,

It doesn't seem to help, install still fails with same error.

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

Re: [openstack-dev] [cinder] [third-party] ProphetStor CI account

HI Abhishek:

For you information in the below.

HI Mike:

What I have missed it?

On Mon, Aug 17, 2015 at 8:52 PM, Rick Chen rick.c...@prophetstor.com
mailto:rick.c...@prophetstor.com wrote:

HI Mike:
I completed to refine our CI configuration to follow Ramy's
comments. Does any missed or other attention I need respect?

[1] Add export DEVSTACK_GATE_TEMPEST_REGEX=volume to verify all
cinder volume testing.
[2] Add each service configuration in the log.

http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds
http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-dsvm-tempest-cinder-ci/5100/logs/etc/

vm-tempest-cinder-ci/5100/logs/etc/
[3] Add email alert when the devstack build failed to instead of you
notify to me.

Can you please tell me that how

you have done the [3].

Use Jenkins email E-mail Notification.

Manage Jenkins Configure System E-mail Notification

Add SMTP server and Default user e-mail suffix. Use advanced
button to verify email seting.

Add Email notification in you job.

CI job “Add post-build action” “Email Notification”
add Recipients.

Reference link:
https://www.safaribooksonline.com/library/view/jenkins-the-definitive/9781449311155/ch08s02.html

[4] Integrate VMware snapshot revert feature in the Jenkins master
to clean CI slave machine OS environment that avoid the devstack building
failed due to previous devstack garbage configuration.

Also, the process of CI slave snapshot revert mentioned in [4].

Add Jenkins plugin agent: vSphere Cloud Plugin

Configure vSphere Cloud in Jenkins master.

Manage Jenkins Configure System vSphere Cloud

Add vSphere hose, user name, password.

Configure vSphere Slave.

Add slave node and select “Slave virtual computer running under
vSphere Cloud”

Manage Jenkins Manage Nodes New node select “Slave virtual
computer running under vSphere Cloud”

Add your vSphere information in this configuration page.

Reference link:
https://wiki.jenkins-ci.org/display/JENKINS/vSphere+Cloud+Plugin

[5] Latest CI result for you reference.

http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds
http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-dsvm-tempest-cinder-ci/5100/logs/

vm-tempest-cinder-ci/5100/logs/
http://download.prophetstor.com/prophetstor_ci/

[6] Logs need to be browsable online.
Add Rewrite module and rule in the apache configuration.

my gerrit account: prophetstor-ci
gerrit account email:prophetstor...@prophetstor.com
mailto:prophetstor...@prophetstor.com

Many thanks.

https://docs.google.com/uc?export=downloadid=0Byq0j7ZjFlFKV3ZCWnlMRXBCcU0revid=0Byq0j7ZjFlFKa2V5VjdBSjIwUGx6bUROS2IrenNwc0kzd2IwPQ

Thanks Regards,

Abhishek

Cloudbyte Inc. http://www.cloudbyte.com

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

Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities

2015-08-17 Thread Adam Young


On 08/15/2015 01:15 PM, Michael Krotscheck wrote:


On Fri, Aug 14, 2015 at 2:26 PM Adam Young ayo...@redhat.com 
mailto:ayo...@redhat.com wrote:


On 08/14/2015 12:43 PM, Michael Krotscheck wrote:
 1- Do users want to page through search results?
Does not matter:  in Federation, the User list is not available.


Let's back up here for a sec: A user wants to page a list of data. 
This is something horizon needs, traditionally relying on keystone, 
and now keystone has broken backwards compatibility for horizon 
because of one use case, without taking responsibility for it and 
providing (with code) a good alternative. Furthermore, you and your 
team are saying You should go use a different service that's better 
at this, which is basically saying We live in this silo, we don't 
have to care about other silo's.


NO.  What we are saying is you are asking for infromation in a away that 
the technoliogies that OpenStack is pulling together cannot support.




You broke backwards compatibility. It's your responsibility to address it.


No. The world moved on.


Keystone pagination in SQL is trivial.  It is also useless.

LDAP does not support paging.  The majority of the deployments us LDAP 
for the back end.


In as SAML/OpenID deployment there is no way to list users.





The other argument I'm hearing here is that keystone is responsible 
for authentication and authorization, but not user management. I 
actually agree with this, but nobody's started a user management 
service and/or its delegation plugins, so now we have a rather large 
hole in horizon's features, late in a release cycle, and nobody has 
the resources to address it. What do you propose to do about it?


We don't maintain MySQL, either.  Use an external tool for user 
management. There are numerous, and OpenStack can integrate with them 
via LDAP or SAML.   Other technologies coming soon, too.




Michael



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


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

Re: [openstack-dev] [Neutron] revert default review branch to master

On 2015-08-17 22:39:56 + (+), Mooney, Sean K wrote:
[...]
 Assuming this was not intentional I have opened a bug and
 submitted a patch to revert this change.
[...]

Fix https://review.openstack.org/213843 is already winding its way
through the sausage factory.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [pbr] [stable] [infra] How to generate .Z version increments on stable/liberty commits

2015-08-17 Thread Alan Pevec

 The only alternative seems to be to have on-demand stable-branch
 tagging. The main drawbacks of that option are that consumers of the
 stable branch are unnecessarily limited to specific tagged commits, and
 depend on various project teams to remember to push them.

As Doug suggested,  stable releases would be triggered by submitting a
patch to the releases
repository, so maybe we could be auto-generating release proposals
periodically (monthly, weekly?) as a reminder to the team if there
hasn't been a release in that period?
Also OSSA merge could trigger an async release proposal too.

Cheers,
Alan

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

Re: [openstack-dev] [Neutron] revert default review branch to master

On Mon, Aug 17, 2015 at 5:58 PM, Jeremy Stanley fu...@yuggoth.org wrote:

 On 2015-08-17 22:39:56 + (+), Mooney, Sean K wrote:
 [...]
  Assuming this was not intentional I have opened a bug and
  submitted a patch to revert this change.
 [...]

 Fix https://review.openstack.org/213843 is already winding its way
 through the sausage factory.


Yes, this was missed during the merge back of feature/qos, of which I
approved the merge commit. Thanks to Doug for jumping on this with 213843
here, which is almost finished having it's casing added.

--
 Jeremy Stanley

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

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

Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints

2015-08-17 Thread Gilles Dubreuil



On 15/08/15 00:23, Rich Megginson wrote:
 On 08/14/2015 06:51 AM, Matthew Mosesohn wrote:
 Gilles,

 I already considered this when looking at another openstackclient
 issue. Version 1.0.4 has almost no changes from 1.0.3, which is the
 official release for Kilo. Maybe we can get this keystone URL handling
 fix backported to the 1.0.X branch of openstackclient?
 
 I think we need some sort of fix in openstacklib and/or puppet-keystone
 so that v3 providers that use token auth can replace any /v2.0 in the
 url with /v3, to override any settings of OS_URL or OS_AUTH_URL in ENV
 or openrc.
 

I've broken down https://review.openstack.org/212523 (now abandoned) in
three pieces:

The first 2 ones can be backported to Kilo.
1. https://review.openstack.org/213598
 https://review.openstack.org/213938
2. https://review.openstack.org/213603
 Once 1. gets merged in Liberty, we'll be able to cherry pick it.

That won't necessarily fix the issue but it won't hurt but more
importantly it's making things a bit easier with clear separation
between url assignments and getting endpoints.

The last and next coming piece removes the API version numbers from the
Endpoints. Meanwhile that one won't be 'back-portable' unless OSC
version on Kilo gets bumped up which not likely to happen.

I hope it helps.

Let's take it from there and see what else we can do to address those
v2/v3.0 issues.

Cheers,
Gilles


 -Matthew

 On Fri, Aug 14, 2015 at 3:47 PM, Gilles Dubreuil gil...@redhat.com
 mailto:gil...@redhat.com wrote:



 On 14/08/15 20:45, Gilles Dubreuil wrote:
 
 
  On 13/08/15 23:29, Rich Megginson wrote:
  On 08/13/2015 12:41 AM, Gilles Dubreuil wrote:
  Hi Matthew,
 
  On 11/08/15 01:14, Rich Megginson wrote:
  On 08/10/2015 07:46 AM, Matthew Mosesohn wrote:
  Sorry to everyone for bringing up this old thread, but it
 seems we may
  need more openstackclient/keystone experts to settle this.
 
  I'm referring to the comments in
  https://review.openstack.org/#/c/207873/
  Specifically comments from Richard Megginson and Gilles Dubreuil
  indicating openstackclient behavior for v3 keystone API.
 
 
  A few items seem to be under dispute:
  1 - Keystone should be able to accept v3 requests at
 
 
 http://keystone-server:5000/http://keystone-server:5000/http://keystone-server:5000/
  I don't think so.  Keystone requires the version suffix
 /v2.0 or
  /v3.
 
  Yes, if the public endpoint is set without a version then the
 service
  can deal with either version.
 
  http://paste.openstack.org/raw/412819/
 
  That is not true for the admin endpoint (authentication is
 already done,
  the admin services deals only with tokens), at least for now,
 Keystone
  devs are working on it.
 
  I thought it worked like this - the openstack cli will infer
 from the
  arguments if it should do v2 or v3 auth.  In the above case for v3,
  since you specify the username/password, osc knows it has to use
  password auth (as opposed to token auth), and since all of the
 required
  v3 arguments are provided (v3 api version, domains for
 user/project), it
  can use v3 password auth.  It knows it has to use the
 /v3/auth/token
  path to get a token.
 
  Similarly for v2, since it only has username/password, no v3
 api or v3
  domain arguments, it knows it has to use v2 password auth.  It
 knows it
  has to use /v2.0/token to get a token.
 
  With the puppet-keystone code, since it uses TOKEN/URL, osc
 cannot infer
  if it can use v2 or v3, so it requires the /v2.0 or /v3
 suffix, and
  the api version.
 
 
  First of my apologies because I confused admin enpdoint with the
 admin
  service (or whatever that's dubbed).
 
  As of Keystone v3 (not the API, the latest version of Keystone which
  supports both API v2.0 and V3), the OS_AUTH_URL doesn't need the
  version. That can be effectively any of the endpoints, either
 the main
  (or public) by default on port 5000 or the admin by default on port
  35357, the third one internal pointing to either of the first
 two ones.
 
  This is a behavior at Keystone level not at the OSC. I mean OSC will
  just reflect the http-api behavior.
 
  Now the admin service, the one needed for the OS-TOKEN (used for
  bootstrapping) needs a URL (OS_URL) with a version to work.
 
  ATM, the issue with puppet keystone is that endpoints, OS_URL and
  OS_AUTH_URL are walking on each others.
 
 

 My latest update on this one, is that I found out while testing beaker
 which is using OSC 1.0.3 is not handling OS_AUTH_URL properly.

 I had been testing with OSC 1.5.1 and now latest 1.6.1 from Dolerean
 repo, where the version-less URLs are working, but not with OSC 1.0.1:

Re: [openstack-dev] [cinder] [third-party] ProphetStor CI account

HI Adhishek:

One more information, how are you catching the logs and making it browsable?

Do you mean item[6]? I just follow OpenStack Third-part CI document.
You can reference
http://docs.openstack.org/infra/system-config/third_party.html#faq-frequently-asked-questions.
Add this configuration in our web server.

On Tue, Aug 18, 2015 at 7:10 AM, Rick Chen rick.c...@prophetstor.com
mailto:rick.c...@prophetstor.com wrote:

HI Abhishek:

For you information in the below.

HI Mike:

What I have missed it?

On Mon, Aug 17, 2015 at 8:52 PM, Rick Chen rick.c...@prophetstor.com
mailto:rick.c...@prophetstor.com wrote:

HI Mike:
I completed to refine our CI configuration to follow Ramy's
comments. Does any missed or other attention I need respect?

[1] Add export DEVSTACK_GATE_TEMPEST_REGEX=volume to verify all
cinder volume testing.
[2] Add each service configuration in the log.

http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds
http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-dsvm-tempest-cinder-ci/5100/logs/etc/

vm-tempest-cinder-ci/5100/logs/etc/
[3] Add email alert when the devstack build failed to instead of you
notify to me.

Can you please tell me that how

you have done the [3].

Use Jenkins email E-mail Notification.

Manage Jenkins Configure System E-mail Notification

Add SMTP server and Default user e-mail suffix. Use advanced
button to verify email seting.

Add Email notification in you job.

CI job “Add post-build action” “Email Notification”
add Recipients.

Reference link:
https://www.safaribooksonline.com/library/view/jenkins-the-definitive/9781449311155/ch08s02.html

https://www.safaribooksonline.com/library/view/jenkins-the-definitive/9781449311155/ch08s02.html

[4] Integrate VMware snapshot revert feature in the Jenkins master
to clean CI slave machine OS environment that avoid the devstack building
failed due to previous devstack garbage configuration.

Also, the process of CI slave snapshot revert mentioned in [4].

Add Jenkins plugin agent: vSphere Cloud Plugin

Configure vSphere Cloud in Jenkins master.

Manage Jenkins Configure System vSphere Cloud

Add vSphere hose, user name, password.

Configure vSphere Slave.

Add slave node and select “Slave virtual computer running under
vSphere Cloud”

Manage Jenkins Manage Nodes New node select “Slave virtual
computer running under vSphere Cloud”

Add your vSphere information in this configuration page.

Reference link:
https://wiki.jenkins-ci.org/display/JENKINS/vSphere+Cloud+Plugin
https://wiki.jenkins-ci.org/display/JENKINS/vSphere+Cloud+Plugin

[5] Latest CI result for you reference.

http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds
http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-dsvm-tempest-cinder-ci/5100/logs/

vm-tempest-cinder-ci/5100/logs/
http://download.prophetstor.com/prophetstor_ci/

[6] Logs need to be browsable online.
Add Rewrite module and rule in the apache configuration.

my gerrit account: prophetstor-ci
gerrit account email:prophetstor...@prophetstor.com
mailto:prophetstor...@prophetstor.com

Many thanks.

https://docs.google.com/uc?export=downloadid=0Byq0j7ZjFlFKV3ZCWnlMRXBCcU0revid=0Byq0j7ZjFlFKa2V5VjdBSjIwUGx6bUROS2IrenNwc0kzd2IwPQ

Thanks Regards,

Abhishek

http://www.cloudbyte.com Cloudbyte Inc.

https://docs.google.com/uc?export=downloadid=0Byq0j7ZjFlFKV3ZCWnlMRXBCcU0revid=0Byq0j7ZjFlFKa2V5VjdBSjIwUGx6bUROS2IrenNwc0kzd2IwPQ

Thanks Regards,

Abhishek

http://www.cloudbyte.com Cloudbyte Inc.

Re: [openstack-dev] [openstack-deb] Devstack stable/juno fails to install

2015-08-17 Thread Tony Breeds

On Mon, Aug 17, 2015 at 03:51:46PM -0500, Matt Riedemann wrote:

 What version of taskflow is installed?  Cinder 2014.2.3 requires this
 version of taskflow [1]:
 
 taskflow=0.4,0.7.0
 
 Which should get you taskflow 0.6.2, and taskflow 0.6.2 has this requirement
 [2] for futures:
 
 futures=2.2.0,=2.1.6
 
 What version of futures is installed?  Run 'pip show futures'.

---
stack@stack01:~/projects/openstack/openstack-dev/devstack$ pip show futures
---
Metadata-Version: 2.0
Name: futures
Version: 3.0.3
Summary: Backport of the concurrent.futures package from Python 3.2
Home-page: https://github.com/agronholm/pythonfutures
Author: Alex Gronholm
Author-email: alex.gronholm+p...@nextday.fi
License: BSD
Location: /usr/local/lib/python2.7/dist-packages
Requires: 
---

I think this is being pulled in by an uncapped dependancy in swiftclient:
---
2015-08-17 23:41:42.287 | Collecting futures=2.1.3 (from 
python-swiftclient=2.3.1,=2.2.0-glance==2014.2.4.dev6)
2015-08-17 23:41:42.326 |   Using cached futures-3.0.3-py2-none-any.whl
---

I know the devstack/juno install worked on Friday last week, so something 
changed over the weekend.

Ahh perhaps this https://review.openstack.org/#/c/212652/ ?

My solution would be to cap futures in swiftclient but I don't knwo that is 
correct.
 
Yours Tony.


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

Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities

2015-08-17 Thread David Lyle

I think we've conveniently been led off track here. The original
request/subject was regarding pagination of projects in the v3 API. Since
this is purely a keystone construct it seems implausible to me that ldap or
the IdP of choice would be limiting the ability to return a paginated list
of all projects. Or groups or domains or roles for that matter.

There is no reason to punt on pagination across the API for one resource
type, which actually would also work with select backends. Give me
something that I can exhaustively list in the API I can build from.

David
On Aug 17, 2015 10:53 AM, Fox, Kevin M kevin@pnnl.gov wrote:

 1. yes, but probably only if its a short list. It may be feasible to show
 it only if there are 5 or less pages, and maybe just load all pages of data
 and paginate it on the client. If too big, ask the user to refine their
 search? Or always paginate to 5, and then the 6th page have a page
 requesting further refinement?

 2. Not sure what the difference between searching and filtering is in this
 context? something like facets? If so, probably the 5 or less thing would
 work here too.

 3. Yes, but again, probably within a smaller set of pages?

 Thanks,
 Kevin
 
 From: Kruithof, Piet [pieter.c.kruithof...@hp.com]
 Sent: Sunday, August 16, 2015 9:41 AM
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination support
 for Identity dashboard entities

 I like Michael’s response because it moved the thread towards identifying
 actual user needs before digging into the technical feasibility.  IMHO, it
 would be helpful to have a few people on the list answer his questions:

 1 - Do users want to page through search results?


 2 - Do users want to page through filter results? (do they use filter
 results?)


 3 - If they want to page, do they want to be able to go back a page and/or
 know their current page?


 I understand that even if we answer “yes” to all three questions that
 there could be issues around implementation, but at least we’ll know a gap
 exists.


 Piet Kruithof
 Sr UX Architect, HP Helion Cloud
 PTL, OpenStack UX project

 For every complex problem, there is a solution that is simple, neat and
 wrong.”

 H L Menken


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

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

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

Re: [openstack-dev] [nova] Nova API sub-team meeting (New meeting time)

2015-08-17 Thread Ed Leafe

On Aug 17, 2015, at 9:08 AM, Alex Xu hejie...@intel.com wrote:

 We have weekly Nova API meeting this week. The meeting is being held tomorrow 
 Tuesday UTC1200.
 
 In other timezones the meeting is at:
 
 EST 08:00 (Fri)
 Japan 21:00 (Fri)
 China 20:00 (Fri)
 United Kingdom 13:00 (Fri)

s/Fri/Tue for all of the above. :)


-- Ed Leafe







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

Re: [openstack-dev] [nova] Nova API sub-team meeting (New meeting time)

2015-08-17 Thread Alex Xu


 在 2015年8月18日，上午10:07，Ed Leafe e...@leafe.com 写道：
 
 On Aug 17, 2015, at 9:08 AM, Alex Xu hejie...@intel.com wrote:
 
 We have weekly Nova API meeting this week. The meeting is being held 
 tomorrow Tuesday UTC1200.
 
 In other timezones the meeting is at:
 
 EST 08:00 (Fri)
 Japan 21:00 (Fri)
 China 20:00 (Fri)
 United Kingdom 13:00 (Fri)
 
 s/Fri/Tue for all of the above. :)

oops! good catch!

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


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

Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities

2015-08-17 Thread Adam Young


On 08/17/2015 09:53 PM, David Lyle wrote:


I think we've conveniently been led off track here. The original 
request/subject was regarding pagination of projects in the v3 API. 
Since this is purely a keystone construct it seems implausible to me 
that ldap or the IdP of choice would be limiting the ability to return 
a paginated list of all projects. Or groups or domains or roles for 
that matter.




Yeah, SQL can support it.  LDAP assignment can't.  But that is not going 
to have a long life.


With Hierarchical projects, we'll probably also have to keep nesting in 
mind for how we display a project list:  do we always show a flat list, 
or is a tree closer to what users expect?


Both are going to work poorly for some deployments and work well for others.

There is no reason to punt on pagination across the API for one 
resource type, which actually would also work with select backends. 
Give me something that I can exhaustively list in the API I can build 
from.


David

On Aug 17, 2015 10:53 AM, Fox, Kevin M kevin@pnnl.gov 
mailto:kevin@pnnl.gov wrote:


1. yes, but probably only if its a short list. It may be feasible
to show it only if there are 5 or less pages, and maybe just load
all pages of data and paginate it on the client. If too big, ask
the user to refine their search? Or always paginate to 5, and then
the 6th page have a page requesting further refinement?

2. Not sure what the difference between searching and filtering is
in this context? something like facets? If so, probably the 5 or
less thing would work here too.

3. Yes, but again, probably within a smaller set of pages?

Thanks,
Kevin

From: Kruithof, Piet [pieter.c.kruithof...@hp.com
mailto:pieter.c.kruithof...@hp.com]
Sent: Sunday, August 16, 2015 9:41 AM
To: openstack-dev@lists.openstack.org
mailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination
support for Identity dashboard entities

I like Michael’s response because it moved the thread towards
identifying actual user needs before digging into the technical
feasibility.  IMHO, it would be helpful to have a few people on
the list answer his questions:

1 - Do users want to page through search results?


2 - Do users want to page through filter results? (do they use
filter results?)


3 - If they want to page, do they want to be able to go back a
page and/or know their current page?


I understand that even if we answer “yes” to all three questions
that there could be issues around implementation, but at least
we’ll know a gap exists.


Piet Kruithof
Sr UX Architect, HP Helion Cloud
PTL, OpenStack UX project

For every complex problem, there is a solution that is simple,
neat and wrong.”

H L Menken


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

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



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


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

Re: [openstack-dev] [heat-translator] Nominating new core reviewers

2015-08-17 Thread Ton Ngo


+1 for both.



From:   Sahdev P Zala/Durham/IBM@IBMUS
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Date:   08/17/2015 12:39 PM
Subject:[openstack-dev]  [heat-translator] Nominating new core
reviewers



Hello,

I am glad to nominate Vahid Hashemian [1] and Srinivas Tadepalli [2] for
the Heat-Translator core reviewers team.


Both of them have been providing significant contribution, development and
review, since the beginning of this year and knows code base well.


Existing cores, please reply this email by end of this week with your vote
+1/-1 for their addition to the team.


Review stats:
http://stackalytics.com/report/contribution/heat-translator/90


[1] https://review.openstack.org/#/q/reviewer:%22Vahid+Hashemian
+%253Cvahidhashemian%2540us.ibm.com%253E%22,n,z


[2] https://review.openstack.org/#/q/reviewer:%22srinivas_tadepalli
+%253Csrinivas.tadepalli%2540tcs.com%253E%22,n,z


Regards,
Sahdev Zala
PTL, Heat-Translator


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


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

Re: [openstack-dev] [tripleo] Upgrades, Releases Branches

2015-08-17 Thread Giulio Fidente


On 08/17/2015 09:29 PM, James Slagle wrote:

On Mon, Aug 17, 2015 at 9:28 AM, Steven Hardy sha...@redhat.com wrote:

Hi all,

Recently I had some discussion with folks around the future strategy for
TripleO wrt upgrades, releases and branches, specifically:

- How do we support a stable TripleO release/branch that enables folks to
   easily deploy the current stable release of OpenStack
- Related to the above, how do we allow development of TripleO components
   (and in particular t-h-t) to proceed without imposing undue constraints
   on what new features may be used (e.g new-for-liberty Heat features which
   aren't present in the current released OpenStack version)
- We're aiming to provide upgrade support, thus from and to which versions?

I know historically TripleO has taken something of a developer and/or
continuous deployment model for granted, but I'd like to propose that we
revisit that discusion, such that we move towards something that's more
consumable by users/operators that are consuming the OpenStack coordinated
releases.

The obvious answer is a stable branch for certain TripleO components, and
in particular for t-h-t, but this has disadvantages if we take the
OpenStack wide no feature backports approach - for example upgrade
support to liberty could be considered a feature, and many other TripleO
features are really more about making features of the deployed OpenStack
services consumable.

I'd like propose we take a somewhat modified release branch approach,
which combines many of the advantages of the stable-branch model, but
allows for a somewhat more liberal approach to backports, where most things
are considered valid backports provided they work with the currently
released OpenStack services (e.g right now, a t-h-t release/kilo branch
would have to maintain compatibility with a kilo Heat in the undercloud)


I like the idea, it seems reasonable to me.


/me too

from what I understand this would apply only to the latest stable, the 
previous releases won't get automated updates when a new release is out, 
is this correct?



I do think we should clarify if the rule is:

We *can* backport anything to release/kilo that doesn't break
compatibility with kilo Heat.

Or:

We *must* backport anything to release/kilo that doesn't break
compatibility with kilo Heat.



[...]



I think it's important to decide this up front so we can set the
expectation. I'm leaning towards the latter (must backport) myself,
but then I wonder if the release branch would really solve the
downstream use.


I am for a must as well; a CI job deploying openstack/kilo code using 
the proposed tripleo/master changes might help exposing 
incompatibilities early on



Again, I just go back to the point of the branch. Does it exist to
provide some semblance of stability so that we make distros happy? Or
does it exist solely for the purpose so that we can iterate faster on
using new Heat features in master?


I am not a puppet expert but another reason for the branches could be to 
avoid cross-release incompatibilities due to updates of the 
manifests/modules, not only of the templates


Architectural (incompatible) changes might also benefit from having 
different branches; even though these would remain a hard problem to 
solve in an upgrade scenario



One way to minimise the overhead of maintaing such a branch could be to
implement a bot which automatically proposes commits which land in master
to the branch (using Depends-On to maintain the history order).


I'm not sure I'm following how this would work. Which patch depends on
which other one? If the master patch is A'd, is the release branch
automatically +A'd as well (as long as it's not -2'd)? It seems like
that might be necessary to maintain consistent looking history between
master and the release branch.

Likewise, if the release branch were to fail to merge, it would need
to block the master patch from merging so that there wasn't potential
for different patches to merge out of order in the 2 branches.


yeah looks like the automated process should try to backport the changes 
in the same order they are merged in the master branch and completely 
stop if one of them fails? then assuming manual intervention continue 
from more recent backport?



Interested to hear feedback on the idea, as well as if anyone has direct
experience of implementing the bot/automation pieces.


/me doesn't have experience but would think about the bot as a very 
'stupid' tool rather than an intelligent one; stopping the backports 
seems generally safer than an automated merge which breaks things out of 
immediate sight

--
Giulio Fidente
GPG KEY: 08D733BA

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

Re: [openstack-dev] [kolla] Proposing Swapnil Kulkarni (coolsvap) for kolla core reviewer team

2015-08-17 Thread Steven Dake (stdake)

Cool so its almost unanimous but all the core reviewers have weighed in.

Welcome to the Kolla Core Reviewer team Swapnil !

Regards
-steve


From: Martin André martin.an...@gmail.commailto:martin.an...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, August 17, 2015 at 11:33 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla] Proposing Swapnil Kulkarni (coolsvap) for 
kolla core reviewer team



On Fri, Aug 14, 2015 at 3:29 PM, Steven Dake (stdake) 
std...@cisco.commailto:std...@cisco.com wrote:
Hi folks,

Swapnil has done a bunch of great technical work, participates heavily in IRC, 
and has contributed enormously to the implementation of Kolla.  I’d like to see 
more reviews from Swapnil, but he has committed to doing more reviews and 
already has gone from something like 0 reviews to 90 reviews in about a month.  
Count this proposal as a +1 from me.

His 90 day stats are:
http://stackalytics.com/report/contribution/kolla-group/90

The process we go to select new core reviewers is that we require a minimum of 
3 +1 votes within a 1 week voting window.  A vote of –1 is a veto.  It is fine 
to abstain as well without any response to this email.  If the vote is 
unanimous or there is a veto vote prior to the end of the voting window, I’ll 
close voting then.

The voting is open until Friday August 21st.

I'm abstaining from the vote as I haven't been very involved lately and feel I 
can't judge on Swapnil's work. That being said, I entirely trust other cores' 
judgment and am sure he'll be an excellent kolla core.

Martin


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


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

[openstack-dev] [Neutron] revert default review branch to master

2015-08-17 Thread Mooney, Sean K

Hi I just noticed the default review branch for neutron has been updated to the 
feature/qos branch

Assuming this was not intentional I have opened a bug and submitted a patch to 
revert this change.

https://bugs.launchpad.net/neutron/+bug/1485788
https://review.openstack.org/#/c/213908/

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

Re: [openstack-dev] [pbr] [stable] [infra] How to generate .Z version increments on stable/liberty commits

On 2015-08-18 01:36:05 +0200 (+0200), Alan Pevec wrote:
[...]
 OSSA merge could trigger an async release proposal too.

True, now that we're putting the advisories through Gerrit, that's
certainly an available option.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities

2015-08-17 Thread Steve Martinelli

Paging support for certain Keystone constructs seems reasonable to me
(roles, domains and projects). But as Adam Young just wrote in [0], though
possible for our SQL backends, why? Do you really expect deployments to
have 100s of roles/domains/projects?

IMO groups probably should not have paging, as with users, they can be
owned by another identity source as well.

A minor note about paging through LDAP; in my experience LDAP paging
usually requires an administrator authenticate/bind, which most users
likely are not, and still uses it's own server side settings to determine
how many results to return.

[0]
http://openstack.markmail.org/search/?q=keystone#query:keystone%20list%3Aorg.openstack.lists.openstack-dev%20order%3Adate-backward
+page:1+mid:kdw5wf5tcc6ad36j+state:results

Thanks,

Steve Martinelli
OpenStack Keystone Core



From:   David Lyle dkly...@gmail.com
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Date:   2015/08/17 09:54 PM
Subject:Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination
support for Identity dashboard entities



I think we've conveniently been led off track here. The original
request/subject was regarding pagination of projects in the v3 API. Since
this is purely a keystone construct it seems implausible to me that ldap or
the IdP of choice would be limiting the ability to return a paginated list
of all projects. Or groups or domains or roles for that matter.


There is no reason to punt on pagination across the API for one resource
type, which actually would also work with select backends. Give me
something that I can exhaustively list in the API I can build from.


David


On Aug 17, 2015 10:53 AM, Fox, Kevin M kevin@pnnl.gov wrote:
  1. yes, but probably only if its a short list. It may be feasible to show
  it only if there are 5 or less pages, and maybe just load all pages of
  data and paginate it on the client. If too big, ask the user to refine
  their search? Or always paginate to 5, and then the 6th page have a page
  requesting further refinement?

  2. Not sure what the difference between searching and filtering is in
  this context? something like facets? If so, probably the 5 or less thing
  would work here too.

  3. Yes, but again, probably within a smaller set of pages?

  Thanks,
  Kevin
  
  From: Kruithof, Piet [pieter.c.kruithof...@hp.com]
  Sent: Sunday, August 16, 2015 9:41 AM
  To: openstack-dev@lists.openstack.org
  Subject: Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination support
  for Identity dashboard entities

  I like Michael’s response because it moved the thread towards identifying
  actual user needs before digging into the technical feasibility.  IMHO,
  it would be helpful to have a few people on the list answer his
  questions:

  1 - Do users want to page through search results?


  2 - Do users want to page through filter results? (do they use filter
  results?)


  3 - If they want to page, do they want to be able to go back a page
  and/or know their current page?


  I understand that even if we answer “yes” to all three questions that
  there could be issues around implementation, but at least we’ll know a
  gap exists.


  Piet Kruithof
  Sr UX Architect, HP Helion Cloud
  PTL, OpenStack UX project

  For every complex problem, there is a solution that is simple, neat and
  wrong.”

  H L Menken


  __

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

  __

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

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


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

Re: [openstack-dev] [pbr] [stable] [infra] How to generate .Z version increments on stable/liberty commits

2015-08-17 Thread Doug Hellmann

Excerpts from Alan Pevec's message of 2015-08-18 01:36:05 +0200:
  The only alternative seems to be to have on-demand stable-branch
  tagging. The main drawbacks of that option are that consumers of the
  stable branch are unnecessarily limited to specific tagged commits, and
  depend on various project teams to remember to push them.
 
 As Doug suggested,  stable releases would be triggered by submitting a
 patch to the releases
 repository, so maybe we could be auto-generating release proposals
 periodically (monthly, weekly?) as a reminder to the team if there
 hasn't been a release in that period?
 Also OSSA merge could trigger an async release proposal too.

I want to do something similar for libraries off of master, so I think
this is a generalizable thing.

Doug

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

Re: [openstack-dev] [Ironic] Let's talk about API versions

2015-08-17 Thread Robert Collins

On 11 August 2015 at 06:13, Ruby Loo rlooya...@gmail.com wrote:
 Hi, sorry for the delay. I vote no. I understand the rationale of trying to
 do things so that we don't break our users but that's what the versioning is
 meant for and more importantly -- I think adding the ENROLL state is fairly
 important wrt the lifecycle of a node. I don't particularly want to hide
 that and/or let folks opt out of it in the long term.

 From a reviewer point-of-view, my concern is me trying to remember all the
 possible permutations/states etc that are possible to make sure that new
 code doesn't break existing behavior. I haven't thought out whether adding
 this new API would make that worse or not, but then, I don't really want to
 have to think about it. So KISS as much as we can! :)

I'm a little surprised by this, to be honest.

Here's why: allowing the initial state to be chosen from
ENROLL/AVAILABLE from the latest version of the API is precisely as
complex as allowing two versions of the API {old, new} where old
creates nodes in  AVAILABLE and new creates nodes in ENROLL. The only
difference I can see is that eventually someday if {old} stops being
supported, then and only then we can go through the code and clean
things up.

It seems to me that the costs to us of supporting graceful transitions
for users here are:

1) A new version NEWVER of the API that supports node state being one
of {not supplied, AVAILABLE, ENROLL}, on creation, defaulting to
AVAILABLE when not supplied.
2) Supporting the initial state of AVAILABLE indefinitely rather than
just until we *delete* version 1.10.
3) CD deployments that had rolled forward to 1.11 will need to add the
state parameter to their scripts to move forward to NEWVER.
4) Don't default the client to the veresions between 1.10 and NEWVER
versions at any point.

That seems like a very small price to pay on our side, and the
benefits for users are that they can opt into the new functionality
when they are ready.

-Rob

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

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

Re: [openstack-dev] [TripleO] Encapsulating logic and state in the client

2015-08-17 Thread Tzu-Mainn Chen

- Original Message -
 It occurs to me that there has never been a detailed exposition of the
 purpose of the tripleo-common library here, and that this might be a
 good time to rectify that.
 
 Basically, there are two things that it sucks to have in the client:
 
 First, logic - that is, any code that is not related to the core client
 functionality of taking input from the user, making ReST API calls, and
 returning output to the user. This sucks because anyone needing to
 connect to a ReST API using a language other than Python has to
 reimplement the logic in their own language. It also creates potential
 versioning issues, because there's nothing to guarantee that the client
 code and anything it interacts with on the server are kept in sync.
 
 Secondly, state. This sucks because the state is contained in a user's
 individual session, which not only causes all sorts of difficulties for
 anyone trying to implement a web UI but also means that you're at risk
 of losing some state if you e.g. accidentally Ctrl-C the CLI client.
 
 Unfortunately, as undesirable as these are, they're sometimes necessary
 in the world we currently live in. The only long-term solution to this
 is to put all of the logic and state behind a ReST API where it can be
 accessed from any language, and where any state can be stored
 appropriately, possibly in a database. In principle that could be
 accomplished either by creating a tripleo-specific ReST API, or by
 finding native OpenStack undercloud APIs to do everything we need. My
 guess is that we'll find a use for the former before everything is ready
 for the latter, but that's a discussion for another day. We're not there
 yet, but there are things we can do to keep our options open to make
 that transition in the future, and this is where tripleo-common comes in.
 
 I submit that anything that adds logic or state to the client should be
 implemented in the tripleo-common library instead of the client plugin.
 This offers a couple of advantages:
 
 - It provides a defined boundary between code that is CLI-specific and
 code that is shared between the CLI and GUI, which could become the
 model for a future ReST API once it has stabilised and we're ready to
 take that step.
 - It allows for an orderly transition when that happens - we can have a
 deprecation period during which the tripleo-common library is imported
 into both the client and the (future, hypothetical) ReST API.
 
 cheers,
 Zane.
 

+1; as someone who's done work integrating OpenStack with external code bases
(Ruby), I like this idea a lot.  People have been extremely impressed with
how easy it's been to integrate services like Nova or Ironic, and I think
eventually enabling that sort of ease of integration with TripleO will be a
good step in encouraging wider adoption of TripleO.


Mainn



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

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

Re: [openstack-dev] [pbr] [stable] [infra] How to generate .Z version increments on stable/liberty commits

On 2015-08-17 15:25:07 +0200 (+0200), Thierry Carrez wrote:
[...]
 I see Doug, Robert, Clark and myself as necessary to the
 discussion
[...]

It would also be great to get some of the operators and/or package
maintainers involved since they were the ones arguing against the
original and much simpler proposal (no longer making stable branch
point releases at all). Coming up with a solution which technically
solves the problem statement we've settled on without actually
addressing the concerns leading to that wouldn't be much help to
anyone.

If we put this on the CP agenda, I'll send a pointer to the
-operators ML too.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [nova] Silent nova fails

2015-08-17 Thread Andrew Laski


On 08/17/15 at 02:59pm, Timofei Durakov wrote:

Hello,

In current design there are places when nova fails while executing users
CLI commands, but no error messages, except some logs in nova-compute,
produced [1] . The problem is that there is no response from compute node
to conductor, as RPC cast is used.

To fix this nova should make a synchronous call before operation itself to
verify that it is valid. E.g. here is my patch that fixes this problem in
resize operation [2]


I think that Nova should avoid synchronous calls when at all possible.  
They often end up leading to timeouts and needing to be very careful 
about locking or idempotence because the natural reaction to a timeout 
is to try again, but often the original operation is still in progress.  
And when there is a timeout, or disconnect, you've lost the benefit you 
were hoping to gain of providing immediate feedback.  I think that 
rather than trying to treat requests as local operations we should 
embrace the asynchronous nature of the distributed system and work on a 
robust way to provide feedback that works with, rather than against, how 
Nova is architected.


There is already a framework in place for doing this called instance 
actions which are visible via the Nova API.  And a longer term solution 
under discussion called tasks.  By having a resize task exposed in the 
API a user could check on the status of that and see if it had 
succeeded/failed and get a relevant error message for a failure. 



So, I would like to get feedback about such hypervisor checks before
operations. Nova already makes these checks during live-migration process:
conductor calls compute manager[3], which also consults with driver[4]. And
as for me I think we should use such logic in resize operation.

Timofey.

[1] https://bugs.launchpad.net/nova/+bug/1455460

[2] https://review.openstack.org/195088

[3]
https://github.com/openstack/nova/blob/master/nova/conductor/tasks/live_migrate.py#L144

[4]
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5157



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



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

[openstack-dev] [neutron] extension implemented by multiple plugins

2015-08-17 Thread Bence Romsics

Hi All,

How do I implement one extension by two plugins?

If I extend the API by:
* a first class resource, and
* attributes to an already existing resource (the port resource in my case).

These two parts don't make sense without each other, so I'd like to
keep this as one extension, not two.

Then naturally I'd like to implement:
* the first class resource as a service plugin, and
* the new port attributes as an ml2 extension driver.

And straightforwardly I put the same extension alias into both the
service plugin and the ml2 extension driver. Then I get this error:

File /opt/stack/neutron/neutron/manager.py, line 199, in _load_service_plugins
ValueError: Multiple plugins for service TRUNK_PORT were configured

IMHO prohibiting two plugins of the same type was good logic when we
had service plugins only, but now that we have ml2 extension drivers
too it seems to be buggy logic.

What do you think?
Shall we change this logic?
Maybe keep track of two sets of plugins, one for service plugins and
one for ml2 extension drivers?
Or do you know some other way?

For further details it seems to me the following files and methods are
implementing the current logic:

neutron/plugins/ml2/plugin.py:
Ml2Plugin.supported_extension_aliases()

neutron/plugins/ml2/managers.py:
ExtensionManager.extension_aliases()

neutron/manager.py:
NeutronManager._load_service_plugins()
NeutronManager._load_services_from_core_plugin()

Thanks in advance,
Bence

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

Re: [openstack-dev] [Fuel] Get rid of run_test.sh in Fuel Client

2015-08-17 Thread Mike Scherbakov

+1. Especially if you don't use fake mode of Nailgun, I don't know why
would you even be copying legacy code to the new repo..

Thanks!

On Mon, Aug 17, 2015 at 6:25 AM Jay Pipes jaypi...@gmail.com wrote:

 On 08/17/2015 08:50 AM, Roman Prykhodchenko wrote:
  Hi Fuelers!
 
  I was working on enabling Python tests in Fuel Client to run on
  OpenStack CI and I figured out that we actually have a piece of
  legacy code which can be removed now. That piece is run_tests.sh
  file. For those who’s not aware, that script allows to run different
  tests under different environments. I don’t know how it was a
  thousand years ago when I was not involved to Fuel project, but the
  situation at this particular moment looks like that:
 
  - Tests are actually orchestrated by tox - The biggest job of
  run_tests.sh is to translate its options to tox’es options - The only
  useful job of run_tests.sh is to start Nailgun correctly for
  functional tests
 
  As you can see the profit of that script is tiny. However, the
  problems it brings are pretty much big and looks as follows:
 
  - It is unstable — tiniest changes to tests require big changes to
  the script - The CLI it provides is confusing - Working on that file
  looks like doing the same job that is already done in tox - Among the
  active Fuel Client’s community there are only a few guys who are
  proficient in bash enough, to support that script effectively
 
 
  My proposal is to extract the code responsible for starting Nailgun
  into to a small utility script and let tox do the rest by removing
  run_test.sh completely. That will bring us the following advantages:
 
  - No need to support a complex bash script. - Closer to being able to
  run functional tests on DSVM gates. - Test CLI will be more
  compatible with other OpenStack projects.
 
  I foresee a few questions and the answers for them follow:
 
  Q: How is verify-job from FuelCI going to run tests without that
  file? A: Fuel Client has its own job on FuelCI, so it will be just
  necessary to change the invocation there.
 
  Q: But run_test.sh is in all Fuel projects, shouldn’t we keep them
  all similar. A: Why does it have to be similar? This kind of
  difference is minor and it brings more advantages, than just having
  the same file. In fact the set of options in run_tests.sh is already
  different from run_tests.sh in fuel-web.
 
  Q: Why should we look ad other OpenStack projects? A: Fuel is living
  in the OpenStack ecosystem so being compatible with it is a big
  advantage. It’s also a must for going big tent.

 +1.

 Just make sure any documentation that might refer to run_tests.sh is
 updated accordingly :)

 Best,
 -jay

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

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

[openstack-dev] [nova] Nova API sub-team meeting (New meeting time)

2015-08-17 Thread Alex Xu

Hi,

We have weekly Nova API meeting this week. The meeting is being held tomorrow 
Tuesday UTC1200.

In other timezones the meeting is at:

EST 08:00 (Fri)
Japan 21:00 (Fri)
China 20:00 (Fri)
United Kingdom 13:00 (Fri)

The proposed agenda and meeting details are here:

https://wiki.openstack.org/wiki/Meetings/NovaAPI 
https://wiki.openstack.org/wiki/Meetings/NovaAPI

Please feel free to add items to the agenda.__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Get rid of run_test.sh in Fuel Client

2015-08-17 Thread Roman Prykhodchenko

Hi Fuelers!


I was working on enabling Python tests in Fuel Client to run on OpenStack CI 
and I figured out that we actually have a piece of legacy code which can be 
removed now. That piece is run_tests.sh file. For those who’s not aware, that 
script allows to run different tests under different environments. I don’t know 
how it was a thousand years ago when I was not involved to Fuel project, but 
the situation at this particular moment looks like that:

- Tests are actually orchestrated by tox
- The biggest job of run_tests.sh is to translate its options to tox’es options
- The only useful job of run_tests.sh is to start Nailgun correctly for 
functional tests

As you can see the profit of that script is tiny. However, the problems it 
brings are pretty much big and looks as follows:

- It is unstable — tiniest changes to tests require big changes to the script
- The CLI it provides is confusing
- Working on that file looks like doing the same job that is already done in tox
- Among the active Fuel Client’s community there are only a few guys who are 
proficient in bash enough, to support that script effectively


My proposal is to extract the code responsible for starting Nailgun into to a 
small utility script and let tox do the rest by removing run_test.sh 
completely. That will bring us the following advantages:

- No need to support a complex bash script.
- Closer to being able to run functional tests on DSVM gates.
- Test CLI will be more compatible with other OpenStack projects.

I foresee a few questions and the answers for them follow:

Q: How is verify-job from FuelCI going to run tests without that file?
A: Fuel Client has its own job on FuelCI, so it will be just necessary to 
change the invocation there.

Q: But run_test.sh is in all Fuel projects, shouldn’t we keep them all similar.
A: Why does it have to be similar? This kind of difference is minor and it 
brings more advantages, than just having the same file. In fact the set of 
options in run_tests.sh is already different from run_tests.sh in fuel-web.

Q: Why should we look ad other OpenStack projects?
A: Fuel is living in the OpenStack ecosystem so being compatible with it is a 
big advantage. It’s also a must for going big tent.


- romcheg






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

Re: [openstack-dev] [pbr] [stable] [infra] How to generate .Z version increments on stable/liberty commits

2015-08-17 Thread Thierry Carrez

Hi!

This discussion died without a clear way forward...

The automatically tagging every commit option, described by Robert as
the only sensible route, results according to Clark in so many tags
you end up polluting the ref space and making it unusable by humans.
However, we are lacking other solutions that let us clearly associate a
version number to every commit on the branch.

The only alternative seems to be to have on-demand stable-branch
tagging. The main drawbacks of that option are that consumers of the
stable branch are unnecessarily limited to specific tagged commits, and
depend on various project teams to remember to push them. Basically that
would only work with stable branch liaisons regularly pushing such tags
for every service project on a stable branch. The obvious benefit of
that option is that we don't really require to code black magic to make
it happen, it's consistent with the current tooling and systems we have.

We need to make progress on this so that the tooling is ready when we
switch to stable branches at the end of Liberty. Should we discuss it
live at a cross-project meeting ? I see Doug, Robert, Clark and myself
as necessary to the discussion, but anyone else is welcome to
participate and help, especially stable team members :)

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [stable] [infra] How to auto-generate stable release notes

2015-08-17 Thread Thierry Carrez

Thierry Carrez wrote:
 Doug Hellmann wrote:
 How detailed do we want release notes to be? For example, do we need to
 worry about supporting multiple paragraphs or ASCII art or anything like
 that?
 
 Looking at our current release notes, they are a set of bullet points of
 a pre-determined type. Types vary slightly between master and stable:
 
 Master release notes (https://wiki.openstack.org/wiki/ReleaseNotes/Kilo)
 currently contain three/four sections:
 
 * Key new features
 * Known issues
 * Upgrade notes
 * (Other notes)
 
 [ Known issues are generally used to list known bugs that we didn't
 have time to fix (or couldn't find a good fix for) at release time. So
 there is no related commit. How would we push those ? ]
 
 Stable release notes
 (https://wiki.openstack.org/wiki/ReleaseNotes/2015.1.1) currently list:
 
 * (Upgrade notes) -- hopefully never needed
 * Security fixes
 * Bugs fixed (just links to Launchpad lists)
 
 To answer your question, I don't think we need to support complex
 entries with multiple paragraphs or ascii art: single bullet points are
 probably enough. A simple grammar of predetermined headers should do the
 trick.

So I propose we use, starting with stable/liberty backports in two
months, the following commit message headers:

Critical-note: text
For a critical release note bullet point, generally if backward
compatibility is broken and/or the upgrade from the original stable
release requires manual intervention. That generally means the stable
branch rules have been pretty broken and this commit got an exception,
so hopefully this is never used.

OSSA: -ZZZ
For commits that correspond to vulnerability fixes.

Release-note: text
For general release note bullet point.

pbr could pick up those headers in git commits, build a RELEASENOTES
text file including bullets for the 3 sections (in that order) and
(maybe) add a link to the corresponding Launchpad milestone page for
people interested in seeing bugfix lists. How crazy does that sound ?

We can extend the vocabulary and enable this on master branches as a
second step, but the time-sensitive issue is on stable branches: we want
this ready in 2 months for when we'll start generating stable/liberty
thingies.

 We also might need a mechanism to add to release notes when we realize
 after the fact that a specific commit in past history warrants a
 highlight. Would some kind of no-change commit do the trick ?

Any suggestion on how to work around that situation ?

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [cinder][ThirdPartyCI]CloudFounders OpenvStorage CI - request to re-add the cinder driver

Hi,

We had our driver removed by commit:
https://github.com/openstack/cinder/commit/f0ab819732d77a8a6dd1a91422ac183ac4894419
 due to no CI.

Last week we got it working again and it's been commenting for the last 3
days continuously.

A normal run looks like this:

*08:40:37* Ran: 1265 tests in 2338. sec.*08:40:37*  - Passed:
1156*08:40:37*  - Skipped: 109*08:40:37*  - Expected Fail: 0*08:40:37*
 - Unexpected Success: 0*08:40:37*  - Failed: 0*08:40:37* Sum of
execute time for each test: 3300.1602 sec.

for this review:

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

and logs:

http://packages.cloudfounders.com/ci_logs/44/212144/3/check/dsvm-tempest-full/f1c6f6a/




Pls let me know if there is something wrong so we can fix it asap so
we can have the driver back in Liberty (if possible).


Thanks,


-- 

*Eduard Biceri Matei, Senior Software Developer*
www.cloudfounders.com
 | eduard.ma...@cloudfounders.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Keystone] [swift3] [s3] [ec2] What preferable way to implement S3 signature verification V4 in keystone projects?

2015-08-17 Thread Andrey Pavlov

Hi,

I'm trying to support AWS signature version 4 for S3 requests.
Related bugs:[1] for keystonemiddleware and [2] for swift3:

Also keystone doesn't have support for V4 signature verification for S3
(but it supports V4 for EC2 requests).

Differences between V1 and V4 can be found here - V1: [3] and V4: [4].
(Signature verification has several differences for EC2 and S3 requests)

My question is - how to implement V4 signature verification?
I have several scenarios:
1) Leave current architecture. Swift3 will parse authorization info, will
calculate StringToSign, will place it in 'X-Auth-Token'
and place some additional header with signature version info. s3token will
provide these values to keystone. keystone will
calculate signature with V4 algorithm and check it.
2) Same as first but without s3token - swift3 will send all info to
keystone itself.
3) Same as first but most authorization headers will be parsed by s3token
and s3token will send to keystone.

I prefer first scenario.
But what think keystone team?


Current implementation of S3 signature V1 verificatoin has several oddities
for me:

First oddity for me is in implementation of EC2 and S3 verification in
keystone -
ec2tokens (in keystone) takes all request parameters, calculates all that
it needs, and checks
calculated signature with user provided (Because only keystone can securely
access secret_key
by provided access_key). But signature calculation code is placed in
keystoneclient...
But s3tokens takes strange 'token' attribute (that calculated outside of
keystone), access_key and signature.
Then keystone hash token with secret_key (that was obtained from DB by
access_key) and checks this result
with provided signature.
Oddity for me is in different algorithms for similar essences.

Next oddity is in swift pipeline for S3 requests -
at 'first' request with S3 params recognized by swift3 plugin. It checks
authorization information,
validates S3 parameters, calculates StringToSign as it described in [3] and
places it in 'X-Auth-Token' header.
at next step s3token from keystonemiddleware takes X-Auth-Token (that is a
StringToSign) from header,
sends it to keystone to check authorization.
Oddity for me is in s3token that doesn't parse authorization information
unlike ec2token from keystonemiddleware.

[1] https://bugs.launchpad.net/keystonemiddleware/+bug/1473042
[2] https://bugs.launchpad.net/swift3/+bug/1411078
[3] http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html
[4]
http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html

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

Re: [openstack-dev] [neutron] FW: [Ryu-devel] [IMPORTANT]: Query regarding BGP Speaker and BGP Peer States.

2015-08-17 Thread Gal Sagie

Maybe its best to also send this to the Ryu mailing list

On Mon, Aug 17, 2015 at 4:31 PM, Vikram Choudhary 
vikram.choudh...@huawei.com wrote:

 Widening audience!



 *From:* Vikram Choudhary [mailto:vikram.choudh...@huawei.com]
 *Sent:* 17 August 2015 18:05
 *To:* ryu-de...@lists.sourceforge.net
 *Cc:* Tidwell, Ryan; Vikram Choudhary; Jaume Devesa; Numan Siddique;
 Kalyankumar Asangi; Baldwin, Carl (OpenStack Neutron)
 *Subject:* [Ryu-devel] [IMPORTANT]: Query regarding BGP Speaker and BGP
 Peer States.



 Hi All,



 We have used Ryu’s BGP speaker functionality for one of the neutron
 projects (https://review.openstack.org/#/c/207635/) and want to know BGP
 Speaker and Peer states for display purpose/s.



 With reference to this we have following question’s.



 è Does Ryu’s BGP Speaker functionality expose any API to query BGP
 Speaker and BGP Peer state?

 BGP_FSM_IDLE = 'Idle'

 BGP_FSM_CONNECT = 'Connect'

 BGP_FSM_ACTIVE = 'Active'

 BGP_FSM_OPEN_SENT = 'OpenSent'

 BGP_FSM_OPEN_CONFIRM = 'OpenConfirm'

 BGP_FSM_ESTABLISHED = 'Established'



 è If not then what will be the easiest way of getting this information?

 o   From the code, we could find “self.state” saves BGP Speaker state.
 Can we use it directly?

 o   How to get Peer’s state information.



 Any help would be appreciated.



 Thanks

 Vikram









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




-- 
Best Regards ,

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

Re: [openstack-dev] [Ceilometer][AODH] Timeout Event Alarms

2015-08-17 Thread Igor Degtiarov

Hi,

As far as I understand we have a base agreement that both specs are
appropriate and either of that two features are shifted to Mitaka cycle.

Gordon probably that question to you:
Are we going to create a new folder in spec's dir for next cycle, or we
continue discussing new specs as part of liberty?
And the second one: are we going to create special rep for AODH specs or
ceilometer-specs is ok for all new projects?

Thank you in advance,
Igor Degtiarov
Software Engineer
Mirantis Inc.
www.mirantis.com

On Fri, Aug 7, 2015 at 10:59 AM, Ryota Mibu r-m...@cq.jp.nec.com wrote:

 Hi,


 Sorry for my late response and my absent in weekly meetings...

 I'm not sure whether I captured your idea correctly, but I prefer the
 second approach now.

 I agreed the point Igor and liusheng mentioned that the second approach
 enables end users to have configurable expire-time.

 In another point of view, the first approach may affect pipeline
 performance since it have to keep event sequence state or have to access DB
 for state querying when each event received. This is just my concern, but I
 think event pipeline should be simplest and limited to have only common
 features between event data storage, event alarming and other receiver like
 audit system.


 Thanks,
 Ryota

  -Original Message-
  From: liusheng [mailto:liusheng1...@126.com]
  Sent: Wednesday, August 05, 2015 1:12 PM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Ceilometer][AODH] Timeout Event Alarms
 
  Hi,
 
  Maybe the event transformer is needed in some use cases to generate new
 events or do transformations like the samples
  handling.  but for this timeout event alarming requirement,  the
 'timeout' of alarms will be various, it not a good idea
  of changing event_pipeline.yaml to generate new events based on events
 timeout when we need an event-timeout alarm. and
  also, the access of event pipeline definitions to users is inadvisable.
 I personally think it'd better to implement the
  second option and based on Ryota's proposal.
 
  Best Regards
  Liusheng
 
 
  在 2015/8/5 3:36, gord chung 写道:
 
 
hi Igor,
 
i would suggest you go with second option as i believe your
 implementation will overlap and reuse some of the
  functionality Ryota would code for his alarm spec [1]. also, since Aodh
 is working on an independent release cycle, it'll
  give you some more time as i don't think we'd be able to get this into
 Liberty if we went the pipeline route.
 
[1]
 http://specs.openstack.org/openstack/ceilometer-specs/specs/liberty/event-alarm-evaluator.html
 
 
On 04/08/2015 10:00 AM, Igor Degtiarov wrote:
 
 
Hi folks,
 
 
On our meatup we agreed to add timeout event alarms
 [1](Event-Base Alarming part).
In ToDo task Сhoose the optimal way for timeout alerting
 implementation
 
Now we have two proposition for implementation:
 
 - first is to add timeout param in event pipeline
 (transformer part) [2]
   -- weakness of this approach is that we cannot allow
 user change config files, so only administrator
  will be able to set rules for timeout events alarms, and that is not
 what we are expecting from alarms.
 
 - second is additional optional parameters in event
 alarms description like sequence of required events
  and timeout threshold. Event alarm evaluator looks thru getting events
 and evaluates alarm if even one event from required
  sequence isn't received in set timeout.[3]
 
 
It seems that second approach is better it doesn't have
 restrictions for end user.
 
Hope for your help in choosing optimal way for
 implementation.
(In specs review there is silence now)
 
 
[1]
 https://wiki.openstack.org/wiki/Meetings/Ceilometer/Liberty_Virtual_Mid-Cycle
[2] https://review.openstack.org/#/c/162167
[3] https://review.openstack.org/#/c/199005
 
 
Igor Degtiarov
Software Engineer
Mirantis Inc.
www.mirantis.com
 
 
 
 
  __
OpenStack Development Mailing List (not for usage
 questions)
Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
--
--
gord
 
 
 
 
  __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

 __
 OpenStack Development Mailing List (not

Re: [openstack-dev] [Neutron] VPNaaS and DVR compatibility

2015-08-17 Thread Sergey Kolekonov

BTW, the similar situation is with FWaaS [1]

[1] https://bugs.launchpad.net/neutron/+bug/1485509

On Fri, Aug 7, 2015 at 4:07 AM, shihanzhang ayshihanzh...@126.com wrote:

 I have same question, I have filed a bug on launchpad:
 https://bugs.launchpad.net/neutron/+bug/1476469,
 who can help to clarify it?
 Thanks,
 Hanzhang, shi





 At 2015-08-05 00:33:05, Sergey Kolekonov skoleko...@mirantis.com
 wrote:

 Hi,

 I'd like to clarify a situation around VPNaaS and DVR compatibility in
 Neutron.
 In non-DVR case VMs use a network node to access each other and external
 network.
 So with VPNaaS enabled we just have additional setup steps performed on
 network nodes to establish VPN connection between VMs.
 With DVR enabled two VMs from different networks (or even clouds) should
 still reach each other through network nodes, but if floating IPs are
 assigned, this doesn't work.
 So my question is: is it expected and if yes are there any plans to add
 full support for VPNaaS on DVR-enabled clusters?

 Thank you.
 --
 Regards,
 Sergey Kolekonov




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




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

Re: [openstack-dev] [neutron] extension implemented by multiple plugins

2015-08-17 Thread Ihar Hrachyshka

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/17/2015 04:35 PM, Bence Romsics wrote:
 Hi All,
 
 How do I implement one extension by two plugins?
 
 If I extend the API by: * a first class resource, and * attributes
 to an already existing resource (the port resource in my case).
 
 These two parts don't make sense without each other, so I'd like
 to keep this as one extension, not two.
 

That's exactly what we needed in feature/qos: we have new QoS policy
and rules objects, and we extend networks and ports with qos_policy_id.

 Then naturally I'd like to implement: * the first class resource as
 a service plugin, and * the new port attributes as an ml2 extension
 driver.
 
 And straightforwardly I put the same extension alias into both the 
 service plugin and the ml2 extension driver. Then I get this
 error:
 
 File /opt/stack/neutron/neutron/manager.py, line 199, in
 _load_service_plugins ValueError: Multiple plugins for service
 TRUNK_PORT were configured

Indeed it does not currently allow it. But in feature/qos, we solved
it as in line 760:

https://review.openstack.org/#/c/203105/6/neutron/plugins/ml2/managers.p
y

And the feature/qos branch is scheduled to merge back into master in
next days: https://review.openstack.org/212170

So you can base your work on top of the merge patch and claim problem
solved. :)

Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJV0fO1AAoJEC5aWaUY1u57SgEIAJYy3UAjqT4NXF8CdNfy3jcv
5dw4fqktjlj0yaiOOGM+J98vi3wVTnz+qQsk+jkS5M/0hySYQyo0M8JPF38PlRIW
Jw5vjZJZjdOivn3y/fccGq7ph3T0KTYPvCyc2nThVxGxaFB/mb4TLuZlGzXh2vYt
PsIjW15V56zIhHK2oS9t32DAfd64fvz86BfpNwuizKLAqyqnO84fWysxuK8P5rnC
2S67YmP3DeC0IhVbDLNs1Gzpk4mMpQpbRIHiZR2gIVFswy4EKuwoDjDY0AgVb0zw
6+BovJNdm1BWiNbQgNnn6K2LC53Nsc95WQzLeticzvLGGyG7cz4pMyraIDoBfqg=
=OKeU
-END PGP SIGNATURE-

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

Re: [openstack-dev] [puppet] current CI status

2015-08-17 Thread Emilien Macchi

puppet-ceilometer is in fact broken for the same reason oh puppet-horizon,
so no action required, we just need to wait for
https://review.openstack.org/213688 got merged.

On Mon, Aug 17, 2015 at 8:31 AM, Emilien Macchi emilien.mac...@gmail.com
wrote:

 So we bumped our CI to Liberty last week, and added logs support in our
 jobs ( https://goo.gl/8ncRHi )

 But now, we have some failures:
 * puppet-horizon: log publisher is broken for apache, we need
 https://review.openstack.org/213688 merged and the dsvm image updated -
 no action required from our group.
 * puppet-ceilometer,manilla: liberty packages are now broken (very new).
 See https://review.openstack.org/213504 and
 https://review.openstack.org/213509 to see logs - we need to reproduce
 and track what's wrong in packaging and report it to maintainers.
 * puppet-heat,neutron,ironic are still on Kilo. Though puppet-neutron is
 ready to be bumped ( https://review.openstack.org/209294 - please review
 ) while 2 others have still broken packages - need investigation.

 I'm offline today, I'll look at this tomorrow, but feel free to give an
 hand :-)

 Thanks,
 --
 Emilien Macchi




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

[openstack-dev] [mistral] Team meeting - 08/17/2015

2015-08-17 Thread Renat Akhmerov

Hi,

This is a reminder that we’ll have a team meeting today at #openstack-meeting 
at 16.00 UTC time.

The agenda:
Review action items
Current status (progress, issues, roadblocks, further plans)
Liberty-3 progress
New meeting time
Open discussion

Add your items whether by replying to this email or by modifying 
https://wiki.openstack.org/wiki/Meetings/MistralAgenda 
https://wiki.openstack.org/wiki/Meetings/MistralAgenda.

Renat Akhmerov
@ Mirantis Inc.



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

Re: [openstack-dev] [pbr] [stable] [infra] How to generate .Z version increments on stable/liberty commits

2015-08-17 Thread Thierry Carrez

Thierry Carrez wrote:
 We need to make progress on this so that the tooling is ready when we
 switch to stable branches at the end of Liberty. Should we discuss it
 live at a cross-project meeting ? I see Doug, Robert, Clark and myself
 as necessary to the discussion, but anyone else is welcome to
 participate and help, especially stable team members :)

I added it to tomorrow's meeting agenda, Clark and Dave Walker can make
it. Hoping Robert and Doug will be around too.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [neutron] FW: [Ryu-devel] [IMPORTANT]: Query regarding BGP Speaker and BGP Peer States.

2015-08-17 Thread Vikram Choudhary

Thanks for the information.
On 17-Aug-2015 7:53 pm, Gal Sagie gal.sa...@gmail.com wrote:

 Maybe its best to also send this to the Ryu mailing list

 On Mon, Aug 17, 2015 at 4:31 PM, Vikram Choudhary 
 vikram.choudh...@huawei.com wrote:

 Widening audience!



 *From:* Vikram Choudhary [mailto:vikram.choudh...@huawei.com]
 *Sent:* 17 August 2015 18:05
 *To:* ryu-de...@lists.sourceforge.net
 *Cc:* Tidwell, Ryan; Vikram Choudhary; Jaume Devesa; Numan Siddique;
 Kalyankumar Asangi; Baldwin, Carl (OpenStack Neutron)
 *Subject:* [Ryu-devel] [IMPORTANT]: Query regarding BGP Speaker and BGP
 Peer States.



 Hi All,



 We have used Ryu’s BGP speaker functionality for one of the neutron
 projects (https://review.openstack.org/#/c/207635/) and want to know BGP
 Speaker and Peer states for display purpose/s.



 With reference to this we have following question’s.



 è Does Ryu’s BGP Speaker functionality expose any API to query BGP
 Speaker and BGP Peer state?

 BGP_FSM_IDLE = 'Idle'

 BGP_FSM_CONNECT = 'Connect'

 BGP_FSM_ACTIVE = 'Active'

 BGP_FSM_OPEN_SENT = 'OpenSent'

 BGP_FSM_OPEN_CONFIRM = 'OpenConfirm'

 BGP_FSM_ESTABLISHED = 'Established'



 è If not then what will be the easiest way of getting this information?

 o   From the code, we could find “self.state” saves BGP Speaker state.
 Can we use it directly?

 o   How to get Peer’s state information.



 Any help would be appreciated.



 Thanks

 Vikram









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




 --
 Best Regards ,

 The G.

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


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

[openstack-dev] [nova] compute - conductor and version compatibility

2015-08-17 Thread Markus Zoeller

I have the impression that more and more people try to run OpenStack
in a mixed-releases-mode and face some troubles to understand how
the capabilities and limitations look like. For example, the reporter
of [1] runs a nova-conductor (Juno) with a nova-compute (Kilo). I tried
in comment #3 of [1] to rationalize if this is a valid setup or not
and I failed... 
If someone with more experience and knowledge could help there and
clarify it also for other users in the future, that would be awesome.

[1] https://bugs.launchpad.net/nova/+bug/1483321

Regards,
Markus Zoeller (markus_z)


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

[openstack-dev] [neutron] FW: [Ryu-devel] [IMPORTANT]: Query regarding BGP Speaker and BGP Peer States.

2015-08-17 Thread Vikram Choudhary

Widening audience!

From: Vikram Choudhary [mailto:vikram.choudh...@huawei.com]
Sent: 17 August 2015 18:05
To: ryu-de...@lists.sourceforge.net
Cc: Tidwell, Ryan; Vikram Choudhary; Jaume Devesa; Numan Siddique; Kalyankumar 
Asangi; Baldwin, Carl (OpenStack Neutron)
Subject: [Ryu-devel] [IMPORTANT]: Query regarding BGP Speaker and BGP Peer 
States.

Hi All,

We have used Ryu's BGP speaker functionality for one of the neutron projects 
(https://review.openstack.org/#/c/207635/) and want to know BGP Speaker and 
Peer states for display purpose/s.

With reference to this we have following question's.

è Does Ryu's BGP Speaker functionality expose any API to query BGP Speaker and 
BGP Peer state?

BGP_FSM_IDLE = 'Idle'

BGP_FSM_CONNECT = 'Connect'

BGP_FSM_ACTIVE = 'Active'

BGP_FSM_OPEN_SENT = 'OpenSent'

BGP_FSM_OPEN_CONFIRM = 'OpenConfirm'

BGP_FSM_ESTABLISHED = 'Established'

è If not then what will be the easiest way of getting this information?

o   From the code, we could find self.state saves BGP Speaker state. Can we 
use it directly?

o   How to get Peer's state information.

Any help would be appreciated.

Thanks
Vikram

--
___
Ryu-devel mailing list
ryu-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][fwaas] APAC friendly meeting

2015-08-17 Thread Sean M. Collins

Hi,

During last week's Firewall as a Service IRC meeting, we discussed the
possibility of having an Asia-Pacific timezone friendly meeting. If you
are in that timezone - please let me know what time (UTC) works. 

I am US EST, and we have a lot of US PST attendees (I think) - so here's what 
is possible:

http://www.timeanddate.com/worldclock/meetingtime.html?iso=20150817p1=224p2=102p3=198

I'm more of a night-owl than a morning person, so I can do 2300 UTC,  UTC, 
or
0100 UTC, so it is during the evening period of my local time, and the
morning hours of APAC.

Ideally we'd alternate, with the odd week being the current time, and
the even week being the new APAC friendly time.


-- 
Sean M. Collins

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

Re: [openstack-dev] [Fuel] Get rid of run_test.sh in Fuel Client

2015-08-17 Thread Jay Pipes


On 08/17/2015 08:50 AM, Roman Prykhodchenko wrote:

Hi Fuelers!

I was working on enabling Python tests in Fuel Client to run on
OpenStack CI and I figured out that we actually have a piece of
legacy code which can be removed now. That piece is run_tests.sh
file. For those who’s not aware, that script allows to run different
tests under different environments. I don’t know how it was a
thousand years ago when I was not involved to Fuel project, but the
situation at this particular moment looks like that:

- Tests are actually orchestrated by tox - The biggest job of
run_tests.sh is to translate its options to tox’es options - The only
useful job of run_tests.sh is to start Nailgun correctly for
functional tests

As you can see the profit of that script is tiny. However, the
problems it brings are pretty much big and looks as follows:

- It is unstable — tiniest changes to tests require big changes to
the script - The CLI it provides is confusing - Working on that file
looks like doing the same job that is already done in tox - Among the
active Fuel Client’s community there are only a few guys who are
proficient in bash enough, to support that script effectively


My proposal is to extract the code responsible for starting Nailgun
into to a small utility script and let tox do the rest by removing
run_test.sh completely. That will bring us the following advantages:

- No need to support a complex bash script. - Closer to being able to
run functional tests on DSVM gates. - Test CLI will be more
compatible with other OpenStack projects.

I foresee a few questions and the answers for them follow:

Q: How is verify-job from FuelCI going to run tests without that
file? A: Fuel Client has its own job on FuelCI, so it will be just
necessary to change the invocation there.

Q: But run_test.sh is in all Fuel projects, shouldn’t we keep them
all similar. A: Why does it have to be similar? This kind of
difference is minor and it brings more advantages, than just having
the same file. In fact the set of options in run_tests.sh is already
different from run_tests.sh in fuel-web.

Q: Why should we look ad other OpenStack projects? A: Fuel is living
in the OpenStack ecosystem so being compatible with it is a big
advantage. It’s also a must for going big tent.


+1.

Just make sure any documentation that might refer to run_tests.sh is 
updated accordingly :)


Best,
-jay

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

[openstack-dev] [tripleo] Upgrades, Releases Branches

2015-08-17 Thread Steven Hardy

Hi all,

Recently I had some discussion with folks around the future strategy for
TripleO wrt upgrades, releases and branches, specifically:

- How do we support a stable TripleO release/branch that enables folks to
  easily deploy the current stable release of OpenStack
- Related to the above, how do we allow development of TripleO components
  (and in particular t-h-t) to proceed without imposing undue constraints
  on what new features may be used (e.g new-for-liberty Heat features which
  aren't present in the current released OpenStack version)
- We're aiming to provide upgrade support, thus from and to which versions?

I know historically TripleO has taken something of a developer and/or
continuous deployment model for granted, but I'd like to propose that we
revisit that discusion, such that we move towards something that's more
consumable by users/operators that are consuming the OpenStack coordinated
releases.

The obvious answer is a stable branch for certain TripleO components, and
in particular for t-h-t, but this has disadvantages if we take the
OpenStack wide no feature backports approach - for example upgrade
support to liberty could be considered a feature, and many other TripleO
features are really more about making features of the deployed OpenStack
services consumable.

I'd like propose we take a somewhat modified release branch approach,
which combines many of the advantages of the stable-branch model, but
allows for a somewhat more liberal approach to backports, where most things
are considered valid backports provided they work with the currently
released OpenStack services (e.g right now, a t-h-t release/kilo branch
would have to maintain compatibility with a kilo Heat in the undercloud)

I know in the past stable branches have been discounted due to capacity
concerns, but the reality atm is such branches are likely to be maintained
downstream due to release-orientated efforts based on TripleO (e.g
rdo-manager) anyway, so it could be better for the TripleO community if we
maintained such branches upstream, where they can be consumed more directly
by such downstream projects.

This could have several benefits:

- TripleO can much more easily offer an easy end-to-end deployment solution
  for released OpenStack versions, e.g you always use release/kilo to
  deploy kilo OpenStack, and in future steps may be defined for upgrading
  between branches when upgrades are implemented and we support upgrading
  e.g from kilo to liberty or whatever.
- RDO (and RDO Manager in particular) can consume the release branches to
  provide package-based TripleO, and effort won't be potentially duplicated
  over downstream efforts, since we maintain the release-orientated TripleO
  components directly upstream.  Obviously this benefits any projects
  downstream in a similar way.

One way to minimise the overhead of maintaing such a branch could be to
implement a bot which automatically proposes commits which land in master
to the branch (using Depends-On to maintain the history order).

Reviewers would then monitor the release/kilo queue, and -2 any changes
which aren't appropriate to backport (e.g use new Heat features or some
other backwards incompatiblity), which would cause the bot to drop the
patch and rebase.  An alternative to this would be a commit message tag
which caused the commit to be picked up (or not).

Obviously there will be merge conflicts which require manual fixup
sometimes (in which case the bot would commit with the conflicts block
intact and propose the patch for manual fixup).

Interested to hear feedback on the idea, as well as if anyone has direct
experience of implementing the bot/automation pieces.

Steve

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

[openstack-dev] [openstack][oslo.service] Manage of openstack services by ProcessLauncher

2015-08-17 Thread mhorban

Most of openstack services use ProcessLauncher(located in oslo.services) 
to run services, fork new worker processes, reload configuration, etc. 
Initialization of services in master process usually contains opening of 
sockets, so that socket will be inherited in child processes. Then 
master(parent) process spawns(with fork call) children. Communication 
between master process and children is implemented with signals, for 
example when master process wants to shutdown children it sends SIGTERM 
signal to children, to reload children config master process sends 
SIGHUP signal.


I would like to discuss three things:
1. Behaviour of reloading configuration in children processes.
2. Additional way to control of master process.
3. Communication between master and children processes.

1. Behaviour of reloading configuration in children processes.
Now we can reload processes by sending SIGHUP to master process. Master 
process reloads its own configuration and sends SIGHUP signal to 
children. When child process receives SIGHUP signal it loads config 
file, stops and starts service. During stopping-starting service new 
config options usually don't applied because there should be written a 
lot of code to manage cofiguration changes. rpodolyaka expressed idea to 
shutdown children during reloading configuration and respawn new 
workers. This approach frees us of implementing a huge amount of 
service-related code for reloading configuration of specific objects. 
Apache and NGINX uses the same reloading approach: gracefully stop 
children and start new child instances.


2. Additional way to control of master process.
Right now we can control ProcessLauncher by sending signals to master 
process. It is the only way to manage it. The problem is that such 
approach is not platform independent. We already faced an issue: Windows 
doesn't support SIGHUP signal, so part of functionality is inaccessible 
in Windows :(. Usually process containers like ProcessLauncher could be 
managed by CLI too. What do you think about creating listening interface 
for incoming commands?


3. Сommunication between master and children processes.
Master process uses signals to control children. Since many signals are 
not supported on some platforms I suggest to replace signal mechanism 
with pipes. Each of children will listen to input commands on one side 
of pipe and master process will write commands on the other side of pipe.


Any idea?

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

[openstack-dev] [puppet] current CI status

2015-08-17 Thread Emilien Macchi

So we bumped our CI to Liberty last week, and added logs support in our
jobs ( https://goo.gl/8ncRHi )

But now, we have some failures:
* puppet-horizon: log publisher is broken for apache, we need
https://review.openstack.org/213688 merged and the dsvm image updated - no
action required from our group.
* puppet-ceilometer,manilla: liberty packages are now broken (very new).
See https://review.openstack.org/213504 and
https://review.openstack.org/213509 to see logs - we need to reproduce and
track what's wrong in packaging and report it to maintainers.
* puppet-heat,neutron,ironic are still on Kilo. Though puppet-neutron is
ready to be bumped ( https://review.openstack.org/209294 - please review )
while 2 others have still broken packages - need investigation.

I'm offline today, I'll look at this tomorrow, but feel free to give an
hand :-)

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

Re: [openstack-dev] [neutron][vmware][stable] vmware-nsx has no releases

On 2015-08-17 14:05:38 +0200 (+0200), Ihar Hrachyshka wrote:
[...]
 I tried to follow the dumb way of generating a tarball from github,
 but pbr complains about lack of sdist or git when I call to 'setup.py
 build'. Putting egg-info directory inside the tarball does not help.

In a clean checkout of the branch, run:

tox -e venv python setup.py sdist

Then you should have a tarball in the dist subdirectory.

 I think it would be better for everyone if tags and tarballs came from
 upstream.
[...]

I completely agree.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [cinder] [third-party] ProphetStor CI account

HI Adhishek:

I add “AllowOverride all” option and point to the OpenStack CI log 
folder in the apache configuration.

Directory /var/log/prophetstor_ci

Options Indexes FollowSymLinks

AllowOverride All

Require all granted

/Directory

and set the .htaccess file in the /var/log/prophetstor_ci.

.htaccess contents as below:

Options Indexes FollowSymLinks

Order allow,deny

Allow from all

RewriteEngine On

RewriteCond   %{HTTP:Accept-Encoding} gzip

RewriteCond   %{LA-U:REQUEST_FILENAME}.gz -f

RewriteRule   ^(.+)$ $1.gz [L]

FilesMatch .*\.gz$

  ForceType text/html

  AddDefaultCharset UTF-8

  AddEncoding x-gzip gz

/FilesMatch

reference: http://httpd.apache.org/docs/2.2/howto/htaccess.html

 

 

From: Abhishek Shrivastava [mailto:abhis...@cloudbyte.com] 
Sent: Tuesday, August 18, 2015 1:05 PM
To: Rick Chen rick.c...@prophetstor.com
Subject: Re: [openstack-dev] [cinder] [third-party] ProphetStor CI account

 

Hi Rick,

 

I know we had to put the following for making logs browsable, but where exactly 
to put it, I mean in which file can you specify it clearly.

 

On Tue, Aug 18, 2015 at 9:28 AM, Rick Chen rick.c...@prophetstor.com 
mailto:rick.c...@prophetstor.com  wrote:

HI Adhishek:

 

One more information, how are you catching the logs and making it browsable?

Do you mean item[6]? I just follow OpenStack Third-part CI document. 
You can reference 
http://docs.openstack.org/infra/system-config/third_party.html#faq-frequently-asked-questions.
 Add this configuration in our web server.

 

 

On Tue, Aug 18, 2015 at 7:10 AM, Rick Chen rick.c...@prophetstor.com 
mailto:rick.c...@prophetstor.com  wrote:

HI Abhishek:

For you information in the below. 

 

HI Mike:

What I have missed it?

 

On Mon, Aug 17, 2015 at 8:52 PM, Rick Chen rick.c...@prophetstor.com 
mailto:rick.c...@prophetstor.com  wrote:

HI Mike:
I completed to refine our CI configuration to follow Ramy's
comments. Does any missed or other attention I need respect?

[1] Add export DEVSTACK_GATE_TEMPEST_REGEX=volume to verify all
cinder volume testing.
[2] Add each service configuration in the log.

http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds 
http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-dsvm-tempest-cinder-ci/5100/logs/etc/
 
vm-tempest-cinder-ci/5100/logs/etc/
[3] Add email alert when the devstack build failed to instead of you
notify to me.

 

Can you please tell me that how 

 

you have done the [3].

Use Jenkins email E-mail Notification.

Manage Jenkins  Configure System  E-mail Notification

Add SMTP server and Default user e-mail suffix. Use advanced 
button to verify email seting.

Add Email notification in you job.

CI job  “Add post-build action”  “Email Notification”  
add Recipients.

Reference link:  
https://www.safaribooksonline.com/library/view/jenkins-the-definitive/9781449311155/ch08s02.html
 
https://www.safaribooksonline.com/library/view/jenkins-the-definitive/9781449311155/ch08s02.html

 

 

[4] Integrate VMware snapshot revert feature in the Jenkins master
to clean CI slave machine OS environment that avoid the devstack building
failed due to previous devstack garbage configuration.

 

Also, the process of CI slave snapshot revert mentioned in [4].

Add Jenkins plugin agent: vSphere Cloud Plugin

Configure vSphere Cloud in Jenkins master.

Manage Jenkins  Configure System  vSphere Cloud

Add vSphere hose, user name, password.

Configure vSphere Slave.

Add slave node and select “Slave virtual computer running under 
vSphere Cloud”

Manage Jenkins  Manage Nodes  New node  select “Slave virtual 
computer running under vSphere Cloud”

Add your vSphere information in this configuration page.

Reference link:  
https://wiki.jenkins-ci.org/display/JENKINS/vSphere+Cloud+Plugin 
https://wiki.jenkins-ci.org/display/JENKINS/vSphere+Cloud+Plugin

 

 

[5] Latest CI result for you reference.

http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds 
http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-dsvm-tempest-cinder-ci/5100/logs/
 
vm-tempest-cinder-ci/5100/logs/
http://download.prophetstor.com/prophetstor_ci/

[6] Logs need to be browsable online.
Add Rewrite module and rule in the apache configuration.

my gerrit account:  prophetstor-ci
   gerrit account email:prophetstor...@prophetstor.com 
mailto:prophetstor...@prophetstor.com 

Many thanks.

 

-- 

  
https://docs.google.com/uc?export=downloadid=0Byq0j7ZjFlFKV3ZCWnlMRXBCcU0revid=0Byq0j7ZjFlFKa2V5VjdBSjIwUGx6bUROS2IrenNwc0kzd2IwPQ
 

Thanks  Regards,

Abhishek

 http://www.cloudbyte.com Cloudbyte Inc.

Re: [openstack-dev] [openstack-infra][third-paty][CI][nodepool]Using Nodepool for creating slaves.

2015-08-17 Thread Abhishek Shrivastava

Also adding the following:

   -
   
https://github.com/openstack-infra/project-config/tree/master/nodepool/elements

Does this means that we don't have to take care of creating slaves(i.e;
installing slave using scripts as we have done in master) and it will be
done automatically, and also we don't have to configure slaves in Jenkins.

A bit confusing for me so if anyone can explain it to me then it will be
very helpful.

On Tue, Aug 18, 2015 at 11:11 AM, Abhishek Shrivastava 
abhis...@cloudbyte.com wrote:

 Hi Folks,

 I was going through Ramy's guide for setting up CI, there I found out the
 following:

-

 https://github.com/rasselin/os-ext-testing#setting-up-nodepool-jenkins-slaves

 But I don't get the fact on how to create the image, also what major
 settings need to be done to make the config perfect for use. Can anyone
 help me with that?

 --


 *Thanks  Regards,*
 *Abhishek*
 *Cloudbyte Inc. http://www.cloudbyte.com*




-- 


*Thanks  Regards,*
*Abhishek*
*Cloudbyte Inc. http://www.cloudbyte.com*
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [openstack-infra][third-paty][CI][nodepool]Using Nodepool for creating slaves.

2015-08-17 Thread Abhishek Shrivastava

Hi Folks,

I was going through Ramy's guide for setting up CI, there I found out the
following:

   -
   https://github.com/rasselin/os-ext-testing#setting-up-nodepool-jenkins-slaves

But I don't get the fact on how to create the image, also what major
settings need to be done to make the config perfect for use. Can anyone
help me with that?

-- 


*Thanks  Regards,*
*Abhishek*
*Cloudbyte Inc. http://www.cloudbyte.com*
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] compute - conductor and version compatibility

2015-08-17 Thread Chris Friesen


On 08/17/2015 08:59 AM, Jay Pipes wrote:

On 08/17/2015 10:41 AM, Markus Zoeller wrote:

I have the impression that more and more people try to run OpenStack
in a mixed-releases-mode and face some troubles to understand how
the capabilities and limitations look like. For example, the reporter
of [1] runs a nova-conductor (Juno) with a nova-compute (Kilo). I tried
in comment #3 of [1] to rationalize if this is a valid setup or not
and I failed...
If someone with more experience and knowledge could help there and
clarify it also for other users in the future, that would be awesome.

[1] https://bugs.launchpad.net/nova/+bug/1483321


No, that's not valid behaviour. You need to upgrade the controller
infrastructure (conductor, API nodes, etc) before any compute nodes.


Is this documented somewhere?

I did a bit of digging and couldn't find anywhere that explicitly required that 
for the J-K upgrade.  Certainly it was documented for the I-J upgrade.


Chris


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

[openstack-dev] [ironic] weekly meeting time

2015-08-17 Thread Ruby Loo

Hi,

Starting last week, we are no longer alternating meeting times. Going
forward, the ironic meetings will be held weekly on Mondays at 1700 UTC.
(For more information on our weekly meetings, see [0]).

There had been a friendly discussion about this [1] and it was mentioned in
last week's meeting [2].

--ruby


[0] https://wiki.openstack.org/wiki/Meetings/Ironic
[1] http://lists.openstack.org/pipermail/openstack-dev/2015-July/069363.html
[2] @17:04:59,
http://eavesdrop.openstack.org/meetings/ironic/2015/ironic.2015-08-10-17.00.log.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cinder] Midcycle Sprint Summary

2015-08-17 Thread Mike Perez

A *summary* of the Cinder midcycle sprint, in attempt to keep your attention.
Full meeting notes available [1].

Image Caching
=
Glance Cinder backend store + Cinder Image Caching are so similar, it would
just be confusing to operators. We'll document only about the Cinder Image
Caching since the Glance backend store is limited in comparison.


Revisit Spec Review
===
The PTL in the future will be the only one to +2/A specs after sufficient +1's
have been given, and notice of approval to follow in the Cinder meeting.


When Specs and Blueprints are needed

Done https://wiki.openstack.org/wiki/Cinder/how-to-contribute-new-feature


People can guess UUID's that don't belong to them
=
Who cares. In past security discussions this has been a moot point.


Update Hypervisor about extending attached volumes
==
Add support to os-brick, but the Nova team has to be fine with this only
supporting Libvirt for now.


Microversions
=
We're doing it.


Getting rid of API extensions
=
Move obvious things over (volume attach, type manager) to core API controllers.
Deprecate existing extensions and have these use core API controller code. Get
rid of the silly os- prefix in endpoints. Use Microversions to know when the
API has the new extensions in core controllers.


Third Party CI for target drivers and zone manager drivers
==
Yes. This is already happening for Brocade and Cisco in Liberty!


Cinder - Nova API communication
=
Agreed on how the Cinder API should be used. It requires changes and
a Microversion bump on the Nova side. Design summit session to follow.


Out of tree drivers
===
No.


Exposing force-detach of a volumes
==
Yes, this will be in nova-manage in Liberty.


HA and Cinder
=
We need cross project consensus first. There are existing issues that can be
fixed without a DLM. Fix those first. Mike Perez will be leading cross project 
discussion at the summit.


Replication V2
==
John Griffith did extreme programming with the group and posted a review.
A limited replication feature with async and manual failover should be in
Liberty.


ABC classes for each driver feature
===
Keeping the current solution [2].


[1] - https://etherpad.openstack.org/p/cinder-meetup-summer-2015
[2] - http://lists.openstack.org/pipermail/openstack-dev/2015-June/067563.html

-- 
Mike Perez

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

[openstack-dev] [mistral] Team meeting minutes - 08/17/2015

2015-08-17 Thread Renat Akhmerov

Thanks for joining us today for the meeting.

Meeting minutes: 
http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-08-17-16.02.html
 
http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-08-17-16.02.html
Meeting log: 
http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-08-17-16.02.log.html
 
http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-08-17-16.02.log.html

The next meeting will be on Aug 24 at the same time. See you soon.

Renat Akhmerov
@ Mirantis Inc.



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

Re: [openstack-dev] [neutron][vmware][stable] vmware-nsx has no releases

2015-08-17 Thread Gary Kotton

Hi,
There are still a few extra stable back ports that we need to make.
In addition to this I think that we should try and sync all of the etrnal 
projects for a common release.
Thanks
Gary

From: mest...@mestery.commailto:mest...@mestery.com 
mest...@mestery.commailto:mest...@mestery.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, August 17, 2015 at 9:59 AM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron][vmware][stable] vmware-nsx has no 
releases

On Mon, Aug 17, 2015 at 7:05 AM, Ihar Hrachyshka 
ihrac...@redhat.commailto:ihrac...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi VmWare folks,

I wonder whether we can get some actual release tags for stable/kilo
branch of the repo. Lack of any consumable tarballs does not help
packagers that want to just get the tarball from pypi and use it as a
base.

I tried to follow the dumb way of generating a tarball from github,
but pbr complains about lack of sdist or git when I call to 'setup.py
build'. Putting egg-info directory inside the tarball does not help.

I think it would be better for everyone if tags and tarballs came from
upstream.

I suspect other spinned-out neutron drivers could have the same
problem. Can we somehow make sure they are releasing deliverables and
not just git repo?

We will talk about this at the meeting today but yes, the plan is to get 
releases for these. So far we've only discussed stable releases, but I think 
the plan to release master snapshots would be good. It would give the packagers 
a chance to package these.

Ihar, lets work to make this happen tomorrow or Wednesday.

Thanks,
Kyle


Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJV0c4PAAoJEC5aWaUY1u57M2cIALuH2MByojn7N1byCV4ctTal
NPsUTgFyzDEXSU1QSgobR6x1uP8hYBW2RSUqnh4tR+SoYz/vmF1IvwXl53tb3Jnq
4MTwXbom3xPgjUYsUep5TAhPglMXf4LwnTYejhqc78IOlNg7tAC0U/yA2ZitFhm2
5zWsec1zggsku4aIMCz06bFwgQHwYl57uHBB/iqO+fbRIGZLkcGrbjiucKIlQqsF
uv9GoymuwOEVjmTtooQBoVQ0J2f/yZYswcRBExbJU78eIP89+A2kDL9nA4fFFhCl
b5Yus6oJDn/XMaU8PWZ8TptWEOY3Z80wbCRZk27FNObSb6yLs+2ZS7Rge+ZCz5s=
=VP83
-END PGP SIGNATURE-

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

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

Re: [openstack-dev] [Ceilometer][AODH] Timeout Event Alarms

2015-08-17 Thread Igor Degtiarov

Gordon thanks for quick answer.

I'll add a patch with new dir for mitaka specs and move my specs there.


cheers,

Igor Degtiarov
Software Engineer
Mirantis Inc.
www.mirantis.com

On Mon, Aug 17, 2015 at 7:02 PM, gord chung g...@live.ca wrote:

 good questions...

 On 17/08/2015 10:19 AM, Igor Degtiarov wrote:

 Gordon probably that question to you:
 Are we going to create a new folder in spec's dir for next cycle, or we
 continue discussing new specs as part of liberty?


 we can create a new dir for M* cycle specs. as mentioned in last week's
 meeting, even though we don't have a exact date for feature freeze, unless
 it's a small bug size spec, Liberty specs are closed. feel free to create a
 patch for new M* dir

 And the second one: are we going to create special rep for AODH specs or
 ceilometer-specs is ok for all new projects?


 we'll track aodh specs under ceilometer now -- i don't want to increase
 the number of repos we need to monitor unless we notice Aodh specs are too
 much to handle.

 cheers,


 --
 gord


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

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

Re: [openstack-dev] [neutron][vmware][stable] vmware-nsx has no releases

On Mon, Aug 17, 2015 at 7:42 AM, Jeremy Stanley fu...@yuggoth.org wrote:

 On 2015-08-17 14:05:38 +0200 (+0200), Ihar Hrachyshka wrote:
 [...]
  I tried to follow the dumb way of generating a tarball from github,
  but pbr complains about lack of sdist or git when I call to 'setup.py
  build'. Putting egg-info directory inside the tarball does not help.

 In a clean checkout of the branch, run:

 tox -e venv python setup.py sdist

 Then you should have a tarball in the dist subdirectory.

  I think it would be better for everyone if tags and tarballs came from
  upstream.
 [...]

 I completely agree.


I agree as well.


 --
 Jeremy Stanley

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

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

Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities

2015-08-17 Thread Fox, Kevin M

1. yes, but probably only if its a short list. It may be feasible to show it 
only if there are 5 or less pages, and maybe just load all pages of data and 
paginate it on the client. If too big, ask the user to refine their search? Or 
always paginate to 5, and then the 6th page have a page requesting further 
refinement?

2. Not sure what the difference between searching and filtering is in this 
context? something like facets? If so, probably the 5 or less thing would work 
here too.

3. Yes, but again, probably within a smaller set of pages?

Thanks,
Kevin

From: Kruithof, Piet [pieter.c.kruithof...@hp.com]
Sent: Sunday, August 16, 2015 9:41 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination support for 
Identity dashboard entities

I like Michael’s response because it moved the thread towards identifying 
actual user needs before digging into the technical feasibility.  IMHO, it 
would be helpful to have a few people on the list answer his questions:

1 - Do users want to page through search results?


2 - Do users want to page through filter results? (do they use filter results?)


3 - If they want to page, do they want to be able to go back a page and/or know 
their current page?


I understand that even if we answer “yes” to all three questions that there 
could be issues around implementation, but at least we’ll know a gap exists.


Piet Kruithof
Sr UX Architect, HP Helion Cloud
PTL, OpenStack UX project

For every complex problem, there is a solution that is simple, neat and wrong.”

H L Menken


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

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

Re: [openstack-dev] [neutron][qos] request to merge feature/qos back into master

I've pushed the patch into the merge queue now. Any nits people find at
this point we'll address post merge.

Awesome work QoS team!

On Mon, Aug 17, 2015 at 9:56 AM, Ihar Hrachyshka ihrac...@redhat.com
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 So the patch in question sit there for some time, and honestly, I
 haven't seen much interest from reviewers to take a look at it, apart
 from Assaf who played with the code and reported a bunch of minor issues
 .

 I think Kyle's plan was to wait until Fri and then merge.

 We had a git conflict on Fri though, so today I respin the patch
 again, hoping that it will either get more reviews or it's merged
 before we hit another conflict that can be inflicted by any new db
 migration.

 Ihar

 On 08/12/2015 09:55 PM, Ihar Hrachyshka wrote:
  Hi all,
 
  with great pleasure, I want to request a coordinated review for
  merging feature/qos branch back to master:
 
  https://review.openstack.org/#/c/212170/
 
  Since it's a merge patch, gerrit fails to show the whole diff that
  it introduces into master. To get over it, fetch the patch:
 
  $ git review -d 212170
 
  and then check the difference:
 
  $ git fetch origin  git diff origin/master...
 
  I think we should stick to review process originally suggested at
  [1]. Specifically, since it's not reasonable to expect the whole
  feature branch to be reviewed by a single person, I hope multiple
  people will assign themselves to the job and split the pieces to
  review based on devref document that describes the feature [2]
  (Note that a new RPC push/pull mechanism is described in a separate
  devref section [3]).
 
  Note that we don't expect to tackle all review comments, however
  tiny, in feature/qos. We are happy to handle major flaws there, but
  for minor stuff, it's good to proceed in master. Nevertheless we
  are happy to get minors too and collect them for post-merge.
 
  Things we have in the tree:
 
  - server: QoS API extension; QoS core resource extension; QoS ML2
  extension driver; QoS versioned objects + base for new objects;
  QoS supported rule types mechanism for ML2; QoS notification
  drivers mechanism to update SDN controllers;
 
  - RPC: new push/pull mechanisms for versioned objects to propagate
  QoS objects into the agents;
 
  - agent side: new L2 agent extensions mechanism, integrated into
  OVS and SR-IOV agents; QoS l2 agent extension; OVS and SR-IOV QoS
  drivers; ovs_lib and pci_lib changes.
 
  I suggest to split review into following logical pieces:
 
  - API controller + service plugin + API tests; - Versioned objects:
  neutron.objects.* - ML2: supported_qos_rule_types mechanism,
  extension driver, update for get_device_details payload; - RPC
  mechanism (push/pull), resource manager, registries + notification
  drivers integration; - l2 extensions (manager, base interface) +
  qos extension; - OVS integration with extension manager + OVS QoS
  driver + ovs_lib changes; - SR-IOV agent integration with extension
  manager + SR-IOV QoS driver + pci_lib changes; - functional tests.
 
  We will also need to update the spec:
  https://review.openstack.org/#/c/199112/
 
  Included test coverage:
 
  - unit tests; - API tests; - functional tests (more scenarios to
  come in master); - fullstack tests [4] (not in the tree since we
  need to merge client and base fullstack patches first).
 
  We have client patches up for review [5][6] and expect them to go
  in after merge of server component.
 
  We hope that we'll make fullstack in before closing the blueprint
  in this cycle.
 
  [1]:
  http://lists.openstack.org/pipermail/openstack-dev/2015-July/069188.ht
 ml
 
 
 [2]:
  http://git.openstack.org/cgit/openstack/neutron/tree/doc/source/devref
 /q
 
 
 uality_of_service.rst?h=feature/qos
  [3]:
  http://git.openstack.org/cgit/openstack/neutron/tree/doc/source/devref
 /r
 
 
 pc_callbacks.rst?h=feature/qos
  [4]: https://review.openstack.org/202492 [5]:
  https://review.openstack.org/189655 [6]:
  https://review.openstack.org/198277 [7]:
  https://review.openstack.org/202061
 
  __
 
 
 
 OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQEcBAEBCAAGBQJV0fYnAAoJEC5aWaUY1u57rtsH/iaQ5HCRuFDbhFsFAkGeW/hB
 gn/pR9lmx/hXUIkEWfGPIsgtEnuA8nIQ3knwLfvkrPxR60YHkCK5YeRDaTVd0IQb
 oV5njw3eMJablTtquPybSzUljfx+oCQ2pxwhXgWAcj5KucksXLcvC+lkfk5uQ1OT
 iFum1jCmZ+7Te8uPdjkgGxxxpLjnJJs0Na6i+GhRppRc/HK77jM31MggfA3dJw9y
 cdB0JN3w2tT4wbjtmtCsVgKVWeDuuKXlnZjmI0Do1Qm1YDC0NNPLNGcBTV70vyPB
 B8lGyk9kvtbzSQ701T3LEp8hRIL6Oto8cHRrt3jkfygrlXPQL8x1pwtjSD59bXU=
 =s4FB
 -END PGP SIGNATURE-

 __
 OpenStack Development Mailing List (not for usage

[openstack-dev] [neutron] New networking-calico project

2015-08-17 Thread Neil Jerram

I'd like to announce networking-calico, a new project within the Neutron
stadium to provide OpenStack integration pieces for Project Calico
[1][2].  In a sentence, Calico is a backend that uses routing and
iptables to provide IP-level connectivity between VMs, instead of - as
most Neutron backends do - using bridging to provide an effective L2
broadcast domain.  You can read about why that might be interesting at
[1][2], or in more OpenStack-centric terms at [3].

Calico's semantics are not fully describable by the current Neutron API,
and I plan to contribute to API and data model work to address this. 
Discussion about that has already begun at [3] and in the email thread
about 'routed, segmented networks' [4], and I hope it will continue
through the end of this cycle, in Tokyo, and during Mitaka.

For a practical deployment, though, and with some semantic caveats [5],
Calico-style connectivity can be used already in an OpenStack cluster - 
and we have several operator partners interested in and trialling that. 
My team has been developing and refining this since Icehouse, using
Calico-specific patches to Nova and Neutron, but we are now within
touching distance, we think, of working with vanilla OpenStack when
Liberty is released.  We released our v1.0 milestone of the core Calico
code last week [14], our Nova patches were merged in July, and we have
the following core Neutron patches currently in review.

[6] https://review.openstack.org/#/c/205181/
[7] https://review.openstack.org/#/c/206078/
[8] https://review.openstack.org/#/c/206077/
[9] https://review.openstack.org/#/c/206079/

These patches have been through many cycles of review - thanks in
particular to Cedric and Oleg - and are now, I believe, fully tested and
polished.  They make small generalizations to the DHCP agent code so
that a networking-calico-provided interface driver will be able to use
it, instead of having to provide a parallel DHCP agent implementation. 
I would particularly appreciate if Neutron core reviewers would consider
reviewing and approving [6] and [7] now, as they are the changes that
would be messiest if I had to reimplement them out-of-tree using some
kind of subclassing approach.

Then the plan for networking-calico is that it will contain docs, an ML2
mechanism driver, a DHCP interface driver, and a Devstack plugin for
Calico.  These aren't yet at [10], but I will be getting on with that
shortly, and you can already see those pieces in other forms (which will
be retired) at [11], [12] and [13].  Hence, within the next few weeks, I
hope that networking-calico and the vanilla Neutron tree (+ the core
Calico project) will provide a complete demonstration of this kind of
networking.

Looking ahead, we will also set up a regular IRC meeting for people
interested in networking-calico.  I'll write again at the time, but
please do let me know if you'd like to be pinged when that is being
arranged.

Many thanks for your attention - please do let me know if you have
questions!

Neil



[1] http://www.projectcalico.org/
[2] http://docs.projectcalico.org/en/latest/
[3] https://review.openstack.org/#/c/198439/
[4] http://lists.openstack.org/pipermail/openstack-dev/2015-July/070028.html
[5] http://docs.projectcalico.org/en/latest/calico-neutron-api.html
[10] https://git.openstack.org/cgit/openstack/networking-calico
[11] https://github.com/projectcalico/calico/tree/master/calico/openstack
[12] https://review.openstack.org/#/c/197578/
[13] https://github.com/projectcalico/calico/tree/routed/devstack
[14] http://www.projectcalico.org/announcing-calico-v1-0/


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

Re: [openstack-dev] [Fuel][MOS][Bootstrap] Please try Ubuntu bootstrap in MOS 7.0

2015-08-17 Thread Mike Scherbakov

+ I've just discussed UX for Ubuntu bootstrap in #fuel-dev [1], which
doesn't look very clear at the moment.

Mikhail - can you please help to clear it up? Namely, can I build Ubuntu
bootstrap on Fuel master without direct Internet access? How can I trigger
its build (is it from Fuel menu or from master node console?)

Thanks,

[1] http://irclog.perlgeek.de/fuel-dev/2015-08-17

On Mon, Aug 17, 2015 at 10:08 AM Mike Scherbakov mscherba...@mirantis.com
wrote:

Hi all,
what is the current status of the feature in terms of readiness for
production use? I'm wondering as I see a number of bugs, and so we might
want to still have it in experimental mode for 7.0, and enable in 8.0.

These are the bugs I came across:
[1] https://bugs.launchpad.net/fuel/+bug/1485188
[2] https://bugs.launchpad.net/fuel/+bug/1481721
[3] https://bugs.launchpad.net/fuel/+bug/1482242
[4] https://bugs.launchpad.net/fuel/+bug/1483188
[5] https://bugs.launchpad.net/fuel/+bug/1485188

QA team - what is your point of view? Do you see that it's converging to
working solution with high level of confidence or not?
Some of the bugs seem to be blocking easy scale testing [1,2,4,5]. If it's
the case, then I would rather revert back to CentOS-default: we can't block
testing at this stage in the release timeline.

Thanks,

On Mon, Aug 17, 2015 at 12:03 AM Lukasz Oles lo...@mirantis.com wrote:

On Mon, Aug 17, 2015 at 7:16 AM, Alexei Sheplyakov
asheplya...@mirantis.com wrote:
Lukasz,

As I see, unfortunatly script which you recommend to use does not use
this
paths.
Instead it have hardcoded values.

Actually the script does use the values from the config file
(/etc/fuel-bootstrap-image.conf) generated by fuelmenu.
Ah, I missed it. Thx

Now we need to update paths in two places. Why is that?

There are fallback settings in the script so it can work without
fuelmenu/config file.

Best regards,
Alexei

On Fri, Aug 14, 2015 at 2:12 PM, Lukasz Oles lo...@mirantis.com
wrote:

Hello,

there is some inconsistency here. Currently I'm fixing bug[1] in
fuelmemu. In my fix[2] I changed paths to repos. As I see,
unfortunatly script which you recommend to use does not use this
paths. Instead it have hardcoded values.
Now we need to update paths in two places. Why is that?

1. https://bugs.launchpad.net/fuel/+bug/1484648
2. https://review.openstack.org/#/c/213090/
3.

https://github.com/stackforge/fuel-main/blob/master/fuel-bootstrap-image-builder/bin/fuel-bootstrap-image#L14

Regards

On Thu, Aug 13, 2015 at 5:39 PM, Mikhail Semenov
mseme...@mirantis.com
wrote:
Hi all,

We have new feature in the upcoming release MOS 7.0 - Ubuntu-based
bootstrap
in addition to current CentOS-based one. Design spec can be found
here.

Current 7.0 ISO contains 2 bootstrap images: CentOS-based (default)
and
Ubuntu-based. You can easily switch to Ubuntu-based bootstrap using
this
steps:
1. Make sure the master node can access Ubuntu
(http://archive.ubuntu.com/ubuntu) and MOS
(http://mirror.fuel-infra.org/mos-repos) APT repositories.
2. Run the following command on the master node:
fuel-bootstrap-image-set ubuntu
3. Just in a case restart dnsmasq:
dockerctl shell cobbler service dnsmasq restart
4. Reboot the slave nodes.

There are only 2 weeks left for testing. On 08/27 we will make a
decision
about using Ubuntu bootstrap by default in MOS 7.0. It depends on the
test
results and statistics(more deployments - more confidence).

I want to ask everyone to try new Ubuntu bootstrap. Please, deploy
it on
your environments and file bugs in case of failures. It's most
important
for
partners and plugin developers. Feel free to contact Alexei
Sheplyakov(feature lead) and me in case of questions.

--
Thanks,
Michael

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

--
Łukasz Oleś

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

--
Mike Scherbakov
#mihgen

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

Re: [openstack-dev] [neutron][vmware][stable] vmware-nsx has no releases

On Mon, Aug 17, 2015 at 7:05 AM, Ihar Hrachyshka ihrac...@redhat.com
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Hi VmWare folks,

 I wonder whether we can get some actual release tags for stable/kilo
 branch of the repo. Lack of any consumable tarballs does not help
 packagers that want to just get the tarball from pypi and use it as a
 base.

 I tried to follow the dumb way of generating a tarball from github,
 but pbr complains about lack of sdist or git when I call to 'setup.py
 build'. Putting egg-info directory inside the tarball does not help.

 I think it would be better for everyone if tags and tarballs came from
 upstream.

 I suspect other spinned-out neutron drivers could have the same
 problem. Can we somehow make sure they are releasing deliverables and
 not just git repo?


We will talk about this at the meeting today but yes, the plan is to get
releases for these. So far we've only discussed stable releases, but I
think the plan to release master snapshots would be good. It would give the
packagers a chance to package these.

Ihar, lets work to make this happen tomorrow or Wednesday.

Thanks,
Kyle



 Ihar
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQEcBAEBCAAGBQJV0c4PAAoJEC5aWaUY1u57M2cIALuH2MByojn7N1byCV4ctTal
 NPsUTgFyzDEXSU1QSgobR6x1uP8hYBW2RSUqnh4tR+SoYz/vmF1IvwXl53tb3Jnq
 4MTwXbom3xPgjUYsUep5TAhPglMXf4LwnTYejhqc78IOlNg7tAC0U/yA2ZitFhm2
 5zWsec1zggsku4aIMCz06bFwgQHwYl57uHBB/iqO+fbRIGZLkcGrbjiucKIlQqsF
 uv9GoymuwOEVjmTtooQBoVQ0J2f/yZYswcRBExbJU78eIP89+A2kDL9nA4fFFhCl
 b5Yus6oJDn/XMaU8PWZ8TptWEOY3Z80wbCRZk27FNObSb6yLs+2ZS7Rge+ZCz5s=
 =VP83
 -END PGP SIGNATURE-

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

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

Re: [openstack-dev] [Fuel][MOS][Bootstrap] Please try Ubuntu bootstrap in MOS 7.0

2015-08-17 Thread Mike Scherbakov

Thanks,

On Mon, Aug 17, 2015 at 12:03 AM Lukasz Oles lo...@mirantis.com wrote:

On Mon, Aug 17, 2015 at 7:16 AM, Alexei Sheplyakov
asheplya...@mirantis.com wrote:
Lukasz,

As I see, unfortunatly script which you recommend to use does not use
this
paths.
Instead it have hardcoded values.

Actually the script does use the values from the config file
(/etc/fuel-bootstrap-image.conf) generated by fuelmenu.
Ah, I missed it. Thx

Now we need to update paths in two places. Why is that?

There are fallback settings in the script so it can work without
fuelmenu/config file.

Best regards,
Alexei

On Fri, Aug 14, 2015 at 2:12 PM, Lukasz Oles lo...@mirantis.com wrote:

Hello,

1. https://bugs.launchpad.net/fuel/+bug/1484648
2. https://review.openstack.org/#/c/213090/
3.

https://github.com/stackforge/fuel-main/blob/master/fuel-bootstrap-image-builder/bin/fuel-bootstrap-image#L14

Regards

On Thu, Aug 13, 2015 at 5:39 PM, Mikhail Semenov mseme...@mirantis.com

wrote:
Hi all,

We have new feature in the upcoming release MOS 7.0 - Ubuntu-based
bootstrap
in addition to current CentOS-based one. Design spec can be found
here.

I want to ask everyone to try new Ubuntu bootstrap. Please, deploy it
on
your environments and file bugs in case of failures. It's most
important
for
partners and plugin developers. Feel free to contact Alexei
Sheplyakov(feature lead) and me in case of questions.

--
Thanks,
Michael

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

--
Łukasz Oleś

Re: [openstack-dev] [nova] compute - conductor and version compatibility

2015-08-17 Thread Dan Smith

 No, that's not valid behaviour. You need to upgrade the controller
 infrastructure (conductor, API nodes, etc) before any compute nodes.

Yep.

--Dan



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

Re: [openstack-dev] [cinder] [third-party] ProphetStor CI account

HI Mike:
I completed to refine our CI configuration to follow Ramy's
comments. Does any missed or other attention I need respect?

[1] Add export DEVSTACK_GATE_TEMPEST_REGEX=volume to verify all
cinder volume testing.
[2] Add each service configuration in the log.

http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds
vm-tempest-cinder-ci/5100/logs/etc/
[3] Add email alert when the devstack build failed to instead of you
notify to me.
[4] Integrate VMware snapshot revert feature in the Jenkins master
to clean CI slave machine OS environment that avoid the devstack building
failed due to previous devstack garbage configuration.
[5] Latest CI result for you reference.

http://download.prophetstor.com/prophetstor_ci/203895/3/check/prophetstor-ds
vm-tempest-cinder-ci/5100/logs/
http://download.prophetstor.com/prophetstor_ci/

[6] Logs need to be browsable online.
Add Rewrite module and rule in the apache configuration.

my gerrit account:  prophetstor-ci
   gerrit account email:prophetstor...@prophetstor.com

Many thanks.

-Original Message-
From: Mike Perez [mailto:thin...@gmail.com] 
Sent: Friday, August 14, 2015 11:41 PM
To: Rick Chen rick.c...@prophetstor.com
Cc: openstack-dev@lists.openstack.org
Subject: Re: [cinder] [third-party]RE: [OpenStack-Infra] ProphetStor CI
account

On 09:44 Aug 14, Rick Chen wrote:
 HI Mike:
   Sorry again, I already add email alert agent in our CI Jenkins
server 
 to capture each failed build result.
   [1] -
 http://lists.openstack.org/pipermail/third-party-announce/2015-June/00
 0192.h
 tml
   [2] -
 http://lists.openstack.org/pipermail/third-party-announce/2015-June/00
 0193.h
 tml
   Solution 1: Our Jenkins client machine is vmware machine, I already 
 add snapshot revert script in the Jenkins Job script. Each git review job
 trigger the client will revert to  clean environment
 to solve this problem.
   Solution 2: I don't know whiched changed to make keystone unable to

 import pastedeploy. So I try to uninstall python-pastedeploy package 
 in the local to solve some
issue about unable to build devstack issue.
   Sorry again to disturb you.

Rick,

I looked at your CI results directory [1], but it looks like the last time
this ran was on July 28th according to the last modified dates. This should
be actively running even if you account is disabled from leaving comments,
so I can verify from the logs things are running fine again.

In addition, see Ramy's comments with issues with the CI [2].

[1] - http://download.prophetstor.com/prophetstor_ci/?C=M;O=A
[2] -
http://lists.openstack.org/pipermail/openstack-infra/2015-August/003057.html

--
Mike Perez


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

Re: [openstack-dev] [nova] compute - conductor and versioncompatibility

2015-08-17 Thread Markus Zoeller

Dan Smith d...@danplanet.com wrote on 08/17/2015 05:08:25 PM:

 From: Dan Smith d...@danplanet.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: 08/17/2015 05:15 PM
 Subject: Re: [openstack-dev] [nova] compute - conductor and version 
 compatibility

  No, that's not valid behaviour. You need to upgrade the controller
  infrastructure (conductor, API nodes, etc) before any compute nodes.

 Yep.

 --Dan

Thanks Jay and Dan, for the clarification! 
I'll see if I can update the docs to make it a bit more clearer,
even for newbies like me.

Regards, 
Markus Zoeller (markus_z)

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

Re: [openstack-dev] [packaging][all] setting minimum version of setuptools in setup.py

2015-08-17 Thread Victor Stinner


Le 29/07/2015 10:27, Robert Collins a écrit :

Similar to pbr, we have a minimum version of setuptools required to
consistently install things in OpenStack. Right now thats 17.1.

However, we don't declare a setup_requires version for it.

I think we should.


If it's possible to explicit the minimum version of setuptools required 
to install an application in setup.py, yes, we should do that. I like 
being explicit to avoid bad surprises.


Victor

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

Re: [openstack-dev] sr-iov kilo getting libvirtd error while spawning a vm

2015-08-17 Thread Moshe Levi

Hi,
The driver name should be kvm and not qemu.
interface type=hostdev managed=yes
  mac address=fa:16:3e:eb:38:da/
  driver name=qemu/
  source
address type=pci domain=0x bus=0x81 slot=0x02 
function=0x7/
  /source
  vlan
tag id=1009/
  /vlan
/interface

I think you need to set the virt_type to kvm as describe below in the nova.conf
[libvirt]
virt_type = kvm



From: Kamsali, RaghavendraChari (Artesyn) 
[mailto:raghavendrachari.kams...@artesyn.com]
Sent: Monday, August 17, 2015 6:50 PM
To: openst...@lists.openstack.org
Cc: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Subject: [openstack-dev] sr-iov kilo getting libvirtd error while spawning a vm

Hi,
Trying to bring up vm on sr-iov enabled openstack getting this error on compute 
node as shown below



from (pid=9551) _get_guest_xml /opt/stack/nova/nova/virt/libvirt/driver.py:4195
2015-08-17 21:15:40.957 DEBUG nova.virt.libvirt.vif 
[req-8d3ac9c1-d33d-4bd4-b4ab-5eda2e1c400f demo demo] vif_type=hw_veb 
instance=Instance(access_ip_v4=None,access_ip_v6=None,architecture=None,auto_disk_config=False,availability_zone=None,cell_name=None,cleaned=False,config_drive='',created_at=2015-08-17T15:45:32Z,default_ephemeral_device=None,default_swap_device='/dev/vdb',deleted=False,deleted_at=None,disable_terminate=False,display_description='vm1',display_name='vm1',ephemeral_gb=0,ephemeral_key_uuid=None,fault=?,flavor=Flavor(8),host='Compute1',hostname='vm1',id=18,image_ref='ef29abd3-f52c-4591-b608-c3ed948fb49b',info_cache=InstanceInfoCache,instance_type_id=8,kernel_id='',key_data=None,key_name=None,launch_index=0,launched_at=None,launched_on='Compute1',locked=False,locked_by=None,memory_mb=2048,metadata={},new_flavor=None,node='Compute1',numa_topology=None,old_flavor=None,os_type=None,pci_devices=PciDeviceList,pci_requests=InstancePCIRequests,power_state=0,progress=0,project_id='c3aa578e594f44f7a79cb075ac7688ab',ramdisk_id='',reservation_id='r-0u6rbpou',root_device_name='/dev/vda',root_gb=10,scheduled_at=None,security_groups=SecurityGroupList,shutdown_terminate=False,system_metadata={image_base_image_ref='ef29abd3-f52c-4591-b608-c3ed948fb49b',image_container_format='bare',image_disk_format='qcow2',image_min_disk='10',image_min_ram='0',network_allocated='True'},tags=?,task_state='spawning',terminated_at=None,updated_at=2015-08-17T15:45:34Z,user_data=None,user_id='9dd44e8f987548b2a304b3f12b812381',uuid=480128a7-7640-4ddb-9bd1-bdc0018e7f6e,vcpu_model=VirtCPUModel,vcpus=2,vm_mode=None,vm_state='building')
 vif=VIF({'profile': {u'pci_slot': u':81:02.7', u'physical_network': 
u'default', u'pci_vendor_info': u'8086:154c'}, 'ovs_interfaceid': None, 
'preserve_on_delete': True, 'network': Network({'bridge': None, 'subnets': 
[Subnet({'ips': [FixedIP({'meta': {}, 'version': 4, 'type': 'fixed', 
'floating_ips': [], 'address': u'192.168.1.11'})], 'version': 4, 'meta': 
{'dhcp_server': u'192.168.1.2'}, 'dns': [], 'routes': [], 'cidr': 
u'192.168.1.0/24', 'gateway': IP({'meta': {}, 'version': 4, 'type': 'gateway', 
'address': u'192.168.1.1'})})], 'meta': {'injected': False, 'tenant_id': 
u'c3aa578e594f44f7a79cb075ac7688ab', 'physical_network': u'default'}, 'id': 
u'e82ec190-e36d-4157-ae9c-e4e4948735e2', 'label': u'mgmt-net'}), 'devname': 
u'tap3b0a1ae4-4e', 'vnic_type': u'direct', 'qbh_params': None, 'meta': {}, 
'details': {u'port_filter': False, u'vlan': u'1009'}, 'address': 
u'fa:16:3e:eb:38:da', 'active': True, 'type': u'hw_veb', 'id': 
u'3b0a1ae4-4eb5-4911-a9a7-109217188067', 'qbg_params': None}) from (pid=9551) 
plug /opt/stack/nova/nova/virt/libvirt/vif.py:597
2015-08-17 21:15:40.961 ERROR nova.virt.libvirt.driver 
[req-8d3ac9c1-d33d-4bd4-b4ab-5eda2e1c400f demo demo] Error defining a domain 
with XML: domain type=qemu
  uuid480128a7-7640-4ddb-9bd1-bdc0018e7f6e/uuid
  nameinstance-0012/name
  memory2097152/memory
  vcpu2/vcpu
  metadata
nova:instance xmlns:nova=http://openstack.org/xmlns/libvirt/nova/1.0;
  nova:package version=2015.1.2/
  nova:namevm1/nova:name
  nova:creationTime2015-08-17 15:45:40/nova:creationTime
  nova:flavor name=m1.new
nova:memory2048/nova:memory
nova:disk10/nova:disk
nova:swap200/nova:swap
nova:ephemeral0/nova:ephemeral
nova:vcpus2/nova:vcpus
  /nova:flavor
  nova:owner
nova:user uuid=9dd44e8f987548b2a304b3f12b812381demo/nova:user
nova:project 
uuid=c3aa578e594f44f7a79cb075ac7688abdemo/nova:project
  /nova:owner
  nova:root type=image uuid=ef29abd3-f52c-4591-b608-c3ed948fb49b/
/nova:instance
  /metadata
  sysinfo type=smbios
system
  entry name=manufacturerOpenStack Foundation/entry
  entry name=productOpenStack Nova/entry
  entry name=version2015.1.2/entry
  entry name=serial94e62060-1011-4750-ac16-88c58d7b40af/entry
  entry name=uuid480128a7-7640-4ddb-9bd1-bdc0018e7f6e/entry
/system
  /sysinfo
  os
typehvm/type

Re: [openstack-dev] [nova] compute - conductor and version compatibility

2015-08-17 Thread Jay Pipes


On 08/17/2015 10:41 AM, Markus Zoeller wrote:

I have the impression that more and more people try to run OpenStack
in a mixed-releases-mode and face some troubles to understand how
the capabilities and limitations look like. For example, the reporter
of [1] runs a nova-conductor (Juno) with a nova-compute (Kilo). I tried
in comment #3 of [1] to rationalize if this is a valid setup or not
and I failed...
If someone with more experience and knowledge could help there and
clarify it also for other users in the future, that would be awesome.

[1] https://bugs.launchpad.net/nova/+bug/1483321


No, that's not valid behaviour. You need to upgrade the controller 
infrastructure (conductor, API nodes, etc) before any compute nodes.


Best,
-jay

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

Re: [openstack-dev] [nova] compute - conductor and version compatibility

2015-08-17 Thread Chen CH Ji

I remembered I saw somewhere about how to upgrade, (step by step in
updating from J to K or others)
I think it's best and suitable way to use this kind of 'different version'
talking to make compute host alive
during system upgrade.


so I believe controller should be upgrade first the compute node to be
update set by set
that means Kilo conductor should works with Juno compute
but on the contrary I didn't see a value for supporting it

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



From:   Jay Pipes jaypi...@gmail.com
To: openstack-dev@lists.openstack.org
Date:   08/17/2015 05:01 PM
Subject:Re: [openstack-dev] [nova] compute - conductor and version
compatibility



On 08/17/2015 10:41 AM, Markus Zoeller wrote:
 I have the impression that more and more people try to run OpenStack
 in a mixed-releases-mode and face some troubles to understand how
 the capabilities and limitations look like. For example, the reporter
 of [1] runs a nova-conductor (Juno) with a nova-compute (Kilo). I tried
 in comment #3 of [1] to rationalize if this is a valid setup or not
 and I failed...
 If someone with more experience and knowledge could help there and
 clarify it also for other users in the future, that would be awesome.

 [1] https://bugs.launchpad.net/nova/+bug/1483321

No, that's not valid behaviour. You need to upgrade the controller
infrastructure (conductor, API nodes, etc) before any compute nodes.

Best,
-jay

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

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

Re: [openstack-dev] [stable] [infra] How to auto-generate stable release notes

2015-08-17 Thread Dave Walker

On 17 August 2015 at 15:59, Jeremy Stanley fu...@yuggoth.org wrote:
 On 2015-08-17 15:46:24 +0200 (+0200), Thierry Carrez wrote:
 [...]
 OSSA: -ZZZ
 For commits that correspond to vulnerability fixes.
 [...]

 I don't think that's going to be feasible. Consider the sequence
 with a public security vulnerability... often the OSSA number isn't
 assigned until after one or more backports have been approved. With
 some careful controls introduced into the VMT process we may be able
 to make sure most of these get updated commit messages before they
 merge, but would still need a plan to solve for the times when
 backported security fixes slip in without an OSSA header in the
 commit message.

Maybe this is a perfect use-case for git-notes?  This means the commit
itself isn't touched and the non-scale git-tag space isn't wasted?

--
Kind Regards,
Dave Walker

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

Re: [openstack-dev] [neutron][qos] request to merge feature/qos back into master

2015-08-17 Thread Ihar Hrachyshka

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

So the patch in question sit there for some time, and honestly, I
haven't seen much interest from reviewers to take a look at it, apart
from Assaf who played with the code and reported a bunch of minor issues
.

I think Kyle's plan was to wait until Fri and then merge.

We had a git conflict on Fri though, so today I respin the patch
again, hoping that it will either get more reviews or it's merged
before we hit another conflict that can be inflicted by any new db
migration.

Ihar

On 08/12/2015 09:55 PM, Ihar Hrachyshka wrote:
 Hi all,
 
 with great pleasure, I want to request a coordinated review for 
 merging feature/qos branch back to master:
 
 https://review.openstack.org/#/c/212170/
 
 Since it's a merge patch, gerrit fails to show the whole diff that
 it introduces into master. To get over it, fetch the patch:
 
 $ git review -d 212170
 
 and then check the difference:
 
 $ git fetch origin  git diff origin/master...
 
 I think we should stick to review process originally suggested at
 [1]. Specifically, since it's not reasonable to expect the whole
 feature branch to be reviewed by a single person, I hope multiple
 people will assign themselves to the job and split the pieces to
 review based on devref document that describes the feature [2]
 (Note that a new RPC push/pull mechanism is described in a separate
 devref section [3]).
 
 Note that we don't expect to tackle all review comments, however
 tiny, in feature/qos. We are happy to handle major flaws there, but
 for minor stuff, it's good to proceed in master. Nevertheless we
 are happy to get minors too and collect them for post-merge.
 
 Things we have in the tree:
 
 - server: QoS API extension; QoS core resource extension; QoS ML2 
 extension driver; QoS versioned objects + base for new objects;
 QoS supported rule types mechanism for ML2; QoS notification
 drivers mechanism to update SDN controllers;
 
 - RPC: new push/pull mechanisms for versioned objects to propagate
 QoS objects into the agents;
 
 - agent side: new L2 agent extensions mechanism, integrated into
 OVS and SR-IOV agents; QoS l2 agent extension; OVS and SR-IOV QoS
 drivers; ovs_lib and pci_lib changes.
 
 I suggest to split review into following logical pieces:
 
 - API controller + service plugin + API tests; - Versioned objects:
 neutron.objects.* - ML2: supported_qos_rule_types mechanism,
 extension driver, update for get_device_details payload; - RPC
 mechanism (push/pull), resource manager, registries + notification
 drivers integration; - l2 extensions (manager, base interface) +
 qos extension; - OVS integration with extension manager + OVS QoS
 driver + ovs_lib changes; - SR-IOV agent integration with extension
 manager + SR-IOV QoS driver + pci_lib changes; - functional tests.
 
 We will also need to update the spec: 
 https://review.openstack.org/#/c/199112/
 
 Included test coverage:
 
 - unit tests; - API tests; - functional tests (more scenarios to
 come in master); - fullstack tests [4] (not in the tree since we
 need to merge client and base fullstack patches first).
 
 We have client patches up for review [5][6] and expect them to go
 in after merge of server component.
 
 We hope that we'll make fullstack in before closing the blueprint
 in this cycle.
 
 [1]: 
 http://lists.openstack.org/pipermail/openstack-dev/2015-July/069188.ht
ml

 
[2]:
 http://git.openstack.org/cgit/openstack/neutron/tree/doc/source/devref
/q

 
uality_of_service.rst?h=feature/qos
 [3]: 
 http://git.openstack.org/cgit/openstack/neutron/tree/doc/source/devref
/r

 
pc_callbacks.rst?h=feature/qos
 [4]: https://review.openstack.org/202492 [5]:
 https://review.openstack.org/189655 [6]:
 https://review.openstack.org/198277 [7]:
 https://review.openstack.org/202061
 
 __


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

iQEcBAEBCAAGBQJV0fYnAAoJEC5aWaUY1u57rtsH/iaQ5HCRuFDbhFsFAkGeW/hB
gn/pR9lmx/hXUIkEWfGPIsgtEnuA8nIQ3knwLfvkrPxR60YHkCK5YeRDaTVd0IQb
oV5njw3eMJablTtquPybSzUljfx+oCQ2pxwhXgWAcj5KucksXLcvC+lkfk5uQ1OT
iFum1jCmZ+7Te8uPdjkgGxxxpLjnJJs0Na6i+GhRppRc/HK77jM31MggfA3dJw9y
cdB0JN3w2tT4wbjtmtCsVgKVWeDuuKXlnZjmI0Do1Qm1YDC0NNPLNGcBTV70vyPB
B8lGyk9kvtbzSQ701T3LEp8hRIL6Oto8cHRrt3jkfygrlXPQL8x1pwtjSD59bXU=
=s4FB
-END PGP SIGNATURE-

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

Re: [openstack-dev] [Ceilometer][AODH] Timeout Event Alarms

2015-08-17 Thread gord chung


good questions...

On 17/08/2015 10:19 AM, Igor Degtiarov wrote:

Gordon probably that question to you:
Are we going to create a new folder in spec's dir for next cycle, or 
we continue discussing new specs as part of liberty?


we can create a new dir for M* cycle specs. as mentioned in last week's 
meeting, even though we don't have a exact date for feature freeze, 
unless it's a small bug size spec, Liberty specs are closed. feel free 
to create a patch for new M* dir


And the second one: are we going to create special rep for AODH specs 
or ceilometer-specs is ok for all new projects?


we'll track aodh specs under ceilometer now -- i don't want to increase 
the number of repos we need to monitor unless we notice Aodh specs are 
too much to handle.


cheers,

--
gord


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

Re: [openstack-dev] [cinder] Midcycle Sprint Summary

2015-08-17 Thread Jay Pipes


On 08/17/2015 11:53 AM, Mike Perez wrote:

Getting rid of API extensions
=
Move obvious things over (volume attach, type manager) to core API controllers.
Deprecate existing extensions and have these use core API controller code. Get
rid of the silly os- prefix in endpoints. Use Microversions to know when the
API has the new extensions in core controllers.


3

-jay

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

[openstack-dev] [Ironic] reminder: meeting time change

2015-08-17 Thread Devananda van der Veen

Hi folks,

Just a quick reminder - we're switching back to a consistent meeting time,
at 18:00 UTC Mondays.

That means the next meeting is in two hours.

I should have sent this on Friday, but exhaustion and juggling the
midcycle, and well, I forgot :-/

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

Re: [openstack-dev] [Ironic] reminder: meeting time change

2015-08-17 Thread Lucas Alvares Gomes

Hi,

Thanks for the reminder.

 Just a quick reminder - we're switching back to a consistent meeting time,
 at 18:00 UTC Mondays.


The time is actually 17:00 UTC [1]

[1] https://wiki.openstack.org/wiki/Meetings/Ironic#Next_Meeting

Cheers,
Lucas

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

Re: [openstack-dev] [nova] compute - conductor and version compatibility

2015-08-17 Thread Dan Smith

 Is this documented somewhere?
 
 I did a bit of digging and couldn't find anywhere that explicitly
 required that for the J-K upgrade.  Certainly it was documented for the
 I-J upgrade.

It's our model, so I don't think we need to document it for each cycle
since we don't expect it to change. We may need more general coverage
for this topic, but I don't expect the release notes to always mention it.

This isn't formal documentation, but it's relevant:

http://www.danplanet.com/blog/2015/06/26/upgrading-nova-to-kilo-with-minimal-downtime/

--Dan

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

Re: [openstack-dev] [packaging][all] setting minimum version of setuptools in setup.py

2015-08-17 Thread Victor Stinner


Le 29/07/2015 18:12, Clay Gerrard a écrit :

I agree an error message is better than breaking for insane reasons.

But... maybe as an aside... what about not breaking?


Well, yes, but *who* wants to do that?

Old versions of setuptoolsl, pip and pbr have a lot of issues. It will 
be a nightmare to workaround them.


For example, it was really difficult to handle dependencies which depend 
on the Python version (for python = 2.6, for python = 3.0, etc.). 
Environment markers solve a real concrete issue. Trying to working 
around environment markers is like reinventing the wheel, it doesn't 
sound like a good idea to me.


For me, it's a better investment to work upstream on setuptools, pip and 
pbr, and require recent versions.


Victor

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

Re: [openstack-dev] [Neutron] VPNaaS and DVR compatibility

2015-08-17 Thread Sean M. Collins

On Mon, Aug 17, 2015 at 10:42:18AM EDT, Sergey Kolekonov wrote:
 BTW, the similar situation is with FWaaS [1]
 
 [1] https://bugs.launchpad.net/neutron/+bug/1485509

Can you take a look at the following patch?

https://review.openstack.org/203493

If it resolves the issue I may need to re-think my -1, and we may need
to restore it.

-- 
Sean M. Collins

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

Re: [openstack-dev] [kolla] Proposing Swapnil Kulkarni (coolsvap) for kolla core reviewer team

2015-08-17 Thread Martin André

On Fri, Aug 14, 2015 at 3:29 PM, Steven Dake (stdake) std...@cisco.com
wrote:

 Hi folks,

 Swapnil has done a bunch of great technical work, participates heavily in
 IRC, and has contributed enormously to the implementation of Kolla.  I’d
 like to see more reviews from Swapnil, but he has committed to doing more
 reviews and already has gone from something like 0 reviews to 90 reviews in
 about a month.  Count this proposal as a +1 from me.

 His 90 day stats are:
 http://stackalytics.com/report/contribution/kolla-group/90

 The process we go to select new core reviewers is that we require a
 minimum of 3 +1 votes within a 1 week voting window.  A vote of –1 is a
 veto.  It is fine to abstain as well without any response to this email.
 If the vote is unanimous or there is a veto vote prior to the end of the
 voting window, I’ll close voting then.

 The voting is open until Friday August 21st.


I'm abstaining from the vote as I haven't been very involved lately and
feel I can't judge on Swapnil's work. That being said, I entirely trust
other cores' judgment and am sure he'll be an excellent kolla core.

Martin



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


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

Re: [openstack-dev] [third-party-ci]Tests randomly failing because of lvm

2015-08-17 Thread Andrey Pavlov

glance log -

2015-08-17 03:13:42.938 2312 INFO swiftclient
[req-463d065c-8c26-4be2-8e30-5f1d83e4a6b8 2c757dc5add24d02b867436d82db5e99
98a460b55a544902b4bfbb104e8fae7f - - -] REQ: curl -i
http://127.0.0.1:8080/v1/AUTH_93bdc098999d400b9838abb51a7a8126/glance/32be6815-3571-48e8-b664-7902613ffd04
-X PUT -H X-Auth-Token: 5103ad1cf0684071aa47e36683004ead
2015-08-17 03:13:42.938 2312 INFO swiftclient
[req-463d065c-8c26-4be2-8e30-5f1d83e4a6b8 2c757dc5add24d02b867436d82db5e99
98a460b55a544902b4bfbb104e8fae7f - - -] RESP STATUS: 503 Service Unavailable
2015-08-17 03:13:42.938 2312 INFO swiftclient
[req-463d065c-8c26-4be2-8e30-5f1d83e4a6b8 2c757dc5add24d02b867436d82db5e99
98a460b55a544902b4bfbb104e8fae7f - - -] RESP HEADERS: [('date', 'Mon, 17
Aug 2015 03:13:17 GMT'), ('content-length', '118'), ('content-type',
'text/html; charset=UTF-8'), ('x-trans-id',
'tx78adec8088444befb8faf-0055d15136')]
2015-08-17 03:13:42.938 2312 INFO swiftclient
[req-463d065c-8c26-4be2-8e30-5f1d83e4a6b8 2c757dc5add24d02b867436d82db5e99
98a460b55a544902b4bfbb104e8fae7f - - -] RESP BODY: htmlh1Service
navailable/h1pThe server is currently unavailable. Please try again at
a later time./p/html
2015-08-17 03:13:43.939 2312 ERROR glance_store._drivers.swift.store
[req-463d065c-8c26-4be2-8e30-5f1d83e4a6b8 2c757dc5add24d02b867436d82db5e99
98a460b55a544902b4bfbb104e8fae7f - - -] Failed to add object to Swift.
Got error from Swift: put_object('glance',
'32be6815-3571-48e8-b664-7902613ffd04', ...) failure and no ability to
reset contents for reupload..
2015-08-17 03:13:43.940 2312 ERROR glance.api.v1.upload_utils
[req-463d065c-8c26-4be2-8e30-5f1d83e4a6b8 2c757dc5add24d02b867436d82db5e99
98a460b55a544902b4bfbb104e8fae7f - - -] Failed to upload image
32be6815-3571-48e8-b664-7902613ffd04
2015-08-17 03:13:43.940 2312 ERROR glance.api.v1.upload_utils Traceback
(most recent call last):
2015-08-17 03:13:43.940 2312 ERROR glance.api.v1.upload_utils   File
/opt/stack/new/glance/glance/api/v1/upload_utils.py, line 113, in
upload_data_to_store
2015-08-17 03:13:43.940 2312 ERROR glance.api.v1.upload_utils
context=req.context)
2015-08-17 03:13:43.940 2312 ERROR glance.api.v1.upload_utils   File
/usr/local/lib/python2.7/dist-packages/glance_store/backend.py, line 340,
in store_add_to_backend
2015-08-17 03:13:43.940 2312 ERROR glance.api.v1.upload_utils
context=context)
2015-08-17 03:13:43.940 2312 ERROR glance.api.v1.upload_utils   File
/usr/local/lib/python2.7/dist-packages/glance_store/capabilities.py, line
226, in op_checker
2015-08-17 03:13:43.940 2312 ERROR glance.api.v1.upload_utils return
store_op_fun(store, *args, **kwargs)
2015-08-17 03:13:43.940 2312 ERROR glance.api.v1.upload_utils   File
/usr/local/lib/python2.7/dist-packages/glance_store/_drivers/swift/store.py,
line 620, in add
2015-08-17 03:13:43.940 2312 ERROR glance.api.v1.upload_utils raise
glance_store.BackendException(msg)
2015-08-17 03:13:43.940 2312 ERROR glance.api.v1.upload_utils
BackendException: Failed to add object to Swift.
2015-08-17 03:13:43.940 2312 ERROR glance.api.v1.upload_utils Got error
from Swift: put_object('glance', '32be6815-3571-48e8-b664-7902613ffd04',
...) failure and no ability to reset contents for reupload.

swift-object log -

object-server: 127.0.0.1 - - [17/Aug/2015:03:13:12 +] PUT
/sdb1/419/AUTH_93bdc098999d400b9838abb51a7a8126/glance/68b9d0f8-f20f-42e8-a430-8930608e9ed4
201 - PUT
http://127.0.0.1:8080/v1/AUTH_93bdc098999d400b9838abb51a7a8126/glance/68b9d0f8-f20f-42e8-a430-8930608e9ed4;
txe6ba789f3616452aa2a12-0055d15148 proxy-server 2111 0.0039 - 2159 0
object-server: ERROR __call__ error with PUT
/sdb1/134/AUTH_93bdc098999d400b9838abb51a7a8126/glance/32be6815-3571-48e8-b664-7902613ffd04
: [Errno 28] No space left on device (txn:
tx78adec8088444befb8faf-0055d15136)

maybe test tries to upload very huge image?


On Mon, Aug 17, 2015 at 10:02 AM, Abhishek Shrivastava 
abhis...@cloudbyte.com wrote:

 Hi Eduard,

 This is what I gathered the cause of the test failure:

 2015-08-17 03:13:44.239 ERROR oslo_messaging.rpc.dispatcher 
 [req-95c1bc0f-e333-493b-9730-cfba9c3dfd9a 
 tempest-VolumesV1ActionsTest-418947994] Exception during message handling: 
 500 Internal Server Error: Failed to upload image 
 32be6815-3571-48e8-b664-7902613ffd04 (HTTP 500)
 2015-08-17 03:13:44.239 16950 ERROR oslo_messaging.rpc.dispatcher Traceback 
 (most recent call last):
 2015-08-17 03:13:44.239 16950 ERROR oslo_messaging.rpc.dispatcher   File 
 /usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py, 
 line 142, in _dispatch_and_reply
 2015-08-17 03:13:44.239 16950 ERROR oslo_messaging.rpc.dispatcher 
 executor_callback))
 2015-08-17 03:13:44.239 16950 ERROR oslo_messaging.rpc.dispatcher   File 
 /usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py, 
 line 186, in _dispatch
 2015-08-17 03:13:44.239 16950 ERROR oslo_messaging.rpc.dispatcher 
 executor_callback)
 2015-08-17 03:13:44.239 16950 ERROR oslo_messaging.rpc.dispatcher   File

Re: [openstack-dev] [third-party-ci]Tests randomly failing because of lvm

Thanks,
I didn't see that errror, seems to be caused by swift:
2015-08-17 03:13:43.940 2312 ERROR glance.api.v1.upload_utils
BackendException: Failed to add object to Swift.

I'll investigate further.
But what about the lvmdriver-1 error? Isn't that related.

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

Re: [openstack-dev] [third-party-ci]Tests randomly failing because of lvm

Thanks,
I will try to increase the size of the dsvm disk, maybe that will help.

No idea about the image size.
The problem is that not all test runs fail, so it's not easy to trace.

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

Re: [openstack-dev] [openstack][nova] Streamlining of config options in nova

2015-08-17 Thread Markus Zoeller

Michael Still mi...@stillhq.com wrote on 08/12/2015 10:08:26 PM:

 From: Michael Still mi...@stillhq.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: 08/12/2015 10:14 PM
 Subject: Re: [openstack-dev] [openstack][nova] Streamlining of config 
 options in nova
 [...]

 Do we see https://review.openstack.org/#/c/205154/ as a reasonable 
 example of such centralization? If not, what needs to change there to 
 make it an example of that centralization? I see value in having a 
 worked example people can follow before we attempt a large number of 
 these moves.
 [...]
 Michael

IIUC, this change doesn't yet meet the idea and needs to change by:
* creating a module nova/conf/default.py and
* move the imagecache config options to that module

After this change, it wouldn't address the need to lookup which
services use a specific config option. What about enhancing this to
something like this:

Add a services package to the tree structure, which would then look
like this:

├── nova
│   ├── conf
│   │   ├── sections
│   │   │   ├── default.py
│   │   └── services
│   │   ├── compute.py

The *registration* of the config options would be done by sections
(here: default.py):

from oslo_config import cfg
CONF = cfg.CONF
imagecache_opts = [
cfg.IntOpt('image_cache_manager_interval',
   default=2400,
   help='... help text ...'),
# [...]
]
CONF.register_opts(imagecache_opts)

The *import* of the options would be done by service
(here: compute.py):

from oslo_config import cfg
CONF = cfg.CONF
CONF.import_opt('image_cache_manager_interval', 
'nova.conf.sections.default')
# ... more here ...

The usage via the conf.service.compute module
(here: imagecache.py):

import nova.conf.services.compute as cpu

def __init__(self):
self.remove_unused_base_images = \
cpu.CONF.remove_unused_base_images

Which means we would still use global variables but would at least know
which services are meant to use them and which module thinks to which
service it belongs (by using its config variables). An additional
checking if a module uses import_opt could result in a warning and
when the restructuring is done, result in an error.

I think we wouldn't have problems with cyclic dependencies this way.

The generation of the sample.conf file must be changed to use the
nova.conf.sections package instead of the opts.list_opts methods
as soon as we are done.

Scenarios: 
1) A new option should be added:
= register in conf.sections.section.py
= import in conf.services.service.py
+ It's immediatley clear which service is affected by that
+ If someone has to import another conf.services.service.py
  than the already existing ones, it's immediately clear in the
  review.
+ The person who adds it, sees that we have already a lot of config
  options and maybe is a bit more hesitant (let me dream, ...).
2) The config.sample has to be generated
= use conf.sections.*.py for the generation
3) Someone wants a nova.conf for a compute node
= use conf.services.compute.py for the generation
4) An existing option should be accessible by another service
= import it in conf.services.another-service.py

Regards,
Markus Zoeller (markus_z)

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

[openstack-dev] [zaqar] Ryan Brown to join Zaqar's reviewers team

2015-08-17 Thread Flavio Percoco


Greetings,

I'm delighted to announce that Ryan Brown (ryansb) has accepted to
join Zaqar's core-reviewers team.

After our last summit (Vancouver), Ryan has dedicated a significant
amount of time to the project by reviewing patches, which has helped
the team to keep things consistent.

Ryan has demonstrated he's familiar with the code base and he has also
provided valuable support on IRC and reviews not only to existing
members but also to newcomers. This has increased everyone's trust on
him to the point his feedback is many times requested on general
discussions.

I believe Ryan would be a great addition to our team and I'm happy he
has accepted to join.

Unless someone disagrees with the above, I'll proceed to give him the
required permissions on the project.

Feedback welcome from anyone at anytime. However, this thread will
remain valid until Friday, August 21st.

Thanks, Ryan. Keep it up.
Flavio

--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [sahara] Proposing Ethan Gafford for the core reviewer team

2015-08-17 Thread Flavio Percoco


On 16/08/15 19:51 +, Telles Nobrega wrote:

  For what is worth I got that it was just a joke.


That's great. However, not everyone did and this is a public mailing
list with lots of newcomers.

As I mentioned in my email, I know Trevor sent it with good intentions
but not everyone read it that way (including me).

I'm happy it was all clarified,
Flavio


  On Fri, Aug 14, 2015 at 2:30 PM Trevor McKay tmc...@redhat.com wrote:

Flavio,

A  thanks, bad joke on my part. I work with Telles on Sahara, just
poking
him in jest.A  Apologies, didn't mean to create an issue on the list.

Trev

On Fri, 2015-08-14 at 17:30 +0200, Flavio Percoco wrote:
 On 14/08/15 09:29 -0400, Trevor McKay wrote:
 Hi Telles,
 
  you technically don't get a vote, but thanks anyway :)

 Hi Trevor,

 Technically, everyone gets to vote and speak up. Regardless of whether
 you're a core-reviewer or not. Most of the time, non-core contributors
 provide amazing feedback on what their experience has been while
 receiving reviews from the nominated person.

 Regardless of the comment, we as a community always welcome
 contributor's opinions and encourage folks to speak up.

 I knew your intentions are good but I thought it'd be a good time to
 share the above so that it would work as a reminder for others as
 well.

 Thank you both and +1 for Ethan ;)
 Flavio

 
 Trev
 
 On Fri, 2015-08-14 at 12:14 +, Telles Nobrega wrote:
  +1
 
  On Fri, Aug 14, 2015 at 7:11 AM Alexander Ignatov
  aigna...@mirantis.com wrote:
 
 A  A  A  A  A +1
 
 A  A  A  A  A Regards,
 A  A  A  A  A Alexander Ignatov
 
 
 
 
 
 A  A  A  A  A  On 13 Aug 2015, at 18:29, Sergey Reshetnyak
 A  A  A  A  A  sreshetn...@mirantis.com wrote:
 A  A  A  A  A 
 A  A  A  A  A  +2
 A  A  A  A  A 
 A  A  A  A  A  2015-08-13 18:07 GMT+03:00 Matthew Farrellee
 A  A  A  A  A  m...@redhat.com:
 A  A  A  A  A A  A  A  A  A On 08/13/2015 10:56 AM, Sergey Lukjanov
wrote:
 A  A  A  A  A A  A  A  A  A  A  A  A  A Hi folks,
 A  A  A  A  A 
 A  A  A  A  A A  A  A  A  A  A  A  A  A I'd like to propose Ethan
Gafford as a
 A  A  A  A  A A  A  A  A  A  A  A  A  A member of the Sahara core
 A  A  A  A  A A  A  A  A  A  A  A  A  A reviewer team.
 A  A  A  A  A 
 A  A  A  A  A A  A  A  A  A  A  A  A  A Ethan contributing to
Sahara for a long time
 A  A  A  A  A A  A  A  A  A  A  A  A  A and doing a great job on
 A  A  A  A  A A  A  A  A  A  A  A  A  A reviewing and improving
Sahara. Here are the
 A  A  A  A  A A  A  A  A  A  A  A  A  A statistics for reviews
 A  A  A  A  A A  A  A  A  A  A  A  A  A [0][1][2] and commits [3].
BTW Ethan is
 A  A  A  A  A A  A  A  A  A  A  A  A  A already stable maint team
core
 A  A  A  A  A A  A  A  A  A  A  A  A  A for Sahara.
 A  A  A  A  A 
 A  A  A  A  A A  A  A  A  A  A  A  A  A Existing Sahara core
reviewers, please vote
 A  A  A  A  A A  A  A  A  A  A  A  A  A +1/-1 for the addition of
 A  A  A  A  A A  A  A  A  A  A  A  A  A Ethan to the core reviewer
team.
 A  A  A  A  A 
 A  A  A  A  A A  A  A  A  A  A  A  A  A Thanks.
 A  A  A  A  A 
 A  A  A  A  A A  A  A  A  A  A  A  A  A [0]
 A  A  A  A  A A  A  A  A  A  A  A  A 
A https://review.openstack.org/#/q/reviewer:%
 A  A  A  A  A A  A  A  A  A  A  A  A 
A 22Ethan+Gafford+%253Cegafford%2540redhat.com

 A  A  A  A  A A  A  A  A  A  A  A  A  A %253E%22,n,z
 A  A  A  A  A A  A  A  A  A  A  A  A  A [1]
 A  A  A  A  A A  A  A  A  A  A  A  A 
A http://stackalytics.com/report/contribution/sahara-group/90

 A  A  A  A  A A  A  A  A  A  A  A  A  A [2]
 A  A  A  A  A A  A  A  A  A  A  A  A 
A http://stackalytics.com/?user_id=egaffordmetric=marks

 A  A  A  A  A A  A  A  A  A  A  A  A  A [3]
 A  A  A  A  A A  A  A  A  A  A  A  A 
A https://review.openstack.org/#/q/owner:%
 A  A  A  A  A A  A  A  A  A  A  A  A 
A 22Ethan+Gafford+%253Cegafford%2540redhat.com

 A  A  A  A  A A  A  A  A  A  A  A  A  A %253E%22+status:merged,n,z
 A  A  A  A  A 
 A  A  A  A  A A  A  A  A  A  A  A  A  A --
 A  A  A  A  A A  A  A  A  A  A  A  A  A Sincerely yours,
 A  A  A  A  A A  A  A  A  A  A  A  A  A Sergey Lukjanov
 A  A  A  A  A A  A  A  A  A  A  A  A  A Sahara Technical Lead
 A  A  A  A  A A  A  A  A  A  A  A  A  A (OpenStack Data Processing)
 A  A  A  A  A A  A  A  A  A  A  A  A  A Principal Software Engineer
 A  A  A  A  A A  A  A  A  A  A  A  A  A Mirantis Inc.
 A  A  A  A  A 
 A  A  A  A  A 
 A  A  A  A  A A  A  A  A  A +1 ethan has really taken to sahara,
providing
 A  A  A  A  A A  A  A  A  A valuable input to both development and
deployments
 A  A  A  A  A A  A  A  A  A as

[openstack-dev] [openstack-deb] Devstack stable/juno fails to install