[01:20] <StevenK> wgrant: I'm free to land db-previewdiff-to-bmp and start this pipe up?
[01:21] <wgrant> StevenK: Might as well
[01:21]  * StevenK files a high bug to track it all
[01:21] <wgrant> DF's nearly done, btw
[01:21] <wgrant> Probably 2-3 hours left
[04:35] <StevenK> wgrant: Putting together an FDT for 1000Z
[04:40] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/index-previewdiff-merge_proposal/+merge/162915 is the only branch of the pipe missing an Approve, can you look again?
[06:04] <wgrant> StevenK: Hm, might that want to be unique actually?
[06:04] <wgrant> So we can use the timestamp as a key
[06:06] <StevenK> wgrant: The best we could do is a composite key of BMP and the timestamp, but it's a little table
[06:14] <wgrant> StevenK: I mean in the context of an MP
[06:14] <wgrant> With the schema in the pipe today, we'd have to use PD.id
[06:15] <wgrant> But the timestamp is a natural key
[06:15] <wgrant> So I'd make the index in that patch unique
[06:15] <wgrant> (and rename to _key)
[06:32] <StevenK> wgrant: Hm, I don't see the lxc veth* device after rebooting
[06:34] <wgrant> StevenK: It won't be there until the container starts
[06:35] <wgrant> It's the host side of the guest's eth0
[06:43] <StevenK> wgrant: http://pastebin.ubuntu.com/5660394/
[06:50] <wgrant> StevenK: Indeed
[07:00] <StevenK> wgrant: The diff has updated
[20:23] <Ursinha> wgrant, StevenK, hello :) how bad things would break if removed the requirement of people being sprint attendees for them to show listed as blueprint subscribers here: https://launchpad.net/sprints/uds-1305/+temp-meeting-export ?
[20:24] <Ursinha> (and good morning, whenever you show up :))
[23:09] <wgrant> Ursinha: We should check how much bigger and slower it would get.
[23:17] <Ursinha> wgrant, right. How can we do that?
[23:21] <Ursinha> wgrant, reasoning behind this is that it seems this is the first UDS registering attendance isn't required, but they still need to know the people that are subscribed to the blueprints
[23:22] <Ursinha> cjohnston said they'll have problems with that, starting tomorrow
[23:23] <Ursinha> I checked the code and it seems that being an attendee is a requirement to be displayed on that page, but I couldn't find the reason why
[23:23] <Ursinha> do you know?
[23:23] <Ursinha> I meant, subscribers displayed there need to be also attendees
[23:25] <wgrant> Ursinha: Summit only cared about attendees, and there was no way in the export format to say whether someone was an attendee or not.
[23:25] <wgrant> And IIRC Summit used to try to schedule even non-essential participants without conflicts if possible.
[23:25] <wgrant> So it was fairly important that it not get random extra people.
[23:25] <Ursinha> right, got it
[23:34] <Ursinha> actually, as that page has a list of attendees, it would be fairly trivial to know if a subscriber is an attendee or not whenever parsing that
[23:34] <Ursinha> so adding all subscribers at this moment is more a matter of performance than anything else?
[23:35] <wgrant> Ursinha: It seems so.
[23:35] <wgrant> Removing them is probably reasonable, though it might be worth someone running some quick queries to determine how many times more people that would have been for historical UDSen.
[23:36] <Ursinha> right
[23:42] <cjohnston> howdy
[23:43] <cjohnston> wgrant and Ursinha thanks for looking into this... when summit runs in auto mode it does still try to make as many peoples schedules work as possible
[23:44] <wgrant> cjohnston: So this sounds like it might be a regression.
[23:45] <cjohnston> wgrant: I'm not sure that it is. I think while we were using LP for attendees, we never noticed the problem. but since we are trying to make things easier by not requiring registration on one service and everything else on another, I think we are now figuring this out
[23:46] <Ursinha> cjohnston, wouldn't be too much to summit trying to work with the schedules of all subscribed people?
[23:47] <cjohnston> Ursinha: I doubt there are that many people who aren't 'attending' but are subscribed to a BP
[23:48] <cjohnston> But, atleast for this event, summit isn't doing the schdeuling, its being done manually