Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

document automigration caveats and "host!" option #809

Closed
hjoliver opened this issue Feb 26, 2025 · 6 comments
Closed

document automigration caveats and "host!" option #809

hjoliver opened this issue Feb 26, 2025 · 6 comments
Assignees

Comments

@hjoliver
Copy link
Member

From cylc/cylc-flow#6623 (comment) -

The idea was to condemn the host first (i.e. ask workflows to migrate nicely), then mop up any stragglers with the "force" mode.

OK that's fine. Leave the decision on when to force it up to the humans.

We should document that though, as some will assume the options are migrate-all or kill-all, and not think of migrate-if-possible before changing the global config again to kill the rest.

We should also document the circumstances under which workflows will not successfully auto-migrate.

@hjoliver hjoliver added this to the 8.4.x milestone Feb 26, 2025
@hjoliver hjoliver changed the title document automigration caveats and force-condemn document automigration caveats and "host!" option Feb 26, 2025
@hjoliver
Copy link
Member Author

Note as per the linked issue, we should not call hostname! "force condemned" - the host is condemned regardless; the option just implies we should shut its workflows down rather than attempt to migrate them.

@oliver-sanders
Copy link
Member

Note as per the linked issue, we should not call hostname! "force condemned" - the host is condemned regardless; the option just implies we should shut its workflows down rather than attempt to migrate them.

@hjoliver Suggest an alternative, or I'll stick with force.

@hjoliver
Copy link
Member Author

hjoliver commented Feb 27, 2025

I did suggest an alternative - on the linked issue where we were discussing it. Summary:

"Force condemn" doesn't make sense, and simply replacing the word "force" with something else isn't going to help much. That being the case we need to rethink how to describe the relevant concepts - which isn't difficult.

"Condemned" means "sentenced to some future, typically negative, fate". A condemned host is going to be shut down (or whatever) soon, so we need we need to get the workflows off it. Such a host is condemned from the moment it is declared to be condemned, with no need for "forcing". It doesn't just become condemned later on, once the workflows have gone.


The concepts we need to document are simply:

Condemned hosts have been sentenced to death (figuratively speaking) so:

  • new workflows will not be started on them
  • existing workflows need to be stopped (with !) or migrated (without !) off them

The two options for what to do with workflows on a condemned host already have perfectly good names: migrate and stop.

I can't see any problem with simply documenting this as stated.

(There's no actual config item called "force condemn" that we have to think of a name for.)

@oliver-sanders
Copy link
Member

Not particularly interested in the debate, just need a name you're happy with.

migrate and stop.

Ok, will use "migrate mode" and "stop mode".

@hjoliver
Copy link
Member Author

hjoliver commented Feb 27, 2025

Not particularly interested in the debate,

Me neither - but we have to give reasons for why something should be changed. Then, it's only a debate if someone else disagrees with those reasons (or the conclusions that follow from them).

@oliver-sanders
Copy link
Member

@oliver-sanders oliver-sanders removed this from the 8.4.x milestone Feb 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants