It worked well, but didn't readily lend itself to an open source release. I wonder whether other folks have built similar things and found themselves in the same boat.
On Sun, Jan 5, 2014 at 8:26 PM, Lamont Granquist < " target="_blank"> > wrote:
I keep hoping that someone in the Chef community would start using data bags more like a real database and writing web front-ends that sit in front of them for application and user management, but so far I haven't seen that pattern pop up yet...At a previous employer, we did just that - we built a user management system with a data bag as the system of record. Each user's details were in a data bag item, and Chef was responsible for managing user accounts in as many systems and applications as we could reasonably teach it to do so. For the few where this wasn't practical, we had an LDAP service (built on ldapjs) which authenticated against the data bag items. On the front end, a Rails webapp allowed managers to create accounts for new users, and individual users to update their passwords.It worked well, but didn't readily lend itself to an open source release. I wonder whether other folks have built similar things and found themselves in the same boat.On the other hand, we discarded a similar approach for application management in favour of a web service backed by a relational database. The nature of data bags (no relationships, no partial updates, last writer wins & no CAS, etc) rendered them unattractive for modelling the complexity we had to manage in that area.Another factor in that environment was our use of the open-source Chef server - without data-bag level ACLs, any web-app storing data in a data bag needs a full admin client. We could live with this for the user management app, but it was a showstopper for other potential applications.Zac
Archive powered by MHonArc 2.6.16.