21:03:09 <jaypipes> #startmeeting
21:03:10 <openstack> Meeting started Tue Sep 28 21:03:09 2010 UTC.  The chair is jaypipes. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:03:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
21:03:37 <jaypipes> #topic python version
21:03:41 <soren> jaypipes: I was just waving.
21:03:52 <jaypipes> any objections to making 2.6 the standard?
21:04:01 <creiht> yes
21:04:01 <jaypipes> myself, I think it's a reasonable requirement.
21:04:03 <vishy> nope
21:04:05 <creiht> :)
21:04:09 <jaypipes> creiht: pls elaborate.
21:04:52 <creiht> If one of the major desires for openstack is getting people on board, then I believe that for now python 2.5 support should be considered
21:05:09 <jaypipes> creiht: other than debian, what platform does not support 2.6
21:05:14 <creiht> There are still a lot of people running distros that are limited 2.5
21:05:21 <jaypipes> creiht: which ones?
21:05:30 <anotherjesse> In the past there have been parts that broke in 2.5 with nova - trying to remember if it is still the case
21:05:30 <creiht> Centos
21:05:33 <creiht> RHEL
21:05:40 <jaypipes> creiht: that is incorrect.
21:05:45 <jaypipes> creiht: it's in EPEL.
21:05:56 <creiht> the gap from 2.5 to 2.6 is small I believe for what it buys us
21:06:11 <jaypipes> creiht: other than context managers, what are we talking?
21:06:24 <creiht> The redhat places that I have been at before didn't use EPEL
21:06:25 <anotherjesse> we used to use multi-processing which caused issues in 2.5
21:06:26 <jaypipes> actually, that ? is for all, not just creiht :)
21:06:32 <jaypipes> ah, yes.
21:06:39 <anotherjesse> but there might have been other issues as well
21:06:44 <creiht> jaypipes: 2.5 has context managers
21:06:46 <jaypipes> nosetests uses multiprocessing module as well.
21:06:57 <jaypipes> creiht: right, I asked what other than context managers.. :)
21:07:11 <soren> We have a bunch of dependencies that aren't in *any* distro other than Ubuntu.
21:07:19 <jaypipes> creiht: b/c that can be fixed with a simple import from __future__, right?
21:07:27 <creiht> jaypipes: correct
21:07:32 <soren> How are we expecting people running CentOS to deal with those?
21:07:50 <jaypipes> soren: pls be specific, for the meeting notes, if not for people's benefit ;)
21:08:27 <soren> gflags, eventlet 0.9.12, greenlets, pyredis (for now), sqlalchemy 0.6.3, ...
21:08:44 <soren> Probably more that I don't know about. RHEL is ancient. It's probably missing all sorts of stuff.
21:08:51 <creiht> I would argue that it is easier to get some other packages installed, since python is used for things like package management
21:09:01 <creiht> it is more difficult to upgrade
21:09:16 <jaypipes> soren: AFAIK, all those except for gflags is in pypi, no?
21:09:20 <soren> python 2.5 and 2.6 can peacefully coexist.
21:09:26 <soren> jaypipes: No clue.
21:09:35 <soren> You don't have to remove 2.5 to get 2.6.
21:09:36 <creiht> soren: in theory yes, but ops people do not like that
21:09:48 <soren> What /do/ they like? :)
21:09:57 <jaypipes> the only package that is a pain IMHO is M2Crypto since you need dev headers to compile it...
21:10:05 <soren> jaypipes: Same for eventlet.
21:10:12 <soren> jaypipes: I believe.
21:10:18 <jaypipes> soren: ok.
21:10:40 <creiht> All I'm saying is that it is my opinion that it will be easier to get adoption if we support python 2.5
21:10:47 <jaypipes> OK, this information is good, but it's kind of besides the point about 2.5 vs 2.6, no?
21:10:55 <Daviey> Surely a consistent coding requirements(.txt) is required...
21:11:06 <jaypipes> Daviey: ?
21:11:07 <creiht> besides, the gap in functionality between 2.5 and 2.6 is fairly small
21:11:17 <Daviey> Can the merge masters really be expected to test against all kinda variables like inconsistent deps?
21:11:21 <jaypipes> creiht: the big one is multiprocessing module.
21:11:37 <creiht> which is available as an external module for 2.5
21:11:48 <jaypipes> creiht: also good to know :)
21:11:55 <creiht> granted possibly with a couple of caveats
21:11:55 * Daviey would suggest 2.6 makes sense... if something breaks for 2.5 "patches welcome".
21:12:05 <dabo> creiht: But 2.6 has a forward path to 3.x; 2.5 doesn't
21:12:26 <jaypipes> good point.
21:12:30 <soren> Does anyone have any overview of what in Swift or Nova currently does not work with py2.5?
21:12:40 <xtoddx> daviey: that is idempotent with supporting 2.5
21:12:49 <creiht> I'm not saying we always have to support 2.5, I'm saying just for now
21:13:00 <soren> I mean.. How much work would it be to make it supported (ignoring the maintenance burden for a little bit).
21:13:00 <creiht> it is going to be a long time before everything will be in place to support 3
21:13:03 <jaypipes> soren: Nova would have to have the pool stuff reworked to include external multiprocessing module and use import from __future__ for context managers.
21:13:21 <creiht> soren: I think the only thing left for swift is changing the default ssl to use OpenSSL
21:13:50 <creiht> dabo: 2.7 is really where the path forward to 3.0 is
21:13:57 <soren> Ok, so let's pretend we decide to support 2.5, too.
21:13:59 <creiht> 2.6 really doesn't buy you much on the road to 3.0
21:14:23 <soren> This is supposedly to get poeple running old distros to run OpenStack.
21:14:33 <creiht> or even try it
21:14:34 <jaypipes> OK, so the options are 1) patch nova/swift to be 2.5 compatible, 2) use 2.6 as the required version. Please vote #1 or #2
21:14:36 <dabo> creiht: sure, since 2.7 is current, but 2.6 was the first release to add that capability
21:14:47 <zul> #2
21:14:50 <jk0> #2
21:14:51 <soren> Does that mean that we effectively support these ancient distros?
21:14:53 <creiht> #1
21:15:00 <jaypipes> #2
21:15:01 <Daviey> #2
21:15:09 <anotherjesse> #2
21:15:13 <dabo> #2
21:15:14 <creiht> no... we just support python 2.5, which goes a long way to help packaging people support ancient distros
21:15:16 <soren> This may mean that we need to have all sorts of special magic in place to ensure our use of system tools.
21:15:17 <jc_smith> Other than local dev tinkering, I would think greenfield deployments would be with the latests distros
21:15:17 <vishy> #2
21:15:24 <creiht> *may*
21:15:30 * creiht sighs
21:15:35 <eday> soren: it would be interesting to see if the hypervisors would even work on the old distros for what openstack needs
21:15:41 <soren> creiht: That's the thing. Are we accepting this burden, too?
21:15:50 <creiht> I would say no
21:16:11 <soren> creiht: I think that's important. Just supporting py2.5 seems like a half day of work, but if it actually means "support ancient linux distros", it's much more than that.
21:16:23 <jaypipes> creiht: I understand your concern, I do.  But I believe we have agreement on this.
21:16:25 <Daviey> O_o... So you can use openstack - but can't use libvirt for example.
21:16:28 <ttx> at that point in the project history, I'd advise looking forward rather than back
21:16:47 <soren> Oh, yeah. good one. nove requires libvirt > 0.7.5.
21:16:50 <jaypipes> creiht: unless there is an option #3 you can think of?
21:16:55 <soren> and > 0.8.1 for the firewall stuff.
21:16:56 <jc_smith> for hypervisors, you usually want the latest greatest kvm/xen and not older distros anyways
21:17:10 <creiht> the main difference is, that it is a lot more difficult to get someone to upgrade python on an older distro, then it is other packages
21:17:20 * creiht gives up
21:17:25 <MrKohonen> Support for libvirt in old hypervisors is an issue
21:17:27 <jaypipes> creiht: don't give up, please.
21:17:32 <alekibango> #2
21:17:51 <jaypipes> creiht: the discussion is just that. trying to get all sides, and if you feel strongly, I want to talk it through.
21:18:14 <jaypipes> creiht: what is the likelihood that someone will be deploying Nova on a distro that does not have 2.6?
21:18:21 <creiht> I dunno
21:18:22 <jaypipes> creiht: what is RS' internal systems?
21:18:35 <creiht> but I would say it is high, that they want to play with it on a system that does not have 2.6
21:18:37 <xtoddx> option #3: distro survery on openstack.org?
21:18:42 <xtoddx> and mailing list?
21:18:45 <Daviey> creiht, hmm.. using virtualenv should help with that BTW.
21:18:45 <creiht> jaypipes: for swift we use ubuntu and 2.6
21:19:00 <jc_smith> would it make sense swift be 2.5 and nova 2.6? Since the dependencies are much different
21:19:12 <creiht> Daviey: that is true, but I am talking from an ops perspective, who tend to not like virtualenv
21:19:12 <_0x44> jaypipes: In ozone the app servers have python 2.5.2
21:19:15 <_0x44> chris@193134-app1:~$ python --version
21:19:16 <_0x44> Python 2.5.2
21:19:16 <pvo> our version of python on xenserver 5.5 is 2.5.2
21:19:18 <jaypipes> xtoddx: yes, a possibility.  however, as creiht is pointing out, it may be best to ask the distros/sysadmins themselves?
21:19:23 * creiht has fought many of these battles before
21:19:39 <jaypipes> creiht: understood.
21:19:40 <Daviey> creiht, agreed.
21:19:51 <creiht> As a dev, I would love to stay with 2.6
21:19:54 <creiht> it makes it a lot easier
21:19:57 <anotherjesse> creiht: could py 2.5 support come in a point release?
21:19:57 <alekibango> how much work it might be to make #1 ?
21:20:06 <creiht> but I'm making this point purely from the ops perspective
21:20:06 <jaypipes> _0x44: well, since ozone is built on Ruby I don't really give that much weight ;)
21:20:11 <creiht> anotherjesse: sure
21:20:28 <creiht> I'm not trying to say we have to have it first thing, just that it would be nice to have that as a goal
21:20:32 <_0x44> jaypipes: ozone is built on Ruby, but going to start migrating onto openstack post austin
21:20:34 <alekibango> when is another RHEL/CENTOS release? will it contain 2.6 ?
21:20:44 <soren> I'm not *opposed* to 2.5 working. If people want to put in the effort, that's great, but I'm against making it a release critical issue if there's something that doesn't play well with python 2.5.
21:20:53 <jaypipes> alekibango: I'm not quite sure... I'd need mtaylor to set up a Tarmac target with 2.5 on it, at the very least, and then get fixing breakages.
21:20:53 <anotherjesse> creiht: we spent a lot of time fighting python2.5 before we ran away due to issues with multi-processing / threading / signals
21:20:55 <creiht> alekibango: next RHEL has been real soon now for like forever
21:20:55 <pvo> _0x44: but the host OS  won't necessarily upgrade
21:20:56 * alekibango agrees with soren
21:21:12 <alekibango> its a bug, but not release critical one
21:21:18 <soren> I will happily accept patches that make stuff work with python 2.5.
21:21:21 <jaypipes> _0x44: right, all I was saying is that the version of Python on those hosts, up to this point, hasn't been a big disucssion point, I'm assuming :)
21:21:44 <creiht> I don't want to make a big issue about it
21:21:52 <pvo> jaypipes: valid point. I don't knwo what xen 5.6.1 or 6.0 will include.
21:21:55 <pvo> I haven't looked yet
21:22:04 <soren> Conversely, I will not reject a patch if it doesn't work with python 2.5.
21:22:11 <creiht> I didn't think it would turn into this big of a deal
21:22:39 <_0x44> jaypipes: Good point, I'll shutup.
21:22:49 <jaypipes> OK, so, here is a summary decision: "For Austin, we go with 2.6 as requirement.  At a later time, if the demand is there, we can do a release targeting back-deployment on 2.5".  If agreed, please put #agreed.
21:23:03 <Daviey> #agreed
21:23:04 <dabo> #agreed
21:23:05 <creiht> #ifwehaveto
21:23:06 <anotherjesse> #agreed
21:23:07 <creiht> :)
21:23:08 <zul> #agreed
21:23:10 <chmouel> #agreed
21:23:13 <jaypipes> creiht: :)
21:23:15 <sirp1> #agreed
21:23:16 <soren> #agreed
21:23:17 <devcamcar> #agreed
21:23:19 <_0x44> #agreed
21:23:28 <jaypipes> alrighty then, let's move on.
21:23:36 <jaypipes> #topic arch board nominations
21:23:42 <jaypipes> nominate away...
21:23:50 <alekibango> #agreed
21:24:16 <jaypipes> alright, send nominations to jonathan.bryce@rackspace.com
21:24:18 <jaypipes> moving on...
21:24:24 <soren> Er..
21:24:24 <jaypipes> #topic blueprint statuses
21:24:27 <soren> Wait, what?
21:24:28 <creiht> heh
21:24:31 <soren> "arch board"?
21:24:34 <soren> -v
21:24:38 <jaypipes> soren: Architecture Board
21:24:42 <soren> What the heck is that?
21:24:44 <jaypipes> soren: rick sent an email about it..
21:24:50 <jaypipes> soren: one sec, grabbing link.
21:25:07 <eday> http://wiki.openstack.org/Governance
21:25:09 <pvo> soren: #link http://wiki.openstack.org/Governance
21:25:10 <jaypipes> from rick:
21:25:11 <jaypipes> We are looking for nominations for the Architecture board.
21:25:11 <jaypipes> [http://wiki.openstack.org/Governance]
21:25:11 <jaypipes> To nominate yourself or others send an email to jonathan@openstack.org
21:25:11 <jaypipes> by September 30th.
21:25:28 <soren> Oh, it got renamed?
21:25:30 <soren> Ok.
21:25:33 <jaypipes> guess so :)
21:25:44 <jaypipes> ok, so #topic blueprint statuses
21:25:49 <xtoddx> are there already some people sitting on it, or is it totally new?
21:25:57 <jaypipes> I'm going to run down austin blueprints and ask assignees for a brief update.
21:26:12 <jaypipes> xtoddx: not sure, I think dendro-afk is the one to ask about the board.
21:26:15 <soren> xtoddx: It's being established now, as I understand it.
21:26:20 <eday> xtoddx: I think they will be appointed at the end of Oct
21:26:22 <ttx> xtoddx: "Chief Architect" has a seat
21:26:23 <creiht> xtoddx: I think it is all new
21:26:41 <jaypipes> #link https://blueprints.launchpad.net/nova/austin
21:26:48 <jaypipes> going from the top...
21:26:58 <jaypipes> sirp1: how goes it on image store?
21:27:35 <sirp1> so far so good… working on parallax so far, running in to some issues with some library dependencies (lockfile), but should have those cleared up
21:27:45 <sirp1> rootkit has made good progress on teller
21:27:59 <jaypipes> sirp1: good to hear.  on my own blueprints, making progress, should be done tomorrow...
21:28:04 <sirp1> and sounds like (jaypipes) are on the same page as we are for the nova integration piece
21:28:29 <sirp1> #done unless questions
21:28:39 <jaypipes> cool. xtoddx how's the openstack api blueprint going? any update?
21:28:50 <xtoddx> maybe _cerberus_ should update?
21:28:59 <jaypipes> ok
21:29:20 <pvo> he stepped away for a second
21:29:27 <pvo> gundlach?
21:29:34 <eday> I can give some update there too. shared_ip_groups are probably not going to make it in due to back-end mismatches (see email to nova list)
21:29:37 <jaypipes> no worries. gundlach and eday, want to update your stuff?
21:29:43 <eday> core functionality is going well
21:29:56 <jaypipes> eday: k.  good to know.
21:30:15 <xtoddx> the servers_api branch is looking good, anyone interested should review it
21:30:22 <eday> some things like caching and delta change requests will not be done, but do not change features really
21:31:00 <jaypipes> xtoddx: which blueprint(s) is the servers_api for?
21:31:04 <jaypipes> xtoddx: https://blueprints.launchpad.net/nova/austin
21:31:19 <jaypipes> xtoddx: is that the openstack-api one?
21:31:25 <eday> jaypipes: it's the openstack-api, but there are bugs files for each task within it
21:31:35 <eday> (yes, this is not correct, but how it was done)
21:31:39 <jaypipes> eday: gotcha. ok.
21:31:45 <xtoddx> austin-openstack-api
21:32:18 <jaypipes> vishy: the AnsoLabs-assigned blueprints....where do we sit?
21:32:23 <jaypipes> anotherjesse: ^^
21:32:56 <jaypipes> eday, pvo: is Chris B done with the scheduler stuff?
21:32:57 <anotherjesse> guest-agent is mostly with xen
21:33:16 <jaypipes> anotherjesse: should I ask ewan for a status on that one then?
21:33:20 <pvo> jaypipes: I think the simple scheduler is done
21:33:31 <eday> jaypipes: the start or a scheduler is in there, but I don't think Chris is taskedwith it anymore
21:33:41 <_cerberus_> re: the openstack api - things are coming along, but there are a host of tasks yet to be done. http://etherpad.openstack.org/fm0PKBhE3D for reference sake
21:33:46 <anotherjesse> jaypipes: guest agent is only implemented in the xenapi driver for compute
21:33:48 <jaypipes> pvo, eday: ok, cool.  if one of you could update that blueprint, myuch appreciated
21:34:01 <eday> jaypipes: not sure who owns it now :)
21:34:17 <anotherjesse> joshua mckenty did a pass - he is working on further testing  -- he started with the python library but moved back to using CLI tools and shelling out since there were issue with compatability and building the library without being a major PITA
21:34:26 <jaypipes> eday: then it should be unassigned from Chris, no? :)
21:34:50 <jaypipes> anotherjesse: ok, good to hear.  could I ask you or Josh to update those blueprints when you get a chance?  2 days till freeze...
21:35:14 <anotherjesse> rescue is mostly done (and will be proposed for merge once the openstack API is added)
21:35:17 <anotherjesse> vishy is working on that
21:35:26 <jaypipes> alright
21:35:42 <anotherjesse> the web-based-serial-console is done module testing in xen and adding the openstack api
21:35:52 <jaypipes> #action anotherjesse, josh: update blueprint statuses...
21:36:10 <anotherjesse> resize, migration, snapshotting are designed but might not make it ...
21:36:10 <jaypipes> #action jaypipes: track down ewan for status on xen blueprints.
21:36:11 <anotherjesse> :(
21:36:37 <jaypipes> anotherjesse: no worries.  the sooner we can get a definitive status, the better, so we can move them out to Bexar, ok?
21:37:03 <anotherjesse> when working on scheduler blueprint (which shows started but it is actually already merged) we added the required functionality to implement resize, migration
21:37:33 <anotherjesse> but it will depend on how much time the nebula release (which happens this monday) takes
21:37:38 <jaypipes> anotherjesse: so is the resize blueprint actually implemented then?
21:37:40 <anotherjesse> since we have to release first
21:38:05 <anotherjesse> jaypipes: resize has been designed and support added to scheduler - but not actually implemented
21:38:15 <anotherjesse> mostly missing copying the image from the old machine to the new one
21:38:15 <jaypipes> anotherjesse: ok, understood.
21:38:59 <jaypipes> anotherjesse: pls do update the blueprint statuses as accurately as possible.  dendro-afk and I will move the blueprints that can't be completed out to Bexar, where those blueprints will serve as starting points for discussions at the next summit.
21:39:10 <anotherjesse> we updated delievery already
21:39:18 <anotherjesse> but will update with more info
21:39:28 <jaypipes> anotherjesse: awesome, thx much :)
21:39:47 <jaypipes> alrighty, any more updates before we discuss the next topic?
21:39:56 <soren> yeah.
21:40:00 <soren> If anyone cares, the austin-ec2-security-groups spec is going pretty well. I pushed a fresh version of the branch this morning which seems in good shape. vishy and anotherjesse pointed out a problem yesterday, though, that I haven't addresssed yet (no filtering between vm's in the same security group), but that shoulnd't be too big of a deal.
21:40:25 <soren> It can get merged now, if reviewed, and then I fix that problem up afterwards.
21:40:34 <jaypipes> soren: so is that a long way of asking for a code review? ;)
21:40:41 <soren> It's a pretty big patch. I'd love to get it merged sooner rather than later.
21:40:54 <soren> jaypipes: I think it is, yes :)
21:40:57 <anotherjesse> we can review - sicne we have it in our deploy branch already
21:41:07 <jaypipes> #action ALL: please review soren's ec2 security groups merge proposal
21:41:17 <jaypipes> #link https://code.launchpad.net/nova/+activereviews
21:41:24 <anotherjesse> we've already been pushing our patches to soren for the sec group stuff
21:41:44 <anotherjesse> I have heard that the hyper-v work is going well
21:41:47 <jaypipes> anotherjesse: cool.  let's get that reviewed and merged then... :)
21:41:57 <vishy> soren: i'm good with it, just as long as we are careful to let people know that they need bleeding-edge libvirt to make it work
21:42:03 <anotherjesse> but I don't have an update other than that
21:42:16 <gundlach> sorry, was late and then catching up with logs.  api is "coming along" -- i've got 2 tasks left on my plate which i am pretty sure will be done by tomorrow evening
21:42:23 <eday> jaypipes, all: and in general, we have a lot of other outstanding merge reqs we need to get in before thursday (or deny)
21:42:31 <jaypipes> eday: indeed.
21:42:33 <anotherjesse> also xtoddx got austin-rename-servers merged
21:42:48 <anotherjesse> so we will update it as well
21:42:48 <soren> vishy: True.
21:43:18 <jaypipes> #action ALL: Many merge proposals need a second reviewer...let's get things merged! https://code.launchpad.net/nova/+activereviews
21:43:31 <gundlach> eday, _cerberus_: if shared ip groups isn't going into Austin, is there anything eday can do to help you, _cerberus_?
21:44:03 <eday> gundlach: I'm still stubbing out as much as I can, but yeah, we I can focus on other core bits.
21:44:04 <xtoddx> actually, austin_rename_servers just got updated to latest trunk and is ready to merge https://code.launchpad.net/~anso/nova/rename/+merge/36382
21:44:26 <eday> gundlach: also, I'm traveling tomorrow to speak about openstack on thursday in baltimore, so my time is limited this week
21:44:34 <jaypipes> xtoddx: cool.
21:45:15 <jaypipes> an update from /me..  I pushed off completing the nosql datastore driver until Bexar.  It because way too big of a PITA and I wanted to help with Glance's stuff...
21:45:27 <jaypipes> s/because/became
21:46:25 <jaypipes> alright, I don't see any of the summit organizers on the channel, so we'll skip the next topic (summit). Anyone want to discuss anything else? 10 .. 9 .. 8 ..
21:46:41 <gundlach> eday: if you have a chance, it looks like the GlanceImageService is a remaining task (once Glance is ready to be coded against)
21:46:54 <jaypipes> gundlach: that's what I am working on. :)
21:46:59 <_cerberus_> gundlach: anything from the etherpad would be great
21:47:07 <gundlach> jaypipes: sorry, i should have read the logs more carefully :)
21:47:12 <jaypipes> gundlach: no worries!
21:47:15 <anotherjesse> jaypipes: perhaps the swift guys can give advice on eventlet and connection pooling?
21:47:17 <dabo> The Call for Proposals for the 2011 US PyCon is open now until 2010-11-01. I think we should have some OpenStack representation
21:47:20 <gundlach> jaypipes: i'll update the etherpad ghetto-bug-tracker we're using
21:47:25 <dabo> http://us.pycon.org/2011/speaker/proposals/
21:47:36 <creiht> anotherjesse: what problem are you guys running into?
21:47:39 <jaypipes> gundlach: cool
21:47:40 <_cerberus_> gundlach: after I merge in my current iteration of the servers_api branch, anyone is free to pick off the remaining tasks.
21:48:44 <eday> anotherjesse: we just need to replace singletons with a pool really
21:48:59 <anotherjesse> k
21:49:21 <jaypipes> ok dokey, going to end the meeting...
21:49:22 <jaypipes> 7
21:49:24 <jaypipes> 6
21:49:27 <jaypipes> 5
21:49:30 <jaypipes> 4
21:49:32 <xtoddx> eday: are there managers other than authmanager?
21:49:32 <jaypipes> 3
21:49:38 <xtoddx> or, singletons, rather
21:49:47 <soren> Yes.
21:49:53 <soren> In the rpc code.
21:49:59 <soren> rpc.Connection or something.
21:50:03 <jaypipes> xtoddx: rpc.Connection
21:50:10 <jaypipes> soren: damn, jinx.
21:50:22 <xtoddx> ok
21:50:25 <anotherjesse> move to #openstack?
21:50:29 <jaypipes> yep.
21:50:31 <jaypipes> 3
21:50:33 <jaypipes> 2
21:50:34 <jaypipes> 1
21:50:38 <jaypipes> #endmeeting