[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Communication from node to broker



On Sep 13, 2012, at 3:40 PM, Jhon Honce wrote:

> in-line
> 
> ----- Original Message -----
> From: "Krishna Raman" <kraman gmail com>
> To: "openshift Origin Dev List" <dev lists openshift redhat com>
> Sent: Thursday, September 13, 2012 11:57:48 AM
> Subject: Communication from node to broker
> 
> Hi,
> 
> Please review the documentation about the messages and directives that are sent back from component hooks (on nodes) back to the broker and let me know if I missed anything.
> I have also included some suggested renames to make the messages easier to understand.
> 
> Messages from hooks:
> 1) Info level messages. 
> 	These are messages that are always returned via the REST API and displayed to the client. Eg:
> 	- Components having service issues or experiencing degraded performance
> 	- Other warnings that must always be displayed to the user
> 
> 	Current format for message:
> 		"CLEINT_MESSAGE: message here"
> 	Suggested change:
> 		"CLIENT_INFO: message here"
> 
> 2) error messages
> 	These are messages that explain why a component hook failed to execute successfully.
> 	- Error output is only used for non-zero hook exit codes.
> 
> 	Format for message:
> 		"CLIENT_ERROR: message here"
> 
> 3) debug messages
> 	These are messages that help debug component hooks and other functionality. 
> 	- Debug output is sent back from REST API but not normally displayed to the user unless they use the debug flag.
> 
> 	Format for message:
> 		"CLIENT_DEBUG: message here"
> 
> 4) log messages
> 	Normal output logs.
> 	- These messages are sent back via the REST API but may not be displayed to the client for non-zero exit codes
> 
> 	Current format for message:
> 		"CLEINT_REPLY: message here"
> 	Suggested change:
> 		"CLIENT_LOG: message here"
> 
> [jwh: If changing the tags to be more logger-like, shouldn't this be CLIENT_INFO and CLIENT_INFO above be CLIENT_WARNING? I also assume CLEINT_REPLY is the current CLIENT_RESULT?]

[kr: Yes I meant CLIENT_RESULT, not CLIENT_REPLY. 

Im fine with CLIENT_MESSAGE --> CLIENT_WARNING if WARN messages are always displayed to the user. 
And in that case CLIENT_RESULT --> CLIENT_INFO also makes sense to me.]

> 
> Directives
> Directives are commands that the broker acts upon.
> 
> 1) Application SSH key management. 
> 	- Application SSH keys enable gears to use ssh and invoke commands on other gears that are part of the same application.
> 	This is typically used by components like ha-proxy to push/rsync code to other gears that are running a web framework.
> 
> 	Commands:
> 		"APP_SSH_KEY_ADD: <component nam> <ssh-key content>"
> 		"APP_SSH_KEY_REMOVE: <component nam>"
> 
> 2) Domain SSH key management.
> 	- Domain SSH keys enable applications to use ssh pull/push code from other application in the same domain. 
> 	This is typically used by continuous integration packages like Jenkins to perform builds and deployments.
> 	
> Commands:
> 		"SSH_KEY_ADD: <component nam> <ssh-key content>"
> 		"SSH_KEY_REMOVE: <component nam>"
> 
> 3) Domain environment management
> 	- Domain ENV variables allow an application to provide environment variables to other application within the same domain. 
> 	This is typically used by continuous integration packages like Jenkins to provide the location/user/pass of the CI server to other applications in the same domain.
> 
> 	Commands:
> 		"ENV_VAR_ADD: <key>=<value>"
> 		"ENV_VAR_REMOVE <key>"
> 
> 4) Broker authentication
> 	- Requesting broker auth allows the current application to invoke REST APIs on other application within the same domain. 
> 	This is typically used by continuous integration packages like Jenkins to start/stop/restart other application before or after a deployment.
> 
> 	Commands:
> 		"BROKER_AUTH_KEY_ADD"
> 		"BROKER_AUTH_KEY_REMOVE"
> 
> 5) Storing property values on the broker (For use in REST API's)
> 	- This directive allows a component define a set of properties that are stored on the broker and are accessible via the REST APIs.
> 
> 	Current format for command:
> 		"ATTR: <key>=<value>"
> 		"CART_DATA: <key>=<value>"
> 		"CART_PROPERTIES: <key=<value>"
> 	Suggested change to command:
> 		"OPENSHIFT_ATTR_<category>: <key>=<value>"
> 
> Comments/suggestions?
> 
> --Krishna
> 
> _______________________________________________
> dev mailing list
> dev lists openshift redhat com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]