You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Sam Ruby <ru...@intertwingly.net> on 2016/10/13 20:27:33 UTC

[discuss] Apache OpenWhisk Incubator Proposal

Hello everyone,

Attached to this message is a proposed new project - Apache OpenWhisk.

The text of the proposal is included below. Additionally, the proposal 
is in draft form on the Wiki, where we will make any required changes:

https://wiki.apache.org/incubator/OpenWhiskProposal

We look forward to your feedback and input.

  - Sam Ruby


  OpenWhisk Proposal

/OpenWhisk is an open source, distributed //Serverless/ 
<https://developer.ibm.com/openwhisk/what-is-serverless-computing/>/computing 
platform able to execute application logic (Actions) in response to 
events (Triggers) from external sources (Feeds) or HTTP requests 
governed by conditional logic (Rules). It provides a programming 
environment supported by a REST API-based Command Line Interface (CLI) 
along with tooling to support packaging and catalog services. /

*Champion**: *Sam Ruby, IBM
*Mentors**:* Felix Meschberger, Adobe; Isabel Drost-Fromm, Elasticsearch 
GmbH


  *Proposal*


      *Background*

Serverless computing is the evolutionary next stage in Cloud computing 
carrying further the abstraction offered to software developers using 
Container-based operating system virtualization. The Serverless paradigm 
enables programmers to just \u201cwrite\u201d functional code and not worry about 
having to configure any aspect of a server needed for execution. Such 
Serverless functions are single purpose and stateless that respond to 
event-driven data sources and can be scaled on-demand.

The OpenWhisk project offers a truly open, highly scalable, performant 
distributed Serverless platform leveraging other open technologies along 
with a robust programming model, catalog of service and event provider 
integrations and developer tooling.

Specifically, every architectural component service of the OpenWhisk 
platform (e.g., Controller, Invokers, Messaging, Router, Catalog, API 
Gateway, etc.) all is designed to be run and scaled as a Docker 
container. In addition, OpenWhisk uniquely leverages aspects of Docker 
engine to manage, load balance and scale supported OpenWhisk runtime 
environments (e.g., JavaScript, Python, Swift, Java, etc.), that run 
Serverless functional code within Invoker compute instances, using 
Docker containers.

OpenWhisk's containerized design tenants not only allows it to be hosted 
in various IaaS, PaaS Clouds platforms that support Docker containers, 
but also achieves the high expectation of the Serverless computing 
experience by masking all aspects of traditional resource specification 
and configuration from the end user simplifying and accelerating Cloud 
application development.

In order to enable HTTP requests as a source of events, and thus the 
creation of Serverless microservices that expose REST APIs, OpenWhisk 
includes an API Gateway that performs tasks like request routing, 
throttling and logging.


      *Rationale*

Serverless computing is in the very early stages of the technology 
adoption curve and has great promise in enabling new paradigms in 
event-driven application development, but current implementation efforts 
are fractured as most are tied to specific Cloud platforms and services. 
Having an open implementation of a Serverless platform, such as 
OpenWhisk, available and governed by an open community like Apache could 
accelerate growth of this technology, as well as encourage dialog and 
interoperability.

Having the ASF accept and incubate OpenWhisk would provide a clear 
signal to developers interested in Serverless and its future that they 
are welcome to participate and contribute in its development, growth and 
governance.

In addition, there are numerous projects already at the ASF that would 
provide a natural fit to the API-centric, event-driven programming model 
that OpenWhisk sees as integral to a Serverless future. In fact, any 
project that includes a service that can produce or consume actionable 
events could become an integration point with OpenWhisk-enabled 
functions. Apache projects that manage programming languages and (micro) 
service runtimes could become part of the OpenWhisk set of supported 
runtime environments for functions. Device and API gateways would 
provide natural event sources that could utilize OpenWhisk functions to 
process, store and analyze vast amounts of information immediately 
unlocking the potential of fast-growing computing fields offered in 
spaces as IoT, analytics, cognitive, mobile and more.


    *Initial **Goals*

OpenWhisk is an open source community project which seeks to adopt the 
Apache way through the course of the incubator process and foster 
collaborative development in the Serverless space.

Currently, the OpenWhisk project's source repository is in GitHub using 
its associated project tooling, but we believe the open Apache 
processes, democratic project governance, along with its rich developer 
community and natural integrations with existing projects provide the 
ideal fit for the technology to grow.

Serverless will only reach its full potential and avoid fragmentation if 
it is grown in an environment that Apache can offer.


    *Current **Status*

The OpenWhisk project was published as an open source project within 
GitHub (_https://github.com/openwhisk_) under the Apache v2.0 license in 
February 2016. The project consists of the \u201ccore\u201d platform repository 
(https://github.com/openwhisk/openwhisk) code along with its family of 
repositories that include a \u201ccatalog\u201d of OpenWhisk system and utility 
packages.

The project also includes repositories for:

  * JavaScript and Swift SDKs for client integration
  * Docker SDK for user-created \u201cblackbox\u201d (Action) runtimes
  * Graphical Command Line Tutorial (using NodeJS)
  * Packages for popular service integrations (i.e., JIRA, Twilio,
    Slack, Kafka, RSS, etc.)

Issue tracking and project governance (milestones, epics) are also 
managed through *GitHub* *Issues* and visualized through *ZenHub*. All 
\u201cpull\u201d requests, once passing automated tests run by *TravisCI*, are 
reviewed by \u201ccore\u201d contributors with \u201cwrite\u201d privileges. IBM has also 
setup private staging servers to \u201cstress\u201d test the platform performance 
under load and over extended periods of time before being merged into 
the main code branch. As part of the incubation process we would make 
these staging tests public and have them be run by Apache.

Currently, the project is not officially versioned and is considered an 
\u201cexperimental beta\u201d, but is marching towards milestone 10 that aligns 
with what is considered to be a \u201cbeta\u201d the end of October and another 
milestone 11 end of November 2016 which is considered \u201cGA\u201d content for 
the \u201ccore\u201d platform. Again, we would very much like to adopt an Apache 
community system for deciding on milestones, constituent epics 
(features) along with dates a versioning plan and communicate 
effectively using email lists, IRC and a project homepage (which is 
currently lacking).

In addition to the OpenWhisk core runtime, the API Gateway components of 
the projects are published in a separate GitHub project 
(https://github.com/adobe-apiplatform/apigateway) under the MIT license. 
The API Gateway components were initially released in August 2015. These 
components include functionality for:

  * Request validation
  * Request tracking
  * Caching
  * Logging
  * Load Balancing


      *Meritocracy*

The OpenWhisk project firmly believes in meritocracy from its inception. 
Issue, Feature and code submissions, to fix, improve or optimize the 
platform code, tooling and documentation, as well as contributions of 
new SDKs, Packages, Tutorials, etc. have all been welcomed after 
successful community input, consultation and testing. Contributions can 
be made by anyone as long as integration and staging (including stress 
and performance) tests pass. We are looking forward to talented 
individuals to progress the success of OpenWhisk and an open Serverless 
ecosystem surrounding it. It would be a pleasure to invite strong 
contributors to become committers in the project areas where they have 
shown a consistent track record.


      *Community*

OpenWhisk has made significant effort to build a community using all 
possible media and social outlets as possible, always asking for 
interested developers to join and contribute.

The following outlets have been created to engage the public in as many 
ways as we could conceive. Every single of these sources is monitored 
continually via OpenWhisk code that triggers events and messages to 
appropriate developer Slack channels where we seek to respond and engage 
as quickly as we can.

  * /Twitter/: https://twitter.com/openwhisk
  * /Slack/: https://dwopen.slack.com/messages/openwhisk/
  * /StackOverflow/: http://stackoverflow.com/search?q=OpenWhisk
  * /dwAnswers/ (developerWorks):
    https://developer.ibm.com/answers/smartspace/open/
  * /Blog site/: https://developer.ibm.com/openwhisk/blogs/
  * /Google//group/: https://groups.google.com/forum/ - !forum/openwhisk
    <https://groups.google.com/forum/#%21forum/openwhisk>

IBM has sought to promote OpenWhisk at every logical event worldwide 
where we are able.

  * */Events and Meetups/*:
      o 20+ past events, 6 planned through YE 2016 /(across 12 countries)/
      o Event calendar: https://developer.ibm.com/openwhisk/events/
  * */Stats/* (GitHub):
      o 43+**contributors: https://github.com/orgs/openwhisk/people
      o /Contribution Graphs/:
        https://github.com/openwhisk/openwhisk/graphs/contributors
  * */Stars/*:
      o 623 <https://github.com/openwhisk/openwhisk/stargazers> /(and
        growing ~10-20 per week on average):
        //https://github.com/openwhisk/openwhisk/stargazers/


      *Core **Developers*

The following core developers, along with their credentials, are 
proposed; each have been committers within OpenWhisk since its initial 
development:

  * Stephen Fink, sjfink@us.ibm.com <ma...@us.ibm.com>, original
    project architect
  * Rodric Rabbah, rabbah@us.ibm.com <ma...@us.ibm.com>,
    project's developer who has deepest knowledge who has been with the
    project since its inception.
  * Markus Thommes, markus.thoemmes@de.ibm.com
    <ma...@de.ibm.com>, project build and deployment
    expert for all roles and environments (Mac, Linux, etc. either
    local/distributed).
  * Jeremias Werner, JEREWERN@de.ibm.com <ma...@de.ibm.com>,
    tooling and integration expert.  Understands all the build and
    runtime dependencies / external projects OpenWhisk relies upon.
  * Perry Cheng, perry@us.ibm.com <ma...@us.ibm.com>, Performance
    and stress testing guru.


      *Alignment*

We have looked, from the earliest days of developing OpenWhisk, at 
Apache as a model for building a strong developer community and worked 
to adopt its spirit and its best practices.  From the outset, we have 
wished to have enough interest and momentum in order to have a robust 
pool of developers in order to adopt an Apache governance model for 
meritorious acknowledgement of committer and core contributors who can 
bring external knowledge to further grow the project.

We see immediate chances to leverage Apache projects such as Kafka, 
Camel, MQTT, ApacheMQ, etc. Wherever there is a collector, funnel or 
router of message data that can directly or indirectly generate events, 
we intend to link to OpenWhisk as an even provider. These and other 
projects are listed below and are just, we hope, \u201cscratching the 
surface\u201d of integration points for Serverless enabled applications.

In addition, we should note that we see immediate interest in leveraging 
the Apache relationship with the Linux foundation to integrate with the 
OpenAPI specification (f.k.a., Swagger) and seek to standardize API 
gateways that follow that spec. to formalize endpoints for services that 
can produce events.


      *Known **Risks*


      /*Orphaned **products*/

OpenWhisk and its initial group of committers along with the community 
currently supporting the project will continue to promote and look for 
ways to engage new developers and provide linkage to other compatible 
open source projects. Serverless computing has a significant future in 
Cloud computing and an open source implementation of a platform, as 
OpenWhisk embodies, must success to provide competition and 
interoperability and provide a rich foundation for new Serverless 
technologies to rely upon.


      /*Inexperience with Open **Source*/

OpenWhisk, as you can deduce from its name, has been an open source 
project from its public debut in February 2016.  As soon as a the 
initial code, developed within IBM research, was viable and provided the 
functionality expected of a Serverless platform, the project team open 
sourced it and sought to build an open community to evolve it. Most all 
current all current project team members have strong experience 
developing within open source projects with meritorious governance 
models. In fact, several of the current team members are committers on 
other Apache projects and are excited to reach out to and align with 
other project communities within Apache.


      *Homogenous **Developers*

The current list of committers includes developers from two  different 
companies. The current set of committers are geographically distributed 
across the U.S., Europe and China. All committers are experienced with 
working in a distributed environment and utilize many messaging and 
collaboration  tools to continually communicate with each effectively to 
develop and review code regardless of location.

Additionally, the current project members are very focused on addressing 
comments, feedback and issue or  feature requests as soon as we are 
able.  In fact, we utilize OpenWhisk itself to intelligently notify 
project developers with the correct knowledge or expertise of any public 
posting to any community outlets (listed above).


      *Reliance on Salaried **Developers*

All of the initial developers are currently salaried by either IBM or 
Adobe. With increasing awareness and interest in Serverless 
technologies, we expect this to change due to the addition of volunteer 
contributors.  We intend to promote and encourage participation whenever 
interest is shown in the project to build a robust community.


      *Relationships with Other Apache **Products*

Some possible project intersections or potential connections are listed 
below.  We hope to identify many others through the course of incubation.

  * *Kafka*, http://kafka.apache.org/project, OpenWhisk has plans to use
    Kafka for an intelligent \u201cmessage hub\u201d service that can channel
    events to OpenWhisk triggers.
  * *Camel*, http://camel.apache.org/message-bus.html, Any message bus
    naturally carries message data that may carry events direcly or be
    used indirectly to derive events that devlopers can link to
    OpenWhisk actions.
  * *ActiveMQ*, http://activemq.apache.org/, Again, a widely used
    message server, that supports MQTT and AMQP, which can provide
    trusted event data to OpenWhisk.

Some additional projects we would like to explore any connection with 
include:

  * *CouchDB*, _https://projects.apache.org/project.html?couchdb_:
    OpenWhisk already supports use of CouchDB for its own storage needs
    (Actions, Bindings, etc.); however, there may be more integrations
    possible  as we develop a package manifest  to describe OpenWhisk
    entities reposited in document stores as pseudo-catalogs.
  * *Mesos*, _https://projects.apache.org/project.html?mesos_: in
    effect, OpenWhisk also manages a \u201cpool of nodes\u201d that can run
    various Actions (functions). It would be interesting to see if any
    overlap or sharing of node resources could be achieved.
  * *Spark*, _https://projects.apache.org/project.html?spark_ : As with
    Mesos, OpenWhisk nodes could be leveraged to perform distributed
    data-processing with Spark.

and many others that we hope the community will help identify and 
prioritize for development work.


      *AN Excessive Fascination with the Apache **Brand*

The developers of OpenWhisk share a high appreciation of the Apache 
Software Foundation, and many have been active as users, contributors or 
committers to other Apache projects.

The main expectation for the developers is not the Apache brand, but the 
project governance and best practices established by the ASF, access to 
the Apache community and support and mentorship through senior Apache 
members.


      *Documentation*

OpenWhisk offers a comprehensive set of documentation (primarily in 
Markdown) for all parts of the project from installation and deployment 
(locally, remotely, distributed) on various platforms in order to get 
developers \u201cup and running\u201d as quickly as possible on multiple platforms 
(Mac, Windows, Ubuntu). In addition, OpenWhisk goes to great links to 
document its architecture and programming model and provide guided 
tutorials for the CLI. All SDKs and Packages that can be installed, 
besides installation and use cases descriptions, often include videos 
and blogs. OpenWhisk is dedicated to providing the best documentation 
possible and even has volunteers\u2019 submissions for translations in some 
areas.


      *Initial **Source*

The project is comprised of multiple repositories all under the primary 
openwhisk name. All initial source that would be moved under Apache 
control can be found in GitHub (by repository) here:

  * */Primary Repositories:/*
      o https://github.com/openwhisk/openwhisk
          + primary source code repository including run books, tests.
      o https://github.com/openwhisk/openwhisk-catalog
          + Catalog of built-in system, utility, test and sample
            Actions, Feeds and provider integration services and catalog
            packaging tooling.
  * */Client (SDK) repos.: /*
      o https://github.com/openwhisk/openwhisk-client-js
          + JavaScript (JS) client library for the OpenWhisk platform.
      o https://github.com/openwhisk/openwhisk-client-swift
          + /Swift-based client SDK for OpenWhisk///compatible with
            Swift 2.x and runs on iOS 9, WatchOS 2, and Darwin.
      o https://github.com/openwhisk/openwhisk-podspecs
          + CocoaPods Podspecs repo for \u2018/openwhisk-client-swift/\u2019.
      o https://github.com/openwhisk/openwhisk-sdk-docker
          + This is an SDK that shows how to create \u201cBlack box\u201d Docker
            containers that can run Action (code).
  * */Package repos.: /*
      o https://github.com/openwhisk/openwhisk-package-pushnotifications
          + / In-progress/, Push notifications to registered devices.
      o https://github.com/openwhisk/openwhisk-package-twilio
          + /In-progress/, Integration with Twilio.
      o https://github.com/openwhisk/openwhisk-package-jira
          + /In-progress,/ Integration with JIRA events.
      o https://github.com/openwhisk/openwhisk-package-rss
          + Integration with RSS feeds.
      o https://github.com/openwhisk/openwhisk-package-kafka
          + /New, In-progress/, Integration with Kafka
      o https://github.com/openwhisk/openwhisk-slackbot-poc
          + /In-progress/, deploy a Slackbot with the capability to run
            OpenWhisk <https://github.com/openwhisk/openwhisk> actions
  * */Ecosystem repos.: /*
      o https://github.com/openwhisk/openwhisk-tutorial
          + Place to submit interactive tutorials for OpenWhisk, its CLI
            and packages. Currently, contains Javascript-based tutorial
            for learning the OpenWhisk CLI.
      o https://github.com/openwhisk/openwhisk-vscode
          + This is a prototype extension for Visual Studio Code that
            enables complete round trip cycles for authoring OpenWhisk
            actions inside the editor.
  * /*API Gateway repos.:*/
      o https://github.com/adobe-apiplatform/apigateway
          + The main API Gateway repository containing basic
            configuration files and a Dockerfile to build all modules
            into a single container.
      o https://github.com/adobe-apiplatform/api-gateway-request-validation
          + Module to validate the incoming API requests with support
            for OAuth 2.0, OAuth 1.0, and API-KEYs.
      o https://github.com/adobe-apiplatform/api-gateway-request-tracking
          + Support for Throttling & Rate Limiting
      o https://github.com/adobe-apiplatform/api-gateway-config-supervisor
          + Syncs config files from Amazon S3, Google Drive, Dropbox,
            Amazon Cloud Drive reloading the API Gateway with the updates
      o https://github.com/adobe-apiplatform/api-gateway-cachemanager
          + API request caching. This module manages multiple cache
            stores ( i.e. Redis cache, in-memory cache )
      o https://github.com/adobe-apiplatform/api-gateway-async-logger
          + Performant asynchronous logger used for capturing usage data
            based on the incoming API traffic
      o https://github.com/adobe-apiplatform/api-gateway-zmq-adaptor
          + ZeroMQ Adaptor for the API Gateway
      o https://github.com/adobe-apiplatform/api-gateway-zmq-logger
          + Logging module for ZeroMQ
      o https://github.com/adobe-apiplatform/api-gateway-aws
          + AWS SDK for NGINX
      o https://github.com/adobe-apiplatform/api-gateway-hmac
          + HMAC support for Lua with multiple algorithms, via OpenSSL


    *Source and Intellectual Property Submission **Plan*


      *External **Dependencies*

The OpenWhisk project code, documentation, samples (for all 
repositories)  have been fully authored under the Apache 2 license with 
a comprehensive CLA requirements enforced for all committers from its 
inception. The code has been fully screened and evaluated to assure its 
code consists of original contributions not encumbered by any license 
that would be incompatible with Apache.

_openwhisk-openwhisk_ <https://github.com/openwhisk/openwhisk>__

This repository is the primary repository for the OpenWhisk platform; it 
contains the implementations for all its component services, CLI and 
tooling.

  * /tooling and runtime dependencies/:
      o */Note/*/: all dependencies are to latest version unless noted
        otherwise.
        /
  * /Build and Deployment Tooling:/
      o ansible <https://github.com/ansible/ansible>v2.*
        <https://github.com/ansible/ansible/releases> : GNU GPL
        <https://github.com/ansible/ansible/blob/devel/COPYING>
          + Primary Runbook (playbooks) tooling for deployment with
            configurations for multiple target environments
            (ppa:ansible/ansible
            <https://launchpad.net/%7Eansible/+archive/ubuntu/ansible>).  Installed
            by ansible.sh
            <https://github.com/openwhisk/openwhisk/blob/master/tools/ubuntu-setup/ansible.sh>.

      o git <https://git-scm.com/> : GPL 2
        <https://opensource.org/licenses/GPL-2.0>
          + Command line for automation of \u201cpulling\u201d OpenWhisk
            repositories\u2019 code from Git repos.  Installed by misc.sh
            <https://github.com/openwhisk/openwhisk/blob/master/tools/ubuntu-setup/misc.sh>.

      o zip <http://packages.ubuntu.com/trusty/zip> : Info-ZIP
        <http://www.info-zip.org/license.html> (BSD style)
          + Tooling for decompressing files packaged in compressed ZIP
            <http://www.info-zip.org/Zip.html> format. Installed by
            misc.sh
            <https://github.com/openwhisk/openwhisk/blob/master/tools/ubuntu-setup/misc.sh>.

      o python-pip <https://pypi.python.org/pypi/pip> : MIT
          + Python installer. Installed by pip.sh
            <https://github.com/openwhisk/openwhisk/blob/master/tools/ubuntu-setup/pip.sh>

      o jsonschema <https://pypi.python.org/pypi/jsonschema> : MIT
          + Python Library. JSON schema validation. Installed by pip.sh
            <https://github.com/openwhisk/openwhisk/blob/master/tools/ubuntu-setup/pip.sh>

      o argcomplete <https://pypi.python.org/pypi/argcomplete/1.4.1>  :
        Apache
          + Python Library. Bash tab completion for \u2018argparse\u2019.
            Installed by pip.sh
            <https://github.com/openwhisk/openwhisk/blob/master/tools/ubuntu-setup/pip.sh>

      o oracle-java8-installer
        <http://www.ubuntuupdates.org/package/webupd8_java/precise/main/base/oracle-java8-installer> :
        Oracle Binary Code
        <http://www.oracle.com/technetwork/java/javase/downloads/thirdpartylicensereadme-java8-2168078.txt>

          + Oracle Java 8 Installer (_Ubuntu PPA archive_), Installed by
            java8.sh
            <https://github.com/openwhisk/openwhisk/blob/master/tools/ubuntu-setup/java8.sh>

      o software-properties-common
        <https://launchpad.net/software-properties> : GNU GPL v2
          + Manage your own PPAs
            <https://launchpad.net/ubuntu/+ppas> for use with Ubuntu
            APT. Installed by ansible.sh
            <https://github.com/openwhisk/openwhisk/blob/master/tools/ubuntu-setup/ansible.sh>

      o gradle <https://gradle.org/> 3.0
        <https://github.com/gradle/gradle/blob/master/design-docs/gradle-3.0.md>:
        _Apache 2_
        <https://github.com/openwhisk/openwhisk/tree/master/gradle/wrapper>
          + Build tool.
      o gradle-wrapper.jar
        <https://github.com/gradle/gradle/tree/master/subprojects/wrapper/src/main/java/org/gradle/wrapper> :
        Apache 2 <https://github.com/gradle/gradle/blob/master/LICENSE>
          + Gradle wrapper tool. Installed by gradle-wrapper.properties
            <https://github.com/openwhisk/openwhisk/blob/master/gradle/wrapper/gradle-wrapper.properties>

      o One-JAR <http://one-jar.sourceforge.net/> : One-JAR license
        <http://one-jar.sourceforge.net/index.php?page=documents&file=license> (BSD-style)

          + package a Java application together with its dependency Jars
            into a single executable Jar file. Used by
            core/javaAction/proxy/build.gradle
            <https://github.com/openwhisk/openwhisk/blob/555841b89da0375f6955069cbc7053015b7abbac/core/javaAction/proxy/build.gradle>

      o npm <https://www.npmjs.com/>  : Artistic License 2.0
        <https://en.wikipedia.org/wiki/Artistic_License_2.0>
          + Node Package Manager (NPM), core/nodejs6Action/Dockerfile
            <https://github.com/openwhisk/openwhisk/blob/04b6268895001aa556e6d579f4c3e0a5a9901a04/core/nodejs6Action/Dockerfile>

  * /Application Services:/
      o docker-engine <https://www.docker.com/products/docker-engine>,
        v1.9, moving to v1.12 : Apache 2
        <https://github.com/docker/docker/blob/master/LICENSE>
          + Runtime for Docker containers. Installed by docker.sh
            <https://github.com/openwhisk/openwhisk/blob/master/tools/ubuntu-setup/docker.sh>.

      o docker-py <https://github.com/docker/docker-py> v1.9, Apache 2
        <https://github.com/docker/docker-py/blob/master/LICENSE>
          + Python API client. Installed by ansible.sh
            <https://github.com/openwhisk/openwhisk/blob/master/tools/ubuntu-setup/ansible.sh>.

      o ntp <http://www.ntp.org/> : NTP
        <https://www.ntpsec.org/license.html> (BSD 3-clause)
          + Network Time Protocol service started to sync. peer-computer
            times. *Note*: UTC is default for all hosts.  Installed by
            misc.sh
            <https://github.com/openwhisk/openwhisk/blob/master/tools/ubuntu-setup/misc.sh>.

      o CouchDB <http://couchdb.apache.org/> : Apache 2
        <http://www.apache.org/licenses/LICENSE-2.0>
          + JSON document database. /Vagrant / User installed./
      o Consul <https://github.com/hashicorp/consul> v0.5.2
        <https://releases.hashicorp.com/consul/0.5.2/consul_0.5.2_linux_amd64.zip> :
        Mozilla v2
        <https://github.com/hashicorp/consul/blob/master/LICENSE>
          + Consul <https://www.consul.io/> Key-value data store.
            Installed by services/consul/Dockerfile.
            <https://github.com/openwhisk/openwhisk/blob/e8940509cc9ec73964fe3c5e68ab067bff83d7a2/services/consul/Dockerfile>

  * Runtime Libraries:
      o Scala <https://github.com/scala/scala/> v2.11
        <http://www.scala-lang.org/files/archive/scala-2.11.6.deb> :
        Scala (3-clause BSD <https://en.wikipedia.org/wiki/BSD_licenses>)
          + Primary language for OpenWhisk.  Specifically:
            org.scala-lang:scala-library
            <https://github.com/scala/scala/>, 2.11.6. Installed by
            scala.sh
            <https://github.com/openwhisk/openwhisk/blob/master/tools/ubuntu-setup/scala.sh>,
            (referenced by build.gradle
            <https://github.com/openwhisk/openwhisk/blob/master/common/scala/build.gradle>).

      o Node <https://nodejs.org/en/> v0.12.14
        <https://nodejs.org/en/blog/release/v0.12.14/>: MIT
        <https://raw.githubusercontent.com/nodejs/node/master/LICENSE>
          + Node JavaScript Runtime. It also includes many NPM
            libraries. See core/nodejsAction/Dockerfile
            <https://github.com/openwhisk/openwhisk/blob/master/core/nodejsAction/Dockerfile>
            for a complete/current list.
      o Node <https://nodejs.org/en/> v6.2
        <https://nodejs.org/en/blog/release/v6.2.0/>: MIT
        <https://raw.githubusercontent.com/nodejs/node/master/LICENSE>
          + The NodeJS6 Runtime. It also includes many NPM libraries.
            See core/nodejs6Action/Dockerfile
            <https://github.com/openwhisk/openwhisk/blob/master/core/nodejs6Action/Dockerfile> for
            a complete/current list.
      o Python Runtime, v2.7 (Python Std. Library
        <https://docs.python.org/2.7/library/index.html>) : Python
        <https://www.python.org/download/releases/2.7/license/>
          + Python based Docker Images are used in a few places.  For
            example, seee core/ActionProxy/Dockerfile
            <https://github.com/openwhisk/openwhisk/blob/master/core/actionProxy/Dockerfile>.  In
            addition, it is referenced by the Python CLI which is being
            deprecated as it is being replaced by a Go language CLI.
      o Java 8 JRE
        <http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html> :
        Oracle
        <http://www.oracle.com/technetwork/java/javase/downloads/thirdpartylicensereadme-java8-2168078.txt>

          + Java Language Runtime (Oracle Java 8 JDK). Referenced by
            common/scala/Dockerfile
            <https://github.com/openwhisk/openwhisk/blob/cc8c48f7a62ea7eefd04dbee415741987cc35510/common/scala/Dockerfile>,
            core/javaAction/Dockerfile
            <https://github.com/openwhisk/openwhisk/blob/master/core/javaAction/Dockerfile>,
            services/consul/.classpath
            <https://github.com/openwhisk/openwhisk/blob/d84ba6370ac9d889248829805eff00b1a7a62ce5/services/consul/.classpath>.

      o Akka <http://akka.io/> 2.47
        <http://akka.io/news/2016/06/03/akka-2.4.7-released.html>
        Libraries for Scala 2.11 : Apache 2
        <http://doc.akka.io/docs/akka/snapshot/project/licenses.html>
          + Specifically the following: \u201ccom.typesafe.akka:\u201d modules are
            used: akka-actor, akka-slf4j, akka-http-core,
            akka-http-spray-json-experimental. Installed by build.gradle
            <https://github.com/openwhisk/openwhisk/blob/master/common/scala/build.gradle>.

      o _argcomplete_ <https://pypi.python.org/pypi/argcomplete> : Apache
          + Python library. Bash tab completion for argparse. Installed
            by tools/ubuntu-setup/pip.sh
            <https://github.com/openwhisk/openwhisk/blob/master/tools/ubuntu-setup/pip.sh>.

      o _httplib_ <https://docs.python.org/2/library/httplib.html> :
        _Python_ <https://www.python.org/download/releases/2.7/license/>
          + Python library. HTTP protocol client. Installed by .
      o jsonschema <https://pypi.python.org/pypi/jsonschema> : MIT
          + Python library. Installed by tools/ubuntu-setup/pip.sh
            <https://github.com/openwhisk/openwhisk/blob/master/tools/ubuntu-setup/pip.sh>.

      o spray (source) : _Apache 2_
        <https://github.com/spray/spray/blob/master/LICENSE>
          + Scala libraries for building/consuming RESTful web services
            on top of Akka. Installed by _build.gradle_
            <https://github.com/openwhisk/openwhisk/blob/master/common/scala/build.gradle>.
            Specifically but not limited to: spray-caching, spray-json,
            spray-can, spray-client, spray-httpx, spray-io, spray-routing.
      o _log4j:log4j_
        <https://mvnrepository.com/artifact/log4j/log4j>:1.2.16
          + Java logging library. Installed by _build.gradle_
            <https://github.com/openwhisk/openwhisk/blob/master/common/scala/build.gradle>.

      o org.apache.* Libraries : _Apache 2_
        <http://www.apache.org/licenses/>
          + Including: _org.apache.commons_
            <https://commons.apache.org/>.*.
            org.apache.zookeeper:zookeeper,
            org.apache.kafka:kafka-clients,
            org.apache.httpcomponents:httpclient. See _build.gradle_
            <https://github.com/openwhisk/openwhisk/blob/master/common/scala/build.gradle>
            for current list and versions.
          + Including low level HTTP transport component libraries:
            _org.apache.http_
            <https://hc.apache.org/httpcomponents-core-4.4.x/index.html>.*,
            _org.apache.httpcomponents:_
            _httpclient_, . See whisk/_common_
            <https://github.com/openwhisk/openwhisk/tree/3f50c7b990145cebbd269a5978b7badd84123c5e/common/scala/src/main/scala/whisk/common>for
            current list and versions.
          + _org.apache.jute.compiler.JString_
            <https://svn.apache.org/repos/asf/zookeeper/trunk/src/java/main/org/apache/jute/compiler/JString.java>

      o _urlparse_ <https://docs.python.org/2/library/urlparse.html> :
        _Python_ <https://www.python.org/download/releases/2.7/license/>
          + Python library for URL string parsing. Referenced
            by tools/cli/_wskutil.py_
            <https://github.com/openwhisk/openwhisk/blob/e37db2a45562c1978fd2b625006d222c30b89b0f/tools/cli/wskutil.py>
            tools/build/_citool_.
            <https://github.com/openwhisk/openwhisk/blob/913e7c8f9a5debb7905d4bede5631582acc1a3d9/tools/build/citool>

      o _swagger-ui_ <https://github.com/swagger-api/swagger-ui/> 2.1.4
        : _Apache 2_
        <https://github.com/swagger-api/swagger-ui/blob/master/LICENSE>
        * /atypical license text/
          + Collection of HTML, Javascript, and CSS assets that
            dynamically generate documentation from a Swagger-compliant
            API.  See core/controller/_Dockerfile_
            <https://github.com/openwhisk/openwhisk/blob/master/core/controller/Dockerfile>.

  * /Optional Services and Tooling:/
      o _Cloudant_ <https://cloudant.com/> : Apache 2
          + /(Optional)/ Database service.  User may connect to instance
            from README. CouchDB can be used otherwise.
      o _Eclipse IDE_
        <http://eclipse.bluemix.net/packages/mars.1/data/eclipse-inst-linux64.tar.gz> : Eclipse
        Public License (EPL)
          + Tooling, IDE. /(Optional)/. OpenWhisk supplies a .project
            <https://github.com/openwhisk/openwhisk/blob/master/.project>
            and .pydevproject
            <https://github.com/openwhisk/openwhisk/blob/master/.pydevproject>
            files for the Eclipse IDE.
      o _emacs_ <https://www.gnu.org/software/emacs/> : _Emacs GPL_
        <https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=0ahUKEwjdoo2Ylv3NAhWp7YMKHfJkA3YQFggsMAM&url=http%3A%2F%2Fwww.free-soft.org%2Fgpl_history%2Femacs_gpl.html&usg=AFQjCNFaQUVDmA7smUHKz4_eSEOVXZTmBQ&sig2=GTOmmx3ooTBde>

          + Tooling, Editor. /(Optional) /Installs Emacs editor.
            Installed by _emacs.sh_.
            <https://github.com/openwhisk/openwhisk/blob/master/tools/ubuntu-setup/emacs.sh>

  * /Swift3 Runtime Dependencies/:
      o The following Python libraries are installed in
        the core/swift3Action/_Dockerfile_:
        <https://github.com/openwhisk/openwhisk/blob/287bae8eb96b2965a65e4d87b14adbc885a83352/core/swift3Action/Dockerfile>

      o _Python 2.7 : _Python_
        <https://www.python.org/download/releases/2.7/license/>_
          + _Python Std. Library_
            <https://docs.python.org/2.7/library/index.html>.
      o _python-gevent_ <http://www.gevent.org/> : MIT
          + Python proxy support.
      o _python-distribute_
        <https://pypi.python.org/pypi/distribute/0.6.49>/ : /_PSF_
        <https://opensource.org/licenses/Python-2.0> (or ZPL)
          +   Supports the /download/, /build/, /install/, /upgrade/,
            /uninstall/ of Python packages. See:
            _http://pythonhosted.org/distribute_
            <http://pythonhosted.org/distribute/>. /Note: this is a fork
            of: _https://github.com/pypa/setuptools_./
      o _python-pip : MIT_
          + PyPA recommended tool for installing Python packages.
      o _python-flask_ <https://pypi.python.org/pypi/Flask> : BSD
          + Python proxy support.
      o _clang_ <http://clang.llvm.org/>  : _NCSA Open Source_
        <https://en.wikipedia.org/wiki/University_of_Illinois/NCSA_Open_Source_License>

          + 'C' Library. Apple compiler front-end for \u2018C\u2019 (LLVM back-end).
      o _libedit-dev_
        <https://launchpad.net/ubuntu/trusty/+package/libedit-dev> : BSD
        (3-clause)
          + Linux, BSD editline and hostry library.
      o _libxml2-dev_
        <https://launchpad.net/ubuntu/trusty/+package/libxml2-dev> : MIT
          + Linux, Gnome XML library.
      o _libicu52_
        <http://www.ubuntuupdates.org/package/core/vivid/main/updates/libicu52>
        : _Unicode_ <http://www.unicode.org/copyright.html>
          + Linux, Unicode support library.
      o Kitura <https://github.com/IBM-Swift/Kitura> : Apache 2
        <https://github.com/IBM-Swift/Kitura/blob/master/LICENSE.txt>
          + Web framework and web server that is created for web
            services written in Swift.
      o Kitura dependencies : BSD (BSD-like)
          + Linux libraries including: autoconf, libtool,
            _libkqueue-dev, _libkqueue0, libdispatch-dev, libdispatch0,
            libcurl4-openssl-dev, libbsd-dev.
      o _apple/swift-corelibs-libdispatch_
        <https://github.com/apple/swift-corelibs-libdispatch> : _Apache
        2_
        <https://github.com/apple/swift-corelibs-libdispatch/blob/master/LICENSE>

          + Enables Swift code execution on multicore hardware.

Adobe-API-Platform <https://github.com/adobe-apiplatform>

  * Openresty - Licensed under the 2-clause BSD license -
    https://github.com/openresty/ngx_openresty#copyright--license
  * NGINX License - http://nginx.org/LICENSE
  * Luajit - MIT License - http://luajit.org/luajit.html
  * PCRE - BSD license - http://www.pcre.org/licence.txt
  * NAXSI: GPL - is not compiled with the Gateway API code. Instead The
    API Gateway project contains instructions for developers on where to
    get NAXSI code (under GPL)
  * ZeroMQ / �MQ - Linked Dynamically in separate module
  * libzmq - LGPL license with SPECIAL EXCEPTION GRANTED BY COPYRIGHT
    HOLDERS - https://github.com/zeromq/libzmq
  * czmq - High Level C binding for libzmq - MPL v2 license
    https://github.com/zeromq/czmq


      *Cryptography*

Please note that the file 
https://github.com/openwhisk/openwhisk/blob/master/common/scala/src/main/scala/whisk/common/Crypt.scala 
makes use of the Java javax.crypto.* libraries to implement 
encrypt/decrypt functions.  Primarily this is used to encrypt/decrypt 
user keys  or secrets when being passed or stored between or by 
OpenWhisk components.


      *Required Resources*

Resources that infrastructure will be asked to supply for this project.

Over the course of the incubator we would like to develop staging and 
playground server environments for testing and developer experience. The 
following environment would be desirable for an initial staging (and 
separate playground):

  * */CI /**/Test /**/Cluster requirements/**/:/*
      o 3 VMs ,Catalog (CouchDB/Cloudant), Router (Nginx), Registry
      o 2 VMs, Master (Controller + Consul), Message Bus (Kafka)
      o 10 VMs, Invokers
      o Each VM assumes 4 CPUs, 8GB Memory, 80GB additional storage
  * */Mechanics/**/:/*
      o Scripts that invoke Ansible playbooks for *build*, *deploy*
        (run) and *clean* are provided.
      o The various architectural components are started via Docker
        containers (either natively, within a single Vagrant VM, or
        across multiple, designated VM roles) using user configured (or
        defaulted) endpoints and (guest) authorization credentials.
      o In addition, the user/developer may choose to use the default
        ephemeral CouchDB (via Docker container) for the OpenWhisk
        catalog or switch to use a native CouchDB or a remote Cloudant
        database.

In addition, we would like to host a VM with a Node.js server that 
provides Command Line Tutorials, along with demo samples.


      *Mailing **lists*

Initially, we would start with the following recommended initial podling 
mailing lists:

  * _private@openwhisk.incubator.apache.org_
    <ma...@openwhisk.incubator.apache.org>,
  * _dev@_/_{podling}_/_.incubator.apache.org_
    <mailto:dev@%7Bpodling%7D.incubator.apache.org>

We would add more as we transition off exiting mailings lists and 
through the course of incubation.


      *Git Repository*

As a community we would like to keep the master repository as well as 
issue tracking on GitHub. We will be working closely with ASF Infra. 
team to implement all the required pieces like ensure to send push and 
issue notifications through ASF controlled mailing lists. During 
incubation we will work closely with Infra to support GitHub master 
repositories. We also understand that we have to support a way of 
providing patches, which does not require a GitHub account for 
contributors who are not willing or not able abide by GitHub\u2019s terms and 
conditions. It is our understanding that this approach has been signed 
off by Greg Stein, ASF\u2019s Infrastructure Administrator.

If we need to adapt our repo. paths to conform to Apache guidelines (and 
perhaps necessitted by a move the the Apache named repo.) It is 
conventional to use all lower case, dash-separated (|-|) repository 
names. The repository should be prefixed with incubator and later 
renamed assuming the project is promoted to a TLP.

If we need to move the project codebase from its existing GitHub repo. 
as part of incubation, we would like to preserve the directory names as 
they appear today and adopt the \u201capache\u201d as part of the URI path as we 
have seen other projects adopt.

This would mean all existing repositories which are now of the form:

  * _https://github.com/openwhisk/openwhisk_
  * _https://github.com/openwhisk/openwhisk-catalog_
  * _https://githun.com/openwhisk/openwhisk-package-rss_
  * etc.

would now take the form:

  * _https://github.com/apache/openwhisk/openwhisk_
  * _https://github.com/apache/openwhisk/openwhisk-catalog_
  * _https://githun.com/apache/openwhisk/openwhisk-package-rss_
  * and so on ...


      *Issue Tracking*

We would like to explore the possibility of continuing to use GitHub 
issue tracking (as project milestones, epics and features are all nicely 
tracked via ZenHub boards) as we understand that this may now be 
possible. We will provide any linkage or support for JIRA issue tracking 
if that is required in order to track any \u201cpull\u201d requests within GitHub.


      *Other **Resources*

We would like to preserve our existing automated TravisCI automated 
testing from GitHub. The project uses a continuous CD/CI process 
currently that we would like to continue to support via multiple stages 
that run progressive stress and performance tests that are also automated.


      *Initial **Committers*

The following is the proposed list of initial committers, email address 
[, GitHub ID)]:

  * Stephen Fink, sjfink@us.ibm.com <ma...@us.ibm.com>, _sjfink_
    <https://github.com/sjfink>
  * Rodric Rabbah, rabbah@us.ibm.com <ma...@us.ibm.com>,
    _rabbah_ <https://github.com/rabbah>
  * Markus Thommes, markus.thoemmes@de.ibm.com
    <ma...@de.ibm.com>, _markusthoemmes_
    <https://github.com/markusthoemmes>
  * Jeremias Werner, JEREWERN@de.ibm.com <ma...@de.ibm.com>,
    _jeremiaswerner_ <https://github.com/jeremiaswerner>
  * Perry Cheng, perry@us.ibm.com <ma...@us.ibm.com>, _perryibm_
    <https://github.com/perryibm>
  * Philippe Sutor, psuter@us.ibm.com <ma...@us.ibm.com>,
    _psutor_ <https://github.com/psuter>
  * Christian Bickel, CBICKEL@de.ibm.com <ma...@de.ibm.com>,
    _christianbickel_ <https://github.com/ChrBi>
  * Carlos Santana, csantana@us.ibm.com <ma...@us.ibm.com>,
    _csantanapr_ <https://github.com/csantanapr>
  * Matt Rutkowski, mrutkows@us.ibm.com <ma...@us.ibm.com>,
    _mrutkows_ <https://github.com/mrutkows>
  * Vincent Hou, shou@us.ibm.com <ma...@us.ibm.com>, _houshengbo_
    <https://github.com/houshengbo>
  * Daisy Guo, guoyingc@cn.ibm.com <ma...@cn.ibm.com>,
    _daisy-ycguo_ <https://github.com/daisy-ycguo>
  * David Liu, david.liu@cn.ibm.com <ma...@cn.ibm.com>,
    _lzbj_ <https://github.com/lzbj>
  * Paul Castro, castrop@us.ibm.com <ma...@us.ibm.com>,
    _paulcastro_ <https://github.com/paulcastro>
  * Nicholas Speeter, nwspeete@us.ibm.com <ma...@us.ibm.com>,
    nwspeete-ibm <https://github.com/nwspeete-ibm>
  * Carsten Ziegeler, cziegeler@apache.org
    <ma...@apache.org>, cziegeler <https://github.com/cziegeler>
  * Chetan Mehrotra, chetanm@adobe.com <ma...@adobe.com>,
    chetanmeh <https://github.com/chetanmeh>
  * Bertrand Delacretaz, bdelacretaz@apache.org
    <ma...@apache.org>, bdelacretaz
    <https://github.com/bdelacretaz>
  * Dragos Dascalita Haut, ddascal@adobe.com <ma...@adobe.com>,
    ddragosd <https://github.com/ddragosd>

Although this list of initial committers appears long, OpenWhisk is a 
complete platform which consists of many services supporting many 
environments, programming languages and integrations. This diversity in 
needs is reflected by the size of the initial committers group. 
OpenWhisk also supports an end user ecosystem including CLI, Tooling, 
Package Catalog, \u201ccurated\u201d Packages, samples, etc. along with the 
intention of tying in API gateway (e.g., OpenAPI) and other event source 
integrations.

We hope to add many more committers who provide expertise and the 
various areas OpenWhisk uses to efficiently provide an exceptional 
Serverless platform with compelling content.


      *Affiliations*

Additional TBD during the proposal process


      *Sponsors*

Additional TBD during the proposal process.


      *Sponsoring **Entity*

OpenWhisk would ask that the Apache Incubator be the sponsor.


Re: [discuss] Apache OpenWhisk Incubator Proposal

Posted by Felix Meschberger <fm...@adobe.com>.
Hi Mark

Understood. And these are valid points to be discussed in the larger context of whether ASF supports GitHub as a primary repository. Which in turn is outside of the scope of this proposal. And which is where this OpenWhiz community will have a vested interest in participating.

And as Greg already added a comment to the proposal, would it be ok to get back to the technical merrit of this proposal and not loose ourselves in the discussion over whether GitHub is ok or not ? Thanks.

Regards
Felix

> Am 14.10.2016 um 15:37 schrieb Mark Struberg <st...@yahoo.de.INVALID>:
> 
> The problem with github is that we (ASF) cannot give any guarantees if the main stuff doesn't originate from our own hardware.
> 
> Not whether the ticket system doesn't loose all tickets (didn't that happen in the past?) nor whether really only IP clean stuff got committed.
> You e.g. have no clue if someone else uses your email and name in a commit and pushes it.
> Everyone else can create a commit with your email and name in GIT, there is no check. And when pulling in changes, a faked one might get piggy packed and introduce a backdoor. I know this might be close to paranoid but it is theoretically possible.
> 
> 
> 
> The workflow with git hosted @ASF is btw pretty much exactly the same for committers. And a PR integration does exist as well. So I don't see what you miss?
> 
> LieGrue,
> strub
> 
> 
> 
> 
>> On Friday, 14 October 2016, 13:52, Felix Meschberger <fm...@adobe.com> wrote:
>>> Hi John
>> 
>> This also ties into Mark’s question earlier on.
>> 
>> The OpenWhisk part of the proposal is currently being developed in GitHub and 
>> the developers are used to the GitHub flow and features including but not 
>> limited to GitHub Issues.
>> 
>> We have discussed this topic before proposing the project and we are all aware 
>> on the caveats. But as we write in the proposal, we intend to work with infra 
>> and other stakeholders to have repositories in GitHub accepted as primary work 
>> repositories before graduation.
>> 
>> Hope that helps.
>> 
>> Regards
>> Felix
>> 
>> 
>>> Am 14.10.2016 um 12:50 schrieb John D. Ament <jo...@apache.org>:
>>> 
>>> Sam,
>>> 
>>> Can your or someone representing the proposed podling explain why using
>>> github as master is preferable to the current mirror strategy in use?
>>> 
>>> John
>>> 
>>> On Fri, Oct 14, 2016 at 6:29 AM Sam Ruby <ru...@intertwingly.net> 
>> wrote:
>>> 
>>>> On Fri, Oct 14, 2016 at 1:31 AM, Greg Stein <gs...@gmail.com> 
>> wrote:
>>>>> On Thu, Oct 13, 2016 at 3:27 PM, Sam Ruby 
>> <ru...@intertwingly.net>
>>>> wrote:
>>>>> 
>>>>>> Hello everyone,
>>>>>> 
>>>>>> Attached to this message is a proposed new project - Apache 
>> OpenWhisk.
>>>>>> 
>>>>>> The text of the proposal is included below. Additionally, the 
>> proposal
>>>> is
>>>>>> in draft form on the Wiki, where we will make any required 
>> changes:
>>>>>> 
>>>>>> https://wiki.apache.org/incubator/OpenWhiskProposal
>>>>>> 
>>>>>> We look forward to your feedback and input.
>>>>> 
>>>>> OpenWhisk has a first-time-unique request on its Git repository 
>> request.
>>>> I
>>>>> inserted a comment about OpenWhisk's use of a GitHub repository 
>> [from
>>>>> Infra's standpoint], and the relation to the Foundation and a 
>> possible
>>>>> block on graduation.
>>>> 
>>>> If I could get some help in the form of an infrastructure team review
>>>> of the following plan, I would appreciate it:
>>>> 
>>>> 
>>>> 
>> https://lists.apache.org/thread.html/5b93ec0517ce7f90c0a467db9fc5e9cd087f1d4d9305c5491198b6c1@%3Cinfrastructure-private.apache.org%3E
>>>> 
>>>>> Thx,
>>>>> -g
>>>> 
>>>> - Sam Ruby
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>> 
>>>> 
>> 
>> B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB•È[œÝXœØÜšX™KK[XZ[ˆÙ[™\˜[][œÝXœØÜšX™P[˜ÝX˜]Ü‹˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ËK[XZ[ˆÙ[™\˜[Z[[˜ÝX˜]Ü‹˜\XÚK›Ü™ÃB
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org


Re: [discuss] Apache OpenWhisk Incubator Proposal

Posted by Mark Struberg <st...@yahoo.de.INVALID>.

> Git repositories are effectively cryptographically-signed (weak/strong,
> immaterial to this discussion), so a readonly mirror on ASF hardware is
> equivalent to a read/write repository living on GitHub.


Allow me to disagree. The hashes are cryptographically strong. But it's only sha1 hashes and no real signing. The sha1 hashes only the things you tell him. Try to do  git config user.name "Foo Baz" and you are Mr Foo Baz from now on. If you push this to github then your own authentity is lost for the commit. I could e.g. also commit something with your name and your email ;) We still hope that this would get catched if the commit gets mirrored to the list...

The -s option is btw something completely different.


But Felix is right, it's a foundation wide question and we should continue this discussion on the infra lists.


txs and LieGrue,
strub


> On Friday, 14 October 2016, 16:26, Greg Stein <gs...@gmail.com> wrote:
> > On Fri, Oct 14, 2016 at 8:37 AM, Mark Struberg <st...@yahoo.de.invalid>
> wrote:
> 
>>  The problem with github is that we (ASF) cannot give any guarantees if the
>>  main stuff doesn't originate from our own hardware.
>> 
> 
> Git repositories are effectively cryptographically-signed (weak/strong,
> immaterial to this discussion), so a readonly mirror on ASF hardware is
> equivalent to a read/write repository living on GitHub.
> 
> 
>>  Not whether the ticket system doesn't loose all tickets (didn't 
> that
>>  happen in the past?) nor whether really only IP clean stuff got committed.
>> 
> 
> All commits, issues, PRs, etc will/must be sent to ASF mailing lists for
> archival. Some projects do/have used third party systems. The ASF doesn't
> mind, as long as we capture that work into our archives.
> 
> 
>>  You e.g. have no clue if someone else uses your email and name in a commit
>>  and pushes it.
>>  Everyone else can create a commit with your email and name in GIT, there
>>  is no check. And when pulling in changes, a faked one might get piggy
>>  packed and introduce a backdoor. I know this might be close to paranoid but
>>  it is theoretically possible.
>> 
> 
> We require that anybody committing to a GitHub repository authenticates
> with BOTH: GitHub, and the ASF. No commits without that multiple
> authentication.
> (this is based on our current experiments with Whimsy and Traffic Server;
> same rules would apply to this podling)
> 
> 
>>  The workflow with git hosted @ASF is btw pretty much exactly the same for
>>  committers. And a PR integration does exist as well. So I don't see 
> what
>>  you miss?
>> 
> 
> ASF repositories mirrored to GitHub cannot merge/close PRs. They cannot
> manage issues. They cannot use labels. There is a large amount of GitHub
> tooling that is not available to ASF-based projects/workflows. The Github
> repository is a simple mirror. ... OpenWhisk proposes to continue using
> their GitHub workflows and tooling during incubation. At the *end* of
> incubation, the Foundation will allow them to stay (as we'll be allowing
> other projects to similarly change their focal point of development), or
> they will be required to shift their focal point to ASF-based workflows (as
> we require today).
> 
> Cheers,
> 
> -g
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [discuss] Apache OpenWhisk Incubator Proposal

Posted by Greg Stein <gs...@gmail.com>.
On Fri, Oct 14, 2016 at 8:37 AM, Mark Struberg <st...@yahoo.de.invalid>
wrote:

> The problem with github is that we (ASF) cannot give any guarantees if the
> main stuff doesn't originate from our own hardware.
>

Git repositories are effectively cryptographically-signed (weak/strong,
immaterial to this discussion), so a readonly mirror on ASF hardware is
equivalent to a read/write repository living on GitHub.


> Not whether the ticket system doesn't loose all tickets (didn't that
> happen in the past?) nor whether really only IP clean stuff got committed.
>

All commits, issues, PRs, etc will/must be sent to ASF mailing lists for
archival. Some projects do/have used third party systems. The ASF doesn't
mind, as long as we capture that work into our archives.


> You e.g. have no clue if someone else uses your email and name in a commit
> and pushes it.
> Everyone else can create a commit with your email and name in GIT, there
> is no check. And when pulling in changes, a faked one might get piggy
> packed and introduce a backdoor. I know this might be close to paranoid but
> it is theoretically possible.
>

We require that anybody committing to a GitHub repository authenticates
with BOTH: GitHub, and the ASF. No commits without that multiple
authentication.
(this is based on our current experiments with Whimsy and Traffic Server;
same rules would apply to this podling)


> The workflow with git hosted @ASF is btw pretty much exactly the same for
> committers. And a PR integration does exist as well. So I don't see what
> you miss?
>

ASF repositories mirrored to GitHub cannot merge/close PRs. They cannot
manage issues. They cannot use labels. There is a large amount of GitHub
tooling that is not available to ASF-based projects/workflows. The Github
repository is a simple mirror. ... OpenWhisk proposes to continue using
their GitHub workflows and tooling during incubation. At the *end* of
incubation, the Foundation will allow them to stay (as we'll be allowing
other projects to similarly change their focal point of development), or
they will be required to shift their focal point to ASF-based workflows (as
we require today).

Cheers,
-g

Re: [discuss] Apache OpenWhisk Incubator Proposal

Posted by Mark Struberg <st...@yahoo.de.INVALID>.
The problem with github is that we (ASF) cannot give any guarantees if the main stuff doesn't originate from our own hardware.

Not whether the ticket system doesn't loose all tickets (didn't that happen in the past?) nor whether really only IP clean stuff got committed.
You e.g. have no clue if someone else uses your email and name in a commit and pushes it.
Everyone else can create a commit with your email and name in GIT, there is no check. And when pulling in changes, a faked one might get piggy packed and introduce a backdoor. I know this might be close to paranoid but it is theoretically possible.



The workflow with git hosted @ASF is btw pretty much exactly the same for committers. And a PR integration does exist as well. So I don't see what you miss?

LieGrue,
strub




> On Friday, 14 October 2016, 13:52, Felix Meschberger <fm...@adobe.com> wrote:
> > Hi John
> 
> This also ties into Mark’s question earlier on.
> 
> The OpenWhisk part of the proposal is currently being developed in GitHub and 
> the developers are used to the GitHub flow and features including but not 
> limited to GitHub Issues.
> 
> We have discussed this topic before proposing the project and we are all aware 
> on the caveats. But as we write in the proposal, we intend to work with infra 
> and other stakeholders to have repositories in GitHub accepted as primary work 
> repositories before graduation.
> 
> Hope that helps.
> 
> Regards
> Felix
> 
> 
>>  Am 14.10.2016 um 12:50 schrieb John D. Ament <jo...@apache.org>:
>> 
>>  Sam,
>> 
>>  Can your or someone representing the proposed podling explain why using
>>  github as master is preferable to the current mirror strategy in use?
>> 
>>  John
>> 
>>  On Fri, Oct 14, 2016 at 6:29 AM Sam Ruby <ru...@intertwingly.net> 
> wrote:
>> 
>>>  On Fri, Oct 14, 2016 at 1:31 AM, Greg Stein <gs...@gmail.com> 
> wrote:
>>>>  On Thu, Oct 13, 2016 at 3:27 PM, Sam Ruby 
> <ru...@intertwingly.net>
>>>  wrote:
>>>> 
>>>>>  Hello everyone,
>>>>> 
>>>>>  Attached to this message is a proposed new project - Apache 
> OpenWhisk.
>>>>> 
>>>>>  The text of the proposal is included below. Additionally, the 
> proposal
>>>  is
>>>>>  in draft form on the Wiki, where we will make any required 
> changes:
>>>>> 
>>>>>  https://wiki.apache.org/incubator/OpenWhiskProposal
>>>>> 
>>>>>  We look forward to your feedback and input.
>>>> 
>>>>  OpenWhisk has a first-time-unique request on its Git repository 
> request.
>>>  I
>>>>  inserted a comment about OpenWhisk's use of a GitHub repository 
> [from
>>>>  Infra's standpoint], and the relation to the Foundation and a 
> possible
>>>>  block on graduation.
>>> 
>>>  If I could get some help in the form of an infrastructure team review
>>>  of the following plan, I would appreciate it:
>>> 
>>> 
>>> 
> https://lists.apache.org/thread.html/5b93ec0517ce7f90c0a467db9fc5e9cd087f1d4d9305c5491198b6c1@%3Cinfrastructure-private.apache.org%3E
>>> 
>>>>  Thx,
>>>>  -g
>>> 
>>>  - Sam Ruby
>>> 
>>>  ---------------------------------------------------------------------
>>>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>  For additional commands, e-mail: general-help@incubator.apache.org
>>> 
>>> 
> 
> B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB•È[œÝXœØÜšX™KK[XZ[ˆÙ[™\˜[][œÝXœØÜšX™P[˜ÝX˜]Ü‹˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ËK[XZ[ˆÙ[™\˜[Z[[˜ÝX˜]Ü‹˜\XÚK›Ü™ÃB
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [discuss] Apache OpenWhisk Incubator Proposal

Posted by Felix Meschberger <fm...@adobe.com>.
Hi John

This also ties into Mark’s question earlier on.

The OpenWhisk part of the proposal is currently being developed in GitHub and the developers are used to the GitHub flow and features including but not limited to GitHub Issues.

We have discussed this topic before proposing the project and we are all aware on the caveats. But as we write in the proposal, we intend to work with infra and other stakeholders to have repositories in GitHub accepted as primary work repositories before graduation.

Hope that helps.

Regards
Felix

> Am 14.10.2016 um 12:50 schrieb John D. Ament <jo...@apache.org>:
> 
> Sam,
> 
> Can your or someone representing the proposed podling explain why using
> github as master is preferable to the current mirror strategy in use?
> 
> John
> 
> On Fri, Oct 14, 2016 at 6:29 AM Sam Ruby <ru...@intertwingly.net> wrote:
> 
>> On Fri, Oct 14, 2016 at 1:31 AM, Greg Stein <gs...@gmail.com> wrote:
>>> On Thu, Oct 13, 2016 at 3:27 PM, Sam Ruby <ru...@intertwingly.net>
>> wrote:
>>> 
>>>> Hello everyone,
>>>> 
>>>> Attached to this message is a proposed new project - Apache OpenWhisk.
>>>> 
>>>> The text of the proposal is included below. Additionally, the proposal
>> is
>>>> in draft form on the Wiki, where we will make any required changes:
>>>> 
>>>> https://wiki.apache.org/incubator/OpenWhiskProposal
>>>> 
>>>> We look forward to your feedback and input.
>>> 
>>> OpenWhisk has a first-time-unique request on its Git repository request.
>> I
>>> inserted a comment about OpenWhisk's use of a GitHub repository [from
>>> Infra's standpoint], and the relation to the Foundation and a possible
>>> block on graduation.
>> 
>> If I could get some help in the form of an infrastructure team review
>> of the following plan, I would appreciate it:
>> 
>> 
>> https://lists.apache.org/thread.html/5b93ec0517ce7f90c0a467db9fc5e9cd087f1d4d9305c5491198b6c1@%3Cinfrastructure-private.apache.org%3E
>> 
>>> Thx,
>>> -g
>> 
>> - Sam Ruby
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>> 
>> 


Re: [discuss] Apache OpenWhisk Incubator Proposal

Posted by "John D. Ament" <jo...@apache.org>.
Sam,

Can your or someone representing the proposed podling explain why using
github as master is preferable to the current mirror strategy in use?

John

On Fri, Oct 14, 2016 at 6:29 AM Sam Ruby <ru...@intertwingly.net> wrote:

> On Fri, Oct 14, 2016 at 1:31 AM, Greg Stein <gs...@gmail.com> wrote:
> > On Thu, Oct 13, 2016 at 3:27 PM, Sam Ruby <ru...@intertwingly.net>
> wrote:
> >
> >> Hello everyone,
> >>
> >> Attached to this message is a proposed new project - Apache OpenWhisk.
> >>
> >> The text of the proposal is included below. Additionally, the proposal
> is
> >> in draft form on the Wiki, where we will make any required changes:
> >>
> >> https://wiki.apache.org/incubator/OpenWhiskProposal
> >>
> >> We look forward to your feedback and input.
> >
> > OpenWhisk has a first-time-unique request on its Git repository request.
> I
> > inserted a comment about OpenWhisk's use of a GitHub repository [from
> > Infra's standpoint], and the relation to the Foundation and a possible
> > block on graduation.
>
> If I could get some help in the form of an infrastructure team review
> of the following plan, I would appreciate it:
>
>
> https://lists.apache.org/thread.html/5b93ec0517ce7f90c0a467db9fc5e9cd087f1d4d9305c5491198b6c1@%3Cinfrastructure-private.apache.org%3E
>
> > Thx,
> > -g
>
> - Sam Ruby
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: [discuss] Apache OpenWhisk Incubator Proposal

Posted by Sam Ruby <ru...@intertwingly.net>.
On Fri, Oct 14, 2016 at 1:31 AM, Greg Stein <gs...@gmail.com> wrote:
> On Thu, Oct 13, 2016 at 3:27 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>
>> Hello everyone,
>>
>> Attached to this message is a proposed new project - Apache OpenWhisk.
>>
>> The text of the proposal is included below. Additionally, the proposal is
>> in draft form on the Wiki, where we will make any required changes:
>>
>> https://wiki.apache.org/incubator/OpenWhiskProposal
>>
>> We look forward to your feedback and input.
>
> OpenWhisk has a first-time-unique request on its Git repository request. I
> inserted a comment about OpenWhisk's use of a GitHub repository [from
> Infra's standpoint], and the relation to the Foundation and a possible
> block on graduation.

If I could get some help in the form of an infrastructure team review
of the following plan, I would appreciate it:

https://lists.apache.org/thread.html/5b93ec0517ce7f90c0a467db9fc5e9cd087f1d4d9305c5491198b6c1@%3Cinfrastructure-private.apache.org%3E

> Thx,
> -g

- Sam Ruby

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [discuss] Apache OpenWhisk Incubator Proposal

Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Why isn't it enough to just mirror to github?
I only quickly read through the proposal and I'm not sure if thy just stated that _currently_ the repo is on github. 

With GIT it makes no difference at all where the repo is hosted IF you have a track record (which ASF git-wip does, but github doesn't have).

LieGrue,
strub





> On Friday, 14 October 2016, 7:31, Greg Stein <gs...@gmail.com> wrote:
> > On Thu, Oct 13, 2016 at 3:27 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> 
>>  Hello everyone,
>> 
>>  Attached to this message is a proposed new project - Apache OpenWhisk.
>> 
>>  The text of the proposal is included below. Additionally, the proposal is
>>  in draft form on the Wiki, where we will make any required changes:
>> 
>>  https://wiki.apache.org/incubator/OpenWhiskProposal
>> 
>>  We look forward to your feedback and input.
>> 
> 
> OpenWhisk has a first-time-unique request on its Git repository request. I
> inserted a comment about OpenWhisk's use of a GitHub repository [from
> Infra's standpoint], and the relation to the Foundation and a possible
> block on graduation.
> 
> Thx,
> -g
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [discuss] Apache OpenWhisk Incubator Proposal

Posted by Greg Stein <gs...@gmail.com>.
On Thu, Oct 13, 2016 at 3:27 PM, Sam Ruby <ru...@intertwingly.net> wrote:

> Hello everyone,
>
> Attached to this message is a proposed new project - Apache OpenWhisk.
>
> The text of the proposal is included below. Additionally, the proposal is
> in draft form on the Wiki, where we will make any required changes:
>
> https://wiki.apache.org/incubator/OpenWhiskProposal
>
> We look forward to your feedback and input.
>

OpenWhisk has a first-time-unique request on its Git repository request. I
inserted a comment about OpenWhisk's use of a GitHub repository [from
Infra's standpoint], and the relation to the Foundation and a possible
block on graduation.

Thx,
-g

Re: [discuss] Apache OpenWhisk Incubator Proposal

Posted by Isabel Drost-Fromm <is...@apache.org>.
On Mon, Oct 17, 2016 at 11:48:15AM -0400, Sam Ruby wrote:
> On Mon, Oct 17, 2016 at 11:30 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> > I have an issue, based on past history, related to IBM's continued
> > efforts and dedication on ASF projects. I will not mention specific
> > projects, but the ASF has a number of projects which died (or
> > almost died and only were revived via super-human effort) when
> > IBM decided to switch gears and no longer support the project.
> >
> > Now most of all this was our fault: the whole intent of Incubation
> > and the Apache Way is to prevent dependence on a single person
> > or entity: diversity means being able to continue, in a healthy
> > way, should someone (or some-thing) decide that the project is
> > no longer for them.
> >
> > Considering all this, I would hope and expect that this podling
> > take extra steps to ensure that we don't get "burned" again...
> 
> +1
> 
> I see this as an issue to be resolved prior to exiting incubation, not
> something that should impact being accepted for incubation.

The above reads like we have experience with bringing projects back to life when
one sponsor of time for committers goes away. From that experience do we have a
description of which concrete steps worked in the past?


Isabel


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [discuss] Apache OpenWhisk Incubator Proposal

Posted by Sam Ruby <ru...@intertwingly.net>.
On Mon, Oct 17, 2016 at 11:30 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> I see that this is a proposal that originates, basically from IBM.

IBM + Adobe

> I have an issue, based on past history, related to IBM's continued
> efforts and dedication on ASF projects. I will not mention specific
> projects, but the ASF has a number of projects which died (or
> almost died and only were revived via super-human effort) when
> IBM decided to switch gears and no longer support the project.
>
> Now most of all this was our fault: the whole intent of Incubation
> and the Apache Way is to prevent dependence on a single person
> or entity: diversity means being able to continue, in a healthy
> way, should someone (or some-thing) decide that the project is
> no longer for them.
>
> Considering all this, I would hope and expect that this podling
> take extra steps to ensure that we don't get "burned" again...

+1

I see this as an issue to be resolved prior to exiting incubation, not
something that should impact being accepted for incubation.

> PS: Nothing against IBM of course: being a business, their strategy
>     is wont to change, and we cannot (and should not) "fault" them
>     when such a strategy change adversely affects a project. My
>     only point is that, based on past experience, we should simply
>     recognize that IBM dropping their support/resources on this
>     project at some point is a very real, statistical possibility,
>     and be serious in our efforts in ensuring this podling/project
>     can and will survive that.

Agreed on both points: this is a general concern that should apply
everywhere, and given IBM's past history is particularly relevant to
this proposal.

- Sam Ruby

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [discuss] Apache OpenWhisk Incubator Proposal

Posted by Jim Jagielski <ji...@jaguNET.com>.
I see that this is a proposal that originates, basically from IBM.

I have an issue, based on past history, related to IBM's continued
efforts and dedication on ASF projects. I will not mention specific
projects, but the ASF has a number of projects which died (or
almost died and only were revived via super-human effort) when
IBM decided to switch gears and no longer support the project.

Now most of all this was our fault: the whole intent of Incubation
and the Apache Way is to prevent dependence on a single person
or entity: diversity means being able to continue, in a healthy
way, should someone (or some-thing) decide that the project is
no longer for them.

Considering all this, I would hope and expect that this podling
take extra steps to ensure that we don't get "burned" again...

PS: Nothing against IBM of course: being a business, their strategy
    is wont to change, and we cannot (and should not) "fault" them
    when such a strategy change adversely affects a project. My
    only point is that, based on past experience, we should simply
    recognize that IBM dropping their support/resources on this
    project at some point is a very real, statistical possibility,
    and be serious in our efforts in ensuring this podling/project
    can and will survive that.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org