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
