Differences

This shows you the differences between two versions of the page.

--- bloglike:2020-12 [2020/12/30 14:25] – unit tests stybla
+++ bloglike:2020-12 [2020/12/31 14:36] (current) – add EBT deploy stybla
@@ Line 50: / Line 50: @@
 In the end, I've managed to reproduce issue by executing migration as ''subprocess'' and then execute small script which tries to read migrated cache. Lo and behold, this produced exactly the same Traceback.
-The problem was the fact that I wanted migration to be frozen in time and work exactly the same even if ''dataclass'' is extended or changed in ''rss2irc.py''. Therefore, I've duplicated(copy pasted) ''dataclass'' from ''rss2irc.py'' into migration script. However, ''pickle'' saves the name of the module as well. (Theory) This is fine for ''rss2irc.py'', because module name, ''__main__'', is same in given context, but not when executed from eg. ''rss2slack.py'' which calls ''rss2irc.read_cache()''. Issue has been fixed in [[https://github.com/zstyblik/rss2irc/pull/6|rss2irc PR#6]] including proper unit test.
+The problem was the fact that I wanted migration to be frozen in time and work exactly the same even if ''dataclass'' is extended or changed in ''rss2irc.py''. Therefore, I've duplicated(copy pasted) ''dataclass'' from ''rss2irc.py'' into migration script. However, ''pickle'' saves the name of the module as well. (Theory) This is fine for ''rss2irc.py'', because module name, ''%%__main__%%'', is same in given context, but not when executed from eg. ''rss2slack.py'' which calls ''rss2irc.read_cache()''. Issue has been fixed in [[https://github.com/zstyblik/rss2irc/pull/6|rss2irc PR#6]] including proper unit test.
 Take away is that unit and integration tests are not bulletproof. If tests are either written incorrectly or testing the wrong thing or wrong way, tests can give misleading results or provide false sense of security/confidence. Tests are the best effort, although this seems to be rather harsh and improper expression(I'm unable to think of better one, sorry). Anyway, is it worth writing tests then? Absolutely.
  --- //[[stybla@turnovfree.net|Zdenek Styblik]] 2020/12/30 20:12//
+===== When AWS Elastic Beanstalk deploy fails for no reason =====
+I've heard couple rumors that AWS Elastic Beanstalk(EBT) can end up belly up for no reason. It almost seemed like this can happen at random. Ok, seriously - this is one of pain points and drawbacks of EBT and deploys. I waived it off since no details were provided and when something like that happens, I'm going to deal with it. What else?
+It did happen to us. Simple change like any other. Test at ''localhost'' was a OK and so were unit tests/CI. The same cannot be said about deploy. It failed, crashed, burned and left no return address. Deploy crashed in one of ''.ebextension''/''.platform'' hooks. Unfortunately, this was some time ago and I didn't keep the logs. This part was working before and was not touched by MR. However, that was the only lead(error) I could find in AWS CloudWatch logs. As usual this was misleading. Also, container was being killed so fast, one couldn't catch any logs. Enough of blabbering, database migration was to blame, because data couldn't be migrated for one reason or another, and there is ''/var/log/eb-docker/containers/eb-current-app/unexpected-quit.log'' you should check in case something like that happens. Note that there is a 50:50 chance rollback to previous version will be successful and happen(don't be surprised if it does not). It's probably somewhere in documentation, although I cannot find it right now. Anyway, nothing new since EBT is quite old platform and everybody knows this one.
+ --- //[[stybla@turnovfree.net|Zdenek Styblik]] 2020/12/31 19:40//