Hi everyone, I'm one
of
the devs for Opscode, if you don't know me. What Matt said is correct. Due to licensing issues, we could not ship mysql with Chef like we wanted to. We could ship code, but there always would have to be a manual step for linking Chef to the db. If we didn't do this, the mysql license would require that we make all code open, even the code in Private Chef. Clearly there are bits in Private Chef that we don't want to give away. At least not yet anyway. That said, we initially resolved this by making Chef work with mysql but not shipping mysql enabled. However, the longer we went down this path the more of a burden it became. We were seeing very little adoption of mysql with most people just going with the Postgres support that ships out of the box. In addition, we were having to maintain code and queries for both databases. We continually found Postgres the easier db to write against. This might be internal team preference and experience, but this coupled with the lack of mysql adoption we were seeing made us confident in dropping mysql support. In our determination the time we saved in not supporting mysql would enable us to move faster on feature and performance improvements in other areas, with very minimal impact to the community. Hopefully that answers your question well enough. Thanks, Mark Mzyk " type="cite"> |
Archive powered by MHonArc 2.6.16.