Ceph » CephFS

I'm thinking to make use of ceph repo's raw content access of src/ceph_release i.e [0]. This is still a github API call and so there is rate limit associated with it but it is much more lenient when compared it to api.github.com calls. Check [1], [2]. So my plan is to write a lua script that:

1) fetches the release details from [0]
2) extracts the required info i.e. the version and version name.
3) use the version for initiating fs upgrades from N-1 -> main and N-2 -> main.

for this i'll be making use of lua-socket and lua-sec where i'd be sending a https request to the url to fetch the ceph_release file. i'm still learning about https.request{}, almost done. then i need to figure out how to extract the data and then store it in a variable which will be used to get N-1 and N-2 versions.

[0] https://raw.githubusercontent.com/ceph/ceph/main/src/ceph_release
[1] https://github.com/github/docs/issues/8031
[2] https://stackoverflow.com/questions/66522261/does-github-rate-limit-access-to-public-raw-files

Github docs for rate limits especially unauthenticated requests to the raw content API is non-existent, but since github's technical writer confirmed the existence of ~5000/hr [0] with their engineering team i think this is pretty generous number and shouldn't be an issue.

[0] https://github.com/github/docs/issues/8031

Dhairya Parmar wrote:

Github docs for rate limits especially unauthenticated requests to the raw content API is non-existent, but since github's technical writer confirmed the existence of ~5000/hr [0] with their engineering team i think this is pretty generous number and shouldn't be an issue.

[0] https://github.com/github/docs/issues/8031

The only thing that makes me worried is these rate limit values can change overtime and that could affect our test runs.

Is it a bad idea to maintain a release map somewhere in qa suite that can be referred by upgrade tests to select a start point for upgrades?

Venky Shankar wrote:

Dhairya Parmar wrote:

Github docs for rate limits especially unauthenticated requests to the raw content API is non-existent, but since github's technical writer confirmed the existence of ~5000/hr [0] with their engineering team i think this is pretty generous number and shouldn't be an issue.

[0] https://github.com/github/docs/issues/8031

The only thing that makes me worried is these rate limit values can change overtime and that could affect our test runs.

That would severely impact tons of open source projects if they do something like that. Highly unlikely. To be foolproof, I've have a kill-switch that would shift to deciding manually(the way it is done now).

Is it a bad idea to maintain a release map somewhere in qa suite that can be referred by upgrade tests to select a start point for upgrades?

kills the whole purpose - to automate in order to have least manual intervention at every new release.

im in strong favour of having this done, considering the caveat discussed above i still feel the risk:reward is significant. Since this is high prio, Do let me know if we're moving ahead with so that I can finalize the PR, I've already spent significant time researching on this and want to push a PR ASAP.

Dhairya Parmar wrote:

Venky Shankar wrote:

Dhairya Parmar wrote:

Github docs for rate limits especially unauthenticated requests to the raw content API is non-existent, but since github's technical writer confirmed the existence of ~5000/hr [0] with their engineering team i think this is pretty generous number and shouldn't be an issue.

[0] https://github.com/github/docs/issues/8031

The only thing that makes me worried is these rate limit values can change overtime and that could affect our test runs.

That would severely impact tons of open source projects if they do something like that. Highly unlikely. To be foolproof, I've have a kill-switch that would shift to deciding manually(the way it is done now).

Is it a bad idea to maintain a release map somewhere in qa suite that can be referred by upgrade tests to select a start point for upgrades?

kills the whole purpose - to automate in order to have least manual intervention at every new release.

It doesn't. It could be autogenerated and even if its manualy maintained, its a single point change per release - way better than current way of replacing everywhere...

Dhairya Parmar wrote:

im in strong favour of having this done, considering the caveat discussed above i still feel the risk:reward is significant. Since this is high prio, Do let me know if we're moving ahead with so that I can finalize the PR, I've already spent significant time researching on this and want to push a PR ASAP.

If we are going ahead with

1) fetches the release details from [0]
2) extracts the required info i.e. the version and version name.
3) use the version for initiating fs upgrades from N-1 -> main and N-2 -> main.

then I suggest to use Patrick's suggestion of maintaining a file in source tree with the supported releases.

Venky Shankar wrote:

Dhairya Parmar wrote:

im in strong favour of having this done, considering the caveat discussed above i still feel the risk:reward is significant. Since this is high prio, Do let me know if we're moving ahead with so that I can finalize the PR, I've already spent significant time researching on this and want to push a PR ASAP.

If we are going ahead with

1) fetches the release details from [0]
2) extracts the required info i.e. the version and version name.
3) use the version for initiating fs upgrades from N-1 -> main and N-2 -> main.

then I suggest to use Patrick's suggestion of maintaining a file in source tree with the supported releases.

we already have it https://github.com/ceph/ceph/blob/main/src/ceph_release, this contains the version, name of the branch and the state(dev/stable). Once the version is extracted, we can use it and get the N-1 and N-2 versions.

EDIT: Okay, i think by "supported releases", you wanted more than what the ceph_release offers but don't worry we do have a file for that too https://github.com/ceph/ceph/blob/main/doc/releases/releases.yml :D

Dhairya Parmar wrote:

Venky Shankar wrote:

Dhairya Parmar wrote:

im in strong favour of having this done, considering the caveat discussed above i still feel the risk:reward is significant. Since this is high prio, Do let me know if we're moving ahead with so that I can finalize the PR, I've already spent significant time researching on this and want to push a PR ASAP.

If we are going ahead with

1) fetches the release details from [0]
2) extracts the required info i.e. the version and version name.
3) use the version for initiating fs upgrades from N-1 -> main and N-2 -> main.

then I suggest to use Patrick's suggestion of maintaining a file in source tree with the supported releases.

we already have it https://github.com/ceph/ceph/blob/main/src/ceph_release, this contains the version, name of the branch and the state(dev/stable). Once the version is extracted, we can use it and get the N-1 and N-2 versions.

EDIT: Okay, i think by "supported releases", you wanted more than what the ceph_release offers but don't worry we do have a file for that too https://github.com/ceph/ceph/blob/main/doc/releases/releases.yml :D

That yml is missing the "current" branched out release (squid) since it's it's not released yet (dev/.1 releases). But, I'd imagine relying on something like this would be nice :)

We have https://github.com/ceph/ceph/blob/main/src/common/ceph_releases.h which I'm using to fetch the last two versions.

The script is

local https = require("ssl.https")
https.TIMEOUT = 10
local ltn12 = require("ltn12")

local url = "https://raw.githubusercontent.com/ceph/ceph/main/src/common/ceph_releases.h" 

local function fetchContent(url)
    local response = {}
    local _, code, _, status = https.request{
        url = url,
        sink = ltn12.sink.table(response)
    }

    if code == 200 then
        return table.concat(response)
    else
        return nil, "Error: " .. status
    end
end

local function fetchVersions()
    local content, err = fetchContent(url)
    if content then
        local enumContent = content:match("enum class ceph_release_t : std::uint8_t {([^}]-)};")
        local versions = {}
        for version in enumContent:gmatch("(%w+),") do
            table.insert(versions, version)
        end
        return versions
    else
        print(err)
        return nil
    end
end

local versions = fetchVersions()
if versions then
    print(versions[#versions - 1]) -- py_attrgetter().append()
    print(versions[#versions - 2]) -- py_attrgetter().append()
else
    print("Failed to fetch the latest Ceph versions.")
end

Dhairya Parmar wrote:

We have https://github.com/ceph/ceph/blob/main/src/common/ceph_releases.h which I'm using to fetch the last two versions.

The script is

[...]

I don't think you need to fetch this over http at all. You should modify teuthology to pass the $CEPH_GIT_TREE as a global variable to lua. Then lookup that file in the tree.

Patrick Donnelly wrote:

Dhairya Parmar wrote:

We have https://github.com/ceph/ceph/blob/main/src/common/ceph_releases.h which I'm using to fetch the last two versions.

The script is

[...]

I don't think you need to fetch this over http at all. You should modify teuthology to pass the $CEPH_GIT_TREE as a global variable to lua. Then lookup that file in the tree.

Interesting, this will get rid of the dependency on the github API. I'll check this out.

Dhairya Parmar wrote:

Patrick Donnelly wrote:

Dhairya Parmar wrote:

We have https://github.com/ceph/ceph/blob/main/src/common/ceph_releases.h which I'm using to fetch the last two versions.

The script is

[...]

I don't think you need to fetch this over http at all. You should modify teuthology to pass the $CEPH_GIT_TREE as a global variable to lua. Then lookup that file in the tree.

Interesting, this will get rid of the dependency on the github API. I'll check this out.

Based on discussion happened during standup today, I'll be pushing out a PR that uses http, since that is the change i can push really quick. With the approach patrick suggested, since I'm not quite well versed with the teuthology code, it will take more time to push a PR, once the PR (using http method) is up, we can discuss the approach and make changes accordingly, till then I'll continue working on the patrick's idea.