[question] Conan 2.7.0 is trying to ping /v1/ping endpoint that doesn't exist in Artifactory

[k-channon-PA]

What is your question?

Using:
OS: Centos Stream 8/9
Python: 3.8
Conan: 2.7.0
Artifactory: 7.55.18

I have created a Conan repository in Artifactory, using a "virtual" repo strategy. So, there is a "conan-local" repo that actually has packages in it and a "conan-remote" that is basically a mirror of conanceter and in front of these is another "virtual" repo that has the conan-local as the default deployment repo.

I can push packages to the repo and they duly appear in a structure like:

/conan/
   - .conan/
   - _
   - v1/
      - ping
   - v2/
      - conans/

All the packages are in /v2/conans.

However, when I try to install from this repo using conan install . --of some-build-dir, then I get a message that says:

ERROR: Remote https://my.company.artifactory/my-conan doesn't seem like a valid Conan remote. [Remote: my-conan]

Running with -vvv gives a call-stack and I can see that the error originates in: client/rest/rest_client_common.py, when it's trying to get the server capabilities.

The offending code looks like this:

def server_capabilities(self, user=None, password=None):
        """Get information about the server: status, version, type and capabilities"""
        url: str = self.router.ping()
        # logger.debug("REST: ping: %s" % url)
        if user and password:
            # This can happen in "conan remote login" cmd. Instead of empty token, use HttpBasic
            auth = HTTPBasicAuth(user, password)
        else:
            auth = self.auth
        ret = self.requester.get(url, auth=auth, headers=self.custom_headers, verify=self.verify_ssl)

        server_capabilities = ret.headers.get('X-Conan-Server-Capabilities')
        if not server_capabilities and not ret.ok:
            # Old Artifactory might return 401/403 without capabilities, we don't want
            # to cache them #5687, so raise the exception and force authentication
            raise get_exception_from_error(ret.status_code)(response_to_str(ret))
    

That self.router.ping() function is returning /v1/ping as the endpoint to hit, which doesn't seem to be an endpoint, hence the message. If I alter this code to just do a url = url.replace("v1", "v2"), then the whole thing hangs together.

Looking at the code for that ping function, then I see this thing:

def ping(self):
        # FIXME: The v2 ping is not returning capabilities
        return "{}/v1/".format(self.root_url) + self.routes.ping

here: https://github.com/conan-io/conan/blob/release/2.7/conans/client/rest/client_routes.py#L29
which looks a bit sus to me.

What am I doing wrong??

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @k-channon-PA

Thanks for your report.

Artifactory didn't remove the v1/ping endpoint, this endpoint is actually common for both API v1 and API v2 (it is not really related to Conan 2 either, the API v2 is also used in Conan 1 with revisions_enabled).

I think the issue is that you added the remote URL instead of the repo URL
Conan remotes URLs will be like:

http://<serverurl>/artifactory/api/conan/reponame

But the artifactori/api/conan is always there for Conan repos.
Please make sure you are copying the right URL in the server "SetMeUp" and let us know.

[k-channon-PA]

@memsharded , thanks for your reply!

Sorry for the misunderstanding. I hadn't understood that the version was for the API, not the Conan version.

I followed the "set me up" as you suggested (although the suggested login command does not seem to be correct for Conan 2 in the version of Artifactory we have (7.55.18), as the remote name is specified with a -r argument in the set me up, but it actually seems to be positional in Conan 2. Anyway, I removed the -r and it seemed happy).

Following this, there is a different issue when installing whereby it doesn't seem to be able to find the packages it's looking for. Running conan install -vvv gives a call stack where I can see it's raising an exception in rest_client_common.py here:

def get_json(self, url, data=None, headers=None):
        req_headers = self.custom_headers.copy()
        req_headers.update(headers or {})
        if data:  # POST request
            req_headers.update({'Content-type': 'application/json',
                                'Accept': 'application/json'})
            # logger.debug("REST: post: %s" % url)
            response = self.requester.post(url, auth=self.auth, headers=req_headers,
                                           verify=self.verify_ssl,
                                           stream=True,
                                           data=json.dumps(data))
        else:
            # logger.debug("REST: get: %s" % url)
            response = self.requester.get(url, auth=self.auth, headers=req_headers,
                                          verify=self.verify_ssl,
                                          stream=True)
            print(f"{url} returns {response}")      ### Added this debug output

        if response.status_code != 200:  # Error message is text
            response.charset = "utf-8"  # To be able to access ret.text (ret.content are bytes)
            raise get_exception_from_error(response.status_code)(response_to_str(response))  ######## Raised here

From the added debug output, I can see that it does:

spdlog/1.14.1: Not found in local cache, looking in remotes...
spdlog/1.14.1: Checking remote: my-conan-repo
https://my.company.artifactory/artifactory/api/conan/my-conan-repo/v2/conans/spdlog/1.14.1/_/_/latest returns <Response [200]>
https://my.company.artifactory/artifactory/api/conan/my-conan-repo/v2/conans/spdlog/1.14.1/_/_/revisions/972bbf70be1da4bc57ea589af0efde03/files returns <Response [404]>
spdlog/1.14.1: ERROR: Error downloading from remote 'my-conan-repo'

Looking at the repo in Artifactory, I can see that /v2/conans/spdlog/1.14.1/_/_/latest is there, but /v2/conans/spdlog/1.14.1/_/_/revisions/972bbf70be1da4bc57ea589af0efde03/files is not. The only thing that is there is v2/conans/spdlog/1.14.1/_/_/revisions, but this is not a directory, it's a file containing:

{
  "reference" : "spdlog/1.14.1@_/_",
  "revisions" : [ {
    "revision" : "972bbf70be1da4bc57ea589af0efde03",
    "time" : "2024-05-02T00:42:23.140+0000"
  } ]
}

Since this is a virtual repo, I also checked its default deploy repo and can see the package at https://my.company.artifactory/artifactory/my-conan-local-repo/_/spdlog/1.14.1/_/972bbf70be1da4bc57ea589af0efde03/package/da39a3ee5e6b4b0d3255bfef95601890afd80709/536fa07c5ff18232a266f2954c0dfb20/conan_package.tgz

but I don't know if this is correct/significant :(

[k-channon-PA]

Also, I think this is turning into more of an Artifactory user error issue than a Conan 2 issue... :|

[memsharded]

Also, I think this is turning into more of an Artifactory user error issue than a Conan 2 issue... :|

Yes, probably.

What happens if you add directly with conan remote add the local repo instead of the virtual one? Does it work correctly? If that is the case, you might want to file a support ticket for Artifactory.

[memsharded]

Any update here? Does it work using the local repo directly?

It is possible that the above is also normal behavior, the recipe exists, but it doesn't contain a valid pre-compiled binary for the current configuration (404), in general it is better to refer to the Conan command and the Conan output than to the http protocol to report issues.

[memsharded]

Did you manage to make it work? Any further question? Thanks for your feedback.

[k-channon-PA]

Sorry for the slow reply!

I'm afraid I was not able to get it to work. Strangely, I was able to push to the local repo (via the virtual repo, actually). However, I was never able to successfully pull from either the virtual repo, or the local one directly.

Due to the requirement to actually do the thing I was trying to do in a timely manner I had to work around the issue, so I haven't been able to investigate further.

[memsharded]

Ok, it would be nice to have more information to try to help better.
If you won't be able to investigate this, maybe we can close the issue in the meantime, you can always re-open or create a new ticket when you have time to investigate.

What I would do if I had to investigate this:

• Start with running a local instance, like an ArtifactoryCE you can download form our page, to rule out possible network or other configuration issues (like a proxy limiting access to some URLs)
• Starting with a local repo, upload, download, etc.
• Then a virtual repo, with only one local attached, upload, download
• Finally adding the extra remote repo

[k-channon-PA]

I'm sorry I can't put more time into investigating. Unfortunately, I do not own the infrastructure, so investigation time is dependent on not just me but a bunch of other people too. Such is life.

A piece of information that I didn't add in the original report was that I hacked the code in the client to insert "v2" where I noted that there was a "v1" that I was suspicious of. When I did this, it did actually work (i.e. I was able to pull the packages as expected).

I don't know why, given the information you previously provided, but there it is.

If you want to close the issue, then go for it. If I'm able to investigate further at some later date, I'll update then. Thanks for your time!

[memsharded]

I'm sorry I can't put more time into investigating. Unfortunately, I do not own the infrastructure, so investigation time is dependent on not just me but a bunch of other people too. Such is life.

No problem, I know how this things are. This is why I usually triage these things running things locally if I have the time, because that really helps to know where the issue lies and can save lots of time in the process.
But of course if you don't have time now, no problem, no rush from our side.

A piece of information that I didn't add in the original report was that I hacked the code in the client to insert "v2" where I noted that there was a "v1" that I was suspicious of. When I did this, it did actually work (i.e. I was able to pull the packages as expected).

I don't know exactly what you changed, but if the v1/ping is changed:

(conan2_310) λ conan list z* -r=art
URL get http://localhost:8081/artifactory/api/conan/conan/v2/ping {'auth': <conans.client.rest.rest_client_v2.JWTAuth object at 0x0000024C09F10190>,, 'verify': True}
art
  ERROR: 400

It doesn't work. If you changed the client code to v2/ping and it worked, the only possibility that I could think of would be some server side re-routing, redirect, proxy, or the like.

I think this is what we can do so far, so I am closing the issue, you can always re-open or create a new one when you have more information (we are trying to change a bit the policy for open tickets to try to reduce the large number of obsolete or outdated tickets there are). Thanks very much for your feedback!