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

[Mariam John]

Thank you Craig for your leadership and hard work in helping shape and
guide the Trove community. Wish you good luck and success in everything you
do.

Regards,
Mariam.




From:   Craig Vyvial 
To: OpenStack Development Mailing List

Date:   10/07/2016 10:25 PM
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

__
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] OpenStack Trove Ocata Virtual Midcycle,

[Mariam John]

Hello Amrith,

  Just wanted to confirm that I can attend the virtual midcycle during the
proposed dates: July 26th-28th.

Thank you.

Regards,
Mariam.




From:   Amrith Kumar 
To: "OpenStack Development Mailing List (not for usage questions)"
,
"openstack-operat...@lists.openstack.org"

Date:   06/25/2016 04:50 AM
Subject:[openstack-dev] [trove] OpenStack Trove Ocata Virtual Midcycle,




After we discussed and announced this mid-cycle, there has been some
feedback that (a) it would be better to hold the mid-cycle earlier, and (b)
NYC was not the most convenient location for all attendees.

Thanks for the feedback. Given that we are coming up on a holiday week (in
the US), and the N2 deadline in the week of July 18th, I propose that we
conduct the Trove Ocata midcycle as a virtual midcycle in the week of July
25th.

In the interest of time, I'd like all those who are able and interested in
attending to reply to this email so we can confirm this at the Trove
meeting on Wednesday.

 Trove Ocata Virtual Midcycle
 Date and Time: 4 hours each day, July 26, 27 and 28; 1300-1700
EDT
 (1200 - 1600 CDT, 1000 to 1400 PDT, 1700 to 
2100
UTC)
 Location: Virtual midcycle, [likely] Google Hangouts with
audio dial in (telephone)

Thanks,

-amrith



> -Original Message-
> From: Amrith Kumar
> Sent: Wednesday, June 22, 2016 9:54 AM
> To: openstack-dev 
> Subject: OpenStack Trove Ocata Midcycle, NYC, August 25 and 26.
>
> The Trove midcycle will be held in midtown NYC, thanks to IBM for hosting
> the event, on August 25th and 26th.
>
> If you are interested in attending, please join the Trove meeting today,
> 2pm Eastern Time (#openstack-meeting-alt) and register at
> http://www.eventbrite.com/e/openstack-trove-ocata-midcycle-tickets-
> 26197358003.
>
> An etherpad for proposing sessions is at
> https://etherpad.openstack.org/p/ocata-trove-midcycle
>
> This will be a two-day event (not three days as we have done in the past)
> so we will start early on 25th and go as late as we can on 26th
> recognizing that people who have to travel out of NYC may want to get
late
> flights (9pm, 10pm) on Friday.
>
> 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

Re: [openstack-dev] [Trove] Stepping down from Trove Core

[Mariam John]

Thank you Victoria for all your hard work and dedication to the Trove
project. It's been a pleasure knowing you and working with you.

Wish you all the best and good luck.

Regards,
Mariam.




From:   Victoria Martínez de la Cruz 
To: OpenStack Development Mailing List

Date:   06/07/2016 01:37 PM
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

__
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][sahara][infra][Octavia][manila] discussion of image building in Trove

[Mariam John]

From:   Victoria Martínez de la Cruz <victo...@vmartinezdelacruz.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:   05/05/2016 08:12 AM
Subject:Re: [openstack-dev] [trove][sahara][infra][Octavia][manila]
discussion of image building in Trove



Hi all,

A few things:

- I agree that moving from DIB to libguestfs is a bold move and that we
should try to avoid changing tools unless highly necessary. The downsides
we found for DIB are detailed in this spec [0] and Ethan (in this same
thread) also added valid points on the Sahara case. My concern here is,
should we stick with DIB just because is the standard for image creation?
Shouldn't we take in consideration that some projects, like Sahara, are
moving away from?

I think it would be worth trying to see if DIB can address the concerns
raised by the different projects around image building and improve upon
that. By improving DIB, I think all these projects and OpenStack in general
can benefit from it.

- In the long term it would be ideal that we reach to a common solution for
image creation for all the projects that need tailored images: Trove,
Sahara, Octavia, Manila, and IIRC, Kolla and Cue.
- In the short term, I'm on board or working on having tools based on DIB
for image creation in Trove.
- Amrith, Pete is working on the image creation process for Trove. The spec
is up there [0]. I think is his work to kick-off that repository.

Best,

Victoria

[0] https://review.openstack.org/#/c/295274/

2016-05-04 23:20 GMT-03:00 Amrith Kumar <amr...@tesora.com>:
  As we discussed at summit, (and consistent with all of the comments) we
  should move ahead with the project to advance the image builder for Trove
  and make it easier to build guest images for Trove by leveraging the DIB
  elements that we have in trove-integration.





  To that end, the infra [1] and governance [2] changes have been submitted
  for review. The Launchpad tracker [3] has been registered.





  I am working on taking the existing DIB elements in trove-integration and
  putting them in the new repository (openstack/trove-image-builder). I am
  also going to continue to watch this conversation and record any
  shortcomings with the existing DIB elements in Launchpad [3] and work on
  fixing those as well. Pete mentions one in his earlier email and I’ve
  logged that in Launchpad [4].





  Thanks,





  -amrith





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


  [2] https://review.openstack.org/#/c/312806/


  [3] https://launchpad.net/trove-image-builder


  [4] https://bugs.launchpad.net/trove-image-builder/+bug/1578454











  From: Mariam John [mailto:mari...@us.ibm.com]
  Sent: Wednesday, May 04, 2016 4:19 PM
  To: OpenStack Development Mailing List (not for usage questions) <
  openstack-dev@lists.openstack.org>



  Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila]
  discussion of image building in Trove





  The way I see this, these are the 2 main concerns I have been hearing
  regarding image building in Trove:
  1) making the process simple and easy for users
  2) addressing the issue of security

  I dont think there is any argument regarding the benefits of moving the
  database elements to a seperate repository and packaging and managing
  them from there.

  It looks like the case that we make for whether to use libguestfs or DIB
  for image building are in the technical details of how image building
  happens and their nuances - assuming that ease of use & having a simple
  interface to build secure images matters most, I wonder if the end-users
  would be concerned about these details.

  By addressing some of the issues like:
  - moving the Trove elements to a new repository
  - adding support for new distros
  - creating a wrapper script for building an image -getting the Trove
  guest agent code & configuration files
  - managing environment variables better

  I believe it will make a huge improvement in terms of simplifying and
  improving the ease of use for end users and hence could be the low
  hanging fruit that we can implement in the mean time. I agree that
  switching from DIB to any other tool is a big step and we need to put
  alot of thought into it like many others have suggested. Like Pete
  mentioned earlier in one of the links, there are couple of other tools
  available for building images. I am sure we could make the case for each
  of these tools and how it is easier/faster/better than the others. If we
  go down this route experimenting with libguestfs, is there anything
  stopping us couple of releases down the lane from wanting to experiment
  with some other tool because libguestfs doesn't perform well? The end
  user could use any tool they want to use to create images if they wish to
  do so but I agree and believe that Trove should support a standard way of

Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

[Mariam John]

The way I see this, these are the 2 main concerns I have been hearing
regarding image building in Trove:
1) making the process simple and easy for users
2) addressing the issue of security

I dont think there is any argument regarding the benefits of moving the
database elements to a seperate repository and packaging and managing them
from there.

It looks like the case that we make for whether to use libguestfs or DIB
for image building are in the technical details of how image building
happens and their nuances - assuming that ease of use & having a simple
interface to build secure images matters most, I wonder if the end-users
would be concerned about these details.

By addressing some of the issues like:
  - moving the Trove elements to a new repository
  - adding support for new distros
  - creating a wrapper script for building an image -getting the Trove
guest agent code & configuration files
  - managing environment variables better

I believe it will make a huge improvement in terms of simplifying and
improving the ease of use for end users and hence could be the low hanging
fruit that we can implement in the mean time. I agree that switching from
DIB to any other tool is a big step and we need to put alot of thought into
it like many others have suggested. Like Pete mentioned earlier in one of
the links, there are couple of other tools available for building images. I
am sure we could make the case for each of these tools and how it is
easier/faster/better than the others. If we go down this route
experimenting with libguestfs, is there anything stopping us couple of
releases down the lane from wanting to experiment with some other tool
because libguestfs doesn't perform well? The end user could use any tool
they want to use to create images if they wish to do so but I agree and
believe that Trove should support a standard way of building images (DIB
being an OpenStack project, I would assume that would be the standard) and
do it well keeping it simple and easy to use as opposed to what it is
today.

I think we should split this into 2 tasks
  - one for going forward with seperating image building into a seperate
repository and putting all efforts into simplifying the current process,
and
  - second, to have a joint collaboration with the DIB/TripleO team to
raise concerns regarding DIB and see if we can address them in turn OR if
using a different tool like libguestfs makes sense at that point.

Thanks,
Mariam.



From:   Peter MacKinnon 
To: openstack-dev@lists.openstack.org
Date:   05/04/2016 12:39 PM
Subject:Re: [openstack-dev] [trove][sahara][infra][Octavia][manila]
discussion of image building in Trove



On 5/4/16 12:52 PM, Gregory Haynes wrote:
> On Wed, May 4, 2016, at 08:55 AM, Flavio Percoco wrote:
>> On 04/05/16 15:05 +, Amrith Kumar wrote:
>>> I'm emailing the ML on the subject of a review ongoing in the Trove
project regarding image building[1].
>>>
>>> TL;DR
>>>
>>> One of the most frequent questions that new users of Trove ask is how
and where to get guest images with which to experiment with Trove, and how
to build these images for themselves. While documentation about this exists
in multiple places (including [2], [3]) this is still something that can do
with some improvement.
>>>
>>> Trove currently uses diskimage-builder for building images used in
testing the product and these can serve as a good basis for anyone wishing
to build an image for their own use of Trove. The review [1] makes the
argument for the libguestfs based approach to building images and advocates
that Trove should use this instead of diskimage-builder.
>> At the summit we discussed the possibility of providing an
implementation
>> that
>> would allow for both DIB and libguestfs to be used but to give priority
>> to DIB.
>> Since there's no real intention of just switching tools at this point, I
>> believe
>> it'd be good to amend the spec so that it doesn't mention libguestfs
>> should be
>> used instead of DiB.
>>
>> The goal at this stage is to provide both and help these move forward.
>>
>>> I believe that a broader discussion of this is required and I
appreciate Greg Haynes' proposal at the design summit to have this
discussion on the ML. I took the action item to bring this discussion to
the ML.
>>>
>>> Details follow ...
>>>
>>> Before going further, I will state my views on these matters.
>>>
>>> 1. It is important for the Trove project to do things quickly to make
it easier for end users who wish to use Trove and who wish to build their
own images. I am not concerned what tool or tools a person will use to
build these images.
> ++. One of the biggest issues I see users of DIB hit is ease of use for
> 'just make me an image, I don't care about twiddling knobs'. A wrapper
> script in trove is one way to help with this, but I am sure there are
> other solutions as well... maybe by rethinking some of our fear about
> using elements as entry points to an 

Re: [openstack-dev] [all][trove] Trove bug scrub

[Mariam John]

Thanks Amrith for going through the list and triaging the bugs. I think
it's a great thing that we now have bugs assigned as 'low-hanging-fruit'.
It should make it easier for newcomers to pick bugs and get started.

Regards,
Mariam.




From:   Amrith Kumar 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   04/05/2016 03:59 PM
Subject:Re: [openstack-dev] [all][trove] Trove bug scrub




From: Victoria Martínez de la Cruz [mailto:victo...@vmartinezdelacruz.com]
Sent: Tuesday, April 05, 2016 4:35 PM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [all][trove] Trove bug scrub

Thanks Amrith.

I'll follow your lead and do some triaging as well.

We should organize bug triage days to make this process easier next time.

[amrith] I’ve been meaning to do this for some time and this morning I
finally got around to it. But in the future, it would be good to stay ahead
of this so we don’t have so much of backlog.

How about bug fixing days or bug squashing days? I’d love to do that as
well and further trim the backlog.

2016-04-05 14:44 GMT-03:00 Flavio Percoco :
 On 05/04/16 15:15 +, Amrith Kumar wrote:
  If you are subscribed to bug notifications from Trove, you’d have
  received a
  lot of email from me over the past couple of days as I’ve gone through
  the LP
  bug list for the project and attempted to do some spring cleaning.



  Here’s (roughly) what I’ve tried to do:



  -many bugs that have been inactive, and/or assigned to people who
  have not
  been active in Trove for a while have been updated and are now no longer
  assigned to anyone

  -many bugs that related to reviews that have been abandoned at some
  time
  and were marked as “in-progress” at the time are now updated; some are
  marked
  ‘confirmed’, others which appear to be no longer the case are set to
  ‘incomplete’

  -some bugs that were recently fixed, or are in the process of getting
  merged have been nominated for backports to mitaka and in some cases
  liberty

 Awesome! I'll go through the backport reviews.
  Over the next several days, I will continue this process and start
  assigning
  meaningful milestones for the bugs that don’t have them.



  There are now a number of bugs marked as ‘low-hanging-fruit’, and several
  others that are unassigned so please feel free to pitch in and help with
  making
  this list shorter.

 ++

 Flavio

 --
 @flaper87
 Flavio Percoco

 __
 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-dev] [Trove] Feature Freeze request for CouchDB backup & restore

[Mariam John]

Hello,

   I would like to request a feature freeze for the following feature: Add
support for CouchDB backup & restore [1]. The code for this feature is
complete and up for review [2]. The integration tests requires a new
library which was added to global-requirements [3]. Unit tests and
integration tests have been added to cover all the features implemented.
This feature implements full backup and restore capabilities for CouchDB
and uses the existing Trove API's and does not affect or alter the base
Trove code. Hence the risk for regression is very minimal.

Thank you.

Regards,
Mariam
[1] https://blueprints.launchpad.net/trove/+spec/couchdb-backup-restore
[2] https://review.openstack.org/#/c/270443/
[3] https://review.openstack.org/#/c/285191/
__
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] Tip: jsonformatter site for parsing/debugginglogs

[Mariam John]

T



From:   Doug Hellmann 
To: openstack-dev 
Date:   01/21/2016 10:38 AM
Subject:Re: [openstack-dev] Tip: jsonformatter site for
parsing/debugging   logs



Excerpts from Matt Riedemann's message of 2016-01-21 10:09:32 -0600:
> Are you tired of trying to strain your eyes to parse something like this
> in the logs [1]?
>
> vif=VIF({'profile': {}, 'ovs_interfaceid':
> u'ac3ca8e7-c22d-4f63-9620-ce031bf3eaac', 'preserve_on_delete': False,
> 'network': Network({'bridge': u'br-int', 'subnets': [Subnet({'ips':
> [FixedIP({'meta': {}, 'version': 4, 'type': u'fixed', 'floating_ips':
> [], 'address': u'10.100.0.18'})], 'version': 4, 'meta': {u'dhcp_server':
> u'10.100.0.17'}, 'dns': [], 'routes': [], 'cidr': u'10.100.0.16/28',
> 'gateway': IP({'meta': {}, 'version': None, 'type': u'gateway',
> 'address': None})})], 'meta': {u'injected': False, u'tenant_id':
> u'1d760ac487e24e06add18dacefa221a1'}, 'id':
> u'b13e9828-2bd9-4fb4-a20d-a92e2a8c1a77', 'label':
> u'tempest-network-smoke--1979535575'}), 'devname': u'tapac3ca8e7-c2',
> 'vnic_type': u'normal', 'qbh_params': None, 'meta': {}, 'details':
> {u'port_filter': True, u'ovs_hybrid_plug': True}, 'address':
> u'fa:16:3e:0c:d3:95', 'active': False, 'type': u'ovs', 'id':
> u'ac3ca8e7-c22d-4f63-9620-ce031bf3eaac', 'qbg_params': None}
>
> I found https://jsonformatter.curiousconcept.com/ which is nice since
> you can just copy that json from the logs and paste it into the text
> area and format it (I disable validation).

You can also do this using Python's json module from the command line:

$ echo '{"json":"obj"}' | python -m json.tool
{
  "json": "obj"
}

Doug

__
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] Nominating Mariam John to Trove Core

[Mariam John]

Thank you for all the support. I am humbled to be part of a truly great
team and I look forward to working with all of you and continuing to
contribute to OpenStack Trove.

Thank you.

Mariam.




From:   "Vyvial, Craig" <craig.vyv...@hpe.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:   01/08/2016 03:30 PM
Subject:Re: [openstack-dev] [trove] Nominating Mariam John to Trove
Core



Looks like we have a consensus from the team and I’d like to welcome Mariam
John to the Trove Core Team!

I look forward to continuing to work with Mariam!

Thanks,
-Craig


On Jan 7, 2016, at 12:21 PM, Nikhil Manchanda <nik...@manchanda.me<
mailto:nik...@manchanda.me>> wrote:

+1 from me as well.
Couldn't agree more!

Thanks,
-Nikhil

On Wed, Jan 6, 2016 at 12:03 PM, Peter Stachowski <pe...@tesora.com<
mailto:pe...@tesora.com>> wrote:
I agree!

+1

Peter

-Original Message-
From: Vyvial, Craig [mailto:craig.vyv...@hpe.com<
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 <amr...@tesora.com<
mailto:amr...@tesora.com><mailto:amr...@tesora.com<mailto:amr...@tesora.com
>>> 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<
mailto:openstack-dev-requ...@lists.openstack.org><
mailto:openstack-dev-requ...@lists.openstack.org<
mailto: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<
mailto: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] [opensatck-dev][trove]redis replication

[Mariam John]

Have you checked the blueprint for this at:
https://review.openstack.org/#/c/189445/.

Hope that helps.

Regards,
Mariam.




From:   李田清 tianq...@unitedstack.com
To: openstack-dev openstack-dev@lists.openstack.org
Date:   06/17/2015 02:06 AM
Subject:[openstack-dev] [opensatck-dev][trove]redis replication



Hello,
Right now we can create one replication once, but it is not suitable
for redis. What we will do for this?
And if time permit can the assigner of redis replication tell about the
process for redis replication? Thanks a lot.
__
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-dev] Feature Freeze request for DB2 support in Trove

[Mariam John]

Hello,

   I would like to request a feature freeze for Trove for the following
feature: Add DB2 support for Trove (
https://blueprints.launchpad.net/openstack/?searchtext=db2-plugin-for-trove
)

These are the patches related to this blueprint:
- https://review.openstack.org/#/c/164293/
- https://review.openstack.org/#/c/156802/

The changes include the following changes:
- disk image builder elements for DB2 to create DB2 images
- guest agent for DB2 which will enable users to create/delete DB2
instances, databases and users.

Unit tests have been added to cover all the API's implemented by this guest
agent and the patches have been linked to the blueprint. The risk for
regression is very minimal since the changes use the exisiting API's and is
providing support for a new datastore and the code changes does not affect
base Trove code.

Thank you.

Regards,
Mariam 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

Re: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core

[Mariam John]

+1



From:   Peter Stachowski pe...@tesora.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   10/30/2014 08:45 AM
Subject:Re: [openstack-dev] [Trove] Proposal to add Iccha Sethi to
trove-core



+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

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