gt;>> 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 abili
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
t; 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
ype?
> GET /configurations/:id won't be applicable, so will it be
> something like GET /configurations/default?
>
see above paragraph.
>
>
>
> From: Craig Vyvial
> Reply-To: OpenStack Development Mailing List
>
> Date: Thursday, October 3, 2013 11:17 AM
&g
t?
From: Craig Vyvial
Reply-To: OpenStack Development Mailing List
Date: Thursday, October 3, 2013 11:17 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [trove] Configuration API BP
inline.
On Wed, Oct 2, 2013 at 1:03 PM, McReynolds, Auston
wrote:
Awesome!
ve type of
feature.
>
>
> From: Craig Vyvial
> Reply-To: OpenStack Development Mailing List
>
> Date: Wednesday, October 2, 2013 10:06 AM
> To: OpenStack Development Mailing List >
> Subject: Re: [openstack-dev] [trove] Configuration API BP
>
>
> I'
it.
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 through the API (or MGMT API)?
From: Craig Vyvial
Reply-To: OpenStack Development Mailing List
Date: Wednesday, October 2, 2013 10:06 AM
To:
I'm glad we both agree on most of these answers.
:)
On Oct 2, 2013 11:57 AM, "Michael Basnight" wrote:
> On Oct 1, 2013, at 11:20 PM, McReynolds, Auston wrote:
>
> > I have a few questions left unanswered by the blueprint/wiki:
> >
> > #1 - Should the true default configuration-group for a servi
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 ent
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.
On Wed, Oct 2, 2013 at 11:39 AM, Michael Basnight wrote:
> On Oct 2, 2013, at 9:21 AM, Craig Vyvial wrote:
>
> > If a configuration is updated that is attached to N instances then those
> instances will be updated with the configuration overrides. This will keep
> the configuration n-sync[hah 90s
These are some good q's.
responses inline
On Wed, Oct 2, 2013 at 1:20 AM, McReynolds, Auston wrote:
> I have a few questions left unanswered by the blueprint/wiki:
>
> #1 - Should the true default configuration-group for a service-type be
> customizable by the cloud provider?
>
The true
If a configuration is updated that is attached to N instances then those
instances will be updated with the configuration overrides. This will keep
the configuration n-sync[hah 90s boy band reference] with instances that
have it attached. I'm not sure that this is really a "confusing situation"
bec
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?
#2 - Should a user be able to enumerate the entire actualized/realized
set of values for a configuration-group,
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.o
> On Sep 26, 2013, at 8:49 AM, Michael Basnight wrote:
>
>> 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/+spe
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,
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 fo
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 -
19 matches
Mail list logo
