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
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
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 i
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, Octob
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] [key
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 wrote:
On 08/27/2015 11:28 PM, Chen, Wei D wrote:
>
> I agree that re
> > 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,
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
> On Aug 26, 2015, at 4:45 AM, Henry Nash 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
> 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
Congrats Lin Hua for being a dual-cores role, well deserved!
Best Regards,
Dave Chen
From: Morgan Fainberg [mailto:morgan.fainb...@gmail.com]
Sent: Wednesday, April 08, 2015 6:30 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Keystone] Core Revi
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
roval
>
> 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 nece
+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 Maili
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 DEL
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
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://lis
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 w
18 matches
Mail list logo
