19:01:08 <devananda> #startmeeting ironic
19:01:09 <openstack> Meeting started Mon Jun 23 19:01:08 2014 UTC and is due to finish in 60 minutes.  The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:12 <jroll> \o
19:01:13 <openstack> The meeting name has been set to 'ironic'
19:01:16 <devananda> #chair NobodyCam
19:01:17 <openstack> Current chairs: NobodyCam devananda
19:01:23 <devananda> #link https://wiki.openstack.org/wiki/Meetings/Ironic
19:01:28 <devananda> as usual, the agenda can be found ^
19:02:07 <devananda> #topic greetings, announcement, etc
19:02:34 <devananda> I think the "bug tag" announcement may have been left from last week, but to reiterate
19:02:49 <devananda> as we are filing and triaging bugs, let's try to tag them using the official tags
19:03:05 <devananda> also, lots of thanks to dtantsur for work on that :)
19:03:19 <dtantsur> np :)
19:03:20 <mrda> +1
19:03:41 <devananda> as for the midcycle meetup(s), there's info here for ours
19:03:44 <devananda> #link https://wiki.openstack.org/wiki/Sprints/BeavertonJunoSprint
19:03:47 <dtantsur> action for me or somebody: to add the same tags to python-ironicclient
19:03:59 <NobodyCam> should this be done by the bug submiter or person doing triage
19:04:06 <devananda> NobodyCam: either one
19:04:08 <dtantsur> NobodyCam, both
19:04:19 <NobodyCam> ack ack :)
19:04:32 <devananda> if you are able to make it to the Ironic meetup, please RSVP on the links from that wiki page
19:04:45 <devananda> so we can tell the venue how many to expect
19:04:59 <devananda> I've estimated that we'll be between 20 and 30 ppl ...
19:05:18 <Shrews> How many plan to attend the TripleO one instead/as well?
19:05:48 <dtantsur> sorry for interrupting you: is anyone attending meet-up in Paris in the beginning of June?
19:05:56 <devananda> Shrews: i was just about to ask that :)
19:06:18 <devananda> I will be at the tripleo midcycle
19:06:29 * Shrews will attend tripleo instead
19:06:48 <ifarkas> dtantsur, I am: https://wiki.openstack.org/wiki/Sprints/ParisJuno2014
19:06:51 * NobodyCam should be at Ironic's meetup
19:07:13 * matty_dubs is attending only the Ironic+Nova one
19:07:16 <lucasagomes> dtantsur, yeah me too
19:07:32 <romcheg> dtantsur: viktors will be there so you can discuss oslo.db :)
19:07:41 <NobodyCam> we may have just lost devananda
19:08:35 * Shrews mourns the loss
19:08:43 <mrda> :)
19:08:47 <NobodyCam> lol yep lost his connection
19:08:56 <rloo_> all in favour of NobodyCam taking over...
19:09:18 <lucasagomes> :)
19:09:24 <NobodyCam> :)
19:09:41 * matty_dubs for one, welcomes our new Ironic overlords
19:09:47 <mrda> oh, its only his *connection* :)
19:09:50 <romcheg> king is dead long live the king
19:10:08 <NobodyCam> #topic Release cycle progress report
19:10:33 <NobodyCam> we'll skip over ironic-specs and blueprint status (devananda)
19:10:38 <lucasagomes> ok deva is off, so I think I can talk about the refactor
19:10:39 <NobodyCam> so lucasagomes your up
19:10:54 <lucasagomes> the base patches and the dependencies in devstack and tempest are merged
19:11:03 <lucasagomes> there's 2 patches left for the instance_info work
19:11:31 <NobodyCam> nice
19:11:33 <lucasagomes> the migration script and another one changing the patcher.py on the driver to make it not delete the pxe_deploy_{kernel,ramdisk} when tearing down the node
19:11:39 * lucasagomes will grab the links
19:11:54 <lucasagomes> #link https://review.openstack.org/96136
19:12:02 <lucasagomes> #link https://review.openstack.org/101864
19:12:05 <lucasagomes> and that's it :)
19:12:18 <NobodyCam> awesome
19:13:28 <ifarkas> one question if anyone knows: what's the status of the ceilometer integration?
19:13:30 <NobodyCam> we'll come back to get deva's report
19:14:03 <NobodyCam> ifarkas: I'd have to follow up and looking to it
19:14:33 <NobodyCam> shall we move on to the Sub-team reports
19:14:51 <jroll> +1
19:14:53 <NobodyCam> #topic Sub-team status reports
19:15:03 <NobodyCam> going to go a little out of order
19:15:13 <ifarkas> NobodyCam, ok, I just found a WIP patch but wanted to check the progress
19:15:14 <NobodyCam> Jroll I know you have leave early
19:15:21 <jroll> oh yeah!
19:15:31 <NobodyCam> wanta give ipa's report
19:15:36 <jroll> yep
19:15:48 <NobodyCam> :)
19:16:03 <jroll> so, first off, we announced onmetal last week, which is based on ironic. thank you all for your help!
19:16:21 <mrda> jroll: \o/
19:16:27 <NobodyCam> woot
19:16:32 <jroll> second, I wrote a blog post about how we run ironic with IPA for onmetal, for anyone interested: http://developer.rackspace.com/blog/from-bare-metal-to-rackspace-cloud.html
19:16:37 <jroll> configs and all are included there
19:17:03 <jroll> third, we've been working on powering through our todo list. as usual, that's located here: https://etherpad.openstack.org/p/ipa-todos
19:17:24 <jroll> we're refactoring the agent patches to be easier to merge
19:17:35 <jroll> this is the main agent patch now (still needs tests) https://review.openstack.org/#/c/101020/
19:17:44 <lucasagomes> cool!
19:17:45 <jroll> and features that the PXE driver doesn't have will be applied on top of that
19:17:48 <NobodyCam> awesome stuff jroll
19:18:09 <NobodyCam> wb devananda_
19:18:13 <jroll> feel free to review that agent patch, I should have the tests up later today, hopefully
19:18:40 <dtantsur> jroll, is it just a new review request?
19:18:43 <devananda> ugh. lost connection to irc proxy. reconnected directly... so no history here
19:18:55 <dtantsur> I mean, it's not the same as I saw :)
19:19:02 <jroll> one last thing, JoshNang worked friday on an infra job to post an agent image tarball every time a patch is merged. unclear if that's working yet, but if not it will be soon
19:19:03 <NobodyCam> devananda: it will be in the logs :)
19:19:05 <NobodyCam> lol
19:19:14 <jroll> dtantsur: yes, we'll be abandoning the 100-patchset review soon :)
19:19:37 <dtantsur> jroll, nooooo... I wanted to see 100th patchset so badly :(
19:19:38 <NobodyCam> we doing IPA subteam report as jroll needs to jump out a bit early
19:19:42 <jroll> and, I believe that's all I have right now for IPA
19:19:51 <jroll> dtantsur: lol, I can submit patches anyway :P
19:19:56 <dtantsur> jroll, any updates on testing IPA?
19:20:22 <jroll> dtantsur: that infra job I mentioned is the first step, the smaller agent patch is the second
19:20:36 <jroll> dtantsur: planning on building tempest jobs to test against 101020
19:20:58 <devananda> NobodyCam: ack, thanks
19:21:35 <devananda> NobodyCam: have we covered other subteams yet?
19:21:52 <NobodyCam> devananda: thou we do need to loop back and get a ironic-specs and blueprint status update too
19:22:02 <NobodyCam> not yet
19:22:18 <devananda> ok, let's move on then
19:22:47 <devananda> shrews, adam_g: any updates on our tempest test status?
19:22:49 <NobodyCam> Integration Testing
19:22:53 <devananda> i think there was a bunch of discussion about taht last week
19:23:09 <adam_g> our check and  gate jobs look to be stabalized.
19:23:25 <adam_g> im currently working on weeding thru tempest test failures that are the result of unsupported hypervisor features, and adding new flags to tempest to avoid them in our job
19:23:39 <adam_g> with the goal of removing the redundent devstack jobs, and consolidating them into just a few
19:23:50 <devananda> looks like our tempest job is not voting in our gate still. pending https://review.openstack.org/#/c/100623/
19:23:50 <adam_g> and getting rid of the big ugly regex we use in devstack-gate
19:24:02 <devananda> adam_g: awesome
19:24:06 <adam_g> Shrews, any updates on how the rebuild testing is coming along?
19:24:31 <Shrews> nothing from my end except added a new compute flag for the rebuild feature. and we should probably think about adding separate icehouse tests at some point
19:25:35 <Shrews> but rebuild test is ready to merge, IMO
19:25:38 <adam_g> cool
19:26:04 <adam_g> thats about it from the tempest front
19:26:21 <devananda> NobodyCam: any news on the tripleo CI front?
19:26:39 <devananda> any progress with the tripleo-undercloud test?
19:27:10 <NobodyCam> I poked infra this morning on the package
19:27:16 <NobodyCam> gah.. patch
19:27:40 <devananda> ok
19:27:56 <devananda> dtantsur: hi! any updates on bugs and fedora coverage?
19:28:21 <dtantsur> devananda, Fedora: devstack work out-of-box once my patch got merged, nothing new here
19:28:35 <devananda> \o/
19:28:37 <NobodyCam> dtantsur: nice
19:28:43 <jroll> \o/
19:28:48 <dtantsur> to the bugs
19:29:08 <dtantsur> people like numbers, so here are numbers: 2 New bugs (0); 123 Open bugs (+5); 36 In-progress bugs (-5); 1 Critical bug (0); 20 High importance bugs (+1); 6 Incomplete bug
19:29:13 <devananda> #info devstack support for Ironic is working on fedora now
19:29:54 <dtantsur> as to me, we're pretty where we used to be last week
19:30:20 <devananda> so, could be worse (and could be better)
19:30:26 <dtantsur> I managed to do some unassigning and reassigning though
19:30:36 <dtantsur> and I have one thing to try clarify
19:30:52 <dtantsur> we lack clarify in how we use assignee field vs "In Progress"
19:31:03 <NobodyCam> dtantsur: the one critical bug still open?
19:31:03 <dtantsur> to me "In Progress" == assigned and that's why:
19:31:36 <dtantsur> NobodyCam, it cound Fix Commited too
19:31:48 <dtantsur> that's default Launchpad stats, thank you for letting me now
19:31:53 <NobodyCam> ahh just not released yet ...
19:32:00 <dtantsur> next time I'll probably count manually or write a script
19:32:21 <devananda> dtantsur: I believe you can filter out bugs by status with URI parameters
19:32:36 <dtantsur> 1. In Progress should be assigned, because there should be one responsible for this "progress"
19:32:58 <devananda> would be good to show stats for bugs not counting fix-committed, otherwise the stats will only decrease when we release milestones
19:32:59 <dtantsur> 2. assigned should be "In Progress" just because it's otherwise hard to track assigned bugs
19:33:23 <devananda> so, IMO, and based on https://wiki.openstack.org/wiki/BugTriage#In_progress_bugs_without_an_assignee
19:33:30 <dtantsur> i.e. launchpad cannot "filter all assigned bugs"
19:33:33 <devananda> bugs which are "in progress" _must_ have an assignee
19:33:45 <dtantsur> agreed
19:33:51 <dtantsur> what about the opposite direction?
19:34:01 <devananda> while a bug may have an assignee without being in progress yet, eg. the person has just started working and has not proposed a fix yet
19:34:31 <dtantsur> devananda, so for you "In Progress" means "Has patch"?
19:34:43 <lucasagomes> that's how I understand it
19:34:55 <lucasagomes> in progress == a patch has been proposed for that bug
19:34:55 <devananda> dtantsur: that's the emergent behavior which I have observed
19:35:05 <devananda> that doesn't make it good, necessarily
19:35:33 <lucasagomes> I'm also fine if we add a policy to, if u assign urself to a bug just mark it as "in progress" straight away
19:35:33 <dtantsur> devananda, the only downside is that you can't easily get all assigned bugs via launchpad ui
19:35:48 <devananda> dtantsur: if we required that all assigned bugs be marked "in progress" as soon as they're assigned, we wouldn't gain anything
19:36:03 <Shrews> also very hard to enforce
19:36:06 <devananda> *we wouldn't gain anything that I'm aware of
19:36:48 <devananda> dtantsur: if you look at a milestone, you can see which bugs are assigned, eg https://launchpad.net/ironic/+milestone/juno-2
19:36:50 <dtantsur> devananda, I'm ok with this approach, than next question: should we force people to not set "In Progress" while they don't have a patch?
19:37:16 <dtantsur> because some people set "In Progress" right away
19:37:20 <devananda> right
19:37:46 <matty_dubs> That's not terribly intuitive -- to me, as soon as I start working on a patch, it's 'in progress'
19:37:57 <matty_dubs> I'm not arguing that it _should_ be that way, but that it's what the term intuitively seems to mean
19:38:04 <jroll> isn't there a 'fix proposed' status?
19:38:06 <mrda> so I see the difference between assigned and in progress being whether someone is actually working on it.  People assign themselves to "reserve" a bug, but haven't necessarily started working on it.
19:38:11 <romcheg> I think it should not be set to In Progress before no one can see the progress
19:38:18 <mrda> it's not good doing that, btw
19:38:24 <dtantsur> mrda, I don't particularly like reserving bugs, yeah
19:38:25 <devananda> mrda: exactly
19:38:54 <devananda> dtantsur: so what is it that we need to solve -- launchpad is a tool we're using to organize work among a very distributed bunch of people
19:39:09 <mrda> but worth noting that once aa patch is pushed, gerrit moves bugs to in progress if they're not already
19:39:11 <devananda> dtantsur: I dont want us to create more work for people (or for you) just to police bug status :)
19:39:27 <NobodyCam> how about adding a commit like "I have an idea for a fix.. but can not start until x/y/z
19:39:44 <dtantsur> devananda, my only concern is people reserving bug and forgetting about it
19:39:46 <matty_dubs> NobodyCam: Do you mean a comment?
19:39:55 <devananda> dtantsur: taht said, we may be able to create tools (ttx has some we can use as templates to get started) to enforce some of these things for us -- if that's going to be beneficial to our development process
19:39:57 <NobodyCam> why yes I do
19:40:09 <mrda> NobodyCam: at least then it opens the door for someone to "steal" if if they have free cycles beforehand...
19:40:23 <jroll> I don't see the problem with jumping in IRC and asking "hey mrda, this is assigned to you, are you working on it or may I?"
19:40:35 <lucasagomes> jroll, +1
19:40:35 <devananda> dtantsur: so for "reserved and forgotten" I think simply enforcing that an assigned bug with no patch revision in the last N days should get human attention and _possibly_ be unassigned
19:40:39 <devananda> dtantsur: is totally reasonable
19:40:40 <NobodyCam> ya, and they would also know someone already has an idea for a fix , and can ping them
19:40:44 <jroll> let people mark bugs as in progress
19:40:50 <dtantsur> devananda, N = 7 IIRC?
19:40:52 <jroll> but hold them responsible for that bug
19:40:54 <devananda> dtantsur: and I bet we can create a script that polls launchpad and prints a list of those bugs
19:40:56 <mrda> jroll: except tz.  We are a global project (it's 5:10am right now here :)
19:41:07 <jroll> mrda: so give them a day to respond
19:41:08 <devananda> dtantsur: that's what we agreed on last time, ya. was just speaking in teh generic sense :)
19:41:09 <dtantsur> devananda, I'm thinking of this script already, yeah
19:41:13 <jroll> mrda: send an email if necessary
19:41:20 * dtantsur likes dashboards :)
19:41:29 <jroll> mrda: there's enough to do where nobody will be blocked because they can't work on bug xyz
19:41:30 <matty_dubs> Is this all documented somewhere? It seems like it should be.
19:41:52 <devananda> so, i think we should leave the states as they are now -- folks are mostly doing the right thing, I think.
19:41:59 <dtantsur> matty_dubs, mostly in hours heads :) I wanted to writing something after this discussion
19:42:07 <dtantsur> * hours = ours
19:42:08 <devananda> and create a script which we can use to help catch forgotten assigned bugs
19:42:21 <devananda> anyone disagree with ^ ?
19:42:29 <matty_dubs> dtantsur: Yeah, I think that'll be good, to make sure everyone's on the same page
19:42:35 <matty_dubs> devananda: +1
19:42:39 <jroll> devananda: I'm fine with that, but s/script/launchpad URL/
19:42:58 <lucasagomes> +1
19:43:01 <dtantsur> not everything is possible with launchpad URL's I'm afraid...
19:43:03 <NobodyCam> I'm good with status quo
19:43:13 <devananda> jroll: i'm not sure it's as simple as a launchpad URL but perhaps someone can host the outptu of said script and refresh taht every N hours or something
19:43:37 <jroll> devananda: sure, I hope it's possible but if not, sure, a script
19:43:55 <dtantsur> ack, thanks to everyone :)
19:44:05 <dtantsur> I guess that's all for me
19:44:26 <mrda> thanks dtantsur
19:44:34 <devananda> #agreed continue using assignee + "in progress" in the current (flexible) way, document our expectation that an assigned bug must be actively worked on, and create a script (or URL with result of script) displaying forgotten bugs for all to see
19:44:39 <devananda> dtantsur: cheers
19:44:52 <devananda> GheRivero: hi! any updates on the oslo front?
19:45:26 <GheRivero> the oslo.db patch is ready. Still with problems when testing in parallel the db migrations tests
19:45:36 <GheRivero> but that an issue we already have
19:45:58 <devananda> GheRivero: sort of....
19:46:05 <lucasagomes> GheRivero, do you think we should wait that to be fixed before merging it?
19:46:12 <devananda> GheRivero: ironic is not actually running migration tests in our gate jobs AFAIK
19:46:30 <GheRivero> lucasagomes: yes. I will wait fot the fixes to get it merged
19:46:45 <GheRivero> and activate the migrations tests in the gate jobs
19:46:47 <lucasagomes> ack
19:46:51 <devananda> GheRivero: great, thanks
19:47:07 <devananda> romcheg: hi! any updates on the nova-> ironic db migration?
19:47:15 <romcheg> Hi all!
19:47:23 <romcheg> Yes, there are some updates
19:47:34 <romcheg> So I moved the code to Nova
19:47:42 <devananda> #info oslo.db patch is ready, but still has a few problems with db migration tests. We should merge it once those are fixed, and enable db migration tests in Ironic's gate at that time.
19:47:57 <romcheg> #link https://review.openstack.org/#/c/101920/
19:48:26 * jroll has to run, enjoy the rest of the meeting :)
19:48:32 <devananda> jroll: thanks, ciao!
19:48:37 <lucasagomes> jroll, see ya
19:48:41 <romcheg> I'm testing now a new patch set that does not copy Ironic models
19:49:01 <devananda> romcheg: do we have any volunteers yet for the grenade testing of this upgrade?
19:49:12 <romcheg> I remember direct imports caused conflicts in the past. It seems now the problem is fixed
19:49:31 <romcheg> devananda: No one volunteered
19:49:50 <devananda> anyone want to volunteer now? heh heh
19:50:01 <romcheg> I can take a look at that too, if no one wants
19:50:09 <romcheg> But more time is required
19:50:21 <romcheg> So I have also made a tool that updates nova flavors
19:50:31 <romcheg> The only question is the input format
19:50:37 <devananda> romcheg: ack. please continue focusing on the nova migration itself
19:50:39 <rloo_> does the migration tool belong in nova/baremetal, or ironic? (just wondering)
19:50:54 <romcheg> rloo_ nova
19:51:08 <rloo_> romcheg: but it is going to modify ironic db?
19:51:16 <romcheg> It is
19:51:29 <rloo_> romcheg: so why nova?
19:51:36 <devananda> rloo_: that question was raised on the nova spec, but nova team hasn't answered yet
19:51:54 <rloo_> romcheg: also wondering if it is in nova, and we modify ironic db still before juno, how hard/easy will it be to update it in nova?
19:52:03 <romcheg> There was a discussion in specs, there's still no answer but it's more likely it will be nova
19:52:16 <rloo_> romcheg, devananda: ok.
19:52:28 <devananda> rloo_: it's nova's responsibility to accept a migration tool away from the driver they will be deprecating
19:52:31 <romcheg> So regarding to the input format
19:52:50 <devananda> rloo_: but that's a good point -- we may need to make changes to that migration tool before the end of juno
19:53:04 <romcheg> Every flavour might have it's own deploy kernel and ramdisk
19:53:22 <rloo_> romcheg: just wondering. does the tool assume the ironic db is 'housed' by the same db server as the nova db?
19:53:49 <devananda> #info seeking volunteers for creating grenade testing for upgrades from nova-baremetal to ironic. reference: https://review.openstack.org/#/c/95025/
19:54:05 <romcheg> I think it's better to make csv file like flavor, new_kernel_uuid, new_ramdisk_uuid and give that to the migration tool
19:55:11 <NobodyCam> * five minute beep
19:55:12 <romcheg> What do you think?
19:55:40 <devananda> romcheg: AFAIK, it needs to be able to run against a deployment of openstack
19:56:03 <devananda> romcheg: so if one tool connects to nova and saves a .csv with that info, and a second tool parses that .csv -- that's probably fine, and may be more easily tested
19:56:10 <romcheg> devananda: It's the user who builds and uploads the stuff to glance
19:56:28 <NobodyCam> devananda: dose it need to support live migrations?
19:56:28 <devananda> ok, gotta move on
19:56:37 <NobodyCam> mv
19:56:38 <devananda> #link https://review.openstack.org/#/c/95025/
19:56:46 <romcheg> NobodyCam: Oh, please not now, it's such a pain :)
19:56:49 <devananda> for anyone curious about the upgrade path, it's all proposed there ^
19:57:12 <devananda> thanks to everyoen for the great subteam reports again this week!
19:57:16 <devananda> #topic open discussion
19:57:21 <devananda> 3 minutes left - go :)
19:57:29 <dtantsur> ifarkas, had question about ceilometer IIRC
19:57:31 <lucasagomes> idk if there's enough time but
19:57:37 <matty_dubs> For the meetup -- are people leaving mid-day Weds., or should we plan 3 full days?
19:57:40 <lucasagomes> do we still want consistency on the partition sizes parameters (ephemeral, root, swap)?
19:57:42 <devananda> lucasagomes: i think you wanted to bring up the GB/MB discussion
19:57:43 <devananda> :)
19:57:48 <lucasagomes> devananda, yup
19:57:54 <ifarkas> devanand, yeah, wanted to check the progress of the celiometer integration
19:58:00 <lucasagomes> if so, how people want to do it?
19:58:01 <devananda> yea, might be worth taking to the mailing list ... this one has dragged on for too long IMO
19:58:08 <lucasagomes> 1- Everthing to be in MB?
19:58:08 <lucasagomes> 2- Everything GB and float (so 0.5 == 512MB)?
19:58:08 <lucasagomes> 3- Everything GB and rounding it up the swap size (because swap is MB in nova) so if users says 512 MB they will get 1GB in Ironic?
19:58:16 <NobodyCam> if anyone happens to be in infra a poke for https://review.openstack.org/#/c/100063 would be awesome
19:58:17 <devananda> ifarkas: afaik no work has been done this cycle
19:58:29 <lucasagomes> devananda, ack
19:58:29 <devananda> ifarkas: we had a summit session with ceilometer folks
19:58:52 <ifarkas> devanand, thanks, I will check it with Haomeng
19:58:55 <devananda> ifarkas: my take away was that they feel ironic should expose $things ina  pluggable way, but ceilometer probably won't consume them initially
19:58:57 <NobodyCam> lucasagomes: are there plans for nova to move to GB (EVER)
19:58:58 <matty_dubs> It didn't go swimmingly.
19:59:02 <lucasagomes> NobodyCam, no
19:59:17 <devananda> ifarkas: https://etherpad.openstack.org/p/juno-ironic-and-ceilometer
19:59:40 <NobodyCam> i may vote to have our interface match theirs (ie MB)
19:59:44 <devananda> ifarkas: hmm, looks ilke there weren't a lot of notes there :(
19:59:55 <lucasagomes> NobodyCam, only for swap?
19:59:57 <dtantsur> lucasagomes, as before I vote for (1)
20:00:08 <dtantsur> i.e. MiB for everything
20:00:09 <lucasagomes> dtantsur, yeah cheers
20:00:15 <NobodyCam> no
20:00:21 <NobodyCam> dtantsur: ++
20:00:30 <devananda> time's up - let's continue in channel as needed
20:00:32 <lucasagomes> ok 2 votes for 1)
20:00:35 <lucasagomes> devananda, ?
20:00:37 <rloo_> lucasagomes: but if we do MB, then we're allowing folks to do root/ephemeral in sizes that aren't GB units.
20:00:38 <lucasagomes> oh time
20:00:43 <devananda> lucasagomes: oh, do we need a vote real quick?
20:00:52 <lucasagomes> devananda, nop
20:00:59 <lucasagomes> let's go to the channel
20:01:01 <NobodyCam> thank you all
20:01:02 <devananda> k k
20:01:03 <romcheg> Thanks everyone!
20:01:06 <rloo_> lucasagomes: and I thought that was one of lifeless' objections.
20:01:06 <devananda> thanks everyone!
20:01:12 <devananda> #endmeeting