21:00:46 <danwent> #startmeeting quantum
21:00:47 <openstack> Meeting started Mon Oct 22 21:00:46 2012 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:49 <openstack> The meeting name has been set to 'quantum'
21:01:06 <danwent> gongysh, did you or garyk get the award for longest distance traveled?
21:01:11 <danwent> probably garyk?
21:01:16 <gongysh> no
21:01:26 <garyk> i had 8 hours at heathrow :)
21:01:30 <danwent> haha
21:01:41 <danwent> #link agenda: http://wiki.openstack.org/Network/Meetings
21:01:44 <rkukura> hi
21:01:47 <amotoki> hi
21:01:50 <salv-orlando> I got flu on the plane :/
21:01:55 <danwent> we have a ton to cover, so let's get going
21:01:57 <sasha_> hi
21:02:08 <danwent> ok, apologies for starting the discussion on who had the worst flight :P
21:02:29 <danwent> #info Grizzly release schedule has been finalized http://wiki.openstack.org/GrizzlyReleaseSchedule
21:02:35 <garyk> i had the worst and the longest
21:02:37 <danwent> the big news is that there is no big news
21:02:51 <danwent> release schedule is following pretty much the same pattern as folsom
21:03:09 <danwent> three milestones, fairly long RC time.  two weeks between release and next summit.
21:03:11 <garyk> if possible we should also try and contain bugs
21:03:25 <danwent> garyk: ?
21:04:02 <danwent> garyk: sorry, don't understand the last statement
21:04:09 <garyk> danwent: it seems like lately there are quite a few bugs opened. we should try and make sure that the open bugs stays low
21:04:15 <garyk> danwent: does that make sense
21:04:26 <danwent> garyk: ah yes, in fact, we'll talk about that later down on the agenda
21:04:41 <garyk> ok, sorry for the interruption
21:04:50 <danwent> as I wanted to discuss the set of bugs open against folsom and when we should target a stable folsom update
21:04:52 <danwent> no worries
21:05:05 <danwent> #topic Grizzly-1
21:05:15 <danwent> so the Grizzly-1 date is actually just a month away
21:05:53 <danwent> so I wanted to spend a chunk of this meeting making sure we have blueprints created for key community tasks needed early in grizzly
21:06:10 <danwent> as rkukura pointed out during the summit, there's a need for us to do a better job as a community creating blueprints
21:06:31 <gongysh> agree
21:06:40 <nati_ueno> +1
21:06:41 <danwent> a blueprint should be good enough that a reveiwer can read it before reviewing the code and understand what you are trying to achieve, and roughly how you plan to achieve it
21:06:54 <garyk> +1
21:07:17 <markmcclain> +1
21:07:21 <garyk> it will certainly help the review process
21:07:27 <salv-orlando> salv_orlando: +1 (this also implies we as cores must review blueprints too)
21:07:30 <garyk> and documentation
21:07:33 <danwent> let's all hold each other to a higher standard.  If you go to review something that is bigger than a bug fix, and you find that the blueprint is not sufficient, moving forward we should as the feature creator to improve the blueprint before reviewing
21:07:49 <rkukura> early feedback on the blueprints is also important, well before the review
21:07:59 <danwent> garyk: agreed.  one idea i had been thinking about was requiring docs along with a change-set, but that is hard in practice.
21:08:18 <danwent> garyk: but i'm open to ideas there… leaving all docs to the end of the release is bad
21:08:39 <garyk> danwent: if we follow the suggestions for the detailed blueprints then it should be easier to port to docs later
21:08:51 <salv-orlando> danwent, garyk: that is feasible IMHO. Just a matter of establishing rules for things.
21:09:01 <garyk> salv-orlando: agreed
21:09:15 <gongysh> a good spec is ok.
21:09:17 <salv-orlando> A desirable side effect would be avoiding feature creep
21:09:47 <danwent> salv-orlando: are you suggesting docs in the admin guide before code is committed, or just a blueprint that people thing is good enough to turn into docs?
21:10:38 <danwent> the issue is that often features arrive in several commits, making the former difficult.
21:10:38 <salv-orlando> Ideally one would like to have the documents before the code is merged. Then this could be evaluated case by case
21:11:02 <salv-orlando> danwent: agree. Let's see what we can do offline
21:11:49 <danwent> ok.  salv-orlando, can you put together a proposal for this?  It sounds like something we should have on the quantum development wiki page for (how do i implement a feature?)
21:12:32 <danwent> garyk: sounds like you're interested as well.  perhaps you and salv-orlando can coordinate
21:12:44 <garyk> danwent: ok
21:12:51 <gongysh> I will review. Haha
21:12:57 <salv-orlando> danwent: sure
21:12:59 <danwent> gongysh: :)
21:13:34 <danwent> Ok, so i'm going to quickly move through some  of the quick community topics, to identify who will be putting blueprints together on the key community topics discussed at teh summit
21:13:55 <danwent> CI gating (nati_ueno ?  mnewby ?)
21:14:08 <danwent> do we have a blueprint that we are using for this?
21:14:11 <nati_ueno> I'm working on execise.sh to work
21:14:15 <mnewby> danwent: Not sure
21:14:27 <nati_ueno> danwent: We can reuse this https://blueprints.launchpad.net/quantum/+spec/quantum-gate
21:14:28 <garyk> danwent: dan prince is intersted in getting smokestack working with quantum
21:14:32 <nati_ueno> Please assign it to me
21:14:33 <danwent> ok, this will be the top focus of every quantum team meeting until we do.
21:14:45 <danwent> or rather, until we have a gate running with quantum
21:14:53 <garyk> i think that we should maybe invest in the smokestack like nova.
21:15:05 <mnewby> garyk: What is smokestack executing?
21:15:19 <nati_ueno> garyk: +1 for smokestack
21:15:39 <danwent> nati_ueno: ok, updated the BP, assigned it to you, and updated other fields
21:15:40 <mnewby> garyk, nati_ueno: what is the relationship between smokestack and tempest?
21:15:46 <garyk> mnewby: as far as i understand it runs installation packages, puppet moduels etc. launches vm's and test traffic between them. i can ask dan for extra details
21:16:07 <nati_ueno> mnewby: Yes. It is another CI process.
21:16:29 <danwent> will smokestack continue to run even once we have full tempest integration?
21:16:46 <danwent> I am not sure if they are duplicate efforts, or have different goals.
21:16:56 <mnewby> it sounds like duplicative
21:17:10 <garyk> http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCsQFjAA&url=http%3A%2F%2Fwiki.openstack.org%2Fsmokestack&ei=ybeFUML3JI3LtAbfjICgBw&usg=AFQjCNGcZzE9UMz-BrrfJsR4-iWxGspmaQ
21:17:12 <mnewby> it's useful, but if developers can't run the tests themselves i question it's longterm value
21:17:47 <mnewby> Oh well, I guess we do both.
21:18:28 <garyk> i think that i should be used for our gating.
21:18:31 <mnewby> I'm more interested in single-host (devstack) testing (at least initially), but for gating we'll need all of the aboev.
21:20:07 <danwent> garyk: can you ask dan prince about the long-term direction of the openstack community regarding tempest vs. smokestack?  What i've been told to date is that our efforts should be focused on tempest (though i'll be grateful for more testing, regardless of platform)
21:20:17 <garyk> danwent: sure.
21:20:20 <mnewby> The annoyance is that the tests are in ruby.
21:20:24 <mnewby> (for smokestack)
21:20:30 <gongysh> I need a facility that make sure each patch will not break our dear quantum in the end.
21:21:11 <danwent> gongysh: that is what gating does.  what i've been told so far is that the CI team is moving toward gating on tempest in the long-term
21:21:28 <danwent> though in the short-term they also gate on devstack exercise scripts + smokestack (I believe)
21:22:04 <danwent> ok, got to keep moving.  nati_ueno: any blockers in terms of gating?
21:22:17 <danwent> just fixing issues with exercise.sh?
21:22:21 <nati_ueno> I think just debug exesice.sh
21:22:27 <nati_ueno> Yes
21:22:51 <nati_ueno> I'll request merge for devstack until this week
21:22:53 <danwent> do you anticipate having that done soon?  I'd say to escalate any issues you're having to the entire core team, as its critical we get this going
21:23:09 <nati_ueno> Yes soon
21:23:11 <danwent> ok, garyk and I are both core devstack devs, so we should be able to review quickly.
21:23:14 <danwent> ok, next topick
21:23:25 <danwent> related: tempest tests
21:23:36 <danwent> nati_ueno, maru  blueprints here?
21:23:39 <danwent> others?
21:23:56 <nati_ueno> related https://blueprints.launchpad.net/quantum/+spec/quantum-system-test ?
21:24:18 <nati_ueno> Maybe, we should have the blueprint in QA team project
21:24:37 <mnewby> I would agree
21:24:37 <nati_ueno> https://blueprints.launchpad.net/tempest
21:24:39 <danwent> nati_ueno: yes, i'm fine with the BP being there, just really looking to make sure someone is working on it.
21:24:53 <nati_ueno> OK I'll create one
21:25:20 <danwent> ok, please send it out to the team so we can track.  there was also someone from rackspace who said he would have developers for this.
21:25:31 <danwent> anyone remember the name?  I'll have to look it up.
21:25:37 <mnewby> daryl
21:25:38 <danwent> he was at the meeting, sitting behind me.
21:25:43 <nati_ueno> danwent: gotcha
21:26:00 <danwent> mnewby: thx.  anyone know daryl's email or irc?
21:26:12 <danwent> was he on that old thread we had going?
21:26:16 <mnewby> Daryl Walleck <daryl.walleck@rackspace.com>
21:26:22 <danwent> thx
21:27:11 <danwent> Ok, let's loop him into the discussion
21:27:36 <danwent> mnewby: do you expect to create a BP, or just work with daryl + nachi?
21:27:54 <mnewby> danwent: I haven't really worked with BPs, what is requied?
21:28:29 <nati_ueno> Done https://blueprints.launchpad.net/tempest/+spec/quantum-tempest
21:28:34 <danwent> BPs are just a feature/bug-tracking tools where you describe a new capability you will be adding to the system.
21:29:17 <danwent> as we mentioned above, for features, they should include use cases, design, and doc for configuring + using the feature.  Might be slightly different for test cases though.
21:29:44 <mnewby> Ok
21:30:09 <danwent> I think during the summit we agreed that this work would be discussed during the weekly temptest meetings, but it would be good if someone reported back progress to the quantum meeting
21:30:28 <danwent> as having good system test is critical to the success of quantum long-term, especially as it grows in complexity.
21:30:44 <nati_ueno> OK I'll attend both of meeting and report it
21:30:45 <danwent> ok, got to keep moving
21:30:48 <danwent> nati_ueno: thx
21:30:58 <danwent> database upgrade: markmcclain , salv-orlando
21:31:16 <markmcclain> I can help with it
21:31:16 <danwent> had a work item from summit that markmcclain was proposing a mechanism other than sqlalchemy-migrate
21:31:22 <salv-orlando> I haven't done anything beyond looking at how we can use alembic
21:31:33 <salv-orlando> for solving issue with plugin-specific upgrade paths
21:31:39 <danwent> let's get a BP together on this that describe the trade-offs and a design
21:31:55 <danwent> we need to get this infrastructure in before we start significantly changing the DB
21:32:04 <markmcclain> +1
21:32:09 <salv-orlando> np. markmcclain - I'll send you an email for stealing some of your time on IRC
21:32:28 <garyk> danwent: salv-orlando: i was thinking that we have the user first upgrade to folsom and then convert to quantum. is this relevant
21:32:31 <danwent> ok, can one of you create a BP and assign to G-1 with essential priority?
21:32:45 <salv-orlando> danwent: sure
21:32:58 <danwent> garyk: you're talking about converting from nova-network to quantum?
21:32:59 <salv-orlando> garyk: we are looking at Quantum to Quantum upgrades at the moment
21:33:06 <danwent> that's slightly different, but also useful
21:33:13 <garyk> danwent: yes. salv-orlando: ok
21:33:15 <salv-orlando> perhaps we can have a separate blueprints from nova-network to Quantum migration
21:33:21 <danwent> i had it on the agenda for today, but then took it off thinking we shouldn't have time.
21:33:35 <danwent> but if you want to create a nova-network conversion blueprint, i think that makes sense.
21:34:13 <danwent> garyk: can you make a bp for this?  either way, its good to track it.
21:34:19 <danwent> nova gaps
21:34:21 <garyk> danwent: sure
21:34:25 <danwent> three sub-topics
21:34:34 <danwent> security groups (arosen / nachi)
21:34:55 <danwent> security groups api is already in review, as it was a miss from folsom.
21:35:06 <gongysh> we have much talk for security groups in design summit session.
21:35:10 <danwent> arosen, i haven't seen the blueprint, but probably a good idea to freshen it up, given the above conversation
21:35:17 <gongysh> we should have a   wrap up.
21:35:23 <arosen> danwent:  will do
21:35:33 <danwent> gongysh: let's have the discussion around the blueprint
21:35:56 <gongysh> yes. pointint to the etherpad
21:35:59 <danwent> aaron, i'm guessing the blueprint needs to be expanded to our new grizzly standards.
21:36:19 <amotoki> I think https://blueprints.launchpad.net/quantum/+spec/quantum-security-groups is related to this.
21:36:25 <garyk> with gongysh reviewing
21:36:37 <danwent> note: there is a ton of stuf we could do around firewalling and filtering.
21:36:38 <gongysh> garyk: haha. bad guy.
21:37:15 <danwent> but the most critical thing we HAVE to accomplish in grizzly is getting security groups in quantum with support for overlapping IPs.
21:37:27 <danwent> that was a black-eye for quantum in folsom.
21:37:33 <ijw1> And for multiple interfaces in some sensible fashion.
21:37:46 <danwent> ijw1: agreed.  that's already tackled in aaron's proposal as well.
21:37:59 <danwent> ok, multi-host
21:38:04 <amotoki> It is a good idea to merge arosen's security group API first before moving the next.
21:38:13 <ijw1> Where's Aaron's proposal?
21:38:19 <danwent> amotoki: merge with what?
21:38:36 <amotoki> danwent: the current patch under review from arosen
21:38:41 <danwent> ijw1: this was actually covered at the folsom summit for folsom, he can point to the preso
21:38:58 <danwent> arosen: does BP link to dave's presentation?
21:39:04 <arosen> ijw1:  I'll put up the openstack-manual documentation i'm working on that should help shed some light as well.
21:39:11 <arosen> danwent:  yes it does.
21:39:12 <danwent> amotoki: ah, i agree.
21:39:37 <danwent> I'd like to make sure the base security groups stuff is in very early, which is why arosen and nati_ueno are working on it already.
21:39:44 <arosen> This is the review:  https://review.openstack.org/#/c/14262/
21:39:51 <danwent> ok, only 20 mins left and much to cover :(
21:39:57 <danwent> quickly, multi-host
21:40:01 <nati_ueno> I didn't started yet. Just play with firewall.py
21:40:06 <danwent> what is active blueprint for this, and who owns it?
21:40:11 <nati_ueno> I updated bp for multi-host https://blueprints.launchpad.net/quantum/+spec/quantum-multihost-dhcp
21:40:18 <danwent> nati_ueno: this is just for dhcp?
21:40:25 <gongysh> https://blueprints.launchpad.net/quantum/+spec/quantum-multihost-dhcp
21:40:31 <nati_ueno> No not just dhcp
21:40:34 <nati_ueno> I should update it
21:40:38 <danwent> nati_ueno: i'm also a bit worried that you seem to be volunteering for all of the blueprints
21:40:39 <ijw1> What of the routing aspects of multihost?
21:40:48 <ijw1> Oh, sorry, bit late with that ;)
21:41:00 <danwent> nati_ueno: can you update BP name to avoid confusion?
21:41:05 <nati_ueno> danwent: I got it
21:41:14 <danwent> gongysh: are you contributing to multi_host stuff as well?
21:41:16 <gongysh> nati_ueno: don't u want me to do it?
21:41:30 <nati_ueno> danwent: It seem I can't update bp id
21:41:40 <danwent> ah, launchpad...
21:41:42 <nati_ueno> gongysh: Ether way is OK :)
21:42:10 <nati_ueno> gongysh: Do you want to do this one?
21:42:15 <danwent> nati_ueno: since you have so much on your plate, having gongysh head it up makes sense to me.
21:42:29 <nati_ueno> danwent: I got it
21:42:35 <gongysh> nati_ueno: I hope I can help u to do it.
21:42:38 <danwent> nati_ueno: title of blueprint is good…, mentions both dhcp and L2
21:42:43 <danwent> L3
21:43:01 <nati_ueno> I updated whiteboard today
21:43:04 <danwent> i updated the link: https://blueprints.launchpad.net/quantum/+spec/quantum-multihost
21:43:17 <danwent> ok, keep moving
21:43:26 <nati_ueno> Ohh It can be updated!
21:43:38 <danwent> nova gaps, metadata. markmcclain, you or carlp handling this?
21:43:48 <markmcclain> I'm working on metadata
21:43:57 <markmcclain> I hoped to have code today… looks like tomorrow
21:44:08 <danwent> great, this will be a huge help
21:44:19 <danwent> we already have a bp targeted for G-1 for that
21:44:47 <danwent> garyk: planning on creating a blueprint on the nova/quantum flow and vif-plugging stuff?
21:44:59 <garyk> danwent: yes, i'll do it tomorrow
21:45:19 <danwent> garyk: cool.  for the LB plugin in particular, I see that as essential.
21:45:30 <garyk> danwent: agreed
21:45:31 <ijw1> garyk: drop me a mail when you've done it, ta
21:45:41 <garyk> ijw1: will do
21:45:54 <garyk> ijw1: as long as you do not heckle
21:45:57 <ijw1> aww
21:46:01 <danwent> salv-orlando: are you creating blueprints around the API infrastructure for higher-level services like LBaaS?
21:46:15 <salv-orlando> danwent: yep
21:46:45 <danwent> I think rkukura is likely interested in helping with API extension framework stuff as well.
21:46:47 <gongysh> does the separate LBaas will use our API infra?
21:47:05 <markmcclain> I think it should
21:47:16 <danwent> gongysh: higher level services will be able to be loaded and run indepdent of the main plugin, and that's something we don't really support now
21:47:34 <danwent> roman (spelling?) from mirantis had a good slide that discussed this at the summit
21:47:46 <ijw1> I think a LBaaS will plug into quantum as a client; I don't necessarily know that it's a part of the same API endpoint.
21:48:16 <gongysh> then what do we mean by API infrastructure for higher-level services like LBaaS?
21:48:22 <danwent> ijw1: current plan is same endpoint, though I'm not sure the discussion is final.
21:48:30 <salv-orlando> I think we talked about this a bit :)
21:48:47 <danwent> gongysh: perhaps best to take a look at salv-orlando's blueprint, and at the sessions he and sasha presented
21:48:59 <salv-orlando> salv-orlando: I will start an email discussion offline once the blueprint is filed
21:49:08 <gongysh> ok. I will talk to salv offline.
21:49:10 <danwent> anyway, we have 12 mins left in the meeting, so let's leave those details for offline discussion
21:49:12 <danwent> thx
21:49:26 <danwent> client-lib + cli enhancements
21:49:34 <danwent> i assume gongysh and markmcclain will be coordinating here
21:49:39 <markmcclain> yep
21:49:43 <gongysh> sure.
21:49:49 <danwent> note, these should actually be created as blueprints in the python-quantumclient project
21:49:57 <markmcclain> will do
21:50:01 <danwent> but we will discuss them in this meeting
21:50:18 <danwent> horizon next steps.  amotoki, nati_ueno ?  filing these under horizon?
21:50:30 <amotoki> BP is not filed yet.
21:50:32 <danwent> but please send a note to the quantum team or post the BPs next meeting so peopel are aware of them.
21:50:42 <nati_ueno> I got it
21:50:44 <amotoki> danwent: sure.
21:50:56 <danwent> IPv6 stuff.  markmcclain, you will file?
21:51:00 <markmcclain> yes
21:51:07 <amotoki> nati_ueno: I will send you a mail later.
21:51:13 <markmcclain> and have a few folks who'd said that help with code
21:51:15 <nati_ueno> amotoki: gotcha
21:51:19 <danwent> Ok.  rkukura where you planning on doing a BP for your modular plugin stuff in G-1?
21:51:26 <rkukura> yes
21:51:36 <danwent> Ok, please create and target.
21:51:38 <rkukura> first steps
21:52:12 <danwent> I know there are other items that people want to do in G-1, and that's fine, I just wanted to cover key community wide topics here.  Are there other items that we think should be priority high or above for G-1?
21:52:32 <danwent> (note: i'm leaving the LBaaS stuff out for now, as they are doing a separeate meeting)
21:52:37 <nati_ueno> VPN stuff is not G1?
21:52:45 <nati_ueno> and Service enhancement
21:53:01 <markmcclain> VPN is a blueprint I'm going to write
21:53:31 <danwent> nati_ueno: I figure we had a lot on our plate for G-1.  If mark things we can tackle in in G-1 as well, that's great
21:53:44 <amotoki> regarind firewalling, i plan to write a document during G-1.
21:53:48 <danwent> but I was thinking other services would probably wait until G-2 before they were a major community focus.
21:53:59 <nati_ueno> danwent:  I got it
21:54:50 <danwent> #info: as a heads up for those interested in LBaaS.  they have a separeate weekly meeting on thursday mornings now, see: http://wiki.openstack.org/Quantum/LBaaS
21:54:56 <salv-orlando> danwent: my plea is for getting service insertion complete in G-1 before moving to the other services
21:54:57 <sasha_> I will also write a blueprint for L3/services so that it is there for comments ... and also talk offline to Salvatore
21:55:09 <danwent> salv-orlando: that's a good point.
21:55:36 <markmcclain> +1 to get service insertion in early
21:55:45 <garyk> +1
21:55:51 <danwent> amotoki: feel free to put together a BP, but I want to make sure we have main service insertion stuff somewhat settled before we actually start coding on all types of higher-level services.
21:56:09 <danwent> salv-orlando: ok, let's jack up the priority of that BP for G-1
21:56:15 <danwent> and make sure we really focus effort there.
21:56:20 <amotoki> danwent: I feel so too.
21:56:26 <danwent> ok, 4 minutes :(
21:56:40 <garyk> danwent: lets talk about bugs next week
21:56:52 <danwent> ok, sounds like we'll need to leave the discussion of sub-teams to tomorrow, but I just wanted to send out this link with some of my thoughts: https://etherpad.openstack.org/grizzly-quantum-wrapup
21:57:06 <danwent> garyk: agreed, let's just highlight the list
21:57:14 <garyk> ok
21:57:21 <nati_ueno> Where can I know sub-teams?
21:57:24 <danwent> #info here is list of current bugs tagged for possible folsom-backport: https://bugs.launchpad.net/quantum/+bugs?field.tag=folsom-backport-potential
21:57:43 <danwent> nati_ueno: all info i've put together so far is on that etherpad link.  feel free to comment there and we'll talk about it next week.
21:57:51 <danwent> garyk is our master of folsom stable
21:57:53 <garyk> danwent: there is no beer team!
21:57:54 <nati_ueno> danwent: I got it
21:58:02 <nati_ueno> lol
21:58:09 <salv-orlando> danwent: more than happy to start rolling on service insertion (and there goes my sleep)
21:58:14 <danwent> please help him out by making sure all bugs relevant to folsom are tagged with folsom-backport-potential
21:58:43 <danwent> we should also start thinking about a date for a folsom-stable release update
21:59:00 <danwent> let's nail that down next week, along with a list of bugs we think must be fixed in that release.
21:59:06 <danwent> garyk: sound reasonable?  anything to add?
21:59:24 <garyk> danwent: not at the moment. tomorrow i'll go over the bugs etc.
21:59:29 <danwent> garyk: awesome
21:59:33 <danwent> #topic open discussion
22:00:05 <danwent> I will send an email to the list with my thoughts on how to handle possible influx of plugins + drivers from vendors in grizzly
22:00:09 <gongysh> danwent, nati: can u agree to assign multi-host to me?
22:00:27 <danwent> so far we have had a policy that any plugin must has a core dev who offers to stand behind it
22:00:36 <danwent> gongysh: yes, I will
22:00:39 <nati_ueno> gongysh: I agree
22:00:43 <nati_ueno> gongysh: Thanks!
22:00:52 <gongysh> U are welcome
22:00:59 <danwent> ok, anything else we need to discuss here before we sign off?
22:01:00 <gongysh> good nati_ueno.
22:01:11 <gongysh> pagination?
22:01:27 <gongysh> I hope pagination can get in for G1
22:01:35 <danwent> salv-orlando: can you chat with gongysh about pagination after the meeting?  I know you had thoughts on nit.
22:01:37 <danwent> it
22:01:51 <danwent> ok, hope you all had a fun summit, now its back to work :)
22:01:52 <salv-orlando> danwent, gongysh: sure
22:01:55 <danwent> #endmeeting