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

feat: Support for creating volumes without a FS #400

Merged
merged 1 commit into from
Nov 9, 2023

Conversation

japokorn
Copy link
Collaborator

@japokorn japokorn commented Oct 27, 2023

Currently whenever volume is created without fs_type specification, a filesystem of default type (i.e. xfs) is automatically put on it.
This change allows user to prevent FS creation by using "unformatted" value as a fs_type option. In the same manner it also allows to remove an existing FS. To be able to do that the safe mode has to be off.

Enhancement:

Reason:

Result:

Issue Tracker Tickets (Jira or BZ if any):

@codecov
Copy link

codecov bot commented Oct 27, 2023

Codecov Report

Attention: 6 lines in your changes are missing coverage. Please review.

Comparison is base (fccfa38) 13.67% compared to head (cd84a91) 13.66%.
Report is 4 commits behind head on main.

❗ Current head cd84a91 differs from pull request most recent head c320742. Consider uploading reports for the commit c320742 to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #400      +/-   ##
==========================================
- Coverage   13.67%   13.66%   -0.01%     
==========================================
  Files           8        8              
  Lines        1733     1734       +1     
  Branches       79       79              
==========================================
  Hits          237      237              
- Misses       1496     1497       +1     
Flag Coverage Δ
sanity 16.54% <ø> (ø)

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

Files Coverage Δ
library/blivet.py 0.00% <0.00%> (ø)

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

@japokorn japokorn force-pushed the main-lvs_wo_fs branch 3 times, most recently from ca2930a to 494ce56 Compare October 27, 2023 13:07
@japokorn japokorn marked this pull request as ready for review October 27, 2023 13:12
volumes:
- name: test1
size: "{{ volume_size }}"
fs_type: None
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this require storage_safe_mode: false? Seems kinda dangerous

Copy link
Collaborator Author

@japokorn japokorn Oct 30, 2023

Choose a reason for hiding this comment

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

Yes, it does. In code the behavior extends the functionality of _reformat method which handles the safe_mode.
Still, fs_type: None 'creation' on empty device will work even with safe_mode on since it is a no-op.

I have added the safe_mode requirement into the commit message, worth mentioning there.

@richm
Copy link
Contributor

richm commented Oct 27, 2023

What happens now if the fs_type is not specified? e.g. if you use

        storage_pools:
          - name: foo
            disks: "{{ unused_disks }}"
            volumes:
              - name: test1
                size: "{{ volume_size }}"

what happens? Does the role do nothing? Does it remove the fs? Does it create a volume with no fs?

What happens when a user has a playbook with the above, which was working and creating file systems with fs_type xfs, and they upgrade the storage role, and run the playbook again? The user expects that the behavior will not change - that is, it should create fs_type xfs. We cannot easily break that, especially if the default will be destructive, or will just silently fail.

I think a better option to avoid breaking the api is to use a special value for fs_type e.g. fs_type: NOFS which will create the volume with no fs, or remove the fs on an existing volume.

@japokorn
Copy link
Collaborator Author

japokorn commented Oct 30, 2023

Using None is in this case recognized and processed differently than when fs_type is not used at all.

For idempotency reasons we already have to be able to identify the situations when some variable is omitted. When that happens, any value found (on possibly already existing device) should remain unchanged.

Otherwise, for example running the role over pre-existing encrypted volume without encryption option in the task would force default absent value on it and change the device.

@richm
Copy link
Contributor

richm commented Oct 30, 2023

The way the current role (current contents of main, not this PR) works is this: if fs_type is omitted, or has the value of null, an fs is created with a type of xfs (on RHEL 8.9 manage nodes anyway). I don't think we should change this behavior as it would break the existing API. I have verified this by using the test tests_create_disk_then_remove.yml and using various different values for, or omitting, fs_type.

@vojtechtrefny
Copy link
Collaborator

I think a better option to avoid breaking the api is to use a special value for fs_type e.g. fs_type: NOFS which will create the volume with no fs, or remove the fs on an existing volume.

We are currently using unformatted in blivet-gui and empty in udisks so these would be also options. There is a (old and probably never really used) filesystem called NoFS so we should probably avoid using that.

@japokorn
Copy link
Collaborator Author

japokorn commented Nov 1, 2023

Using ansible 'false' equivalents might be interchangeable with None, so based on discussion with vtrefny I have changed the string from None to all case variations of unformatted.
I added this to README and also modified the commit message accordingly.

@@ -143,6 +143,7 @@ variables:
This indicates the desired file system type to use, e.g.: "xfs", "ext4", "swap".
The default is determined according to the OS and release
(currently `xfs` for all the supported systems).
Use "unformatted" if you do not want file system to be present.
Copy link
Contributor

Choose a reason for hiding this comment

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

or maybe this should be "unconfigured"?

Copy link
Contributor

Choose a reason for hiding this comment

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

Not sure how we note destructive operations elsewhere, but seems to me like we should say something like **WARNING**: Using "unconfigured" on an existing filesystem will remove the filesystem.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Thanks. The correct value is actually 'unformatted' in the code. I made sure the value is unified.
I have also added a warning note into the README.

Currently whenever volume is created without fs_type specification, a filesystem of default
type (i.e. xfs) is automatically put on it.
This change allows user to prevent FS creation by explicitly using "unformatted" value as a fs_type option.
In the same manner it also allows to remove an existing FS. To be able to do that the safe mode has to be off.
@richm
Copy link
Contributor

richm commented Nov 9, 2023

ok - I also did a test with

        storage_pools:
          - name: foo
            disks: "{{ unused_disks }}"
            volumes:
              - name: test1
                size: "{{ volume_size }}"
                fs_type: unformatted

i.e. create a volume without an FS - it worked fine

@richm richm merged commit c141303 into linux-system-roles:main Nov 9, 2023
17 checks passed
@richm richm mentioned this pull request Jan 22, 2024
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.

3 participants