chore!: drop python 3.6 support

[dbluhm]

Update setup.py minimum python version requirement.
Update workflows to use Python 3.9 by default.
Update container image docs.

@swcurran @WadeBarnes I believe these are the relevant changes in workflows and setup files in order to officially drop Python 3.6. I think once we've made the transition, there are a number of dependencies that ought to be updated. I think those updates are best suited to a follow up PR.

closes: #2244

[dbluhm]

The integration test action used von-image as a base which had python 3.6 installed. I switched the base image to a locally built indy base image (indy-base target in Dockerfile.indy). However, this is not currently caching the image build so this adds a significant amount of time to the action (since building Indy takes a while). We could switch to running the integration tests on Askar (maybe it already is?) to reduce build time in the integration test action.

[swcurran]

Could we not add a new von-image that is based on Python 3.9 so everything is essentially the same? Definitely think we should be use Askar as the default.

[swcurran]

LGTM, but deferring to @WadeBarnes for a final answer and merge.

[dbluhm]

Integration tests didn't finish cleanly -- I'll have to take a closer look

[dbluhm]

I'll try to keep this timely but if someone beats me to it, contributions are welcome

[WadeBarnes]

Some minor recommendations

[WadeBarnes]

Once the integration tests are working, I'll have to switch over the Python 3.9 Tests over to the Required ones:

[WadeBarnes]

The integration tests are running through to completion locally for me. It seems like they are getting hung up somewhere in GHA.

[swcurran]

So good to merge then, @WadeBarnes ?

[swcurran]

@dbluhm — can you update the branch so we can merge?

[WadeBarnes]

So good to merge then, @WadeBarnes ?

@swcurran , Not yet, there are some changes that need to be made. @dbluhm, I can make the changes if you agree to them.

[dbluhm]

I agree with the recommended changes. I wondered if it made sense to continue to test against 3.7 and 3.8 but given that I bumped the minimum version to 3.9, that wouldn't really make sense.

[dbluhm]

@WadeBarnes if we update lines like this one in the demo, we could probably change the base from von-image or indy-base to just a standard python image. This would remove the opportunity for running with Indy in the demo, though, since the library wouldn't be available in the image.

[swcurran]

Who’s got the ball on this one? I’d really like to get this merged...

[WadeBarnes]

In my court. I'll get things done first thing in the morning.

[WadeBarnes]

@dbluhm, I've made the changes, however I'm unable to push them to the Indicio-tech:chore/drop-py3.6 branch. It seems the permission for maintainers to edit was not set when the PR was created. I can PR to Indicio-tech:chore/drop-py3.6 directly if needed. Let me know.

The changes are currently sitting here: WadeBarnes:chore/drop-py3.6

[dbluhm]

@WadeBarnes I merged your branch locally and pushed but I'll see if I can push the right buttons to allow edits from maintainers in case any other changes are needed. It might be because I opened it from Indicio's fork and permissions on our org, not sure.

[WadeBarnes]

@WadeBarnes I merged your branch locally and pushed but I'll see if I can push the right buttons to allow edits from maintainers in case any other changes are needed. It might be because I opened it from Indicio's fork and permissions on our org, not sure.

Thanks, You should see a checkbox on the PR for the edit option. Example:

[WadeBarnes]

Lots of timeout errors in the integration tests. I'll have to look into those.

[dbluhm]

No such box, unfortunately 😞 I suspect it is an org permissions thing. I'm happy to close this PR in favor of one you open. Also happy to merge in changes as before. Whatever is most convenient for you!

[WadeBarnes]

Lets figure out the issue with the test first and then decide how to proceed.

[WadeBarnes]

Quick update on the integration test issue. It's definitely something to do with the differences in the base images used for the bdd tests. When using the original base image the tests run to completion. When using the updates that use the indy-base image there are timeout errors. What's strange is the issues only occur on GHA, when the same setup is used locally on an Ubuntu devContainer the tests run just fine.

Run using the original base image setup:
https://github.com/WadeBarnes/aries-cloudagent-python/actions/runs/5147239795

Runs using the updated base image setup:
https://github.com/WadeBarnes/aries-cloudagent-python/actions/runs/5146808656/jobs/9266369701

• Using this setup, the tests run locally without issue.

[WadeBarnes]

Suspecting a startup timing issue. Testing that theory.

Edit: That's not it

[WadeBarnes]

The issues are related to the Python version of the base, indy-base container. I've tested with 3.6, 3.7, 3.8, and 3.9. The crashing and hanging issues start occurring with python 3.8 on GHA, yet locally using a docker-in-docker devContainer I can run the tests successfully with python 3.8 and 3.9. With the @T001-RFC0160 tests the Mediator.Agent.8035 agent fails to start in a timely fashion, errors occur and the tests end up hanging.

[WadeBarnes]

I need a little help with this issue. I'm not having much luck tracking down why the tests will run locally but not in GHA. My most recent run of the tests with logging set to info is here; https://github.com/WadeBarnes/aries-cloudagent-python/actions/runs/5214202473/jobs/9410171574. In the scenario were a mediator is created for both Acme and Bob, Bob's mediator never starts, and there are no logs to indicate any possible errors. There is also this run with logging set to debug https://github.com/WadeBarnes/aries-cloudagent-python/actions/runs/5213743145/jobs/9409134016.

I'm hope I'm missing something simple.

I've limited the testing to -t @T001-RFC0160 since that reproduces the issue. Locally that looks like LEDGER_URL=http://test.bcovrin.vonx.io PUBLIC_TAILS_URL=https://tails-test.vonx.io LOG_LEVEL=info NO_TTY="1" ./run_bdd -t @T001-RFC0160

I've added the devContainer I'm using for local testing to the troubleshoot-integration-tests of my fork.

[dbluhm]

I'll see if I can squeeze in some time to analyze!

[dbluhm]

I attempted increasing timeouts on the off chance it simply wasn't ready in time and observed the same failures. I've reverted the timeout change.

[dbluhm]

For posterity's sake, the issue was resolved by increasing the number of workers on the thread pool used to spawn the subprocesses for the mediators in the integration tests. On github action runners, the default pool size was 10 (number of processors * 5). This default changed in 3.8 and witnessed in our tests in 3.9:

Changed in version 3.8: Default value of max_workers is changed to min(32, os.cpu_count() + 4). This default value preserves at least 5 workers for I/O bound tasks. It utilizes at most 32 CPU cores for CPU bound tasks which release the GIL. And it avoids using very large resources implicitly on many-core machines.

Found here: https://docs.python.org/3.9/library/concurrent.futures.html#concurrent.futures.ThreadPoolExecutor

So max number of workers dropped from 10 to 6 by default, preventing the mediator process from spawning because the pool was full.

[dbluhm]

@swcurran What is the order of operations required to get this merged? We need to finalize 0.8.2, right?

[WadeBarnes]

@swcurran, has requested this be merged after the pending release. I'll make the updates to the required checks right before this PR is merged, otherwise it will adversely affect other pending PRs.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[WadeBarnes]

LGTM

[WadeBarnes]

Once the tests are complete I just need to adjust the required status checks before merging.

[WadeBarnes]

Required checks have been updated to