[juju][collect] Fix new juju collection

[arif-ali]

New version of juju uses colorisation, and therefore juju status and json.loads doesn't load the juju status correctly. By using --no-color based on the version of juju this should this particular use-case

Resolves: #3399
Resolves: SET-339

---

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 protected]?
• 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-3400
• And now you can install the packages.

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

[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-3400
• And now you can install the packages.

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

[TurboTurtle]

/packit rebuild-failed

[TurboTurtle]

LGTM.

We're trying to push f-strings, but here it'd be a bit awkward without re-writing the entire command slicing, so we'll put this one on the back burner for another time.

As an aside, I can't imagine we're the only ones calling juju so it may be worth working with the juju devs to automatically detect when to use --no-color from the juju command for situations like this (e.g. when not called from a shell).

[pmoravec]

Why not single

res = sos_get_command_output("juju version")

?

(or maybe even merge it with return, though that might sacrifice code readability too much)

[arif-ali]

As an aside, I can't imagine we're the only ones calling juju so it may be worth working with the juju devs to automatically detect when to use --no-color from the juju command for situations like this (e.g. when not called from a shell).

Actually, I didn't think too much of it, and I think that is valid point.

So, I have opened a bug on our end.

I think, at this point, I'm on the opinion that I would put this as a draft/wip, until we are 100%, and if it does get fixed in juju, then there's no point on this PR.

[arif-ali]

So, after discussing this, and update on the bug, https://bugs.launchpad.net/juju/+bug/2042309, the reason why we are getting colorise is due to the fact we are allocating PTY. Is there a way we can avoid this, and then we don't need to force the --no-color

         res = self.primary.run_command(cmd, get_pty=pty, need_root=need_root,
                                       timeout=timeout)

[TurboTurtle]

IIRC, that is due to the default usage of ssh and some behavior of that we found during early testing. I'm open to making that toggle-able at the transport in use, which would allow juju to avoid it (and at the very least provide us the opportunity to re-test ssh).

On that note, it's weird that we're setting this in a Cluster profile, and not having it fully determined in the transport.

I think the best approach here is to remove the pty determination from cluster, let the transports determine it via a (to be added) property, with current behavior as the default and an override for juju.

I'm happy to move bits around on this (though likely in a few days as day job has me tied up for the week), but if you'd like to handle it within this or another PR, that's fine too, just let me know.

[arif-ali]

/packit rebuild-failed