On 20 August 2015 at 23:19, Ruby Loo wrote:
>
> On 18 August 2015 at 17:13, Ruby Loo wrote:
>
>>
>>
>> On 18 August 2015 at 13:08, Lucas Alvares Gomes
>> wrote:
>>
>>> HI
>>>
>>> > Hi, I'd like to make sure I understand. Is it the case that ideally,
>>> if we
>>
>> > could go back in time, we'd
On 18 August 2015 at 17:13, Ruby Loo wrote:
>
>
> On 18 August 2015 at 13:08, Lucas Alvares Gomes
> wrote:
>
>> HI
>>
>> > Hi, I'd like to make sure I understand. Is it the case that ideally,
>> if we
>
> > could go back in time, we'd like to change the client so it defaults to
>> 1.1?
>>
>> AFA
On 18 August 2015 at 13:08, Lucas Alvares Gomes
wrote:
> HI
>
> > Hi, I'd like to make sure I understand. Is it the case that ideally, if
> we
> > could go back in time, we'd like to change the client so it defaults to
> 1.1?
>
> AFAIUI, yes
>
> > But since we can't, the next client that we ship/
HI
> Hi, I'd like to make sure I understand. Is it the case that ideally, if we
> could go back in time, we'd like to change the client so it defaults to 1.1?
AFAIUI, yes
> But since we can't, the next client that we ship/release will have the most
> reasonable oldest version? If so, then since
On 11 August 2015 at 06:13, Ruby Loo wrote:
> Hi, sorry for the delay. I vote no. I understand the rationale of trying to
> do things so that we don't break our users but that's what the versioning is
> meant for and more importantly -- I think adding the ENROLL state is fairly
> important wrt the
On 1 August 2015 at 05:16, Lucas Alvares Gomes
wrote:
> Hi,
>
> > It sounds like we all agree -- the client we ship should default to a
> fixed,
> > older version. Anyone who wants newer functionality can pass a newer
> version
> > to their client.
> >
> > Here's the current state of things:
> >
On Mon, Aug 10, 2015 at 9:13 PM, Ruby Loo wrote:
> So KISS as much as we can! :)
+1
Cheers,
Serge Kovaleff
http://www.mirantis.com
cell: +38 (063) 83-155-70
__
OpenStack Development Mailing List (not for usage questions)
U
On 4 August 2015 at 12:20, Jim Rollenhagen wrote:
> On Mon, Jul 27, 2015 at 01:35:25PM -0700, Jim Rollenhagen wrote:
> >
> > Now we've landed a patch[0] with a new version (1.11) that is not
> > backward compatible. It causes newly added Node objects to begin life in
> > the ENROLL state, rather
Thanks for giving me a chance to vote. I don't have any experience talking
to production/live Ironic using a client and only talk to my own devstack.
Personally I vote for a *no* (for such a 1.12) the reasons that have been
cited in the previous threads that
1) we need users to be aware of API ve
On Mon, Jul 27, 2015 at 01:35:25PM -0700, Jim Rollenhagen wrote:
>
> Now we've landed a patch[0] with a new version (1.11) that is not
> backward compatible. It causes newly added Node objects to begin life in
> the ENROLL state, rather than AVAILABLE. This is a good thing, and
> people should wan
Hi,
> It sounds like we all agree -- the client we ship should default to a fixed,
> older version. Anyone who wants newer functionality can pass a newer version
> to their client.
>
> Here's the current state of things:
>
> server:
> - stable/kilo: 1.6
> - current: 1.11
>
> client:
> - stable/kil
It sounds like we all agree -- the client we ship should default to a
fixed, older version. Anyone who wants newer functionality can pass a newer
version to their client.
Here's the current state of things:
server:
- stable/kilo: 1.6
- current: 1.11
client:
- stable/kilo: 1.6
- latest release (0
On Fri, Jul 31, 2015 at 02:37:52PM -0700, Clint Byrum wrote:
> Excerpts from Sean Dague's message of 2015-07-31 04:14:54 -0700:
> > On 07/30/2015 04:58 PM, Devananda van der Veen wrote:
> >
> > > Thoughts?
> > >
> > > * I'm assuming it is possible to make micro version changes to the
> >
Excerpts from Sean Dague's message of 2015-07-31 04:14:54 -0700:
> On 07/30/2015 04:58 PM, Devananda van der Veen wrote:
>
> > Thoughts?
> >
> > * I'm assuming it is possible to make micro version changes to the
> > 1.x API
> > as 1.10.1, 1.10.2,etc
> >
> >
> > Despite most fo
2015-07-30 22:58 GMT+02:00 Devananda van der Veen :
>
> On Thu, Jul 30, 2015 at 10:21 AM Clint Byrum wrote:
>
>> Excerpts from Jim Rollenhagen's message of 2015-07-27 13:35:25 -0700:
>> > Hi friends.
>> >
>> > Ironic implemented API "micro" versions in Kilo. We originally did this
>> > to allow f
On 07/30/2015 04:58 PM, Devananda van der Veen wrote:
> Thoughts?
>
> * I'm assuming it is possible to make micro version changes to the
> 1.x API
> as 1.10.1, 1.10.2,etc
>
>
> Despite most folks calling this "microversions", I have been trying to
> simply call this "API versi
On Thu, Jul 30, 2015 at 10:21 AM Clint Byrum wrote:
> Excerpts from Jim Rollenhagen's message of 2015-07-27 13:35:25 -0700:
> > Hi friends.
> >
> > Ironic implemented API "micro" versions in Kilo. We originally did this
> > to allow for breaking changes in the API while allowing users to opt in
>
Excerpts from Jim Rollenhagen's message of 2015-07-27 13:35:25 -0700:
> Hi friends.
>
> Ironic implemented API "micro" versions in Kilo. We originally did this
> to allow for breaking changes in the API while allowing users to opt in
> to the breakage.
>
> Since then, we've had a "default version
On 07/30/2015 12:55 AM, Michael Davies wrote:
On Tue, Jul 28, 2015 at 6:05 AM, Jim Rollenhagen mailto:j...@jimrollenhagen.com>> wrote:
[snip]
It seems to me we have a few options here:
1) Default the python client and CLI to the earliest supported version.
This will never brea
On Tue, Jul 28, 2015 at 6:05 AM, Jim Rollenhagen
wrote:
> [snip]
>
> It seems to me we have a few options here:
>
> 1) Default the python client and CLI to the earliest supported version.
> This will never break users by default.
>
> 2) Default the python client and CLI to use the special version
After reading through this thread as a whole, I¹d like to summarise my
thoughts so far:
* I've noticed all these discussions revolve around existing people using
the API, and seem to ignore that most new users of the API don¹t care how
it used to work, and just want the full feature set without h
>> 1. yes
>> 2. no -- the client should default to the minimum supported version. We got
>> that wrong previously, and that's what is hurting us now.
>
> So if we do this, simply shipping the code doesn't break anyone. Nobody
> has disagreed on this yet, best I can tell.
>
We would still need a de
On 07/28/2015 10:51 PM, Devananda van der Veen wrote:
On Tue, Jul 28, 2015 at 1:01 AM Dmitry Tantsur mailto:dtant...@redhat.com>> wrote:
On 07/27/2015 10:41 PM, Sean Dague wrote:
> On 07/27/2015 04:35 PM, Jim Rollenhagen wrote:
>> Hi friends.
>>
>> Ironic implemented API
On Tue, Jul 28, 2015 at 09:55:03PM -0400, Julia Kreger wrote:
> > So if we do this, simply shipping the code doesn't break anyone. Nobody
> > has disagreed on this yet, best I can tell.
> >
> > So let's ship some code. :)
> >
> > // jim
> >
> >
> I'm not sure we can just ship some code, unless I've
On Tue, Jul 28, 2015 at 5:30 PM, Jim Rollenhagen
wrote:
> On Tue, Jul 28, 2015 at 09:19:46PM +, Devananda van der Veen wrote:
> > On Tue, Jul 28, 2015 at 1:57 PM Jim Rollenhagen
> > wrote:
> >
> > > On Tue, Jul 28, 2015 at 08:23:34PM +, Devananda van der Veen wrote:
> > > > On Mon, Jul 2
On Tue, Jul 28, 2015 at 09:19:46PM +, Devananda van der Veen wrote:
> On Tue, Jul 28, 2015 at 1:57 PM Jim Rollenhagen
> wrote:
>
> > On Tue, Jul 28, 2015 at 08:23:34PM +, Devananda van der Veen wrote:
> > > On Mon, Jul 27, 2015 at 4:58 PM Sean Dague wrote:
> > >
> > > > On 07/27/2015 07:
On Tue, Jul 28, 2015 at 08:05:49PM +, Devananda van der Veen wrote:
> I'm going to reply to several emails in this thread - but separately,
> because they're from separate people and with separate POV, and I think it
> will be even harder to discern what I'm saying if I merge the contexts
> bef
On Tue, Jul 28, 2015 at 1:57 PM Jim Rollenhagen
wrote:
> On Tue, Jul 28, 2015 at 08:23:34PM +, Devananda van der Veen wrote:
> > On Mon, Jul 27, 2015 at 4:58 PM Sean Dague wrote:
> >
> > > On 07/27/2015 07:10 PM, Jim Rollenhagen wrote:
> > > > On Mon, Jul 27, 2015 at 03:28:49PM -0700, Clint
On Tue, Jul 28, 2015 at 08:23:34PM +, Devananda van der Veen wrote:
> On Mon, Jul 27, 2015 at 4:58 PM Sean Dague wrote:
>
> > On 07/27/2015 07:10 PM, Jim Rollenhagen wrote:
> > > On Mon, Jul 27, 2015 at 03:28:49PM -0700, Clint Byrum wrote:
> > >> Excerpts from Sean Dague's message of 2015-07-
On Tue, Jul 28, 2015 at 1:01 AM Dmitry Tantsur wrote:
> On 07/27/2015 10:41 PM, Sean Dague wrote:
> > On 07/27/2015 04:35 PM, Jim Rollenhagen wrote:
> >> Hi friends.
> >>
> >> Ironic implemented API "micro" versions in Kilo. We originally did this
> >> to allow for breaking changes in the API whi
On Mon, Jul 27, 2015 at 4:58 PM Sean Dague wrote:
> On 07/27/2015 07:10 PM, Jim Rollenhagen wrote:
> > On Mon, Jul 27, 2015 at 03:28:49PM -0700, Clint Byrum wrote:
> >> Excerpts from Sean Dague's message of 2015-07-27 13:41:20 -0700:
> >>> So the CLI should actually break less often, and will exp
On Mon, Jul 27, 2015 at 1:41 PM Sean Dague wrote:
> Consider the CLI an auto negotiating microversion application of the
> python API client. And, realistically, should solve some of the issues
> of people running "nova foo" and getting cryptic errors from the server
> when they are hitting an ol
I'm going to reply to several emails in this thread - but separately,
because they're from separate people and with separate POV, and I think it
will be even harder to discern what I'm saying if I merge the contexts
before replying... so bear with me ...
On Mon, Jul 27, 2015 at 1:36 PM Jim Rollen
Hi,
> Could you combine 1 and 4?
>
> Deprecate not specifying the version, but pin to the oldest one for now?
> That way users get the warnings that they need to adapt, but things keep
> working? Could be switched to just 4 after a few months.
>
This is similar to what I would like to suggest. Bu
On 07/27/2015 10:41 PM, Sean Dague wrote:
On 07/27/2015 04:35 PM, Jim Rollenhagen wrote:
Hi friends.
Ironic implemented API "micro" versions in Kilo. We originally did this
to allow for breaking changes in the API while allowing users to opt in
to the breakage.
Since then, we've had a "default
Excerpts from Jim Rollenhagen's message of 2015-07-27 13:35:25 -0700:
> Hi friends.
>
> Ironic implemented API "micro" versions in Kilo. We originally did this
> to allow for breaking changes in the API while allowing users to opt in
> to the breakage.
>
> Since then, we've had a "default version
On 07/27/2015 07:10 PM, Jim Rollenhagen wrote:
> On Mon, Jul 27, 2015 at 03:28:49PM -0700, Clint Byrum wrote:
>> Excerpts from Sean Dague's message of 2015-07-27 13:41:20 -0700:
>>> So the CLI should actually break less often, and will expose the most
>>> functionality you can get out of your cloud
On Mon, Jul 27, 2015 at 03:28:49PM -0700, Clint Byrum wrote:
> Excerpts from Sean Dague's message of 2015-07-27 13:41:20 -0700:
> > So the CLI should actually break less often, and will expose the most
> > functionality you can get out of your cloud.
> >
>
> What I find odd about this is that I w
Excerpts from Sean Dague's message of 2015-07-27 13:41:20 -0700:
> On 07/27/2015 04:35 PM, Jim Rollenhagen wrote:
> > Hi friends.
> >
> > Ironic implemented API "micro" versions in Kilo. We originally did this
> > to allow for breaking changes in the API while allowing users to opt in
> > to the b
On 07/27/2015 04:35 PM, Jim Rollenhagen wrote:
> Hi friends.
>
> Ironic implemented API "micro" versions in Kilo. We originally did this
> to allow for breaking changes in the API while allowing users to opt in
> to the breakage.
>
> Since then, we've had a "default version" for our client that w
Hi friends.
Ironic implemented API "micro" versions in Kilo. We originally did this
to allow for breaking changes in the API while allowing users to opt in
to the breakage.
Since then, we've had a "default version" for our client that we bump to
something sensible with each release. Currently it
41 matches
Mail list logo
