ffjlabo
commented
1 month ago Platform Provider; Livestatestore
The purpose of the component
- Livestatestore stores the actual resource state for each app belonging to the platform.
- Livestatestore is almost all for the platform-specific things such as detector, livestatereporter, and executor.
Modification idea
- Put it on the plugin side
- Store the app resource state per
deployTarget - Introduce an aggregation layer to get multiple resource states by appID across the multiple deployTarget, In case of the multiple deployTarget per app,
khanhtc1202
What would you like to be added:
This issue tracks the progress for deprecating Platform Provider and Kind toward piped plugin architecture in pipedv1.
The purpose is to manage application kind and platform providers on the PipeCD plugin side in the future.
Considering the impact on users, pay attention to the following points:
current update process
kindbased on the current Application Kind to the Application.deployTargetbased on the current Application Platform Provider to the Application.Details (under planning)
For Platform Provider
Instead of Platform Provider, we plan to introduce the config for the plugin and define deployTargets.
piped config
We also plan to deploy the app to multiple targets at once in a multicluster feature for k8s. So, we define
DeployTargetsas an array in Application and Deployment.Application
Deployment
For the backward compatibility
Before updating the piped, users should migrate the current data on DB.
Former idea
During the migration, there might be both platform providers and deploy targets in the piped config. So we need to convert the platform providers to deploy targets internally. **Refer the Platform Provider or Deploy Target** - If the ApplicationKind is `Application`, just use `DeployTarget` - If the ApplicationKind is old one, convert `PlatformProvider` to `DeployTarget` ```golang func (s *PipedSpec) FindDeployTarget(name string, t model.ApplicationKind) (*PipedDeployTarget, bool) { // First, check the application is supported by the plugin architecture. It means that the kind is set to "Application". // If not, the deploy target is the platform provider. // For backward compatibility, the deploy target is the platform provider. if t != model.ApplicationKind_APPLICATION { p, found := s.FindPlatformProvider(name, t) if !found { return &PipedDeployTarget{}, false } return &PipedDeployTarget{ Name: p.Name, Labels: p.Labels, Config: p.Config, }, true } // If the application is supported by the plugin architecture, the deploy target is the deploy target. for _, dt := range s.DeployTargets { if dt.Name == name { return dt, true } } return &PipedDeployTarget{}, false } ```For Kind
Instead of Kind, we plan to introduce the label to represent the application kind.
For the builtin plugins, we define 5 labels as string.
For the backward compatibility
Before updating the piped, users should migrate the current data on DB.
Former idea
We need to support both before and after creating plugin architecture for now. So, I propose the way to decide the application kind like this. - Define `APPLICATION` as `ApplicationKind` - Add new method to decide the actual kind for Application and Deployment. ```proto enum ApplicationKind { KUBERNETES = 0; TERRAFORM = 1; LAMBDA = 3; CLOUDRUN = 4; ECS = 5; APPLICATION = 6; <- new! } ``` ```golang func (a * Application) GetKind() string { // First, check the application is supported by the plugin architecture. It means that the kind is set to "Application". // If so, return the kind from the labels. if a.Kind == ApplicationKind_Application { return a.Labels["kind"] } // For backward compatibility, return the kind as string return a.Kind.String() } ``` ```golang func (d *Deployment) GetKind() string { // First, check the application is supported by the plugin architecture. It means that the kind is set to "Application". // If so, return the kind from the labels. if d.Kind == ApplicationKind_Application { return d.Labels["kind"] } // For backward compatibility, return the kind as string return d.Kind.String() } ```TODO
Firstly, I listed the target features to require some modifications. We need to further investigation to decide the way to fix.
investigation
implementation
Why is this needed: