date:20150810

Sorry my bad. 7 months :)

On 8/10/15, 5:17 PM, Gary Kotton gkot...@vmware.com wrote:

Hi,
I am not really sure what to say here. The code was in review for over 8
months. On a side note but related - we have a patch for a plugin
developed in Liberty - https://review.openstack.org/#/c/165750/. This has
been in review since March. I really hope that that lands in Liberty. If
not we will go through the same thing again.
Working in Nova on code that is self contained within a driver is
difficult - terribly difficult. Not only is this demotivating, it also
effectively does not help any of the drivers actually add any features.
A sad day for OpenStack.
Thanks
Gary

On 8/5/15, 4:01 PM, Ihar Hrachyshka ihrac...@redhat.com wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I think Erno made a valid point here. If that would touch only vmware
code, that could be an option to consider. But it looks like both
patches are very invasive, and they are not just enabling features
that are already in the tree, but introduce new stuff that is not even
tested for long in master.

I guess we'll need to wait for those till Liberty. Unless
nova-core-maint has a different opinion and good arguments to approach
the merge.

Ihar

On 08/05/2015 12:37 PM, Kuvaja, Erno wrote:
 Hi Gary,
 
 
 
 While I do understand the interest to get this functionality
 included, I really fail to see how it would comply with the Stable
 Branch Policy: 
 https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy
 
 Obviously the last say is on stable-maint-core, but normally new
 features are really no-no to stable branches.
 
 
 
 My concerns are more on the metadata side of your changes.
 
 Even the refactoring is fairly clean it is major part of the
 metadata handler.
 
 It also changes the API (In the case of X-Metadata-Provider being
 present) which tends to be sacred on stable branches.
 
 
 
 The changes here does not actually fix any bug but just implements
 new functionality that missed kilo not even slightly but by months.
 Thus my -1 for merging these.
 
 
 
 -  Erno
 
 
 
 *From:*Gary Kotton [mailto:gkot...@vmware.com] *Sent:* Wednesday,
 August 05, 2015 8:03 AM *To:* OpenStack List *Subject:*
 [openstack-dev] [Stable][Nova] VMware NSXv Support
 
 
 
 Hi,
 
 In the Kilo cycle a Neutron driver was added for supporting the
 Vmware NSXv plugin. This required patches in Nova to enable the
 plugin to work with Nova. These patches finally landed yesterday. I
 have back ported them to stable/kilo as the Neutron driver is
 unable to work without these in stable/kilo. The patches can be
 found at:
 
 1. VNIC support - https://review.openstack.org/209372 2. Metadata
 support - https://review.openstack.org/209374
 
 I hope that the stable team can take this into consideration.
 
 
 
 Thanks in advance
 
 Gary
 
 
 
 __


 
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

iQEcBAEBCAAGBQJVwgkjAAoJEC5aWaUY1u57NacIALsJ8oo6eJKqJIidBSFzwxvg
zqJXHE56Lpg62/afRF94B2edfhm791Mz42LTFn0BHHRjV51TQX4k/Jf3Wr22CEvm
zFZkU5eVMVOSL3GGnOZqSv/T06gBWmlMVodmSKQjGxrIL1s8G1m4aTwe6Pqs+lie
N+cT0pZbcjL/P1wYTac6XMpF226gO1owUjhE4oj9VZzx7kEqNsv22SIzVN2fQcco
YLs/LEcabMhuuV4Amde3RqUr0BkB+mlIX1TUv5/FTXT/F4ZwzYS/DBH9MaBJ5t8n
hgCTJzCeg598+irgOt3VJ3Jn3Unljz6LNzKIM8RnBG0o51fp8vfE/mODQQaUKOg=
=ZYP8
-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


__
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] [Cinder] [Glance] glance_store and glance

2015-08-10 Thread Flavio Percoco


On 09/08/15 18:41 -0700, Mike Perez wrote:

On 13:07 Aug 07, Jay Pipes wrote:

Hi Nik, some comments inline, but tl;dr I am strongly against
returning the glance_store library to the Glance source repository.
Explanations inline...

On 08/07/2015 01:21 AM, Nikhil Komawar wrote:
Hi,

During the mid-cycle we had another proposal that wanted to put back the
glance_store library back into the Glance repo and not leave it is as a
separate repo/project.

The questions outstanding are: what are the use cases that want it as a
separate library?

The original use cases that supported a separate lib have not had much
progress or adoption yet.

This is really only due to a lack of time to replace the current
nova/image/download/* stuff with calls to the glance_store library.
It's not that the use case has gone away; it's just a lack of time to
work on it.


When Cinder wanted to integrate os-brick (initiator code library) into Nova,
Cinder folks integrated it themselves [1]. Has anyone from Glance been spending
the time to do this? If so, are there reviews you can give so we can see why
things are blocked?


There have been sessions that I personally attended in Atlanta and
Paris. There was one in Vancouver that I didn't attend. These sessions
were to work on the future of the Nova-Glance interaction. The
conclusion of these discussions has always been that we should migrate
Nova to Glance V2 before allowing it to consume glance_store.

I'll stop here otherwise we'll get into the whys/whats of why this
hasn't happened yet.




 There have been complaints about overhead of
maintaining it as a separate lib and version tracking without much gain.

I don't really see much overhead in maintaining a separate lib,
especially when it represents functionality that can be used by
Cinder and Nova directly.


As mentioned earlier Cinder is doing os-brick for both Cinder and Nova to
consume. Other projects are planning to use it as well, and it has been a huge
win to take some complications from other projects that aren't focusing on
block storage like we are. I recommend creating a gerrit dashboard [2] to
include a separate library with Glance reviews. I'm also not sure of what
overhead there could be besides having do release.

snip


4. cleaner api / more methods that support backend store capabilities -
a separate library is not necessarily needed, smoother re-factor is
possible within Glance codebase.

So, here's the crux of the issue. Nova and Cinder **do not want to
speak the Glance REST API** to either upload or download image bits
from storage. Streaming image bits through the Glance API endpoint is
a needless and inefficient step, and Nova and Cinder would like to
communicate directly with the backend storage systems.

glance_store IS the library that would enable Nova and Cinder to
communicate directly with the backend storage systems. The Glance API
will only be used by Nova and Cinder to get information *about* the
images in backend storage, not the image bits themselves.


+1

Provide a way to talk to the implementation, and step out of the way to let it
do what it does best. This is no different than other Openstack projects.

In Cinder, image copying to a volume is a huge problem today. We have a Cinder
glance_store [2] that is being revived to leave the images stored in the block
storage backends themselves, which, oh my goodness is using os-brick!!

The block storage backends know how to do efficient image copying/cloning to
their volumes, not Glance.



Jay/Mike

Thanks for the feedback on the validity of the use cases. That was the
goal of this thread and I'm glad you both stepped up.

Flavio


--
@flaper87
Flavio Percoco


pgpVApfxYXOXK.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] [Stable][Nova] VMware NSXv Support




On 8/10/2015 9:17 AM, Gary Kotton wrote:

Hi,
I am not really sure what to say here. The code was in review for over 8
months. On a side note but related - we have a patch for a plugin
developed in Liberty - https://review.openstack.org/#/c/165750/. This has
been in review since March. I really hope that that lands in Liberty. If
not we will go through the same thing again.
Working in Nova on code that is self contained within a driver is
difficult - terribly difficult. Not only is this demotivating, it also
effectively does not help any of the drivers actually add any features.
A sad day for OpenStack.
Thanks
Gary

On 8/5/15, 4:01 PM, Ihar Hrachyshka ihrac...@redhat.com wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I think Erno made a valid point here. If that would touch only vmware
code, that could be an option to consider. But it looks like both
patches are very invasive, and they are not just enabling features
that are already in the tree, but introduce new stuff that is not even
tested for long in master.

I guess we'll need to wait for those till Liberty. Unless
nova-core-maint has a different opinion and good arguments to approach
the merge.

Ihar

On 08/05/2015 12:37 PM, Kuvaja, Erno wrote:

Hi Gary,



While I do understand the interest to get this functionality
included, I really fail to see how it would comply with the Stable
Branch Policy:
https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy

Obviously the last say is on stable-maint-core, but normally new
features are really no-no to stable branches.



My concerns are more on the metadata side of your changes.

Even the refactoring is fairly clean it is major part of the
metadata handler.

It also changes the API (In the case of X-Metadata-Provider being
present) which tends to be sacred on stable branches.



The changes here does not actually fix any bug but just implements
new functionality that missed kilo not even slightly but by months.
Thus my -1 for merging these.



-  Erno



*From:*Gary Kotton [mailto:gkot...@vmware.com] *Sent:* Wednesday,
August 05, 2015 8:03 AM *To:* OpenStack List *Subject:*
[openstack-dev] [Stable][Nova] VMware NSXv Support



Hi,

In the Kilo cycle a Neutron driver was added for supporting the
Vmware NSXv plugin. This required patches in Nova to enable the
plugin to work with Nova. These patches finally landed yesterday. I
have back ported them to stable/kilo as the Neutron driver is
unable to work without these in stable/kilo. The patches can be
found at:

1. VNIC support - https://review.openstack.org/209372 2. Metadata
support - https://review.openstack.org/209374

I hope that the stable team can take this into consideration.



Thanks in advance

Gary



__






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

iQEcBAEBCAAGBQJVwgkjAAoJEC5aWaUY1u57NacIALsJ8oo6eJKqJIidBSFzwxvg
zqJXHE56Lpg62/afRF94B2edfhm791Mz42LTFn0BHHRjV51TQX4k/Jf3Wr22CEvm
zFZkU5eVMVOSL3GGnOZqSv/T06gBWmlMVodmSKQjGxrIL1s8G1m4aTwe6Pqs+lie
N+cT0pZbcjL/P1wYTac6XMpF226gO1owUjhE4oj9VZzx7kEqNsv22SIzVN2fQcco
YLs/LEcabMhuuV4Amde3RqUr0BkB+mlIX1TUv5/FTXT/F4ZwzYS/DBH9MaBJ5t8n
hgCTJzCeg598+irgOt3VJ3Jn3Unljz6LNzKIM8RnBG0o51fp8vfE/mODQQaUKOg=
=ZYP8
-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



https://review.openstack.org/#/c/165750/ is a feature add but it's not 
targeted against a blueprint, so it's just running as a random thing 
outside any tracking mechanism for features (launchpad).


Salvatore made some comments back in March but otherwise no one from the 
VMware development team has even commented on this.  As I've said in 
some other VMware patches in Nova lately, I expect the VMware sub-team 
to be doing a better job of reviewing each other's code first since they 
are supposed to be the subject matter experts here.


I know Gary reviews pretty much all of the changes that go into the 
VMware driver in Nova but I don't see the same reciprocated from other 
members of that team which I think also slows down development - and it 
impedes building a trust relationship between nova-core and the sub-team 
to be self-reviewing.


--

Thanks,

Matt Riedemann

Re: [openstack-dev] [Stable][Nova] VMware NSXv Support



On 8/10/15, 5:46 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote:



On 8/10/2015 9:17 AM, Gary Kotton wrote:
 Hi,
 I am not really sure what to say here. The code was in review for over 8
 months. On a side note but related - we have a patch for a plugin
 developed in Liberty - https://review.openstack.org/#/c/165750/. This
has
 been in review since March. I really hope that that lands in Liberty. If
 not we will go through the same thing again.
 Working in Nova on code that is self contained within a driver is
 difficult - terribly difficult. Not only is this demotivating, it also
 effectively does not help any of the drivers actually add any features.
 A sad day for OpenStack.
 Thanks
 Gary

 On 8/5/15, 4:01 PM, Ihar Hrachyshka ihrac...@redhat.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Hi,

 I think Erno made a valid point here. If that would touch only vmware
 code, that could be an option to consider. But it looks like both
 patches are very invasive, and they are not just enabling features
 that are already in the tree, but introduce new stuff that is not even
 tested for long in master.

 I guess we'll need to wait for those till Liberty. Unless
 nova-core-maint has a different opinion and good arguments to approach
 the merge.

 Ihar

 On 08/05/2015 12:37 PM, Kuvaja, Erno wrote:
 Hi Gary,



 While I do understand the interest to get this functionality
 included, I really fail to see how it would comply with the Stable
 Branch Policy:
 https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy

 Obviously the last say is on stable-maint-core, but normally new
 features are really no-no to stable branches.



 My concerns are more on the metadata side of your changes.

 Even the refactoring is fairly clean it is major part of the
 metadata handler.

 It also changes the API (In the case of X-Metadata-Provider being
 present) which tends to be sacred on stable branches.



 The changes here does not actually fix any bug but just implements
 new functionality that missed kilo not even slightly but by months.
 Thus my -1 for merging these.



 -  Erno



 *From:*Gary Kotton [mailto:gkot...@vmware.com] *Sent:* Wednesday,
 August 05, 2015 8:03 AM *To:* OpenStack List *Subject:*
 [openstack-dev] [Stable][Nova] VMware NSXv Support



 Hi,

 In the Kilo cycle a Neutron driver was added for supporting the
 Vmware NSXv plugin. This required patches in Nova to enable the
 plugin to work with Nova. These patches finally landed yesterday. I
 have back ported them to stable/kilo as the Neutron driver is
 unable to work without these in stable/kilo. The patches can be
 found at:

 1. VNIC support - https://review.openstack.org/209372 2. Metadata
 support - https://review.openstack.org/209374

 I hope that the stable team can take this into consideration.



 Thanks in advance

 Gary



 __
 


 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

 iQEcBAEBCAAGBQJVwgkjAAoJEC5aWaUY1u57NacIALsJ8oo6eJKqJIidBSFzwxvg
 zqJXHE56Lpg62/afRF94B2edfhm791Mz42LTFn0BHHRjV51TQX4k/Jf3Wr22CEvm
 zFZkU5eVMVOSL3GGnOZqSv/T06gBWmlMVodmSKQjGxrIL1s8G1m4aTwe6Pqs+lie
 N+cT0pZbcjL/P1wYTac6XMpF226gO1owUjhE4oj9VZzx7kEqNsv22SIzVN2fQcco
 YLs/LEcabMhuuV4Amde3RqUr0BkB+mlIX1TUv5/FTXT/F4ZwzYS/DBH9MaBJ5t8n
 hgCTJzCeg598+irgOt3VJ3Jn3Unljz6LNzKIM8RnBG0o51fp8vfE/mODQQaUKOg=
 =ZYP8
 -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


https://review.openstack.org/#/c/165750/ is a feature add but it's not
targeted against a blueprint, so it's just running as a random thing
outside any tracking mechanism for features (launchpad).

Salvatore made some comments back in March but otherwise no one from the
VMware development team has even commented on this.  As I've said in
some other VMware patches in Nova lately, I expect the VMware sub-team
to be doing a better job of reviewing each other's code first since they
are supposed to be the subject matter experts here.

I know Gary reviews pretty much all of the changes that go into the
VMware driver in Nova but I don't see the same reciprocated from other
members of that team which I think also slows down development - and it
impedes building a trust

Re: [openstack-dev] How should we expose host capabilities to the scheduler

2015-08-10 Thread Chris Friesen


On 08/10/2015 08:05 AM, Jay Pipes wrote:


The Glance metadefs stuff is problematic in a number of ways:

1) It wasn't written with Nova in mind at all, but rather for UI needs. This
means it introduces a bunch of constants that are different from the constants
in Nova.

2) It uses a custom JSON format instead of JSONSchema, so we now need to figure
out the schema for these metadef documents and keep up to date with that schema
as it changes.

3) It mixes qualitative things -- CPU model, features, etc -- with quantitative
things -- amount of cores, threads, etc. These two things are precisely what we
are trying to decouple from each other in the next generation of Nova's 
flavors.

4) It is still missing the user-facing representation of these things. Users --
i.e. the people launching VMs in Nova -- do not want or need to know whether the
underlying hardware is running Nehalem processors or Sandybridge processors.
They only need to know the set of generic features that are exposed to the
workloads running on the host. In other words, we are looking for a way to map
service levels such as Silver Compute or Whizbang Amazing Compute to a set
of hardware that exposes some features. We need that compatibility layer on top
of the low-level hardware specifics that will allow service providers to create
these product categories if you will.


I think it would make sense for an end user to be able to specify something like 
my image requires at least a Sandybridge virtual processor or better to run 
properly.  Now from what I understand vendors sometimes mask out CPU features 
for some reason, so it might actually be necessary to do something like my 
image requires at least a Sandybridge or better, and I specifically want to make 
sure that CPU features X, Y, and Z are enabled.


Maybe this could work with what you suggest above in that if the requirement 
isn't met by the service level then the user gets a nice error message saying 
they need to set a particular service level or better.


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

Re: [openstack-dev] [Stable][Nova] VMware NSXv Support

2015-08-10 Thread Kuvaja, Erno

 -Original Message-
 From: Gary Kotton [mailto:gkot...@vmware.com]
 Sent: Monday, August 10, 2015 4:18 PM
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Stable][Nova] VMware NSXv Support

 On 8/10/15, 6:05 PM, Gary Kotton gkot...@vmware.com wrote:

 On 8/10/15, 6:03 PM, Gary Kotton gkot...@vmware.com wrote:

 On 8/10/15, 5:46 PM, Matt Riedemann mrie...@linux.vnet.ibm.com
 wrote:

 On 8/10/2015 9:17 AM, Gary Kotton wrote:
  Hi,
  I am not really sure what to say here. The code was in review for
 over
 8
  months. On a side note but related - we have a patch for a plugin
 developed in Liberty - https://review.openstack.org/#/c/165750/.
 This has  been in review since March. I really hope that that lands
 in Liberty.
 If
  not we will go through the same thing again.
  Working in Nova on code that is self contained within a driver is
 difficult - terribly difficult. Not only is this demotivating, it
 also  effectively does not help any of the drivers actually add any
 features.
  A sad day for OpenStack.
  Thanks
  Gary

  On 8/5/15, 4:01 PM, Ihar Hrachyshka ihrac...@redhat.com wrote:

  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256

  Hi,

  I think Erno made a valid point here. If that would touch only
 vmware  code, that could be an option to consider. But it looks
 like both  patches are very invasive, and they are not just
 enabling features  that are already in the tree, but introduce new
 stuff that is not even  tested for long in master.

  I guess we'll need to wait for those till Liberty. Unless
 nova-core-maint has a different opinion and good arguments to
 approach  the merge.

  Ihar

  On 08/05/2015 12:37 PM, Kuvaja, Erno wrote:
  Hi Gary,

  While I do understand the interest to get this functionality
  included, I really fail to see how it would comply with the
  Stable Branch Policy:
  https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy

  Obviously the last say is on stable-maint-core, but normally new
  features are really no-no to stable branches.

  My concerns are more on the metadata side of your changes.

  Even the refactoring is fairly clean it is major part of the
  metadata handler.

  It also changes the API (In the case of X-Metadata-Provider being
  present) which tends to be sacred on stable branches.

  The changes here does not actually fix any bug but just
  implements new functionality that missed kilo not even slightly but
 by months.
  Thus my -1 for merging these.

  -  Erno

  *From:*Gary Kotton [mailto:gkot...@vmware.com] *Sent:*
 Wednesday,
  August 05, 2015 8:03 AM *To:* OpenStack List *Subject:*
  [openstack-dev] [Stable][Nova] VMware NSXv Support

  Hi,

  In the Kilo cycle a Neutron driver was added for supporting the
  Vmware NSXv plugin. This required patches in Nova to enable the
  plugin to work with Nova. These patches finally landed yesterday.
  I have back ported them to stable/kilo as the Neutron driver is
  unable to work without these in stable/kilo. The patches can be
  found at:

  1. VNIC support - https://review.openstack.org/209372 2. Metadata
  support - https://review.openstack.org/209374

  I hope that the stable team can take this into consideration.

  Thanks in advance

  Gary

 __
 ___
 _

  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

 iQEcBAEBCAAGBQJVwgkjAAoJEC5aWaUY1u57NacIALsJ8oo6eJKqJIidBSFzwxv
 g

 zqJXHE56Lpg62/afRF94B2edfhm791Mz42LTFn0BHHRjV51TQX4k/Jf3Wr22CEv
 m

 zFZkU5eVMVOSL3GGnOZqSv/T06gBWmlMVodmSKQjGxrIL1s8G1m4aTwe6P
 qs+lie

 N+cT0pZbcjL/P1wYTac6XMpF226gO1owUjhE4oj9VZzx7kEqNsv22SIzVN2fQcc
 o

 YLs/LEcabMhuuV4Amde3RqUr0BkB+mlIX1TUv5/FTXT/F4ZwzYS/DBH9MaBJ5t
 8n

 hgCTJzCeg598+irgOt3VJ3Jn3Unljz6LNzKIM8RnBG0o51fp8vfE/mODQQaUKOg
 =
  =ZYP8
  -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

 https://review.openstack.org/#/c/165750/ is a feature add but it's
 not targeted against a blueprint, so it's just running as a random
 thing outside any tracking mechanism for features (launchpad).

 Salvatore made some comments back in March but

Re: [openstack-dev] How should we expose host capabilities to the scheduler

2015-08-10 Thread Chris Friesen


On 08/10/2015 10:11 AM, Dugger, Donald D wrote:

In re: Different architectures.

I'm not saying we should create architecture specific definitions in our
APIs.  I like the idea of capabilities being exposed as arbitrary strings
like AES or AltiVec.  An Intel user would be providing an IA architecture
image and should know that it makes no sense to request AltiVec
capabilities (and that request would correctly fail as either the image
wouldn't run on the selected host or no host would be selected).

I'm looking for Nova to provide a common way of exposing and requesting host
capabilities and you just use appropriate architecture specific strings when
using these common interfaces.


There are some complications.

For non-x86 architectures they don't have the equivalent of CPU features 
exposed.  It's basically all encoded in the CPU model.


For x86, you can't just pick features, you actually need to specify the guest 
CPU model in order to ensure that live-migration is possible between hosts with 
potentially different host CPU models.  Also, the guest CPU model is not 
sufficient by itself, because different cloud vendors mask out different CPU 
features from the guest.  (Still not totally sure why, but apparently they do.)


So specifically for CPU model/features I think we'd want to allow the 
specification of a CPU flavor, which would expose a vCPU model and (if 
appropriate) a set of features that could be queried.  These would be created by 
the admin, likely to match the underlying hardware available in the cloud. 
(Since it doesn't buy you anything to expose CPU models that don't match up with 
a host CPU model.)


I'm not quite sure how to deal with clouds that have multiple hypervisors, since 
the different hypervisors have subtly different virtual CPU models/features.


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] [Fuel] Fuel Project Specifications

2015-08-10 Thread Alexander Charykov

Hello all.

We have launched fuel specs service at [1] where you can read fuel
project specifications.

[1] http://specs.fuel-infra.org/fuel-specs-master/

-- 
Alexander C. DevOps Engineer.

__
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] [Glance] glance_store and glance

2015-08-10 Thread Flavio Percoco


On 07/08/15 01:21 -0400, Nikhil Komawar wrote:

Hi,

During the mid-cycle we had another proposal that wanted to put back the
glance_store library back into the Glance repo and not leave it is as a
separate repo/project.


I replied to a different email in this thread but I'd like to reply to
the original one to make sure my take on this is clear.



The questions outstanding are: what are the use cases that want it as a
separate library?


As mentioned in the meeting you linked in your email, I'm against
merging glance_store back into Glance. A few reasons below.


The original use cases that supported a separate lib have not had much
progress or adoption yet. There have been complaints about overhead of
maintaining it as a separate lib and version tracking without much gain.
The proposals for the re-factor of the library is also a worrysome topic
in terms of the stability of the codebase.

The original use cases from my memory are:
1. Other projects consuming glance_store -- this has become less likely
to be useful.


As mentioned by Jay/Mike and as I also mentioned in the meeting, this
is not true. Actually, based on the meeting logs, I believe this
statement is being made on the assumption that other proposals - like
the seam library Jessee proposed[0] - will be acceted. We can't make
plans based on things that haven't happend yet and that clearly have
different, strong, opinions.


2. another upload path for users for the convenience of tasks -- not
preferable as we don't want to expose this library to users.


If by users you mean people using glanceclient then I think this
statement is not valid either. The reason is that we've discussed this
in the past and we've clearly said that these is a library that is to
be consumed by services - especially with the current API - rather
than by end-users.


3. ease of addition of newer drivers for the developers -- drivers are
only being removed since.


Which is a good thing. We've removed drivers that are not maintained
anymore, which will give us more time and bandwidth to dedicate to
hypothetical new drivers. The ease of addition exists, the fact that
there are no new drivers is not a real problem.

Also, these drivers don't need to live in glance_store, that's one of
the points of having stevedore in place to handle these plugins for
us.


4. cleaner api / more methods that support backend store capabilities -
a separate library is not necessarily needed, smoother re-factor is
possible within Glance codebase.


We can work on a less agressive re-factor if needed. The problem with
the current proposed re-factor is not the re-factor itself but the
lack of attention from the community.

If we want the library's API to be cleaned up, we need to get to it. I
proposed the first version of that spec that Cindy took over later on.
The spec hasn't been changed much because there has not been enough
feedback other than show me the code.

Admitedly, the re-factored code hasn't been shown entirely but lets be
honest with ourselves, if the proposal is the issue, the code won't
fix it. Lets work on a smoother refactor and get this over with. (Note
that the proposal says clearly that it'll add a new API but it'll keep
the older to give enough time for services to migrate).[1]



Also, the authN/Z complexities and ACL restrictions on the back-end
stores can be potential security loopholes with the library and Glance
evolution separately.


Fair enough. However, this is not new and it has been fixed elsewhere,
I believe. I also think we should have a better public API to be able
to provide better ACL guarantees.



In order to move forward smoothly on this topic in Liberty, I hereby
request input from all concerned developer parties. The decision to keep
this as a separate library will remain in effect if we do not come to
resolution within 2 weeks from now. However, if there aren't any
significant use cases we may consider a port back of the same.


In case it wasn't clear, I'm against merging this back into Glance and
it has nothing to do with the Sunk Cost Fallacy[2] as Jesse mentioned
in one of his emails. There are no just past efforts on this library.
There are on-going efforts to make it lighter and hopefully better,
there are efforts on having services consuming it.

One last note. I don't believe the benefits of this library should be
messured just on how many projects are using it or whether we have a
maintenance cost or not - which I don't think we really have.

For instance, the library gives us a better code structure, it allows
for other services to consume it and talk to external stores that are
not managed by Glance - why not?. In addition to this, it will help us
building a better abstraction for the library and hopefully a more
secure interaction between the Glance's API and the store, which we
didn't have because the code was in Glance's code base. This doesn't
mean a proper abstraction shouldn't have been built, though.

Anyway, no, please, lets not

Re: [openstack-dev] [Stable][Nova] VMware NSXv Support



On 8/10/15, 6:03 PM, Gary Kotton gkot...@vmware.com wrote:



On 8/10/15, 5:46 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote:



On 8/10/2015 9:17 AM, Gary Kotton wrote:
 Hi,
 I am not really sure what to say here. The code was in review for over
8
 months. On a side note but related - we have a patch for a plugin
 developed in Liberty - https://review.openstack.org/#/c/165750/. This
has
 been in review since March. I really hope that that lands in Liberty.
If
 not we will go through the same thing again.
 Working in Nova on code that is self contained within a driver is
 difficult - terribly difficult. Not only is this demotivating, it also
 effectively does not help any of the drivers actually add any features.
 A sad day for OpenStack.
 Thanks
 Gary

 On 8/5/15, 4:01 PM, Ihar Hrachyshka ihrac...@redhat.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Hi,

 I think Erno made a valid point here. If that would touch only vmware
 code, that could be an option to consider. But it looks like both
 patches are very invasive, and they are not just enabling features
 that are already in the tree, but introduce new stuff that is not even
 tested for long in master.

 I guess we'll need to wait for those till Liberty. Unless
 nova-core-maint has a different opinion and good arguments to approach
 the merge.

 Ihar

 On 08/05/2015 12:37 PM, Kuvaja, Erno wrote:
 Hi Gary,



 While I do understand the interest to get this functionality
 included, I really fail to see how it would comply with the Stable
 Branch Policy:
 https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy

 Obviously the last say is on stable-maint-core, but normally new
 features are really no-no to stable branches.



 My concerns are more on the metadata side of your changes.

 Even the refactoring is fairly clean it is major part of the
 metadata handler.

 It also changes the API (In the case of X-Metadata-Provider being
 present) which tends to be sacred on stable branches.



 The changes here does not actually fix any bug but just implements
 new functionality that missed kilo not even slightly but by months.
 Thus my -1 for merging these.



 -  Erno



 *From:*Gary Kotton [mailto:gkot...@vmware.com] *Sent:* Wednesday,
 August 05, 2015 8:03 AM *To:* OpenStack List *Subject:*
 [openstack-dev] [Stable][Nova] VMware NSXv Support



 Hi,

 In the Kilo cycle a Neutron driver was added for supporting the
 Vmware NSXv plugin. This required patches in Nova to enable the
 plugin to work with Nova. These patches finally landed yesterday. I
 have back ported them to stable/kilo as the Neutron driver is
 unable to work without these in stable/kilo. The patches can be
 found at:

 1. VNIC support - https://review.openstack.org/209372 2. Metadata
 support - https://review.openstack.org/209374

 I hope that the stable team can take this into consideration.



 Thanks in advance

 Gary



 
__
 


 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

 iQEcBAEBCAAGBQJVwgkjAAoJEC5aWaUY1u57NacIALsJ8oo6eJKqJIidBSFzwxvg
 zqJXHE56Lpg62/afRF94B2edfhm791Mz42LTFn0BHHRjV51TQX4k/Jf3Wr22CEvm
 zFZkU5eVMVOSL3GGnOZqSv/T06gBWmlMVodmSKQjGxrIL1s8G1m4aTwe6Pqs+lie
 N+cT0pZbcjL/P1wYTac6XMpF226gO1owUjhE4oj9VZzx7kEqNsv22SIzVN2fQcco
 YLs/LEcabMhuuV4Amde3RqUr0BkB+mlIX1TUv5/FTXT/F4ZwzYS/DBH9MaBJ5t8n
 hgCTJzCeg598+irgOt3VJ3Jn3Unljz6LNzKIM8RnBG0o51fp8vfE/mODQQaUKOg=
 =ZYP8
 -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


https://review.openstack.org/#/c/165750/ is a feature add but it's not
targeted against a blueprint, so it's just running as a random thing
outside any tracking mechanism for features (launchpad).

Salvatore made some comments back in March but otherwise no one from the
VMware development team has even commented on this.  As I've said in
some other VMware patches in Nova lately, I expect the VMware sub-team
to be doing a better job of reviewing each other's code first since they
are supposed to be the subject matter experts here.

I know Gary reviews pretty much all of the changes that go into the
VMware driver in Nova but I don't see the same reciprocated from other
members of that team which I think also

[openstack-dev] [cinder] [nova] Cinder and Nova availability zones

2015-08-10 Thread Dulko, Michal

Hi,

In Kilo cycle [1] was merged. It started passing AZ of a booted VM to Cinder to 
make volumes appear in the same AZ as VM. This is certainly a good approach, 
but I wonder how to deal with an use case when administrator cares about AZ of 
a compute node of the VM, but wants to ignore AZ of volume. Such case would be 
when fault tolerance of storage is maintained on another level - for example 
using Ceph replication and failure domains.

Normally I would simply disable AvailabilityZoneFilter in cinder.conf, but it 
turns out cinder-api validates if availability zone is correct [2]. This means 
that if Cinder has no AZs configured all requests from Nova will fail on an API 
level.

Configuring fake AZs in Cinder is also problematic, because AZ cannot be 
configured on a per-backend manner. I can only configure it per c-vol node, so 
I would need N extra nodes running c-vol,  where N is number of AZs to achieve 
that.

Is there any solution to satisfy such use case?

[1] https://review.openstack.org/#/c/157041
[2] 
https://github.com/openstack/cinder/blob/master/cinder/volume/flows/api/create_volume.py#L279-L282

__
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] How should we expose host capabilities to the scheduler

2015-08-10 Thread Dugger, Donald D

In re: user specifying requirements

Note that we have 2 different requirements here:

1) The cloud user needs to be able to specify I want to run this image on a 
machine that supports capability `foo'.
2) The cloud provider needs to be able to say If you want capability `foo' 
it'll cost you.  The cloud provider needs to be able to provide tiers of 
service with appropriate pricing models for those different tiers.

Note that the pricing tier issues means that we have to be careful about how 
the user asks for capabilities.  If we bury that into the image meta-data then 
the user could unexpectedly find himself implicitly asking for a pricier 
instance than expected.

--
Don Dugger
Censeo Toto nos in Kansa esse decisse. - D. Gale
Ph: 303/443-3786

-Original Message-
From: Chris Friesen [mailto:chris.frie...@windriver.com] 
Sent: Monday, August 10, 2015 9:22 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] How should we expose host capabilities to the 
scheduler

On 08/10/2015 08:05 AM, Jay Pipes wrote:

 The Glance metadefs stuff is problematic in a number of ways:

 1) It wasn't written with Nova in mind at all, but rather for UI 
 needs. This means it introduces a bunch of constants that are 
 different from the constants in Nova.

 2) It uses a custom JSON format instead of JSONSchema, so we now need 
 to figure out the schema for these metadef documents and keep up to 
 date with that schema as it changes.

 3) It mixes qualitative things -- CPU model, features, etc -- with 
 quantitative things -- amount of cores, threads, etc. These two things 
 are precisely what we are trying to decouple from each other in the next 
 generation of Nova's flavors.

 4) It is still missing the user-facing representation of these things. 
 Users -- i.e. the people launching VMs in Nova -- do not want or need 
 to know whether the underlying hardware is running Nehalem processors or 
 Sandybridge processors.
 They only need to know the set of generic features that are exposed to 
 the workloads running on the host. In other words, we are looking for 
 a way to map service levels such as Silver Compute or Whizbang 
 Amazing Compute to a set of hardware that exposes some features. We 
 need that compatibility layer on top of the low-level hardware 
 specifics that will allow service providers to create these product 
 categories if you will.

I think it would make sense for an end user to be able to specify something 
like my image requires at least a Sandybridge virtual processor or better to 
run properly.  Now from what I understand vendors sometimes mask out CPU 
features for some reason, so it might actually be necessary to do something 
like my image requires at least a Sandybridge or better, and I specifically 
want to make sure that CPU features X, Y, and Z are enabled.

Maybe this could work with what you suggest above in that if the requirement 
isn't met by the service level then the user gets a nice error message saying 
they need to set a particular service level or better.

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 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] [nova] Cinder and Nova availability zones

2015-08-10 Thread John Griffith

On Mon, Aug 10, 2015 at 9:24 AM, Dulko, Michal michal.du...@intel.com
wrote:

Hi,

In Kilo cycle [1] was merged. It started passing AZ of a booted VM to
Cinder to make volumes appear in the same AZ as VM. This is certainly a
good approach, but I wonder how to deal with an use case when administrator
cares about AZ of a compute node of the VM, but wants to ignore AZ of
volume. Such case would be when fault tolerance of storage is maintained on
another level - for example using Ceph replication and failure domains.

Normally I would simply disable AvailabilityZoneFilter in cinder.conf, but
it turns out cinder-api validates if availability zone is correct [2]. This
means that if Cinder has no AZs configured all requests from Nova will fail
on an API level.

Configuring fake AZs in Cinder is also problematic, because AZ cannot be
configured on a per-backend manner. I can only configure it per c-vol node,
so I would need N extra nodes running c-vol, where N is number of AZs to
achieve that.

Is there any solution to satisfy such use case?

[1] https://review.openstack.org/#/c/157041
[2]
https://github.com/openstack/cinder/blob/master/cinder/volume/flows/api/create_volume.py#L279-L282

Seems like we could introduce the capability in cinder to ignore that if
it's desired? It would probably be worth looking on the Cinder side at
being able to configure multiple AZ's for a volume (perhaps even an
aggregate Zone just for Cinder). That way we still honor the setting but
provide a way to get around it for those that know what they're doing.

John
__
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

2015-08-10 Thread Anastasia Kuznetsova

Thanks everyone for coming!

Meeting minutes:
http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-08-10-16.03.txt
Meeting log:
http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-08-10-16.03.log.html

The next meeting will be on Aug 17. You can post your agenda items at
https://wiki.openstack.org/wiki/Meetings/MistralAgenda

-- 
Best regards,
Anastasia Kuznetsova
__
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] OS::Neutron::Port fails to set security group by name, no way to retrieve group ID from Neutron::SecurityGroup

2015-08-10 Thread jason witkowski

Please ignore this thread.  The issue was the line ' device_owner:
network:dhcp ' from the server_port resource.  Once removed the port was
created with the security group attached.

On Mon, Aug 10, 2015 at 10:11 AM, jason witkowski jwit...@gmail.com wrote:

 Just to confirm as well if I use the CLI to create a neutron port after
 the Heat stack has ran and created the security group everything works fine
 and the security group is attached to the neutron port as expected.
 However heat is not managing to make this happen, even if I run a check or
 an update after the first run I am still met with neutron ports with no
 security groups.  Looking at the code snippets above it looks like default
 is only not applied when an empty list is supplied.  Wouldn't this mean
 that the get_resource function is returning empty?

 On Sun, Aug 9, 2015 at 7:25 PM, jason witkowski jwit...@gmail.com wrote:

 Steve,

 There is no error.  Heat reports a successful build with no issues.  I've
 attached the neutron port-show as well as the full heat engine logs for a
 build of the stack start to end.

 http://paste.openstack.org/show/412313/ - Heat Engine logs
 http://paste.openstack.org/show/412314/ - neutron port-show on newly
 created interface


 -Jason

 On Sun, Aug 9, 2015 at 6:51 PM, Steve Baker sba...@redhat.com wrote:

 On 08/08/15 01:51, jason witkowski wrote:

 Thanks for the replies guys.  The issue is that it is not working.  If
 you take a look at the pastes I linked from the first email I am using the
 get_resource function in the security group resource. I am not sure if it
 is not resolving to an appropriate value or if it is resolving to an
 appropriate value but then not assigning it to the port. I am happy to
 provide any more details or examples but I'm not sure what else I can do
 but provide the configuration examples I am using that are not working?
 It's very possible my configurations are wrong but I have scoured the
 internet for any/all examples and it looks like what I have should be
 working but it is not.


 Can you provide details of what the actual error is, plus the output of
 neutron port-show for that port?



 __
 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] [tempest] Mellanox CI request to comment

2015-08-10 Thread Matthew Treinish

On Mon, Aug 10, 2015 at 10:56:00AM +, Lenny Verkhovsky wrote:
 Hi all,
 Lately we discovered a bug[1] in tempest after the code was merged.
 To minimize such things in the future we are asking permission for our CI
 to comment as non-voting CI to tempest commits.

As long as it's not leaving -1 votes on failures (at least to start) I
personally don't have any issue with your ci commenting on tempest changes.
There have been a couple external CI systems that have commented on tempest
changes in the past, although there aren't too many right now.

-Matt Treinish

 
 We are running SR-IOV tempest tests on Mellanox HW.
 
 Our CI results can be viewed here[2]
 Our CI page can be viewed here[3]
 
 
 [1] https://review.openstack.org/#/c/209553/1
 [2] http://144.76.193.39/ci-artifacts/Nova-ML2-Sriov_1864
 [3] https://wiki.openstack.org/wiki/ThirdPartySystems/Mellanox_CI
 
 Thanks.
 Lenny Verkhovsky
 


signature.asc
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] [Fuel][Puppet] Keystone V2/V3 service endpoints

2015-08-10 Thread Rich Megginson


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/


I don't think so.  Keystone requires the version suffix /v2.0 or /v3.

2 - openstackclient should be able to interpret v3 requests and append 
v3/ to OS_AUTH_URL=http://keystone-server.5000/ or rewrite the URL 
if it is set as OS_AUTH_URL=http://keystone-server.5000/


It does, if it can determine from the given authentication arguments if 
it can do v3 or v2.0.


3 - All deployments require /etc/keystone/keystone.conf with a token 
(and not simply use openrc for creating additional endpoints, users, 
etc beyond keystone itself and an admin user)


No.  What I said about this issue was Most people using 
puppet-keystone, and realizing Keystone resources on nodes that are not 
the Keystone node, put a /etc/keystone/keystone.conf on that node with 
the admin_token in it.


That doesn't mean the deployment requires /etc/keystone/keystone.conf.  
It should be possible to realize Keystone resources on non-Keystone 
nodes by using ENV or openrc or other means.




I believe it should be possible to set v2.0 keystone OS_AUTH_URL in 
openrc and puppet-keystone + puppet-openstacklib should be able to 
make v3 requests sensibly by manipulating the URL.


Yes.  Because for the puppet-keystone resource providers, they are coded 
to a specific version of the api, and therefore need to be able to 
set/override the OS_IDENTITY_API_VERSION and the version suffix in the URL.


Additionally, creating endpoints/users/roles shouldbe possible via 
openrc alone.


Yes.

It's not possible to write single node tests that can demonstrate this 
functionality, which is why it probably went undetected for so long.


And since this is supported, we need tests for this.


If anyone can speak up on these items, it could help influence the 
outcome of this patch.


Thank you for your time.

Best Regards,
Matthew Mosesohn

On Fri, Jul 31, 2015 at 6:32 PM, Rich Megginson rmegg...@redhat.com 
mailto:rmegg...@redhat.com wrote:


On 07/31/2015 07:18 AM, Matthew Mosesohn wrote:

Jesse, thanks for raising this. Like you, I should just track
upstream
and wait for full V3 support.

I've taken the quickest approach and written fixes to
puppet-openstacklib and puppet-keystone:
https://review.openstack.org/#/c/207873/
https://review.openstack.org/#/c/207890/

and again to Fuel-Library:
https://review.openstack.org/#/c/207548/1

I greatly appreciate the quick support from the community to
find an
appropriate solution. Looks like I'm just using a weird edge case
where we're creating users on a separate node from where
keystone is
installed and it never got thoroughly tested, but I'm happy to fix
bugs where I can.


Most puppet deployments either realize all keystone resources on
the keystone node, or drop an /etc/keystone/keystone.conf with
admin token onto non-keystone nodes where additional keystone
resources need to be realized.



-Matthew

On Fri, Jul 31, 2015 at 3:54 PM, Jesse Pretorius
jesse.pretor...@gmail.com mailto:jesse.pretor...@gmail.com
wrote:

With regards to converting all services to use Keystone v3
endpoints, note
the following:

1) swift-dispersion currently does not support consuming
Keystone v3
endpoints [1]. There is a patch merged to master [2] to
fix that, but a
backport to kilo is yet to be done.
2) Each type (internal, admin, public) of endpoint created
with the Keystone
v3 API has its own unique id, unlike with the v2 API where
they're all
created with a single ID. This results in the keystone
client being unable
to read the catalog created via the v3 API when querying
via the v2 API. The
solution is to use the openstack client and to use the v3
API but this
obviously needs to be noted for upgrade impact and operators.
3) When glance is setup to use swift as a back-end,
glance_store is unable
to authenticate to swift when the endpoint it uses is a v3
endpoint. There
is a review to master in progress [3] to fix this which is
unlikely to make
it into kilo.

We (the openstack-ansible/os-ansible-deployment project)
are

Re: [openstack-dev] [Glance][Nova][Cinder] glance_store and glance

2015-08-10 Thread Flavio Percoco


On 07/08/15 14:02 +, Jesse Cook wrote:

I largely agree with the points made in the messages by Nikhil and Erno. A
few additional points.

One of the biggest use cases that I heard for glance_store (true, false,
or otherwise) was that Glance is a bottleneck and an unnecessary proxy to
the stores and consumers should be able to interface with the stores
directly. A few lessons learned from creating and subsequently killing
Glance Bypass internally (bypass Glance to interface directly with the
store i.e. Swift in our case):


True and false. I've heard several times that Glance is the bottleneck
but no, that was not the main reason for this library to be pulled
out. One reason, besides it allowing services talk to Glance's stores
directly was to allow for fancier things like CoW, etc. This can be
translated in faster boot times but again, that's a side effect of
some of the features that are being targeted.


1. The proxy is not free, but it¹s not the bottleneck (assuming you have
decent networking on your Glance API nodes)
2. Maintaining the code to interface directly with the object store is
expensive and reinvents what Glance already does killing the value of
moving Glance out of Nova tree


Not really. Glance is more than a simple interface to a storage.
Glance is an image registry that happens to store images itself.
Honeslty, once we have a better API, the glance_store shouldn't
receive much changes other than bug fixes - that should not be
underestimated - and new stores(?).


3. Loses the abstraction provided by Glance


I'm failing to see what abstraction we are loosing here. Mind
elaborating more? I read this as a one-line version of #2 but I assume
I'm just missing the point.


4. Allows retrying uploads (this is being fixed in Glance in Liberty along
with other reliability and performance improvements)


This would be handled by the service consuming glance_store. Sure,
Glance could do this for you but there's an extra cost there. Also,
lets not forget that using glance_store is *optional*.



My current perception is that glance_store raises confidence issues
outside the community with the Glance and causes confusion about what and
how to consume the project. It¹s a leaky abstraction and leads to a path
of maintaining multiple APIs and circular dependencies.


Ok, I'll need you to elaborate more on this as well. What confidence
issues does it raise? What confusion is it causing? It's been around
for 3 - or 4? - cycles already, it's been packaged, shipped and
installed. It's deprecated some stores and people are well aware of
what it does - at least I haven't head any complains on that side - so
I fail to see your point here, again.

Again, if you are refering to the the current API as the leaky
abstraction, I believe we all know how we can fix that.


Glance should provide a single clean API that ensures data
consistency, is performant, and has reliability guarantees.


This I agree with and I believe Glance does that - well without the
consistent, performant and reliable parts ;). Seriously, I don't think
glance_store takes the Glance team through a path that leads to worse
APIs. If anything, I really hope that it'll help us to focus more on
the Glance API.

There's a lot to improve and way more to do. I think glance_store is
the lease worrysome of our problems.



One other thought: After seeing some of the discussion on IRC I want to
remind people that the sunken cost fallacy can strongly influence one¹s
position, so please think carefully about the use cases and value outside
the cost already put into splitting it out.


It has not much to do with this, really. I mentioned that we had put
lots of efforts in pulling it out, true. But lets be honest, there's
more to it than past efforts and we should not focus on seeing the
current benefit but the future benefit.

Thanks for all the insights,
Flavio


On 8/7/15, 3:56 AM, Kuvaja, Erno kuv...@hp.com wrote:


Hi,

Flagged Nova and Cinder into this discussion as they were the first
intended adopters iirc.

I don't have big religious view about this topic. I wasn't huge fan of
the idea separating it in the first place and I'm not huge fan of keeping
it separate either.

After couple of cycles we have so far witnessed only the downside of
glance_store being on it's own. We break even our own gate with our own
lib releases, we have one extra bug tracker to look after and even not
huge but it just increases the load on the release and stable teams as
well.

In my understanding the interest within Nova to consume glance_store
directly has pretty much died off since we separated it, please do
correct me if I'm wrong.
I haven't heard anyone expressing any interest to consume glance_store
directly within Cinder either.
So far I have failed to see use-case for glance_store alone apart from
Glance API Server and the original intended use-cases/consumers have
either not expressed interest what so ever or directly expressed being
not interested.

Do we

Re: [openstack-dev] stable is hosed




On 8/10/2015 9:40 AM, Matt Riedemann wrote:



On 8/9/2015 7:16 PM, Matt Riedemann wrote:



On 8/9/2015 7:09 PM, Robert Collins wrote:

On 8 August 2015 at 08:52, Matt Riedemann mrie...@linux.vnet.ibm.com
wrote:

Well it's a Friday afternoon so you know what that means, emails
about the
stable branches being all busted to pieces in the gate.

Tracking in the usual place:

https://etherpad.openstack.org/p/stable-tracker

Since things are especially fun the last two days I figured it was
time for
a notification to the -dev list.

Both are basically Juno issues.

1. The large ops job is busted because of some uncapped dependencies in
python-openstackclient 1.0.1.

https://bugs.launchpad.net/openstack-gate/+bug/1482350

The fun thing here is g-r is capping osc=1.0.1 and there is already
a 1.0.2
version of osc, so we can't simply cap osc in a 1.0.2 and raise that
in g-r
for stable/juno (we didn't leave ourselves any room for bug fixes).

We talked about an osc 1.0.1.1 but pbr=0.11 won't allow that
because it
breaks semver.

The normal dsvm jobs are OK because they install cinder and cinder
installs
the dependencies that satisfy everything so we don't hit the osc
issue.  The
large ops job doesn't use cinder so it doesn't install it.

Options:

a) Somehow use a 1.0.1.post1 version for osc.  Would require input from
lifeless.


This is really tricky. postN versions are a) not meant to change
anything functional (see PEP-440) and b) are currently mapped to devN
by pbr for compatibility with pbr 0.10.x which had the unenviable task
of dealing with PEP-440 going live in pip.


b) Install cinder in the large ops job on stable/juno.


That would seem fine IMO.


c) Disable the large ops job for stable/juno.


I'd rather not do this.


2. grenade on kilo blows up because python-neutronclient 2.3.12 caps
oslo.serialization at =1.2.0, keystonemiddleware 1.5.2 is getting
pulled in
which pulls in oslo.serialization 1.4.0 and things fall apart.

https://bugs.launchpad.net/python-neutronclient/+bug/1482758

I'm having a hard time unwinding this one since it's a grenade job.
I know
the failures line up with the neutronclient 2.3.12 release which caps
requirements on stable/juno:

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

Need some help here.


I think it would be entirely appropriate to bump the lower bound of
neutronclient in kilo: running with the version with juno caps *isn't
supported* full stop, across the board. Its a bug that we have a bad
lower bound there.


On Friday, adam_g and I weren't sure what the policy was on overlapping
upper bounds for juno and lower bounds for kilo, but yeah, my first
reaction was that's bonkers and anything that's working that way today
is just working as a fluke and could wedge us the same way at any point.

The reason I'd prefer to not raise the minimum required version of a
library in stable g-r is simply for those packagers/distros that are
basically frozen on the versions of libraries they are providing for
kilo and I'd like to not make them arbitrarily move up just because of
our screw ups.

Apparently in our case (the product I work on), we already ship
neutronclient 2.4.0 in our kilo release so I guess it'd wouldn't be the
end of the world for us.



-Rob






We're going with raising the minimum required neutronclient for kilo to
2.4.0:

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



Cripes, that depends on this fix now:

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

--

Thanks,

Matt Riedemann


__
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] How should we expose host capabilities to the scheduler

2015-08-10 Thread Dugger, Donald D

In re: Different architectures.

I'm not saying we should create architecture specific definitions in our APIs.  
I like the idea of capabilities being exposed as arbitrary strings like AES 
or AltiVec.  An Intel user would be providing an IA architecture image and 
should know that it makes no sense to request AltiVec capabilities (and that 
request would correctly fail as either the image wouldn't run on the selected 
host or no host would be selected).

I'm looking for Nova to provide a common way of exposing and requesting host 
capabilities and you just use appropriate architecture specific strings when 
using these common interfaces.

--
Don Dugger
Censeo Toto nos in Kansa esse decisse. - D. Gale
Ph: 303/443-3786

-Original Message-
From: Tony Breeds [mailto:t...@bakeyournoodle.com] 
Sent: Sunday, August 9, 2015 8:19 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] How should we expose host capabilities to the 
scheduler

On Mon, Aug 03, 2015 at 04:49:59PM +0100, Alexis Lee wrote:
 Dugger, Donald D said on Mon, Aug 03, 2015 at 05:39:49AM +:
  Also note that, although many capabilities can be represented by 
  simple key/value pairs (e.g. the presence of a specific special
  instruction) that is not true for all capabilities (e.g. Numa 
  topology doesn't really fit into this model) and even the need to 
  specify ranges of values (more that x byes of RAM, less than y 
  bandwidth
  utilization) makes things more complex.
 
 I'm glad you brought up ranges. I don't want to get too exotic 
 prematurely but these certainly seem useful.
 
  Without going into the solution space the first thing we need to do 
  is make sure we know what the requirements are for exposing host 
  capabilities.  At a minimum we need to:
  
  1)  Enumerate the capabilities.  This will involve both
  quantitative values (amount of RAM, amount of disk, ...) and Boolean 
  (magic instructions present).  Also, there will be static 
  capabilities that are discovered at boot time and don't change 
  afterwards and dynamic capabilities that vary during node operation.
  
  2)  Expose the capabilities to both users and operators.
 
 As discussed at the midcycle, part of this is presenting a 
 somewhat-uniform API. I was fairly sleepy but I seem to recall PowerVM 
 does not publish an exhaustive list of its capabilities? Do we need a 
 facade which lists implicit capabilities for newer CPUs?
 
 We might also want to abstract over similar capabilities in Intel and 
 PowerVM?

So just for clarity POWER CPUs do expose this information but it isn't exposed 
via the CPU flags the way intel does.

A /proc/cpuinfo for a current POWER box looks like:
---
snip

processor   : 152
cpu : POWER8E (raw), altivec supported
clock   : 3690.00MHz
revision: 2.1 (pvr 004b 0201)

timebase: 51200
platform: PowerNV
model   : 8247-22L
machine : PowerNV 8247-22L
firmware: OPAL v3
---

Between the firmware version and the pvr value you can work out which feature 
the CPU supports.  Asking for SSE clearly only makes sense on intel and 
mapping that to anything on POWER would be strange at best.


IIRC a primary motivator for this is to say this os image has been built with 
SSE so only boot it on a compute host with that support.  As that's an image 
feature it dosn't make sense to run that on POWER
 
Yours Tony.
__
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] Barbican : Test cases failing for the current Barbican Kilo code

2015-08-10 Thread Asha Seshagiri

Thanks Juan :) for your response.

On Sun, Aug 9, 2015 at 12:32 PM, Juan Antonio Osorio jaosor...@gmail.com
wrote:

 It only runs the unit tests.

 BR
 On 9 Aug 2015 02:19, Asha Seshagiri asha.seshag...@gmail.com wrote:

 Thanks a lot Juan for your response:)
 One question I had was the barbican.sh script would run only the unit
 tests after the barbican installation right.
 The functional tests needs to be runned explicitly using tox utility.

 Thanks and Regards,
 Asha Seshagiri

 On Sat, Aug 8, 2015 at 3:45 AM, Juan Antonio Osorio jaosor...@gmail.com
 wrote:

 The stable/kilo is currently having issues with tests (both stable and
 functional) this CR https://review.openstack.org/#/c/205059/ is meant
 to fix that, and currently it does fix the unit and doc tests. But I
 haven't been able to fix the functional tests. I'm about to start
 travelling so I won't be able to fix it soon. But hopefully Doug (redrobot)
 and Ade will take it over.

 BR
 On 8 Aug 2015 01:42, Asha Seshagiri asha.seshag...@gmail.com wrote:

 Hi All ,

 Would like to know if the current kilo branch of Barbican is stable .
 Tried to install the current kilo version of Barbican code .
 Barbican installation is successful but test cases are failing.

 Please find the list of commands below :

 [root@client-barbican2 barbican]# git checkout -b kilo
 origin/stable/kilo
 Branch kilo set up to track remote branch stable/kilo from origin.
 Switched to a new branch 'kilo'
   [root@client-barbican2 barbican]# git branch
 * kilo
 master

 When I ran bin/barbican.sh , Barbican was successfully installed , but
 the test cases are failing

 Barbican is installed successfully but unit test seems to be failing
   Installing collected packages: barbican
 Running setup.py develop for barbican
 Successfully installed barbican
 running testr


 FAILED (id=0, failures=48, skips=6)
 error: testr failed (1)
 Starting barbican...

 PFA logs for which the test cases are failing.
 Any help would highly be appreciated.

 *Thanks and Regards,*
 *Asha Seshagiri*


 __
 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




 --
 *Thanks and Regards,*
 *Asha Seshagiri*

 __
 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




-- 
*Thanks and Regards,*
*Asha Seshagiri*
__
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][keystone] To always use or not use domain name?

2015-08-10 Thread Richard Raseley

On 08/07/2015 01:58 PM, Rich Megginson wrote:
 Would someone who actually has to deploy/maintain puppet manifests and
 supporting code chime in here?  How do you feel about having to ensure
 that every domain scoped Keystone resource name must end in
 ::domain?  At the very least, if not using domains, and not changing
 the default domain, you would have to ensure something::Default
 _everywhere_ - and I do mean everywhere - every user and tenant name
 use, including in keystone_user_role, and in other, higher level
 classes/defines that refer to keystone users and tenants.

 Anyone?

 I also wonder how the Ansible folks are handling this, as they move to
 support domains and other Keystone v3 features in openstack-ansible code? 
As an operator, I like the ::$domain notation. I think the benefits it
brings in terms of clarity outweigh any downsides.



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

[openstack-dev] [chef] Restart service when package changes but config doesn't

2015-08-10 Thread Ken Thomas

Hi all,
(I've been away for a couple of weeks and I tried to send this before I left. I 
didn't see it come through so my apologies if this is the second time you've 
seen this.)
I recall markvan mentioning a while ago that there was a need for services to 
restart when the underlying package changed but the config file didn't.  We've 
got something in place and working that does exactly that. I'd like to get 
y'all's opinion if it's an ugly kludge or something useful that we might want 
to refine and contribute back.
The basic approach is to look up a given package's version at recipe compile 
time, and then again at runtime.  If the two values are different, then we 
notify the service to stop. We rely on the main recipe to make sure that the 
service is started. This avoids multiple restarts if both the package and the 
config change.
For example, we have a library module that contains a routine that does the 
equivalent of 'rpm -q a name'.  If the package isn't installed yet, then the 
library routine will just return an empty string and that'll be different from 
the post install version.
In the recipe itself, we then have the following: (This is from our glance 
recipe.)
# Get access to the library routine that can look up package# versions. Note 
that we're including it twice. The first time is# so that we can get the 
preinstall version during the compile phase.# The second include is so that we 
can check the package version# during the run-time phase. Yes, we could have 
done the preinstall check# at run time and just had one include, but that 
rubyblock of code is# more complicated than doing the include.class 
::Chef::Recipe # rubocop:disable Documentation,ClassAndModuleChildren  include 
our special moduleend
class ::Chef # rubocop:disable ClassAndModuleChildren  class Resource    class 
RubyBlock # rubocop:disable Documentation      include our special module    
end  endend...package install commands...# trigger_pkg is the package that we 
want to check and was picked it up# from an attribute. We'll call our library 
routine (this is at compile# time) and stash the preinstall 
version.node.default['openstack']['image']['preinstall'] =  
pkg_version(trigger_pkg)
# Check the installed version at runtime, after the pkg commands# have actually 
run.  If there's a change in the version, then tell# glance to shutdown. It'll 
get restarted later on and pick up the# new binaries.ruby_block 'glance 
postinstall' do  block do    postinstall_version = pkg_version(trigger_pkg)    
preinstall_version = node['openstack']['image']['preinstall']    Chef::Log.info 
preinstall version: #{preinstall_version}    Chef::Log.info postinstall 
version:#{postinstall_version}    if preinstall_version != postinstall_version 
     Chef::Log.info 'Stopping glance services'      resources(service: 
'glance-api').run_action(:stop)      resources(service: 
'glance-registry').run_action(:stop)    else      Chef::Log.info 'No need to 
stop glance services'    end  endend

That's the basics. Is this worth pursuing? If it seems reasonable then I'll be 
happy to write up a spec, including any suggestions y'all may have. I.e. there 
may be some really braindead stuff in there just from my ignorance and flailing 
around just to make it work. I'm definitely open to suggestions.
Ken__
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 is hosed




On 8/9/2015 7:16 PM, Matt Riedemann wrote:



On 8/9/2015 7:09 PM, Robert Collins wrote:

On 8 August 2015 at 08:52, Matt Riedemann mrie...@linux.vnet.ibm.com
wrote:

Well it's a Friday afternoon so you know what that means, emails
about the
stable branches being all busted to pieces in the gate.

Tracking in the usual place:

https://etherpad.openstack.org/p/stable-tracker

Since things are especially fun the last two days I figured it was
time for
a notification to the -dev list.

Both are basically Juno issues.

1. The large ops job is busted because of some uncapped dependencies in
python-openstackclient 1.0.1.

https://bugs.launchpad.net/openstack-gate/+bug/1482350

The fun thing here is g-r is capping osc=1.0.1 and there is already
a 1.0.2
version of osc, so we can't simply cap osc in a 1.0.2 and raise that
in g-r
for stable/juno (we didn't leave ourselves any room for bug fixes).

We talked about an osc 1.0.1.1 but pbr=0.11 won't allow that because it
breaks semver.

The normal dsvm jobs are OK because they install cinder and cinder
installs
the dependencies that satisfy everything so we don't hit the osc
issue.  The
large ops job doesn't use cinder so it doesn't install it.

Options:

a) Somehow use a 1.0.1.post1 version for osc.  Would require input from
lifeless.


This is really tricky. postN versions are a) not meant to change
anything functional (see PEP-440) and b) are currently mapped to devN
by pbr for compatibility with pbr 0.10.x which had the unenviable task
of dealing with PEP-440 going live in pip.


b) Install cinder in the large ops job on stable/juno.


That would seem fine IMO.


c) Disable the large ops job for stable/juno.


I'd rather not do this.


2. grenade on kilo blows up because python-neutronclient 2.3.12 caps
oslo.serialization at =1.2.0, keystonemiddleware 1.5.2 is getting
pulled in
which pulls in oslo.serialization 1.4.0 and things fall apart.

https://bugs.launchpad.net/python-neutronclient/+bug/1482758

I'm having a hard time unwinding this one since it's a grenade job.
I know
the failures line up with the neutronclient 2.3.12 release which caps
requirements on stable/juno:

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

Need some help here.


I think it would be entirely appropriate to bump the lower bound of
neutronclient in kilo: running with the version with juno caps *isn't
supported* full stop, across the board. Its a bug that we have a bad
lower bound there.


On Friday, adam_g and I weren't sure what the policy was on overlapping
upper bounds for juno and lower bounds for kilo, but yeah, my first
reaction was that's bonkers and anything that's working that way today
is just working as a fluke and could wedge us the same way at any point.

The reason I'd prefer to not raise the minimum required version of a
library in stable g-r is simply for those packagers/distros that are
basically frozen on the versions of libraries they are providing for
kilo and I'd like to not make them arbitrarily move up just because of
our screw ups.

Apparently in our case (the product I work on), we already ship
neutronclient 2.4.0 in our kilo release so I guess it'd wouldn't be the
end of the world for us.



-Rob






We're going with raising the minimum required neutronclient for kilo to 
2.4.0:


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

--

Thanks,

Matt Riedemann


__
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] Brocade CI

2015-08-10 Thread Tim O'Konski

Mike:

We are looking into the CI issues now, thank you for bringing to our attention.

Tim

-Original Message-
From: Mike Perez [mailto:thin...@gmail.com] 
Sent: Sunday, August 09, 2015 5:35 PM
To: OpenStack Development Mailing List openstack-dev@lists.openstack.org
Cc: DL-GRP-ENG-Brocade-Openstack-CI brocade-openstack...@brocade.com
Subject: [cinder] Brocade CI

People have asked me at the Cinder midcycle sprint to look at the Brocade CI
to:

1) Keep the zone manager driver in Liberty.
2) Consider approving additional specs that we're submitted before the
   deadline.

Here are the current problems with the last 100 runs [1]:

1) Not posting success or failure.
2) Not posting a result link to view logs.
3) Not consistently doing runs. If you compare with other CI's there are plenty
   missing in a day.

This CI does not follow the guidelines [2]. Please get help [3].

[1] - http://paste.openstack.org/show/412316/
[2] - 
http://docs.openstack.org/infra/system-config/third_party.html#requirements
[3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Questions

-- 
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] How should we expose host capabilities to the scheduler

2015-08-10 Thread Chris Friesen




On 08/10/2015 09:55 AM, Dugger, Donald D wrote:

In re: user specifying requirements

Note that we have 2 different requirements here:

1) The cloud user needs to be able to specify I want to run this image on a machine 
that supports capability `foo'.
2) The cloud provider needs to be able to say If you want capability `foo' it'll 
cost you.  The cloud provider needs to be able to provide tiers of service with 
appropriate pricing models for those different tiers.

Note that the pricing tier issues means that we have to be careful about how 
the user asks for capabilities.  If we bury that into the image meta-data then 
the user could unexpectedly find himself implicitly asking for a pricier 
instance than expected.


That's why I suggested an error if the requirement on the image can't be met by 
the chosen flavor (which I assume is associated with a particular service level).


Presumably the provider is charging based on flavor, so we need some way to 
expose which flavors provide which CPU models/features.  In the case of AWS, 
they explicitly give Intel CPU model numbers for most of their instance types 
(see https://aws.amazon.com/ec2/instance-types/ for examples).  Because the 
OpenStack provider space is more diverse, we should have some way to 
programatically query the set of supported CPU models (and the features exposed 
for each model).


I was involved in a blueprint proposal for this general topic for Liberty, but 
it got bogged down in the details. 
(https://blueprints.launchpad.net/nova/+spec/cpu-model-per-flavor-or-image)


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] [TaskFlow] Cross-run persistence

2015-08-10 Thread Demian Brecht

Hi all,

As I understand it, the persistence and related backends are intended to store 
atom and flow state. This will only persist until the end of an entirely 
successful run (unless explicitly configured to not purge for auditing and 
other such reasons). My question is: Is there a way to configure storage to 
persist data across runs? My specific use case: I’ve defined an authentication 
task. The auth server allows for ticket-based auth, which means the user 
(optionally) wouldn’t have to log in on every run if storage could be 
configured to persist the given token across runs.

Did I miss something in the docs about this use case or should I be looking at 
something like oslo.cache to solve this problem?

Thanks,
Demian


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] [Ironic] Let's talk about API versions

2015-08-10 Thread Ruby Loo

On 4 August 2015 at 12:20, Jim Rollenhagen j...@jimrollenhagen.com wrote:

 On Mon, Jul 27, 2015 at 01:35:25PM -0700, Jim Rollenhagen wrote:
 
  Now we've landed a patch[0] with a new version (1.11) that is not
  backward compatible. It causes newly added Node objects to begin life in
  the ENROLL state, rather than AVAILABLE. This is a good thing, and
  people should want this! However, it is a breaking change. Automation
  that adds nodes to Ironic will need to do different things after the
  node-create call.
 
  Our API versioning scheme makes this opt-in (by specifying the API
  version). However, some folks have a problem with releasing this change
  as-is. The logic is that we might release a client that defaults to 1.11
  or higher, or the user may request 1.12 later to get a new feature, thus
  breaking their application that enrolls nodes.

 So after much deliberation, we took an informal vote in IRC this morning
 between 5 out of our 9 cores.

 The question was: should we do a 1.12 api version that allows the user
 to pick begining provision state in (AVAILABLE, ENROLL), defaulting to
 AVAILABLE?

 The results were 3 for no, 2 for yes. So that's the plan.

 Other Ironic cores (Haomeng, Yuriy, Ramesh, Ruby): please chime in if
 you have opinions on this. :)

 Otherwise we'll be getting to work on releasing a server as-is in the
 next few days.

 // jim


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! :)

--ruby
__
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] [oslo][keystone] oslo_config and wsgi middlewares

2015-08-10 Thread Michael Krotscheck

It appears that the patch related to this discussion were rushed through
rather quickly, and without appropriate updates to the documentation. The
documentation of the library no longer matches the actual functionality,
and will need to be updated before we can release a new version of
oslo_middleware.

Mehdi, if you would please update the documentation in oslo_middleware as
quickly as possible? Some of us have features that we're trying to land in
liberty, which we cannot do without a new release of this library.

To the rest of the Oslo team, I'd like to propose that if we do not have
appropriate updated documentation by the end of this week, we revert
Medhi's patches so that we can unblock the library.

In case you're curious, the related patch is here:
https://review.openstack.org/#/c/209817/3

Michael Krotscheck

On Sun, Aug 9, 2015 at 7:58 PM Jamie Lennox jamielen...@redhat.com wrote:



 - Original Message -
  From: Jamie Lennox jamielen...@redhat.com
  To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
  Sent: Monday, August 10, 2015 12:36:14 PM
  Subject: Re: [openstack-dev] [oslo][keystone] oslo_config and wsgi
 middlewares
 
 
 
  - Original Message -
   From: Mehdi Abaakouk sil...@sileht.net
   To: openstack-dev@lists.openstack.org
   Sent: Friday, August 7, 2015 1:57:54 AM
   Subject: [openstack-dev] [oslo][keystone] oslo_config and wsgi
 middlewares
  
   Hi,
  
   I want to share with you some problems I have recently encountered with
   openstack middlewares and oslo.config.
  
   The issues
   --
  
   In project Gnocchi, I would use oslo.middleware.cors, I have expected
 to
   just put the name of the middleware to the wsgi pipeline, but I can't.
   The middlewares only works if you pass the oslo_config.cfg.ConfigOpts()
   object or via 'paste-deploy'... Gnocchi doesn't use paste-deploy, so
   I have to modify the code to load it...
   (For the keystonemiddleware, Gnocchi already have a special
   handling/hack to load it [1] and [2]).
   I don't want to write the same hack for each openstack middlewares.
  
  
   In project Aodh (ceilometer-alarm), we recently got an issue with
   keystonemiddleware since we remove the usage of the global object
   oslo_config.cfg.CONF. The middleware doesn't load its options from the
   config file of aodh anymore. Our authentication is broken.
   We can still pass them through paste-deploy configuration but this
 looks
   a method of the past. I still don't want to write a hack for each
   openstack middlewares.
  
  
   Then I have digged into other middlewares and applications to see how
   they handle their conf.
  
   oslo_middlewarre.sizelimit and oslo_middlewarre.ssl take options only
   via the global oslo_config.cfg.CONF. So they are unusable for
 application
   that doesn't use this global object.
  
   oslo_middleware.healthcheck take options as dict like any other python
   middleware. This is suitable for 'paste-deploy'. But doesn't allow
   configuration via oslo.config, doesn't have a strong config options
   type checking and co.
  
   Zaqar seems got same kind of issue about keystonemiddleware, and just
   write a hack to workaround the issue (monkeypatch the cfg.CONF of
   keystonemiddleware with their local version of the object [3] and then
   transform the loaded options into a dict to pass them via the legacy
   middleware dict options [4]) .
  
   Most applications, just still use the global object for the
   configuration and don't, yet, see those issues.
  
  
   All of that is really not consistent.
  
   This is confusing for developer to have some middlewares that need
   pre-setup,
   enforce them to rely on global python object, and some others not.
   This is confusing for deployer their can't do the configuration of
   middlewares in the same way for each middlewares and each projects.
  
   But keystonemiddleware, oslo.middleware.cors,... are supposed to be
 wsgi
   middlewares, something that is independant of the app.
   And this is not really the case.
  
   From my point of view and what wsgi looks like generally in python, the
   middleware object should be just MyMiddleware(app, options_as_dict),
   if the middleware want to rely to another configuration system it
 should
   do the setup/initialisation itself.
  
  
  
   So, how to solve that ?
   
  
   Do you agree:
  
   * all openstack middlewares should load their options with oslo.config
 ?
 this permits type checking and all other features it provides, it's
 cool
 :)
 configuration in paste-deploy conf is thing of past
  
   * we must support local AND global oslo.config object ?
 This is an application choice not something enforced by middleware.
 The deployer experience should be the same in both case.
  
   * the middleware must be responsible of the section name in the
 oslo.config
   ?
 Gnocchi/Zaqar hack have to hardcode the

Re: [openstack-dev] [puppet][keystone] To always use or not use domain name?

2015-08-10 Thread Rich Megginson


On 08/10/2015 10:45 AM, Richard Raseley wrote:

On 08/07/2015 01:58 PM, Rich Megginson wrote:

Would someone who actually has to deploy/maintain puppet manifests and
supporting code chime in here?  How do you feel about having to ensure
that every domain scoped Keystone resource name must end in
::domain?  At the very least, if not using domains, and not changing
the default domain, you would have to ensure something::Default
_everywhere_ - and I do mean everywhere - every user and tenant name
use, including in keystone_user_role, and in other, higher level
classes/defines that refer to keystone users and tenants.

Anyone?

I also wonder how the Ansible folks are handling this, as they move to
support domains and other Keystone v3 features in openstack-ansible code?

As an operator, I like the ::$domain notation. I think the benefits it
brings in terms of clarity outweigh any downsides.


If you have to add ::$domain to all of your manifests and supporting 
code, what impact does that have?






__
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] [puppet][keystone] To always use or not use domain name?

2015-08-10 Thread Richard Raseley

On 08/10/2015 10:24 AM, Rich Megginson wrote:
 As an operator, I like the ::$domain notation. I think the benefits it
 brings in terms of clarity outweigh any downsides.

 If you have to add ::$domain to all of your manifests and supporting
 code, what impact does that have?

Practically speaking, as I know ahead of time where all the relevant
bits live, it just means I have to find all the instances of resources
which require the new notation, parse them and make the changes, and
then do some manual review. Save for the review, it could be easily
scripted.



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] Gaining access to consoles.

2015-08-10 Thread Andrew Laski


On 08/10/15 at 03:59pm, Tony Breeds wrote:

Hi All,
   Nova has bug: https://bugs.launchpad.net/nova/+bug/1447679 (service No-VNC
(port 6080) doesn't require authentication).

Which explains that if you know the 'token'[1] associated with an instances
console you can get access to said console without otherwise proving that you
should be allowed access to that instance[3].

Nothing limits the problem to VNC, so all console types are potentially 
affected.

There is a proposed solution (https://review.openstack.org/#/c/182129) which
adds a config option that means a token is only valid for a single usei[4].
The assertion is that bookmarking a URL to a console and then using it multiple
times is something that we want to still allow albeit discouraged.  When the
config value is introduced it will default to False (meaning that the
bookmarking scenario above will still work).  At some stage it'd be ideal to
invert this so that the option is True and operators can switch it if
appropriate.

I don't think that much of that in controversial, my question is what should
the schedule for switching this be?  Assuming we land a fix in Liberty[5], make
the change in Mitaka? Norbert?


I would treat this like a deprecation and follow the standard of one 
cycle of notice.  So if it lands in Liberty it could be switched in 
Mitaka.





Also is being able to bookmark/save the token a thing that users do?


I'm only one data point, but we have a short TTL on tokens so it is not 
something that our users could reasonably due.  And the Nova default TTL 
is 10 minutes, which is also out of bookmarking range IMO.




Yours Tony.

[1] How you get that token isn't really the issue, it could be a network or
   browser issue [2]
[2] I should look at the documentation of how we configure console access to
   ensure it's secure by default
[3] Even if the console isn't logged in this is a bad thing(tm)
[4] There is an outstanding issue with SPICE that is being looked into
[5] Which isn't a given.





__
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] [openstack-ansible] Release: Kilo 11.1.0

2015-08-10 Thread Jesse Pretorius

Hi everyone,

The openstack-ansible community is pleased to announce our release of the
Kilo 11.1.0 milestone.

This release fixes 57 bugs and implements 4 major blueprints, including:

* Keystone as a Federated Identity Provider
* Keystone as a Federated Service Provider
* Horizon Federation Single Sign-On
* Multi-Region Swift Clustering
* Ceilometer

For the full details please see launchpad [1].

For 11.2.0 [2] we'll be optionally incorporating Ceph as a back-end for
Glance, Cinder and Nova. Between now and then we expect to release at least
two hotfix releases in our usual cadence of once every two weeks.

If you're looking to kick the tyres to see how we do things or just want to
try OpenStack out and have a test system up and running within around 60
minutes, then try out our all-in-one deployment [3] which is used for
development/testing.

We welcome everyone to give it a try, participate in reviews [4] and get
involved! [5] If you have any questions, contact us in #openstack-ansible.

Best regards,

Jesse
IRC: odyssey4me

[1] https://launchpad.net/openstack-ansible/+milestone/11.1.0
[2] https://launchpad.net/openstack-ansible/+milestone/11.2.0
[3]
https://github.com/stackforge/os-ansible-deployment/blob/kilo/development-stack.rst
[4]
https://review.openstack.org/#/q/project:stackforge/os-ansible-deployment,n,z
[5]
https://github.com/stackforge/os-ansible-deployment/blob/master/CONTRIBUTING.rst
__
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]Do we have plan for restoring on-line volume?

2015-08-10 Thread John Griffith

On Mon, Aug 10, 2015 at 3:47 AM, hao wang sxmatch1...@gmail.com wrote:

 Sorry if I missed something, since now we have supported backup in-use
 volumes in L,  so I wonder is there some plan or design to support
 restoring on-line volumes.

 Thanks.

 --

 Best Wishes For You!


 __
 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

 No, a restore operation is going to require that the volume be taken
offline for a number of reasons.  Even with multi-attach if/when it ever
becomes a reality you can't write to the volume while it's in use by
another Instance (corruption, file system updates etc etc) unless you're
using a shared FS or clustered File System.

That's a use case that I don't think has a ton of value and it's not
compelling enough to introduce all of the issues that come along with it
IMO.

Thanks,
John
__
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] [Keystone] [Horizon] Federated Login

2015-08-10 Thread David Chadwick



On 10/08/2015 01:53, Jamie Lennox wrote:
 
 
 - Original Message -
 From: David Chadwick d.w.chadw...@kent.ac.uk To:
 openstack-dev@lists.openstack.org Sent: Sunday, August 9, 2015
 12:29:49 AM Subject: Re: [openstack-dev] [Keystone] [Horizon]
 Federated Login
 
 Hi Jamie
 
 nice presentation, thanks for sharing it. I have forwarded it to
 my students working on federation aspects of Horizon.
 
 About public federated cloud access, the way you envisage it, i.e.
 that every user will have his own tailored (subdomain) URL to the
 SP is not how it works in the real world today. SPs typically
 provide one URL, which everyone from every IdP uses, so that no
 matter which browser you are using, from wherever you are in the
 world, you can access the SP (via your IdP). The only thing the
 user needs to know, is the name of his IdP, in order to correctly
 choose it.
 
 So discovery of all available IdPs is needed. You are correct in
 saying that Shib supports a separate discovery service (WAYF), but
 Horizon can also play this role, by listing the IdPs for the user.
 This is the mod that my student is making to Horizon, by adding
 type ahead searching.
 
 So my point at the moment is that unless there's something i'm
 missing in the way shib/mellon discovery works is that horizon can't.
 Because we forward to a common websso entry point there is no way (i
 know) for the users selection in horizon to be forwarded to keystone.
 You would still need a custom select your idp discovery page in
 front of keystone. I'm not sure if this addition is part of your
 students work, it just hasn't been mentioned yet.
 
 About your proposed discovery mod, surely this seems to be going in
 the wrong direction. A common entry point to Keystone for all IdPs,
 as we have now with WebSSO, seems to be preferable to separate
 entry points per IdP. Which high street shop has separate doors for
 each user? Or have I misunderstood the purpose of your mod?
 
 The purpose of the mod is purely to bypass the need to have a
 shib/mellon discovery page on /v3/OS-FEDERATION/websso/saml2. This
 page is currently required to allow a user to select their idp
 (presumably from the ones supported by keystone) and redirect to that
 IDPs specific login page.

There are two functionalities that are required:
a) Horizon finding the redirection login URL of the IdP chosen by the user
b) Keystone finding which IdP was used for login.

The second is already done by Apache telling Keystone in the header field.

The first is part of the metadata of the IdP, and Keystone should make
this available to Horizon via an API call. Ideally when Horizon calls
Keystone for the list of trusted IdPs, then the user friendly name of
the IdP (to be displayed to the user) and the login page URL should be
returned. Then Horizon can present the user friendly list to the user,
get the login URL that matches this, then redirect the user to the IdP
telling the IdP the common callback URL of Keystone.

 When the response comes back from that
 login it returns to that websso page and we look at remote_ids to
 determine which keystone idp is handling the response from that
 site.

This seems the more secure way of determining the IdP to me, since
Apache determines the IdP then tells Keystone via the header field. If
you rely on the IdP to contact the right endpoint, then doesn't this
allow the IdP to return to a different URL and thereby trick Keystone
into thinking it was a different IdP?

regards

David

 
 If we were to move that to
 /v3/OS-FEDERATION/identity_providers/{idp_id}/protocols/saml2/websso
 then we can more easily support selection from horizon, or otherwise
 do discovery without relying on shib/mellons discovery mechanism. A
 selection from horizon would forward us to the idp specific websso on
 keystone, which would forward to the idp's login page (without
 needing discovery because we already know the idp) and the response
 from login would go to the idp specific page negating the need for
 dealing with remote_ids.
 
 So i'm not looking for a seperate door so much as a way to indicate
 that the user picked an IDP in horizon and i don't want to do
 discovery again.
 
 regards
 
 David
 
 On 07/08/2015 01:29, Jamie Lennox wrote:
 
 
 


 
*From: *Dolph Mathews dolph.math...@gmail.com
 *To: *OpenStack Development Mailing List (not for usage
 questions) openstack-dev@lists.openstack.org *Sent: *Friday,
 August 7, 2015 9:09:25 AM *Subject: *Re: [openstack-dev]
 [Keystone] [Horizon] Federated Login
 
 
 On Thu, Aug 6, 2015 at 11:25 AM, Lance Bragstad
 lbrags...@gmail.com mailto:lbrags...@gmail.com wrote:
 
 
 
 On Thu, Aug 6, 2015 at 10:47 AM, Dolph Mathews 
 dolph.math...@gmail.com mailto:dolph.math...@gmail.com
 wrote:
 
 
 On Wed, Aug 5, 2015 at 6:54 PM, Jamie Lennox 
 jamielen...@redhat.com mailto:jamielen...@redhat.com wrote:
 
 
 
 - Original Message -
 From: David Lyle

Re: [openstack-dev] [Stable][Nova] VMware NSXv Support



On 8/10/15, 6:05 PM, Gary Kotton gkot...@vmware.com wrote:



On 8/10/15, 6:03 PM, Gary Kotton gkot...@vmware.com wrote:



On 8/10/15, 5:46 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote:



On 8/10/2015 9:17 AM, Gary Kotton wrote:
 Hi,
 I am not really sure what to say here. The code was in review for over
8
 months. On a side note but related - we have a patch for a plugin
 developed in Liberty - https://review.openstack.org/#/c/165750/. This
has
 been in review since March. I really hope that that lands in Liberty.
If
 not we will go through the same thing again.
 Working in Nova on code that is self contained within a driver is
 difficult - terribly difficult. Not only is this demotivating, it also
 effectively does not help any of the drivers actually add any
features.
 A sad day for OpenStack.
 Thanks
 Gary

 On 8/5/15, 4:01 PM, Ihar Hrachyshka ihrac...@redhat.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Hi,

 I think Erno made a valid point here. If that would touch only vmware
 code, that could be an option to consider. But it looks like both
 patches are very invasive, and they are not just enabling features
 that are already in the tree, but introduce new stuff that is not
even
 tested for long in master.

 I guess we'll need to wait for those till Liberty. Unless
 nova-core-maint has a different opinion and good arguments to
approach
 the merge.

 Ihar

 On 08/05/2015 12:37 PM, Kuvaja, Erno wrote:
 Hi Gary,



 While I do understand the interest to get this functionality
 included, I really fail to see how it would comply with the Stable
 Branch Policy:
 https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy

 Obviously the last say is on stable-maint-core, but normally new
 features are really no-no to stable branches.



 My concerns are more on the metadata side of your changes.

 Even the refactoring is fairly clean it is major part of the
 metadata handler.

 It also changes the API (In the case of X-Metadata-Provider being
 present) which tends to be sacred on stable branches.



 The changes here does not actually fix any bug but just implements
 new functionality that missed kilo not even slightly but by months.
 Thus my -1 for merging these.



 -  Erno



 *From:*Gary Kotton [mailto:gkot...@vmware.com] *Sent:* Wednesday,
 August 05, 2015 8:03 AM *To:* OpenStack List *Subject:*
 [openstack-dev] [Stable][Nova] VMware NSXv Support



 Hi,

 In the Kilo cycle a Neutron driver was added for supporting the
 Vmware NSXv plugin. This required patches in Nova to enable the
 plugin to work with Nova. These patches finally landed yesterday. I
 have back ported them to stable/kilo as the Neutron driver is
 unable to work without these in stable/kilo. The patches can be
 found at:

 1. VNIC support - https://review.openstack.org/209372 2. Metadata
 support - https://review.openstack.org/209374

 I hope that the stable team can take this into consideration.



 Thanks in advance

 Gary



 
_
_
 


 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

 iQEcBAEBCAAGBQJVwgkjAAoJEC5aWaUY1u57NacIALsJ8oo6eJKqJIidBSFzwxvg
 zqJXHE56Lpg62/afRF94B2edfhm791Mz42LTFn0BHHRjV51TQX4k/Jf3Wr22CEvm
 zFZkU5eVMVOSL3GGnOZqSv/T06gBWmlMVodmSKQjGxrIL1s8G1m4aTwe6Pqs+lie
 N+cT0pZbcjL/P1wYTac6XMpF226gO1owUjhE4oj9VZzx7kEqNsv22SIzVN2fQcco
 YLs/LEcabMhuuV4Amde3RqUr0BkB+mlIX1TUv5/FTXT/F4ZwzYS/DBH9MaBJ5t8n
 hgCTJzCeg598+irgOt3VJ3Jn3Unljz6LNzKIM8RnBG0o51fp8vfE/mODQQaUKOg=
 =ZYP8
 -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


https://review.openstack.org/#/c/165750/ is a feature add but it's not
targeted against a blueprint, so it's just running as a random thing
outside any tracking mechanism for features (launchpad).

Salvatore made some comments back in March but otherwise no one from the
VMware development team has even commented on this.  As I've said in
some other VMware patches in Nova lately, I expect the VMware sub-team
to be doing a better job of reviewing each other's code first since they
are supposed to be the subject matter experts here.

I know Gary reviews pretty much all of the changes that go into the
VMware driver in Nova but I don't see the same

Re: [openstack-dev] [TaskFlow] Cross-run persistence

2015-08-10 Thread Joshua Harlow


Hmmm,

I'm pretty sure what u want exists,

For example:

https://github.com/openstack/taskflow/blob/master/taskflow/examples/persistence_example.py

That uses sqlite (or a file) to store information,

U just have to decide what backend is best for u,

Is that what u are looking for? (or possibly something else?),

-Josh

Demian Brecht wrote:

Hi all,

As I understand it, the persistence and related backends are intended to store 
atom and flow state. This will only persist until the end of an entirely 
successful run (unless explicitly configured to not purge for auditing and 
other such reasons). My question is: Is there a way to configure storage to 
persist data across runs? My specific use case: I’ve defined an authentication 
task. The auth server allows for ticket-based auth, which means the user 
(optionally) wouldn’t have to log in on every run if storage could be 
configured to persist the given token across runs.

Did I miss something in the docs about this use case or should I be looking at 
something like oslo.cache to solve this problem?

Thanks,
Demian

__
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] [oslo] Question on oslo_i18n._message

2015-08-10 Thread Okuma, Wayne

Hello All,

I have a question on the usage of oslo_i18n._message and hope to get an answer.

Some background first:
I'm working on a portion of Glance - the Glance Metadata Definitions (i.e., 
metadefs) section.
We have about ~20 .JSON files which hold data. The .JSON files get loaded into 
the Glance.metadef_xxx related tables which in turn gets displayed in Horizon 
via the glance REST API code.
There are some fields in the .JSON files which need to be internationalized.
I have a program which produces glance-json.pot files for the JSON files.

In Horizon, when they are viewing the data, the end-user may change the 
language they wish to see by going into the profile section (upper right hand 
corner of Horizon) and selecting the language. So,  I need a more dynamic 
version of i18n than just the version of i18n that gets started up when the 
Glance service is started (i.e., based on GLANCE_LOCALEDIR and LANGUAGE, LANG, 
etc., settings).

This seems to work:

import oslo_i18n

# Assumes GLANCE_JSON_LOCALEDIR has been set appropriately.
def translate(message, locale=None):
obj = oslo_i18n._message.Message(message, domain='glance-json')
return oslo_i18n.translate(obj, locale)
...
# then in code...
def _format_namespace_from_db(self, namespace_obj, locale=None):
...
display_name=translate(namespace_obj['display_name'], locale),

The returned display_name will have the correct version based on the locale 
passed in.

But, is this correct usage of oslo_i18n._message()?
Or is it to remain hidden since it is not part of oslo_i18n.__init__py?
If it is to remain hidden, then, what would be the better way of getting a 
dynamic translation based on some arbitrary locale that is passed in.

If you don't know the answer, but, know someone that might - please pass on 
their name(s) and I can try to contact them directly.

Thanks and Regards,
Wayne Okuma

__
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] [searchlight] Liberty release planning video conference

2015-08-10 Thread Tripp, Travis S

At our last weekly IRC meeting we decided that we should have a short video 
conference meetup to talk about the Liberty 3 release. The purpose will be to 
walk through the Liberty Blueprints / Bugs and finalize the list for Liberty 3. 
I promised to create a doodle poll for choosing the time, so here it is:

http://doodle.com/99kzigdbmed57g7s

Please note, one time I set is the same time as the normal IRC meeting.  If 
that is what works best for everybody, we’ll start the IRC meeting normally, 
but share a video link in the meeting room for people to join.
__
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] [api] [all] To changes-since or not to changes-since

2015-08-10 Thread Everett Toews

On Aug 9, 2015, at 11:03 PM, hao wang 
sxmatch1...@gmail.commailto:sxmatch1...@gmail.com wrote:

Hi, stackers

Since now we have merged filtering guideline[1], is that said we should 
implement this feature according this guideline?  like this:

GET /app/items?f_updated_at=gte:some_timestamp

Do we have reached a consensus about this?

You’ll definitely want to drop the “f_” prefix from your filter name, see the 
about-to-be-merged guideline No project uses f_ prefix in filter params [1].

Everett

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

__
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] [oslo] Question on oslo_i18n._message

2015-08-10 Thread Doug Hellmann

Excerpts from Okuma, Wayne's message of 2015-08-10 21:22:09 +:
 Hello All,
 
 I have a question on the usage of oslo_i18n._message and hope to get an 
 answer.
 
 Some background first:
 I'm working on a portion of Glance - the Glance Metadata Definitions (i.e., 
 metadefs) section.
 We have about ~20 .JSON files which hold data. The .JSON files get loaded 
 into the Glance.metadef_xxx related tables which in turn gets displayed in 
 Horizon via the glance REST API code.
 There are some fields in the .JSON files which need to be internationalized.
 I have a program which produces glance-json.pot files for the JSON files.
 
 In Horizon, when they are viewing the data, the end-user may change the 
 language they wish to see by going into the profile section (upper right hand 
 corner of Horizon) and selecting the language. So,  I need a more dynamic 
 version of i18n than just the version of i18n that gets started up when the 
 Glance service is started (i.e., based on GLANCE_LOCALEDIR and LANGUAGE, 
 LANG, etc., settings).

The API layer can also set a language based on the browser settings. Are
the JSON files being served by the glance API? Or are they in some other
way coming through from glance?

 
 This seems to work:
 
 import oslo_i18n
 
 # Assumes GLANCE_JSON_LOCALEDIR has been set appropriately.
 def translate(message, locale=None):
 obj = oslo_i18n._message.Message(message, domain='glance-json')
 return oslo_i18n.translate(obj, locale)
 ...
 # then in code...
 def _format_namespace_from_db(self, namespace_obj, locale=None):
 ...
 display_name=translate(namespace_obj['display_name'], locale),
 
 The returned display_name will have the correct version based on the locale 
 passed in.
 
 But, is this correct usage of oslo_i18n._message()?
 Or is it to remain hidden since it is not part of oslo_i18n.__init__py?
 If it is to remain hidden, then, what would be the better way of getting a 
 dynamic translation based on some arbitrary locale that is passed in.
 
 If you don't know the answer, but, know someone that might - please pass on 
 their name(s) and I can try to contact them directly.
 
 Thanks and Regards,
 Wayne Okuma

As you surmise, the _message module is marked private (note the
_ prefix on the name), so you shouldn't use it directly. The fact that
Message objects exists is an implementation detail of the lazy
translation machinery, and isn't meant to be something that applications
rely on.

You could use oslo_i18n.TranslatorFactory to get a function to wrap
your strings instead [1].  The primary attribute should be what
you want. Passing the return value to translate() would then give
you the translated value.

Something like:

  factory = oslo_i18n.TranslatorFactory('glance-json')
  trans = factory.primary

  def translate(message, locale=None):
  return oslo_i18n.translate(trans(message), locale)

This ought to work whether lazy translation is enabled or not, as long
as the catalog files are installed properly.

Doug

[1] 
http://docs.openstack.org/developer/oslo.i18n/api.html#oslo_i18n.TranslatorFactory

__
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] [Keystone] [Horizon] Federated Login

2015-08-10 Thread Jamie Lennox

- Original Message -
 From: David Chadwick d.w.chadw...@kent.ac.uk
 To: openstack-dev@lists.openstack.org
 Sent: Tuesday, 11 August, 2015 12:50:21 AM
 Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login

 On 10/08/2015 01:53, Jamie Lennox wrote:

  - Original Message -
  From: David Chadwick d.w.chadw...@kent.ac.uk To:
  openstack-dev@lists.openstack.org Sent: Sunday, August 9, 2015
  12:29:49 AM Subject: Re: [openstack-dev] [Keystone] [Horizon]
  Federated Login

  Hi Jamie

  nice presentation, thanks for sharing it. I have forwarded it to
  my students working on federation aspects of Horizon.

  About public federated cloud access, the way you envisage it, i.e.
  that every user will have his own tailored (subdomain) URL to the
  SP is not how it works in the real world today. SPs typically
  provide one URL, which everyone from every IdP uses, so that no
  matter which browser you are using, from wherever you are in the
  world, you can access the SP (via your IdP). The only thing the
  user needs to know, is the name of his IdP, in order to correctly
  choose it.

  So discovery of all available IdPs is needed. You are correct in
  saying that Shib supports a separate discovery service (WAYF), but
  Horizon can also play this role, by listing the IdPs for the user.
  This is the mod that my student is making to Horizon, by adding
  type ahead searching.

  So my point at the moment is that unless there's something i'm
  missing in the way shib/mellon discovery works is that horizon can't.
  Because we forward to a common websso entry point there is no way (i
  know) for the users selection in horizon to be forwarded to keystone.
  You would still need a custom select your idp discovery page in
  front of keystone. I'm not sure if this addition is part of your
  students work, it just hasn't been mentioned yet.

  About your proposed discovery mod, surely this seems to be going in
  the wrong direction. A common entry point to Keystone for all IdPs,
  as we have now with WebSSO, seems to be preferable to separate
  entry points per IdP. Which high street shop has separate doors for
  each user? Or have I misunderstood the purpose of your mod?

  The purpose of the mod is purely to bypass the need to have a
  shib/mellon discovery page on /v3/OS-FEDERATION/websso/saml2. This
  page is currently required to allow a user to select their idp
  (presumably from the ones supported by keystone) and redirect to that
  IDPs specific login page.

 There are two functionalities that are required:
 a) Horizon finding the redirection login URL of the IdP chosen by the user
 b) Keystone finding which IdP was used for login.

 The second is already done by Apache telling Keystone in the header field.

 The first is part of the metadata of the IdP, and Keystone should make
 this available to Horizon via an API call. Ideally when Horizon calls
 Keystone for the list of trusted IdPs, then the user friendly name of
 the IdP (to be displayed to the user) and the login page URL should be
 returned. Then Horizon can present the user friendly list to the user,
 get the login URL that matches this, then redirect the user to the IdP
 telling the IdP the common callback URL of Keystone.

So my understanding was that this wasn't possible. Because we want to have 
keystone be the registered service provider and receive the returned SAML 
assertions the login redirect must be issued from keystone and not horizon. Is 
it possible to issue a login request from horizon that returns the response to 
keystone? This seems dodgy to me but may be possible if all the trust 
relationships are set up.

In a way this is exactly what my proposal was. A way for horizon to determine a 
unique websso login page for each idp, just my understanding is that this 
request must be bounced through keystone.

  When the response comes back from that
  login it returns to that websso page and we look at remote_ids to
  determine which keystone idp is handling the response from that
  site.

 This seems the more secure way of determining the IdP to me, since
 Apache determines the IdP then tells Keystone via the header field. If
 you rely on the IdP to contact the right endpoint, then doesn't this
 allow the IdP to return to a different URL and thereby trick Keystone
 into thinking it was a different IdP?

To me the difference is that if we all return to a common 
/OS-FEDERATION/websso/saml2 endpoint then apache has to let all SAML responses 
through for all registered idps and then keystone must determine which is the 
real idp. By returning to an IDP specific websso route apache can assert that 
this response may only have come from the provider configured for that idp. 
This is really a secondary concern. I don't see there being much security 
difference, just that in this way you offload some additional responsibility 
for validating a SAML assertion to apache and we remove some (not all)

Re: [openstack-dev] [searchlight] Liberty release planning video conference

2015-08-10 Thread Anita Kuno

On 08/10/2015 06:28 PM, Tripp, Travis S wrote:
At our last weekly IRC meeting we decided that we should have a short video
conference meetup to talk about the Liberty 3 release. The purpose will be to
walk through the Liberty Blueprints / Bugs and finalize the list for Liberty
3. I promised to create a doodle poll for choosing the time, so here it is:

http://doodle.com/99kzigdbmed57g7s

Please note, one time I set is the same time as the normal IRC meeting. If
that is what works best for everybody, we’ll start the IRC meeting normally,
but share a video link in the meeting room for people to join.
__
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

Hello:

Part of being an OpenStack project listed in the governance repo, as you
are [0], is agreeing to conduct your business in an open manner. Had you
not done so prior to now I would not have known that you are using
Postman for testing [1], as you linked in your meeting log [2]. If
Postman is open source licensed I couldn't find it in their
documentation [3].

Now I'm certainly not going to waste my time telling you how you should
operate your project. I am simply going to take the time to tell you
that currently your tool choices aren't in keeping with the 4 opens [4].
If this is by design, power to you, and please don't let me hold you back.

If this is by accident and you really do want to ensure you stay an
OpenStack project, do reach out to a member of the technical committee
as I feel you could benefit from some tool choice and workflow guidance.

Thank you,
Anita.

[0]
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml#n2011
[1] https://www.getpostman.com/collections/8c0b1e05875c7c58e967
[2]
http://eavesdrop.openstack.org/meetings/openstack_search/2015/openstack_search.2015-08-06-15.01.log.html
[3] https://www.getpostman.com/docs
[4]
http://git.openstack.org/cgit/openstack/governance/tree/reference/new-projects-requirements.rst#n17

Re: [openstack-dev] [Bug 1482444] Abnormal changes of quota usage after instance restored by admin

2015-08-10 Thread Zhenyu Zheng

Hi, I didn't reproduce this bug, maybe you can explain more details.

On Tue, Aug 11, 2015 at 8:37 AM, 郑岳 zheng...@hihuron.com wrote:

 Hello everyone:
 I found a bug in openstack about project's quota usage in newest version.

 The link of bug description: https://bugs.launchpad.net/nova/+bug/1482444

 Reproduce steps:
 1. Enable soft delete via set reclaim_instance_interval in nova.conf.

 2. A normal project: ProjectA create a new instance and then delete it,
 then it's status change to SOFT_DELETED.

 3. Now restore the instance by admin user in project: admin, the instance
 back to ACTIVE, but the quota usage of project: admin has changed, the
 flavor of that instance has added on admin project quota usage.
 Please help me to confirm the problem is real.
 Thanks!

 __
 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] [cinder]Do we have plan for restoring on-line volume?

@Duncan and John, thank you both and I have understood this.  The reason I
ask this question is we can't restore the boot volume of instance which is
boot-from-volume, since Nova can't detach the boot disk now. So we need to
figure out a way to solve this issue.

Maybe we should let nova can detach the boot disk, but there are also some
problems, like what state should be set after detach the boot disk? Can
user reboot/stop/migrate the instance after detach the boot disk? etc.

Anyway, I feel it may be a long way to solve this issue properly.

2015-08-11 0:13 GMT+08:00 John Griffith john.griffi...@gmail.com:



 On Mon, Aug 10, 2015 at 3:47 AM, hao wang sxmatch1...@gmail.com wrote:

 Sorry if I missed something, since now we have supported backup in-use
 volumes in L,  so I wonder is there some plan or design to support
 restoring on-line volumes.

 Thanks.

 --

 Best Wishes For You!


 __
 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

 No, a restore operation is going to require that the volume be taken
 offline for a number of reasons.  Even with multi-attach if/when it ever
 becomes a reality you can't write to the volume while it's in use by
 another Instance (corruption, file system updates etc etc) unless you're
 using a shared FS or clustered File System.

 That's a use case that I don't think has a ton of value and it's not
 compelling enough to introduce all of the issues that come along with it
 IMO.

 Thanks,
 John


 __
 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 Wishes For You!
__
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]Do we have plan for restoring on-line volume?

@Duncan and John, I have a idea about this issue,  if volume is in-use but
the instance which it's attached to is power-off, so can we avoid data
corruption? If it's true, cinder could free the available restriction,
let user decide if they want to restore the boot disk, and they should shut
down the instance first and then restore volume.

2015-08-11 11:30 GMT+08:00 hao wang sxmatch1...@gmail.com:

 @Duncan and John, thank you both and I have understood this.  The reason I
 ask this question is we can't restore the boot volume of instance which is
 boot-from-volume, since Nova can't detach the boot disk now. So we need to
 figure out a way to solve this issue.

 Maybe we should let nova can detach the boot disk, but there are also some
 problems, like what state should be set after detach the boot disk? Can
 user reboot/stop/migrate the instance after detach the boot disk? etc.

 Anyway, I feel it may be a long way to solve this issue properly.

 2015-08-11 0:13 GMT+08:00 John Griffith john.griffi...@gmail.com:



 On Mon, Aug 10, 2015 at 3:47 AM, hao wang sxmatch1...@gmail.com wrote:

 Sorry if I missed something, since now we have supported backup in-use
 volumes in L,  so I wonder is there some plan or design to support
 restoring on-line volumes.

 Thanks.

 --

 Best Wishes For You!



 __
 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

 No, a restore operation is going to require that the volume be taken
 offline for a number of reasons.  Even with multi-attach if/when it ever
 becomes a reality you can't write to the volume while it's in use by
 another Instance (corruption, file system updates etc etc) unless you're
 using a shared FS or clustered File System.

 That's a use case that I don't think has a ton of value and it's not
 compelling enough to introduce all of the issues that come along with it
 IMO.

 Thanks,
 John


 __
 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 Wishes For You!




-- 

Best Wishes For You!
__
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] [kolla] Reprioritization of blueprints for Liberty-3 for Kolla

2015-08-10 Thread Steven Dake (stdake)

Hi folks,

We had about 40 blueprints for Kolla marked for L3.  Our community can 
typically process about 20-25 blueprints in a 1 month period.  As a result, I 
pushed a bunch of blueprints to Mitaka, and got our blueprint count down to 
about 24 blueprints.  The Essential/High blueprints are what I think are 
necessary to make a version of Kolla that is shippable and ready for evaluation 
by Operators.

The full list is here:
https://launchpad.net/kolla/+milestone/liberty-3

The list of stuff bounced to mitaka:
https://blueprints.launchpad.net/kolla/mitaka

As our PTL I will not refuse work that was pushed to Mitaka into Liberty.  If 
your blueprint was pushed and you still want to continue working on it, please 
feel free to do so, and when its ready to merge, I will pull it in to the 
Liberty tracker.

I only spent about 3 hours doing this process and reprioritizing blueprints, so 
it is likely I made some errors.  We will have a timeboxed 30 minute blueprint 
review at our Wednesday meeting.  The first priority of this session will be 
puling blueprints from Mitaka into Liberty that people feel strongly about.  
The end goal of this session is to make sure that essential/high blueprints are 
all that are necessary for an Operator to evaluate Kolla and see if it fits 
their needs, even if it leaves them with some functional gaps (especially 
around supplemental projects as defined here[1]).

Regards,
-steve

[1] https://blueprints.launchpad.net/kolla/+spec/restructure-template
__
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] [chef] Restart service when package changes but config doesn't

2015-08-10 Thread Ken Thomas

Hi all,

(I've been away for a couple of weeks and I tried to send this before I
left. I didn't see it come through so my apologies if this is the second
time you've seen this.)

I recall markvan mentioning a while ago that there was a need for services
to restart when the underlying package changed but the config file didn't.
We've got something in place and working that does exactly that. I'd like
to get y'all's opinion if it's an ugly kludge or something useful that we
might want to refine and contribute back.

The basic approach is to look up a given package's version at recipe compile
time, and then again at runtime.  If the two values are different, then we
notify the service to stop. We rely on the main recipe to make sure that
the service is started. This avoids multiple restarts if both the package
and the config change.

For example, we have a library module that contains a routine that does the
equivalent of 'rpm -q a name'.  If the package isn't installed yet, then
the library routine will just return an empty string and that'll be
different from the post install version.

In the recipe itself, we then have the following: (This is from our glance
recipe.)

# Get access to the library routine that can look up package
# versions. Note that we're including it twice. The first time is
# so that we can get the preinstall version during the compile phase.
# The second include is so that we can check the package version
# during the run-time phase. Yes, we could have done the preinstall check
# at run time and just had one include, but that rubyblock of code is
# more complicated than doing the include.
class ::Chef::Recipe # rubocop:disable Documentation,ClassAndModuleChildren
  include our special module
end

class ::Chef # rubocop:disable ClassAndModuleChildren
  class Resource
class RubyBlock # rubocop:disable Documentation
  include our special module
end
  end
end
...
package install commands
...
# trigger_pkg is the package that we want to check and was picked it up
# from an attribute. We'll call our library routine (this is at compile
# time) and stash the preinstall version.
node.default['openstack']['image']['preinstall'] =
  pkg_version(trigger_pkg)

# Check the installed version at runtime, after the pkg commands
# have actually run.  If there's a change in the version, then tell
# glance to shutdown. It'll get restarted later on and pick up the
# new binaries.
ruby_block 'glance postinstall' do
  block do
postinstall_version = pkg_version(trigger_pkg)
preinstall_version = node['openstack']['image']['preinstall']
Chef::Log.info preinstall version: #{preinstall_version}
Chef::Log.info postinstall version:#{postinstall_version}
if preinstall_version != postinstall_version
  Chef::Log.info 'Stopping glance services'
  resources(service: 'glance-api').run_action(:stop)
  resources(service: 'glance-registry').run_action(:stop)
else
  Chef::Log.info 'No need to stop glance services'
end
  end
end


That's the basics. Is this worth pursuing? If it seems reasonable then I'll
be happy to write up a spec, including any suggestions y'all may have. I.e.
there may be some really braindead stuff in there just from my ignorance
and flailing around just to make it work. I'm definitely open to
suggestions.

Ken
__
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] [api] [all] To changes-since or not to changes-since

Haha, thanks Everett, you're totally right.

Anyway, with or without f_, I want to ensure we will use updated_at
=gte:some_timestamp like guideline said, or use changes-since=
some_timestamp. Since I think this function it's useful to query resources
and we should introduce it into projects(some projects already have it.).

2015-08-11 6:34 GMT+08:00 Everett Toews everett.to...@rackspace.com:

 On Aug 9, 2015, at 11:03 PM, hao wang sxmatch1...@gmail.com wrote:

 Hi, stackers

 Since now we have merged filtering guideline[1], is that said we should
 implement this feature according this guideline?  like this:

 *GET /app/items?f_updated_at=gte:some_timestamp*

 Do we have reached a consensus about this?


 You’ll definitely want to drop the “f_” prefix from your filter name, see
 the about-to-be-merged guideline No project uses f_ prefix in filter params
 [1].

 Everett

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


 __
 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 Wishes For You!
__
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] [oslo] Question on oslo_i18n._message

2015-08-10 Thread Okuma, Wayne

-Original Message-
From: Doug Hellmann [mailto:d...@doughellmann.com] 
Sent: Monday, August 10, 2015 4:00 PM
To: openstack-dev
Subject: Re: [openstack-dev] [oslo] Question on oslo_i18n._message

Excerpts from Okuma, Wayne's message of 2015-08-10 21:22:09 +:
 Hello All,

 I have a question on the usage of oslo_i18n._message and hope to get an 
 answer.

 Some background first:
 I'm working on a portion of Glance - the Glance Metadata Definitions (i.e., 
 metadefs) section.
 We have about ~20 .JSON files which hold data. The .JSON files get loaded 
 into the Glance.metadef_xxx related tables which in turn gets displayed in 
 Horizon via the glance REST API code.
 There are some fields in the .JSON files which need to be internationalized.
 I have a program which produces glance-json.pot files for the JSON files.

 In Horizon, when they are viewing the data, the end-user may change the 
 language they wish to see by going into the profile section (upper right hand 
 corner of Horizon) and selecting the language. So,  I need a more dynamic 
 version of i18n than just the version of i18n that gets started up when the 
 Glance service is started (i.e., based on GLANCE_LOCALEDIR and LANGUAGE, 
 LANG, etc., settings).

The API layer can also set a language based on the browser settings. Are the 
JSON files being served by the glance API? Or are they in some other way coming 
through from glance?

WO: The JSON data is being served by the REST API as far as I know. The current 
API doesn't support being passed a locale flag yet though.

 This seems to work:

 import oslo_i18n

 # Assumes GLANCE_JSON_LOCALEDIR has been set appropriately.
 def translate(message, locale=None):
 obj = oslo_i18n._message.Message(message, domain='glance-json')
 return oslo_i18n.translate(obj, locale) ...
 # then in code...
 def _format_namespace_from_db(self, namespace_obj, locale=None):
 ...
 display_name=translate(namespace_obj['display_name'], locale),

 The returned display_name will have the correct version based on the locale 
 passed in.

 But, is this correct usage of oslo_i18n._message()?
 Or is it to remain hidden since it is not part of oslo_i18n.__init__py?
 If it is to remain hidden, then, what would be the better way of getting a 
 dynamic translation based on some arbitrary locale that is passed in.

 If you don't know the answer, but, know someone that might - please pass on 
 their name(s) and I can try to contact them directly.

 Thanks and Regards,
 Wayne Okuma

As you surmise, the _message module is marked private (note the _ prefix on 
the name), so you shouldn't use it directly. The fact that Message objects 
exists is an implementation detail of the lazy translation machinery, and isn't 
meant to be something that applications rely on.

You could use oslo_i18n.TranslatorFactory to get a function to wrap your 
strings instead [1].  The primary attribute should be what you want. Passing 
the return value to translate() would then give you the translated value.

Something like:

  factory = oslo_i18n.TranslatorFactory('glance-json')
  trans = factory.primary

  def translate(message, locale=None):
  return oslo_i18n.translate(trans(message), locale)

This ought to work whether lazy translation is enabled or not, as long as the 
catalog files are installed properly.

Doug

WO: The above works for me...Thanks. I'm curious if there will be a version in 
which a global set of already opened catalogues will be kept for the sake of 
efficiency?

[1] 
http://docs.openstack.org/developer/oslo.i18n/api.html#oslo_i18n.TranslatorFactory

__
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] [ironic] weekly subteam status report

2015-08-10 Thread Ruby Loo

Hi,

Following is the subteam report for Ironic. As usual, this is pulled
directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)

As of Mon, Aug 10 (diff with Aug 3)
- Open: 142. 6 new (-2), 50 in progress (+2), 0 critical, 12 high and 9
incomplete
- Nova bugs with Ironic tag: 25. 1 new, 0 critical, 0 high


Neutron/Ironic work (jroll)
===
- we seem to have missed the boat for the nova side of this :/
- patches are up for a lot of the ironic work
- network flip thing still needs an update
- reviews needed on
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bp/ironic-ml2-integration,n,z


Inspector (dtansur)
===
gate-ironic-inspector-dsvm-nv is running on ironic patches now
- it's pretty reliable (modulo transient failures when building a ramdisk),
so please pay attention to it when submitting and reviewing patches


Drivers
==

iRMC (naohirot)
-
https://review.openstack.org//#/q/owner:+naohirot%2540jp.fujitsu.com+status:+open,n,z

Status: Active (solicit core team's advice for two major issues described
in the spec and the POC code review)
- Enhance Power Interface for Soft Reboot and NMI
- bp/enhance-power-interface-for-soft-power-off-and-inject-nmi

Status: Reactive (code review is on going)
- iRMC out of band inspection
- bp/ironic-node-properties-discovery

Status: TODO
- iRMC Virtual Media Deploy Driver
- Add documentation for iRMC virtual media driver
- follow up patch to fix nits



Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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-operators] Gaining access to consoles.

2015-08-10 Thread Matt Fischer

On Sun, Aug 9, 2015 at 11:59 PM, Tony Breeds t...@bakeyournoodle.com
wrote:

 Hi All,
 Nova has bug: https://bugs.launchpad.net/nova/+bug/1447679 (service
 No-VNC
 (port 6080) doesn't require authentication).

 Which explains that if you know the 'token'[1] associated with an instances
 console you can get access to said console without otherwise proving that
 you
 should be allowed access to that instance[3].

 Nothing limits the problem to VNC, so all console types are potentially
 affected.

 There is a proposed solution (https://review.openstack.org/#/c/182129)
 which
 adds a config option that means a token is only valid for a single usei[4].
 The assertion is that bookmarking a URL to a console and then using it
 multiple
 times is something that we want to still allow albeit discouraged.  When
 the
 config value is introduced it will default to False (meaning that the
 bookmarking scenario above will still work).  At some stage it'd be ideal
 to
 invert this so that the option is True and operators can switch it if
 appropriate.


I'm not excited about making this the default until token revocations don't
impact performance the way that they do now. I don't know how often this
would get exercised though, but the impact of 100+ token revokes is
noticeable on every API call.





 I don't think that much of that in controversial, my question is what
 should
 the schedule for switching this be?  Assuming we land a fix in Liberty[5],
 make
 the change in Mitaka? Norbert?

 Also is being able to bookmark/save the token a thing that users do?

 Yours Tony.

 [1] How you get that token isn't really the issue, it could be a network or
 browser issue [2]
 [2] I should look at the documentation of how we configure console access
 to
 ensure it's secure by default
 [3] Even if the console isn't logged in this is a bad thing(tm)
 [4] There is an outstanding issue with SPICE that is being looked into
 [5] Which isn't a given.

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


__
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] [searchlight] Liberty release planning video conference

2015-08-10 Thread Tripp, Travis S

Hello Anita,

Thank you for the email and for checking into the Postman open ness! There
might be some mis-comunication here. Postman is not an official part of the
project and never will be. Neither will any non-open source code base. As
mentioned in the IRC logs, I personally like to perform additional manual tests
of APIs when doing code reviews. I use both curl and also sometimes find the
Postman browser plugin to be helpful, so was sharing that with others who might
use it. If you do already have an open source browser plugin that has similar
functionality I would very much like to take advantage of it for my personal
testing, because you are certainly right that we don’t want to seem as thought
we are endorsing non-open tool sets!

Thank you!
Travis

On 8/10/15, 5:34 PM, Anita Kuno ante...@anteaya.info wrote:

On 08/10/2015 06:28 PM, Tripp, Travis S wrote:
At our last weekly IRC meeting we decided that we should have a short video
conference meetup to talk about the Liberty 3 release. The purpose will be
to walk through the Liberty Blueprints / Bugs and finalize the list for
Liberty 3. I promised to create a doodle poll for choosing the time, so here
it is:

http://doodle.com/99kzigdbmed57g7s

Hello:

Thank you,
Anita.

__
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] [Bug 1482444] Abnormal changes of quota usage after instance restored by admin

2015-08-10 Thread 郑岳

Hello everyone:
I found a bug in openstack about project's quota usage in newest version.

The link of bug description: https://bugs.launchpad.net/nova/+bug/1482444

Reproduce steps:
 1. Enable soft delete via set reclaim_instance_interval in nova.conf.

2. A normal project: ProjectA create a new instance and then delete it, then 
it's status change to SOFT_DELETED.

 3. Now restore the instance by admin user in project: admin, the  instance 
back to ACTIVE, but the quota usage of project: admin  has  changed, the flavor 
of that instance has added on admin project quota  usage.
Please help me to confirm the problem is real.
Thanks!__
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] Gaining access to consoles.

2015-08-10 Thread Tony Breeds

On Mon, Aug 10, 2015 at 01:34:03PM -0400, Andrew Laski wrote:

 I'm only one data point, but we have a short TTL on tokens so it is not
 something that our users could reasonably due.  And the Nova default TTL is
 10 minutes, which is also out of bookmarking range IMO.

So that's a good point.  If operators allow that behavior they'er already
editing the config so it'd would be the same workflow just editing 2 options
now instead of 1.  Would that be terrible?

Yours Tony.


pgpbORN_2MJxL.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] [Keystone] [Horizon] Federated Login

2015-08-10 Thread Jamie Lennox

- Original Message -
 From: Jamie Lennox jamielen...@redhat.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Sent: Tuesday, 11 August, 2015 10:09:33 AM
 Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login

 - Original Message -
  From: David Chadwick d.w.chadw...@kent.ac.uk
  To: openstack-dev@lists.openstack.org
  Sent: Tuesday, 11 August, 2015 12:50:21 AM
  Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login

  On 10/08/2015 01:53, Jamie Lennox wrote:

   - Original Message -
   From: David Chadwick d.w.chadw...@kent.ac.uk To:
   openstack-dev@lists.openstack.org Sent: Sunday, August 9, 2015
   12:29:49 AM Subject: Re: [openstack-dev] [Keystone] [Horizon]
   Federated Login

   Hi Jamie

   nice presentation, thanks for sharing it. I have forwarded it to
   my students working on federation aspects of Horizon.

   About public federated cloud access, the way you envisage it, i.e.
   that every user will have his own tailored (subdomain) URL to the
   SP is not how it works in the real world today. SPs typically
   provide one URL, which everyone from every IdP uses, so that no
   matter which browser you are using, from wherever you are in the
   world, you can access the SP (via your IdP). The only thing the
   user needs to know, is the name of his IdP, in order to correctly
   choose it.

   So discovery of all available IdPs is needed. You are correct in
   saying that Shib supports a separate discovery service (WAYF), but
   Horizon can also play this role, by listing the IdPs for the user.
   This is the mod that my student is making to Horizon, by adding
   type ahead searching.

   So my point at the moment is that unless there's something i'm
   missing in the way shib/mellon discovery works is that horizon can't.
   Because we forward to a common websso entry point there is no way (i
   know) for the users selection in horizon to be forwarded to keystone.
   You would still need a custom select your idp discovery page in
   front of keystone. I'm not sure if this addition is part of your
   students work, it just hasn't been mentioned yet.

   About your proposed discovery mod, surely this seems to be going in
   the wrong direction. A common entry point to Keystone for all IdPs,
   as we have now with WebSSO, seems to be preferable to separate
   entry points per IdP. Which high street shop has separate doors for
   each user? Or have I misunderstood the purpose of your mod?

   The purpose of the mod is purely to bypass the need to have a
   shib/mellon discovery page on /v3/OS-FEDERATION/websso/saml2. This
   page is currently required to allow a user to select their idp
   (presumably from the ones supported by keystone) and redirect to that
   IDPs specific login page.

  There are two functionalities that are required:
  a) Horizon finding the redirection login URL of the IdP chosen by the user
  b) Keystone finding which IdP was used for login.

  The second is already done by Apache telling Keystone in the header field.

  The first is part of the metadata of the IdP, and Keystone should make
  this available to Horizon via an API call. Ideally when Horizon calls
  Keystone for the list of trusted IdPs, then the user friendly name of
  the IdP (to be displayed to the user) and the login page URL should be
  returned. Then Horizon can present the user friendly list to the user,
  get the login URL that matches this, then redirect the user to the IdP
  telling the IdP the common callback URL of Keystone.

 So my understanding was that this wasn't possible. Because we want to have
 keystone be the registered service provider and receive the returned SAML
 assertions the login redirect must be issued from keystone and not horizon.
 Is it possible to issue a login request from horizon that returns the
 response to keystone? This seems dodgy to me but may be possible if all the
 trust relationships are set up.

Note also that currently this metadata including the login URL is not known by 
keystone. It's controlled by apache in the metadata xml files so we would have 
to add this information to keystone. Obviously this is doable just extra config 
setup that would require double handling of this URL.

 In a way this is exactly what my proposal was. A way for horizon to determine
 a unique websso login page for each idp, just my understanding is that this
 request must be bounced through keystone.

   When the response comes back from that
   login it returns to that websso page and we look at remote_ids to
   determine which keystone idp is handling the response from that
   site.

  This seems the more secure way of determining the IdP to me, since
  Apache determines the IdP then tells Keystone via the header field. If
  you rely on the IdP to contact the right endpoint, then doesn't this
  allow the IdP to return to a different

Re: [openstack-dev] [neutron] Neutron Development Wiki Update

2015-08-10 Thread Sean M. Collins

Link.

Frankly if we have something in DevRef - we should link to it from the
wiki. I hate how stuff gets put in the wiki and then it goes stale real
quick. At least with DevRef, when functionality is added we can push people to
add things to devref, and changes undergo review, as opposed to the free
for all that is the wiki

/rant


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

[openstack-dev] Gaining access to consoles.

2015-08-10 Thread Tony Breeds

Hi All,
Nova has bug: https://bugs.launchpad.net/nova/+bug/1447679 (service No-VNC
(port 6080) doesn't require authentication).

Which explains that if you know the 'token'[1] associated with an instances
console you can get access to said console without otherwise proving that you
should be allowed access to that instance[3].

Nothing limits the problem to VNC, so all console types are potentially 
affected.

There is a proposed solution (https://review.openstack.org/#/c/182129) which
adds a config option that means a token is only valid for a single usei[4].
The assertion is that bookmarking a URL to a console and then using it multiple
times is something that we want to still allow albeit discouraged.  When the
config value is introduced it will default to False (meaning that the
bookmarking scenario above will still work).  At some stage it'd be ideal to
invert this so that the option is True and operators can switch it if
appropriate.

I don't think that much of that in controversial, my question is what should
the schedule for switching this be?  Assuming we land a fix in Liberty[5], make
the change in Mitaka? Norbert?

Also is being able to bookmark/save the token a thing that users do?

Yours Tony.

[1] How you get that token isn't really the issue, it could be a network or
browser issue [2]
[2] I should look at the documentation of how we configure console access to
ensure it's secure by default
[3] Even if the console isn't logged in this is a bad thing(tm)
[4] There is an outstanding issue with SPICE that is being looked into
[5] Which isn't a given.


pgpi2sS33fUwa.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] Detach a volume when it's under migration

I think cinder allow detach volume when it's under migration, but the
volume status will not become 'detaching' or 'available'.

See the code of begin_detaching in cinder:

# If we are in the middle of a volume migration, we don't want the
user
# to see that the volume is 'detaching'. Having 'migration_status'
set
# will have the same effect internally.
if volume['migration_status']:
return

The volume status should be updated correctly when migration is finish.

There is a routine in  _migrate_volume_generic to update the new volume
status after driver.copy_volume_data is done.

2015-08-10 13:09 GMT+08:00 liuxinguo liuxin...@huawei.com:

 Detach a volume when it's under migration, volume status is still “in-use”:

 1.   create vol-1

 2.   attach vol-1 to a vm

 3.   migrate vol-1

 4.   when vol-1 is under migration, detach vol-1

 5.   after vol-1 is detached, command “cinder list” show that the
 Status of vol-1 is still “in-use”.



 If 'migration_status' of the volume is not None, detach process won’t
 update the status of the volume to 'available':



 volume_ref = _volume_get(context, volume_id, session=session)

 if not remain_attachment:

 # Hide status update from user if we're performing volume
 migration

 # or uploading it to image

 if (*not volume_ref['migration_status']* and

 not (volume_ref[*'status'*] == *'uploading'*)):

 volume_ref[*'status'*] = *'available'*



 So how to deal with this? Dose it means that we should not detach a volume
 when it’s under migration?



 Thanks for any input!

 __
 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 Wishes For You!
__
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] Upstream Training prep, live assistance, and mentoring

2015-08-10 Thread Tim Freund


Hi Everyone -

We'll open registration for the Tokyo Upstream training soon, and we're 
doing something a little different this time:  we are pairing students 
with mentors right away and allowing them to work through some of the 
technical details of OpenStack contribution before class begins.


To do that, we need to fill our roster of Upstream mentors!

We need people who are willing to mentor students via IRC and email 
before and after the class that occurs on October 25th and 26th, and we 
also need people who can be with us in Tokyo to help students complete 
hands on exercises.


Please fill out the following form if you can help in either role:
http://goo.gl/forms/fczq3NZ16g

Our students will be looking for bugs tagged as low-hanging-fruit, so 
you can also help by tagging such bugs appropriately in Launchpad.


If you're unfamiliar with Upstream training, and you'd like to learn 
more, we have basic course information and a complete training schedule 
on the wiki[1].  You can read about our Vancouver training session in 
Superuser[2].


[1] https://wiki.openstack.org/wiki/OpenStack_Upstream_Training
[2] 
http://superuser.openstack.org/articles/what-building-legos-can-teach-you-about-open-source


Please direct additional questions or comments to the 
commun...@lists.openstack.org list with the [upstream] tag.  You can 
also reach out to me directly.


Thanks for your help!

Tim

--
Tim Freund
913-207-0983 | @timfreund
http://tim.freunds.net


__
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] Merge back of QoS and pecan branches

2015-08-10 Thread Salvatore Orlando

Kyle,

I can speak very little about the QoS branch, but from what I gather it is
mature enough to be merged back.
However, I believe the Pecan work is still incomplete as we need a solution
to run the RPC over AMQP server independently. Once we have that we can
start merging back what we have.

Salvatore

On 8 August 2015 at 04:39, Kyle Mestery mest...@mestery.com wrote:

As we're beginning to wind down Liberty-3 in a few weeks, I'd like to
present the rough, high level plan to merge back the QoS and pecan branches
into Neutron. Ihar has been doing a great job shepherding the QoS work, and
I believe once we're done landing the final patches this weekend [1], we
can look to merge this branch back next week.

The pecan branch [2] has a few patches left, but it's also my
understanding from prior patches we'll need some additional testing done.
Kevin, what else is left here? I'd like to see if we could merge this
branch back the following week. I'd also like to hear your comments on
enabling the pecan WSGI layer by default for Liberty and what additional
testing is needed (if any) to make that happen.

Thanks!
Kyle

[1]
https://review.openstack.org/#/q/project:openstack/neutron+branch:feature/qos+status:open,n,z
[2]
https://review.openstack.org/#/q/project:openstack/neutron+branch:feature/pecan+status:open,n,z

Re: [openstack-dev] ][third-party-ci]Running custom code before tests

2015-08-10 Thread Eduard Matei

Hi,

Replying to my own post... i found how/where to put the pre_test_hook (in
the jenkins job, in the step that executes the devstack-vm script)

The problem is that now i need to execute code BETWEEN installation of
devstack and start of tests.

Is there a hook i can define that will be executed after devstack installed
but before tests start?

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] [tempest] Mellanox CI request to comment

2015-08-10 Thread Lenny Verkhovsky

Hi all,
Lately we discovered a bug[1] in tempest after the code was merged.
To minimize such things in the future we are asking permission for our CI
to comment as non-voting CI to tempest commits.

We are running SR-IOV tempest tests on Mellanox HW.

Our CI results can be viewed here[2]
Our CI page can be viewed here[3]


[1] https://review.openstack.org/#/c/209553/1
[2] http://144.76.193.39/ci-artifacts/Nova-ML2-Sriov_1864
[3] https://wiki.openstack.org/wiki/ThirdPartySystems/Mellanox_CI

Thanks.
Lenny Verkhovsky

__
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] change of day for API subteam meeting?

2015-08-10 Thread Sean Dague

With no strong preference showing up by the major contributors here I'm
going to suggest Tuesday as the right day -
https://review.openstack.org/#/c/211104/ - (John has a slight preference
for Tuesday).

If you have an issue with that, place a vote on the review.

-Sean

On 08/07/2015 09:26 PM, Ken'ichi Ohmichi wrote:
 Nice idea :-)
 
 
 2015年8月8日(土) 9:05 Alex Xu hejie...@intel.com
 mailto:hejie...@intel.com:
 
 
  在 2015年8月8日，上午12:48，Sean Dague s...@dague.net
 mailto:s...@dague.net 写道：
 
  Friday's have been kind of a rough day for the Nova API subteam. It's
  already basically the weekend for folks in AP, and the weekend is
 right
  around the corner for everyone else.
 
  I'd like to suggest we shift the meeting to Monday or Tuesday in the
  same timeslot (currently 12:00 UTC). Either works for me. Having this
  earlier in the week I also hope keeps the attention on the items
 we need
  to be looking at over the course of the week.
 
 Either works for me.
 
 
  If current regular attendees could speak up about day preference,
 please
  do. We'll make a change if this is going to work for folks.
 
-Sean
 
  --
  Sean Dague
  http://dague.net
 
 
 __
  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
 


-- 
Sean Dague
http://dague.net

__
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][Plugins] add health check for plugins

2015-08-10 Thread Samuel Bartel

Hi all,

actually with fuel plugins there are test for the plugins used by the CICD,
but after a deployment it is not possible for the user to easily test if a
plugin is crrectly deploy or not.
I am wondering if it could be interesting to improve the fuel plugin
framework in order to be able to define test for each plugin which would ba
dded to the health Check. the user would be able to test the plugin when
testing the deployment test.

What do you think about that?


Kind regards

Samuel
__
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]Do we have plan for restoring on-line volume?

2015-08-10 Thread Duncan Thomas

Does restoring a volume online make any logical sense? Generally operating
systems don't like it when a mounted volume changes contents, and a
restore, being a slow sequential write is likely to be even worse. Since
you have to unmount anyway, attaching a new volume should not be an issue.

Just because a feature is technically possible doesn't mean it is a good
idea, particularly when the use of that feature under normal circumstances
causes data corruption.  We have plenty of code paths in cinder already
that are hard to exercise fully and buggy (e.g migration) without adding
more.
On 10 Aug 2015 10:49, hao wang sxmatch1...@gmail.com wrote:

 Sorry if I missed something, since now we have supported backup in-use
 volumes in L,  so I wonder is there some plan or design to support
 restoring on-line volumes.

 Thanks.

 --

 Best Wishes For You!


 __
 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] Merge back of QoS and pecan branches

Thanks Salv. I'll add an item to tomorrow's meeting agenda to discuss this
a bit more and come up with a plan.

On Mon, Aug 10, 2015 at 2:39 AM, Salvatore Orlando salv.orla...@gmail.com
wrote:

Kyle,

I can speak very little about the QoS branch, but from what I gather it is
mature enough to be merged back.
However, I believe the Pecan work is still incomplete as we need a
solution to run the RPC over AMQP server independently. Once we have that
we can start merging back what we have.

Salvatore

On 8 August 2015 at 04:39, Kyle Mestery mest...@mestery.com wrote:

Thanks!
Kyle

[1]
https://review.openstack.org/#/q/project:openstack/neutron+branch:feature/qos+status:open,n,z
[2]
https://review.openstack.org/#/q/project:openstack/neutron+branch:feature/pecan+status:open,n,z

[openstack-dev] [neutron][stable] stable/kilo neutron jobs are blocked on bug 1483266


Looks like this is blocking any jobs in kilo that use neutron:

http://logs.openstack.org/70/210870/1/check/gate-grenade-dsvm-neutron/20f794e/logs/new/screen-q-svc.txt.gz?level=TRACE

This is the bug I reported:

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

What is the Neutron team doing to resolve this since it's holding up the 
other fix for the wedged grenade issues due to neutronclient 2.3.12 
released last week.


--

Thanks,

Matt Riedemann


__
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] Neutron Development Wiki Update

Lets move these types of things into the devref. You can link from the wiki
to the official devref.

On Mon, Aug 10, 2015 at 7:41 AM, Sean M. Collins s...@coreitpro.com wrote:

 Link.

 Frankly if we have something in DevRef - we should link to it from the
 wiki. I hate how stuff gets put in the wiki and then it goes stale real
 quick. At least with DevRef, when functionality is added we can push
 people to
 add things to devref, and changes undergo review, as opposed to the free
 for all that is the wiki

 /rant


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

__
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-10 Thread Matthew Mosesohn

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/
2 - openstackclient should be able to interpret v3 requests and append
v3/ to OS_AUTH_URL=http://keystone-server.5000/ or rewrite the URL if it
is set as OS_AUTH_URL=http://keystone-server.5000/
3 - All deployments require /etc/keystone/keystone.conf with a token (and
not simply use openrc for creating additional endpoints, users, etc beyond
keystone itself and an admin user)

I believe it should be possible to set v2.0 keystone OS_AUTH_URL in openrc
and puppet-keystone + puppet-openstacklib should be able to make v3
requests sensibly by manipulating the URL.
Additionally, creating endpoints/users/roles shouldbe possible via openrc
alone. It's not possible to write single node tests that can demonstrate
this functionality, which is why it probably went undetected for so long.

If anyone can speak up on these items, it could help influence the outcome
of this patch.

Thank you for your time.

Best Regards,
Matthew Mosesohn

On Fri, Jul 31, 2015 at 6:32 PM, Rich Megginson rmegg...@redhat.com wrote:

 On 07/31/2015 07:18 AM, Matthew Mosesohn wrote:

 Jesse, thanks for raising this. Like you, I should just track upstream
 and wait for full V3 support.

 I've taken the quickest approach and written fixes to
 puppet-openstacklib and puppet-keystone:
 https://review.openstack.org/#/c/207873/
 https://review.openstack.org/#/c/207890/

 and again to Fuel-Library:
 https://review.openstack.org/#/c/207548/1

 I greatly appreciate the quick support from the community to find an
 appropriate solution. Looks like I'm just using a weird edge case
 where we're creating users on a separate node from where keystone is
 installed and it never got thoroughly tested, but I'm happy to fix
 bugs where I can.


 Most puppet deployments either realize all keystone resources on the
 keystone node, or drop an /etc/keystone/keystone.conf with admin token onto
 non-keystone nodes where additional keystone resources need to be realized.



 -Matthew

 On Fri, Jul 31, 2015 at 3:54 PM, Jesse Pretorius
 jesse.pretor...@gmail.com wrote:

 With regards to converting all services to use Keystone v3 endpoints,
 note
 the following:

 1) swift-dispersion currently does not support consuming Keystone v3
 endpoints [1]. There is a patch merged to master [2] to fix that, but a
 backport to kilo is yet to be done.
 2) Each type (internal, admin, public) of endpoint created with the
 Keystone
 v3 API has its own unique id, unlike with the v2 API where they're all
 created with a single ID. This results in the keystone client being
 unable
 to read the catalog created via the v3 API when querying via the v2 API.
 The
 solution is to use the openstack client and to use the v3 API but this
 obviously needs to be noted for upgrade impact and operators.
 3) When glance is setup to use swift as a back-end, glance_store is
 unable
 to authenticate to swift when the endpoint it uses is a v3 endpoint.
 There
 is a review to master in progress [3] to fix this which is unlikely to
 make
 it into kilo.

 We (the openstack-ansible/os-ansible-deployment project) are tracking
 these
 issues and doing tests to figure out all the bits. These are the bugs
 we've
 hit so far. Also note that there is a WIP patch to gate purely on
 Keystone
 v3 API's which is planned to become voting (hopefully) by the end of this
 cycle.

 [1] https://bugs.launchpad.net/swift/+bug/1468374
 [2] https://review.openstack.org/195131
 [3] https://review.openstack.org/193422


 __
 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

Re: [openstack-dev] [murano] Questions on creating and importing HOT packages

2015-08-10 Thread GERSHENZON, Michal (Michal)

These two subjects have probably been discussed already, but I couldn't find 
any info on them, so very much appreciate if someone could clarify. 
1. Why is the HOT template that is fed to package-create command renamed to 
template.yaml? Any issue with keeping the original name?
2. Why HOT syntax validation is deferred until package import time? Why not do 
it when creating the package?

Hi Vahid,

This is my understanding of the issues you presented:

1. To support such a feature, obviously the code needs to change, since today
   the file template.yaml is expected to be in the root of the package.
   
   In addition if the package structure will remain as it is today, the naming
   options will still be limited. More specificity - the template could not be
   saved with the name manifest.yaml, since it is reserved for the manifest.
   
2. If the user has a few versions of Heat he works with. He might want to use
   python-muranoclient only to package the template. In other use cases I think
   validation can be helpful.

Thanks,
Michal

__
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] [oslo] troubling passing of unit tests on broken code

2015-08-10 Thread Lenny Verkhovsky

Hi,
Had you tried removing oslo_db package?
I saw a similar issues and usually uninstalling or upgrading packages solved 
the problem

L.

-Original Message-
From: Mike Bayer [mailto:mba...@redhat.com] 
Sent: Saturday, August 08, 2015 1:43 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [nova] [oslo] troubling passing of unit tests on 
broken code

Just a heads up that this recently merged code is wrong:

https://review.openstack.org/#/c/192760/14/nova/tests/unit/db/test_migrations.py,cm

and here it is failing tests on my local env, as it does on my CI, as would be 
expected, there's a lot more if I keep it running:

http://paste.openstack.org/show/412236/

However, utterly weirdly, all those tests *pass* with the same versions of 
everything in the gate:

http://paste.openstack.org/show/412236/


I have no idea why this is.  This might be on the oslo.db side within 
the test_migrations logic, not really sure.If someone feels like 
digging in, that would be great.

The failure occurs with both Alembic 0.7.7 and Alembic 0.8 as yet unreleased.  
I have a feeling that releasing Alembic 0.8 may or may not bump this failure to 
be more widespread, just because of its apparent heisenbuggy nature, and I'm 
really hoping to release 0.8 next week.  It was supposed to be this week but I 
got sidetracked.



__
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] Neutron Development Wiki Update

2015-08-10 Thread Andreas Scheuring

Hi, 
I wonder if it makes sense to update the section Proposing and
Implementing a Feature [1] of the Neutron development wiki with the new
RFE workflow described here [2]. Or even better just add a link?

Thanks



[1]
https://wiki.openstack.org/wiki/NeutronDevelopment#Proposing_and_Implementing_a_Feature

[2] http://docs.openstack.org/developer/neutron/policies/blueprints.html

-- 
Andreas
(IRC: scheuran)



__
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] weekly meeting #46

2015-08-10 Thread Emilien Macchi

Hello,

Here's an initial agenda for our weekly meeting, tomorrow at 1500 UTC
in #openstack-meeting-4:

https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150811

Colleen will lead the meeting.
Please add additional items you'd like to discuss.
If our schedule allows it, we'll make bug triage during the meeting.
-- 
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] [api] [all] To changes-since or not to changes-since

2015-08-10 Thread Kirill Zaitsev

GET /app/items?f_updated_at=gte:some_timestamp

I guess this should only return existing entries in a collection, while the 
proposition was to add deleted entries to the result too (if we use 
changes_since). More like a delta, than simple filtering.

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 10 Aug 2015 at 07:10:23, hao wang (sxmatch1...@gmail.com) wrote:

Hi, stackers

Since now we have merged filtering guideline[1], is that said we should 
implement this feature according this guideline?  like this:

GET /app/items?f_updated_at=gte:some_timestamp

Do we have reached a consensus about this?

2015-06-19 17:07 GMT+08:00 Chris Dent chd...@redhat.com:

There's an open question in the API-WG on whether to formalize or
otherwise enshrine the concept of a changes-since query parameter
on collection oriented resources across the projects. The original
source of this concept is from Nova's API:

    
http://docs.openstack.org/developer/nova/v2/polling_changes-since_parameter.html

There are arguments for and against but we've been unable to reach a
consensus so the agreed next step was to bring the issue to the
mailing list so more people can hash it out and provide their input.
The hope is that concerns or constraints that those in the group
are not aware of will be revealed and a better decision will be
reached.

The basic idea of changes-since is that it can be used as a way to
signal that the requestor is doing some polling and would like to
ask Give me stuff that has changed since the last time I checked.
As I understand it, for the current implementations (in Nova and
Glance) this means including stuff that has been deleted. Repeated
requests to the resource with a changes-since parameter gives a
running report on the evolving state of the resource. This is intended
to allow efficient polling[0].

The pro camp on this likes it because this is very useful and quite
humane: The requestor doesn't need to know the details of how the
query is is implemented under the hood. That is, if there are
several timestamps associated with the singular resources in the
collection which of those are used for time comparison and which
attributes (such as state with a value of deleted) are used to
determine if a singular resource is included. The service gets to
decide these things and in order for efficient polling to actually
be achieved it needs to do in order to make effective queries of the
data store.

The con camp doesn't like it because it introduces magic, ambiguity
and inconsistency into the API (when viewed from a cross-project
perspective) and one of the defining goals of the working group is
to slowly guide things to some measure of consistency. The
alternate approach is to formulate a fairly rigorous query system
for both filtering[1] and sorting[2] and use that to specify
explicit queries that state I want resources that are newer than time
X in timestamp attribute 'updated_at' _and_ have attribute 'state'
that is one of 'foo', 'bar' or 'baz'.

(I hope I have represented the two camps properly here and not
introduced any bias. Myself I'm completely on the fence. If you
think I've misrepresented the state of things please post a
clarifying response.)

The questions come down to:

* Are there additional relevant pros and cons for the two proposals?
* Are there additional proposals which can address the shortcomings
  in either?

Thanks for your input.

[0] Please try to refrain from responses on the line of ha!
    efficiency! that's hilarious! and ZOMG, polling, that's so
    last century. Everybody knows this already and it's not
    germane to the immediate concerns. We'll get to a fully message
    driven architecture next week. This week we're still working
    with what we've got.
[1] filtering guideline proposal
    https://review.openstack.org/#/c/177468/
[2] sorting guideline proposal
    https://review.openstack.org/#/c/145579/
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

__
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 Wishes For You!
__  
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][Plugins] add health check for plugins

2015-08-10 Thread Simon Pasquier

Hello Samuel,
This looks like an interesting idea. Do you have any concrete example to
illustrate your point (with one of your plugins maybe)?
BR,
Simon

On Mon, Aug 10, 2015 at 12:04 PM, Samuel Bartel samuel.bartel@gmail.com
 wrote:

 Hi all,

 actually with fuel plugins there are test for the plugins used by the
 CICD, but after a deployment it is not possible for the user to easily test
 if a plugin is crrectly deploy or not.
 I am wondering if it could be interesting to improve the fuel plugin
 framework in order to be able to define test for each plugin which would ba
 dded to the health Check. the user would be able to test the plugin when
 testing the deployment test.

 What do you think about that?


 Kind regards

 Samuel

 __
 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] How should we expose host capabilities to the scheduler

2015-08-10 Thread Jay Pipes

On 08/03/2015 09:57 AM, Dulko, Michal wrote:

-Original Message-
From: Dugger, Donald D [mailto:donald.d.dug...@intel.com]
Sent: Monday, August 3, 2015 7:40 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] How should we expose host capabilities to the
scheduler

Without going into the solution space the first thing we need to do is make
sure we know what the requirements are for exposing host capabilities.  At a
minimu we need to:

Enumerate the capabilities.  This will involve both quantitative values
(amount of RAM, amount of disk, .) and Boolean (magic instructions
present).  Also, there will be static capabilities that are discovered at boot
time and don't change afterwards and dynamic capabilities that vary during
node operation.
Expose the capabilities to both users and operators.
Request specific capabilities.  A way of requesting an instance with an explicit
list of specific capabilities is a minimal requirement.  It would probably also 
be
good to have a way to easily specify an aggregate that encompasses a set of
capabilities.

Note that I'm not saying we should remove flavors, but we might need a
different way to specify what makes up a flavor.

As I said, I don't have the answer to how to do this but I want to start a
discussion on where we go from here.

--
Don Dugger
Censeo Toto nos in Kansa esse decisse. - D. Gale
Ph: 303/443-3786

There already is a Glance Metadata Catalog which is enumerating and exposing 
different meaningful extra_specs that can be attached to a flavor. The list of 
capabilities is defined here: 
https://github.com/openstack/glance/tree/master/etc/metadefs. Example 
definition of flavor extra_specs: 
https://github.com/openstack/glance/blob/master/etc/metadefs/compute-host-capabilities.json.

The Glance metadefs stuff is problematic in a number of ways:

1) It wasn't written with Nova in mind at all, but rather for UI needs. 
This means it introduces a bunch of constants that are different from 
the constants in Nova.

2) It uses a custom JSON format instead of JSONSchema, so we now need to 
figure out the schema for these metadef documents and keep up to date 
with that schema as it changes.

3) It mixes qualitative things -- CPU model, features, etc -- with 
quantitative things -- amount of cores, threads, etc. These two things 
are precisely what we are trying to decouple from each other in the next 
generation of Nova's flavors.

4) It is still missing the user-facing representation of these things. 
Users -- i.e. the people launching VMs in Nova -- do not want or need to 
know whether the underlying hardware is running Nehalem processors or 
Sandybridge processors. They only need to know the set of generic 
features that are exposed to the workloads running on the host. In other 
words, we are looking for a way to map service levels such as Silver 
Compute or Whizbang Amazing Compute to a set of hardware that exposes 
some features. We need that compatibility layer on top of the low-level 
hardware specifics that will allow service providers to create these 
product categories if you will.

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] stable is hosed

On Sun, Aug 9, 2015 at 8:28 PM, Matt Riedemann mrie...@linux.vnet.ibm.com
wrote:



 On 8/9/2015 7:55 PM, Matt Riedemann wrote:



 On 8/9/2015 7:09 PM, Matt Riedemann wrote:



 On 8/9/2015 6:57 PM, Robert Collins wrote:

 On 8 August 2015 at 12:45, Matt Riedemann mrie...@linux.vnet.ibm.com
 wrote:

 What I do know is we need to be better about bumping the minor
 version in a
 release rather than the patch version all of the time - we've kind of
 painted ourselves into a corner a few times here with leaving no
 wiggle room
 for patch releases on stable branches.


 Right: any non-bugfix change should be a minor version bump. Most
 (perhaps all?) dependency changes should be a minor bump. Some may
 even qualify as major bumps.

 -Rob


 This is my hack attempt to fix grenade:

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

 I'm not well versed in grenade so if there is a better way to tell
 devstack to install that specific range of neutronclient on the target
 side I'm all ears.


 I'm not totally sure if this is due to neutronclient being 2.4.0 in
 grenade kilo or not, could use some help from neutron people:


 http://logs.openstack.org/70/210870/1/check/gate-grenade-dsvm-neutron/20f794e/logs/new/screen-q-svc.txt.gz?level=TRACE



 Yuck, looks like another issue that's been around since last week:

 http://goo.gl/Jwib2w


 Per discussion on IRC just now, Doug is on this and should post a fix for
this soon. Stay tuned, and I'll reply here with the patch once it lands.


 --

 Thanks,

 Matt Riedemann


 __
 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] OS::Neutron::Port fails to set security group by name, no way to retrieve group ID from Neutron::SecurityGroup

2015-08-10 Thread jason witkowski

Just to confirm as well if I use the CLI to create a neutron port after the
Heat stack has ran and created the security group everything works fine and
the security group is attached to the neutron port as expected.  However
heat is not managing to make this happen, even if I run a check or an
update after the first run I am still met with neutron ports with no
security groups.  Looking at the code snippets above it looks like default
is only not applied when an empty list is supplied.  Wouldn't this mean
that the get_resource function is returning empty?

On Sun, Aug 9, 2015 at 7:25 PM, jason witkowski jwit...@gmail.com wrote:

 Steve,

 There is no error.  Heat reports a successful build with no issues.  I've
 attached the neutron port-show as well as the full heat engine logs for a
 build of the stack start to end.

 http://paste.openstack.org/show/412313/ - Heat Engine logs
 http://paste.openstack.org/show/412314/ - neutron port-show on newly
 created interface


 -Jason

 On Sun, Aug 9, 2015 at 6:51 PM, Steve Baker sba...@redhat.com wrote:

 On 08/08/15 01:51, jason witkowski wrote:

 Thanks for the replies guys.  The issue is that it is not working.  If
 you take a look at the pastes I linked from the first email I am using the
 get_resource function in the security group resource. I am not sure if it
 is not resolving to an appropriate value or if it is resolving to an
 appropriate value but then not assigning it to the port. I am happy to
 provide any more details or examples but I'm not sure what else I can do
 but provide the configuration examples I am using that are not working?
 It's very possible my configurations are wrong but I have scoured the
 internet for any/all examples and it looks like what I have should be
 working but it is not.


 Can you provide details of what the actual error is, plus the output of
 neutron port-show for that port?


 __
 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][Plugins] add health check for plugins

2015-08-10 Thread Sheena Gregson

I like that idea a lot – I also think there would be value in adding
pre-deployment sanity checks that could be called from the Health Check
screen prior to deployment.  Thoughts?



*From:* Simon Pasquier [mailto:spasqu...@mirantis.com]
*Sent:* Monday, August 10, 2015 9:00 AM
*To:* OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
*Subject:* Re: [openstack-dev] [Fuel][Plugins] add health check for plugins



Hello Samuel,

This looks like an interesting idea. Do you have any concrete example to
illustrate your point (with one of your plugins maybe)?

BR,

Simon



On Mon, Aug 10, 2015 at 12:04 PM, Samuel Bartel samuel.bartel@gmail.com
wrote:

Hi all,



actually with fuel plugins there are test for the plugins used by the CICD,
but after a deployment it is not possible for the user to easily test if a
plugin is crrectly deploy or not.

I am wondering if it could be interesting to improve the fuel plugin
framework in order to be able to define test for each plugin which would ba
dded to the health Check. the user would be able to test the plugin when
testing the deployment test.



What do you think about that?





Kind regards



Samuel


__
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][Nova] VMware NSXv Support

Hi,
I am not really sure what to say here. The code was in review for over 8
months. On a side note but related - we have a patch for a plugin
developed in Liberty - https://review.openstack.org/#/c/165750/. This has
been in review since March. I really hope that that lands in Liberty. If
not we will go through the same thing again.
Working in Nova on code that is self contained within a driver is
difficult - terribly difficult. Not only is this demotivating, it also
effectively does not help any of the drivers actually add any features.
A sad day for OpenStack.
Thanks
Gary

On 8/5/15, 4:01 PM, Ihar Hrachyshka ihrac...@redhat.com wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I think Erno made a valid point here. If that would touch only vmware
code, that could be an option to consider. But it looks like both
patches are very invasive, and they are not just enabling features
that are already in the tree, but introduce new stuff that is not even
tested for long in master.

I guess we'll need to wait for those till Liberty. Unless
nova-core-maint has a different opinion and good arguments to approach
the merge.

Ihar

On 08/05/2015 12:37 PM, Kuvaja, Erno wrote:
 Hi Gary,
 
 
 
 While I do understand the interest to get this functionality
 included, I really fail to see how it would comply with the Stable
 Branch Policy: 
 https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy
 
 Obviously the last say is on stable-maint-core, but normally new
 features are really no-no to stable branches.
 
 
 
 My concerns are more on the metadata side of your changes.
 
 Even the refactoring is fairly clean it is major part of the
 metadata handler.
 
 It also changes the API (In the case of X-Metadata-Provider being
 present) which tends to be sacred on stable branches.
 
 
 
 The changes here does not actually fix any bug but just implements
 new functionality that missed kilo not even slightly but by months.
 Thus my -1 for merging these.
 
 
 
 -  Erno
 
 
 
 *From:*Gary Kotton [mailto:gkot...@vmware.com] *Sent:* Wednesday,
 August 05, 2015 8:03 AM *To:* OpenStack List *Subject:*
 [openstack-dev] [Stable][Nova] VMware NSXv Support
 
 
 
 Hi,
 
 In the Kilo cycle a Neutron driver was added for supporting the
 Vmware NSXv plugin. This required patches in Nova to enable the
 plugin to work with Nova. These patches finally landed yesterday. I
 have back ported them to stable/kilo as the Neutron driver is
 unable to work without these in stable/kilo. The patches can be
 found at:
 
 1. VNIC support - https://review.openstack.org/209372 2. Metadata
 support - https://review.openstack.org/209374
 
 I hope that the stable team can take this into consideration.
 
 
 
 Thanks in advance
 
 Gary
 
 
 
 __


 
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

iQEcBAEBCAAGBQJVwgkjAAoJEC5aWaUY1u57NacIALsJ8oo6eJKqJIidBSFzwxvg
zqJXHE56Lpg62/afRF94B2edfhm791Mz42LTFn0BHHRjV51TQX4k/Jf3Wr22CEvm
zFZkU5eVMVOSL3GGnOZqSv/T06gBWmlMVodmSKQjGxrIL1s8G1m4aTwe6Pqs+lie
N+cT0pZbcjL/P1wYTac6XMpF226gO1owUjhE4oj9VZzx7kEqNsv22SIzVN2fQcco
YLs/LEcabMhuuV4Amde3RqUr0BkB+mlIX1TUv5/FTXT/F4ZwzYS/DBH9MaBJ5t8n
hgCTJzCeg598+irgOt3VJ3Jn3Unljz6LNzKIM8RnBG0o51fp8vfE/mODQQaUKOg=
=ZYP8
-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] [neutron][stable] stable/kilo neutron jobs are blocked on bug 1483266