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

Fix: ui_context: crm configure up prompt #1466 #1481

Merged

Conversation

aleksei-burlakov
Copy link

The regression was introduced in beb26f3
Before beb26f3 it was like

crm(live/15sp5-1)configure# primitive d Dummy
crm(live/15sp5-1)configure# up
There are changes pending. Do you want to commit them (y/n)?

After beb26f3 there is no prompt There are changes pending. Do you want to commit them (y/n)?
This change brings the prompt back.

The regression was introduced in beb26f3
Before beb26f3 it was like
$ crm(live/15sp5-1)configure# primitive d Dummy
$ crm(live/15sp5-1)configure# up
$ There are changes pending. Do you want to commit them (y/n)?
After beb26f3 there is no prompt 'There are changes pending... (y/n)?'
This change brings the prompt back.
Copy link

codecov bot commented Jul 4, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 69.27%. Comparing base (3b3d7ee) to head (ac4a532).

Additional details and impacted files
Flag Coverage Δ
integration 53.92% <100.00%> (ø)
unit 52.34% <0.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Coverage Δ
crmsh/ui_context.py 58.17% <100.00%> (ø)

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Collaborator

@liangxin1300 liangxin1300 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

Please backport to crmsh-4.6

@liangxin1300 liangxin1300 merged commit 3e96f90 into ClusterLabs:master Jul 8, 2024
30 of 31 checks passed
@nicholasyang2022
Copy link
Collaborator

It seems that this patch breaks regression tests.

@aleksei-burlakov aleksei-burlakov deleted the fix-crm-conf-up-prompt branch July 8, 2024 09:31
aleksei-burlakov pushed a commit to aleksei-burlakov/crmsh that referenced this pull request Jul 8, 2024
backport ClusterLabs#1481

The regression was introduced in beb26f3
Before beb26f3 it was like
$ crm(live/15sp5-1)configure# primitive d Dummy
$ crm(live/15sp5-1)configure# up
$ There are changes pending. Do you want to commit them (y/n)?
After beb26f3 there is no prompt 'There are changes pending... (y/n)?'
This change brings the prompt back.
liangxin1300 added a commit that referenced this pull request Jul 9, 2024
backport #1481

The regression was introduced in beb26f3
Before beb26f3 it was like
$ crm(live/15sp5-1)configure# primitive d Dummy
$ crm(live/15sp5-1)configure# up
$ There are changes pending. Do you want to commit them (y/n)? After
beb26f3 there is no prompt 'There are changes pending... (y/n)?' This
change brings the prompt back.
liangxin1300 added a commit that referenced this pull request Jul 11, 2024
#1300 tried to remove unnecessary dependencies on a running pacemaker
service when crmsh is not actually going to call the service. However,
it removed the call to `end_game()` from `up()` and `quit()`
incorrectly. This made sublevel `configure` not to have a chance to
check uncommitted changes anymore, leading to a regression described in
#1466.

#1481 tried to fix this regression by adding the call to `end_game()`
back to `up()`, and check if pacemaker service is running before calling
`end_game()`. This is not optimal as `up()` is a common method used for
all sublevels and the status of pacemaker service is only related
sublevel `configure`. Checking the status of pacemaker service when
using other sublevels does not make sense.

This pull request uses a more straightforward method to fix the problem:
improve how to detect uncommitted changes in `has_cib_changes()`.

The original implementation is to check if there is any elements in
change queue. This requires the in memory representation of cib to be
populated, leading to an indirect dependency to pacemaker service.
However, we can take advantage of a property: the in memory cib needs to
be populated before doing any changes. So in the implementation can be
optimized: if the in memory cib is not populated, we will know there is
not any change.
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

Successfully merging this pull request may close these issues.

None yet

3 participants