> Yeah this followed by glusterd restart should help > > But frankly, i was hoping that 'rm' the file isn't a neat way to fix this > issue Why is rm not a neat way? Is it because the container deployment tool needs to know about gluster internals? But isn't a Dockerfile dealing with details of the service(s) that is being deployment in a container. > AFAICT we have 2 scenarios: > > 1) Non-container scenario, where the current behaviour of glusterd persisting > the info in .info file makes sense > > 2) Container scenario, where the same image gets used as the base, hence all > containers gets the same UUID > For this we can have an option to tell glusterd that instructs it to refresh > the UUID during next start. > > Maybe somethign like presence of a file /var/lib/glusterd/refresh_uuid makes > glusterd refresh the UUID in .info > and then delete this file, that ways, Dockerfile can touch this file, post > gluster rpm install step and things should > work as expected ? If container deployment needs are different it should should address issues like above. If we start addressing glusterd's configuration handling for every new deployment technology it would quickly become unmaintainable. _______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-users
