[Openstack-operators] OpenStack Developer Mailing List Digest May 14 to June 17

2016-06-17 Thread Mike Perez 
HTML render: 
http://www.openstack.org/blog/2016/06/openstack-developer-mailing-list-digest-20160617/

SuccessBot Says
===
* Qiming: Senlin has completed API migration from WADL.
* Mugsie: Kiall Fixed the gate - development can now continue!!!
* notmyname: exactly 6 years ago today, Swift was put into production
* kiall: DNS API reference is live [1].
* sdague: Nova legacy v2 api code removed [2].
* HenryG: Last remnant of oslo incubator removed from Neutron [3].
* dstanek: I was able to perform a roundtrip between keystone and testshib.org
  using my new SAML2 middleware!
* Sdague: Nova now defaults to Glance v2 for image operations [4].
* Ajaeger: First Project Specific Install Guide is published - congrats to the
  heat team!
* Jeblair: There is no Jenkins, only Zuul.
* All: https://wiki.openstack.org/wiki/Successes


Require A Level Playing Field for OpenStack Projects

* Thierry Carrez proposes a new requirement [5] for OpenStack “official”
  projects.
* An important characteristic of open collaboration grounds is they need to be
  a level playing field. No specific organization can be given an unfair
  advantage.

  - Projects that are blessed as “official” project teams need to operate in
a fair manner. Otherwise they could be essentially a trojan horse for
a given organization.
  - If in a given project, developers from one specific organization benefit
from access specific knowledge or hardware, then the project should be
rejected under the “open community” rule.
  - Projects like Cinder provide an interesting grey area, but as long as all
drivers are in and there is a fully functional (and popular) open source
implementation there is likely no specific organization considered as
unfairly benefiting.

* Neutron plugin targeting a specific piece of networking hardware would likely
  given an unfair advantage to developers of the hardware's manufacturer
  (having access to hardware for testing and being able to see and make changes
  to its proprietary source code).
* Open source projects that don't meet the open community requirement can still
  exist in the ecosystem (developed using gerrit and openstack/* git
  repository, gate testing, but as an unofficial project.
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-June/thread.html#97307


Add Option to Disable Some Strict Response Checking for Interop Testing

* Nova introduced their API micro version change [6]
* QA team adds strict API schema checking to Tempest to ensure no additional
  Nova API responses [7][8].
  - In the last year, three vendors participating in the OpenStack powered
trademark program were impacted by this [9].
* DefCore working group determines guidelines for the OpenStack powered
  program.

  - Includes capabilities with associated functional tests from Tempest that
must pass.
  - There is a balance of future direction of development with lagging
indicators of deployments and user adoption.

* A member of the working group Chris Hoge would like to implement a temporary
  waiver for strict API checking requirements.

  - While this was discussed publicly in the developer community and took some
time to implement. It still landed quickly, and broke several existing
deployments overnight.
  - It's not viable for downstream deployers to use older versions of Tempest
that don't have these strict response checking, due to the TC resolution
passed [10] to advise DefCore to use Tempest as the single source of

capability testing.
* Proposal:
  - Short term:
+ There will be a blueprint and patch to Tempest that allows configuration
  of a grey-list of Nova APIs which strict response checking on additional
  properties will be disabled.
+ Using this code will emit a deprecation warning.
+ This will be removed 2017.01.
+ Vendors are required to submit the grey-list of APIs with additional
  response data that would be published to their marketplace entry.

  - Long term:
+ Vendors will be expected to work with upstream to update the API
  returning additional data.
+ The waiver would no longer be allowed after the release of 2017.01
guidleine.

* Former QA PTL Matthew Treinish feels this a big step backwards.
  - Vendors who have implemented out of band extensions or injected additional
things in responses believe that by doing so they're interoperable. The API
is not a place for vendor differentation.
  - Being a user of several clouds, random data in the response makes it more
difficult to write code against. Which are the vendor specific responses?
* Alternatives to not giving vendors more time in the market:
  - Having some vendors leave the the Powered program unnecessarily weakening
it.
  - Force DefCore to adopt non-upstream testing, either as a fork

Re: [Openstack-operators] [openstack-dev] [Neutron][IPAM] Anyone using builtin pluggable IPAM driver?

2016-06-17 Thread Robert Starmer 
I didnt' even realize that there was a special "internal" driver. The only
time I've set this parameter was to use a non-standard IPAM service (
romana.io SDN specifically), otherwise I'd likely never have even looked
for an ipam_driver config parameter.

R

On Fri, Jun 17, 2016 at 2:03 PM, Sean M. Collins  wrote:

> Doesn't look like anyone sets it. I don't see any references to it in
> the provisioning tools (puppet, ansible, salt).
>
> http://codesearch.openstack.org/?q=ipam_driver=nope==
>
> So probably only very advanced users have done anything with it since
> it would require manual configuration?
> --
> Sean M. Collins
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [Neutron][IPAM] Anyone using builtin pluggable IPAM driver?

2016-06-17 Thread Sean M. Collins 
Doesn't look like anyone sets it. I don't see any references to it in
the provisioning tools (puppet, ansible, salt).

http://codesearch.openstack.org/?q=ipam_driver=nope==

So probably only very advanced users have done anything with it since
it would require manual configuration?
-- 
Sean M. Collins

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

Re: [Openstack-operators] [Glance] Default policy in policy.json

2016-06-17 Thread Abel Lopez 
Great, thanks for the clarification.
> On Jun 17, 2016, at 9:56 AM, Bunting, Niall  wrote:
> 
> > By setting default to admin, won't we be overly restrictive?
> > I see that "add_image, download_image" are both set to "", which I assume 
> > means, default, which means admin,
> > If that's correct, then no regular project users will be able to create 
> > images, or worse, launch instances.
> > I usually go with "owner_or_admin" for my defaults, wrt add_image, etc.
> 
> An empty string means everybody. So this would not affect download_image etc. 
> The default only applies when the policy does not exist in the file. For 
> example a new policy is added and the policy.json is not updated.
> 
> Niall
> From: Abel Lopez 
> Sent: 17 June 2016 17:46:47
> To: Bunting, Niall
> Cc: openstack-operators@lists.openstack.org
> Subject: Re: [Openstack-operators] [Glance] Default policy in policy.json
> 
> By setting default to admin, won't we be overly restrictive?
> I see that "add_image, download_image" are both set to "", which I assume 
> means, default, which means admin,
> If that's correct, then no regular project users will be able to create 
> images, or worse, launch instances.
> I usually go with "owner_or_admin" for my defaults, wrt add_image, etc.
> 
> > On Jun 17, 2016, at 9:27 AM, Bunting, Niall  wrote:
> >
> > Hi,
> >
> >
> > Glance is planning to implement the patch [1], which affects the value of 
> > the 'default' policy.
> >
> >
> > This would make the following change in the policy.json:
> >
> > - "default": ""
> >
> > + "default": "role:admin" (or to "!" to restrict everybody)
> >
> >
> > We are just wondering if the operators have any reason not to make this 
> > change? As our thinking is that this would be more restrictive for new 
> > policies, to stop users accidentally getting additional permissions when a 
> > policy is not explicitly stated. However, we may have overlooked something 
> > else.
> >
> >
> > Also which would be preferred "role:admin" or "!"? Brian points out on [1] 
> > that "!" would in effect, notify the admins that a policy is not defined as 
> > they would be unable to preform the action themselves.
> >
> >
> > Thanks,
> >
> > Niall
> >
> >
> > 1. https://review.openstack.org/#/c/330443/
> >
> > ___
> > OpenStack-operators mailing list
> > OpenStack-operators@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Glance] Default policy in policy.json

2016-06-17 Thread Bunting, Niall 
> By setting default to admin, won't we be overly restrictive?
> I see that "add_image, download_image" are both set to "", which I assume 
> means, default, which means admin,
> If that's correct, then no regular project users will be able to create 
> images, or worse, launch instances.
> I usually go with "owner_or_admin" for my defaults, wrt add_image, etc.


An empty string means everybody. So this would not affect download_image etc. 
The default only applies when the policy does not exist in the file. For 
example a new policy is added and the policy.json is not updated.


Niall


From: Abel Lopez 
Sent: 17 June 2016 17:46:47
To: Bunting, Niall
Cc: openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] [Glance] Default policy in policy.json

By setting default to admin, won't we be overly restrictive?
I see that "add_image, download_image" are both set to "", which I assume 
means, default, which means admin,
If that's correct, then no regular project users will be able to create images, 
or worse, launch instances.
I usually go with "owner_or_admin" for my defaults, wrt add_image, etc.

> On Jun 17, 2016, at 9:27 AM, Bunting, Niall  wrote:
>
> Hi,
>
>
> Glance is planning to implement the patch [1], which affects the value of the 
> 'default' policy.
>
>
> This would make the following change in the policy.json:
>
> - "default": ""
>
> + "default": "role:admin" (or to "!" to restrict everybody)
>
>
> We are just wondering if the operators have any reason not to make this 
> change? As our thinking is that this would be more restrictive for new 
> policies, to stop users accidentally getting additional permissions when a 
> policy is not explicitly stated. However, we may have overlooked something 
> else.
>
>
> Also which would be preferred "role:admin" or "!"? Brian points out on [1] 
> that "!" would in effect, notify the admins that a policy is not defined as 
> they would be unable to preform the action themselves.
>
>
> Thanks,
>
> Niall
>
>
> 1. https://review.openstack.org/#/c/330443/
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


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

Re: [Openstack-operators] [Glance] Default policy in policy.json

2016-06-17 Thread Abel Lopez 
By setting default to admin, won't we be overly restrictive?
I see that "add_image, download_image" are both set to "", which I assume 
means, default, which means admin,
If that's correct, then no regular project users will be able to create images, 
or worse, launch instances.
I usually go with "owner_or_admin" for my defaults, wrt add_image, etc.

> On Jun 17, 2016, at 9:27 AM, Bunting, Niall  wrote:
> 
> Hi,
> 
> 
> Glance is planning to implement the patch [1], which affects the value of the 
> 'default' policy.
> 
> 
> This would make the following change in the policy.json:
> 
> - "default": ""
> 
> + "default": "role:admin" (or to "!" to restrict everybody)
> 
> 
> We are just wondering if the operators have any reason not to make this 
> change? As our thinking is that this would be more restrictive for new 
> policies, to stop users accidentally getting additional permissions when a 
> policy is not explicitly stated. However, we may have overlooked something 
> else.
> 
> 
> Also which would be preferred "role:admin" or "!"? Brian points out on [1] 
> that "!" would in effect, notify the admins that a policy is not defined as 
> they would be unable to preform the action themselves.
> 
> 
> Thanks,
> 
> Niall
> 
> 
> 1. https://review.openstack.org/#/c/330443/
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [Glance] Default policy in policy.json

2016-06-17 Thread Bunting, Niall 
Hi,


Glance is planning to implement the patch [1], which affects the value of the 
'default' policy.


This would make the following change in the policy.json:

- "default": ""

+ "default": "role:admin" (or to "!" to restrict everybody)


We are just wondering if the operators have any reason not to make this change? 
As our thinking is that this would be more restrictive for new policies, to 
stop users accidentally getting additional permissions when a policy is not 
explicitly stated. However, we may have overlooked something else.


Also which would be preferred "role:admin" or "!"? Brian points out on [1] that 
"!" would in effect, notify the admins that a policy is not defined as they 
would be unable to preform the action themselves.


Thanks,

Niall


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

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