-
Notifications
You must be signed in to change notification settings - Fork 261
OCPBUGS-1272: Add pipe support to "opm alpha render-veneer basic" #1026
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
OCPBUGS-1272: Add pipe support to "opm alpha render-veneer basic" #1026
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1026 +/- ##
=======================================
Coverage 51.95% 51.95%
=======================================
Files 102 102
Lines 9215 9215
=======================================
Hits 4788 4788
Misses 3514 3514
Partials 913 913
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
if !isBundleVeneer(&b) { | ||
outb = append(outb, b) | ||
continue | ||
return nil, fmt.Errorf("bundle veneers must define only a schema and an image; all other fields must not be defined") | ||
} |
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.
The original intent of this code was to allow the author to provide a combination of completely-rendered olm.bundle references as well as 'shorthand-ed' ones which contained only the image references.
If a bundle contained properties, it was presumed to be of the completely-rendered variety and just accumulated (i.e. the author was responsible for the completeness of the rendering).
If a bundle was without properties, it was presumed to be a shorthand bundle, and we would render it ourselves and accumulate it to the output.
I don't love the idea of refusing to accept any completely-rendered bundles in the veneer, but there is some question of why any author would choose to mix-and-match in that fashion anyway.
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.
My perspective here is to make things as strict and locked down as possible at first so that we can attempt to keep the scope of what we need to support small. We can always open things up to support that use case in the future, but it we support it now, we're signing up for it now and we might not understand the ways that people might use/abuse it.
} | ||
|
||
func readYAMLOrJSON(r io.Reader) (*DeclarativeConfig, error) { | ||
func LoadReader(r io.Reader) (*DeclarativeConfig, error) { |
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.
What was the benefit of the rename? I may be missing some background but readYAMLOrJSON
, while verbose, does tell us what it does while LoadReader
is more vague.
Reading between the lines ... is it because this interface was not exported?
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 guess the reason I'd lean towards reader vs yaml or json is just because I feel like I'd be more likely to assume that readYAMLOrJSON would take yaml or json as an input vs a reader, but I'm also not super wedded to it.
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.
IMO, its because we're going to export it, and since we're exporting it, we're following the pattern of the other exported functions that return (declcfg.DeclarativeConfig, error)
|
||
cfg, err := declcfg.LoadFile(root, fname) | ||
func (v Veneer) Render(ctx context.Context, reader io.Reader) (*declcfg.DeclarativeConfig, error) { | ||
cfg, err := declcfg.LoadReader(reader) |
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.
We were originally using declcfg.LoadFile here because we wanted the follow-on call to readBundleObjects. Do we no longer want that?
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.
LoadFile
doesn't work with an arbitrary io.Reader
because readBundleObjects
needs to have some awareness of the directory in which the file containing the bundle object was found. That way it can de-reference those bundle object paths, using that directory as the root.
The root of the problem is essentially that the basic veneer input is not the same as FBC, but we're using FBC loaders because the basic veneer input is "close" to FBC.
d5e0a02
to
a0188f4
Compare
alpha/veneer/basic/basic.go
Outdated
if !isBundleVeneer(&b) { | ||
outb = append(outb, b) | ||
continue | ||
return nil, fmt.Errorf("bundle veneers must define only a schema and an image; all other fields must not be defined") |
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 think I would just say something more generic, something like: "unexpected fields present in basic veneer bundle"
"all other fields must not be defined" gives the impression that there are other fields that should be left empty. In my mind, that's probably the wrong message. Basic veneer is its own format that just happens to look a bit like FBC.
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 say this because it gives us more flexibility in the future if we define the basic veneer input file separately from FBC. The two formats don't necessarily have to evolve in lock-step.
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 lean heavily toward getting the basic veneer on its own schema, so we could do opm alpha render-veneer
instead of opm alpha render-veneer [basic|semver]
.
cmd/opm/alpha/veneer/basic.go
Outdated
Long: `Generate a declarative config blob from a single 'basic veneer' file, typified as a declarative configuration file where olm.bundle objects have no properties`, | ||
Args: cobra.ExactArgs(1), | ||
Short: "Generate a declarative config blob from a single 'basic veneer' file \nWhen FILE is '-' or not provided, the veneer is read from standard input", | ||
Long: "Generate a declarative config blob from a single 'basic veneer' file, typified as a declarative configuration file where olm.bundle objects have no properties \nWhen FILE is '-' or not provided, the veneer is read from standard input", |
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.
Two in one suggestion:
- You can use backticks and actual newlines in the code (rather than escape newline characters), which can help with readability.
- Drop the mention of FBC, minus bundle properties. re, my previous comment.
Long: "Generate a declarative config blob from a single 'basic veneer' file, typified as a declarative configuration file where olm.bundle objects have no properties \nWhen FILE is '-' or not provided, the veneer is read from standard input", | |
Long: `Generate a declarative config blob from a single 'basic veneer' file. | |
When FILE is '-' or not provided, the veneer is read from standard input.`, |
cmd/opm/alpha/veneer/basic.go
Outdated
data, source, err := OpenFileOrReadStdin(cmd, args) | ||
if err != nil { | ||
log.Fatalf("unable to read %q: %v", source, err) |
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.
couple of nits here:
- we're not reading stdin yet, we're just opening it for reading.
- do we need
OpenFileOrReadStdin
to be consumed outside this package? If not, make it unexported.
data, source, err := OpenFileOrReadStdin(cmd, args) | |
if err != nil { | |
log.Fatalf("unable to read %q: %v", source, err) | |
data, source, err := OpenFileOrStdin(cmd, args) | |
if err != nil { | |
log.Fatalf("unable to open %q: %v", source, err) |
a0188f4
to
2cb7213
Compare
func openFileOrStdin(cmd *cobra.Command, args []string) (io.ReadCloser, string, error) { | ||
if len(args) == 0 || args[0] == "-" { | ||
return io.NopCloser(cmd.InOrStdin()), "stdin", nil | ||
} | ||
reader, err := os.Open(args[0]) | ||
return reader, args[0], err | ||
} |
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.
yay, re-use!
2cb7213
to
b11b214
Compare
Signed-off-by: Catherine Chan-Tse <cchantse@redhat.com>
b11b214
to
de60ef8
Compare
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.
/lgtm
// but no Properties, RelatedImages or Package defined | ||
func isBundleVeneer(b *declcfg.Bundle) bool { | ||
return len(b.Properties) == 0 | ||
return b.Schema != "" && b.Image != "" && b.Package == "" && len(b.Properties) == 0 && len(b.RelatedImages) == 0 |
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.
We should have the field restrictions for the simple veneer documented, specifically the hard requirement for prohibited fields. The error message isn't very helpful here.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ankitathomas, grokspawn, oceanc80 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 |
@oceanc80: Jira Issue OCPBUGS-1272 is in an unrecognized state (ON_QA) and will not be moved to the MODIFIED state. In response to this:
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. |
Add pipe support to the render-veneer basic command and expand basic veneer validation checks.
Signed-off-by: Catherine Chan-Tse cchantse@redhat.com
Description of the change:
Motivation for the change:
Reviewer Checklist
/docs