<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=391815) </details> <!--IssueSummary end--> Re: https://gitlab.com/gitlab-org/remote-development/gitlab-remote-development-docs/-/merge_requests/11#note_1280879175 > An additional field we will have to store is the "flattened devfile" content in the DB. Devfile allows referencing a parent devfile within itself which itself can have a parent reference. Now, the way we have architecture, any update to a workspace would require us to regenerate the k8s resources(using the devfile). If we use the unflattened devfile, there is a chance the the final content of the flattened devfile might change during the lifecycle of the workspace if a parent devfile changes; thus leading to unintended changes in the workspace. > > So, we would need at least one field in the DB table `flattened_devfile` which we will use to generate the k8s resources. > > This is in addition to the original devfile(unflattened) that is present in the project. Pulling this in a separate issue to avoid the noise in the MR as mentioned [here](https://gitlab.com/gitlab-org/remote-development/gitlab-remote-development-docs/-/merge_requests/11#note_1280903941)