15:01:21 <kgriffs> #startmeeting marconi
15:01:22 <openstack> Meeting started Tue Apr  1 15:01:21 2014 UTC and is due to finish in 60 minutes.  The chair is kgriffs. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:25 <openstack> The meeting name has been set to 'marconi'
15:01:27 <flaper87> o/
15:01:28 <kgriffs> #topic roll call
15:01:29 <flaper87> o/
15:01:31 <flaper87> o/
15:01:34 <kgriffs> o/
15:01:35 <malini> \o/
15:01:36 * flaper87 is here \o/
15:01:37 <sriram> o/ \o
15:01:37 <dmitryme> o/
15:01:43 <alcabrera> -o-
15:01:43 <flaper87> dmitryme: hey :)
15:01:57 <flwang> o/
15:01:59 <dmitryme> flaper87, folks, hello!
15:02:06 <alcabrera> dmitryme: hey, welcome. :)
15:02:08 <malini> hello dmitryme
15:02:39 <kgriffs> anybody else in teh house for Marconi?
15:02:43 <cpallares> o/
15:02:48 <balajiiyer> o/
15:03:08 <kgriffs> let's do this
15:03:12 <kgriffs> #link https://wiki.openstack.org/wiki/Meetings/Marconi#Agenda
15:03:16 <flaper87> kgriffs: what? The meeting? now?
15:03:19 * flaper87 STFU
15:03:21 <kgriffs> #topic FAQ meetup
15:03:22 <alcabrera> lol
15:03:48 <flaper87> #link https://etherpad.openstack.org/p/draft-marconi-faq
15:04:16 <flaper87> So, very quick, the idea would be to organize a hangout sometime this week (or next week) to go through the FAQ
15:04:27 <flaper87> there's a lot of content there to be discussed
15:04:41 <flaper87> the goal of that hangout is to come up with a fairly decent FAQ
15:04:48 <flaper87> that could be put on our wiki
15:05:00 <flaper87> I'm kinda tempted to put the FAQ somewhere in the code base too
15:05:06 <flaper87> but lets not talk about that now
15:05:26 <flaper87> So, lot has been written in that FAQ, I'll schedule the hangout and invite you all
15:05:35 <flaper87> we'll stream it and invite folks to join
15:05:49 <flaper87> and that's it. I don't have anything else to say
15:06:06 <kgriffs> when would be a good time to for the hangout?
15:06:33 <flaper87> I guess this same time ?
15:06:37 <flaper87> I mean, 15 UTC
15:07:00 <kgriffs> is anyone going to be offline this week or next?
15:07:10 <alcabrera> 15 UTC seems to work for myself, kgriffs, malini, and flaper87. How about you, flwang?
15:07:20 * alcabrera is timezoning
15:07:30 <kgriffs> I will be at PyCon starting next thur
15:07:41 <flaper87> kgriffs: ahhhh, lucky you
15:07:45 <malini> 15 UTC works for me
15:07:45 <flwang> alcabrera: what's current meeting time?
15:07:47 <alcabrera> enjoy, kgriffs. :)
15:07:53 <flaper87> flwang: 15UTC
15:07:53 <alcabrera> flwang: 1500 UTC
15:07:57 <flaper87> flwang: and you're on-line
15:08:03 <flaper87> we could infer it works for you
15:08:05 <flaper87> :D
15:08:07 <flaper87> just kidding
15:08:08 <flwang> flaper87: it works for me
15:08:11 <alcabrera> sweet
15:08:11 <flaper87> I know it's late there
15:08:22 <flaper87> cool, so 15UTC it is
15:08:40 <flaper87> lets pick a day during this week, probably Thursday
15:08:44 <flaper87> how does that sound?
15:09:17 <alcabrera> lemme check
15:09:34 <alcabrera> works for me
15:10:17 <kgriffs> I'm generally free 1400 or 1500
15:10:27 <flaper87> kgriffs: cpallares malini flwang ?
15:10:28 <kgriffs> flaper87: can you send out a doodle poll to the ML
15:10:36 <flaper87> kgriffs: sure, will do
15:10:42 * flaper87 forgot about that
15:10:43 <flaper87> :P
15:10:49 <flaper87> ok, nothing else from me
15:10:57 <flaper87> we can jump into the next topic
15:11:00 <alcabrera> +1 for doodle
15:11:05 <cpallares> +2 for doodle
15:11:14 <kgriffs> #action flaper87 to schedule and moderate FAQ hangout
15:11:15 <alcabrera> #action flaper87 to send out doodle poll to ML for FAQ meetup
15:11:28 <alcabrera> double the action for flaper87
15:11:30 * kgriffs wonders if he's bugged
15:11:44 <flaper87> not fair, not fair
15:11:46 <flaper87> :(
15:11:47 * alcabrera knows kgriffs is bugged -- bwahaha
15:11:53 * kgriffs wonders who alcabrera *really* works for
15:11:58 <kgriffs> ok, moving on
15:11:59 <alcabrera> :P
15:12:29 <kgriffs> #topic FYI: Third-party testing (malini)
15:12:31 <kgriffs> #link http://ci.openstack.org/third_party.html
15:12:52 <malini> So this was one was to figure out how we can get a newer mongo at the gate
15:13:11 <malini> I checked with os-infra & 3rd party testing wont be a good solution here
15:13:38 <malini> they suggest 3rd party testing, in scenarios that we need dedicated hardware to test
15:14:00 <kgriffs> why won't it be a good solution?
15:14:45 <malini> infra wants projects to be able to run with the distro version supplied s/w
15:15:04 <malini> Our option now is to wait for Trusty at the gate
15:15:25 <kgriffs> hmmm.
15:15:26 <flaper87> so, for the mongodb test we *have* to make it work in the gate
15:15:30 <flaper87> one way or another
15:15:43 <alcabrera> #info Ubuntu Trusty out April 17th
15:15:44 <malini> currently ceilometer folks do  ot run with mongo at the gate
15:15:44 <flaper87> I lost track of what the issues around that were
15:15:47 <alcabrera> #link https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule
15:15:59 <kgriffs> oh, if it is that soon, we should be OK
15:16:09 <malini> infra will have Trusty once the cloud providers have them
15:16:32 <malini> So we need RAX etc. to have trusty or infra should be able to upload a glance image
15:16:32 * flaper87 votes for waiting and parting 'til Trusty arrives to THE GATE!
15:16:51 <malini> hopefully we'll have it within the next 2 months
15:16:52 <kgriffs> flaper87: we can't use older mongo because we need TTL iirc
15:17:14 <flaper87> kgriffs: ah, that might be it
15:17:30 <alcabrera> Mongo TTLs: New in version 2.2
15:17:39 <kgriffs> #note third-party testing is really for specialized hardware, not for working around db versions
15:17:39 <malini> Trusty has Mongo 2.4
15:17:40 <alcabrera> #link http://docs.mongodb.org/manual/tutorial/expire-data/
15:18:13 <kgriffs> #note marconi requires newer version of Mongo than is currently offered in the gate.
15:18:22 <sriram> yes
15:18:31 <kgriffs> #agreed wait until Trusty lands in the gate to enable mongodb in devstack
15:18:40 <kgriffs> ok, anything else on this topic?
15:18:40 <malini> kgriffs: +1
15:18:45 <malini> thts it from me
15:19:08 <kgriffs> FWIW, that blueprint was moved out of RC1: https://launchpad.net/marconi/+milestone/icehouse-rc1
15:19:32 <kgriffs> P.S. - RC1 is ready to be cut, unless I miss it and it was already done.
15:20:06 <flaper87> kgriffs: it hasn't been done yet
15:20:12 * malini wonders why it is 'cut' & not ready for release
15:20:21 <flaper87> I'd like the cut to happen asap so we can open Juno's development
15:20:34 <flaper87> malini: because you cut the master branch :P
15:20:48 <malini> flaper87: reminds me of a barber :D
15:21:04 <flaper87> kgriffs: also, as soon as rc1 is out we should release a new client version
15:21:15 <flaper87> pls, approve: https://review.openstack.org/#/c/82820/
15:21:17 <flaper87> :D
15:21:27 <flaper87> flwang did great tests on the client side
15:21:32 <flaper87> and added a keystone example
15:22:13 <kgriffs> rock on, thanks flwang
15:22:15 <kgriffs> #note flwang rocks
15:22:24 <kgriffs> #topic Enforce alphabetical ordering in requirements file
15:22:25 * flwang is ashamed now :D
15:22:33 <kgriffs> just want to triage this real quick: #topic Enforce alphabetical
15:22:33 <alcabrera> flaper87: approved. :)
15:22:37 <flaper87> alcabrera: thanks :)
15:22:40 <kgriffs> #link https://bugs.launchpad.net/glance/+bug/1285478
15:23:01 * flaper87 thought we were already doing that
15:23:19 <flaper87> +1 from me
15:23:41 <kgriffs> we probably are, but just not enforcing it with requirements_style_check.sh
15:24:04 <alcabrera> works for me
15:24:23 * flaper87 tried hard to keep that `tools` dir out of Marconi
15:24:26 <kgriffs> ok, I'll set it to low priority
15:24:29 * flaper87 failed
15:24:57 <kgriffs> flaper87: I'll forgive you just as long as you rewrite all those bash scripts in Python. ;)
15:25:01 <alcabrera> tools/nothing_to_see_here.asm
15:25:13 <flaper87> kgriffs: LOL
15:25:43 <kgriffs> #topic Oslo plans for Juno
15:25:46 <kgriffs> #link https://wiki.openstack.org/wiki/Oslo/JunoGraduationPlans
15:26:11 <kgriffs> so, this is an FYI and call for volunteer
15:27:08 <kgriffs> first off all, kudos to dhellmann and his crew for getting a bunch of Oslo projects prepped for graduation
15:27:20 <kgriffs> I encourage everyone to take a few minutes to review that wiki page
15:27:48 <kgriffs> second, I need a volunteer for "Project Liason" (https://wiki.openstack.org/wiki/Oslo/JunoGraduationPlans#Project_Liaisons)
15:27:52 <alcabrera> sweet, oslo.log
15:28:21 * flaper87 reviewed that wiki before it came out :P
15:30:03 <kgriffs> brb
15:30:11 <kgriffs> one minute
15:31:49 <kgriffs> ok, got my connection back
15:32:23 <alcabrera> w00t
15:32:25 <kgriffs> so, flaper87 you've basically been the liason for, like, ever
15:32:32 <flwang> kgriffs: as for the liason, I would say flaper87 is the best candidate :)
15:32:48 <flwang> flaper87: core for olso and marconi, both
15:33:02 <kgriffs> flaper87: are you cool with continuing in that role?
15:33:12 <flaper87> kgriffs: yup, absolutely
15:33:14 <flaper87> :)
15:33:15 <kgriffs> kewl
15:33:32 <kgriffs> #note flaper87 is now Marconi's official oslo Liason/Champion
15:34:09 <kgriffs> #topic graduation review followup
15:34:11 <alcabrera> thanks, flaper87. :)
15:34:30 <kgriffs> So, has everyone signed up at ask.openstack.org and put a watch on the "marconi" tag?
15:34:50 <flaper87> kgriffs: you know my answer already, right?
15:34:53 <sriram> yes.
15:34:53 <malini> I did
15:34:59 <alcabrera> I think I did. >.>
15:35:11 <alcabrera> yes
15:35:14 <cpallares> I didn't even know we had and ask.openstack.org :O
15:35:14 <flwang> me too
15:35:26 <kgriffs> cpallares: now you do. :D
15:35:39 <cpallares> kgriffs: :D
15:35:46 * cpallares signs up
15:35:57 <kgriffs> #topic Check trademarks for project
15:36:03 <kgriffs> megan_w: ^^^
15:36:26 <megan_w> still pending legal review
15:37:05 <kgriffs> so, just to fill everyone in, megan_w has been talking to OS Marketing to see if we have any issues with "Marconi" or whatever
15:37:11 <vkmc> o/
15:37:29 <kgriffs> vkmc: hi!
15:37:40 <alcabrera> vkmc: heya. :)
15:37:44 * vkmc catching up
15:37:45 <vkmc> :)
15:37:51 <kgriffs> #topic ATL summit
15:38:14 <kgriffs> Please get your design session proposals in by end of day (EOD) thursday
15:38:32 <kgriffs> I would like to start reviewing them on Friday and discuss at the next mtg if that is cool with everyone.
15:39:21 <flaper87> that sounds good
15:40:00 <kgriffs> anybody have any general summit thoughts/questions?
15:40:17 <malini> not from me
15:40:21 <alcabrera> nothing comes to mind at the moment from me
15:40:32 <flaper87> We need to focus on planning what's comming next
15:40:53 <flaper87> I mean, what we want to have as a graduation ground and what we're going to do community-wise
15:41:02 * flaper87 didn't mean to state the obvious
15:41:38 <kgriffs> +1
15:42:27 <kgriffs> FWIW, before the summit I'd like to overhaul the Marconi wiki and have everyone aligned on our goals for the summit and our messaging to the community
15:43:20 <kgriffs> So, in a couple weeks let's start working on that and go to the summit ready to rock
15:43:35 <alcabrera> +1 for wiki overhaul
15:43:39 <alcabrera> it's been some time
15:43:40 * flaper87 will bring his guitar
15:43:44 <alcabrera> the refactoring will be lovely
15:43:46 <alcabrera> :)
15:44:30 <kgriffs> #topic Proposal: use Marconi for Guest Agent (dmitryme)
15:44:39 <kgriffs> #link https://wiki.openstack.org/wiki/UnifiedGuestAgent
15:45:15 <dmitryme> kgriffs: thank you for introduction
15:45:36 <flwang> kgriffs: interesting idea
15:46:00 <dmitryme> so, basically if you are not familiar with the agent, the idea is to allow OpenStack services execute commands 'inside' VMs
15:46:25 <dmitryme> for that we need an agent running inside the VM and executing the commands
15:46:39 <dmitryme> the question is how to negotiate with it
15:47:05 <dmitryme> long story short, we decided that Marconi seems to be the best fit for it
15:47:37 <dmitryme> mainly because it provides multi-tenancy
15:47:58 <dmitryme> I'd like to hear from you folks if you have any concerns with that
15:48:20 <dmitryme> from my understanding, such agent seems to a regular consumer app for Marconi
15:48:55 <dmitryme> the only special requirement is Marconi API availability not only from VMs, but from OpenStack Controller nodes as well
15:49:02 <alcabrera> hmmm
15:49:05 <dmitryme> but that does not sound like a big deal
15:49:12 <flaper87> dmitryme: that sound feasible
15:49:29 <flaper87> dmitryme: Do the agents have special routing needs?
15:49:41 <flaper87> dmitryme: what about pub-sub requirements ?
15:49:47 <flwang> dmitryme: can the agent be used to collect guest os metrics?
15:49:50 <dmitryme> flaper87: agent only needs connection to Marconi API
15:50:26 <dmitryme> flaper87: it is my thinking that agent has no special pub-sub requirements
15:50:58 <dmitryme> the only thing I am thinking right now is that Marconi should be ready for high performance
15:51:43 <malini> dmitryme: do you have any specific perf requirements- rps /response time etc ?
15:51:46 <dmitryme> in case we bring up a cluster consisting of hundreds of VMs, all of them will start polling the API at the same time
15:52:12 <alcabrera> dmitryme: how often will they poll? Once per second? etc.?
15:52:31 <dmitryme> flwang: I think collecting metrics for Ceilometer could be viwed as one of use cases
15:52:50 <flwang> dmitryme: nice
15:52:54 <dmitryme> regarding response time, naturally we would like to have it as small as possible
15:53:20 <dmitryme> say, poll once in 0.1 or 0.2 seconds
15:53:27 <alcabrera> hmmm
15:53:35 <kgriffs> dmitryme: you may not need to poll that often
15:53:39 <dmitryme> one of the other options I see is to use long polling
15:53:44 <alcabrera> that amounts to roughly 1500 - 3000 rps
15:54:05 <kgriffs> dmitryme: I mean, sometimes you may, but you might consider defining some polling "modes"
15:54:25 <kgriffs> like, ['idle', 'active', 'fast']
15:54:50 <kgriffs> for example, an agent can be 'idle'
15:54:53 <dmitryme> kgriffs: yep, we can do it, but the thing is the load will be bursty anyway
15:55:05 <kgriffs> then when it gets a "wakeup" or other message, you could throttle up for X period of time
15:55:07 <dmitryme> because most communication will be done at provisioning time
15:55:42 <kgriffs> dmitryme: then you would default to "fast" and then throttle down after provisioning to 'idle' - something like that
15:56:00 <kgriffs> dmitryme: anyway, just a thought for making more efficient use of your Marconi cluster
15:56:16 <kgriffs> flaper87: may be a good feature to have in the client
15:56:29 <dmitryme> kgriffs: did you guys think about implementing consuming API with long polling?
15:56:31 * flaper87 got distracted, back!
15:56:40 <dmitryme> that might solve the problem
15:56:44 <kgriffs> dmitryme: yep, we've discussed it. No firm plans atm.
15:57:02 <dmitryme> the thing is, I think the agent is not the only app which would prefer low latency
15:57:53 <kgriffs> dmitryme: low latency is great, but practically speaking, "pretty" low latency is usually good enough
15:58:08 <kgriffs> (in my experience, just speaking anectodaly)
15:58:24 <kgriffs> dmitryme: don't get me wrong, we very much care about performance when it comes to Marconi!
15:58:47 * flaper87 is really exited by this use case
15:59:33 <dmitryme> kgriffs: right, I think we'll need to do performance testing to estimate how frequently we can poll
15:59:45 <kgriffs> I'm just making a point that once you get to low-ms range per transaction, that is sufficient for a most use cases
16:00:39 <kgriffs> dmitryme: yep, that would be good to quantify what you need. Also, FWIW, malini has been talking to the Rally folks so we can start getting some regular benchmarking setup
16:01:33 <kgriffs> oh, and by "low-ms" range, I mean < 40 ms turnaround, or < 20 ideally
16:02:01 <dmitryme> kgriffs: I think I would be absolutely happy with < 100 ms
16:02:13 <kgriffs> dmitryme: p.s. - if you enable HTTP keepalive on your load balancer, that helps reduce latency. Not sure if that is enabled in the client library?
16:02:24 <dmitryme> users are not that fast, or maybe its just me ;-)
16:02:32 <kgriffs> heh
16:02:48 <adrian_otto> all done?
16:02:53 <kgriffs> dmitryme: I think 100-200 ms is perceived as "instant" by humans
16:03:12 <kgriffs> adrian_otto: just about - 1 min
16:03:14 <kgriffs> anyway
16:03:25 <kgriffs> I think everyone is cool with this idea?
16:03:30 <kgriffs> s/idea/proposal
16:03:39 <dmitryme> kgriffs: yep, the only exception is if you playing Counter-Strike. Sorry for the flame :-)
16:03:46 <kgriffs> dmitryme: LOL
16:04:19 <kgriffs> #agreed Guest Agent is a good use case for Marconi
16:04:54 <kgriffs> dmitryme: cool, let's keep in touch on this and feel free to suggest ideas that will make Marconi easier for you to use
16:05:01 <kgriffs> #endmeeting