Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 17:51
    EugenMayer commented #48
  • Jan 31 17:32
    markround commented #48
  • Jan 31 12:05
    EugenMayer commented #48
  • Jan 31 08:48
    markround commented #74
  • Jan 31 08:39

    markround on develop

    Merge branch 'release/1.3.0' Merge branch 'release/1.4.0' Merge branch 'release/1.4.1' and 2 more (compare)

  • Jan 31 08:38

    markround on master

    Added Ruby 2.5 to Travis tests (compare)

  • Jan 31 08:31
    markround commented #48
  • Jan 31 08:26
    markround assigned #48
  • Jan 30 13:08
    EugenMayer commented #48
  • Jan 30 13:00
    EugenMayer opened #75
  • Dec 11 2018 09:33
    sithukyaw007 starred markround/tiller
  • Dec 05 2018 14:20
    a1300 starred markround/tiller
  • Dec 04 2018 04:54
    romeshniriella starred markround/tiller
  • Nov 13 2018 02:39
    denji starred markround/tiller
  • Nov 06 2018 09:40
    tgagor edited #74
  • Nov 06 2018 09:39
    tgagor edited #74
  • Nov 06 2018 09:39
    tgagor opened #74
  • Nov 06 2018 03:30
    simic1 starred markround/tiller
  • Oct 30 2018 03:08
  • Oct 25 2018 20:53
    tomobrien starred markround/tiller
deepsit19
@deepsit19
file and environment
Mark Dastmalchi-Round
@markround
Great! OK, so I’ll start work on adding API versioning, then I’ll extend those two plugins first.
deepsit19
@deepsit19
Ok great :)
Mark Dastmalchi-Round
@markround
It means I can gradually add support on plugins as I go along, so I don’t have to do everything all at once. You’ll have to explicitly opt-in to use the new API, so it won’t break existing configurations.
I’ll let you know here when I have something for you to test.
deepsit19
@deepsit19
sure, I'll wait for the changes to test.
Mark Dastmalchi-Round
@markround
@deepsit19 I’ve been really busy with other things recently, but I am still working on this stuff. I’ve just comitted a system that enables plugins to declare support for an API version, I need to have a long think now about how to handle these changes in the main code without breaking anything or making it too long-winded. Just wanted to let you know I am still working on it!
deepsit19
@deepsit19
@markround No issues Mark, take your time.
Mark Dastmalchi-Round
@markround
@/all New blog post on 3 years of Tiller: http://www.markround.com/ Thank you everyone for your contributions!
TomGudman
@TomGudman
Hi, I would like to know if Tiller supports reload on changes? We like tiller's modularity and excellent documentation. Congrats. However we would like something like consul-template or confd that execute something on config changes (our backend would be consul). Is it something that Tiller can do or am I missing a page in the doco (the only reference is 'exec' in the 'Main configuration section'). Typical example is 'feature flags'. We would like to enable a flag in Consul and let this info flow to the apps via Tiller regenerating the config and notifying the app to reload its config. That would be our use case.
Mark Dastmalchi-Round
@markround
@TomGudman Hi! Sorry for the delay in responding, I was on holiday and had no internet for most of the week :) So, currently the answer is a simple “no” - Tiller is a one-shot configuration generation tool. However, you’re not the first person who has asked for this so I would consider it as a future feature. But it would require a fair amount of internal re-writing and careful consideration (as, at that point, Tiller would effectively become an init system). So it’s not something that will end up in a release in the short term.
Aananth.K
@aananthraj
Tiller is excellent, and can it be decoupled from underlying environment..?
Here is a case: There is a python app that is to be containerised, to extend the feature of Tiller , we need to install ruby inside the image or use a ruby base image, which would increase the image size. Do we have existing solution/ work arounds ?
Mark Dastmalchi-Round
@markround
Hi! Unfortunately, there’s no way to ship Tiller without the Ruby runtime. I am working on a set of base, minimal Tiller Docker images which may provide a helpful starting-point, but there’s not much else that can be done. The only thing that would “help” would be a complete re-write in something like Go which would allow shipping of a single, statically-linked binary. But a.) I really dislike Golang, and b.) It would be a massive effort, and the plugin system would need to be completely overhauled.
Eugen Mayer
@EugenMayer
@markround ruby is one of tiller biggest downsides and some of its strengths too. Its one of the reasons we sometimes not user tiller - no doubt i love it
Jeremy Lyman
@maarek
Does anyone know what resolved this? markround/tiller#37
I am running 1.2.0 but I'm finding that environments configs are not overriding defaults in a template even though it says it should be in the verbose logs.
exec: [ "/usr/bin/java", "-jar", "/usr/share/examples/examples.jar", "--config", "/usr/share/examples/kafka_streams_counter.conf"]
data_sources: [ defaults, file , environment ]
template_sources: [ file ]

defaults:

    kafka_streams_counter.erb:
      env_bootstrap_servers: 'localhost:9092'
      target: /usr/share/examples/kafka_streams_counter.conf

environments:

  dev:
    kafka_streams_counter.erb:
      env_bootstrap_servers: '10.0.10.10:9092'
config.key: "kafka_streams_counter"

kafka.server {
  application.id = "kafka-streams-counter"
  bootstrap.servers = [<%= env_bootstrap_servers -%>]
}
Merging duplicate target values
env_bootstrap_servers => 'localhost:9092' being replaced by : '10.0.10.10:9092' from FileDataSource
Building template kafka_streams_counter.erb
But the file ends up coming out with localhost:9092.
Jeremy Lyman
@maarek
Is env_ messing with it?
It looks like I just needed to put the values under config:
Mark Dastmalchi-Round
@markround
Yeah, that's the issue.
All config values have to go under config: blocks in the environments
I know it's a little inconsistent. I've just started a new job and am in the middle of moving house and other exciting life changes, so progress on Tiller has been very slow recently. However, I have started putting together a list of what I'd like to see in Tiller 2.0 and unifying / simplifying a lot of the configuration is one of the big items on my mental TODO.md file ;) Hopefully, we'll see a brand new release in the spring/summer months when everything else is behind me.
Jeremy Lyman
@maarek
@markround Thanks! :) One question, is there an environment variable that could be passed to build the right environment? For example we run tiller -v -e development. But if I start this from the docker image it will always build with development. What if I want to specify the environment on docker like docker run -i -e "production" ...
Jeremy Lyman
@maarek
I found it in options.rb
:thumbsup:
Pablo Gonzalez
@kydorn
hey! would it be possible to generate release soon? thanks!
Mark Dastmalchi-Round
@markround
Yes
I'm just in the middle of moving house but have Internet again now 😁
Hope to add some more tests and get a few bug fixes out soon. And start laying the foundations for Tiller 2.0
Expect a new release next week
Mark Dastmalchi-Round
@markround
Just merged an awesome PR from dmarchewka - it adds reusable templates and a regex replacement plugin. New release with these will be coming soon, but for a quick look at how they work, check out the test fixtures at https://github.com/markround/tiller/blob/develop/features/fixtures/reusable/scenario1/common.yaml and https://github.com/markround/tiller/blob/develop/features/fixtures/regex/common.yaml
Mark Dastmalchi-Round
@markround
Tiller 1.4.0 is now out with the awesome new plugins from dmarchewka.
free bash
@freebash_gitlab
Hi @markround, is there a way to override a default value with env_ ? I can't find this in the docs, I'm using only defaults and env data sources, thanks.
free bash
@freebash_gitlab
ah nvm, its the order of the data sources
Eugen Mayer
@EugenMayer
@markround are you arround?
@markround i wonder if http://tiller.readthedocs.io/en/latest/plugins/consul/ .. Services actually does respect the health status, because i think it is not, it always returns them all, not just the healthy ones
well yeah, i just confirmed it. The even worse part is, in the open struct you return there, there is no health status, so i could not even filter myself. Thats a real bummer
@markround why dont you use Diplomat::Health.state('passing') ?
Diplomat::Health.state('passing')
Eugen Mayer
@EugenMayer
@markround one would need to use Diplomat::Health.state('passing') and the enrich the date with the data from Services to have address/port availabel
Eugen Mayer
@EugenMayer
@markround markround/tiller#73
Eugen Mayer
@EugenMayer
@markround are your arround by any chance?
Torsten Schmidt
@torstello

Hi there. I'm playing around with tiller, nice tool, looks very promising especially, if you have a lot of erb templates from puppet :)
But something is missing, I get an error message running tiller inside a container (alpine 3.9 + ruby 2.5), saying
```4: from /usr/bin/tiller:23:in <main>

3: from /usr/bin/tiller:23:in `load'

2: from /usr/lib/ruby/gems/2.5.0/gems/tiller-1.5.0/bin/tiller:17:in `<top (required)>'

1: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'

/usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require': cannot load such file -- json (LoadError)```

within the container there're the same /etc/tiller/{common.yaml,templates} that run without any erros if i execute it outside the container with tiller -b <basedir> -v

Torsten Schmidt
@torstello
the gem json (and others) are missing within the container... I'm checking further...
Clemens Kolbitsch
@clemenskol_twitter

looks very promising especially, if you have a lot of erb templates from puppet :)

hehe, same here - trying to move our projects from Puppet to docker, and finding Tiller a great way to easy the pain of rewriting everything :)

Clemens Kolbitsch
@clemenskol_twitter

I'm adding a few plugins/features, which I'm planning on contributing back asap, but before I send merge-requests your way, I wanted to understand a few things that are surprising me... for now, 2 things I wanted feedback on:

1) dynamic_values allows changing the configs, except for the "environment.yaml" input. But that's what I'm finding especially useful. The current code has the following snippet:

      temp_config.deep_traverse do |path,value|
        # We skip anything under environments block (Unless it's the "common" over-ride block) as these
        # may contain values we want to replace with template-specific values later on.
        next if path.include?('environments') and ! path.include?('common')

but I have not wrapped my head around why this exception exists.

My goal is to allow env-variables to define conditions under which a certain file is to be rendered from a template.

For example, if the env provides S3 credentials, I'll write config files containing these S3-credentials for our application to load.
For now, I'm working around that by just writing empty files and telling the application to ignore empty configs, but would be much more elegant to just disable the generation of the file in the first place using some env-base condition.

Thus, I'll write a change to allow dynamic_values even for re-rendering the "environments.yaml" input (probably in a step after iterating through all configs as shown above).
But if you see a reason why this is a bad idea (I didn't find it yet), I'd appreciate some feedback!

2) Due to the way our legacy code works, we often have multiple config files with very similar structure, for which we'd like to re-use templates to render multiple files. But the "environments" file for mapping templates to file (target) seems backwards, as it's mapping of template -> target rather than allowing multiple targets.

I'm currently thinking of specifying a targets value (instead of the existing target), which seems like a very easy change, but it does not really make sense for the general case where different files have different permissions or may allow specifying different Exec properties.

Thus, my alternative (and preferred) change is to make a bigger change to load the "environments.yaml" as a target -> template mapping (that is, invert how it is stored). I would make it backwards-compatible, either by using a config that specifies how templates are loaded, or by inferring the "direction" using some heuristic (e.g., if the key starts with a / then it's assumed to be a "target" and enforce that the hash that the key points to contains a template entry).

Is that a bad idea, or is there an existing mechanism that I may have overlooked?
If not, I'll be working on this and send merge-requests as soon as I have something generally useful.

Any feedback on the above ideas are greatly appreciated! :)

BTW, another change I could send for review is loading environment variables from yaml blobs (similar to the existing environment_json), because I found it more consistent to pass data in as yaml, which seems to be "the docker way these days".

Clemens Kolbitsch
@clemenskol_twitter
@markround I did see markround/tiller#21 , but the above seems to be a bit more generic (or I misunderstood issue #21)