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

adds purge support for the lvm_osds osd scenario #1797

Merged
merged 2 commits into from Aug 23, 2017
Merged

Conversation

andrewschoen
Copy link
Contributor

To add this support, restructuring of lvm_volumes was necessary. The new format provides more flexibility in regards to how you define your lvm-based OSDs.

This also adds a purge_lvm_osds testing scenario to ensure it works correctly.

Fixes: #1787

@@ -321,6 +326,22 @@
- ceph_disk_present.rc == 0
- ceph_data_partlabels.rc == 0

- name: remove osd logical volumes
Copy link
Contributor

Choose a reason for hiding this comment

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

can you add a comment here so that we know this needs to go away once ceph-volume lvm zap becomes available?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

sure

@andrewschoen
Copy link
Contributor Author

@jharriga would you mind taking a look at this please?

@@ -77,15 +77,15 @@
- not osd_auto_discovery
- lvm_volumes|length == 0

- name: make sure the lvm_volumes variable is a dictionary
- name: make sure the lvm_volumes variable is a list
fail:
msg: "lvm_volumes: must be a dictionary"
Copy link
Contributor

Choose a reason for hiding this comment

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

this needs to be updated

The lvm_volumes variable is now a list of dictionaries that represent
each OSD you'd like to deploy using ceph-volume. Each dictionary must
have the following keys: data, journal and data_vg. Each dictionary also
can optionaly provide a journal_vg key.

The 'data' key represents the lv name used for the OSD and the 'data_vg'
key is the vg name that the given lv resides on. The 'journal' key is
either an lv, device or partition. The 'journal_vg' key is optional and
must be the vg name for the journal lv if given. This key is mainly used
for purging of the journal lv if purge-cluster.yml is run.

For example:

  lvm_volumes:
    - data: data_lv1
      journal: journal_lv1
      data_vg: vg1
      journal_vg: vg2
    - data: data_lv2
      journal: /dev/sdc
      data_vg: vg1

Signed-off-by: Andrew Schoen <aschoen@redhat.com>
This also adds a new testing scenario for purging lvm osds

Signed-off-by: Andrew Schoen <aschoen@redhat.com>
@andrewschoen
Copy link
Contributor Author

jenkins test luminous-ansible2.3-update_docker_cluster

@andrewschoen
Copy link
Contributor Author

The failure in luminous-ansible2.3-update_docker_cluster is unrelated to this PR.

@alfredodeza alfredodeza merged commit e651469 into master Aug 23, 2017
@alfredodeza alfredodeza deleted the purge-lvm branch August 23, 2017 18:28
@jharriga
Copy link

I just ran this against my cluster and it completed the purge with no errors.
Thank you for such quick response!

@jharriga
Copy link

One observation. I attempted to reinstall the cluster after the purge and it failed - no LV's.
purge-cluster removed the LVM log vols specified in lvm_volumes. The VG's and PV's
still exist.
The current usage model requires pre-creating the LVM devices prior to creating
the cluster. I did not expect purge-cluster would remove those logical vols.
What is the eventual usage model?

@andrewschoen
Copy link
Contributor Author

@jharriga Yes, when purging it does lvremove the lvs defined in lvm_volumes, it also zaps any disks used for journals. In my testing I deployed a cluster, purged it, setup the lvs again and redeployed and everything worked fine. I guess I'm not sure what other behavior should be taken here. What would you expect to happen?

@alfredodeza
Copy link
Contributor

This is also how purge works for regular disks, the partitions get destroyed. The one difference, and where we divert (although temporarily) is that there is no facility to create/re-create lv's, unlike ceph-disk which will create them again

@jharriga
Copy link

Just wanted to check that the difference of not currently create/re-create is temporary.
FYI, I recreated the lv's, ran ceph-ansible and the cluster is back.
Thanks.

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