Components previously deleted reappear in cloned environment.

[henrjk]

Openshift resources are exported into the <project>-occonfig-artifacts repo during cloning or the daily automated export.

If one removes a component the related files are not deleted in <project>-occonfig-artifacts. As a consequence components previously delete reemerge.

Presumably on export we could simply rm -rf the are that was checked out and is written to.

[michaelsauter]

@henrjk Moving this to 3.

[clemensutschig]

@michaelsauter / @henrjk - this is a MUST for 2.0 .. we cannot afford to bootstrap an environment wrongly. (too many components. ... )

[michaelsauter]

@henrjk Could you attempt to implement/test your suggested fix?

[henrjk]

I just noticed this is in my queue. When I wrote original description that the export is happening daily. However I don't see this happening.
It appeared to be only invoked when auto cloning (or when manually migrating) environments.
@clemensutschig Does this mitigate the issue so it could be pushed past ODS 2? Otherwise I will make it a priority.

[henrjk]

If follow correctly, th code in this branch

ods-core/ocp-scripts/export-project.sh

Line 458 in 44f9d3a

cd $temp_dir_with_updated_files

appears to ignore the prior exporting in the script above and to also leak a temp_dir.

Should it be in its own script?

[henrjk]

I was just preparing to test this. However the changes in commit opendevstack/ods-jenkins-shared-library@0709122#diff-9b926a359deb3f339e040516225f076e (see this line) mean that for cloning the occonfig_artifacts repo is checked out with a unique branch so it should be empty anyways.

If my assumptions are true then this behavior should no longer occur even without any further change. I will aim to test this, but it might take a bit until I get to that.

[henrjk]

Some more info on my previous comment gathered while testing with autocloning with the suggested code changes

1. On the first project cloning the occonfig_artifacts repo is empty and has no branches. A git clone will not have a branch and this the newly checked out branch is empty.
2. On the second project cloning the occonfig_artifacts repo has a branch produced by the previous clone-project run. When the repo is git cloned this branch will be checkout during the clone operation. So in this case it the content of the newly created branch is not empty.
3. On the third cloning there are two branches (both not called master). When the repo is git cloned a warning is given so that when the newly created branch will be empty again.

Cloning into 'ods2hk-occonfig-artifacts'...
warning: remote HEAD refers to nonexistent ref, unable to checkout.
> did a manual checkout and creation of new branch -> will be empty.

So for the second case and presumably if somebody exported to master (manually) the new code is still needed.

I did a fourth cloning operation after deleting another component with oc delete. And in this case the deleted component did not reappear.

There was error in the jenkins job of the first cloning only. I believe it is unrelated. The error was:

[ods2hk-cd-be-python-flask-1-fix-gh318-test] Running shell script
+ oc -n ods2hk-fix-gh318-test get rc/be-python-flask-1 -o 'jsonpath={.metadata.annotations.openshift\.io/deployment\.phase}'
Error from server (NotFound): replicationcontrollers "be-python-flask-1" not found

I manually cross checked and got:

ods2hk-be-python-flask-1 $ oc -n ods2hk-fix-gh318-test get rc/be-python-flask-1 -o 'jsonpath={.metadata.annotations.openshift\.io/deployment\.phase}'
Error from server (NotFound): replicationcontrollers "be-python-flask-1" not found
?️️️1 ods2hk-be-python-flask-1 $ oc -n ods2hk-fix-gh318-test get rc
NAME                  DESIRED   CURRENT   READY     AGE
be-python-flask-1-1   1         1         1         4m

Notice that during jenkins script rc/be-python-flask-1 is referenced while only rc/be-python-flask-1-1 is defined.

My vote would be to merge this based on these test results. @michaelsauter if you want to inspect the jenkins logs yourself, please ping me directly.