Re: [DISCUSSION] Kubernetes Helm
I'm sorry but I'm not really aware of the Kubernetes ecosystem in much
detail. Do we have an indication of how much demand there is for Helm
support in Brooklyn?
This sounds like a significant change - both to our build process, but also
our release process and website (supporting multiple platform downloads).
I'd be opposed to doing it unless there's a significant demand for Helm.
I'd prefer to see this as a community-supported addon (like most of our
blueprints are) instead of being core Brooklyn, until there's evidence of
demand for this to be in core.
On 17 April 2018 at 09:07, Geoff Macartney <geoff.macartney@xxxxxxxxxxxx>
> hi Thomas
> It certainly doesn't sound right to have to have separate builds of
> Brooklyn for different platforms, and especially not just for this
> feature. Can we build the dependency package into a bundle for each
> platform, so that it is the only thing that is platform specific, and
> provide all three bundles along with the distribution of Brooklyn? Then on
> whatever target platform you are on, OSX, Linux, Windows, you install the
> right dependency bundle for that platform into Brooklyn's Karaf?
> On Mon, 16 Apr 2018 at 12:18 Thomas Bouron <thomas.bouron@cloudsoftcorp.
> > Hi Brooklyners.
> > You might have noticed that the Brooklyn builds started to fail more than
> > usual recently. I spent some time last week to fix those issues but I
> > realised that there is a deeper one with the recent change I merged
> > Kubernetes Helm)
> > This change requires a dependency, which depends on some native code.
> > this dependency exists for 3 platforms: macOS, Linux and Window. The
> > is that the "right" dependency is included at build time via the maven
> > classifier, and the way it is picked is by looking at the current build
> > and selecting the corresponding one. Obviously, this leads to nasty
> > problem: as all our builds are done on Linux, Brooklyn artifacts only
> > on Linux. Not only that, the classifier is dynamically picked and set as
> > envvar by a plugin. This is also an issue for any downstream projects.
> > While we want this feature in Brooklyn, I don't think this is acceptable
> > for our users therefore I reverted the changes and started this
> > conversation. What do you think would be the best approach to fix this?
> > Having 1 build per platform doesn't sound good as it won't be portable
> > anymore. Maybe we can find another dependency without a link to native
> > code?
> > Best.
> > 
> > https://github.com/apache/brooklyn-dist/pull/119/files#diff-
> > --
> > Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
> > https://cloudsoft.io/
> > Github: https://github.com/tbouron
> > Twitter: https://twitter.com/eltibouron