Skip to content
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

Merged
merged 14 commits into from
Jun 7, 2019
Merged

Introduce kubevirt #1592

merged 14 commits into from
Jun 7, 2019

Conversation

mareklibra
Copy link
Contributor

@mareklibra mareklibra commented May 21, 2019

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:


TODO:


Some of immediate follow-ups:

  • VM-status with fetching of related objects
  • VM Detail page
  • VM templates (list, detail)
  • Create VM Wizard

@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. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels May 21, 2019
@openshift-ci-robot
Copy link
Contributor

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 /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

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.

@openshift-ci-robot openshift-ci-robot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label May 21, 2019
@vojtechszocs
Copy link
Contributor

@mareklibra Note that #1584 is already merged.

@openshift-ci-robot openshift-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. labels May 22, 2019
@mareklibra mareklibra changed the title [WIP] Introduce kubevirt2 [WIP] Introduce kubevirt May 22, 2019
@spadgett spadgett added this to the v4.2 milestone May 22, 2019
frontend/package.json Outdated Show resolved Hide resolved
@@ -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"
Copy link
Contributor Author

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

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

Looks good overall, I'm working #1586 to close the immediate gaps regarding model definitions and YAML template extension.

@vojtechszocs
Copy link
Contributor

introduce new extension point for yaml templates (initially for Create VM from Yaml)

This is addressed by #1613

@openshift-ci-robot openshift-ci-robot added needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. 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. needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. labels May 28, 2019
@mareklibra
Copy link
Contributor Author

Rebased, just #1613 is missing to be merged

@yaacov yaacov mentioned this pull request May 30, 2019
3 tasks
@vojtechszocs
Copy link
Contributor

Rebased, just #1613 is missing to be merged

Thanks, reviewing this now 👀

@vojtechszocs
Copy link
Contributor

@mareklibra There were some changes in #1613 (like YamlTemplate => YAMLTemplate) so please rebase.

@@ -0,0 +1 @@
// TODO(mlibra)
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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={[
Copy link
Contributor

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

Copy link
Contributor

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.

Copy link
Member

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
Copy link
Contributor

Choose a reason for hiding this comment

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

@jelkosz This is a gap we need to close, i.e. make listFilters in public/components/factory/list.tsx extensible.

cc @spadgett

Copy link
Contributor Author

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.

Copy link
Contributor Author

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> {
Copy link
Contributor

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.

Copy link
Contributor Author

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';
Copy link
Contributor

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.

Copy link
Contributor Author

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;
Copy link
Contributor

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.

Copy link
Contributor Author

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
Copy link
Contributor

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 😃

Copy link
Contributor Author

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),
Copy link
Contributor

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.

Copy link
Contributor Author

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 = `
Copy link
Contributor

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
..
`;

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

@vojtechszocs
Copy link
Contributor

@spadgett @christianvogt Please check my inline comment regarding snapshot testing.

@openshift-ci-robot openshift-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label May 31, 2019
@mareklibra
Copy link
Contributor Author

/retest

@openshift-ci-robot openshift-ci-robot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Jun 6, 2019
@mareklibra
Copy link
Contributor Author

/test e2e-aws

};

/* TODO(mlibra): migrate templates
export const VmTemplateModel: K8sKind = {
Copy link
Contributor

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.)

@vojtechszocs
Copy link
Contributor

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.

@jelkosz
Copy link

jelkosz commented Jun 6, 2019

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?

@vojtechszocs
Copy link
Contributor

If it will prove to be a problem, we can change it in a followup, but lets not block on it.

Agreed. I'm fine with merging this and improve/change as needed.

@mareklibra mareklibra mentioned this pull request Jun 7, 2019
4 tasks
lodash "4.x"
react-dnd "2.6.x"
react-dnd-html5-backend "5.0.x"
react-measure "2.x"
Copy link
Member

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:
Copy link
Member

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.)

Copy link
Contributor Author

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.

Copy link

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.

Copy link
Contributor

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, like react-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 the kubevirt-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 = {
Copy link
Member

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.

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
/approve

@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
Contributor

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@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 7, 2019
@openshift-merge-robot openshift-merge-robot merged commit e966550 into openshift:master Jun 7, 2019
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. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants