https://codereview.appspot.com/86490043/diff/1/state/addmachine.go#newcode555
state/addmachine.go:555: if err != nil {
On 2014/04/11 10:09:17, rog wrote:
> If err==txn.ErrAborted, I think it's only going to be because someone
> else has run EnsureAvailability concurrently. Perhaps we should check
if the
> voting server count has changed - if it has, return an error,
otherwise return
> nil because our work will already have been done.
Done, I made it a transaction loop and added a few tests.
https://codereview.appspot.com/86490043/diff/1/state/addmachine.go#newcode598
state/addmachine.go:598: // If the machine does want to vote, we simply
set novote and
On 2014/04/11 10:09:17, rog wrote:
> Since the comments are inside the if statement, we can phrase them
> unconditionally, which might read slightly more clearly.
> // The machine wants to vote, so we simply set novote etc
Please take a look.
https:/ /codereview. appspot. com/86490043/ diff/1/ state/addmachin e.go
File state/addmachine.go (right):
https:/ /codereview. appspot. com/86490043/ diff/1/ state/addmachin e.go#newcode555 e.go:555: if err != nil { ErrAborted, I think it's only going to be because someone
state/addmachin
On 2014/04/11 10:09:17, rog wrote:
> If err==txn.
> else has run EnsureAvailability concurrently. Perhaps we should check
if the
> voting server count has changed - if it has, return an error,
otherwise return
> nil because our work will already have been done.
Done, I made it a transaction loop and added a few tests.
https:/ /codereview. appspot. com/86490043/ diff/1/ state/addmachin e.go#newcode578 e.go:578: var newVotingMachin eIds, newMachineIds []string
state/addmachin
On 2014/04/11 10:09:17, rog wrote:
> rather than two variables, it might be clearer if we did:
> var newInfo StateServerInfo
> and then, e.g. newInfo. MachineIds, ...)
> newInfo.MachineIds = append(
> then it's more obvious when we're just building
> up ids in the new info.
Done.
https:/ /codereview. appspot. com/86490043/ diff/1/ state/addmachin e.go#newcode589 e.go:589: if !m.WantsVote() {
state/addmachin
On 2014/04/11 10:09:17, rog wrote:
> switch the sense of the condition to avoid the negative?
Done.
https:/ /codereview. appspot. com/86490043/ diff/1/ state/addmachin e.go#newcode598 e.go:598: // If the machine does want to vote, we simply
state/addmachin
set novote and
On 2014/04/11 10:09:17, rog wrote:
> Since the comments are inside the if statement, we can phrase them
> unconditionally, which might read slightly more clearly.
> // The machine wants to vote, so we simply set novote etc
Done.
https:/ /codereview. appspot. com/86490043/ diff/1/ state/addmachin e.go#newcode605 e.go:605: } else if !m.HasVote() {
state/addmachin
On 2014/04/11 10:09:17, rog wrote:
> perhaps invert the condition here to save negatives?
Done.
https:/ /codereview. appspot. com/86490043/ diff/1/ state/addmachin e.go#newcode606 e.go:606: // If the machine does not want to vote and
state/addmachin
doesn't have a vote,
On 2014/04/11 10:09:17, rog wrote:
> again, we can phrase it unconditionally.
Done.
https:/ /codereview. appspot. com/86490043/ diff/1/ state/addmachin e.go#newcode625 e.go:625: Assert: bson.D{{"novote", bson.D{{"$ne",
state/addmachin
false}}}},
On 2014/04/11 10:09:17, rog wrote:
> I *think* this should be {{"$eq", true}}, because nil!=false
> and legacy machines may have a nil novote field.
> similarly below.
Done.
https:/ /codereview. appspot. com/86490043/ diff/1/ state/addmachin e.go#newcode655 e.go:655: Update: bson.D{{"$pull", bson.D{{"jobs", n}}}},
state/addmachin
JobManageEnviro
On 2014/04/11 10:09:17, rog wrote:
> perhaps set novote=false here too?
Done.
https:/ /codereview. appspot. com/86490043/