On 06/16/2015 09:51 AM, Dmitry Tantsur wrote:
> On 06/16/2015 08:56 AM, Dmitry Tantsur wrote:
>> To sum this long post up, I'm seeing that hiding new features based on
>> microversions brings much more problems, than it solves (I'm not aware
>> of the latter at all). I'm very opposed to continuing doing it in
>> Ironic, and I'm going to propose patch stopping gating Kilo changes
>> (non-breaking obviously).
>
> I'm talking about this patch: https://review.openstack.org/#/c/192196/
> We have to do it right now, as otherwise we can't test inspection in
> tempest (it does not seem to be microversion-aware).
Dmitry,
How do you solve for the following situation?
2 Clouds (A and B), both being Continuously Deployed.
Assume both clouds start at same revision of code. At point in time T a
new "compatable change" is added to the API. For instance, another field
returned by some resource.
Cloud B upgrades to that change.
Brand new developer shows up. Starts writing application against Cloud
B. Sees that change is available at version 1.4. Hard codes her
application to use this parameter.
Then she points her application at Cloud A. And it explodes.
I feel like in your concerns there has been an assumption that the
operation across all clouds effectively always goes forwards. But
because we're trying to encourage and create a multicloud ecosystem a
user application might experience the world the following way.
Cloud A -> Cloud A' -> Cloud A'' -> Cloud D -> Cloud B' -> Cloud C ->
Cloud C'.
While no individual cloud is likely to downgrade code (though we can't
fully rule that out), the fact that we'd like applications to work
against a wide range of deployments means effectively applications are
going to experience the world as if the code bases both upgrade and
downgrade over time.
Which means that a change is only "compatable" if the inverse of the
change is also "compatable". So a field add is only compatable if the
field delete is also considered compatible, because people are going to
experience that when they hop to another cloud.
Which is also why feature hiding is a thing. Because we don't control
when every cloud is going to upgrade, and what they'll upgrade to. So
the best idea so far about getting this right is that API 1.4 is
*exactly* a specific surface. Features added in 1.5 are not visibile if
you ask for 1.4. Because if they were, and you now wrote applications
that used that bleed through, when you jump to a cloud without 1.5 yet
deployed, all your application code breaks.
If we were only working on a single install of OpenStack in the world,
like EC2, github, meetup, or any other proprietary API service out
there, it would be a different story. We'd control time's arrow, and
never would have to worry about "going back in time". But we're not
working on that. We're working on software we hope will bloom 10,000+
clouds. At all scales. And the challenge to provide a consistent
programming experience for application writers that want to work against
any of those clouds means we needed to come up with some new models here.
If you have other solutions to the time's arrow issue, that would be
great to here. But it is the crux of why the model looks like it does.
-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
