2 ms·

1) It is great that snapshots are on their way. I am looking forward to use them. All in all you cannot benefit from them in Cinder right now. 2) I dont claim

1) It is great that snapshots are on their way. I am looking forward to use them. All in all you cannot benefit from them in Cinder right now. 2) I dont claim that all bricks must be specified in mount command. I just point out that having let's say 4 bricks it is impossible to mount volume by specifing only 2 servers if both of them are down, yet still the rest 2 work. 3) Like I wrote. It only considers CLI. 4) I totally agree with you. Mounting volume from many locations is one of advantages. It is not supported by Openstack. I dont blame GlusterFS for that. 5) My intension was not to describe GlusterFS cool features but current state (and preview of Openstack Havana implementation) of integration with Openstack.

notacoward 13y ago
(1) You can in some configurations. If you use qemu there's a block-device driver in qemu and another on the GlusterFS back end (as of 3.4), which both allow snapshots via methods external to us. I meant what I said about it being a hard problem. We're determined to deliver a general snapshot function. That's much harder than delivering snapshots that rely on an uncommon and/or unstable base technology, so it's taking a while. (2) Yes, if you want to survive N concurrent failures you need N+1 mount servers, and currently released code only supports N=1. However, http://review.gluster.org/#/c/5400/ http://review.gluster.org/#/c/5400/ has already been merged and will be available in the next release. (3) IMO you should also have mentioned that the problem only manifests in a specific deprecated use of the CLI (from machines other than the servers). Nonetheless, this is a known deficiency which I've been personally pushing to fix. (5) The current state includes many of these "cool features" (thanks!) without need for any specific OpenStack integration. That's kind of the point. Unlike some, we don't need to re-implement features for every access method or use case. 90% of that functionality would be available e.g. to CloudStack or OpenNebula today. IMO making a big deal of snapshots as a differentiator in one direction without mentioning myriad differentiators in the other doesn't leave people with the information they need to make progress toward their own decisions.
- mgalkiewicz 13y ago
  1) Nobody says it is easy. I keep my fingers crossed for this feature. 2) Exactly. I have pointed out this ticket. When do you think it will be available and in which version? 3) Unfortunately, I have not found any document where setting authentication other than IP based is described. I would like to set it through openstack and by hand. Is it possible? 5) Of course it is great that most features do not require any specific OpenStack integration. I just wanted to describe those that need it. It mostly shows what needs to be done in Openstack.
  - notacoward 13y ago
    (2) It'll automatically be in 3.5 approximately the end of this year. It will probably also be backported into the next 3.4.x, but I can't comment on schedules either for that or for the "downstream" Red Hat Storage releases. (3) I don't know of any such instructions off the top of my head. Basically you'll have to edit /etc/glusterfs/glusterd.vol and add by hand the same auth options that are available for volumes via the CLI. I think there are (possibly hidden) CLI options that you'd need to specify username/password to work with that. If you try it and things aren't seeming fairly obvious, feel free to ping me via email (jdarcy@myemployer.com) or Freenode IRC.
    - mgalkiewicz 13y ago
      (3) I would definitely like to avoid modifying files by hand. I knew about this method but it just does not work for me. I am automatically creating many volumes with cli and modifying them in configuration file is not convenient. I guess it is also not possible for cinder devs to implement it reasonably well.
      - notacoward 13y ago
        You're opposed to manipulating config files by hand, but you recommend Ceph over GlusterFS? Interesting.
        13y ago

notacoward 13y ago

(1) You can in some configurations. If you use qemu there's a block-device driver in qemu and another on the GlusterFS back end (as of 3.4), which both allow snapshots via methods external to us. I meant what I said about it being a hard problem. We're determined to deliver a general snapshot function. That's much harder than delivering snapshots that rely on an uncommon and/or unstable base technology, so it's taking a while. (2) Yes, if you want to survive N concurrent failures you need N+1 mount servers, and currently released code only supports N=1. However, http://review.gluster.org/#/c/5400/ http://review.gluster.org/#/c/5400/ has already been merged and will be available in the next release. (3) IMO you should also have mentioned that the problem only manifests in a specific deprecated use of the CLI (from machines other than the servers). Nonetheless, this is a known deficiency which I've been personally pushing to fix. (5) The current state includes many of these "cool features" (thanks!) without need for any specific OpenStack integration. That's kind of the point. Unlike some, we don't need to re-implement features for every access method or use case. 90% of that functionality would be available e.g. to CloudStack or OpenNebula today. IMO making a big deal of snapshots as a differentiator in one direction without mentioning myriad differentiators in the other doesn't leave people with the information they need to make progress toward their own decisions.

mgalkiewicz 13y ago
1) Nobody says it is easy. I keep my fingers crossed for this feature. 2) Exactly. I have pointed out this ticket. When do you think it will be available and in which version? 3) Unfortunately, I have not found any document where setting authentication other than IP based is described. I would like to set it through openstack and by hand. Is it possible? 5) Of course it is great that most features do not require any specific OpenStack integration. I just wanted to describe those that need it. It mostly shows what needs to be done in Openstack.
- notacoward 13y ago
  (2) It'll automatically be in 3.5 approximately the end of this year. It will probably also be backported into the next 3.4.x, but I can't comment on schedules either for that or for the "downstream" Red Hat Storage releases. (3) I don't know of any such instructions off the top of my head. Basically you'll have to edit /etc/glusterfs/glusterd.vol and add by hand the same auth options that are available for volumes via the CLI. I think there are (possibly hidden) CLI options that you'd need to specify username/password to work with that. If you try it and things aren't seeming fairly obvious, feel free to ping me via email (jdarcy@myemployer.com) or Freenode IRC.
  - mgalkiewicz 13y ago
    (3) I would definitely like to avoid modifying files by hand. I knew about this method but it just does not work for me. I am automatically creating many volumes with cli and modifying them in configuration file is not convenient. I guess it is also not possible for cinder devs to implement it reasonably well.
    - notacoward 13y ago
      You're opposed to manipulating config files by hand, but you recommend Ceph over GlusterFS? Interesting.
      - 13y ago