search

deis / steward

The Kubernetes-native Service Broker.
https://deis.com/
MIT License
154 stars 16 forks source link

Proposal: remove `catalog` from command mode #228

Closed slack closed 7 years ago

slack commented 8 years ago

One of the design goals for command mode was to provide an excruciatingly simple way for operators to create brokers. After building https://github.com/deis/steward-demo-postgres I think we can safely remove the catalog command invocation from the API.

Instead, steward would be launched with a configured set of service-id/plan-id pairs to publish to the ServiceCatalog. Removes a command to implement and doesn't encode ids in the broker image.

krancour commented 8 years ago

A few things here:

  1. This gets us closer to the proposal we gave to the sig, because therein, "ServiceClasses" are operator-defined.
  2. This being said, there was a little pushback on that in the SIG.
  3. Lastly, I'm not clear on why we'd remove this for just this one mode. Why not for CF mode as well? I'm not clear on why CF mode should query the broker's own catalog and publish but cmd shouldn't. Can you clarify?
arschles commented 8 years ago

@krancour regarding your third point, as I understand it, your proposal would render this issue obsolete because ServiceClass would replace all of the various options steward currently offers to get catalog entry names to publish to the catalog

krancour commented 8 years ago

@arschles that is true, but per the second point... I got the sense during SIG that operators manually defining ServiceClasses wasn't necessarily appealing.

slack commented 8 years ago

Curation doesn't mean that everything has to be hand edited, just that operators are going to make a conscious choice about what shows up in the catalog.

If you have a broker with catalog contents that you know and trust; then sure, you can reflect everything from the CF catalog untouched. Steward + CF should support filtering (whitelist, blacklist, mapping) of discovered catalog entries (comment in #213), which I'm happy to open a second issue for.

arschles commented 8 years ago

I got the sense during SIG that operators manually defining ServiceClasses wasn't necessarily appealing

got the same sense, but we should still start with creating ServiceClasses manually. that point leads me to my second comment....

If you have a broker with catalog contents that you know and trust; then sure, you can reflect everything from the CF catalog untouched

agree. @slack as you suggested, can you add a new issue for the filtering. I have some comments specific to how we'll do filtering that I'll save for there.

slack commented 8 years ago

CF mode filtering opened in https://github.com/deis/steward/issues/229

krancour commented 8 years ago

All points are well made. Curation != (100%) manual. Manual application of "filters" (whitelists, blacklists, etc.) can limit what service/plans offered by a Steward's underlying broker actually become available within the cluster...

But that inevitably leads me back to a question of how this proposal moves us forward. If we want to filter a backing broker's offerings, we must still have the capability to query the backing broker to learn what its offerings are.

Taking this issue in conjunction with #229, I don't see this so much as an imperative to remove catalog from command mode so much as an imperative to insert a new point of articulation into the mode-agnostic catalog publishing process.

slack commented 8 years ago

Back to the OP, the goal for CMD mode was to make it as simple as possible to build and deploy a broker. By removing /bin/broker catalog it is one fewer things to implement and simplifies the broker's relationship to the catalog.

CMD mode then becomes the easiest way to publish a single service:plan pair into the catalog.

arschles commented 7 years ago

Since we're removing command mode (see https://github.com/deis/steward/issues/239), this issue is obsolete. Closing.