Scenarios in which to allow a node to change groups

[Adeodato Simo]

Hi,

I'm looking into implementing `gnt-group modify -g`, and I want to bring
back those brief discussions we had offline regarding what to allow and
what to disallow regarding instances that would end up with primary and
secondary nodes in different groups.

Some of the possibilities are:

1. only allow changing the group of nodes with no instances

2. warn if there are any instances in the node, and require --force to
proceed

3. allow something like `gnt-node modify -g newgroup node1 node2`, and
compute whether any split instances would result; require --force
(or disallow) if that's the case [this was initially proposed by
Guido, I think]

It is settled that `gnt-cluster verify` will emit warnings for split
instances (I will be sending patches for this next), so the question is
what to do re node movements.

#3 should be able to share code with `gnt-cluster verify`, but would
#change the signature of `gnt-node modify`.

Let me know what you think.

Cheers,

--
Adeodato Simo | da...@google.com
Corp Computing Services SRE (Dublin)

[Balazs Lecz]

I'd like to cast my vote for #3.

#1 and #2 are just too strict.

/leczb

[Guido Trotter]

Definitely #3 or #2, not #1! :) Also for #1 you mean drbd instances:
plain or file instances would still be allowed!

Thanks,

Guido

[Adeodato Simo]

Hi, I'm following-up to this now that I'm on my way through implementing
it, but I have a couple questions.

Option #3 below was favored by Balazs and Guido; I interpret, actually,
that what was mainly favored was actually the ability to safely change
the group of several nodes (safely == without --force), provided that no
split instances resulted. I agree with this.

However, the following difficulties arise:

1. As mentioned in my original mail, allowing:

# gnt-node modify -g newgroup node1 node2 node3

changes the signature of `gnt-node modify`, which has always acted
on one node, only.

2. Moreover, if we would allow the above signature change, we would
need further changes in the master bits of the SetNodeParams
operation, for this operation, of course, only works on one node at
a time too. We would have to either:

(a) update SetNodeParams to allow it to work on several nodes at
a time [I strongly disfavor this option, and I think you guys
will do too]

(b) introduce a new "ChangeNodeGroup" operation that accepts
several nodes, and has the "is the change safe if considered
as an atomic unit" logic. This operation would be
instantiated from `gnt-node modify` client code if -g was
given with more than one node (and no other options were
given, which would be an error).

I was initially favoring (b), but Michael points out that this still
means a change in the signature of the "modify" operation at the CLI
level (and an inconsistency with the rest of the "modify" CLI), and
suggested a new command instead.

Iustin, I would like to know what you think. It was the 2.3 design doc
that specified the `gnt-node modify -g` syntax, but perhaps the
following makes more sense after all:

# gnt-group assign-nodes -g groupx [--force] node1 node2 node3

Or something similar. Thoughts?

Thanks,

--

[Iustin Pop]

On Tue, Jan 04, 2011 at 06:33:22PM +0000, Adeodato Simo wrote:
> Hi, I'm following-up to this now that I'm on my way through implementing
> it, but I have a couple questions.
>
> Option #3 below was favored by Balazs and Guido; I interpret, actually,
> that what was mainly favored was actually the ability to safely change
> the group of several nodes (safely == without --force), provided that no
> split instances resulted. I agree with this.
>
> However, the following difficulties arise:

[…]

> Iustin, I would like to know what you think. It was the 2.3 design doc
> that specified the `gnt-node modify -g` syntax, but perhaps the
> following makes more sense after all:
>
> # gnt-group assign-nodes -g groupx [--force] node1 node2 node3
>
> Or something similar. Thoughts?

Totally agreed. This kind of changes (to which node group a node
belongs) makes more sense at the gnt-group level, rather than gnt-node
modify. assign-nodes or move-nodes. Also, you can get rid of the -g
part, and make the group the first argument (instead of option).

iustin

[Adeodato Simo]

Okay, perfect.

> Also, you can get rid of the -g part, and make the group the first
> argument (instead of option).

I suggested -g here because I tend to dislike positional arguments that
are not homogeneous, but Michael tells me that they're used in a few
places in Ganeti, and Bash completion can handle them, so I'll proceed
with dropping the -g for `gnt-group assign-nodes`.

Thanks for the answer,