[GitHub] lionelvillard commented on issue #730: Multiple projects management
lionelvillard commented on issue #730: Multiple projects management URL: https://github.com/apache/incubator-openwhisk-wskdeploy/issues/730#issuecomment-365343069 @davidbreitgand in this model, there is only one project: ``` P --> A --> B |-> C --> B ``` then it's up to wskdeploy to factor out B. When both A and C instantiates B with the same parameters, then all is fine. Otherwise wskdeploy can reject or decide to deploy B is two different packages (when there is no dynamic bindings) or two different namespaces (wskdeploy automatically handles authentication). As for `wsk action update b`, I suppose you also mean the user will then use `export`. In that case the expected behavior is to update the action in the manifest B. However as you said, the OW data model does not support dependencies so in order to propagate changes to A and C (like for instance if a parameter on b is defined in A) additional annotations must be added to encode such dependencies. To be clear: I'm not against adding the `managedList` annotation, I'm just trying to contrast this approach with the `dependencies` approach. It seems to me that in order to let wskdeploy managing dependencies we will need more than the `managedList` annotation. 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: us...@infra.apache.org With regards, Apache Git Services
[GitHub] lionelvillard commented on issue #730: Multiple projects management
lionelvillard commented on issue #730: Multiple projects management URL: https://github.com/apache/incubator-openwhisk-wskdeploy/issues/730#issuecomment-365304303 The idea of the explicit dependencies approach is to have only one project which include all your dependencies. Only one project needs to be deployed (and wskdeploy can compute an optimal deployment plan). Going back to the multiple projects management issue (in which dependencies are not explicitly specified and instead managed outside of wskdeploy), here I currently think what could go wrong and things to be aware of: - if asset a in Project A and asset b in Project B have the same name but not identical (different code, parameters, etc...) then in general b cannot be deployed, otherwise it would break A. - consequently: if the purpose of B is to extends A (e.g. adding new actions to a package P), then both package descriptions P in A and B must be identical (same parameters, annotations, ...). - comparing feeds for equality required adding additional annotations to store feed parameters. - comparing APIs should probably be done by comparing swagger specifications Bottom line: - By default, deployment should fail when assets of the same name are different. A flag could be provided to override this behavior - Asset equality must be formally defined to support the default behavior above. 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: us...@infra.apache.org With regards, Apache Git Services
[GitHub] lionelvillard commented on issue #730: Multiple projects management
lionelvillard commented on issue #730: Multiple projects management URL: https://github.com/apache/incubator-openwhisk-wskdeploy/issues/730#issuecomment-365022690 Are your projects statically dependent to each other or not? If yes, then `dependencies` might solve your problem by putting the common assets into a "library manifest". Otherwise can you deploy each project to their own namespace? 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: us...@infra.apache.org With regards, Apache Git Services
