From Robert.Grosschopff at suse.com Fri Apr 6 08:52:18 2018 From: Robert.Grosschopff at suse.com (Robert Grosschopff) Date: Fri, 6 Apr 2018 14:52:18 +0000 Subject: [Deepsea-users] too many MONs created Message-ID: <683D1589-0E1F-48B2-9754-8095610205B7@suse.com> Hi *, we got another unexpected behavior regarding MON creation. policy.cfg states # 3 MONs role-mon/stack/default/ceph/minions/ld49[40,41,73]*.yml role-mon/cluster/ld49[40,41,73]*.sls After the cluster is installed we end up with 5 MONs i.e. all nodes : services: mon: 5 daemons, quorum ld4940,ld4941,ld4973,ld4974,ld4975 A very, very distant voice in my head tells me that we have seen this before and it is related to the way the above stanza is expanded. It seems that it matches ld49[40,41,73]*.yml to anything that resembles ld4940*yml, ld4941*yml, ld4973*yml but also ld494*yml and ld497*yml resulting in the inclusion of all nodes. Could that be the case ? Robert From tserong at suse.com Mon Apr 9 01:06:48 2018 From: tserong at suse.com (Tim Serong) Date: Mon, 9 Apr 2018 17:06:48 +1000 Subject: [Deepsea-users] adventures with wip-salt2018 / SLE 15 / python3 Message-ID: <9553cc3d-ef0e-b3d8-baec-9ba1ba6bf1f1@suse.com> Hi All, I have a problem. I'm trying out the deepsea wip-salt2018 branch on the latest(?) SLE 15 (salt 2018.1.99, python 3.6.4), and various runners somewhat intermittently break. Here's an example: # salt-run state.orch ceph.stage.3 firewall : disabled apparmor : disabled fsid : valid public_network : valid cluster_network : valid cluster_interface : valid monitors : valid mgrs : valid storage : valid ganesha : valid master_role : valid time_server : valid fqdn : valid (...snip...) Summary for admin.ceph_master ------------- Succeeded: 50 (changed=32) Failed: 0 ------------- Total states run: 50 Total run time: 220.284 s OK, that worked fine. Now I run it again: # salt-run state.orch ceph.stage.3 firewall : disabled apparmor : disabled [ERROR ] Rendering exception occurred Traceback (most recent call last): (...snip...) KeyError: 'validate.pillar' Huh? If I try to run validate.pillar by hand, I get: # salt-run validate.pillar cluster=ceph 'validate' __virtual__ returned False: No module named 'deepsea_minions' If I then delete that runner's pyc file, everything works again # rm /srv/modules/runners/__pycache__/validate.cpython-36.pyc # salt-run validate.pillar cluster=ceph fsid : valid public_network : valid cluster_network : valid cluster_interface : valid monitors : valid mgrs : valid storage : valid ganesha : valid master_role : valid time_server : valid fqdn : valid True Likewise, stage 3 runs through fine again at this point. Has anyone else seen this? What the hell is going on here? Thanks, Tim -- Tim Serong Senior Clustering Engineer SUSE tserong at suse.com -------------- next part -------------- A non-text attachment was scrubbed... Name: tserong.vcf Type: text/x-vcard Size: 4 bytes Desc: not available URL: From jschmid at suse.de Mon Apr 9 02:31:14 2018 From: jschmid at suse.de (Joshua Schmid) Date: Mon, 9 Apr 2018 10:31:14 +0200 Subject: [Deepsea-users] adventures with wip-salt2018 / SLE 15 / python3 In-Reply-To: <9553cc3d-ef0e-b3d8-baec-9ba1ba6bf1f1@suse.com> References: <9553cc3d-ef0e-b3d8-baec-9ba1ba6bf1f1@suse.com> Message-ID: <20180409083114.3td36ojejlrsoe5v@g127.suse.de> Hey Tim, Tim Serong wrote on Mon, 09. Apr 17:06: > Hi All, > > I have a problem. I'm trying out the deepsea wip-salt2018 branch on the > latest(?) SLE 15 (salt 2018.1.99, python 3.6.4), and various runners > somewhat intermittently break. Here's an example: > > # salt-run state.orch ceph.stage.3 > firewall : disabled > apparmor : disabled > fsid : valid > public_network : valid > cluster_network : valid > cluster_interface : valid > monitors : valid > mgrs : valid > storage : valid > ganesha : valid > master_role : valid > time_server : valid > fqdn : valid > (...snip...) > > Summary for admin.ceph_master > ------------- > Succeeded: 50 (changed=32) > Failed: 0 > ------------- > Total states run: 50 > Total run time: 220.284 s > > > OK, that worked fine. Now I run it again: > > # salt-run state.orch ceph.stage.3 > firewall : disabled > apparmor : disabled > [ERROR ] Rendering exception occurred > Traceback (most recent call last): > (...snip...) > KeyError: 'validate.pillar' That's apparently a bug in salt.. I mentioned that in my PR (https://github.com/SUSE/DeepSea/pull/1051) under 'Caveats'. Bug for it is here: https://bugzilla.suse.com/show_bug.cgi?id=1087232 > > Has anyone else seen this? What the hell is going on here? What I know is that salt's loader.py has goes a different path for python_version >= 3.3 and uses the 'importlib' isntead of 'imp'. That shouldn't mess with cache files, though.. So, no idea what the hell is going on :) > > Thanks, > > Tim > -- > Tim Serong > Senior Clustering Engineer > SUSE > tserong at suse.com > _______________________________________________ > 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 From tserong at suse.com Mon Apr 9 02:38:03 2018 From: tserong at suse.com (Tim Serong) Date: Mon, 9 Apr 2018 18:38:03 +1000 Subject: [Deepsea-users] adventures with wip-salt2018 / SLE 15 / python3 In-Reply-To: <20180409083114.3td36ojejlrsoe5v@g127.suse.de> References: <9553cc3d-ef0e-b3d8-baec-9ba1ba6bf1f1@suse.com> <20180409083114.3td36ojejlrsoe5v@g127.suse.de> Message-ID: <32cc2b70-1fd5-8db7-12e3-4a969a469374@suse.com> On 04/09/2018 06:31 PM, Joshua Schmid wrote: > Hey Tim, > > Tim Serong wrote on Mon, 09. Apr 17:06: >> Hi All, >> >> I have a problem. I'm trying out the deepsea wip-salt2018 branch on the >> latest(?) SLE 15 (salt 2018.1.99, python 3.6.4), and various runners >> somewhat intermittently break. Here's an example: >> >> # salt-run state.orch ceph.stage.3 >> firewall : disabled >> apparmor : disabled >> fsid : valid >> public_network : valid >> cluster_network : valid >> cluster_interface : valid >> monitors : valid >> mgrs : valid >> storage : valid >> ganesha : valid >> master_role : valid >> time_server : valid >> fqdn : valid >> (...snip...) >> >> Summary for admin.ceph_master >> ------------- >> Succeeded: 50 (changed=32) >> Failed: 0 >> ------------- >> Total states run: 50 >> Total run time: 220.284 s >> >> >> OK, that worked fine. Now I run it again: >> >> # salt-run state.orch ceph.stage.3 >> firewall : disabled >> apparmor : disabled >> [ERROR ] Rendering exception occurred >> Traceback (most recent call last): >> (...snip...) >> KeyError: 'validate.pillar' > > That's apparently a bug in salt.. I mentioned that in my PR (https://github.com/SUSE/DeepSea/pull/1051) > under 'Caveats'. > Bug for it is here: https://bugzilla.suse.com/show_bug.cgi?id=1087232 Ah, silly me. Somehow I missed reading that :-/ Thanks! >> >> Has anyone else seen this? What the hell is going on here? > > What I know is that salt's loader.py has goes a different path for > python_version >= 3.3 and uses the 'importlib' isntead of 'imp'. > That shouldn't mess with cache files, though.. > So, no idea what the hell is going on :) > >> >> Thanks, >> >> Tim >> -- >> Tim Serong >> Senior Clustering Engineer >> SUSE >> tserong at suse.com > > >> _______________________________________________ >> Deepsea-users mailing list >> Deepsea-users at lists.suse.com >> http://lists.suse.com/mailman/listinfo/deepsea-users > > -- Tim Serong Senior Clustering Engineer SUSE tserong at suse.com -------------- next part -------------- A non-text attachment was scrubbed... Name: tserong.vcf Type: text/x-vcard Size: 4 bytes Desc: not available URL: From ncutler at suse.cz Mon Apr 9 05:14:46 2018 From: ncutler at suse.cz (Nathan Cutler) Date: Mon, 9 Apr 2018 13:14:46 +0200 Subject: [Deepsea-users] Trouble installing vagrant on latest openSUSE Tumbleweed Message-ID: <6f843c5d-f126-084e-e2e5-358a25d9aeca@suse.cz> I installed the latest Tumbleweed and am having trouble getting vagrant to work. I'm using the openSUSE_vagrant_setup.sh script from openSUSE/vagrant-ceph Everything goes fine until "vagrant plugin install vagrant-libvirt" The error displayed is: https://paste2.org/sUcbttgD I'm stuck and would be grateful for any tips, suggestions, brickbats... Nathan From ncutler at suse.cz Mon Apr 9 05:17:32 2018 From: ncutler at suse.cz (Nathan Cutler) Date: Mon, 9 Apr 2018 13:17:32 +0200 Subject: [Deepsea-users] Trouble installing vagrant on latest openSUSE Tumbleweed In-Reply-To: <6f843c5d-f126-084e-e2e5-358a25d9aeca@suse.cz> References: <6f843c5d-f126-084e-e2e5-358a25d9aeca@suse.cz> Message-ID: <1a744e40-b73e-1d64-1255-9dd481f006b9@suse.cz> Ah, progress. Here is where the problem occurs: "gcc -o conftest -I/opt/vagrant/embedded/include/ruby-2.4.0/x86_64-linux -I/opt/vagrant/embedded/include/ruby-2.4.0/ruby/backward -I/opt/vagrant/embedded/include/ruby-2.4.0 -I. -I/opt/vagrant/embedded/include -I/opt/vagrant/embedded/include -I/vagrant-substrate/cache/ruby-2.4.3/include -O3 -fPIC conftest.c -L. -L/opt/vagrant/embedded/lib -Wl,-rpath,/opt/vagrant/embedded/lib -L/opt/vagrant/embedded/lib -Wl,-rpath,/opt/vagrant/embedded/lib -L. -L/opt/vagrant/embedded/lib -Wl,-rpath=XORIGIN/../lib:/opt/vagrant/embedded/lib -fstack-protector -rdynamic -Wl,-export-dynamic -L/opt/vagrant/embedded/lib -Wl,-rpath,/opt/vagrant/embedded/lib -Wl,-rpath,'/../lib' -Wl,-rpath,'/../lib' -lruby -lpthread -lrt -lgmp -ldl -lcrypt -lm -lc " sh: /opt/vagrant/embedded/lib/libreadline.so.7: no version information available (required by sh) sh: symbol lookup error: /opt/vagrant/embedded/lib/libreadline.so.7: undefined symbol: PC checked program was: /* begin */ 1: #include "ruby.h" 2: 3: int main(int argc, char **argv) 4: { 5: return 0; 6: } /* end */ And this page [1] says the problem is incompatibility with libreadline.so.7 (needs an earlier version) Nathan From agraul at suse.com Mon Apr 9 05:36:11 2018 From: agraul at suse.com (Alexander Graul) Date: Mon, 9 Apr 2018 13:36:11 +0200 Subject: [Deepsea-users] Trouble installing vagrant on latest openSUSE Tumbleweed In-Reply-To: <1a744e40-b73e-1d64-1255-9dd481f006b9@suse.cz> References: <6f843c5d-f126-084e-e2e5-358a25d9aeca@suse.cz> <1a744e40-b73e-1d64-1255-9dd481f006b9@suse.cz> Message-ID: <838ed5a9-1d2c-a8f8-d3a1-47f62ffce334@suse.com> On 04/09/2018 01:17 PM, Nathan Cutler wrote: > And this page [1] says the problem is incompatibility with > libreadline.so.7 (needs an earlier version) > I had the same problem, just copying the distro lib worked for me: sudo cp /lib64/libreadline.so.7 /opt/vagrant/embedded/lib I then installed vagrant-libvirt with the following options: CONFIGURE_ARGS='with-ldflags=-L/opt/vagrant/embedded/lib with-libvirt-include=/usr/include/libvirt with-libvirt-lib=/usr/lib' GEM_HOME=~/.vagrant.d/gems GEM_PATH=$GEM_HOME:/opt/vagrant/embedded/gems PATH=/opt/vagrant/embedded/bin:$PATH vagrant plugin install vagrant-libvirt I don't know if those options are required, I came across them on StackOverflow and kept using them after copying the library. Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From ncutler at suse.cz Mon Apr 9 05:40:07 2018 From: ncutler at suse.cz (Nathan Cutler) Date: Mon, 9 Apr 2018 13:40:07 +0200 Subject: [Deepsea-users] Trouble installing vagrant on latest openSUSE Tumbleweed In-Reply-To: <838ed5a9-1d2c-a8f8-d3a1-47f62ffce334@suse.com> References: <6f843c5d-f126-084e-e2e5-358a25d9aeca@suse.cz> <1a744e40-b73e-1d64-1255-9dd481f006b9@suse.cz> <838ed5a9-1d2c-a8f8-d3a1-47f62ffce334@suse.com> Message-ID: <11c5718c-202c-3f34-69db-95f2768252dd@suse.cz> Thanks, Alex! I just got it to work by installing libreadline6 and then manually copying that library over to /opt/vagrant/embedded/lib Once I did that, and deleted /opt/vagrant/embedded/lib/libreadline.so.7*, it started to work - at least, the command "vagrant plugin install vagrant-libvirt" succeeded. Nathan On 04/09/2018 01:36 PM, Alexander Graul wrote: > On 04/09/2018 01:17 PM, Nathan Cutler wrote: >> And this page [1] says the problem is incompatibility with >> libreadline.so.7 (needs an earlier version) >> > > I had the same problem, just copying the distro lib worked for me: > > sudo cp /lib64/libreadline.so.7 /opt/vagrant/embedded/lib > > > I then installed vagrant-libvirt with the following options: > > CONFIGURE_ARGS='with-ldflags=-L/opt/vagrant/embedded/lib > with-libvirt-include=/usr/include/libvirt with-libvirt-lib=/usr/lib' > GEM_HOME=~/.vagrant.d/gems GEM_PATH=$GEM_HOME:/opt/vagrant/embedded/gems > PATH=/opt/vagrant/embedded/bin:$PATH vagrant plugin install vagrant-libvirt > > I don't know if those options are required, I came across them on > StackOverflow and kept using them after copying the library. > > > Alex