[Deepsea-users] Which SuSE version is best for deapsea "exploring"
Joshua Schmid
jschmid at suse.de
Mon Nov 12 05:22:55 MST 2018
Hi Rainer,
Rainer Krienke <krienke at uni-koblenz.de> wrote on Fri, 09. Nov 09:08:
> Hello,
>
> In the article they used openSuSE42.3 for testing and so did I., I set
> up four citrix VMs running 42.3 and added the deapsea repos:
>
> https://download.opensuse.org/repositories/filesystems:/ceph:/luminous/openSUSE_Leap_42.3
>
> The salt-master has version: salt-master-2018.3.0-20.1.x86_64
Deepsea releases are tied to certain version of salt, opensuse and
ceph. This is our 'stable' combination of versions.
DeepSea versions 0.8.x -> Ceph Luminous -> openSUSE 42.3 -> salt
2016.11.x
We are currently working on a DeepSea v 0.9.x on Ceph Nautilus but
that can't be considered as stable yet.
I just noticed that https://build.opensuse.org/project/show/filesystems:ceph:luminous
has a rather outdated version of deepsea. I'll push a new version to
this repo soon.
>
> When running salt-run state.orch ceph.stage.0
> I saw error in a state that checks the current kernel version in
>
> /srv/salt/ceph/updates/restart/default.sls
>
> which ended up in a call of "rpm -1" which returns an invalid option
> error. I was able to fix this simply by removing the shell command that
> should determine the current kernel version. Strange is that basically
> the command does what it is supposed to do but beeing part of the Jinja
> code in ceph/updates/restart/default.sls:
>
> {% set kernel = grains['kernelrelease'] | replace('-default', '') %}
> {% set installed = salt['cmd.run']('rpm -q --last kernel-default | head
> -1 | cut -f1 -d\ ') | replace('kernel-default-', '') %}
>
> it fails with the rpm -1 error message.
>
> The next problems occured in state 2. Here I see many errors. The first
> one right at the beginning is the following:
>
> ID: setup monitoring
> Function: salt.state
> Result: False
> Comment: Run failed on minions: susecsalt.uni-koblenz.de
> Started: 08:37:36.121449
> Duration: 16573.77 ms
> Changes:
> salthost.uni-koblenz.de:
> Data failed to compile:
> ----------
> The require statement in state
> '/etc/prometheus/ses_nodes' in SLS
> 'ceph.monitoring.prometheus.update_service_discovery' needs to be formed
> as a list
>
> My question is now if perhaps 42.3 with the chosen deapsea repos is a
> suboptimal choice from my side and if another combination should work
> more smoothly?
This may very well be connected to the version missmatch between
salt/deepsea and the prometheus packages. If you can reproduce this
issue with the version mentioned above, please let us know.
>
> Thanks a lot
> Rainer
> --
> Rainer Krienke, Uni Koblenz, Rechenzentrum, A22, Universitaetsstrasse 1
> 56070 Koblenz, Tel: +49261287 1312 Fax +49261287 100 1312
> Web: http://userpages.uni-koblenz.de/~krienke
> PGP: http://userpages.uni-koblenz.de/~krienke/mypgp.html
> _______________________________________________
> Deepsea-users mailing list
> Deepsea-users at lists.suse.com
> http://lists.suse.com/mailman/listinfo/deepsea-users
--
Joshua Schmid
Software Engineer
SUSE Enterprise Storage
More information about the Deepsea-users
mailing list