aboutsummaryrefslogtreecommitdiffstats
path: root/flags
Commit message (Collapse)AuthorAgeFilesLines
* Revert "Revert "Add infrastructure applications to DuperModel""Håkon Hallingstad2018-12-031-6/+0
|
* Revert "Add infrastructure applications to DuperModel"Harald Musum2018-12-031-0/+6
|
* Add OWNERS and README.mdHåkon Hallingstad2018-12-032-0/+5
|
* Install fat flags jarHåkon Hallingstad2018-12-031-0/+2
|
* Add infrastructure applications to DuperModelHåkon Hallingstad2018-11-301-6/+0
| | | | | | | | | | | | | | | | | | | | | | | DuperModel is (will be) responsible for both active tenant applications (through SuperModel) and infrastructure applications. This PR is one step in that direction: - All infrastructure applications (config, confighost, controller, controllerhost, and proxyhost) are owned and managed by DuperModel. - The InfrastructureProvisioner retrieves all possible infra apps from the DuperModel (through a reduced API), and "activates" each of them if target is set and there are any nodes etc. - The InfrastructureProvisioner then notifies the DuperModel which apps have been activated, and with which hosts. - The DuperModel can then build delegate artificially create ApplicationInfo, which gets translated into the application model, and finally the service model. - The resulting service model has NOT_CHECKED for each hostadmin service instance. This is sufficient for goal 1 of this sprint. - The config server application currently has health, so that's kept as-is for now. - Feature flags have been tried and works and allows 1. to disable adding the infra apps in the DuperModel, and 2. to enable the infra configserver instead of the currently created configserver w/health.
* Use correct Inject for componentsHåkon Hallingstad2018-11-271-1/+2
|
* Require default value for FeatureFlagHåkon Hallingstad2018-11-262-15/+7
|
* Remove Optional classesHåkon Hallingstad2018-11-267-148/+72
| | | | | | | | | | | After review & new ideas: - All Optional classes have been removed: They must take a default argument to avoid having clients test whether the flag has been set or not, in order to allow local file flag source to undo a file flag setting from config server. - FeatureFlag is now backed by FlagSource::getString, and FlagSource::hasFeature has been removed. - FeatureFlag now allows default-true to facilitate default-enabled features
* Remove change to jacksonClass typeHåkon Hallingstad2018-11-251-1/+1
|
* Replace timeout- with io-exceptionHåkon Hallingstad2018-11-252-4/+3
|
* Add flags moduleHåkon Hallingstad2018-11-2315-0/+691
FileFlagSource reads flags from files in /etc/vespa/flags and is a component that can be injected in host admin, config server, etc. A flag named foo corresponds to filename foo. In general a FlagSource manages: - Feature flags: A feature is either set (true/enabled) or otherwise false. Touching a file foo means the feature flag foo is set (true). - Value flags: Either a String or empty if not set. The String corresponds to the file content. The plan is to make the config server another source of flags. A unified FlagSource can merge the two sources with some priority and used in e.g. parts of node-admin. In other parts one would only have access to the file source. Defines various flag facades: - FeatureFlag: Used to test whether a feature has been enabled or not. - IntFlag - JacksonFlag: Deserializes JSON to Jackson class, or return default if unset. - LongFlag - OptionalJacksonFlag: Deserializes JSON to Jackson class, or empty if unset. - OptionalStringFlag - StringFlag This is part of removing some of the last Chef recipes. Some minor tweaks have been necessary as part of this and are included in this PR (test whether a systemd service exists, task-friendly file deletion, allow capitalized letters in YUM package name).