Re: [openstack-dev] [all][policy][keystone] Better Policy Model and Representing Capabilites

2014-10-13 Thread Rodrigo Duarte
This is a hot topic for some brainstorms here, since I started to hack a
bit with OpenStack  =)

Regarding the given options, the second one looks better IMO, and we could
avoid some of the token bloating issues by having a parameter where the
service specifies what is set of actions that are important (the parameter
could be service name). Although we have some services with a huge set of
possible operations, like Nova.

But there is also some points that seem important to keep in mind, giving
that we have some cases for each action, not just the action itsel. For
example: update_project. A project_admin can update its own project but not
another project. And I don't see other options to check this than having
two different rules: update_own_project, update_any_project, and the rules
would be checked against the project_id in the token scope.

On Mon, Oct 13, 2014 at 5:17 PM, Morgan Fainberg morgan.fainb...@gmail.com
wrote:

 Description of the problem: Without attempting an action on an endpoint
 with a current scoped token, it is impossible to know what actions are
 available to a user.


 Horizon makes some attempts to solve this issue by sourcing all of the
 policy files from all of the services to determine what a user can
 accomplish with a given role. This is highly inefficient as it requires
 processing the various policy.json files for each request in multiple
 places and presents a mechanism that is not really scalable to understand
 what a user can do with the current authorization. Horizon may not be the
 only service that (in the long term) would want to know what actions a
 token can take.

 I would like to start a discussion on how we should improve our policy
 implementation (OpenStack wide) to help make it easier to know what is
 possible with a current authorization context (Keystone token). The key
 feature should be that whatever the implementation is, it doesn’t require
 another round-trip to a third party service to “enforce” the policy which
 avoids another scaling point like UUID Keystone token validation.

 Here are a couple of ideas that we’ve discussed over the last few
 development cycles (and none of this changes the requirements to manage
 scope of authorization, e.g. project, domain, trust, ...):

 1. Keystone is the holder of all policy files. Each service gets it’s
 policy file from Keystone and it is possible to validate the policy (by any
 other service) against a token provided they get the relevant policy file
 from the authoritative source (Keystone).

 Pros: This is nearly completely compatible with the current policy system.
 The biggest change is that policy files are published to Keystone instead
 of to a local file on disk. This also could open the door to having
 keystone build “stacked” policies (user/project/domain/endpoint/service
 specific) where the deployer could layer policy definitions (layering would
 allow for stricter enforcement at more specific levels, e.g. users from
 project X can’t terminate any VMs).

 Cons: This doesn’t ease up the processing requirement or the need to hold
 (potentially) a significant number of policy files for each service that
 wants to evaluate what actions a token can do.


 2. Each enforcement point in a service is turned into an attribute/role,
 and the token contains all of the information on what a user can do
 (effectively shipping the entire policy information with the token).

 Pros: It is trivial to know what a token provides access to: the token
 would contain something like `{“nova”: [“terminate”, “boot”], “keystone”:
 [“create_user”, “update_user”], ...}`. It would be easily possible to allow
 glance “get image” nova “boot” capability instead of needing to know the
 roles for policy.json for both glance and nova work for booting a new VM.

 Cons: This would likely require a central registry of all the actions that
 could be taken (something akin to an IANA port list). Without a grouping to
 apply these authorizations to a user (e.g. keystone_admin would convey
 “create_project, delete_project, update_project, create_user, delete_user,
 update_user, ...”) this becomes unwieldy. The “roles” or “attribute” that
 convey capabilities are also relatively static instead of highly dynamic as
 they are today. This could also contribute to token-bloat.



 I’m sure there are more ways to approach this problem, so please don’t
 hesitate to add to the conversation and expand on the options. The above
 options are by no mean exhaustive  nor fully explored. This change may not
 even be something to be expected within the current development cycle
 (Kilo) or even the next, but this is a conversation that needs to be
 started as it will help make OpenStack better.

 Thanks,
 Morgan

 —
 Morgan Fainberg



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




-- 
Rodrigo Duarte Sousa
Software Engineer

Re: [openstack-dev] [oslo] kilo graduation plans

2014-11-13 Thread Rodrigo Duarte
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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




-- 
Rodrigo Duarte Sousa
Software Engineer at Advanced OpenStack Brazil
Distributed Systems Laboratory
MSc in Computer Science
Federal University of Campina Grande
Campina Grande, PB - Brazil
http://rodrigods.com http://lsd.ufcg.edu.br/%7Erodrigods
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] kilo graduation plans

2014-11-13 Thread Rodrigo Duarte
Thanks Steve.

On Thu, Nov 13, 2014 at 12:50 PM, Steve Martinelli steve...@ca.ibm.com
wrote:

 looking at http://specs.openstack.org/openstack/oslo-specs/ and
 http://specs.openstack.org/openstack/keystone-specs/ should have all the
 info you need. The specs are hosted at:
 https://github.com/openstack/keystone-specs there's a template spec too.

 Thanks,

 _
 Steve Martinelli
 OpenStack Development - Keystone Core Member
 Phone: (905) 413-2851
 E-Mail: steve...@ca.ibm.com



 From:Rodrigo Duarte rodrigodso...@gmail.com
 To:OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date:11/13/2014 10:13 AM
 Subject:Re: [openstack-dev] [oslo] kilo graduation plans
 --



 Hi Doug,

 I'm going to write the spec regarding the policy graduation, it will be
 placed in the keystone-specs repository. I was wondering if someone have
 examples of such specs so we can cover all necessary points.

 On Thu, Nov 13, 2014 at 10:34 AM, Doug Hellmann *d...@doughellmann.com*
 d...@doughellmann.com wrote:

 On Nov 13, 2014, at 8:31 AM, Dmitry Tantsur *dtant...@redhat.com*
 dtant...@redhat.com wrote:

  On 11/13/2014 01:54 PM, Doug Hellmann wrote:
 
  On Nov 13, 2014, at 3:52 AM, Dmitry Tantsur *dtant...@redhat.com*
 dtant...@redhat.com wrote:
 
  On 11/12/2014 08:06 PM, Doug Hellmann wrote:
  During our “Graduation Schedule” summit session we worked through the
 list of modules remaining the in the incubator. Our notes are in the
 etherpad [1], but as part of the Write it Down” theme for Oslo this cycle
 I am also posting a summary of the outcome here on the mailing list for
 wider distribution. Let me know if you remembered the outcome for any of
 these modules differently than what I have written below.
 
  Doug
 
 
 
  Deleted or deprecated modules:
 
  funcutils.py - This was present only for python 2.6 support, but it
 is no longer used in the applications. We are keeping it in the stable/juno
 branch of the incubator, and removing it from master (
 *https://review.openstack.org/130092*
 https://review.openstack.org/130092)
 
  hooks.py - This is not being used anywhere, so we are removing it. (
 *https://review.openstack.org/#/c/125781/*
 https://review.openstack.org/#/c/125781/)
 
  quota.py - A new quota management system is being created (
 *https://etherpad.openstack.org/p/kilo-oslo-common-quota-library*
 https://etherpad.openstack.org/p/kilo-oslo-common-quota-library) and
 should replace this, so we will keep it in the incubator for now but
 deprecate it.
 
  crypto/utils.py - We agreed to mark this as deprecated and encourage
 the use of Barbican or cryptography.py (
 *https://review.openstack.org/134020*
 https://review.openstack.org/134020)
 
  cache/ - Morgan is going to be working on a new oslo.cache library as
 a front-end for dogpile, so this is also deprecated (
 *https://review.openstack.org/134021*
 https://review.openstack.org/134021)
 
  apiclient/ - With the SDK project picking up steam, we felt it was
 safe to deprecate this code as well (*https://review.openstack.org/134024*
 https://review.openstack.org/134024).
 
  xmlutils.py - This module was used to provide a security fix for some
 XML modules that have since been updated directly. It was removed. (
 *https://review.openstack.org/#/c/125021/*
 https://review.openstack.org/#/c/125021/)
 
 
 
  Graduating:
 
  oslo.context:
  - Dims is driving this
  -
 *https://blueprints.launchpad.net/oslo-incubator/+spec/graduate-oslo-context*
 https://blueprints.launchpad.net/oslo-incubator/+spec/graduate-oslo-context
  - includes:
 context.py
 
  oslo.service:
  - Sachi is driving this
  -
 *https://blueprints.launchpad.net/oslo-incubator/+spec/graduate-oslo-service*
 https://blueprints.launchpad.net/oslo-incubator/+spec/graduate-oslo-service
  - includes:
 eventlet_backdoor.py
 loopingcall.py
 periodic_task.py
  By te way, right now I'm looking into updating this code to be able to
 run tasks on a thread pool, not only in one thread (quite a problem for
 Ironic). Does it somehow interfere with the graduation? Any deadlines or
 something?
 
  Feature development on code declared ready for graduation is basically
 frozen until the new library is created. You should plan on doing that work
 in the new oslo.service repository, which should be showing up soon. And
 the you describe feature sounds like something for which we would want a
 spec written, so please consider filing one when you have some of the
 details worked out.
  Sure, right now I'm experimenting in Ironic tree to figure out how it
 really works. There's a single oslo-specs repo for the whole oslo, right?

 Yes, that’s right openstack/oslo-specs. Having a branch somewhere as a
 reference would be great for the spec reviewers, so that seems like a good
 way to start.

 Doug

 
 
 
 request_utils.py
 service.py
 sslutils.py

[openstack-dev] [keystone] SPF exception: Recursive deletion and project disabling

2015-02-08 Thread Rodrigo Duarte
Hi,

We are proposing this spec: https://review.openstack.org/#/c/148730/ . In
there we detail how will work recursive deletion and disabling for projects
(and domains). This change was dependent on the Reseller spec that was
approved before the deadline and adds some good improvements for the recent
merged Hierarchical Multitenancy feature, these changes would ease a lot
the way operators handle deployments using projects/domains hierarchies,
the implementation changes are not big and we believe it could easily land
in Kilo if the spec was approved.

What do you think? Makes sense for this spec to be a Spec Proposal Freeze
exception?

-- 
Rodrigo Duarte Sousa
Senior Software Engineer at Advanced OpenStack Brazil
Distributed Systems Laboratory
MSc in Computer Science
Federal University of Campina Grande
Campina Grande, PB - Brazil
http://rodrigods.com http://lsd.ufcg.edu.br/%7Erodrigods
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Keystone] Proposing Marek Denis for the Keystone Core Team

2015-02-13 Thread Rodrigo Duarte
Congrats Marek, well deserved!

On Fri, Feb 13, 2015 at 2:35 PM, Morgan Fainberg morgan.fainb...@gmail.com
wrote:

 Based upon the feedback from this thread, I want to welcome Marek as the
 newest member of keystone core.

 Cheers,
 Morgan
 --
 Morgan Fainberg

 On February 10, 2015 at 9:51:16 AM, Morgan Fainberg (
 morgan.fainb...@gmail.com) wrote:

  Hi everyone!

  I wanted to propose Marek Denis (marekd on IRC) as a new member of the
 Keystone Core team. Marek has been instrumental in the implementation of
 Federated Identity. His work on Keystone and first hand knowledge of the
 issues with extremely large OpenStack deployments has been a significant
 asset to the development team. Not only is Marek a strong developer working
 on key features being introduced to Keystone but has continued to set a
 high bar for any code being introduced / proposed against Keystone. I know
 that the entire team really values Marek’s opinion on what is going in to
 Keystone.

  Please respond with a +1 or -1 for adding Marek to the Keystone core
 team. This poll will remain open until Feb 13.

  --
 Morgan Fainberg


 __
 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




-- 
Rodrigo Duarte Sousa
Senior Software Engineer at Advanced OpenStack Brazil
Distributed Systems Laboratory
MSc in Computer Science
Federal University of Campina Grande
Campina Grande, PB - Brazil
http://rodrigods.com http://lsd.ufcg.edu.br/%7Erodrigods
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?

2015-04-04 Thread Rodrigo Duarte
yes please [2]

On Sat, Apr 4, 2015 at 1:07 PM, Raildo Mascena rail...@gmail.com wrote:

 I totally agree, since this is not used in production and make the dev job
 more complicated.

 @Henry If you want help with this, I would be glad to work with you to
 make this clean up.

 On Sat, Apr 4, 2015 at 2:55 AM Henry Nash hen...@linux.vnet.ibm.com
 wrote:

 Fully support this.  I, for one, volunteer to take on a lot of the work
 needed to clean up any our tests/environment to allow this to a happen.
 Hardly a month goes by without a fix having to be re-applied to our sql
 code to get round some problem that didn’t show up in original testing
 because SQLite is too promiscuous.

 Henry

 On 4 Apr 2015, at 01:55, Morgan Fainberg morgan.fainb...@gmail.com
 wrote:

 I am looking forward to the Liberty cycle and seeing the special casing
 we do for SQLite in our migrations (and elsewhere). My inclination is that
 we should (similar to the deprecation of eventlet) deprecate support for
 SQLite in Keystone. In Liberty we will have a full functional test suite
 that can (and will) be used to validate everything against much more real
 environments instead of in-process “eventlet-like” test-keystone-services;
 the “Restful test cases” will no longer be part of the standard unit tests
 (as they are functional testing). With this change I’m inclined to say
 SQLite (being the non-production usable DB) what it is we should look at
 dropping migration support for SQLite and the custom work-arounds.

 Most deployers and developers (as far as I know) use devstack and MySQL
 or Postgres to really suss out DB interactions.

 I am looking for feedback from the community on the general stance for
 SQLite, and more specifically the benefit (if any) of supporting it in
 Keystone.

 --
 Morgan Fainberg
 __
 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




-- 
Rodrigo Duarte Sousa
Senior Software Engineer at Advanced OpenStack Brazil
Distributed Systems Laboratory
MSc in Computer Science
Federal University of Campina Grande
Campina Grande, PB - Brazil
http://rodrigods.com http://lsd.ufcg.edu.br/%7Erodrigods
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name

2015-06-04 Thread Rodrigo Duarte
...@lists.openstack.org?subject:unsubscribe
  
   
 http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
  
  
  
 
  __
   OpenStack Development Mailing List (not for usage questions)
   Unsubscribe:
  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  
 http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
 
 
  __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  
 http://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




-- 
Rodrigo Duarte Sousa
Senior Software Engineer at Advanced OpenStack Brazil
Distributed Systems Laboratory
MSc in Computer Science
Federal University of Campina Grande
Campina Grande, PB - Brazil
http://rodrigods.com http://lsd.ufcg.edu.br/%7Erodrigods
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [keystone] SPF exception: Extend endpoint filtering to Service Providers

2015-06-25 Thread Rodrigo Duarte
Hi all,

Endpoint filtering is a keystone extension since the Havana release, in
Juno it was expanded by the Multi-Attribute Endpoint Grouping spec [1] that
improves the filtering flexibility.

Since Kilo, we added the concept of Service Providers to keystone, the list
of such resources is returned in the token alongside the service catalog
[2]. In Liberty we are proposing to extend endpoints filtering to also
support Service Providers [3]. This should not bring API nor model changes,
just extra checks to the endpoint filter controller/backend.

We believe this could easily land in Liberty if the spec is approved - so
we'd like to formally request a spec freeze exception for it.

[1]
https://github.com/openstack/keystone-specs/blob/master/specs/juno/endpoint-group-filter.rst
[2]
https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3.rst#authentication-responses
[3] https://review.openstack.org/#/c/188534/

Thanks!

-- 
Rodrigo Duarte Sousa
Senior Software Engineer at Advanced OpenStack Brazil
Distributed Systems Laboratory
MSc in Computer Science
Federal University of Campina Grande
Campina Grande, PB - Brazil
http://rodrigods.com http://lsd.ufcg.edu.br/%7Erodrigods
__
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][keystone] Nova calls to Keystone

2015-06-23 Thread Rodrigo Duarte
On Tue, Jun 23, 2015 at 5:48 AM, John Garbutt j...@johngarbutt.com wrote:

 On 23 June 2015 at 03:30, Adam Young ayo...@redhat.com wrote:
  On 06/22/2015 10:13 PM, Sajeesh Cimson Sasi wrote:
  
  From: Adam Young [ayo...@redhat.com]
  Sent: 23 June 2015 00:01:48
  To: openstack-dev@lists.openstack.org
  Subject: Re: [openstack-dev] [nova][keystone] Nova calls to Keystone
 
  On 06/20/2015 02:46 PM, Sajeesh Cimson Sasi wrote:
 
  Hi All,
 I need your advice for the implementation of the following blueprint.
  https://review.openstack.org/#/c/160605 .
 All the use cases mentioned in the blueprint have  been implemented
 and
  the complete code is up for review.
https://review.openstack.org/#/c/149828/
However, we have an issue on which we need your input. In the nova
 quota
  api call, keystone calls are made to
get the parent_id and the child project or sub project list. This is
  required because nova doesn't store any information
regarding the hierarchy.

 This is maybe a dumb question, but...

 Could this information not come from the keystone middleware at the
 same time we get all the other identity information, and just live in
 the context?


Unfortunately no, the project hierarchy information is only available in
the GET /projects API - having this in the token so it could live in the
context could be a nice improvement (although this would need to feasible
for all types of tokens).


 Hierarchy Information is  taken during run time,
  from keystone. Since the keystone calls are
made inside the api call, it is not possible to give any dummy or  fake
  values while writing the unit tests. If the keystone
call was made outside the api call, we could have given fake values in
 the
  test cases. However,  the keystone calls for
 parent_id and child projects are made inside the api call.
Can anyone suggest an elegant solution to this problem? What is the
 proper
  way to implement this ?
  Did anybody encounter and solve a  similar  problem ? Many thanks for
  any suggestions!
   best regards
 sajeesh
 
 
 
 __
  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
 
  If you are talking to a live Keystone server, make sure you are using
 valid
  data.
 
  If you are not talking to a live keystone server in a unit test, use
  RequestsMock or equivalent (varied by project)  to handle the HTTP
 request
  and response.
 
  A worst case approach is to monkey patch the Keystoneclient.  Please
 don't
  do that if you can avoid it;  better to provide a mock alternative.
 
 
  Hi Adam,
 Thanks a lot. I am not planning to talk to the live
 keystone
  server in the unit test.
 I don't think that I need to monkey patch the
 KeystoneClient.
  In the nova api code, there are two methods (get_parent_project and
  get_immediate_child_list),which uses keystoneclient.I can monkey patch
 those
  two methods to return fixed data according to a fake hierarchy. Am I
 right ?
 
 
  Its not great, but not horrible.  It seems to match the scope of what you
  are testing.  However, you might want to consider doing a mock for the
 whole
  Keystoneclient call, as that really should beo utside of the unit test
 for
  the Nova code.
 

 Please use mock to do that for you, following the pattern of the
 existing Nova unit tests. I think you will find that easier.


Maybe point out where he can find similar tests?

Thanks!



 Thanks,
 John

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




-- 
Rodrigo Duarte Sousa
Senior Software Engineer at Advanced OpenStack Brazil
Distributed Systems Laboratory
MSc in Computer Science
Federal University of Campina Grande
Campina Grande, PB - Brazil
http://rodrigods.com http://lsd.ufcg.edu.br/%7Erodrigods
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] FFE Request for Reseller

2015-09-07 Thread Rodrigo Duarte
Hi all,

Although Steve is right about the amount of code that needs to land, the
code has received lots of iterations on top of it. If the team don't agree
in landing the whole patch chain, maybe agree with a reasonable cut for
Liberty (more 3 or 4 patches, for example) so we have good prospects for M.

Thanks,

On Sun, Sep 6, 2015 at 2:23 AM, Steve Martinelli <steve...@ca.ibm.com>
wrote:

> I suspect we'll vote on this topic during the next meeting on Tuesday, but
> this seems like a huge amount of code to land.
>
> Thanks,
>
> Steve Martinelli
> OpenStack Keystone Core
>
> [image: Inactive hide details for Henrique Truta ---2015/09/04 12:12:47
> PM---Hi Folks, As you may know, the Reseller Blueprint was prop]Henrique
> Truta ---2015/09/04 12:12:47 PM---Hi Folks, As you may know, the Reseller
> Blueprint was proposed and approved in Kilo (
>
> From: Henrique Truta <henriquecostatr...@gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: 2015/09/04 12:12 PM
> Subject: [openstack-dev] [keystone] FFE Request for Reseller
> --
>
>
>
> Hi Folks,
>
>
> As you may know, the Reseller Blueprint was proposed and approved in Kilo (
> *https://review.openstack.org/#/c/139824/*
> <https://review.openstack.org/#/c/139824/>) with the developing postponed
> to Liberty.
>
> During this time, the 3 main patches of the chain were split into 8,
> becoming smaller and easier to review. The first 2 of them were merged
> before liberty-3 freeze, and some of the others have already received +2s.
> The code is very mature, having a keystone core member support through the
> whole release cycle.
>
>
> I would like to request an FFE for the remaining 9 patches (reseller core)
> which are already in review (starting from
> *https://review.openstack.org/#/c/213448/*
> <https://review.openstack.org/#/c/213448/> to
> *https://review.openstack.org/#/c/161854/*
> <https://review.openstack.org/#/c/161854/>).
>
>
> Henrique
> __
> 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
>
>


-- 
Rodrigo Duarte Sousa
MSc in Computer Science
http://rodrigods.com <http://lsd.ufcg.edu.br/%7Erodrigods>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] PTL non-candidacy

2015-09-11 Thread Rodrigo Duarte
Thanks Morgan, it was a pleasure to have you contributing as PTL while
working with Keystone.

On Fri, Sep 11, 2015 at 4:52 PM, Yee, Guang <guang@hpe.com> wrote:

> Morgan, thanks for all your hard work. It’s been an honor to have you as
> our PTL.
>
>
>
> "All the world's a stage,”
>
>
>
> Now set back, relax, grab a drink, and enjoy the show. J
>
>
>
>
>
> Guang
>
>
>
>
>
> *From:* Morgan Fainberg [mailto:morgan.fainb...@gmail.com]
> *Sent:* Thursday, September 10, 2015 2:41 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [keystone] PTL non-candidacy
>
>
>
> As I outlined (briefly) in my recent announcement of changes (
> https://www.morganfainberg.com/blog/2015/09/09/openstack-career-act-3-scene-1/
> ) I will not be running for PTL of Keystone this next cycle (Mitaka). The
> role of PTL is a difficult but extremely rewarding job. It has been amazing
> to see both Keystone and OpenStack grow.
>
>
>
> I am very pleased with the accomplishments of the Keystone development
> team over the last year. We have seen improvements with Federation,
> Keystone-to-Keystone Federation, Fernet Tokens, improvements of testing,
> releasing a dedicated authentication library, cross-project initiatives
> around improving the Service Catalog, and much, much more. I want to thank
> each and every contributor for the hard work that was put into Keystone and
> its associated projects.
>
>
>
> While I will be changing my focus to spend more time on the general needs
> of OpenStack and working on the Public Cloud story, I am confident in those
> who can, and will, step up to the challenges of leading development of
> Keystone and the associated projects. I may be working across more
> projects, but you can be assured I will be continuing to work hard to see
> the initiatives I helped start through. I wish the best of luck to the next
> PTL.
>
>
>
> I guess this is where I get to write a lot more code soon!
>
>
>
> See you all (in person) in Tokyo!
>
> --Morgan
>
> __
> 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
>
>


-- 
Rodrigo Duarte Sousa
MSc in Computer Science
http://rodrigods.com <http://lsd.ufcg.edu.br/%7Erodrigods>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] New Core Reviewer (sent on behalf of Steve Martinelli)

2016-05-25 Thread Rodrigo Duarte
Thank you all, it's a privilege to be part of a team from where I've
learned so much. =)

On Wed, May 25, 2016 at 1:05 PM, Brad Topol <bto...@us.ibm.com> wrote:

> CONGRATULATIONS Rodrigo!!! Very well deserved!!!
>
> --Brad
>
>
> Brad Topol, Ph.D.
> IBM Distinguished Engineer
> OpenStack
> (919) 543-0646
> Internet: bto...@us.ibm.com
> Assistant: Kendra Witherspoon (919) 254-0680
>
> [image: Inactive hide details for Lance Bragstad ---05/25/2016 09:09:55
> AM---Congratulations Rodrigo! Thank you for all the continued a]Lance
> Bragstad ---05/25/2016 09:09:55 AM---Congratulations Rodrigo! Thank you for
> all the continued and consistent reviews.
>
> From: Lance Bragstad <lbrags...@gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: 05/25/2016 09:09 AM
> Subject: Re: [openstack-dev] [keystone] New Core Reviewer (sent on behalf
> of Steve Martinelli)
> --
>
>
>
> Congratulations Rodrigo!
>
> Thank you for all the continued and consistent reviews.
>
> On Tue, May 24, 2016 at 1:28 PM, Morgan Fainberg <
> *morgan.fainb...@gmail.com* <morgan.fainb...@gmail.com>> wrote:
>
>I want to welcome Rodrigo Duarte (rodrigods) to the keystone core
>team. Rodrigo has been a consistent contributor to keystone and has been
>instrumental in the federation implementations. Over the last cycle he has
>shown an understanding of the code base and contributed quality reviews.
>
>I am super happy (as proxy for Steve) to welcome Rodrigo to the
>Keystone Core team.
>
>Cheers,
>--Morgan
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe:
>*openstack-dev-requ...@lists.openstack.org?subject:unsubscribe*
><http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*
><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
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] Who is going to fix the broken non-voting tests?

2016-05-26 Thread Rodrigo Duarte
The function-nv was depending of a first test to be merged =)

The v3 depends directly on it, the difference is that it passes a flag to
deactivate v2.0 in devstack.

On Thu, May 26, 2016 at 5:48 PM, Steve Martinelli <s.martine...@gmail.com>
wrote:

> On Thu, May 26, 2016 at 12:59 PM, Adam Young <ayo...@redhat.com> wrote:
>
>> On 05/26/2016 11:36 AM, Morgan Fainberg wrote:
>>
>>
>>
>> On Thu, May 26, 2016 at 7:55 AM, Adam Young <ayo...@redhat.com> wrote:
>>
>>> Some mix of these three tests is almost always failing:
>>>
>>> gate-keystone-dsvm-functional-nv FAILURE in 20m 04s (non-voting)
>>> gate-keystone-dsvm-functional-v3-only-nv FAILURE in 32m 45s (non-voting)
>>> gate-tempest-dsvm-keystone-uwsgi-full-nv FAILURE in 1h 07m 53s
>>> (non-voting)
>>>
>>>
>>> Are we going to keep them running and failing, or boot them?  If we are
>>> going to keep them, who is going to commit to fixing them?
>>>
>>> We should not live with broken windows.
>>>
>>>
>>>
>> The uwsgi check should be moved to a proper run utilizing mod_proxy_uwsgi.
>>
>> Who wants to own this?  I am not fielding demands for uwsgi support
>> mysqlf, and kind of think it is just a novelty, thus would not mind see it
>> going away.  If someone really cares, please make yourself known.
>>
>
> Brant has a patch (https://review.openstack.org/#/c/291817/) that adds
> support in devstack to use uwsgi and mod_proxy_http. This is blocked until
> infra moves to Ubuntu Xenial. Once this merges we can propose a patch that
> swaps out the uwsgi job for uwsgi + mod_proxy_http.
>
>
>>
>>
>> The v3 only one is a WIP that a few folks are working on
>>
>> Fair enough.
>>
>> The function-nv one was passing somewhere. I think that one is close.
>>
>>
>> Yeah, it seems to be intermittant.
>>
>>
> These two are actively being worked on.
>
>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] Single Sign On integration research

2016-03-15 Thread Rodrigo Duarte
ailman/listinfo/openstack-dev*
><http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
> --
> Adam Heczko
> Security Engineer @ Mirantis Inc.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __
> 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
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tempest] Implementing tempest test for Keystone federation functional tests

2016-04-05 Thread Rodrigo Duarte
On Tue, Apr 5, 2016 at 11:53 AM, Minying Lu <m...@bu.edu> wrote:

> Thank you for your awesome feedbacks!
>
>
>> Another option is to add those tests to keystone itself (if you are not
>>> including tests that triggers other components APIs). See
>>> https://blueprints.launchpad.net/keystone/+spec/keystone-tempest-plugin-tests
>>>
>>>
>>
>>
> knikolla and I are looking into the keystone-tempest-plugin too thanks
> Rodrigo!
>
>
>> Again though, the problem is not where the tests live but where we run
>> them. To practically run these tests we need to either add K2K testing
>> support to devstack (not sure this is appropriate) or come up with a new
>> test environment that deploys 2 keystones and federation support that we
>> can CI against in the gate. This is doable but i think something we need
>> support with from infra before worrying about tempest.
>>
>>
> We have engineers in the team that are communicating with the infra team
> on how to set up a environment that runs the federation test. We're
> thinking about creating a 2 devstack setup with the keystones configured as
> Identity provider and service provider with federation support. Meanwhile I
> can just work on writing the test in a pre-configured environment that's
> the same as the 2 devstack setup.
>

Awesome, please share your work so I can help on that front too!


>
>
>>
>>
>>>
>>>> The fly in the ointment for this case will be CI though. For tests to
>>>> live in
>>>> tempest they need to be verified by a CI system before they can land.
>>>> So to
>>>> land the additional testing in tempest you'll have to also ensure there
>>>> is a
>>>> CI job setup in infra to configure the necessary environment. While I
>>>> think
>>>> this is a good thing to have in the long run, it's not necessarily a
>>>> small
>>>> undertaking.
>>>>
>>>
>>>> -Matt Treinish
>>>>
>>>>
>>>> __
>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>> Rodrigo Duarte Sousa
>>> Senior Quality Engineer @ Red Hat
>>> MSc in Computer Science
>>> http://rodrigods.com
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack 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
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [QA][all] Propose to remove negative tests from Tempest

2016-03-19 Thread Rodrigo Duarte
Totally agree here, also, having positive/negative API tests in Tempest
helps in the API stability effort. Although the API is owned by the service
in question, it interacts with other services and making sure the API is
stable is valuable for the communication between them.

We know a recent example where a change in keystone API caused a change in
Cinder.

On Thu, Mar 17, 2016 at 8:05 AM, Andrea Frittoli <andrea.fritt...@gmail.com>
wrote:

>
>
> On Thu, Mar 17, 2016 at 2:57 AM Ken'ichi Ohmichi <ken1ohmi...@gmail.com>
> wrote:
>
>> 2016-03-16 19:41 GMT-07:00 Jim Rollenhagen <j...@jimrollenhagen.com>:
>> > On Wed, Mar 16, 2016 at 06:20:11PM -0700, Ken'ichi Ohmichi wrote:
>> >> Hi
>> >>
>> >> I have one proposal[1] related to negative tests in Tempest, and
>> >> hoping opinions before doing that.
>> >>
>> >> Now Tempest contains negative tests and sometimes patches are being
>> >> posted for adding more negative tests, but I'd like to propose
>> >> removing them from Tempest instead.
>> >>
>> >> Negative tests verify surfaces of REST APIs for each component without
>> >> any integrations between components. That doesn't seem integration
>> >> tests which are scope of Tempest.
>> >> In addition, we need to spend the test operating time on different
>> >> component's gate if adding negative tests into Tempest. For example,
>> >> we are operating negative tests of Keystone and more
>> >> components on the gate of Nova. That is meaningless, so we need to
>> >> avoid more negative tests into Tempest now.
>> >>
>> >> If wanting to add negative tests, it is a nice option to implement
>> >> these tests on each component repo with Tempest plugin interface. We
>> >> can avoid operating negative tests on different component gates and
>> >> each component team can decide what negative tests are valuable on the
>> >> gate.
>> >>
>> >> In long term, all negative tests will be migrated into each component
>> >> repo with Tempest plugin interface. We will be able to operate
>> >> valuable negative tests only on each gate.
>> >
>> > So, positive tests in tempest, negative tests as a plugin.
>> >
>> > Is there any longer term goal to have all tests for all projects in a
>> > plugin for that project? Seems odd to separate them.
>>
>> Yeah, from implementation viewpoint, that seems a little odd.
>> but from the main scope of Tempest and to avoid unnecessary gate
>> operation time, that can be acceptable, I feel.
>> Negative tests can be corner cases in most cases, they don't seem
>> integration tests.
>>
>
> I think it's difficult to define a single black and white criteria for
> negative tests, as they encompass a wide range of types of tests.
>
> I agree that things that only testing the API level of a service (not even
> a DB behind) do not necessarily belong in tempest - i.e. testing of input
> validation done by an API.  We could have a guideline for such tests to be
> implemented as unit/functional tests in tree of the service.
>
> However Tempest is also interoperability, so we should keep at least a few
> negative API checks in tempest (for the core six services) to enforce that
> return codes do not change inadvertently in negative cases, which could
> break existing clients and applications.
>
> If a project was to move all negative tests out of tempest, than they
> might consider have hacking rules to prevent modifying the code and tests
> at the same time, and change behaviour inadvertently.
>
> andrea
>
>
>>
>> Thanks
>> Ken Ohmichi
>>
>> __________
>> 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
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tempest] Implementing tempest test for Keystone federation functional tests

2016-04-01 Thread Rodrigo Duarte
On Thu, Mar 31, 2016 at 1:11 PM, Matthew Treinish <mtrein...@kortar.org>
wrote:

> On Thu, Mar 31, 2016 at 11:38:55AM -0400, Minying Lu wrote:
> > Hi all,
> >
> > I'm working on resource federation at the Massachusetts Open Cloud. We
> want
> > to implement functional test on the k2k federation, which requires
> > authentication with both a local keystone and a remote keystone (in a
> > different cloud installation). It also requires a K2K/SAML assertion
> > exchange with the local and remote keystones. These functions are not
> > implemented in the current tempest.lib.service library, so I'm adding
> code
> > to the service library.
> >
> > My question is, is it possible to adapt keystoneauth python clients? Or
> do
> > you prefer implementing it with http requests.
>
> So tempest's clients have to be completely independent. That's part of
> tempest's
> design points about testing APIs, not client implementations. If you need
> to add
> additional functionality to the tempest clients that's fine, but pulling in
> keystoneauth isn't really an option.
>

++


>
> >
> > And since this test requires a lot of environment set up including: 2
> > separate cloud installations, shibboleth, creating mapping and protocols
> on
> > remote cloud, etc. Would it be within the scope of tempest's mission?
>
> From the tempest perspective it expects the environment to be setup and
> already
> exist by the time you run the test. If it's a valid use of the API, which
> I'd
> say this is and an important one too, then I feel it's fair game to have
> tests
> for this live in tempest. We'll just have to make the configuration options
> around how tempest will do this very explicit to make sure the necessary
> environment exists before the tests are executed.
>

Another option is to add those tests to keystone itself (if you are not
including tests that triggers other components APIs). See
https://blueprints.launchpad.net/keystone/+spec/keystone-tempest-plugin-tests


>
> The fly in the ointment for this case will be CI though. For tests to live
> in
> tempest they need to be verified by a CI system before they can land. So to
> land the additional testing in tempest you'll have to also ensure there is
> a
> CI job setup in infra to configure the necessary environment. While I think
> this is a good thing to have in the long run, it's not necessarily a small
> undertaking.
>

> -Matt Treinish
>
> __
> 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
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] How to single sign on with windows authentication with Keystone

2016-05-19 Thread Rodrigo Duarte
Hi,

So you are trying to use keystone to authorize your users, but want to
avoid having to authenticate via keystone, right?

Check if the Federated Identity feature [1] covers your use case.

[1]
http://docs.openstack.org/security-guide/identity/federated-keystone.html

On Thu, May 19, 2016 at 8:27 AM, OpenStack Mailing List Archive <
cor...@gmail.com> wrote:

> Link: https://openstack.nimeyo.com/85057/?show=85057#q85057
> From: imocha <imo...@gmail.com>
>
> I have to call the keystone APIs and want to use the windows
> authentication using Active Directory. Keystone provides integration with
> AD at the back end. To get the initial token to use OpenStack APIs, I need
> to pass user name and password in the keystone token creation api.
>
> Since I am already logged on to my windows domain, is there any way that I
> can get the token without passing the password in the api.
>
> __
> 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
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [cinder] [keystone] cinder quota behavior differences after Keystone mitaka upgrade

2016-06-28 Thread Rodrigo Duarte
On Tue, Jun 28, 2016 at 3:38 AM, Henry Nash <henryna...@mac.com> wrote:

> Hi Matt,
>
> So the keystone changes were intentional. From Mitaka onwards, a domain is
> represented as a project which is “acting as a domain” (it has an attribute
> “is_domain” set to true). The situation you describe, where what were top
> level projects now have the project acting as the default domain as their
> parent, is what I would expect to happen after the update.
>
> During Mitaka development, we  worked with the cinder folks - who were to
> re-designing their quota code anyway - and this was modified to take
> account of the project structure. I’m not sure if the quota semantics you
> see are what was intended (I’ll let the cinder team comment). Code can, if
> desired, distinguish the case of top projects that are at the top level, vs
> projects somewhere way down the hierarchy, by looking at the parent and
> seeing if it is a project acting as a domain.
>

Just to add to Henry's answer, checking if the parent is a project acting
as a domain is just matter of comparing the parent_id with the domain_id,
if they are equal, it means the parent is a project acting as a domain.


>
> Henry
> keystone core
>
> On 27 Jun 2016, at 17:13, Matt Fischer <m...@mattfischer.com> wrote:
>
> We upgraded our dev environment last week to Keystone stable/mitaka. Since
> then we're unable to show or set quotas on projects of which the admin is
> not a member. Looking at the cinder code, it seems that cinder is pulling a
> project list and attempting to determine a hierarchy.  On Liberty Keystone,
> projects seem to lack parents:
>
>  id=9e839870dd0d4a2f96f9d71b7e7c5a4e, is_domain=False, links={u'self': u'
> https://liberty-endpoint:5000/v3/projects/9e839870dd0d4a2f96f9d71b7e7c5a4e'},
> name=admin, parent_id=None, subtree=None>
>
> In Mitaka, it seems that projects are children of the default domain:
>
>  id=4764ba822ecb43e582794b875751924c, is_domain=False, links={u'self': u'
> http://mitaka-endpoint:5000/v3/projects/4764ba822ecb43e582794b875751924c'},
> name=admin, parent_id=default, subtree=None>
>
> In Liberty since all projects were parentless, the authorize_* code blocks
> were skipped since both conditionals were false:
>
>
> https://github.com/openstack/cinder/blob/stable/liberty/cinder/api/contrib/quotas.py#L174-L191
>
> But now in Mitaka, the code is run, and it fails out since the projects
> are "brothers", both with the parent of the default domain, but not
> hierarchically related.
>
> Previously it was a useful ability for us to be able to (as admins) set
> and view  quotas for cinder projects. Now we need to scope into the user's
> project to even be able to view their quotas, much less change them. This
> seems broken, but I'm not sure where the issue is or why the keystone
> behavior changed. Is this the expected behavior?
>
> __
> 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
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [QA] Announcing my candidacy for PTL of the Pike cycle

2017-02-07 Thread Rodrigo Duarte
upport
>> > microversion which provides a way to introduce the APIs changes in
>> Backward
>> > compatible way. I'd like to concentrate on response schema validation
>> for
>> > those projects also. This helps the OpenStack interoperability and the
>> APIs
>> > compatibility.
>> >
>> >
>> >
>> > * Improve Documentation and UX:
>> >
>> > Documentation and UX are the key part for any software. There have been
>> huge
>> > improvement in UX , documentation side and new Tempest workflow is
>> > available.  Still configuration and usage is the pain point for Users.
>> > During summit/ptg or other platforms I’d like us to have more feedbacks
>> from
>> > users and improve accordingly. Making configuration easy for people is
>> one
>> > of the area we will be focusing on.
>> >
>> >
>> >
>> > * Bring on more contributor and core reviewers:
>> >
>> > QA projects have been one of the active projects during last couple of
>> years
>> > and I'd like the team to mentor new contributors to help QA projects in
>> > planned goal and get them to a place where they will be ready for core
>> > reviewers.
>> >
>> >
>> >
>> > * Migrate required Tempest Interfaces as stable to lib:
>> >
>> > We together have done great job in this area which helped plugin tests.
>> In
>> > Service clients migration, Object Storage service client are left and
>> all
>> > others have been moved as stable interfaces. Lot of others
>> > framework/interface also available in lib. But still lot of unstable
>> > interfaces are being used in Plugins which should be migrated to lib
>> soon.
>> > In Pike cycle, we will wind up all remaining service client migration
>> and
>> > other required interfaces.
>> >
>> >
>> >
>> > * Last but not the least, Openness is great power of Open Source and so
>> does
>> > OpenStack. All new ideas from anyone will be most welcome.
>> >
>> >
>> >
>> > Thanks to previous QA PTL, Sean, Matthew, Kenichi who have shown great
>> > leadership quality and taken QA projects to a new height. I have learnt
>> a
>> > lot from them which motivates me.
>> >
>> >
>> >
>> > I look forward to contributing to all of these areas and more during the
>> > Pike cycle.
>> >
>> >
>> >
>> > -gmann
>> >
>> >
>> >
>> >
>> > 
>> __
>> > 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
>> >
>>
>> --
>>
>> <http://go.scality.com/acton/media/18585/gartner-magic-
>> quadrant-object-storage?utm_campaign=MQ_medium=Email&
>> utm_source=signatures>
>>
>> 
>> __
>> 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
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] removing Guang Yee (gyee) from keystone-core

2017-02-02 Thread Rodrigo Duarte
Thanks for everything Guang! We are already missing you.

On Thu, Feb 2, 2017 at 10:13 AM, Steve Martinelli <s.martine...@gmail.com>
wrote:

> Due to inactivity and a change in his day job, Guang was informed that he
> would be removed from keystone-core, a change he understands and supports.
>
> I'd like to publicly thank Guang for his years of service as a core
> member. He juggled upstream and downstream responsibilities at HP while
> bringing real world use cases to the table.
>
> Thanks for everything Guang, o\
>
> Steve
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Subject: [Keystone][Tempest][QA] Tempest full fails with policy.v3cloudsample.json and gate is using old policy.json

2017-01-24 Thread Rodrigo Duarte
on to grant
> cloud_admin if the project is the admin domain then that seems to fix
> things. The change I'm trying is:
>
>  3c3,4
> < "cloud_admin": "role:admin and (token.is_admin_project:True or
> domain_id:admin_domain_id)",
> ---
> > "bob": "project_domain_id:363ab68785c24c81a784edca1bceb935 or
> domain_id:363ab68785c24c81a784edca1bceb935",
> > "cloud_admin": "role:admin and (token.is_admin_project:True or
> rule:bob)",
>
> I did notice this comment on Bug #1451987 *4:
>
> If you see following errors for all identity api v3 tests, then please be
> known that its not a a bug in tempest, rather you need to change keystone
> v3 policy.json and make it more relaxed so tempest can authorize with users
> created for each test with separate projects(tenants) because we set
> tenant_isolation to True in tempest.conf ...
>
> This suggests to me that it is expected for policy.json to need tweaking.
>
> Regards
> Liam
>
> *1 https://github.com/openstack/keystone/blob/stable/newton/
> etc/policy.v3cloudsample.json
> *2 http://logs.openstack.org/66/418166/10/check/gate-
> keystone-dsvm-functional-v3-only-ubuntu-xenial-nv/fc0af39/
> logs/etc/keystone/policy.json.txt.gz
> *3 https://github.com/openstack/keystone/blob/master/etc/policy.json
> *4 https://bugs.launchpad.net/tempest/+bug/1451987/comments/2
>
> __
> 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
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] User survey feedback

2017-02-20 Thread Rodrigo Duarte
That's a nice feedback! Now we have a great way to know where to push
harder.

On Mon, Feb 20, 2017 at 5:34 PM, Lance Bragstad <lbrags...@gmail.com> wrote:

> As you may have noticed from other threads, we have some early feedback
> available from the User Survey. It hasn't closed yet - and I'm sure we'll
> get updated results once that happens, but the early feedback will be nice
> to have going into project discussions at the PTG.
>
> The question and responses are as follows:
>
> *In your opinion, where should the Keystone development team focus their
> effort(s)?*
>
> *Possible responses:*
>
> Enhancing policy
> Per domain configuration
> Federated identity enhancements
> Scaling out to multiple regions
> Performance improvements
> Other (with the option to give specific feedback)
>
> The following is a breakdown of the responses:
>
> Federated identity enhancements: *62* responses
> Scaling out to multiple regions: *62* responses
> Performance improvements: *51* responses
> Enhancing policy: *46* responses
> Per domain configuration: *41* responses
> Other: *5 *responses
>
> The following are the 5 Other responses directly from users taking the
> survey:
>
> "1: Better delegation of project admin rights (project admin should be
> able to easily add sub projects and users). Should work with federation. 2:
> AWS IAM role like functionality. Delegation of rights to instances. "
>
> "delegation is still very corse. Needs a way to do fine grained delegation
> and resource level delegation."
>
> "Easier role customization."
>
> "Role based access control- like we have in the corporates. restriction
> based on per API / Functionality bassis. And a user should be able to
> create sub-users for his / her account with RBAC."
>
> "User based policy"
>
>
> I'll post updates here if I get any more information/data regarding the
> feedback.
>
> Thanks,
>
> Lance
>
> __
> 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
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone][defcore][refstack] Removal of the v2.0 API

2017-03-01 Thread Rodrigo Duarte
On Wed, Mar 1, 2017 at 7:10 PM, Lance Bragstad <lbrags...@gmail.com> wrote:

> During the PTG, Morgan mentioned that there was the possibility of
> keystone removing the v2.0 API [0]. This thread is a follow up from that
> discussion to make sure we loop in the right people and do everything by
> the books.
>
> The result of the session [1] listed the following work items:
> - Figure out how we can test the removal and make the job voting (does the
> v3-only job count for this)?
>

We have two v3-only jobs, one only runs keystone's tempest plugin tests -
which are specific to federation (it configures a federated environment
using mod_shib) - and another one (non-voting) that runs tempest, I believe
the later can be a good way to initially validate the v2.0 removal.


> - Reach out to defcore and refstack communities about removing v2.0 (which
> is partially what this thread is doing)
>
> Outside of this thread, what else do we have to do from a defcore
> perspective to make this happen?
>
> Thanks for the time!
>
> [0] https://review.openstack.org/#/c/437667/
> [1] https://etherpad.openstack.org/p/pike-ptg-keystone-deprecations
>
> __
> 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
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] new core reviewer (rderose)

2016-09-01 Thread Rodrigo Duarte
Thanks for the good work. Congrats, Ron!

On Thu, Sep 1, 2016 at 12:21 PM, Adam Young <ayo...@redhat.com> wrote:

> On 09/01/2016 10:44 AM, Steve Martinelli wrote:
>
> I want to welcome Ron De Rose (rderose) to the Keystone core team. In a
> short time Ron has shown a very positive impact. Ron has contributed
> feature work for shadowing LDAP and federated users, as well as enhancing
> password support for SQL users. Implementing these features and picking up
> various bugs along the way has helped Ron to understand the keystone code
> base. As a result he is able to contribute to the team with quality code
> reviews.
>
> Thanks for all your hard work Ron, we sincerely appreciate it.
>
> Steve
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> I want to state that I (jokingly) opposed Ron's inclusion as core.
>
> Not because he didn't earn it. He very much earned it.
>
> But because Ron is doing amazing work actually writing code for Keystone,
> and I don't know that we can spare him to now review code, too.
>
> Fantastic work, Ron.  Keep it up.
>
> __
> 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
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron] Skip-only tests

2016-09-13 Thread Rodrigo Duarte
On Thu, Sep 8, 2016 at 12:44 PM, Joe Hakim Rahme <jhaki...@redhat.com>
wrote:

> On Thu, 2016-09-08 at 10:36 +0200, Andreas Jaeger wrote:
> >
> > Toni, sorry, I wasn't clear. I'm not advocating for this, I wanted to
> > bring Joe into this discussion to see whether the solution that John
> > suggested will help them as well - I wanted to broaden the scope of
> > this since it's not only neutron that faces this.
> >
>
> Hi,
>
> Just to be clear, my intention with the repo I'm trying to create is
> to hold tests that are not acceptable in upstream Tempest by design
> (mainly whitebox testing). I think what John was referring to (correct
> me if I'm wrong) are tests that are acceptable Tempest tests but we
> lack the required infrastrcuture (hardware, images, ...) to run them
> in the gate.
>
> I realize now that the name I chose "nova-tempest-staging" might be
> misleading and I think it should be changed. Maybe something like
> "tempest-whitebox-plugin" might be more descriptive?
>

This sounds like a generic repo, not specific or tied to service. Not being
specific sounds much better to me.

I liked the idea and would be willing to help out in the effort, but agree
it needs more thorough discussion.


>
> As for the topic of skip-only tests, I think that it'd be a shame to
> reject valid and valuable tests simply because the gate is not equipped
> to run them. There are use cases for Tempest outside of the upstream
> gate, so marking certain tests as valid-but-skipped-in-the-gate seems
> like an acceptable solution to me.
>
> (I'm not a maintainer of the Tempest repo so please take my opinion
> with a grain of salt).
>
> Cheers,
> Joe
>
> __
> 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
>



-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] gate-keystoneclient-dsvm-functional-ubuntu-xenial is broken

2016-09-21 Thread Rodrigo Duarte
Forgot to add the commit reference :)

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

On Wed, Sep 21, 2016 at 10:59 AM, Rodrigo Duarte <rodrigodso...@gmail.com>
wrote:

> After some investigation I've found the possible issue: the functional
> tests run in parallel, some of them create and delete roles and others use
> tokens to perform the creation/update/delete of other types of fixtures.
> The problem is that when we delete a role, we also revoke *all* tokens
> from a user that has any assignment containing that role - so? Race
> condition: if we are executing a not related operation and another test
> deletes a role, the user tokens will be revoked resulting in a request
> error.
>
> The strange part is that reverting this commit [1], the tests seem to work
> fine most of the times - what makes think that commit actually *fixes* a
> big issue in our revoke events (since before it, we would not revoke such
> types of tokens).
>
> I can see a couple of options:
> - Create brand new users and role_assignments to be responsible to handle
> operations in the fixtures for each test
> - Change the "framework" of the tests and rely on tempest plugins
>
> What to think? Makes sense?
>
> On Tue, Sep 20, 2016 at 11:03 AM, Steve Martinelli <s.martine...@gmail.com
> > wrote:
>
>> Since September 14th the keystoneclient functional test job has been
>> broken. Let's be mindful of infra resources and stop rechecking the patches
>> there. Anyone have time to investigate this?
>>
>> See patches https://review.openstack.org/#/c/369469/ or
>> https://review.openstack.org/#/c/371324/
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Rodrigo Duarte Sousa
> Senior Quality Engineer @ Red Hat
> MSc in Computer Science
> http://rodrigods.com
>



-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] gate-keystoneclient-dsvm-functional-ubuntu-xenial is broken

2016-09-21 Thread Rodrigo Duarte
After some investigation I've found the possible issue: the functional
tests run in parallel, some of them create and delete roles and others use
tokens to perform the creation/update/delete of other types of fixtures.
The problem is that when we delete a role, we also revoke *all* tokens from
a user that has any assignment containing that role - so? Race condition:
if we are executing a not related operation and another test deletes a
role, the user tokens will be revoked resulting in a request error.

The strange part is that reverting this commit [1], the tests seem to work
fine most of the times - what makes think that commit actually *fixes* a
big issue in our revoke events (since before it, we would not revoke such
types of tokens).

I can see a couple of options:
- Create brand new users and role_assignments to be responsible to handle
operations in the fixtures for each test
- Change the "framework" of the tests and rely on tempest plugins

What to think? Makes sense?

On Tue, Sep 20, 2016 at 11:03 AM, Steve Martinelli <s.martine...@gmail.com>
wrote:

> Since September 14th the keystoneclient functional test job has been
> broken. Let's be mindful of infra resources and stop rechecking the patches
> there. Anyone have time to investigate this?
>
> See patches https://review.openstack.org/#/c/369469/ or
> https://review.openstack.org/#/c/371324/
>
> __
> 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
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [keystone][qa] PCI-DSS (security compliance tests)

2016-10-14 Thread Rodrigo Duarte
Hi all,

Recently in keystone we got merged the PCI-DSS feature [1]. Basically, we
have new settings that enforce password security practices. For example, if
we set the password history setting to 2, a user won't be able to update
its password to one of the last 2 that have been set in the past.

The issue is that, this settings, can break a couple of tests in Tempest.
Assuming the non-admin users in this tests don't affect any other test,
I've inserted a "security_compliance" feature flag and skipped the portion
of the tests that can break when the PCI-DSS settings are enabled [2].

With that, I've pushed another patch that sets these settings upon DevStack
deployment [3] and added the actual tests for the feature at [4]. So we
have a "tempest -> devstack -> tempest" chain of patches dependencies.

I want your feedback regarding this, if this approach is acceptable and, if
not, what are the options.

Thanks!

[1] https://blueprints.launchpad.net/keystone/+spec/pci-dss
[2] https://review.openstack.org/#/c/382018/
[3] https://review.openstack.org/#/c/377004/
[4] https://review.openstack.org/#/c/378624/

-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] Pike PTL

2016-11-21 Thread Rodrigo Duarte
On Mon, Nov 21, 2016 at 5:22 PM, Lance Bragstad <lbrags...@gmail.com> wrote:

> Steve, thanks for all the hard work and dedication over the last 3 cycles.
> I hope you have a nice break and I look forward to working with you on Pike!
>

I could not say better! Thanks for everything Steve.


>
> Enjoy you're evenings :)
>

I'm sure they will be full of Harry! :)


>
>
>
> On Mon, Nov 21, 2016 at 1:38 PM, Steve Martinelli <s.martine...@gmail.com>
> wrote:
>
>> one of these days i'll learn how to spell :)
>>
>> On Mon, Nov 21, 2016 at 12:52 PM, Steve Martinelli <
>> s.martine...@gmail.com> wrote:
>>
>>> Keystoners,
>>>
>>> I do not intend to run for the PTL position of the Pike development
>>> cycle. I'm sending this out early so I can work with folks interested in
>>> the role, If you intend to run for PTL in Pike and are interested in
>>> learning the ropes (or just want to hear more about what the role means)
>>> then shoot me an email.
>>>
>>> It's been an unforgettable ride. Being PTL a is very rewarding
>>> experience, I encourage anyone interested to put your name forward. I'm
>>> not going away from OpenStack, I just think three terms as PTL has been
>>> enough. It'll be nice to have my evenings back :)
>>>
>>> To *all* the keystone contributors (cores and non-cores), thank you for
>>> all your time and commitment. More importantly thank you for putting up
>>> with my many questions, pings, pokes and -1s. Each of you are amazing and
>>> together you make an awesome team. It has been an absolute pleasure to
>>> serve as PTL, thank you for letting me do so.
>>>
>>> stevemar
>>>
>>>
>>> 
>>>
>>> Thanks for the idea Lana [1]
>>> [1] http://lists.openstack.org/pipermail/openstack-docs/2016
>>> -November/009357.html
>>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] Stepping down from keystone core

2016-11-24 Thread Rodrigo Duarte
Thanks for everything Marek, good times when we debugged federation issues!
:)

On Wed, Nov 23, 2016 at 1:05 PM, Henry Nash <henryna...@mac.com> wrote:

> Echoing the comments of others. - thanks for all your hard work and
> expertise.
>
> Henry
>
> On 23 Nov 2016, at 15:05, Lance Bragstad <lbrags...@gmail.com> wrote:
>
> Thanks for all your hard work, Marek. It's been a pleasure working with
> you. Best of luck and hopefully our paths cross in the future!
>
> On Tue, Nov 22, 2016 at 7:57 PM, Steve Martinelli <s.martine...@gmail.com>
> wrote:
>
>> Marek, thanks for everything you've done in Keystone. It was loads of fun
>> to develop some of the early federation work with you back in the Icehouse
>> release! Good luck in whatever the future holds for you!
>>
>> On Tue, Nov 22, 2016 at 5:18 PM, Marek Denis <
>> marek.denis+openst...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Due to my current responsibilities I cannot serve as keystone core
>>> anymore. I also feel I should make some space for others who will surely
>>> bring new quality to the OpenStack Identity Program.
>>>
>>> It's been a great journey, I surely learned a lot and improved both my
>>> technical and soft skills. I can only hope my contributions and reviews
>>> have been useful and made OpenStack a little bit better.
>>>
>>> I wish you all the best in the future.
>>>
>>> With kind regards,
>>> Marek Denis
>>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] new keystone core (breton)

2016-11-02 Thread Rodrigo Duarte
Congrats Boris! Very well deserved!

On Tue, Nov 1, 2016 at 9:17 PM, Jamie Lennox <jamielen...@gmail.com> wrote:

> Congrats Boris, Great to have new people on board. Well earned.
>
> On 1 November 2016 at 15:53, Brad Topol <bto...@us.ibm.com> wrote:
>
>> Congratulations Boris!!! Very well deserved!!!
>>
>> --Brad
>>
>>
>> Brad Topol, Ph.D.
>> IBM Distinguished Engineer
>> OpenStack
>> (919) 543-0646
>> Internet: bto...@us.ibm.com
>> Assistant: Kendra Witherspoon (919) 254-0680
>>
>> [image: Inactive hide details for Steve Martinelli ---10/31/2016 03:51:29
>> PM---I want to welcome Boris Bobrov (breton) to the keystone]Steve
>> Martinelli ---10/31/2016 03:51:29 PM---I want to welcome Boris Bobrov
>> (breton) to the keystone core team. Boris has been a contributor for
>>
>> From: Steve Martinelli <s.martine...@gmail.com>
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> Date: 10/31/2016 03:51 PM
>> Subject: [openstack-dev] [keystone] new keystone core (breton)
>> --
>>
>>
>>
>> I want to welcome Boris Bobrov (breton) to the keystone core team. Boris
>> has been a contributor for some time and is well respected by the keystone
>> team for bringing real-world operator experience and feedback. He has
>> recently become more active in terms of code contributions and bug
>> triaging. Upon interacting with Boris, you quickly realize he has a high
>> standard for quality and keeps us honest.
>>
>> Thanks for all your hard work Boris, I'm happy to have you on the team.
>>
>> Steve Martinelli
>> stevemar
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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:unsubscrib
>> e
>> 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
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone][qa] PCI-DSS (security compliance tests)

2016-10-14 Thread Rodrigo Duarte
On Fri, Oct 14, 2016 at 1:10 PM, Clark Boylan <cboy...@sapwetik.org> wrote:

> On Fri, Oct 14, 2016, at 08:21 AM, Rodrigo Duarte wrote:
> > Hi all,
> >
> > Recently in keystone we got merged the PCI-DSS feature [1]. Basically, we
> > have new settings that enforce password security practices. For example,
> > if
> > we set the password history setting to 2, a user won't be able to update
> > its password to one of the last 2 that have been set in the past.
> >
> > The issue is that, this settings, can break a couple of tests in Tempest.
> > Assuming the non-admin users in this tests don't affect any other test,
> > I've inserted a "security_compliance" feature flag and skipped the
> > portion
> > of the tests that can break when the PCI-DSS settings are enabled [2].
> >
> > With that, I've pushed another patch that sets these settings upon
> > DevStack
> > deployment [3] and added the actual tests for the feature at [4]. So we
> > have a "tempest -> devstack -> tempest" chain of patches dependencies.
>
> Curious why the tests for this wouldn't go into the keystone functional
> job [5] which appear to run as a tempest plugin? Testing of these
> features shouldn't require any other service, just keystone right
> (though this job does start and run other services)? One big reason I
> ask is it could help constrain the testing of non default behaviors of
> keystone to a single job rather than needing to edit a bunch of other
> jobs or create new jobs just to toggle the non default behavior.
>

That was the plan initially, but we considered two things:

1 - The users API is a pretty widely used API, so having it running in
Tempest makes sense
2 - We need to add new settings in Tempest's config - I know that we can
"inherit" the Tempest config's in the plugin, but looks strange having some
stuff not actually used in Tempest but set there.

But... If the both things above are acceptable, or even preferable, we can
change the approach.


>
> >
> > I want your feedback regarding this, if this approach is acceptable and,
> > if
> > not, what are the options.
>
> I don't really know which approach is more preferable but I think that
> functional testing is an option too.


> >
> > Thanks!
> >
> > [1] https://blueprints.launchpad.net/keystone/+spec/pci-dss
> > [2] https://review.openstack.org/#/c/382018/
> > [3] https://review.openstack.org/#/c/377004/
> > [4] https://review.openstack.org/#/c/378624/
> >
>
> [5]
> http://logs.openstack.org/56/371856/5/gate/gate-keystone-
> dsvm-functional-ubuntu-xenial/c9f937c/
>
> Clark
>
> ______
> 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
>



-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone][qa] PCI-DSS (security compliance tests)

2016-10-14 Thread Rodrigo Duarte
On Fri, Oct 14, 2016 at 2:23 PM, Rodrigo Duarte <rodrigodso...@gmail.com>
wrote:

>
>
> On Fri, Oct 14, 2016 at 1:10 PM, Clark Boylan <cboy...@sapwetik.org>
> wrote:
>
>> On Fri, Oct 14, 2016, at 08:21 AM, Rodrigo Duarte wrote:
>> > Hi all,
>> >
>> > Recently in keystone we got merged the PCI-DSS feature [1]. Basically,
>> we
>> > have new settings that enforce password security practices. For example,
>> > if
>> > we set the password history setting to 2, a user won't be able to update
>> > its password to one of the last 2 that have been set in the past.
>> >
>> > The issue is that, this settings, can break a couple of tests in
>> Tempest.
>> > Assuming the non-admin users in this tests don't affect any other test,
>> > I've inserted a "security_compliance" feature flag and skipped the
>> > portion
>> > of the tests that can break when the PCI-DSS settings are enabled [2].
>> >
>> > With that, I've pushed another patch that sets these settings upon
>> > DevStack
>> > deployment [3] and added the actual tests for the feature at [4]. So we
>> > have a "tempest -> devstack -> tempest" chain of patches dependencies.
>>
>> Curious why the tests for this wouldn't go into the keystone functional
>> job [5] which appear to run as a tempest plugin? Testing of these
>> features shouldn't require any other service, just keystone right
>> (though this job does start and run other services)? One big reason I
>> ask is it could help constrain the testing of non default behaviors of
>> keystone to a single job rather than needing to edit a bunch of other
>> jobs or create new jobs just to toggle the non default behavior.
>>
>
> That was the plan initially, but we considered two things:
>
> 1 - The users API is a pretty widely used API, so having it running in
> Tempest makes sense
> 2 - We need to add new settings in Tempest's config - I know that we can
> "inherit" the Tempest config's in the plugin, but looks strange having some
> stuff not actually used in Tempest but set there.
>
> But... If the both things above are acceptable, or even preferable, we can
> change the approach.
>

Turns out there were smarter ways to restore the user credentials after the
tests run, we won't need the first tempest patch after all.

Submitted the new changes at [4].


>
>
>>
>> >
>> > I want your feedback regarding this, if this approach is acceptable and,
>> > if
>> > not, what are the options.
>>
>> I don't really know which approach is more preferable but I think that
>> functional testing is an option too.
>
>
>> >
>> > Thanks!
>> >
>> > [1] https://blueprints.launchpad.net/keystone/+spec/pci-dss
>> > [2] https://review.openstack.org/#/c/382018/
>> > [3] https://review.openstack.org/#/c/377004/
>> > [4] https://review.openstack.org/#/c/378624/
>> >
>>
>> [5]
>> http://logs.openstack.org/56/371856/5/gate/gate-keystone-dsv
>> m-functional-ubuntu-xenial/c9f937c/
>>
>> Clark
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Rodrigo Duarte Sousa
> Senior Quality Engineer @ Red Hat
> MSc in Computer Science
> http://rodrigods.com
>



-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] office hours starting January 6th

2016-12-21 Thread Rodrigo Duarte
Thanks for the initiative! This is something that both keystone and the
community will benefit! :)

On Wed, Dec 21, 2016 at 4:22 PM, Steve Martinelli <s.martine...@gmail.com>
wrote:

> Thanks for setting this up Lance!
>
> You can count on me to join and smash some bugs.
>
> On Wed, Dec 21, 2016 at 1:06 PM, Lance Bragstad <lbrags...@gmail.com>
> wrote:
>
>> Hi folks!
>>
>> If you remember, last year we started a weekly bug day [0]. The idea was
>> to dedicate one day a week to managing keystone's bug queue by triaging,
>> fixing, and reviewing bugs. This was otherwise known as keystone's office
>> hours.
>>
>> I'd like to remind everyone that we are starting up this initiative
>> again, right after the New Year. Our first bug day this year will be
>> Friday, January 6th, and it will be recurring every Friday after that.
>>
>> Previously, we used the etherpad [1] to track the status of patches and
>> bugs through the day. This time around, I'd like to see if we can keep
>> state out of the etherpad in favor of Gerrit dashboards and IRC (which are
>> easier to log and track). The etherpad now consists of information about
>> the event, which should eventually be moved into a wiki somewhere.
>>
>> I wanted to get this out the door before the holidays so that people can
>> get it on their calendar. We can also use this thread to air out any
>> questions about office hours before the January 6th.
>>
>> Thanks and have a safe holiday season!
>>
>> Lance
>>
>>
>> [0] http://lists.openstack.org/pipermail/openstack-dev/2015-
>> October/076649.html
>> [1] https://etherpad.openstack.org/p/keystone-office-hours
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] slide deck

2017-03-15 Thread Rodrigo Duarte
Thanks Lance, this is very useful.

On Tue, Mar 14, 2017 at 11:07 PM, Lance Bragstad <lbrags...@gmail.com>
wrote:

> Of course I would make changes to the template *right* after sending this
> email. I'll just share the presentation that I have [0].
>
> https://docs.google.com/presentation/d/1s9BNHI4aHs_
> fEcCYuekDCFwMg1VTsKCHMkSko92Gqco/edit?usp=sharing
>
> On Tue, Mar 14, 2017 at 8:54 PM, Lance Bragstad <lbrags...@gmail.com>
> wrote:
>
>> Hi all,
>>
>> With the forum approaching, I threw together a slide deck that
>> incorporates the new mascot. I wanted to send this out in enough advance
>> for folks to use them at the forum.
>>
>> This is in no way our *official* deck and you're not required to use it
>> for keystone related talks or presentations. It's just something you can
>> use if you wish. If you make edits, or have invested time into your own
>> decks and feel like sharing, let me know. I think it would be great to have
>> several decks available for people to choose from.
>>
>> Thanks,
>>
>> Lance
>>
>
>
> __
> 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
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Keystone] Admin or certain roles should be able to list full project subtree

2017-03-16 Thread Rodrigo Duarte
On Thu, Mar 16, 2017 at 2:46 PM, Morgan Fainberg <morgan.fainb...@gmail.com>
wrote:

>
>
> On Mar 16, 2017 07:28, "Jeremy Stanley" <fu...@yuggoth.org> wrote:
>
> On 2017-03-16 08:34:58 -0500 (-0500), Lance Bragstad wrote:
> [...]
> > These security-related corner cases have always come up in the past when
> > we've talked about implementing reseller. Another good example that I
> > struggle with is what happens when you flip the reseller bit for a
> project
> > admin who goes off and creates their own entities but then wants support?
> > What does the support model look like for the project admin that needs
> help
> > in a way that maintains data integrity?
>
> It's still entirely unclear to me how giving someone the ability to
> hide resources you've delegated them access to create in any way
> enables "reseller" use cases. I can understand the global admins
> wanting to have optional views where they don't see all the resold
> hierarchy (for the sake of their own sanity), but why would a
> down-tree admin have any expectation they could reasonably hide
> resources they create from those who maintain the overall system?
>
> In other multi-tenant software I've used where reseller
> functionality is present, top-level admins have some means of
> examining delegated resources and usually even of impersonating
> their down-tree owners for improved supportability.
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> Hiding projects is a lot like implementing Mandatory Access Control within
> OpenStack. I would like to go on record and say we should squash the hidden
> projects concept (within a single hierarchy). If we want to implement MAC
> (SELinux equivalent) in OpenStack, we have a much, much, bigger scope to
> cover than just in Keystone, and this feels outside the scope of any
> heirarchical multi-tenancy work that has been done/will be done.
>
>
Liked the comparison here, with this in mind, we can try to improve the
design of the current solution.


> TL DR: let's not try and hide projects from users with rights in the same
> (peer, or above) hierarchy.
>

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


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Keystone] Admin or certain roles should be able to list full project subtree

2017-03-16 Thread Rodrigo Duarte
On Thu, Mar 16, 2017 at 3:42 PM, Lance Bragstad <lbrags...@gmail.com> wrote:

>
> On Thu, Mar 16, 2017 at 12:46 PM, Morgan Fainberg <
> morgan.fainb...@gmail.com> wrote:
>
>>
>>
>> On Mar 16, 2017 07:28, "Jeremy Stanley" <fu...@yuggoth.org> wrote:
>>
>> On 2017-03-16 08:34:58 -0500 (-0500), Lance Bragstad wrote:
>> [...]
>> > These security-related corner cases have always come up in the past when
>> > we've talked about implementing reseller. Another good example that I
>> > struggle with is what happens when you flip the reseller bit for a
>> project
>> > admin who goes off and creates their own entities but then wants
>> support?
>> > What does the support model look like for the project admin that needs
>> help
>> > in a way that maintains data integrity?
>>
>> It's still entirely unclear to me how giving someone the ability to
>> hide resources you've delegated them access to create in any way
>> enables "reseller" use cases. I can understand the global admins
>> wanting to have optional views where they don't see all the resold
>> hierarchy (for the sake of their own sanity), but why would a
>> down-tree admin have any expectation they could reasonably hide
>> resources they create from those who maintain the overall system?
>>
>> In other multi-tenant software I've used where reseller
>> functionality is present, top-level admins have some means of
>> examining delegated resources and usually even of impersonating
>> their down-tree owners for improved supportability.
>> --
>> Jeremy Stanley
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> Hiding projects is a lot like implementing Mandatory Access Control
>> within OpenStack. I would like to go on record and say we should squash the
>> hidden projects concept (within a single hierarchy). If we want to
>> implement MAC (SELinux equivalent) in OpenStack, we have a much, much,
>> bigger scope to cover than just in Keystone, and this feels outside the
>> scope of any heirarchical multi-tenancy work that has been done/will be
>> done.
>>
>> TL DR: let's not try and hide projects from users with rights in the same
>> (peer, or above) hierarchy.
>>
>
> If that's the direction - we need to realign our documentation [0].
>
>
> [0] http://specs.openstack.org/openstack/keystone-specs/
> specs/keystone/mitaka/reseller.html#problem-description
>

I guess we need a new spec to discuss improvements in the "regular" HMT
implementation. Once we cover just the "project hierarchy" we can think in
improvements for the reseller use case as well.


>
>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] Adding foreign keys between subsystems

2017-04-12 Thread Rodrigo Duarte
Just to illustrate the discussion, we have a bug fix that currently tries
to drop a FK between the federation and identity subsystems [1].

The previous fix for this bug (which has been merged and had the backport
abandoned) took advantage of the FK in order to cascade delete federated
users when a protocol or an identity provider is deleted [2].

[1] https://review.openstack.org/#/c/445505/
[2] https://review.openstack.org/#/c/420893/

On Wed, Apr 12, 2017 at 11:58 AM, Lance Bragstad <lbrags...@gmail.com>
wrote:

>
>
> On Wed, Apr 12, 2017 at 9:28 AM, David Stanek <dsta...@dstanek.com> wrote:
>
>> [tl;dr I want to remove the artificial restriction of not allowing FKs
>> between
>> subsystems and I want to stop FK enforcement in code.]
>>
>> The keystone code architecture is pretty simple. The data and
>> functionality are
>> divided up into subsystems. Each subsystem can be configured to use a
>> different
>> backend datastore. Of course, there are always exceptions to the rule
>> like how
>> the federation and identity subsystems are highly coupled in the data
>> model.
>>
>> On the surface this flexible model sounds good, but there are some
>> interesting
>> consequences. First, you can't tell from looking at the data model that
>> there
>> actually is a lot of coupling between the subsystems. So instead of
>> looking at
>> our sqlalchemy models to see relationships, we must look throughout the
>> code
>> for where a particular primary key is used and look for enforcement.
>> (Hopefully
>> we enforce it in all of the right places.) Additionally, a DBA/data
>> architect/
>> whenever can't see the relationship at all by looking at the database.
>>
>> Second, this has polluted our code and causes erroneous API errors. We
>> have added
>> lots of get_*() calls in our code that checks for the existence of IDs in
>> another subsystem. In some cases we probably don't do the check and thus
>> would
>> allow bad data to be stored. The check often causes 404s instead of 400s
>> when
>> bad data is provided.
>>
>
> Having these cleaned up would be awesome. I imagine we'd also see some
> sort of performance benefit as a result, too.
>
>
>>
>> So I'd like us to be more deliberate in defining which parts of the data
>> model
>> are truly independent and a separate backend datastore would make sense.
>> For
>> instance, we know we want to support LDAP for identity (although this
>> still puts
>> identity info into a SQL database) and catalog is very isolated from the
>> rest of
>> the data model.
>>
>> As a side effect this means that if deployers wished to use a separate
>> backend
>> for something they would need to also implement it for the other highly
>> coupled
>> subsystems. They would also have to provide any FK enforcement that their
>> own
>> datastore does not provide.
>>
>
> So for deployers, this would mean that if today they only deploy keystone
> backed with LDAP for *only* identity, tomorrow they will have to ensure
> that LDAP has all the proper things for other subsystems that use to have
> an in-code constraint with identity (i.e. assignment). I wonder how many
> folks that would be? What would an upgrade look like for deployments
> wishing to stick to LDAP? I imagine we'd be raising the bar for that
> particular upgrade.
>
>
>>
>> Thoughts?
>>
>> --
>> david stanek
>> web: https://dstanek.com
>> twitter: https://twitter.com/dstanek
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [keystone] Adding foreign keys between subsystems

2017-04-12 Thread Rodrigo Duarte
On Wed, Apr 12, 2017 at 2:47 PM, David Stanek <dsta...@dstanek.com> wrote:

> On 12-Apr 14:30, Rodrigo Duarte wrote:
> > Just to illustrate the discussion, we have a bug fix that currently tries
> > to drop a FK between the federation and identity subsystems [1].
> >
> > [1] https://review.openstack.org/#/c/445505/
>
> I think this highlights one of my problems with the current architecture.
> I see that
> you've removed the FK and added delete logic to do what the data layer
> would be doing
> for you. I didn't see any added get_user() checks to make sure the user_id
> being used
> in creates/updates is valid. Are we already checking that somewhere else
> or is this
> introducing a new bug?
>

The review [1] is dropping the idp_id and idp_id + protocol_id FKs, not the
user_id one.


>
> --
> david stanek
> web: https://dstanek.com
> twitter: https://twitter.com/dstanek
>
> __
> 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
>



-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Keystone] Admin or certain roles should be able to list full project subtree

2017-03-14 Thread Rodrigo Duarte
Hi Adrian,

In project hierarchies, it is not that simple to have a "tree admin".
Imagine you have something like the following:

A -> B -> C

You are an admin of project C and want to create a project called
"secret_D" under C:

A -> B -> C -> secret_D

This is an example of a hierarchy where the admin of project A is not
supposed to "see" the whole tree. Of course we could implement this in a
different way, like using a flag "secret" in project "secret_D", but the
implementation we chose was the one that made more sense for the way role
assignments are organized. For example, we can assign to project A admin an
inherited role assignment, which will give access to the whole subtree and
make it impossible to create a "secret_D" project like we defined above -
it is basically a choice between the possibility to have "hidden" projects
or not in the subtree.

However, we can always improve! Please submit a spec where we will be able
to discuss in further detail the options we have to improve the current UX
of the HMT feature :)

On Tue, Mar 14, 2017 at 12:24 AM, Adrian Turjak <adri...@catalyst.net.nz>
wrote:

> Hello Keystone Devs,
>
> I've been playing with subtrees in Keystone for the last while, and one
> thing that hit me recently is that as admin, I still can't actually do
> subtree_as_list unless I have a role in all projects in the subtree.
> This is kind of silly.


> I can understand why this limitation was implemented, but it's also a
> frustrating constraint because as an admin, I have the power to add
> myself to all these projects anyway, why then can't I just list them?


> Right now if I want to get a list of all the subtree projects I need to
> do subtree_as_ids, then list ALL projects, and then go through that list
> grabbing out only the projects I want. This is a pointless set of
> actions, and having to get the full project list when I just need a
> small subset is really wasteful.


> Beyond the admin case, people may in fact want certain roles to be able
> to see the full subtree regardless of access. In fact I have a role
> 'project_admin' which allows you to edit your own roles within the scope
> of your project, including set those roles to inherit down, and create
> subprojects. If you have the project_admin role, it would make sense to
> see the full subtree regardless of your actually having access to each
> element in the subtree or not.
>
> Looking at the code in Keystone, I'm not entirely sure there is a good
> way to set role based policy for this given how it was setup. Another
> option might be to introduce a filter which allows listing of
> subprojects. Project list is already an admin/cloud_admin only command
> so there is no need to limit it, and the filter could be as simple as
> 'subtree=' and would make getting subtrees as admin, or a
> given admin-like role, actually doable without the pain of roles
> everywhere.
>
> The HMT stuff in Keystone is very interesting, and potentially very
> useful, but it also feels like so many of the features are a little
> half-baked. :(
>
> Anyone with some insight into this and is there any interest in making
> subtree listing more flexible/useful?
>
> Cheers,
> Adrian Turjak
>
>
> Further reading:
> https://github.com/openstack/keystone-specs/blob/master/spec
> s/keystone/kilo/project-hierarchy-retrieval.rst
> https://bugs.launchpad.net/keystone/+bug/1434916
> https://review.openstack.org/#/c/167231
>
>
>
> ______
> 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
>



-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Keystone] Admin or certain roles should be able to list full project subtree

2017-03-14 Thread Rodrigo Duarte
On Tue, Mar 14, 2017 at 10:36 AM, Lance Bragstad <lbrags...@gmail.com>
wrote:

> Rodrigo,
>
> Isn't what you just described the reseller use case [0]? Was that work
> ever fully finished? I thought I remember having discussions in Tokyo about
> it.
>

You are right, one of the goals of reseller is to have an even stronger
separation in the hierarchy by having subdomains, but this is not
implemented yet. However, I was referring only to the project hierarchy and
having or not inherited role assignments to grant access to the subtree.


>
>
> [0] http://specs.openstack.org/openstack/keystone-specs/
> specs/keystone/mitaka/reseller.html
>
> On Tue, Mar 14, 2017 at 7:38 AM, Rodrigo Duarte <rodrigodso...@gmail.com>
> wrote:
>
>> Hi Adrian,
>>
>> In project hierarchies, it is not that simple to have a "tree admin".
>> Imagine you have something like the following:
>>
>> A -> B -> C
>>
>> You are an admin of project C and want to create a project called
>> "secret_D" under C:
>>
>> A -> B -> C -> secret_D
>>
>> This is an example of a hierarchy where the admin of project A is not
>> supposed to "see" the whole tree. Of course we could implement this in a
>> different way, like using a flag "secret" in project "secret_D", but the
>> implementation we chose was the one that made more sense for the way role
>> assignments are organized. For example, we can assign to project A admin an
>> inherited role assignment, which will give access to the whole subtree and
>> make it impossible to create a "secret_D" project like we defined above -
>> it is basically a choice between the possibility to have "hidden" projects
>> or not in the subtree.
>>
>> However, we can always improve! Please submit a spec where we will be
>> able to discuss in further detail the options we have to improve the
>> current UX of the HMT feature :)
>>
>> On Tue, Mar 14, 2017 at 12:24 AM, Adrian Turjak <adri...@catalyst.net.nz>
>> wrote:
>>
>>> Hello Keystone Devs,
>>>
>>> I've been playing with subtrees in Keystone for the last while, and one
>>> thing that hit me recently is that as admin, I still can't actually do
>>> subtree_as_list unless I have a role in all projects in the subtree.
>>> This is kind of silly.
>>
>>
>>> I can understand why this limitation was implemented, but it's also a
>>> frustrating constraint because as an admin, I have the power to add
>>> myself to all these projects anyway, why then can't I just list them?
>>
>>
>>> Right now if I want to get a list of all the subtree projects I need to
>>> do subtree_as_ids, then list ALL projects, and then go through that list
>>> grabbing out only the projects I want. This is a pointless set of
>>> actions, and having to get the full project list when I just need a
>>> small subset is really wasteful.
>>
>>
>>> Beyond the admin case, people may in fact want certain roles to be able
>>> to see the full subtree regardless of access. In fact I have a role
>>> 'project_admin' which allows you to edit your own roles within the scope
>>> of your project, including set those roles to inherit down, and create
>>> subprojects. If you have the project_admin role, it would make sense to
>>> see the full subtree regardless of your actually having access to each
>>> element in the subtree or not.
>>>
>>> Looking at the code in Keystone, I'm not entirely sure there is a good
>>> way to set role based policy for this given how it was setup. Another
>>> option might be to introduce a filter which allows listing of
>>> subprojects. Project list is already an admin/cloud_admin only command
>>> so there is no need to limit it, and the filter could be as simple as
>>> 'subtree=' and would make getting subtrees as admin, or a
>>> given admin-like role, actually doable without the pain of roles
>>> everywhere.
>>>
>>> The HMT stuff in Keystone is very interesting, and potentially very
>>> useful, but it also feels like so many of the features are a little
>>> half-baked. :(
>>>
>>> Anyone with some insight into this and is there any interest in making
>>> subtree listing more flexible/useful?
>>>
>>> Cheers,
>>> Adrian Turjak
>>>
>>>
>>> Further reading:
>>> https://github.com/openstack/keystone-specs/blob/master/spec
>>> s/keystone/kil

Re: [openstack-dev] [keystone] Adding Kristi Nikolla to keystone-core

2017-08-15 Thread Rodrigo Duarte
Congrats Kristi! Well deserved.

On Tue, Aug 15, 2017 at 4:54 PM, Davanum Srinivas  wrote:

> Go Kristi!
>
> On Tue, Aug 15, 2017 at 3:00 PM, Lance Bragstad 
> wrote:
> > I made the announcement in today's keystone meeting [0] that the current
> > reviewers have decided to add Kristi Nikolla (knikolla) to the team.
> >
> > Kristi has been an extremely valuable asset to the team over the last
> > couple of releases. He especially stepped up to the plate during Pike.
> > He provides consistent and valuable feedback on reviews, actively
> > participates in discussions about the project's future, and takes
> > initiative when something needs to get done. In addition to that, he's
> > been great about helping folks out in the channel and getting our Pike
> > release candidate out the door.
> >
> > I'm excited to add Kristi to the keystone core group and I look forward
> > to seeing him make positive changes. Thanks for all the dedication and
> > hard work, Kristi!
> >
> > [0]
> > http://eavesdrop.openstack.org/meetings/keystone/2017/
> keystone.2017-08-15-18.00.log.html#l-130
> >
> >
> >
> > 
> __
> > 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
> >
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> 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
>



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


Re: [openstack-dev] [keystone] Signing off

2018-06-05 Thread Rodrigo Duarte
Henry,

I'm really sad to see you go, you were a terrific mentor when I first
joined the community - I remember all the thorough reviews and nice
discussions ranging from topics on how to model the root domain for the
reseller usecase to how to improve the role assignments API. :)

Thanks for everything!

On Wed, May 30, 2018 at 11:22 AM, Gage Hugo  wrote:

> It was great working with you Henry.  Hope to see you around sometime and
> wishing you all the best!
>
> On Wed, May 30, 2018 at 3:45 AM, Henry Nash  wrote:
>
>> Hi
>>
>> It is with a somewhat heavy heart that I have decided that it is time to
>> hang up my keystone core status. Having been involved since the closing
>> stages of Folsom, I've had a good run! When I look at how far keystone has
>> come since the v2 days, it is remarkable - and we should all feel a sense
>> of pride in that.
>>
>> Thanks to all the hard work, commitment, humour and support from all the
>> keystone folks over the years - I am sure we will continue to interact and
>> meet among the many other open source projects that many of us are becoming
>> involved with. Ad astra!
>>
>> Best regards,
>>
>> Henry
>> Twitter: @henrynash
>> linkedIn: www.linkedin.com/in/henrypnash
>>
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>


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


Re: [openstack-dev] [keystone] adding Gage Hugo to keystone core

2018-01-18 Thread Rodrigo Duarte
Congrats, Gage. Well deserved!

On Tue, Jan 16, 2018 at 6:16 PM, Harry Rybacki  wrote:

> +100 -- congratulations, Gage!
>
>
> On Tue, Jan 16, 2018 at 2:24 PM, Raildo Mascena de Sousa Filho <
> rmasc...@redhat.com> wrote:
>
>> +1
>>
>> Congrats Gage, very well deserved!
>>
>> Cheers,
>>
>> On Tue, Jan 16, 2018 at 4:02 PM Lance Bragstad 
>> wrote:
>>
>>> Hey folks,
>>>
>>> In today's keystone meeting we made the announcement to add Gage Hugo
>>> (gagehugo) as a keystone core reviewer [0]! Gage has been actively
>>> involved in keystone over the last several cycles. Not only does he
>>> provide thorough reviews, but he's really stepped up to help move the
>>> project forward by keeping a handle on bugs, fielding questions in the
>>> channel, and being diligent about documentation (especially during
>>> in-person meet ups).
>>>
>>> Thanks for all the hard work, Gage!
>>>
>>> [0]
>>> http://eavesdrop.openstack.org/meetings/keystone/2018/keysto
>>> ne.2018-01-16-18.00.log.html
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> --
>>
>> Raildo mascena
>>
>> Software Engineer, Identity Managment
>>
>> Red Hat
>>
>> 
>> 
>> TRIED. TESTED. TRUSTED. 
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>


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


Re: [openstack-dev] Stepping down as coordinator for the Outreachy internships

2018-08-17 Thread Rodrigo Duarte
Thanks for everything, Victoria.

On Fri, Aug 17, 2018 at 1:07 PM Victoria Martínez de la Cruz <
victo...@vmartinezdelacruz.com> wrote:

> Thanks everyone for your words!
>
> I really love the OpenStack community and I'm glad I could contribute back
> with this.
>
> Samuel has been a great mentor for Outreachy in several rounds and I
> believe he will excel as coordinator along with Mahati. Thanks for
> volunteer for this Samuel!
>
> All the best,
>
> Victoria
>
> 2018-08-17 14:56 GMT-03:00 Samuel de Medeiros Queiroz  >:
>
>> Hi all,
>>
>> As someone who cares for this cause and participated twice in this
>> program as a mentor, I'd like to candidate as program coordinator.
>>
>> Victoria, thanks for all your lovely work. You are awesome!
>>
>> Best regards,
>> Samuel
>>
>>
>> On Thu, Aug 9, 2018 at 6:51 PM Kendall Nelson 
>> wrote:
>>
>>> You have done such amazing things with the program! We appreciate
>>> everything you do :) Enjoy the little extra spare time.
>>>
>>> -Kendall (daiblo_rojo)
>>>
>>>
>>> On Tue, Aug 7, 2018 at 4:48 PM Victoria Martínez de la Cruz <
>>> victo...@vmartinezdelacruz.com> wrote:
>>>
 Hi all,

 I'm reaching you out to let you know that I'll be stepping down as
 coordinator for OpenStack next round. I had been contributing to this
 effort for several rounds now and I believe is a good moment for somebody
 else to take the lead. You all know how important is Outreachy to me and
 I'm grateful for all the amazing things I've done as part of the Outreachy
 program and all the great people I've met in the way. I plan to keep
 involved with the internships but leave the coordination tasks to somebody
 else.

 If you are interested in becoming an Outreachy coordinator, let me know
 and I can share my experience and provide some guidance.

 Thanks,

 Victoria

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

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


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


[openstack-dev] [Keystone] Feature to enable domain-related role validation

2014-07-01 Thread Rodrigo Duarte Sousa

Hi all,

We created a POC that enables domain-related role checking to components 
that do not support domains (such as Nova and Cinder). The code can be 
found here: https://github.com/rodrigods/keystone/tree/domain-check


The idea is to use the HttpCheck feature: 
https://github.com/openstack/oslo-incubator/blob/master/openstack/common/policy.py#L849 
to check if a user has a given role in a domain. The changes were made 
exclusively into Keystone. The service willing to use the feature, just 
has to add the rule in its policy file.


Here is a list of the changes added to make it work:

1 - Create a new endpoint to handle the HttpCheck calls, for example:
/v3/projects/ project_id/roles/role_name

2 - Add a method to handle this endpoint at Keystone:
https://github.com/rodrigods/keystone/blob/domain-check/keystone/assignment/controllers.py#L559

 * Get domain_id from target project (from given project_id)
 * Filter all role_assignments from logged user in target domain (from
   user_id in given credentials)
 * Check if role_assignments contains target role


To test it, we added the following rule into Nova's policy file:

 * compute:create:rule:domain_admin
 * domain_admin:http://localhost:5000/v3/projects/%(project_id)
   s/roles/admin

Once the request arrives into Keystone, it checks if the the logged user 
has /admin/ role at /project_id/'s domain.


So, what do you think? We would like your feedback before giving extra 
efforts such as creating the bp/spec.


--

Rodrigo Duarte Sousa
MSccandidate in Computer Science
Software Engineer at OpenStack Project HP/LSD-UFCG
Distributed Systems Laboratory
Federal University of Campina Grande
Campina Grande, PB - Brazil
http://lsd.ufcg.edu.br/~rodrigod http://lsd.ufcg.edu.br/%7Erodrigodss
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Keystone][Glance] Hierarchical multitenancy and Glance?

2015-04-28 Thread Rodrigo Duarte Sousa

Hi all,

Our team in the Federal University of Campina Grande implemented the 
initial Hierarchical Multitenancy support and now we are implementing 
the Reseller use case in Keystone.


Already answering Travis question, in the Reseller solution we are 
merging the domains and projects entities: domains are going to be a 
feature of projects - if a project has the domain feature enabled, 
it will behave exactly as domains currently behave (being a container of 
users). With domain being a project, they will be part of the same 
hierarchy, for more details you may read the spec: 
https://github.com/openstack/keystone-specs/blob/master/specs/liberty/reseller.rst


And yes, we need to extend the Hierarchical Mutlitenancy concept to 
other projects and our team is already working in Horizon and in contact 
with Sajeesh (Nova). We are definitely interested in participating the 
proposed design session and discussions that could emerge from it.


--

Rodrigo Duarte

On 28-04-2015 10:59, Geoff Arnold wrote:

Yes. 100% upstream.

And although I’ve referred to it as “reseller” (following the previous 
Keystone BP), it’s a much more generic pattern. Long term, I think it 
turns into something like a supply chain framework for services.


Geoff

On Apr 28, 2015, at 3:51 AM, Tim Bell tim.b...@cern.ch 
mailto:tim.b...@cern.ch wrote:


Geoff,

Would the generic parts of your “reseller” solution by contributed to 
the upstream projects (e.g. glance, horizon, ceilometer) ? It would 
be good to get the core components understanding hierarchical 
multitenancy for all the use cases.


The nova quota work is being submitted upstream for Liberty by 
Sajeesh 
(https://blueprints.launchpad.net/nova/+spec/nested-quota-driver-api)


The cinder quota proposal is also underway 
(https://blueprints.launchpad.net/cinder/+spec/cinder-nested-quota-driver)


Tim

*From:*Geoff Arnold [mailto:ge...@geoffarnold.com]
*Sent:* 28 April 2015 08:11
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [Keystone][Glance] Hierarchical 
multitenancy and Glance?


Use cases:

https://wiki.openstack.org/wiki/HierarchicalMultitenancy

Blueprints:

(Kilo):

https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy

https://blueprints.launchpad.net/keystone/+spec/reseller

(Liberty):

https://blueprints.launchpad.net/nova/+spec/multiple-level-user-quota-management

https://blueprints.launchpad.net/nova/+spec/nested-quota-driver-api

(Pending):

https://blueprints.launchpad.net/horizon/+spec/hierarchical-projects

https://blueprints.launchpad.net/horizon/+spec/inherited-roles

As for adoption, it’s hard to say. The HMT work in Keystone was a 
necessary starting point, but in order to create a complete solution 
we really need the corresponding changes in Nova (quotas), Glance 
(resource visibility), Horizon (UI scoping), and probably Ceilometer 
(aggregated queries). We (Cisco) are planning to kick off a 
Stackforge project to knit all of these things together into a 
complete “reseller” federation system. I’m assuming that there will 
be other system-level compositions of the various pieces.


Geoff

On Apr 27, 2015, at 9:48 PM, Tripp, Travis S travis.tr...@hp.com
mailto:travis.tr...@hp.com wrote:

Geoff,

Getting a spec on HMT would be helpful, as Nikhil mentioned.

As a general question, what it the current adoption of domains / vs
hierarchical projects? Is there a wiki or something that
highlights what
the desired path forward is with regard to domains?

Thanks,
Travis

On 4/27/15, 7:16 PM, Geoff Arnold ge...@geoffarnold.com
mailto:ge...@geoffarnold.com wrote:


Good points. I¹ll add some details. I¹m sure the Reseller
guys will have
some comments.

Geoff


On Apr 27, 2015, at 3:32 PM, Nikhil Komawar
nikhil.koma...@rackspace.com
mailto:nikhil.koma...@rackspace.com wrote:

Thanks Geoff. Added some notes and questions.

-Nikhil


From: Geoff Arnold ge...@geoffarnold.com
mailto:ge...@geoffarnold.com
Sent: Monday, April 27, 2015 5:50 PM
To: OpenStack Development Mailing List (not for usage
questions)
Subject: [openstack-dev] [Keystone][Glance] Hierarchical
multitenancy
and   Glance?

In preparation for Vancouver, I¹ve been looking for
blueprints and
design summit discussions involving the application of
the Keystone
hierarchical multitenancy work to other OpenStack
projects. One obvious
candidate is Glance, where, for example, we might want
domain-local
resource visibility as a default. Despite my searches, I
wasn¹t able to
find anything. Did I miss something obvious