=== pip is now known as Guest19552
[02:15] <Guest19552> tas
=== frankban|afk is now known as frankban
[11:06] <digv> which Minimum Kernel should I choose if I want 4.4.* kernel for charm deployment?
=== mup_ is now known as mup
=== frankban is now known as frankban|afk
=== beisner_ is now known as beisner
=== zeus is now known as Guest47987
=== rick_h changed the topic of #juju to: Juju as a Service Beta now available at https://jujucharms.com/jaas | https://review.jujucharms.com/ | https://jujucharms.com/docs/ | http://goo.gl/MsNu4I || https://www.youtube.com/c/jujucharms
[20:24] <skay> I have a django app deployed with a really old inscrutable juju charm. I'm in the process of upgrading the django app so that it uses native django migrations instead of south migrations
[20:24] <skay> this means that on initial deployment of the upgraded stuff, I need to run a migration with --fake
[20:25] <skay> I'm not sure how to have that happen with a charm, much less an old inscrutable one
[20:25] <skay> subsequent deployments would just call migrate
[20:49] <mat128> skay: identify which table native django migrations use and make sure they state what django expects so that it doesnt upgrade them again
[20:51] <skay> mat128: er, native django migrations run against the same tables that the south migrations ran against. https://docs.djangoproject.com/en/1.7/topics/migrations/#upgrading-from-south
[20:51] <mat128> skay: so I assume running "django migrate" on top of your existing database (run it against a copy first!) will simply no-op, right?
[20:52] <mat128> in that case what is the problem?
[20:53] <skay> mat128: like the link says, we have to run --fake due to reasons
[20:53] <skay> mat128: indeed I have been testing against a copy of the database while doing all of this
[20:54] <mat128> skay: My best bet would be to run the django migrate --fake outside of your charm
[20:54] <mat128> I assume it only marks all migrations as "done"
[20:55] <mat128> skay: are you running into the circular foreign keys?
[20:56] <skay> mat128: I was hoping to run it outside the charm, but due to the way the charm is written, it only grabs the updated src from the django app when the upgrade-charm command is called. this means that I can't run a management command by hand with teh new src
[20:56] <mat128> juju ssh?
[20:56] <skay> mat128: not sure if it was the circular foreign keys that caused the problem, but I think so
[20:56] <mat128> skay: the guide mentions running with --fake only on circular keys issues, otherwise it's a straightforward upgrade
[20:57] <skay> juju ssh is no good. what the charm does on upgrade is to get a tarball of the latest version of the app... so, the new code won't be on the unit before a charm upgrade is called
[20:57] <skay> it is not how I'd write a charm, but it's what I have to work with
[20:58] <mat128> can you edit it somehow?
[20:58] <skay> I think changing the charm would be tantamount to writing a new one
[20:58] <mat128> skay: a different approach would be to look at what --fake does (maybe run it locally and see?) and just import that data back into the database
[20:59] <skay> that's an interesting idea
[20:59] <mat128> make sure you run it for the right version of the app though
[21:00] <skay> mat128: thanks for the thoughts
[21:01] <mat128> np, good luck with your project :)
[21:02] <skay> it's a doozy. I want to do the minimal amount to get me to django LTS and keep running in to things where I want to rewrite the charm, etc.
=== Guest47987 is now known as zeus`
=== zeus` is now known as zeus