Mailing-List: contact dev-help@openwhisk.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openwhisk.apache.org
MIME-Version: 1.0
In-Reply-To: <CADHijTQS+bXRnou0scLzvYR1hsPCm_zBGQNaKJVf_pfwuXBnBA@mail.gmail.com>
References: <CADHijTQS+bXRnou0scLzvYR1hsPCm_zBGQNaKJVf_pfwuXBnBA@mail.gmail.com>
From: Ben Browning <bbrownin@redhat.com>
Date: Wed, 14 Jun 2017 12:25:56 -0400
Message-ID: <CAOpbpxGSLbt9NMWJ2NL0_N0u=B+mGZWMYU8xg+yEr6A55QL3dA@mail.gmail.com>
Subject: Re: Kubernetes + packages with persistent services
To: dev@openwhisk.apache.org
Content-Type: multipart/alternative; boundary="001a1145c4f22336060551ee04ad"
archived-at: Wed, 14 Jun 2017 16:26:50 -0000

--001a1145c4f22336060551ee04ad
Content-Type: text/plain; charset="UTF-8"

For the first option, I'd suggest using a Kubernetes ConfigMap to store the
actual config needed by the persistent service. The user can edit the
ConfigMap as needed without having to worry about the other details. There
could of course still be a script like installCatalog.sh that creates that
ConfigMap based on provided values and deploys it along with the Deployment
for the user.

The larger question is really where should environment-specific deployment
logic live, especially when it comes to packages. Today there doesn't seem
to be any deployment instructions or Ansible files for the alarms package,
for example. Do we want separate repositories with all the Kubernetes yml
files for packages, similar to how the Kubernetes yml files for OpenWhisk
itself are separated out into a separate repo? Add OpenShift, Mesos, and
others to the mix and we need to have a plan for how we'll handle each
environment.

Ben


On Wed, Jun 14, 2017 at 12:00 PM, Toby Crawley <tcrawley@redhat.com> wrote:

> With the move towards supporting Kubernetes, has anyone given any
> thought to better handling packages that require a persistent service
> be deployed somewhere (alarms, rss, etc)?
>
> When running on Kubernetes, I think we have the opportunity to make
> using packages with persistent services a nicer experience. I have a
> couple of ideas on that, and want to get feedback before going
> further (and see if there are other approaches that would work):
>
> * Provide a deployment yaml file in the package repo that deploys the
>   persistent service, allowing the user to easily deploy via
>   kubectl. This may also require a script to create the deployment
>   config based on the environment needed by the service (database url,
>   credentials, etc).
>
> * Modify the setup actions to create deployments on demand when
>   needed, and destroying them when no longer needed (for example: only
>   having the cron service running when there are active cron
>   jobs). This option is much more invasive, and requires the setup
>   action to have Kubernetes credentials (and to know it is running
>   inside kube), but does reduce resource usage.
>
> Of those, I think the first option is probably what makes sense
> currently. If that makes sense to others, I'm happy to provide PR's to
> the package repos.
>
> - Toby
>

--001a1145c4f22336060551ee04ad--