You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by David Bosschaert <da...@gmail.com> on 2018/03/16 09:48:19 UTC
Re: [Sling Feature Model] Expanded requirements
Hi all,
In the mean time some additional requirements surfaced, which I added in
[1].
I also updated the feature model format, mostly based on existing
requirements. It can be found at [2]. Once it's matured we should create a
JSON Schema for it (or something similar)...
Main additions are:
* Support for variables
* Comments can now also be put in the document by using a key that starts
with a hash '#'. This is because most JSON editors don't support the JSMin
(/* */ and //) style comments and show these as errors.
* Some small additions that make it possible to 100% roundtrip between the
provisioning and the feature model which is especially important during the
phase where users are migrating.
Best regards,
David
[1]
https://github.com/apache/sling-whiteboard/commit/2dcab0e45866ce51f732ac525ebf100a82737099
[2]
https://github.com/apache/sling-whiteboard/blob/master/featuremodel/design/feature-model.json
Re: [Sling Feature Model] Expanded requirements
Posted by David Bosschaert <da...@gmail.com>.
Hi Dominik,
On 19 March 2018 at 09:20, Dominik Süß <do...@gmail.com> 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
Re: [Sling Feature Model] Expanded requirements
Posted by Dominik Süß <do...@gmail.com>.
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.
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)
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).
Cheers
Dominik
On Fri, Mar 16, 2018 at 10:48 AM, David Bosschaert <
david.bosschaert@gmail.com> wrote:
> Hi all,
>
> In the mean time some additional requirements surfaced, which I added in
> [1].
>
> I also updated the feature model format, mostly based on existing
> requirements. It can be found at [2]. Once it's matured we should create a
> JSON Schema for it (or something similar)...
>
> Main additions are:
> * Support for variables
> * Comments can now also be put in the document by using a key that starts
> with a hash '#'. This is because most JSON editors don't support the JSMin
> (/* */ and //) style comments and show these as errors.
> * Some small additions that make it possible to 100% roundtrip between the
> provisioning and the feature model which is especially important during the
> phase where users are migrating.
>
> Best regards,
>
> David
>
> [1]
> https://github.com/apache/sling-whiteboard/commit/
> 2dcab0e45866ce51f732ac525ebf100a82737099
> [2]
> https://github.com/apache/sling-whiteboard/blob/master/
> featuremodel/design/feature-model.json
>