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
