You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by Udara Liyanage <ud...@wso2.com> on 2014/11/20 03:16:17 UTC
Re: [grouping][question] cartrdige type in dependency definition
Hi Martin,
Creating another cartridge type is just changing the type parameter of the
existing cartridge json if you are using the base image approach and
deploying the new json.
If the requirement is only the easiness in testing, I don't think
implementing this feasibility is necessary given that we are in a tight
schedule. However if there is a real world use case I am OK.
Touched, not typed. Erroneous words are a feature, not a typo.
Re: [grouping][question] cartrdige type in dependency definition
Posted by Lakmal Warusawithana <la...@wso2.com>.
Shall we introduce tags into cartridges. This may useful in versioning as
well.
On Thu, Nov 20, 2014 at 11:40 PM, Martin Eppel (meppel) <me...@cisco.com>
wrote:
> I think this might not cover the use cases and we still need to support
> dependencies of same type cartridges in service groups. I wonder if we can
> extend the dependency description model and add an extra parameter which
> allows us to refer to instance of same type cartridges:
>
>
>
>
>
> {
>
> "name": "group5",
>
> "subGroups": [
>
> ],
>
> "cartridges": [
>
> "c1.1", "c1.2", "c3", “c4”
>
> ],
>
> "dependencies": {
>
> "startupOrders": [
>
> "cartridge.c3,cartridge.c1.1”,
>
> "cartridge.c4,cartridge.c1.2”,
>
> ],
>
> "terminationBehaviour": "terminate-dependents"
>
> }
>
> }
>
>
>
>
>
> with cartridge cartridge.c1.1 and cartridge.c1.2 using different
> subscription parameters (like deployment policy, etc ).
>
>
>
> In this configuration, c3 and c4 will start up in parallel and an instance
> of c1 cartridge will start up once c3 is active and respectively when c4
> becomes active.
>
>
>
> WDYT ?
>
>
>
> Thanks
>
>
>
> Martin
>
>
>
> *From:* isuruh@wso2.com [mailto:isuruh@wso2.com] *On Behalf Of *Isuru
> Haththotuwa
> *Sent:* Wednesday, November 19, 2014 9:15 PM
>
> *To:* dev
> *Subject:* Re: [grouping][question] cartrdige type in dependency
> definition
>
>
>
> Hi Martin,
>
> In a Service Group, we do not have runtime data, as aliases and other
> relevant subscription data are provided in the application deployment.
>
> If you need to start two instances of the same cartridge type, what you
> can do is to put them in the application itself without using a group, and
> then specify the startup order using cartridge aliases:
>
> "startupOrders": [
>
> "cartridge.*<alias1>*, cartridge.*<alias2>*, cartridge.
> *<alias3>*"
>
> ],
>
> all the aliases refer to the same cartridge type.
>
>
>
> On Thu, Nov 20, 2014 at 9:35 AM, Martin Eppel (meppel) <me...@cisco.com>
> wrote:
>
> Hi Udara,
>
>
>
> Yes, I confirmed, there are real use cases where we have dependencies on
> the same cartridge type but different subscriptions, one is an example of
> active / standby scenario another one a scenario to patch / upgrade the
> system.
>
>
>
> Quoting the response below:
>
>
>
>
>
> ns-01 and ns-02 are instances of a network server cluster. Strictly
> speaking they belong to the same cluster so having both be the same
> cartridge type makes sense. Making them different cartridge types seems
> wrong. We really only need either ns-01 or ns-02 to be up in order to
> declare the cluster as available and I can't see how we do that if we use
> different cartridge types.
>
> One of the original use cases was to use grouping to represent a cluster.
> One use cases might involve have multiple subscriptions representing
> collectively a cluster, so each having the same cartridge type would be
> useful. Each subscription in this case would have one or more instances.
> For example, if we want to represent a cluster with a subscription a. At
> some point later, we might want to add a subscription b to the group which
> point to a different version of code (likely a patched version) and remove
> subscription a after we've deploy and verified subscription b. I imagine
> doing this by revising a group with additional subscriptions with the same
> cartridge type.
>
> I believe Matt has a similar requirement where one VM is in active state
> and the other is in standby.
>
>
>
>
>
>
>
> *From:* Martin Eppel (meppel)
> *Sent:* Wednesday, November 19, 2014 6:21 PM
> *To:* dev@stratos.apache.org
> *Subject:* RE: [grouping][question] cartrdige type in dependency
> definition
>
>
>
> Hi Udara,
>
>
>
> No problem, I was just wondering if it is supported or not.
>
>
>
> On the other hand we might have a real use case, let me follow up on this
>
>
>
> Thanks
>
>
>
> Martin
>
>
>
> *From:* Udara Liyanage [mailto:udara@wso2.com <ud...@wso2.com>]
> *Sent:* Wednesday, November 19, 2014 6:16 PM
> *To:* dev
> *Subject:* Re: [grouping][question] cartrdige type in dependency
> definition
>
>
>
> Hi Martin,
>
> Creating another cartridge type is just changing the type parameter of the
> existing cartridge json if you are using the base image approach and
> deploying the new json.
>
> If the requirement is only the easiness in testing, I don't think
> implementing this feasibility is necessary given that we are in a tight
> schedule. However if there is a real world use case I am OK.
>
> Touched, not typed. Erroneous words are a feature, not a typo.
>
> --
>
> Thanks and Regards,
>
> Isuru H.
>
> +94 716 358 048
>
>
>
>
--
Lakmal Warusawithana
Vice President, Apache Stratos
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/
RE: [grouping][question] cartrdige type in dependency definition
Posted by "Martin Eppel (meppel)" <me...@cisco.com>.
I think this might not cover the use cases and we still need to support dependencies of same type cartridges in service groups. I wonder if we can extend the dependency description model and add an extra parameter which allows us to refer to instance of same type cartridges:
{
"name": "group5",
"subGroups": [
],
"cartridges": [
"c1.1", "c1.2", "c3", “c4”
],
"dependencies": {
"startupOrders": [
"cartridge.c3,cartridge.c1.1”,
"cartridge.c4,cartridge.c1.2”,
],
"terminationBehaviour": "terminate-dependents"
}
}
with cartridge cartridge.c1.1 and cartridge.c1.2 using different subscription parameters (like deployment policy, etc ).
In this configuration, c3 and c4 will start up in parallel and an instance of c1 cartridge will start up once c3 is active and respectively when c4 becomes active.
WDYT ?
Thanks
Martin
From: isuruh@wso2.com [mailto:isuruh@wso2.com] On Behalf Of Isuru Haththotuwa
Sent: Wednesday, November 19, 2014 9:15 PM
To: dev
Subject: Re: [grouping][question] cartrdige type in dependency definition
Hi Martin,
In a Service Group, we do not have runtime data, as aliases and other relevant subscription data are provided in the application deployment.
If you need to start two instances of the same cartridge type, what you can do is to put them in the application itself without using a group, and then specify the startup order using cartridge aliases:
"startupOrders": [
"cartridge.<alias1>, cartridge.<alias2>, cartridge.<alias3>"
],
all the aliases refer to the same cartridge type.
On Thu, Nov 20, 2014 at 9:35 AM, Martin Eppel (meppel) <me...@cisco.com>> wrote:
Hi Udara,
Yes, I confirmed, there are real use cases where we have dependencies on the same cartridge type but different subscriptions, one is an example of active / standby scenario another one a scenario to patch / upgrade the system.
Quoting the response below:
ns-01 and ns-02 are instances of a network server cluster. Strictly speaking they belong to the same cluster so having both be the same cartridge type makes sense. Making them different cartridge types seems wrong. We really only need either ns-01 or ns-02 to be up in order to declare the cluster as available and I can't see how we do that if we use different cartridge types.
One of the original use cases was to use grouping to represent a cluster. One use cases might involve have multiple subscriptions representing collectively a cluster, so each having the same cartridge type would be useful. Each subscription in this case would have one or more instances. For example, if we want to represent a cluster with a subscription a. At some point later, we might want to add a subscription b to the group which point to a different version of code (likely a patched version) and remove subscription a after we've deploy and verified subscription b. I imagine doing this by revising a group with additional subscriptions with the same cartridge type.
I believe Matt has a similar requirement where one VM is in active state and the other is in standby.
From: Martin Eppel (meppel)
Sent: Wednesday, November 19, 2014 6:21 PM
To: dev@stratos.apache.org<ma...@stratos.apache.org>
Subject: RE: [grouping][question] cartrdige type in dependency definition
Hi Udara,
No problem, I was just wondering if it is supported or not.
On the other hand we might have a real use case, let me follow up on this
Thanks
Martin
From: Udara Liyanage [mailto:udara@wso2.com]
Sent: Wednesday, November 19, 2014 6:16 PM
To: dev
Subject: Re: [grouping][question] cartrdige type in dependency definition
Hi Martin,
Creating another cartridge type is just changing the type parameter of the existing cartridge json if you are using the base image approach and deploying the new json.
If the requirement is only the easiness in testing, I don't think implementing this feasibility is necessary given that we are in a tight schedule. However if there is a real world use case I am OK.
Touched, not typed. Erroneous words are a feature, not a typo.
--
Thanks and Regards,
Isuru H.
+94 716 358 048
Re: [grouping][question] cartrdige type in dependency definition
Posted by Isuru Haththotuwa <is...@apache.org>.
Hi Martin,
In a Service Group, we do not have runtime data, as aliases and other
relevant subscription data are provided in the application deployment.
If you need to start two instances of the same cartridge type, what you can
do is to put them in the application itself without using a group, and then
specify the startup order using cartridge aliases:
"startupOrders": [
"cartridge.*<alias1>*, cartridge.*<alias2>*, cartridge.
*<alias3>*"
],
all the aliases refer to the same cartridge type.
On Thu, Nov 20, 2014 at 9:35 AM, Martin Eppel (meppel) <me...@cisco.com>
wrote:
> Hi Udara,
>
>
>
> Yes, I confirmed, there are real use cases where we have dependencies on
> the same cartridge type but different subscriptions, one is an example of
> active / standby scenario another one a scenario to patch / upgrade the
> system.
>
>
>
> Quoting the response below:
>
>
>
>
>
> ns-01 and ns-02 are instances of a network server cluster. Strictly
> speaking they belong to the same cluster so having both be the same
> cartridge type makes sense. Making them different cartridge types seems
> wrong. We really only need either ns-01 or ns-02 to be up in order to
> declare the cluster as available and I can't see how we do that if we use
> different cartridge types.
>
> One of the original use cases was to use grouping to represent a cluster.
> One use cases might involve have multiple subscriptions representing
> collectively a cluster, so each having the same cartridge type would be
> useful. Each subscription in this case would have one or more instances.
> For example, if we want to represent a cluster with a subscription a. At
> some point later, we might want to add a subscription b to the group which
> point to a different version of code (likely a patched version) and remove
> subscription a after we've deploy and verified subscription b. I imagine
> doing this by revising a group with additional subscriptions with the same
> cartridge type.
>
> I believe Matt has a similar requirement where one VM is in active state
> and the other is in standby.
>
>
>
>
>
>
>
> *From:* Martin Eppel (meppel)
> *Sent:* Wednesday, November 19, 2014 6:21 PM
> *To:* dev@stratos.apache.org
> *Subject:* RE: [grouping][question] cartrdige type in dependency
> definition
>
>
>
> Hi Udara,
>
>
>
> No problem, I was just wondering if it is supported or not.
>
>
>
> On the other hand we might have a real use case, let me follow up on this
>
>
>
> Thanks
>
>
>
> Martin
>
>
>
> *From:* Udara Liyanage [mailto:udara@wso2.com <ud...@wso2.com>]
> *Sent:* Wednesday, November 19, 2014 6:16 PM
> *To:* dev
> *Subject:* Re: [grouping][question] cartrdige type in dependency
> definition
>
>
>
> Hi Martin,
>
> Creating another cartridge type is just changing the type parameter of the
> existing cartridge json if you are using the base image approach and
> deploying the new json.
>
> If the requirement is only the easiness in testing, I don't think
> implementing this feasibility is necessary given that we are in a tight
> schedule. However if there is a real world use case I am OK.
>
> Touched, not typed. Erroneous words are a feature, not a typo.
>
> --
> Thanks and Regards,
>
> Isuru H.
> +94 716 358 048* <http://wso2.com/>*
>
>
> * <http://wso2.com/>*
>
>
>
RE: [grouping][question] cartrdige type in dependency definition
Posted by "Martin Eppel (meppel)" <me...@cisco.com>.
Hi Udara,
Yes, I confirmed, there are real use cases where we have dependencies on the same cartridge type but different subscriptions, one is an example of active / standby scenario another one a scenario to patch / upgrade the system.
Quoting the response below:
ns-01 and ns-02 are instances of a network server cluster. Strictly speaking they belong to the same cluster so having both be the same cartridge type makes sense. Making them different cartridge types seems wrong. We really only need either ns-01 or ns-02 to be up in order to declare the cluster as available and I can't see how we do that if we use different cartridge types.
One of the original use cases was to use grouping to represent a cluster. One use cases might involve have multiple subscriptions representing collectively a cluster, so each having the same cartridge type would be useful. Each subscription in this case would have one or more instances. For example, if we want to represent a cluster with a subscription a. At some point later, we might want to add a subscription b to the group which point to a different version of code (likely a patched version) and remove subscription a after we've deploy and verified subscription b. I imagine doing this by revising a group with additional subscriptions with the same cartridge type.
I believe Matt has a similar requirement where one VM is in active state and the other is in standby.
From: Martin Eppel (meppel)
Sent: Wednesday, November 19, 2014 6:21 PM
To: dev@stratos.apache.org
Subject: RE: [grouping][question] cartrdige type in dependency definition
Hi Udara,
No problem, I was just wondering if it is supported or not.
On the other hand we might have a real use case, let me follow up on this
Thanks
Martin
From: Udara Liyanage [mailto:udara@wso2.com]
Sent: Wednesday, November 19, 2014 6:16 PM
To: dev
Subject: Re: [grouping][question] cartrdige type in dependency definition
Hi Martin,
Creating another cartridge type is just changing the type parameter of the existing cartridge json if you are using the base image approach and deploying the new json.
If the requirement is only the easiness in testing, I don't think implementing this feasibility is necessary given that we are in a tight schedule. However if there is a real world use case I am OK.
Touched, not typed. Erroneous words are a feature, not a typo.
RE: [grouping][question] cartrdige type in dependency definition
Posted by "Martin Eppel (meppel)" <me...@cisco.com>.
Hi Udara,
No problem, I was just wondering if it is supported or not.
On the other hand we might have a real use case, let me follow up on this
Thanks
Martin
From: Udara Liyanage [mailto:udara@wso2.com]
Sent: Wednesday, November 19, 2014 6:16 PM
To: dev
Subject: Re: [grouping][question] cartrdige type in dependency definition
Hi Martin,
Creating another cartridge type is just changing the type parameter of the existing cartridge json if you are using the base image approach and deploying the new json.
If the requirement is only the easiness in testing, I don't think implementing this feasibility is necessary given that we are in a tight schedule. However if there is a real world use case I am OK.
Touched, not typed. Erroneous words are a feature, not a typo.