* Alberto Garcia (be...@igalia.com) wrote: > On Wed 30 Mar 2016 05:07:15 PM CEST, Max Reitz wrote: > >> I also have another (not directly related) question: why not simply > >> use the node name when removing children? I understood that the idea > >> was that it's possible to have the same node attached twice to the > >> same Quorum, but can you actually do that? And what's the use case? > > > > What I like about using the child role name is that it automatically > > prevents you from specifying a node that is not a child of the given > > parent. > > Right, but checking if a node is not a child and returning an error is > very simple. And it doesn't require the user to keep track of the node > name *and* the child role name. > > Unless I'm forgetting something this would be the first time we expose > the child role name in the API, that's why I'm wondering if it's > something worth doing. > > > Which makes me notice that it might be a good idea to require the user > > to specify the child's role when adding a new child. In this version > > of this series (where only quorum is supported), the children are just > > inserted in numerical order (first free slot is taken first), but > > maybe the user wants to insert them in a different order. > > For the Quorum case it totally makes sense to let the user choose the > position of the new child. > > But for creating a Quorum array in the first place we don't require > that, the order is the one that the user provides, and the user does not > need to know about the child role names at that point.
Actually in my setup I only add the local block device using the normal command line, and use drive_add even at startup. It solves a lot of the ordering problems with getting COLO booted. Dave > > > And the "filling up quorum's children" topic then makes me notice that > > (x-)blockdev-change should probably be transaction-able (so you can > > restructure the whole BDS graph in a single transaction), but that's > > something we can care about later on. > > I agree. > > Berto -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
