Re: [Gluster-devel] context based defaults for volume options in glusterd
- Original Message - > > > On 09/01/2015 12:05 PM, Krishnan Parthasarathi wrote: > >>> Here are a few things that are not clear to me. > >>> > >>> 1) Does the context-based default value for an option comes into effect > >>> only when .value in vme table is NULL? > >> If there is context based default then the static default value should > >> be NULL is my feeling. > >>> 2) IIUC, the generated default value is applied to the volume files > >>> generated > >>> and persisted no place else. Is this correct? > >> Yes. > >>> 3) What happens if the context_based_default_get() is not available in > >>> all > >>> glusterds in the cluster? e.g, upgrade from 3.6 to 3.7.x (where this may > >>> land). > >>> Shouldn't this behaviour also be 'versioned' to prevent different volume > >>> files > >>> being served by different nodes of the cluster? > >> In the context_based_default_value_get() we can add the version checks > >> and generate it the way we want. > > Hmm. We have op-version for the options in vme table against which we > > ensure > > that all servers generate the same volume files. What versions would the > > context based default value generator functions use? I'd recommend > > documenting > > these details of the proposal and send a PR to gluster-specs repository. > > This needs to be reviewed carefully with all the details available in one > > place. > The version context based defaults will use is dependent on the version > the change needs to go into. We will do one thing. We will add this > proposal to the specs repo and as an example we will give the link to > the patch for afr quorum which implements this proposal. It will be very > similar to the current implementation Anuradha came up with absent > storing on gluster-store from op-version Point of view. > OK ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] context based defaults for volume options in glusterd
On 09/01/2015 12:05 PM, Krishnan Parthasarathi wrote: Here are a few things that are not clear to me. 1) Does the context-based default value for an option comes into effect only when .value in vme table is NULL? If there is context based default then the static default value should be NULL is my feeling. 2) IIUC, the generated default value is applied to the volume files generated and persisted no place else. Is this correct? Yes. 3) What happens if the context_based_default_get() is not available in all glusterds in the cluster? e.g, upgrade from 3.6 to 3.7.x (where this may land). Shouldn't this behaviour also be 'versioned' to prevent different volume files being served by different nodes of the cluster? In the context_based_default_value_get() we can add the version checks and generate it the way we want. Hmm. We have op-version for the options in vme table against which we ensure that all servers generate the same volume files. What versions would the context based default value generator functions use? I'd recommend documenting these details of the proposal and send a PR to gluster-specs repository. This needs to be reviewed carefully with all the details available in one place. The version context based defaults will use is dependent on the version the change needs to go into. We will do one thing. We will add this proposal to the specs repo and as an example we will give the link to the patch for afr quorum which implements this proposal. It will be very similar to the current implementation Anuradha came up with absent storing on gluster-store from op-version Point of view. Pranith ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] context based defaults for volume options in glusterd
> > Here are a few things that are not clear to me. > > > > 1) Does the context-based default value for an option comes into effect > > only when .value in vme table is NULL? > If there is context based default then the static default value should > be NULL is my feeling. > > > > 2) IIUC, the generated default value is applied to the volume files > > generated > > and persisted no place else. Is this correct? > Yes. > > > > 3) What happens if the context_based_default_get() is not available in all > > glusterds in the cluster? e.g, upgrade from 3.6 to 3.7.x (where this may > > land). > > Shouldn't this behaviour also be 'versioned' to prevent different volume > > files > > being served by different nodes of the cluster? > In the context_based_default_value_get() we can add the version checks > and generate it the way we want. Hmm. We have op-version for the options in vme table against which we ensure that all servers generate the same volume files. What versions would the context based default value generator functions use? I'd recommend documenting these details of the proposal and send a PR to gluster-specs repository. This needs to be reviewed carefully with all the details available in one place. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] context based defaults for volume options in glusterd
On 09/01/2015 11:55 AM, Krishnan Parthasarathi wrote: - Original Message - hi, Afr needs context based defaults for quorum where by default quorum value is 'none' for 2-way replica and 'auto' for 3 way replica. Anuradha sent http://review.gluster.org/11872 to fix the same. May be we can come up with more generic solution. The present solution remembers the default in volinfo->options and also written to the store. So the default will be shown in "volume info" output and if we want to change the defaults in future we will need to carefully think of all the things that could go wrong especially peers getting rejected because of the md5sum mismatch. Another way to solve the same problem is to generate the default value of the vme-option based on the context of the volume when we have to write to the volfile. In this particular case, we need to generate default as 'none' for 2-way-replica-count volume. and 'auto' for 3-replica-count volume. For volume-get command handling also we need to consider this dynamic default value. For implementing this, we can add a new member 'context_based_default_value_get()'(please feel free to come up with better name for the function :-) ) to the vme-table which can be invoked to get the default option which takes the volinfo as parameter at least, and not set .value i.e implicitly .value will be NULL. This is based on earlier design detail in the comment of vme-table: * Fourth field is . In this context they are used to specify * a default. That is, even the volume dict doesn't have a value, * we procced as if the default value were set for it. We just want to enhance the existing behavior with this proposed change. It seems more generic than the present solution in the patch. In future people can write their own implementations of context based default value generation following same procedure. Let me know your comments. Here are a few things that are not clear to me. 1) Does the context-based default value for an option comes into effect only when .value in vme table is NULL? If there is context based default then the static default value should be NULL is my feeling. 2) IIUC, the generated default value is applied to the volume files generated and persisted no place else. Is this correct? Yes. 3) What happens if the context_based_default_get() is not available in all glusterds in the cluster? e.g, upgrade from 3.6 to 3.7.x (where this may land). Shouldn't this behaviour also be 'versioned' to prevent different volume files being served by different nodes of the cluster? In the context_based_default_value_get() we can add the version checks and generate it the way we want. Pranith Pranith ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] context based defaults for volume options in glusterd
- Original Message - > hi, > Afr needs context based defaults for quorum where by default > quorum value is 'none' for 2-way replica and 'auto' for 3 way replica. > Anuradha sent http://review.gluster.org/11872 to fix the same. May be we > can come up with more generic solution. The present solution remembers > the default in volinfo->options and also written to the store. So the > default will be shown in "volume info" output and if we want to change > the defaults in future we will need to carefully think of all the things > that could go wrong especially peers getting rejected because of the > md5sum mismatch. Another way to solve the same problem is to generate > the default value of the vme-option based on the context of the volume > when we have to write to the volfile. In this particular case, we need > to generate default as 'none' for 2-way-replica-count volume. and 'auto' > for 3-replica-count volume. For volume-get command handling also we need > to consider this dynamic default value. For implementing this, we can > add a new member 'context_based_default_value_get()'(please feel free to > come up with better name for the function :-) ) to the vme-table which > can be invoked to get the default option which takes the volinfo as > parameter at least, and not set .value i.e implicitly .value will be NULL. > > This is based on earlier design detail in the comment of vme-table: > * Fourth field is . In this context they are used to specify > * a default. That is, even the volume dict doesn't have a value, > * we procced as if the default value were set for it. > > We just want to enhance the existing behavior with this proposed change. > It seems more generic than the present solution in the patch. In future > people can write their own implementations of context based default > value generation following same procedure. Let me know your comments. Here are a few things that are not clear to me. 1) Does the context-based default value for an option comes into effect only when .value in vme table is NULL? 2) IIUC, the generated default value is applied to the volume files generated and persisted no place else. Is this correct? 3) What happens if the context_based_default_get() is not available in all glusterds in the cluster? e.g, upgrade from 3.6 to 3.7.x (where this may land). Shouldn't this behaviour also be 'versioned' to prevent different volume files being served by different nodes of the cluster? > > Pranith > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] context based defaults for volume options in glusterd
hi, Afr needs context based defaults for quorum where by default quorum value is 'none' for 2-way replica and 'auto' for 3 way replica. Anuradha sent http://review.gluster.org/11872 to fix the same. May be we can come up with more generic solution. The present solution remembers the default in volinfo->options and also written to the store. So the default will be shown in "volume info" output and if we want to change the defaults in future we will need to carefully think of all the things that could go wrong especially peers getting rejected because of the md5sum mismatch. Another way to solve the same problem is to generate the default value of the vme-option based on the context of the volume when we have to write to the volfile. In this particular case, we need to generate default as 'none' for 2-way-replica-count volume. and 'auto' for 3-replica-count volume. For volume-get command handling also we need to consider this dynamic default value. For implementing this, we can add a new member 'context_based_default_value_get()'(please feel free to come up with better name for the function :-) ) to the vme-table which can be invoked to get the default option which takes the volinfo as parameter at least, and not set .value i.e implicitly .value will be NULL. This is based on earlier design detail in the comment of vme-table: * Fourth field is . In this context they are used to specify * a default. That is, even the volume dict doesn't have a value, * we procced as if the default value were set for it. We just want to enhance the existing behavior with this proposed change. It seems more generic than the present solution in the patch. In future people can write their own implementations of context based default value generation following same procedure. Let me know your comments. Pranith ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
