Description of problem: If the changelog is off while doing the geo-rep create, there should be a warning issued to the user, or should fail or should enable the changelog itself if it's off. Version-Release number of selected component (if applicable): glusterfs-3.4.0.14rhs-1.el6rhs.x86_64 How reproducible: Always Steps to Reproduce: 1. Create master and slave volume with both 2*2 distributed configuration. 2. Now disable changelog in master. #gluster v set master_vol changelog off 3. Now try to create the session using the geo-rep create #gluster v geo master_vol slave_node::slave_vol create Actual results: The geo-rep create succeeds even if the changelog is off. Expected results: Ideally it should throw out a warning message or should fail saying that changelog is disabled or should take care of enabling the changelog by itself. Additional info: Even if we're going to document it saying that changelog should be enabled, we need this enhancement sometime in future. Checking for the status of changelog and taking care of enabling it is fairly simple IMHO.
Geo-Replication start "enables" changelog. Why is it needed to be shown in create phase? It's an internal change detection mechanism.
(In reply to Venky Shankar from comment #2) > Geo-Replication start "enables" changelog. > > Why is it needed to be shown in create phase? It's an internal change > detection mechanism. I thought "geo-rep create" is the right place enable the chanelog, if not enabled already by user.
There is no pressing need to enable "changelog" during the create phase. Please reopen this bug if there is any.