|
On 06/27/2013 12:34 PM, Kanagaraj M
wrote:
Right, I forgot the fact that gluster clis are executed thru super-vdsm, so non-priv / insecure issue won't be present. But the VDSM usecase still is a issue... when VDSM host (hypervisor node) is not a gluster peer, we need a way to set the glusterd option... currently one has to do that manually, which is not a good choice.
So, as i see it, there are couple of scenarios.... from VDSM perspective... For the sake of discussion, lets say VDSM (aka hypervisor host) is hostA & Gluster node/host is hostB. Case 1: hostA is not a gluster peer. hostB is a gluster peer (obviously) , part of Gluster volume which is managed by oVirt Engine. hostA will access Gluster volume as non-root (as part of VM running on Gluster storage domain, using libgfapi). Since hostA is not a gluster peer but since the Gluster volume is managed by oVirt, it should be possible for the engine to first execute 'gluster peer set all rpc-auth-allow-insecure on the gluster volume, then ask VDSM to create the gluster storage domain. From the perspective of "User friendliness", its better to have User click on something like "Allow insecure access" or "Make this gluster volume work with VDSM Gluster storage domain" which will execute 'gluster peer set all ..insecure.. ' option, so that User is aware of enabling the insecure option, instead of engine doing it w/o User's knowledge as part of gluster storage domain flow. This should work and for this to happen seamless, the CLI support for setting glusterd is needed, so this usecase is covered. Case 2: hostA is not a gluster peer. hostB is a gluster peer (obviously), but the Gluster volume is not managed by oVirt. The same as Case 1 applies, with the exception that, since the Gluster volume is not managed by oVirt, engine cannot do 'gluster peer set all rpc-auth-allow-insecure'. Ther are again 2 sub-cases here ... 2a) Have the user import the gluster volume into oVirt, post which it becomes like Case 1... problem solved. 2b) For some reason, user doesn't want to import the gluster volume into oVirt.. in which case, the only way is for someone to _manually_ do 'gluster peer set all rpc-auth-allow-insecure' from one of the gluster peers, which is not a good thing since it involved manual intervention. One can argue that hostA can use --remote-host option and do 'gluster peer set all...', which will work today, but that would be insecure way of doing it, since you are allowing a non-peer to set insecure option for all peers. Also Mohan's another patch (http://review.gluster.org/#/c/5092/) adds support for IP based access control, which also disables any 'set' kind of actions using --remote-host, so --remote-host anyways won't be possible in VDSM once that patch is thru. Net, there is no way in VDSM to enable glusterd insecure option for this usecase. Case 3: hostA is a gluster peer. hostB is a gluster peer (obviously) , part of Gluster volume which is managed by oVirt Engine. Since oVirt is managing is gluster volume, the same as Case 1 applies Case 4: hostA is a gluster peer. hostB is a gluster peer (obviously) , but the Gluster volume is not managed by oVirt. (Someone manually set up the Gluster volume, using hypervisor hosts as peers, for using the un-used disk space on hyp host for storage) This is similar to Case 2, but since hostA and hostB are part of gluster peer, VDSM can do 'gluster peer set all ...insecure..' before creating storage domain. Problem happens, when new hosts are added to the datacentre which are not part of gluster peer. Note in a virt env. hosts can be dynamically added / remove. So when a VM backed by gluster storage domain migrates to a host that is not a gluster peer, this usecase is broken like in Case 2b To Summarize: 1) 'gluster peer set all ...insecure...' cli option will definitely help and it will help more if the oVirt Volumes tab provides an UI way of invoking this on User request. This will cover some usecases as desc above 2) Case 2b & 4 - how to handle this scenario ? thanx, deepak
|
