refined networking service procedure #512
Conversation
| The {networking_service} adoption is complete if you see the following results: | ||
|
|
||
| * The `NeutronAPI` service is running. | ||
| * The {identity_service_first_ref} endpoints are updated, and the same back end of the source cloud is available. | ||
|
|
||
| This guide also assumes that: |
There was a problem hiding this comment.
@slawqo Can you help me understand how this part is relevant to the procedure?
Also, what is meant by “one side” and “other side”? Do you mean "source environment (RHOSP)" and "target environment (the OpenShift cluster)"?
There was a problem hiding this comment.
I'm not sure what exactly You are asking for. This says about how to start adoption of the networking service (patch existing CR where neutron service was disabled to enable it) and how to validate that this adoption was finished (check that NeutronAPI is running and networking endpoints in the keystone db points to the new neutron service in the OpenShift cluster, and not the one in the OSP 17.1)
Where do You see "one side" and "other side" there? I don't see it so it is hard for me to tell what it means.
There was a problem hiding this comment.
@slawqo I apologize for the confusion. My comment applies to the following text:
"This guide also assumes that:
. A {OpenStackPreviousInstaller} environment (the source Cloud) is running on one side;
. A SNO / CodeReadyContainers is running on the other side."
There was a problem hiding this comment.
yes, so the 'one side' is actually old, tripleo/Director based deployment and 'the other side' is in this context is Openshift cluster (it can be CRC in e.g. u/s ci)
|
@slawqo The following comment is still in the file. Does info on SR-IOV adoption need to be added? |
|
|
||
| .Procedure | ||
| //The following link takes me to a 404. Do we need this text? I think we should start the procedure at "Patch OpenStackControlPlane..." | ||
| ifeval::["{build}" != "downstream"] | ||
| As already done for https://github.com/openstack-k8s-operators/data-plane-adoption/blob/main/keystone_adoption.md[Keystone], the Neutron Adoption follows the same pattern. | ||
| endif::[] | ||
|
|
||
| * Patch `OpenStackControlPlane` to deploy {networking_service}: | ||
| * Patch the `OpenStackControlPlane` CR to deploy the {networking_service}: |
There was a problem hiding this comment.
@slawqo Which files is being updated in this step? Is it the openstack_control_plane.yaml file, which defines the OpenStackControlPlane CR?
There was a problem hiding this comment.
basically what is updated in this step is the OpenStackControlPlane CR which is already in the OpenShift. You can do it in many different ways, like e.g.:
- updating openstack_control_plane.yaml file and then use
oc apply -fcommand to apply that file to the OCP, - using
oc edit openstackcontrolplanecommand and then update it "live" in the text editor, - using
oc patchcommand to patch existing CR and change this setting - this method is showed below
I think this can be removed simply as SR-IOV adoption is already described in the https://github.com/openstack-k8s-operators/data-plane-adoption/blob/main/docs_user/modules/proc_adopting-compute-services-to-the-data-plane.adoc |
klgill
force-pushed
the
Docs-Refine-Networking-Service
branch
from
ad023a6
to
8c1fa9f
Compare
https://issues.redhat.com/browse/RHOSPDOC-1636