22:03:14 <danwent> #startmeeting
22:03:15 <openstack> Meeting started Tue Apr 24 22:03:14 2012 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:03:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
22:03:40 <danwent> or maybe I should first check if anyone is here.  I know several key people said they couldn't make it.
22:03:56 <salv-orlando> well, I'm here :)
22:04:02 <rkukura> I'm here
22:04:06 <GheRivero> here
22:04:13 <danwent> great :)
22:04:14 <med_> I'm not here.  :^)
22:04:18 <danwent> boo
22:04:39 <danwent> ok, let's get started.
22:04:52 <danwent> We're going to target more of a quick scrum, since quantum is now discussed at the main meeting.
22:05:23 <danwent> I've been mapping out all of the items we discussed at the summit, dependencies, etc.  I will be harassing people to create blueprints this week.
22:06:04 <danwent> For the key topics we need to achieve Nova parity, I'd like to make sure we have a bp by next week, with at least an outline.
22:06:15 <danwent> jkoelker: are you here?
22:06:54 <danwent> #action get jkoelker to put together bp for melange integration
22:07:08 <danwent> carlp: around?  bp on dhcp?
22:07:41 <danwent> Ok, sounds like this is a losing strategy :)
22:07:58 <salv-orlando> maybe they are writing the bps...
22:08:04 <danwent> haha :)
22:08:15 <cdub> ah, just no topic change...
22:08:20 <danwent> Ok, anyone who's actually here need to talk about BPs?
22:08:29 <danwent> otherwise, we can call it a meeting.  Don't want to wait people's time.
22:08:34 <med_> #info annegentle is closing Essex docs in a week
22:08:50 <danwent> i'll do a better job of making sure the right people actually show up next week.
22:08:52 <rkukura> Are we going to keep meeting weekly? At the same time?
22:09:28 <danwent> med_:  good to know.  med_  and rkukura  are both working to see how we can better document ubuntu + fedora setup in the Quantum admin guide.
22:09:33 <mnewby> I have a question regarding agents
22:09:48 <danwent> rkukura: plan was to use it as a scrum.  but if the right people don't show up, perhaps we shouldn't bother :)
22:09:57 <danwent> mnewby:  go ahead
22:10:23 <mnewby> In reviewing the agent code I noticed that at least the linuxbridge and ovs plugins need direct access to the quantum db
22:10:42 <mnewby> Is this going to remain for folsom?  I can see the potential for major problems with this design.
22:10:47 <danwent> yes, same model as nova-compute, I believe
22:10:52 <mnewby> yikes
22:10:53 <mnewby> Ok.
22:11:23 <rkukura> Are you more concerned with the plugins or their agents?
22:11:29 <mnewby> The agents.
22:11:33 <mnewby> I'm going to research possible alternatives with an eye towards using a more distributed approach.
22:11:46 <rkukura> I'm signed up to look at using amqp.
22:11:48 <mnewby> I'll discuss on the ml and capture my ideas in a bp.
22:11:50 <danwent> other model I guess is to pass everything via RPC, I guess that would save on DB conections.
22:12:11 <danwent> or shifting to a more distributed data store
22:12:19 <mnewby> The issue with rpc is whether we use persistent queues or acknowledgement.
22:12:35 <mnewby> But we can discuss going foward.
22:12:48 <danwent> right now I'm much more worried about getting something functional, and for functional, the "centralized db" model works pretty well.
22:13:03 <mnewby> I'm not going to get in the way of that, but 'functional' isn't 'scalable'.
22:13:37 <danwent> the good news is that the plugin model can handle this pretty well
22:13:59 <danwent> I'd focus on a plugin that we're targeting to be the "super-stable, nova-parity" option for Folsom.
22:14:18 <danwent> if we get that locked up quickly, we can easily start working on another plugin that uses more exotic datastores
22:14:22 <danwent> and will scale better.
22:14:23 <cdub> mnewby: did you have a specific issue w/ something like amqp?
22:14:24 <salv-orlando> mnewby: what you're proposing falls in the category of "give some love to the open source plugins".
22:14:26 <mnewby> Agreed.  And better plugin->agent communication model is developed won't hinder other efforts.
22:14:53 <mnewby> cdub: amqp is certainly an option, but nova has had scalability issues with the rabbitmq implementation.
22:15:03 <mnewby> zeromq may be a better fit.
22:15:10 <mnewby> Or just using a better centralized store.
22:15:11 <salv-orlando> I'd love that, but agree with Dan that we want to have a basic thing working and super-stable. Is a fork from ovsplugin something that can be considere?
22:15:18 <danwent> I think we can pretty easily get rid of the polling in existing plugins using an RPC for notifications
22:15:36 <cdub> yes, i'd expect so
22:15:50 <med_> I thought that the rabbitmq scalability issue was somewhat debunked at ODS-F (but not really a Quantum issue)
22:15:51 <mnewby> salv-orlando: I'm not suggesting replacement from what, at present, works.
22:16:01 <mnewby> Just that I'd like to consider alternative.
22:16:02 <mnewby> s
22:16:05 <danwent> salv-orlando: I think if we're good about designing plugin code as libraries, it should be easy to have a stable one, then a more aggressive one that shares much of the same code.
22:16:10 <salv-orlando> mnewby: agreed
22:16:23 <salv-orlando> danwent: agree with you too :)
22:16:36 <rkukura> Why keep the non-scalable one around if we solve the scalability issue without decreasing stability?
22:16:37 <mnewby> Anyway, just wanted to raise the issue.
22:16:48 <mnewby> rkukura: nice to have options ;)
22:16:50 <danwent> mnewby: sure.  but what really keeps me up at night is making sure we have a rock solid open source plugin, so I'm nervous about dividing our focus until we achieve that.
22:17:03 <danwent> mnewby: definitely good to raise.
22:17:14 <cdub> danwent: actually database access is part of stabliilty issue w/ current agents ;)
22:17:21 <rkukura> We have stability issues right now regarding DB connection management.
22:17:34 <cdub> danwent: so 2 birds w/ one rabbit (or qpid, or..)
22:17:38 <mnewby> Yes, that's my concern.  Stability won't last with centralized db once scaling is involved.
22:17:43 <somik> rkukura: I think the no-scalable one is 'as scalable' as nova, so we can do better, but this works and we can make it scale better after we are done with functionality
22:17:54 <danwent> rkukura: my main comment is a design that is simple to understand, build, debug…. regardless of technology
22:18:01 <mnewby> Yes, that is definitely the goal.
22:18:05 <rkukura> agreed
22:18:07 <danwent> my experience with nova is that adding a bunch of RPC calls does not help :)
22:18:23 <mnewby> Simple/maintainable is usually easier to scale, too.
22:18:30 <mnewby> danwent: at least not using rabbitmq
22:18:42 <mnewby> Time to do some reading on distributed systems ;-)
22:18:51 <mnewby> Anyway, in the same vein, I'm going to file a bug on testing the agents.
22:19:03 <danwent> Ok, so I think we're clear on goals.  I don't particularly care about the technology, so much as making sure we get something stable and working quickly.
22:19:23 <danwent> mnewby: great.  good testing infrastructure will help in both cases.
22:19:43 <danwent> ok, where were we? :)
22:19:53 <mnewby> One more thing: reviewing
22:20:03 <danwent> mnewby: that was my next topic :)
22:20:07 <mnewby> Nice :)
22:20:20 <danwent> mnewby is doing a kick-ass job fixing bug and improving the code base.
22:20:29 <danwent> we at the very least need to support him by reviewing code :)
22:20:31 <danwent> https://review.openstack.org/#/q/status:open+project:openstack/quantum,n,z
22:20:37 <danwent> https://review.openstack.org/#/q/status:open+project:openstack/python-quantumclient,n,z
22:20:56 <danwent> probably most urgent is patch to get rid of quantum.common, is that true mnewby ?
22:21:07 <danwent> server-side must go in first, then client side
22:21:34 <danwent> then probably good to do the HACKING patches to avoid being in rebase hell.
22:21:35 <mnewby> Yes
22:21:39 <danwent> or should HACKING be first?
22:21:56 <mnewby> quantum.common first.  Then hacking.
22:22:01 <danwent> k
22:22:05 <mnewby> They are dependent changes, in any case.
22:22:15 <danwent> I've already reviewed the quantum.common stuff…. I think we're in good shape there.
22:22:49 <danwent> also garyk has some fixes for the OVS plugin… would like to get those merged quickly.
22:22:57 <danwent> any other urgent reviews?
22:23:28 <danwent> Ok, and any other topics to discuss?
22:23:33 <rkukura> gary has some DB connection fixes as well
22:23:34 <mnewby> I've noticed a drop-off in the number of participating core reviews post-summit.  I'm hoping things will swing back to pre-summit levels sooner.
22:23:43 <danwent> rkukura: yup, just mentioned those :)
22:23:53 <rkukura> linuxbridge and openvswitch
22:24:00 <mnewby> Is there manual testing being done of those changes?
22:24:09 <mnewby> I reviewed the code and saw at least one bug.
22:24:26 <danwent> mnewby: we need better agent test coverage on both sides.
22:24:39 <cdub> mnewby: i believe gary's manually testing, yes
22:25:06 <mnewby> cdub: I'll ask him about that then.  He clearly wasn't testing the failure case or he would have had a failing linuxbridge agent.
22:25:32 <cdub> mnewby: ok, yeah, definitely note it in review
22:25:44 <danwent> there' s a lot of code from the OVS agent that has been copied to other agents as well… I think we really need to get an agent.common directory going, so we don't have similar patches against all agents when we want to change something.
22:26:12 <mnewby> I was wondering that.
22:26:24 <rkukura> What about config, logging, etc., across agents and the server?
22:26:25 <mnewby> How are the agents deployed at present?
22:26:43 <mnewby> Is all of quantum installed with them?
22:26:54 <mnewby> Ah, logging.
22:27:06 <mnewby> I'm displaying my ignorance, but do agents log to the server?
22:27:10 <danwent> mnewby: no, which is part of the issue.  we don't want all quantum dependences, so really we need to have something like a quantum-agent-common package
22:27:12 <mnewby> Or would logs have to be collected?
22:27:16 <rkukura> That's distro-specific, but fedora includes the agents in the plugin packages
22:27:20 <mnewby> danwent: understood.
22:27:20 <salv-orlando> danwent: I kind of agree with Dan that refactoring is a sort of priority
22:27:35 <salv-orlando> mnewby: no, if they do, the log is local
22:27:36 <danwent> mnewby: agents log locally (or not at all...)
22:27:41 <mnewby> danwent: It would be really good to extract the common stuff out of at least ovs and linuxbridge.
22:28:05 <danwent> #action danwent create common agent framework
22:28:10 <mnewby> danwent: So the agent has to update the db for quantum to know what's going on?
22:28:21 <rkukura> I really think the agents and server should also handle DB connections, config, and logging consistently - so its not just the agents
22:28:24 <danwent> mnewby: its actually even beyond that… even ryu borrows code from OVS significantly.
22:28:28 <mnewby> danwent: Did you want to do that, or are you just going to file a bug?
22:29:05 <danwent> rkukura: yes… sharing should happen at both the server + agent level.
22:29:07 <mnewby> rkukura: agreed.  And that stuff should be shared.
22:29:18 <danwent> mnewby: I was going to do it, but if you want to, I'm fine with that :P
22:29:21 <mnewby> (between all plugins).
22:29:32 <mnewby> danwent: It's yours if you want it.  :)
22:29:44 <danwent> mnewby: you're doing lots of stuff already.  I'll take this one
22:30:10 <rkukura> danwent: We need to pay attention to openstack-common for a lot of that
22:30:39 <mnewby> rkukura: Is there much of anything in common yet?
22:30:42 <danwent> rkukura: i've been talking with those folks.  Their next priority is wsgi stuff, which will help on the server, but doesn't really apply to plugin code.
22:30:59 <danwent> mnewby: not much yet… though some of the config stuff may be applicable.
22:31:02 <rkukura> The config stuff is there (almost) I think
22:31:46 <danwent> ok, now is a good time to do a lot fo this clean-up, so let's push forward with it.
22:32:07 <danwent> ok, any other topics to discuss?
22:32:48 <danwent> ok, great.  thanks folks.  don't forget to keep an eye on reviews!
22:32:56 <salv-orlando> bye!
22:33:00 <mnewby> bye!
22:33:06 <danwent> talk to you next week, at which point we should have a lot of the key bps together.
22:33:08 <markvoelker> 'night!
22:33:09 <cdub> cya
22:33:10 <med_> #endmeeting
22:33:12 <danwent> later!
22:33:21 <danwent> no soup for you med_ !
22:33:22 * med_ can't actually end it
22:33:24 <danwent> #endmeeting