19:00:02 <NobodyCam> #startmeeting Ironic
19:00:02 <NobodyCam> #chair devananda
19:00:02 <openstack> Meeting started Mon Jan 20 19:00:02 2014 UTC and is due to finish in 60 minutes.  The chair is NobodyCam. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:04 <NobodyCam> Welcome everyone to the Ironic meeting.
19:00:06 <openstack> The meeting name has been set to 'ironic'
19:00:07 <openstack> Current chairs: NobodyCam devananda
19:00:15 <romcheg> o/
19:00:20 <NobodyCam> who here for the meeting
19:00:22 <agordeev2> o/
19:00:24 <devananda> \o
19:00:25 <lucasagomes> o/
19:00:26 <NobodyCam> who's even
19:00:29 <max_lobur> o/
19:00:29 <ifarkas> \o
19:00:35 <GheRivero> o/
19:00:35 <rloo> me
19:00:41 <NobodyCam> Of course the agenda can be found at:
19:00:42 <NobodyCam> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
19:00:44 <yuriyz> +
19:01:10 <k4n0> o/
19:01:10 <NobodyCam> #topic Greetings, and announcements
19:01:13 <NobodyCam> welcome all
19:01:37 <NobodyCam> ok let start with a quick announcement
19:01:48 <haomeng2> wel
19:02:04 <NobodyCam> devananda: sent a really good email to the list yesterdat
19:02:06 <NobodyCam> http://lists.openstack.org/pipermail/openstack-dev/2014-January/024823.html
19:02:10 <NobodyCam> #link http://lists.openstack.org/pipermail/openstack-dev/2014-January/024823.html
19:02:21 <NobodyCam> def worth the read
19:02:49 <k4n0> NobodyCam: thanks for the link
19:03:17 <haomeng2> got it
19:03:30 <NobodyCam> its a holiday here so I may be a bit slow
19:03:33 <NobodyCam> :-p
19:04:02 <max_lobur> hehe
19:04:12 <NobodyCam> lets jump into
19:04:13 <NobodyCam> #topic Outstanding, in-progress or Action Item updates
19:04:37 <NobodyCam> Icehouse release progress // graduation?
19:04:43 <haomeng2> :)
19:04:45 <NobodyCam> this is the week
19:04:56 <NobodyCam> we are so close!
19:05:09 <devananda> yep
19:05:13 <NobodyCam> dkehn: are you around?
19:05:16 <rloo> what do you mean, this is the week?
19:05:23 <devananda> so i'm going to be working with ttx this week to get the i2 release tested and tagged
19:05:35 <lucasagomes> nice
19:05:43 <devananda> s/release/milestone
19:05:56 <rloo> so if we don't make i2, we won't graduate?
19:06:10 <dkehn> NobodyCam: just got here
19:06:16 <NobodyCam> :)
19:06:17 <devananda> rloo: not exactly
19:06:26 <devananda> rloo: this is a checkpoint of sorts
19:06:30 <dkehn> NobodyCam: eating lunch
19:06:45 <NobodyCam> :)
19:06:48 <rloo> devananda: ok. (phew).
19:06:51 <devananda> the TC evaluates our progress as a project towards becoming part of the release process here
19:07:21 <romcheg> Guys, I have a few questions about migrations from Nova
19:07:36 <romcheg> This is the thing we also need to have as soon as possible
19:08:04 <devananda> so it's more about me working with them to get the milestone tagged, tested, etc.
19:08:08 <NobodyCam> romcheg: that would be nice to have... but is not required as I understand it
19:08:24 <devananda> we are so close to having deploy() working, though, and I was hoping we'd have it done this week
19:08:26 <romcheg> Ah, cool then
19:08:34 <lucasagomes> NobodyCam, I thought it was required
19:08:43 <romcheg> but I still have the questions :)
19:08:52 <devananda> migration from nova is required, but not this week
19:09:01 <devananda> we need that by icehouse release
19:09:07 * NobodyCam notes holiday status and use of the word understanding
19:09:21 <NobodyCam> but not the mile stone
19:09:32 <devananda> correct
19:09:36 <devananda> by april something
19:09:43 <lucasagomes> devananda, do you have a checklist points of what is missing for deploy(). Neutron integration?
19:10:02 <rloo> so what is needed, if anything for icehouse-2 this week? (ie, what do you need if anything, from us, todo?)
19:10:19 <devananda> lucasagomes: not off hand, no. i'm still recovering my test env after LCA
19:10:29 <lucasagomes> I've tested the deployment with some variables off (neutron and nova), and at least the ironic part seems to be stable
19:10:44 <NobodyCam> lucasagomes: the main is setting the dhcp options for pxe boot
19:10:51 <devananda> lucasagomes: with what's in trunk, or with patches taht are in flight?
19:10:57 <NobodyCam> which has to come from the conductor incharge
19:11:00 <lucasagomes> devananda, with the patches
19:11:10 <devananda> lucasagomes: ok. so lett's land those
19:11:15 <lucasagomes> but none of them are big patches
19:11:23 <devananda> lucasagomes: can you (after the meeting) call those out to me specificaly?
19:11:28 <lucasagomes> for those interested, there's a guideline I wrote (and has being improved by others)
19:11:34 <devananda> i'll prioritize reviewing/fixing/landing that stuff today
19:11:36 <lucasagomes> #link https://etherpad.openstack.org/p/IronicDeployDevstack
19:11:39 <lucasagomes> devananda, sure
19:11:42 <lucasagomes> thanks
19:12:34 <lucasagomes> NobodyCam, yea, I hear ya, I didn't test the dhcp part integrated with neutron yet
19:12:42 <NobodyCam> ok to bring the meeting back under control
19:13:09 <NobodyCam> do we want to go over the bp/ bugs?
19:13:28 <NobodyCam> lucasagomes: that really about it.
19:13:33 <devananda> let's see what's targeted to i2
19:13:38 <devananda> and either close it or bump it
19:13:45 <devananda> #link https://launchpad.net/ironic/+milestone/icehouse-2
19:14:01 <devananda> BP's first
19:14:03 <devananda> #link https://blueprints.launchpad.net/ironic/+spec/pxe-mount-and-dd
19:14:08 <NobodyCam> I have thought about a hack that would allow supporting a single conductor, but its not the right way
19:14:12 <devananda> we know this works now, so we can close it, yes?
19:14:23 <GheRivero> yes
19:14:43 <GheRivero> it was more an historic bp
19:14:44 <lucasagomes> +1
19:14:54 <devananda> agreed
19:14:57 <devananda> #link https://blueprints.launchpad.net/ironic/+spec/add-neutron-support
19:15:05 <devananda> this one is still stuck. let's move it to i3
19:15:07 <devananda> yes?
19:15:24 <GheRivero> +1
19:15:30 <NobodyCam> we kinda have too
19:15:37 <lucasagomes> makes sense to me
19:15:46 <devananda> k
19:15:51 <devananda> #link https://blueprints.launchpad.net/ironic/+spec/instance-mapping-by-consistent-hash
19:16:00 <devananda> what about that one?
19:16:30 <lucasagomes> we have almost pretty much everything for this one in place already right?
19:16:38 <NobodyCam> most of it has landed no?
19:16:39 <lucasagomes> list of conductors, routing the rpc calls
19:16:42 <devananda> yep
19:16:51 <devananda> rebalance / takeover hasn't landed yet
19:16:57 <devananda> but i can do that separeately
19:17:01 <NobodyCam> ya
19:17:08 <NobodyCam> core function are there
19:17:15 <max_lobur> +1
19:17:25 <rloo> there's something about update mapping in neutron?
19:17:39 <devananda> yea, that's aprt of the takeover
19:17:42 <lucasagomes> rloo, takeover?
19:17:46 <devananda> and depends on the neutron work in teh prior BP
19:17:52 <devananda> i should add that as a dependency
19:17:57 <devananda> well
19:18:19 <devananda> #action deva to file a new bp for takeover, including the neutron update part, and remove this from https://blueprints.launchpad.net/ironic/+spec/instance-mapping-by-consistent-hash
19:18:23 <NobodyCam> we will need a initial way of setting it for the options for neutron
19:18:31 <devananda> lastly
19:18:32 <devananda> #link https://blueprints.launchpad.net/ironic/+spec/serial-console-access
19:18:42 <devananda> sjing has posted code for this but i dont know if anyone of us have tested
19:18:46 <devananda> (i haven't)
19:18:53 * NobodyCam has not :(
19:19:02 * GheRivero not me
19:19:18 <lucasagomes> me neither
19:19:18 <devananda> ok, i'll bump
19:19:29 <NobodyCam> to i-3?
19:19:31 <lucasagomes> it needs ipmi to test it
19:19:53 <NobodyCam> #action nobodycam to test serial-console
19:20:04 <haomeng2> devananda: it is in code review status. need more comments
19:20:10 <devananda> yes
19:20:10 <NobodyCam> we can do it ipmi native
19:20:50 <NobodyCam> for us to say we have it will we NEED it in ipmitool?
19:20:57 <devananda> there are many open bugs targeted to i2
19:22:26 <devananda> anyone blocked on anything in particular there?
19:22:45 <max_lobur> me
19:22:50 <NobodyCam> deva can we bump anything below high ?
19:22:51 <rloo> (reviewers)
19:22:52 <max_lobur> I can't reproduce https://bugs.launchpad.net/ironic/+bug/1244747
19:23:10 <devananda> NobodyCam: we can bump anything we need to, but i'd rather get them fixed :)
19:24:00 <devananda> max_lobur: it looks like lucasagomes referenced a bug in pecan/wsme as a possible cause
19:24:10 <NobodyCam> rloo: smack /me upside the head when that is the case
19:24:10 <max_lobur> deva
19:24:17 <max_lobur> that's a separate bug
19:24:24 <lucasagomes> actually, there's two different approach
19:24:29 <max_lobur> just another way to implement the hook
19:24:29 <rloo> NobodyCam. Sure, a virtual smack? :-)
19:24:35 <lucasagomes> max_lobur, approach doesn't need wsme to be fixed
19:25:10 <max_lobur> devananda, lucasagomes yes, we're able to fix on current wsme already
19:25:30 <max_lobur> I mean it's already seems fixed to me ;)
19:26:16 <NobodyCam> devananda: this seems kinda big-ish
19:26:21 <NobodyCam> #link https://bugs.launchpad.net/ironic/+bug/1187209
19:27:21 <devananda> sorry guys, gotta step away for 2 mintues. brb
19:28:00 * NobodyCam turns on the wheel-of-fourtune music
19:28:18 <lucasagomes> so mostly of the bugs seems to be marked as in-progress
19:28:22 <lucasagomes> bugs for i2
19:28:27 <NobodyCam> ya
19:28:38 <NobodyCam> I think we'doing good on them
19:29:24 <max_lobur> NobodyCam, stevedore bug doesn't seems hard to fix
19:29:34 <max_lobur> also it's low priority
19:29:47 <NobodyCam> max_lobur: ya after re-rereading it I was just about to say that
19:29:59 <max_lobur> hehe :)
19:30:22 <NobodyCam> shall we move on to the call outs
19:30:46 <NobodyCam> #Topic Callouts
19:30:49 <devananda> back
19:30:59 <NobodyCam> WB
19:31:34 <NobodyCam> nova driver while still lacking any real tests can deploy a nova
19:32:04 <devananda> woot! good job!
19:32:06 <NobodyCam> it is current stuck at deploy as the node never attempts to pxe boot
19:32:38 <NobodyCam> its just that the pxe options are not set. (for neutron)
19:32:45 <lucasagomes> does that gets fixed after passing the dhcp options to neutron
19:32:47 <lucasagomes> via pxe driver?
19:33:00 <lucasagomes> ok that asnwer
19:33:01 <NobodyCam> yes
19:33:13 <NobodyCam> :)
19:33:14 <lucasagomes> good stuff NobodyCam :D
19:33:37 <NobodyCam> #topic testing
19:34:03 <NobodyCam> romcheg: devananda any thing to say on testing?
19:34:39 <romcheg> NobodyCam: agordeev2 is working on basic infrastructure for intergation testing
19:34:51 <romcheg> agordeev2: are you around?
19:34:58 <agordeev2> yep, i'm here
19:35:15 <NobodyCam> Hey agordeev2 :) welcome
19:35:22 * lucasagomes brb
19:35:26 <romcheg> AFAIR there were several questions about how to perform initial configuration
19:35:49 <devananda> waiting for this to land
19:35:51 <devananda> #link https://review.openstack.org/#/c/65845/
19:35:54 <agordeev2> on last thirsday i'd visited QA meeing just to highlight testing scheme and get more attention to it.
19:36:07 <devananda> which will move tempest API tests from the experimental pipeline into check & gate
19:36:20 <romcheg> But I don't think that creating VMs in tempest is a good idea because it's unlikely to be accepted
19:36:57 <devananda> romcheg: our discussion on the ML seemed to settle on that being the right approach
19:36:57 <agordeev2> agreed
19:37:28 <devananda> romcheg, agordeev2 - what do you suggest intead of creating the VMs via tempest?
19:37:50 <romcheg> I would do that in devstack.
19:38:14 <devananda> ok. that was my initial suggestion :)
19:38:37 <devananda> create the VMs and the bridge in devstack as part of the bring-up
19:38:44 <devananda> dump the MACs to a text file
19:38:49 <romcheg> Or even in nodepool. That might be more efficient but then regular users will have to create vms by hands
19:39:02 <devananda> then we can do the enrol/deploy/undeploy/delete in the tempest tests
19:39:07 <lucasagomes> back
19:39:13 <devananda> not nodepool
19:39:48 <romcheg> The good thing in nodepool AFAIK is that it can pre-create test nodes. So that might reduce the time required for running a job
19:39:51 <devananda> we should be able to run these tests with tempest + devstack. it shouldn't need more infrastructure
19:40:15 <NobodyCam> devananda: agreeded :)
19:40:17 <romcheg> I vote for devstack as well
19:40:32 <romcheg> I just had to mention that thing about nodepool :)
19:40:44 <max_lobur> :)
19:40:44 <NobodyCam> :)
19:40:57 <devananda> devstack making some quick calls to libvirt to create NN vm's shouldn't take taht long
19:40:57 <NobodyCam> ok anything else on testing
19:41:00 <devananda> it's not installing anything
19:41:05 <devananda> just making blank VMs
19:41:20 <devananda> on testing, just to mention again my email about third-party testing
19:41:29 <devananda> but if anyone has comments, please discuss on the ML, not here today
19:41:43 <NobodyCam> :)
19:42:04 <romcheg> No more news from me
19:42:10 <NobodyCam> ok :)
19:42:15 <NobodyCam> what to move to
19:42:41 <NobodyCam> agenda says:
19:42:42 <NobodyCam> #topic Food for Thought / Open Discussion
19:43:05 <k4n01> I wanted to update you guys on SeaMicro driver status
19:43:06 <romcheg> Guys, I have a few questions on migrating from Nova
19:43:11 <NobodyCam> shot
19:43:19 <devananda> k4n01: great! please do
19:43:20 <max_lobur> I'd like to discuss a race bug today
19:43:25 <max_lobur> but since it may be long
19:43:35 <max_lobur> we may proceed on our chart
19:43:39 <max_lobur> -chat
19:43:59 <romcheg> So I wrote a script that converts nova's db into Ironic db
19:44:01 <k4n01> We have finished coding for the Power and VendorPassThru blueprints, we doing internal reviews and will be ready for community before end of this week
19:44:04 <NobodyCam> max_lobur: if thats ok we can do in channel after meeting?
19:44:24 <devananda> max_lobur: you're referring to the need for an intent lock between API cals, yes? yea, let's do in channel. i'll be around for a while
19:44:31 <romcheg> However Ironic's DB will change in the future
19:44:34 <NobodyCam> k4n01: awesome
19:44:34 <lucasagomes> max_lobur, I remember devananda raised some q about python threads (os threads) and green threads
19:44:42 <lucasagomes> have you looked into it?
19:44:44 <k4n01> devananda: did you see my update to SeaMicro VendorPassthru blueprint?
19:44:53 <devananda> k4n01: no. lemme take a look now
19:44:59 <romcheg> So I think whether it's reasonable to use existing migrations somehow?
19:45:00 <NobodyCam> k4n01: please take look at devananda's email to the list
19:45:38 <devananda> romcheg: i can think of two solutions
19:45:40 <k4n01> NobodyCam: Yes, already read it, i agree with those 5 points in email, and I will come up with SeaMicro's plan to implement them till next time we have meeting
19:45:43 <max_lobur> devananda, lucasagomes, NobodyCam yes, lets discuss in ironic chat. I have an answer to green threads question. I'm armed and dangerous :)
19:45:52 <lucasagomes> :D
19:46:20 <NobodyCam> k4n01: :) Ty
19:46:25 <devananda> romcheg: 1. we keep the novadb->ironicdb migration review open and maintain it until icehouse-3 milestone, at which point feature freeze should prevent (most) db changes after taht
19:46:30 <devananda> romcheg: and we land it at that point
19:46:47 <devananda> romcheg: or, 2) we land it now, and maintain it via additional small patches until icehouse release
19:46:56 <romcheg> If someone wants to migrate after i3?
19:47:15 <romcheg> We might want to change the DB in future releases
19:47:30 <devananda> romcheg: we'll need the migration script to be applicable on the icehouse release itself
19:47:37 <devananda> romcheg: not after taht
19:47:51 <romcheg> makes sense
19:47:53 <devananda> noav-bm will be marked deprecated if ironic graduates this cycle
19:47:59 <NobodyCam> devananda: ++
19:48:03 <devananda> so no new changes to nova_bm schema will be allowed
19:48:05 <devananda> after taht
19:48:14 <NobodyCam> after then uses should uising Ironic
19:48:28 <devananda> and migration path can be defined as Icehouse Noav_bm -> Icehouse Ironic -> "J" Ironic -> "K" Ironic ... etc
19:48:31 <romcheg> Sounds like a dictatorship but I like it :)
19:48:32 <NobodyCam> users
19:49:09 <NobodyCam> :)
19:49:16 <devananda> k4n01: i dont see a reply on either BP
19:49:17 <romcheg> The second question was how should be store this utility, but now I understand that it should be the part of Ironic distribution, shouldn't it??
19:49:28 <devananda> romcheg: yes, part of ironic
19:49:41 <devananda> romcheg: something like our ironic-dbsync utility.
19:49:49 <devananda> romcheg: eg, ironic-import-db-from-nova, or something
19:49:50 <k4n01> devananda: i have updated the main description of https://blueprints.launchpad.net/ironic/+spec/seamicro-vendor-passthru-interface-implementation
19:49:56 <romcheg> yes, makes sense
19:50:03 <NobodyCam> in https://github.com/openstack/ironic/tree/master/tools
19:50:13 <k4n01> devananda: I am not sure if that triggers an update mail to people involved , sorry
19:50:19 <lucasagomes> and what people thinks about: dict-like behavior on the ironic objects  should be removed or stay? (https://review.openstack.org/#/c/64336)
19:50:24 <romcheg> Should that be one single migrate_from_nova script or a series of scripts?
19:50:26 <devananda> k4n01: ah! i see now, thanks. I will review the more detailed BP after meeting
19:50:28 <rloo> it seems to me that from user's point of view, icehouse nova_bm->icehouse ironic, icehouse nova_bm->J ironic, etc would make more sense.
19:50:34 <devananda> #action devananda to review https://blueprints.launchpad.net/ironic/+spec/seamicro-vendor-passthru-interface-implementation
19:50:47 <k4n01> devananda: ok, i will hang around #openstack-ironic
19:50:48 <romcheg> like migrate_nova_db build_nova_tftproots
19:51:30 <max_lobur> lucasagomes, I'd vote for removing dict like behavior
19:51:32 <devananda> rloo: in my past discussions with the TC and other PTLs, taht didnt' seem necessary. take cinder and neutron as examples. they didn't skip releases like that
19:51:43 <max_lobur> I don't see any profit on it
19:51:51 <rloo> devananda: ok, if there's a precedence, that's fine.
19:51:52 <NobodyCam> romcheg: I like the chain of scripts (with a wrapper to make it easy to use ofc)
19:51:52 <max_lobur> (dict like behavior)
19:52:04 <lucasagomes> right, yea I kinda like the idea of having only one consistent way to access the the objects attributes, so I would remove the dict behavior as well
19:52:17 <devananda> rloo: but if, during the J release, someone wants to add a "migrate from icehouse nova to J ironic" script, and that is even possible given how different our arch might be by then.... i dont think there'll be a problem with it
19:52:24 <GheRivero> i would remove dict behaviour too
19:52:48 <devananda> lucasagomes: i'm fine with removing dict usage of objects
19:52:56 <max_lobur> great
19:52:56 <rloo> wrt remove dict behaviour, i think that makes sense, but the review only removes the [] part of dict like behaviour.
19:52:58 <devananda> lucasagomes: however that object code in noa stil lhas it
19:53:14 <lucasagomes> devananda, yea, I commented that on patch one
19:53:19 <devananda> lucasagomes: and when it moves to oslo (which I think is in progress???) it will still be there, too, i believe
19:53:19 <lucasagomes> I don't think we should diverge from nova
19:53:19 <NobodyCam> I would go along as well :-p
19:53:30 <max_lobur> rloo and what else?
19:53:37 <devananda> lucasagomes: so we can't actualy REMOVE that support fromour code. we can jsut -1 any patch that tries to use it
19:53:54 <lucasagomes> devananda, right, so shouldnot remove it from the base object code
19:53:58 <devananda> right
19:54:07 <rloo> max_lobur. there are a bunch of methods that support dict-like behaviour, not just the setitem/getitem stuff I think.
19:54:17 <max_lobur> I see
19:54:40 <lucasagomes> devananda, cool, right that looks reasonable for me
19:54:48 <lucasagomes> I will review that series of patches as well
19:54:52 <NobodyCam> so maybe a blueprint with whats required ?
19:55:06 <NobodyCam> (to remove dict_*)
19:55:08 <devananda> also, removing dict-like object access is pretty low on my priority list
19:55:14 <max_lobur> so we'll just remove usages right?
19:55:30 <lucasagomes> devananda, yea, just brought it up beucase it's on the meeting calendar
19:55:36 <devananda> lucasagomes: ah. thanks
19:55:53 <max_lobur> we can also have an intermediate parent class between oslo's object and our, which will throw exception in dict methods
19:56:01 <max_lobur> to be sure we're not using them
19:56:12 <NobodyCam> if lucasagomes is looking at the actual agenda
19:56:16 <rloo> seems like a lot of work to do for ... ??
19:56:17 <max_lobur> or it will be to much? :)
19:56:22 <NobodyCam> can we talk about Using an intent/two-phase lock or a thread to solve the race condition in four moinutes
19:56:27 <NobodyCam> minutes even
19:56:35 <lucasagomes> NobodyCam, +1, in the ironic channel
19:56:36 <lucasagomes> :)
19:56:51 <NobodyCam> :)
19:56:57 <max_lobur> there's a point about tempest coverage
19:57:03 <max_lobur> I started to expand it
19:57:23 <max_lobur> but it turns out to be just porting all the tests from our API
19:57:53 <devananda> max_lobur: our API unit tests aren't actually exercizing all the pathways (RPC, DBAPI, etc)
19:58:17 <max_lobur> for RPC - true
19:58:22 <devananda> so tempest API tests are functional tests. yes, they may cover the same CRUD operations
19:58:27 <max_lobur> that's definitely should be in tempest
19:58:33 <max_lobur> for orthers
19:58:34 <devananda> but i dont' think they're duplicate effort
19:58:54 <max_lobur> do you think we need to expand coverage in tempest or just add some tests to the api?
19:59:07 <devananda> what's missing?
19:59:09 <dkehn> in some cases yes, in some no, grenade is a ersion upgrade testing
19:59:26 <max_lobur> because tempest will require a separate patch to update tests, it may be not convenient
19:59:38 <dkehn> soem of the others rely on the devstack exercises etc.
19:59:39 * NobodyCam note times up
19:59:47 <dkehn> note
19:59:51 <devananda> max_lobur: not convenient to do what?
19:59:52 <NobodyCam> :)
20:00:03 <max_lobur> to update tempest for each API change
20:00:13 <devananda> dkehn: grenade is a great effort. but ironic doesn't have a prior release to upgrade from (yet)
20:00:19 <NobodyCam> we should move back to channel
20:00:25 <max_lobur> https://review.openstack.org/#/c/67854/1 expanding tempest coverage
20:00:26 <dkehn> assuming it will
20:00:40 <devananda> yep, times up -- let's continue these great discussions back in channel
20:00:47 <devananda> thanks everyone!
20:00:52 <haomeng2> bye
20:00:54 <lucasagomes> thanks
20:00:58 <NobodyCam> thank you all see un in channel
20:01:01 <haomeng2> thk
20:01:01 <devananda> #endmeeting