openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tyson Norris <>
Subject Re: Kubernetes + packages with persistent services
Date Wed, 14 Jun 2017 18:49:28 GMT
I don't see any harm in adding deployment utilities for dependent services
to package repos, as long as deploying the package does not rely on them.
If this becomes overwhelming, they can be reorganized to other individual
repos per env+package, OR into the openwhisk-devtools repo. I think it can
be helpful to make packages more useable to new devs.

I also don't see any harm in keeping them in separate repos, except for the
hassle of dealing with more repos, which is not a great argument, but takes
away some ease of use for new devs.

If adding env-specific scripts, it may be helpful to add other envs as
placeholders (include a kube dir, a mesos dir, etc) indicating explicitly
that they are missing and need contributions, if anyone wants to use them.


On Wed, Jun 14, 2017 at 9:26 AM Ben Browning <> wrote:

> 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 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 <>
> 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
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message