Description of problem: ==================== currently with colonizer, when we create gluster setup with the volume based on deployment theme, the name assigned to the volume is done by colonizer. Instead we must prompt the user to give a name to the volume. We don't have a way to rename a volume in gluster in general, and hence user will have to live with that name for ever. Instead leave it to the user or if user doenst enter anything , then default it to a random name.
Excluding this flexibility was done consciously in an effort to limit user choice and thus target simplicity in the UX. The name of a Gluster volume is mostly arbitrary, so the ability to change the name is not critical. That being said, offering a balance of flexibility and simple UX here is preferred. I'm proposing that we move the default volume name to the OEMID config file where it can be a more easily adjustable variable while still maintaining the simpler UX for the colonizer.
Default volname now in the oemid file with upstream merge commit to master d97a4789a9add2c177c41bde7e8c05200abbffd8
I think having it configurable in oemid yaml config is perfect. I'd consider this one fixed
(In reply to Jeff Applewhite from comment #4) > I think having it configurable in oemid yaml config is perfect. I'd consider > this one fixed Jeff, While I understand that making volume name configurable through yaml file is good, and is does work on gluster-colonizer-1.1-2.el7rhgs.noarch.rpm However, the bug I raised is to have user prompted for the same. If you think that this feature is not required for now, or is not to be scoped in rhsone, then we must be either deferring this bug or close it as won't fix. For now, the bug doesn't fix the problem raised.
(In reply to Dustin Black from comment #3) > Default volname now in the oemid file with upstream merge commit to master > d97a4789a9add2c177c41bde7e8c05200abbffd8 Dustin, Based on comment#2 and comment#3, if we don't want to prompt user to feed vol name, and that is not in plan for now, then this bug should be left as is (ie deferred) or closed as won't fix. If we want to allow user to rename volume by modifying volume name in yaml file, then we should track this under a new bug.
moving this bug to verified as we now allow user to choose a volume name of personal choice, through modifying the yaml file However raising a new RFE for user being prompted instead of having to edit yaml files. discussed same with Ramky
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:1317