-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make seq indent configurable and add retain seq indent functionality #4043
Make seq indent configurable and add retain seq indent functionality #4043
Conversation
936c22f
to
86f1cdc
Compare
86f1cdc
to
ed38b5f
Compare
@phanimarupaka: This PR has multiple commits, and the default merge method is: merge. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking better. Some more thoughts.
a2814b7
to
2a99e0b
Compare
2a99e0b
to
f81201b
Compare
@KnVerey @natasha41575 Let us know your thoughts. |
kyaml/kio/byteio_reader.go
Outdated
@@ -37,6 +38,9 @@ type ByteReadWriter struct { | |||
// the Resources, otherwise they will be cleared. | |||
KeepReaderAnnotations bool | |||
|
|||
// AddSeqIndentAnnotation if true adds kioutil.SeqIndentAnnotation to each resource | |||
AddSeqIndentAnnotation bool |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to name this for the effect rather than the mechanism? E.g. something like PreserveSequenceIndentStyle
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's also an awkward conflict between this option (however named) and OmitReaderAnnotations
. If we can do it cheaply enough, wdyt about treating it like any other reader annotation, and adding a "preserve indent style" option on the writer to make use of it where available?
Related to this, I see that the writer already has a Style
option, which I'm guessing might also interact with this new feature. E.g. if the Style
is set to the json-like FlowStyle
where sequence indent style doesn't apply, I'm guessing Style
wins. We should document/test this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's also an awkward conflict between this option (however named) and
OmitReaderAnnotations
. If we can do it cheaply enough, wdyt about treating it like any other reader annotation, and adding a "preserve indent style" option on the writer to make use of it where available?
It is not cheap to identify the indentation in byteio_reader. Hence made it opt-in. Except for that, this annotation is identical to index
annotation and follows the same life cycle.
Related to this, I see that the writer already has a
Style
option, which I'm guessing might also interact with this new feature. E.g. if theStyle
is set to the json-likeFlowStyle
where sequence indent style doesn't apply, I'm guessingStyle
wins. We should document/test this.
That is a good point. Few options clash here.
Both OmitReaderAnnotations
and Style
win over PreserveSequenceIndentStyle
. I will document and test this behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to name this for the effect rather than the mechanism? E.g. something like
PreserveSequenceIndentStyle
I started off with this but @droot thinks otherwise. I was on the fence. But the more I think, I think it is better to go with the mechanism rather than annotation(@droot WDYT). In that case, should we error out if conflicting options are set ? For e.g. OmitReaderAnnotations
and PreserveSequenceIndentStyle
are set ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, PreserveSequenceIndentStyle
makes sense at the ReaderWriter
level or PackageReaderWriter
level because they do reading and writing so can encapsulate the preserving behavior. So +1 to that.
The same name may not make sense at the Reader
level because reader can't ensure that behavior, so mechanism fits better there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Re: OmitReaderAnnotations
. If we were starting today, would have definitely made the preserveIdentStyle as the default behavior and treating it like ReaderAnnotation. But at this point, to reduce the blast radius (and the cost involved), making this additive makes sense. There is an alternative path here, where we introduce this as an opt-in now (keeping it consistent with ReaderAnnotation) and eventually make it the default behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ByteReader is also exposed. We may change the logic even at bytereader as well. So it is better to be consistent.
kyaml/kio/byteio_reader.go
Outdated
noIndentDiff := copyutil.PrettyFileDiff(string(out), originalYAML) | ||
|
||
var style string | ||
if len(noIndentDiff) <= len(twoSpaceIndentDiff) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this heuristic be confounded by a non-2 general indent level with compact style? Rather than attempting to determine the average indent level, could we sample the first sequence somehow (scanning? column data on YNodes?) and use that? I imagine most documents would be consistent, and when they're not, "first" behaviour might be easier for the end user to understand than "average".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the feedback we received, users want to see less diffs. The goal here is to minimize the diff. So the "first" behavior doesn't achieve that goal.
And identifying first sequence is difficult problem. There would be many edge cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure on the complexity of identify the "first" behavior, but picking the "first" behavior has more benefits over the "average" when indentation is not consistent within a resource. It makes it more deterministic and can potentially make this function cheaper as well. We should definitely explore if it is a possibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did a benchmark analysis and found that the latency is 2.5 times more. Implemented "first" approach. There is no significant performance degradation. Since the new approach involves raw YAML string parsing, I might be missing few corner cases. We can improve it as we go.
kyaml/yaml/alias.go
Outdated
const DefaultIndent = 2 | ||
const DefaultSequenceStyle = CompactSequenceStyle | ||
// SeqIndentType holds the indentation style for sequence nodes | ||
type SeqIndentType string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: SeqIndentStyle represent the behavior better. Also, preserve the older CompactSequenceStyle
, WideSequenceStyle
names to reduce the changes on public symbols.
kyaml/kio/byteio_reader.go
Outdated
@@ -37,6 +38,9 @@ type ByteReadWriter struct { | |||
// the Resources, otherwise they will be cleared. | |||
KeepReaderAnnotations bool | |||
|
|||
// AddSeqIndentAnnotation if true adds kioutil.SeqIndentAnnotation to each resource | |||
AddSeqIndentAnnotation bool |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, PreserveSequenceIndentStyle
makes sense at the ReaderWriter
level or PackageReaderWriter
level because they do reading and writing so can encapsulate the preserving behavior. So +1 to that.
The same name may not make sense at the Reader
level because reader can't ensure that behavior, so mechanism fits better there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@phanimarupaka The change looks good. I have minor comments.
b86d0a6
to
b6fb62b
Compare
b6fb62b
to
29be7fa
Compare
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: droot, phanimarupaka The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
sequenceIndentationStyle
in alias.go configurable by adding getter and setterSeqIndent
. This is purely an additional change and doesn't affect any of the existing tests. The motivation is to makekio
package expose an option to downstream callers(likekpt
) to retain the existing indentation of resources. This is done by adding a new internal annotation with nameinternal.config.kubernetes.io/seqindent
. The byteio_reader adds this annotation so that byteio_write can encode the resources based on the indentation specified in the annotation.Adding more tests. But want to confirm the direction.
@droot @KnVerey @natasha41575