3 ms·
"sane backend for the chef server" Would love to understand more as I at times do think of writing a better chef.
by sangupta 11y ago
"sane backend for the chef server"
Would love to understand more as I at times do think of writing a better chef.
- viraptor 11y agoI believe that chef is really over engineered in many ways. They were thinking big... too big. For example things like document indexer which is used in 99.99% of cases to search for "some.attribute == 'hardcoded value'". Most of the other cases are prefix searches. This can be done in a normal database. Document storage where what chef really needs is ~5 extracted fields and a json blob that only client deals with. (Again - database is better) Message queue to the indexer which only exists to get broken and be a limiting factor. (extracting even 100 fields from json is not a huge work - just insert them as database rows and prevent the indexing delay) They go after new technologies, where a very conservative stack would be more than enough. The server API is public, so I started working on a replacement using only python/flask/postgres. I got maybe 80% implemented (ignoring the enterprise namespaces). Then got discouraged because I discovered some API flaws which I thought were just too big - for example the API call to update and create a new node is exactly the same, which can make terrible mess by accident. (seen in real deployment) In the end I just started using salt which I think is a better solution overall. If you use chef and would like to continue, I'm happy to send you the repo. (email in my profile) If you don't - I can only recommend migrating to something better (salt, ansible, etc. - your choice).
- sangupta 11y agoI would have loved to check the repo out, but to my bad, I haven't worked with python ever ... and might not have the time as well. However, I would checkout salt. Thanks a bunch.