"Environments" within clusters

[Michael Fair]

How difficult would it be to add the idea of "environments" to clusters?

Let me explain what I mean:

Let's say I have two apps; echo request, and echo serve (they do the obvious thing; send messages and display the received results and send back what is received (respectively))

So I set up my network and launch the clusters; and everything is fine.

The one day I upgrade the server; but before I roll it out to production, I want to test it.

So in this idealized world, I take my existing set of iris server nodes, install my code, and launch it, but have the servers identify themselves as part of the "test" environment.

Then I take my production echo client and launch it as part of the "test" environment too (no code was changed so there's nothing to install); as the client it asks "where are my servers"?

The iris nodes are all part of the same administrative organization (somedomain.dom); and they've all registered as "echo service" servers, the difference is some of them are in the "test" environment while others are in the "production" environment.  So when the test environment programs query for other peers and services, they see others in the same environment.

Ideally, once federation is fully set up, I can further identify a target "environment" within the remote organization to locate the service I wish to connect with.

Or when something from the remote organization is attempting to connect to one of the local resources here, we can tell what "environment" the request is coming from.

In a broader sense, this is being able to create multiple logical contexts that form a distinct "broadcast zone"; all other things being equal.

If I'd had to deal with sending and receiving files/data between many systems and organizations; and it turns out that being able to identify the "purpose" or the "point" of a particular set of nodes (which is expressed logically by the humans installing/configuring it) and have the services understand that context is extremely useful.

Thanks, I look forward to your thoughts,

Mike

[Péter Szilágyi]

Hi Michael,

  I think currently the easiest way for you to do that is to use a different network name (--net argument) for your test and production environment. Then the nodes will never even try to connect to each other as they'll notice already during peer discovery that they are part of different "services".

  If you would like to run the test environment on top of the very same Iris network as the production, then a possible solution would be to tag the cluster names accordingly (e.g. echo and echo.test) or something along these lines :)

  Does this make sense in your use case?

Cheers,

  Peter

--
You received this message because you are subscribed to the Google Groups "Iris cloud messaging" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-iris...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Fair]

Upon reading everything more carefully, it might be that "clusters" could be most of the organization unit I'm describing.

Aka there are many hosts/nodes making up a "network"; those hosts form a p2p network that supports many logical "clusters"; and those logical "clusters" then host services.

So I could connect my client to the same named service on either the "test" or "prod" cluster.   Both clusters could be running on the same set of physical nodes. 

I still think of "environment" as something else; something like the collection of cluster settings... For instance if many echo services on different hosts are registered to the same cluster, they aren't necessarily running the same codebase.  The "environment" is a logical place where the service could request shared parameters.  E.g. what is our default app specific protocol version?  What "prefix message" do we prepend to responses when sending replies?  What service do we use as a database?  How long do we use a timeout before repsonding to the client as "couldn't complete request"?

So a cluster could be supporting a number of different "environments"; and the code connecting to the different nodes that host the cluster and implement the service could be different codebases; but the "environment" settings could inform the code on how to configure itself for a request for that environment. Then environments could be in different "modes" (starting up, shutting down, default, etc).

You've actually already got this concept somewhat with the -dev flag on a node; what if in addition to a node process level setting, "-dev" was also cluster level setting.  That way the same iris node could support different clusters in different states....