I agree completely. My point is not that we don't need any planning, but that the planing is scoped per plugin. On Wed, Nov 8, 2017 at 3:05 PM, Jeremy Cline <jeremy@xxxxxxxxxx> wrote: > On 11/08/2017 09:24 AM, Nathaniel McCallum wrote: >> Here is why I don't think we need to have all the data collection >> requirements up front. Clevis is designed to be very modular. A data >> collector plugin is just an executable that outputs a JSON blob. A >> corresponding server-side plugin parses this data and stores it in the >> database in an efficient way to be later queried. > > I certainly don't expect to walk away from this with everything everyone > wants (and nothing people don't want), but it doesn't hurt to spend a > little time up-front thinking about this. > > Since we're going to be putting this in a database and hopefully we have > a lot of data, thinking about what that data will look like now will > save us and those who have to maintain this system in production a great > deal of pain. It looks like that current implementation uses MongoDB, > which could either be a good choice or a bad choice depending on what > the data schema looks like. If it is a good choice, we need to be able > to prove that since Fedora Infrastructure uses PostgreSQL for pretty > much everything and they probably won't be thrilled about maintaining > another database. > > If we opt for PostgreSQL that means we really do have to model our data > (I think is a good thing to do even with something like MongoDB) so we > should have a pretty solid idea of what it looks like. > > > -- > Jeremy Cline > XMPP: jeremy@xxxxxxxxxx > IRC: jcline > _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
