Support updating a service instance

[FlorianSW]

CloudFoundry allows one to update a service with the update-service command. This supports both, chaning the configuration of a service (if the service needs/requires/provides a way to configure it through the service configuration of CF) and also change the plan of the service.

As this is especially required when we want to change the configuration of a service without needing to delete and recreate it with the new configuration through this resource, I want to propose to support this command in cf-cli-resource, too :)

[aegershman]

Thinking outloud-- would it make sense to have updating be a part of the "create" command so that it's idempotent? Or should it be an entirely separate command? I'd imagine it would be better as a part of "create" so that you could update an instance which is already created without it having to be a separate pipeline job?

[FlorianSW]

I thought about this, too. My concern is: Is it guaranteed that each service can handle an update command? If not, we shouldn't run update-service on any create-service ci command. However, if it is guaranteed then I would also prefer to have it combined with create-service :)

[patrickcrocker]

Back in issue #38 I did make a similar change for cups, which makes sense for that scenario (because there is no service broker/backing "service" to interact with.)

@FlorianSW to your point i'm not comfortable doing an automatic update-service as part of a create-service command if the service already exists.

So, two potential solutions would be:

1. Introduce a update-service command
2. Create a boolean update flag (default to false) on the create-service command that would run the update-service command if the service already exists.

One or both solutions could be implemented to give the pipeline author more flexibility.

Thoughts?

[aegershman]

My team's use-case seems to best fit option 2 of having a flag which allows "create" to update an instance if it's already created. That would make pipelining simpler because allows for a single job as an idempotent operation for creating & maintaining a service instance + it's longer-term config management

I'll chat with my coworkers next week and see if they have opinions + use cases. Perhaps having an independent update-service command makes more sense that I am seeing. definitely interested in hearing @FlorianSW 's thoughts on it.

[FlorianSW]

I totally agree with @patrickcrocker.

Currently, we've used a separate task step to update a service, which would correspond to the separate Update-Service command. What I could think about (however, we're not doing that atm) is, that one would probably want to use Update-Service in the pipeline only, while creating the service instance needs to be done manually (as it requires user interaction at some point or so, like AWS SES where the requester needs to verify their e-mail address). In this case, having a combined create service with update included would not suffer.

On the other hand, I totally agree with @aegershman that having a update flag has it's charmey tooy as it reduces the pipeline size.

So, TL;Dr: if we could implement only one, I would vote for the separate Update-Service command, but having both ways sound like it would cover (potentially) all use cases :)

[patrickcrocker]

OK, I think step one is to TDD the update-service command and then take a look at the update flag on the create-service command next.

Can I get some examples/use cases for how a service would be created and then updated? What configuration values would change? Looking for concrete examples.

[FlorianSW]

Agreed on that! :)

This would be an example use case (which changes the actual configuration of a specific service, leaving it with the same plan):

cf create-service auth basic-auth auth-service -c '{"Username": "A_USERNAME", "Password": "A_PASSWORD"}'
cf update-service auth-service -c '{"Username": "A_USERNAME", "Password": ANOTHER_PASSWORD"}'

However, one would probably also want to update the plan and the configuration (moving, e.g., from the basic-auth plan to whatever authentication plan is supported by the auth service, let's say, oauth).

[patrickcrocker]

@FlorianSW @aegershman (and anyone else that cares)

Poll (vote True or False):

When including an update_service flag for the create-service command, should the update_service flag default to true or false?

[FlorianSW]

definitely false

[aegershman]

Agreed, defaulting to false makes sense && I think follows the principal of least surprise. Having the service instance be updated if it already exists should be an explicit option. Makes sense semantically, too, since a create operation is simply not the same as update-ing it if it already exists. (Now, if this command were called crupdate-service, it would make sense to default to true 😉)

[patrickcrocker]

Updated in v2.10.0!