|
At first I found this quite funny, but now it's just annoying. Dude, if
piranha sucks and Red Hat screwed you over on support, use UltraMonkey and
get your money back and tell all your friends that Piranha sucks and throw
darts at a picture of Keith and burn Bob Young's book but just keep it off
the list.
-jeremy
> On Thu, 14 Sep 2000, Keith Barrett wrote:
>
> > Unfortunately, whether it was obvious on the mailing list or not, there was
> > a lot of other issues involved. For example; he was offered a refund but
> > refused it, then complained here that he was out $2k (which is for the
>
>
> Kieth, that is bull crap. The refund was offered in the beginning with
> **NO TROUBLSHOOTING** done with the problem. And the refund was offered in
> response to my question of "If we're not going to recieve assistance on
> the problem then why include technical support for the product!"
>
> ** Of course we're not going to just take the refund right off the
> bat! This is a business! We have deadlines to meet, We have a technology
> model that needs to be put in place. We purchased a rather expensive piece
> of software to accomplish that mission. IT comes with a technical support
> contract to assist us in the matter. OF COURSE we're not going to take the
> refund right yet! We haven't even recieved the barest of technical support
> which we just paid $2000 for! ***
>
> Not once was I asked OK what set up do you have? How are you building the
> config file? What equipment is this running on? These are some pretty
> standard questions to ask from a technical support stand point. Why were
> they never asked? No one attempted to contact us back regarding the
> problem. All contact was done because *I* institued the calls,
> because *I* pushed the emails. You guys were content to just let the
> problem hang there. Of COURSE we refused the refund inthe
> beginning! We wanted the goddamn troubleshooting to take place that
> you are so avid about pointing out. "It comes with a one year 24x7
> telephone support" We got NONE of this!
>
>
> OK let's get the goddamn facts straight.
>
>
> First, we purchased this product from you after speaking with Nathan
> Thomas about some concerns. Things like caching of dead routes even when
> restarting, having to stop the secondary node in order to correctly get
> the primary node online and lvs working, having to reapply ipchains rules
> after restarting lvs, lvs installing multiple default routes on start up,
> lvs not correctly adding or removing backend nodes from/to the routing
> paths. All this was spoken about BEFORE we purchased.
>
> We were told that all these issues worked in the product. We installed the
> product according to your documentation and found that either nanny was
> failing to pass the lvs.cf file information to pulse or the lvs daemon was
> failing to correctly parse it's own configuration file which in turn kept
> the ipvsadm rules from being properly created and/or maintained. Unless
> lvs creates the rules itself just manually adding the rules does not get
> them monitored or controlled.
>
> We spoke quite extensively with technical support with me being told that
> they were still too new to the product and that they would ahve to speak
> with those responsible for the product (in this case that being you and
> members of your HA team). Not to mentionthe fact that you guys lost the
> original registration of the product and a member of the technical
> support team had to go back and REREGISTER the product! Then we we are
> told that the technical support only covers configuration and
> administration of the product. When we told you that it's a bug, were
> told that we need to get a development contract since bugs are not
> covered inthe technical support. OK, THEN we're told by development that
> it's a CONFIGURATION issue! OK, then THAT is convered under the original
> technical support contract. Nope. It belongs under development, nope it
> belongs under technical support. Not once did anyone try to actually
> RESOLVE the issue. Over 75% of my conversations with various members at
> Red hat revolved around you guys trying to get MORE MONEY out of us.
> We never recieved a call back until I called up about the issue. Finally
> after posting my config files AS YOU REQUESTED to
> bugzilla, I never ONCE recieved an email regarding the problem from you
> Kieth WHO ORIGINALLY REQUESTED the cofig file. I had to spend another day
> calling Red Hat repeatedly to get ANY type of information on where things
> stood. Next thing I know the problem is closed as WORKSFORME. That was the
> ONLY indication i had that you guys were even working on the
> problem. Finally I call back to technical support looking for
> assistance in this and the answers are "Everything is in tha manual" or
> "Read the manual" Not a single one of you listened to the fact that I
> told you that I had actually yanked the system out of the co-location
> facility to work on them here and that we had done a STEP BY STEP set
> up of the product. We actually sat here and set up a testbed network
> with the actual settings from the book. We gave the systems the IPs
> specifically mentioned in the manual. We did everything THREE TIMES to
> make sure we weren't goofing the problem. NOT A SINGLE TECH SUPPORT
> AGENT LISTENED TO THAT FACT! The same response was given, "It's in the
> manual". The entire team back here is sitting back going "No, really?? Are
> you sure it's in the manual?"
>
> Not once did YOU call or email saying OK let's walk through this and see
> what's wrong. I called and gave technical support a number of steps we had
> taken to debug the problem all with the response "We'll pass it on and see
> what they say". We told you guys we were not able to pass the -v
> switch the man page says to use to enable verbose mode for nanny but no
> one paid any attention to that. LITERALLY, mind you. NONE of the
> troublshooting steps were taken. This was a core piece of assistance
> that we requested since without it, there was no way to tell exactly
> where the product was dropping the ball. THEN, You say that I was more
> interested in taking a stand than getting the issues resolved. Show me
> where we HAVEN'T worked with you or tried to get things answered! You have
> a lot of nerve to say that!
>
>
> > support, not the software). If you read the bugzilla entries, you can also
> > see that I tried to work with him,
>
>
> And anyone reading the entries will see that I GAVE YOU what you
> requested.
>
>
> > There were additional interactions (many not with me) that it is not
> > my place to discuss, so I have to accept that it may appear unbalanced.
>
>
> Yeah the interactions were my phone calls to you guys saying "Where's the
> support that comes with this product?" Goddamn it!
>
> GET FOCUSED!! ADDRESS THE DAMN ISSUES I'M PRESENTING! You have walked
> around every damn issue I have broached! You go around pointing out "He
> has personal issues with redhat". "He was offered a refund but he
> refused" "you hate redhat but promote and rhce"
>
>
> Screw that! Answer the damn questions. How does one pass the -v switch to
> nanny to get more verbosity so we can see where things are failing. Is
> nanny being called hardcoded from inside pulse or some other spot or a
> script? How do we pass the verbose switch to lvs itself so we can seee
> what IT'S doing? We can see that the lvs daeemon is parsing the file to
> some degree since the NAT IP and the VIP are coming online. It's dropping
> the ball on the virtual declaration(s). How do we follow along with it to
> find out exactly WHERE it's dropping the ball?
>
>
>
> We've been asking these questions all the way along with no reply. Either
> we get technical support agents that don't knwo the product and say they
> need to ask the HA development team to find this stuff out or tell us we
> need to buy a development contract in order to get the problem
> resolved? WHY? This is functionality that should be in the base product
> and isn't. If it's supposed to work then troubleshoot WHY it's not
> working. Quit referring folks back to a manual. Actually TALK to folks
> about the problem. Taking a configuration file and running it in a lab
> and it working would normally mean you call or email the client back
> and say OK it works here, let's see where the differences are so we
> can fix this. Who at Red hat did that? None!
>
>
> > Ignoring the legal possibilities, many of his statements
> > false, and he never gave specifics or stating it's just his opinion or
> > experience.
>
> Please PLEASE PLEASE take this legal! PLEASE take this to court. Oh
> please! please please!
>
>
>
> I have tried throughout this whole thing to NOT give the exact details
> BECAUSE I didn't want this to get out of hand. But when you sit there and
> say the product works fine, that the person involved has personal issues
> that extend beyond the scope of the product, that Red Hat has tried to
> work with the client and the CLIENT refused assistance, AND state that you
> personally tried to assist (ALL OF WHICH IS NOT TRUE) I HAVE to come
> forward and bring in the extra information. I'm not going to just sit back
> and let Red Hat claim that it's incompetency on the client's part and that
> they have no fault or blame in this.
>
>
>
> --
> David D.W. Downey
> Systems Administrator
> RHCE, CUA/CLA
> Internet Security Specialist
> QIXO.com
>
>
>
>
>
eholes.org * jeremy@xxxxxxxxxx
-----------------------------------------
eholes have feelings too...
|
