When using the module without puppetdb approach, it fails the second and consecutive times the puppet agent is run, with following error message: ------------------ Error: /sbin/mkfs.xfs -q -f -i size=512 -n size=8192 -d su=256k,sw=10 /dev/vg_f1-glu3.os.tst+_glance/lv_f1-glu3.os.tst+_glance && /usr/sbin/xfs_admin -U '4bacfc2c-1d61-4a5d-8e2c-081d59555ac5' /dev/vg_f1-glu3.os.tst+_glance/lv_f1-glu3.os.tst+_glance returned 1 instead of one of [0] Error: /Stage[main]/Quickstack::Gluster::Server/Gluster::Brick[f1-glu3.os.tst:/glance]/Exec[/sbin/mkfs.xfs -q -f -i size=512 -n size=8192 -d su=256k,sw=10 /dev/vg_f1-glu3.os.tst+_glance/lv_f1-glu3.os.tst+_glance && /usr/sbin/xfs_admin -U '4bacfc2c-1d61-4a5d-8e2c-081d59555ac5' /dev/vg_f1-glu3.os.tst+_glance/lv_f1-glu3.os.tst+_glance]/returns: change from notrun to 0 failed: /sbin/mkfs.xfs -q -f -i size=512 -n size=8192 -d su=256k,sw=10 /dev/vg_f1-glu3.os.tst+_glance/lv_f1-glu3.os.tst+_glance && /usr/sbin/xfs_admin -U '4bacfc2c-1d61-4a5d-8e2c-081d59555ac5' /dev/vg_f1-glu3.os.tst+_glance/lv_f1-glu3.os.tst+_glance returned 1 instead of one of [0] ------------------- Because the puppet agent has to be launched several time in round robin fashion, a workaround is to make following true, in order to go through: https://github.com/purpleidea/puppet-gluster/blob/master/manifests/brick.pp#L469
(In reply to Gilles Dubreuil from comment #0) > When using the module without puppetdb approach, it fails the second and > consecutive times the puppet agent is run, with following error message: > > ------------------ > Error: /sbin/mkfs.xfs -q -f -i size=512 -n size=8192 -d su=256k,sw=10 > /dev/vg_f1-glu3.os.tst+_glance/lv_f1-glu3.os.tst+_glance && > /usr/sbin/xfs_admin -U '4bacfc2c-1d61-4a5d-8e2c-081d59555ac5' > /dev/vg_f1-glu3.os.tst+_glance/lv_f1-glu3.os.tst+_glance returned 1 instead > of one of [0] > Error: > /Stage[main]/Quickstack::Gluster::Server/Gluster::Brick[f1-glu3.os.tst:/ > glance]/Exec[/sbin/mkfs.xfs -q -f -i size=512 -n size=8192 -d su=256k,sw=10 > /dev/vg_f1-glu3.os.tst+_glance/lv_f1-glu3.os.tst+_glance && > /usr/sbin/xfs_admin -U '4bacfc2c-1d61-4a5d-8e2c-081d59555ac5' > /dev/vg_f1-glu3.os.tst+_glance/lv_f1-glu3.os.tst+_glance]/returns: change > from notrun to 0 failed: /sbin/mkfs.xfs -q -f -i size=512 -n size=8192 -d > su=256k,sw=10 /dev/vg_f1-glu3.os.tst+_glance/lv_f1-glu3.os.tst+_glance && > /usr/sbin/xfs_admin -U '4bacfc2c-1d61-4a5d-8e2c-081d59555ac5' > /dev/vg_f1-glu3.os.tst+_glance/lv_f1-glu3.os.tst+_glance returned 1 instead > of one of [0] > ------------------- > > Because the puppet agent has to be launched several time in round robin > fashion, a workaround is to make following true, in order to go through: > https://github.com/purpleidea/puppet-gluster/blob/master/manifests/brick. > pp#L469 In this type of scenario, when you get a consistent failure, what I do is this: I copy+paste from the above message the exact command run. In this case it is: /sbin/mkfs.xfs -q -f -i size=512 -n size=8192 -d su=256k,sw=10 /dev/vg_f1-glu3.os.tst+_glance/lv_f1-glu3.os.tst+_glance && /usr/sbin/xfs_admin -U '4bacfc2c-1d61-4a5d-8e2c-081d59555ac5' /dev/vg_f1-glu3.os.tst+_glance/lv_f1-glu3.os.tst+_glance In this case it is a compound command, so I split it up: /sbin/mkfs.xfs -q -f -i size=512 -n size=8192 -d su=256k,sw=10 /dev/vg_f1-glu3.os.tst+_glance/lv_f1-glu3.os.tst+_glance AND /usr/sbin/xfs_admin -U '4bacfc2c-1d61-4a5d-8e2c-081d59555ac5' /dev/vg_f1-glu3.os.tst+_glance/lv_f1-glu3.os.tst+_glance Then I run the first piece (the mkfs). Please paste the stdout/stderr and the exit code. If it is non-zero, that's the problem. Please let me know what it is so I can fix this scenario or identify it. Step two: if the first piece was okay, I then run the second piece. This sets the UUID for the XFS file system. This is very important so that Puppet-Gluster knows that it made the filesystem. If there are any errors, please paste exit code, and stdout/stderr. This might seem like a bit of a PITA, but it's how we'll understand/solve the issue. I'll either patch the issue, or we'll add a documentation patch to explain the occurence if needed.
@James, The first bit fails because the partition is already mounted. The output is actually available here: https://bugzilla.redhat.com/show_bug.cgi?id=1075766#c28 This is why I did force the Exec class to fail by adding "unless => /bin/true" After searching a bit, it seems it shouldn't go that far if dm has the corresponding uuid fs advertized. But I haven't traced it further yet. One thing I noticed though, LVM volume groups seems not always activated and had to run "vgchange -ay" to resync.
(In reply to Gilles Dubreuil from comment #2) > @James, Hey Gilles... > > The first bit fails because the partition is already mounted. > The output is actually available here: > https://bugzilla.redhat.com/show_bug.cgi?id=1075766#c28 But but but... WHY is anything already mounted? There isn't supposed to be anything on the server before Puppet runs. It's dirty from an old run!! Or am I missing something?? > > This is why I did force the Exec class to fail by adding "unless => > /bin/true" ? If you add this, then the exec will NEVER run. > > After searching a bit, it seems it shouldn't go that far if dm has the > corresponding uuid fs advertized. But I haven't traced it further yet. ? > > One thing I noticed though, LVM volume groups seems not always activated and > had to run "vgchange -ay" to resync. This is the same issue as WHY is something already there...
Hi James, As I already said, here's the work-flow: 1. Fresh install, no partition defined or mounted, only physical devices (/dev/vdb, etc) 2. First puppet run works fine 3. Partitions are now mounted but there is no gluster volume yet 4. Second (or any consecutive) puppet run fails because the partition is mounted. The workaround I mentioned is not a fix at all, it's just to get passed point 4 and be able to continue.
Part of the issue seems to be related to fsuuid not matching between creation time and consecutive passes. Which blocks finding out if /dev/disk/by-uuid partition exists, then exec mkfs always run and that fails because the partition is mounted. But that cannot be the default otherwise mkfs will never run in the first place To progress, I forced each fsuiid in gluster::brick with a unique and static value. I then was blocked by a "valid uuid" test bug: https://github.com/purpleidea/puppet-gluster/blob/master/manifests/brick.pp#L86 The above regex works in ruby but fails for me with puppet. For moving on I commented out the fail call: https://github.com/purpleidea/puppet-gluster/blob/master/manifests/brick.pp#L87 That pass, but the overall still doesn't work: Here are disk uuids # ls -l /dev/disk/by-uuid/ lrwxrwxrwx. 1 root root 10 Apr 16 02:11 072eb352-8035-4bcf-bf32-4271992c9630 -> ../../dm-1 lrwxrwxrwx. 1 root root 10 Apr 16 01:55 b2d8a80d-db41-4cbf-84a2-34a0b782c89c -> ../../vda1 lrwxrwxrwx. 1 root root 10 Apr 16 02:11 c9c6d709-e956-40ba-be84-a461543e3f7a -> ../../dm-0 lrwxrwxrwx. 1 root root 10 Apr 16 02:11 dddbcb95-90c0-4d67-be32-1a4a2e32b494 -> ../../dm-2 Unless I those fsuuid are not supposed to match, then I'm wrong: Notice: /Stage[main]/Quickstack::Gluster::Server/Gluster::Brick[f1-glu1.os.tst:/glance]/Notify[=====>>>>> a00b34d1-a5e0-4723-981c-f51ed4815f65]/message: defined 'message' as '=====>>>>> a00b34d1-a5e0-4723-981c-f51ed4815f65' Notice: =====>>>>> 50ec0bf5-447e-49e4-813d-66367df7994d Notice: /Stage[main]/Quickstack::Gluster::Server/Gluster::Brick[f1-glu1.os.tst:/swift]/Notify[=====>>>>> 50ec0bf5-447e-49e4-813d-66367df7994d]/message: defined 'message' as '=====>>>>> 50ec0bf5-447e-49e4-813d-66367df7994d' Notice: =====>>>>> d2f7e17b-974c-4b06-a229-9d282d1425fe Notice: /Stage[main]/Quickstack::Gluster::Server/Gluster::Brick[f1-glu1.os.tst:/cinder]/Notify[=====>>>>> d2f7e17b-974c-4b06-a229-9d282d1425fe]/message: defined 'message' as '=====>>>>> d2f7e17b-974c-4b06-a229-9d282d1425fe' The following workaround fails the exec if the partition is already mounted: Adding to https://github.com/purpleidea/puppet-gluster/blob/master/manifests/brick.pp#L468 this line: "/usr/bin/test -e ${dev2}", That's not ideal but works. Meanwhile afterward the gluster volume are not present but all layers underneath are present. So I'm re-testing with dynamic fsuuid But the testing turned slow because of intermediate runs using already define fsuuid values, therefore the need to rebuild all storage machines.
Need to have firewall manually setup to either: - gluster puncholes - off because puppet-gluster supports only Shorewall, see https://bugzilla.redhat.com/show_bug.cgi?id=1087173
command vgchange -ay was needed between puppet runs on 3 storage servers tested But the volumes are availables: --------------------------------------- [root@f1-glu3 ~]# gluster volume info Volume Name: swift Type: Distributed-Replicate Volume ID: be7cea30-6610-467f-8c14-f55808d14240 Status: Started Number of Bricks: 3 x 3 = 9 Transport-type: tcp Bricks: Brick1: f1-glu1.os.tst:/cinder/swift Brick2: f1-glu2.os.tst:/cinder/swift Brick3: f1-glu3.os.tst:/cinder/swift Brick4: f1-glu1.os.tst:/glance/swift Brick5: f1-glu2.os.tst:/glance/swift Brick6: f1-glu3.os.tst:/glance/swift Brick7: f1-glu1.os.tst:/swift/swift Brick8: f1-glu2.os.tst:/swift/swift Brick9: f1-glu3.os.tst:/swift/swift Options Reconfigured: network.remote-dio: enable cluster.server-quorum-type: server cluster.eager-lock: on performance.read-ahead: off performance.quick-read: off cluster.quorum-type: auto performance.stat-prefetch: off performance.io-cache: off Volume Name: cinder Type: Distributed-Replicate Volume ID: bac59a04-76de-4f35-b193-eb7e68c303d1 Status: Started Number of Bricks: 3 x 3 = 9 Transport-type: tcp Bricks: Brick1: f1-glu1.os.tst:/cinder/cinder Brick2: f1-glu2.os.tst:/cinder/cinder Brick3: f1-glu3.os.tst:/cinder/cinder Brick4: f1-glu1.os.tst:/glance/cinder Brick5: f1-glu2.os.tst:/glance/cinder Brick6: f1-glu3.os.tst:/glance/cinder Brick7: f1-glu1.os.tst:/swift/cinder Brick8: f1-glu2.os.tst:/swift/cinder Brick9: f1-glu3.os.tst:/swift/cinder Options Reconfigured: storage.owner-uid: 161 performance.io-cache: off cluster.server-quorum-type: server network.remote-dio: enable storage.owner-gid: 161 performance.stat-prefetch: off performance.quick-read: off cluster.quorum-type: auto performance.read-ahead: off cluster.eager-lock: on Volume Name: glance Type: Distributed-Replicate Volume ID: 0bfbd91f-6608-4091-9995-11a05300a343 Status: Started Number of Bricks: 3 x 3 = 9 Transport-type: tcp Bricks: Brick1: f1-glu1.os.tst:/cinder/glance Brick2: f1-glu2.os.tst:/cinder/glance Brick3: f1-glu3.os.tst:/cinder/glance Brick4: f1-glu1.os.tst:/glance/glance Brick5: f1-glu2.os.tst:/glance/glance Brick6: f1-glu3.os.tst:/glance/glance Brick7: f1-glu1.os.tst:/swift/glance Brick8: f1-glu2.os.tst:/swift/glance Brick9: f1-glu3.os.tst:/swift/glance ------------------------------------
Submitted following Pull Request: https://github.com/purpleidea/puppet-gluster/pull/12
(In reply to Gilles Dubreuil from comment #8) > Submitted following Pull Request: > https://github.com/purpleidea/puppet-gluster/pull/12 Hi Gilles, my biggest issue with this patch is that it's not clear to me _WHY_ the UUID's aren't showing up correctly. I suspect it's something wrong with your test environment. I don't want to just patch something to cover up a different underlying bug. In any case, to aid your testing, I've written a patch: https://github.com/purpleidea/puppet-gluster/tree/bug/gilles Please test and let me know if this helps. It's basically similar to yours, except uses findmnt for simplicity and scriptability.
Hi James, 1. "Why UUIDs are not working?". Agreed, this is the real question. I understand your concern about patching an underlying bug, meanwhile my test environment is automatically generated based on RHEL6.5+ and RHOS4.3+. I'm using raw LVM slices underneath provided to virtual instances as extra disks. Therefore I don't really see what could be wrong there. Maybe such path has never been tested before (?). Although not likely a real scenario production environment it worth having it working because of dev/test/CI/nested environments anyway. 2. Many Puppet exec resource statements I hope not to hurt purpleidea feelings too much with this, but tracing purpleidea/puppet-gluster is challenging. I mean beyond normal learning curve of getting used to the module implementation, which, don't get me wrong, I think makes great use of Puppet. The reason has mostly to do with many Exec[] statements. Effectively, Puppet standards recommends to encapsulate/replace 'exec' to provide Puppet resources. I understand this is not going to be addressed overnight but this is something to keep in mind. I'm thinking on the long run of maintaining this for our customers/users. Besides, it will also give the module a chance to move higher upstream. 3. Patch I'm happy to use the findmnt alternative, "simplicity and scriptability" is a viewpoint, again this goes directly to exec comment above. Validation is in progress.
(In reply to Gilles Dubreuil from comment #10) > Hi James, > > > 1. "Why UUIDs are not working?". > > Agreed, this is the real question. > > I understand your concern about patching an underlying bug, meanwhile my > test environment is automatically generated based on RHEL6.5+ and RHOS4.3+. > I'm using raw LVM slices underneath provided to virtual instances as extra > disks. Therefore I don't really see what could be wrong there. > Maybe such path has never been tested before (?). > Although not likely a real scenario production environment it worth having > it working because of dev/test/CI/nested environments anyway. I'll be getting some real hardware to test puppet-gluster shortly, so I'll have a chance to test this myself. If you can describe your environment better it might help me understand what you're doing. > > > 2. Many Puppet exec resource statements > > I hope not to hurt purpleidea feelings too much with this, but tracing > purpleidea/puppet-gluster is challenging. I mean beyond normal learning > curve of getting used to the module implementation, which, don't get me > wrong, I think makes great use of Puppet. The reason has mostly to do with > many Exec[] statements. It is a complex module. That's because distributed puppet is complex :) > > Effectively, Puppet standards recommends to encapsulate/replace 'exec' to > provide Puppet resources. > > I understand this is not going to be addressed overnight but this is > something to keep in mind. I'm thinking on the long run of maintaining this > for our customers/users. > > Besides, it will also give the module a chance to move higher upstream. It's not clear what recommendation you're making here... > > 3. Patch > > I'm happy to use the findmnt alternative, "simplicity and scriptability" is > a viewpoint, again this goes directly to exec comment above. > > Validation is in progress. Sounds good! I'll put the needinfo flag back. Clear it when this patch solves your issue, or it doesn't and you have more info on the bug. Thanks, James
(In reply to James from comment #11) > > 1. "Why UUIDs are not working?". > I'll be getting some real hardware to test puppet-gluster shortly, so I'll > have a chance to test this myself. If you can describe your environment > better it might help me understand what you're doing. > > 2. Many Puppet exec resource statements .../.. > It's not clear what recommendation you're making here... My recommendation would be to have less 'exec {'':}' statements by encapsulating them in customized resources/functions. > > 3. Patch .../... > Sounds good! I'll put the needinfo flag back. Clear it when this patch > solves your issue, or it doesn't and you have more info on the bug. > Unfortunately findmnt has a different path on RHEL6 so that breaks: ------------------------- # cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.5 (Santiago) # which findmnt /bin/findmnt ------------------------- Meanwhile using /bin/findmnt instead works and bypasses the mkfs_exec. At least my patch works in both Fedora and RHEL ;). That said I consider both patches ugly because not puppetized. One more thing, I had to manually run "vgchange -ay" on all storage servers to make the LVM volumes effective. I've seen that before (I think I mentioned it somewhere). This is an inconsistent issue, sometimes the puppet agent won't need such refresh. Have you seen that before? What do you think? Would it be possible to add the vgchange at the end of the LVM section? => New BZ? Regards, Gilles
(In reply to Gilles Dubreuil from comment #12) > (In reply to James from comment #11) > > > It's not clear what recommendation you're making here... > > My recommendation would be to have less 'exec {'':}' statements by > encapsulating them in customized resources/functions. I looked at doing this a while back, and I don't think it would be an improvement, as well, there are rumours (maybe facts?) that the puppet extensions bits will change or disappear from their ruby mess... Keeping it as declarative Puppet DSL ensures the actions are safer (less chance of a programming error) and stable. > > > > > 3. Patch > .../... > > Sounds good! I'll put the needinfo flag back. Clear it when this patch > > solves your issue, or it doesn't and you have more info on the bug. > > > Unfortunately findmnt has a different path on RHEL6 so that breaks: > ------------------------- > # cat /etc/redhat-release > Red Hat Enterprise Linux Server release 6.5 (Santiago) > # which findmnt > /bin/findmnt > ------------------------- Woops! Good catch thanks. Fixed (rebased) in branch. https://github.com/purpleidea/puppet-gluster/tree/bug/gilles > > Meanwhile using /bin/findmnt instead works and bypasses the mkfs_exec. > At least my patch works in both Fedora and RHEL ;). > That said I consider both patches ugly because not puppetized. What does it mean "not puppetized" ? This is of course puppet code... > > One more thing, I had to manually run "vgchange -ay" on all storage servers > to make the LVM volumes effective. > I've seen that before (I think I mentioned it somewhere). > This is an inconsistent issue, sometimes the puppet agent won't need such > refresh. This sounds like ghosts... Why would this possibly be necessary. It sounds like a symptom of an unclean setup which I mentioned earlier in this bug. > > Have you seen that before? Nope. > What do you think? I think it's a problem with your environment. > Would it be possible to add the vgchange at the end of the LVM section? > => New BZ? Please open a new BZ if you continue to see this issue. Please include *detailed* information about your environment setup and how to create this issue. Record a screencast if you need to. > > Regards, > Gilles Cheers, James PS: It's fun to have someone else running my code and finding bugs (not that there are any though... bwahaha)... I just got two BAGL servers allocated to me, and the puppet master VM is coming shortly, so I should expect to be able to test these exact issues alongside you soon! :)
(In reply to James from comment #13) > Woops! Good catch thanks. Fixed (rebased) in branch. > https://github.com/purpleidea/puppet-gluster/tree/bug/gilles > > That fix looks good for RHEL6, which will make RHOS/RDO happy on those platforms. Unfortunately that won't work on Fedora or either RHEL7 because those are using /usr/bin/findmnt as your first patch suggested. > > > It's not clear what recommendation you're making here... > > > > My recommendation would be to have less 'exec {'':}' statements by > > encapsulating them in customized resources/functions. > > I looked at doing this a while back, and I don't think it would be an > improvement, as well, there are rumours (maybe facts?) that the puppet > extensions bits will change or disappear from their ruby mess... I'm not following you with the puppet extensions bits, could you please develop? +1 for "their ruby mess"! > Keeping it as declarative Puppet DSL ensures the actions are safer (less > chance of a programming error) and stable. > Sorry but that doesn't make sense to me. I would say the 'exec {}' resource call is DSL but definitely not its content. The best current example we have is the findmnt issue above! A provider would be able to handle the different platforms, please see below. > > What does it mean "not puppetized" ? This is of course puppet code... As you said, Puppet is DSL, which idea is to encapsulate pretty much everything as packages, configuration or services. Running commands via 'exec' is not considered DSL and therefore what I meant by 'not puppetized', maybe not the best term, sorry for the confusion. Nevertheless, the idea is to encapsulate commands using types/providers: http://www.slideshare.net/PuppetLabs/replacing-exec-16297381 or http://spin.atomicobject.com/2012/09/13/from-imperative-to-declarative-system-configuration-with-puppet/ Re 'vgchange' issue: Yeah, vgchange shouldn't be needed after VG or LV creations, at least according to RHEL4/5/6 manuals > Please open a new BZ if you continue to see this issue. Please include > *detailed* information about your environment setup and how to create this > issue. Will, do. > > PS: It's fun to have someone else running my code and finding bugs (not that > there are any though... bwahaha)... I just got two BAGL servers allocated to > me, and the puppet master VM is coming shortly, so I should expect to be > able to test these exact issues alongside you soon! :) Sounds good, :) Thanks, Gilles
(In reply to Gilles Dubreuil from comment #14) > > That fix looks good for RHEL6, which will make RHOS/RDO happy on those > platforms. > Unfortunately that won't work on Fedora or either RHEL7 because those are > using /usr/bin/findmnt as your first patch suggested. Quite true! At the moment, only CentOS/RHEL 6 is supported. I actually have a private branch to support multi distro/version things, but it's not ready yet. It's using a pretty cool new technique. If you need the multi version support, please open a BZ and let me know a timeframe please :) > > I'm not following you with the puppet extensions bits, could you please > develop? > +1 for "their ruby mess"! > > > Keeping it as declarative Puppet DSL ensures the actions are safer (less > > chance of a programming error) and stable. > > > Sorry but that doesn't make sense to me. > I would say the 'exec {}' resource call is DSL but definitely not its > content. > The best current example we have is the findmnt issue above! > A provider would be able to handle the different platforms, please see below. This is a longer conversation, and is really out of scope for this BZ thread. Feel free to give me a ring or ping me offline if you want to chat more about it. > > > > > What does it mean "not puppetized" ? This is of course puppet code... > > As you said, Puppet is DSL, which idea is to encapsulate pretty much > everything as packages, configuration or services. > Running commands via 'exec' is not considered DSL and therefore what I meant > by 'not puppetized', maybe not the best term, sorry for the confusion. > Nevertheless, the idea is to encapsulate commands using types/providers: > http://www.slideshare.net/PuppetLabs/replacing-exec-16297381 > or > http://spin.atomicobject.com/2012/09/13/from-imperative-to-declarative- > system-configuration-with-puppet/ I know the technique. I just don't believe it's an improvement in most cases. Again, this is out of scope for this bug. > > > Re 'vgchange' issue: > > Yeah, vgchange shouldn't be needed after VG or LV creations, at least > according to RHEL4/5/6 manuals > > > Please open a new BZ if you continue to see this issue. Please include > > *detailed* information about your environment setup and how to create this > > issue. > > Will, do. > > > > > > PS: It's fun to have someone else running my code and finding bugs (not that > > there are any though... bwahaha)... I just got two BAGL servers allocated to > > me, and the puppet master VM is coming shortly, so I should expect to be > > able to test these exact issues alongside you soon! :) > > Sounds good, :) > > Thanks, > Gilles
Unless you have any objections, I'm going to close *this* bug.
(In reply to James from comment #15) > Quite true! At the moment, only CentOS/RHEL 6 is supported. I actually have > a private branch to support multi distro/version things, but it's not ready > yet. It's using a pretty cool new technique. If you need the multi version > support, please open a BZ and let me know a timeframe please :) A bit surprised here. Yes, puppet-gluster's readme, in the limitations sections, says it's not tested, doesn't mean it doesn't work. Also that's confusing, haven't you mentioned Fedora many times, as the current test platform, including in regards of Vagrant? So if Fedora 20 (and basically RHEL7 which is pretty close to) works (but not officially tested) why not simply use my patch which is platform independent? (In reply to James from comment #16) > Unless you have any objections, I'm going to close *this* bug. Please wait before closing it, this has many implication. Need to get ack on BZ#1075766 (don't want to create a BZ dead loop dependency though!)
(In reply to Gilles Dubreuil from comment #17) > (In reply to James from comment #15) > > > Quite true! At the moment, only CentOS/RHEL 6 is supported. I actually have > > a private branch to support multi distro/version things, but it's not ready > > yet. It's using a pretty cool new technique. If you need the multi version > > support, please open a BZ and let me know a timeframe please :) > > A bit surprised here. Oh, sorry. For the last year+ puppet-gluster has been my personal hack project. Only recently is RedHat officially using it. Please give me some time before it's "truly" "supported" on all the platforms/versions. > > Yes, puppet-gluster's readme, in the limitations sections, says it's not > tested, doesn't mean it doesn't work. Correct. It most likely works in many places I don't test. > > Also that's confusing, haven't you mentioned Fedora many times, as the > current test platform, including in regards of Vagrant? I use F20 as the vagrant HOST. I use CentOS 6.x as the vm os which runs gluster+puppet-gluster. > > So if Fedora 20 (and basically RHEL7 which is pretty close to) works (but > not officially tested) why not simply use my patch which is platform > independent? > > (In reply to James from comment #16) > > Unless you have any objections, I'm going to close *this* bug. > > Please wait before closing it, this has many implication. Okay. Please leave the "needinfo" until I can close. Thanks. > > Need to get ack on BZ#1075766 (don't want to create a BZ dead loop > dependency though!)
Please, let me know if you're going to merge this patch to trunk/head? https://github.com/purpleidea/puppet-gluster/tree/bug/gilles ? I suppose so since this works on RHEL6/CentOS. BTW, could you please answer previous question about why not using other patch which will also work on RHEL7/Fedora and therefore avoiding extra effort down the road? I'm moving the part about RHEL6/7 and Fedora support to BZ#1075766 because this is out of scope.
(In reply to Gilles Dubreuil from comment #19) > Please, let me know if you're going to merge this patch to trunk/head? > > https://github.com/purpleidea/puppet-gluster/tree/bug/gilles ? Once I have tested it (don't have an env yet) and once I have information on your env. See comment #9, #11, etc... As I said, I'm interested in tracking down the root cause of the bug, not just masking it. That is what git master for an _upstream_ project is for. Typically upstream can == downstream in most cases, but not for this particular patch, yet. > > I suppose so since this works on RHEL6/CentOS. > > BTW, could you please answer previous question about why not using other > patch which will also work on RHEL7/Fedora and therefore avoiding extra > effort down the road? They're two unrelated issues. See: https://bugzilla.redhat.com/show_bug.cgi?id=1087177#c9 > > I'm moving the part about RHEL6/7 and Fedora support to BZ#1075766 because > this is out of scope.
(In reply to James from comment #23) > Great! So it solves your issue? Yes the patch works but it hasn't made its way to any puppet-gluster master or rhs branch. The bug/gilles needs to be merged. We don't want to have O-P-M flapping branches as it makes more sense to stik the submodule to head of a specific (or master) branch. > The reason I ask, was because I wanted to close this bug, but you had > objected. > How should I proceed? As above, could you please make the merge and let me know so I can update O-P-M submodule? > Yeah, I get that! If it helps, I did a bunch of coding this weekend to help > get ahead of some of these issues, eg: > https://github.com/pradels/vagrant-libvirt/pull/178 I've sent a contact details that might help. Thanks, Gilles
(In reply to Gilles Dubreuil from comment #24) > (In reply to James from comment #23) > > > Great! So it solves your issue? > > Yes the patch works but it hasn't made its way to any puppet-gluster master > or rhs branch. > The bug/gilles needs to be merged. > We don't want to have O-P-M flapping branches as it makes more sense to stik > the submodule to head of a specific (or master) branch. Merged! https://github.com/purpleidea/puppet-gluster/commit/80c2b13448c97c70a4b4bc0e402e00ecb5d681d5 Keep in mind: submodules don't track a branch, they track a specific commit SHA1. Eg: 80c2b... So having the OPM module point to the unmerged branch, or to git master actually is irrelevant. They're both identical and they both point to the SHA1 (which is based on the _data). > > > > The reason I ask, was because I wanted to close this bug, but you had > > objected. > > How should I proceed? > > As above, could you please make the merge and let me know so I can update > O-P-M submodule? > > > Yeah, I get that! If it helps, I did a bunch of coding this weekend to help > > get ahead of some of these issues, eg: > > https://github.com/pradels/vagrant-libvirt/pull/178 > > I've sent a contact details that might help. > > Thanks, > Gilles Cheers+Happy hacking! *closed*