Dates

[Poul-Henning Kamp]

In message <F42AAEC0-AADB-4EEB-95A8-385C9BBB182D at vgnett.no>, Anders Berg writes
:

>> ---------------------------------------------------------------------- 
>> -
>> What:
>> 	Error handling on backend connections
>> Situation:
>> 	Right now we more or less panic on any sign of trouble.
>> What needs to be done:
>> 	We need to decide how to tie this into VCL
>> 	Errors must be handled, presumably by retry.
>> 	Timeouts probably desirable as well.
>> Severity:
>> 	alpha:	can live with
>> 	beta:	must be improved
>> 	1.0:	backend trouble SHALL not kill varnish
>>
>
>Agree.
>
>I guess this is also tied to how Varnish handles "error/fault" on  
>backend as well.

yes.


>> ---------------------------------------------------------------------- 
>> -
>> What:
>> 	VCL error implementation
>> Situation:
>> 	The error keyword in VCL is not implemented
>> What needs to be done:
>> 	Find out if this is really the right strategy, it looks
>> 	more and more dubious to me.
>> 	Maybe a redirect to an error document loaded with storage_tar
>> 	would be more useful.
>> Severity:
>> 	alpha:	can live with minimal improvement
>> 	beta:	can live with minimal improvement
>> 	1.0:	can live with minimal improvement
>
>Not sure what this one means. Is this the error we return to client?  
>Or is this the error from backend?
>
>By that I mean:
>
>if (something true){
>
>	error;
>
>}

yes, this.

>Stats that should be visible in VCL would from the top of my mind be.
>
>Hits on documents. (Not sure about if we can implement this, but I am  
>thinking in the line of 20.000 hits on /index.html last 2 min and ttl  
>+2m. It certainly requires us to keep stats on each document/URL or a  
>top-hit-list, and that may not be possible.)
>Backend responstime.
>Client bandwith/hits.

noted, I'll get back to this.

>> ---------------------------------------------------------------------- 
>> -
>> What:
>> 	CLI management interface
>> Situation:
>> 	Only minimally functional.
>> What needs to be done:
>> 	Reevaluate the list we created initially (ie: no unlisten)
>> 	Implement TCP / SSH carried CLI port
>> Severity:
>> 	alpha:	can live with
>> 	beta:	improvement desirable
>> 	1.0:	TCP/SSH mandatory
>
>"Reevaluate the list we created initially (ie: no unlisten" ?

We talked about being able to gracefully stop the cache process
without destroying the listening socket, but it transpires that
there is no way to do this in UNIX, there is no "unlisten()" call.

>> What:
>> 	VCL completeness
>> Situation:
>> 	VCL can't do much yet.
>> What needs to be done:
>> 	Go through our list, implement in proritized order
>> Severity:
>> 	alpha:	can live with
>> 	beta:	HTTP header manipulation desirable
>> 	1.0:	TBD
>
>Agree.
>
>Should I prioritize?

Good question.  I have added some fundamental bits in the meantime.

>> ---------------------------------------------------------------------- 
>> -
>> What:
>> 	VCL compiler error checking
>> Situation:
>> 	Errors from GCC and at load-time still happens.
>> 	Failed loading of default/boot VCL is not currently fatal.
>> What needs to be done:
>> 	Check conditions better, for instance do getaddrinfo() on
>> 	ACL targets and warn if non () entries fail.
>> Severity:
>> 	alpha:	can live with
>> 	beta:	can live with
>> 	1.0:	can live with
>>
>
>Agree.
>
>We at least need getaddrinfo on the backend IP's, but I guess that  
>this is meant on other cases?

Also test-compiles of regexp etc.

>> ---------------------------------------------------------------------- 
>> -
>> What:
>> 	RFC compliance audit
>> Situation:
>> 	We don't know how many small details we are missing.
>> What needs to be done:
>> 	Go through RFC(s) and sourcecode and mark up RFC(s)
>> 	with "not relevant", "deliberate variance", "not implemented"
>> 	and "OK".  (OK preferably listing relevant testcases)
>> Severity:
>> 	alpha:	can live with
>> 	beta:	can live with
>> 	1.0:	can live with
>
>Bump to must/should have on 1.0?
>
>We are gonna need this sooner rather than later. Ppl are gonna ask  
>for this as soon as they start using Varnish in a prod. envorionment  
>is my guess.

I really don't know about this one.  It's a fxxking tedious job and
most of what the standard allows seems to be little used in practice.

>> ---------------------------------------------------------------------- 
>> -
>> What:
>> 	storage_file.c allocation strategy
>> Situation:
>> 	we have seen pessimisal allocation patterns with
>> 	degenerate trafic patterns.
>> 	Real World traffic looks basically OK, but no detailed
>> 	analysis done.  Missing stats an issue.
>> What needs to be done:
>> 	Carefully consider mitigation once we have analyzed
>> 	the issue.
>> Severity:
>> 	alpha:	no issue
>> 	beta:	no issue
>> 	1.0:	no issue
>
>Agree.
>
>1.0 should have a way to dump the stats, so users reporting an error  
>in that area, can give us a clue as to what is happening.

Yes.

>> ---------------------------------------------------------------------- 
>> -
>> Nice to have:
>> 	log-tailer which writes httpd format.
>
>I wanna bump up this one. Ppl may need it for stats.

>I know that bumps upwards are gonna resolve on more work, but a httpd  
>format log is really a must-have I think. Not for VG, but for others.
>I am currently looking into seeing if I can program any C at all :)  
>httpd logg would be a good place to start I guess. A mail will follow  
>after this one about the logging code.

I think we may want to teach the libvarnishAPI to sort things into 
requests and sessions so that not every program has to do this on
its own.  I havn't given much (enough) thought to this yet.


I was hoping DES would have put these items in the ticket base by now
so we could have kept track of them there ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.