| === pip is now known as Guest19552 | ||
| Guest19552 | tas | 02:15 |
|---|---|---|
| === frankban|afk is now known as frankban | ||
| digv | which Minimum Kernel should I choose if I want 4.4.* kernel for charm deployment? | 11:06 |
| === 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 | ||
| 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:24 |
| 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:25 |
| 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:49 |
| 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:51 |
| mat128 | in that case what is the problem? | 20:52 |
| 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:53 |
| 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:54 |
| mat128 | skay: are you running into the circular foreign keys? | 20:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| skay | that's an interesting idea | 20:59 |
| mat128 | make sure you run it for the right version of the app though | 20:59 |
| skay | mat128: thanks for the thoughts | 21:00 |
| mat128 | np, good luck with your project :) | 21:01 |
| 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. | 21:02 |
| === Guest47987 is now known as zeus` | ||
| === zeus` is now known as zeus | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!