Apply a feature naming convention
Closed this issue · 8 comments
Split of issue #187 , as it can be implemented separately.
Implement naming convention for feature names that will include distro+version that is can be applied to.
Suggestion:
distro/minVersion/featureName (e.g.: ubuntu/16.04/java, centos/6.5/node)
Implement naming convention check when saving new feature. This is so we do not entirely change our data model, but still maintain option for determining which distro+version is feature meant to be for.
It is also convenient for searching, since we already have implemented substring search.
Implications on dependency resolution: Features can declare dependencies on other features. If we introduce namespaces that include the distro and versions, it will be much harder to declare a generic dependency. For example I have a script that needs wget, but is otherwise os-independent, but I would have to depend on a os-specific script that installs wget. Possible solution would be splitting os-package and feature dependencies, like described here: pazuzu-io/pazuzu-registry#40
see #187 (comment)
Features will most likely also have a maximum version they support, e.g. if you have a feature that ships a SysV init script then this might not work any more on SystemD based distros.
Similar, what if I want my feature to auto-detect the OS version and to adjust itself accordingly?
We could include maximum version too, something like ubuntu/15.10-16.04/java, or if it is not bounded, leave wildcard, e.g. ubuntu/16.04-*/java. Does that seem right?
For the second part, if you wrote the script, then you should be able to detect which minimum and maximum versions are supported for it, it may use autodetect, but what you do with it's outcome is up to you, and you can detect which OS versions are supported by your script that handles different OS versions.
@schlomo the description should mention which versions have been tested and are supported in addition to the min-version. If a user updates his base image, he should check if he needs to use other features that more closely match his new distro version.
I don't think it makes sense to implement max-version inside the naming convention.
With regards to scripts that are distro-independent (which means you're over-engineering) we could add a generic linux/any/ namespace.
Like Oliver said, we are adding an unnecessary complexity by implementing the max-version. Pazuzu should fetch the feature with closer version to the base requirement when doing the compose, if the test fails for some feature we know that a new feature with an updated version need to be created.