+1
On Tue, Aug 26, 2014 at 1:55 PM, Vipul Sabhaya wrote:
> +1
>
>
> On Tue, Aug 26, 2014 at 11:43 AM, Robert Myers wrote:
>
>> +1
>>
>>
>> On Tue, Aug 26, 2014 at 8:54 AM, Tim Simpson
>> wrote:
>>
>>> +1
>>>
>>>
>>> From: Sergey Gotliv [sgot...@redhat.
> I would like to see this functionality in the next way:
> 1. Creating parameters group.
> 2. Validate and Save.
> 3. Send to an instance those parameters in dict representation.
> 4. Merge into main config.
>
> PS: #4 is database specific, so it's should be handled
with either the type, version, or
both and would allow it to work across providers given that they are likely
to configure types/versions differently.
I'd like to hear how the community views this and bring up the conversation
now rather than later.
Thanks,
-Craig V
+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
eters allowed on that
configuration.
/configurations//parameters - parameter list for mysql
- after some thought i think this method (5) might be the best way to
handle this.
I've outlined a few ways we could make this work. Let me know if you agree
or why you may disagree with strategy 5.
Tha
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
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
routes
>>>
>>> /datastores//configuration/ would be the collection of all
>>> parameters
>>> /datastores//configuration/:parameter would be an individual
>>> setting.
>>>
>>> - kpom
>>>
>>> --
>>&g
arameter that exists in
> MySQL 5.6 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 questions)" <
> openstack
datastores/versions//parameters/
This would the new set of paths for the parameters.
Any objections?
On Fri, Jan 24, 2014 at 2:47 PM, Craig Vyvial wrote:
> Oh shoot. That reminds me i needed to rebase the code i was working on.
>
> And yes this changes things a little because we
rticular qualities.
>
> Best regards, Denis Makogon.
>
>
> 2014/1/24 Craig Vyvial
>
>> Looks like there is a "short cut" if you know the datastore version and
>> you want to look it up.
>>
>> Exist today in the code:
>> /datastores//versions
reason the slave
never comes online or connects up to the master.
Is the writable flag completely optional for creating the metadata on an
instance? Would that mean that there is a default per datastore or overall?
Thanks for putting all this together. Great work man.
- Craig Vyvial
On Wed
over an
hour to run through everything still.
-Craig Vyvial
On Sun, Feb 16, 2014 at 12:25 AM, Mirantis wrote:
> 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
Matt,
Thanks for sharing this. Pretty cool!
-Craig
On Wed, May 7, 2014 at 11:13 AM, Lowery, Mathew wrote:
> I just wanted to share a project that I've been working on. It's a
> development workflow for OpenStack projects.
>
> I like to code in PyCharm and push my changes to a DevStack VM. I d
Hey Mathew,
Great sleuthing and maybe that will help. Sounds like a possible solution
to the job sitting for a while.
The reason we put the chmod in the README.md was because on a cloud server
when we tested everything we found that you could not connect to the screen
session because permissions
This is to be more inline with the other services we have ie. taskmanager
[1] that you can override if you see fit.
On Mon, Jun 2, 2014 at 3:55 PM, Russell Bryant wrote:
> On 06/02/2014 09:23 AM, boden wrote:
> > On 4/28/2014 2:58 PM, Dan Smith wrote:
> >>> I'd like to propose the ability to s
/taskmanager.py#L26
-Craig
On Mon, Jun 2, 2014 at 10:27 PM, Craig Vyvial wrote:
> This is to be more inline with the other services we have ie. taskmanager
> [1] that you can override if you see fit.
>
>
>
> On Mon, Jun 2, 2014 at 3:55 PM, Russell Bryant wrote:
>
>> On
Mathew,
Thats really cool. I've been using vagrant for a while and Ed created this
repo and it works pretty well. We've been using it for about 6 months or
longer. Its nice if you want to be able to test something locally.
https://github.com/ed-/trove-vagrant-vmware
I've been exploring using a p
+1
On Thu, Oct 30, 2014 at 9:42 AM, Mariam John wrote:
> +1
>
> [image: Inactive hide details for Peter Stachowski ---10/30/2014 08:45:43
> AM---+1 -Original Message-]Peter Stachowski ---10/30/2014
> 08:45:43 AM---+1 -Original Message-
>
> From: Peter Stachowski
> To: "OpenStack
= my.guestagent.datastore.mysql.manager.Manager
[percona]
manager = my.guestagent.datastore.percona.manager.Manager
After typing out the second idea i dont like it as much as something like
the first way.
Thoughts?
Thanks,
- Craig Vyvial
___
OpenStack-dev mailing list
Denis,
The scope of the metadata api goes beyond just using the glance metadata.
The metadata can be used for instances and and other objects to add extra
data like tags or something else that maybe a UI might want to use. We need
this feature either way.
-Craig
On Thu, Jul 24, 2014 at 12:17 PM
On Wed, Jul 30, 2014 at 10:10 AM, Denis Makogon
wrote:
> Hello, Stackers.
>
>
>
> I’d like to gather Trove team around question related to
> Datastores/Version API responses (request/response payloads and HTTP codes).
>
> Small INFO
>
> When deployer creates datastore and versions for it
used in other
projects across Openstack. What does everyone think about this?
If there are any concerns around this please let me know.
Thanks,
Craig Vyvial
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi
On Sep 25, 2013, at 7:16 PM, Craig Vyvial wrote:
>
> > So we have a blueprint for this and there are a couple things to point
> out that have changed since the inception of this BP.
> >
> > https://blueprints.launchpad.net/trove/+spec/configuration-management
> >
&
maybe renamed now that it has more scope than just using vmware
fusion. In the mean time it can be found here.
https://github.com/ed-/trove-vagrant-vmware
-Craig Vyvial
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
If a configuration is updated that is attached to N instances then those
instances will be updated with the configuration overrides. This will keep
the configuration n-sync[hah 90s boy band reference] with instances that
have it attached. I'm not sure that this is really a "confusing situation"
bec
These are some good q's.
responses inline
On Wed, Oct 2, 2013 at 1:20 AM, McReynolds, Auston wrote:
> I have a few questions left unanswered by the blueprint/wiki:
>
> #1 - Should the true default configuration-group for a service-type be
> customizable by the cloud provider?
>
The true
On Wed, Oct 2, 2013 at 11:39 AM, Michael Basnight wrote:
> On Oct 2, 2013, at 9:21 AM, Craig Vyvial wrote:
>
> > If a configuration is updated that is attached to N instances then those
> instances will be updated with the configuration overrides. This will keep
> the configurat
I'm glad we both agree on most of these answers.
:)
On Oct 2, 2013 11:57 AM, "Michael Basnight" wrote:
> On Oct 1, 2013, at 11:20 PM, McReynolds, Auston wrote:
>
> > I have a few questions left unanswered by the blueprint/wiki:
> >
> > #1 - Should the true default configuration-group for a servi
+1 to Vipul
On Tue, Oct 1, 2013 at 9:46 PM, Michael Basnight wrote:
> On Oct 1, 2013, at 7:06 PM, Vipul Sabhaya wrote:
>
> > On Oct 1, 2013, at 3:37 PM, Michael Basnight
> wrote:
> >
> >> On Oct 1, 2013, at 3:06 PM, Ilya Sviridov
> wrote:
> >>
> >>>
> >>> On Tue, Oct 1, 2013 at 6:45 PM, Tim Si
l the default template for a service-type be
> represented as a default configuration-group? If so, I imagine it
> can be managed through the API (or MGMT API)?
>
The default template will not be represented as a configuration group.
This could potentially be a good fit but its more of a nice to ha
ype?
> GET /configurations/:id won't be applicable, so will it be
> something like GET /configurations/default?
>
see above paragraph.
>
>
>
> From: Craig Vyvial
> Reply-To: OpenStack Development Mailing List
>
> Date: Thursday, October 3, 2013 11:17 AM
&g
Oops forgot the link on BP for versioning templates.
https://blueprints.launchpad.net/trove/+spec/configuration-templates-versionable
On Thu, Oct 3, 2013 at 3:47 PM, Craig Vyvial wrote:
> I have been trying to figure out where a call for the "default"
> configuration s
+1 to Robert's suggestion
I think it makes sense to keep all data store templates that are used in
the same location. ie. templates/{data-store}/*.template
As trove expands its data stores then we have all the templates next to
each other. I think it would make it easier to remove/add support for
Krishanu,
I think you might need to choose a different nickname for irc. Looks like
krish could be already taken.
-Craig
On Fri, Nov 8, 2013 at 12:38 AM, Krishanu Dhar wrote:
> Thanks. I tried hooking onto the IRC but it just doesn't seem to connect.
> Below is the error I got.
>
> [11:59] -h
Thats really cool. This kinda gets around the fact that gerrit's REST api
is not available in the version that is currently deployed. I think this
will help me in a tool i was working on to aggregate a view of everything i
want in a single location. Thanks!
-Craig
On Mon, Nov 11, 2013 at 3:16 PM
deleted instead of doing a hard delete in
the db.
Thanks,
Craig Vyvial
On Thu, Oct 3, 2013 at 3:48 PM, Craig Vyvial wrote:
> Oops forgot the link on BP for versioning templates.
>
>
> https://blueprints.launchpad.net/trove/+spec/configuration-templates-versionable
>
>
> On
the
configs to the end of the main config file (my.cnf for mysql example).
-Craig Vyvial
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Doug,
I updated the liaisons for Trove on the wiki page.
Thanks,
-Craig
On Wed, Oct 21, 2015 at 11:26 AM Doug Hellmann
wrote:
> Excerpts from Lingxian Kong's message of 2015-10-21 16:42:32 +0800:
> > Hi, Doug,
> >
> > After conversition with Mistral PTL(Renat), I'm willing to be mistral
> > li
We've updated the Trove Sessions to include some great topics.
https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Trove
http://mitakadesignsummit.sched.org/overview/type/trove
Thanks to everyone involved and looking forward to seeing everyone next
week!
-Craig Vyvial
(cp
version release adds the az and nic parameters.
Thanks,
Craig Vyvial
signature.asc
Description: This is a digitally signed message part
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack
Victoria,
Thank for your contributions to Trove and wish you the best. Its been great
working with you in the community.
-Craig Vyvial
On Tue, Jun 7, 2016 at 1:34 PM Victoria Martínez de la Cruz <
victo...@vmartinezdelacruz.com> wrote:
> After one year and a half contributing to
Just an update on this thread that the trove-dashboard RC2 was released
https://review.openstack.org/#/c/298365/
Thanks,
Craig Vyvial
On Wed, Mar 23, 2016 at 11:36 PM Craig Vyvial wrote:
> The trove-dashboard has its own stable/mitaka branch [1] as well. We have
> an RC1 release already
-dsvm-mysql/e70f5c0/logs/devstack-gate-post_test_hook.txt.gz#_2016-02-11_05_12_01_023
Can someone help us resolve this?
Thanks,
Craig Vyvial
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstac
Jeremy,
Thanks for looking at this. That makes sense but I'm not sure how to
resolve this issue with the current diskimage-builder elements. If anyone
has ideas it would be greatly appreciated.
Thanks,
-Craig Vyvial
On Thu, Feb 11, 2016 at 8:44 AM Jeremy Stanley wrote:
> On 2016-02-
Hello,
My name is Craig Vyvial and I'd like run for Mitaka Trove PTL. I've been
working on Trove for about 4 years and a core member for about 2 years.
Over the this time, Trove has continued to evolve and the community has
grown. My passion is to help make sure that Trove continues
Doug,
I'm working on the Trove patch to fix the test failures.
https://review.openstack.org/#/c/235149/
Thanks,
Craig Vyvial (cp16net)
OpenStack Trove Project Team Lead
On Thu, Oct 15, 2015 at 1:57 PM Steve Martinelli
wrote:
> Doug,
>
> Dolph and Brant are in the process
the next
leadership. I would like to thank the community of Trove as well as the
rest of the OpenStack team for the opportunity to help and learn from
everyone.
I look forward to working with the new leadership and excited to see what
is in store for the future of Trove.
Trove has 3 patches in the gate that are awaiting merge.
https://review.openstack.org/#/c/281576/
https://review.openstack.org/#/c/288123/
https://review.openstack.org/#/c/273204/
I expect these will merge in the next few hours at that time we will be
submitting the rc-1 release.
Thanks,
Craig
The trove-dashboard has its own stable/mitaka branch [1] as well. We have
an RC1 release already and we can make sure to land the translations and
cut an RC2 early next week (March 28).
Thanks,
Craig Vyvial
[1] https://github.com/openstack/trove-dashboard/tree/stable/mitaka
On Wed, Mar 23
+1 +1 +1
I think these nominations will help grow the trove community.
-Craig
On Thu, Feb 5, 2015 at 10:48 AM, Amrith Kumar wrote:
> Nikhil,
>
>
>
> Regarding your nomination of Victoria, Peter and Edmond to core, here is
> my vote (here are my votes).
>
>
>
> Victoria: +1
>
> Peter: +1
>
> Ed
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.o
52 matches
Mail list logo
