Skip to content

Add conditions as future replacement of requirements #519

Merged
ruflin merged 4 commits intoelastic:masterfrom
ruflin:conditions
Jun 30, 2020
Merged

Add conditions as future replacement of requirements #519
ruflin merged 4 commits intoelastic:masterfrom
ruflin:conditions

Conversation

@ruflin
Copy link
Copy Markdown
Collaborator

@ruflin ruflin commented Jun 17, 2020

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.

@elasticmachine
Copy link
Copy Markdown

elasticmachine commented Jun 17, 2020

💚 Build Succeeded

Pipeline View Test View Changes Artifacts preview

Expand to view the summary

Build stats

  • Build Cause: [Pull request #519 updated]

  • Start Time: 2020-06-30T20:03:57.836+0000

  • Duration: 8 min 16 sec

Test stats 🧪

Test Results
Failed 0
Passed 161
Skipped 0
Total 161

@ruflin
Copy link
Copy Markdown
Collaborator Author

ruflin commented Jun 25, 2020

Throwing this in here as I found some additional conditions in an old file:

compatibility: [1.0.2, 2.0.1]
os.platform: [darwin, freebsd, linux, macos, openbsd, windows]

But these are probably more on the dataset level.


owner.github: "ruflin"

conditions:
Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+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.

  1. Its a limited set of fixed conditions.
  2. The conditions are joined with an AND this mean all condition predicates must return true.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@ruflin ruflin marked this pull request as ready for review June 29, 2020 11:06
@ruflin
Copy link
Copy Markdown
Collaborator Author

ruflin commented Jun 29, 2020

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 :-(

@ruflin ruflin force-pushed the conditions branch 2 times, most recently from 6f0f3dc to ad1bca1 Compare June 30, 2020 07:24
@ruflin ruflin changed the title Conditions playground Add conditions as future replacement of requirements Jun 30, 2020
@ruflin ruflin requested a review from mtojek June 30, 2020 07:24
ruflin added a commit to ruflin/package-storage that referenced this pull request Jun 30, 2020
As soon as elastic/package-registry#519 is merged, the mod file needs to be updated to the most recent version of the registry.
Copy link
Copy Markdown
Contributor

@mtojek mtojek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder why some fields are in such encoded format and some are not: kibana.version: ">6.7.0 <7.6.0"

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest to rename this field, the difference is in capitals. How about kibanaConstraint or kibanaSemver?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Renamed to kibanaConstraint.

@mtojek
Copy link
Copy Markdown
Contributor

mtojek commented Jun 30, 2020

Is there any meta-issue to link this PR?

ruflin added a commit to ruflin/integrations that referenced this pull request Jun 30, 2020
This PR needs updating after elastic/package-registry#519 is merged.
@ruflin
Copy link
Copy Markdown
Collaborator Author

ruflin commented Jun 30, 2020

Meta issue tracking this change is in #517

ruflin added 2 commits June 30, 2020 15:35
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.
@ruflin ruflin requested a review from mtojek June 30, 2020 13:38
@ruflin
Copy link
Copy Markdown
Collaborator Author

ruflin commented Jun 30, 2020

@mtojek PR updated with the reviews. Could you take a look again?

ruflin added a commit to elastic/package-storage that referenced this pull request Jun 30, 2020
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)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be p.Conditions.KibanaVersion?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed


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
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
  }
}    

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should requirements be deprecated?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will be removed in a few hours ;-)

Copy link
Copy Markdown
Contributor

@ycombinator ycombinator left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a note about the CHANGELOG. Code and test changes LGTM.

@ruflin ruflin merged commit 33c9f9d into elastic:master Jun 30, 2020
@ruflin ruflin deleted the conditions branch June 30, 2020 20:26
@ph
Copy link
Copy Markdown

ph commented Jul 1, 2020

post merge LGTM?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants