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

All keys are marked as changed on update() in case of a dual gateway change #241

Closed
gbregman opened this issue Sep 24, 2023 · 1 comment · Fixed by #294
Closed

All keys are marked as changed on update() in case of a dual gateway change #241

gbregman opened this issue Sep 24, 2023 · 1 comment · Fixed by #294
Assignees

Comments

@gbregman
Copy link
Contributor

The update() function checks to see if the OMAP file version is greater than the local version. In case it is the code gets the state of the OMAP file and the local state. It goes over the keys which are identical in both states and compares their value. In case the value is different, the resource is marked as needed to be deleted from the OMAP file and added again. Only, it seems that all these keys are marked as different, even ones which are the same. The reason is that the OMAP value and the local value are kept in different Python types. The OMAP value is stored in a bytes[] object while the local value is stored in a structure. Adding debug messages to the code and creating a new bdev on the second gateway I could see this on the first gateway:

OMAP:
b'{\n "subsystem_nqn": "nqn.2016-06.io.spdk:cnode1",\n "serial_number": "SPDK87782274058122"\n}'

Local:
{ "subsystem_nqn": "nqn.2016-06.io.spdk:cnode1", "serial_number": "SPDK87782274058122" }

So, even though the actual NQN and serial number here are identical the values are still regarded to be different.

I think we need to parse the bytes[] object from OMAP and compare the fields properly to the local values.

@github-project-automation github-project-automation bot moved this to 🆕 New in NVMe-oF Sep 24, 2023
@gbregman gbregman self-assigned this Oct 25, 2023
@gbregman
Copy link
Contributor Author

The exact scenario I was using:

  • docker-compose up --scale nvmeof=2 ceph nvmeof
  • make demo
  • open a shell on the gateway which didn't run the CLI commands (usually gw-1)
  • in this shell create a bdev using CLI

Now looking at the log we can see that all the existing resources, which were created by "make demo", get deleted and created again

gbregman added a commit to gbregman/ceph-nvmeof that referenced this issue Oct 26, 2023
@github-project-automation github-project-automation bot moved this from 🆕 New to ✅ Done in NVMe-oF Oct 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

1 participant