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
