Uploaded image for project: 'Couchbase Server'
  1. Couchbase Server
  2. MB-37040

Importing saved Eventing Handlers via the CLI will no longer work (but the UI will)

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved
    • Critical
    • Resolution: Not a Bug
    • 6.5.0, Cheshire-Cat
    • None
    • eventing
    • Untriaged
    • Unknown

    Description

      Seems like fix for MB-32244 breaks existing exported configurations that do not have new "language_compatibility" field which is counter intuitive since this is a backward compatibility feature. 

      This issue will impact customers the rely on the CLI for eventing (cURL or couchbase-cli).

      Importing saved Eventing Handlers via the CLI will no longer work (but the UI will)

      curl -s -X POST -d @./verifier_01w_inst01.json -s http://${CB_USERNAME}:${CB_PASSWORD}@localhost:8096/api/v1/functions/verifier_01w_inst01
      {
       "name": "ERR_INVALID_CONFIG",
       "code": 38,
       "description": "Invalid configuration",
       "attributes": null,
       "runtime_info": {
        "code": 38,
        "info": "Language compatibility missing in the configuration"
       }
       
      couchbase-cli eventing-function-setup -c localhost -u $CB_USERNAME -p $CB_PASSWORD --import --name verifier_01w_inst01 --file verifier_01w_inst01.json2
      ERROR: {'code': 38, 'info': 'Language compatibility missing in the configuration'}
      

      Important we use 'verifier_01w_inst01.json' for curl and 'verifier_01w_inst01.json2' for couchbase-cli as the two CLI export-then-import modes do not seem to be cross compatible. But that is another issue for a future dat.

       The attached Eventing Handler/Function was created under 6.5 (source build a 11 days ago) it has been importing fine for several days.  However I know have the above error.  

      Note using the UI the imported function will get a 'tag' or new setting of 6.5.0 (under Settings/Language compatibility).  So it appears that this logic is in the UI not in shared code that underlies both the UI and the CLI.

      If we edit the exported files, e.g. 'verifier_01w_inst01.json' for curl and 'verifier_01w_inst01.json2', and add the missing directive we can indeed use both cURL and couchbase-cli to import the function.

      vi verifier_01w_inst01.json
      (ADD)
      "language_compatibility":"6.5.0",
      

      Now we can do one of the following:

      curl -s -X POST -d @./verifier_01w_inst01.json -s http://${CB_USERNAME}:${CB_PASSWORD}@localhost:8096/api/v1/functions/verifier_01w_inst01
      {
       "code": 0,
       "info": {
        "status": "Stored function: 'verifier_01w_inst01' in metakv",
        "warnings": null
       }
      }
      

      or

      couchbase-cli eventing-function-setup -c localhost -u $CB_USERNAME -p $CB_PASSWORD --import --name verifier_01w_inst01 --file verifier_01w_inst01.json.couchbase-cli.exported
      SUCCESS: Events imported
      

      Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

          Jon Strabala The mad-hatter RC1 candidate it build 4908 (not 4731 which is quite old). The changes for language-compatibility went into the product at build couchbase-server-6.5.0-4893. Could you please try build 4908 or later and share the issues you see?

          jeelan.poola Jeelan Poola added a comment - Jon Strabala The mad-hatter RC1 candidate it build 4908 (not 4731 which is quite old). The changes for language-compatibility went into the product at build couchbase-server-6.5.0-4893. Could you please try build 4908 or later and share the issues you see?

          Reopening based on Jon's comment above

          siri Sriram Melkote (Inactive) added a comment - Reopening based on Jon's comment above
          vikas.chaudhary Vikas Chaudhary added a comment - - edited

          Summary of the issue: 

          • Export any handler from UI and then import it using rest without language compatibility ==> version in UI= 6.5.0 
          • Export any handler from CLI and then import it with CLI without language compatibility ==> version in UI = 6.0.0 

          Clearly a bug

          vikas.chaudhary Vikas Chaudhary added a comment - - edited Summary of the issue:  Export any handler from UI and then import it using rest without language compatibility ==> version in UI= 6.5.0  Export any handler from CLI and then import it with CLI without language compatibility ==> version in UI = 6.0.0  Clearly a bug
          jon.strabala Jon Strabala added a comment -

          Clarification to "Summary of the issue": 

          • Export any handler from UI from a 6.0.X system via REST and then import it into a 6.5 system using REST without language compatibility ==> version in UI= 6.5.0 
          • Export any handler from a 6.0.X system via CLI and then import it into a 6.5 system with CLI without language compatibility ==> version in UI = 6.0.0 

          Clearly a bug 

          Comment: the UI and the CLI have identical formats, the REST API has a slightly different format that is not cross compatible (refer to MB-37042) you can not use the UI to export and REST to import.

          jon.strabala Jon Strabala added a comment - Clarification to "Summary of the issue":  Export any handler from UI   from a 6.0.X system via REST  and then import it into a 6.5 system using REST without language compatibility ==> version in UI= 6.5.0  Export any handler from a 6.0.X system via  CLI and then import it into a 6.5 system  with CLI without language compatibility ==> version in UI = 6.0.0  Clearly a bug  Comment: the UI and the CLI have identical formats, the REST API has a slightly different format that is not cross compatible (refer to MB-37042 ) you can not use the UI to export and REST to import.

          Jon Strabala,

          > Export any handler from UI from a 6.0.X system via REST and then import it into a 6.5 system using REST without language compatibility ==> version in UI= 6.5.0

          I see from the above comment where you describe the steps, at step 13 to import the handler, you make POST to http://${CB_USERNAME}:${CB_PASSWORD}@localhost:8096/api/v1/functions/verifier_01w_inst01
          Any post call to api/v1/function/<function_name> is treated as a create and creating an handler will stamp the language compatibility if missing to the latest language compatibility available. This is an expected behaviour.

          Import
          We have a dedicated endpoint to import - api/v1/import. POST to this endpoint, will be treated as an import, and if language compatibility is missing then the oldest compatible language compatibility is taken, which in our case is 6.0.0.

          CLI/UI import POST to api/v1/import, the behaviour of CLI/UI import is correct.

          Hence, resolving it as not a bug.

          Thanks

          suraj.naik Suraj Naik (Inactive) added a comment - Jon Strabala , > Export any handler from UI from a 6.0.X system via REST and then import it into a 6.5 system using REST without language compatibility ==> version in UI= 6.5.0 I see from the above comment where you describe the steps, at step 13 to import the handler, you make POST to http://$ {CB_USERNAME}:${CB_PASSWORD}@localhost:8096/api/v1/functions/verifier_01w_inst01 Any post call to api/v1/function/<function_name> is treated as a create and creating an handler will stamp the language compatibility if missing to the latest language compatibility available. This is an expected behaviour. Import We have a dedicated endpoint to import - api/v1/import. POST to this endpoint, will be treated as an import, and if language compatibility is missing then the oldest compatible language compatibility is taken, which in our case is 6.0.0. CLI/UI import POST to api/v1/import, the behaviour of CLI/UI import is correct. Hence, resolving it as not a bug. Thanks

          People

            jeelan.poola Jeelan Poola
            jon.strabala Jon Strabala
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes

                PagerDuty