-
Notifications
You must be signed in to change notification settings - Fork 84
Setup new staging and prod environments #57
Comments
Issue-Label Bot is automatically applying the label Links: app homepage, dashboard and code for this bot. |
* create_secrets.py creates secrets needed for dev instance * Created a kustomize package for deploying the app. * Need to add in the ingress resources Related to: machine-learning-apps#57 setup a dev instance
Created static IP resources in github-probots named
I created CNAME records corresponding to those addresses as well. |
https://label-bot-dev.mlbot.net/ is now up. |
For the dev instance the webhooks are failing with 405's method not allowed.
Maybe I have the wrong URL for the webhook; maybe there's a missing path? |
* machine-learning-apps#57 is tracking setting up new staging and prod environments * This PR sets up a new staging (or dev environment) * We create a kustomize manifest for deploying the front end into that namespace * The staging environment is configured to use the dev instance of the issue label bot backend microservice (i.e the pubsub workers) * I created some python scripts to make it easier to setup the secrets. * The motivation for doing this was to test the changes to the front end * Front end now forwards all issues for the kubeflow org to the backend * This is needed because we want to use multiple models for all Kubeflow repos kubeflow/code-intelligence#70 * The backend should also be configured with logging to measure the impact of the predictions. kubeflow/code-intelligence#104 is an a test issue showing that the bot is working. * Fix how keys are handled * For GOOGLE_APPLICATION_CREDENTIALS; depend on that environment variable being set and pointing to the file containing the private key; don't get the private key from an environment variable and then write it to a file. * For the GitHub App private key; use an environment variable to point to the file containing the PEM key. * Create a script to create the secrets. * Flask app is running in dev namespace * create_secrets.py creates secrets needed for dev instance
Everying this is deployed in prod. Looks like issues were labeled correctly when I manually sent a webhook Updating the app |
Delivery of webhooks is returning 502s but I don't see any errors in my weblogs. |
Success issue was labeled with the new bot see |
We need to tear down the old namespace |
Going to delete the old
|
namespace deleted. |
* As described in kubeflow#133 as people comment on an issue; label bot should take these additional comments into account when predicting labels. * Hopefully these additional comments will lead to better predictions as they will contain valuable information. To support this: * get_issue should get all comments (not just the body) * We also need to get any labels that have been explicitly removed as well as any labels already on the issue. We need this because we want to take into account multiple comments and not just the first one when predicting labels. * Since we are going to add additional labels based on additional comments we want to be sure not to add back labels which were explicitly removed. * issue_label_predictor should filter out labels which have already been applied or any labels which have been explicitly removed. This is necessary to ensure we don't spam the issue when we allow the bot to comment not just in response to the first comment but additional comments. * Likewise, we only want to apply the comment about not being able to label an issue once. So we need to check if the label bot has already commented on the issue. * Update the readme to account for the new staging and prod environments for the front end as described in machine-learning-apps/Issue-Label-Bot#57
* LabelBot should take into account all comments on an issue. * As described in #133 as people comment on an issue; label bot should take these additional comments into account when predicting labels. * Hopefully these additional comments will lead to better predictions as they will contain valuable information. To support this: * get_issue should get all comments (not just the body) * We also need to get any labels that have been explicitly removed as well as any labels already on the issue. We need this because we want to take into account multiple comments and not just the first one when predicting labels. * Since we are going to add additional labels based on additional comments we want to be sure not to add back labels which were explicitly removed. * issue_label_predictor should filter out labels which have already been applied or any labels which have been explicitly removed. This is necessary to ensure we don't spam the issue when we allow the bot to comment not just in response to the first comment but additional comments. * Likewise, we only want to apply the comment about not being able to label an issue once. So we need to check if the label bot has already commented on the issue. * Update the readme to account for the new staging and prod environments for the front end as described in machine-learning-apps/Issue-Label-Bot#57 * Fix log messages. * Update prod to use a newly built image.
Opening this issue to document the setup of new staging and prod environments.
We'd like to roll out some changes to the label bot frontend (see kubeflow/code-intelligence#90).
Trying to figure out how to roll things safely is revealing some areas for improvement in the way
our staging and prod clusters are setup.
We recently created a new GitHub App kf-label-bot-dev (see Create a GitHub App in Kubeflow Org for Label Bot Development kubeflow/code-intelligence#84) to correspond to the dev/staging instance of the label bot
We also cleaned up the deployment of the backend (See Ensemble repo specific and non-repo specific models kubeflow/code-intelligence#70) so we have separate namespaces for dev vs. prod
We'd like a similar setup for the label bot frontend with a dev instance using the dev label bot and the prod instance using the prod instance.
It looks like the prod instance is currently running in
It looks like there are two separate ingresses in this namespace
Here's my plan
label-bot-dev
with a dev instance of the label botlabel-bot-dev.mlbot.net
to use this serverlabel-bot-prod
with a prod instancelabel-bot-prod.mlbot.net
to use this serverlabel-bot-prod.mlbot.net
label-bot-prod
namespaceThe text was updated successfully, but these errors were encountered: