Open Stack

Much appreciate Alex.
As long they can all be called as "openstack overcloud xyz"  that should work if it allows user to control the order of the steps and ensure that previous step completed successfully.
We may loose a bit on possible parallelism.
But as long as we can provision and deploy multiple nodes in parallel it should be OK.

Thanks,
Arkady

-----Original Message-----
From: Alex Schultz <aschultz at redhat.com> 
Sent: Monday, October 26, 2020 3:53 PM
To: Kanevsky, Arkady
Cc: openstack-discuss at lists.openstack.org; Roquesalane, Jean-Pierre; Rehault, Gael
Subject: Re: [TripleO] [ptg] deployment flow


[EXTERNAL EMAIL] 

On Mon, Oct 26, 2020 at 2:36 PM Kanevsky, Arkady <Arkady.Kanevsky at dell.com> wrote:
>
> After today’s PTG meeting want to make sure I have the right understanding of deployment flow.
>
> After deploying  undercloud, are these the steps need to be done that are partially outside TripleO (https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/provisioning/baremetal_provision.html ):
>
> Ironic discovery to discover all nodes. (networking for ironic must be 
> in place for all nodes) Metalsmith will provision baremetal machines - 
> https://docs.openstack.org/metalsmith/latest/
> Metalsmith  provisions OS on provisioned nodes

This is the current process as of Victoria with the switch to nova being disabled on the undercloud by default.

> Something(???) optionally provisions Ceph (based  on appropriate 
> roles)

This was the possibly proposed solution based on the fact that we would also like to move network items outside of the deployment process. This would enable us to do the full OS provision + network configuration prior to deploying the OpenStack services which allows other processes to occur after provisioning but before openstack comes into the picture.

> Something(???) optionally provisions other 3rd party services, like 
> switch provisioning (based on appropriate roles)

This is not currently a thing, however could occur if we complete the work to separate the full network configuration of the hosts from the `openstack overcloud deploy` process.

> Metalsmith optionally provisions Glance (may require Ceph or other 3rd 
> party storage) Metalsmith optionally provisions Neutron (may require 
> switch provisioning)

No, this should not be handled by Metalsmith.  Metalsmith would simply handle the OS provisioning and basic network.

> TripleO deploys overcloud

TripleO deploys an overcloud with the configuration provided. By switching to metalsmith, the `openstack overcloud node provision` process produces an output file containing the required host information to the `openstack overcloud deploy` process.  This effectively turns on the pre-deployed method of deploying and removes the concept of server provisioning from the "deployment".  The thought is to continue to push towards this direction for ceph which would be another step that handles the configuration and deployment of ceph which provides TripleO friendly outputs that become an input into the `openstack overcloud deploy` command.  In the ceph world, this is similar to "external ceph".

If there's another 3rd party who would like to do something similar, that may also be viable.  The current idea is to not continue to add more things to tripleo, but leave it to the configuration and management of the openstack (and accompanying services) only.

It used to be:
`openstack overcloud deploy` did all the things (provisioning, network configuration, service configuration, etc).

We're moving more towards developing specific processes for each of the phases to improve usability, troubleshooting and better integration for external services and allowing for the more complex information of the cloud to be generated for the user rather than having them craft a bunch of custom heat files).

Something like:
`openstack overcloud node provision` (only does provisioning `opesntack overcloud network provision` (example name, only does networking configurations) `openstack overcloud deploy` (deploys software for OpenStack using outputs from previous two steps)

By splitting these a part into specific steps, this would allow for and optional `ceph-deployer` to be executed prior to `openstack overcloud deploy` meaning it can be completely managed by a different tool and as far as tripleo is concerned, we just get the relevant configuration information as inputs into the deployment process.
We're attempting to decouple the very tight integration at these stages which has been very hard to integrate with for 3rd parties or even our own services.

Hope that helps.

Thanks,
-Alex

>
>
>
> Is this the correct flow?
>
> Do we still need “openstack overcloud node provision” call or metalsmith already handles it? Or this call uses metalsmith under the cover?
>
>
>
> Thanks,
> Arkady