Re: [openstack-dev] [Trove] Trove-Gate timeouts

Hi Nikhil, This is great! You may have assumed this but I wanted to be explicit: To get the higher timeout, I think all that needs to be done is to upgrade the boot-hpcloud-vm plugin. Then the plugin will pass the current timeout (7200 in rdjenkins) down to the net-ssl-simple library. (This is al

Re: [openstack-dev] [Trove] Trove-Gate timeouts

Hi Mathew: Nice work identifying these issues with the current Jenkins integration tests! I'm looking into some of these issues at the moment and am attempting to ensure that the appropriate fixes are merged so that the Trove integration gate job is healthy again. Some of my comments are inline.

Re: [openstack-dev] [Trove] Trove-Gate timeouts

Hi, Craig. Yes, i thought about configurations test suits. For now core team, maybe, should extend gate running time. But for the tempest tests i would suggest to exclude some tests from 'gate'-group (the longest ones). We need to deal with it asap, because gate failing for four or five days. Bes

Re: [openstack-dev] [Trove] Trove-Gate timeouts

Trovesters, One reason for the longer running test was that for the configuration groups i added a creation of a new instance. This is to test a new instance will be created with a configuration group applied. This might be causing the run to be a little longer but i am surprised that its taking o

Re: [openstack-dev] [Trove] Trove-Gate timeouts

Hello, Mathew. I'm seeing same issues with the gate. I also tried to found out why gate job is failing. First ran into issue related to cinder installation failure in devstack. But then I found same problem as you described. The best option is to increase job time range. Thanks for such researc

[openstack-dev] [Trove] Trove-Gate timeouts

Hi all, Issue #1: Jobs that need more than one hour Of the last 30 Trove-Gate builds (spanning three days), 7 have failed due to a Jenkins job-level timeout (not a proboscis timeout). These jobs had no failed tests when the timeout occurred. Not ha

Re: [openstack-dev] [Trove] Replication Contract Verbiage

Daniel Salinas writes: > https://wiki.openstack.org/wiki/Trove-Replication-And-Clustering-API#REPLICATION > > I have updated the wiki page to reflect the current proposal for > replication verbiage with some explanation of the choices. I would like to > open discussion here regarding that verbia

Re: [openstack-dev] [Trove] Backup/Restore encryption/decryption issue

As we decided at meeting, we wouldn't keep our own implementations of security stuff, we'll use Barbican as single entry point of delivering secrets. I hadn't talked with Barbican team, but since oslo-incubator will (someday) release oslo.crypto lib for all projects, i think that adding implementat

Re: [openstack-dev] [Trove] Backup/Restore encryption/decryption issue

Denis Makogon writes: > Goodday, OpenStack DВaaS community. > > > I'd like to start conversation about guestagent security issue related > to backup/restore process. Trove guestagent service uses AES with 256 bit > key (in CBC mode) [1] to encrypt backups which are stored at predefined >

Re: [openstack-dev] [Trove] Replication Contract Verbiage

Daniel, Couple questions. So what happens if/when the volume is different on the nodes in the replication cluster? If you need to resize the volume larger to handle more data are you required to resize all the nodes individually? It makes sense that maybe all the instances could have a different

[openstack-dev] [Trove] Replication Contract Verbiage

https://wiki.openstack.org/wiki/Trove-Replication-And-Clustering-API#REPLICATION I have updated the wiki page to reflect the current proposal for replication verbiage with some explanation of the choices. I would like to open discussion here regarding that verbiage. Without completely duplicatin

[openstack-dev] [Trove] Backup/Restore encryption/decryption issue

Goodday, OpenStack DВaaS community. I'd like to start conversation about guestagent security issue related to backup/restore process. Trove guestagent service uses AES with 256 bit key (in CBC mode) [1] to encrypt backups which are stored at predefined Swift container. As you can see

[openstack-dev] [Trove] Security groups provisioning flow update

Goodday, OpenStack DBaaS users/contributors. I'd like to start topic related to network access to Trove instances. Basicaly this topic related to security groups inside which are provisioned inside Trove. Not so long ago, Trove began support Redis DB, supported core API and extensions mentione

Re: [openstack-dev] [Trove] API extention update in order to support multi-databases integration

ot. Cassandra also supports > user/pass authentication as a part of its simple-auth protocol. > > From: Denis Makogon > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Monday, February 3, 2014 9:54

[openstack-dev] [Trove] API extention update in order to support multi-databases integration

Stack Development Mailing List Subject: [openstack-dev] [Trove] API extention update in order to support multi-databases integration Goodday, OpenStack DBaaS users/contributors. I'd like to start topic related to refactoring of API extensions. Since Trove already supports more than o

[openstack-dev] [Trove] API extention update in order to support multi-databases integration

Goodday, OpenStack DBaaS users/contributors. I'd like to start topic related to refactoring of API extensions. Since Trove already supports more than one db engines (mysql and redis in single-instance mode). At this moment if contributors will decide that one of the integrated db engines

Re: [openstack-dev] [trove] scheduled tasks redux

On Jan 23, 2014, at 3:41 PM, Michael Basnight wrote: > > Will we be doing more complex things than "every day at some time"? ie, does > the user base see value in configuring backups every 12th day of every other > month? I think this is easy to write the schedule code, but i fear that it >

Re: [openstack-dev] [Trove] how to list available configuration parameters for datastores

lts need to be a unique 1-1 >>>> mapping to a datastore version as they will vary across versions not just >>>> the datastore type. You may have a configurable parameter that exists in >>>> MySQL 5.6 that does not exist in MySQL 5.1 or vice versa. Or am I >>>&

Re: [openstack-dev] [Trove] how to list available configuration parameters for datastores

that does not exist in MySQL 5.1 or vice versa. Or am I >>> misunderstanding? >>> >>> Thanks, >>> Daniel >>> >>> >>> From: Craig Vyvial >>> Reply-To: "OpenStack Development Mailing List (not for usage >>

Re: [openstack-dev] [Trove] how to list available configuration parameters for datastores

stions)" >> >> Date: Thursday, January 23, 2014 10:55 AM >> To: "OpenStack Development Mailing List (not for usage questions)" < >> openstack-dev@lists.openstack.org> >> >> Subject: Re: [openstack-dev] [Trove] how to list available configurati

Re: [openstack-dev] [Trove] how to list available configuration parameters for datastores

-dev@lists.openstack.org> > Date: Thursday, January 23, 2014 10:55 AM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > > Subject: Re: [openstack-dev] [Trove] how to list available configuration > parameters fo

Re: [openstack-dev] [trove] scheduled tasks redux

> >Will we be doing more complex things than "every day at some time"? ie, >does the user base see value in configuring backups every 12th day of >every other month? I think this is easy to write the schedule code, but i >fear that it will be hard to build a smarter scheduler that would only >allow

Re: [openstack-dev] [trove] scheduled tasks redux

s seems easier to schedule and would enable an operator to change things in a pinch. From: Michael Basnight [mbasni...@gmail.com] Sent: Thursday, January 23, 2014 3:41 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [trove] scheduled tasks redux On Jan 23, 2014, at

Re: [openstack-dev] [Trove][Discussion] Are we using troveclient/tools/install_venv_common.py ?

Hello, Nilakhya Chatterjee. I would suggest you to ping trove -core team and ask them if there's any need of keeping it at codebase. Also, i suggest you to analyze how python-trove client installed while building dev. env. in trove-integration project. Fast research gave me next resalts: [novacli

Re: [openstack-dev] [Trove][Discussion] Are we using troveclient/tools/install_venv_common.py ?

Hello All, I have not received any reply on my mail, I will wait one more day for your comments on the same and proceed with a checkin, that removes the given file from python-troveclient. Let me know your thoughts. On Thu, Jan 23, 2014 at 1:43 AM, Nilakhya < nilakhya.chatter...@globallogic.co

Re: [openstack-dev] [Trove] how to list available configuration parameters for datastores

g List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Thursday, January 23, 2014 10:55 AM To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Trove] how

Re: [openstack-dev] [trove] scheduled tasks redux

On Jan 23, 2014, at 12:20 PM, Greg Hill wrote: > The blueprint is here: > > https://wiki.openstack.org/wiki/Trove/scheduled-tasks > > So I have basically two questions: > > 1. Does anyone see a problem with defining the repeating options as a single > field rather than multiple fields? Im fin

[openstack-dev] [trove] scheduled tasks redux

The blueprint is here: https://wiki.openstack.org/wiki/Trove/scheduled-tasks I've been working on the REST API portion of this project, and as I was working on the client, a part of it didn't sit quite right. As it is specified, it calls for two fields to define when and how often to run the t

Re: [openstack-dev] [Trove] how to list available configuration parameters for datastores

routes >>> >>> /datastores//configuration/ would be the collection of all >>> parameters >>> /datastores//configuration/:parameter would be an individual >>> setting. >>> >>> - kpom >>> >>> -- >>&g

Re: [openstack-dev] [Trove] how to list available configuration parameters for datastores

>> -- >> *From:* Craig Vyvial [cp16...@gmail.com] >> *Sent:* Wednesday, January 22, 2014 4:11 PM >> *To:* OpenStack Development Mailing List (not for usage questions) >> *Subject:* Re: [openstack-dev] [Trove] how to list available >>

Re: [openstack-dev] [Trove] how to list available configuration parameters for datastores

ter would be an individual > setting. > > - kpom > > -- > *From:* Craig Vyvial [cp16...@gmail.com] > *Sent:* Wednesday, January 22, 2014 4:11 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Trove] ho

Re: [openstack-dev] [Trove] how to list available configuration parameters for datastores

o: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Trove] how to list available configuration parameters for datastores Ok with overwhelming support for #3. What if we modified #3 slightly because looking at it again seems like we could shorten th

Re: [openstack-dev] [Trove] how to list available configuration parameters for datastores

res//configuration/:parameter would be an individual > setting. > > - kpom > > -- > *From:* Craig Vyvial [cp16...@gmail.com] > *Sent:* Wednesday, January 22, 2014 4:11 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subj

Re: [openstack-dev] [Trove] how to list available configuration parameters for datastores

[cp16...@gmail.com] Sent: Wednesday, January 22, 2014 4:11 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Trove] how to list available configuration parameters for datastores Ok with overwhelming support for #3. What if we modified #3 slightly because

Re: [openstack-dev] [Trove] how to list available configuration parameters for datastores

Ok with overwhelming support for #3. What if we modified #3 slightly because looking at it again seems like we could shorten the path since /datastores//configuration doesnt do anything. instead of #1 /datastores//configuration/parameters maybe: #2 /datastores//parameters #3 /datastores//configu

Re: [openstack-dev] [Trove] how to list available configuration parameters for datastores

Another +1 for option 3. Greg On Jan 22, 2014, at 2:27 PM, Denis Makogon mailto:dmako...@mirantis.com>> wrote: Goodday to all. #3 looks more than acceptable. /datastores//configuration/parameters. According to configuration parameters design, a configuration set must be associated to exactly

Re: [openstack-dev] [Trove] how to list available configuration parameters for datastores

Goodday to all. #3 looks more than acceptable. /datastores//configuration/parameters. According to configuration parameters design, a configuration set must be associated to exactly one datastore. Best regards, Denis Makogon. 2014/1/22 Michael Basnight > On Jan 22, 2014, at 10:19 AM, Kaleb Po

[openstack-dev] [Trove][Discussion] Are we using troveclient/tools/install_venv_common.py ?

Hi All, Are we using tools/install_venv_common.py in python-troveclient, If so just let us know. Otherwise, it may be cleaned up (removing it from openstack-common.conf) Thanks. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http:

Re: [openstack-dev] [Trove] how to list available configuration parameters for datastores

On Jan 22, 2014, at 10:19 AM, Kaleb Pomeroy wrote: > My thoughts so far: > > /datastores//configuration/parameters (Option Three) > + configuration set without an associated datastore is meaningless > + a configuration set must be associated to exactly one datastore > + each datastore must have

Re: [openstack-dev] [trove] Datastore Type/Version Migration

Hi Looks good approach. Lets start discussion. I propose API spec for it https://gist.github.com/andreyshestakov/8559309 Please look it and add your advices and comments. Thanks On Thu, Nov 21, 2013 at 2:44 AM, McReynolds, Auston wrote: > With "Multiple Datastore Types/Versions" merged to mas

Re: [openstack-dev] [Trove] how to list available configuration parameters for datastores

blueprint for this feature soon, so I'd like any feedback anyone has. - kpom From: Craig Vyvial [cp16...@gmail.com] Sent: Wednesday, January 22, 2014 10:10 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [Trove] how to list availabl

Re: [openstack-dev] [Trove] how to list available configuration parameters for datastores

I like #4 over #5 because it seems weird to have to create a configuration first to see what parameters are allowed. With #4 you could look up what is allowed first then create your configuration. Robert On Jan 22, 2014 10:18 AM, "Craig Vyvial" wrote: > Hey everyone I have run into an issue with

[openstack-dev] [Trove] how to list available configuration parameters for datastores

Hey everyone I have run into an issue with the configuration parameter URI. I'd like some input on what the URI might look like for getting the list configuration parameters for a specific datastore. Problem: Configuration parameters need to be selected per datastore. Currently: Its setup to use

[openstack-dev] [Trove] Tempest Tests for Trove -- Next Steps

Hello Team: As some of you are aware, I've been working on a couple of reviews to add Trove testing support to devstack-gate (viz. https://review.openstack.org/#/c/65040/, and https://review.openstack.org/#/c/65065/). Hopefully these will be merged soon. The next part of the integration plan is t

Re: [openstack-dev] [trove][mistral] scheduled tasks

Greg, Looks like I missed your last email in an email storm after NY holidays but now was able to see it accidentally. So answering your question about Mistral incubation your concern is valid. We’re currently working on moving Mistral into incubation and we’ll keep you (and others) posted on t

Re: [openstack-dev] [OpenStack-dev] [Trove] Implementing unit-tests and int-tests for heat based instance

Goodday, Shalini Khandelwal. You brought really good topic. I'd like to make few things clear: 1. https://bugs.launchpad.net/trove/+bug/1267945 there is already registred bug, even before your BP. 2. I see problem in proposed test coverage, since BP is telling us, that the main idea is to improve

[openstack-dev] [OpenStack-dev] [Trove] Implementing unit-tests and int-tests for heat based instance

Hi, I am writing this mail to shed some light on the implementation of tests for heat based instance creation. I have implemented unit tests and int-tests for the purpose. These tests are needed in trove because there is no criteria for testing the creation of instance using heat or any template

Re: [openstack-dev] [trove] Proposal to add Auston McReynolds to trove-core

> On Dec 27, 2013, at 2:48 PM, Michael Basnight wrote: > > Howdy, > > Im proposing Auston McReynolds (amcrn) to trove-core. The people have spoken. Welcome to trove core, Auston. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http:

[openstack-dev] [trove] mid cycle meetup

Howdy, In the spirit of getting together to get stuff done, Trove is having a mid cycle meetup in Austin, TX. We are having it Wednesday, February 19, 2014 to Friday, February 21, 2014, in downtown Austin at the Capital Factory, which is a hip startup incubator. See [1] for more information. The

Re: [openstack-dev] [trove] Proposal to add Auston McReynolds to trove-core

+1 to adding amcrn to Trove core. Thanks for the thoughtful reviews, and IRC discussions! Cheers, -Nikhil On Thu, Jan 2, 2014 at 9:40 AM, Michael Basnight wrote: > Hi Illya, > > I greatly appreciate what Denis is providing to the Trove community. Thank > you for letting him devote his time to t

Re: [openstack-dev] [trove][mistral] scheduled tasks

Renat, Thanks for the additional information. I've been trying to put the pieces of history together and it seems I missed some of it. I think I now understand the evolution of things. Mistral does seem like it would work for what we need, so I'll definitely be paying attention to it. I'm c

Re: [openstack-dev] [trove] Proposal to add Auston McReynolds to trove-core

Hi Illya, I greatly appreciate what Denis is providing to the Trove community. Thank you for letting him devote his time to trove. Denis and I have spoken privately at length about core (most recently a few weeks ago), and I believe he has a good idea of how to grow into a core member. Please have

Re: [openstack-dev] [trove] Proposal to add Auston McReynolds to trove-core

+1 amcrn On Thu, Jan 2, 2014 at 6:30 AM, Ilya Sviridov wrote: > Hello Trove team > Hello Michael > > I believe that Auston does a great job and personally think that his > reviews are always thorough and reasonable. > But It is surprising to not to see Denis Makogon (dmakogon, > denis_makogon) a

Re: [openstack-dev] [trove] Proposal to add Auston McReynolds to trove-core

Hello Trove team Hello Michael I believe that Auston does a great job and personally think that his reviews are always thorough and reasonable. But It is surprising to not to see Denis Makogon (dmakogon, denis_makogon) as candidate to cores. He is well known active community player driving HEAT i

Re: [openstack-dev] [trove][mistral] scheduled tasks

Greg, This is really not a new discussion. Particularly, we’ve already discussed EventScheduler thing before with heat folks (http://lists.openstack.org/pipermail/openstack-dev/2013-November/019150.html). We agreed that EventScheduler doesn’t make a lot of sense alone after Mistral came into

Re: [openstack-dev] [trove][mistral] scheduled tasks

I guess this isn't a new discussion. I did some more digging and apparently this is what came out of the last discussion: https://wiki.openstack.org/wiki/EventScheduler That definitely seems like it would be something simple we could use, since it only provides scheduling and that's all we nee

Re: [openstack-dev] [trove][mistral] scheduled tasks

Agreed taskflow doesn't currently provide scheduling as it was thought that reliable execution that can be restarted and resumed is the foundation that someone using taskflow can easily provide scheduling ontop of... Better IMHO to have a project doing this foundation well (since openstack would

Re: [openstack-dev] [trove] Proposal to add Auston McReynolds to trove-core

+1 On Dec 30, 2013, at 1:13 PM, Vipul Sabhaya wrote: > +1 > > Sent from my iPhone > > On Dec 30, 2013, at 10:50 AM, Craig Vyvial wrote: > >> +1 >> >> >> On Mon, Dec 30, 2013 at 12:00 PM, Greg Hill wrote: >> +1 >> >> On Dec 27, 2013, at 4:48 PM, Michael Basnight wrote: >> >>> Howdy, >>>

Re: [openstack-dev] [trove][mistral] scheduled tasks

Sorry for being a little bit verbose :) … Renat ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove][mistral] scheduled tasks

Greg, Georgy is right. We’re now actively working on PoC and we’ve already implemented the functionality we initially planned, including cron-based scheduling. You can take a look at our repo and evaluate what we’ve done, we’d be very glad to hear some feedback from anyone potentially intereste

Re: [openstack-dev] [trove][mistral] scheduled tasks

ght be kind of overkill for what you want, though. > > cheers, > brian > > -- > *From:* Greg Hill [greg.h...@rackspace.com] > *Sent:* Monday, December 30, 2013 12:59 PM > > *To:* OpenStack Development Mailing List (not for usage questions) &g

Re: [openstack-dev] [trove][mistral] scheduled tasks

reg.h...@rackspace.com] Sent: Monday, December 30, 2013 12:59 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [trove][mistral] scheduled tasks I've begun working on the scheduled tasks feature that will allow automated backups (and other things) in trove.

Re: [openstack-dev] [trove] Proposal to add Auston McReynolds to trove-core

+1 Sent from my iPhone > On Dec 30, 2013, at 10:50 AM, Craig Vyvial wrote: > > +1 > > >> On Mon, Dec 30, 2013 at 12:00 PM, Greg Hill wrote: >> +1 >> >>> On Dec 27, 2013, at 4:48 PM, Michael Basnight wrote: >>> >>> Howdy, >>> >>> Im proposing Auston McReynolds (amcrn) to trove-core. >>>

Re: [openstack-dev] [trove][mistral] scheduled tasks

pment Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Monday, December 30, 2013 at 9:59 AM To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Subject: [openstack-dev] [trove][m

Re: [openstack-dev] [trove] Proposal to add Auston McReynolds to trove-core

+1 On Mon, Dec 30, 2013 at 12:00 PM, Greg Hill wrote: > +1 > > On Dec 27, 2013, at 4:48 PM, Michael Basnight > wrote: > > Howdy, > > Im proposing Auston McReynolds (amcrn) to trove-core. > > Auston has been working with trove for a while now. He is a great > reviewer. He is incredibly tho

Re: [openstack-dev] [trove][mistral] scheduled tasks

nstack.org>> Subject: [openstack-dev] [trove][mistral] scheduled tasks I've begun working on the scheduled tasks feature that will allow automated backups (and other things) in trove. Here's the blueprint: https://wiki.openstack.org/wiki/Trove/scheduled-tasks I've heard som

[openstack-dev] [trove][mistral] scheduled tasks

I've begun working on the scheduled tasks feature that will allow automated backups (and other things) in trove. Here's the blueprint: https://wiki.openstack.org/wiki/Trove/scheduled-tasks I've heard some mention that mistral might be an option rather than building something into trove. I did

Re: [openstack-dev] [trove] Proposal to add Auston McReynolds to trove-core

+1 On Dec 27, 2013, at 4:48 PM, Michael Basnight mailto:mbasni...@gmail.com>> wrote: Howdy, Im proposing Auston McReynolds (amcrn) to trove-core. Auston has been working with trove for a while now. He is a great reviewer. He is incredibly thorough, and has caught more than one critical error

Re: [openstack-dev] [trove] Proposal to add Auston McReynolds to trove-core

+1 On Dec 27, 2013 2:51 PM, "Michael Basnight" wrote: > Howdy, > > Im proposing Auston McReynolds (amcrn) to trove-core. > > Auston has been working with trove for a while now. He is a great > reviewer. He is incredibly thorough, and has caught more than one critical > error with reviews and help

Re: [openstack-dev] [trove] Proposal to add Auston McReynolds to trove-core

ev@lists.openstack.org>> Subject: [openstack-dev] [trove] Proposal to add Auston McReynolds to trove-core Howdy, Im proposing Auston McReynolds (amcrn) to trove-core. Auston has been working with trove for a while now. He is a great reviewer. He is incredibly thorough, and has caught more

Re: [openstack-dev] [trove] Proposal to add Auston McReynolds to trove-core

+1 On Fri, Dec 27, 2013 at 4:48 PM, Michael Basnight wrote: > Howdy, > > Im proposing Auston McReynolds (amcrn) to trove-core. > > Auston has been working with trove for a while now. He is a great > reviewer. He is incredibly thorough, and has caught more than one critical > error with reviews a

[openstack-dev] [trove] Proposal to add Auston McReynolds to trove-core

Howdy, Im proposing Auston McReynolds (amcrn) to trove-core. Auston has been working with trove for a while now. He is a great reviewer. He is incredibly thorough, and has caught more than one critical error with reviews and helps connect large features that may overlap (config edits + multi data

Re: [openstack-dev] [trove] Delivering datastore logs to customers

ons)" mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [trove] Delivering datastore logs to customers On Mon, Dec 23, 2013 at 8:59 AM, Daniel Morris mailto:daniel.mor...@rackspace.com>> wrote: Vipul, I know we discussed this briefly in the Wednesday meeti

Re: [openstack-dev] [trove] Delivering datastore logs to customers

ons)" < > openstack-dev@lists.openstack.org> > Date: Friday, December 20, 2013 2:14 AM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [trove] Delivering datastore logs

Re: [openstack-dev] [trove] Delivering datastore logs to customers

)" < > openstack-dev@lists.openstack.org> > Date: Friday, December 20, 2013 2:14 AM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [trove] Delivering datastore logs to >

Re: [openstack-dev] [trove] Delivering datastore logs to customers

ng List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [trove] Delivering datastore logs to customers Yep agreed, this is a great idea. We really only need two API calls to get this going: - List available logs to ‘save’ - Save

Re: [openstack-dev] [trove] Dropping connectivity from guesagent to Trove back-end

ctor will complicate things without giving us any benefit. >> >> Thanks, >> >> Tim >> >> -- >> *From:* Ed Cranford [ed.cranf...@gmail.com] >> *Sent:* Friday, December 20, 2013 10:13 AM >> >> *To:* OpenStack Develop

Re: [openstack-dev] [trove] Dropping connectivity from guesagent to Trove back-end

; -- > *From:* Ed Cranford [ed.cranf...@gmail.com] > *Sent:* Friday, December 20, 2013 10:13 AM > > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [trove] Dropping connectivity from > guesagent to

Re: [openstack-dev] [trove] Dropping connectivity from guesagent to Trove back-end

OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [trove] Dropping connectivity from guesagent to Trove back-end Conductor was the first phase of https://wiki.openstack.org/wiki/Trove/guest_agent_communication whose proposed future phases include turning co

Re: [openstack-dev] [trove] Dropping connectivity from guesagent to Trove back-end

t;> *From:* Denis Makogon [dmako...@mirantis.com] >> *Sent:* Friday, December 20, 2013 8:58 AM >> *To:* OpenStack Development Mailing List (not for usage questions) >> *Subject:* Re: [openstack-dev] [trove] Dropping connectivity from >> guesagent to Trove back-end >> >&g

Re: [openstack-dev] [trove] Dropping connectivity from guesagent to Trove back-end

* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [trove] Dropping connectivity from > guesagent to Trove back-end > > Unfortunately, Trove cannot manage it's own extensions, so if, suppose, > i would try to get provisioned cassandr

Re: [openstack-dev] [trove] Dropping connectivity from guesagent to Trove back-end

three hour meetings and we couldn't reach consensus. Thanks, Tim From: Denis Makogon [dmako...@mirantis.com] Sent: Friday, December 20, 2013 9:44 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [trove] Dropping co

Re: [openstack-dev] [trove] Dropping connectivity from guesagent to Trove back-end

; https://review.openstack.org/#/c/59410/5 > > Thanks, > > Tim > > -- > *From:* Denis Makogon [dmako...@mirantis.com] > *Sent:* Friday, December 20, 2013 8:58 AM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subjec

Re: [openstack-dev] [trove] datastore migration issues

provided default values sensible and ask operators who don't like it to manually update the database. - Tim From: Robert Myers [myer0...@gmail.com<mailto:myer0...@gmail.com>] Sent: Thursday, December 19, 2013 9:59 AM To: OpenStack Development Mailing List

Re: [openstack-dev] [trove] Dropping connectivity from guesagent to Trove back-end

usage questions) Subject: Re: [openstack-dev] [trove] Dropping connectivity from guesagent to Trove back-end Thanks for response, Tim. As i said, it would be confusing situation when database which has no ACL would be deployed by Trove with root enabled - this looks very strange since user allow

Re: [openstack-dev] [trove] Dropping connectivity from guesagent to Trove back-end

-- > *From:* Denis Makogon [dmako...@mirantis.com] > *Sent:* Friday, December 20, 2013 7:04 AM > *To:* OpenStack Development Mailing List > *Subject:* [openstack-dev] [trove] Dropping connectivity from guesagent > to Trove back-end > >Goodday, OpenStack DВaaS community. &g

Re: [openstack-dev] [trove] Dropping connectivity from guesagent to Trove back-end

cember 20, 2013 7:04 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [trove] Dropping connectivity from guesagent to Trove back-end Goodday, OpenStack DВaaS community. I'd like to start conversation about dropping connectivity from In-VM guestagent and Trove ba

[openstack-dev] [trove] Dropping connectivity from guesagent to Trove back-end

Goodday, OpenStack DВaaS community. I'd like to start conversation about dropping connectivity from In-VM guestagent and Trove back-end. Since Trove has conductor service which interacts with agents via MQ service, we could let it deal with any back-end required operations initialize

Re: [openstack-dev] [trove] Delivering datastore logs to customers

Vipul, agreed. Trove server side could store a mapping of available log files and their paths per datastore. Also i agreed with ingoring DBLog model since it's really useless in term of future manipulations. And deployer would be able to define which logs could be available for user by setting all

Re: [openstack-dev] [trove] Delivering datastore logs to customers

Yep agreed, this is a great idea. We really only need two API calls to get this going: - List available logs to ‘save’ - Save a log (to swift) Some additional points to consider: - We don’t need to create a record of every Log ‘saved’ in Trove. These entries, treated as a Trove resource aren’t u

Re: [openstack-dev] [trove] datastore migration issues

-- > *From:* Robert Myers [myer0...@gmail.com] > *Sent:* Thursday, December 19, 2013 9:59 AM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [trove] datastore migration issues > > I think that we need to be goo

Re: [openstack-dev] [trove] datastore migration issues

like it to manually update the database. - Tim From: Robert Myers [myer0...@gmail.com] Sent: Thursday, December 19, 2013 9:59 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [trove] datastore migration issues I think th

Re: [openstack-dev] [trove] My thoughts on the Unified Guest Agent

code shared as can be. What do you think? Thanks, Kevin From: Tim Simpson [tim.simp...@rackspace.com<mailto:tim.simp...@rackspace.com>] Sent: Wednesday, December 18, 2013 11:34 AM To: OpenStack Development Mailing List (not for usage questions) Subjec

Re: [openstack-dev] [trove] datastore migration issues

I think that we need to be good citizens and at least add dummy data. Because it is impossible to know who all is using this, the list you have is probably complete. But Trove has been available for quite some time and all these users will not be listening on this thread. Basically anytime you have

Re: [openstack-dev] [trove] My thoughts on the Unified Guest Agent

> From: Tim Simpson [tim.simp...@rackspace.com] > Sent: Wednesday, December 18, 2013 11:34 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [trove] My thoughts on the Unified Guest Agent > > Thanks for the summary Dmitry. I

Re: [openstack-dev] [trove] datastore migration issues

We did consider doing that, but decided it wasn't really any different from the other options as it required the deployer to know to alter that data. That would require the fewest code changes, though. It was also my understanding that mysql variants were a possibility as well (percona and mar

Re: [openstack-dev] [trove] My thoughts on the Unified Guest Agent

om] Sent: Wednesday, December 18, 2013 4:15 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [trove] My thoughts on the Unified Guest Agent On 12/18/2013 12:27 PM, Tim Simpson wrote: Please provide proof of that assumption or at least a general hypothesis

Re: [openstack-dev] [trove] datastore migration issues

There is the database migration for datastores. We should add a function to back fill the existing data with either a dummy data or set it to 'mysql' as that was the only possibility before data stores. On Dec 18, 2013 3:23 PM, "Greg Hill" wrote: > I've been working on fixing a bug related to m

Re: [openstack-dev] [trove] My thoughts on the Unified Guest Agent

and how it's written and explained, has changed a lot over the past ten years. Thanks, Tim -Original Message- From: Steven Dake [mailto:sd...@redhat.com] Sent: Wednesday, December 18, 2013 4:15 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openst

Re: [openstack-dev] [trove] My thoughts on the Unified Guest Agent

nks, Tim From: Clint Byrum [cl...@fewbar.com] Sent: Wednesday, December 18, 2013 11:36 AM To: openstack-dev Subject: Re: [openstack-dev] [trove] My thoughts on the Unified Guest Agent Excerpts from Tim Simpson's message of 2013-12-18 07:34:14 -0800: I

<    2   3   4   5   6   7   8   9   >