[openstack-dev] [Trove] trove core team

[Craig Vyvial]

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] [Trove] Stepping down from Trove Core

[Craig Vyvial]

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 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] [i18n][horizon][sahara][trove][magnum][murano] dashboard plugin release schedule

[Craig Vyvial]

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 <cp16...@gmail.com> wrote:

> 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, 2016 at 11:02 PM Akihiro Motoki <amot...@gmail.com> wrote:
>
>> Thank you all for your supports.
>> We can see the progress of translations at [0]
>>
>> Shu,
>> Magnum UI adopts the independent release model. Good to know you have
>> stable/mitaka branch :)
>> Once the stable branch is cut, let not only me but also the i18n team
>> know it.
>> openstack-i18n ML is the best place to do it.
>> If so, the i18n team and the infra team will setup required action for
>> Zanata sync.
>>
>> [0]
>> https://translate.openstack.org/version-group/view/mitaka-translation/projects
>>
>> 2016-03-24 12:33 GMT+09:00 Shuu Mutou <shu-mu...@rf.jp.nec.com>:
>> > Hi Akihiro,
>> >
>> > Thank you for your announcement.
>> > We will create stable/mitaka branch for Magnum-UI in this week,
>> > and that will freeze strings.
>> >
>> > Thanks,
>> >
>> > Shu Muto
>> >
>> >
>> >
>> __
>> > 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] [i18n][horizon][sahara][trove][magnum][murano] dashboard plugin release schedule

[Craig Vyvial]

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, 2016 at 11:02 PM Akihiro Motoki <amot...@gmail.com> wrote:

> Thank you all for your supports.
> We can see the progress of translations at [0]
>
> Shu,
> Magnum UI adopts the independent release model. Good to know you have
> stable/mitaka branch :)
> Once the stable branch is cut, let not only me but also the i18n team know
> it.
> openstack-i18n ML is the best place to do it.
> If so, the i18n team and the infra team will setup required action for
> Zanata sync.
>
> [0]
> https://translate.openstack.org/version-group/view/mitaka-translation/projects
>
> 2016-03-24 12:33 GMT+09:00 Shuu Mutou <shu-mu...@rf.jp.nec.com>:
> > Hi Akihiro,
> >
> > Thank you for your announcement.
> > We will create stable/mitaka branch for Magnum-UI in this week,
> > and that will freeze strings.
> >
> > Thanks,
> >
> > Shu Muto
> >
> >
> >
> __
> > 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] [release] Release countdown for week R-2, Mar 21-25

[Craig Vyvial]

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 Vyvial

On Thu, Mar 17, 2016 at 9:12 PM Jim Rollenhagen <j...@jimrollenhagen.com>
wrote:

> Ironic and IPA should have releases coming next week.
>
> // jim
>
> > On Mar 17, 2016, at 12:23, Doug Hellmann <d...@doughellmann.com> wrote:
> >
> > We're almost to the finish line with Mitaka!
> >
> > Focus
> > -
> >
> > Project teams following the cycle-with-milestone model should be
> > testing their release candidates and fixing release-critical bugs.
> >
> > Project teams following the cycle-with-intermediary model should
> > ensure they have at least one Mitaka release, and determine whether
> > they will need another release before the end of the Mitaka cycle.
> >
> > All feature ongoing work should be retargeted to the Newton cycle.
> >
> > All project teams should be working on release-critical bugs.
> >
> > General Notes
> > -
> >
> > The global requirements list is frozen. If you need to change a
> > dependency, for example to include a bug fix in one of our libraries
> > or an upstream library, please provide enough detail in the change
> > request to allow the requirements review team to evaluate the change.
> >
> > User-facing strings are frozen to allow the translation team time
> > to finish their work.
> >
> > Release Actions
> > ---
> >
> > We still have quite a few managed cycle-with-milestones projects
> > without a release candidate:
> >
> > aodh
> > ceilometer
> > barbican
> > designate
> > horizon
> > manila
> > sahara
> > trove
> > zaqar
> >
> > And there are a few managed cycle-with-intermediary projects without
> > a clear indication if they have cut their final release:
> >
> > ironic
> > ironic-python-agent
> > python-manilaclient
> > sahara-tests
> > swift
> >
> > Please contact the release team, or submit a release request to the
> > releases repository, to address these missing releases.
> >
> > Important Dates
> > ---
> >
> > Final release candidates: R-1, Mar 28-1
> > Mitaka final release: Apr 7
> >
> > Mitaka release schedule:
> http://releases.openstack.org/mitaka/schedule.html
> >
> >
> __
> > 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] PTL non-candidacy

[Craig Vyvial]

All,

I've decided to not run for Trove PTL for the upcoming Newton cycle.

I've enjoyed working with everyone in the Trove community. We've
accomplished many features over the last cycle. I am positive with the
roadmap we've talked about that Trove will continue to grow with 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.

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] [infra] [trove] gate jobs failing with ovh apt mirrors

[Craig Vyvial]

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 <fu...@yuggoth.org> wrote:

> On 2016-02-11 07:00:01 + (+0000), Craig Vyvial wrote:
> > I started noticing more of the Trove gate jobs failing in the last 24
> hours
> > and I think i've tracked it down to this mirror specifically.
> > http://mirror.bhs1.ovh.openstack.org/ubuntu/pool/main/p/
> > It looks like its missing the python-software-properties package and
> > causing our gate job to fail.
> [...]
>
> I think you're looking for this:
>
>
> http://mirror.bhs1.ovh.openstack.org/ubuntu/pool/universe/s/software-properties/
>
> >
> http://logs.openstack.org/50/278050/1/check/gate-trove-functional-dsvm-mysql/e70f5c0/logs/devstack-gate-post_test_hook.txt.gz#_2016-02-11_05_12_01_023
> [...]
>
> The error there implies that diskimage-builder invocation in your
> job is reusing the host's apt sources but not its apt configuration,
> and so is expecting the packages on the mirrors to be secure-apt
> signed by a trusted key.
> --
> Jeremy Stanley
>
> __
> 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] [infra] [trove] gate jobs failing with ovh apt mirrors

[Craig Vyvial]

I started noticing more of the Trove gate jobs failing in the last 24 hours
and I think i've tracked it down to this mirror specifically.
http://mirror.bhs1.ovh.openstack.org/ubuntu/pool/main/p/
It looks like its missing the python-software-properties package and
causing our gate job to fail. I found a job that passed in the last 24
hours and it wasnt using this same mirror.

[job pass]
http://logs.openstack.org/50/278050/1/check/gate-trove-functional-dsvm-mysql/067e81c/console.html#_2016-02-10_18_39_14_494
[job fail]
http://logs.openstack.org/50/278050/1/check/gate-trove-functional-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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [trove][release] python-troveclient 1.4.0 release

[Craig Vyvial]

Hello everyone,

We have released the 1.4.0 version of the python-troveclient.

In liberty Trove had added more datastores to support clustering but the
client was missing an attribute to allow you to set the network and
availability zone for each of the instances in the cluster. This
troveclient 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-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release] establishing release liaisons for mitaka

[Craig Vyvial]

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
> > liaison to take participate in cross-project release effort on beharf
> > of mistral team, so please count me in.
>
> Great, thank you for volunteering!
>
> Please add your contact details to the wiki page [3], and make sure
> you have your email client configured so that you will see messages
> with the "[release]" topic tag.
>
> Doug
>
> [3]
> https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management
>
> >
> > On Wed, Oct 14, 2015 at 11:25 PM, Doug Hellmann 
> wrote:
> > > As with the other cross-project teams, the release management team
> > > relies on liaisons from each project to be available for coordination
> of
> > > work across all teams. It's the start of a new cycle, so it's time to
> > > find those liaison volunteers.
> > >
> > > We are working on updating the release documentation as part of the
> > > Project Team Guide. Release liaison responsibilities are documented in
> > > [0], and we will update that page with more details over time.
> > >
> > > In the past we have defaulted to having the PTL act as liaison if no
> > > alternate is specified, and we will continue to do that during Mitaka.
> > > If you plan to delegate release work to a liaison, especially for
> > > submitting release requests, please update the wiki [1] to provide
> their
> > > contact information. If you plan to serve as your team's liaison,
> please
> > > add your contact details to the page.
> > >
> > > Thanks,
> > > Doug
> > >
> > > [0]
> http://docs.openstack.org/project-team-guide/release-management.html#release-liaisons
> > > [1]
> https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management
> > >
> > >
> __
> > > 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] Mitaka Design Summit Sessions

[Craig Vyvial]

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
(cp16net)
__
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] PTL Candidacy

[Craig Vyvial]

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 this trend and
guide Trove to be a world class database as a service for OpenStack.

Trove started just provisioing a single MySQL instance and has grown to a
total of 12 datastores to date with a few datastores supporting clustering.
I think there are a few areas that make sense with this kind of growth that
we should focus on during Mitaka.

* Add CI tests for other datastores with third patry CI systems. With so
many new datastores available within Trove, we need to make sure that we
stabilize tests on multiple datastores.

* Advance the features of Trove for all datastores.

* Simplify the installation of Trove that includes install, upgrades,
building guest images, and management operations.

* Continue the trend of growing the trove community.

As PTL of Trove, I will help the project move forward by looking to the
community for input and making sure we take steps toward making OpenStack a
better platform as well as Trove the ideal solution for users looking for a
database as a service solution.


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] [Trove] Core reviewer update

[Craig Vyvial]

+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 amr...@tesora.com wrote:

  Nikhil,



 Regarding your nomination of Victoria, Peter and Edmond to core, here is
 my vote (here are my votes).



 Victoria: +1

 Peter: +1

 Edmond: +1



 My thanks to all of you for your contributions to the project thus far,
 and I look forward to working with all of you moving forward.



 Also, my sincere thanks to Michael (Bas) Basnight and Tim (grapex)
 Simpson. It has been awesome working with both of you and look forward to
 working together again!



 Thanks,



 -amrith





 --



 Amrith Kumar, CTO Tesora (www.tesora.com)



 Twitter: @amrithkumar

 IRC: amrith @freenode











 *From:* Nikhil Manchanda [mailto:slick...@gmail.com]
 *Sent:* Thursday, February 05, 2015 11: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


__
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

[Craig Vyvial]

+1

On Thu, Oct 30, 2014 at 9:42 AM, Mariam John mari...@us.ibm.com 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 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 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


___
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 Amrith Kumar to trove-core

[Craig Vyvial]

+1


On Tue, Aug 26, 2014 at 1:55 PM, Vipul Sabhaya vip...@gmail.com wrote:

 +1


 On Tue, Aug 26, 2014 at 11:43 AM, Robert Myers myer0...@gmail.com wrote:

 +1


 On Tue, Aug 26, 2014 at 8:54 AM, Tim Simpson tim.simp...@rackspace.com
 wrote:

 +1

 
 From: Sergey Gotliv [sgot...@redhat.com]
 Sent: Tuesday, August 26, 2014 8:11 AM
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Trove] Proposal to add Amrith Kumar to
 trove-core

 Strong +1 from me!


  -Original Message-
  From: Nikhil Manchanda [mailto:nik...@manchanda.me]
  Sent: August-26-14 3:48 AM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: [openstack-dev] [Trove] Proposal to add Amrith Kumar to
 trove-core
 
  Hello folks:
 
  I'm proposing to add Amrith Kumar (amrith on IRC) to trove-core.
 
  Amrith 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 for multiple bug-fixes
 in
  Trove, and most recently drove the audit and clean-up of log messages
 across
  all Trove components.
 
  https://review.openstack.org/#/q/reviewer:amrith,n,z
  https://review.openstack.org/#/q/owner:amrith,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



 ___
 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

Re: [openstack-dev] [Trove] Datastore/Versions API improvements

[Craig Vyvial]

On Wed, Jul 30, 2014 at 10:10 AM, Denis Makogon dmako...@mirantis.com
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 Troves` backend
 receives request to store DBDatastore and DBDatastoreVersion objects with
 certain parameters. The most interesting attribute of DBDatastoreVersion is
 “packages” - it’s being stored as String object (and it’s totally fine).
 But when we’re trying to query given datastore version through the
 Datastores API attribute “packages” is being returned as String object too.
 And it seems that it breaks response pattern - “If given attribute
 represents complex attribute, such as: list, dict, tuple - it should be
 returned as is.

 So, the first question is - are we able to change it in terms of V1?

If it does not break the public api then i do not think there is an issue
making a change.
I made a change not long ago around making the packages a list thats sent
to the guest. I'm a bit confused what you are wanting to change here.
Are you suggesting changing the data that is stored for packages (string to
a json.dumps list or something).
Or making the model parse the string into a list when you request the
packages for a datastore version?



 The second question is about admin_context decorator (see [1]). This
 method executes methods of given controller and verifies that user is able
 to execute certain procedure.

 Taking into account RFC 2616 this method should raise HTTP Forbidden
 (code 403) if user tried to execute request that he’s not allowed to.

 But given method return HTTP Unauthorized (code 401) which seems
 weird since user is authorized.

I think this is a valid bug for the error code although the message makes
it clear why you get the 401.
https://github.com/openstack/trove/blob/master/trove/common/auth.py#L85



 This is definitely a bug. And it comes from [2].


 [1]
 https://github.com/openstack/trove/blob/master/trove/common/auth.py#L72-L87

 [2]
 https://github.com/openstack/trove/blob/master/trove/common/wsgi.py#L316-L318



 Best regards,

 Denis Makogon

 ___
 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] [Glance][Trove] Metadata Catalog

[Craig Vyvial]

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, Amrith Kumar amr...@tesora.com wrote:

 Speaking as a ‘database guy’ and a ‘Trove guy’, I’ll say this; “Metadata”
 is a very generic term and the meaning of “metadata” in a database context
 is very different from the meaning of “metadata” in the context that Glance
 is providing.



 Furthermore the usage and access pattern for this metadata, the frequency
 of change, and above all the frequency of access are fundamentally
 different between Trove and what Glance appears to be offering, and we
 should probably not get too caught up in the project “title”.



 We would not be “reinventing the wheel” if we implemented an independent
 metadata scheme for Trove; we would be implementing the right kind of when
 for the vehicle that we are operating. Therefore I do not agree with your
 characterization that concludes that:



  given goals at [1] are out of scope of Database program, etc



 Just to be clear, when you write:



  Unfortunately, we’re(Trove devs) are on half way to metadata …



 it is vital to understand that our view of “metadata” is very different
 from (for example, a file system’s view of metadata, or potentially
 Glance’s view of metadata). For that reason, I believe that your comments
 on https://review.openstack.org/#/c/82123/16 are also somewhat extreme.



 Before postulating a solution (or “delegating development to Glance
 devs”), it would be more useful to fully describe the problem being solved
 by Glance and the problem(s) we are looking to solve in Trove, and then we
 could have a meaningful discussion about the right solution.



 I submit to you that we will come away concluding that there is a round
 peg, and a square hole. Yes, one will fit in the other but the final
 product will leave neither party particularly happy with the end result.



 -amrith



 *From:* Denis Makogon [mailto:dmako...@mirantis.com]
 *Sent:* Thursday, July 24, 2014 9:33 AM
 *To:* OpenStack Development Mailing List
 *Subject:* [openstack-dev] [Glance][Trove] Metadata Catalog



 Hello, Stackers.


  I’d like to discuss the future of Trove metadata API. But first small
 history info (mostly taken for Trove medata spec, see [1]):

 *Instance metadata is a feature that has been requested frequently by our
 users. They need a way to store critical information for their instances
 and have that be associated with the instance so that it is displayed
 whenever that instance is listed via the API. This also becomes very usable
 from a testing perspective when doing integration/ci. We can utilize the
 metadata to store things like what process created the instance, what the
 instance is being used for, etc... The design for this feature is modeled
 heavily on the Nova metadata API with a few tweaks in how it works
 internally.*

 And here comes conflict. Glance devs are working on “Glance Metadata
 Catalog” feature (see [2]). And as for me, we don’t have to* “reinvent
 the wheel” for Trove. *It seems that we would be able

 to use Glance API to interact with   Metadata Catalog. And it seems to be
 redundant to write our own API for metadata CRUD operations.



 From Trove perspective, we need to define a list concrete use cases
 for metadata usage (eg given goals at [1] are out of scope of Database
 program, etc.).

 From development and cross-project integration perspective, we need to
 delegate all development to Glance devs. But we still able to help Glance
 devs with this feature by taking active part in polishing proposed spec
 (see [2]).



 Unfortunately, we’re(Trove devs) are on half way to metadata - patch
 for python-troveclient already merged. So, we need to consider
 deprecation/reverting of merged and block

 merging of proposed ( see [3]) patchsets in favor of Glance Metadata
 Catalog.



 Thoughts?

 [1] https://wiki.openstack.org/wiki/Trove-Instance-Metadata

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

 [3] https://review.openstack.org/#/c/82123/



 Best regards,

 Denis Makogon

 ___
 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] [trove] guestagent config for overriding managers

[Craig Vyvial]

If you want to override the trove guestagent managers its looks really
nasty to have EVERY manager on a single line here.

datastore_registry_ext =
mysql:my.guestagent.datastore.mysql.manager.Manager,percona:my.guestagent.datastore.mysql.manager.Manager,...

This needs to be tidied up and split out some way.
Ideally each of these should be on a single line.

datastore_registry_ext = mysql:my.guestagent.datastore.mysql.manager.Manager
datastore_registry_ext =
percona:my.guestagent.datastore.mysql.manager.Manager

or maybe...

datastores = mysql,precona
[mysql]
manager = 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
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Trove] Pluggable conductor manager

[Craig Vyvial]

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 rbry...@redhat.com 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 support a pluggable trove conductor
  manager. Currently the trove conductor manager is hard-coded [1][2] and
  thus is always 'trove.conductor.manager.Manager'. I'd like to see this
  conductor manager class be pluggable like nova does [3].
 
  Note that most of us don't like this and we're generally trying to get
  rid of these sorts of things. I actually didn't realize that
  conductor.manager was exposed in the CONF, and was probably just done to
  mirror other similar settings.
 
  Making arbitrary classes pluggable like this without a structured and
  stable API is really just asking for trouble when people think it's a
  pluggable interface.
 
  So, you might not want to use because nova does it as a reason to add
  it to trove like this :)
 
  --Dan
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
  Thanks for the input Dan.
 
  Is the real concern here that the conductor API(s) and manager are
  coupled based on version?

 FWIW, I really don't like this either.

 I snipped some implementation detail proposals here.  I missed why you
 want to do this in the first place.  This seems far from an obvious plug
 point to me.

 --
 Russell Bryant

 ___
 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] Pluggable conductor manager

[Craig Vyvial]

Sent that a little too quickly...

This is to be more inline with the other services we have ie. taskmanager
[1] that you can override if you see fit. We decided this was an oversight
from the original creation and should be added.

[1]
https://github.com/openstack/trove/blob/master/trove/cmd/taskmanager.py#L26

-Craig


On Mon, Jun 2, 2014 at 10:27 PM, Craig Vyvial cp16...@gmail.com 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 rbry...@redhat.com 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 support a pluggable trove conductor
  manager. Currently the trove conductor manager is hard-coded [1][2]
 and
  thus is always 'trove.conductor.manager.Manager'. I'd like to see this
  conductor manager class be pluggable like nova does [3].
 
  Note that most of us don't like this and we're generally trying to get
  rid of these sorts of things. I actually didn't realize that
  conductor.manager was exposed in the CONF, and was probably just done
 to
  mirror other similar settings.
 
  Making arbitrary classes pluggable like this without a structured and
  stable API is really just asking for trouble when people think it's a
  pluggable interface.
 
  So, you might not want to use because nova does it as a reason to add
  it to trove like this :)
 
  --Dan
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
  Thanks for the input Dan.
 
  Is the real concern here that the conductor API(s) and manager are
  coupled based on version?

 FWIW, I really don't like this either.

 I snipped some implementation detail proposals here.  I missed why you
 want to do this in the first place.  This seems far from an obvious plug
 point to me.

 --
 Russell Bryant

 ___
 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] gpd: a git-push-based dev workflow for OpenStack projects

[Craig Vyvial]

Matt,

Thanks for sharing this. Pretty cool!

-Craig


On Wed, May 7, 2014 at 11:13 AM, Lowery, Mathew mlow...@ebay.com 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 don't
 use Vagrant and I don't like manually scp'ing code. So I created
 git-push-devstack or gpd:

 https://github.com/mlowery/git-push-devstack

 After configuring your laptop (or wherever you code) and your DevStack VM,
 pushing your code from your laptop to your DevStack VM and restarting
 affected processes is as easy as:

 $ git commit
 $ git push test

 Code and doc are at the GitHub link.

 Feedback is welcome.


 ___
 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] development workflows

[Craig Vyvial]

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 pure remote VM to run things like what your
document describes. I like the idea of using a post hook.

Thanks,
Craig


On Thu, Mar 6, 2014 at 11:00 AM, Lowery, Mathew mlow...@ebay.com wrote:

  So I submitted this 
 dochttp://docs-draft.openstack.org/29/70629/3/check/gate-trove-docs/34ceff7/doc/build/html/dev/install_alt.html
  (in
 this patch set https://review.openstack.org/#/c/70629/) and Dan Nguyen
 (thanks Dan) stated that there were some folks using Vagrant. (My workflow
 uses git push with a git hook to copy files and trigger restarts.) Can
 anyone point me to any doc regarding Trove using Vagrant? Assuming my doc
 is desirable in some form, where is the best place to put it? Thanks.

 ___
 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] Trove-Gate timeouts

[Craig Vyvial]

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 over an
hour to run through everything still.

-Craig Vyvial


On Sun, Feb 16, 2014 at 12:25 AM, Mirantis dmako...@mirantis.com 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 failure in devstack. But then I found same
 problem as you described. The best option is to increase job time range.
 Thanks for such research. I hope gate will be fixed in the easiest way and
 for the shortest period of time.

 Best regards
 Denis Makogon.
 Sent from an iPad

 16 февр. 2014, в 00:46, Lowery, Mathew mlow...@ebay.com написал(а):

  Hi all,

  *Issue #1: Jobs that need more than one hour*

  Of the last 30 Trove-Gate 
 https://rdjenkins.dyndns.org/job/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 having access to the job config to see what the job looks like, I
 used the console output to guess what was going on. It appears that a
 Jenkins plugin named 
 boot-hpcloud-vmhttps://github.com/mrhoades/boot-hpcloud-vm/blob/2272770b0ce54752eabb84229dc8939d79b2be50/models/boot_vm_concurrent.rb#L181
  is
 booting a VM and running the commands given, including redstack int-tests.
 From the console output, it states that it was supplied with an
 ssh_shell_timeout=7200. This is passed down to another library called
 net-ssh-simplehttps://github.com/busyloop/net-ssh-simple/blob/e3834f259a47606bfb06a487ca701fc20dbad8a5/lib/net/ssh/simple.rb#L632.
 net-ssh-simple has two timeouts: an idle timeout and an operation timeout.

  In the latest 
 boot-hpcloud-vmhttps://github.com/mrhoades/boot-hpcloud-vm/blob/2272770b0ce54752eabb84229dc8939d79b2be50/models/boot_vm_concurrent.rb#L182,
 ssh_shell_timeout is passed down to net-ssh-simple for both the idle
 timeout and the operation timeout. But in older versions of
 boot-hp-cloud-vmhttps://github.com/mrhoades/boot-hpcloud-vm/blob/9260e957d6c54142c33dd9e9632b86e17fd5c02f/models/boot_vm_concurrent.rb#L141,
 ssh_shell_timeout is passed down to net-ssh-simple for only the idle
 timeout, leaving a default operation timeout of 3600. This is why I believe
 these jobs are failing after exactly one hour.

  FYI: Here are the jobs that failed due to the Jenkins job-level timeout
 (and had no test failures when the timeout occurred) along with their
 associated patch sets:
 https://rdjenkins.dyndns.org/job/Trove-Gate/2532/console (
 http://review.openstack.org/73786)
 https://rdjenkins.dyndns.org/job/Trove-Gate/2530/console (
 http://review.openstack.org/73736)
 https://rdjenkins.dyndns.org/job/Trove-Gate/2517/console (
 http://review.openstack.org/63789)
 https://rdjenkins.dyndns.org/job/Trove-Gate/2514/console (
 https://review.openstack.org/50944)
 https://rdjenkins.dyndns.org/job/Trove-Gate/2513/console (
 https://review.openstack.org/50944)
 https://rdjenkins.dyndns.org/job/Trove-Gate/2504/console (
 https://review.openstack.org/73147)
 https://rdjenkins.dyndns.org/job/Trove-Gate/2503/console (
 https://review.openstack.org/73147)

   *Suggested action items:*

- If it is acceptable to have jobs that run over one hour, then
install the latest boot-hpcloud-vm plugin for Jenkins which will increase
the make the operation timeout match the idle timeout.


  *Issue #2: The running time of all jobs is 1 hr 1 min*

  While the Jenkins job-level timeout will end the job after one hour, it
 also appears to keep every job running for a minimum of one hour.  To be
 more precise, the timeout (or minimum running time) occurs on the part of
 the Jenkins job that runs commands on the VM; the VM provision (which takes
 about one minute) is excluded from this timeout which is why the running
 time of all jobs is around 1 hr 1 
 minhttps://rdjenkins.dyndns.org/job/Trove-Gate/buildTimeTrend.
 A sampling of console logs showing the time the int-tests completed and
 when the timeout kicks in:

  https://rdjenkins.dyndns.org/job/Trove-Gate/2531/console (00:01:03
 wasted)

 *04:51:12* COMMAND_0: echo refs/changes/36/73736/2

 ...

 *05:50:10* 335.41 proboscis.case.MethodTest 
 (test_instance_created)*05:50:10* 194.05 proboscis.case.MethodTest 
 (test_instance_returns_to_active_after_resize)*05:51:13* 
 ***05:51:13* ** STDERR-BEGIN **


  https://rdjenkins.dyndns.org/job/Trove-Gate/2521/console (00:06:44
 wasted)

 *21:11:44* COMMAND_0: echo refs/changes/89/63789/13

 ...

 *22:05:00* 195.11 proboscis.case.MethodTest 
 (test_instance_returns_to_active_after_resize)*22:05:00* 186.89

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

[Craig Vyvial]

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 flavor if its not the
master in the cluster/grouping.

So is there a status of the replication set? If its healthy? or is that
just managed by the individual instances?
Because what would you expect to see if the first instance you create is
the master and the second is the slave and for what ever 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, Feb 5, 2014 at 4:38 PM, Daniel Salinas imsplit...@gmail.com wrote:


 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
 duplicating everything I just wrote in the wiki here are the proposed words
 that could be used to describe replication between two datastore instances
 of the same type.  Please take a moment to consider them and let me know
 what you think.  I welcome all feedback.

 replicates_from:  This term will be used in an instance that is a slave of
 another instance. It is a clear indicator that it is a slave of another
 instance.

 replicates_to: This term will be used in an instance that has slaves of
 itself. It is a clear indicator that it is a master of one or more
 instances.

 writable: This term will be used in an instance to indicate whether it is
 intended to be used for writes. As replication is used commonly to scale
 read operations it is very common to have a read-only slave in many
 datastore types. It is beneficial to the user to be able to see this
 information when viewing the instance details via the api.

 The intention here is to:
 1.  have a clearly defined replication contract between instances.
 2.  allow users to create a topology map simply by querying the api for
 details of instances linked in the replication contracts
 3.  allow the greatest level of flexibility for users when replicating
 their data so that Trove doesn't prescribe how they should make use of
 replication.

 I also think there is value in documenting common replication topologies
 per datastore type with example replication contracts and/or steps to
 recreate them in our api documentation.  There are currently no examples of
 this yet

 e.g. To create multi-master replication in mysql...

 As previously stated I welcome all feedback and would love input.

 Regards,

 Daniel Salinas

 ___
 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] how to list available configuration parameters for datastores

[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/datastore/versions/version
/datastores/versions/version

Add these paths:
/datastores/datastore/versions/version/parameters
/datastores/datastore/versions/version/parameters/parameters
/datastores/versions/version/parameters
/datastores/versions/version/parameters/parameters

This would the new set of paths for the parameters.

Any objections?


On Fri, Jan 24, 2014 at 2:47 PM, Craig Vyvial cp16...@gmail.com 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 are using the same
 template paths for the validation_rules as the base template which uses the
 manager field on the datastore_version. This means that we need to make the
 path over the version instead.

 /datastores/datastore/versions/version/parameters
 /datastores/datastore/versions/version/parameters/parameters

 Thanks for reminding me Morris.

 -Craig


 On Thu, Jan 23, 2014 at 11:52 PM, Daniel Morris 
 daniel.mor...@rackspace.com wrote:

   Quick question…

  When y'all say that onfiguration set must be associated to exactly one
 datastore, do you mean datastore or datastore version?  Wouldn't the
 configuration set available parameters defaults 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
 misunderstanding?

  Thanks,
 Daniel


   From: Craig Vyvial cp16...@gmail.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-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 for datastores

   I support the latest as well. I will make it so.

  Thanks


 On Thu, Jan 23, 2014 at 8:16 AM, Daniel Salinas imsplit...@gmail.comwrote:

 I agree.  This keeps everything identical to our current routing scheme.
  On Jan 23, 2014 7:31 AM, Denis Makogon dmako...@mirantis.com wrote:

  +1 to Greg.
  Given schema is more preferable for API routes
  /datastores/datastore/parameters
 /datastores/datastore/parameters/parameters



 2014/1/23 Greg Hill greg.h...@rackspace.com

 To be more consistent with other APIs in trove, perhaps:

  /datastores/datastore/parameters
  /datastores/datastore/parameters/parameters

  Greg

  On Jan 22, 2014, at 4:52 PM, Kaleb Pomeroy 
 kaleb.pome...@rackspace.com wrote:

  I think that may have been a slight oversite. We will likely have
 the following two routes

 /datastores/datastore/configuration/ would be the collection of all
 parameters
 /datastores/datastore/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)
 *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 the path since /datastores/datastore/configuration 
 doesnt
 do anything.

  instead of
 #1
 /datastores/datastore/configuration/parameters

  maybe:
 #2
 /datastores/datastore/parameters

  #3
 /datastores/datastore/configurationparameters




 On Wed, Jan 22, 2014 at 2:27 PM, Denis Makogon dmako...@mirantis.com
  wrote:

 Goodday to all.

  #3 looks more than acceptable.
 /datastores/datastore/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 mbasni...@gmail.com

  On Jan 22, 2014, at 10:19 AM, Kaleb Pomeroy wrote:

  My thoughts so far:
 
  /datastores/datastore/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 0-1 configuration set
  + All above relationships are immediately apparent
  - Listing all configuration sets becomes more difficult (which I
 don't think that is a valid concern)

  +1 to option 3, given what kaleb and craig have outlined so far. I
 dont see the above minus as a valid concern either, kaleb.


  ___
 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

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

[Craig Vyvial]

Denis,

This was slightly modified.

https://blueprints.launchpad.net/trove/+spec/move-manager-to-datastore-version

So an instance is correlated one-to-one with a datastore version because we
need to the datastore manager to get the templates and the configuration
rules because they are located in the same place. The manager can be shared
among multiple versions but it could be unique for a version as well which
could prove to be useful for version of mysql and other datastores.

I hope this make sense. :)

Thanks,
Craig


On Fri, Jan 24, 2014 at 3:29 PM, Denis Makogon dmako...@mirantis.comwrote:

 Hello, Craig.

 This short-cut seems like would affect initial design and implementation.
 For now we're pinning configuration to datastore (means for all version).
 I'd suggest you to elaborate how route changing would change current
 validations taking into accout version particular qualities.

 Best regards, Denis Makogon.


 2014/1/24 Craig Vyvial cp16...@gmail.com

 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/datastore/versions/version
 /datastores/versions/version

 Add these paths:
 /datastores/datastore/versions/version/parameters
  /datastores/datastore/versions/version/parameters/parameters
 /datastores/versions/version/parameters
 /datastores/versions/version/parameters/parameters

 This would the new set of paths for the parameters.

 Any objections?


 On Fri, Jan 24, 2014 at 2:47 PM, Craig Vyvial cp16...@gmail.com 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 are using the same
 template paths for the validation_rules as the base template which uses the
 manager field on the datastore_version. This means that we need to make the
 path over the version instead.

 /datastores/datastore/versions/version/parameters
 /datastores/datastore/versions/version/parameters/parameters

 Thanks for reminding me Morris.

 -Craig


 On Thu, Jan 23, 2014 at 11:52 PM, Daniel Morris 
 daniel.mor...@rackspace.com wrote:

   Quick question…

  When y'all say that onfiguration set must be associated to exactly
 one datastore, do you mean datastore or datastore version?  Wouldn't the
 configuration set available parameters defaults 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
 misunderstanding?

  Thanks,
 Daniel


   From: Craig Vyvial cp16...@gmail.com
 Reply-To: OpenStack Development Mailing List (not for usage
 questions) openstack-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 for datastores

   I support the latest as well. I will make it so.

  Thanks


 On Thu, Jan 23, 2014 at 8:16 AM, Daniel Salinas 
 imsplit...@gmail.comwrote:

 I agree.  This keeps everything identical to our current routing
 scheme.
  On Jan 23, 2014 7:31 AM, Denis Makogon dmako...@mirantis.com
 wrote:

  +1 to Greg.
  Given schema is more preferable for API routes
  /datastores/datastore/parameters
 /datastores/datastore/parameters/parameters



 2014/1/23 Greg Hill greg.h...@rackspace.com

 To be more consistent with other APIs in trove, perhaps:

  /datastores/datastore/parameters
  /datastores/datastore/parameters/parameters

  Greg

  On Jan 22, 2014, at 4:52 PM, Kaleb Pomeroy 
 kaleb.pome...@rackspace.com wrote:

  I think that may have been a slight oversite. We will likely have
 the following two routes

 /datastores/datastore/configuration/ would be the collection of
 all parameters
 /datastores/datastore/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)
 *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 the path since
 /datastores/datastore/configuration doesnt do anything.

  instead of
 #1
 /datastores/datastore/configuration/parameters

  maybe:
 #2
 /datastores/datastore/parameters

  #3
 /datastores/datastore/configurationparameters




 On Wed, Jan 22, 2014 at 2:27 PM, Denis Makogon 
 dmako...@mirantis.com wrote:

 Goodday to all.

  #3 looks more than acceptable.
 /datastores/datastore/configuration/parameters.
  According to configuration parameters design, a configuration set
 must be associated to exactly one datastore.

  Best regards, Denis Makogon.


 2014/1/22

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

[Craig Vyvial]

I support the latest as well. I will make it so.

Thanks


On Thu, Jan 23, 2014 at 8:16 AM, Daniel Salinas imsplit...@gmail.comwrote:

 I agree.  This keeps everything identical to our current routing scheme.
 On Jan 23, 2014 7:31 AM, Denis Makogon dmako...@mirantis.com wrote:

 +1 to Greg.
 Given schema is more preferable for API routes
 /datastores/datastore/parameters
 /datastores/datastore/parameters/parameters



 2014/1/23 Greg Hill greg.h...@rackspace.com

  To be more consistent with other APIs in trove, perhaps:

  /datastores/datastore/parameters
  /datastores/datastore/parameters/parameters

  Greg

  On Jan 22, 2014, at 4:52 PM, Kaleb Pomeroy kaleb.pome...@rackspace.com
 wrote:

  I think that may have been a slight oversite. We will likely have the
 following two routes

 /datastores/datastore/configuration/ would be the collection of all
 parameters
 /datastores/datastore/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)
 *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 the path since /datastores/datastore/configuration doesnt
 do anything.

  instead of
 #1
 /datastores/datastore/configuration/parameters

  maybe:
 #2
 /datastores/datastore/parameters

  #3
 /datastores/datastore/configurationparameters




 On Wed, Jan 22, 2014 at 2:27 PM, Denis Makogon dmako...@mirantis.com
 wrote:

 Goodday to all.

  #3 looks more than acceptable.
 /datastores/datastore/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 mbasni...@gmail.com

  On Jan 22, 2014, at 10:19 AM, Kaleb Pomeroy wrote:

  My thoughts so far:
 
  /datastores/datastore/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 0-1 configuration set
  + All above relationships are immediately apparent
  - Listing all configuration sets becomes more difficult (which I
 don't think that is a valid concern)

  +1 to option 3, given what kaleb and craig have outlined so far. I
 dont see the above minus as a valid concern either, kaleb.


  ___
 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



 ___
 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


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

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

[Craig Vyvial]

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 the default(mysql) datastore and this wont work
for other datastores like redis/cassandra/etc.

/configurations/parameters - parameter list for mysql
/configurations/parameters/parameter_name - details of parameter

We need to be able to request the parameter list per datastore. Here are
some suggestions that outlines how each method may work.

ONE:

/configurations/parameters?datastore=mysql - list parameter for mysql
/configurations/parameters?datastore=redis - list parameter for redis

- we do not use query parameters for anything other than pagination (limit
and marker)
- this requires some finagling with the context to add the datastore.
https://gist.github.com/cp16net/8547197

TWO:

/configurations/parameters - list of datastores that have configuration
parameters
/configurations/parameters/datastore - list of parameters for datastore

THREE:

/datastores/datastore/configuration/parameters - list the parameters for
the datastore

FOUR:

/datastores/datastore - add an href on the return to the configuration
parameter list for the datastore
/configurations/parameters/datastore - list of parameters for datastore

FIVE:

* Require a configuration be created with a datastore.
Then a user may list the configuration parameters allowed on that
configuration.

/configurations/config_id/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.

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

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

[Craig Vyvial]

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/datastore/configuration doesnt
do anything.

instead of
#1
/datastores/datastore/configuration/parameters

maybe:
#2
/datastores/datastore/parameters

#3
/datastores/datastore/configurationparameters




On Wed, Jan 22, 2014 at 2:27 PM, Denis Makogon dmako...@mirantis.comwrote:

 Goodday to all.

 #3 looks more than acceptable.
 /datastores/datastore/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 mbasni...@gmail.com

 On Jan 22, 2014, at 10:19 AM, Kaleb Pomeroy wrote:

  My thoughts so far:
 
  /datastores/datastore/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 0-1 configuration set
  + All above relationships are immediately apparent
  - Listing all configuration sets becomes more difficult (which I don't
 think that is a valid concern)

 +1 to option 3, given what kaleb and craig have outlined so far. I dont
 see the above minus as a valid concern either, kaleb.


 ___
 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

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

[Craig Vyvial]

+1 yes that is true.

Thanks,
Craig


On Wed, Jan 22, 2014 at 4:52 PM, Kaleb Pomeroy
kaleb.pome...@rackspace.comwrote:

  I think that may have been a slight oversite. We will likely have the
 following two routes

 /datastores/datastore/configuration/ would be the collection of all
 parameters
 /datastores/datastore/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)
 *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 the path since /datastores/datastore/configuration doesnt
 do anything.

  instead of
 #1
 /datastores/datastore/configuration/parameters

  maybe:
 #2
 /datastores/datastore/parameters

  #3
 /datastores/datastore/configurationparameters




 On Wed, Jan 22, 2014 at 2:27 PM, Denis Makogon dmako...@mirantis.comwrote:

 Goodday to all.

  #3 looks more than acceptable.
 /datastores/datastore/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 mbasni...@gmail.com

  On Jan 22, 2014, at 10:19 AM, Kaleb Pomeroy wrote:

  My thoughts so far:
 
  /datastores/datastore/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 0-1 configuration set
  + All above relationships are immediately apparent
  - Listing all configuration sets becomes more difficult (which I don't
 think that is a valid concern)

  +1 to option 3, given what kaleb and craig have outlined so far. I dont
 see the above minus as a valid concern either, kaleb.


  ___
 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


___
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 Auston McReynolds to trove-core

[Craig Vyvial]

+1


On Mon, Dec 30, 2013 at 12:00 PM, Greg Hill greg.h...@rackspace.com wrote:

  +1

  On Dec 27, 2013, at 4:48 PM, Michael Basnight 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 with reviews and helps connect large features that may overlap
 (config edits + multi datastores comes to mind). The code he submits is top
 notch, and we frequently ask for his opinion on architecture / feature /
 design.

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

  Please respond with +1/-1, or any further comments.
  ___
 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

[openstack-dev] [trove] configuration groups and datastores type/versions

[Craig Vyvial]

Configuration Groups is currently developed to associate the datastore
version with a configuration that is created. If a datastore version is not
presented it will use the default similar to the way instances are created
now. This looks like a way of associating the configuration with a
datastore because an instance has this same association.

Depending on how you setup your datastore types and versions this might not
be ideal.
Example:
Datastore Type | Version
-
Mysql  | 5.1
Mysql  | 5.5
Percona| 5.5
-

Configuration  | datastore_version
---
mysql-5.5-config   | mysql 5.5
percona-5.5-config | percona 5.5
---

or

Datastore Type | Version
-
Mysql 5.1  | 5.1.12
Mysql 5.1  | 5.1.13
Mysql  | 5.5.32
Percona| 5.5.44
-

Configuration  | datastore_version
---
mysql-5.1-config   | mysql 5.5
percona-5.5-config | percona 5.5
---


Notice that if you associate the configuration with a datastore version
then in the latter example you will not be able to use the same
configurations that you created with different minor versions of the
datastore.

Something that we should consider is allowing a configuration to be
associated with a just a datastore type (eg. Mysql 5.1) so that any
versions of 5.1 should allow the same configuration to be applied.

I do not view this as a change that needs to happen before the current code
is merged but more as an additive feature of configurations.


*snippet from Morris and I talking about this*

Given the nature of how the datastore / types code has been implemented in
that it is highly configurable, I believe that we we need to adjust the way
in which we are associating configuration groups with datastore types and
versions.  The main use case that I am considering here is that as a user
of the API, I want to be able to associate configurations with a specific
datastore type so that I can easily return a list of the configurations
that are valid for that database type (Example: Get me a list of
configurations for MySQL 5.6).   We know that configurations will vary
across types (MySQL vs. Redis) as well as across major versions (MySQL 5.1
vs MySQL 5.6).   Presently, the code only keys off the datastore version,
and consequently, if I were to set up my datastore type as MySQL X.X and
datastore versions as X.X.X, then you would be potentially associating a
configuration with a specific minor version such as MySQL 5.1.63.Given
then, I am thinking that it makes more sense to allow a configuration to be
associated with both a datastore type AND and datastore version with
precedence given to the datastore type (where both attributes are either
optional – or at least one is required).  This would give the most
flexibility to associate configurations 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 Vyvial
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Trove] configuration groups using overrides file

[Craig Vyvial]

Denis,

I'm proposing that #3 and #4 sorta be swapped from your list where we merge
the config group parameters into the main config and send down the file
like we do now. So the guest does not need to handle the merging. The logic
is the same just the location of the logic to merge be handled by the
service rather than at the guest.

Most of the merging logic could be part of the jinja template we already
have.

This will allow the guest to be agnostic of the type of config file and
less logic in the guest.


-Craig




On Wed, Nov 13, 2013 at 1:19 PM, Denis Makogon dmako...@mirantis.comwrote:

 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 by manager.


 2013/11/13 Craig Vyvial cp16...@gmail.com

 We need to determine if we should not use a separate file for the
 overrides config as it might not be supported by all dbs trove supports.
 (works well for mysql but might not for cassandra as we discussed in the
 irc channel)

 To support this for all dbs we could setup the jinja templates to add 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



 ___
 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] Configuration API BP

[Craig Vyvial]

I have updated the reviews related to configuration groups.

Trove - https://review.openstack.org/#/c/53168/
Python-TroveClient - https://review.openstack.org/#/c/53169/

Please review at your leisure.

TODOs:
* add pagination support for configuration on instances
* mark configuration groups as deleted instead of doing a hard delete in
the db.


Thanks,
Craig Vyvial


On Thu, Oct 3, 2013 at 3:48 PM, Craig Vyvial cp16...@gmail.com wrote:

 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 cp16...@gmail.com wrote:

 I have been trying to figure out where a call for the default
 configuration should go. I just finished adding a method to get the
 [mysqld] section via an api call but not sure where this should go yet.

 Currently i made it:
 GET - /instance/{id}/configuration

 This kinda only half fits in the path here because it doesnt really
 describe that this is the default configuration on the instance. On the
 other hand, it shows that it is coupled to the instance because we need the
 instance flavor to give what the current values are in the template applied
 to the instance.

 Maybe other options could be:
 GET - /instance/{id}/configuration/default
 GET - /instance/{id}/defaultconfiguration
 GET - /instance/{id}/default-configuration
 GET - /configuration/default/instance/{id}

 Suggestions welcome on the path.

 There is some wonkiness showing this information to the user because of
 the difference in the values used. [1] This example shows that the template
 uses 50M as a value applied and the configuration-group would apply the
 value equivalent to 52428800. I dont think we should worry about this now
 but this could lead to confusion by a user. If they are a power-user type
 then they might understand compared to a entry level user.

 [1] https://gist.github.com/cp16net/6816691



  On Thu, Oct 3, 2013 at 2:36 PM, McReynolds, Auston amcreyno...@ebay.com
  wrote:

 If User X's existing instance is isolated from the change, but there's
 no snapshot/clone/versioning of the current settings on X's instance
 (via the trove database or jinja template), then how will
 GET /configurations/:id return the correct/current settings? Unless
 you're planning on communicating with the guest? There's nothing
 wrong with that approach, it's just not explicitly noted anywhere in
 the blueprint. For some reason I inferred that it would be handled
 like trove security-groups.

 So this is a great point. There are talks about making the templating
 versioned in some form or fashion. ekonetzk(irc) said he would write up a
 BP around versioning.



 On a slightly different note: If the default template will not be
 represented as a default configuration-group from an api standpoint,
 then how will you support the ability for a user to enumerate the list
 of default configuration-group values for a service-type?
 GET /configurations/:id won't be applicable, so will it be
 something like GET /configurations/default?

 see above paragraph.





 From:  Craig Vyvial cp16...@gmail.com
 Reply-To:  OpenStack Development Mailing List
 openstack-dev@lists.openstack.org
 Date:  Thursday, October 3, 2013 11:17 AM
 To:  OpenStack Development Mailing List 
 openstack-dev@lists.openstack.org
 Subject:  Re: [openstack-dev] [trove] Configuration API BP


 inline.


 On Wed, Oct 2, 2013 at 1:03 PM, McReynolds, Auston
 amcreyno...@ebay.com wrote:

 Awesome! I only have one follow-up question:

 Regarding #6  #7, how will the clone behavior work given that the
 defaults are hydrated by a non-versioned jinja template?


 I am not sure i understand clone behavior because there is not really a
 concept of cloning here. The jinja template is created and passed in the
 prepare call to the guest to write to the default my.cnf file.

 When a configuration-group is removed the instance will return to the
 default state. This does not exactly act as a clone behavior.



 Scenario Timeline:

 T1) Cloud provider begins with the default jinja template, but changes
the values for properties 'a' and 'b'. (Template Version #1)
 T2) User X deploys a database instance
 T3) Cloud provider decides to update the existing template by modifying
property 'c'. (Template Version #2)
 T4) User Z deploys a database instance

 I think it goes without saying that User Z's instance gets Template
 Version #2 (w/ changes to a  b  c), but does User X?


 No User X does not get the changes. For User X to get the changes a
 maintenance may need to be scheduled.



 If it's a true clone, User X should be isolated from a change in
 defaults, no?


 User X will not see these default changes until a new instance is
 created.



 Come to think about it, this is eerily similar to security-groups:
 administratively, it can be beneficial to share a
 configuration/security-group across multiple instances, but it can
 also

[openstack-dev] [Trove] configuration groups using overrides file

[Craig Vyvial]

We need to determine if we should not use a separate file for the overrides
config as it might not be supported by all dbs trove supports. (works well
for mysql but might not for cassandra as we discussed in the irc channel)

To support this for all dbs we could setup the jinja templates to add 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

Re: [openstack-dev] [trove] Configuration API BP

[Craig Vyvial]

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 cp16...@gmail.com wrote:

 I have been trying to figure out where a call for the default
 configuration should go. I just finished adding a method to get the
 [mysqld] section via an api call but not sure where this should go yet.

 Currently i made it:
 GET - /instance/{id}/configuration

 This kinda only half fits in the path here because it doesnt really
 describe that this is the default configuration on the instance. On the
 other hand, it shows that it is coupled to the instance because we need the
 instance flavor to give what the current values are in the template applied
 to the instance.

 Maybe other options could be:
 GET - /instance/{id}/configuration/default
 GET - /instance/{id}/defaultconfiguration
 GET - /instance/{id}/default-configuration
 GET - /configuration/default/instance/{id}

 Suggestions welcome on the path.

 There is some wonkiness showing this information to the user because of
 the difference in the values used. [1] This example shows that the template
 uses 50M as a value applied and the configuration-group would apply the
 value equivalent to 52428800. I dont think we should worry about this now
 but this could lead to confusion by a user. If they are a power-user type
 then they might understand compared to a entry level user.

 [1] https://gist.github.com/cp16net/6816691



 On Thu, Oct 3, 2013 at 2:36 PM, McReynolds, Auston 
 amcreyno...@ebay.comwrote:

 If User X's existing instance is isolated from the change, but there's
 no snapshot/clone/versioning of the current settings on X's instance
 (via the trove database or jinja template), then how will
 GET /configurations/:id return the correct/current settings? Unless
 you're planning on communicating with the guest? There's nothing
 wrong with that approach, it's just not explicitly noted anywhere in
 the blueprint. For some reason I inferred that it would be handled
 like trove security-groups.

 So this is a great point. There are talks about making the templating
 versioned in some form or fashion. ekonetzk(irc) said he would write up a
 BP around versioning.



 On a slightly different note: If the default template will not be
 represented as a default configuration-group from an api standpoint,
 then how will you support the ability for a user to enumerate the list
 of default configuration-group values for a service-type?
 GET /configurations/:id won't be applicable, so will it be
 something like GET /configurations/default?

 see above paragraph.





 From:  Craig Vyvial cp16...@gmail.com
 Reply-To:  OpenStack Development Mailing List
 openstack-dev@lists.openstack.org
 Date:  Thursday, October 3, 2013 11:17 AM
 To:  OpenStack Development Mailing List 
 openstack-dev@lists.openstack.org
 Subject:  Re: [openstack-dev] [trove] Configuration API BP


 inline.


 On Wed, Oct 2, 2013 at 1:03 PM, McReynolds, Auston
 amcreyno...@ebay.com wrote:

 Awesome! I only have one follow-up question:

 Regarding #6  #7, how will the clone behavior work given that the
 defaults are hydrated by a non-versioned jinja template?


 I am not sure i understand clone behavior because there is not really a
 concept of cloning here. The jinja template is created and passed in the
 prepare call to the guest to write to the default my.cnf file.

 When a configuration-group is removed the instance will return to the
 default state. This does not exactly act as a clone behavior.



 Scenario Timeline:

 T1) Cloud provider begins with the default jinja template, but changes
the values for properties 'a' and 'b'. (Template Version #1)
 T2) User X deploys a database instance
 T3) Cloud provider decides to update the existing template by modifying
property 'c'. (Template Version #2)
 T4) User Z deploys a database instance

 I think it goes without saying that User Z's instance gets Template
 Version #2 (w/ changes to a  b  c), but does User X?


 No User X does not get the changes. For User X to get the changes a
 maintenance may need to be scheduled.



 If it's a true clone, User X should be isolated from a change in
 defaults, no?


 User X will not see these default changes until a new instance is created.



 Come to think about it, this is eerily similar to security-groups:
 administratively, it can be beneficial to share a
 configuration/security-group across multiple instances, but it can
 also be a nightmare. Internally, it's extremely rare that we wish to
 apply a database change to multiple tenants at once, so I'd argue
 at a minimum to support a CONF opt-in for isolation, if not default
 to it.


 If i understand this correctly my above statement means that its isolated
 by default.



 On a related note: Will the default template for a service-type be
 represented as a default configuration-group? If so, I imagine it
 can be managed

Re: [openstack-dev] [trove] Configuration API BP

[Craig Vyvial]

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
because you are updating the configuration key/values. This will not update
the UUID of the configuration because we are not trying to make the changes
like a sub-versioned system.

'configuration' is a resource that can be applied only to instances. Making
it a sub-resource of '/instances' is an option but does that warrant it
always being tied to an instance?

Each configuration is unique to a tenant and therefore doesnt allow a
reseller to create a tweaked out config. I see value in allowing resellers
to do this but currently they can update the templates that are used in the
system.



On Tue, Oct 1, 2013 at 9:55 PM, Michael Basnight mbasni...@gmail.comwrote:

 On Oct 1, 2013, at 7:19 PM, Vipul Sabhaya wrote:
 
  So from this API, I see that a configuration is a standalone resource
 that could be applied to N number of instances.  It's not clear to me what
 the API is for 'applying' a configuration to an existing instance.


 https://wiki.openstack.org/wiki/Trove/Configurations#Update_an_Instance_.28PUT.29

  Also if we change a single item in a given configuration, does that
 change propagate to all instances that configuration belongs to?

 Thats a good question. Maybe PATCH'ing a configuration is not a good
 thing. We either have 1) drift between an attached config on an instance vs
 the template, or 2) a confusing situation where we are potentially updating
 configurations on running instances. Another possibility is that a PATCH
 would in effect, clone the existing template, if its in use, giving it a
 new UUID with the updated parameters. But im not sure i like that approach
 either… Its really not a PATCH at that point anyway id think.

 Blueprint designers, im looking to you for clarity.

  What about making 'configuration' a sub-resource of /instances?
 
  Unless we think configurations will be common amongst instances for a
 given tenant, it may not make sense to make them high level resources.

 As in /instances/configurations, or /instances/{id}/configurations ? I do
 see commonality between a configuration and a bunch of instances, such that
 a configuration is not unique to a single instance. I can see a reseller
 having a tweaked out works with _insert your favorite CMS here_ template
 applied to all the instances they provision.


 ___
 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] Configuration API BP

[Craig Vyvial]

These are some good q's.
responses inline


On Wed, Oct 2, 2013 at 1:20 AM, McReynolds, Auston amcreyno...@ebay.comwrote:

 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 default configuration group should be customized by a provider.
This can be done via the jinja templates that are currently used.



 #2 - Should a user be able to enumerate the entire actualized/realized
 set of values for a configuration-group, or just the overrides?

The user should be able to see what configurations they have overridden
from the defaults. The user should be able to see the defaults by querying
the db.



 #3 - Should a user be able to apply a different configuration-group on
 a master, than say, a slave?

Yes they should be able to apply any configuration they want to each
instance they own.



 #4 - If a user creates a new configuration-group with values equal to
 that of the default configuration-group, what is the expected
 behavior?

The user should be capable of creating a configuration-group with any
values they would like that are in bounds to the variable to be set.



 #5 - For GET /configuration/parameters, where is the list of supported
 parameters and their metadata sourced from?

There is a config file that has all the options available to the user. This
is sources and displayed via the GET call.
example of the file: https://gist.github.com/6796477



 #6 - Should a user be able to reset a configuration-group to the
 current default configuration-group?

A user should be able to reset the configuration-group to the default in
the template and they can do this by unassigning the configuration to the
instance.
There is a test case for this.


 #7 - Is a new configuration-group a clone of the then current default
 configuration-group with various changes, or will inheritence be
 utilized?

A new configuration-group will be setting the override changes to the
default my.cnf template.
We include the overrides.cnf directory location in the my.cnf
!includedir /etc/mysql/conf.d/
The overrides.cnf will be written with the changes to the configuration
group and apply them dynamically if they can be, otherwise a restart will
be required of the instance.


 #8 - How should the state of pending configuration-group changes be
 reflected in GET /instances/:id ? How will this state be
 persisted?

All dynamic changes will be applied at the time they are either 1) applied
to the configuration group that is tied to an instance or 2) when a
configuration group is applied to an instance. If there are changes that
cannot be dynamically set then we will change the state of the instance to
RESTART_REQUIRED to apply the changes.



 #9 - Reminder: Once multiple service-types and versions are supported,
 the configuration-group will need a service-type field.

Yes i agree with this and need a way of splitting the validation rules and
making sure that we dont allow applying a configuration-group to different
service types.



 #10 - Should dynamic values (via functions and operators) in
   configuration-groups be supported?
   Example: innodb_buffer_pool_size = 150 * flavor['ram']/512

I've thought about this but I do not this we should try to shoot for this
right now.
I have some ideas similar to what you are describing but not sure i want to
tackle this in the first iteration.



 My Thoughts:

 #1 - Yes
 #2 - Actualized
 #3 - Yes
 #4 - Depends on whether the approach for configuration-groups is to
 clone or to inherit.
 #5 - ?
 #6 - Yes
 #7 - ?
 #8 - ?
 #9 - N/A
 #10 - In the first iteration of this feature I don't think it's an
   absolute necessity, but it's definitely a nice-to-have. The
   design/implementation should not preclude this from being easily
   added in the future.

 Where ? == I'd like to think about it a bit more, but I have a gut
 feeling

 Thoughts?



 On 10/1/13 7:55 PM, Michael Basnight mbasni...@gmail.com wrote:

 On Oct 1, 2013, at 7:19 PM, Vipul Sabhaya wrote:
 
  So from this API, I see that a configuration is a standalone resource
 that could be applied to N number of instances.  It's not clear to me
 what the API is for 'applying' a configuration to an existing instance.
 
 
 https://wiki.openstack.org/wiki/Trove/Configurations#Update_an_Instance_.2
 8PUT.29
 
  Also if we change a single item in a given configuration, does that
 change propagate to all instances that configuration belongs to?
 
 Thats a good question. Maybe PATCH'ing a configuration is not a good
 thing. We either have 1) drift between an attached config on an instance
 vs the template, or 2) a confusing situation where we are potentially
 updating configurations on running instances. Another possibility is that
 a PATCH would in effect, clone the existing 

Re: [openstack-dev] [trove] Configuration API BP

[Craig Vyvial]

On Wed, Oct 2, 2013 at 11:39 AM, Michael Basnight mbasni...@gmail.comwrote:

 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 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
 because you are updating the configuration key/values. This will not update
 the UUID of the configuration because we are not trying to make the changes
 like a sub-versioned system.

 ok if thats the expected behavior, im ok with that. ByeByeBye with the
 other options ;)

 
  'configuration' is a resource that can be applied only to instances.
 Making it a sub-resource of '/instances' is an option but does that warrant
 it always being tied to an instance?

 No.

 
  Each configuration is unique to a tenant and therefore doesnt allow a
 reseller to create a tweaked out config. I see value in allowing resellers
 to do this but currently they can update the templates that are used in the
 system.

 I mean a single tenant being that reseller. He has 1 template he applies
 to all his db instances for his customers, which he supports outside of
 trove.

This sounds similar to supporting roles or sharing resources. This is a
great use case and if we were to put configurations under instances would
we be able to achieve this? I'm thinking no?



 ___
 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] Configuration API BP

[Craig Vyvial]

I'm glad we both agree on most of these answers.
:)
 On Oct 2, 2013 11:57 AM, Michael Basnight mbasni...@gmail.com 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 service-type be
 customizable by the cloud provider?

 Yes

 
  #2 - Should a user be able to enumerate the entire actualized/realized
 set of values for a configuration-group, or just the overrides?

 actualized

 
  #3 - Should a user be able to apply a different configuration-group on
 a master, than say, a slave?

 Yes

 
  #4 - If a user creates a new configuration-group with values equal to
 that of the default configuration-group, what is the expected
 behavior?

 Im not sure thats an issue. You will select your config group, and it will
 be the one used. I believe you are talking the difference between the
 template thats used to set up values for the instance, and the config
 options that users are allowed to edit. Those are going to be appended,
 so to speak, to the existing template. Itll be up to the server software to
 define what order values, if duplicated, are read / used.

 
  #5 - For GET /configuration/parameters, where is the list of supported
 parameters and their metadata sourced from?

 i believe its a db table… someone may have to correct me there.

 
  #6 - Should a user be able to reset a configuration-group to the
 current default configuration-group?

 Yes, assuming we have a default config group, and im not sure we have a
 concept of that. We have what the install creates, the templated config
 file. Removing the association of your config from the instance will do
 this thought.

 
  #7 - Is a new configuration-group a clone of the then current default
 configuration-group with various changes, or will inheritence be
 utilized?

 I think clone will be saner for now. But you can edit your group with a
 PATCH, and that will not clone it. See [1] first paragraph.

 
  #8 - How should the state of pending configuration-group changes be
 reflected in GET /instances/:id ? How will this state be
 persisted?

 You are talking about changes that require a restart i believe. I think
 this falls into the same category as our conversation about minor version
 updates. We can have a pretty generic restart required somewhere there.

 
  #9 - Reminder: Once multiple service-types and versions are supported,
 the configuration-group will need a service-type field.

 Most def. You will only be able to assign relevant configs to their
 service-types, and the /configuration/parameters will need to be typed too.

 
  #10 - Should dynamic values (via functions and operators) in
   configuration-groups be supported?
   Example: innodb_buffer_pool_size = 150 * flavor['ram']/512

 H. This is quite interesting. But no, not v1. I totally agree w/ the
 nice-to-have. Good idea though, we should add it to the blueprint.

 
  My Thoughts:
 
  #1 - Yes
  #2 - Actualized
  #3 - Yes
  #4 - Depends on whether the approach for configuration-groups is to
 clone or to inherit.
  #5 - ?
  #6 - Yes
  #7 - ?
  #8 - ?
  #9 - N/A
  #10 - In the first iteration of this feature I don't think it's an
   absolute necessity, but it's definitely a nice-to-have. The
   design/implementation should not preclude this from being easily
   added in the future.
 
  Where ? == I'd like to think about it a bit more, but I have a gut
  feeling
 
  Thoughts?

 [1]
 http://lists.openstack.org/pipermail/openstack-dev/2013-October/015919.html

 ___
 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] Thoughts on DNS refactoring, Designate integration.

[Craig Vyvial]

+1 to Vipul


On Tue, Oct 1, 2013 at 9:46 PM, Michael Basnight mbasni...@gmail.comwrote:

 On Oct 1, 2013, at 7:06 PM, Vipul Sabhaya wrote:

  On Oct 1, 2013, at 3:37 PM, Michael Basnight mbasni...@gmail.com
 wrote:
 
  On Oct 1, 2013, at 3:06 PM, Ilya Sviridov isviri...@mirantis.com
 wrote:
 
 
  On Tue, Oct 1, 2013 at 6:45 PM, Tim Simpson tim.simp...@rackspace.com
 wrote:
  Hi fellow Trove devs,
 
  With the Designate project ramping up, its time to refactor the
 ancient DNS code that's in Trove to work with Designate.
 
  The good news is since the beginning, it has been possible to add new
 drivers for DNS in order to use different services. Right now we only have
 a driver for the Rackspace DNS API, but it should be possible to write one
 for Designate as well.
 
  How it corelates with Trove dirrection to use HEAT for all
 provisioning and managing cloud resources?
  There are BPs for Designate resource (
 https://blueprints.launchpad.net/heat/+spec/designate-resource) and
 Rackspace DNS (
 https://blueprints.launchpad.net/heat/+spec/rax-dns-resource) as well and
 it looks logically to use the HEAT for that.
 
  Currently Trove has logic for provisioning instances, dns driver,
 creation of security group, but with switching to HEAT way, we have
 duplication of the same functionality we have to support.
 
  +1 to using heat for this. However, as people are working on heat
 support right now to make it more sound, if there is a group that
 wants/needs DNS refactoring now, I'd say lets add it in. If no one is in
 need of changing what's existing until we get better heat support, then we
 should just abandon the review and leave the existing DNS code as is.
 
  I would prefer, if there is no one in need, to abandon the exiting
 review and add it to heat support.
 
 
  I would hate to wait til we have full Heat integration before getting
 Designate support, considering Heat does not yet have Designate support.
  My vote is to move forward with a DNS driver in trove that can be
 deprecated once everything works with Heat.
 
  As far as supporting only Designate, I would be fine with a driver
 interface that could potentially wrap Designate as well as Rax DNS.  Given
 that both will be somewhat temporary, I don't see a reason why we have to
 rip out rsdns at this point.

 Sounds like we have a winner.

 ___
 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] [Trove] vagrant vbox and vmware developer environment support

[Craig Vyvial]

We have vagrant working with virtual box to start up a trove development
environment. This was tested with VirtualBox on an Ubuntu machine but
should work with any other environment as well. This is nice and should
benefit the community to setup trove easily in multiple environments.

This repo 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove] Configuration API BP

[Craig Vyvial]

I see PATCH used all over the keystone v3 API. Its not used at all in other
older versions. I take that meaning that they did not want to add confusion
or many changes in the current version of the API.[1]

Although since the Configuration is technically a new API being added to
the core of Trove, should consider it to enhance the API now or keep it on
par the way the rest of the API looks.

After looking over the docs[1] I am on the fence and I would like others to
weigh in.

[1] http://api.openstack.org/api-ref-identity.html


On Thu, Sep 26, 2013 at 10:49 AM, Michael Basnight mbasni...@gmail.comwrote:

 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
 
  This is an overview of the API calls for
 
  POST /configurations - create config
  GET  /configurations - list all configs
  PUT  /configurations/{id} - update all the parameters
 
  GET  /configurations/{id} - get details on a single config
  GET  /configurations/{id}/{key} - get single parameter value that was
 set for the configuration
 
  PUT  /configurations/{id}/{key} - update/insert a single parameter
  DELETE  /configurations/{id}/{key} - delete a single parameter
 
  GET  /configurations/{id}/instances - list of instances the config is
 assigned to
  GET  /configurations/parameters - list of all configuration parameters
 
  GET  /configurations/parameters/{key} - get details on a configuration
 parameter
 
  There has been talk about using PATCH http action instead of PUT action
 for thie update of individual parameter(s).
 
  PUT  /configurations/{id}/{key} - update/insert a single parameter
  and/or
  PATCH  /configurations/{id} - update/insert parameter(s)
 
 
  I am not sold on the idea of using PATCH unless its widely used in other
 projects across Openstack. What does everyone think about this?
 
  If there are any concerns around this please let me know.

 Im a fan of PATCH. Id rather have a different verb on the same resource
 than creating a new sub-resource just to do the job of what PATCH defines.
 Im not sure the [1] gives us any value, and i think its only around because
 of [2]. I can see PATCH removing the need for [1], simplifying the API. And
 of course removing the need for [2] since it _is_ the updating of a single
 kv pair. And i know keystone and glance use PATCH for updates in their
 API as well.

 [1]  GET /configurations/{id}/{key}
 [2] PUT  /configurations/{id}/{key}

 ___
 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] [trove] Configuration API BP

[Craig Vyvial]

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

This is an overview of the API calls for

POST /configurations - create config
GET  /configurations - list all configs
PUT  /configurations/{id} - update all the parameters
GET  /configurations/{id} - get details on a single config
GET  /configurations/{id}/{key} - get single parameter value that was
set for the configuration
PUT  /configurations/{id}/{key} - update/insert a single parameter
DELETE  /configurations/{id}/{key} - delete a single parameter
GET  /configurations/{id}/instances - list of instances the config is
assigned to
GET  /configurations/parameters - list of all configuration parameters
GET  /configurations/parameters/{key} - get details on a configuration parameter


There has been talk about using PATCH http action instead of PUT action for
thie update of individual parameter(s).

PUT /configurations/{id}/{key} - update/insert a single parameter
and/or
PATCH /configurations/{id} - update/insert parameter(s)

I am not sold on the idea of using PATCH unless its widely 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-bin/mailman/listinfo/openstack-dev