Deprecate non-{start,status,stop} commands

[gregakinman]

cc @cbrockington @iamdanfox

I want to see what the proper route is for deprecating these commands. I'm thinking:

• add these echos for due diligence (though in this day and age, humans should generally not be running these commands, though I don't know what the large internal product is doing in this regard)
• calling this out in changelog for release that includes this deprecation
• email
• search for usages of these and follow up individually with products using them to lessen impact of their removal

(Also, restart is potentially still includable, though I initially left it out from the perspective of ruthless spec-adherence, there's no concept of instantaneous restarts in the spec and status is easily replaceable on the client-side with stop && start, which, as a sidenote, is probably how the current command should be anyway, as it currently will still issue a start again even if stop fails, small edge case)

[cbrockington]

The only other potential step to add is before completely removing the commands, setting the commands to echo the fact they have been removed and exit 1 / some other error code.

I do find this to be overly optimistic

add these echos for due diligence (though in this day and age, humans should generally not be running these commands, though I don't know what the large internal product is doing in this regard)

while that world would be nice, there will definitely be some who currently rely on the additional functionality (particularly for debugging), so while I don't think everything should be held back by them, I think it's reasonable to expect that this will ruffle some feathers.

[gregakinman]

@iamdanfox thoughts?

[cbrockington]

Other than console I also somewhat still don't understand the need for the deprecation. Restart can be left in exactly as is, and check would be trivial to add to go-init as long as the underlying start function had the launcher config location as a param.

I appreciate I'm somewhat harping on about ways to avoid the deprecation, but it's because I still feel the deprecation is very hard to effectively communicate (since it's all bash, and as we mentioned before, there is no compilation / checking against bash APIs), so I consider avoiding changes there if possible to be pretty valuable.

[gregakinman]

There's no "need" for deprecation per se, but I think the deprecation is just better/nicer. The mentality here is to support only what the SLS spec requires, since any deployment infrastructure managing SLS services will only be running commands dictated by the SLS spec, since those are the only things that are guaranteed to be present in an SLS service. Therefore, the only things running console, restart, and check are humans or custom scripts. console is explicitly for humans so should go away, restart seems like it would only be a convenience for a human to not have to do stop+start, and check doesn't even work and has already been marked for deprecation: #261.

The deprecation is hard to communicate, yes, but as noted above, comes with the expectation that we will do due diligence to seek out uses of these and notify them. The removal of them will be pretty easy to communicate, though, since it will come with a major version bump.

[cbrockington]

Since there is no need for it, can we focus on doing other work instead then?

[gregakinman]

I think it's better to take this opportunity to remove some not-needed functionality rather than implement it in go-init (however easy it may be) just to support backcompat, especially when we don't deem the functionality necessary or in line with the trajectory of how our software is being managed. Just because something isn't necessary to do doesn't mean we shouldn't do it.

[cbrockington]

I doesn't mean it shouldn't ever be done, it does mean we shouldn't do it now. All the functions we don't want to implement in go-init can be left as they are, and we can push forward with other work.

Happy for us to create an issue tracking eventual deprecation of things don't need, but as a P3 or 4, not something we should be spending time on now.

If the tests were already working then I see no problem with merging this since the work is already done now, but given they aren't, I feel it would be more prudent to focus on things which directly and more immediately impact what we are trying to achieve. (there is an internal burndown list for this).

[gregakinman]

Closing in lieu of #306