19:00:25 #startmeeting Insight (Agenda: http://tinyurl.com/insight-agenda) 19:00:25 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:00:26 * nirik is around, but afk for a few minutes... 19:00:29 #meetingname Insight 19:00:29 The meeting name has been set to 'insight' 19:00:32 #topic Roll call! 19:00:52 here, but have to be away for a minute or 5... back then. 19:00:59 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 #info Present: jsmith rbergeron nirik stickster 19:02:49 #chair jsmith rbergeron nirik 19:02:49 Current chairs: jsmith nirik rbergeron stickster 19:02:55 #topic Last week's action items 19:03:07 #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 rbergeron finished a draft SOP 19:03:22 oops 19:03:33 #info 1 - rbergeron finished a draft SOP, asking for review on the list 19:03:45 #info 2 - Sparks started review of bug 693117, bad URLs corrected 19:03:48 #chair pcalarco 19:03:48 Current chairs: jsmith nirik pcalarco rbergeron stickster 19:03:50 Hi Pascal! 19:04:03 #info Present: jsmith rbergeron nirik stickster pcalarco 19:04:03 stickster: sorry I am late, Hi! 19:04:07 No problem :-) 19:04:11 * stickster just going over action items 19:04:27 #info 3 - stickster has not made puppet changes since new host was not available until now, but this will happen ASAP 19:04:38 #action stickster make puppet changes required for staging/dev switcheroo 19:04:53 * nirik is back 19:05:21 #info 4 - averi notes we are actually deleting publictest09 shortly, since everything is being migrated to the new insight.dev host 19:05:37 #info 5 - averi did the RFR, and insight.dev.fp.o is up and running! 19:05:45 * rbergeron pops 19:05:46 err 19:05:47 pops in 19:05:47 * nirik nods. Hopefully this will meet your needs. 19:05:54 #info 6 - Haven't seen new tickets from asrob, but this can continue 19:06:14 #action asrob File tickets for phase 2 work, document and test on .dev host now that it's available 19:06:28 #action stickster Get asrob admin access on insight.dev host using the new 'sysadmin-insight' group 19:06:52 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 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 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 .bug 693117 19:07:40 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 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 ok. any ideas how far out the review is? 19:08:41 if we can get it in epel-testing we could just install from there. 19:08:43 nirik: sparks just started it, I got some bug mail today 19:08:47 ok 19:09:08 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 So maybe 3 weeks total? 19:09:33 sure, but we could short circut by installing from testing if need be... 19:09:42 Oh yeah, we have that available, I forgot. 19:10:01 or infra. We can work it out out of band... 19:10:11 Cool nirik, I'm down with that. 19:10:52 #info nirik and stickster will get the backup_migrate module package available for staging/prod 19:11:02 #action stickster add backup_migrate module package to insight.dev 19:11:11 #action sparks Finish bug 693117 review 19:11:43 I have one comment regarding averi's pt09 note 19:11:46 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 pcalarco: I'll topic to make things clearer 19:12:05 #topic Development and pt09 host status 19:12:19 #info Some information found in the action items section above :-) 19:12:23 Go ahead pcalarco ! 19:12:47 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 #link https://fedorahosted.org/fedora-infrastructure/ticket/2726 19:13:53 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 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 pcalarco: So staging has it wrong, correct? 19:14:58 stickster: yes 19:15:53 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 I think we do already; we pick off the appropriate beat in the FWN content type 19:17:07 pcalarco: By "pick off" you mean...? 19:17:30 drop down menu selection, sorry :) 19:17:35 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 np :) 19:17:45 pcalarco: Ah, yes 19:18:14 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 But there's no *implicit* value assigned to the allowed values... so the View is interpreting it as alphabetical 19:19:16 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 er, SQL key value 19:19:32 * stickster hasn't dug into it to see if that's possible 19:20:05 #info Need to see if we can order in the 'fwn' view by field_beat's SQL key value 19:20:09 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 pcalarco: And on staging, you entered them in the same order, but they show up alphabetically -- correct? 19:20:36 assuming there is an internal value for the nodes in the queue 19:20:45 stickster: yes, correct 19:20:47 Ha 19:21:01 I know what caused it then. It was adding a 'key' in the array for the field_beat content type 19:21:27 Doing that probably overwrote the implicit 'key' values of 0, 1, ... that are used in pt09 with 'introduction', 'ambassadors',... 19:21:47 Thus the ordering now happens alphabetically because that's what makes sense in SQL 19:22:06 If we rename those keys as '0-introduction', '1-somethingelse', ... then it should magically get fixed 19:22:07 stcikster: that makes sense, yes 19:22:38 However, the renaming needs to be accompanied by altering the DB to fix those keys globally with UPDATE statements 19:23:06 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 stickster: thank you very much! 19:23:42 pcalarco: No problem 19:23:58 #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 back 19:26:46 pcalarco: Maybe we should #topic to the change proposal process which will make the new world order clearer :-) 19:27:09 stickster: :) 19:27:13 #topic Change process proposal 19:27:26 #info stickster wrote https://fedoraproject.org/wiki/How_to_develop_for_Insight for this purpose 19:28:34 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 pcalarco: The latter 19:28:50 #info Basic NWO: (1) We blow away pt09, taking DB backup for posterity 19:29:17 #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 stickster: thanks for the clarification; that was the only question I had in reviewing this; looks very clear 19:30:09 #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 #info (4) Then the DB is redeployed to insight.fp.o (production) 19:31:03 staging has proxy's and such like production, where dev doesn't. 19:31:21 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 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 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 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 nirik: EXCELLENT point. 19:34:15 and we do have freezes around releases, etc... just something to keep in mind. 19:34:26 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 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 seems sane to me, +1 here. 19:36:14 +1 to the proposal as stickster has written it 19:36:31 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 #action stickster fix language in proposal to match intent as outlined here 19:37:42 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 On [[Insight]] too. 19:41:31 With pcalarco's +1 we're good to go, but I'd like nirik's nod too for good measure 19:42:16 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 pcalarco: Can you look and +1 again if you're good with that? 19:44:32 +1 thanks 19:44:42 cool. 19:44:43 OK, then: 19:44:54 * nirik has to go... might be back on in a bit. 19:45:09 #agreed Change process proposal is good to go, we'll start using it. 19:45:23 pcalarco: You up for a quick ticket review with me? 19:45:32 sure 19:45:37 And that will probably bring us to :00, when I have another meeting on the phone :-) 19:45:40 Cool! 19:45:52 #topic Ticket review 19:46:04 #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 asrob is working on 2695 19:47:53 Ah OK... I had a fix for that, he needs to take the ticket assignment if he's working on it 19:48:54 we closed a couple last week: https://fedorahosted.org/fedora-infrastructure/ticket/2694 19:49:15 pcalarco: I left a note in 2694 and reopened 19:49:27 We shouldn't close these until (1) we document how it was fixed, (2) it goes to production 19:50:07 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 Then close once the fix is live on the production instance 19:50:26 That way we can tell things we've fixed in testing from things we haven't 19:51:09 stickster: I'm sorry, we thought that staging would be pushed to production and so this could be closed 19:51:40 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 stickster: ok, glad we reviewed this, thanks! 19:52:30 pcalarco: That's just one way we could do it though. Still remains to be seen whether that's practical. 19:52:57 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 #info Only unclaimed tickets right now are 2691 (404 page spruce-up) and 2188 (RSS for /fwn and /fwn/beat nodes) 19:55:11 #undo 19:55:11 Removing item from minutes: 19:55:15 #info Only unclaimed tickets right now are 2691 (404 page spruce-up) and 2695 (RSS for /fwn and /fwn/beat nodes) 19:56:44 pcalarco: We probably need to get 2691 assigned, looks like 2695 is going to asrob -- just emailed him about it 19:57:02 #info 2100 is also unclaimed 19:57:45 stickster: would tactica work on 2691? She was doing CSS work on Insight? 19:57:56 Sure, we could ask her 19:58:04 Can you do that? 19:58:20 yes, I will ask her 19:58:32 #action pcalarco Check with tatica about taking ticket 2691 19:59:02 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 #action stickster email the list about the precise format we want to use for making changes 20:01:20 Okey doke 20:01:22 #endmeeting