[ceph] add iSCSI gateway

[nobuto-m]

Along with existing Ceph plugins, Ceph iSCSI gateway use case requires additional config and log files to be analyzed.
https://docs.ceph.com/en/latest/rbd/iscsi-overview/

Closes: #3098
Related-Bug: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/2000672
Signed-off-by: Nobuto Murata nobuto.murata@canonical.com

---

Please place an 'X' inside each '[]' to confirm you adhere to our Contributor Guidelines

• Is the commit message split over multiple lines and hard-wrapped at 72 characters?
• Is the subject and message clear and concise?
• Does the subject start with [plugin_name] if submitting a plugin patch or a [section_name] if part of the core sosreport code?
• Does the commit contain a Signed-off-by: First Lastname email@example.com?
• Are any related Issues or existing PRs properly referenced via a Closes (Issue) or Resolved (PR) line?

[packit-as-a-service]

Congratulations! One of the builds has completed. 🍾

You can install the built RPMs by following these steps:

• sudo yum install -y dnf-plugins-core on RHEL 8
• sudo dnf install -y dnf-plugins-core on Fedora
• dnf copr enable packit/sosreport-sos-3099
• And now you can install the packages.

Please note that the RPMs should be used only in a testing environment.

[pmoravec]

As not knowing ceph and esp. its nuances between Ubuntu and RedHat distros, I am asking for a review some more knowledgable people to check:

• do the packages = ("ceph-iscsi",) and services = ("rbd-target-api", "rbd-target-gw") enablement condition match on RedHat distro?
• logs and commands execution exist there as well?
• does it deserve to have a separate plugin for this - or is there some overlap with other ceph_* plugins?

Thanks anybody from @jcastill , @asm0deuz, @nkshirsagar for such review.

[TurboTurtle]

In updating some of the other ceph plugins, I've found that the /var/log locations have changed in newer versions (16+) of ceph. Most include the fsid, e.g. /var/log/ceph/ to /var/log/ceph/fsid/.

Can we double check to make sure we're able to collect this log file from both newer and older versions?

[nobuto-m]

I dug into this but I'm not sure I'm following. Indeed, there is a particular path conversion with fsid in bind mount with cephadm, but from a process point of view the path is just /var/log/ceph, e.g. /var/log/ceph/ceph-osd.0.log. So not sure if that's the case for non-cephadm deployments.

docker inspect ceph-894b217c-8b2c-11ed-829c-930768227c30-iscsi-iscsi-cephadm-onylll | jq '.[].Mounts | .[] | select(.Destination=="/var/log")'
{
  "Type": "bind",
  "Source": "/var/log/ceph/894b217c-8b2c-11ed-829c-930768227c30",
  "Destination": "/var/log",
  "Mode": "z",
  "RW": true,
  "Propagation": "rprivate"
}

[TurboTurtle]

If the collections needs to happen in a container, then you need to specify the container in the add_copy_spec()/add_cmd_output() calls with the container parameter (either the container name or the ID).

Having the containers listed in the containers tuple just enables the plugin to run. As written, these collections would still happen directly on the host - so to copy them from the host you would need to use /var/log/ceph/*/ceph-client.iscsi.log or similar.

[nobuto-m]

• do the packages = ("ceph-iscsi",) and services = ("rbd-target-api", "rbd-target-gw") enablement condition match on RedHat distro?

According to the manual installation guide for RHEL/CentOS, the package name and the two service names are common between Ubuntu and RHEL.
https://docs.ceph.com/en/latest/rbd/iscsi-target-cli/

• logs and commands execution exist there as well?

gwcli command for sure as in the doc above. And let me double check the log location. I doubt it contains fsid because ceph-iscsi is rbd client side basically not Ceph cluster side.

[TurboTurtle]

Ack.

Merge pending confirmation on if the collections are meant to be from the container or the host. If the host location is volume-mounted into the container, slight preference from me to copy from the host but it is not a required pattern.

[nobuto-m]

Merge pending confirmation on if the collections are meant to be from the container or the host. If the host location is volume-mounted into the container, slight preference from me to copy from the host but it is not a required pattern.

The intention was to detect containers and collect logs on the host instead of from inside a container.

I wasn't aware #3092 was coming so assumed that the existing code base didn't expect cephadm based deployment yet but package based and ceph-ansible container based deployments.

So this PR can be merged for package based and ceph-ansible based deployments. For accommodating both existing deployments and cephadm, I'd like to wait for a conclusion in #3100 so Ceph iSCSI plugin can be updated as well later.

[TurboTurtle]

Per the discussion in #3100 - let's update this to use ** and merge it at that point.

[TurboTurtle]

Cycling back around on this. I think we just need this to be /var/log/ceph/**/ceph-client.iscsi.log and this one will be good to merge.