User story #5670
Updated by François ARMAND about 10 years ago
Today, when an ncf Technique is created, the user has to manually add the technique from the reference library to the active technique library. We want to automatise that step so that as soon a Technique is created with ncf, it is automatically added. We will need to handle correctly error messages from Rudder for that, for example in the case where a Technique with the same name/version already exists (see #5685). We also need to take into account the case when the user actually removed an ncf Technique and the Technique is modified/saved again in ncf-builder. We don't want to add it again (it is perhaps a second use case, at least it should not block the first part which is auto-addition). In fact, we have to clearly spec what we are doing when a Technique is removed from ncf-builder. In all case, we have to removed the ncf-technique, but several things can happen to the Rudder Technique generated from it: - 1/ also removed that Technique from Rudder (completly), cascade-deleting Directives based on it - 2/ just remove the Technique from active ones, and disable Directive based on it - 3/ just disable technique - 4/ do nothing. Only the first and last seem to have deep rationnal. For 1/, the rationnal is "as presented here, ncf-builder is an integrated part of Rudder that build a unique software, action on one are deeply bound to action on the other". For 2/, the rationnal is "ncf-builder" is *just* a Technique builder, so it does not make sense to allow it to modify production". From what user are saying, it seems that 1/ is the actual perceived start of affair. It can be change with more documentation and explanation about what is expected to happen to Rudder when you are in ncf-builder. 2/ has my preference, because it forbid surprising effect in prod. And it is still rather easy to delete a technique in Rudder if you really want to get rid of it.