Add conditions as future replacement of requirements #519
Add conditions as future replacement of requirements #519ruflin merged 4 commits intoelastic:masterfrom
Conversation
|
Throwing this in here as I found some additional conditions in an old file: But these are probably more on the dataset level. |
|
|
||
| owner.github: "ruflin" | ||
|
|
||
| conditions: |
There was a problem hiding this comment.
@ph @michalpristas I initially was thinking about aligning the syntax with the constraints on the agent. But it only complicates things. The reason is that the available conditions here are very limited and have very specific checks. Adding additional "non yaml" syntax only complicates things. So here is what I'm proposing at the moment.
As each condition can only be used once I made it a key/value pair instead of an array.
One thing I think we should align is the naming. I landed on conditions as I think it fits best in all the places. WDYT about renaming it also in the agent?
There was a problem hiding this comment.
+1 on using "conditions" instead of constraints, which would align with dynamic input.
Now, I am Okayish with using key values pair, for what you are proposing.
- Its a limited set of fixed conditions.
- The conditions are joined with an AND this mean all condition predicates must return true.
There was a problem hiding this comment.
Also, using key/value also mean you don't have to have the parser in Kibana and we don't have to share code in the registry.
So since everything is defined upfront I do not see a concern if the syntax arent the same, it's easier to start fixed and limited than to be dynamic all the way.
|
Marked this as ready for review but it seems currently Github is flaky and has not picked up the most recent commits that I pushed :-( |
6f0f3dc to
ad1bca1
Compare
As soon as elastic/package-registry#519 is merged, the mod file needs to be updated to the most recent version of the registry.
mtojek
left a comment
There was a problem hiding this comment.
Requirements will be removed as soon as packages are updated.
It would be faster to introduce such changes once new integrations are already merged. Otherwise, we need to track if all PRs are correctly rebased.
| } | ||
| }, | ||
| "conditions": { | ||
| "kibana.version": "\u003e6.7.0" |
There was a problem hiding this comment.
I wonder why some fields are in such encoded format and some are not: kibana.version: ">6.7.0 <7.6.0"
There was a problem hiding this comment.
The "problem" is the > char which gets converted. But I tested this quite some time ago and it works as expected even though it is converted.
util/package.go
Outdated
|
|
||
| type Conditions struct { | ||
| KibanaVersion string `config:"kibana.version,omitempty" json:"kibana.version,omitempty" yaml:"kibana.version,omitempty"` | ||
| kibanaVersion *semver.Constraints |
There was a problem hiding this comment.
I suggest to rename this field, the difference is in capitals. How about kibanaConstraint or kibanaSemver?
There was a problem hiding this comment.
Renamed to kibanaConstraint.
|
Is there any meta-issue to link this PR? |
This PR needs updating after elastic/package-registry#519 is merged.
|
Meta issue tracking this change is in #517 |
This change adds `conditions` as part of the package manifest to align with other parts in the stack. Currently it adds the future of conditions and does not remove requirements yet. Requirements will be removed as soon as packages are updated.
|
@mtojek PR updated with the reviews. Could you take a look again? |
As soon as elastic/package-registry#519 is merged, the mod file needs to be updated to the most recent version of the registry.
util/package.go
Outdated
| if p.Conditions != nil && p.Conditions.KibanaVersion != "" { | ||
| p.Conditions.kibanaConstraint, err = semver.NewConstraint(p.Conditions.KibanaVersion) | ||
| if err != nil { | ||
| return nil, errors.Wrapf(err, "invalid Kibana versions range: %s", p.Requirement.Kibana.Versions) |
There was a problem hiding this comment.
I think this should be p.Conditions.KibanaVersion?
|
|
||
| if p.Requirement.Kibana.Versions != "" { | ||
| p.Requirement.Kibana.semVerRange, err = semver.NewConstraint(p.Requirement.Kibana.Versions) | ||
| // If the new conditions are used, select them over the requirements |
There was a problem hiding this comment.
There is duplicated code in this if-else to account for the new and legacy settings. Looks like the intent is to use the new setting, p.Conditions.KibanaVersion. So why not do something like this instead?
p.setKibanaVersion()
if p.Conditions != nil && p.Conditions.KibanaVersion != "" {
...
}
func (p *Package) setKibanaVersion() {
if p.Conditions != nil && p.Conditions.KibanaVersion != "" {
return
}
if p.Requirement.Kibana.Versions != "" {
if p.Conditions == nil {
// initialize p.Conditions
}
p.Conditions.KibanaVersion = p.Requirement.Kibana.Versions
}
}
There was a problem hiding this comment.
@ycombinator The legacy code should only be around for 24-48h, so I was sloppy.
| * Implement package watcher. [#553](https://github.com/elastic/package-registry/pull/553) | ||
| * Add conditions as future replacement of requirements. [#519](https://github.com/elastic/package-registry/pull/519) | ||
|
|
||
| ### Deprecated |
There was a problem hiding this comment.
Should requirements be deprecated?
There was a problem hiding this comment.
I will be removed in a few hours ;-)
ycombinator
left a comment
There was a problem hiding this comment.
Left a note about the CHANGELOG. Code and test changes LGTM.
|
post merge LGTM? |
This change adds
conditionsas part of the package manifest to align with other parts in the stack. Currently it adds the future of conditions and does not remove requirements yet. Requirements will be removed as soon as packages are updated.