Skip to content

Conversation

@benjaminapetersen
Copy link
Contributor

@benjaminapetersen benjaminapetersen commented May 16, 2019

Related to:

RBAC considerations

  • Console will directly request console links via something like 'api/kubernetes/apis/console.openshift.io/v1/consolelinks' for all users, this will require RBAC for system:authenticated for this resource. see here
  • Console will directly request console cli downloads via API for all authenticated users, this will require RBAC for system:authenticated on this resource. see here
  • Console will directly request console notification banner via API for all authenticated users, this will require RBAC for system:authenticated on this resource. see here

@enj has made the observation that this is config, and as such, only the operator as a privileged component should request it & then pass it to the console pod. The objection to this approach is that every time one of these resources is created, the console pod will need to be restarted. This is problematic as the console in the browser will not be notified & thus the data will not be passed to the user in a timely fashion.

ConsoleServerConfig
In addition, the console server config has previously been approved as an API, but it exists in the console repo. It should likely be migrated & helps clarify the folder structure.

  • Decide if this is how we want to structure this kind of config (new folders under /config) as these are not top-level config. Establishes precedence. Top level /console directory
  • Generate code
  • Annotations are still needed in these files (+optional, +required, etc)
  • gofmt with go1.11 (per travis.yaml)
  • We need to decide if any of these, such as the banners, ought to be instead handled within the console config (or console operator config).

fyi @spadgett @rhamilto

@benjaminapetersen benjaminapetersen changed the title Add api types for console extension resources and console server config [WIP] Add api types for console extension resources and console server config May 16, 2019
@openshift-ci-robot openshift-ci-robot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels May 16, 2019
@benjaminapetersen
Copy link
Contributor Author

@jwforres @bparees for review

@benjaminapetersen benjaminapetersen changed the title [WIP] Add api types for console extension resources and console server config Add api types for console extension resources and console server config May 21, 2019
@openshift-ci-robot openshift-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label May 21, 2019
@benjaminapetersen benjaminapetersen force-pushed the console/extensions branch 3 times, most recently from 8128f0b to 769530b Compare May 21, 2019 19:16
@benjaminapetersen
Copy link
Contributor Author

@spadgett also on spec, the manifests have validation for a spec, see here, here, here.

Just a last call confirmation we don't want a spec wrapper. I'll eliminate it from the CRD as well.

@bparees
Copy link
Contributor

bparees commented May 21, 2019

Just a last call confirmation we don't want a spec wrapper. I'll eliminate it from the CRD as well.

isn't that also going to have ripple effects on other code?

the CRD and the go struct need to be in sync, whatever you do.

@spadgett
Copy link
Member

It should be pretty straightforward to remove spec in the other code if we don't want it. Nothing has merged yet to console or console-operator.

Is there a reason to keep it? I wouldn't expect any of these resources to ever have a status.

@benjaminapetersen
Copy link
Contributor Author

benjaminapetersen commented May 22, 2019

// With spec
//////////////////////
apiVersion: console.openshift.io/v1
kind: ConsoleCLIDownload
metadata:
  creationTimestamp: '2019-05-22T18:59:36Z'
  generation: 1
  name: example
  resourceVersion: '611639'
  selfLink: /apis/console.openshift.io/v1/consoleclidownloads/example
  uid: be9a861f-7cc3-11e9-8b51-02b1a6acaf5e
spec:
  description: foo bar baz
  displayName: Foo
  link:
    href: 'https://www.redhat.com'
    text: Foo bar

// With no spec
//////////////////////
apiVersion: console.openshift.io/v1
kind: ConsoleCLIDownload
metadata:
  creationTimestamp: '2019-05-22T18:59:36Z'
  generation: 1
  name: example
  resourceVersion: '611639'
  selfLink: /apis/console.openshift.io/v1/consoleclidownloads/example
  uid: be9a861f-7cc3-11e9-8b51-02b1a6acaf5e
description: foo bar baz
displayName: Foo
link:
  href: 'https://www.redhat.com'
  text: Foo bar

I don't know that it hurts us really to keep spec. I guess it means we always have the opportunity to add status, but are not obligated. Would we ever have todo anything like:

  • reject, too many additional menu items (lots of operators adding, menu gets unwieldy)
  • reject, too many additional items from a single provider (one operator makes a dozen?)

What is a little more painful about dropping spec is that the properties you care about get alphabetized into the boilerplate of the object. So an object returned from API will look like:

apiVersion: console.openshift.io/v1
description: foo bar baz
displayName: Foo
kind: ConsoleCLIDownload
link:
  href: 'https://www.redhat.com'
  text: Foo bar
metadata:
  creationTimestamp: '2019-05-22T18:59:36Z'
  generation: 1
  name: example
  resourceVersion: '611639'
  selfLink: /apis/console.openshift.io/v1/consoleclidownloads/example
  uid: be9a861f-7cc3-11e9-8b51-02b1a6acaf5e

Or

apiVersion: console.openshift.io/v1
href: 'http://www.redhat.com'
kind: ConsoleLink
location: helpMenu
metadata:
  creationTimestamp: '2019-05-23T17:29:29Z'
  generation: 1
  name: example
  resourceVersion: '60295'
  selfLink: /apis/console.openshift.io/v1/consolelinks/example
  uid: 521f3b4c-7d80-11e9-abc5-067bd6cb3f50
text: My link

I personally find that rather annoying/messy, but I realize its a cosmetic issue, not a functional issue.
This just seems better to me:

apiVersion: console.openshift.io/v1
kind: ConsoleLink
metadata:
  creationTimestamp: '2019-05-23T17:29:29Z'
  generation: 1
  name: example
  resourceVersion: '60295'
  selfLink: /apis/console.openshift.io/v1/consolelinks/example
  uid: 521f3b4c-7d80-11e9-abc5-067bd6cb3f50
spec:
  text: My link
  href: 'https://www.redhat.com'
  location: helpMenu

@benjaminapetersen
Copy link
Contributor Author

verify success, better.

@benjaminapetersen benjaminapetersen force-pushed the console/extensions branch 2 times, most recently from d8c0f57 to d1686d3 Compare June 3, 2019 17:56
@spadgett
Copy link
Member

spadgett commented Jun 4, 2019

lgtm, but verify failed

go build github.com/openshift/api/...
# github.com/openshift/api/console/v1
console/v1/zz_generated.deepcopy.go:234:8: cannot use new(ConsoleLink) (type *ConsoleLink) as type *Link in assignment
make: *** [build] Error 2

@benjaminapetersen
Copy link
Contributor Author

make generate, tiny update pushed, lets see if it passes.

@benjaminapetersen
Copy link
Contributor Author

passed.

Copy link
Member

@spadgett spadgett left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Jun 5, 2019
@spadgett
Copy link
Member

spadgett commented Jun 5, 2019

@bparees ptal, will need your approval

Copy link
Contributor

@bparees bparees left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

couple of doc nits

@bparees
Copy link
Contributor

bparees commented Jun 5, 2019

/lgtm cancel
/approve

@spadgett you can reassert your lgtm when the godoc items are addressed.

@bparees
Copy link
Contributor

bparees commented Jun 5, 2019

/hold
(in case my lgtm cancel doesn't work)

@openshift-ci-robot openshift-ci-robot removed the lgtm Indicates that a PR is ready to be merged. label Jun 5, 2019
@bparees
Copy link
Contributor

bparees commented Jun 5, 2019

/approve

(prow or github may be having issues....)

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 5, 2019
Extensions:
- console links
- console cli downloads
- console notification banners
@benjaminapetersen
Copy link
Contributor Author

@spadgett updates made.

@spadgett
Copy link
Member

spadgett commented Jun 7, 2019

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Jun 7, 2019
@openshift-ci-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: benjaminapetersen, bparees, spadgett

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-merge-robot openshift-merge-robot merged commit 3ca714b into openshift:master Jun 7, 2019
@benjaminapetersen benjaminapetersen deleted the console/extensions branch June 12, 2019 14:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants