Re: [openstack-dev] [Trove] trove core team

2016-10-14 Thread Peter Stachowski
Hi Craig,

What?  Trove’s not considered ‘new technology’ anymore?!?  Wait, maybe that’s a 
good thing.  :D  It’s too bad you’re leaving as it’s been good working with 
you.  Good luck in your new projects and hopefully we’ll still bump into each 
other!

Later,
Peter

From: Craig Vyvial [mailto:cp16...@gmail.com]
Sent: October-07-16 11:23 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Trove] trove core team

Whats up yall.

So I've changed my focus over the last couple months to working on some new 
technology and do not have time to fulfill my duties as Trove Core any longer. 
I think its time to move on and step down from trove core.

I have been around for a while and seen the Trove community grow and seen great 
strides of development within Trove. I look forward to seeing the future of 
what Trove will offer within the OpenStack ecosystem. I've truly enjoyed my 
time hanging out, working with, and getting to know everyone. Feel free to 
contact me if you have wanna chat or just hang out if you around around the 
Austin area.
Thanks,
Craig Vyvial
__
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] Change in openstack/trove[master]: Ophaned Volume Not Removed on Instance Delete

2016-06-29 Thread Peter Stachowski
Hi Kevin,

There are a few blueprints in Trove that might address your use case.  See 
https://blueprints.launchpad.net/trove/+spec/snapshot-as-backup-strategy or 
maybe https://blueprints.launchpad.net/trove/+spec/volume-delete-on-terminate . 
 If neither is entirely correct, please feel free to submit a new one.

Thanks!
Peter

From: Fox, Kevin M [mailto:kevin@pnnl.gov]
Sent: June-28-16 7:10 PM
To: OpenStack Development Mailing List (not for usage questions); Ali Adil
Subject: Re: [openstack-dev] Change in openstack/trove[master]: Ophaned Volume 
Not Removed on Instance Delete

To me, one of the benefits of cinder is the ability to have the volume outlast 
the vm. So, for example, if you knew a yum upgrade went bad on the vm, but the 
db data is safe, it would be nice to be able to just delete the vm and have 
trove relaunch using the existing volume, not having to import all the data 
again. Or the host it was running on died but the volume is ok. It would be 
very nice if Trove supported this use case.

Thanks,
Kevin

From: Peter Stachowski [pe...@tesora.com]
Sent: Tuesday, June 28, 2016 3:39 PM
To: OpenStack Development Mailing List (not for usage questions); Ali Adil
Subject: Re: [openstack-dev] Change in openstack/trove[master]: Ophaned Volume 
Not Removed on Instance Delete
Hi Will,

Trove is a managed database service.  Once you delete the database, all 
associated volumes with it are also deleted, as is the Nova instance.  One of 
the key benefits of using Trove is that you don’t have to manage 
servers/volumes/security_groups etc.  Also, depending on the provider’s 
implementation, the volume may not be visible to the end user and thus would 
just be left lying around using up resources if it isn’t deleted by Trove 
(while potentially having the use charged back to the end user).  This is the 
case that is being addressed – having a volume left undeleted even if the Nova 
instance is gone (or in this case didn’t start successfully).

Thanks,
Peter


From: Will Zhou [mailto:zzxw...@gmail.com]
Sent: June-28-16 10:55 AM
To: OpenStack Development Mailing List (not for usage questions); Ali Adil
Subject: Re: [openstack-dev] Change in openstack/trove[master]: Ophaned Volume 
Not Removed on Instance Delete

Hi Scott, many thanks for your figuration.  Thanks and +1 for your nomination 
to nova core:)

Hi aadil, we should DETACH the volume, instead of DELETE. Please help enhance 
your code which is really a helpful fix to the bug. Thanks.

On Tue, Jun 28, 2016 at 10:51 PM D'Angelo, Scott 
<scott.dang...@hpe.com<mailto:scott.dang...@hpe.com>> wrote:
If a volume is attached to an instance, and the instance is deleted, the volume 
will be DETACHED, but the volume will still exist, it will NOT be DELETED.

It is up to the volume owner to delete the volume if they wish.


From: Will Zhou <zzxw...@gmail.com<mailto:zzxw...@gmail.com>>
Sent: Tuesday, June 28, 2016 8:43:51 AM
To: aa...@tesora.com<mailto:aa...@tesora.com>; OpenStack Development Mailing 
List (not for usage questions)
Subject: Re: [openstack-dev] Change in openstack/trove[master]: Ophaned Volume 
Not Removed on Instance Delete

Hi all,

I'd like to make sure should the volume, which is attached to an instance, be 
detached or be deleted after the instance is deleted? Thanks.


On Tue, Jun 28, 2016 at 10:16 PM Ali Asgar Adil (Code Review) 
<rev...@openstack.org<mailto:rev...@openstack.org><mailto:rev...@openstack.org<mailto:rev...@openstack.org>>>
 wrote:
Ali Asgar Adil has posted comments on this change.

Change subject: Ophaned Volume Not Removed on Instance Delete
..


Patch Set 1:

In what situation would a nova instance be in "available" state. Also, we are 
are deleting the instance so we would want the volume to be deleted as well not 
detached.

--
To view, visit https://review.openstack.org/334722
To unsubscribe, visit https://review.openstack.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Ie921a8ff2851e2d9d76a3c3836945c750f090c4e
Gerrit-PatchSet: 1
Gerrit-Project: openstack/trove
Gerrit-Branch: master
Gerrit-Owner: Ali Asgar Adil 
<aa...@tesora.com<mailto:aa...@tesora.com><mailto:aa...@tesora.com<mailto:aa...@tesora.com>>>
Gerrit-Reviewer: Ali Asgar Adil 
<aa...@tesora.com<mailto:aa...@tesora.com><mailto:aa...@tesora.com<mailto:aa...@tesora.com>>>
Gerrit-Reviewer: Jenkins
Gerrit-Reviewer: zzxwill 
<zzxw...@gmail.com<mailto:zzxw...@gmail.com><mailto:zzxw...@gmail.com<mailto:zzxw...@gmail.com>>>
Gerrit-HasComments: No
--

-
?
???
Mobile: 13701280947
?WeChat: 472174291

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] Change in openstack/trove[master]: Ophaned Volume Not Removed on Instance Delete

2016-06-29 Thread Peter Stachowski
Hi Will,

Any time.  ☺  If there is specific functionality that you think is missing and 
would like to see added to Trove, please enter a blueprint.  Thanks!

Peter

From: Will Zhou [mailto:zzxw...@gmail.com]
Sent: June-29-16 12:53 AM
To: OpenStack Development Mailing List (not for usage questions); Ali Adil
Subject: Re: [openstack-dev] Change in openstack/trove[master]: Ophaned Volume 
Not Removed on Instance Delete

Hi Peter,

I got the point and I realize that I am wrong about the fix. Thanks for the 
clarification.
On Wed, Jun 29, 2016 at 6:42 AM Peter Stachowski 
<pe...@tesora.com<mailto:pe...@tesora.com>> wrote:
Hi Will,

Trove is a managed database service.  Once you delete the database, all 
associated volumes with it are also deleted, as is the Nova instance.  One of 
the key benefits of using Trove is that you don’t have to manage 
servers/volumes/security_groups etc.  Also, depending on the provider’s 
implementation, the volume may not be visible to the end user and thus would 
just be left lying around using up resources if it isn’t deleted by Trove 
(while potentially having the use charged back to the end user).  This is the 
case that is being addressed – having a volume left undeleted even if the Nova 
instance is gone (or in this case didn’t start successfully).

Thanks,
Peter


From: Will Zhou [mailto:zzxw...@gmail.com<mailto:zzxw...@gmail.com>]
Sent: June-28-16 10:55 AM
To: OpenStack Development Mailing List (not for usage questions); Ali Adil

Subject: Re: [openstack-dev] Change in openstack/trove[master]: Ophaned Volume 
Not Removed on Instance Delete

Hi Scott, many thanks for your figuration.  Thanks and +1 for your nomination 
to nova core:)

Hi aadil, we should DETACH the volume, instead of DELETE. Please help enhance 
your code which is really a helpful fix to the bug. Thanks.

On Tue, Jun 28, 2016 at 10:51 PM D'Angelo, Scott 
<scott.dang...@hpe.com<mailto:scott.dang...@hpe.com>> wrote:
If a volume is attached to an instance, and the instance is deleted, the volume 
will be DETACHED, but the volume will still exist, it will NOT be DELETED.

It is up to the volume owner to delete the volume if they wish.


From: Will Zhou <zzxw...@gmail.com<mailto:zzxw...@gmail.com>>
Sent: Tuesday, June 28, 2016 8:43:51 AM
To: aa...@tesora.com<mailto:aa...@tesora.com>; OpenStack Development Mailing 
List (not for usage questions)
Subject: Re: [openstack-dev] Change in openstack/trove[master]: Ophaned Volume 
Not Removed on Instance Delete

Hi all,

I'd like to make sure should the volume, which is attached to an instance, be 
detached or be deleted after the instance is deleted? Thanks.


On Tue, Jun 28, 2016 at 10:16 PM Ali Asgar Adil (Code Review) 
<rev...@openstack.org<mailto:rev...@openstack.org><mailto:rev...@openstack.org<mailto:rev...@openstack.org>>>
 wrote:
Ali Asgar Adil has posted comments on this change.

Change subject: Ophaned Volume Not Removed on Instance Delete
..


Patch Set 1:

In what situation would a nova instance be in "available" state. Also, we are 
are deleting the instance so we would want the volume to be deleted as well not 
detached.

--
To view, visit https://review.openstack.org/334722
To unsubscribe, visit https://review.openstack.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Ie921a8ff2851e2d9d76a3c3836945c750f090c4e
Gerrit-PatchSet: 1
Gerrit-Project: openstack/trove
Gerrit-Branch: master
Gerrit-Owner: Ali Asgar Adil 
<aa...@tesora.com<mailto:aa...@tesora.com><mailto:aa...@tesora.com<mailto:aa...@tesora.com>>>
Gerrit-Reviewer: Ali Asgar Adil 
<aa...@tesora.com<mailto:aa...@tesora.com><mailto:aa...@tesora.com<mailto:aa...@tesora.com>>>
Gerrit-Reviewer: Jenkins
Gerrit-Reviewer: zzxwill 
<zzxw...@gmail.com<mailto:zzxw...@gmail.com><mailto:zzxw...@gmail.com<mailto:zzxw...@gmail.com>>>
Gerrit-HasComments: No
--

-
?
???
Mobile: 13701280947
?WeChat: 472174291

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

-
​
周

Re: [openstack-dev] Change in openstack/trove[master]: Ophaned Volume Not Removed on Instance Delete

2016-06-28 Thread Peter Stachowski
Hi Will,

Trove is a managed database service.  Once you delete the database, all 
associated volumes with it are also deleted, as is the Nova instance.  One of 
the key benefits of using Trove is that you don’t have to manage 
servers/volumes/security_groups etc.  Also, depending on the provider’s 
implementation, the volume may not be visible to the end user and thus would 
just be left lying around using up resources if it isn’t deleted by Trove 
(while potentially having the use charged back to the end user).  This is the 
case that is being addressed – having a volume left undeleted even if the Nova 
instance is gone (or in this case didn’t start successfully).

Thanks,
Peter


From: Will Zhou [mailto:zzxw...@gmail.com]
Sent: June-28-16 10:55 AM
To: OpenStack Development Mailing List (not for usage questions); Ali Adil
Subject: Re: [openstack-dev] Change in openstack/trove[master]: Ophaned Volume 
Not Removed on Instance Delete

Hi Scott, many thanks for your figuration.  Thanks and +1 for your nomination 
to nova core:)

Hi aadil, we should DETACH the volume, instead of DELETE. Please help enhance 
your code which is really a helpful fix to the bug. Thanks.

On Tue, Jun 28, 2016 at 10:51 PM D'Angelo, Scott 
> wrote:
If a volume is attached to an instance, and the instance is deleted, the volume 
will be DETACHED, but the volume will still exist, it will NOT be DELETED.

It is up to the volume owner to delete the volume if they wish.


From: Will Zhou >
Sent: Tuesday, June 28, 2016 8:43:51 AM
To: aa...@tesora.com; OpenStack Development Mailing 
List (not for usage questions)
Subject: Re: [openstack-dev] Change in openstack/trove[master]: Ophaned Volume 
Not Removed on Instance Delete

Hi all,

I'd like to make sure should the volume, which is attached to an instance, be 
detached or be deleted after the instance is deleted? Thanks.


On Tue, Jun 28, 2016 at 10:16 PM Ali Asgar Adil (Code Review) 
>>
 wrote:
Ali Asgar Adil has posted comments on this change.

Change subject: Ophaned Volume Not Removed on Instance Delete
..


Patch Set 1:

In what situation would a nova instance be in "available" state. Also, we are 
are deleting the instance so we would want the volume to be deleted as well not 
detached.

--
To view, visit https://review.openstack.org/334722
To unsubscribe, visit https://review.openstack.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Ie921a8ff2851e2d9d76a3c3836945c750f090c4e
Gerrit-PatchSet: 1
Gerrit-Project: openstack/trove
Gerrit-Branch: master
Gerrit-Owner: Ali Asgar Adil 
>>
Gerrit-Reviewer: Ali Asgar Adil 
>>
Gerrit-Reviewer: Jenkins
Gerrit-Reviewer: zzxwill 
>>
Gerrit-HasComments: No
--

-
?
???
Mobile: 13701280947
?WeChat: 472174291

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

-
​
周正喜
Mobile: 13701280947
​WeChat: 472174291
__
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] [Trove] Stepping down from Trove Core

2016-06-08 Thread Peter Stachowski
Hi Victoria,

Thanks for all the help and good luck in your future work!

Peter

From: Victoria Martínez de la Cruz [mailto:victo...@vmartinezdelacruz.com]
Sent: June-07-16 2:34 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Trove] Stepping down from Trove Core


After one year and a half contributing to the Trove project,

I have decided to change my focus and start gaining more experience

on other storage and data-management related projects.



Because of this decision, I'd like to ask to be removed from the Trove core 
team.



I want to thank Trove community for all the good work and shared experiences.

Working with you all has been a very fulfilling experience.



All the best,



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


Re: [openstack-dev] [trove] timeouts in gate-trove-python34-db

2016-05-16 Thread Peter Stachowski
Victor,

You're right, all the tests are currently passing the detector.  There is still 
legacy code that does unmocking the 'old' way and there is a fair bit of it.  
Our concern if you remove the detector is that objects that have been mocked 
might not be unmocked correctly (due to copy/paste) and we might miss it in 
review.  The detector won't miss it, and so we don't have to worry about it.

We could fix all the old tests, but (as I said) it was agreed upon that that 
would not be productive and might even destabilize the code base, so it wasn't 
done.  At the moment the detector is still doing a useful job and I don't think 
we can get rid of it just yet.

Peter


-Original Message-
From: Victor Stinner [mailto:vstin...@redhat.com] 
Sent: May-16-16 12:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [trove] timeouts in gate-trove-python34-db

Le 16/05/2016 16:12, Peter Stachowski a écrit :
> We're aware that there are ways to mock (and un-mock) correctly.
> We're trying to make sure that all our new test code follows those 
> patterns.  We also decided that it wouldn't make sense to change all 
> the working tests to use the 'right' methods as that could have the 
> short-term effect of destabilizing the tests considerably (plus it 
> would be a fair bit of effort with very little actual gain). As a 
> compromise we added this code to check that things weren't left mocked 
> (just in case someone copy-pasted the old style, did it wrong and 
> no-one noticed - we're still trying to maintain consistency wherever 
> possible).

Thanks for the explanation. But I don't understand something.

The purpose of the code detecting dangling mocks is to find bugs in "legacy" 
tests which don't use correctly the mock module. I read the code and I saw that 
it makes the unit test failing in such case. All unit tests pass on Python 2. 
Does it mean that all the legacy code is gone and all unit tests use correctly 
the mock module?

If I'm wrong, how can we detect remaining "dangling mocks"? Would it be 
possible to fix them at once to be able to remove the code detecting dangling 
mocks?

I proposed a patch to remove the code detecting dangling mocks: it makes unit 
tests 13x faster on Python 3 (183.6 sec => 13.8 sec):

https://review.openstack.org/#/c/316955/

Victor

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

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


Re: [openstack-dev] [trove] timeouts in gate-trove-python34-db

2016-05-16 Thread Peter Stachowski
Victor,

To correct the math, Python3 runs 686 tests in 15.971s or 42.95 tests per 
second.  Python2 runs 1495 tests in 22.595s or 66.16 tests per second.  Python2 
is 54% faster (but even that's just an estimate, since it assumes all tests run 
at the same speed, which isn't true - plus it runs them on different hardware 
and not all VMs are created equal ;) ).

We're aware that the 'dangling mock detector' makes the code run significantly 
slower (historically ~15 min instead of ~5 min) however it's helped us catch 
more than one bug with minimal effort.  The question is why does it run even 
slower in python3?  If it is just the infra issue of running on slower 
hardware, then we could probably address that.

Peter



-Original Message-
From: Victor Stinner [mailto:vstin...@redhat.com] 
Sent: May-16-16 10:57 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [trove] timeouts in gate-trove-python34-db

Le 16/05/2016 16:12, Peter Stachowski a écrit :
> Amrith is right though - python34 is *much* slower running this check 
> (and somewhat in general) than python27.  Maybe that doesn't translate 
> into real-world performance data, but it has made me a bit nervous 
> nonetheless.

IMHO we should look more closely to the output. See my comments on the bug 
report:

https://bugs.launchpad.net/trove/+bug/1582257

Currently, running unit tests on Python 3 runs 686 tests in 15.971s, whereas 
Python 2 runs 1495 tests in 22.595s. Python 3 is "faster" :-)
(16 sec < 23 sec)

The whole Python 3 job takes 10 minutes, but in these 10 minutes, almost
8 minutes are taken just to build binary wheel packages. On Python 2, prebuilt 
packages are used and so creating the virtual environment is much faster 
(around one minute). I proposed a change to prebuild also wheel packages on 
Python 3:

https://review.openstack.org/#/c/316890/

Ok, but sometimes we get timeout, right? Again, if you look closely to the 
output, between two runs on Python 2, the timing also changes a lot:

(a) Ran 1495 tests in 22.595s
(b) Ran 1495 tests in 393.364s => 17x slower!

The issue is not specific to Python 3. But it looks like the random slowdown is 
much larger on Python 3. Duration of Python 3 unit tests:

(a) "Ran 686 tests in 15.971s"
(b) "Ran 686 tests in 1581.090s" => 100x slower!

I guess that the difference is that Python 3 unit tests are currently run 
sequentially (1 process), whereas Python 2 unit tests are run in parallel (8 
processes).

*Again* please check the code detecting dangling mocks. For example, "tox -e 
py34" takes 14 seconds without this code, 177 seconds with the
code: 12x slower with the code.

Victor

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

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


Re: [openstack-dev] [trove] timeouts in gate-trove-python34-db

2016-05-16 Thread Peter Stachowski
Victor,

We're aware that there are ways to mock (and un-mock) correctly.  We're trying 
to make sure that all our new test code follows those patterns.  We also 
decided that it wouldn't make sense to change all the working tests to use the 
'right' methods as that could have the short-term effect of destabilizing the 
tests considerably (plus it would be a fair bit of effort with very little 
actual gain). As a compromise we added this code to check that things weren't 
left mocked (just in case someone copy-pasted the old style, did it wrong and 
no-one noticed - we're still trying to maintain consistency wherever possible). 
 As the code base gets cleaned up we can eventually run this just once per test 
class, or even just once at the end of the test run.  Petr has a changeset up 
now that will reduce it to twice per class 
(https://review.openstack.org/#/c/312781 ), and as I said we can drop that to 
just one probably by the end of the cycle.

Amrith is right though - python34 is *much* slower running this check (and 
somewhat in general) than python27.  Maybe that doesn't translate into 
real-world performance data, but it has made me a bit nervous nonetheless.

Peter


-Original Message-
From: Victor Stinner [mailto:vstin...@redhat.com] 
Sent: May-16-16 9:38 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [trove] timeouts in gate-trove-python34-db

Le 16/05/2016 13:52, Amrith Kumar a écrit :
>> IMHO the strange mock detector code must be removed. It is very slow 
>> and I don't understand its purpose.
>
> [amrith] It serves and has served a very useful purpose and that is to 
> detect bad tests where code has (and we've had lots of trouble with 
> this) established a Mock() but failed to delete it.

There are many options to disable (unregister, stop, call it as you
want) mocks automatically. As I wrote, fixtures & oslotest give you tools to do 
that automatically. It's also a base feature of the mock
module: "with mock.patch(...): ...". Sorry, I don't know enough the Trove code 
base (code of the unit tests) to say which option is the best.


> I'd rather figure out why it is slower in Python3 because it may be 
> indicative of something that may impact other parts of the code as 
> well. We're having this whole discussion about Python performance and 
> the Go language, I think it is not a good idea to delete code which is 
> performing poorly because it is performing slowly.

Sorry but Go doesn't solve badly designed functions :-) It's an algorithmic 
complexity issue: the function has to iterate on *all* alive Python objects: 
complexity of O(n). I propose to remove to code to simplify the complexity to 
O(1) :-)

Ok, let's take an example with Python 2.7: the command "python -bb -m 
testtools.run trove/tests/unittests/common/test_exception.py" takes 972 ms. 
Remove the mock workaround, the command now taks 1 ms: it's now 972x faster.

=> removing the slow workaround makes test ~1000x faster!

IMHO it's worth to start here, instead of starting to investigate why running 
tests on Python 3 seems slower.

I'm not aware of such huge performance difference between Python 2 and Python 3 
when running unit tests on other OpenStack services. The issue is specific to 
Trove, and IMHO it comes from the mock workaround.

Victor

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

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


Re: [openstack-dev] [trove] timeouts in gate-trove-python34-db

2016-05-09 Thread Peter Stachowski
Hi Amrith,

We've had a lot of 'new' tests enabled for py34 in the last week - from your 
results you can see it's running 6x the number of tests (although it's taking 
8.5x as long).  It looks like python3 isn't as fast as python2.7?  If so, we 
may have to do something wrt the 'dangling-mock' detector code so that the 
tests run faster (I believe we can optimize it now that all the tests have 
moved over to the new paradigm).

Peter

From: Amrith Kumar [mailto:amr...@tesora.com]
Sent: May-08-16 8:42 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [trove] timeouts in gate-trove-python34-db


I'm seeing python34's gate job running very long and sometimes it is timing out 
at 40m. There is something amiss with this and I've let Victor and Abhishek 
know about it.



In https://review.openstack.org/#/c/313941/ which is a dummy commit (just 
changed README.rst) it took 37m.



2016-05-08 21:35:11.438 | Tests running...

2016-05-08 21:35:11.438 |

2016-05-08 21:35:11.438 | Ran 686 tests in 1581.090s

2016-05-08 21:35:11.439 | OK



On the other hand, in other reviews (https://review.openstack.org/#/c/222752/) 
it takes barely 15m.



2016-05-02 19:26:06.018 | Tests running...

2016-05-02 19:26:06.019 |

2016-05-02 19:26:06.019 | Ran 115 tests in 185.864s

2016-05-02 19:26:06.019 | OK



Running it on my desktop takes a long time as well. I guess we'll have to 
figure out why this is generating these failures.



-amrith
__
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] [trove] Adding release notes to changes

2016-04-18 Thread Peter Stachowski
Right, we are still waiting on the final +2/+1 for that  ;)

See https://review.openstack.org/#/c/306018/

Thanks!
Peter

-Original Message-
From: Andreas Jaeger [mailto:a...@suse.com] 
Sent: April-18-16 2:32 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [trove] Adding release notes to changes

On 2016-04-17 19:04, Amrith Kumar wrote:
>> -Original Message-
>> > From: Andreas Jaeger [mailto:a...@suse.com]
>> > Sent: Sunday, April 17, 2016 4:31 AM
>> > To: OpenStack Development Mailing List (not for usage questions) 
>> > 
>> > Subject: Re: [openstack-dev] [trove] Adding release notes to 
>> > changes
>> > 
>> > On 04/16/2016 05:07 PM, Amrith Kumar wrote:
>>> > > Folks,
>>> > >
>>> > > We are now using reno[1] for release notes in trove, 
>>> > > trove-dashboard, and python-troveclient.
>> > 
>> > Note that the trove-dashboard changes are not published and tested 
>> > at all, you do not have set it up in project-config yet,
> [amrith] Oink? I thought this was dealt with in 
> https://review.openstack.org/#/c/306012/
> 
> Yes, there are currently no release notes for trove-dashboard, and I know 
> that the release notes jobs need to be added in zuul etc., Am I missing 
> something else?
> 

That's all I wanted to point out - add it to project-config repo.
Without that, you have no job to test and publish the release notes,

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


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

__
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] [trove] Adding release notes to changes

2016-04-16 Thread Peter Stachowski
Just a note that certain character combinations cannot be used in the yaml file 
text as they are parsed (such as ': ' and '- ' that is a colon or dash with a 
space after). If you need to use either a colon or dash, then you cannot have a 
space, or you must enclosed the entire text in quotes. For bug numbers, it's 
probably easiest just to use a format like 'Bug 1234567' to avoid this issue.

Thanks,
Peter

-Original Message-
From: Amrith Kumar [mailto:amr...@tesora.com] 
Sent: April-16-16 11:07 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [trove] Adding release notes to changes

Folks,

We are now using reno[1] for release notes in trove, trove-dashboard, and 
python-troveclient.

If you submit a change to any one of these repositories, that is going to be 
visible to a user (i.e. not changes that only impact tests, or are procedural 
changes relating to management of the repository etc.,) please DO add a release 
note.

For instructions on how to add a release note, please see [2].

Once you add a release note, please be sure to run

tox -e releasenotes 

before you push your change set for review. It will save you a lot of time, and 
will spare the CI a lot of unnecessary testing.

If you are fixing a bug, please include the LP bug number(s) in the release 
note.

Some samples of release notes are provided in [3], [4], and [5].

Thanks,

-amrith

[1] http://docs.openstack.org/developer/reno/
[2]
http://docs.openstack.org/project-team-guide/release-management.html#how-to-add-new-release-notes
[3]
https://review.openstack.org/#/c/237184/6/releasenotes/notes/fix-cluster-issues-2651eaf31a85b11f.yaml
[4]
https://review.openstack.org/#/c/39/4/releasenotes/notes/fix-mysql-replication-bf2b131994a5a772.yaml
[5]
https://review.openstack.org/#/c/301936/4/releasenotes/notes/locality-support-for-clusters-78bb74145d867df2.yaml

__
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] [Trove][FFE] Module management

2016-03-03 Thread Peter Stachowski
I'd like to request a feature freeze exception for "Add support for adding and 
applying module configuration to an instance" [1]

The work was split up and several parts of this have already merged in Mitaka. 
[2][3][4]. I have one more troveclient commit and a commit for the remainder of 
the server and guestagent implementation. I expect this work to be up for 
review in 2-3 days.


[1] https://blueprints.launchpad.net/trove/+spec/module-management
[2] https://review.openstack.org/284526
[3] https://review.openstack.org/284399
[4] https://review.openstack.org/284482

Regards,
Peter Stachowski
Tesora 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


Re: [openstack-dev] [trove] Nominating Mariam John to Trove Core

2016-01-06 Thread Peter Stachowski
I agree!

+1

Peter

-Original Message-
From: Vyvial, Craig [mailto:craig.vyv...@hpe.com] 
Sent: January-06-16 2:40 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [trove] Nominating Mariam John to Trove Core

Thanks for the nomination Amrith and I think Mariam will be a great addition to 
the core team.

+1

-Craig

On Jan 6, 2016, at 12:39 PM, Amrith Kumar 
> wrote:

Members of the Trove team,

I would like to nominate Mariam John (johnma on IRC) to the Trove core review 
team.

Mariam has been an active member of the Trove team for some time now. She added 
support for IBM DB2 in Trove and provided elements for building Trove guest 
images. She also implemented code that provided CouchDB support in Trove. She 
has been an active reviewer and I have found her review comments to be 
insightful and useful.

You can review her activity report at

http://stackalytics.com/report/users/mariamj

Members of the Trove core team, please reply to this message with your feedback 
to this proposed change.

Thanks,

-amrith

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


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

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


Re: [openstack-dev] [trove]Any process of redis configuration group

2015-06-18 Thread Peter Stachowski
Hi chendi...@unitedstack.commailto:chendi...@unitedstack.com,  (you forgot to 
identify yourself ;) )

A quick search in gerrit turned up the following review for ‘Configuration 
Groups for Redis’: https://review.openstack.org/#/c/191860

Hope that helps!

Thanks,
Peter



From: 陈迪豪 [mailto:chendi...@unitedstack.com]
Sent: June-18-15 10:14 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [trove]Any process of redis configuration group

Hi all,

We're trying to implement redis configuration group for trove. Now I can see 
the blueprint in 
http://specs.openstack.org/openstack/trove-specs/specs/liberty/redis-configuration-groups.html

But is anyone working on it now? It would be better to know about the process 
about it and help for the community.
__
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] [trove] where is the api to fetch mysql log?

2015-04-15 Thread Peter Stachowski
Hi Li,

Unfortunately, fetching the logs didn't make it into kilo and is still an 
ongoing project.  It should make it into liberty, though.  ;)

Regards,
Peter Stachowski

From: Li Tianqing [mailto:jaze...@163.com]
Sent: April-15-15 10:30 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [trove] where is the api to fetch mysql log?

Hi,
   all, i know the kilo-rc 1 is released. I found an introduction about new 
features here
http://www.slideshare.net/openstack/trove-juno-to-kilo
   It says that we can fetch mysql error log. Then i search in the source code 
on master branch, and i do not find the api. Can someone help me ?


--
Best
Li Tianqing

__
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] [all] Ask for help with devstack error

2015-02-12 Thread Peter Stachowski
Hi,

Take a look at this commit, it broke a number of Trove tests last night: 
https://review.openstack.org/#/c/154391

Not sure if it’s related, but it seems similar (try manually backing out the 
change for cinder and see if it fixes your problem).

Good luck!
Peter

From: liuxinguo [mailto:liuxin...@huawei.com]
Sent: February-12-15 6:57 AM
To: openstack-dev@lists.openstack.org; openstack-in...@lists.openstack.org
Cc: Zhangli (ISSP); Fanyaohong; Chenzongliang
Subject: [openstack-dev] [all] Ask for help with devstack error

Our CI failed when building devstack, the error is about “Unauthorized”. 
Following is the segment of the devstacklog:


2015-02-12 11:16:14.639 | + is_service_enabled c-api
2015-02-12 11:16:14.646 | + return 0
2015-02-12 11:16:14.646 | + is_service_enabled tls-proxy
2015-02-12 11:16:14.646 | + _run_process c-vol '/usr/local/bin/cinder-volume 
--config-file /etc/cinder/cinder.conf' ''
2015-02-12 11:16:14.647 | + local service=c-vol
2015-02-12 11:16:14.647 | + local 'command=/usr/local/bin/cinder-volume 
--config-file /etc/cinder/cinder.conf'
2015-02-12 11:16:14.647 | + local group=
2015-02-12 11:16:14.647 | + exec
2015-02-12 11:16:14.647 | + exec
2015-02-12 11:16:14.658 | + return 1
2015-02-12 11:16:14.658 | + create_volume_types
2015-02-12 11:16:14.659 | + is_service_enabled c-api
2015-02-12 11:16:14.687 | + return 0
2015-02-12 11:16:14.688 | + [[ -n lvm:default ]]
2015-02-12 11:16:14.688 | + local be be_name be_type
2015-02-12 11:16:14.688 | + for be in '${CINDER_ENABLED_BACKENDS//,/ }'
2015-02-12 11:16:14.688 | + be_type=lvm
2015-02-12 11:16:14.688 | + be_name=default
2015-02-12 11:16:14.689 | + cinder type-create default
2015-02-12 11:16:22.734 | ERROR: Unauthorized (HTTP 401) (Request-ID: 
req-33c9392a-046f-4894-b22a-1a119eacec62)‍

In c-api.log, I find the error with “auth_token”:

2015-02-12 03:16:19.722 19912 WARNING keystonemiddleware.auth_token [-] 
Retrying on HTTP connection exception: SSL exception connecting to 
https://127.0.0.1:35357/
2015-02-12 03:16:20.723 19912 DEBUG keystoneclient.session [-] REQ: curl -g -i 
--cacert /opt/stack/data/ca-bundle.pem -X GET https://127.0.0.1:35357/ -H 
Accept: application/json -H User-Agent: python-keystoneclient 
_http_log_request 
/opt/stack/new/python-keystoneclient/keystoneclient/session.py:190
2015-02-12 03:16:20.724 19912 DEBUG urllib3.util.retry [-] Converted retries 
value: 0 - Retry(total=0, connect=None, read=None, redirect=0) from_int 
/usr/local/lib/python2.7/dist-packages/urllib3/util/retry.py:155
2015-02-12 03:16:22.730 19912 ERROR keystonemiddleware.auth_token [-] HTTP 
connection exception: SSL exception connecting to https://127.0.0.1:35357/
2015-02-12 03:16:22.731 19912 WARNING keystonemiddleware.auth_token [-] 
Authorization failed for token‍

Any one can give me some help?
Thanks!
__
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] [Trove] Core reviewer update

2015-02-05 Thread Peter Stachowski
Hi Nikhil et al.,

Thanks for the nomination!  I’m more than happy to join the core team and do 
all I can to help improve Trove and the community.  Also a +1 for the other 
nominations and sincere thanks for all the work hub_cap and grapex have done 
over the years.  Let’s keep the momentum going!

Thanks all!
Peter

From: Nikhil Manchanda [mailto:slick...@gmail.com]
Sent: February-05-15 8:27 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Trove] Core reviewer update

Hello Trove folks:

Keeping in line with other OpenStack projects, and attempting to keep
the momentum of reviews in Trove going, we need to keep our core-team up
to date -- folks who are regularly doing good reviews on the code should
be brought in to core and folks whose involvement is dropping off should
be considered for removal since they lose context over time, not being
as involved.

For this update I'm proposing the following changes:
- Adding Peter Stachowski (peterstac) to trove-core
- Adding Victoria Martinez De La Cruz (vkmc) to trove-core
- Adding Edmond Kotowski (edmondk) to trove-core
- Removing Michael Basnight (hub_cap) from trove-core
- Removing Tim Simpson (grapex) from trove-core

For context on Trove reviews and who has been active, please see
Russell's stats for Trove at:
- http://russellbryant.net/openstack-stats/trove-reviewers-30.txt
- http://russellbryant.net/openstack-stats/trove-reviewers-90.txt

Trove-core members -- please reply with your vote on each of these
proposed changes to the core team. Peter, Victoria and Eddie -- please
let me know of your willingness to be in trove-core. Michael, and Tim --
if you are planning on being substantially active on Trove in the near
term, also please do let me know.

Thanks,
Nikhil
__
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] [Trove] Proposal to add Iccha Sethi to trove-core

2014-10-30 Thread Peter Stachowski
+1

-Original Message-
From: Nikhil Manchanda [mailto:nik...@manchanda.me] 
Sent: October-30-14 4:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core

Hello folks:

I'm proposing to add Iccha Sethi (iccha on IRC) to trove-core.

Iccha has been working with Trove for a while now. She has been a very active 
reviewer, and has provided insightful comments on numerous reviews. She has 
submitted quality code for multiple bug-fixes in Trove, and most recently drove 
the per datastore volume support BP in Juno. She was also a crucial part of the 
team that implemented replication in Juno, and helped close out multiple 
replication related issues during Juno-3.

https://review.openstack.org/#/q/reviewer:iccha,n,z
https://review.openstack.org/#/q/owner:iccha,n,z

Please respond with +1/-1, or any further comments.

Thanks,
Nikhil

___
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


Re: [openstack-dev] [Trove] Proposal to add Craig Vyvial to trove-core

2014-05-06 Thread Peter Stachowski
+1

-Original Message-
From: Nikhil Manchanda [mailto:nik...@manchanda.me] 
Sent: May-06-14 5:32 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Trove] Proposal to add Craig Vyvial to trove-core


Hello folks:

I'm proposing to add Craig Vyvial (cp16net) to trove-core.

Craig has been working with Trove for a while now. He has been a consistently 
active reviewer, and has provided insightful comments on numerous reviews. He 
has submitted quality code to multiple features in Trove, and most recently 
drove the implementation of configuration groups in Icehouse.

https://review.openstack.org/#/q/reviewer:%22Craig+Vyvial%22,n,z
https://review.openstack.org/#/q/owner:%22Craig+Vyvial%22,n,z

Please respond with +1/-1, or any further comments.

Thanks,
Nikhil

___
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