Uploaded image for project: 'LAB Portal'
  1. LAB Portal
  2. FP-89

Cloud portal appending '/v1' to swift endpoint

        Details

        • Type: Bug
        • Status: Closed
        • Priority: Major
        • Resolution: Fixed
        • Component/s: None
        • Labels:
          None

          Description

          The cloud portal is appending '/v1' to swift endpoint every time a request is made - list, create, etc. This results in "Invalid bucket name" error and the operation is not completed.

          Radosgw log file:
          SCRIPT_URI=http://zurich.cloud.lab.fiware.org:8080/swift/v1/v1/

          while the correct endpoint in Keystone is:
          http://zurich.cloud.lab.fiware.org:8080/swift/v1

          The same operation succeeds using the command-line.

            Activity

            Ascending order - Click to sort in descending order
            Hide
            Permalink
            fla Fernando Lopez added a comment - - edited

            Dear Bruno,

            Previously to talk with Álvaro, I was checking the value of the service endpoint related to swift and Zürich2 (keep in main Zürich2 and not Zürich), the data that I obtain is the following:

                      {
            "adminURL": "http://zurich.cloud.lab.fiware.org:8080/swift/v1",
            "region": "Zurich2",
            "internalURL": "http://zurich.cloud.lab.fiware.org:8080/swift/v1",
            "id": "36cd08b3cb59468492fc61022e7296ef",
            "publicURL": "http://zurich.cloud.lab.fiware.org:8080/swift/v1"
          },

            The first thing that surprised me was that the publicURL does not contain information about the account information, when I try to create a container, the cloud portal send a put operation to:

            PUT https://cloud.lab.fiware.org/Zurich2/object-store/swift/v1/tbd-container

            If I make the same operation in Spain node, the operation is:

            PUT https://cloud.lab.fiware.org/Spain2/object-store/v1/AUTH_00000000000000000000000000000104/tbd-container

            Although the content of the service endpoint is the following:

                      {
            "adminURL": "http://172.32.0.144:8080",
            "region": "Spain2",
            "internalURL": "http://172.32.0.144:8080/v1/AUTH_00000000000003228460960090160000",
            "id": "083337d26f7d46d8ab1426c8d6f5831c",
            "publicURL": "http://130.206.112.3:8080/v1/AUTH_00000000000003228460960090160000"
          }
            Show
            fla Fernando Lopez added a comment - - edited Dear Bruno, Previously to talk with Álvaro, I was checking the value of the service endpoint related to swift and Zürich2 (keep in main Zürich2 and not Zürich), the data that I obtain is the following: { "adminURL" : "http: //zurich.cloud.lab.fiware.org:8080/swift/v1" , "region" : "Zurich2" , "internalURL" : "http: //zurich.cloud.lab.fiware.org:8080/swift/v1" , "id" : "36cd08b3cb59468492fc61022e7296ef" , "publicURL" : "http: //zurich.cloud.lab.fiware.org:8080/swift/v1" }, The first thing that surprised me was that the publicURL does not contain information about the account information, when I try to create a container, the cloud portal send a put operation to: PUT https://cloud.lab.fiware.org/Zurich2/object-store/swift/v1/tbd-container If I make the same operation in Spain node, the operation is: PUT https://cloud.lab.fiware.org/Spain2/object-store/v1/AUTH_00000000000000000000000000000104/tbd-container Although the content of the service endpoint is the following: { "adminURL" : "http: //172.32.0.144:8080" , "region" : "Spain2" , "internalURL" : "http: //172.32.0.144:8080/v1/AUTH_00000000000003228460960090160000" , "id" : "083337d26f7d46d8ab1426c8d6f5831c" , "publicURL" : "http: //130.206.112.3:8080/v1/AUTH_00000000000003228460960090160000" }
            Hide
            Permalink
            ZHAW Node Helpdesk Zurich Node Helpdesk added a comment -

            Hi Fernando,

            That's correct, Ceph was used as swift backend in this region and for that reason the endpoint is different. Ceph takes the information of an account from its token which is sent as a header in the request.

            I'm not sure how this PUT request is translated in Keystone but I thought it would point directly to our endpoint.
            Do you think this could be an issue related to keystone and not the cloud portal itself?

            BR,
            Bruno

            Show
            ZHAW Node Helpdesk Zurich Node Helpdesk added a comment - Hi Fernando, That's correct, Ceph was used as swift backend in this region and for that reason the endpoint is different. Ceph takes the information of an account from its token which is sent as a header in the request. I'm not sure how this PUT request is translated in Keystone but I thought it would point directly to our endpoint. Do you think this could be an issue related to keystone and not the cloud portal itself? BR, Bruno
            Hide
            Permalink
            fla Fernando Lopez added a comment -

            Dear Bruno,

            I think that it was resolved yet by email, correct?

            Show
            fla Fernando Lopez added a comment - Dear Bruno, I think that it was resolved yet by email, correct?
            Hide
            Permalink
            ZHAW Node Helpdesk Zurich Node Helpdesk added a comment -

            Hi Fernando,

            This issue is solved now. You can close this ticket.

            BR,
            Bruno.

            Show
            ZHAW Node Helpdesk Zurich Node Helpdesk added a comment - Hi Fernando, This issue is solved now. You can close this ticket. BR, Bruno.

              People

              • Assignee:
                fla Fernando Lopez
                Reporter:
                ZHAW Node Helpdesk Zurich Node Helpdesk
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: