In relation to the quoted emails (down) about 4.1 Stability.
I was asked more then once the next question:
"What if the proxy goes down???"
Once it was from an IT manager and couple other times in private emails
and country\work local discussions.
The issues of concern was touched at the article I wrote:
http://wiki.squid-cache.org/Features/StoreID/CollisionRisks
And I wish to honor this amazing IT manager with a few words of mine and
yours to give some answers about the facts of life, the open-source
world and from the other side respect his mental stability\sanity after
being conned more then once in his career.(despite of some of these
being obviates to many)
I had the pleasure to know some of the heartless and fearsome IT
managers, the **Kings** of the IT world!
When you actually see a walking dead men you start to understand how the
IT King actually revives these bodies more then once every day. Is he
the best in understanding the technology and code? sometimes yes. When
you see how the code or the service is not really what important for him
but the Business and the Company workers, you see how it's only a *life
supporting* system and not real life. You can see how the decisions
heartless as they might be because of some bad manners\respect\honesty
or sometimes the result of greed to money\respect\lust\love\fame are
there and they still happen.
I try to respect the decisions and to understand that many times when
even I am asked I would answer "Don't pour for me what you pour for
yourself!!".
The fact of life is that a proxy and many other pieces of software are
somehow fragile and in them you can see that "High Force" at play and as
a human you do not have the option to handle\resolve everything.
Sometimes it's the Kernel and in others it's the Glibc or just the old
monkey that runs inside the dynamo\generator and keeps pumping the
electricity into the "BOX".
Then what comes in handy is the belief that somehow even if you cannot
grasp all these Kernel, libraries and physics you can rely on the
software engineer good heart\soul\mind\skills to be able to grasp what
he can and enough to somehow be the King which can revive the situation
and somehow understand that things are out of someone hands at the moment.
But!!! This burden can never fall on one King each and every time it
happens. Every King in the Open-Source Kingdoms has it's own advisers,
friends, trees, walls, food and world. It happens that Kings are being
replaced by others more suitable names. One of the big examples is SUN
and Oracle. Did SUN fell? Did Oracle succeeded? I really don't care...
The only real thing that matters is that as long as the code exists we
can sense that some developer wrote it. If a human would think 100k
years(5 years passed in a flash) to the future I believe that any code
somehow will leave it's mark but in the future will probably need some
"decrypting" before being used.
Someone in the IT industry mentioned something like "Don't Open-Source
such an old and unusable code!" and I will not argue but I do agree that
in some cases it is better for humanity to bury and forget some pieces
of unusable codes. In the security area some think it's required to "0"
trillion times the sector and others will prefer to "1" trillion times
but I think that in-light to this example we can try to at-least
minimize the options into manageable pieces compared to the goal!!!
Quoting kinkie and many other world experts "OpenStack is not for the
faint of heart!" and it's the same for IT managers jobs!
Now for the fun and practical part!
My current offer for testing is splitting the task into some kind of
binary search. Currently the Build-Farm is making sure that somethings
are done in a way that the CPU and couple other parts will not explode.
I cannot say a thing about this side automation since I am a manual gear
person. The humanity for now is relying on these parts enough both from
the code-reviewing aspect and the drive-testing results.
I can safely say that to delve into these territories you must be "born"
there and not delve into them randomly. There are some Mighty Kings
which have grown in these special lands of Super-Ultra-Mighty Kings,
Warriors Castles and Damsel in distress.
My recommendation for these who wish to delve into these territories to
take some time and prepare themselves watching and understanding first
Inception[http://www.imdb.com/title/tt1375666/] (or if you prefer text
only then beware of being "Transplanted" any non-clear directions).
Also from my tiny experience with these realms it is important to have
some form of lifeline or as they say in many places around the globe
"land-line" which you can use in times of need and no... when you are
deep deep deep inside, Google cannot solve the issue but can help you to
find some re-direction or "re-think" but again beware.
After RedHat, Oracle and many others are taking care of some specific
aspects of the Kernel and Support the basic testing are in our (as
humans and not some Mighty Kings) hands.
For now I have built RPMs for: CentOS, Oracle Linux and SLES.
I have tried to somehow build also for Amazon Linux but I could not find
a way I can get my hold on a VM image that will work on ubuntu KVM
hypervisior yet.
All these RPMs of version 3.5.X and 3.4.X was tested manually in a
forward proxy mode with some basic tests, reverse proxy mode was
partially tested.
Basic Tproxy and Interception tests were conducted on a 3.4.X version
and was found stable enough to test only if changes to the core code
were done, I am planning to test 4.0.X in Tproxy and Intercept mode but
it is an optional test which I will only conduct in my spare time.
Thanks for all the 4.0.X beta testers until now!!!
List of practical tests:
- Forward proxy for HTTP(static objects with size + without size
declaration, dynamic content from various normal use cases such as
social networks, academic sources, search engines)
- Forward proxy for "fake HTTP" requests( I am looking for such
applications)
- Forward proxy for basic CONNECT requests with HTTPS, IRC, SKYPE, MAIL
and couple other basic DESKTOP applications.
- proxy basic cache manager http(only) basic functionality(no reconf or
shutdown etc)
- Forward proxy with ssl_bump and basic splice all settings
- Forward proxy with ssl_bump and basic peek and splice all settings
- Forward proxy with ssl_bump and basic peek and splice most settings
- Forward proxy with ssl_bump and basic peek and splice with specially
crafted SSL requests
- Forward proxy with ssl_bump and basic peek and splice with specific
applications such SKYPE, DROPBOX
The above list is not complete and needs couple more pair of eyes to
highlight specific points and also practical methods.
Please.. if you have tested something and you can send me privately an
email with any results which can help me or the squid developers to
grasp the status of the BETA then send me or anyone from the squid
development team or the measurement-factory staff an email.
This is the place to say thanks to:
- Duane Wessels
- Henrik Nordstrom
- Amos Jeffries
- Alex rousskov
And these who works and helps on every step of the process of
squid-cache pumping bits around the globe 24X7 and making the WWW better
for everybody.
Eliezer Croitoru
* This is a 1 pass text which is salted with many words from the Old and
Fantasy literature world.
##QUOTE
On 01/02/2016 16:55, Eliezer Croitoru wrote:
> On 01/02/2016 16:23, Amos Jeffries wrote:
>> The next beta (4.0.5) should be out in the next few days.
>>
>> 4.1 (stable) will be out as soon as we have a 10 day period with no
>> major bugs existing and no new bugs being found. No certain timeline on
>> when that will occur.
>>
>> Amos
>
> ( kind of hijacking the thread due to the context... we can open a new
> thread for the responses.)
> Can we construct a list of tests that 4.1 should pass?
> A 10 days period is OK from one aspect of the picture but it doesn't
> mean that specific test cases were verified to work or not.
> Compared to older releases we would have couple very good check-marks.
> For now I still have my small testing environment which can test lots of
> basic things but I am working on a high performance hardware testing
> environment.
>
> Eliezer
##END OF QUOTE
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
