-
Notifications
You must be signed in to change notification settings - Fork 61
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
RHEL7/CentOS7 support + 5 more #30
base: master
Are you sure you want to change the base?
Conversation
templates/master.erb
Outdated
MESOS_cluster="<%= @cluster %>" | ||
MESOS_log_dir="<%= @log_dir %>" | ||
MESOS_logbufsecs=1 | ||
MESOS_logging_level="INFO" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like default that you can't change. Though, in this case you could override this value in @env_var
with same key.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@deric I hope I understand your comment correctly.
As this is a template it could be used to generate defaults or other files.
I'm suggesting it should be based on the environment variables and, hence could be sourced (e.g. by systemd).
The current one relies on variables that are replaced with environment variables by a script that is not versioned with mesos (not even source if it's available).
IMHO there are too many ways to configure things (this, defaults, configs, files, env vars and cli args) and this could be confusing and also unneeded in Puppet managed environments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should decide whether we want to configure Mesos via properties (/etc/mesos-master/*
and /etc/mesos-slave/*
) or by using ENV MESOS_{variables}
. I think supporting both at the same time is very confusing. CLI arguments are out of questions, we expect people run Mesos as service using systemd, sysvinit or whatever else. When someone checks Mesos machine configuration will he look into /etc/default/mesos-slave
or /etc/mesos-slave
? Each Mesos version adds new parameters, it's problematic to add new variables each time this happens.
Generally I like the changes, don't be mistaken by too many comments. Definitely we have to fix the tests and try not to break current behaviour. If the changes would come in separate PR, it would be much easier to merge them. Anyway, we should probably bump the version at least to |
Thanks @deric I'll address the comments and make multiple PRs |
Is there any update on this? |
It would be nice to separate this into multiple PR, or create at least an issue for systemd support. |
@clehene: are you working on this? |
@felixb @deric yes, we use this internally and had very recently made a few more changes we'd like to push upstream. ping @adragomir |
We've rebased on top of master, need to cleanup patches and will make new PRs |
any updates? |
@felixb I rebased everything we have on top of current master and will make separate PRs for each one CentOS7 will come as a single commit/PR but I recommend we discuss the whole group. @deric there are a few questions which you still haven't answered. I think it's worth discussing them, can you please take a look over the comments on the PR. Thanks! |
manifests/init.pp
Outdated
@@ -27,14 +27,15 @@ | |||
$conf_dir = '/etc/mesos', | |||
# e.g. zk://localhost:2181/mesos | |||
$zookeeper = '', | |||
$quorum = 1, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Until now quorum
variable could have been set via options:
options => {
quorum => 4
}
But which one should take precedence? We don't want to break existing installations, so from this point of view it should be overridden by options value, if defined.
any status on this? I'm currently trying to use this module on CentOS7 since puppet forge advertises it as compatible, but i'm slowly finding it's not fully. some strange issues that may be resolved by this fix |
@blsmth What kind of issues you're having? Could you create a separate issue, so that we can address then individually? |
thanks @deric see this issue |
4a81e73
to
15d3549
Compare
@clehene cool, looks much better! What's the reasoning for introducing file{'/some/path':
ensure => present,
recurse => true,
} otherwise we have to handle various duplicate declaration conflicts. The exec should contain at least exec { "mkdir_p-${name}":
creates => $name,
command => "mkdir -p ${name}",
unless => "test -d ${name}",
path => '/bin:/usr/bin',
} But it would be better if we could manage it just with default |
@deric |
The commit "Changed templates to set |
4c43b12
to
fcdeb51
Compare
Ensure the directories are created with mkdir -p
This may cause conflicts, but it's better than relying on Mesosphere script that all it seems to do is to replace these with MESOS prefixed vars anyway.
Question: this is currently sourcing |
Imho, the config should live in |
thanks @felixb for pointing that. I'll fix it. |
Quick note. I'm seeing some issues ( |
@clehene What is the reason for removing all: owner => $owner,
group => $group, does it cause problems on RHEL7? Can't we just set |
@deric I'm not removing them, I'm just setting them globally File {
owner => $owner,
group => $group,
} (resource default statements - https://docs.puppetlabs.com/puppet/latest/reference/lang_defaults.html) so that we avoid having them set everywhere |
Ok, sorry. I've overlooked that. |
|
||
[Service] | ||
Delegate=yes | ||
ExecStart=/usr/sbin/mesos-<%= @name %> <% if @name=='slave' -%>-containerizers=docker,mesos<% end -%> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you're using Mesosphere packages it would be easier to use:
ExecStart=/usr/bin/mesos-init-wrapper <%= @name %>
if you want to execute directly mesos binaries, we have to make sure, that all environment variables are defined.
Either way -containerizers=docker,mesos
should not be hardcoded.
We should introduce some parameter |
This PR is getting too old and some of the issues mentioned are probably already solved, please let me know if any of the issues still persists. I'll try to track the discussion as separate issues:
|
I'd like to discuss these changes on the PR and see how much we can integrate :)
.pp
files