In our Software factory, we are building on-demand test platforms running a standalone devtest/registry-broker-base image (VSE+ Registry).
These short-lived environments have no connectivity to EDashboard server, so the registry cannot connect at startup....
Problem is as follow: we have one DevTest license hosted in our EDashboard to share between our QA (Virtual Service authoring and Unit Test execution) and our automated regression platforms, which are dynamically provisioned by Continuous Delivery process and with limited connectivity.
Any idea to sort-out this problem ?
Missing something here - what do you mean - container has no connectivity to dashboard?
When you start the container for Reg+ VSE, you provide the info on the dashboard....
Yes we do , but we have a nomad platform configuration where there is no network connectivity with the dashboard.
So Ideally we would like to "record" the first conversation between Registry and EDd to fill the cache before Registry 1st startup ?
sadly, the client (registry+VSE) ip address will change, and thus become a new client. You could 'save' the one time config, but the client cannot change its IP address after that.. not very useful for an on demand farm of VSEs providing short term services.
my registry+VSE clients do not have dns entries in the corp dns server.. so are IP address based only
he must have network access to the EDb system. if not, the registry startup will fail the 1st time.
if he is doing these tests in an isolated lab, then he has no outward connectivity
another solution is to spin up another EDb inside the isolated lab, for the purpose of allowing the nomads to work.
use the same license key
the registry in your container MUST talk to the EDb at least once. there is a cache for subsequent connections.. it will expire at some time, I don't know what the timeout is myself (never paid attention)..
but to get running, the Registry MUST contact the EDb on the 1st startup. if, like my environment, you start and stop containers of short duration, then they need to connect.
AND, with DT V9.1, the ability to cleanup the DB of transient registry entries has been removed.. so it will get cluttered pretty quickly.
CA doesn't understand this usage model yet. they assume that the services will be stood up, and long running
net, you need to find a communication path for these containers
We expect CA licence model to evolve to allow a nomad usage on self-containing and volatile platform: this is one trend with generalization of Docker ...
good luck with that.. they just went to this centrally managed license model..