#16

 {% set versionRepo = salt['pillar.get']('kibana:repoVersion') %}
  {% if versionRepo.startswith('5.') %}
{{ versionRepo }}:
   repo_url: https://artifacts.elastic.co/packages/5.x/apt

@blbradley I wonder if there is a way the formula can access the data under dict key 5 while still setting your full version number 5.5.1. Clearly, the repo for all versions of ES 5 is the same.

Error:

"Rendering SLS 'base:kibana.config' failed: Jinja variable 'dict object' has no attribute 'config'"

Working on a reasonable fix now.

I just switched to repoVersion: '5', and had trouble when I specified repoVersion: 5 in the pillars. This occurred because something in this formula tries to look up the version in the version map, and does not find the key 5. Instead, it needs to be '5'. Converting the value to a string explicitly should fix this.

Problems regarding the plugins.sls
https://www.elastic.co/guide/en/kibana/5.5/installing-xpack-kb.html
states $fullinstallpath/bin/kibana-plugin install x-pack

1.) If Installed via apt-get on a debian it will be installed to "/usr/share/bin" this path is no where specified.

2.) command to install xpack / plugins has been changed from $fullinstallpath/bin/kibana-plugin install -b x-pack' to do without -b`

While getting more and more into ELK Stack I really hate Elastic for not thinking about automatisation of installations.

So to preserve configuration of pre 5 and after 5 I would recommend to do some magic in the map.jinja

When I try to run this state on an a RHEL 7 system, it fails. The problem seems to be that this only has debian package repositories and no others.

I just switched to repoversion: '5', and noticed that the state kibana-config fails because /etc/kibana is not created automatically.

Brought up in #8 when discussing duplicate Debian source entries.

I am using elasticsearch-formula and kibana-formula together to manage my ELK stack. They both attempt to install different APT repositories in /etc/apt/sources.list.d/elasticsearch.list. The state they use to do this, pkgrepo.managed, does not support multiple entries in the same list.

In order to avoid having to clean up my environment, I've reproduced this here using the testing mode.

On the first run, we have

# /etc/apt/sources.list.d/elasticsearch.list
deb http://packages.elastic.co/elasticsearch/2.x/debian stable main

and

----------
          ID: elasticsearch_repo
    Function: pkgrepo.managed
        Name: deb http://packages.elastic.co/elasticsearch/2.x/debian stable main
      Result: True
     Comment: Package repo 'deb http://packages.elastic.co/elasticsearch/2.x/debian stable main' already configured
     Started: 21:31:08.981497
    Duration: 105.291 ms
     Changes:  
----------
          ID: kibana-repo
    Function: pkgrepo.managed
        Name: deb http://packages.elastic.co/kibana/4.6/debian stable main
      Result: None
     Comment: Package repo 'deb http://packages.elastic.co/kibana/4.6/debian stable main' will be configured. This may cause pkg states to behave differently than stated if this action is repeated without test=True, due to the differences in the configured repositories.
     Started: 21:31:14.612941
    Duration: 96.899 ms
     Changes: 

If we carry out these changes, then we see

# /etc/apt/sources.list.d/elasticsearch.list
deb http://packages.elastic.co/kibana/4.6/debian stable main

and applying the states again gives us

----------
          ID: elasticsearch_repo
    Function: pkgrepo.managed
        Name: deb http://packages.elastic.co/elasticsearch/2.x/debian stable main
      Result: None
     Comment: Package repo 'deb http://packages.elastic.co/elasticsearch/2.x/debian stable main' will be configured. This may cause pkg states to behave differently than stated if this action is repeated without test=True, due to the differences in the configured repositories.
     Started: 22:01:19.203244
    Duration: 99.405 ms
     Changes:  
----------
          ID: kibana-repo
    Function: pkgrepo.managed
        Name: deb http://packages.elastic.co/kibana/4.6/debian stable main
      Result: True
     Comment: Package repo 'deb http://packages.elastic.co/kibana/4.6/debian stable main' already configured
     Started: 22:01:25.128232
    Duration: 95.166 ms
     Changes:  

As you can see, we can apply the highstate as many time as we want: the formulas will just keep swapping which repository lives in that file. If we ran the same without test=True, as I saw before, the one which is executed later always runs.