Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set Up Publishing-Bot #520

Closed
wants to merge 1 commit into from
Closed

Set Up Publishing-Bot #520

wants to merge 1 commit into from

Conversation

ameukam
Copy link
Member

@ameukam ameukam commented Dec 17, 2019

Part of #503.

Configs and deployments files are from Publishing-Bot repo.

/assign @dims @nikhita

@k8s-ci-robot k8s-ci-robot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Dec 17, 2019
@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. wg/k8s-infra labels Dec 17, 2019
publishing-bot/Makefile Outdated Show resolved Hide resolved
publishing-bot/configs/kubernetes-nightly Show resolved Hide resolved
publishing-bot/manifests/secret.yaml Outdated Show resolved Hide resolved
publishing-bot/configs/example Outdated Show resolved Hide resolved
@nikhita
Copy link
Member

nikhita commented Jan 20, 2020

@ameukam can you also add validate, build-image, etc in the Makefile as in https://github.com/kubernetes/publishing-bot/blob/master/Makefile? We'll need that to build the image before deploying...

publishing-bot/Makefile Outdated Show resolved Hide resolved
@ameukam ameukam changed the title WIP: Set Up Publishing-Bot Set Up Publishing-Bot Jan 21, 2020
@k8s-ci-robot k8s-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jan 21, 2020
@bartsmykla
Copy link
Contributor

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jan 22, 2020
publishing-bot/Makefile Outdated Show resolved Hide resolved
@k8s-ci-robot k8s-ci-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jan 24, 2020
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign bartsmykla
You can assign the PR to them by writing /assign @bartsmykla in a comment when ready.

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

Needs approval from an approver in each of these files:

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

@bartsmykla
Copy link
Contributor

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 4, 2020
and releases >= v1.14, we run two instances of the bot today.

The instance of the bot responsible for syncing releases <= v1.14 runs in the
`k8s-publishing-bot-godeps` namespace and the instance of the bot responsible
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This NS does not exist yet - should this PR add it to infra/gcp/namespaces/ensure-namespaces.sh ?

apiVersion: v1
kind: ConfigMap
metadata:
name: publisher-config
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to have 2 subdirs, "kubernetes" and "kubernetes-nightly" to isolate the files better? would make diffing them easier, too

port: 80
resources:
requests:
cpu: 300m
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is CPU hardcoded but memory is parameterized?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also, .3 cores is a LOT of CPU

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have client-go smoke tests in there, which require a certain amount of CPU in order to be stable.

cpu: 300m
memory: MEMORY_REQUESTS
limits:
cpu: 2
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't set CPU limits. There's no point to it.

@@ -0,0 +1,15 @@
apiVersion: apps/v1
kind: Replicaset
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this not using Deployment?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nikhita asked to keep it as Replicaset in a previous conversation: #520 (comment)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see why this is needed, though. Is it JUSt to avoid changing 2 things at once?

@@ -0,0 +1,7 @@
kind: StorageClass
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should go ... somewhere else. Probably in clusters/kubernetes-public/aaa - see https://www.terraform.io/docs/providers/kubernetes/r/storage_class.html

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be a PR of its own


SHELL := /bin/bash

build:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't seem to apply at all in this directory? The code is not here

.PHONY: validate

init-deploy: validate
$(KUBECTL) delete -n "$(NAMESPACE)" --ignore-not-found=true replicaset publisher
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels a little baroque - why are we trying to delete things?

{ cat manifests/pod.yaml && sed 's/^/ /' manifests/podspec.yaml; } | \
$(call prepare_spec) | $(KUBECTL) apply -n "$(NAMESPACE)" -f -

deploy: init-deploy
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Document assumptions - like the current context

$(KUBECTL) apply -n "$(NAMESPACE)" -f manifests/service.yaml
{ cat manifests/rs.yaml && sed 's/^/ /' manifests/podspec.yaml; } | \
$(call prepare_spec) | sed 's/-interval=0/-interval=$(INTERVAL)/g' | \
$(KUBECTL) apply -n "$(NAMESPACE)" -f -
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why are we duplicating deployment code from the publishing bot? 😱 This repo is invisible to anybody doing changes in the bot repository, which will eventually break this copy.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the migration of the publishing bot to a new community-owned GKE cluster (aaa), we want to migrate some parts of the deployment code. What's the right approach in this scenario ?

Copy link
Contributor

@sttts sttts Feb 14, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code in the bot repo is used by a number of parties. So we won't remove it. Hence, you are creating a copy here which will most certainly divert.

Where is the problem of keeping the deployment code where it is? The people deploying the publishing bot (which is @nikhita, @dims and myself only; nobody without deep knowledge of what the bot does should do this) all are used to the bot repo. Which pain points should this duplication solve?

I would also be fine to do some git clone magic here checking out the bot repo and call the Makefile in there. Then it's well documented what is going on.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am fine to leave the config in the bot repo, I guess. This repo/dir could be reduced to a README explaining how we deploy it in "aaa"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But all my comments here apply - especially around CPu and memory limits.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ameukam can you move the fixes to the publishing-bot repo instead? @nikhita and I are happy to review over there. Thanks!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sttts @thockin @ameukam @nikhita I have added to todays agenda for k8s-infra-wg bi-weekly meeting discussion about this topic. Please attend if you want to discuss about it in syncronous manner. http://bit.ly/wg-k8s-infra-notes

@bartsmykla
Copy link
Contributor

@ameukam what do you think about @sttts suggestion about moving the fixes to publishing-bot repo? Can I help you with anything to move this thing forward? :-)

@ameukam
Copy link
Member Author

ameukam commented Feb 24, 2020

@bartsmykla I'm going to work on it this week.

@bartsmykla
Copy link
Contributor

@ameukam perfect! If you'll need any help just ping me on slack :-)

@bartsmykla
Copy link
Contributor

@ameukam is there anything I can help you with to move this forward? :-)

@sttts
Copy link
Contributor

sttts commented Apr 1, 2020

/hold

Just to be sure it is not merged accidently until the comments are addresses that we don't want to duplicate build code for the bot.

@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Apr 1, 2020
@bartsmykla
Copy link
Contributor

@ameukam can you give us some updates about the state of the issue? I can help with moving some of the resources like StorageClass to different places like @thockin suggested. If you don't have time I can also do more work to move the things forward. :-)

@ameukam
Copy link
Member Author

ameukam commented Apr 10, 2020

@bartsmykla kubernetes/publishing-bot#221 got merged. I think this PR is not useful anymore. I will close this PR when publishing-bot will be migrated.

@nikhita
Copy link
Member

nikhita commented Apr 23, 2020

@ameukam Even though we ended up taking a different approach, thank you SO MUCH for taking the time to work on this and driving the migration! ❤️

Going to close this since migration is now complete (#503).
/close

@k8s-ci-robot
Copy link
Contributor

@nikhita: Closed this PR.

In response to this:

@ameukam Even though we ended up taking a different approach, thank you SO MUCH for taking the time to work on this and driving the migration! ❤️

Going to close this since migration is now complete (#503).
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@bartsmykla
Copy link
Contributor

Huge thanks for @ameukam from me too!

@bartsmykla
Copy link
Contributor

And to you @nikhita too! :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. lgtm "Looks good to me", indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants