amplify-education/asiaq

asiaq's Issues

Specify supported Python versions

Seems like Python 3 is not supported. Would be nice to reflect this in Installation section of README

Should we register asiaq with python package index

Since it is open source now. Should we officially register Asiaq to python's package system?

Do we need examples or tutorials to tell users how to create their own configuration repo

There is a sample configuration in Asiaq. As a new user I am kind of puzzled by where to put my configuration(s). And I would like some suggestion from original developers.

Add Travis CI status to Asiaq, NTH -- coverage

I think if we want more users to participate Asiaq's ecosystem. We should adopt some common practice in github.

For examples, Boto has an icon to display current build status. Moto even shows up coverage. Both give users confidence on our code in their environments.

License Policy Violation detected in certifi-2024.2.2-py3-none-any.whl

License Policy Violation detected in certifi-2024.2.2-py3-none-any.whl

Library - certifi-2024.2.2-py3-none-any.whl

Python package for providing Mozilla's CA Bundle.

Library home page: https://files.pythonhosted.org/packages/ba/06/a07f096c664aeb9f01624f858c3add0a4e913d6c96257acb4fce61e7de14/certifi-2024.2.2-py3-none-any.whl

Path to dependency file: /requirements.txt

Path to library: /requirements.txt

Dependency Hierarchy:

• requests-2.31.0-py3-none-any.whl (Root Library)
  • ❌ certifi-2024.2.2-py3-none-any.whl (Library containing License Policy Violation)

Found in HEAD commit: 7caccee522e37735d9c43392ece0bdd3cd88cae7

Found in base branch: main

📃 License Details

Mozilla 2.0
License Reference File: https://index.whitesourcesoftware.com/gri/app/reader/resource/content/asString/fc7bc954-42e2-4c44-a342-b25a1d7a1a35

    ⛔ License Policy Violation - [Reject][Global] Block CopyLeft Licenses

DiscoDeploy's handle_nodeploy_ami and handle_tested_ami are not safe

Both of these methods work in similar way:

1. Change autoscaling group's AMI
2. Scale up number of instances in group (double it)
3. Perform tests
4. Scale back to original group size

The problem is that if there is an error in step 3 or 4 then double the normal instance count is maintained. If this operation is performed multiple times against the autoscaling group number of hosts will start growing exponentially. This is not good.

Possible solutions:

1. Make step 3 and 4 more robust. This is not ideal as failure is always possible even with infinite retry and no timeouts.
2. Instead of looking up current size of autoscaling store the original number somewhere else and use it to figure out intermediate and final size. Ideally a tag or something similar. If on step 0, current actual size > final desired size then fail.

[Defect] testing ASG should be span down if tests failed

When the deployenator fails in the middle of deploy asiaq doesn't destroy testing ASG and AMI is not available to re-run.
If blue-green deploy fails, testing ASG should be destroyed so it's possible to re-run the job with the same AMI

[Feature Request] option to disable auto-promote with disco_deploy.py test

Currently disco_deploy.py test does provision and test new untested AMI in CI and automatically promote it to Staging if all tests pass.

But in Burst we ran into an issue where some db schema changes have been made manually in CI for development but not yet available in Staging. Because tests work fine in CI, new AMIs are tested and auto-promoted. This causes inconsistency between database and code, therefore raises error in Staging.

There are two ways to work around this problem.

1. Add an option to only provision and test AMIs with disco_deploy.py test
2. Add integration tests on Staging as soon as possible, and mark any failed AMIs as failed and therefore no new instances are provisioned in Staging.

As an immediate solution, it looks that former option may be easier to implement.

Let me know your thoughts. Any suggests are welcomed.