On Wed, 26 Jun 2013 10:25:40 +0100 Justin Clift <jclift@xxxxxxxxxx> wrote: > On 26/06/2013, at 9:28 AM, Stephan von Krawczynski wrote: > <snip> > >> This is an idea that's been on my mind for a while, to overcome a > >> fundamental problem Gluster has with some network common topologies. > >> (thanks to Niels de Vos for letting me bounce ideas off him btw) > >> > >> Most corp places I've worked have multiple network interfaces on their > >> storage boxes, each for a specific purpose (eg backup interface, client > >> interface, general connectivity interface, and more). > >> > >> At present Gluster can't really make use of this kind of topology > >> effectively. Having some interfaces only for client traffic, other > >> interfaces for peer replication traffic just isn't how it's designed. > >> > >> To address this, we could introduce "connection groups". > >> [...] > >> Thoughts? :) > >> > >> Regards and best wishes, > >> > >> Justin Clift > > > > Dear Justin, > > > > it was pretty easy to use such an infrastructure in times of glusterfs 2.X > > where an admin had true control over the ongoing with a _config file_. Since > > the whole 3.X mess started really nothing was improved besides the automatic > > self-heal. The network part has become unusable in terms of controlling what > > is really going on and where. > > Interesting point. I barely remember 2.x from the brief times I was trying > that out (before I joined Red Hat). :) > > That being said, the "controlled" approach (my wording) in 3.x is here to > stay, so let's fix its weaknesses. > > What do you reckon about of the general concept in my email? ;> > > Regards and best wishes, > > Justin Clift My general critics are not so much targetted on your proposal but more on the basic administration based on "sudo gluster <configure yet another option without clear reading of the already configured ones>". I hardly believe that most servers on this planet are dynamically reconfigured every twenty minutes which would be the only excuse for this type of "dynamic configuration interface". It adds what is mostly not needed in favor of having a passive type of security by using static config files. It is bogus to think that it is necessary to distribute a config over the net by ignoring the fact that you have to install the software itself on every box anyways before being able to use it at all. I cannot fight the feeling that this whole "interface" was only created because it was way easier to implement than to cure the real continuing problem of glusterfs - the context switching because of being userspace. "we cannot address the true problem, so lets make some noise and add complexity to show we are working at all". There have been lots of great concepts for just about everything on this planet and most vanished because of fiddling around with unnecessary details. It's really quite parallel to replacement of SysV init with systemd. A working and completely sufficient system is replaced by a daemon which only "advantage" is to save 5 seconds boot time during 2 years runtime. But instead of having static scripts in one location you have now links and pseudo configs spread all over the fs and no sequential logfile. -- Regards, Stephan
