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

Re: Communication from node to broker




----- Original Message -----
> 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.

That doesn't match the usage very closely. Today Result is basically client stdout.  And message is like client logger level :info.


> 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
> 
> 
> _______________________________________________
> 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]