This repository has been archived by the owner on Jan 30, 2020. It is now read-only.
Fleetctl destroy unit does not remove it from etcd registry #1290
Assignees
Labels
Comments
wuqixuan
pushed a commit
to wuqixuan/fleet
that referenced
this issue
Jul 4, 2015
Fleetctl destroy unit does not remove the unit file content from etcd registry(/_coreos.com/fleet/unit/XXXX). It will cause so many junk to leave in the etcd. The modification removes it from etcd when destroying unit. Fixes coreos#1290
|
Fleet dedupes unit files based on the hash of the contents. We need to check for any other units referencing this hash before deleting it. |
|
I've had a similar issue, I "solved" it by rebooting all machines in my cluster. It was an unintended side-effect of the reboots that weren't an intended remedy for this problem, I was merely updating to a more recent CoreOS version. However I noticed that some orphan units were actually gone after that. Anyway, It might help in the bug-huntin'. |
dongsupark
pushed a commit
to endocode/fleet
that referenced
this issue
Mar 18, 2016
So far each command "fleetctl destroy unit" has removed job entries from the etcd registry, under /_coreos.com/fleet/job. But it has not removed its unit file, under /_coreos.com/fleet/unit. As a result, fleet left lots of garbages in the etcd registry, so users had to manually clean them up. So this patch gets unit contents deleted actually from etcd registry when DestroyUnit() gets called. To avoid potential hash collisions, it first fetches a list of units from registry, to check there's any duplicated entry. Only if no duplicated unit is found, fleetd actually deletes the unit from registry. Fixes: coreos#1456 Fixes: coreos#1290 Reference: coreos#1291
dongsupark
pushed a commit
to endocode/fleet
that referenced
this issue
Mar 21, 2016
So far each command "fleetctl destroy unit" has removed job entries from the etcd registry, under /_coreos.com/fleet/job. But it has not removed its unit file, under /_coreos.com/fleet/unit. As a result, fleet left lots of garbages in the etcd registry, so users had to manually clean them up. So this patch gets unit contents deleted actually from etcd registry when DestroyUnit() gets called. To avoid potential hash collisions, it first fetches a list of units from registry, to check there's any duplicated entry. Only if no duplicated unit is found, fleetd actually deletes the unit from registry. Fixes: coreos#1456 Fixes: coreos#1290 Reference: coreos#1291
dongsupark
pushed a commit
to endocode/fleet
that referenced
this issue
Mar 24, 2016
So far each command "fleetctl destroy unit" has removed job entries from the etcd registry, under /_coreos.com/fleet/job. But it has not removed its unit file, under /_coreos.com/fleet/unit. As a result, fleet left lots of garbages in the etcd registry, so users had to manually clean them up. So this patch gets unit contents deleted actually from etcd registry when DestroyUnit() gets called. To avoid potential hash collisions, it first fetches a list of units from registry, to check there's any duplicated entry. Only if no duplicated unit is found, fleetd actually deletes the unit from registry. Fixes: coreos#1456 Fixes: coreos#1290 Reference: coreos#1291
dongsupark
pushed a commit
to endocode/fleet
that referenced
this issue
Mar 24, 2016
So far each command "fleetctl destroy unit" has removed job entries from the etcd registry, under /_coreos.com/fleet/job. But it has not removed its unit file, under /_coreos.com/fleet/unit. As a result, fleet left lots of garbages in the etcd registry, so users had to manually clean them up. So this patch gets unit contents deleted actually from etcd registry when DestroyUnit() gets called. To avoid potential hash collisions, it first fetches a list of units from registry, to check there's any duplicated entry. Only if no duplicated unit is found, fleetd actually deletes the unit from registry. Fixes: coreos#1456 Fixes: coreos#1290 Reference: coreos#1291
dongsupark
pushed a commit
to endocode/fleet
that referenced
this issue
Apr 4, 2016
So far each command "fleetctl destroy unit" has removed job entries from the etcd registry, under /_coreos.com/fleet/job. But it has not removed its unit file, under /_coreos.com/fleet/unit. As a result, fleet left lots of garbages in the etcd registry, so users had to manually clean them up. So this patch gets unit contents deleted actually from etcd registry when DestroyUnit() gets called. To avoid potential hash collisions, it first fetches a list of units from registry, to check there's any duplicated entry. Only if no duplicated unit is found, fleetd actually deletes the unit from registry. Fixes: coreos#1456 Fixes: coreos#1290 Reference: coreos#1291
dongsupark
pushed a commit
to endocode/fleet
that referenced
this issue
Apr 19, 2016
So far each command "fleetctl destroy unit" has removed job entries from the etcd registry, under /_coreos.com/fleet/job. But it has not removed its unit file, under /_coreos.com/fleet/unit. As a result, fleet left lots of garbages in the etcd registry, so users had to manually clean them up. So this patch gets unit contents deleted actually from etcd registry when DestroyUnit() gets called. To avoid potential hash collisions, it first fetches a list of units from registry, to check there's any duplicated entry. Only if no duplicated unit is found, fleetd actually deletes the unit from registry. Fixes: coreos#1456 Fixes: coreos#1290 Reference: coreos#1291
dongsupark
pushed a commit
to endocode/fleet
that referenced
this issue
Apr 25, 2016
So far each command "fleetctl destroy unit" has removed job entries from the etcd registry, under /_coreos.com/fleet/job. But it has not removed its unit file, under /_coreos.com/fleet/unit. As a result, fleet left lots of garbages in the etcd registry, so users had to manually clean them up. So this patch gets unit contents deleted actually from etcd registry when DestroyUnit() gets called. To avoid potential hash collisions, it first fetches a list of units from registry, to check there's any duplicated entry. Only if no duplicated unit is found, fleetd actually deletes the unit from registry. Fixes: coreos#1456 Fixes: coreos#1290 Reference: coreos#1291
dongsupark
pushed a commit
to endocode/fleet
that referenced
this issue
Apr 29, 2016
So far each command "fleetctl destroy unit" has removed job entries from the etcd registry, under /_coreos.com/fleet/job. But it has not removed its unit file, under /_coreos.com/fleet/unit. As a result, fleet left lots of garbages in the etcd registry, so users had to manually clean them up. So this patch gets unit contents deleted actually from etcd registry when DestroyUnit() gets called. To avoid potential hash collisions, it first fetches a list of units from registry, to check there's any duplicated entry. Only if no duplicated unit is found, fleetd actually deletes the unit from registry. Fixes: coreos#1456 Fixes: coreos#1290 Reference: coreos#1291
dongsupark
pushed a commit
to dongsupark/fleet
that referenced
this issue
May 26, 2016
So far each command "fleetctl destroy unit" has removed job entries from the etcd registry, under /_coreos.com/fleet/job. But it has not removed its unit file, under /_coreos.com/fleet/unit. As a result, fleet left lots of garbages in the etcd registry, so users had to manually clean them up. So this patch gets unit contents deleted actually from etcd registry when DestroyUnit() gets called. To avoid potential hash collisions, it first fetches a list of units from registry, to check there's any duplicated entry. Only if no duplicated unit is found, fleetd actually deletes the unit from registry. Fixes: coreos#1456 Fixes: coreos#1290 Reference: coreos#1291
dongsupark
pushed a commit
to endocode/fleet
that referenced
this issue
Jul 21, 2016
So far each command "fleetctl destroy unit" has removed job entries from the etcd registry, under /_coreos.com/fleet/job. But it has not removed its unit file, under /_coreos.com/fleet/unit. As a result, fleet left lots of garbages in the etcd registry, so users had to manually clean them up. So this patch gets unit contents deleted actually from etcd registry when DestroyUnit() gets called. To avoid potential hash collisions, it first fetches a list of units from registry, to check there's any duplicated entry. Only if no duplicated unit is found, fleetd actually deletes the unit from registry. Fixes: coreos#1456 Fixes: coreos#1290 Reference: coreos#1291
dongsupark
pushed a commit
to endocode/fleet
that referenced
this issue
Aug 12, 2016
So far each command "fleetctl destroy unit" has removed job entries from the etcd registry, under /_coreos.com/fleet/job. But it has not removed its unit file, under /_coreos.com/fleet/unit. As a result, fleet left lots of garbages in the etcd registry, so users had to manually clean them up. So this patch gets unit contents deleted actually from etcd registry when DestroyUnit() gets called. To avoid potential hash collisions, it first fetches a list of units from registry, to check there's any duplicated entry. Only if no duplicated unit is found, fleetd actually deletes the unit from registry. Fixes: coreos#1456 Fixes: coreos#1290 Reference: coreos#1291
dongsupark
pushed a commit
to endocode/fleet
that referenced
this issue
Aug 31, 2016
So far each command "fleetctl destroy unit" has removed job entries from the etcd registry, under /_coreos.com/fleet/job. But it has not removed its unit file, under /_coreos.com/fleet/unit. As a result, fleet left lots of garbages in the etcd registry, so users had to manually clean them up. So this patch gets unit contents deleted actually from etcd registry when DestroyUnit() gets called. To avoid potential hash collisions, it first fetches a list of units from registry, to check there's any duplicated entry. Only if no duplicated unit is found, fleetd actually deletes the unit from registry. Fixes: coreos#1456 Fixes: coreos#1290 Reference: coreos#1291
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Fleetctl destroy unit does not remove the unit file content from etcd registry(/_coreos.com/fleet/unit/XXXX). It will cause so many junk to leave in the etcd.
The text was updated successfully, but these errors were encountered: