Having problems with your account or logging in?
A lot of changes are happening in the community right now. Some may affect you. READ MORE HERE

configure pause subscription at catalog or offering level

configure pause subscription at catalog or offering level

•Brief Description
configure pause subscription at catalog or offering level
•Benefits / Value
this allows different models of acting towards failures in different Designs/offerings.
organizations are not right level to define pausing. if a subscription should be right away failing or should be fixed by an operator is usually to be decided based on the Design and what it is good for.
currently it is impossible to allow designs to fail when you have other offerings/designs that must be handled by pausing
•Design details
Move/add a function at minimum at catalog level that defines if subcriptions will pause or fail.
probably catalog is the right level between micromanagement and flexibility.
although at catalog level might grow the amount of catalogs exponentialy taking the matrix of different settings into account(permissions, potentially notifications, approval policies)
based on the growing amount of potential settings it might be a better way to set all at offering level.
there is anyway a lot that needs to be configured at offering
maybe it is good to make a standard set of Configurations for a CSA instance for newly created offerings
this would allow an CSA admin to sepcify best match for most new offering cases

5 Comments
Micro Focus Contributor
Micro Focus Contributor

I fully agree and acknowledge that failure hanlding configuration should not be made at the organization level, as how a failure should be handled will depend on the implementation of the service design and can vary from one service design to another which has no relation to where from (catalog or oragzation) that service is being consumed. 

From that perspective, would it make more sense to allow this configuration at the service design level, so that all the offerings created from that service design inherits that behavior and not require this to be configured per offering (a lot of times multiple offerings are created from a service design)? When we "revisit" this we want to do it the right way :-)

Also agree that there are a lot of configuration that can be offered at the service offering level for more flexibility, to name a few, default or allowed ownership type, e.g. user owned or group owned, default or allowed subscription lease type, e.g. recurring or periodic etc. These type of settings should be allowed at the service offering level.

Regards,

Nivedita

 

 

Account_Closed
Not applicable
 
Michael_it Honored Contributor.
Honored Contributor.

@nivghoshI agree that the decission on how failure handling should be done is in 99% of the cases based on the Design. Currently i can not think about any usecase of us where this would not work.

Another Thought around the same topic: in small CSA you probably have just one OPs team.

But larger CSA instances you will have multiple Teams taking care for different Usecases/Designs or even on Offering Level ... eg. Design A -> Offering 1 is for Customer 1 and supported by Team 1 but Design A -> Offering 2 is for Customer 2 and supported by Team 2.

this implies that not one Support team is sufficent any more on Org level but best would be on Offering Level.

a model similar to the different Roles in the MPP would be needed here... split down the Service Operator Role on Provider Side into different Service Operator Teams authorized by LDAP being responsible for a set of Offerings.

Using a catalog is probably not good as with Customer Admin Role customers can sort offerings them self into catalogs interfering with Operations Model

ill add an extra Idea  for this

Micro Focus Contributor
Micro Focus Contributor

@Michael_it  Michael, I see what you are saying about multiple operator teams for large deployment.

When I see the Pause on Failure configuration, I would split that configuration in two parts - 1) whether provisioning should be paused when it fails (I think this decision depends largely on the specific service design, in the sense if the designe was implemented in a way that it could be paused and resumed) and 2) if pause on failure is turned on, then who are the people who should be notified (I think this part of the configuration will depend on who are the operators. Whether a single operator team or multiple operator teams involved, when a service instance is paused due to failure, if the configuration says that the operator team should be notified, then the notification should be sent to the "corresponding" operators - could be just one operation team or a specific operator team (when we have such role defined).

So, in that case whether an instance should be paused on failure should be configured at the service design level and who should get notified should be configured at Operator team(s) level and when there would be multiple operator team, then assignment of operators probably can be done at the Org / Catalog / Offering level depending on what suits the best for particular customer's model.

 

regards,

Nivedita

Michael_it Honored Contributor.
Honored Contributor.

Hi Nivedita, that makes total sense. i totally support this 

Michael

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.