[REMINDER] Policies around Publicity & Press

[John D. Ament]

All Podlings,

In recent days I've been contacted about several publicity issues that have
gone a bit off kilter.  I wanted to remind podlings two very import
policies.

1. Podlings MUST coordinate with the Public Relations Committee with all
publicity activities.
2. The Press Team MUST review any press releases or similar communication
referencing a podling before it is published.

Relevant Links:

https://incubator.apache.org/guides/branding.html#publicity_activities
https://incubator.apache.org/guides/branding.html#publicity_throughout_the_incubation_process

Please reach out with any concerns.

Regards,

John D. Ament
VP, Apache Incubator

consul removed

[Rodric Rabbah]

A heads up since this was anticipated by a few downstream dependencies that
the PR which removes consul was merged to master as
https://github.com/apache/incubator-openwhisk/commit/e466e48a8cb7bf44b358e38728f58360b8377f7e
.

Thanks to Markus, Dragos, Dan and others who helped along the way.

-r

Re: http enablement in nginx for local development

[Rodric Rabbah]

I would not go as far as removing nginx - I do know some things that will
not work in that case (the edge host will need to change, the environment
configurations for the port which define the __OW_API_HOST, and some of the
cli commands will break related to sdk submenu).

Perhaps a compromise is to allow nginx to forward port http to https
automatically or to enable port 80 through a forced flag, and just leaving
it untested.

-r

Re: http enablement in nginx for local development

[Dragos Dascalita Haut]

Hi Rodric,


"...without running the full test suite against both HTTP and
HTTPS deployments, I for one can't say what will and will not work"

I assume you're referring to the test suite for the CLI, right ?


So the argument is that we can simplify the CLI tests by removing NGINX from 
the local env, assuming that w/o NGINX we can invoke the endpoints in the 
controller via HTTP b/c NGINX should only listen on port 443 ?




Thanks,
dragos

From: Rodric Rabbah 
Sent: Sunday, July 23, 2017 7:28:17 AM
To: dev@openwhisk.apache.org
Subject: http enablement in nginx for local development

If you've deployed openwhisk locally you'll have noticed that the nginx is
listening on port 443 only (https); for local development, we document a
workaround to the self-signed SSL certificate by bypassing nginx. This is
helpful for switching deployments from local to production where the latter
will have a valid certificate but the former requires some additional flags
for wsk CLI or curl to ignore the certificate.

A while ago PR 2042 was offered to open port 80 [1] and enables HTTP  as a
convenience for local dev since it avoids having to ignore the self-signed
cert. On the other hand, this path is not tested explicitly and could rot
but more so, without running the full test suite against both HTTP and
HTTPS deployments, I for one can't say what will and will not work.

At one point, we explored storing the insecure flag in the wsk CLI
properties file but ended up abandoning (see PR 1838 [2]) and instead
documenting a convenient but limited workaround instead (bypassing nginx).

[1] 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fincubator-openwhisk%2Fpull%2F2042=02%7C01%7C%7C1e26f14d4bb84aee3c8108d4d1d72f8e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636364169522575347=3MZ%2FyfPbAZJ%2FqnRz8pLyVQ0MF9NahgGrZk71UNNIAMI%3D=0
[2] 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fincubator-openwhisk%2Fpull%2F1838=02%7C01%7C%7C1e26f14d4bb84aee3c8108d4d1d72f8e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636364169522575347=VJniIpCYlvsB1743CCGMehJ6XHDZlhAmpEVDH2Ug%2F5c%3D=0

I'm inclined to continue to only support HTTPS and in fact push this
protocol even further inside the deployment.

Thoughts?  I will summarize the dev list discussion on the PR as
appropriate and then we can decide that to do with the offered patch.

-r

Re: Updating Package and Language versions for a kind

[Rob Allen]

Yeah, this is my thinking too.

Regards,

Rob...

> On 27 Jul 2017, at 16:20, Carlos Santana  wrote:
> 
> Being thinking more about this, and having a core set of packages included
> by default is very useful and I think critical for open source integration
> and continues integration in the open.
> Also keeping large actions away from the system for folks that just want to
> get started and kick the tires using the embedded packages
> 
> I think we could have a mid way alternative:
> 
> What about if we create new kinds every time we want to pickup an update
> for new language update but at the minor (y) level (version x.y.z).
> Also include a very small set of core packages, for example request for
> nodejs very stable and popular package
> 
> We create a new kind to pick up a new minor update and at that time will
> pickup the latest version of the packages.
> For patch updates, at least for security updates this are done at the patch
> level, will update the current kind to update the patch level of the
> language.
> 
> So I think this aligns with what Rob mentioned about trying to keep kinds
> versions at the minor level.
> 
> Taking nodejs as an example:
> we have nodejs:6 (this is set to 6.9)
> let's create a new kind for node nodejs:6.11
> This will include latest version of 6.11 and latest versions of packages at
> the time of creating of the new kind nodejs:6.11
> If there are nodejs patch updates to pickup for 6.11 we update without
> creating a new kind will be kept at nodejs:6.11 with the packages pinned to
> the versions that they shipped.
> I think nodejs moves a bit faster than the other languages so we could
> pickup  a new minor nodejs:6.12 or 6.14 when ever the community thinks
> there is a minor update from nodejs worth the update to create a new kind.
> 
> There might be a gap, I think it's OK for those corner cases that an user
> wants to use the latest nodejs version but use old version of the packages,
> or use the latest version of the package but an old version of nodejs. I
> think for this cases user would need to pinned and include the exact
> version of the modules to include and that's OK, I think this will be a
> normal thing for people going into production and pinning and controlling
> dependencies.
> 
> I think it's hard to come up with silver bullet for all languages, as every
> language updates at a different speed, and dependencies are more slowest
> pace than others.
> 
> 
> 
> 
> 
> 
> 
>> On Wed, Jul 26, 2017 at 8:30 PM Carlos Santana  wrote:
>> 
>> One thought I have being debating is that the open source project doesn't
>> include any packages going forward.
>> The project will have an image that is small and common denominator that
>> the operators deploying decide which packages to add on top.
>> 
>> For example for nodejs 8, we create the kind nodejs:8 (at LTS Oct/2017),
>> 
>> Will keep the version of language nodejs 8 up to date to the latest as
>> official releases come out from nodejs
>> Operators like IBM and Adobe, RH, others, can base their custom images for
>> their offerings on the same base image, adding packages that they want base
>> on their offering.
>> 
>> Same for swift new kind swift:4, and so on.
>> 
>> This will be a general policy, as every language has their peculiarity and
>> probably we need our runtimes SMEs to talk about the risk on updating or
>> not updating per language.
>> 
>> dealing with user level packages is always a pickle for example today we
>> have nodejs:6 and we have a set of users that benefit from updating the
>> packages to the latest latest, and could have users that they depend on a
>> current version of the package and updating the package on them could cause
>> problems. If I had my way I would say thought luck for using the embedded
>> package and not packaging or doing a bundle build, but serverless is on
>> baby years of adoption and I don't want to be thought yet :-)
>> 
>> So for nodejs8 we say thought luck no embedded packages, but will do
>> something to make it super easy will have the system help you build/compile
>> your action and include your dependencies, these system actions that allow
>> users to provide only their code/git-url, and package.json/package.swift,
>> and these actions will compile/npm install etc..  and install your action
>> including the declared dependencies.
>> 
>> 
>> 
>> 
>> 
>> On Tue, Jul 18, 2017 at 4:08 AM Michael Marth 
>> wrote:
>> 
>>> Hi Rob,
>>> 
>>> Re “I wonder how many deployments roll their own action containers?”
>>> 
>>> I spoke too general (implying what most OW deployments would want). What
>>> I can say is that our team wishes to be in control of the libraries that go
>>> into the action containers, that’s why we need to roll our own.
>>> 
>>> Agree with the approach you have outlined on patch and minor releases.
>>> 
>>> The topic of deprecation IMHO is the same discussion as when to upgrade
>>>