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

MGMT-18227: Add quickstart document for new developers #6744

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

mlorenzofr
Copy link
Contributor

List all the issues related to this PR

  • New Feature
  • Enhancement
  • Bug fix
  • Tests
  • Documentation
  • CI/CD

What environments does this code impact?

  • Automation (CI, tools, etc)
  • Cloud
  • Operator Managed Deployments
  • None

How was this code tested?

  • assisted-test-infra environment
  • dev-scripts environment
  • Reviewer's test appreciated
  • Waiting for CI to do a full test run
  • Manual (Elaborate on how it was tested)
  • No tests needed

Checklist

  • Title and description added to both, commit and PR.
  • Relevant issues have been associated (see [CONTRIBUTING] guide)
  • This change does not require a documentation update (docstring, docs, README, etc)

Reviewers Checklist

  • Are the title and description (in both PR and commit) meaningful and clear?

@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Sep 10, 2024
@openshift-ci-robot
Copy link

openshift-ci-robot commented Sep 10, 2024

@mlorenzofr: This pull request references MGMT-18227 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the sub-task to target the "4.18.0" version, but no target version was set.

In response to this:

List all the issues related to this PR

  • New Feature
  • Enhancement
  • Bug fix
  • Tests
  • Documentation
  • CI/CD

What environments does this code impact?

  • Automation (CI, tools, etc)
  • Cloud
  • Operator Managed Deployments
  • None

How was this code tested?

  • assisted-test-infra environment
  • dev-scripts environment
  • Reviewer's test appreciated
  • Waiting for CI to do a full test run
  • Manual (Elaborate on how it was tested)
  • No tests needed

Checklist

  • Title and description added to both, commit and PR.
  • Relevant issues have been associated (see [CONTRIBUTING] guide)
  • This change does not require a documentation update (docstring, docs, README, etc)

Reviewers Checklist

  • Are the title and description (in both PR and commit) meaningful and clear?

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 openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci openshift-ci bot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label Sep 10, 2024
Copy link

openshift-ci bot commented Sep 10, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mlorenzofr

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 openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Sep 10, 2024
@mlorenzofr
Copy link
Contributor Author

@rccrdpccl @CrystalChun ptal when possible 🙏


We can start this scenario from the `assisted-test-infra` project:
```shell
make run
Copy link
Contributor

@paul-maidment paul-maidment Sep 10, 2024

Choose a reason for hiding this comment

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

I have been working on a guide for this use case, it's a workflow that I use regularly.

Feel free to use as much or as little as you like to add to this.

I am a big fan of using aicli and kcli, two great utilities written by our own @karmab so I have included setup information for my favoured use case in this doc.

Note that aicli and kcli are not official RedHat tools ... But they are superb :)

https://spaces.redhat.com/display/AI/Installing+a+cluster+with+assisted-test-infra%2C+kcli+and+aicli+and+HTTP+API

Copy link
Contributor

Choose a reason for hiding this comment

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

We really should mention that assisted-test-infra requires setup before you can perform make run

Also we should make it clear that assisted-test-infra is very opinionated during the setup phase and that the ideal place to use it is on a Beaker box or other ephemeral server. Using this on your laptop could cause some pain.

Copy link
Contributor

Choose a reason for hiding this comment

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

I am a big fan of using aicli and kcli, two great utilities writtern by our own @karmab so I have included setup information for my favoured use case in this doc.

I agree with Paul, should we mention those tools in the docs? We mention "tests" a lot, and I belive they are implied to be manual most of the time, aicli is a nice tool to do that, and kcli also is worth a mention IMO

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 have been working on a guide for this use case, it's a workflow that I use regularly.

Feel free to use as much or as little as you like to add to this.

I am a big fan of using aicli and kcli, two great utilities writtern by our own @karmab so I have included setup information for my favoured use case in this doc.

Note that aicli and kcli are not official RedHat tools ... But they are superb :)

I would create a simplified setup guide and add it to project assisted-test-infra, leaving a reference here. This way anyone who comes directly to the assisted-test-infra repository will also be able to find it.
BTW, 100% agree on reusing Paul's doc, but I need to review it, I'm having trouble logging into confluence right now.

## Testing Cluster-API (sylva/CAPI)
[Development environment using kind](kind/README.md)

If you are involved in the Cluster API (CAPI) project, which is responsible for the k8s cluster lifecycle management subsystem, you have a small development environment deployed in a local kind environment that will allow you to test it.
Copy link
Contributor

@paul-maidment paul-maidment Sep 10, 2024

Choose a reason for hiding this comment

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

Could we get a link to some documentation for CAPI here, something to give the reader the background they need to understand what CAPI and how it is being used?

I might not be working on a CAPI project today but I certainly want to learn all about CAPI.

## Testing Cluster-API (sylva/CAPI)
[Development environment using kind](kind/README.md)

If you are involved in the Cluster API (CAPI) project, which is responsible for the k8s cluster lifecycle management subsystem, you have a small development environment deployed in a local kind environment that will allow you to test it.
Copy link
Contributor

Choose a reason for hiding this comment

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

Not sure I agree, most of the time we'd need BMHs which is problematic to run in local environment.
We are trying to set up a way to work with remote k8s controlplane and VMs to spin up BMHs, but it's WiP.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It should also work on a local environment, but I understand you are concerned about resource usage and how this environment may affect the host. Maybe I can add a warning and recommend deploying it just on remote machines, WDYT?

The second paragraph tried to explain that this environment is still WiP:

If test clusters are to be deployed, additional work will be required, this section is pending development.

Copy link
Contributor

Choose a reason for hiding this comment

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

It should work on a local environment, but barely with a SNO and not all installations types, as one node requires at least 16GB of memory.
What's needed here is probably similar to Testing kube-api features, but with enough resources to spin up BMHs (which it might also be needed for kube-api).


The goal here would be to test the operation of the resources associated with assisted-installer through the kube-api. This is a lightweight scenario and we could work with a local environment.

We can install a local environment (Openshift / OKD / Microshift) with the **crc** tool. There is a section to perform this type of installation in the [Openshift console](https://console.redhat.com/openshift/create/local).
Copy link
Contributor

Choose a reason for hiding this comment

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

What's the difference between this scenario and the one below, Testing infrastructure operator?
Can't it be unified under the same point?

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 actually added this as another possibility since we had it as a reference in the ticket, but we could actually do these same tests with the infrastructure-operator scenario. If it is redundant and clearer we could eliminate this scenario.

@rccrdpccl
Copy link
Contributor

I think it would be clearer to state the possible type of environments by section, and each section explaining some use cases for such environment (with links to projects and all for more details. WDYT? Also, I think the opinion of new team members would help a lot. cc @linoyaslan @omer-vishlitzky WDYT?


In this scenario the goal is to run small tests with the assisted-installer REST API. This can be done in a local environment by starting the assisted-service with podman.

We can start it directly with make:
Copy link
Contributor

Choose a reason for hiding this comment

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

Should there also be a small bit about which repo to clone too?

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 would add it at the beginning, before starting with the possible scenarios because in all the shellcode boxes with make you are supposed to run make after cloning this repository. Maybe a small section called pre-requisites WDYT?

@linoyaslan
Copy link
Contributor

I think it would be clearer to state the possible type of environments by section, and each section explaining some use cases for such environment (with links to projects and all for more details. WDYT? Also, I think the opinion of new team members would help a lot. cc @linoyaslan @omer-vishlitzky WDYT?

I think it's a great idea! It would be helpful to expand the documentation with a deeper dive into test-infra details, like how to debug using dlv, and maybe a comparison of Minikube vs Kind in test-infra. Those are the main things that come to mind right now related to environments.

@openshift-ci openshift-ci bot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Oct 16, 2024
| [podman](##podman) | light | :white_check_mark: | small validations of API REST service |
| [crc](##crc) | medium | :white_check_mark: | tests with a local SNO Openshift/Microshift cluster |
| [assisted-test-infra](##assisted-test-infra) | heavy | :x: | testing and development of end-to-end tests |
| [infrastructure operator](#infrastructure-operator) | light / heavy | :x: | this should be valid to any test related with assisted-installer |
Copy link
Contributor

Choose a reason for hiding this comment

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

why is infrastrcuture-operator interleaved with podman,crc,test-infra and dev-scripts? Infrastructure Operator is a way to deploy assisted, while the others are frameworks/platforms

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The orientation, in all cases, is to do something related to assisted. Maybe it is not clear when putting podman or crc in other sections, in the case of infrastructure operator it would be kind.

Would it be clearer for a new developer if we put kind instead of infrastructure operator?

100c865abfd6 quay.io/edge-infrastructure/assisted-image-service:latest /assisted-image-s... 3 minutes ago Up 3 minutes 0.0.0.0:8080->8080/tcp, 0.0.0.0:8090->8090/tcp, 0.0.0.0:8888->8888/tcp assisted-installer-image-service
78924b68f7af quay.io/edge-infrastructure/assisted-service:latest /assisted-service 3 minutes ago Up 3 minutes 0.0.0.0:8080->8080/tcp, 0.0.0.0:8090->8090/tcp, 0.0.0.0:8888->8888/tcp assisted-installer-service
```
For testing we can use `curl`:
Copy link
Contributor

Choose a reason for hiding this comment

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

WDYT about mentioning and linking aicli? Maybe something like:

"For testing we can use curl (or aicli for more complex flows)"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, why not? I usually use aicli for SaaS but it is also possible to use it with a local cluster.
Do I need to provide an example of aicli or is linking it enough?

[Detailed documentation](https://github.com/openshift/assisted-test-infra/blob/master/README.md)

This scenario is useful for developing and testing our end-to-end tests.
This environment requires a large amount of resources since it will deploy additional baremetal hosts (VMs), so **running it in local environments is not recommended, do it on a beaker box or an ephemeral server**.
Copy link
Contributor

Choose a reason for hiding this comment

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

The main reason it's not recommended to run in local envs is not about resource usage, but it will change some host configuration that might be relevant for the user. Maybe worth mentioning? Maybe something like Assisted Test infra is an opinionated framework and running it in local environments is not recommended as it will change settings to the host


There is a section to perform this type of installation in the [Openshift console](https://console.redhat.com/openshift/create/local).

## infrastructure operator
Copy link
Contributor

Choose a reason for hiding this comment

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

I see this paragraph more as minikube/kind rather than infra operator.
We could deploy assisted with both infra operator or repo's manifests, and we'd achieve the same level of functionality

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Same as #r1812796099, maybe I can rename the section to kind instead of infrastructure operator.

Copy link
Contributor

@rccrdpccl rccrdpccl left a comment

Choose a reason for hiding this comment

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

Great work, overall I think this doc is clear and helpful for a new user. The only thing that I'd change is the section about infra-operator, which IMO is mixing what is deployed with where it's deployed, while all other sections are focused on where and how

Copy link

openshift-ci bot commented Oct 28, 2024

@mlorenzofr: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/edge-e2e-metal-assisted-odf-4-17 63a3129 link true /test edge-e2e-metal-assisted-odf-4-17
ci/prow/edge-e2e-metal-assisted-mtv-4-17 f96a58d link true /test edge-e2e-metal-assisted-mtv-4-17

Full PR test history. Your PR dashboard.

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-sigs/prow repository. I understand the commands that are listed here.

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. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. 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.

6 participants