R
@imraniqbal welcome :)
Size: a a a
2020 April 11
m
According to https://www.zabbix.com/roadmap, it says
ETA: March, 2020.R
About that apt pinning, there is really no problem if it will be rejected if you (and others) think that it's not beast approach. From a global perspective may be it's better to use another way, like use separate formula as suggested. I just implemented solution which is suitable for me.
m
About that apt pinning, there is really no problem if it will be rejected if you (and others) think that it's not beast approach. From a global perspective may be it's better to use another way, like use separate formula as suggested. I just implemented solution which is suitable for me.
No, I think we're good — we're still trying to formalise the rules across repositories. For example, one clear rule is avoiding formula inter-dependencies as much as possible. This idea is different, because it's only a bit of duplication between formulas. I think Javier's feedback was useful: we can take this idea and apply it to more platforms, then provide that in the
template-formula so it can be used in other formulas as well.R
Currently I'm working on pki formula and I have no idea how to do without mutual dependencies.
1. I.e. I can create state in pki formula like
2. On the other hand I can add issuing state to every formula which require certificate, no dependencies here but a lot of duplicated code.
Already implemented the first way. But still thinking which way is better.
1. I.e. I can create state in pki formula like
pli.issue which will issue certificates based on pillar data, but then I need to restart and probably update config of relevant service so I need to call relevant formula which will do this job. Cross dependencies here.2. On the other hand I can add issuing state to every formula which require certificate, no dependencies here but a lot of duplicated code.
Already implemented the first way. But still thinking which way is better.
m
Currently I'm working on pki formula and I have no idea how to do without mutual dependencies.
1. I.e. I can create state in pki formula like
2. On the other hand I can add issuing state to every formula which require certificate, no dependencies here but a lot of duplicated code.
Already implemented the first way. But still thinking which way is better.
1. I.e. I can create state in pki formula like
pli.issue which will issue certificates based on pillar data, but then I need to restart and probably update config of relevant service so I need to call relevant formula which will do this job. Cross dependencies here.2. On the other hand I can add issuing state to every formula which require certificate, no dependencies here but a lot of duplicated code.
Already implemented the first way. But still thinking which way is better.
> For example, one clear rule is avoiding formula inter-dependencies as much as possible.
Maybe this is one of those situations where it isn't possible. In that case, clear instructions in the
Maybe this is one of those situations where it isn't possible. In that case, clear instructions in the
README should be sufficient.
R
When one formula need result of another formula that's not a big deal. Main problem is the execution order, usually states are simply applying from top to bottom, orch can be used in special cases.
What I don't like the most when you need to provide same data twice in pillar. I think that's really error prone.
What I don't like the most when you need to provide same data twice in pillar. I think that's really error prone.