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

[Chen, Wei D]

Nice to hear you are onboard, congratulation Boris!





Best Regards,

Dave Chen



From: Steve Martinelli [mailto:s.martine...@gmail.com]
Sent: Tuesday, November 01, 2016 3:47 AM
To: OpenStack Development Mailing List (not for usage questions)
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





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

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

[Chen, Wei D]

Well deserved! Congrats!





Best Regards,

Dave Chen



From: Steve Martinelli [mailto:s.martine...@gmail.com]
Sent: Thursday, September 01, 2016 10:44 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [keystone] new core reviewer (rderose)



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:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] changes to keystone-core!

[Chen, Wei D]

Hi,

 

Many thanks to everyone for your patient guidance and  mentoring me in the past 
years!  It's your help to make me grow up from a
newbie! 

 

As a core project in OpenStack, keystone has grown to be several sub-projects, 
I strongly believe that we will continue to provide a
stable/great identity service, and I will do my best to make it a model of high 
quality, great project to contribute!

 

 

 

Best Regards,

Dave Chen

 

From: Steve Martinelli [mailto:steve...@ca.ibm.com] 
Sent: Thursday, January 28, 2016 7:13 AM
To: openstack-dev
Subject: [openstack-dev] [keystone] changes to keystone-core!

 

Hello everyone!

We've been talking about this for a long while, and I am very pleased to 
announce that at the midcycle we have made changes to
keystone-core. The project has grown and our review queue grows ever longer. 
Effective immediately, we'd like to welcome the
following new Guardians of the Gate to keystone-core:

+ Dave Chen (davechen)
+ Samuel de Medeiros Queiroz (samueldmq)

Happy code reviewing!

Steve Martinelli
OpenStack Keystone Project Team Lead



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

Re: [openstack-dev] [keystone] Let's get together and fix all the bugs

[Chen, Wei D]

Great idea! core reviewer’s advice is definitely much important and valuable 
before proposing a fixing. I was always thinking it will help save us if we can 
get some agreement at some point.

 

 

Best Regards,

Dave Chen

 

From: David Stanek [mailto:dsta...@dstanek.com] 
Sent: Saturday, October 10, 2015 3:54 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [keystone] Let's get together and fix all the bugs

 

I would like to start running a recurring bug squashing day. The general idea 
is to get more focus on bugs and stability. You can find the details here: 
https://etherpad.openstack.org/p/keystone-office-hours

 

 

-- 

David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek

www: http://dstanek.com



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

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

[Chen, Wei D]

Morgan, thanks for your great leadership,  all the best in your new journey.





Best Regards,

Dave Chen



From: Lance Bragstad [mailto:lbrags...@gmail.com]
Sent: Friday, September 11, 2015 8:56 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone] PTL non-candidacy



Best of luck in your new adventures, and thanks for all your hard work!



On Thu, Sep 10, 2015 at 5:28 PM, Dolph Mathews  wrote:

Thank you for all your work, Morgan! Good luck with the opportunity to write 
some code again :)



On Thu, Sep 10, 2015 at 4:40 PM, Morgan Fainberg  
wrote:

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




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





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

Re: [openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering

[Chen, Wei D]

Dolph,



Ignore these arbitrary query string is what we did in keystone, current 
implementation did something deliberately to ignore them 
instead of passing them into the backend driver (If these parameter go to 
backend driver we will get nothing for sure), there might be 
no model answer for this situation, but I guess there must be some 
consideration at that time, do you still remember the concerns 
around this?





Best Regards,

Dave Chen



From: Dolph Mathews [mailto:dolph.math...@gmail.com]
Sent: Wednesday, September 02, 2015 9:36 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [api][keystone][openstackclient] Standards for 
object name attributes and filtering



Does anyone have an example of an API outside of OpenStack that would return 
400 in this situation (arbitrary query string 
parameters)? Based on my past experience, I'd expect them to be ignored, but I 
can't think of a reason why a 400 would be a bad idea 
(but I suspect there's some prior art / discussion out there).



On Mon, Aug 31, 2015 at 10:53 AM, Ryan Brown <rybr...@redhat.com> wrote:

On 08/27/2015 11:28 PM, Chen, Wei D wrote:
>
> I agree that return 400 is good idea, thus client user would know what 
> happened.
>

+1, I think a 400 is the sensible choice here. It'd be much more likely
to help devs catch their errors .

--
Ryan Brown / Software Engineer, Openstack / Red Hat, 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





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

Re: [openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering

[Chen, Wei D]

 On Aug 26, 2015, at 4:45 AM, Henry Nash hen...@linux.vnet.ibm.com wrote:
 
  Hi
 
  With keystone, we recently came across an issue in terms of the assumptions 
  that the openstack client is making about the
 entities it can show - namely that is assumes all entries have a 'name' 
 attribute (which is how the openstack show
 command works). Turns out, that not all keystone entities have such an 
 attribute (e.g. IDPs for federation) - often the ID is
 really the name. Is there already agreement across our APIs that all first 
 class entities should have a 'name' attribute?  If
 we do, then we need to change keystone, if not, then we need to change 
 openstack client to not make this assumption (and
 perhaps allow some kind of per-entity definition of which attribute should be 
 used for 'show').
 
 AFAICT, there's no such agreement in the API WG guidelines [1].
 
  A follow on (and somewhat related) question to this, is whether we have 
  agreed standards for what should happen if some
 provides an unrecognized filter to a list entities API request at the http 
 level (this is related since this is also the hole osc
fell
 into with keystone since, again, 'name' is not a recognized filter 
 attribute). Currently keystone ignores filters it doesn't
 understand (so if that was your only filter, you would get back all the 
 entities). The alternative approach would of course be
 to return no entities if the filter is on an attribute we don't recognize (or 
 even issue a validation or bad request exception).
 Again, the question is whether we have agreement across the projects for how 
 such unrecognized filtering should be
 handled?
 
 The closest thing we have is the Filtering guideline [2] but it doesn't 
 account for this particular case.
 
 Client tool developers would be quite frustrated by a service ignoring 
 filters it doesn't understand or returning no entities if
 the filter isn't recognized. In both cases, the developer isn't getting the 
 expected result but you're masking the error made
 by the developer.
 
 Much better to return a 400 so the problem can be fixed immediately. Somewhat 
 related is this draft [3].

I think Henry's point is return everything or return nothing when there is a 
filter doesn't recognized by the server, let' s see the
sample object in the spec [1],
when there is a query like this, GET /app/items?bugus=buzz, will it return all 
the two items we have? I think this confuse the
client developers a lot and give the
user wrong indication, and the wrong direction based on the response, this 
seems to me more like a bug or something we need
improvement. 

I agree that return 400 is good idea, thus client user would know what happened.

Best Regards,
Dave Chen

 Everett
 
 [1] http://specs.openstack.org/openstack/api-wg/
 [2] 
 http://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.html#filtering
 [3] https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering

[Chen, Wei D]

 Hi
 
 With keystone, we recently came across an issue in terms of the assumptions 
 that the openstack client is making about the
 entities it can show - namely that is assumes all entries have a ‘name’ 
 attribute (which is how the openstack show
 command works). Turns out, that not all keystone entities have such an 
 attribute (e.g. IDPs for federation) - often the ID is
 really the name. Is there already agreement across our APIs that all first 
 class entities should have a ‘name’ attribute?  If
 we do, then we need to change keystone, if not, then we need to change 
 openstack client to not make this assumption (and
 perhaps allow some kind of per-entity definition of which attribute should be 
 used for ‘show’).
 

I think OSC do this assumption based on that there is no need to query by the 
ID.
'openstack show' try to get the IDP by following,
curl -s -X GET 
http://127.0.0.1:35357/v3/OS-FEDERATION/identity_providers/notexsitingIDP -H 
Content-Type: application/json -H Accept: application/json -H 
X-Auth-Token: 05e74f9448124aaba339cd809fd7b219

Then fail back to filter by the 'name'. In this case, if we allow the 
per-entity definition, we may tried it again with the query
like this, 
curl GET 
http://127.0.0.1:35357/v3/OS-FEDERATION/identity_providers?id=notexsitingIDP

but this is not necessary since we have tried it with the ID, why we still 
tried it again with different API? the both APIs *should* has the same response 
instead of 
one get nothing and another get everything, this is not make sense. If there 
is, this is a bug of the server IMO.


 A follow on (and somewhat related) question to this, is whether we have 
 agreed standards for what should happen if some
 provides an unrecognized filter to a list entities API request at the http 
 level (this is related since this is also the hole osc fell
 into with keystone since, again, ‘name’ is not a recognized filter 
 attribute). Currently keystone ignores filters it doesn’t
 understand (so if that was your only filter, you would get back all the 
 entities). The alternative approach would of course be
 to return no entities if the filter is on an attribute we don’t recognize (or 
 even issue a validation or bad request exception).
 Again, the question is whether we have agreement across the projects for how 
 such unrecognized filtering should be
 handled?
 
 Thanks
 
 Henry
 Keystone Core
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering

[Chen, Wei D]

  Hi
 
  With keystone, we recently came across an issue in terms of the assumptions 
  that the openstack client is making about the
  entities it can show - namely that is assumes all entries have a ‘name’ 
  attribute (which is how the openstack show
  command works). Turns out, that not all keystone entities have such an 
  attribute (e.g. IDPs for federation) - often the ID is
  really the name. Is there already agreement across our APIs that all first 
  class entities should have a ‘name’ attribute?
 If
  we do, then we need to change keystone, if not, then we need to change 
  openstack client to not make this assumption (and
  perhaps allow some kind of per-entity definition of which attribute should 
  be used for ‘show’).
 
 
 I think OSC do this assumption based on that there is no need to query by the 
 ID.
 'openstack show' try to get the IDP by following,
 curl -s -X GET 
 http://127.0.0.1:35357/v3/OS-FEDERATION/identity_providers/notexsitingIDP -H 
 Content-Type:
 application/json -H Accept: application/json -H X-Auth-Token: 
 05e74f9448124aaba339cd809fd7b219
 
 Then fail back to filter by the 'name'. In this case, if we allow the 
 per-entity definition, we may tried it again with the query
 like this,
 curl GET 
 http://127.0.0.1:35357/v3/OS-FEDERATION/identity_providers?id=notexsitingIDP
 
 but this is not necessary since we have tried it with the ID, why we still 
 tried it again with different API? the both APIs
 *should* has the same response instead of
 one get nothing and another get everything, this is not make sense. If there 
 is, this is a bug of the server IMO.
 
correct myself, both APIs will return nothing if allow per-entity definition in 
the OSC, but ID is tried two times.

Best Regards,
Dave Chen 
 
  A follow on (and somewhat related) question to this, is whether we have 
  agreed standards for what should happen if some
  provides an unrecognized filter to a list entities API request at the http 
  level (this is related since this is also the hole osc fell
  into with keystone since, again, ‘name’ is not a recognized filter 
  attribute). Currently keystone ignores filters it doesn’t
  understand (so if that was your only filter, you would get back all the 
  entities). The alternative approach would of course be
  to return no entities if the filter is on an attribute we don’t recognize 
  (or even issue a validation or bad request exception).
  Again, the question is whether we have agreement across the projects for 
  how such unrecognized filtering should be
  handled?
 
  Thanks
 
  Henry
  Keystone Core
 
  __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] Recall: [api][keystone][openstackclient] Standards for object name attributes and filtering

[Chen, Wei D]

Chen, Wei D would like to recall the message, [openstack-dev] 
[api][keystone][openstackclient] Standards for   object name attributes and 
filtering.
__
OpenStack Development Mailing 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?

[Chen, Wei D]

I am the another one who like the idea, let SQLite goes where it belongs to, we 
have already knew there is couples of limitation in SQLite, actually, it hides 
some issues in some cases. As to functional testing, MySQL or other popular 
RDBMS is the better candidate.

 

+1

 

Best Regards,

Dave Chen

 

From: Rodrigo Duarte [mailto:rodrigodso...@gmail.com] 
Sent: Sunday, April 05, 2015 2:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Keystone] SQLite support (migrations, 
work-arounds, and more), is it worth it?

 

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:// http://lsd.ufcg.edu.br/%7Erodrigods rodrigods.com



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

Re: [openstack-dev] [cinder]difference between spec merged and BP approval

[Chen, Wei D]

Hi Stefano,

Thanks so much for your detailed answer, I finally know the reason why those 
patches are not reviewed in this cycle. 
Actually, this BP 
(https://blueprints.launchpad.net/python-cinderclient/+spec/support-modify-volume-image-metadata)
 is created very
early around Nov. 2014, and there is BP even earlier before that
(https://blueprints.launchpad.net/python-cinderclient/+spec/support-volume-image-metadata)
 which is created around May 2014.

Maybe they just believe this is not such important and not worth to take time 
to review. Hope those patches could be reviewed in
'L'.

Best Regards,
Dave Chen


 -Original Message-
 From: Stefano Maffulli [mailto:stef...@openstack.org]
 Sent: Tuesday, March 10, 2015 10:14 PM
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [cinder]difference between spec merged and BP 
 approval
 
 Hi David,
 
 On Sat, 2015-03-07 at 02:22 +, Chen, Wei D wrote:
  I thought the feature should be approved as long as the SPEC[1] is
  merged, but it seems I am wrong from the beginning[2], both of them
  (SPEC merged and BP approval[4][5]) is necessary and mandatory for
  getting some effective reviews, right? anyone can help to confirm with
  that?
 
 Since Cinder uses BP+spec, the process is described on the wiki page:
 
 https://wiki.openstack.org/wiki/Blueprints#Spec_.2B_Blueprints_lifecycle
 
 If it helps, I'd consider the spec and the blueprint as one element made of 
 two pieces. The spec needs to be approved and
 its corresponding blueprint needs to be approved and have a priority, 
 deadline/milestone assigned. If any of these attributes
 is missing, the feature is not going to be reviewed.
 
 Blueprints and their attributes 'priority' and 'milestone' are used to track 
 the status of the release. The reviewers use BPs to
 identify the code that they need to review. For example,
 https://launchpad.net/cinder/+milestone/kilo-3
 
 I've tried to piece the history of your experience from the links you
 provided:
 
 - you submitted the spec in November 2014
 - the spec was approved on Jan 6, 2015 (from
 https://review.openstack.org/#/c/136253/)
 - the spec references two blueprints, one for Cinder, one of Cinder-client; 
 both BPs were created at the end of February
 - none of the BP have a milestone set
 - you submitted code related to the approved spec between Jan 6 and today
 
 I have the impression that you may have missed a step in the BP+spec process. 
 I have tried to find the documentation for this
 process myself and I had a hard time, too.
 
  Besides, who is eligible to define/modify the priority in the list[3],
  only PTL or any core? I am trying to understand the acceptable
  procedure for the coming 'L'.
 
 The project team leaders (PTL) are ultimately responsible to set the 
 priorities, although the decision is always a consensual
 decision of the core teams.
 
 Have you considered joining OpenStack Upstream Training?
 https://www.openstack.org/blog/2015/02/openstack-upstream-training-in-vancouver/
 
 Cheers,
 stef
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

[Chen, Wei D]

+1,

 

I am fan of checking the constraints in the controller level instead of relying 
on FK constraints itself, thanks.

 

 

Best Regards,

Dave Chen

 

From: Morgan Fainberg [mailto:morgan.fainb...@gmail.com] 
Sent: Monday, March 09, 2015 2:29 AM
To: David Stanek; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

 

On March 8, 2015 at 11:24:37 AM, David Stanek (dsta...@dstanek.com) wrote:


On Sun, Mar 8, 2015 at 1:37 PM, Mike Bayer mba...@redhat.com wrote:

can you elaborate on your reasoning that FK constraints should be used less
overall?  or do you just mean that the client side should be mirroring the same
rules that would be enforced by the FKs?


I don't think he means that we will use them less.  Our SQL backends are full 
of them.  What Keystone can't do is rely on them because not all 
implementations of our backends support FKs.

100% spot on David. We support implementations that have no real concept of FK 
and we cannot assume that a cascade (or restrict) will occur on these 
implementations.

 

—Morga

 

--

David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek

www: http://dstanek.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 



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

[openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

[Chen, Wei D]

Hi,

I did some homework to follow up the inline comment about on delete cascade 
subclauses of the foreign key clause[1], when ' ON
DELETE CASCADE ' is given, delete a recode from parent table will DELETE all 
the corresponding rows from the CHILD table
automatically *without any warning*. 'ON DELETE RESTRICT' looks different, it 
will fail complaining about the existing child rows,
this is the default foreign key relationship behavior, this seems give end user 
a chance to double check the data.

I did a quick test against the table 'endpoint_group', the output error message 
like below,
mysql delete from endpoint_group;
ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key 
constraint fails (`keystone`.`project_endpoint_group`,
CONSTRAINT `project_endpoint_group_ibfk_1` FOREIGN KEY (`endpoint_group_id`) 
REFERENCES `endpoint_group` (`id`))

I am a little confused about two different subclauses as both of them can be 
found in the table definition of SQL backends, it hard
to say which one is better, is it worthwhile to move all of them to ON DELETE 
CASCADE or ON DELETE RESTRICT?


[1] 
https://review.openstack.org/#/c/151931/5/keystone/contrib/endpoint_filter/migrate_repo/versions/002_add_endpoint_groups.py

Best Regards,
Dave Chen



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

[openstack-dev] [cinder]difference between spec merged and BP approval

[Chen, Wei D]

Hi,

I thought the feature should be approved as long as the SPEC[1] is merged, but 
it seems I am wrong from the beginning[2], both of
them (SPEC merged and BP approval[4][5]) is necessary and mandatory for getting 
some effective reviews, right? anyone can help to
confirm with that?

Besides, who is eligible to define/modify the priority in the list[3], only PTL 
or any core? I am trying to understand the
acceptable procedure for the coming 'L'.

[1] https://review.openstack.org/#/c/136253/
[2] https://review.openstack.org/#/c/147726/
[3] https://etherpad.openstack.org/p/cinder-k3-priorities
[4] 
https://blueprints.launchpad.net/cinder/+spec/support-modify-volume-image-metadata
[5] 
https://blueprints.launchpad.net/python-cinderclient/+spec/support-modify-volume-image-metadata



Best Regards,
Dave Chen



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

[openstack-dev] [cinder] Anyone knows whether there is freezing day of spec approval?

[Chen, Wei D]

Hi,

I know nova has such day around Dec. 18, is there a similar day in Cinder 
project? thanks!

Best Regards,
Dave Chen




smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Cinder] Support Modifying Volume Image Metadata

[Chen, Wei D]

Hi all,

We talked about this topic (Support Modifying Volume Image Metadata) in this 
week's IRC meeting. Unfortunately, I didn't prepared
well and couldn't detail one concrete use case on this spec. Apologize for 
messing up the meeting!
Now, we have updated the spec and addressed some comments we got from the 
meeting, so it's great if someone could review the spec
again and give me your comments there 
(https://review.openstack.org/#/c/136253/). 
Thanks in the advance.

Best Regards,
Dave Chen




smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev