On Fri, Oct 31, 2014 at 5:50 AM, Roshan Deniyage <[email protected]> wrote:
> Hi Devs, > Based on the previous discussion and decision, I'm in the process of > developing the improvement of the subject as follows, > > (1) Publish a new Event called "ArtifactDeploymentCompletedEvent" to the > "instance-notifier" topic of activemq of stratos side by each cartridge > agent upon successful git pull. > > (2) Register a listener to the same topic by appfactory and get the event. > > (3) Based on the data in the event update the runtime database of > appfactory. (last deployment status of the relevant application) > > To complete the above feature based on the logic mentioned, we need the > following data to be published by cartridge agent itself. > > (a) tenantdomain > (b) stage (cartridge knows this) > (c) applicationId > (d) applicationVersion > (e) artifactLastModifiedTime > > from above data presently only the (b) can be published by cartridge agent. > > In the S2 git repo the artifact are represented as separate folders of the > application for each version. (by appending the version info to the folder > name) > > Since the (a), (b) and (c) are static to single-tenant cartridge those can > be obtained if we provide those information with cartridge alias (as a > custom formatted string) or manipulating the git repo url. > Stratos Git repo is a good source of information. But I believe startos way of doing it is passing pay load parameters. Since this is more of a core thing (not specific to AF) +1 for passing payload parameters > > property (e) also can be obtained for each version-ed artifact folder. > > But, the main problem is getting the property (d). Actually we can get the > version info of all the artifacts by its name. But, in cartridge side there > is no way to get the updated artifact list. > > One possible solution for this problem is to send all the artifact names > with "lastmodifiedtime" from cartridge side and in appfactory side we can > update the database records which the "lastmodifiedtime" is greater than > the existing db records. > > Since, this would allow us to have different subscription types (per app, per version, per tenant) and our implementation would stay the same. So +1. thanks, dimuthu > > Any comment on this issue is appreciated. > > > Thanks, > Roshan Deniyage > Associate Technical Lead > WSO2, Inc: http://wso2.com > > Mobile : +94 777636406 > Twitter : *https://twitter.com/roshku <https://twitter.com/roshku>* > LinkedIn : https://www.linkedin.com/in/roshandeniyage > > -- Dimuthu Leelarathne Architect & Product Lead of App Factory WSO2, Inc. (http://wso2.com) email: [email protected] Mobile : 0773661935 Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
