21:00 <tsimonq2> #startmeeting LoCo Portal Planning Meeting 21:00 <meetingology> Meeting started Wed Mar 23 21:00:01 2016 UTC. The chair is tsimonq2. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 21:00 <meetingology> 21:00 <meetingology> Available commands: action commands idea info link nick 21:00 <daker> yo 21:00 <tsimonq2> hey daker :) 21:01 <tsimonq2> so this is the second LoCo Portal planning meeting 21:01 <tsimonq2> a little bit smaller than the last but I have some topics in mind 21:01 <tsimonq2> even if it's just with daker, this will be valuable :) 21:01 <tsimonq2> okay 21:01 <tsimonq2> #topic Meeting Time 21:02 <tsimonq2> I sent out the reminder for this meeting a bit late, and daylight savings time messed things up again 21:02 <tsimonq2> do we want to keep the time of 21 UTC or do we want to pull back to 20 UTC? 21:02 <tsimonq2> daker: thoughts? 21:03 <daker> 21 is good 21:03 <daker> well at least for me :) 21:03 <tsimonq2> alright, I'll give until 21:05 for people to object, then we can move on :) 21:05 <tsimonq2> so it seems that not many people are here 21:05 <superfly> o/ 21:05 <superfly> I'm here :-) 21:05 <tsimonq2> oh hello superfly :) 21:05 <tsimonq2> daker: do you have the IS response nearby? 21:06 <tsimonq2> #topic IS Response about the server 21:07 <tsimonq2> daker: I'm hunting it down now if you can't find it 21:08 <daker> https://paste.ubuntu.com/15482854/ 21:08 <tsimonq2> okay, cool, thanks daker :) 21:08 <daker> recap : IS recommendation is to stick with 1.3.1 21:09 <tsimonq2> So I've read this a few times, here's my opinion 21:09 <tsimonq2> I think that we test it and make sure it works on Trusty 21:09 <tsimonq2> upgrade to Trusty 21:09 <superfly> I agree with tsimonq2 21:09 <tsimonq2> then over the summer we test with Xenial and upgrade to Xenial 21:09 <daker> tsimonq2: you can't upgrade :) 21:09 <tsimonq2> well have IS do it 21:10 <tsimonq2> daker: wait we can't upgrade releases? 21:10 <superfly> also, you can install Django, et al in a virtualenv, and then you don't need to worry about the version in Ubuntu 21:10 <tsimonq2> ^ good point 21:11 <daker> tsimonq2: no, you can't just upgrade like that, the server was upgraded to precise in July 2015 21:11 <daker> precise :) 12.04 21:11 <tsimonq2> daker: then what do we have to work with in that regard? 21:12 <tsimonq2> Precise goes EOL next April, so we have about a year 21:12 <tsimonq2> I would much rather do it sooner than later 21:12 <tsimonq2> but we can only do what we can do :) 21:12 <daker> the recommendation is to stick with 1.3.x if we want to stay like that 21:13 <tsimonq2> daker: would it be possible to have IS upgrade the server to Trusty, or do we have to backport stuff? 21:13 <teward> tsimonq2: I would reread their email if I were you (apologies for appearing) 21:13 <daker> if we want to upgrade for Django for sure we need to write a juju charm 21:13 <teward> the email as it is currently states this: For the moment, while the site is hosted on a precise server, I would recommend sticking with 1.3 and addressing problems exposed by the Ubuntu upgrade. ... 21:14 <teward> without further knowledge, I'd interpret that to be "We don't want to upgrade this right now" 21:14 <daker> teward: yes 21:14 <tsimonq2> ohhhhh I see 21:14 <tsimonq2> sorry :) 21:14 <teward> and again, apologies for popping in, but I thought it would help to have the translation/interpretation made available :) 21:14 <daker> because they have planning on what to upgrades and when 21:14 <teward> tsimonq2: so, the email suggests: 21:15 <teward> (1) sticking to precise 21:15 <tsimonq2> totally okay teward :) 21:15 <teward> (2) work with the existing system and resolve existing issues 21:15 <teward> (3) possible-long-term: backport either trusty or xenial Django in a PPA, confirm it works, migrate site to that, show it works, and IS may consider using the PPA in that case 21:15 <teward> which is in the last paragraph of the email 21:16 <teward> with the backport target being precise. 21:16 <tsimonq2> well I see that, but I haven't been able to easily reproduce the server locally 21:16 <tsimonq2> that's another problem I wanted to bring up 21:16 <tsimonq2> it's a bit tricky 21:16 <tsimonq2> knowing what cron jobs the server uses would be extremely useful 21:16 <daker> tsimonq2: why ? it should work, we have fixed the issues 21:17 <daker> tsimonq2: cronjob for the portal ? 21:17 <tsimonq2> daker: well either the docs aren't there or the docs aren't obvious enough to locally set up a server with all of the functionality 21:17 <tsimonq2> like, we can do the portal 21:17 <tsimonq2> just stuff like the blog requires extra docs that I don't know about 21:18 <daker> ok, i'll document that 21:18 <tsimonq2> I think getting the cron jubs used on the server would be useful to document how it's updated 21:18 <tsimonq2> *jobs 21:18 <tsimonq2> okay, thank you daker :) 21:18 <tsimonq2> daker: mind creating an actuion with meetingology? 21:18 <tsimonq2> *action 21:19 <tsimonq2> or I can do it :) 21:19 <daker> you can do it for me :) 21:19 <teward> fyi: #action 21:19 <tsimonq2> #action daker: better document local setup of the LoCo portal 21:19 * meetingology daker: better document local setup of the LoCo portal 21:19 <teward> now that'll show in the minutes 21:19 <tsimonq2> knowing this would really speed up development, IMHO 21:21 <tsimonq2> so I think that for now we can ensure it works, then when Xenial is released, imho, we should backport Django from Xenial 21:21 <tsimonq2> daker: would that be reasonable to do? 21:22 <daker> tsimonq2: i have absolutely no idea with packaging, and backporting means also handling security issues :) 21:23 <daker> my recommendation is to stick with 1.3 for now, deploy the cronjob fix 21:23 <daker> then start writing a juju charm 21:24 <daker> with the charm i guess that put the portal in a VM instead of the physical server 21:24 <tsimonq2> so do you think the backport will be good at any point? 21:25 <tsimonq2> or do you think that it will just give us more work? 21:26 <daker> tsimonq2: i don't think so it will be good, it's a complicated work + packaging + handling django sec issues 21:26 <tsimonq2> ahh okay 21:26 <tsimonq2> so the current point we are at is to stick with 1.3.x, write a Juju charm for it, then make sure it works and maintain it? 21:27 <superfly> Without sounding like I'm harping on about the virtualenv... I reckon that using a virtualenv will be of more benefit in the long run. With a virtualenv you can set the version of Django that you're using. You're also isolating your version from the operating system, so that you can do things at your own pace if necessary. 21:27 <tsimonq2> (just to make sure we are clear) 21:27 <superfly> (and I'm presuming that you can do that in a Juju Charm too) 21:27 <tsimonq2> superfly: but if we change Django versions, that's a whole other thing we need to support 21:27 <tsimonq2> to clarify, Juju charms are justr for easy configuration 21:28 <tsimonq2> *just 21:28 <tsimonq2> (afair) 21:28 <superfly> tsimonq2: but you can change django versions when *you* want to, not when the operating system dictates 21:28 <tsimonq2> I see 21:28 <tsimonq2> daker: thoughts? 21:28 <tsimonq2> teward: you have experience with packaging, feel free to interject at any point :) 21:29 <teward> sorry, was in the middle of something else for Server team 21:29 * teward scrolls backwards 21:29 <daker> superfly: i don't think IS likes handling stuff with virtualenv 21:29 <daker> if it was possible they will say it 21:29 <tsimonq2> daker: could that question be asked? 21:30 <teward> tsimonq2: I would not be looking at the backport for now 21:30 <superfly> The biggest issue with backporting that you'll likely encounter is dependencies that you'd also have to backport 21:30 <daker> tsimonq2: i'll ask if you want, even if the answer is clear 21:30 <teward> Given that Precise EOLs in about a year, backporting will be a huge painful thing to do, as they suggested in the email may be a waste of time 21:30 <daker> tsimonq2: they don't install modules from pypi only archive ;) 21:31 <daker> teward: +1 21:31 <teward> for all the reasons I have the same headaches with nginx in the Server side, or znc on my own third-party, having to adapt to the much older software in Precise 21:31 <tsimonq2> ahh I see 21:31 <teward> (especially ZNC, as I have to pull in the ubuntu-toolchain test repo to make that build for Precise) 21:32 <tsimonq2> so should we continue to test to see if it works in Xenial and Trusty so when IS *does* upgrade, we have a plan? 21:32 <teward> tsimonq2: so, my recommendation would be to stick with 1.3, diagnose the cron issues, fix them as can be done, and not worry about the backport. 21:32 <teward> tsimonq2: correct. 21:32 <tsimonq2> okay, we need regression tests then, if not already implemented 21:32 <tsimonq2> that should be look at 21:32 <superfly> The age old tussel between devs and sysadmins... 21:32 <tsimonq2> I'll make an action 21:32 <tsimonq2> *looked 21:33 <teward> right, but note that IS alluded to this in their email - see lines 29 - 32 on your paste 21:33 <teward> "Regarding the future of loco.ubuntu.com, I would recommend selecting an Ubuntu LTS release to target, ideally xenial (but trusty would be fine), porting the site to its supplied version of Django (1.8 or 1.6, depending) and writing a Juju charm or charms to deploy the new site." 21:33 <teward> rather than the backporting item, which they *suggest* may be a way around it, but they also suggest "waste of time" given Precise EOL date 21:33 <tsimonq2> #action tsimonq2: Ensure regression tests are in place for the LoCo Portal 21:33 * meetingology tsimonq2: Ensure regression tests are in place for the LoCo Portal 21:34 <superfly> So basically get it working on Django-<version in xenial>, I think 21:34 <teward> ^ that 21:34 <tsimonq2> !infor django xenial 21:34 <teward> tsimonq2: 1.8 21:34 <tsimonq2> !info django xenial 21:34 <ubottu> Package django does not exist in xenial 21:34 <tsimonq2> lol 21:34 <teward> !info python-django 21:34 <ubottu> python-django (source: python-django): High-level Python web development framework (Python 2 version). In component main, is optional. Version 1.7.9-1ubuntu5.4 (wily), package size 952 kB, installed size 10793 kB 21:34 <teward> !info python-django xenial 21:34 <ubottu> python-django (source: python-django): High-level Python web development framework (Python 2 version). In component main, is optional. Version 1.8.7-1ubuntu4 (xenial), package size 842 kB, installed size 9075 kB 21:34 <teward> Or, from rmadison: 21:35 <teward> python-django | 1.6.1-2 | trusty | source, all 21:35 <teward> python-django | 1.8.7-1ubuntu4 | xenial | source, all 21:35 <tsimonq2> okay, so we know what's going to happen going forward? 21:35 <teward> (with other ubuntu spevcific changes in trusty-updates,-security) 21:35 <tsimonq2> teward: or are you implying a different point here besides what's already been established? 21:35 * tsimonq2 can't tell :) 21:36 <teward> [2016-03-23 17:34:17] <superfly> So basically get it working on Django-<version in xenial>, I think 21:36 <teward> OR 21:36 <teward> Django-<version in trusty> 21:36 <teward> Ideally, they want to put it on Xenial (read their email!), but would also settle for Trusty if need be 21:37 <tsimonq2> so I think the priority would be Trusty because that's the next hop up, but Xenial is a priority as well :) 21:37 <superfly> I'm not a Django person, but AFAIK, 1.8 is current-1, so that would be the best one to target 21:37 <teward> tsimonq2: let me rephrase: the IS team wants, ideally, to move to Xenial, not Trusty 21:37 <superfly> I think both 1.6 and 1.7 are already put out to pasture 21:37 <teward> I would start by a port to Xenial's version, determine if it's feasible, and easily done 21:37 <tsimonq2> mhm 21:38 <tsimonq2> but I wouldn't forget Trusty 21:38 <tsimonq2> I see what you are saying 21:38 <tsimonq2> but just in case 21:38 <daker> so 1.8 is an LTS wich is good 1.6 is unsupported 21:38 <superfly> I don't see the point of trusty. you're going to have a big jump, whether to move to trusty or xenial, I think it makes more sense to just jump to xenial. less effort 21:39 <teward> if not, then I would fall back to the version in Trusty, as a secondary solution 21:39 <teward> either way there'll be headaches moving from (ancient) 1.3 to 1.6 (Trusty) or 1.8 (Xenial) 21:39 <teward> tsimonq2: start by targeting Xenial, though I doubt it'll be done until after Xenial releases. 21:39 * teward makes a note to replace his wifi access point at a later time 21:39 <teward> what was my last message? 21:39 <tsimonq2> superfly, teward: that's ultimately IS's decision, although we should prepare either way, let's consider Trusty and Xenial equal priority, just in case, although I get what you are saying :) 21:40 <teward> tsimonq2: i'd still target Xenial first (Django 1.8), before going to Trusty (Django 1.6) 21:40 <teward> that's all :) 21:40 <daker> tsimonq2: xenial 21:40 <teward> per IS's ideal situations 21:40 <daker> 1.6 is alreay outdated 21:40 <teward> indeed 21:40 <daker> and 1.8 is an LTS supported til 2018 21:41 <tsimonq2> alright, creating an action :) 21:41 <teward> also note I don't know Django, so any part of that migration is not something I can assist with; though I'm happy to make suggestions and such when pinged for my input :) 21:41 <tsimonq2> #action Ensure the LoCo Portal works with Xenial's version of Django 21:41 * meetingology Ensure the LoCo Portal works with Xenial's version of Django 21:42 <tsimonq2> so is that all we needed to talk about? 21:42 <tsimonq2> #topic Misc. 21:42 <tsimonq2> I think we are good? 21:43 <daker> the fix for the cronjob is here https://code.launchpad.net/~daker/loco-team-portal/fix.1542697/+merge/289581 21:43 <tsimonq2> I saw :) 21:43 * tsimonq2 is happy 21:44 <daker> and we are done ? 21:45 <tsimonq2> I think so 21:45 <tsimonq2> I'll leave this open until 22 UTC for people to jump in if desired 21:45 <tsimonq2> if they are reading and don't understand something or have something to add :) 21:45 * superfly has nothing further to say :-) 21:51 <teward> I don't think there's anything else, tsimonq2, perhaps #endmeeting is appropriate? 21:51 <teward> (further points can be brought up outside the meeting if need be) 21:54 <tsimonq2> #endmeeting