For me, this use case raises the question of zero-downtime upgrades for Pulp. Technologically speaking Pulp is well setup to do this, and I'm hearing that at least pulp-operator users would actually use it. To support that, Pulp would need to adopt zero-downtime upgrades as an approach. We haven't done that currently, but it would be cool to discuss supporting that.
+1 to the auto-scaling demo. The zero-downtime upgrade also sounds really interesting. On Mon, May 13, 2019 at 6:04 PM Tom McKay <thomasmc...@redhat.com> wrote: > One of the benefits of an operator is updating versions of the containers. > Selfishly, I'd enjoy seeing a deploy of pulp w/ container plugin > auto-updating to a newer version (of your-choice-of-pod) with no down time. > > On Mon, May 13, 2019 at 5:33 PM Mike DePaulo <mikedep...@redhat.com> > wrote: > >> Hi Tom, >> >> I'll add that to my to-do list (which I will soon compile down into >> Redmine tasks): >> http://pulp.etherpad.corp.redhat.com/463 >> >> I'm also wondering how soon to do that in the development of the >> Operator? Right now there are only a few advantages over installing Pulp on >> a single system. For example, multiple pulp-content instances is 1 large >> advantage I intend to implement soon, but autoscaling of pulp-content and >> pulp-worker (later in development) would make for a much better demo. >> >> -Mike >> >> On Mon, May 13, 2019 at 5:03 PM Tom McKay <thomasmc...@redhat.com> wrote: >> >>> This is great! Glad to see the investment continuing. Is there a >>> recorded demo of the operator in action on OCP/OKD? >>> >>> On Thu, May 9, 2019 at 6:12 PM Mike DePaulo <mikedep...@redhat.com> >>> wrote: >>> >>>> Hi everyone, >>>> >>>> Eric Helms & I have been working on creating Pulp 3 Kubernetes / >>>> container packaging, including a Kubernetes Operator. >>>> >>>> This includes each Pulp process (like pulp-content & pulp-worker) >>>> running in their own container, and the end goal is for a single Pulp 3 >>>> cluster to be scalable (such as for those 2 processes in particular.) >>>> >>>> Background: >>>> About 7 months ago, Eric Helms started working on creating Pulp 3 >>>> containers, including a Kubernetes operator. He appropriately named it >>>> "carafe": >>>> https://github.com/ehelms/carafe >>>> But later put much of it in the repo named "pulp-operator" (and >>>> continued development there,) and submitted a PR for the 4 pulp containers >>>> to be in pulpcore itself. >>>> >>>> Latest developments: >>>> I have been working on updating & finishing this effort. Improvements >>>> include: >>>> - Compatibility with pulpcore 3.0 rc2 >>>> - Persistent Volume storage for MEDIA_ROOT (/var/lib/pulp) >>>> >>>> Much more work remains, although it is usable enough for a >>>> demonstration of Pulp running on Kubernetes in the 1st place (with the >>>> pulpcore & pulp-operator PRs.) >>>> >>>> In the meantime, don't be surprised by the following changes: >>>> 1. PRs against pulpcore like this one: >>>> https://github.com/pulp/pulpcore/pull/127 >>>> 2. The pulp-operator repo: >>>> https://github.com/pulp/pulp-operator >>>> 3. Us putting our CentOS 7 based redis Dockerfile somewhere other than >>>> my personal github: >>>> https://github.com/mikedep333/carafe/tree/summit-demo >>>> >>>> Also, note that any DockerHub or Quay.io projects like "carafe" or >>>> "mikedep333" are temporary. >>>> >>>> -Mike >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> Pulp-dev@redhat.com >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>> >>> >>> -- >>> >>> Thomas McKay >>> Principal Software Engineer - Quay >>> @thomasmckay >>> >>> > > -- > > Thomas McKay > Principal Software Engineer - Quay > @thomasmckay > > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
