Skip to content

Setting IAM policy causes deploy failure #222

Open

Description

@edaniszewski

I recently added support for IAM policies (#219), and it appears that using it is causing deploys to fail (#219 (comment))

After overwriting my local compileFunction.js in my node_modules (probably a dumb question, but since I don't use npm/node often -- is there an easier way to reference a branch/local copy other than just overwriting the file?) and running a deployment

service: test-api

provider:
  name: google
  stage: dev
  runtime: python37
  memorySize: 128
  region: us-central1
  project: [project id]
  credentials: ~/.gcloud/keyfile.json

plugins:
  - serverless-google-cloudfunctions

package
  excludeDevDependencies: true
  exclude:
    - node_modules/**
    - .gitignore
    - .git/**

functions:
  first:
    handler: http
    events:
      - http: path
    allowUnauthenticated: true

I got a similar error as to the one described in the PR comment

  Error: Deployment failed: RESOURCE_ERROR
  
       {"ResourceType":"gcp-types/cloudfunctions-v1:projects.locations.functions","ResourceErrorCode":"404","ResourceErrorMessage":{"statusMessage":"Not Found","requestPath":"https://cloudfunctions.googleapis.com/v1/:setIamPolicy","httpMethod":"POST"}}
      at throwErrorIfDeploymentFails (/Users/edaniszewski/dev/test-api/node_modules/serverless-google-cloudfunctions/shared/monitorDeployment.js:71:11)
      at /Users/edaniszewski/dev/test-api/node_modules/serverless-google-cloudfunctions/shared/monitorDeployment.js:42:17
      at processTicksAndRejections (internal/process/task_queues.js:89:5)
  From previous event:
      at PluginManager.invoke (/usr/local/lib/node_modules/serverless/lib/classes/PluginManager.js:489:22)
      at /usr/local/lib/node_modules/serverless/lib/classes/PluginManager.js:524:24
  From previous event:
      at PluginManager.run (/usr/local/lib/node_modules/serverless/lib/classes/PluginManager.js:524:8)
      at /usr/local/lib/node_modules/serverless/lib/Serverless.js:131:33
  From previous event:
      at Serverless.run (/usr/local/lib/node_modules/serverless/lib/Serverless.js:118:74)
      at /usr/local/lib/node_modules/serverless/bin/serverless.js:80:26
      at processImmediate (internal/timers.js:439:21)
      at process.topLevelDomainCallback (domain.js:126:23)
  From previous event:
      at Object.<anonymous> (/usr/local/lib/node_modules/serverless/bin/serverless.js:80:4)
      at Module._compile (internal/modules/cjs/loader.js:774:30)
      at Object.Module._extensions..js (internal/modules/cjs/loader.js:785:10)
      at Module.load (internal/modules/cjs/loader.js:641:32)
      at Function.Module._load (internal/modules/cjs/loader.js:556:12)
      at Function.Module.runMain (internal/modules/cjs/loader.js:837:10)
      at internal/main/run_main_module.js:17:11

The interesting bit to me: https://cloudfunctions.googleapis.com/v1/:setIamPolicy which didn't look right. Looking at the cloudfunctions API doc (https://cloud.google.com/functions/docs/reference/rest/v1/projects.locations.functions/setIamPolicy?hl=fa), the request should be:

POST https://cloudfunctions.googleapis.com/v1/{resource}:setIamPolicy

So, it appears that the resource identifier isn't being set in the API call.

I'll try to dig into this a bit more, but since I'm relatively new to the code base, any pointers on where I should look are appreciated (:

And also apologies for not catching this and fixing this while it was in a PR.

Activity

  1. medikoo commented on Jun 25, 2020

    @medikoo
    Contributor

    @edaniszewski thanks for looking into it. I'm not going to publish new version, once we sort this out. If it's time taking, then probably we need to revert this change for now

    (sorry for confusing comments, I deleted them. I thought it's someone else that reports the problem again :)

  2. edaniszewski commented on Jun 25, 2020

    @edaniszewski
    ContributorAuthor

    Based on the following, it seems like this is an issue w/ the cloud functions / deployment manager api

    I haven't yet read through the entire issue thread, but It looks like there are workarounds, so there seems to be a path forward for this.

  3. edaniszewski commented on Jun 29, 2020

    @edaniszewski
    ContributorAuthor

    As an update, I've cobbled together a minimal implementation for setting IAM policies which appears to work. I'll spend some time over the next day or two cleaning it up and will open a PR when ready.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions