How to update a cloudFunction

[jeandanielJouanneaud]

Describe your question

Hello,

We have deployed an https triggered cloudFunction using configConnector. The source is a gcs zip file.

for example : gs://myBucket/myFunction_0_1_0.zip

We have created another cloudFunction version (myFunction_0_2_0.zip)

We cannot update the field sourceArchiveUrl to gs://myBucket/myFunction_0_2_0.zip since the field is immutable. We cannot delete and recreate the resource since our CICD uses diff and apply.

However it works with the gcloud function deploy command.

Is there anything we can do to update the cloudFunction with config connector ? Thank you.

[jcanseco]

We cannot delete and recreate the resource since our CICD uses diff and apply.

Can you elaborate what you mean by this?

At a quick glance, I would say that recreating the function is how you would go about updating a function in Config Connector since the sourceArchiveUrl field is immutable, but perhaps I may be missing something.

[jeandanielJouanneaud]

Hello,

Our jenkins checks for modification (kubectl diff), and then use kubectl apply

Our CloudFunctions are HTTPs trigger event based (there are called by pubsub subscriptions). So we have created a pubsub subscription (with config connector). The endpoint of the subscription is https://europe-west1-[PROJECT_ID].cloudfunctions.net/[CLOUD_FUNCTION_NAME]

As you can see, the endpoint is fixed by the cloudFunction name.

So that's mean that if we want to modify our cloudFunction code and make a new release, we will need to :

• make a new release of our cloudFunction (say v2.0)
• delete the configconnector PubsubSubscription calling the cloudFunction v1.0 => we will lose a lot of messages...
• delete the configConnector CloudFunctionsFunction (v1.0)
• add the new configConnector CloudFunctionsFunction (v2.0)
• add the new configConnector PubsubSubscription (with the new endpoint v2.0)

The only solution i can see to avoid losing pubsub messages, is to first delete the cloudFunction, and then recreate it.

But it seems to not be possible in one shot, since the field sourceArchiveUrl is immutable and our CICD checks for modification and apply them if any. It can only be possible in two times. (one PR to delete the function, and one to recreate it with the correct sourceArchiveUrl).

It is unfortunate that configConnector doesn't allow CloudFunction updates unlike gcloud function deploy command. However, I understand that sourceArchiveUrl immutability is used as a safeguard

[jcanseco]

Gotcha, I get you now.

I asked the Cloud Functions team if there is a way to do in-place updates using the REST API (since that is just what Config Connector uses to manage Cloud Functions).

Let us wait for their response. For now though, you are right that having to delete-then-recreate is unfortunate, but is probably the best bet here.

[jcanseco]

It seems the API actually supports this via the PATCH method.

Let us take some time to investigate supporting in-place updates in Config Connector then. We likely won't get to it for a while though unfortunately due to limited capacity, so you'll have to rely on delete-then-recreate for now. We'll let you know once we have updates.

[vgelot]

Hi, Is there any news about updating the cloud function by config connector (without deleting and recreating the cloud function)? By changing the sourceRepository.url or the sourceArchiveUrl we have the immutable error. By changing the content of the function in the source repository (or the content of the zip in the bucket) and changing a mutable field like description, configconnector still uses the previous content (the release number increase in cloud function). Thanks

[diviner524]

@vgelot We got confirmation from cloud functions team it is possible to support in-place updates. We have created an internal ticket to track the feature request.

In the mean time, if this issue is a blocker or time-sensitive in your project, please also consider submitting a corresponding issue with GCP support. This will help us to better prioritize our backlog and hopefully get to the issue sooner.

[jonapgar-groupby]

Is there any movement on this? It's been two years since the internal ticket was created.

Without this, how would I possibly update a cloudfunction without missing recreating it entirely and thus missing the events that it is listening to?

I could simply create new functions for every release (or whenever the source archive content changes), but would this not miss events as the previous function is removed and the new one is created.