Open Stack

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>
> wrote:
> >
> > 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
> 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-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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150607/3cdb4de4/attachment.html>