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

Rework 4 #28

Merged
merged 15 commits into from
Apr 20, 2017
Merged

Rework 4 #28

merged 15 commits into from
Apr 20, 2017

Conversation

ypid
Copy link
Member

@ypid ypid commented Apr 14, 2017

Reworks: #6

I dropped the attempt to run the agent under a non-root user.

@ganto
Copy link
Member

ganto commented Apr 14, 2017

Wow, thanks a lot for this update. Please give me some time to go through the changes before I approve. It looks like there is still an issue with a condition on a plugin. Maybe you still can have a look at that?

@ganto
Copy link
Member

ganto commented Apr 14, 2017

Ah, I guess I was a bit too fast in responding. I guess the plugin issue is fixed in ganto/debops-test-suite#2?

@ypid
Copy link
Member Author

ypid commented Apr 14, 2017

I guess the plugin issue is fixed in ganto/debops-test-suite#2?

I have not tried it on Travis but that would be my guess that with this merged, CI should pass.

Copy link
Member

@ganto ganto left a comment

Choose a reason for hiding this comment

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

Thanks a lot for this PR. There is a lot of cleanup from the very early days of this role. 👍

I never used the automated plugin setup of this role, so I just hope the split into the checkmk_agent/env role is worth it. I'm usually not so much in favor of this strategy as it makes it more complicated to use this role without DebOps. Therefore it would be good to have it properly documented (see my other comment).

"checkmk_agent__plugin_list" : {{ checkmk_agent__tpl_plugin_list | to_nice_json }}
}
{{ ({
"plugins": (debops__tpl_macros.flattened(checkmk_agent__tpl_plugins) | from_json | unique),
Copy link
Member

Choose a reason for hiding this comment

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

Since there is a new "sub"-role for setting the facts, could you please still add some documentation in docs/ on the purpose/influence of the facts file?

Copy link
Member Author

@ypid ypid Apr 19, 2017

Choose a reason for hiding this comment

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

Done. I had it "documented" here:

# .. envvar:: checkmk_agent__combined_plugins [[[
#
# Combined list of all plugins which are going to be installed.
# Specified as Ansible local fact so that this variable is also valid in ``when``
# conditions evaluated in the context of other roles called from the same playbook as this role.

I documented the purpose a bit more verbosely in docs/ now.

Copy link
Member

Choose a reason for hiding this comment

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

Ok, something I forgot to mention: In my opinion it would make sense to introduce a page e.g. docs/facts.rst, where the format of the facts is described. As I started to discuss before in debops/debops-policy#16 (comment) it would be nice to have a clear and mostly stable reference about the individual role facts so that a any 3rd-party tool evaluating the facts (e.g. asset inventory tool or such) can reason about the configuration of the role without forcing the author to read and understand the facts template. What do you think?

Copy link
Member Author

Choose a reason for hiding this comment

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

Sounds good to me. Do you have a example/template of such a stable reference I can use?

Copy link
Member

Choose a reason for hiding this comment

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

Not yet. What I think it should contain:

  • Name of the facts key (below ansible_local). Most of the time that's the role name, but sometimes also not 😉
  • Each key which can be there and if it's always there or optional.
  • Format and short description of the according key values. I guess most of the time this will be just a reference to a variable from defaults.

I guess the formatting is good enough to be like e.g. the docs/defaults-detailed.rst.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good idea. I added a first draft which can be updated when a documentation format has been specified.

vars/main.yml Outdated

# Default WATO host attributes. This variable, when being merged with
# `checkmk_agent__host_attributes`, allows to successfully compare the WebAPI
# get_host() response in case the `contactgroups` key is set.
Copy link
Member

Choose a reason for hiding this comment

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

Hmn, not so happy that you remove this from here. This is something that for developer convenience and readability has been separated into an own (internal) variable. However, this must not be changed by the user. That's why I tried to "hide" it in the vars file.

Copy link
Member Author

@ypid ypid Apr 19, 2017

Choose a reason for hiding this comment

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

This is mainly done for transparency reasons. checkmk_agent__default_host_attributes is later combined with checkmk_agent__host_attributes. Ideally, the checkmk_agent__fact_host_attributes could also be moved to defaults. Would you be ok with this or should I change it back to vars?

Copy link
Member

Choose a reason for hiding this comment

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

I see your point. But so far this is something that has many edge cases I still need to look into, so I'd prefer that you don't touch it.

The format of the server facts will change with debops-contrib/ansible-checkmk_server#53 anyway, so I'll have a look at the autojoin feature again in the foreseeable future. Then I'll make sure to clean it up and move it to defaults.

ganto pushed a commit to ganto/debops-test-suite that referenced this pull request Apr 19, 2017
ganto pushed a commit to ganto/debops-test-suite that referenced this pull request Apr 19, 2017
@ypid
Copy link
Member Author

ypid commented Apr 19, 2017

Incorporated your review feedback and CI is passing.

@ganto ganto merged commit 4280d84 into debops-contrib:master Apr 20, 2017
ganto pushed a commit to ganto/debops-test-suite that referenced this pull request May 5, 2017
ganto pushed a commit to ganto/debops-test-suite that referenced this pull request May 18, 2017
ganto pushed a commit to ganto/debops-test-suite that referenced this pull request Jul 3, 2017
ganto pushed a commit to ganto/debops-test-suite that referenced this pull request Aug 9, 2017
ganto pushed a commit to ganto/debops-test-suite that referenced this pull request Aug 17, 2017
ganto pushed a commit to ganto/debops-test-suite that referenced this pull request Aug 28, 2017
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.

2 participants