Reputation: 3
TL;DR: Is there a way to dynamically set the parameters or resource policies for ServicePackageResourceGovernancePolicy
and/or ResourceGovernancePolicy
when we create a new instance of a certain ServiceType at runtime?
We have a use case to have dynamic resource government per service instance (not type).
So basically, we have a service type: VotingDataType.
So you describe the resource government in the ApplicationManifest
, taken from the docs here is an example:
<ApplicationManifest>
...
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName="VotingDataPkg" ServiceManifestVersion="1.0.0" />
...
<!-- Set resource governance at the service package level. -->
<ServicePackageResourceGovernancePolicy CpuCores="[CpuCores]" MemoryInMB="[Memory]"/>
<!-- Set resource governance at the code package level. -->
<ResourceGovernancePolicy CodePackageRef="Code" CpuPercent="10" MemoryInMB="[Memory]" BlockIOWeight="[BlockIOWeight]"
MaximumIOBandwidth="[MaximumIOBandwidth]" MaximumIOps="[MaximumIOps]" MemoryReservationInMB="[MemoryReservationInMB]"
MemorySwapInMB="[MemorySwapInMB]"/>
</Policies>
</ServiceManifestImport>
...
</ApplicationManifest
Now for every customer, my custom placement service will instantiate a new instance of the VotingDataType. However, by some meta data we get before we are about to instantiate a new instance, we decide if it needs a bigger instance to begin with. so instead of 10% CPU limit, we want a 20% CPU limit.
Our placement service will then use the following method to create a new instance of that VotingDataType service. fabricClient.ServiceManager.CreateServiceAsync(...)
. However, we're not able to customize the Parameters for the ResourceGovernancePolicy
.
Is there a way to dynamically set the parameters or resource policies for ServicePackageResourceGovernancePolicy
and/or ResourceGovernancePolicy
when we create a new instance of a certain ServiceType at runtime?
Upvotes: 0
Views: 320
Reputation: 11351
Application parameters are defined at Application Level, so the values are valid to all services inside the named application.
In your case, is suitable if you have one named application(instance) per tenant, even though they are the same AppType. This way you deploy once and create multiple services with different configuration or versions.
One app per tenant is also better, because you can update them individually, so each tenant can decide when they want to apply the update.
i.e:
ApplicationTypes
ApplicationType | Version
----------------------------
SalesAppType 1.0
SalesAppType 1.1
Applications (Named Applications)
Application | ApplicationType | Version
-------------------------------------------
Ten1-SalesApp SalesAppType 1.0
Ten2-SalesApp SalesAppType 1.0
Ten3-SalesApp SalesAppType 1.1
Upvotes: 1