-
Notifications
You must be signed in to change notification settings - Fork 615
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
Introduce kubevirt #1592
Introduce kubevirt #1592
Conversation
Hi @mareklibra. Thanks for your PR. I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
@mareklibra Note that #1584 is already merged. |
@@ -7,6 +7,7 @@ | |||
"dependencies": { | |||
"@console/internal": "0.0.0-fixed", | |||
"@console/plugin-sdk": "0.0.0-fixed", | |||
"@console/shared": "0.0.0-fixed" | |||
"@console/shared": "0.0.0-fixed", | |||
"@console/kubevirt-plugin": "0.0.0-fixed" |
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.
part of DO NOT MERGE commit
Looks good overall, I'm working #1586 to close the immediate gaps regarding model definitions and YAML template extension. |
This is addressed by #1613 |
Rebased, just #1613 is missing to be merged |
Thanks, reviewing this now 👀 |
@mareklibra There were some changes in #1613 (like |
@@ -0,0 +1 @@ | |||
// TODO(mlibra) |
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 to add this file later in a follow-up PR.
@christianvogt @spadgett We'd like to start adding React component snapshot tests and utilize Enzyme which is already set up in before-tests.js
.
The current proposal is to put snapshot files next to test files, for example:
path/to/widget.tsx
path/to/__tests__/widget.spec.tsx
path/to/__tests__/widget.spec.snap
To avoid the default path/to/__tests__/__snapshots__/widget.spec.snap
behavior, which adds unnecessary noise to existing file structure, we can configure Jest with custom snapshot resolver.
@mareklibra I'd prefer to first set up ^^ snapshot resolver before adding our snapshot tests.
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'm indifferent to the location of snapshots.
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.
Removed. I like the proposed collocation.
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.
#1648 should address test vs. snapshot co-location.
</div> | ||
<div className="dropdown-kebab-pf"> | ||
{/* | ||
<ResourceKebab actions={menuActions} kind={VirtualMachineModel.kind} resource={vm} resources={[ |
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.
@christianvogt @jelkosz This relates to our discussion about having a single map of models to corresponding actions, to be used consistently throughout the codebase.
For now, resource actions are handled on a local level, i.e. VM list page creating/using its "own" VM actions.
cc @spadgett
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 agree that this is something we should look at doing.
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.
+1, this is something we had been planning to do.
VMList.displayName = 'VMList'; | ||
|
||
const filters = undefined; | ||
/* TODO(mlibra): introduce extension point for list.tsx and reenable here then |
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 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 new extension point makes sense here.
Will be implemented within a follow-up, but menioning here to keep in mind:
To properly determine VM status, there are additional objects needed (pods and CRs). Recent filtering logic around list.tsx
can handle just the single object "listed" object. We will need to find a way how to supply additional resources 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.
So it will be handled via follow-ups for:
- extension point
- VM status filtering
- optionally: enhanced logic around
list.tsx
enabling examination of additional (related) objects
namespace: string; | ||
}; | ||
|
||
export class VirtualMachinesPage extends React.Component<VirtualMachinesPageProps> { |
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.
@mareklibra We should prefer using function-based components, i.e. React.FC
that can use hooks to support additional concerns like component state. @rawagner already did this in #1591.
We can improve this later on, just keep this in mind.
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.
done
@@ -0,0 +1,60 @@ | |||
import * as _ from 'lodash-es'; | |||
import { Plugin, ResourceNSNavItem, ResourceListPage, ResourceDetailPage, ModelFeatureFlag, YamlTemplate, ModelDefinition } from '@console/plugin-sdk'; |
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-pick: please split into multiple lines for better readability.
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.
done
import * as models from './models'; | ||
import { vmYamlTemplate } from './yaml-templates'; | ||
|
||
type ConsumedExtensions = ResourceNSNavItem | ResourceListPage | ResourceDetailPage | ModelFeatureFlag | YamlTemplate | ModelDefinition; |
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-pick: please split into multiple lines for better readability.
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.
done
resource: models.VirtualMachineModel.plural, | ||
required: FLAG_KUBEVIRT, | ||
}, | ||
mergeAfter: 'Pods', // rendered name of the resource navigation link in the left-side menu |
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.
Nav extension properties will be documented via #1638 so we can remove this comment, I think 😃
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.
done
type: 'ResourcePage/List', | ||
properties: { | ||
model: models.VirtualMachineModel, | ||
loader: () => import('./components/vm' /* webpackChunkName: "virtual-machines" */).then(m => m.VirtualMachinesPage), |
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.
For consistency with Metal3 plugin, I'd suggest using a kubevirt-
prefix in the chunk name, e.g. kubevirt-virtual-machines
or kubevirt-virtualmachines
.
It will give us better traceability when analyzing webpack-generated chunks that might come from different Console plugins.
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.
done
@@ -0,0 +1,37 @@ | |||
import { VirtualMachineModel } from './models'; | |||
|
|||
export const vmYamlTemplate = ` |
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.
Check out #1613 - a more robust (but also more complex) alternative is to use a map with tuple key [model, templateName]
:
import { Map as ImmutableMap } from 'immutable';
import { FooBarModel } from './models';
export const yamlTemplates = ImmutableMap()
.setIn([FooBarModel, 'default'], `
apiVersion: ${FooBarModel.apiVersion}
kind: ${FooBarModel.kind}
metadata:
name: example
namespace: default
`);
I'm OK with a simple const vmYamlTemplate
too.
In any case, please remove the leading whitespace (they aren't stripped automatically):
export const vmYamlTemplate = `
apiVersion: ${VirtualMachineModel.apiGroup}/${VirtualMachineModel.apiVersion}
kind: VirtualMachine
metadata:
name: example
..
`;
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.
done
@spadgett @christianvogt Please check my inline comment regarding snapshot testing. |
/retest |
So far without any functionlity.
An extension point needs to be implemented first.
And small code-style improvements.
As recently updated within @console/plugin-sdk: ResourcePage/List => Page/Resource/List ResourcePage/Detail => Page/Resource/Details
/test e2e-aws |
}; | ||
|
||
/* TODO(mlibra): migrate templates | ||
export const VmTemplateModel: K8sKind = { |
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.
This relates to #1658 - we really shouldn't redefine existing base k8s models.
I'm working on a PR that will integration-test actual Console plugins and detect any conflicts among their extensions.
(It's perfectly fine to do this in our Console fork, which is meant to support KubeVirt specifically.)
Thanks @mareklibra for updating the PR. As far as I can see, the only remaining issue is deciding whether KubeVirt related models will be declared as CRDs or not. Other than that, LGTM. |
We had this discussion back in the days when implementing it in the fork and the decision was to go as it is in this PR. If the PR is otherwise ready, I would really love to see it merged. If it will prove to be a problem, we can change it in a followup, but lets not block on it. @spadgett WDYT? |
Agreed. I'm fine with merging this and improve/change as needed. |
lodash "4.x" | ||
react-dnd "2.6.x" | ||
react-dnd-html5-backend "5.0.x" | ||
react-measure "2.x" |
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 look at removing this dependency from kubevirt-web-ui-components if we can. See discussion in #1591
@@ -8023,6 +8087,21 @@ kind-of@^6.0.0, kind-of@^6.0.2: | |||
version "6.0.2" | |||
resolved "https://registry.yarnpkg.com/kind-of/-/kind-of-6.0.2.tgz#01146b36a6218e64e58f3a8d66de5d7fc6f6d051" | |||
|
|||
kubevirt-web-ui-components@^0.1.34-4: |
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.
Can we consider removing this in this PR? We're only using getName
and getNamespace
currently. Those are trivial to implement.
Having this dependency defeats the purpose of the monorepo. Is it feasible to simply bring the components in to console directly as we add the capabilities? (I don't know the code well enough to say.)
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.
Sam, this is just initial PR with bare minimum functionality to enable transfer of the rest in follow-ups. I guess 80% of the planed functionality is recently in kubevirt-web-ui.
As mentioned before: we plan to deprecate kubevirt-web-ui
asap and so remove it even from dependencies here.
But doing it now would cause us a lot of troubles in case we do not achieve full feature parity in 4.2 timeframe (considering recent progress, this is valid concern).
So if possible, it will be huge relieve for us to keep it and go safely feature-by-feature.
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 whole kubevirt-web-ui-components will be moved into this monorepo, but only as a last step. I would like to avoid duplicating the code as part of this effort and having the same stuff on two places. We still need to maintain the fork and its releases so it is important to have it on one place only and if we make fix there, not to have to create a new fix also here.
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.
Until the transition from our fork to Console plugins is complete (in terms of feature parity), it's more practical to use kubevirt-web-ui-components
as an external library. As @mareklibra mentioned, there's always the chance of not achieving full parity in 4.2 timeframe.
Once our fork is discontinued, we can
- either move
kubevirt-web-ui-components
as-is under e.g.packages/kubevirt-components
(which isn't ideal, since it's plain JS and its code & deps might need revisiting, likereact-measure
mentioned above) - or we can create an empty e.g.
packages/kubevirt-components
and gradually bring in the necessary bits (revisiting & migrating them to TS in the process) and eventually remove thekubevirt-web-ui-components
dependency
Personally, I favor the second approach.
@@ -0,0 +1,136 @@ | |||
import { K8sKind } from '@console/internal/module/k8s'; | |||
|
|||
export const VirtualMachineModel: K8sKind = { |
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 would suggest crd: true
for now, although I think we should get rid of the crd
property in the model object if we can. It's a bit misleading since not all CRDs have it, and some resources have it that aren't CRDs. We used to key on it for other behavior changes around watches, but I think we've removed that.
Honestly, I don't think most users will notice or care if the URL doesn't use the short name. The biggest problem is that we include the API version in the URL, not just the group. This could break links if versions change (for instance, v1alpha1 -> v1). But that's outside the scope of this PR. We need to look at this problem generally, not just for KubeVirt.
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
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mareklibra, spadgett 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 |
Initial effort of merging https://github.com/kubevirt/web-ui fork features back to upstream.
New
kubevirt-plugin
is created with bare minimum functionality in terms of listing Virtual Machines.Additional features will be moved within follow-ups.
Depends on:
Improve nav item extensions #1584Support models declared by plugins #1586kinds.ts: Fix connectToPlural() for plugin's models #1600NavSection: allow plugins to define their position #1609Add YAML template extension #1613add extension to contribute arbitrary pages #1668TODO:
Some of immediate follow-ups: