search

kubernetes-retired / spartakus

[EOL] Anonymous Usage Collector
Apache License 2.0
74 stars 30 forks source link

self-updating deployments #11

Closed philips closed 5 years ago

philips commented 7 years ago

It would be great if spartakus would be able to update its own deployment and ideally we could roll out the update in a controlled manner with a feedback loop. Also, it would be cool if people could subscribe to alpha/beta/stable reporting channels.

We are building something that plugs into an Omaha server for the etcd and Prometheus Operator. Would that be OK for spartakus?

philips commented 7 years ago

The Omaha thingie could probably just be a sidecar that takes a deployment and can only update the tag of the spec.container.image.

thockin commented 7 years ago

Self-updating makes me nervous. It is somewhat antithetical to hermetic containers.

On Thu, Nov 17, 2016 at 10:17 PM, Brandon Philips notifications@github.com wrote:

The Omaha thingie could probably just be a sidecar that takes a deployment and can only update the tag of the spec.container.image.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kubernetes-incubator/spartakus/issues/11#issuecomment-261457701, or mute the thread https://github.com/notifications/unsubscribe-auth/AFVgVGYb0fajJHvbfzjtnz7wqIupuBvbks5q_UL_gaJpZM4K2J8Y .

errordeveloper commented 7 years ago

@philips wouldn't it be better to use the API? For example, we could consider a cron job type of sidecar that is able to update image in a deployment spec. However, having said this, would Spartakus benefit from such functionality in significant way really?

philips commented 7 years ago

@errordeveloper sure, the cron job needs to talk to Omaha or something that tells it what version to run though. Cron jobs aren't ideal because you want exponential backoffs.

fejta-bot commented 5 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

fejta-bot commented 5 years ago

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten

fejta-bot commented 5 years ago

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close

k8s-ci-robot commented 5 years ago

@fejta-bot: Closing this issue.

In response to [this](https://github.com/kubernetes-incubator/spartakus/issues/11#issuecomment-503831513): >Rotten issues close after 30d of inactivity. >Reopen the issue with `/reopen`. >Mark the issue as fresh with `/remove-lifecycle rotten`. > >Send feedback to sig-testing, kubernetes/test-infra and/or [fejta](https://github.com/fejta). >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.