This content has been marked as final. Show 4 replies
This is an excellent suggestion, certainly one that I agree with. Part of the problem with providing a template with a pre-existing report node is that the database would need to contain an entries that represent the locations of the report node. ip addresses cause problems because they only become known at VM initialisation time and not at template construction time. For example, the Integration Gateway runs on the same VM as PIA. PIA is the last VM to be initialized after the DB and AppBatch VMs. This means that the DB would not be aware of PIA at its initialisation time.
The only practical way to get around this that I can think of is to add a question to the AppBatch VM first-boot initialization process. This would prompt the user for these ip / hostname-specific concepts and then use these to insert content into the database that would represent these node characteristics.
Please share any additional thoughts that you may have on how this could be achieved.
I'm not sure if prompted for the report repository on the App/Batch server initialization would be the best way. I'm maybe wrong, but it could be some people who wants only the App/Batch VM, but not the other VM images, especially the db (which could be done separately) ? It is also a possibility, isn't it ?
Since it is more a database side update dependent, I was rather thinking about this question during the first boot of the database image. Of course, that will require to know the references (ip) of a non yet configured App/Batch and PIA VMs, but this is something we have to know internally anyway (I mean, on customer side, when setting/starting for all the VMs images we have to know the reserved range of ip address we will give to the images).
We could even think about an update of the +/etc/hosts+ file during the first boot of every VM regarding the two others images to be known from each others (interesting between App/Batch and PIA servers).
I agree with you. I don't like the idea of the prompt at all. Bottom line is that there is prior knowledge required about other VMs that may not yet be present in the environment. Tightening the coupling between the VMs only makes sense if the majority of users want that functionality to be immediately available out of the box.
I think that that it is nice that the templates have a sense of independence to them but with that comes the need for additional post-installation steps by the user.