Add the OpenStack UPI enhancement proposal #23
Conversation
openshift-ci-robot
added
the
size/L
|
Since automation is going to be done with the help of Ansible, have we considered that RHCOS does not come with python installed. And I have previously seen some Ansible modules requiring python on target machines. |
Hold on, the |
Fedora CoreOS has done it already. See coreos/fedora-coreos-tracker#32 The best pattern is to run Ansible from a container image, not the host. This proposal seems to be about using Ansible to control the OpenStack infra, which should work perfectly well in a container. Where things get a bit trickier is if you want a containerized Ansible to affect the host - do you e.g. need to make changes on the bootstrap host too? |
|
Thanks folks for your input. I'm not sure whether we have anything that requires python in the rhcos image (nodes running rhcos will be the target nodes) however we'll definitively keep that info in the back of our mind while developing the ansible scripts. |
|
The OpenStack cloud Ansible modules only require Python on the machine calling Ansible (and you need it there for Ansible itself). The modules themselves call the OpenStack APIs and are only used for the creation of the OpenStack resources (e.g. networks, subnets, floating IP addresses, security groups, servers, ports etc.) There is no requirement for Python or even SSH on the RHCOS images for this to work. |
pierreprinetti
force-pushed
the
openstack-upi
branch
2 times, most recently
from
c15d033 to
eb2a0d3
Compare
|
/lgtm |
openstack-upi/openstack-upi.md
Outdated
| the [bare metal][baremetal-upi] document or try to translate concepts | ||
| from the AWS one. | ||
|
|
||
| [baremetal-upi]: https://github.com/openshift/installer/blob/master/docs/user/metal/install_upi.md |
There was a problem hiding this comment.
move this to the end of the document.
openstack-upi/openstack-upi.md
Outdated
|
|
||
| ## Summary | ||
|
|
||
| The initial OpenStack support for OpenShift 4 was around the IPI |
There was a problem hiding this comment.
nit: IPI installer-provisioned
openstack-upi/openstack-upi.md
Outdated
| The initial OpenStack support for OpenShift 4 was around the IPI | ||
| workflow. While this is the most convenient approach for the end-users | ||
| of OpenStack, there are situations where it falls short. People who | ||
| want to use OpenStack UPI today have to fall back on |
There was a problem hiding this comment.
People who want to use OpenStack UPI today have to fall back on
the [bare metal][baremetal-upi] document or try to translate concepts
from the AWS one.
hmm, not sure what you mean here?
openstack-upi/openstack-upi.md
Outdated
| [baremetal-upi]: https://github.com/openshift/installer/blob/master/docs/user/metal/install_upi.md | ||
|
|
||
| Similar to AWS and GCP, we want to provide the documentation and | ||
| automation (via Ansible) that is specific to OpenStack -- using the |
There was a problem hiding this comment.
automation and user-provisioned are kinda weird. the goal is provide a reference...
|
@abhinavdahiya PTAL |
pierreprinetti
force-pushed
the
openstack-upi
branch
3 times, most recently
from
9fa042f to
ab3dad2
Compare
|
/lgtm |
| Configurations and integrations that are not currently supported by | ||
| the OpenStack IPI. For example: | ||
|
|
||
| Things such as detailed steps for the provider network support, using | ||
| Octavia or Designate for the load balancer / DNS, custom storage | ||
| integration and so on can be added as optional sections once the | ||
| initial UPI work is complete. |
pierreprinetti
force-pushed
the
openstack-upi
branch
from
ab3dad2 to
23dd10a
Compare
|
Thanks again @abhinavdahiya, I think I have addressed your comments. |
| https://github.com/openshift/installer/blob/master/docs/user/openstack/install_upi.md | ||
| * Ansible playbooks for automating the OpenStack resource creation | ||
| available under: | ||
| https://github.com/openshift/installer/tree/master/upi/openstack |
There was a problem hiding this comment.
The contents of installer/upi are not shipped in any artifacts today. You'll notice that th AWS templates are actually copied and pasted into documentation. ex: https://docs.openshift.com/container-platform/4.2/installing/installing_aws_user_infra/installing-aws-user-infra.html#installation-cloudformation-vpc_installing-aws-user-infra
Are we going to be doing the same or does there need to be some new artifact which contains these files?
There was a problem hiding this comment.
The idea is to ship the playbooks as documentation (having them in the installer repo will come handy for testing them in the CI). That's in our backlog. Should I amend the RFE to mention that intention?
There was a problem hiding this comment.
Ok, that's fine. I'd just suggest keeping that in mind when developing them as it will be somewhat limiting in how you structure things.
|
/approve |
openshift-ci-robot
added
the
approved
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: iamemilio, mandre, sdodson, tomassedovic 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 |
This adds a proposal to implement OpenStack UPI in 4.3.
The initial support should mostly just document and automate (with Ansible) what the IPI work does, taking inspiration from the existing UPI documents.