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
Independent Mode Dashboard #3907
Independent Mode Dashboard #3907
Conversation
bipuladh
commented
Jan 9, 2020
- Added blocker extension point to block out the CEPH dashboard if the independent mode is present.
frontend/packages/ocs-independent-plugin/src/components/dashboard-page/details-card/card.tsx
Outdated
Show resolved
Hide resolved
0fdfb94
to
c0847fe
Compare
7f3d8c5
to
8c3d0c9
Compare
@@ -9,3 +9,4 @@ export const PODS = 'Pods'; | |||
export const BY_USED = 'By Used Capacity'; | |||
export const BY_REQUESTED = 'By Requested Capacity'; | |||
export const OCS_OPERATOR = 'ocs-operator'; | |||
export const INDEPENDENT_FLAG = 'INDEPENDENT_FLAG'; |
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.
Let's try to keep a clear exported API boundary between Console plugins.
- in
ocs-independent-plugin/src/plugin.ts
export const INDEPENDENT_FLAG = 'INDEPENDENT_FLAG';
- add
ocs-independent-plugin/src/index.ts
export { INDEPENDENT_FLAG } from './plugin';
- in
ocs-independent-plugin/package.json
..
"private": true,
"main": "src/index.ts",
"dependencies": ..
..
and finally in ceph-storage-plugin/src/plugin.ts
import { INDEPENDENT_FLAG } from '@console/ocs-independent-plugin';
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 this because. ocs is dependent on ceph already. If I export this from ocs then wouldn't this cause a circular dependency issue?
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 I meant is the feature flag constant should live close to the Console plugin which "owns" it.
In this case, it would be ocs-independent-plugin
which declares it as
{
type: 'FeatureFlag/Model',
properties: {
model: OCSServiceModel,
flag: INDEPENDENT_FLAG,
},
},
We should avoid duplicating the same constant value across different packages.
Also, I'd suggest to modify the flag's value to CEPH_INDEPENDENT
or OCS_INDEPENDENT
to reflect relationship with OCS.
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.
ocs is dependent on ceph already
Does it make sense to merge OCS/independent plugin code into existing Ceph plugin? These two plugins seem to be closely related.
If we want to keep them separated and avoid dependency cycle, we should move the common code into console-shared
package, e.g. packages/console-shared/src/constants/flags.ts
declaring shared flags.
const requiredFlags = e.properties.required ? _.castArray(e.properties.required) : []; | ||
return _.every(requiredFlags, (f) => flags[f]); | ||
return ( | ||
_.every(requiredFlags, (f) => flags[f]) && _.every(disallowedFlags, (f) => flags[f] === false) |
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.
_.every(requiredFlags, (f) => flags[f]) && _.every(disallowedFlags, (f) => flags[f] === false) | |
_.every(requiredFlags, (f) => flags[f] === true) && _.every(disallowedFlags, (f) => flags[f] === false) |
frontend/packages/metal3-plugin/src/constants/bare-metal-host.ts
Outdated
Show resolved
Hide resolved
import { GridPosition } from '@console/shared/src/components/dashboard/DashboardGrid'; | ||
import { OCSServiceModel } from '@console/ceph-storage-plugin/src/models'; | ||
import { detectIndependentMode } from './feature'; | ||
import { INDEPENDENT_FLAG } from './consts'; |
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'd suggest keeping flag name constants inside the plugin entry module (this file).
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'd suggest keeping flag name constants inside the plugin entry module (this file).
Update: if the flag is managed via detector function, move it to corresponding features
module. If it's shared between multiple packages, move it to console-shared
constants.
@@ -294,7 +281,6 @@ export const detectFeatures = () => (dispatch: Dispatch) => | |||
[ | |||
detectOpenShift, | |||
// TODO(vojtech): move this flag definition to metal3-plugin via ActionFeatureFlag extension | |||
detectBaremetalPlatform, |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
frontend/public/reducers/features.ts
Outdated
case ActionType.AddFlag: | ||
// eslint-disable-next-line no-console | ||
console.log(`${action.payload.flag} is added`); | ||
return state.set(action.payload.flag, false); |
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 initial value should be set to undefined
(feature detection in progress).
false
means the feature detection is complete and feature is not available.
But I don't think we really need another action, like ActionType.AddFlag
.
The simplest way to handle flags outside the base FLAGS
enum is to remove unknown flag check for ActionType.SetFlag
:
case ActionType.SetFlag:
return state.set(action.payload.flag, action.payload.value);
But I think the best solution is to iterate over all extensions which deal with flags and build an array of allowed flag names, and check against that.
8c3d0c9
to
42ac2f1
Compare
42ac2f1
to
c45c40b
Compare
c45c40b
to
fd38b74
Compare
/retest |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest |
/hold build is failing due to incorrect import
|
501aca1
to
7cb77df
Compare
Fixed rebase conflict in /hold cancel |
/lgtm |
7cb77df
to
8384bb4
Compare
/retest |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bipuladh, rawagner, vojtechszocs 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 |
/retest |
/retest Please review the full test history for this PR and help us cut down flakes. |
3 similar comments
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |