For a reactive fastmap (RFM) based service, a service instance is only “completely” created after multiple iterations of the create callback. What you see is normal expected behavior. Read on for why, and what you can do about it.
Reactive Fastmap
With a simple resource allocation reactive fastmap, the service create callback is putting a request record somewhere into the CDB. You might see this request in the dry-run output. It then tries to read the response value from that record, and if it's empty, exits the service. If it's not blank, it continues to apply templates. The first time your service is deployed, this will always be blank. Therefore, no device/service configuration to output.
Once you commit without dry run, this request is actually placed into the CDB. We assume there is a CDB subscriber that is listening for the request. The subscriber receives the request, calls the external system/resource allocator, and then responds back by placing a response back in the CDB – typically this would be in a sub-element of the initial request record. Once the external system/allocator has completed its job, your service needs to be redeployed. Typically the subscriber that put the response back initiates the re-deploy. Or Kicker could be waiting for the response in the initial request to get filled, and initiate the redeploy. In this re-deploy, device/service configuration is made.
To allow for debugging:
When you need to debug the redeploy, disable your Subscriber, so that you can do your own manual redeploy of your service with commit dry-run. You may again see the request the output, but your reactive fastmap code should also proceed to the next phase - generating device/service config.
If you need to see the output without disabling the Subscribers you have a few options:
Option 1 - Activate after resource allocation
Allow the reactive fastmap to continue allocating the parameters, but do not apply the service configuration templates. Some time later, you can dry-run the "activate" of the service, showing the full device configs and parameters, and make a decision about the full commit.
You could do this by adding a flag to the service model:
leaf active {
type empty;
}When active is not set, you make all allocations via reactive fastmap as normal, BUT skip applying the device templates.
You first instantiate the service without active:
# svc-foo XXX YYY
# commit
After a short wait, all allocations should be made, and it's possible to do:
# svc-foo active true
# commit dry-run
Here you will see the result of the device templates being activated, with their RFM populated values.
Option 2 - Output with dummy values
You could allow the end user to "fake" the resource allocation stage, and skip to the device template phase, outputting a representative, but not quite real config. Please note: This is dangerous as you could end up pushing dummy values to devices.
Add a flag to the service model:
leaf dummy {
type empty;
}When dummy is not set, you make all allocations as normal (e.g. using the ID and or IP allocator), and as normal exit before applying the device templates.
However, when dummy is set to any value, in your code where you normally exit if you don't read values from the request, set some dummy values. (Please note: this means that if you are running this command for a deployed service, AFTER reactive fastmap has populated the values, despite the dummy flag it will use the RFM populated values - this protects your user from doing something by mistake, and breaking running network config by pushing dummy values. With this approach, there is no simple way to see both dummy output, and for you to stop dummy config getting pushed).
You first instantiate the service with dummy
# svc-foo XXX YYY dummy true
# commit dry-run
Here you will see the result of the device templates being activated with your dummy values.
Option 3 - Non RFM - Expert Workaround (CAUTION ADVISED!)
You can request external resources before the CDB lock is granted, allowing for a NON-reactive fastmap service. The callback for this pre-lock code is ServiceCBType.PRE_LOCK_CREATE (Java).
In this callback you could write synchronous code that blocks on assigning these values, before the time critical CDB lock is acquired. Note: with reactive fastmap, during a commit dry-run, or a failure, no resources are allocated. Using this suggested method, resources are always allocated, even for commit dry-run, failures, etc. You would need to write code to handle the de-allocation and clean up for error scenarios. This makes this option very unattractive.
This model should only be used if the resources allocated are never expected to change between requests, and ideally if you only ever need to make the call once. This is really only practical if the system that you are calling is always going to return the same value for your reservation request:
> Request: RD/RT for Customer A, site 1
-> RT = <CustA-Site1>, RD = <CustA-Site1>
> Request: RD/RT for Customer A, site 1 (again)
-> RT = <CustA-Site1>, RD = <CustA-Site1>
If, however, you are doing something like the below, you really should use the reactive FASTMAP method:
> Request: RD/RT for Customer A, site 1
-> RT = 61000:1000001, RD = 61000:1000001
> Request: RD/RT for Customer A, site 1 (again)
-> RT = 61000:1000002, RD = 61000:1000002
> Request: RD/RT for Customer A, site 1 (again)
-> RT = 61000:1000003, RD = 61000:1000003
