Presented to the TAC:
Subgroup reviewed on:
...
Required Information | Responses (Please list N/A if not applicable) |
Name of Project | EdgeLakeCreate |
Project Description (what it does, why it is valuable, origin and history) | EdgeLake provides a software solution to manage and store data at edge nodes such that: a) distributed edge data appears as a unified collection of data (without centralizing the data), b) data processes at the edge are fully automated (for example: automated schema creation) and c) the distributed edge nodes appear and managed from a single point as a single machine. |
Statement on alignment with Foundation Mission Statement | We agree with the foundation's mission statement. |
| High level assessment of project synergy with existing projects under LF Edge, including how the project compliments/overlaps with existing projects, and potential ways to harmonize over time. Responses may be included both here and/or in accompanying documentation. | Open Horizon (OH) is incorporating EdgeLake. As OH is deploying and orchestrating software at the edge (from a single point), and AnyLog manages and queries data from the distributed edge - for many projects - OH + EdgeLake replace the need in the cloud and for all other use cases lowers cloud dependency, and automates data management at the edge. Projects EdgeX Foundry, Akraino, Hyperledger, are interested in integration with EdgeLake. AnyLog brings all these projects together: EdgeX Foundry serves the data to AnyLog Nodes (rather than cloud nodes) and a project like Smart-Transactions in Akraino queries Edge Data (as if the data is centralized), whereas data remains in-place. The blockchain is a key component in EdgeLake and Hyperledger is interested in providing the blockchain functionality. |
Link to current Code of Conduct | We will adopt LF Edge's Code of Conduct. |
2 TAC Sponsors, if identified (Sponsors help mentor projects) - See full definition on Project Stages: Definitions and Expectations | Joe Pearson (Open Horizon) |
Project license | |
Source control (GitHub by default) | https://github.com/EdgeLake - Being used in Open-Horizon, currently private, will make public as requested in the process. |
Issue tracker (GitHub by default) | |
External dependencies (including licenses) | |
Release methodology and mechanics | GitHub Releases |
Names of initial committers, if different from those submitting proposal | Moshe Shadmon, Mark Davidson, Faisal Nawab |
| Current number of code contributors to proposed project | 4 |
| Current number of organizations contributing to proposed project | 21 |
| Briefly describe the project's leadership team and decision-making process | EdgeLake is incubating under involved in Open Horizon, it -Horizon features request subgroup and has been following their Technical Charter. |
| List of project's official communication channels (slack, irc, mailing lists) | Slack & mailing lists |
| Link to project's website | In construction |
Links to social media accounts | In construction |
| Existing financial sponsorship | AnyLog |
| Infrastructure needs or requests (to include GitHub/Gerrit, CI/CD, Jenkins, Nexus, JIRA, other ...) | EdgeLake needs a place to host its community supported plugins. Access to development/test hardware to support other architectures (RISC-V). |
| Currently Supported Architecture | x86/64, ARM |
| Planned Architecture Support | Generic |
| Project logo in svg format (see https://github.com/lf-edge/lfedge-landscape#logos for guidelines) | TBD |
| Trademark status | Trademark will need to be pursed by the Linux Foundation upon project proposal acceptance |
| Does the project have a Core Infrastructure Initiative security best practices badge? (See: https://bestpractices.coreinfrastructure.org) | No |
| Any additional information the TAC and Board should take into consideration when reviewing your proposal? | EdgeLake is an incubation project under Open Horizon and is ready to become its own standalone member project under LF Edge. |
...
Deployment & Industry Verticals (✔ or X; Add context as needed)
Directly applicable Industry/Verticals use cases | (✔ or X; Add context as needed) |
|---|---|
| Automotive / Connected Car | ✔ |
| Chemicals | ✔ |
| Facilities / Building automation | ✔ |
| Consumer | ✔ |
| Manufacturing | ✔ |
| Metal & Mining | ✔ |
| Oil & Gas | ✔ |
| Pharma | ✔ |
| Health Care | ✔ |
| Power & Utilities | ✔ |
| Pulp & Paper | ✔ |
| Telco Operators | ✔ |
| Telco/Communications Service Provider (Network Equipment Provider) | ✔ |
| Transportation (asset tracking) | ✔ |
| Supply Chain | ✔ |
| Preventative Maintenance | ✔ |
| Water Utilities | ✔ |
| Security / Surveillance | ✔ |
| Retail / Commerce (physical point of sale with customers) | ✔ |
| Other - Please add if not listed above (please notify TAC-subgroup@lists.lfedge.org when you add one) |
Deployments (static v dynamic, connectivity, physical placement) - (✔ or X; Add context as needed)
Use Cases | (✔ or X; Add context as needed) |
|---|---|
| Gateways (to Cloud, to other placements) | ✔ |
| NFV Infrastructure | ✔ |
| Stationary during their entire usable life / Fixed placement edge constellations / Assume you always have connectivity and you don't need to store & forward. | ✔ |
| Stationary during active periods, but nomadic between activations (e.g., fixed access) / Not always assumed to have connectivity. Don't expect to store & forward. | ✔ |
| Mobile within a constrained and well-defined space (e.g., in a factory) / Expect to have intermittent connectivity and store & forward. | ✔ |
| Fully mobile (To include: Wearables and Connected Vehicles) / Bursts of connectivity and always store & forward. | ✔ |
...