[openstack-dev] [Ironic] When to bump the microversion?
soulxu at gmail.com
Sun Jun 7 02:45:10 UTC 2015
2015-06-05 5:35 GMT+08:00 Devananda van der Veen <devananda.vdv at gmail.com>:
> On Jun 4, 2015 11:11 AM, "Chris Friesen" <chris.friesen at windriver.com>
> > On 06/04/2015 10:14 AM, Devananda van der Veen wrote:
> >> On Jun 4, 2015 8:57 AM, "Monty Taylor" <mordred at inaugust.com
> >> > So, seriously - let's grow up and start telling people that they do
> >> > get to pick and choose user-visible feature sets. If they have an
> >> > 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
> >> deployment X and Y is a serious enough problem that it will have two
> >> - 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.
> > Chris
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev