Cluster autoscaler doc - part 1

[mwielgus]

cc: @piosz @jszczepkowski @fgrzadkowski

[fgrzadkowski]

I'd remove this part. It's an implenentation details, which is a pure heuristic to find good candidates for removal.

[mwielgus]

Yes, but it also explains why some nodes that could potentially be removed are not deleted.

[fgrzadkowski]

Then let's rephrase it to be more vague and say that we will choose "some nodes" that are not needed. I strongly believe that user documentation should include any implementation details, as they will start depending it. It's like with the API.

[mwielgus]

I disagree - we can always mark that this strategy may change in the future.
I wouldn't trust such autoscaler that sometimes may delete some nodes based on some vague conditions.

[fgrzadkowski]

But then you'd have to describe the whole logic here to be complete. Let's discuss in person/VC tomorrow and ask @piosz and @jszczepkowski for opinion.

[fgrzadkowski]

s/signle/single

I'd expect that user will the same concerns regarding "roughly the same". If this is only about label we should say this explicitly. Or we can phrase it differently, like "we expect that nodes where not manually modified (e.g. by adding labels via kubectl) as those properties would be propagated to the new nodes within the same instance group".

[mwielgus]

Done

[fgrzadkowski]

I think that this PR should be against branch release-1.3, not master.

[mwielgus]

It should also be made in master - the feature will not go away in 1.4. I can create another one for 1.3.

[fgrzadkowski]

My understanding is that master is the current release, i.e. 1.2. Later 1.3 will become master, master will become 1.2 and we'll create new branch for 1.4

[johndmulhausen]

Yes, this should have been opened against the release-1.3 branch, but you're not alone in the confusion here.

[fgrzadkowski]

@johndmulhausen Can we change this PR to be against 1.3 release and merge it now, instead of waiting for the release?

[erictune]

@mwielgus : We are asking the PR authors to do the rebase.

To rebase your work on 1.3 do something like this starting in the branch that you used for this PR:

COMMITS=$(git log master.. | grep commit | cut -f 2 -d " " | tac)
BR=$(git rev-parse --abbrev-ref HEAD)
git fetch upstream
git checkout upstream/release-1.3
git checkout -b $BR-1.3
for c in $COMMITS
do
  git cherry-pick $c; done
done
git push

[johndmulhausen]

@fgrzadkowski Yes, if you rebase this against 1.3 we can merge it now! Thanks to @erictune for providing instructions

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for the commit author(s). If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.

[mwielgus]

Unfortunately it seems that we cannot do this under this PR (or maybe can someone change the target branch of this PR). Please reopen #684 which is for the correct branch.

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request) and all commit authors, but as best as we can tell these commits were authored by someone else. If that's the case, please add them to this pull request and have them confirm that they're okay with these commits being contributed to Google. If we're mistaken and you did author these commits, just reply here to confirm.

[googlebot]

CLAs look good, thanks!

[johndmulhausen]

@mwielgus Reopened PR. Merging that one. Closing this one. :)