Hi Dominik, On 19 March 2018 at 09:20, Dominik Süß <[email protected]> wrote:
> Hi David, > > I would challenge > SFM460 - The feature model should provide an externally accessible API for > reading and writing feature files > > The model itself doesn't provide any API nor would it mandate any > implementation detail. I rather see this partially as refinement of > SFL012 - Tooling must provide a way to add new features to an existing > application. > and it also might be some tooling for remote editing and distribution of > features & application state. > You are right that the model itself doesn't provide an API. However this requirement states the desire for an API to read and write feature model. This is to facilitate the development of tools that create features or reason about it. The feature model uses JSON as serialization, so its not a 'must' requirement as you could use standard JSON libraries, but I think it would make it easier for people to write such tools if an API for this was available. I thinks this requirement really belongs in a separate section 'Feature Model API', so I moved it there... > My thought for this was to implement something like a deployment manager > which is a tool to compose and build up new features and queue up for the > next deployment. So instead of dynamically installing bundles & content one > would have a tool (which should be built with API-first in mind) to > a) build up a new feature based on available artifacts (bundles, packages, > configs, repoinit commands) > This is an example of a tool that could benefit from having an API to read/write feature files. > b) compose an application based on installed application state (features as > deployed in last deployment) and new features > c) queue up an application state for deployment & trigger deployment > (defining the interface to the operational details such as the launcher or > in containerized environments the coordinating system) > > The bullet points ahead account for local deployments (in instance > preparation & triggering) - as well as for remote execution where some > coordinating system would be use to centrally coordinate application state > of n instances and distribute the results accordingly. > > We should properly split up the modeling (deployment manager) from the > operations details (feature model distribution) so we can plug the > distribution system according to the operational details (local, > distributed topology, multi topology system) while reusing the same > mechanism for adjusting a versionable model (which can distribution wise > map to 1 or n systems). > I think these are all valid considerations and they elevate the feature model above what we have mostly been discussing so far. However I think that the feature model, with it's generic requirements and capabilities, the ability to extend features with other features, combined with additional tooling could be the basis for all of these... Best regards, David
