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: [email protected] 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:[email protected]] 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.
