[20:58] <tsimonq2> wxl, pleia2, daker: You were around for the last LoCo Portal Planning meeting, you around now for the meeting that's supposed to start in two minutes? :)
[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> 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:07] <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> ACTION: 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> ACTION: 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] <tsimonq2> lol
[21:34] <teward> !info python-django
[21:34] <teward> !info python-django xenial
[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> ACTION: 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
[21:54] <meetingology> Meeting ended Wed Mar 23 21:54:32 2016 UTC.
[21:54] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2016/ubuntu-meeting.2016-03-23-21.00.moin.txt
[21:54] <tsimonq2> there :)
[21:54] <tsimonq2> thanks for your help teward :)
[21:54] <tsimonq2> and thanks again daker and superfly :)
[21:55] <daker> yw
[21:58] <teward> yep
[21:59] <superfly> yw