Skip to content
This repository has been archived by the owner on Jul 4, 2023. It is now read-only.

kibana-4.3.0 #46593

Closed
wants to merge 14 commits into from
Closed

kibana-4.3.0 #46593

wants to merge 14 commits into from

Conversation

jasontedor
Copy link
Contributor

This pull request updates the Kibana formula from version 4.1.1 to version
4.3.0, the latest stable version of Kibana as of 2015-11-24.

Relates #46349

@c9n
Copy link

c9n commented Dec 3, 2015

👍 works

homepage "https://www.elastic.co/products/kibana"
url "https://github.com/elastic/kibana/archive/v4.1.1.tar.gz"
sha256 "3f91e99e20e82d4e84ec141007822fea8f9454c71595551f9348ea2609c98284"
url "https://download.elastic.co/kibana/kibana/kibana-4.3.0-darwin-x64.tar.gz"
Copy link
Member

Choose a reason for hiding this comment

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

This looks like a binary release, rather than a source release?

Copy link

Choose a reason for hiding this comment

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

@DomT4 It is binary release.

Copy link
Member

Choose a reason for hiding this comment

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

We'd prefer to build from source, per Homebrew submission rules. (Alternatively this could be shipped off to homebrew/binary or something).

Copy link

Choose a reason for hiding this comment

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

@DomT4 It takes a long time to build kibana from source. Really hurts. I do agree moving it to homebrew/binary.

Copy link
Member

Choose a reason for hiding this comment

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

Won't be a huge problem for most of our users though, because we produce our own binaries for the three most recent OS X versions.

Copy link

Choose a reason for hiding this comment

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

I want to contribute, so I am curious about how it really works.

Copy link
Member

Choose a reason for hiding this comment

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

Alright. Let us know if we can help there. The bottle generation logic for the CI specifically is stored in Library/Homebrew/cmd/test-bot.rb if you want to poke around locally.

Copy link

Choose a reason for hiding this comment

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

Thanks very much. I will read the codes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@DomT4 Thanks for the feedback here. I'll probably be looking at modifying this pull request to use a source release rather than a binary distribution but I might not get to it until next week.

Copy link
Member

Choose a reason for hiding this comment

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

Thanks! No worries, give us/me a shout when the change is made so we spot it.

@DomT4 DomT4 mentioned this pull request Dec 5, 2015
@jasontedor
Copy link
Contributor Author

Thanks! No worries, give us/me a shout when the change is made so we spot it.

@DomT4 I've spent a fair amount of time exploring some options here. Right now, the root problem is that Kibana is tested and supported against Node.js 0.12.7 (for version 4.3.0). While there is an open issue to get to an LTS release in elastic/kibana#5541, that's not slated for the 4.x line of Kibana.

Looking past that, I tried to get Kibana running against the latest Node.js (as would be provided by the current node formula), but it turns out we run into nodejs/node#3606 (actually nodejs/node#3922 but that issue is just marked as a duplicate of nodejs/node#3606). The seemingly unreliable workaround presented there did not work on my system, and even if it did we would still have the issue that Kibana is supported on Node.js 0.12.7.

The two proceedings paragraphs combined strongly suggest that it would be preferable to use Node.js 0.12.7 for the time being. That presents several immediate options.

  1. Use the bundled Node.js that comes with the binary distribution (as submitted with this pull request) with the downside of not being a source distribution.
  2. Depend on the versioned formula node012 with the downside of conflicting with existing formula node creating a mess for many users.
  3. Depend on node using npm to install n to install Node.js 0.12.7 with the downside being this ultimately lands us back to depending on a binary install of Node.js.
  4. Depend on the nvm formula to install Node.js 0.12.7 with the same downside of depending on a binary install of Node.js.
  5. During the install of the kibana formula, download and compile Node.js 0.12.7 from source and install it alongside kibana (effectively how the binary distributions are packaged to begin with).

So we have three options that depend on a binary install, one that creates ugly conflicts with the node formula, and one that is going to duplicate the existing node012 formula to avoid conflicting with the node formula.

But before any firm conclusions are reached, I have a few questions. Is there an option that I'm not seeing? Is there an easy way to manage the conflicts in option 2. that doesn't create a mess for users? In particular, is there a way to just install the node012 formula inside the Kibana install?

If I had to rank order these preferences with the information I have now, I would rank them 1, 5, 4, 2, 3. I'm interested to hear your thoughts and if you see an option that I do not see.

@MikeMcQuaid
Copy link
Member

  1. During the install of the kibana formula, download and compile Node.js 0.12.7 from source and install it alongside kibana (effectively how the binary distributions are packaged to begin with).

This seems like the nicest option to me in terms of avoiding side-effects and being consistent with how we handle other formulae. One question: is that version of Node just needed at build time or also needed at run time? Thanks!

@jasontedor
Copy link
Contributor Author

This seems like the nicest option to me in terms of avoiding side-effects and being consistent with how we handle other formulae.

Okay, I'll work on a version of the pull request that does this, but probably won't get to it until early next week.

One question: is that version of Node just needed at build time or also needed at run time?

It's needed at runtime.

Thanks!

Thanks for your help again.

@MikeMcQuaid
Copy link
Member

@jasontedor Sounds good, thanks!

@DomT4
Copy link
Member

DomT4 commented Dec 19, 2015

This seems like the nicest option to me in terms of avoiding side-effects and being consistent with how we handle other formulae.

👍. Should be dumped into libexec and only the kibana binary linked into the top-level prefix, though. I presume if they live inside the same "real" prefix and you use an exec script that shouldn't be problematic (?).

@jasontedor
Copy link
Contributor Author

I presume if they live inside the same "real" prefix and you use an exec script that shouldn't be problematic (?).

Yes, I don't foresee that being a problem. :)

This commit modifies the Kibana formula to build Node.js from
source. This is because the current versions of Kibana are not
compatible with the latest versions of Node.js.
@jasontedor
Copy link
Contributor Author

@MikeMcQuaid @DomT4 I've pushed b85a0f3 that builds Node.js from source alongside Kibana. One hacky thing I don't like is a change to the audit logic to exclude the kibana formula from the npm check so any suggestions there would be appreciated.

# do not download binary installs of Node.js
inreplace buildpath/"tasks/build/index.js" do |s|
s.gsub!(%r{('_build:downloadNodeBuilds:\w+',)}, "// \\1")
end
Copy link
Member

Choose a reason for hiding this comment

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

Can just use the inreplace function form when doing a single replacement in a file.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks. Addressed in dfc3bc7.

inreplace "#{prefix}/config/kibana.yml" do |s|
s.sub!(%r{/var/run/kibana.pid}, "/usr/local/var/run/kibana.pid")
end
(etc/"kibana").install prefix/"config/kibana.yml" unless (etc/"kibana/kibana.yml").exist?
Copy link
Member

Choose a reason for hiding this comment

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

Doing an etc.install in install will prevent overwriting and then perhaps doing just a conditional inreplace in post_install if needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm...I wonder why that's better? This feels like a post install task to me (but I'm still coming up to speed on Homebrew idioms).

Copy link
Member

Choose a reason for hiding this comment

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

@jasontedor In handles rewriting and writing out a default version in a slightly cleverer/more consistent way so it's preferable, if you don't mind.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Got it, thanks! I pushed 854bd6e.

@jasontedor jasontedor force-pushed the kibana-4.3.0 branch 2 times, most recently from c37c460 to 40471e5 Compare December 28, 2015 03:13
@jasontedor
Copy link
Contributor Author

@MikeMcQuaid Thanks for the thorough review; I've addressed or responded to all of your comments and think this is ready for another review cycle?

@MikeMcQuaid
Copy link
Member

@jasontedor One final comment then 👍 from me!

This commit modifies the handling of installing the Kibana config so
that it is consistent with the handling in other formulae.
@jasontedor
Copy link
Contributor Author

One final comment then 👍 from me!

@MikeMcQuaid I've addressed this final comment, but also pushed some caveats in 8be0508. I think we're ready now contingent on the CI builds?

@MikeMcQuaid
Copy link
Member

Thanks for the great work @jasontedor!

@jasontedor
Copy link
Contributor Author

Thanks again @MikeMcQuaid and @DomT4!

@jasontedor jasontedor deleted the kibana-4.3.0 branch December 28, 2015 19:12
@Homebrew Homebrew locked and limited conversation to collaborators Jul 10, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants