I’ve been thinking about the behavior wrt topology generation when the URL(s) for a service declared in a simple descriptor cannot be correctly/completely determined.
The options available include: 1. Abort the topology generation because we can’t produce what has been requested. 2. Complete the topology generation without those services whose URL(s) could not be determined. The unresolved services could be omitted or commented-out in the resulting topology file. 3. Complete the topology generation, allowing the descriptor deployer the opportunity to “fill in the blanks” This will result in Knox deploying a topology it knows to be incorrect. API deployments may not afford the deployer the opportunity to “fill in the blanks” (e.g., Ambari-driven deployments). My initial feeling on this is that we should not produce anything less than what the descriptor declares (i.e., #1). After all, the declared services are in the descriptor precisely because someone wants to access them through Knox. I could possibly be persuaded that producing a partial topology (i.e., #2) may be acceptable, but it’s still not what the descriptor author intends/requires. I don’t believe Knox should ever produce or deploy a topology it knows to be incorrect (i.e., #3). One example, which came up during the review of KNOX-1014, is HIVE; If the hiveserver2 component is not configured for HTTP transport, then there is no valid URL for that service, as far as Knox is concerned. In this case, I think we must abort the topology generation or omit the HIVE service from the generated topology. Interested in your thoughts… -- Phil
