[openstack-dev] [new][keystone] keystonemiddleware 4.7.0 release (newton)

[no-reply]

We are excited to announce the release of:

keystonemiddleware 4.7.0: Middleware for OpenStack Identity

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/keystonemiddleware

With package available at:

https://pypi.python.org/pypi/keystonemiddleware

Please report issues through launchpad:

http://bugs.launchpad.net/keystonemiddleware

For more details, please see below.

Changes in keystonemiddleware 4.6.0..4.7.0
--

8873c48 Add Python 3.5 classifier
20547f1 Updated from global requirements
6c0c988 Updated from global requirements
8ef7afa Updated from global requirements
0d1fc6c Use jsonutils instead of ast for loading the service catalog
23711a5 Remove the _is_v2 and _is_v3 helpers


Diffstat (except docs and test files)
-

keystonemiddleware/audit/_api.py |  5 ++---
keystonemiddleware/auth_token/__init__.py|  8 
.../unit/auth_token/test_auth_token_middleware.py| 20 
requirements.txt |  6 +++---
setup.cfg|  1 +
test-requirements.txt|  2 +-
8 files changed, 17 insertions(+), 45 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 9398a42..8d21a86 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6,2 +6,2 @@ keystoneauth1>=2.7.0 # Apache-2.0
-oslo.config>=3.10.0 # Apache-2.0
-oslo.context>=2.4.0 # Apache-2.0
+oslo.config>=3.12.0 # Apache-2.0
+oslo.context!=2.6.0,>=2.4.0 # Apache-2.0
@@ -10 +10 @@ oslo.serialization>=1.10.0 # Apache-2.0
-oslo.utils>=3.14.0 # Apache-2.0
+oslo.utils>=3.15.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 969c9be..526cea2 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -17 +17 @@ sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
-stevedore>=1.10.0 # Apache-2.0
+stevedore>=1.16.0 # Apache-2.0



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

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Steven Dake (stdake)]

Dims,

I personally think its the responsibility of the TC to resolve this
problem via a resolution.  That’s why we elected you folks :)

Regards
-steve


On 7/28/16, 11:09 AM, "Davanum Srinivas"  wrote:

>Zane, Steve,
>
>I'd say go for it! Can you please write up a proposal for the TC to
>consider? (https://review.openstack.org/#/q/project:openstack/governance)
>
>Thanks,
>-- Dims
>
>On Thu, Jul 28, 2016 at 2:01 PM, Steven Dake (stdake) 
>wrote:
>> Jay,
>>
>> I'll be frank.  I have been receiving numerous complaints which mirror
>> Zane's full second understanding of what it means to be an OpenStack big
>> tent project.  These are not just Kolla developers.  These are people
>>from
>> all over the community.  They want something done about it.  I agree
>>with
>> Zane if clarity is provided by the TC via a resolution, the problem
>>would
>> disappear.  We are all adults and can live by the rules, even if we
>> disagree with them.  This contract is the agreement under which
>> democracies are created, and one of the most appealing properties of
>> OpenStack.
>>
>> In this case there is no policy and one is obviously necessary to avoid
>> these scenarios in the future.
>>
>> The TC has four options as I see it:
>> 1) do nothing
>> 2) write a resolution mirroring Zane's first analysis
>> 3) write a resolution mirroring Zane's second analysis
>> 4) write a different resolution that is a compromise of the first
>>analysis
>> and second analysis
>>
>> I don't wish Mirantis to state anything.  Vladimir did that (thanks
>> Vladimir!).
>>
>> Regards
>> -steve
>>
>>
>> On 7/28/16, 10:30 AM, "Jay Pipes"  wrote:
>>
>>>I don't see what is unclear about any of it.
>>>
>>>What exactly is it that you wish Mirantis to state?
>>>
>>>Zane says there needs to be some guidance from the TC "about what it
>>>means for a repo to be part of the OpenStack tent".
>>>
>>>But the fuel-ccp repos aren't listed in the governance repo, for reasons
>>>that were clearly stated by Mirantis engineers. They want to innovate in
>>>this area without all the politics that this thread exposes.
>>>
>>>Mirantis engineers have clearly laid out the technical reasons that
>>>Kolla doesn't fit the needs that Fuel has of these image definitions and
>>>orchestration tooling.
>>>
>>>The repos *aren't in the OpenStack tent* so how precisely would TC
>>>guidance about what it means for a repo to be part of the OpenStack tent
>>>be useful here?
>>>
>>>-jay
>>>
>>>On 07/28/2016 01:04 PM, Steven Dake (stdake) wrote:
 Jay,

 That resolution doesn't clarify Zane's argument.

 Regards,
 -steve

 On 7/28/16, 9:54 AM, "Jay Pipes"  wrote:

> The TC has given guidance on this already:
>
>
>http://governance.openstack.org/resolutions/20160119-stackforge-retire
>me
>nt
> .html
>
> "In order to simplify software development lifecycle transitions of
> Unofficial and Official OpenStack projects, all projects developed
> within the OpenStack project infrastructure will be permitted to use
>the
> “openstack/” namespace. The use of the term “Stackforge” to describe
> unofficial projects should be considered deprecated."
>
> The Fuel CCP repos are projects that are not official OpenStack
>projects.
>
> They are in the openstack/ git namespace because they use the common
> infrastructure and there isn't any formal plan to have the repos join
> the "official OpenStack projects" (i.e. the ones listed in the
> projects.yaml file in the openstack/governance repository).
>
> Could they be proposed in the future as official OpenStack projects?
> Maybe. Not sure, and I don't believe it's necessary to decide ahead
>of
> time.
>
> Please stop using a marketing press release as some indication of
>what
> the "intent" is for these repos or even that there *is* any intent at
> this point. It's really early on and these repos are intended as a
>place
> to experiment and innovate. I don't see why there is so much anger
>about
> that.
>
> Best,
> -jay
>
> On 07/28/2016 12:33 PM, Steven Dake (stdake) wrote:
>> Doug,
>>
>> Zane's analysis is correct.  I agree with Zane's assessment that TC
>> clarification can solve this situation.
>>
>> Regards
>> -steve
>>
>> On 7/28/16, 9:15 AM, "Zane Bitter"  wrote:
>>
>>> On 28/07/16 08:48, Vladimir Kozhukalov wrote:
 Fuel-ccp repositories are public, everyone is welcome to
participate.
 I
 don¹t see where we violate ³4 opens². These repos are now
 experimental.
 At the moment the team is working on building CI pipeline and
 developing
 functional tests that are to be run as a part of CI process. These
 repos
 are not to be a part of Fuel 

[openstack-dev] [new][keystone] keystoneauth1 2.10.0 release (newton)

[no-reply]

We are satisfied to announce the release of:

keystoneauth1 2.10.0: Authentication Library for OpenStack Identity

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/keystoneauth

With package available at:

https://pypi.python.org/pypi/keystoneauth1

Please report issues through launchpad:

http://bugs.launchpad.net/keystoneauth

For more details, please see below.

2.10.0
^^

Add the prompt parameter to loader Opts

Allow specifying additional_headers to the session and the adapter to
add headers to all requests that pass through these objects.


New Features


* Add support for the Client Credentials OpenID Connect grant type.

* Add support for the OpenID Connect Discovery Document
  (https://openid.net/specs/openid-connect-
  discovery-1_0.html#ProviderMetadata) into the OpenID Connect related
  plugins. Now it is possible to only pass the *discovery-url* option
  and the plugins will try to fetch the required metadata from there.

* The prompt parameter was added to the Opts provided by auth
  plugins. The presence of the prompt parameter on an Option will
  indicate to plugin loaders that it is ok to prompt the user for
  input for this parameter if none is provided initially. Actual
  implementation of this prompting mechanism will be handled by the
  individual loaders such as os-client-config.

* Add the ability to provide additional_headers to the session and
  adapter object. This will allow clients particularly to provide
  additional ways to identify their requests. It will also hopefully
  provide an intermediate way to handle setting microversions until we
  support them directly with keystoneauth.


Bug Fixes
*

* [bug 1583682
  (https://bugs.launchpad.net/keystoneauth/+bug/1583682)] OpenID
  Connect plugins should support OpenID Connect Discovery.

Changes in keystoneauth1 2.9.0..2.10.0
--

6306504 Lazy load oauthlib for plugin loading
712ee40 oidc: add missing 'OidcAccessToken' to __all__
e5fd66c oidc: implement client_credentials grant type
67530bd Fix ECP doc link in Saml2 Password class doc
abb63ce Updated from global requirements
53f1e3c Fix link for "extras dependencies" in extras doc
c21ce26 Add pretty serializer for betamax fixture
bc90281 Update hacking to global-requirements value
701b911 Use SAML2 requests plugin
76bd9bb Updated from global requirements
9bf4efd oidc: move the get_unscoped_auth_ref into the base class
885aff0 oidc: deprecate grant_type argument
00746ea oidc: add discovery document support
1045a14 Add additional_headers to session and adapter
88d4fdb Add Python 3.5 classifier and venv
f2cc77c remove unused LOG
391499f Updated from global requirements
eff0936 Updated from global requirements
71d2e1a Add prompt parameter to Opt
e203d61 Auth plugin for X.509 tokenless authentication
68a7962 oidc: fix OpenID scope management
784ac09 Add create_plugin to loader


Diffstat (except docs and test files)
-

keystoneauth1/adapter.py   |  11 +-
keystoneauth1/exceptions/__init__.py   |   1 +
keystoneauth1/exceptions/oidc.py   |  44 ++
keystoneauth1/extras/_saml2/__init__.py|   2 +
keystoneauth1/extras/_saml2/_loading.py|   4 +
keystoneauth1/extras/_saml2/v3/__init__.py |   2 +
keystoneauth1/extras/_saml2/v3/saml2.py| 514 ++---
keystoneauth1/extras/oauth1/_loading.py|   4 +
keystoneauth1/extras/oauth1/v3.py  |   5 +-
keystoneauth1/fixture/keystoneauth_betamax.py  |   8 +-
keystoneauth1/fixture/serializer.py|  92 
keystoneauth1/identity/__init__.py |   9 +-
keystoneauth1/identity/generic/token.py|   3 -
keystoneauth1/identity/v3/__init__.py  |   7 +-
keystoneauth1/identity/v3/oidc.py  | 326 ++---
keystoneauth1/identity/v3/tokenless_auth.py| 115 +
keystoneauth1/loading/_plugins/identity/generic.py |   5 +-
keystoneauth1/loading/_plugins/identity/v2.py  |   5 +-
keystoneauth1/loading/_plugins/identity/v3.py  |  90 +++-
keystoneauth1/loading/base.py  |  22 +-
keystoneauth1/loading/opts.py  |   6 +-
keystoneauth1/session.py   |  10 +-
.../saml2/fixtures/templates/authn_request.xml |  22 +
...d-oidc-client-credentials-2be065926ba4b849.yaml |   4 +
...iscovery-document-support-b07fe54f83286d62.yaml |  12 +
.../notes/add-prompt-to-opt-d083acc357a7f07b.yaml  |  10 +
.../notes/additional-headers-f2d16f85f5abe942.yaml |  10 +
requirements.txt   |   2 +-
setup.cfg  |   4 +
test-requirements.txt  |   7 +-
tox.ini|   2 +-
43 files changed, 1936 insertions(+), 612 

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Davanum Srinivas]

Steven,

Please see response from Doug:
http://markmail.org/message/yp7fpojnzufb5jki

If anyone disagrees with that position, please file a resolution.

Let's stop this thread now please.

Thanks,
Dims

On Thu, Jul 28, 2016 at 3:26 PM, Steven Dake (stdake)  wrote:
> Dims,
>
> I personally think its the responsibility of the TC to resolve this
> problem via a resolution.  That’s why we elected you folks :)
>
> Regards
> -steve
>
>
> On 7/28/16, 11:09 AM, "Davanum Srinivas"  wrote:
>
>>Zane, Steve,
>>
>>I'd say go for it! Can you please write up a proposal for the TC to
>>consider? (https://review.openstack.org/#/q/project:openstack/governance)
>>
>>Thanks,
>>-- Dims
>>
>>On Thu, Jul 28, 2016 at 2:01 PM, Steven Dake (stdake) 
>>wrote:
>>> Jay,
>>>
>>> I'll be frank.  I have been receiving numerous complaints which mirror
>>> Zane's full second understanding of what it means to be an OpenStack big
>>> tent project.  These are not just Kolla developers.  These are people
>>>from
>>> all over the community.  They want something done about it.  I agree
>>>with
>>> Zane if clarity is provided by the TC via a resolution, the problem
>>>would
>>> disappear.  We are all adults and can live by the rules, even if we
>>> disagree with them.  This contract is the agreement under which
>>> democracies are created, and one of the most appealing properties of
>>> OpenStack.
>>>
>>> In this case there is no policy and one is obviously necessary to avoid
>>> these scenarios in the future.
>>>
>>> The TC has four options as I see it:
>>> 1) do nothing
>>> 2) write a resolution mirroring Zane's first analysis
>>> 3) write a resolution mirroring Zane's second analysis
>>> 4) write a different resolution that is a compromise of the first
>>>analysis
>>> and second analysis
>>>
>>> I don't wish Mirantis to state anything.  Vladimir did that (thanks
>>> Vladimir!).
>>>
>>> Regards
>>> -steve
>>>
>>>
>>> On 7/28/16, 10:30 AM, "Jay Pipes"  wrote:
>>>
I don't see what is unclear about any of it.

What exactly is it that you wish Mirantis to state?

Zane says there needs to be some guidance from the TC "about what it
means for a repo to be part of the OpenStack tent".

But the fuel-ccp repos aren't listed in the governance repo, for reasons
that were clearly stated by Mirantis engineers. They want to innovate in
this area without all the politics that this thread exposes.

Mirantis engineers have clearly laid out the technical reasons that
Kolla doesn't fit the needs that Fuel has of these image definitions and
orchestration tooling.

The repos *aren't in the OpenStack tent* so how precisely would TC
guidance about what it means for a repo to be part of the OpenStack tent
be useful here?

-jay

On 07/28/2016 01:04 PM, Steven Dake (stdake) wrote:
> Jay,
>
> That resolution doesn't clarify Zane's argument.
>
> Regards,
> -steve
>
> On 7/28/16, 9:54 AM, "Jay Pipes"  wrote:
>
>> The TC has given guidance on this already:
>>
>>
>>http://governance.openstack.org/resolutions/20160119-stackforge-retire
>>me
>>nt
>> .html
>>
>> "In order to simplify software development lifecycle transitions of
>> Unofficial and Official OpenStack projects, all projects developed
>> within the OpenStack project infrastructure will be permitted to use
>>the
>> “openstack/” namespace. The use of the term “Stackforge” to describe
>> unofficial projects should be considered deprecated."
>>
>> The Fuel CCP repos are projects that are not official OpenStack
>>projects.
>>
>> They are in the openstack/ git namespace because they use the common
>> infrastructure and there isn't any formal plan to have the repos join
>> the "official OpenStack projects" (i.e. the ones listed in the
>> projects.yaml file in the openstack/governance repository).
>>
>> Could they be proposed in the future as official OpenStack projects?
>> Maybe. Not sure, and I don't believe it's necessary to decide ahead
>>of
>> time.
>>
>> Please stop using a marketing press release as some indication of
>>what
>> the "intent" is for these repos or even that there *is* any intent at
>> this point. It's really early on and these repos are intended as a
>>place
>> to experiment and innovate. I don't see why there is so much anger
>>about
>> that.
>>
>> Best,
>> -jay
>>
>> On 07/28/2016 12:33 PM, Steven Dake (stdake) wrote:
>>> Doug,
>>>
>>> Zane's analysis is correct.  I agree with Zane's assessment that TC
>>> clarification can solve this situation.
>>>
>>> Regards
>>> -steve
>>>
>>> On 7/28/16, 9:15 AM, "Zane Bitter"  wrote:
>>>
 On 28/07/16 08:48, Vladimir 

[openstack-dev] [new][openstack] osc-lib 0.4.1 release (newton)

[no-reply]

We are joyful to announce the release of:

osc-lib 0.4.1: OpenStackClient Library

This release is part of the newton release series.

With source available at:

https://git.openstack.org/cgit/openstack/osc-lib

With package available at:

https://pypi.python.org/pypi/osc-lib

Please report issues through launchpad:

https://bugs.launchpad.net/python-openstackclient

For more details, please see below.

Changes in osc-lib 0.4.0..0.4.1
---

f535ace Allow shell class to be overridden in test subclass
02a8904 Remove option handling unused code
85c977a Use assertEqual() instead of assertDictEqual()
63b8451 Remove unused releasenotes infrastructure


Diffstat (except docs and test files)
-

osc_lib/clientmanager.py| 53 -
test-requirements.txt   |  1 -
tox.ini |  3 --
5 files changed, 11 insertions(+), 82 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index f9215a2..42bca99 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -11 +10,0 @@ oslotest>=1.10.0 # Apache-2.0
-reno>=1.8.0 # Apache2



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

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Steven Dake (stdake)]

On 7/28/16, 12:30 PM, "Davanum Srinivas"  wrote:

>Steven,
>
>Please see response from Doug:
>http://markmail.org/message/yp7fpojnzufb5jki

Dims,

Are you implying Doug's position represents that of the TC?

I have read Doug's position, and it completely ignores Zane's assessment
of the problem at hand.

Clarity has not been reached.  I could restate the problem for you if you
like.

>
>If anyone disagrees with that position, please file a resolution.
>
>Let's stop this thread now please.


Asking for a thread to be stopped before a resolution is reached is not
the right thing.

Regards
-steve

>
>Thanks,
>Dims
>
>On Thu, Jul 28, 2016 at 3:26 PM, Steven Dake (stdake) 
>wrote:
>> Dims,
>>
>> I personally think its the responsibility of the TC to resolve this
>> problem via a resolution.  That’s why we elected you folks :)
>>
>> Regards
>> -steve
>>
>>
>> On 7/28/16, 11:09 AM, "Davanum Srinivas"  wrote:
>>
>>>Zane, Steve,
>>>
>>>I'd say go for it! Can you please write up a proposal for the TC to
>>>consider? 
>>>(https://review.openstack.org/#/q/project:openstack/governance)
>>>
>>>Thanks,
>>>-- Dims
>>>
>>>On Thu, Jul 28, 2016 at 2:01 PM, Steven Dake (stdake) 
>>>wrote:
 Jay,

 I'll be frank.  I have been receiving numerous complaints which mirror
 Zane's full second understanding of what it means to be an OpenStack
big
 tent project.  These are not just Kolla developers.  These are people
from
 all over the community.  They want something done about it.  I agree
with
 Zane if clarity is provided by the TC via a resolution, the problem
would
 disappear.  We are all adults and can live by the rules, even if we
 disagree with them.  This contract is the agreement under which
 democracies are created, and one of the most appealing properties of
 OpenStack.

 In this case there is no policy and one is obviously necessary to
avoid
 these scenarios in the future.

 The TC has four options as I see it:
 1) do nothing
 2) write a resolution mirroring Zane's first analysis
 3) write a resolution mirroring Zane's second analysis
 4) write a different resolution that is a compromise of the first
analysis
 and second analysis

 I don't wish Mirantis to state anything.  Vladimir did that (thanks
 Vladimir!).

 Regards
 -steve


 On 7/28/16, 10:30 AM, "Jay Pipes"  wrote:

>I don't see what is unclear about any of it.
>
>What exactly is it that you wish Mirantis to state?
>
>Zane says there needs to be some guidance from the TC "about what it
>means for a repo to be part of the OpenStack tent".
>
>But the fuel-ccp repos aren't listed in the governance repo, for
>reasons
>that were clearly stated by Mirantis engineers. They want to innovate
>in
>this area without all the politics that this thread exposes.
>
>Mirantis engineers have clearly laid out the technical reasons that
>Kolla doesn't fit the needs that Fuel has of these image definitions
>and
>orchestration tooling.
>
>The repos *aren't in the OpenStack tent* so how precisely would TC
>guidance about what it means for a repo to be part of the OpenStack
>tent
>be useful here?
>
>-jay
>
>On 07/28/2016 01:04 PM, Steven Dake (stdake) wrote:
>> Jay,
>>
>> That resolution doesn't clarify Zane's argument.
>>
>> Regards,
>> -steve
>>
>> On 7/28/16, 9:54 AM, "Jay Pipes"  wrote:
>>
>>> The TC has given guidance on this already:
>>>
>>>
>>>http://governance.openstack.org/resolutions/20160119-stackforge-reti
>>>re
>>>me
>>>nt
>>> .html
>>>
>>> "In order to simplify software development lifecycle transitions of
>>> Unofficial and Official OpenStack projects, all projects developed
>>> within the OpenStack project infrastructure will be permitted to
>>>use
>>>the
>>> “openstack/” namespace. The use of the term “Stackforge” to
>>>describe
>>> unofficial projects should be considered deprecated."
>>>
>>> The Fuel CCP repos are projects that are not official OpenStack
>>>projects.
>>>
>>> They are in the openstack/ git namespace because they use the
>>>common
>>> infrastructure and there isn't any formal plan to have the repos
>>>join
>>> the "official OpenStack projects" (i.e. the ones listed in the
>>> projects.yaml file in the openstack/governance repository).
>>>
>>> Could they be proposed in the future as official OpenStack
>>>projects?
>>> Maybe. Not sure, and I don't believe it's necessary to decide ahead
>>>of
>>> time.
>>>
>>> Please stop using a marketing press release as some indication of
>>>what
>>> the "intent" is for these 

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Doug Hellmann]

If it ever becomes necessary for us to pass a resolution to deal with
every disagreement, we might as well all go herd goats.

This is a very straightforward situation, which has been blown out of
all reasonable proportion through well-intentioned but misplaced
concerns.

Please, everyone, let's call it resolved.

Doug

Excerpts from Steven Dake (stdake)'s message of 2016-07-28 19:26:37 +:
> Dims,
> 
> I personally think its the responsibility of the TC to resolve this
> problem via a resolution.  That’s why we elected you folks :)
> 
> Regards
> -steve
> 
> On 7/28/16, 11:09 AM, "Davanum Srinivas"  wrote:
> 
> >Zane, Steve,
> >
> >I'd say go for it! Can you please write up a proposal for the TC to
> >consider? (https://review.openstack.org/#/q/project:openstack/governance)
> >
> >Thanks,
> >-- Dims
> >
> >On Thu, Jul 28, 2016 at 2:01 PM, Steven Dake (stdake) 
> >wrote:
> >> Jay,
> >>
> >> I'll be frank.  I have been receiving numerous complaints which mirror
> >> Zane's full second understanding of what it means to be an OpenStack big
> >> tent project.  These are not just Kolla developers.  These are people
> >>from
> >> all over the community.  They want something done about it.  I agree
> >>with
> >> Zane if clarity is provided by the TC via a resolution, the problem
> >>would
> >> disappear.  We are all adults and can live by the rules, even if we
> >> disagree with them.  This contract is the agreement under which
> >> democracies are created, and one of the most appealing properties of
> >> OpenStack.
> >>
> >> In this case there is no policy and one is obviously necessary to avoid
> >> these scenarios in the future.
> >>
> >> The TC has four options as I see it:
> >> 1) do nothing
> >> 2) write a resolution mirroring Zane's first analysis
> >> 3) write a resolution mirroring Zane's second analysis
> >> 4) write a different resolution that is a compromise of the first
> >>analysis
> >> and second analysis
> >>
> >> I don't wish Mirantis to state anything.  Vladimir did that (thanks
> >> Vladimir!).
> >>
> >> Regards
> >> -steve
> >>
> >>
> >> On 7/28/16, 10:30 AM, "Jay Pipes"  wrote:
> >>
> >>>I don't see what is unclear about any of it.
> >>>
> >>>What exactly is it that you wish Mirantis to state?
> >>>
> >>>Zane says there needs to be some guidance from the TC "about what it
> >>>means for a repo to be part of the OpenStack tent".
> >>>
> >>>But the fuel-ccp repos aren't listed in the governance repo, for reasons
> >>>that were clearly stated by Mirantis engineers. They want to innovate in
> >>>this area without all the politics that this thread exposes.
> >>>
> >>>Mirantis engineers have clearly laid out the technical reasons that
> >>>Kolla doesn't fit the needs that Fuel has of these image definitions and
> >>>orchestration tooling.
> >>>
> >>>The repos *aren't in the OpenStack tent* so how precisely would TC
> >>>guidance about what it means for a repo to be part of the OpenStack tent
> >>>be useful here?
> >>>
> >>>-jay
> >>>
> >>>On 07/28/2016 01:04 PM, Steven Dake (stdake) wrote:
>  Jay,
> 
>  That resolution doesn't clarify Zane's argument.
> 
>  Regards,
>  -steve
> 
>  On 7/28/16, 9:54 AM, "Jay Pipes"  wrote:
> 
> > The TC has given guidance on this already:
> >
> >
> >http://governance.openstack.org/resolutions/20160119-stackforge-retire
> >me
> >nt
> > .html
> >
> > "In order to simplify software development lifecycle transitions of
> > Unofficial and Official OpenStack projects, all projects developed
> > within the OpenStack project infrastructure will be permitted to use
> >the
> > “openstack/” namespace. The use of the term “Stackforge” to describe
> > unofficial projects should be considered deprecated."
> >
> > The Fuel CCP repos are projects that are not official OpenStack
> >projects.
> >
> > They are in the openstack/ git namespace because they use the common
> > infrastructure and there isn't any formal plan to have the repos join
> > the "official OpenStack projects" (i.e. the ones listed in the
> > projects.yaml file in the openstack/governance repository).
> >
> > Could they be proposed in the future as official OpenStack projects?
> > Maybe. Not sure, and I don't believe it's necessary to decide ahead
> >of
> > time.
> >
> > Please stop using a marketing press release as some indication of
> >what
> > the "intent" is for these repos or even that there *is* any intent at
> > this point. It's really early on and these repos are intended as a
> >place
> > to experiment and innovate. I don't see why there is so much anger
> >about
> > that.
> >
> > Best,
> > -jay
> >
> > On 07/28/2016 12:33 PM, Steven Dake (stdake) wrote:
> >> Doug,
> >>
> >> Zane's analysis is correct.  I agree with 

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Davanum Srinivas]

Steve,

This thread has degenerated. So my request is to use Doug's post as
status quo. If there's disagreement then file for a resolution that
suits them

-- Dims

On Thu, Jul 28, 2016 at 3:40 PM, Steven Dake (stdake)  wrote:
>
>
> On 7/28/16, 12:30 PM, "Davanum Srinivas"  wrote:
>
>>Steven,
>>
>>Please see response from Doug:
>>http://markmail.org/message/yp7fpojnzufb5jki
>
> Dims,
>
> Are you implying Doug's position represents that of the TC?
>
> I have read Doug's position, and it completely ignores Zane's assessment
> of the problem at hand.
>
> Clarity has not been reached.  I could restate the problem for you if you
> like.
>
>>
>>If anyone disagrees with that position, please file a resolution.
>>
>>Let's stop this thread now please.
>
>
> Asking for a thread to be stopped before a resolution is reached is not
> the right thing.
>
> Regards
> -steve
>
>>
>>Thanks,
>>Dims
>>
>>On Thu, Jul 28, 2016 at 3:26 PM, Steven Dake (stdake) 
>>wrote:
>>> Dims,
>>>
>>> I personally think its the responsibility of the TC to resolve this
>>> problem via a resolution.  That’s why we elected you folks :)
>>>
>>> Regards
>>> -steve
>>>
>>>
>>> On 7/28/16, 11:09 AM, "Davanum Srinivas"  wrote:
>>>
Zane, Steve,

I'd say go for it! Can you please write up a proposal for the TC to
consider?
(https://review.openstack.org/#/q/project:openstack/governance)

Thanks,
-- Dims

On Thu, Jul 28, 2016 at 2:01 PM, Steven Dake (stdake) 
wrote:
> Jay,
>
> I'll be frank.  I have been receiving numerous complaints which mirror
> Zane's full second understanding of what it means to be an OpenStack
>big
> tent project.  These are not just Kolla developers.  These are people
>from
> all over the community.  They want something done about it.  I agree
>with
> Zane if clarity is provided by the TC via a resolution, the problem
>would
> disappear.  We are all adults and can live by the rules, even if we
> disagree with them.  This contract is the agreement under which
> democracies are created, and one of the most appealing properties of
> OpenStack.
>
> In this case there is no policy and one is obviously necessary to
>avoid
> these scenarios in the future.
>
> The TC has four options as I see it:
> 1) do nothing
> 2) write a resolution mirroring Zane's first analysis
> 3) write a resolution mirroring Zane's second analysis
> 4) write a different resolution that is a compromise of the first
>analysis
> and second analysis
>
> I don't wish Mirantis to state anything.  Vladimir did that (thanks
> Vladimir!).
>
> Regards
> -steve
>
>
> On 7/28/16, 10:30 AM, "Jay Pipes"  wrote:
>
>>I don't see what is unclear about any of it.
>>
>>What exactly is it that you wish Mirantis to state?
>>
>>Zane says there needs to be some guidance from the TC "about what it
>>means for a repo to be part of the OpenStack tent".
>>
>>But the fuel-ccp repos aren't listed in the governance repo, for
>>reasons
>>that were clearly stated by Mirantis engineers. They want to innovate
>>in
>>this area without all the politics that this thread exposes.
>>
>>Mirantis engineers have clearly laid out the technical reasons that
>>Kolla doesn't fit the needs that Fuel has of these image definitions
>>and
>>orchestration tooling.
>>
>>The repos *aren't in the OpenStack tent* so how precisely would TC
>>guidance about what it means for a repo to be part of the OpenStack
>>tent
>>be useful here?
>>
>>-jay
>>
>>On 07/28/2016 01:04 PM, Steven Dake (stdake) wrote:
>>> Jay,
>>>
>>> That resolution doesn't clarify Zane's argument.
>>>
>>> Regards,
>>> -steve
>>>
>>> On 7/28/16, 9:54 AM, "Jay Pipes"  wrote:
>>>
 The TC has given guidance on this already:


http://governance.openstack.org/resolutions/20160119-stackforge-reti
re
me
nt
 .html

 "In order to simplify software development lifecycle transitions of
 Unofficial and Official OpenStack projects, all projects developed
 within the OpenStack project infrastructure will be permitted to
use
the
 “openstack/” namespace. The use of the term “Stackforge” to
describe
 unofficial projects should be considered deprecated."

 The Fuel CCP repos are projects that are not official OpenStack
projects.

 They are in the openstack/ git namespace because they use the
common
 infrastructure and there isn't any formal plan to have the repos
join
 the "official OpenStack projects" (i.e. 

[openstack-dev] [octavia]redirection and barbican config

[Akshay Kumar Sanghai]

Hi,
I have a couple on questions on octavia. Please answer or redirect me to
relevant documentation:
- Assume listener is listening on 443 and client hits the vip on port 80,
the connection will be refused.  Is it possible to configure http to https
direction?

- For the barbican config, the only config item i can find is
cert_manager_type in neutron_lbaas.conf. How do we configure the barbican
access for lbaas. I assume since we do the access config for nova and
keystone in neutron.conf, there should be some config file where we define
the barbican access(username, password, auth_url).

The community has been very helpful to me. Thanks a lot Guys. Appreciate
your efforts.

Thanks
Akshay Sanghai
__
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] [placement] unresolved topics in resource providers/placement api

[Jay Pipes]

On 07/28/2016 02:10 PM, Chris Dent wrote:

On Thu, 28 Jul 2016, Jay Pipes wrote:


* There was some discussion of adding a configuration setting (e.g.
  'placement_connection') that if not None (the default) would be
  used as the connection for the placement database. If None, the
  API database would be used. I can't recall if we said 'yea' or
  'nay' to this idea. The current code uses the api database and its
  config.


The decision at the mid-cycle was to add a new
placement_sql_connection configuration option to the nova.conf. The
default value would be None which would mean the code in
nova/objects/resource_provider.py would default to using the API
database setting.


Roger that. I was pretty sure that was what we decided but wanted to
confirm as unless I'm mistaken it is a considerable change.

As I understand things it means:

* integrating however much of Roman's WIP at
  https://review.openstack.org/#/c/342384/ is required (we need our
  own copies of the models and migrations and a manage script to do
  a db-sync, yes?)
* adding the config setting
* doing the creation of the correct transaction context dependent on
  that config
* adding the new db into the existing nova.fixtures so the tests can work
* reno note


The above matches my understanding and expectations, yes.


Do we want to test against both configurations?


Not sure. If you're asking whether we should have separate gate jobs 
that pass None and a not-None-not-same-as-API-DB value for 
placement_sql_connection, I don't think that's necessary. A single 
functional test that sets placement_sql_connection to a 
not-None-not-API-DB value and verifies that data is written to a 
database other than the API database would be acceptable to me.



# less straightforward and further out things


[snip]


This will be in Ocata.


Sorry if I wasn't clear about this. By "further out" I meant "not
newton". I'll spin off an adjacent thread to deal with any followups
on these parts. I think it is useful to keep the conversation
flowing on these topics, especially after all the input and
discussion at the mid-cycle.


Ack, and thanks :)

Best,
-jay

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

[openstack-dev] [nova] [placement] *future* topics in resource providers/placement api

[Chris Dent]

Note: I've changed the subject to make it clear that this thread is
about topics related to resource providers and the placement API
that are not relevant to newton. Ideas that we need to be chewing on
but not things that need to solved now.

On Thu, 28 Jul 2016, Roman Podoliaka wrote:

I'd personally prefer the latter. I don't think placement api will be
able to implement all the filters we currently have in
FilterScheduler.

How about we do a query in two steps:

1) take a list of compute nodes (== resource providers) and apply all
the filters which *can not* (or *are not* at some point) be
implemented in placement-api

2) POST a launch request passing the *pre-filtered* list of resource
providers.  placement api will pick one of those RP, *claim* its
resources and return the claim info


While I think the ordering you describe might be useful in the use case
that Ed has described in his message, I think for the general case it is
backwards. We should use the placement API _first_ to winnow out those
hosts that physically cannot satisfy the basic requirements for
inventory of the standard resource classes and then pass that simplified
list to the filters. That ought to be efficient and also provides a path
for easy migration of those filters that can be implemented cleanly in
the placement engine.

--
Chris Dent   ┬─┬ノ( º _ ºノ) http://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Jay Pipes]

How would guidance from the TC about what it means for a repo to be 
"part of the OpenStack tent" add clarity for repos that are not trying 
to be part of the OpenStack tent?


Just curious here...

-jay

On 07/28/2016 02:01 PM, Steven Dake (stdake) wrote:

Jay,

I'll be frank.  I have been receiving numerous complaints which mirror
Zane's full second understanding of what it means to be an OpenStack big
tent project.  These are not just Kolla developers.  These are people from
all over the community.  They want something done about it.  I agree with
Zane if clarity is provided by the TC via a resolution, the problem would
disappear.  We are all adults and can live by the rules, even if we
disagree with them.  This contract is the agreement under which
democracies are created, and one of the most appealing properties of
OpenStack.

In this case there is no policy and one is obviously necessary to avoid
these scenarios in the future.

The TC has four options as I see it:
1) do nothing
2) write a resolution mirroring Zane's first analysis
3) write a resolution mirroring Zane's second analysis
4) write a different resolution that is a compromise of the first analysis
and second analysis

I don't wish Mirantis to state anything.  Vladimir did that (thanks
Vladimir!).

Regards
-steve


On 7/28/16, 10:30 AM, "Jay Pipes"  wrote:


I don't see what is unclear about any of it.

What exactly is it that you wish Mirantis to state?

Zane says there needs to be some guidance from the TC "about what it
means for a repo to be part of the OpenStack tent".

But the fuel-ccp repos aren't listed in the governance repo, for reasons
that were clearly stated by Mirantis engineers. They want to innovate in
this area without all the politics that this thread exposes.

Mirantis engineers have clearly laid out the technical reasons that
Kolla doesn't fit the needs that Fuel has of these image definitions and
orchestration tooling.

The repos *aren't in the OpenStack tent* so how precisely would TC
guidance about what it means for a repo to be part of the OpenStack tent
be useful here?

-jay

On 07/28/2016 01:04 PM, Steven Dake (stdake) wrote:

Jay,

That resolution doesn't clarify Zane's argument.

Regards,
-steve

On 7/28/16, 9:54 AM, "Jay Pipes"  wrote:


The TC has given guidance on this already:


http://governance.openstack.org/resolutions/20160119-stackforge-retireme
nt
.html

"In order to simplify software development lifecycle transitions of
Unofficial and Official OpenStack projects, all projects developed
within the OpenStack project infrastructure will be permitted to use
the
“openstack/” namespace. The use of the term “Stackforge” to describe
unofficial projects should be considered deprecated."

The Fuel CCP repos are projects that are not official OpenStack
projects.

They are in the openstack/ git namespace because they use the common
infrastructure and there isn't any formal plan to have the repos join
the "official OpenStack projects" (i.e. the ones listed in the
projects.yaml file in the openstack/governance repository).

Could they be proposed in the future as official OpenStack projects?
Maybe. Not sure, and I don't believe it's necessary to decide ahead of
time.

Please stop using a marketing press release as some indication of what
the "intent" is for these repos or even that there *is* any intent at
this point. It's really early on and these repos are intended as a
place
to experiment and innovate. I don't see why there is so much anger
about
that.

Best,
-jay

On 07/28/2016 12:33 PM, Steven Dake (stdake) wrote:

Doug,

Zane's analysis is correct.  I agree with Zane's assessment that TC
clarification can solve this situation.

Regards
-steve

On 7/28/16, 9:15 AM, "Zane Bitter"  wrote:


On 28/07/16 08:48, Vladimir Kozhukalov wrote:

Fuel-ccp repositories are public, everyone is welcome to
participate.
I
don¹t see where we violate ³4 opens². These repos are now
experimental.
At the moment the team is working on building CI pipeline and
developing
functional tests that are to be run as a part of CI process. These
repos
are not to be a part of Fuel Newton release. From time to time we
add
and retire git repos and it is a part of development process. Not
all
these repos are to become a part of Big tent.


It seems to me that there are two different interpretations of what
it
means for a repo to be part of the OpenStack tent, and that these
differing interpretations are at the root of the arguments in this
thread.

The first interpretation is that repos listed as belonging to a team
in
the governance repo are part of a deliverable that is released each
development cycle, and that the same team may also control other
repos
that are not deliverables and hence not part of OpenStack. It's easy
to
see how people could have developed this interpretation in good
faith.

The second interpretation is that the TC blesses a team; that the
only
criterion for 

Re: [openstack-dev] FPGA as a dynamic nested resources

[Jay Pipes]

On 07/20/2016 05:07 AM, Daniel P. Berrange wrote:

For FPGA, I'd like to see an initial proposal that assumed the FPGA
is pre-programmed & pre-divided into a fixed number of slots and simply
deal with this.


For the record, this is precisely what is described in the first version 
of the dynamic-resource-classes use cases section:


https://review.openstack.org/#/c/312696/1/specs/newton/approved/resource-providers-dynamic-resource-classes.rst

See starting at line 193.

This level of details was removed in the second revision of the spec, 
which simply focuses on the CRUD operations to add to the placement REST 
API for these user-defined resource classes.


All the 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] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Davanum Srinivas]

Zane,

There's a Spec, Spec was discussed in Weekly Meeting. There's traffic
on the ML. I personally was helpful to some extent with the beginnning
of kolla-kubernetes.

So i don't think it's a lack of communication that's to blame.

Also if you see the repos, there's not much there... In effect they
are starting from scratch knowingly.

But if you wish as i said before, please do file a TC resolution and
let's see where it goes.

As Steven said before "We are all adults and can live by the rules,
even if we disagree with them"

Thanks,
Dims

On Thu, Jul 28, 2016 at 2:29 PM, Zane Bitter  wrote:
> On 28/07/16 12:54, Jay Pipes wrote:
>>
>> The TC has given guidance on this already:
>>
>>
>> http://governance.openstack.org/resolutions/20160119-stackforge-retirement.html
>>
>>
>> "In order to simplify software development lifecycle transitions of
>> Unofficial and Official OpenStack projects, all projects developed
>> within the OpenStack project infrastructure will be permitted to use the
>> “openstack/” namespace. The use of the term “Stackforge” to describe
>> unofficial projects should be considered deprecated."
>
>
> The word "project" has unfortunately had multiple meanings throughout the
> history of OpenStack (I think it's something to do with multitenancy this
> week, right?), so to be clear: when I say 'project' here I mean in the sense
> of 'team'.
>
> So I believe it's quite clear that there are official projects with official
> repos and unofficial projects with unofficial repos, and that all of these
> repos are hosted in the openstack/* namespace. (Nobody in the thread has
> raised the namespacing as an issue AFAICT.)
>
> What's not clear is whether official projects should have unofficial repos.
> I submit that if that _were_ clear then this thread would never have existed
> and we would all be happier :)
>
>> The Fuel CCP repos are projects that are not official OpenStack projects.
>
>
> Because of the aforementioned 'project' pun issue there's two ways of
> interpreting this. You may be saying that the repos are unofficial repos
> within the "Fuel" project (team), in which case the question of whether
> official projects should have unofficial repos applies.
>
> Alternatively, you may be saying that the "Fuel CCP" project (team) is an
> unofficial project separate from the "Fuel" project (team), with it's own
> (naturally unofficial) repos, and that therefore the question of whether
> official projects should have unofficial repos is moot. In which case I
> think you at least have to forgive people for being confused ;)
>
>> They are in the openstack/ git namespace because they use the common
>> infrastructure and there isn't any formal plan to have the repos join
>> the "official OpenStack projects" (i.e. the ones listed in the
>> projects.yaml file in the openstack/governance repository).
>>
>> Could they be proposed in the future as official OpenStack projects?
>> Maybe. Not sure, and I don't believe it's necessary to decide ahead of
>> time.
>>
>> Please stop using a marketing press release as some indication of what
>> the "intent" is for these repos or even that there *is* any intent at
>> this point. It's really early on and these repos are intended as a place
>> to experiment and innovate. I don't see why there is so much anger about
>> that.
>
>
> My only interest here is to try to help two groups that are clearly not
> communicating very well to communicate better. TBH I don't think your
> response was as helpful to those ends as it could have been. Can we start
> again?
>
> cheers,
> Zane.
>
>
>> Best,
>> -jay
>>
>> On 07/28/2016 12:33 PM, Steven Dake (stdake) wrote:
>>>
>>> Doug,
>>>
>>> Zane's analysis is correct.  I agree with Zane's assessment that TC
>>> clarification can solve this situation.
>>>
>>> Regards
>>> -steve
>>>
>>> On 7/28/16, 9:15 AM, "Zane Bitter"  wrote:
>>>
 On 28/07/16 08:48, Vladimir Kozhukalov wrote:
>
> Fuel-ccp repositories are public, everyone is welcome to participate. I
> don¹t see where we violate ³4 opens². These repos are now experimental.
> At the moment the team is working on building CI pipeline and
> developing
> functional tests that are to be run as a part of CI process. These
> repos
> are not to be a part of Fuel Newton release. From time to time we add
> and retire git repos and it is a part of development process. Not all
> these repos are to become a part of Big tent.


 It seems to me that there are two different interpretations of what it
 means for a repo to be part of the OpenStack tent, and that these
 differing interpretations are at the root of the arguments in this
 thread.

 The first interpretation is that repos listed as belonging to a team in
 the governance repo are part of a deliverable that is released each
 development cycle, and that the same team may also control other repos
 that are not 

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Zane Bitter]

On 28/07/16 14:20, Jay Pipes wrote:

How would guidance from the TC about what it means for a repo to be
"part of the OpenStack tent" add clarity for repos that are not trying
to be part of the OpenStack tent?


If it were clear what it means for a repo to be "part of the OpenStack 
tent" then it would be obvious to *everyone* which ones should be and 
which ones should not. As it is there are two different interpretations 
from which follow two different conclusions as to whether the Right 
Thing(TM) is happening, causing unnecessary wailing and gnashing of 
teeth. Please re-read my original message on this subject for a full 
treatment.


cheers,
Zane.

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

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Michał Jastrzębski]

Hello,

So as some of you might know, I write from a peculiar position. I'm
both Kolla core and Intel.

I don't like to see where this thread is going to. We are all one
community, we are all OpenStack after all. I think what's hurting us
here is this sense of competition. I would like to share my personal
view on that matter.

Competition is good thing. Let the best one win and therefore make
whole OpenStack namespace a slightly better place overall. However
what I'd hate to see is to silo ourselves and don't talk to each
other. We, Kolla and Fuel, are trying to solve very similar problem
(openstack deployment) in a very similar way (docker containers on top
of kubernetes). This makes us vulnerable to both competing and
knowledge silo, but that also gives us opportunity to cooperate.
Regardless of decision you guys (Mirantis) make, I would like to
encourage you to share your findings and feedback regarding OpenStack
in Docker on top of Kubernetes with Kolla. We will do the same for
you. As I said before, to me it's not us vs you, it's both of us
trying to improve experience of OpenStack.

That being said, I'm glad to hear from you, Sergey, that you're not
ruling out using Kolla as carrier for containers. I know we have few
points we need to discuss, but that's what we should do, discuss. Make
sure that we're splitting community for a reason and there is
something fundamental that would prevent us from closer cooperation.

I understand that Fuel is center of business for Mirantis, and adding
dependency for non-Mirantis driven project is a huge risk and it's not
a decision taken lightly. To that, I'll say that Nova is not a
Mirantis-driven project as well, which means you already do this, this
is just one step further.

Uff..long mail.

TLDR: Even if you want to have completely separate project, that's
cool, just let's make sure to talk so our collective experience will
improve both projects.

I hope this makes sense?

Cheers,
Michal


On 28 July 2016 at 13:29, Zane Bitter  wrote:
> On 28/07/16 12:54, Jay Pipes wrote:
>>
>> The TC has given guidance on this already:
>>
>>
>> http://governance.openstack.org/resolutions/20160119-stackforge-retirement.html
>>
>>
>> "In order to simplify software development lifecycle transitions of
>> Unofficial and Official OpenStack projects, all projects developed
>> within the OpenStack project infrastructure will be permitted to use the
>> “openstack/” namespace. The use of the term “Stackforge” to describe
>> unofficial projects should be considered deprecated."
>
>
> The word "project" has unfortunately had multiple meanings throughout the
> history of OpenStack (I think it's something to do with multitenancy this
> week, right?), so to be clear: when I say 'project' here I mean in the sense
> of 'team'.
>
> So I believe it's quite clear that there are official projects with official
> repos and unofficial projects with unofficial repos, and that all of these
> repos are hosted in the openstack/* namespace. (Nobody in the thread has
> raised the namespacing as an issue AFAICT.)
>
> What's not clear is whether official projects should have unofficial repos.
> I submit that if that _were_ clear then this thread would never have existed
> and we would all be happier :)
>
>> The Fuel CCP repos are projects that are not official OpenStack projects.
>
>
> Because of the aforementioned 'project' pun issue there's two ways of
> interpreting this. You may be saying that the repos are unofficial repos
> within the "Fuel" project (team), in which case the question of whether
> official projects should have unofficial repos applies.
>
> Alternatively, you may be saying that the "Fuel CCP" project (team) is an
> unofficial project separate from the "Fuel" project (team), with it's own
> (naturally unofficial) repos, and that therefore the question of whether
> official projects should have unofficial repos is moot. In which case I
> think you at least have to forgive people for being confused ;)
>
>> They are in the openstack/ git namespace because they use the common
>> infrastructure and there isn't any formal plan to have the repos join
>> the "official OpenStack projects" (i.e. the ones listed in the
>> projects.yaml file in the openstack/governance repository).
>>
>> Could they be proposed in the future as official OpenStack projects?
>> Maybe. Not sure, and I don't believe it's necessary to decide ahead of
>> time.
>>
>> Please stop using a marketing press release as some indication of what
>> the "intent" is for these repos or even that there *is* any intent at
>> this point. It's really early on and these repos are intended as a place
>> to experiment and innovate. I don't see why there is so much anger about
>> that.
>
>
> My only interest here is to try to help two groups that are clearly not
> communicating very well to communicate better. TBH I don't think your
> response was as helpful to those ends as it could have been. Can we start
> again?
>
> 

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Andreas Jaeger]

On 07/28/2016 07:21 PM, Doug Hellmann wrote:
> [...]
> I think it is a reasonable expectation that teams would want to add
> their new repositories to the governance list to have the rights
> that go along with that, but I'm not aware of any requirement that
> they do so.

Reviewing that change that added the repos, I was struggling with these
interpretations myself.

Here's a team that creates a spec that states they want to develop
certain parts outside of the big tent and seem to work as team on it
(so, much that their marketing believes it;) - a team that is part of
the big tent.

AFAIU, they could have easily opted on adding these repos to their
project and do the same kind of experimentation that they are doing now
as "stackforge" repos.

Most teams are happy to have their new repos as part of the big tent -
let's leave the Neutron stadium out for now which showed some of the
limits for this.

Being part of the Big tent has some advantages - but I did not
understand what kind of advantages it brings the team to have these
repos outside of the big tent.

But it's not my call to make how they do it, and thus I reviewed
positively - I just got the impression that either we have different
understandings on what it means that repos are in the big tent or not -
or I'm missing some information.

If there're any advantages or disadvantages or considerating regarding
the big tent for teams to add repos that I miss, I'd like to be aware of
them so that I can give guidance during project-config review,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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][nova] Globally disabling hw_qemu_guest_agent support

[Tim Bell]

Looking at the number of options for image properties, it would seem that a 
blacklist would be in order. I would be in favour for ‘standard’ images which 
support fsfreeze to support guest agent and that some of the NUMA properties 
not be available for end user images, but still for system ones.

How about a list of delegated properties for images which could override the 
default flavor settings ?

Tim

On 20/07/16 00:40, "Daniel Russell"  wrote:

Hi Daniel,

Fair enough.  I don't personally understand your stance against having a 
configuration option to specifically disable guest agent but imagine there 
would be advantages to having a more generic implementation that can handle 
more use-cases (any property instead of just a specific property).  I imagine 
there will need to be a nova scheduler component to it as well (Or we might 
schedule an instance on a hypervisor that is configured not to allow it).

Is there a blueprint or spec for this kind of thing yet?  I can help put one 
together if there is interest but the implementation is probably for more 
seasoned developers.

Regards,
Dan.

-Original Message-
From: Daniel P. Berrange [mailto:berra...@redhat.com] 
Sent: Tuesday, 19 July 2016 6:39 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [glance][nova] Globally disabling 
hw_qemu_guest_agent support

On Tue, Jul 19, 2016 at 12:51:07AM +, Daniel Russell wrote:
> Hi Erno,
> 
> For the size of team I am in I think it would work well but it feels 
> like I am putting the security of Nova in the hands of Glance.

Yep, from an architectural pov it is not very good. Particularly in a 
multi-hypervisor compute deployment you can have the situation where yoyu want 
to allow a property for one type of hypervisor but forbid it for another.

What we really need is the exact same image property security restrictions 
implemented by nova-compute, so we can setup compute nodes to blacklist certain 
properties.

> 
> What I was more after was a setting in Nova that says 'this hypervisor 
> does not allow guest sockets and will ignore any attempt to create 
> them', 'this hypervisor always creates guest sockets regardless of 
> your choice', 'this hypervisor will respect whatever you throw in 
> hw_qemu_guest_agent with a default of no', or 'this hypervisor will 
> respect whatever you throw in hw_qemu_guest_agent with a default of 
> yes'.  It feels like a more appropriate place to control and manage that kind 
> of configuration.

Nope, there's no such facility right now - glance property protection is the 
only real option. I'd be very much against adding a lockdown which was specific 
to the guest agent too - if we did anything it would be to have a generic 
property protection model in nova that mirrors what glance supports.

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

__
OpenStack 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] [Neutron] SFC stable/mitaka version

[Cathy Zhang]

Hi Ihar and all,

Yes, we have been preparing for such a release. We will do one more round of 
testing to make sure everything works fine, and then I will submit the release 
request. 
There is a new patch on "stadium: adopt openstack/releases in subproject 
release process" which is not Merged yet. 
Shall I follow this 
http://docs.openstack.org/developer/neutron/stadium/sub_project_guidelines.html#sub-project-release-process
 to submit the request? 
Do you have a good bug example for Neutron sub-project release request?  

BTW, a functional and tempest patch for networking-sfc has been uploaded and it 
might take some time for the team to complete the review. The test is 
non-voting. Do you think we should wait until this patch is merged or release 
can be done without it? 

Thanks,
Cathy

-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] 
Sent: Wednesday, July 27, 2016 1:24 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] SFC stable/mitaka version

Tony Breeds  wrote:

> On Wed, Jul 06, 2016 at 12:40:48PM +, Gary Kotton wrote:
>> Hi,
>> Is anyone looking at creating a stable/mitaka version? What if 
>> someone want to use this for stable/mitaka?
>
> If that's a thing you need it's a matter of Armando asking the release 
> managers to create it.

I only suggest Armando is not dragged into it, the release liaison (currently 
me) should be able to handle the request if it comes from the core team for the 
subproject.

Ihar

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

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Jim Rollenhagen]

On Thu, Jul 28, 2016 at 02:29:18PM -0400, Zane Bitter wrote:
> On 28/07/16 12:54, Jay Pipes wrote:
> >The TC has given guidance on this already:
> >
> >http://governance.openstack.org/resolutions/20160119-stackforge-retirement.html
> >
> >
> >"In order to simplify software development lifecycle transitions of
> >Unofficial and Official OpenStack projects, all projects developed
> >within the OpenStack project infrastructure will be permitted to use the
> >“openstack/” namespace. The use of the term “Stackforge” to describe
> >unofficial projects should be considered deprecated."
> 
> The word "project" has unfortunately had multiple meanings throughout the
> history of OpenStack (I think it's something to do with multitenancy this
> week, right?), so to be clear: when I say 'project' here I mean in the sense
> of 'team'.
> 
> So I believe it's quite clear that there are official projects with official
> repos and unofficial projects with unofficial repos, and that all of these
> repos are hosted in the openstack/* namespace. (Nobody in the thread has
> raised the namespacing as an issue AFAICT.)
> 
> What's not clear is whether official projects should have unofficial repos.
> I submit that if that _were_ clear then this thread would never have existed
> and we would all be happier :)

Well, that does happen today, just as a note:
https://git.openstack.org/cgit/openstack/ironic-staging-drivers

This is a bunch of out-of-tree drivers that a few Ironic developers
support, because Ironic is beginning to require third-party CI on
in-tree drivers.

As mentioned elsewhere, the Neutron stadium has many repos in and out of
the Neutron governance and the big tent.

So I'm curious, if we say "official projects should never have unofficial
repos", where that bar would be. Is it that the repo is not worked on by
the PTL? Some percent of core reviewers? Some percent of active
developers? Has the name in it?

If we make a rule that doesn't fit some unofficial repo, people will
either 1) work around the rule, or 2) put it on Github. Both of those
are (IMO) not any better for the community than having some unofficial
repo related to an official project.

(Oh, there's another worse outcome: the repo becomes proprietary
instead.)

// jim

> >The Fuel CCP repos are projects that are not official OpenStack projects.
> 
> Because of the aforementioned 'project' pun issue there's two ways of
> interpreting this. You may be saying that the repos are unofficial repos
> within the "Fuel" project (team), in which case the question of whether
> official projects should have unofficial repos applies.
> 
> Alternatively, you may be saying that the "Fuel CCP" project (team) is an
> unofficial project separate from the "Fuel" project (team), with it's own
> (naturally unofficial) repos, and that therefore the question of whether
> official projects should have unofficial repos is moot. In which case I
> think you at least have to forgive people for being confused ;)
> 
> >They are in the openstack/ git namespace because they use the common
> >infrastructure and there isn't any formal plan to have the repos join
> >the "official OpenStack projects" (i.e. the ones listed in the
> >projects.yaml file in the openstack/governance repository).
> >
> >Could they be proposed in the future as official OpenStack projects?
> >Maybe. Not sure, and I don't believe it's necessary to decide ahead of
> >time.
> >
> >Please stop using a marketing press release as some indication of what
> >the "intent" is for these repos or even that there *is* any intent at
> >this point. It's really early on and these repos are intended as a place
> >to experiment and innovate. I don't see why there is so much anger about
> >that.
> 
> My only interest here is to try to help two groups that are clearly not
> communicating very well to communicate better. TBH I don't think your
> response was as helpful to those ends as it could have been. Can we start
> again?
> 
> cheers,
> Zane.
> 
> >Best,
> >-jay
> >
> >On 07/28/2016 12:33 PM, Steven Dake (stdake) wrote:
> >>Doug,
> >>
> >>Zane's analysis is correct.  I agree with Zane's assessment that TC
> >>clarification can solve this situation.
> >>
> >>Regards
> >>-steve
> >>
> >>On 7/28/16, 9:15 AM, "Zane Bitter"  wrote:
> >>
> >>>On 28/07/16 08:48, Vladimir Kozhukalov wrote:
> Fuel-ccp repositories are public, everyone is welcome to participate. I
> don¹t see where we violate ³4 opens². These repos are now experimental.
> At the moment the team is working on building CI pipeline and
> developing
> functional tests that are to be run as a part of CI process. These
> repos
> are not to be a part of Fuel Newton release. From time to time we add
> and retire git repos and it is a part of development process. Not all
> these repos are to become a part of Big tent.
> >>>
> >>>It seems to me that there are two different interpretations of what it
> >>>means for a repo to be 

Re: [openstack-dev] [neutron][api] Passing random filters on neutron API calls

[Brandon Logan]

On Thu, 2016-07-28 at 19:24 +0200, Ihar Hrachyshka wrote:
> Kevin Benton  wrote:
> 
> > Too late. That's a backwards incompatible change that can mess with  
> > clients putting on cache busting nonce tokens and who knows what else.
> 
> Ideally, API layer would at least avoid passing those unknown filters into  
> plugins; same for plugins returning random fields: API layer should filter  
> unknown data out. We already have attribute maps defined for extensions, so  
> it should be relatively easy to implement that without making plugin layer  
> forgiving to those kinds of requests.
> 
> Ihar

This is possible for most resources, but the resources that use member
actions do not have those attributes mapped out I don't believe so there
won't be a generic way to do this for those.  There aren't many of those
though.  The other one is the extensions that define their own
controllers, like agent reschedulers.  That can be modified in the
controllers themselves though and wouldn't be too big of a deal.

> 
> __
> 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] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Zane Bitter]

On 28/07/16 14:38, Davanum Srinivas wrote:

Zane,


I don't understand why you're directing this reply to me. I *just* made 
clear that I don't have any interest one way or the other.



There's a Spec, Spec was discussed in Weekly Meeting. There's traffic
on the ML. I personally was helpful to some extent with the beginnning
of kolla-kubernetes.

So i don't think it's a lack of communication that's to blame.


AFAICT this has nothing to do with my point that this thread is a *train 
wreck* where everyone is talking past each other.


Also at no time did I ever refer to a "lack of communication".


Also if you see the repos, there's not much there... In effect they
are starting from scratch knowingly.


As I said, I don't have a horse in this race and I don't actually care. 
I'm just trying to explain each side's position to the other in the hope 
that they'll stop arguing.



But if you wish as i said before, please do file a TC resolution and
let's see where it goes.


I wouldn't know which one to file (although Doug's response suggests 
it's interpretation 1). Besides, I already did my good deed for the day 
and got attacked for my trouble.



As Steven said before "We are all adults and can live by the rules,
even if we disagree with them"


I don't even disagree with *either* rule. I'm merely trying to point out 
that different but unexamined opinions on what the rule is leads to bad 
discussions.


cheers,
Zane.


Thanks,
Dims

On Thu, Jul 28, 2016 at 2:29 PM, Zane Bitter  wrote:

On 28/07/16 12:54, Jay Pipes wrote:


The TC has given guidance on this already:


http://governance.openstack.org/resolutions/20160119-stackforge-retirement.html


"In order to simplify software development lifecycle transitions of
Unofficial and Official OpenStack projects, all projects developed
within the OpenStack project infrastructure will be permitted to use the
“openstack/” namespace. The use of the term “Stackforge” to describe
unofficial projects should be considered deprecated."



The word "project" has unfortunately had multiple meanings throughout the
history of OpenStack (I think it's something to do with multitenancy this
week, right?), so to be clear: when I say 'project' here I mean in the sense
of 'team'.

So I believe it's quite clear that there are official projects with official
repos and unofficial projects with unofficial repos, and that all of these
repos are hosted in the openstack/* namespace. (Nobody in the thread has
raised the namespacing as an issue AFAICT.)

What's not clear is whether official projects should have unofficial repos.
I submit that if that _were_ clear then this thread would never have existed
and we would all be happier :)


The Fuel CCP repos are projects that are not official OpenStack projects.



Because of the aforementioned 'project' pun issue there's two ways of
interpreting this. You may be saying that the repos are unofficial repos
within the "Fuel" project (team), in which case the question of whether
official projects should have unofficial repos applies.

Alternatively, you may be saying that the "Fuel CCP" project (team) is an
unofficial project separate from the "Fuel" project (team), with it's own
(naturally unofficial) repos, and that therefore the question of whether
official projects should have unofficial repos is moot. In which case I
think you at least have to forgive people for being confused ;)


They are in the openstack/ git namespace because they use the common
infrastructure and there isn't any formal plan to have the repos join
the "official OpenStack projects" (i.e. the ones listed in the
projects.yaml file in the openstack/governance repository).

Could they be proposed in the future as official OpenStack projects?
Maybe. Not sure, and I don't believe it's necessary to decide ahead of
time.

Please stop using a marketing press release as some indication of what
the "intent" is for these repos or even that there *is* any intent at
this point. It's really early on and these repos are intended as a place
to experiment and innovate. I don't see why there is so much anger about
that.



My only interest here is to try to help two groups that are clearly not
communicating very well to communicate better. TBH I don't think your
response was as helpful to those ends as it could have been. Can we start
again?

cheers,
Zane.



Best,
-jay

On 07/28/2016 12:33 PM, Steven Dake (stdake) wrote:


Doug,

Zane's analysis is correct.  I agree with Zane's assessment that TC
clarification can solve this situation.

Regards
-steve

On 7/28/16, 9:15 AM, "Zane Bitter"  wrote:


On 28/07/16 08:48, Vladimir Kozhukalov wrote:


Fuel-ccp repositories are public, everyone is welcome to participate. I
don¹t see where we violate ³4 opens². These repos are now experimental.
At the moment the team is working on building CI pipeline and
developing
functional tests that are to be run as a part of CI process. These
repos
are not to be a 

Re: [openstack-dev] [Magnum] Microversioning implementation

[Hongbin Lu]

OK. My replies are inline.

> -Original Message-
> From: Grant, Jaycen V [mailto:jaycen.v.gr...@intel.com]
> Sent: July-28-16 2:31 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Magnum] Microversioning implementation
> 
> I was completely unaware of any discussion of Semantic Versioning.
> That was brought up by Eli Qiao in the code review, so he might be the
> one to point us in the right direction for that.
> 
> Jaycen
> 
> -Original Message-
> From: Hongbin Lu [mailto:hongbin...@huawei.com]
> Sent: Thursday, July 28, 2016 11:10 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Magnum] Microversioning implementation
> 
> Added this to the agenda of next team meeting [1].
> 
> I would like to ask clarification for " the community are discussing to
> using Semantic Versioning(X.Y.Z) instead of microversion X.Y ". Could
> anyone provide more information about that?
> 
> Best regards,
> Hongbin
> 
> > -Original Message-
> > From: Grant, Jaycen V [mailto:jaycen.v.gr...@intel.com]
> > Sent: July-28-16 10:52 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: [openstack-dev] [Magnum] Microversioning implementation
> >
> >
> > There has been a discussion around micro versioning implementation
> > going on in the following patch:
> > https://review.openstack.org/#/c/343060/8 and I was asked to bring it
> > to the mailing list for further discussion.
> >
> > Magnum added header support for microversioning according to the
> > Openstack spec[1] but since we haven’t had any changes yet it was not
> > being used.  In the patch mentioned above I added code that provides
> > infrastructure for implementing micro versions for our API methods.
> I
> > took the idea from how Nova implemented micro versioning and used
> some
> > of their code modified to work with Pecan.  The basic idea is that
> you
> > version a method using api_version decorator as shown below:
> >
> > @base.Controller.api_version("1.1")
> > @expose.expose(BayCollection, types.uuid)
> > def get_all(self, marker=None):
> > """Retrieve a list of bays.
> > # code for version 1.1
> >
> > @base.Controller.api_version(“1.2”, “1.3")
> > @expose.expose(BayCollection,
> > types.uuid) def get_all(self, marker=None):
> > """Retrieve a list of bays.
> > # code for versions 1.2 through 1.3
> >
> > @base.Controller.api_version("1.4")
> > @expose.expose(BayCollection, types.uuid) def get_all(self,
> > marker=None):
> > """Retrieve a list of bays.
> > # code for version 1.4 to latest version
> >
> >
> > The api_version code takes care of selecting the correct version
> based
> > on version requested in the header. It also checks for version
> > overlaps in the methods and gaps in the method versions.
> >
> >
> > While working on this Vijendar(working on the first api changes that
> > need api versioning) and myself, evaluated several other alternatives:
> >
> > 1) Just have each method check the version object and handle the
> > differences. This was the most basic solution and will work but we
> > were concerned it would add a lot of duplicate code. We were also
> > concerned it would be messy in the future as more and more micro
> > versions were added. Each method would now be responsible for
> > additional checking and more places to change code if there were
> > overall micro version code changes in the future.
> >
> > 2) Separate pecan controllers for each micro version. When a new
> micro
> > version is added a new controller would be created inheriting from
> the
> > previous version controller. The new controller would override the
> > modified methods. Routing changes would be added to make sure that
> the
> > correct controller was used depending on the API header.  We felt
> that
> > the api_version decorator was slightly less complicated and less code
> > overhead on each api version change.
> >
> > I’d appreciate feedback on whether this is the right way to go or if
> > it would be better to go to alternative option 1 or 2. Here were some
> > of the concerns by one of the cores in the code review:
> >
> > I don't accept this patch, mark it as -2:
> > Reason:
> > 1. we have already support microversion in our code base, and
> your
> > propose (copied from nova) make things complicated.
> > 2. I think you want to support "Support for async bay operations"
> > for youadding microversion support, right?
> > I would like suggest you as
> > http://paste.openstack.org/show/543105/ , it should work for you

[Hongbin Lu] It looks the fundamental difference between the proposed patch 
(https://review.openstack.org/#/c/343060/8/magnum/api/controllers/v1/bay.py) 
and the snippet (http://paste.openstack.org/show/543105/) is the usage of a 
decorator "api_version". The proposed patch implemented the decorator and used 
it to 

Re: [openstack-dev] [nova] [placement] *future* topics in resource providers/placement api

[Ed Leafe]

On Jul 28, 2016, at 1:19 PM, Chris Dent  wrote:

>> How about we do a query in two steps:
>> 
>> 1) take a list of compute nodes (== resource providers) and apply all
>> the filters which *can not* (or *are not* at some point) be
>> implemented in placement-api
>> 
>> 2) POST a launch request passing the *pre-filtered* list of resource
>> providers.  placement api will pick one of those RP, *claim* its
>> resources and return the claim info
> 
> While I think the ordering you describe might be useful in the use case
> that Ed has described in his message, I think for the general case it is
> backwards. We should use the placement API _first_ to winnow out those
> hosts that physically cannot satisfy the basic requirements for
> inventory of the standard resource classes and then pass that simplified
> list to the filters. That ought to be efficient and also provides a path
> for easy migration of those filters that can be implemented cleanly in
> the placement engine.

I can see several use cases where the different approaches result in different 
efficiencies. Let’s take the Watcher example, as this was the use case that 
started us down this road.

Watcher monitors a data center, and can be configured to migrate VMs to achieve 
different strategies. One such strategy is packing so that hosts that are not 
needed can be turned off, saving energy and cooling costs. In this case, 
Watcher will identify VMs that should be moved, and have a few target hosts 
that would result in better packing. In a large DC with thousands of hosts, 
having the placement API go through all those hosts when Watcher only cares 
about a handful or less is terribly inefficient. In that case, the question 
that Watcher is asking the placement API is “I need instance X migrated to one 
of these N hosts. Which of these hosts (if any) are acceptable?”.

There are many other scenarios where the opposite would be true, so I wouldn’t 
want to have it work only one way. IOW, we could change the ‘get_all_hosts’ to 
‘get_all_hosts_unless_I_already_have_some_hosts”. :)


-- Ed Leafe






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

[openstack-dev] [charms] 16.07 OpenStack charm release

[David Ames]

Hi All

We are pleased to announce the 16.07 release of the OpenStack charms.
Highlights include:

* Nova compute apparmor support (Preview)
* openstack-dashboard + Keystone v3 API support
* SR-IOV (Preview)
* External Network Update
* DNS HA (Preview)
* Enhancements to Ceph charms
* New Charm: aodh
* New Charms: designate and designate-bind (Preview)
* All charms are now licensed under the Apache License Version 2.0

For more details please see the release notes here:
https://wiki.ubuntu.com/OpenStack/OpenStackCharms/ReleaseNotes1607

A big thank you to the many people who contributed to the OpenStack
charms over the last cycle and if you'd like to contribute to our next
cycle our charm guide is here:
http://docs.openstack.org/developer/charm-guide/

The OpenStack Charm Team

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

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Doug Hellmann]

Excerpts from Zane Bitter's message of 2016-07-28 14:38:12 -0400:
> On 28/07/16 14:20, Jay Pipes wrote:
> > How would guidance from the TC about what it means for a repo to be
> > "part of the OpenStack tent" add clarity for repos that are not trying
> > to be part of the OpenStack tent?
> 
> If it were clear what it means for a repo to be "part of the OpenStack 
> tent" then it would be obvious to *everyone* which ones should be and 
> which ones should not. As it is there are two different interpretations 
> from which follow two different conclusions as to whether the Right 
> Thing(TM) is happening, causing unnecessary wailing and gnashing of 
> teeth. Please re-read my original message on this subject for a full 
> treatment.
> 
> cheers,
> Zane.
> 

There is only one way for a repository's contents to be considered
part of the big tent: It needs to be listed in the projects.yaml
file in the openstack/governance repository, associated with a
deliverable from a team that has been accepted as a big tent member.

The Fuel team has stated that they are not ready to include the
work in these new repositories under governance, and indeed the
repositories are not listed in the set of deliverables for the Fuel
team [1].

Therefore, the situation is clear, to me: They are not part of the
big tent.

Doug

[1] 
http://governance.openstack.org/reference/projects/fuel.html#deliverables-and-tags

__
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] [Magnum] Microversioning implementation

[Grant, Jaycen V]

I was completely unaware of any discussion of Semantic Versioning.  That was 
brought up by Eli Qiao in the code review, so he might be the one to point us 
in the right direction for that.

Jaycen

-Original Message-
From: Hongbin Lu [mailto:hongbin...@huawei.com] 
Sent: Thursday, July 28, 2016 11:10 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Magnum] Microversioning implementation

Added this to the agenda of next team meeting [1].

I would like to ask clarification for " the community are discussing to using 
Semantic Versioning(X.Y.Z) instead of microversion X.Y ". Could anyone provide 
more information about that?

Best regards,
Hongbin

> -Original Message-
> From: Grant, Jaycen V [mailto:jaycen.v.gr...@intel.com]
> Sent: July-28-16 10:52 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Magnum] Microversioning implementation
> 
> 
> There has been a discussion around micro versioning implementation 
> going on in the following patch:
> https://review.openstack.org/#/c/343060/8 and I was asked to bring it 
> to the mailing list for further discussion.
> 
> Magnum added header support for microversioning according to the 
> Openstack spec[1] but since we haven’t had any changes yet it was not 
> being used.  In the patch mentioned above I added code that provides 
> infrastructure for implementing micro versions for our API methods.  I 
> took the idea from how Nova implemented micro versioning and used some 
> of their code modified to work with Pecan.  The basic idea is that you 
> version a method using api_version decorator as shown below:
> 
> @base.Controller.api_version("1.1")
> @expose.expose(BayCollection, types.uuid)
> def get_all(self, marker=None):
> """Retrieve a list of bays.
> # code for version 1.1
> 
> @base.Controller.api_version(“1.2”, “1.3") 
> @expose.expose(BayCollection,
> types.uuid) def get_all(self, marker=None):
> """Retrieve a list of bays.
> # code for versions 1.2 through 1.3
> 
> @base.Controller.api_version("1.4")
> @expose.expose(BayCollection, types.uuid) def get_all(self,
> marker=None):
> """Retrieve a list of bays.
> # code for version 1.4 to latest version
> 
> 
> The api_version code takes care of selecting the correct version based 
> on version requested in the header. It also checks for version 
> overlaps in the methods and gaps in the method versions.
> 
> 
> While working on this Vijendar(working on the first api changes that 
> need api versioning) and myself, evaluated several other alternatives:
> 
> 1) Just have each method check the version object and handle the 
> differences. This was the most basic solution and will work but we 
> were concerned it would add a lot of duplicate code. We were also 
> concerned it would be messy in the future as more and more micro 
> versions were added. Each method would now be responsible for 
> additional checking and more places to change code if there were 
> overall micro version code changes in the future.
> 
> 2) Separate pecan controllers for each micro version. When a new micro 
> version is added a new controller would be created inheriting from the 
> previous version controller. The new controller would override the 
> modified methods. Routing changes would be added to make sure that the 
> correct controller was used depending on the API header.  We felt that 
> the api_version decorator was slightly less complicated and less code 
> overhead on each api version change.
> 
> I’d appreciate feedback on whether this is the right way to go or if 
> it would be better to go to alternative option 1 or 2. Here were some 
> of the concerns by one of the cores in the code review:
> 
> I don't accept this patch, mark it as -2:
> Reason:
> 1. we have already support microversion in our code base, and your 
> propose (copied from nova) make things complicated.
> 2. I think you want to support "Support for async bay operations"
> for youadding microversion support, right?
> I would like suggest you as
> http://paste.openstack.org/show/543105/ , it should work for you
> 3. we don't have too may requirements to bump our microversion (I 
> know you want to use it in bay-creation async), so we don't want bring 
> much code here then we need to maintain it later.
> 4. the community are discussing to using Semantic 
> Versioning(X.Y.Z) [1] instead of microversion X.Y [1]http://semver.org/
>If you have any questions , please discuss it in mailing list or 
> weekly meeting.
>Eli.
> 
> 
> 
> Jaycen Grant
> OSIC
> 
> 
> 
> 
> [1] http://specs.openstack.org/openstack/api-
> wg/guidelines/microversion_specification.html?highlight=microversionin
> g
> 
> >>
> __
> _
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Zane Bitter]

On 28/07/16 12:54, Jay Pipes wrote:

The TC has given guidance on this already:

http://governance.openstack.org/resolutions/20160119-stackforge-retirement.html


"In order to simplify software development lifecycle transitions of
Unofficial and Official OpenStack projects, all projects developed
within the OpenStack project infrastructure will be permitted to use the
“openstack/” namespace. The use of the term “Stackforge” to describe
unofficial projects should be considered deprecated."


The word "project" has unfortunately had multiple meanings throughout 
the history of OpenStack (I think it's something to do with multitenancy 
this week, right?), so to be clear: when I say 'project' here I mean in 
the sense of 'team'.


So I believe it's quite clear that there are official projects with 
official repos and unofficial projects with unofficial repos, and that 
all of these repos are hosted in the openstack/* namespace. (Nobody in 
the thread has raised the namespacing as an issue AFAICT.)


What's not clear is whether official projects should have unofficial 
repos. I submit that if that _were_ clear then this thread would never 
have existed and we would all be happier :)



The Fuel CCP repos are projects that are not official OpenStack projects.


Because of the aforementioned 'project' pun issue there's two ways of 
interpreting this. You may be saying that the repos are unofficial repos 
within the "Fuel" project (team), in which case the question of whether 
official projects should have unofficial repos applies.


Alternatively, you may be saying that the "Fuel CCP" project (team) is 
an unofficial project separate from the "Fuel" project (team), with it's 
own (naturally unofficial) repos, and that therefore the question of 
whether official projects should have unofficial repos is moot. In which 
case I think you at least have to forgive people for being confused ;)



They are in the openstack/ git namespace because they use the common
infrastructure and there isn't any formal plan to have the repos join
the "official OpenStack projects" (i.e. the ones listed in the
projects.yaml file in the openstack/governance repository).

Could they be proposed in the future as official OpenStack projects?
Maybe. Not sure, and I don't believe it's necessary to decide ahead of
time.

Please stop using a marketing press release as some indication of what
the "intent" is for these repos or even that there *is* any intent at
this point. It's really early on and these repos are intended as a place
to experiment and innovate. I don't see why there is so much anger about
that.


My only interest here is to try to help two groups that are clearly not 
communicating very well to communicate better. TBH I don't think your 
response was as helpful to those ends as it could have been. Can we 
start again?


cheers,
Zane.


Best,
-jay

On 07/28/2016 12:33 PM, Steven Dake (stdake) wrote:

Doug,

Zane's analysis is correct.  I agree with Zane's assessment that TC
clarification can solve this situation.

Regards
-steve

On 7/28/16, 9:15 AM, "Zane Bitter"  wrote:


On 28/07/16 08:48, Vladimir Kozhukalov wrote:

Fuel-ccp repositories are public, everyone is welcome to participate. I
don¹t see where we violate ³4 opens². These repos are now experimental.
At the moment the team is working on building CI pipeline and
developing
functional tests that are to be run as a part of CI process. These
repos
are not to be a part of Fuel Newton release. From time to time we add
and retire git repos and it is a part of development process. Not all
these repos are to become a part of Big tent.


It seems to me that there are two different interpretations of what it
means for a repo to be part of the OpenStack tent, and that these
differing interpretations are at the root of the arguments in this
thread.

The first interpretation is that repos listed as belonging to a team in
the governance repo are part of a deliverable that is released each
development cycle, and that the same team may also control other repos
that are not deliverables and hence not part of OpenStack. It's easy to
see how people could have developed this interpretation in good faith.

The second interpretation is that the TC blesses a team; that the only
criterion for receiving this blessing is for the project to be "one of
us", which in practice effectively means following the Four Opens; and
that all repos which the team intends to operate in this manner, subject
to TC oversight, should be listed in the governance repo. It's also easy
to see how people could have developed this interpretation in good
faith. (In fact, I was following the big tent discussions very closely
at the time and this was always my understanding of what it meant.)

The only additional thing needed to explain this thread is the
(incorrect) assumption on behalf of all participants that everyone has
the same interpretation :)

Assuming everyone holds the first interpretation, 

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Russell Bryant]

On Thu, Jul 28, 2016 at 2:20 PM, Jay Pipes  wrote:

> How would guidance from the TC about what it means for a repo to be "part
> of the OpenStack tent" add clarity for repos that are not trying to be part
> of the OpenStack tent?
>
> Just curious here...


Related, ​Flavio asked about this earlier, and I don't think it was
answered.

Is the issue with the use of the Fuel name?  Would the concern remain if
the repository was called "pancakes-ccp" instead of "fuel-ccp"?

-- 
Russell Bryant​
__
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] [ptl][requirements] nomination period started

[Anita Kuno]

On 07/27/2016 06:06 PM, Jeremy Stanley wrote:
> On 2016-07-27 17:56:39 -0400 (-0400), Doug Hellmann wrote:
> [...]
>> However, we may have some folks on the core team who have not
>> contributed a patch, since it is far more common to do reviews than
>> to submit changes there (more and more of the changes are being
>> automated). So, we probably need to expand the traditional definition
>> to also include the existing core review team (members of
>> requirements-core [1]), just to be safe.
> [...]
> 
> Easy enough to do for a one-off, but might want to consider
> officially adding them as extra-ATCs in governance down the road to
> make that more explicit. Our existing tooling is already adapted to
> that solution as well (for example, the current i18n voters are
> _all_ recorded as extra-ATCs because we haven't implemented API
> calls to Zanata for integrating it into the normal roll generation
> process yet).
> 
> However, implicitly adding core reviewers seems a little weird as
> they're officially appointed by the PTL and so allowing the
> incumbent PTL to appoint (or remove) specific voters before their
> pending reelection... well anyway, I guess it's balanced out by
> there being a lot more committers to that repo than core reviewers
> on it.
> 

So Doug and I had a chat and we propose the following workflow for
deciding the requirements ptl:
1) Nominations open, done:
http://lists.openstack.org/pipermail/openstack-dev/2016-July/100173.html
2) Nominations close: August 5th, 11:59 utc
3) List of Nominees posted to mailing list, a post appened to the
parent:
http://lists.openstack.org/pipermail/openstack-dev/2016-July/100173.html
4) Election officials start civs poll after 13:00 utc August 5, 2016
5) Election poll closes after 13:00 utc  August 11, 2016
6) Winning candidate will be announced to the mailing list
(openstack-dev@lists.openstack.org)

Electorate:
requirements core reviewers and those who have merged at least one
patch to the requirements repo between 1 Aug 2015 and July 31 2016
can I vote?


https://review.openstack.org/#/q/project:openstack/requirements+is:owner+is:merged+after:2015-07-31+before:2016-08-01

how do I vote?

eligible voters will receive a ballot sent to their gerrit preferred
email, if you are an eligible voter and don't receive an email providing
you a link to the poll by August 6, 2016 please email the election
officials with a gerrit url for your patch confirming your eligibility


Please ask any questions you need to ask to clarify this process so you
understand it.

If you have a question of a personal nature, please don't hesitate to
email both election officials: Doug Hellmann  and
Anita Kuno  as soon as you can so we can
ensure you have the answers you need.

Thank you to Jeremy Stanley for his assistance and support as well as
his offer to help us generate the electoral rolls, which include a wip
patch to governance to generate an electoral roll separate from the
Release Management team electorate. After the election, we will abandon
that patch and let the new team propose its own change, including a
mission statement and other metadata, when they seek to become a big
tent project. Gerrit patch: https://review.openstack.org/#/c/348462

Thanks for your participation in the electoral process,

Anita and Doug

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

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Clint Byrum]

Excerpts from Fox, Kevin M's message of 2016-07-27 22:56:56 +:
> I think that would be true, if the container api was opinionated. for 
> example, trying to map only a subset of the openstack config options to 
> docker environment variables. This would make the containers specific to what 
> your talking about. Which business rules to support, what hardware, etc.
> 
> But the api is a fairly small one. Its mostly a standardized way to pass 
> config files in through docker volumes and get them to land in the right 
> places in the container. You should be able to use any system you want 
> (puppet, chef, jinja, shell scripts) to deal with the business logic and 
> such, to generate the config files, then use the standard api contract to 
> ensure that whatever way you launch the container, (puppet, chef, heat, 
> docker run, kubelet, kubernetes, etc) it behaves the same. The way your 
> generated config file specifies.
> 
> Kolla has provided many different variants of each of the containers (centos, 
> ubuntu, etc), showing that api contract is pretty flexible.
> 
> A similar thing is going on with kolla-kubernetes.
> 

I appreciate your optimism, however, Kolla is not "the deployment of
OpenStack". It is a set of tools to deploy OpenStack with a set of options
available. If it were a small thing to do, people would choose it. But
instead, they know, the combinatorial matrix of options is staggering,
and one is much better off specializing if they don't fit into the
somewhat generic model that any tool like Kolla provides.

I'd say focus on _keeping things like Kolla focused_ rather than
worrying about making it interoperable.

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

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Mark Casey]

Sorry for the double post, but the part about people wasting their time 
reads far more inflammatory than I really intended. I merely mean 
community effort is a strong theme.



On 7/28/2016 11:20 AM, Mark Casey wrote:


+1 to one more pass at using the same images. Doing so will become 
practically impossible in a matter of weeks or months, and in the long 
term the additional shared human resources outweigh the interpersonal 
complexities (and for any who don't think so - maybe you're wasting 
your time here?).



Logically, I just view Kolla's existing containers as a thin wrapper 
around OpenStack projects' debs and rpms (though I understand there 
are many differences from a purely technical standpoint, and that the 
containers can be built entirely from source instead). I suppose I 
view them this way because building the existing containers creates 
deployable artifacts (that is, the images) and these images have a lot 
of the same qualities as traditional deb/rpm packages. The resulting 
artifacts in both cases are somewhat immutable, they both put programs 
in certain places, both expect configs in certain places, both 
configure logs to be written in certain places, etc. In fact a lot of 
these locations in the container's case are dictated by where they are 
expected in the packages. Sharing the images could further standardize 
things.



This is different IMHO than deployment tooling in the usual 
configuration management sense, which I presume is one of the reasons 
for this possible Kolla repo-split to begin with. I certainly see the 
upsides to having a diverse set of tooling to deploy project artifacts 
(deb/rpm/container image/git commit [i.e. from source]), but I don't 
get duplicating the artifacts themselves over relatively simple 
technicalities. I highly doubt anyone would create a major packaging 
variation in the deb/rpm packaging (perhaps where all OpenStack 
projects are deployable from a single rpm or deb [wouldn't that be 
fun!], or perhaps a switch to FPM) merely because it made sense for a 
new deployment project. (to be clear though, I am in general happy to 
have more deployment options coming online)



Thank you,
Mark


On 7/28/2016 8:56 AM, Fox, Kevin M wrote:
I really see 3 issues raised in the spec mentioned that have any 
disagreement as far as I can tell.


1. mirantis would like to see kolla-ansible split from the base kolla 
repo. This has a lot of support and is likely to come up for a final 
vote soon. It was postponed due to not wanting to split in the middle 
of a cycle. - This does not seem like a good reason at this point to 
spawn a new project. I support the split.


2. mirantis would like to see repos split for each docker container 
definition to be one per container. This is purely a management style 
difference. Split or combined both has advantages, and at present 
scaling issues have not been hit, so change has a cost that doesn't 
yet have a significant benefit. If it started to be, I'm sure it 
would be re-evaluated. This does not seem like a good reason at this 
point to spawn a new project. I think splitting seems unnecessary at 
this point, but if the whole thing comes down to this one issue, I'd 
support splitting the repos just so we don't duplicate so much work 
over such a minor thing.


3. Some bootstrap logic in some of the containers. mirantis would 
like to see it gone. Its completely optional (just don't set the 
BOOTSTRAP env vars) and needs to stay for api backwards compatibility 
in existing containers. It does not have to be used by deployment 
tools that don't wish to use it. This does not seem like a good 
reason at this point to spawn a new project. I support keeping it to 
not break things as its optional.


Are these really that contentious that we have to split a community 
over? Can we get both sides to give in a little and help each other out?


Maybe something like:
1. kolla commits to split out kolla-ansible as soon as possible 
(right after newton tagged)
2. Some middle ground here. Maybe its keep as is, but come up with a 
formal procedure for re-evaluating when it becomes painful and make a 
change. (Seems similar to the fuel/puppet repo upstreaming thing, in 
a way. Maybe some of the same process could work here? Some time to 
review metrics?)

3. We keep the optional stuff so we don't break existing deployments.

Is this reasonable?

Thanks,
Kevin

*From:* Vladimir Kozhukalov [vkozhuka...@mirantis.com]
*Sent:* Thursday, July 28, 2016 5:48 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like 
Mirantis is getting Fuel CCP (docker/k8s) kicked off


>1. Alter the mission statement of fuel to match the reality being

>published by the press and Mirantis's executive team

>2. Include these non-experimental repos in the projects.yaml governance

>Repository


Frankly, I don’t