mgr/cephadm: mgr/cephadm: Add ceph orch generate-service-specs#35669
mgr/cephadm: mgr/cephadm: Add ceph orch generate-service-specs#35669sebastian-philipp wants to merge 6 commits intoceph:masterfrom
ceph orch generate-service-specs#35669Conversation
Make it usable in other module as well. Signed-off-by: Sebastian Wagner <sebastian.wagner@suse.com>
…etc. Signed-off-by: Sebastian Wagner <sebastian.wagner@suse.com>
the adoption process doesn't create service specifications. This command prints out a set of service specifications that can be used to finalize the adoption process Fixes: https://tracker.ceph.com/issues/45973 Signed-off-by: Sebastian Wagner <sebastian.wagner@suse.com>
src/pybind/mgr/cephadm/utils.py
Outdated
| placement=PlacementSpec( | ||
| hosts=[dd_to_hpl(dd)], | ||
| ), |
There was a problem hiding this comment.
wondering, if we can relax this. cephadm won't re-deploy anything that is currently running. There is IMO no need to redeploy the service with the same name afterwards.
There was a problem hiding this comment.
do not relax... more information .. less things to deduce in the future :-)
There was a problem hiding this comment.
I'm not so sure about this. I think I'll remove the name parameter for the daemons.
|
jenkins test docs |
tserong
left a comment
There was a problem hiding this comment.
How is this expected to be used? Adopt the MONs & MGRs, enable the orchestrator, but pause it, then adopt the other daemons, then ceph orch generate-service-specs, then apply those specs after possibly editing them?
that would be my idea, yes. would that work for you? |
| This command cannot be properly implemented, cuase of: | ||
|
|
||
| * we don't know the exact placement specifier for MONs | ||
| * specs can't be deduced. Like port numbers, passwords etc. |
There was a problem hiding this comment.
I think that maybe we should create a fixed "template" spec file for each daemon/service, including all the attributes we need to configure the daemon/service.
This will make easy to "adopt" things.. because we will know what attributes we are going to need, what are the defaults and if there is a customization in any attribute.
There was a problem hiding this comment.
you mean like e.g.
service_type: rgw
...
spec:
# rgw_port: <adapt this, if required>?
There was a problem hiding this comment.
There was a problem hiding this comment.
ok, turned out, having this this made this PR much more complicated and thus not sustainable.
src/pybind/mgr/mgr_util.py
Outdated
| return format_units(n, width, colored, decimal=False) | ||
|
|
||
|
|
||
| def to_yaml_or_json(what: Any, format: str) -> str: |
There was a problem hiding this comment.
Suggestion:
def to_markup_lang(what: Any, format: str) -> str
There was a problem hiding this comment.
hm. we're not supporting XML yet.
Yes, I think so. It somehow feels a bit cumbersome, but I'm not seeing a way to streamline it any further, and anyway, introducing service specs like this during adoption ensures that the step is explicit, and that the admin will end up getting exactly what they ask for. |
to make it readable
Signed-off-by: Sebastian Wagner <sebastian.wagner@suse.com>
the adoption process doesn't create service specifications.
This command prints out a set of service specifications that can be used to
finalize the adoption process
Fixes: https://tracker.ceph.com/issues/45973
Checklist
Show available Jenkins commands
jenkins retest this pleasejenkins test classic perfjenkins test crimson perfjenkins test signedjenkins test make checkjenkins test make check arm64jenkins test submodulesjenkins test dashboardjenkins test dashboard backendjenkins test docsjenkins render docsjenkins test ceph-volume alljenkins test ceph-volume tox