Addition of method to add OSDs to managed spec #4833
Conversation
42fdd68 to
c4482ba
Compare
b62f229 to
31d6722
Compare
|
Bugzilla pass log : http://magna002.ceph.redhat.com/cephci-jenkins/cephci-run-PCC9TG |
| return True | ||
|
|
||
| if not self.unmanaged_osd_service_exists(): | ||
| log.info("No unmanaged OSDs exist on the cluster on the start of test") |
There was a problem hiding this comment.
Should we return True here?
There was a problem hiding this comment.
No. now with the new behaviour, a new proper spec gets created, and the OSD will be part of it. We want to move the OSD from one spec to another.
That would not be possible if we return here. Hence just a message.
There was a problem hiding this comment.
But we are claiming that no OSDs are unmanaged, so if all the OSDs are already managed, why do we need to do anything at all?
| if not self.get_osd_spec(osd_id=osd_id): | ||
| log.debug("Setting OSDs ID %s to managed state", osd_id) | ||
| set_osds_managed([osd_id]) | ||
| time.sleep(10) |
There was a problem hiding this comment.
To save execution time, how about we write a method to fetch the list of unmanaged OSDs on the cluster, and then run single command to add all of them together.
Maybe as an enhancement in next PR?
There was a problem hiding this comment.
Updated the workflow. Collecting all the OSDs with un-manage-able placement spec, and then running a single command.
| rados_obj.set_service_managed_type(service_type="osd", unmanaged=False) | ||
| # log cluster health |
There was a problem hiding this comment.
I suppose for builds older than 8.1, this section of the code will still get executed and if the cluster already has any OSD services that are not managed by ceph orch, then this would fail
There was a problem hiding this comment.
I think we already handle condition where there un-manage-able placement spec. Would not fail i believe.
tests/rados/test_bug_fixes.py
Outdated
| log.info( | ||
| "No Unmanaged service present on the cluster" | ||
| "Proceeding to change the OSD spec to different one" | ||
| ) |
There was a problem hiding this comment.
Getting inside this block means Unmanaged service is present, the log statements seems to say the opposite
There was a problem hiding this comment.
Thanks. Updated the log
There was a problem hiding this comment.
Thanks. Updated the log
tests/rados/test_bug_fixes.py
Outdated
| log.debug("Completed addition of the OSD back to cluster.") | ||
|
|
||
| # Checking if the newly added OSD is without placement | ||
| if service_obj.unmanaged_osd_service_exists(): |
There was a problem hiding this comment.
At this point aren't all the OSD Orch services in unmanaged state due to execution of line 736?
There was a problem hiding this comment.
this is check for a OSD orch service, that cannot be set in managed state. Basically a check for un-manage-able placement spec.
There was a problem hiding this comment.
this is check for a OSD orch service, that cannot be set in managed state. Basically a check for un-manage-able placement spec.
Not a check for spec that is currently in a unmanaged state.
| # Currently OSD metadta is not updated with the spec change. Open discussion in progress. | ||
| # if osd_spec_name != new_osd_spec_name: | ||
| # log.error("Spec could not be updated for the OSD : %s", target_osd) | ||
| # return 1 |
There was a problem hiding this comment.
Did OSD restart help?
There was a problem hiding this comment.
NO. OSD restart did not help. Even after deleting the osd.default spec, and no longer listing in ceph orch ls, the metadata remained same.
4e32e91 to
ae34a12
Compare
Signed-off-by: Pawan Dhiran <pdhiran@redhat.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: harshkumarRH, neha-gangadhar, pdhiran The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Description
bug : https://bugzilla.redhat.com/show_bug.cgi?id=2304314
placementkey is not present for newly added OSDs.