kpavel opened a new pull request #804: Fix for 730 URL: https://github.com/apache/incubator-openwhisk-wskdeploy/pull/804 This PR extends wskdeploy with a capability to explicitly define relationships between projects and assets beyond single project. More specifically, it allows to express one (asset) to many (projects) relationships, which are useful in e.g., reusing assets managed by one project as “library assets” in multiple other projects. The design goals in this PR are: (a) to preserve current functionality of wskdeploy, (b) not to change current manifest structure, (c) avoid assets duplication among projects while having a single project, the project where an asset have been originally defined as managed, as a single point of truth for any reference to this asset made from other projects. Relationships of projects and assets are expressed via a new MANAGED_LIST annotation of an asset. This functionality is consumed by the user via a (-r) wskdeploy attribute. It receives a YAML file with a format similar to ordinary wskdeploy manifest.yaml or deployment.yaml manifest files. This PR gains: - an option to export only a subset of existing managed assets by specifying them in a relationships manifest file of another project, which will result in this project name to be added to the MANAGED_LIST annotation. The new project name can be used in calling wskdeploy for exporting assets of that new project. - assets reuse by different projects with central asset management by its own single MANAGER project - avoids unnecessary assets duplication Usage example: - 1) Deploy project A with a set of managed assets {a} - 2) Deploy project B with a different set of managed assets {b} - After steps 1 and 2, there will be a union of assets {a} and{b} in OW with MANAGED annotation pointing to the project managing the asset - 3) Deploy project C with the manifest containing nothing but the project name + a relationships manifest file pointing to assets from both {a} and {b} sets. - Step 3 results in no new assets creation, but rather adds a new entry to the MANAGED_LIST annotations array. In this case, C will be added as a project name to the MANAGED_LIST of the assets meaning that C uses these assets. - 4) Export project C. Notice that the manifest file created by the export operation comprisesboth assets from {a} and {b} without any reference to to the A and B projects. - 5) Undeploy project C. This results in no assets deletion, but rather removing of the relationship to project C from the assets MANAGED_LIST annotation. - 6) Undeployment of project A or B will result in complete removal of the {a} or {b} assets sets, although in the future we may consider adding an explicit --force flag to avoid undesired undeployments.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
