Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce "managed" object for all openwhisk entities #633

Closed
pritidesai opened this issue Oct 27, 2017 · 3 comments
Closed

Introduce "managed" object for all openwhisk entities #633

pritidesai opened this issue Oct 27, 2017 · 3 comments

Comments

@pritidesai
Copy link
Member

pritidesai commented Oct 27, 2017

We would like to start distinguishing managed vs unmanaged deployments to ease management of deployed whisk entities. The idea is to create openwhisk entities annotated with a project name. These entities could be created with a single deployment or many different deployments. When it comes to clean up, all the entities annotated with the same project name can be deleted. This can also help listing entities which belong to one particular project.

Introduce a new object managed at the project level with name as a single entity for now, this will be extended to have more than just this one entity:

project:
    managed:
        name: <managed project name>

Add this new object as a annotation to every entities in manifest/deployment file.

@mrutkows @lionelvillard please correct me if I am wrong or have incorrect explanation here.

@mrutkows
Copy link
Contributor

@pritidesai actually, there would be no "managed" keyword anywhere in the YAML; instead a "managed" object would appear in the annotations of OpenWhisk entities (that are managed / tracked at the server-side). This would mean, as part of this issue/design, that we would propose the structure of this object and a reserved set of keynames to use within the annotation. This annotation would automatically be appended by tooling (and perhaps stripped on export/creation of a new manifest). There may need to be a command line option to enable this feature (and/or preserve/sync/update the "managed" object annotation in the saved client-side YAML.

@mrutkows
Copy link
Contributor

@pritidesai allow me to upload today the 0.9.0 spec which has placeholders for some of the underlying use cases that are driving this feature (mainly using wskdeploy from IDEs).

@pritidesai
Copy link
Member Author

pritidesai commented Nov 3, 2017

Deployments are classified into two categories: managed and unmanaged

Managed Deployments:

Managed deployment are the ones when OpenWhisk entities are deployed using wskdeploy with command line flag --managed. This will result in a hidden annotation in every OpenWhisk entity in manifest file. OpenWhisk entities are annotated with Project Name and therefore Project Name in manifest file is mandatory for managed deployments:

project:
    name: MyProject
    packages:
        package1:
            ....

Every OpenWhisk entity in the manifest file will be annotated with:

managed:
    __OW__PROJECT__NAME: MyProject
    __OW__PROJECT_HASH: SHA1("OpenWhisk " + <size_of_manifest_file> + "\0" + <contents_of_manifest_file>)
    __OW__FILE: Absolute path of manifest file on file system

Where the text OpenWhisk is a constant prefix and \0 is also constant and is the NULL character. The <size_of_manifest_file> and <contents_of_manifest_file> vary depending on the file.

Managed deployments will also generate a separate manifest YAML file with all these hidden annotations in every OpenWhisk entities.

Now, subsequent deployment (wskdeploy --managed) of the same project minus few OpenWhisk entities from the manifest file will result in undeployment of those deleted entities.

OpenWhisk entities which are deployed using some other tool or automation and also appearing in the manifest file will left unmodified. Such entities are classified as external entities and will not be overwritten.

Undeployment of such project can be driven with wskdeploy without any manifest/deployment file but only specifying project and SHA1.

[UPDATE] Undeployment of such project can be driven with wskdeploy with manifest file only specifying the project name.

project:
    name: MyProject

Unmanaged Deployments:

Unmanaged deployments are done without specifying --managed flag or done outside of wskdeploy.

Questions:

  1. What is the purpose of annotating entities with SHA1? Hash will change when a manifest file changes. How can we trace back entities belonging to the same project using SHA1? What value does this hash add to deployment/undeployment?

  2. What is the use of client side manifest YAML file?

  3. Can undeployment of managed deployments be done without SHA1?

References:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants