[openstack-dev] [api] Open API 3.0 for OpenStack API

Jim Rollenhagen jim at jimrollenhagen.com
Wed Oct 10 12:58:55 UTC 2018

On Tue, Oct 9, 2018 at 10:25 PM Gilles Dubreuil <gdubreui at redhat.com> wrote:

> On 09/10/18 23:58, Jeremy Stanley wrote:
> > On 2018-10-09 08:52:52 -0400 (-0400), Jim Rollenhagen wrote:
> > [...]
> >> It seems to me that a major goal of openstacksdk is to hide differences
> >> between clouds from the user. If the user is meant to use a GraphQL
> library
> >> themselves, we lose this and the user needs to figure it out themselves.
> >> Did I understand that correctly?
> > This is especially useful where the SDK implements business logic
> > for common operations like "if the user requested A and the cloud
> > supports features B+C+D then use those to fulfil the request,
> > otherwise fall back to using features E+F".
> >
> The features offered to the user don't have to change, it's just a
> different architecture.
> The user doesn't have to deal with a GraphQL library, only the client
> applications (consuming OpenStack APIs).
> And there are also UI tools such as GraphiQL which allow to interact
> directly with GraphQL servers.

Right, this comes back to what I said earlier:

> That said, it seems like using this in a client like OpenStackSDK would
get messy quickly. Instead of asking for which versions are supported,
you'd have to fetch the schema, map it to actual features somehow, and
adjust queries based on this info.
> I guess there might be a middleground where we could fetch the REST API
version, and know from that what GraphQL queries can be made.

This isn't unsolvable, but it does sound like quite a bit of work. This
isn't to say "let's not do graphql at all", but it's important to
understand the work involved.

FWIW, I originally mentioned the SDK (as opposed to the clients speaking
graphql directly), as the client applications are currently transitioning
to use openstacksdk instead of their own API calls.

// jim

> __________________________________________________________________________
> 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/20181010/1c3a8b01/attachment.html>

More information about the OpenStack-dev mailing list