No longer support deprecated legacy QEMU machine structures

[jakecorrenti]

Removes the MachineVMV1 and MonitorV1 structures that have been deprecated for a long enough period of time that it makes sense to no longer support them.

Results in the removal of deprecated getSocketAndPid as well.

The migration code was added in commit 6e0e1cbddd5e1c5dff51215ad2b41a99d890fad8 and made it into release v4.1.0

Does this PR introduce a user-facing change?

Warning (action required): Users running a `podman` version earlier than `v4.1.0` will have machines using a now unsupported internal structure as of `v5.0.0`. There will be no way to migrate unless using a version of `podman` from `v4.1.0` to `v4.5.1` to do the migration. If a migration is not done, the user will not be able to remove the machine files using `podman machine rm` and will have to manually remove all files for the out-of-date machines.

[jakecorrenti]

Only action needed by the user for this removal would be to migrate their existing machines with the old structures to the new structures, but considering the migrateVM function was merged into upstream last year that is a very slight chance

[rhatdan]

@baude @ashley-cui PTAL

[Luap99]

In principle I am fine with this but can you be specific, i.e. what version was this added? It is very useful to know what upgrade path will be broken by this.

[jakecorrenti]

In principle I am fine with this but can you be specific, i.e. what version was this added? It is very useful to know what upgrade path will be broken by this.

I adjusted the commit message, but it was added in commit 6e0e1cbddd5e1c5dff51215ad2b41a99d890fad8 which made it into 4.1.0

[ashley-cui]

LGTM, thanks!

[Luap99]

Is there a specific reason to remove it now? Or can we hold it for podman 5.0? That at lest gives a valid excuse if somebody is broken. Can we really expect all machine users to not directly update from 4.0 to 4.6 or later?

I am not blocking this but at the very least this definably needs a warning in the release notes. So please add a proper entry under: Does this PR introduce a user-facing change?

[jakecorrenti]

That's a valid point I didn't think of. @ashley-cui @baude what are your thoughts on this?

[ashley-cui]

I think the rules of semver say that we should wait until 5.0, and the only impact waiting would have would be some mostly rarely used code in machine. Technically would be a breaking upgrade, but at the same time I'm not sure if many users would make such a large jump from 4.0 to 4.6, and be mad about having to rm their machine since many of our solutions to a broken machine is "try re-creating it" anyway.

I think it's mostly up to how we want to follow semver.

[Luap99]

But can a user rm the machine in this case, I assume the json unmarshal will fail and podman is unable to remove the files because of it? So a user would need to figure out where all files are and remove them by hand.
But if a simple machine rm still works on an old config file I agree that this is not a bid deal.

[jakecorrenti]

afaik that would be an issue. The remove command currently migrates an old machine to the new format, so it would fail

[ashley-cui]

Oops, you're correct, this would break rm as well.

[jakecorrenti]

Should I close this for the time being

[rhatdan]

We can just mark it for 5.0

[TomSweeneyRedHat]

I could be dropping brain bits, but have we written a deprecation notice for this? I concur, this should come out in Podman v5.0. Please update the release note comment in the description to reflect that.

[jakecorrenti]

I could be dropping brain bits, but have we written a deprecation notice for this? I concur, this should come out in Podman v5.0. Please update the release note comment in the description to reflect that.

Updated the release note comment. Where would I look to find or write the deprecation notice?

[TomSweeneyRedHat]

Hopefully, the deprecation notices are in our release announcements, if not there, then the RHEL docs which is more fun to track down.

[baude]

this can go into 4.x. The format was very old and it has been many many generations since the new one is introduced. I'd like to see it rebased and merged. I am willing to bet there are no installs out there with this; also will to take the complaints if there is one.

[jakecorrenti]

rebased

[github-actions]

A friendly reminder that this PR had no activity for 30 days.

[rhatdan]

@jakecorrenti Please rebase

[vrothberg]

@baude what should we do this PR? Is this being tracked in Jira?

[jakecorrenti]

@baude what should we do this PR? Is this being tracked in Jira?

It is tracked under RUN-1955

[jakecorrenti]

@baude PTAL

[Luap99]

LGTM

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jakecorrenti, Luap99

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Luap99]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[jakecorrenti]

failed tests just need a restart (which I don't have the perms for)

[TomSweeneyRedHat]

@jakecorrenti I've just restarted the failed tests, 🤞

[baude]

/lgtm