Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Molecule to require minimal py36 #2629

Closed
ssbarnea opened this issue Mar 26, 2020 · 8 comments · Fixed by #2628
Closed

Proposal: Molecule to require minimal py36 #2629

ssbarnea opened this issue Mar 26, 2020 · 8 comments · Fixed by #2628
Assignees
Labels
critical proposal Suggestion for a larger change
Milestone

Comments

@ssbarnea
Copy link
Member

As py27 is effectively dead and I can no longer keep up the py27 jobs green (two different outages in last 24h), I propose we drop support for py27 in molecule.

The next major version v3.1 will no longer be tested or work with python older than 3.6.

Please be aware that this requirement is about molecule itself and that you can still test hosts using any version of python supported by ansible. Still, if you happen to test a py37 based host using delegated driver, you may be in trouble. You would have to spawn two hosts, one that is used by molecule and the tested one.

Please use thumbs up and down to vote on this change. Once I receive enough feedback, I will implement the change and unblock current PRs.

@geerlingguy
Copy link
Contributor

I mostly run Molecule from local workstation (where I have Python 3.7), in Travis CI (which has Python 2 and Python 3 available... depends on the environment), and GitHub Actions (which defaults to Python 3).

There may be some speed bumps once this lands, but I approve of the general idea, since Python 2.7 is getting harder and harder to support unless you live in RHEL 6 or 7-land.

@nmusatti
Copy link

Wouldn't this make it unusable on RHEL/CentOS 7? The problem I see is that at least for the time being there is no Python 3 binding for libselinux on EL7, so you have to run Ansible on Python 2.7

@tadeboro
Copy link
Contributor

@nmusatti This change will make it almost impossible to run Molecule on RHEL/CentOS 7. But, as @ssbarnea already said, you can still use Molecule to test your stuff on those systems.

@ssbarnea
Copy link
Member Author

@nmusatti Yes and no at the same time. AFAIK, Centos 7.8 will include libselinux for python3. Also, this requirement is for the controller host running molecule itself. You can still test managed hosts that have any version of python, or even not having python at all.

Obviously that if your use case was "running with delegated driver on centos-7", you will pretty much have to pin down molecule or reconfigure the scenarios to avoid this.

We already have few jobs on OpenStack TripleO that are going to be impacted, but they will be gone soon, replaced by either centos-8 or using workarounds.

ssbarnea added a commit to ssbarnea/molecule that referenced this issue Mar 26, 2020
ssbarnea added a commit to ssbarnea/molecule that referenced this issue Mar 26, 2020
ssbarnea added a commit to ssbarnea/molecule that referenced this issue Mar 26, 2020
@sshnaidm
Copy link
Contributor

While I'm for gradual removing py2 everywhere, I think it should be done within a reasonable time frame with a deprecation notice. At least people who install in CI latest version of molecule on CentOS-7 will have time to pin it to last 2.7 supporting version.

@ssbarnea
Copy link
Member Author

@sshnaidm Users using semantic versioning ranges will not be affected. In fact we already do this in several places where we have something like molecule>=3.0.2,<3.1.

We are forced to do the drop ASAP because CI is currently broken and nothing else can merge. I tried fixing and few good hours later I realised that the battle to keep py27 alive is... futile.

@sshnaidm
Copy link
Contributor

@ssbarnea for CI you need to use upper-constraints. Total removing of py2 support is big overhead for solving this problem.

Users using semantic versioning ranges will not be affected

Yes, and there are very few of such. Need to focus on users that WILL be affected, not to search which one wouldn't be.

@gundalow
Copy link
Contributor

I just wanted to say I really appreciate that everybody took the time to give feedback on this.

THANK YOU ALL.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
critical proposal Suggestion for a larger change
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants