As discussed in the PR and here, Daemonset work is limited to what's currently doc'ed in the PR. This has been merged, but as DeShuai Ma comments, requires more work to be Enterprise ready. This has been targeted for 3.3.
The PR work has merged into the Origin docs, but I'll keep an eye out for anything required for more Daemonsets work for 3.3. So I'll move this to CLOSED DEFERRED.
Sorry if this causes confusion for anyone. If anyone has questions please let me know.
Ordinary project admins do not have permission to create DaemonSets by default, as this would give them undue scheduling priority on nodes. cluster-admin users, of course, can create one if they want, and that will be sufficient for most use cases.
If you want to grant the ability to manage DaemonSets to non-cluster-admins then as far as I know the best way is to define a cluster role and grant it to them. (I don't believe system:daemonset-controller is intended for this purpose.)
I have an example of ClusterRole YAML from logging at https://github.com/openshift/origin-aggregated-logging/blob/b476bedea4d5afd4625e76b81725b336c2311f56/deployer/deployer.yaml#L53-L68
Once this is created, then you can grant it to users as desired, either with:
$ oc policy add-role-to-user daemonset-admin luke
... which provides the ability to create a daemonset in only the current project, or:
$ oadm policy add-cluster-role-to-user daemonset-admin luke
... which allows luke to create daemonsets in any project (probably not what you want).
Eric, Luke, I think this goes against what I understood...
I thought the only supported use for daemonsets was during the registry install process, ie, what was doc'ed in the PR above.
So why would an admin need to be able to give daemonset permission? If this ties into 3.3 work, and the features that are with that release leading to other users needing permissions, then maybe this can be done as part of that.
I'll ask Paul if he agrees, but feel free to give me any more information.
(In reply to brice from comment #12)
> Eric, Luke, I think this goes against what I understood...
> I thought the only supported use for daemonsets was during the registry
> install process, ie, what was doc'ed in the PR above.
> So why would an admin need to be able to give daemonset permission? If this
> ties into 3.3 work, and the features that are with that release leading to
> other users needing permissions, then maybe this can be done as part of that.
> I'll ask Paul if he agrees, but feel free to give me any more information.
Please see https://bugzilla.redhat.com/show_bug.cgi?id=1361349 which is also requesting docs for this.
(In reply to Eric Rich from comment #13)
> Please see https://bugzilla.redhat.com/show_bug.cgi?id=1361349 which is also
> requesting docs for this.
That bz is not about daemonsets, it's about general pod/container labels/SCCs, so I believe it's not directly related to the discussion in this bz.
If Pep is right, then I think we'd still need a use case for daemonsets for this to be documented. If so, then I can work to get something going.
(In reply to brice from comment #15)
> If Pep is right, then I think we'd still need a use case for daemonsets for
> this to be documented. If so, then I can work to get something going.
Monitoring Solution: https://github.com/kubernetes/kubernetes/tree/master/examples/newrelic << Use Case
PR submitted for this:
Open to suggestions if people have any.
Sounds like everyone is happy with the PR. I'll put this onto QA.
DeShuai Ma, can I get you to please look at the PR in the comment above? Please let me know if you have any comments.
Thanks very much!
The pr doc LGTM, thanks.
Thanks! I'll move this to review.
Commit pushed to master at https://github.com/openshift/openshift-docs
Merge pull request #2786 from bfallonf/daemonset-bz1337329
Bug 1337329 Added information on daemonsets
Link to released docs: