...
Where do all the yamls live?
Should a creation function create everything necessary for a given datum? I think, yes. If a particular datum needs other things to set up, it should create it. This would align with how factory boy works
The concern here is the sort of ‘circular dependencies’ in data (i.e. lms creates courses, then ecommerce creates seats/modes in lms, then users can enroll as verified.)
How do we shorten the dev cycle for this and to make it repeatable?
Option 1: Take snapshot of provisioned database and make it easier for people to go back to that state
We should do this for first pilot with aim of eventually enabling option 2.
Option 2: Assume this implementation method has replaced most of provisioning. Create ability to return to an empty database(that still has the data scheme, but none of the data).
How do we want to pilot this?
Likely Option: request one team works with us extensively on this. Capture their use case
Recommended decision: If we need to create data from outside of a factory, the code to create data should live in its own creation function.
When the make command is used to create data, it calls a python script which calls the management command in each of the specified service’s container. This requires the user to have pyyaml installed. Should we make it a given that devstack commands should be run from a virtualenv. According to a very quick poll by Tim in devstack-questions, very few people use venvs in devstack.
These scripts will not be idempotent. Modifications will be made to the database each time.
Do we want to limit the changes that these scripts make or do we want to allow them to make a full set of new entries each time?
How exactly do we version the creation functions?
Names?
OEP name: maybe from Test Data to Local Data
management command: from load_data to load_dev_data
yaml file keys: from ida_name to ida, from data_spec_path to path
--data-file-path to --path
Name of the whole framework
What do we want to call this method of data loading to differentiate it from others in documentation?
How opinionated do we want to be about what information you can specify about a particular datum? Example: for User model, should we limit it to unique fields: username, email? Or should developers be able to specify whatever they want(max flexibility)? The current implementation goes for max flexibility. But I imagine this might make it harder to do versioning later.
...