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

Re: Events now part of origin





> On Dec 6, 2014, at 11:20 PM, Steven Pousty <spousty redhat com> wrote:
> 
> Please also think about when messages would be helpful sent to the
> developers using the platform. Classic example that we handled poorly in
> V1 and V2 - running out of disk space, watchman having to restart an
> app,  or  timing out when trying to deploy an app and giving the user a
> good message.

Restarts due to failed health checks (watchman equiv) already send events, disk is harder but we should use events as well.  There is now no longer a deploy timeout, and the UI should indicate where you are in your startup (pulling image vs run).  Eventually we may allow apps to send their own events.

> 
> This information in an overall "application" log should really be there
> for developers using the platform - especially in online.

It should be, and I think we have all the tools to do that already.  We'll need to sort through perf / scale implications, but that's something both we and google feel is fundamental to running applications.

> 
> Thanks
> Steve
>> On 11/24/2014 10:09 PM, Clayton Coleman wrote:
>> 0.5.0 Kube (and our slightly pre 050 rebase) has most of the work necessary to support event logging from system components like the kubelet and the scheduler back to the master.  That will be used for actionable behavior and feedback loops (pod can't be scheduled because all the nodes are down, etc).
>> 
>> I recommend everyone maintaining a subsystem with a controller (build, deploy, images) or adding a subsystem with a controller (source code, node, etc) look through https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/client/record/event.go and start to think about what sorts of events might be relevant for your subsystem.
>> 
>> Remember, events are targeted at humans (app admins or infra admins) or machines (other services within the system).  Administrators should be able to eventually write simple monitoring tools that trigger system reactions based on events (using the cli or api directly).  Events are the current mechanism for backpressure (reducing upstream activity based on downstream congestion).  Events are *not* an RPC mechanism or guaranteed delivery subsystem message bus.
>> 
>> If declarative state and our watch APIs are the arteries of the system, the event subsystem is the veins carrying important info back to higher level components.
>> 
>> _______________________________________________
>> 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]