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

oVirt IPI enhancement document #61

Merged
merged 2 commits into from
Jan 22, 2021

Conversation

rgolangh
Copy link
Contributor

@rgolangh rgolangh commented Oct 6, 2019

@openshift-ci-robot openshift-ci-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Oct 6, 2019
@sdodson
Copy link
Member

sdodson commented Oct 7, 2019

/cc @crawford @abhinavdahiya

@rgolangh rgolangh changed the title oVirt IPI enhancment document oVirt IPI enhancement document Oct 7, 2019
- essentially providing an internal cluster-level DNS service using mDNS and
coreDNS, and load-balancing using keepalived.

Components involved:
Copy link
Contributor

Choose a reason for hiding this comment

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

what about the ingress-controller?

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'm adding a note to reference this in baremetal networking doc.
Also, I don't think I need to change something in ingress controller itself but
I do need t ask the user for the ingress IP and hence I added this in the PR the PlatformStatus:

type OvirtPlatformStatus struct {
	...

	// ingressIP is an external IP which routes to the default ingress controller.
	// The IP is a suitable target of a wildcard DNS record used to resolve default route host names.
	IngressIP string `json:"ingressIP,omitempty"`
}

of the installation: **url**, **user** and **password** of ovirt api. The installer \
will validate it can communicate with the api, otherwise it will fail to proceed.\
Next the installer will ask to choose the ovirt **cluster**, where the VMs will be\
created, and next would be a *template* from that cluster for those VMs.\
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you link or provide details around what is a template?

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

I would like to see these things detailed:

1. How does the boot-images for VMs work?

Will adding this document help? [coreos ignition support][https://ovirt.org/develop/release-management/features/virt/coreos-ignition-support.html]

2. How the ingress-controllers are setup, internally for cluster and how it would be exposed for users.
3. What is the storage setup.

As far as I understand this is day-two operation needed for the registry?

4. Does is turn on any cloud-provider code in k8s? If yes, how are credentials handled?

no, cloud provider is not needed.

Also the docs references Baremetal networking and I couldn't find link for that..

It is at the bottom

Copy link
Contributor

Choose a reason for hiding this comment

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

https://ovirt.org/develop/release-management/features/virt/coreos-ignition-support.html

404s

  1. How does the boot-images for VMs work?

Where will you get the boot-images from? For bootstrap, control-plane and compute.
Is there anything special when providing large ignition files like bootstrap.ign

Copy link
Contributor Author

Choose a reason for hiding this comment

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

https://ovirt.org/develop/release-management/features/virt/coreos-ignition-support.html

404s

It works

  1. How does the boot-images for VMs work?

Where will you get the boot-images from? For bootstrap, control-plane and compute.

For this stage the users will upload the RHCOS qcow image as a template. Later in the survey they will see it and choose it. I add a section to describe that.
I may change that in the future to be easier to use.

Is there anything special when providing large ignition files like bootstrap.ign

No. The boostrap.ign works the same ways for masters and workers, our DB doesn't have the limitation I think openstack had/has

Copy link
Contributor

Choose a reason for hiding this comment

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

For this stage the users will upload the RHCOS qcow image as a template. Later in the survey they will see it and choose it. I add a section to describe that.
I may change that in the future to be easier to use.

So users are allowed to pick a template other than vetted by the installer in IPI??

that is a departure from other 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.

How does the installer does that? guide me here, and I'll asses how much work do I need to make it work like that.

Copy link
Contributor

Choose a reason for hiding this comment

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

on AWS, the installer picks the AMI from the embedded https://github.com/openshift/installer/blob/909f4f8409de9ffe561779bd9f46909a0a14da1d/data/data/rhcos.json#L2-L51 and then creates the machines.

on Azure, the installer picks the vhd URL from embedded https://github.com/openshift/installer/blob/909f4f8409de9ffe561779bd9f46909a0a14da1d/data/data/rhcos.json#L54 -> imports the VHD to percluster storage blob -> Creates an Image using the VHD and creates machines using the Image.

similarly on GCP.

openstack is also in the process to moving to this model, openshift/installer#2473

terraform, which automatically load `.auto.tfvars.json`. `terraform.tfstate` is\
the actual declaration of the resources and with it terraform creates the VMs.\

3. Bootstrap
Copy link
Contributor

Choose a reason for hiding this comment

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

This needs to take into account how cluser-etcd-operator fits into bootstrapping.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Can you elaborate?

Copy link
Contributor

Choose a reason for hiding this comment

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

#56

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 impact of the etcd-operator on the need publishing of the SRV records will probably mean that ovirt, baremetal and openstack platforms can have simpler bootstraping, but it is not yet understood how this is going to change. I'll add it as related enhancement.

The bootstrap VM has a huge ignition config set using terraform and is visible\
in the `terraform.tfstate` file. oVirt boots that VM with that content and the\
bootstraping begins when the `bootkube.service` systemd service starts.\
The bootstrap job is to:
Copy link
Contributor

Choose a reason for hiding this comment

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

I would like these steps to outline what special is being done with oVirt rather the bootstrap process in general

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nothing special in fact. Do you have a link that explains the bootstrap process?

Choose a reason for hiding this comment

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

@abhinavdahiya
Copy link
Contributor

I would like to see these things detailed:

  1. How does the boot-images for VMs work?

  2. How the ingress-controllers are setup, internally for cluster and how it would be exposed for users.

  3. What is the storage setup.

  4. Does is turn on any cloud-provider code in k8s? If yes, how are credentials handled?

Also the docs references Baremetal networking and I couldn't find link for that..


- Storage

Recommended storage setup?
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@mykaul I want to write down a word about recommended storage setup. Can you help? is there anything to take into account?

Copy link

Choose a reason for hiding this comment

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

Assuming there's an oVirt CSI driver, then exposing some of the properties (like thin or preallocated provisioning) makes sense. Otherwise, it should be quite straightforward.

rgolangh added a commit to rgolangh/installer that referenced this pull request Oct 28, 2019
This work establishes an IPI installation on oVirt platform.

Installation document:
https://github.com/openshift/installer/tree/master/docs/user/oviret

The enhancement document:
openshift/enhancements#61

The installation uses a similar network infrastructure to baremetal.
https://github.com/openshift/installer/blob/master/docs/design/baremetal/networking-infrastructure.md

Signed-off-by: Roy Golan <rgolan@redhat.com>
rgolangh added a commit to rgolangh/installer that referenced this pull request Oct 29, 2019
This work establishes an IPI installation on oVirt platform.

Installation document:
https://github.com/openshift/installer/tree/master/docs/user/ovirt

The enhancement document:
openshift/enhancements#61

The installation uses a similar network infrastructure to baremetal.
https://github.com/openshift/installer/blob/master/docs/design/baremetal/networking-infrastructure.md

Signed-off-by: Roy Golan <rgolan@redhat.com>
rgolangh added a commit to rgolangh/installer that referenced this pull request Oct 29, 2019
This work establishes an IPI installation on oVirt platform.

Installation document:
https://github.com/openshift/installer/tree/master/docs/user/ovirt

The enhancement document:
openshift/enhancements#61

The installation uses a similar network infrastructure to baremetal.
https://github.com/openshift/installer/blob/master/docs/design/baremetal/networking-infrastructure.md

Signed-off-by: Roy Golan <rgolan@redhat.com>
rgolangh added a commit to rgolangh/installer that referenced this pull request Oct 29, 2019
This work establishes an IPI installation on oVirt platform.

Installation document:
https://github.com/openshift/installer/tree/master/docs/user/ovirt

The enhancement document:
openshift/enhancements#61

The installation uses a similar network infrastructure to baremetal.
https://github.com/openshift/installer/blob/master/docs/design/baremetal/networking-infrastructure.md

Signed-off-by: Roy Golan <rgolan@redhat.com>
rgolangh added a commit to rgolangh/installer that referenced this pull request Oct 29, 2019
This work establishes an IPI installation on oVirt platform.

Installation document:
https://github.com/openshift/installer/tree/master/docs/user/ovirt

The enhancement document:
openshift/enhancements#61

The installation uses a similar network infrastructure to baremetal.
https://github.com/openshift/installer/blob/master/docs/design/baremetal/networking-infrastructure.md

Signed-off-by: Roy Golan <rgolan@redhat.com>
rgolangh added a commit to rgolangh/machine-api-operator that referenced this pull request Jan 15, 2020
This work is part of making oVirt a supported platform
as mentioned in this the enhancement document:
openshift/enhancements#61

oVirt's cluster-api-providr[1] is added to images.json and
it returned for platform type 'ovirt'.

[1] https://github.com/ovirt/cluster-api-provider-ovirt

Related-to: openshift/installer#1948
Signed-off-by: Roy Golan <rgolan@redhat.com>
rgolangh added a commit to rgolangh/release that referenced this pull request Jan 16, 2020
Publish ovirt/cluster-api-ptovider-ovirt image

Enhancement: openshift/enhancements#61
Signed-off-by: Roy Golan <rgolan@redhat.com>
rgolangh added a commit to rgolangh/release that referenced this pull request Jan 16, 2020
Enhancement: openshift/enhancements#61
Signed-off-by: Roy Golan <rgolan@redhat.com>
jhixson74 pushed a commit to jhixson74/installer that referenced this pull request Jan 30, 2020
This work establishes an IPI installation on oVirt platform.

Installation document:
https://github.com/openshift/installer/tree/master/docs/user/ovirt

The enhancement document:
openshift/enhancements#61

The installation uses a similar network infrastructure to baremetal.
https://github.com/openshift/installer/blob/master/docs/design/baremetal/networking-infrastructure.md

Signed-off-by: Roy Golan <rgolan@redhat.com>
@sdodson
Copy link
Member

sdodson commented Feb 27, 2020

@rgolangh should we go ahead and merge this? I don't know how much actual implementation has deviated from what's outlined here but we should make sure that the enhancement gets merged.

@dougsland
Copy link

@sdodson @abhinavdahiya looks like an old PR. I would consider merging (or abandon?) this document. The oVirt support is already working in the master tree with @rgolangh patches and also listed as one of the platform supported in the README.

will validate it can communicate with the api, otherwise it will fail to proceed.\
Next the installer will ask to choose the ovirt **cluster**, where the VMs will be\
created, and next would be a *template* from that cluster for those VMs.\
*Note* that it is the user's responsibility to upload the relevant RHCOS template\

Choose a reason for hiding this comment

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

Outdated.

Copy link

@dougsland dougsland left a comment

Choose a reason for hiding this comment

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

LGTM, nit changes.

@sdodson
Copy link
Member

sdodson commented Jun 9, 2020

/lgtm
/hold
@rgolangh As long as there are no major deviations between actual implementation and what's written up here go ahead and lift the hold so that we can merge this. If there are significant deviations lets get this updated and merged ASAP.

@openshift-ci-robot openshift-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jun 9, 2020
@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Jun 9, 2020
@openshift-ci-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rgolangh, sdodson

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 9, 2020
@russellb
Copy link
Member

@rgolangh can you take a look at this and ensure it reflects what has already been implemented? then we can just merge this

Signed-off-by: Roy Golan <rgolan@redhat.com>
Signed-off-by: Roy Golan <rgolan@redhat.com>
@openshift-ci-robot openshift-ci-robot removed the lgtm Indicates that a PR is ready to be merged. label Oct 14, 2020
@rgolangh
Copy link
Contributor Author

@sdodson @russellb I updated the section of the template as noted here #61 (comment)

This enhancement needs more updates (CSI for example) but for now I'm good with merging it. I neglected it long enough.

@openshift-bot
Copy link

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

@openshift-ci-robot openshift-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 12, 2021
@russellb
Copy link
Member

OK, I'll merge and follow-up PRs can update this as necessary. It should be in the repo now to reflect what was already done.

/hold cancel
/lgtm

@openshift-ci-robot openshift-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jan 22, 2021
@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Jan 22, 2021
@openshift-merge-robot openshift-merge-robot merged commit 007853c into openshift:master Jan 22, 2021
This document describes how `oVirt` becomes a platform provider for Openshift. \
`oVirt` is a virtualization platform and is similar to the `baremetal` platform \
provider it is lacking DNS and Load-Balancing services, but it has the advantage \
if software-defining your data-center, utilizing existing hardware and making \
Copy link

Choose a reason for hiding this comment

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

if -> of

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. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. 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.

10 participants