19:00:25 <stickster> #startmeeting Insight (Agenda: http://tinyurl.com/insight-agenda)
19:00:25 <zodbot> Meeting started Mon Apr 18 19:00:25 2011 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:26 * nirik is around, but afk for a few minutes...
19:00:29 <stickster> #meetingname Insight
19:00:29 <zodbot> The meeting name has been set to 'insight'
19:00:32 <stickster> #topic Roll call!
19:00:52 <nirik> here, but have to be away for a minute or 5... back then.
19:00:59 <stickster> Sure, thanks nirik
19:01:04 * stickster (of course)
19:01:42 * stickster notes that if he doesn't see someone besides himself, rbergeron, and nirik here, this will be a short meeting :-)
19:02:12 * jsmith is here
19:02:44 <stickster> #info Present: jsmith rbergeron nirik stickster
19:02:49 <stickster> #chair jsmith rbergeron nirik
19:02:49 <zodbot> Current chairs: jsmith nirik rbergeron stickster
19:02:55 <stickster> #topic Last week's action items
19:03:07 <stickster> #link http://meetbot.fedoraproject.org/fedora-meeting-1/2011-04-04/insight.2011-04-04-19.00.html <-- last week's minutes
19:03:20 <stickster> rbergeron finished a draft SOP
19:03:22 <stickster> oops
19:03:33 <stickster> #info 1 - rbergeron finished a draft SOP, asking for review on the list
19:03:45 <stickster> #info 2 - Sparks started review of bug 693117, bad URLs corrected
19:03:48 <stickster> #chair pcalarco
19:03:48 <zodbot> Current chairs: jsmith nirik pcalarco rbergeron stickster
19:03:50 <stickster> Hi Pascal!
19:04:03 <stickster> #info Present: jsmith rbergeron nirik stickster pcalarco
19:04:03 <pcalarco> stickster: sorry I am late, Hi!
19:04:07 <stickster> No problem :-)
19:04:11 * stickster just going over action items
19:04:27 <stickster> #info 3 - stickster has not made puppet changes since new host was not available until now, but this will happen ASAP
19:04:38 <stickster> #action stickster make puppet changes required for staging/dev switcheroo
19:04:53 * nirik is back
19:05:21 <stickster> #info 4 - averi notes we are actually deleting publictest09 shortly, since everything is being migrated to the new insight.dev host
19:05:37 <stickster> #info 5 - averi did the RFR, and insight.dev.fp.o is up and running!
19:05:45 * rbergeron pops
19:05:46 <rbergeron> err
19:05:47 <rbergeron> pops in
19:05:47 * nirik nods. Hopefully this will meet your needs.
19:05:54 <stickster> #info 6 - Haven't seen new tickets from asrob, but this can continue
19:06:14 <stickster> #action asrob File tickets for phase 2 work, document and test on .dev host now that it's available
19:06:28 <stickster> #action stickster Get asrob admin access on insight.dev host using the new 'sysadmin-insight' group
19:06:52 <stickster> OK, that does it for last week -- sorry for the long monologue folks. The above is a good indicator that things are moving right along :-)
19:06:55 <nirik> insight01.dev => devel work, you can local install packages, or use puppet, no proxies in front of it. sysadmin-insight has sudo/access.
19:07:35 <stickster> nirik: Yes, that's superb and will REALLY be helpful for us. I have one request -- a package under review that we need on production + staging to perform our change process. It's listed in:
19:07:38 <stickster> .bug 693117
19:07:40 <zodbot> stickster: Bug 693117 Review Request: drupal6-backup_migrate - Database backup, restore, and migrate module for Drupal 6 - https://bugzilla.redhat.com/show_bug.cgi?id=693117
19:08:20 <stickster> I need to get that included in the infrastructure repo so I can add it to the puppet definitions for our Insight boxes in staging/prod
19:08:32 <nirik> ok. any ideas how far out the review is?
19:08:41 <nirik> if we can get it in epel-testing we could just install from there.
19:08:43 <stickster> nirik: sparks just started it, I got some bug mail today
19:08:47 <nirik> ok
19:09:08 <stickster> nirik: It's according to a template we use for other modules, so it shouldn't take a lot of time to finish the review -- then figure approximately 2 weeks + a couple days for build/push cycle for EPEL
19:09:29 <stickster> So maybe 3 weeks total?
19:09:33 <nirik> sure, but we could short circut by installing from testing if need be...
19:09:42 <stickster> Oh yeah, we have that available, I forgot.
19:10:01 <nirik> or infra. We can work it out out of band...
19:10:11 <stickster> Cool nirik, I'm down with that.
19:10:52 <stickster> #info nirik and stickster will get the backup_migrate module package available for staging/prod
19:11:02 <stickster> #action stickster add backup_migrate module package to insight.dev
19:11:11 <stickster> #action sparks Finish bug 693117 review
19:11:43 <pcalarco> I have one comment regarding averi's pt09 note
19:11:46 <stickster> For those of you rattling your jewelry in the cheap seats... the reason that's important is that we need to be able to migrate data back and forth as we add functionality
19:11:57 <stickster> pcalarco: I'll topic to make things clearer
19:12:05 <stickster> #topic Development and pt09 host status
19:12:19 <stickster> #info Some information found in the action items section above :-)
19:12:23 <stickster> Go ahead pcalarco !
19:12:47 <pcalarco> just noting that the bug at https://fedorahosted.org/fedora-infrastructure/ticket/2726 is still there and having both pt09 to compare to staging might be helpful
19:13:08 <pcalarco> #link https://fedorahosted.org/fedora-infrastructure/ticket/2726
19:13:53 <nirik> well, there's no immediate need to remove pt09... but you could migrate all stuff from it to insight01.dev as you can...
19:13:53 <stickster> pcalarco: Ah, I see -- you're right. I think I know what's causing that, I should note it in the ticket after investigating, so we can tweak it easily on insight.dev.
19:14:48 <stickster> pcalarco: So staging has it wrong, correct?
19:14:58 <pcalarco> stickster: yes
19:15:53 <stickster> pcalarco: OK, I'm betting that we need to attach a value to each beat to get the ordering correct, then adapt the view accordingly.
19:16:48 <pcalarco> I think we do already; we pick off the appropriate beat in the FWN content type
19:17:07 <stickster> pcalarco: By "pick off" you mean...?
19:17:30 <pcalarco> drop down menu selection, sorry :)
19:17:35 <stickster> Sorry, I swear I'm not trying to be difficult... things get really complex quickly in CMSes unless we are talking apples to apples
19:17:44 <pcalarco> np :)
19:17:45 <stickster> pcalarco: Ah, yes
19:18:14 <stickster> pcalarco: So that drop down is populated in whatever order is in the SQL from the "allowed values" list used in defining the field type for field_beat
19:18:36 <stickster> But there's no *implicit* value assigned to the allowed values... so the View is interpreting it as alphabetical
19:19:16 <stickster> We can fix that by either introducing a first value into the array, or if possible just adapting the view to go by the SQL ordering
19:19:22 <stickster> er, SQL key value
19:19:32 * stickster hasn't dug into it to see if that's possible
19:20:05 <stickster> #info Need to see if we can order in the 'fwn' view by field_beat's SQL key value
19:20:09 <pcalarco> stickster: I am entering these in the order in which I want them to appear, so I think on pt09 it is ordering them by the lowest value for the FWN content type for each FWN issue
19:20:35 <stickster> pcalarco: And on staging, you entered them in the same order, but they show up alphabetically -- correct?
19:20:36 <pcalarco> assuming there is an internal value for the nodes in the queue
19:20:45 <pcalarco> stickster: yes, correct
19:20:47 <stickster> Ha
19:21:01 <stickster> I know what caused it then. It was adding a 'key' in the array for the field_beat content type
19:21:27 <stickster> Doing that probably overwrote the implicit 'key' values of 0, 1, ... that are used in pt09 with 'introduction', 'ambassadors',...
19:21:47 <stickster> Thus the ordering now happens alphabetically because that's what makes sense in SQL
19:22:06 <stickster> If we rename those keys as '0-introduction', '1-somethingelse', ... then it should magically get fixed
19:22:07 <pcalarco> stcikster: that makes sense, yes
19:22:38 <stickster> However, the renaming needs to be accompanied by altering the DB to fix those keys globally with UPDATE statements
19:23:06 <stickster> I know how to do all that, it's not a big deal -- just need the backup_migrate in place so we can pull the data to .dev, fix it, then copy it back to staging/production
19:23:37 <pcalarco> stickster: thank you very much!
19:23:42 <stickster> pcalarco: No problem
19:23:58 <stickster> #action stickster fix the key ordering problem in https://fedorahosted.org/fedora-infrastructure/ticket/2726 once backup_migrate is available
19:24:28 * stickster has to run afk for 60 sec, brb
19:25:34 <stickster> back
19:26:46 <stickster> pcalarco: Maybe we should #topic to the change proposal process which will make the new world order clearer :-)
19:27:09 <pcalarco> stickster: :)
19:27:13 <stickster> #topic Change process proposal
19:27:26 <stickster> #info stickster wrote https://fedoraproject.org/wiki/How_to_develop_for_Insight for this purpose
19:28:34 <pcalarco> is staging preproduction, and will we have this ongoing once we are in production?  Or will staging become our new test server when we are in production?
19:28:48 <stickster> pcalarco: The latter
19:28:50 <stickster> #info Basic NWO: (1) We blow away pt09, taking DB backup for posterity
19:29:17 <stickster> #info (2) We use insight.dev.fp.o for development and any untested fixes, with the knowledge that at any moment, the installation there can go poof
19:29:34 <pcalarco> stickster: thanks for the clarification; that was the only question I had in reviewing this; looks very clear
19:30:09 <stickster> #info (3) The backup_migrate module is used to snapshot back to insight.stg.fp.o, and then fixes tested on insight.dev.fp.o are redeployed there to test them
19:30:57 <stickster> #info (4) Then the DB is redeployed to insight.fp.o (production)
19:31:03 <nirik> staging has proxy's and such like production, where dev doesn't.
19:31:21 <stickster> Yup, exactly, so we don't have to worry about caches and what not while testing
19:31:55 * stickster notes there is an implicit lag between (3) and (4), which is why we should plan staging and production runs at a set time.
19:32:11 * nirik nods.
19:32:20 <stickster> You can't snapshot the production DB back to staging, diddle it, and then have someone update the production instance while you're diddling and write over it when you get to step 4.
19:32:53 <stickster> So rather than doing this any time someone wants to implement a fix, we'll schedule steps (3) and (4) for some interval, like a few weeks, to catch all the latest fixes at once.
19:33:32 <stickster> We have a few fixes already ticketed so we'll likely schedule something in the near future.
19:33:33 * nirik notes loading a db from stg -> production should be scheduled with infrastructure folks.
19:33:45 <stickster> nirik: EXCELLENT point.
19:34:15 <nirik> and we do have freezes around releases, etc... just something to keep in mind.
19:34:26 <stickster> nirik: It may be as simple as just having someone around to keep 1/2 an eye peeled while we do the grunt work with the backup_migrate module. And that should only happen outside freeze dates.
19:35:10 * nirik nods
19:35:41 <stickster> pcalarco: nirik: *: I could use a couple +1's on the process as outlined, then -- today I wanted to get the proposal out of draft and into agreed state, so we can start planning for a DB drop at some point
19:35:46 * stickster notes, asrob +1's on the list.
19:36:05 <nirik> seems sane to me, +1 here.
19:36:14 <pcalarco> +1 to the proposal as stickster has written it
19:36:31 <nirik> it doesn't explicitly list the dev instance tho?
19:36:38 * stickster notes he needs to make it clear that staging/production on the wiki isn't clear either
19:36:48 <stickster> #action stickster fix language in proposal to match intent as outlined here
19:37:42 <stickster> nirik: I'll fix that by referring back to the main project page, so the names are always fresh by keeping them in one place.
19:39:04 * stickster made changes
19:40:11 <stickster> On [[Insight]] too.
19:41:31 <stickster> With pcalarco's +1 we're good to go, but I'd like nirik's nod too for good measure
19:42:16 <stickster> https://fedoraproject.org/w/index.php?title=How_to_develop_for_Insight&diff=232460&oldid=232457 <-- minor changes to make sure "development, staging, production" are used specifically throughout
19:43:28 <stickster> pcalarco: Can you look and +1 again if you're good with that?
19:44:32 <pcalarco> +1 thanks
19:44:42 <nirik> cool.
19:44:43 <stickster> OK, then:
19:44:54 * nirik has to go... might be back on in a bit.
19:45:09 <stickster> #agreed Change process proposal is good to go, we'll start using it.
19:45:23 <stickster> pcalarco: You up for a quick ticket review with me?
19:45:32 <pcalarco> sure
19:45:37 <stickster> And that will probably bring us to :00, when I have another meeting on the phone :-)
19:45:40 <stickster> Cool!
19:45:52 <stickster> #topic Ticket review
19:46:04 <stickster> #link https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&component=FedoraInsight
19:46:56 * stickster claims a couple tickets he should have taken before
19:47:11 <pcalarco> asrob is working on 2695
19:47:53 <stickster> Ah OK... I had a fix for that, he needs to take the ticket assignment if he's working on it
19:48:54 <pcalarco> we closed a couple last week: https://fedorahosted.org/fedora-infrastructure/ticket/2694
19:49:15 <stickster> pcalarco: I left a note in 2694 and reopened
19:49:27 <stickster> We shouldn't close these until (1) we document how it was fixed, (2) it goes to production
19:50:07 <stickster> pcalarco: Maybe we could use the Version field to note that -- if it's been documented and we have a fix in hand, change Version to Production
19:50:14 <stickster> Then close once the fix is live on the production instance
19:50:26 <stickster> That way we can tell things we've fixed in testing from things we haven't
19:51:09 <pcalarco> stickster: I'm sorry, we thought that staging would be pushed to production and so this could be closed
19:51:40 <stickster> pcalarco: Yeah, not according to the change proposal... Because there's no real push facility, it involves snapshotting the database back and forth.
19:52:19 <pcalarco> stickster: ok, glad we reviewed this, thanks!
19:52:30 <stickster> pcalarco: That's just one way we could do it though. Still remains to be seen whether that's practical.
19:52:57 <stickster> I suspect we'll need to look at the fine-grained "how to deploy the fixes" bit at the next meeting, which hopefully will have averi and asrob here
19:55:06 <stickster> #info Only unclaimed tickets right now are 2691 (404 page spruce-up) and 2188 (RSS for /fwn and /fwn/beat nodes)
19:55:11 <stickster> #undo
19:55:11 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x29888490>
19:55:15 <stickster> #info Only unclaimed tickets right now are 2691 (404 page spruce-up) and 2695 (RSS for /fwn and /fwn/beat nodes)
19:56:44 <stickster> pcalarco: We probably need to get 2691 assigned, looks like 2695 is going to asrob -- just emailed him about it
19:57:02 <stickster> #info 2100 is also unclaimed
19:57:45 <pcalarco> stickster: would tactica work on 2691?  She was doing CSS work on Insight?
19:57:56 <stickster> Sure, we could ask her
19:58:04 <stickster> Can you do that?
19:58:20 <pcalarco> yes, I will ask her
19:58:32 <stickster> #action pcalarco Check with tatica about taking ticket 2691
19:59:02 <stickster> pcalarco: Anything else before we close? I think all the others we have a plan for... they were mostly waiting on the dev host and the change process approval
19:59:41 <stickster> #action stickster email the list about the precise format we want to use for making changes
20:01:20 <stickster> Okey doke
20:01:22 <stickster> #endmeeting