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

sos collect in Juju environment #3399

Closed
106106 opened this issue Oct 27, 2023 · 2 comments · Fixed by #3400
Closed

sos collect in Juju environment #3399

106106 opened this issue Oct 27, 2023 · 2 comments · Fixed by #3400
Assignees
Labels
Good First Issue This is a good issue for a first time contributor

Comments

@106106
Copy link

106106 commented Oct 27, 2023

Hi sos team,

I'm trying to use sos collect in a juju environment. I see there is this pull request and this issue so I believe the integration with Juju is implemented? But I'm struggling to get it working.

I'm using:

apt-cache policy sosreport
sosreport:
  Installed: 4.5.6-0ubuntu1~22.04.2
  Candidate: 4.5.6-0ubuntu1~22.04.2
  Version table:
 *** 4.5.6-0ubuntu1~22.04.2 500
        500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     4.3-1ubuntu2.1 500
        500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages
     4.3-1ubuntu2 500
        500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages

I have a Juju deployed environment. For example, and have tried something like:

multipass launch -n test-environment -c 4 -m 16G -d 50G
multipass shell test-environment
ssh-keygen
lxd init --auto
lxc network set lxdbr0 ipv6.address none
sudo snap install juju --channel 3.1/stable
mkdir -p ~/.local/share
juju bootstrap localhost controller-1
juju add-model model-1
juju ssh-keys
juju deploy vault
watch -c juju status --color
juju ssh vault/0
exit
sos collect --cluster-type=juju --batch -c juju.apps=vault --nopasswd-sudo 
sos collect --cluster-type=juju --batch -c juju.apps=vault --nopasswd-sudo --ssh-user ubuntu
sos collect --cluster-type=juju --batch -c juju.units=vault/0 --nopasswd-sudo --ssh-user ubuntu
sos collect --cluster-type=juju --batch -c juju.machines=0 --nopasswd-sudo --ssh-user ubuntu

and

juju ssh vault/0

authenticates me into the unit. But from the same host (that I used juju ssh vault/0 from) I can't seem to figure out how to use sos collect. I've tried the following:

sudo sos collect --cluster-type=juju --batch -c juju.apps=vault

and other options/combinations but I keep getting the following:

[...]
sos-collector ASSUMES that SSH keys are installed on all nodes unless the
--password option is provided.

/usr/lib/python3/dist-packages/pkg_resources/__init__.py:116: PkgResourcesDeprecationWarning: 4.5.6-0ubuntu1~22.04.2 is an invalid version and will not be supported in a future release
  warnings.warn(

The following is a list of nodes to collect from:
	test-environment


Connecting to nodes...
Collection would only gather from localhost due to failure to either enumerate or connect to cluster nodes. Assuming single collection from localhost is not desired.
Aborting...

I'm missing something? How do I collect from vault units? Any pointers would be greatly appreciated.

Thanks in advance!

@106106
Copy link
Author

106106 commented Oct 27, 2023

I've also tried:

sos collect --ssh-user ubuntu --nopasswd-sudo --no-local --batch --cluster-type=none --nodes=10.196.114.171 --timeout 1800

but I get

The following is a list of nodes to collect from:
	10.196.114.171  


Connecting to nodes...
[10.196.114.171:__init__] Unable to open remote session: Timeout expires while trying to connect
No nodes connected. Aborting...

@arif-ali arif-ali self-assigned this Oct 30, 2023
@arif-ali arif-ali added the Good First Issue This is a good issue for a first time contributor label Oct 30, 2023
@arif-ali
Copy link
Member

This has been confirmed as an issue with sos collect for juju, when we use newer juju releases. Thanks for reporting this. Will debug on what is going on, when will look towards a fix

arif-ali added a commit to arif-ali/sos that referenced this issue Oct 30, 2023
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: sosreport#3399
Resolves: SET-339

Signed-off-by: Arif Ali <arif.ali@canonical.com>
arif-ali added a commit to arif-ali/sos that referenced this issue Oct 30, 2023
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: sosreport#3399
Resolves: SET-339

Signed-off-by: Arif Ali <arif.ali@canonical.com>
arif-ali added a commit to arif-ali/sos that referenced this issue Oct 31, 2023
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: sosreport#3399
Resolves: SET-339

Signed-off-by: Arif Ali <arif.ali@canonical.com>
TurboTurtle added a commit to TurboTurtle/sos that referenced this issue Nov 3, 2023
The `get_pty` parameter for remote executed commands was both a bit of a
misnomer and applied too broadly.

Refactor this to `use_shell` to be more obvious about what the intent
behind the option is, and default all transports to `False`, so that by
default we do not wrap any commands in a bash shell.

This may be overriden on a per-transport basis via the ned `_need_shell`
property within transport subclasses. Further, this facility has been
expanded to be allowed on a per-command basis from
`SoSNode.run_command()` and wherever that is linked.

Related: sosreport#3399
Related: sosreport#3400

Signed-off-by: Jake Hunsaker <jacob.r.hunsaker@gmail.com>
TurboTurtle added a commit that referenced this issue Nov 7, 2023
The `get_pty` parameter for remote executed commands was both a bit of a
misnomer and applied too broadly.

Refactor this to `use_shell` to be more obvious about what the intent
behind the option is, and default all transports to `False`, so that by
default we do not wrap any commands in a bash shell.

This may be overriden on a per-transport basis via the ned `_need_shell`
property within transport subclasses. Further, this facility has been
expanded to be allowed on a per-command basis from
`SoSNode.run_command()` and wherever that is linked.

Related: #3399
Related: #3400

Signed-off-by: Jake Hunsaker <jacob.r.hunsaker@gmail.com>
arif-ali added a commit to arif-ali/sos that referenced this issue Nov 7, 2023
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: sosreport#3399
Resolves: SET-339

Signed-off-by: Arif Ali <arif.ali@canonical.com>
arif-ali added a commit to arif-ali/sos that referenced this issue Nov 9, 2023
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 fix this
particular use-case

Resolves: sosreport#3399
Resolves: SET-339

Signed-off-by: Arif Ali <arif.ali@canonical.com>
TurboTurtle pushed a commit that referenced this issue Nov 16, 2023
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 fix this
particular use-case

Resolves: #3399
Resolves: SET-339

Signed-off-by: Arif Ali <arif.ali@canonical.com>
arif-ali added a commit to arif-ali/sos that referenced this issue Nov 24, 2023
With juju versions 3 and above, when collecting the tarballs
from machines it will grab them into a strictly confined area.
This means that we need to be able to access this area via sudo.

In order for this now to be fully supported, we need sudo on the
host that is running juju, otherwise sos collect on a juju
environment will not work.

Related: sosreport#3399
Signed-off-by: Arif Ali <arif.ali@canonical.com>
arif-ali added a commit to arif-ali/sos that referenced this issue Nov 24, 2023
With juju versions 3 and above, when collecting the tarballs
from machines it will grab them into a strictly confined area.
This means that we need to be able to access this area via sudo.

In order for this now to be fully supported, we need sudo on the
host that is running juju, otherwise sos collect on a juju
environment will not work.

Related: sosreport#3399
Signed-off-by: Arif Ali <arif.ali@canonical.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Good First Issue This is a good issue for a first time contributor
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants