Skip to content
This repository has been archived by the owner on Jan 30, 2020. It is now read-only.

fleetctl: on destroy command ignore units that do not exist #1417

Merged
merged 1 commit into from
Feb 11, 2016

Conversation

tixxdz
Copy link
Contributor

@tixxdz tixxdz commented Feb 1, 2016

fleetctl used to ignore requests to destory units which do not actually exist.
This behaviour was changed by commit 9530eed, restore the older behaviour by calling findUnits()
to get the right list of units.

This fixes: #1383

fleetctl used to ignore requests to destory units which do not actually exist.
This behaviour was changed by commit 9530eed, restore the older behaviour by calling findUnits()
to get the right list of units.

This fixes: coreos#1383
@kayrus
Copy link
Contributor

kayrus commented Feb 1, 2016

@jonboulle Have checked. It works, but I'd argue with this. If unit doesn't exist - fleetctl should return non-zero code. And we have to document all possible exit statuses.

@jonboulle
Copy link
Contributor

capturing @mirkoboehm's suggestion - we could add a --sensitive option (i.e. --error-on-not-exist) to destroy/stop/unload - then we can restore the previous default behaviour but provide an option for this behaviour

}

for _, v := range units {
err := cAPI.DestroyUnit(v.Name)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

instead of doing two separate calls, can we check the type of the error returned, and ignore it if it's not-exist?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought that findUnits() is needed since it retrieves all units then it filters them, making sure to mangle names etc. It will only fail if it can't retrieve any unit at all which is another problem. Or perhaps I'm missing something ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tixxdz I'm not really happy this got merged without a follow up to this comment (or an LGTM). It's actually a change in behaviour (and does not restore to the semantic of pre- 9530eed as the commit message implies).

Previously, if we received a command fleetctl destroy a b c, and a and b existed but c did not, we would nevertheless successfully remove a and b. Now, we will immediately error out instead, because c couldn't be found.

My suggestion was to just check the response from each cAPI.DestroyUnit() call, and ignore the error if it's one indicating the unit doesn't exist (this might require some error plumbing). As it is now, we have a race condition between getting the list of units from findUnits and doing the Destroy call.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems there was a misunderstanding regarding the discussion in the main thread. Will follow up with a correction.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jonboulle oh for the race condition you have a point here, yes. Adding checks for Destroy will fix it of course, it could be done without removing findUnits() call since my aim was to have more consistency and avoid hard coding logic for each command. @antrik will follow up with a fix.

@antrik
Copy link
Contributor

antrik commented Feb 10, 2016

@jonboulle please clarify: do you think we need actually to add the --error-on-not-exist option, or is this regression fix fine to be merged alone? (Once the feedback comment on the patch has been addressed...)

@jonboulle
Copy link
Contributor

I think this regression fix should be merged, and then if we want to
support that use case, we can do a follow up feature request.

On Wed, Feb 10, 2016 at 6:20 PM, Olaf Buddenhagen [email protected]
wrote:

@jonboulle https://github.com/jonboulle please clarify: do you think we
need actually to add the --error-on-not-exist option, or is this regression
fix fine to be merged alone? (Once the feedback comment on the patch has
been addressed...)


Reply to this email directly or view it on GitHub
#1417 (comment).

tixxdz added a commit that referenced this pull request Feb 11, 2016
fleetctl: on destroy command ignore units that do not exist
@tixxdz tixxdz merged commit 8d8f775 into coreos:master Feb 11, 2016
@tixxdz tixxdz deleted the tixxdz/fleet-01-02-2016-b2 branch March 30, 2016 08:02
@megahall
Copy link

megahall commented Jul 5, 2016

Would it be possible to backport this fix in #1417 into Fleet v0.11.x or ship a CoreOS which includes Fleet 0.12.x? Because no current version of CoreOS includes Fleet 0.12.x as of yet.

@dongsupark
Copy link
Contributor

@megahall 👍
However this PR is already closed. How about creating a new issue on https://github.com/coreos/bugs/issues, so that other maintainers could easily track it?

@megahall
Copy link

megahall commented Jul 7, 2016

Downstream report filed as coreos/bugs#1448 .

@dongsupark
Copy link
Contributor

@megahall FYI I just released v0.12.0 that includes this fix #1417.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

fleetctl (0.11.5) destroy is not backward compatible
6 participants