Everything is a Freaking DNS problem

As Tom and I will be heading to Ottawa for OLS Tomorrow you can expect some active blogging here this week..

That is if we can manage to find quality Wifi and our batteries last long enough..
before we find power :)

Anyway .. I`ll be heading to the Virtualization Mini Summit on tuesday, and then of to the big conference.

I`ll be presenting twice, once on the miniconf about openQRM4 and Tom and I will be presenting our findings comparing different monitoring tools such as Nagios, Hyperic, Zabbix , Zenoss and others at OLS itselve.

But don't hesitate to talk to me about other interresting topics such as MySQL or Drupal :)

Now first we have to cross a couple of borders, and an ocean :)

After a period of inactivity I was hacking back on a Drupal project, I had taken a mysql dump from a production platform and imported into my local dev setup, just to have some realistic data.

All of a sudden some forms started failing with the following error:

user warning: There is no 'user'@'nonlocalhost registered query: insert into blah  (stuff,morestuff) values (x,y) in /var/vhost/drupal-tree/includes/database.mysql.inc on line 172.

My Drupal data connection was correct and working for selects etc.. only a limited set of inserts failed.

After some debugging I realised that the error was not Drupal related, running the same query on my MySQL console gave the same error.

ERROR 1449 (HY000): There is no 'user'@'nonlocalhost' registered

The error came from a trigger on the table I was inserting data into that had been created on the production machine by a user@'host' that didn't exist on my development machine. the user was identical but the host wasn't.

MySQLdump includes that information in a dump and uses it to restore the same values.

So recreating the trigger on the development machine solved the problem.
I should probably look a bit closer into the MySQL bugs to figure out if this is a bug or just expected behaviour.

There might even be a parameter to disable this feature , but I didn't find it yet.

My last post, titled T-Dose CFP, got a comment from Bobby that people reading my feed from Planet MySQL couldn't possibly understand my post because of the lack of context.

So let me repost it..

Geekdinner is an unformal dinner where geeks meet , here in Belgium , but also at other places around the world, Every couple of months we meet , have dinner and chat about geeky stuff , such as tech conferences, mysql, drupal, jboss and other topics.

One of these topics was T-Dose , The Technical Dutch Open Source Event, which has their Call For Papers / Presentations available , so if you want to present there .. you have to tell them.

Bert Boerland gave a talk about Drupal there last year and Some Abstract Type, aka Geert Vanderkelen , MySQL/ Sun has also been spotted there before.

Would this be enough context or do you folks need more ?

Is my idea that people click on links to get more info , or even that people understand what a CFP is wrong ?

At this weeks' geekdinner some people wondered what was up with T-Dose, and guess what .. their CFP has been out for ages.

Last year I just catched the end of Bert's talk and Some Abstract Type has also been spotted there before.

No reason to miss this year's edition.

No Matt, my brain definitely wasn't idle.. I've been thinking about these problems for the better part of the last decade. And it seems like I`m not the only one who wants this discussion.

Dries told me that as a follow up to my previous post I should write a post with solutions to the problem. Difficult as I don't have the solutions yet.. If I had them .. well :)

Fact is that different types of opensource products might require different approaches Alfresco to my knowledge has little to no contributing community , Linux distributions tend to have a big one, if not just in the form of the different open source projects they pacakge. The MySQL community is more one of documentation, helping out and bugsquashing. So my ideas aren't valuable for everybody, which is maybe why Matt Asay can't understand me, he might be looking at only one side of the picture.

There are some little things that I can suggest however.

Open Source works because of people contributing to projects, Open Source companies should recognize that and figure out a way to return more business the partners that also contribute to their code , this way they can contribute both on commercial and financial level. If you keep sending business to non contributing partners at the loss of the ones that actually commit code, some people will be unhappy. Those contributing shops might not be bringing the big revenue for the vendors, but they sure are contributing.

The other part is in the support model, Matt somehow thinks I`m in the "everything must be free" camp. Wrong, I`m in the right price for the right product/service camp.
Which means that if I`m escalating a support issue of a customer of mine to a vendor, my time must also be paid for. However that's a difficult sale, my client already paid for his support contract , to the software vendor.

So my suggestion, back when RedHat came to the Bemelux, was to have different types of support contracts, a customer could get a direct contract with a vendor where no integrator could log the calls. Then with another contract type if the a partner actually logs a call for his customer he must get some kind of kickback for that...
One of the advantages there are that more first line calls can be tackled by local partners, partners that might know their customers better.. but they still have a backup if they can't solve the problem. Therefore less investments are to be made in a support organization by the vendor.

And last but not least , don't tell your partners what they can't do. They should be listening to their customers, if their customers choose for the open source version it's the customers choice, and the partner should be able to help his customer, the last thing you need to do is punish them for listening to their customers needs rather than the vendors. This is how the proprietary world works.

Oh and Matt, next time you are in Belgium, let's do another round of Buytaert vs Asay :)
Maybe we come up with some better ideas than the above ones.

Or, why the Inuits won't partner on selling Ice from Alfresco unless they change their strategy.

I usually agree with lot of the things Matt Asay writes but today in Closing an open-source deal trough your systems integrator , he thinks the way to work with partners in an opensource environment is to force them to sell the commercial solutions of your products.
He also thinks you should block them from starting an implementation before the end customer has signed a purchase order.

Whew.. this must be the most stupid idea he had since he started his opensource career. The sad part is that I haven't seen a commercially backer of an opensource project dealing correctly with its contributing partners. He isn't solving the problem , he is creating a bigger one :(

Integrators and consultants are often the bigger contributors to a project because they are integrating new features for their customers, You know, their local , we speak your language , customers. So now Matt wants to force them not to sell services around GPL software anymore but sell the commercial versions ?

As lots of commercial opensource versions do not allow you to make changes to the code if you don't want to loose support your hands are tied again. And yes I have been in this situation before multiple times, a situation where , a commercially backed opensource project, required a couple of small changes to fit with a customer, because of these changes the commercial vendor would drop support , so the customer decided not to buy the license. Should a local integrator capable of helping such customer loose that deal because of a partnership ? Off course not .. It's perfectly understandable that a software vendor can't support every different patch. Shouldn't an integrator have the freedom to assist a customer in making these choices, and give him valuable advise ?

Forcing the integrator to sell the commercial version brings them back to the proprietary software vendor situation , where they couldn't solve issues either.

Mind this is a Category "C" user ,(an organization that has more money than time), which should be an easy win for the commercial opensource vendors.

Then there is the issue of Paying twice where a customer both pays for the time the integrator spends on solving his issue and the support contract. I`m stil looking for a solution for this one.

In the past we invested in different partnerships , some requiring certification, with different Open source vendors before, never got a dime back from these investments.

While our shop was a small but specialist expert knowledge center most deals that those other vendors had in our area went to the incompetent boxmovers that did volume, often totally screwing up the actual implementation. Whether we had contributed to the project, or in the case of Linux distributions were probably equally skilled to support the environment as the vendor itself didn't matter.
We didn't sell enough boxes , so we never got any deals back. Our business is advising people on how to implement open source , implement it for them and support them. We are working with both type A,B and C customers. But the commercial opensource vendors want to force us to go back to the old proprietary boxmoving model, sell licenses, don't sell solutions, Oh and No you can't fix that .. you'll have to wait for the next commercial release or lose support.

So how many of the opensource benefits should the customer give up ?

No Matt, this time your idea stinks,

This way skilled consultants that care about open source and contribute to the community are being punished for doing so, whereas they should actually be getting business back from the vendors, so they can earn money and contribute more on your product you force them to waste more time on the sales side. While the people that just move boxes, don't care if its an open source application or a proprietary package gain more. For them its just business as usual .. selling boxen.

It just doesn't make sense

This concept is just bad for opensource in general, motivated people will stop contributing to products they implement, as they see that their efforts aren't appreciated by the vendors.

besides a community ?

Some people think that apart from a community and users you also need an infrastructure to support these users.

Murray ignited the discussion by pointing us to the fact that PostgreSQL doesn't have a bugzilla to report an track issues.

Different projects have different approaches. Both the kernel, Drupal and MySQL have build their own infrastructure. Others choose Sourceforge for their projects.

What's your approach ?

Florian is replying to James on the subject of using DRBD for MySQL HA. A discussion started earlier by Eric Florian is refuting most of the arguments that James has against using MySQL and DRBD together.

I`m also saying NO to MySQL and DRBD in most of the cases.. but not for any of the reasons James mentions.

I must say upfront I love DRBD and I have been using it in production for a long time but not for MySQL HA.

The problem with using MySQL on DRBD is the same problem you have when killing the power on a standalone MySQL machine and rebooting that machine.
DRBD saves you the time of powering up your machine and OS. But MySQL still needs to be started again on the standby machine. (In limited cases you might have a lengthy startup process due to eg. Innodb consitency checks) But for lots of organisations this (even limited) downtime is not acceptable.

Both MySQL Cluster and MultiMaster replication give you constant access to your data on more nodes .

For lots of shops, those not needing to scale, those that can live with a limited downtime, DRBD and MySQL is a good match,

But if you want to achieve real high availability as compared to less downtime. or if you are looking to scale your MySQL and want to benefit from HA while you are at it , then MultiMaster is probably the preferred alternative as opposed to DRBD.

In the meanwhile I`ll be happy serving other data from my DRBD volumes ;)

It seems like Jeremy wants to be MySQL community president this week :)

The announcement of a MySQL yum repository is a good one but it's slightly confusing me .. didn't Jeremy already have this with
Dorsal, where there are also 5.1 builds. So what's the difference between Dorsal and the new yum repo anyway .

But he asks for Adittionals packages , well 5.1 to start with, apart from that the CentosPlus repo also has builds for Cluster , having a uniform place go get those to would be good.

And what about builds for CGE ?
Oh and while you are at it .. can you run genbasedir also .. that way we can also use apt4rpm :)

Now I all need is a repository with all drupal modules packaged separatly :)

Slashdot totally misinterpreted Jeremy's post about MySQL starting to build features first for their customers. As a business model , this sounds like a good way to get revenue , customers want certain features that are valuable to them , so why not let them pay for it .

The question however is how your development cycle works. Often this method of keeping code first for your paying customers , and when "the feature has been paid for" give it to the opensource community , is the wrong one.

What it comes down to is that you neglect the release early , release often and the peer review , many eyeballs see more bugs, fundamentals that made opensource projects big and stable. You are in effect stepping back to a proprietary model where you have to rush your deadlines because you have promised customers such and such feature, hence letting your customers do your beta testing.

It’s not like it’s the first time MySQL pulls this trick. They already did that when building a Carrier Grade edition for Cluster. That indeed also was a product where they had customers paying for unstable beta products.

The peer review process is one of the things that insanely attracted me in Open Source, the code that you get is not some piece of overrushed code where a developer made a dozen shortcuts because he had to make a deadline, but a piece of code that has been reviewed by many , discussed, and then eventually allowed into the project.

Releasing beta level code to customers and eventually to opensource means you miss out on a lot of the features a true opensource project has.

Often the reason why Open source minded organisations still chose for this approach is to get revenue to be able to hire more developers/ support peope and improve the product faster. But it's a vicious circle, because your product isn't up to the standards you are used to you need more people to support it.

However in the MySQL case , a mostly user community, lesser user development contributions, this could make sense.