OK, I get that argument. But consider that multiple subscriptions all using a 
single 
deployment spec was the previous model, and now we have inverted that 
cardinality 
completely.

To my knowledge, in addition to the generic automation of single cartridge 
subscriptions we provided our Stratos users, at least two users have 
significant 
investment in dynamically generating and subscribing/unsubscribing cartridges 
on-
the-fly. Converting these to use single application cartridges is necessary 
work needed 
to get to 4.1, but all these usages will now require substantive rework to 
manage the 
opposite cardinality w.r.t. deployment policies.

I'm all in favour of progress, and change where unavoidable, but this seems to 
gratuitously change the model for the bulk of singleton cartridge users in 
favour of the 
currently non-existent grouping users. (And yes, I am aware of the paradox that 
we 
are VERY interested in the grouping).




On Wednesday 11 February 2015 00:32:31 Udara Liyanage wrote:


An application definition defines cartridges and dependencies among the 
cartridges, 
and few other stuff such as autoscaling etc. Deployment policy defines how to 
deploy 
an application. Ideally application is defined once, but it should be able to 
deploy 
differently by using different deployment policy.Let's consider a use case. A 
user can 
define an php-mysql application. Then it should be able to deploy in single 
region, or 
across regions etc by using different deployment policies.
On 10 Feb 2015 23:46, "Shaheedur Haque (shahhaqu)" <shahh...@cisco.com[1]> 
wrote:


Hi,
 
I am just looking at the new group/application mode, for 4.1, and I noticed 
that the 
subscribablesInfo no longer contains a deploymentPolicy. For example, from [1]:
 
“applicationId: “*single_group_v1*”,
…
    "subscribableInfo": {
        "alias": "tom2group6",
        "autoscalingPolicy": "autoscale-policy-1",
        "artifactRepository":{
        …
        }
    }
Instead, what seems to have happened is that the deployment policy point back 
to 
the application, from [2]:
 
"applicationId": "*single_group_v1*",
"applicationPolicy": {
"networkPartition": [
This is surely backwards. Why do deployment policies name the application? Why 
can’t 
a single deployment policy be referenced by multiple applications (just like 
before)?
 
Also, what is confusing is that the samples are themselves inconsistent. For 
example, 
the first one I looked at [3] seems to be missing *any* binding between the 
application .json and the deployment .json; are these samples actually supposed 
to 
work, or are they perhaps a work in progress only?
 
Any insights would be most welcome.
 
Thanks, Shaheed
 
[1] 
https://github.com/apache/stratos/blob/master/samples/applications/single-group-v1/artifacts/application.json[2]
[2] 
https://github.com/apache/stratos/blob/master/samples/applications/single-group-v1/artifacts/openstack/deployment-policy.json[3]
[3] 
https://github.com/apache/stratos/tree/master/samples/applications/single-cartridge/artifacts[4]
 
  



--------
[1] mailto:shahh...@cisco.com
[2] 
https://github.com/apache/stratos/blob/master/samples/applications/single-group-v1/artifacts/application.json
[3] 
https://github.com/apache/stratos/blob/master/samples/applications/single-group-v1/artifacts/openstack/deployment-policy.json
[4] 
https://github.com/apache/stratos/tree/master/samples/applications/single-cartridge/artifacts

Reply via email to