ART-9026 add new api for check schedule

[Ximinhan]

Add 3 api in art-dashboard-server used for check schedule

• /advisory_activites
  this API will get advisory status, used for monitor advisory moved to shipped status
• /release_schedule
  this API will get release schedule of a release version, used for determine release date
• /release_status
  this API will get overall release status used for report summary for alert message

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from ximinhan. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ashwindasr]

Can I know why this scheduled job is here and not in aos-cd-jobs along with the other scheduled jobs? Unless there is a good reason, I would really like it to be in aos-cd-jobs

https://github.com/openshift-eng/aos-cd-jobs/tree/master/scheduled-jobs/scanning

[Ximinhan]

Different from the Jenkins job, this is a script that will build into the image. I used to think that moving this part to art-tools/art-cluster/pipelines, may be the right place along with task and job config. But consider we may set up a trigger to the image build when a new commit happens in the docker file repo. I think the art-tools repo updates more frequently than the art-dashboard-server repo and the script is more bonded with the server API so put it here. When the API is changed, it can be in the same PR and commit and the cluster only will rebuild once.

[ashwindasr]

From what I understand from the code, the new API endpoint serves the data from errata unmodified, so we do not need to redeploy art-dash-server as well. The purpose of the Dockerfile is only to run this script right? This can be achieved with Jenkins, by setting up a periodic job. That is also where similar jobs are running.

[ashwindasr]

So if I didn't miss anything, I don't see any need for a Dockerfile here, and we can achieve the result that you intended by separating out the check_schedule.py code to aos-cd-jobs

[Ximinhan]

true and false, the dockerfile only for run the script is true and we need to redeploy the server to provide service for the API. I would like to try the cron job in art cluster instead of using the jenkins scheduled job. the art-dash-server plays a role has permission to connect errata and response filtered output to the requester, which makes the "job" side very light and shaped with efficiency without extra init step.