Re: [openstack-dev] [Ironic] When to bump the microversion?
2015-06-04 23:27 GMT+08:00 Lucas Alvares Gomes lucasago...@gmail.com:
Hi Ruby,
Thanks for starting this thread, just like you I've been always
confused about when and when not bump the microversioning of the API.
Backwards compatible API adds with no user signaling is a fallacy
because it assumes the arrow of time flows only one way.
If at version 1.5 you have a resource that is
foo {
bar: ...
}
And then you decide you want to add another attribute
foo {
bar: ...
baz: ...
}
And you don't bump the version, you'll get a set of users that use a
cloud with baz, and incorrectly assume that version 1.5 of the API means
that baz will always be there. Except, there are lots of clouds out
there, including ones that might be at the code commit before it was
added. Because there are lots of deploys in the world, your users can
effectively go back in time.
So now your API definition for version 1.5 is:
foo, may or may not contain baz, and there is no way of you knowing if
it will until you try. good luck.
Which is pretty aweful.
Oh, that's a good point, I can see the value on that.
Perhaps the guide should define bumping the micro version something
along these words: Whenever a change is made to the API which is
visible to the client the micro version should be incremented ?
Yes, I should put some words about why we should bump for back-compatible
changes.
This is powerful because gives the clients a fine grained way to
detect what are the API features available.
Cheers,
Lucas
__
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] [Ironic] When to bump the microversion?
2015-06-05 5:35 GMT+08:00 Devananda van der Veen devananda@gmail.com: On Jun 4, 2015 11:11 AM, Chris Friesen chris.frie...@windriver.com wrote: On 06/04/2015 10:14 AM, Devananda van der Veen wrote: On Jun 4, 2015 8:57 AM, Monty Taylor mord...@inaugust.com So, seriously - let's grow up and start telling people that they do not get to pick and choose user-visible feature sets. If they have an unholy obsession with a particular backend technology that does not allow a public feature of the API to work, then they are deploying a broken cloud and they need to fix it. So I just had dinner last night with a very large user of OpenStack (yes, they exist) whose single biggest request is that we stop differentiating in the API. To them, any difference in the usability / behavior / API between OpenStack deployment X and Y is a serious enough problem that it will have two effects: - vendor lock in - they stop using OpenStack And since avoiding single vendor lock in is important to them, well, really it has only one result. Tl;Dr; Monty is right. We MUST NOT vary the API or behaviour significantly or non-discoverably between clouds. Or we simply won't have users. If a vendor wants to differentiate themselves, what about having two sets of API endpoints? One that is full vanilla openstack with bog-standard behaviour, and one that has vendor-specific stuff in it? That way the end-users that want interop can just use the standard API and get common behaviour across clouds, while the end-users that want the special sauce and are willing to lock in to a vendor to get it can use the vendor-specific API. You've just described what ironic has already done with the /vendor_passthu/ end point. However, the issue, more broadly, is just discovery of differences in the API which make one cloud behave differently than another. Sometimes those aren't related to vendor-specific features at all. Eg, changes which are the result of config settings, or where a fix or feature gets back ported (because sometimes someone thinks that's easier than a full upgrade). These things exist today, but create a terrible experience for users who want to move a workload between OpenStack clouds, and find that the APIs don't behave quite the same, even for basic functionality. Can I think about the API Discovery and Drivers/Backup Capabilities Discovery are two things? Microversion is for API Discovery. But as in Nova, it isn't all the driver implement all the functionality. -D Chris __ 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] [Ironic] When to bump the microversion?
On 06/04/2015 05:27 PM, Lucas Alvares Gomes wrote:
Hi Ruby,
Thanks for starting this thread, just like you I've been always
confused about when and when not bump the microversioning of the API.
Backwards compatible API adds with no user signaling is a fallacy
because it assumes the arrow of time flows only one way.
If at version 1.5 you have a resource that is
foo {
bar: ...
}
And then you decide you want to add another attribute
foo {
bar: ...
baz: ...
}
And you don't bump the version, you'll get a set of users that use a
cloud with baz, and incorrectly assume that version 1.5 of the API means
that baz will always be there. Except, there are lots of clouds out
there, including ones that might be at the code commit before it was
added. Because there are lots of deploys in the world, your users can
effectively go back in time.
So now your API definition for version 1.5 is:
foo, may or may not contain baz, and there is no way of you knowing if
it will until you try. good luck.
Which is pretty aweful.
Oh, that's a good point, I can see the value on that.
Perhaps the guide should define bumping the micro version something
along these words: Whenever a change is made to the API which is
visible to the client the micro version should be incremented ?
Ok, one more last thought on this topic: definition of visible change
can go the wrong way even faster. E.g. remember that our JSON fields
(instance_info, driver_info and even driver_internal_info) are part of
API. Which means that we have feature-gate drivers :) and feature like
cleaning as well (which we actually did via configuration option,
despite everything said in this thread).
This is powerful because gives the clients a fine grained way to
detect what are the API features available.
Cheers,
Lucas
__
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] [Ironic] When to bump the microversion?
On Jun 4, 2015 11:11 AM, Chris Friesen chris.frie...@windriver.com wrote: On 06/04/2015 10:14 AM, Devananda van der Veen wrote: On Jun 4, 2015 8:57 AM, Monty Taylor mord...@inaugust.com So, seriously - let's grow up and start telling people that they do not get to pick and choose user-visible feature sets. If they have an unholy obsession with a particular backend technology that does not allow a public feature of the API to work, then they are deploying a broken cloud and they need to fix it. So I just had dinner last night with a very large user of OpenStack (yes, they exist) whose single biggest request is that we stop differentiating in the API. To them, any difference in the usability / behavior / API between OpenStack deployment X and Y is a serious enough problem that it will have two effects: - vendor lock in - they stop using OpenStack And since avoiding single vendor lock in is important to them, well, really it has only one result. Tl;Dr; Monty is right. We MUST NOT vary the API or behaviour significantly or non-discoverably between clouds. Or we simply won't have users. If a vendor wants to differentiate themselves, what about having two sets of API endpoints? One that is full vanilla openstack with bog-standard behaviour, and one that has vendor-specific stuff in it? That way the end-users that want interop can just use the standard API and get common behaviour across clouds, while the end-users that want the special sauce and are willing to lock in to a vendor to get it can use the vendor-specific API. You've just described what ironic has already done with the /vendor_passthu/ end point. However, the issue, more broadly, is just discovery of differences in the API which make one cloud behave differently than another. Sometimes those aren't related to vendor-specific features at all. Eg, changes which are the result of config settings, or where a fix or feature gets back ported (because sometimes someone thinks that's easier than a full upgrade). These things exist today, but create a terrible experience for users who want to move a workload between OpenStack clouds, and find that the APIs don't behave quite the same, even for basic functionality. -D Chris __ 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] [Ironic] When to bump the microversion?
On 06/04/2015 10:14 AM, Devananda van der Veen wrote: On Jun 4, 2015 8:57 AM, Monty Taylor mord...@inaugust.com So, seriously - let's grow up and start telling people that they do not get to pick and choose user-visible feature sets. If they have an unholy obsession with a particular backend technology that does not allow a public feature of the API to work, then they are deploying a broken cloud and they need to fix it. So I just had dinner last night with a very large user of OpenStack (yes, they exist) whose single biggest request is that we stop differentiating in the API. To them, any difference in the usability / behavior / API between OpenStack deployment X and Y is a serious enough problem that it will have two effects: - vendor lock in - they stop using OpenStack And since avoiding single vendor lock in is important to them, well, really it has only one result. Tl;Dr; Monty is right. We MUST NOT vary the API or behaviour significantly or non-discoverably between clouds. Or we simply won't have users. If a vendor wants to differentiate themselves, what about having two sets of API endpoints? One that is full vanilla openstack with bog-standard behaviour, and one that has vendor-specific stuff in it? That way the end-users that want interop can just use the standard API and get common behaviour across clouds, while the end-users that want the special sauce and are willing to lock in to a vendor to get it can use the vendor-specific API. Chris __ 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] [Ironic] When to bump the microversion?
On 06/04/2015 11:27 AM, Dmitry Tantsur wrote:
On 06/04/2015 05:03 PM, Sean Dague wrote:
On 06/04/2015 10:50 AM, Dmitry Tantsur wrote:
On 06/04/2015 04:40 PM, Ruby Loo wrote:
Hi,
In Kilo, we introduced microversions but it seems to be a
work-in-progress. There is an effort now to add microversion into the
API-WG's guidelines, to provide a consistent way of using microversions
across OpenStack projects [1]. Specifically, in the context of this
email, there is a proposed guideline for when to bump the microversion
[2].
As I understand this guideline tells to bump microversion on every
change which I strongly -1 as usual. Reason: it's bump for the sake of
bump, without any direct benefit for users (no, API discoverability is
not one, because microversion do not solve it).
I'll post the same comment to the guideline.
Backwards compatible API adds with no user signaling is a fallacy
because it assumes the arrow of time flows only one way.
If at version 1.5 you have a resource that is
foo {
bar: ...
}
And then you decide you want to add another attribute
foo {
bar: ...
baz: ...
}
And you don't bump the version, you'll get a set of users that use a
cloud with baz, and incorrectly assume that version 1.5 of the API means
that baz will always be there. Except, there are lots of clouds out
there, including ones that might be at the code commit before it was
added. Because there are lots of deploys in the world, your users can
effectively go back in time.
So now your API definition for version 1.5 is:
foo, may or may not contain baz, and there is no way of you knowing if
it will until you try. good luck.
Which is pretty aweful.
Which is not very different from your definition. Version 1.5 contains
feature xyz, unless it's disabled by the configuration or patched out
downstream. Well, 1.4 can also contain the feature, if downstream
backported it. So good luck again.
The whole point of interop is you can't call it OpenStack if you are
patching it downstream to break the upstream contract. Microversions are
a contract.
Downstream can hack code all they want, it's no longer OpenStack when
they do. If they are ok with it, that's fine. But them taking OpenStack
code and making something that's not OpenStack is beyond the scope of
the problem here. This is about good actors, acting in good faith, to
provide a consistent experience to application writers.
-Sean
--
Sean Dague
http://dague.net
__
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] [Ironic] When to bump the microversion?
On 06/04/2015 11:27 AM, Dmitry Tantsur wrote:
On 06/04/2015 05:03 PM, Sean Dague wrote:
On 06/04/2015 10:50 AM, Dmitry Tantsur wrote:
On 06/04/2015 04:40 PM, Ruby Loo wrote:
Hi,
In Kilo, we introduced microversions but it seems to be a
work-in-progress. There is an effort now to add microversion into the
API-WG's guidelines, to provide a consistent way of using microversions
across OpenStack projects [1]. Specifically, in the context of this
email, there is a proposed guideline for when to bump the microversion
[2].
As I understand this guideline tells to bump microversion on every
change which I strongly -1 as usual. Reason: it's bump for the sake of
bump, without any direct benefit for users (no, API discoverability is
not one, because microversion do not solve it).
I'll post the same comment to the guideline.
Backwards compatible API adds with no user signaling is a fallacy
because it assumes the arrow of time flows only one way.
If at version 1.5 you have a resource that is
foo {
bar: ...
}
And then you decide you want to add another attribute
foo {
bar: ...
baz: ...
}
And you don't bump the version, you'll get a set of users that use a
cloud with baz, and incorrectly assume that version 1.5 of the API means
that baz will always be there. Except, there are lots of clouds out
there, including ones that might be at the code commit before it was
added. Because there are lots of deploys in the world, your users can
effectively go back in time.
So now your API definition for version 1.5 is:
foo, may or may not contain baz, and there is no way of you knowing if
it will until you try. good luck.
Which is pretty aweful.
Which is not very different from your definition. Version 1.5 contains
feature xyz, unless it's disabled by the configuration or patched out
downstream. Well, 1.4 can also contain the feature, if downstream
backported it. So good luck again.
If you allow to group features under one microversion, that becomes even
worse - you can have deployment that got microversion only partially.
For example, that's what I would call API discoverability:
$ ironic has-capability foobar
true
and that's how it would play with versioning:
$ ironic --ironic-api-version 1.2 has-capability foobar
false
$ ironic --ironic-api-version 1.6 has-capability foobar
true
On the contrary, the only thing that microversion tells me is that the
server installation is based on a particular upstream commit.
To me these are orthogonal problems, and I believe they should be solved
differently. Our disagreement is due to seeing them as one problem.
We should stop doing this everywhere in OpenStack. It is the absolute
worst experience ever.
Stop allowing people to disable features with config. there is literally
no user on the face of the planet for whom this is a positive thing.
1.5 should mean that your server has Set(A) of features. 1.6 should mean
Set(A+B) - etc. There should be NO VARIATION and any variation on that
should basically mean that the cloud in question is undeniably broken.
I understand that vendors and operators keep wanting to wank around with
their own narccisitic arrogance to differentiate from one another.
STOP IT
Seriously, it causes me GIANT amount of pain and quite honestly if I
wasn't tied to using OpenStack because I work on it, I would have given
up on it a long time ago because of evil stuff like this.
So, seriously - let's grow up and start telling people that they do not
get to pick and choose user-visible feature sets. If they have an unholy
obsession with a particular backend technology that does not allow a
public feature of the API to work, then they are deploying a broken
cloud and they need to fix it.
Looking at your comments in the WG repo you also seem to only be
considering projects shipped at Major release versions (Kilo, Liberty).
Which might be true of Red Hat's product policy, but it's not generally
true that all clouds are at a release boundary. Continous Deployment of
OpenStack has been a value from Day 1, and many public clouds are not
using releases, but are using arbitrary points off of master.
I don't know why you decided I don't know it, but you're wrong.
A
microversion describes when a changes happens so that applications
writers have a very firm contract about what they are talking to.
No, they don't. Too many things can modify behavior - see above.
-Sean
__
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
Re: [openstack-dev] [Ironic] When to bump the microversion?
On 06/04/2015 05:43 PM, Sean Dague wrote:
On 06/04/2015 11:27 AM, Dmitry Tantsur wrote:
On 06/04/2015 05:03 PM, Sean Dague wrote:
On 06/04/2015 10:50 AM, Dmitry Tantsur wrote:
On 06/04/2015 04:40 PM, Ruby Loo wrote:
Hi,
In Kilo, we introduced microversions but it seems to be a
work-in-progress. There is an effort now to add microversion into the
API-WG's guidelines, to provide a consistent way of using microversions
across OpenStack projects [1]. Specifically, in the context of this
email, there is a proposed guideline for when to bump the microversion
[2].
As I understand this guideline tells to bump microversion on every
change which I strongly -1 as usual. Reason: it's bump for the sake of
bump, without any direct benefit for users (no, API discoverability is
not one, because microversion do not solve it).
I'll post the same comment to the guideline.
Backwards compatible API adds with no user signaling is a fallacy
because it assumes the arrow of time flows only one way.
If at version 1.5 you have a resource that is
foo {
bar: ...
}
And then you decide you want to add another attribute
foo {
bar: ...
baz: ...
}
And you don't bump the version, you'll get a set of users that use a
cloud with baz, and incorrectly assume that version 1.5 of the API means
that baz will always be there. Except, there are lots of clouds out
there, including ones that might be at the code commit before it was
added. Because there are lots of deploys in the world, your users can
effectively go back in time.
So now your API definition for version 1.5 is:
foo, may or may not contain baz, and there is no way of you knowing if
it will until you try. good luck.
Which is pretty aweful.
Which is not very different from your definition. Version 1.5 contains
feature xyz, unless it's disabled by the configuration or patched out
downstream. Well, 1.4 can also contain the feature, if downstream
backported it. So good luck again.
The whole point of interop is you can't call it OpenStack if you are
patching it downstream to break the upstream contract. Microversions are
a contract.
Downstream can hack code all they want, it's no longer OpenStack when
they do. If they are ok with it, that's fine. But them taking OpenStack
code and making something that's not OpenStack is beyond the scope of
the problem here. This is about good actors, acting in good faith, to
provide a consistent experience to application writers.
I disagree with all said above, but putting aside discussion about ideal
vs real world, my point actually boils down to:
if you want feature discovery (or as you call it - contract), make it
explicit. Create API for it. Here you're upset with users guessing
features - and you invent one more way to guess them. Probably working
in ideal world, but still a guessing game. And pretty inconvenient to
use (to test, to document), I would say.
And within Ironic community (including people deploying from master),
I'm still waiting to hear requests for such feature at all, but that's
another question.
-Sean
__
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] [Ironic] When to bump the microversion?
On Jun 4, 2015 8:57 AM, Monty Taylor mord...@inaugust.com wrote:
On 06/04/2015 11:27 AM, Dmitry Tantsur wrote:
On 06/04/2015 05:03 PM, Sean Dague wrote:
On 06/04/2015 10:50 AM, Dmitry Tantsur wrote:
On 06/04/2015 04:40 PM, Ruby Loo wrote:
Hi,
In Kilo, we introduced microversions but it seems to be a
work-in-progress. There is an effort now to add microversion into the
API-WG's guidelines, to provide a consistent way of using
microversions
across OpenStack projects [1]. Specifically, in the context of this
email, there is a proposed guideline for when to bump the
microversion
[2].
As I understand this guideline tells to bump microversion on every
change which I strongly -1 as usual. Reason: it's bump for the sake of
bump, without any direct benefit for users (no, API discoverability is
not one, because microversion do not solve it).
I'll post the same comment to the guideline.
Backwards compatible API adds with no user signaling is a fallacy
because it assumes the arrow of time flows only one way.
If at version 1.5 you have a resource that is
foo {
bar: ...
}
And then you decide you want to add another attribute
foo {
bar: ...
baz: ...
}
And you don't bump the version, you'll get a set of users that use a
cloud with baz, and incorrectly assume that version 1.5 of the API
means
that baz will always be there. Except, there are lots of clouds out
there, including ones that might be at the code commit before it was
added. Because there are lots of deploys in the world, your users can
effectively go back in time.
So now your API definition for version 1.5 is:
foo, may or may not contain baz, and there is no way of you knowing if
it will until you try. good luck.
Which is pretty aweful.
Which is not very different from your definition. Version 1.5 contains
feature xyz, unless it's disabled by the configuration or patched out
downstream. Well, 1.4 can also contain the feature, if downstream
backported it. So good luck again.
If you allow to group features under one microversion, that becomes even
worse - you can have deployment that got microversion only partially.
For example, that's what I would call API discoverability:
$ ironic has-capability foobar
true
and that's how it would play with versioning:
$ ironic --ironic-api-version 1.2 has-capability foobar
false
$ ironic --ironic-api-version 1.6 has-capability foobar
true
On the contrary, the only thing that microversion tells me is that the
server installation is based on a particular upstream commit.
To me these are orthogonal problems, and I believe they should be solved
differently. Our disagreement is due to seeing them as one problem.
We should stop doing this everywhere in OpenStack. It is the absolute
worst experience ever.
Stop allowing people to disable features with config. there is literally
no user on the face of the planet for whom this is a positive thing.
1.5 should mean that your server has Set(A) of features. 1.6 should mean
Set(A+B) - etc. There should be NO VARIATION and any variation on that
should basically mean that the cloud in question is undeniably broken.
I understand that vendors and operators keep wanting to wank around with
their own narccisitic arrogance to differentiate from one another.
STOP IT
Seriously, it causes me GIANT amount of pain and quite honestly if I
wasn't tied to using OpenStack because I work on it, I would have given
up on it a long time ago because of evil stuff like this.
So, seriously - let's grow up and start telling people that they do not
get to pick and choose user-visible feature sets. If they have an unholy
obsession with a particular backend technology that does not allow a
public feature of the API to work, then they are deploying a broken
cloud and they need to fix it.
So I just had dinner last night with a very large user of OpenStack (yes,
they exist) whose single biggest request is that we stop differentiating
in the API. To them, any difference in the usability / behavior / API
between OpenStack deployment X and Y is a serious enough problem that it
will have two effects:
- vendor lock in
- they stop using OpenStack
And since avoiding single vendor lock in is important to them, well, really
it has only one result.
Tl;Dr; Monty is right. We MUST NOT vary the API or behaviour significantly
or non-discoverably between clouds. Or we simply won't have users.
Looking at your comments in the WG repo you also seem to only be
considering projects shipped at Major release versions (Kilo, Liberty).
Which might be true of Red Hat's product policy, but it's not generally
true that all clouds are at a release boundary. Continous Deployment of
OpenStack has been a value from Day 1, and many public clouds are not
using releases, but are using arbitrary points off of master.
I don't know why you decided I
Re: [openstack-dev] [Ironic] When to bump the microversion?
So we should have told the folks to so developing agent? (Not sure why you
all think I'm talking about us) Maybe.
But anyway anyone deliberately ignores my points, so I'm done with this
discussion.
04 июня 2015 г. 18:17 пользователь Devananda van der Veen
devananda@gmail.com написал:
On Jun 4, 2015 8:57 AM, Monty Taylor mord...@inaugust.com wrote:
On 06/04/2015 11:27 AM, Dmitry Tantsur wrote:
On 06/04/2015 05:03 PM, Sean Dague wrote:
On 06/04/2015 10:50 AM, Dmitry Tantsur wrote:
On 06/04/2015 04:40 PM, Ruby Loo wrote:
Hi,
In Kilo, we introduced microversions but it seems to be a
work-in-progress. There is an effort now to add microversion into
the
API-WG's guidelines, to provide a consistent way of using
microversions
across OpenStack projects [1]. Specifically, in the context of this
email, there is a proposed guideline for when to bump the
microversion
[2].
As I understand this guideline tells to bump microversion on every
change which I strongly -1 as usual. Reason: it's bump for the sake
of
bump, without any direct benefit for users (no, API discoverability
is
not one, because microversion do not solve it).
I'll post the same comment to the guideline.
Backwards compatible API adds with no user signaling is a fallacy
because it assumes the arrow of time flows only one way.
If at version 1.5 you have a resource that is
foo {
bar: ...
}
And then you decide you want to add another attribute
foo {
bar: ...
baz: ...
}
And you don't bump the version, you'll get a set of users that use a
cloud with baz, and incorrectly assume that version 1.5 of the API
means
that baz will always be there. Except, there are lots of clouds out
there, including ones that might be at the code commit before it was
added. Because there are lots of deploys in the world, your users can
effectively go back in time.
So now your API definition for version 1.5 is:
foo, may or may not contain baz, and there is no way of you knowing
if
it will until you try. good luck.
Which is pretty aweful.
Which is not very different from your definition. Version 1.5 contains
feature xyz, unless it's disabled by the configuration or patched out
downstream. Well, 1.4 can also contain the feature, if downstream
backported it. So good luck again.
If you allow to group features under one microversion, that becomes
even
worse - you can have deployment that got microversion only partially.
For example, that's what I would call API discoverability:
$ ironic has-capability foobar
true
and that's how it would play with versioning:
$ ironic --ironic-api-version 1.2 has-capability foobar
false
$ ironic --ironic-api-version 1.6 has-capability foobar
true
On the contrary, the only thing that microversion tells me is that the
server installation is based on a particular upstream commit.
To me these are orthogonal problems, and I believe they should be
solved
differently. Our disagreement is due to seeing them as one problem.
We should stop doing this everywhere in OpenStack. It is the absolute
worst experience ever.
Stop allowing people to disable features with config. there is literally
no user on the face of the planet for whom this is a positive thing.
1.5 should mean that your server has Set(A) of features. 1.6 should mean
Set(A+B) - etc. There should be NO VARIATION and any variation on that
should basically mean that the cloud in question is undeniably broken.
I understand that vendors and operators keep wanting to wank around with
their own narccisitic arrogance to differentiate from one another.
STOP IT
Seriously, it causes me GIANT amount of pain and quite honestly if I
wasn't tied to using OpenStack because I work on it, I would have given
up on it a long time ago because of evil stuff like this.
So, seriously - let's grow up and start telling people that they do not
get to pick and choose user-visible feature sets. If they have an unholy
obsession with a particular backend technology that does not allow a
public feature of the API to work, then they are deploying a broken
cloud and they need to fix it.
So I just had dinner last night with a very large user of OpenStack (yes,
they exist) whose single biggest request is that we stop differentiating
in the API. To them, any difference in the usability / behavior / API
between OpenStack deployment X and Y is a serious enough problem that it
will have two effects:
- vendor lock in
- they stop using OpenStack
And since avoiding single vendor lock in is important to them, well,
really it has only one result.
Tl;Dr; Monty is right. We MUST NOT vary the API or behaviour significantly
or non-discoverably between clouds. Or we simply won't have users.
Looking at your comments in the WG repo
[openstack-dev] [Ironic] When to bump the microversion?
Hi, In Kilo, we introduced microversions but it seems to be a work-in-progress. There is an effort now to add microversion into the API-WG's guidelines, to provide a consistent way of using microversions across OpenStack projects [1]. Specifically, in the context of this email, there is a proposed guideline for when to bump the microversion [2]. Last week, in an IRC discussion [3], Devananda suggested that we bump the microversion in these situations: ' required for any non-backwards-compatible change, and strongly encouraged for any significant features ? (and yes, that's subjective) '. What do people think of that? I think it is clear that we should do it for any non-backwards-compatible change. The subjective part worries me a bit -- who decides, the feature submitter or the cores or ? Alternatively, if people aren't too worried or care that much, we can decide to follow the guideline [3] (and limp along until that guideline is finalized). --ruby [1] http://lists.openstack.org/pipermail/openstack-dev/2015-June/065793.html [2] https://review.openstack.org/#/c/187896/ [3] around 2015-05-26T16:29:05, http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2015-05-26.log __ 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] [Ironic] When to bump the microversion?
On 06/04/2015 04:40 PM, Ruby Loo wrote: Hi, In Kilo, we introduced microversions but it seems to be a work-in-progress. There is an effort now to add microversion into the API-WG's guidelines, to provide a consistent way of using microversions across OpenStack projects [1]. Specifically, in the context of this email, there is a proposed guideline for when to bump the microversion [2]. As I understand this guideline tells to bump microversion on every change which I strongly -1 as usual. Reason: it's bump for the sake of bump, without any direct benefit for users (no, API discoverability is not one, because microversion do not solve it). I'll post the same comment to the guideline. Last week, in an IRC discussion [3], Devananda suggested that we bump the microversion in these situations: ' required for any non-backwards-compatible change, and strongly encouraged for any significant features ? (and yes, that's subjective) '. What do people think of that? I think it is clear that we should do it for any non-backwards-compatible change. The subjective part worries me a bit -- who decides, the feature submitter or the cores or ? My vote is: if we can proof that a sane user will be broken by the change, we bump the microversion. Alternatively, if people aren't too worried or care that much, we can decide to follow the guideline [3] (and limp along until that guideline is finalized). --ruby [1] http://lists.openstack.org/pipermail/openstack-dev/2015-June/065793.html [2] https://review.openstack.org/#/c/187896/ [3] around 2015-05-26T16:29:05, http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2015-05-26.log __ 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] [Ironic] When to bump the microversion?
On 06/04/2015 05:03 PM, Sean Dague wrote:
On 06/04/2015 10:50 AM, Dmitry Tantsur wrote:
On 06/04/2015 04:40 PM, Ruby Loo wrote:
Hi,
In Kilo, we introduced microversions but it seems to be a
work-in-progress. There is an effort now to add microversion into the
API-WG's guidelines, to provide a consistent way of using microversions
across OpenStack projects [1]. Specifically, in the context of this
email, there is a proposed guideline for when to bump the microversion
[2].
As I understand this guideline tells to bump microversion on every
change which I strongly -1 as usual. Reason: it's bump for the sake of
bump, without any direct benefit for users (no, API discoverability is
not one, because microversion do not solve it).
I'll post the same comment to the guideline.
Backwards compatible API adds with no user signaling is a fallacy
because it assumes the arrow of time flows only one way.
If at version 1.5 you have a resource that is
foo {
bar: ...
}
And then you decide you want to add another attribute
foo {
bar: ...
baz: ...
}
And you don't bump the version, you'll get a set of users that use a
cloud with baz, and incorrectly assume that version 1.5 of the API means
that baz will always be there. Except, there are lots of clouds out
there, including ones that might be at the code commit before it was
added. Because there are lots of deploys in the world, your users can
effectively go back in time.
So now your API definition for version 1.5 is:
foo, may or may not contain baz, and there is no way of you knowing if
it will until you try. good luck.
Which is pretty aweful.
Which is not very different from your definition. Version 1.5 contains
feature xyz, unless it's disabled by the configuration or patched out
downstream. Well, 1.4 can also contain the feature, if downstream
backported it. So good luck again.
If you allow to group features under one microversion, that becomes even
worse - you can have deployment that got microversion only partially.
For example, that's what I would call API discoverability:
$ ironic has-capability foobar
true
and that's how it would play with versioning:
$ ironic --ironic-api-version 1.2 has-capability foobar
false
$ ironic --ironic-api-version 1.6 has-capability foobar
true
On the contrary, the only thing that microversion tells me is that the
server installation is based on a particular upstream commit.
To me these are orthogonal problems, and I believe they should be solved
differently. Our disagreement is due to seeing them as one problem.
Looking at your comments in the WG repo you also seem to only be
considering projects shipped at Major release versions (Kilo, Liberty).
Which might be true of Red Hat's product policy, but it's not generally
true that all clouds are at a release boundary. Continous Deployment of
OpenStack has been a value from Day 1, and many public clouds are not
using releases, but are using arbitrary points off of master.
I don't know why you decided I don't know it, but you're wrong.
A
microversion describes when a changes happens so that applications
writers have a very firm contract about what they are talking to.
No, they don't. Too many things can modify behavior - see above.
-Sean
__
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] [Ironic] When to bump the microversion?
Hi Ruby,
Thanks for starting this thread, just like you I've been always
confused about when and when not bump the microversioning of the API.
Backwards compatible API adds with no user signaling is a fallacy
because it assumes the arrow of time flows only one way.
If at version 1.5 you have a resource that is
foo {
bar: ...
}
And then you decide you want to add another attribute
foo {
bar: ...
baz: ...
}
And you don't bump the version, you'll get a set of users that use a
cloud with baz, and incorrectly assume that version 1.5 of the API means
that baz will always be there. Except, there are lots of clouds out
there, including ones that might be at the code commit before it was
added. Because there are lots of deploys in the world, your users can
effectively go back in time.
So now your API definition for version 1.5 is:
foo, may or may not contain baz, and there is no way of you knowing if
it will until you try. good luck.
Which is pretty aweful.
Oh, that's a good point, I can see the value on that.
Perhaps the guide should define bumping the micro version something
along these words: Whenever a change is made to the API which is
visible to the client the micro version should be incremented ?
This is powerful because gives the clients a fine grained way to
detect what are the API features available.
Cheers,
Lucas
__
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] [Ironic] When to bump the microversion?
On 06/04/2015 10:50 AM, Dmitry Tantsur wrote:
On 06/04/2015 04:40 PM, Ruby Loo wrote:
Hi,
In Kilo, we introduced microversions but it seems to be a
work-in-progress. There is an effort now to add microversion into the
API-WG's guidelines, to provide a consistent way of using microversions
across OpenStack projects [1]. Specifically, in the context of this
email, there is a proposed guideline for when to bump the microversion
[2].
As I understand this guideline tells to bump microversion on every
change which I strongly -1 as usual. Reason: it's bump for the sake of
bump, without any direct benefit for users (no, API discoverability is
not one, because microversion do not solve it).
I'll post the same comment to the guideline.
Backwards compatible API adds with no user signaling is a fallacy
because it assumes the arrow of time flows only one way.
If at version 1.5 you have a resource that is
foo {
bar: ...
}
And then you decide you want to add another attribute
foo {
bar: ...
baz: ...
}
And you don't bump the version, you'll get a set of users that use a
cloud with baz, and incorrectly assume that version 1.5 of the API means
that baz will always be there. Except, there are lots of clouds out
there, including ones that might be at the code commit before it was
added. Because there are lots of deploys in the world, your users can
effectively go back in time.
So now your API definition for version 1.5 is:
foo, may or may not contain baz, and there is no way of you knowing if
it will until you try. good luck.
Which is pretty aweful.
Looking at your comments in the WG repo you also seem to only be
considering projects shipped at Major release versions (Kilo, Liberty).
Which might be true of Red Hat's product policy, but it's not generally
true that all clouds are at a release boundary. Continous Deployment of
OpenStack has been a value from Day 1, and many public clouds are not
using releases, but are using arbitrary points off of master. A
microversion describes when a changes happens so that applications
writers have a very firm contract about what they are talking to.
-Sean
--
Sean Dague
http://dague.net
__
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
