Change:
return nil, err } <del> if string(line) == separator || err == io.EOF { </del> <ins> sep := len([]byte(separator)) if i := bytes.Index(line, []byte(separator)); i == 0 { // We have a potential document terminator i += sep after := line[i:] if len(strings.TrimRightFunc(string(after), unicode.IsSpace)) == 0 { if buffer.Len() != 0 { return buffer.Bytes(), nil } if err == io.EOF { return nil, err } } } if err == io.EOF { </ins> if buffer.Len() != 0 { <ins> // If we're at EOF, we have a final, non-terminated line. Return it. </ins> return buffer.Bytes(), nil } <del> if err == io.EOF { return nil, err } } else { buffer.Write(line) </del> <ins> return nil, err </ins> } <ins> buffer.Write(line) </ins> } }

Discussion:
Kubernetes version (use ): Environment: Cloud provider or hardware configuration: Any OS (e.g. from /etc/os-release): Any Kernel (e.g. ): Any Install tools: Any What happened: If I use a template with the seperator, and if the line with the separator has trailing whitespace characters, then kubectl considers that to be the EOF instead of reading further. e.g. template What you expected to happen: It should not stop reading if there are trailing whitespace characters, it should just trim the separator line and ignore the whitespaces after the . This is how it worked until v1.3.0 kubectl version. How to reproduce it (as minimally and precisely as possible): Just use the template from above and you'll notice that it won't create the Service, but it'll create the Replication controller. Anything else do we need to know: This is on kubectl version 1.4.0
kubectl regression. cc
This bug is general (can be found on get, apply, delete, ...). May be somewhere in resource builder.
Might be , Janet Kuo wrote:
Confirmed - is the cause. would you take a look?
We may need to cherrypick the fix
Yaml rules are separator must be at beginning of line, three dashes, and new line. Did we change how strict we were in that PR? On Sep 27, 2016, at 7:46 PM, Janet Kuo wrote: We may need to cherrypick the fix — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub , or mute the thread .
Yes, and the test was changed too (originally tests allow with trailing spaces)
According to spec (if my spec-alese is correct) newline + three dashes is the only requirement to terminate a document. Whitespace or prefixes are allowed afterwards, but for it to be valid YAML those must be valid at the beginning of a doc as well (as far as I can tell). So we should split and remove on any line starting with a newline and three dashes - but not consume the remaining whitespace (I believe) , Janet Kuo wrote:
We should probably exit non-0 and have an error message if we see something in the file that we don't expect. E.g.

is neither a separator nor parseable yaml.
We should add a test that uses a YAML document prefix rule and verify that it correctly passes / fails when YAML goes to parse. From reading the spec it appears that anything that is invalid when n--- is present is also invalid in a single document context, and vice versa. , Phillip Wittrock wrote:
I have rechecked the code, and I have located the root cause, since I am outing for a training these days, I will fix this right now after the training on Friday.
I am quite sorry about the regression. :(
should we allow trailing whitespace characters after , if so we can trim the whitespaces when we read line by line?
is it possible to include this fix to one of the 1.4 releases? We'd really like our users to have of k8s alpha features (Scheduled jobs is one of them) that can be configured only using 1.4 client; w/o them potentially hitting this regression.
I will double check this regression, and open a cherry-pick PR.
I am thinking create a cherry-pick PR for this to include it in 1.4, wdyt?
I would like to see this in 1.4 since as you note it may break scripts. On Oct 19, 2016, at 8:19 PM, TonyAdo wrote: I am thinking create a cherry-pick PR for this to include it in 1.4, wdyt? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or mute the thread .
Do we have a test case now? :) On Oct 19, 2016, at 8:19 PM, TonyAdo wrote: I am thinking create a cherry-pick PR for this to include it in 1.4, wdyt? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or mute the thread .
we already test this, you can see