looks like teuth machines dont have lua or lua modules im making use of

lupa.lua54.LuaError: [string "teuthology"]:1: attempt to call a nil value (global 'require')

or i suspect it isn't allowed, i see this commit where there is an allowist consisting of only few lua builtins

or i suspect it isn't allowed, i see this commit where there is an allowist consisting of only few lua builtins

yeah this is it, it is missing require function in the allowlist. Without its inclusion in the allowlist, this patch cannot move ahead

@dparmar18 What't the status of this? IMO, we should just hand edit the yaml for now and get that merged to start testing upgrades.

@dparmar18 What't the status of this? IMO, we should just hand edit the yaml for now and get that merged to start testing upgrades.

ive texted on slack for help, im trying to solve issues currently.

EDIT: highlighted my msg on slack just now. https://ceph-storage.slack.com/archives/C04LVQMHM9B/p1711011390319609

It's a lot of fun playing with the lua scripting and inventing new ways of injecting dynamic values.
However, taking a step back and looking at the task at hand, I have the following question: was it considered to encode an n-1 and n-2 branches with dedicated branch name syntax and then resolve them already as part of the install and install.upgrade python task itself? It could be as simple as

- install.upgrade:
    # upgrade the single cluster node, which is running all the mon/mds/osd/mgr daemons
    mon.a:
      branch: "@+1"

where @ would mean the tested branch and ±n would go up/down the release lineup. This would need to be supported as a syntax to install branch as well

UPD: maybe we could even avoid using @ and just use ±n to denote the relation to the current build, where the current build is the one installed, or if it's the install command, then the build of the test branch

It's a lot of fun playing with the lua scripting and inventing new ways of injecting dynamic values. However, taking a step back and looking at the task at hand, I have the following question: was it considered to encode an n-1 and n-2 branches with dedicated branch name syntax and then resolve them already as part of the install and install.upgrade python task itself? It could be as simple as

- install.upgrade:
    # upgrade the single cluster node, which is running all the mon/mds/osd/mgr daemons
    mon.a:
      branch: "@+1"

where @ would mean the tested branch and ±n would go up/down the release lineup. This would need to be supported as a syntax to install branch as well

UPD: maybe we could even avoid using @ and just use ±n to denote the relation to the current build, where the current build is the one installed, or if it's the install command, then the build of the test branch

So let me try to summarise this and I hope I understand it well - You're saying is we enable install and install.upgrade through teuthology code by using @ or ±n which would trigger some logic that fetches the latest ceph version and installs/upgrade automatically?

So let me try to summarise this and I hope I understand it well - You're saying is we enable install and install.upgrade through teuthology code by using @ or ±n which would trigger some logic that fetches the latest ceph version and installs/upgrade automatically?

That is correct!
I think it would be best to implement it on the teuthology side, but if for any reason we would not like that, there's also an option of creating our local cephfs wrapper task for both install and upgrade, that will only deal with the special branch names but after injecting the correct parameters will simply call the standard implementation by importing it from teuthology

This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days.
If you are a maintainer or core committer, please follow-up on this pull request to identify what steps should be taken by the author to move this proposed change forward.
If you are the author of this pull request, thank you for your proposed contribution. If you believe this change is still appropriate, please ensure that any feedback has been addressed and ask for a code review.

This pull request can no longer be automatically merged: a rebase is needed and changes have to be manually resolved

@dparmar18 - are you still planning to work on this? IIRC, we had stumbled upon couple of not-so-straightforward roadblocks related to automatic upgrades.

@dparmar18 - are you still planning to work on this? IIRC, we had stumbled upon couple of not-so-straightforward roadblocks related to automatic upgrades.

right, this one should be closed since we all agreed that the automation requires significant efforts for something like this that requires minor changes once or twice a year