Add ModelFeatureFlag and improve plugin support #1528

vojtechszocs · 2019-05-03T18:20:57Z

New extensions

This PR adds an extension type that allows Console plugins to contribute new model-based feature flags.

For example:

const plugin: Plugin<ModelFeatureFlag> = [
  {
    type: 'FeatureFlag/Model',
    properties: {
      model: VirtualMachineModel,
      flag: 'KUBEVIRT',
    },
  },
];

In general, every Console plugin should contribute one (or possibly more) feature flags related to that plugin. Consequently, any extension of Console UI should be gated by the corresponding feature flag at runtime.

So if e.g. KubeVirt is not detected on the cluster, any KubeVirt related extensions will not be effective.

Code improvements

@console/active-plugins codegen simplified and unit-tested

using TypeScript namespaces to better organize extension's properties types, for example:

namespace ExtensionProperties {
  export interface ModelFeatureFlag {
    model: K8sKind;
    flag: string;
  }
}

export interface ModelFeatureFlag extends Extension<ExtensionProperties.ModelFeatureFlag> {
  type: 'FeatureFlag/Model';
}

eslint-plugin-import bumped to v2.17.2 in order to support TypeScript namespaces
suppress <N> plugins active log when NODE_ENV is test (avoid test output clutter)
print the list of active plugins during webpack build

/cc @spadgett @christianvogt @jelkosz

openshift-ci-robot · 2019-05-03T18:21:00Z

@vojtechszocs: GitHub didn't allow me to request PR reviews from the following users: jelkosz.

Note that only openshift members and repo collaborators can review this PR, and authors cannot review their own PRs.

Details

In response to this:

New extensions

This PR adds an extension type that allows Console plugins to contribute new model-based feature flags.

For example:
const plugin: Plugin<ModelBasedFeatureFlag> = [
 {
   type: 'FeatureFlag/ModelBased',
   properties: {
     model: VirtualMachineModel,
     flag: 'KUBEVIRT',
   },
 },
];
In general, every Console plugin should contribute one (or possibly more) feature flags related to that plugin. Consequently, any extension of Console UI should be gated by the corresponding feature flag at runtime.

So if e.g. KubeVirt is not detected on the cluster, any KubeVirt related extensions will not be effective.

Code improvements

Jest testRegex option covers files ending with .test.(ts|tsx|js|jsx)

@console/active-plugins codegen simplified and unit-tested

using TypeScript namespaces to better organize extension's properties types, for example:
namespace ExtensionProperties {
 export interface ModelBasedFeatureFlag {
   model: K8sKind;
   flag: string;
 }
}

export interface ModelBasedFeatureFlag extends Extension<ExtensionProperties.ModelBasedFeatureFlag> {
 type: 'FeatureFlag/ModelBased';
}
eslint-plugin-import bumped to v2.17.2 in order to support TypeScript namespaces

suppress <N> plugins active log when NODE_ENV is test (avoid test output clutter)

print the list of active plugins during webpack build

/cc @spadgett @christianvogt @jelkosz

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.

vojtechszocs · 2019-05-03T18:25:25Z

Follow-up to #1499

vojtechszocs · 2019-05-03T18:40:14Z

/cc @alecmerdler

alecmerdler · 2019-05-03T18:48:30Z

frontend/packages/console-plugin-sdk/src/codegen/index.test.ts

Why aren't we following the module.spec.ts filename pattern here?

You're right 👍 we should follow the existing pattern.

I'll do the change and update Jest testRegex value accordingly.

@alecmerdler @spadgett What's your opinion on unit test co-location? Right now, the test sits next to the corresponding module. An alternative is to have e.g.

packages/console-plugin-sdk/__tests__/codegen/index.spec.ts

which adds structural duplicity in favor of better test isolation.

Once we move code out of the public directory into appropriate packages, which test location convention should we follow?

I prefer having tests next to their source file, but that's not what we had when I started working on bridge, so we've stuck with the __tests__ directory. We should stick with the duplicate structure; following the module.spec.ts filename format makes it easy to find the test files using search anyway.

Why not just follow the typical pattern found and described by most react apps and tutorials wherein the __tests__ directory is located adjacent to the file being tested. So in this case create test file at src/codegen/__tests__/index.spec.ts

I prefer having tests next to their source file

I have the same preference, the main reason being that it's immediately clear if the given module has a corresponding test, and the secondary reason being that it encourages developers to treat tests in the same way as actual code.

I'm OK with @christianvogt's proposal, co-locating tests under __tests__ adjacent to the module being tested. Should I proceed with this change? @spadgett @alecmerdler

The underscores in __tests__ is something I don't like, though. I guess this comes from Python, which uses __ prefix to denote things that are outside of the regular code. (From my point of view, unit tests should be an integral part of the regular code, not something outside of it.)

If we are going to co-locate the tests, my vote would to have a flat structure and not use __tests__. So:

components/ |--- index.ts |--- index.spec.ts |--- widget.tsx |--- widget.spec.tsx

Whatever we choose, we should do it across the entire codebase to ensure consistency, which means breaking out the existing __tests__ directory to their respective source directories.

Whatever we choose, we should do it across the entire codebase to ensure consistency

I'll take care of that as part of the "moving stuff out of public directory" effort.

I agree that we should do it across the whole repo. But do so in steps.
One benefit to the __tests__ dir is that related test files can also be placed in there as to not confused with application code. The double underscores help move the dir to the top of the file sort order. I can appreciate having tests as sibling files though.

When using jest we also have a __mocks__ folder for mocks and a __snapshots__ folder for snapshots. Snapshots could probably be co-located once again in the same dir. TBH I never looked at changing the directory for mocks though.

Something worth bringing up as we look to improve and enhance the coding guidelines as well as look to add more linting.

One benefit to the __tests__ dir is that related test files can also be placed in there as to not confused with application code. The double underscores help move the dir to the top of the file sort order. I can appreciate having tests as sibling files though.

These are good points. @spadgett do you have any thoughts on this?

For this PR, I'll use the adjacent __tests__ directory convention:

path/to/module.ts(x) path/to/__tests__/module.spec.ts(x)

When using jest we also have a __mocks__ folder for mocks and a __snapshots__ folder for snapshots.

Actually, some files under the __mocks__ directory are setup files:

"setupFiles": [ "./__mocks__/requestAnimationFrame.js", "./__mocks__/localStorage.ts", "./__mocks__/matchMedia.js", "./before-tests.js" ],

Some other files in that directory are automatic module mocks:

"moduleNameMapper": { "\\.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$": "<rootDir>/__mocks__/fileMock.js", "\\.(css|less)$": "<rootDir>/__mocks__/styleMock.js" },

The remaining files in that directory are what I call helper mocks. These are used in tests to provide mocked versions of specific objects, for example:

// in __tests__/components/catalog.spec.tsx import { catalogListPageProps, catalogItems, catalogCategories } from '../../__mocks__/catalogItemsMocks';

As far as I can see, Console doesn't use Jest manual mocks which are used to stub out entire modules, both application and vendor.

Snapshots could probably be co-located once again in the same dir. TBH I never looked at changing the directory for mocks though.

Jest originally introduced the __snapshots__ directory for the purpose of completely unambiguous test vs. snapshot file resolution.

As of Jest 24, it's possible to customize the test snapshot location by providing a custom snapshot resolver.

I don't see any value in having many __snapshots__ directories dispersed across the codebase, so I'd vote for co-locating test snapshot right next to the test itself. If we go with the adjacent __tests__ convention, this means:

path/to/module.ts(x) path/to/__tests__/module.spec.ts(x) path/to/__tests__/module.spec.snap

Also, by putting test snapshots next to the corresponding tests,

related test files can also be placed in there as to not confused with application code

makes even more sense.

christianvogt · 2019-05-06T14:03:44Z

frontend/packages/console-plugin-sdk/src/codegen/index.test.ts

Why not just follow the typical pattern found and described by most react apps and tutorials wherein the __tests__ directory is located adjacent to the file being tested. So in this case create test file at src/codegen/__tests__/index.spec.ts

christianvogt · 2019-05-06T14:05:19Z

frontend/package.json

Stick to using spec as that's the adopted file name pattern

Agreed, will do.

vojtechszocs · 2019-05-06T17:35:27Z

Rebased & updated according to review comments.

spadgett

Looks good. Thanks for adding the unit tests. We should open JIRA issues to track remaining work such as moving the tests.

spadgett · 2019-05-06T17:55:06Z

frontend/packages/console-plugin-sdk/src/typings/features.ts

Maybe just ModelFeatureFlag and ActionFeatureFlag?

Sounds good, I'll do the change.

An ActionFeatureFlag should result in adding new function to featureActions array in public/features.ts module.

Also, not sure if we need to extend ssarChecks which are related to featureActions.

We'll probably want something like an RBACFeatureFlag eventually. I've been investigating ways of handling RBAC in console generally to conditionally disable actions and nav items. I think we can add it when we need it.

vojtechszocs · 2019-05-13T16:29:36Z

PR updated 👨‍💻 all review comments should be addressed.

spadgett

/lgtm

spadgett · 2019-05-14T00:23:26Z

/retest

spadgett · 2019-05-14T01:36:50Z

/retest

vojtechszocs · 2019-05-14T13:45:14Z

@vojtechszocs: PR needs rebase.

I'm on it.

vojtechszocs · 2019-05-15T16:20:29Z

@spadgett @alecmerdler Currently, there's const CRDs in both public/actions/features.ts and public/reducers/features.ts, however the first one seems unused.

So I've updated the second one with

[referenceForModel(MachineAutoscalerModel)]: FLAGS.MACHINE_AUTOSCALER,

and removed the first one 😃

vojtechszocs · 2019-05-17T15:32:29Z

Fixed the failing __tests__/reducers/features.spec.tsx, no other changes.

spadgett · 2019-05-17T21:27:19Z

/lgtm

openshift-ci-robot · 2019-05-17T21:27:28Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: spadgett, vojtechszocs

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:

~~frontend/OWNERS~~ [spadgett]

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

openshift-ci-robot requested review from christianvogt and spadgett May 3, 2019 18:20

openshift-ci-robot added the size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. label May 3, 2019

vojtechszocs mentioned this pull request May 3, 2019

Add support for static plugins #1499

Merged

vojtechszocs force-pushed the improve-plugin-support branch from 5bfe1c3 to 8dbd09f Compare May 3, 2019 18:29

openshift-ci-robot requested a review from alecmerdler May 3, 2019 18:40

alecmerdler reviewed May 3, 2019

View reviewed changes

spadgett added this to the v4.2 milestone May 4, 2019

christianvogt reviewed May 6, 2019

View reviewed changes

vojtechszocs force-pushed the improve-plugin-support branch from 8dbd09f to 24ceaad Compare May 6, 2019 17:34

openshift-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. labels May 6, 2019

vojtechszocs force-pushed the improve-plugin-support branch from 24ceaad to 7e24417 Compare May 6, 2019 17:38

spadgett reviewed May 6, 2019

View reviewed changes

jtomasek mentioned this pull request May 7, 2019

Introduce Metal3 plugin for openshift console #1539

Merged

3 tasks

vojtechszocs force-pushed the improve-plugin-support branch from 7e24417 to 52b6ec9 Compare May 13, 2019 16:22

vojtechszocs changed the title ~~Add ModelBasedFeatureFlag and improve plugin support~~ Add ModelFeatureFlag and improve plugin support May 13, 2019

spadgett changed the base branch from master-next to master May 13, 2019 22:45

spadgett approved these changes May 13, 2019

View reviewed changes

openshift-ci-robot assigned spadgett May 13, 2019

openshift-ci-robot added lgtm Indicates that a PR is ready to be merged. approved Indicates a PR has been approved by an approver from all required OWNERS files. labels May 13, 2019

openshift-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label May 14, 2019

vojtechszocs force-pushed the improve-plugin-support branch from 52b6ec9 to e712229 Compare May 15, 2019 16:16

openshift-ci-robot removed lgtm Indicates that a PR is ready to be merged. needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. labels May 15, 2019

Add ModelFeatureFlag and improve plugin support

b277051

vojtechszocs force-pushed the improve-plugin-support branch from e712229 to b277051 Compare May 17, 2019 15:29

This was referenced May 17, 2019

Improve nav item extensions #1584

Merged

Support models declared by plugins #1586

Merged

openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label May 17, 2019

openshift-merge-robot merged commit 60e27c8 into openshift:master May 18, 2019

vojtechszocs deleted the improve-plugin-support branch May 20, 2019 16:56

Add ModelFeatureFlag and improve plugin support #1528

Add ModelFeatureFlag and improve plugin support #1528

Uh oh!

Conversation

vojtechszocs commented May 3, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

New extensions

Code improvements

Uh oh!

openshift-ci-robot commented May 3, 2019

New extensions

Code improvements

Uh oh!

vojtechszocs commented May 3, 2019

Uh oh!

vojtechszocs commented May 3, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vojtechszocs commented May 6, 2019

Uh oh!

spadgett left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vojtechszocs May 6, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vojtechszocs commented May 13, 2019

Uh oh!

spadgett left a comment

Choose a reason for hiding this comment

Uh oh!

spadgett commented May 14, 2019

Uh oh!

spadgett commented May 14, 2019

Uh oh!

vojtechszocs commented May 14, 2019

Uh oh!

vojtechszocs commented May 15, 2019

Uh oh!

vojtechszocs commented May 17, 2019

Uh oh!

spadgett commented May 17, 2019

Uh oh!

openshift-ci-robot commented May 17, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

vojtechszocs commented May 3, 2019 •

edited

Loading

vojtechszocs May 6, 2019 •

edited

Loading