PROPOSAL: Summarize ServicePlan Free information

[MHBauer]

Summarize ServicePlan Free information

Abstract

Summary data of ServicePlan Free field, embedded into ServiceClass.

Motivation

Address underlying concern in #454. As a client we have to look at all of the ServicePlans to determine how many are free. We want to move this processing to the server.

Proposed Design

ServiceClass API Changes

Add a CountPlanFree status field. Not user settable.

// ServiceClass represents an offering in the service catalog.
type ServiceClass struct {
    ...

    // CountPlanFree
    CountPlanFree int

    ...
}

Controller-Manager Changes

On initial processing of a ServiceClass, while processing service plans, keep count.

On updating a ServiceClass, recalculate count.

On updating a ServicePlan, recalculate count.

Drawbacks

• Duplicates data from ServicePlan that can be calculated by the client.
• New field in ServiceClass

[pmorie]

I'm not sure about this one. It's easy for me to imagine this field showing inaccurate or unexpected values.

I do not believe that we have such mechanisms elsewhere in the API - maybe @spadgett can comment on that, as the OpenShift console consumes a lot of APIs and I believe currently has to do a lot of client-side counting.

[duglin]

For reference, this is what CF shows when a user wants to see the list of services available:

service                         plans                             description
AppConnect                      Lite, AppConnectPlanProfessional* Connect your applications, automate tasks, and improve productivity
AppID                           Graduated tier*                   Add authentication to your apps, and host user profile information so you can build engaging experiences.
Application Security on Cloud   free, standard*                   A robust, practical security vulnerability assessment for your web applications.
Auto-Scaling                    free                              Automatically increase or decrease the number of application instances based on a policy you define.
AvailabilityMonitoring          Lite, Paid*                       Around the world, around the clock availability and performance monitoring.
BigInsightsForApacheHadoop      Basic*                            Provision managed Apache Hadoop and Spark clusters within minutes.
BigInsightsonCloud              Enterprise*                       Provision managed bare metal Apache Hadoop clusters for production use or POCs at scale.

CF's "cf marketplace" command returns 3 bits of info for each service: name, list of plan names, a short description of the service. Each plan name has a "*" to indicate if its free or not.

What's nice about this is that the user, upon seeing that there is a free plan for a particular service available, doesn't need to do a 2nd call to the server to get the name of the plan - they can use it immediately. I think that's a pretty nice UX.

[duglin]

w.r.t. a service have old data, a long time ago we talked about creating specialized GETs (or was it just for "describe"?) that happened on the server side, is it possible to leverage that same feature to have a GET of a service query the plans such that it could augment the ServiceClass's metadata with the latest Plan info? Or even just create a specialized Get() method in storage.go - which Morgan has shown we can do.

[pmorie]

cc @fabianofranz

On Sat, Aug 12, 2017 at 9:25 PM Doug Davis notifications@github.com wrote:

For reference, this is what CF shows when a user wants to see the list of services available:

service plans description AppConnect Lite, AppConnectPlanProfessional Connect your applications, automate tasks, and improve productivity AppID Graduated tier Add authentication to your apps, and host user profile information so you can build engaging experiences. Application Security on Cloud free, standard A robust, practical security vulnerability assessment for your web applications. Auto-Scaling free Automatically increase or decrease the number of application instances based on a policy you define. AvailabilityMonitoring Lite, Paid Around the world, around the clock availability and performance monitoring. BigInsightsForApacheHadoop Basic Provision managed Apache Hadoop and Spark clusters within minutes. BigInsightsonCloud Enterprise Provision managed bare metal Apache Hadoop clusters for production use or POCs at scale.

CF's "cf marketplace" command returns 3 bits of info for each service: name, list of plan names, a short description of the service. Each plan name has a "*" to indicate if its free or not.

What's nice about this is that the user, upon seeing that there is a free plan for a particular service available, doesn't need to do a 2nd call to the server to get the name of the plan - they can use it immediately. I think that's a pretty nice UX.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/kubernetes-incubator/service-catalog/issues/1125#issuecomment-322015828, or mute the thread https://github.com/notifications/unsubscribe-auth/AAWXmAp2z4Q3juBU2di-lvckofLJqsaiks5sXlCegaJpZM4O1M5S .

[spadgett]

If plans are pulled out into a separate resource, I agree this could be a problem for UIs. I don't see a good way to filter on free/paid without getting all the plans and doing some work on the client.

I'm not sure the count is important, though. Just knowing if there's any free plan is probably as useful as knowing how many? (And a count doesn't satisfy @duglin's use case, which lists plan names.)

[MHBauer]

@duglin where's the code + APIs for that?

[duglin]

@MHBauer I don't know if there was code written for it - I just remember there being talks about doing it.

[duglin]

ping @pwittrock

[MHBauer]

@duglin I meant the cf code for the CLI output. Would like to see what they use. Is it a custom API for the User or a usage of existing APIs and aggregation on the client side.

[duglin]

not sure where the CF code is, but when I do a cf marketplace the REST call is:

GET /v2/spaces/be715851-daed-4483-97a3-632ce6f2dded/services

which pulls back a list of resources like this:

    {
      "metadata": {
        "guid": "bed0b74d-6d3e-47b4-ade5-b1407a5b1795",
        "url": "/v2/services/bed0b74d-6d3e-47b4-ade5-b1407a5b1795",
        "created_at": "2014-04-15T20:58:58Z",
        "updated_at": "2017-08-02T10:11:42Z"
      },
      "entity": {
        "label": ".....",
        "provider": null,
        "url": null,
        "description": "Performance Testing Platform",
        "long_description": null,
        "version": null,
        "info_url": null,
        "active": true,
        "bindable": false,
        "unique_id": "45c4ae61-ae64-11e3-8e2c-00259086a7bc",
        "extra": "{\"taxCode\":\"C1\",\"displayName\":\"BlazeMeter\",\"imageUrl\ ...
        "requires": [

        ],
        "documentation_url": null,
        "service_broker_guid": "aae1e9c7-1fbb-4c72-9576-92cd12f8c60d",
        "plan_updateable": false,
        "service_plans_url": "/v2/services/bed0b74d-6d3e-47b4-ade5-b1407a5b1795/
      }
    },

Which is interesting. Notice that it doesn't show the plans directly, it has service_plans_url.

Looking at the remaining REST calls I then see it hit each service plan:

GET /v2/service_plans?q=service_guid%3Abed0b74d-6d3e-47b4-ade5-b1407a5b1795 HTTP/1.1

response - a list of things like:

      "metadata": {
        "guid": "eef13a3b-37a4-4008-886f-d9ff0ac35285",
        "url": "/v2/service_plans/eef13a3b-37a4-4008-886f-d9ff0ac35285",
        "created_at": "2014-04-15T20:58:59Z",
        "updated_at": "2017-08-02T10:11:42Z"
      },
      "entity": {
        "name": "free-tier",
        "free": true,
        "description": "Free",
        "service_guid": "bed0b74d-6d3e-47b4-ade5-b1407a5b1795",
        "extra": "{\"displayName\":\"Free\",\"bullets\":[\"Up to 50 concurrent u...
        "unique_id": "fd227fc2-ad9c-4db9-a55d-a61bbf2f5d5f",
        "public": true,
        "bindable": false,
        "active": true,
        "service_url": "/v2/services/bed0b74d-6d3e-47b4-ade5-b1407a5b1795",
        "service_instances_url": "/v2/service_plans/eef13a3b-37a4-4008-886f-d9ff
      } 

So, from a REST perspective splitting the plans from the services (and providing an easy way to pull back just the plans for the services we care about) would put us on-par with CF. If we think that's good enough.

However, that's just from a REST perspective. CF's main UX (the cmd line) shows it all in one cmd. Now, we could do a kubectl plugin to get the same net result - would just need to decide if it returned json or human readable output (or even two plugins).

[MHBauer]

If we think that's good enough.

I think it is good enough. Optimize later. https://github.com/kubernetes-incubator/service-catalog/issues/454#issuecomment-321100107

If not, this is a separate proposal from the other proposal. We can write up alternatives for the optimization later.

[MHBauer]

closing as we went with #454 split.