Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add conditions as future replacement of requirements #519

Merged
merged 4 commits into from
Jun 30, 2020

Conversation

ruflin
Copy link
Member

@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

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

@@ -10,6 +10,9 @@ release: ga

owner.github: "ruflin"

conditions:
Copy link
Member 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

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

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

@@ -31,6 +31,9 @@
"versions": "\u003e6.7.0"
}
},
"conditions": {
"kibana.version": "\u003e6.7.0"
Copy link
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
Member 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
@@ -97,6 +98,11 @@ type Requirement struct {
Kibana ProductRequirement `config:"kibana" json:"kibana,omitempty" yaml:"kibana"`
}

type Conditions struct {
KibanaVersion string `config:"kibana.version,omitempty" json:"kibana.version,omitempty" yaml:"kibana.version,omitempty"`
kibanaVersion *semver.Constraints
Copy link
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
Member 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
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
Member Author

ruflin commented Jun 30, 2020

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.
@ruflin ruflin requested a review from mtojek June 30, 2020 13:38
@ruflin
Copy link
Member 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
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
Member Author

Choose a reason for hiding this comment

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

fixed

@@ -185,8 +191,18 @@ func NewPackage(basePath string) (*Package, error) {

p.Downloads = []Download{NewDownload(*p, "tar")}

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

@@ -40,6 +40,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
* Add list of downloads to /search endpoint. [#512](https://github.com/elastic/package-registry/pull/512)
* Apply rule: first package found served. [#546](https://github.com/elastic/package-registry/pull/546)
* 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
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
Member 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
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

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