22:02:35 <danwent> #startmeeting
22:02:36 <openstack> Meeting started Tue Jul 19 22:02:35 2011 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:02:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
22:02:50 <danwent> #topic quantum status
22:03:02 <danwent> agenda: http://wiki.openstack.org/Network/Meetings
22:03:21 <danwent> salvatore, you're up first to talk about the awesome testing work you've done :)
22:03:25 <danwent> that's ready for merge?
22:03:33 <salv> proposed yesterday
22:04:03 <danwent> k, I think you'll get two reviews from our end.
22:04:09 <salv> I think the test case for the API covers pretty much most of the code. For each operation there's one unit test for success, plus a unit test for each expected fault
22:04:17 <danwent> anyone else planning on reviewing?
22:04:24 <somik> salv: I am few comments but great exhaustive list of tests!
22:04:25 <salv> Somik claimed a review
22:04:48 <danwent> yup, and brad said he'd take a look too, i think.
22:05:06 <bhall> yep, I approved the review and have some comments written down somewhere
22:05:09 <danwent> let's get that reviewed and in, as I believe we're queuing up all other merges behind that, correct?
22:05:09 <bhall> I'll post them later today
22:05:22 <salv> danwent: right
22:05:37 <salv> do we have a taker for functional test?
22:06:17 <danwent> salv:  is there a blueprint out there for this?
22:06:24 <danwent> or is it still to be defined?
22:06:31 <salv> yep (fetching link...)
22:07:03 <salv> blueprint for functional tests: https://blueprints.launchpad.net/quantum/+spec/quantum-functional-tests
22:07:53 <danwent> salv: so by functional tests do you include testing particular plugins and their ability to pass traffic, or are you thinking more along just testing the daemon?
22:08:14 <danwent> seems like mostly still API?
22:08:31 <salv> danwent: more the second.
22:08:40 <salv> System tests will address the first issue
22:09:32 <danwent> salv: ok, will take a look at this more this week...
22:10:19 <danwent> Ok, anything else on this topic?
22:10:28 <troytoman> couple of notes on quantum
22:10:28 <salv> danwent: good. Still on test, if I'm not wrong Rick was going to look into something for Jenkins integration
22:10:49 <salv> sorry troyman, please go ahead
22:11:15 <troytoman> no worries. we should have an updated merge prop on extensions in the next couple of days to resolve some of the comments around extensions
22:11:17 <danwent> salv: yes, I think the idea was to try and have folks setup a parallel jenkins infrastructure if we couldn't use the "official" one yet.
22:11:41 <danwent> troy: thanks.  we'll be talking about extensions a bit later on the agenda.
22:11:58 <troytoman> also, i will be proposing a blueprint on notifications for quantum and melange soon as well.
22:12:19 <danwent> action: dendrobates provide update on jenkins
22:12:29 <danwent> #action: dendrobates provide update on jenkins
22:12:32 <danwent> action fail :)
22:12:43 <danwent> anything else on testing?
22:13:09 <danwent> Ok, other fairly urgent task we have is nova refactoring.
22:13:24 <danwent> Ryu and I are working to get the vif-plugging basics into D3... it will be tight :)
22:13:29 <danwent> Ryu, any other updates?
22:13:52 <ryu25> Yup, thanks to Dan's help, we should be able to have VIF plugin go in for D3
22:14:22 <danwent> ryu: from openstack meeting, it seems like this basically has to be proposed this week.
22:14:30 <ryu25> we are pretty much done with libvirt but need to finish up the remaining virt
22:14:39 <danwent> yeah... I'm working on XS today.
22:14:46 <salv> ryu25: I can help with xenapi
22:14:47 <danwent> I don't really have a setup for vmware
22:15:02 <salv> danwent: I can find somebody to help with vmware
22:15:20 <danwent> salv: that's great.  I'll do my first pass at the xapi stuff, then ask you for a review.
22:15:22 <ryu25> salv: that would be really helpful
22:15:28 <danwent> salv: please do take a great at vmware :)
22:15:38 <salv> oh now that I recall, I can find somebody for Hyper-V as well :-)
22:15:49 <danwent> salv :)
22:16:02 <danwent> great... our odds of making D3 are improving by the minute
22:16:08 <salv> on refactoring, I was wondering what's the difference between midokura's and cisco's branches for L2-refactoring. I had a look at the code, but cannot find any relevatn difference.
22:16:35 <SumitNaiksatam> salv: we haven't made changes yet
22:16:52 <SumitNaiksatam> we are working on it
22:17:01 <danwent> salv: yes, we're all working off of ryu's change set
22:17:25 <salv> ok
22:17:30 <danwent> Ok, good on nova refactoring?
22:17:31 <SumitNaiksatam> we branched off ryu's network-refactoring-l2 branch
22:17:40 <SumitNaiksatam> so its identical for now
22:17:45 <danwent> Ok, Extensions
22:17:55 <ryu25> it's lp:~midokura/nova/network-refactoring-l2  which only deals with integration of Quantum, and for now mainly VIF driver implementation
22:17:59 <ryu25> yup that's it
22:18:06 <danwent> Troy already mentioned that they are going to respond to comments on the list.
22:18:11 <SumitNaiksatam> yeah thats one
22:18:21 <danwent> Ying mentioned that she was going to be sending mail to the list as well.
22:18:35 <ying> oh, yes. I have checked in the code
22:18:46 <ying> https://code.launchpad.net/~cisco-openstack/quantum/plugin-framework
22:18:47 <danwent> I believe the goals Ying mentioned in her last email are inline with where the extension framework is going, but I'll leave it to Troy to respond in detail.
22:19:09 <somik> ying: I looked at this code a bit
22:19:29 <somik> I believe this not using the extension framework being developed by troy's team
22:19:31 <ying> danwent: yes,
22:20:00 <somik> It seems like this extension is hardcoding the cisco extension instead of using the framework
22:20:06 <somik> was that the intention?
22:20:07 <ying> somik: no, as I mentioned in my earlier email, I think our use case is different
22:20:49 <ying> we have tightly coupled API extension and plugin, since we just have 1 plugin framework
22:20:57 <danwent> ying: when I read your email, it struck me that what you were describing was what we would generally want from an extension framework.
22:21:12 <somik> ying: I think for we should have one plugin framework that handles all use cases or work on an extension within that framework.
22:21:46 <danwent> ying: i definitely think many extensions will be tightly coupled, so whatever comes out of the existing extensions framework work should handle that.
22:22:10 <danwent> danwent: sorry to overwhelm :0
22:22:30 <ying> np ;-) I'm talking with Rajaram earlier
22:22:31 <bhall> ok.. talking to himself again
22:22:37 <somik> ying: looking at the branch it seems this will be a piece of code that will be need to in the trunk for servicing cisco extensions, extensions though can be configured and need not stay in the trunk
22:23:34 <somik> maybe I am mistaken, I guess you guys will port the current extension to rajaram's extension framework then
22:23:39 <danwent> Ok, sounds like there's good discussion to be had here, and I'd like to hear what troy and team have to say as well.  Perhaps move this to netstack list?
22:23:54 <salv> danwent: good idea
22:23:58 <somik> danwent: that sounds good.
22:24:03 <ying> somik: what i'm thinking is that that extension should be with plugin, as it exposes plugin's extended functionalties
22:24:33 <danwent> ying: yup, I agree... let's keep talking about this on list.
22:24:36 <troytoman> i would need for rajaram to engage directly. so we should use the list for further discussion
22:24:37 <somik> ying: agreed
22:24:55 <danwent> great.
22:25:04 <ying> ok, we can have further discussion on the list
22:25:14 <danwent> Ok, on to the client lib + GUI
22:25:28 <danwent> asomya?
22:25:49 <danwent> can you provide a quick update?  I believe tyler has proposed this for merge and is processing feedback?
22:26:07 <asomya> Tyler's finished the client lib refactor and pushed it for a merge but he had a few collissions with Salvatore's commit i think.. he's fixing it now and expects around the 22nd to work everything out
22:26:26 <danwent> ok, great.
22:26:32 <danwent> I had a couple people asking about the GUI
22:26:44 <danwent> are there any screenshots or mock-ups that can easily be shared?
22:26:51 <asomya> I'm working on integrating quantum with the dashboard.. just starting out with a separate project 'django-quantum' that the openstack dashboard can inherit
22:27:33 <somik> asomya: if we can have some screenshots/mockups on the blue print, it owuld be a great tool to provide feedback before doing much implementation
22:27:34 <asomya> I pushed a muck up branch to junk about 2 weeks ago, based on the older dashboard .. fetching link...
22:27:39 <asomya> *mock up
22:27:47 <danwent> :)
22:28:08 <asomya> https://code.launchpad.net/~asomya/+junk/dashboard-quantum-mockup
22:28:18 <somik> asomya: are the mock ups images in some directory? I think wiki would be really great for this
22:28:36 <asomya> somik: it's a working mock up with some hard coded values.. no images :)
22:28:48 <asomya> i can take some screen shots and stick it in the wiki
22:28:59 <danwent> asomya: that would be great.
22:29:09 <danwent> just give people a sense of how it will function
22:29:23 <asomya> danwent: agreed
22:29:55 <somik> asomya: that would be helpful since everybody hasn't developed the dashboard stuff, adding the screenshots should help with the review effort.
22:30:02 <somik> asomya: thanks!
22:30:04 <danwent> Ok, and last topic is API Auth.  Thanks to salvatore for sending out a great summary email to the list.
22:30:10 <asomya> quick question
22:30:26 <danwent> whoops, go ahead asomya
22:30:41 <asomya> The dashboard folks have already ported their authentication to keystone.. are there any plans to do the same for quantum too?
22:31:02 <danwent> asomya: yup, we'll be using keystone
22:31:07 <danwent> in fact, that was the next topic :)
22:31:11 <asomya> danwent: ah ok :)
22:31:18 <danwent> salvatore is lead on that
22:31:31 <danwent> salvatore, I saw the email to the main list.
22:31:47 <salv> danwent: what do you think of Vish's idea?
22:32:35 <danwent> salv: it seems inline with what  I was originally thinking.  Ownership always boils down to actions anyway.  Really this are just very fine-grained roles (i.e., the role allowed to plug in this single vif)
22:33:00 <danwent> your toughts?
22:33:02 <danwent> thoughts?
22:33:57 <salv> danwent: agreed. My only concerns is that quantum does not own the VIF. It is owned by nova. If the authz middleware is part of quantum we need some form of interaction with nova; unless we decide to store predicates for VIFs in Quantum. But IMHO it does not sound right.
22:34:28 <salv> note: by "own" I mean that it is managed by nova :-)
22:34:36 <danwent> salv: agreed.  I think of it as nova would say what users have the right to plug a particular vif
22:34:54 <danwent> and it would be quantum that enforces that the only vifs it plugs are those that are permitted.
22:35:10 <salv> danwent: yep. Do you think that is something we can somehow do within the framework of nova-refactoring?
22:35:26 <danwent> salv: same thought that's going through my head right now :)
22:35:40 <jamesurquhart> salv: Would seem necessary, to me.
22:35:47 <danwent> salv: I think its a natural fit.
22:36:09 <danwent> salv: did we get a sense from the keystone folks if such a use case (i.e., many many roles) was "in scope" from their perspective?
22:36:10 <salv> jamesurquhart, danwent: agreed.
22:36:38 <salv> danwent: no answer yet from Ziad, Khaled and the other Keystone people. But I guess it is out of scope at the moment
22:37:23 <danwent> ok, l'll try poking them about this as well:  #action danwent contact keystone folks about vif-plugging.
22:37:36 <danwent> definitely seems like an attractive approach.
22:37:42 <danwent> ok, anything else on quantum?
22:38:07 <danwent> #topic melange
22:38:15 <danwent> troy, you still around?
22:38:32 <troytoman> yes
22:38:52 <danwent> any update on melange?  I know there's been a lot of work around nova integration.
22:39:00 <troytoman> we are writing up a proposal for creating melange and a folder inside of nova
22:39:10 <troytoman> hopefully that goes to the list late this week or early next
22:39:19 <danwent> ok, sounds good.
22:39:30 <troytoman> we have also been working with ryu on how to refactor Nova to use Melange and are making progress
22:39:41 <troytoman> should have a blueprint in the next week or two on that also
22:39:57 <danwent> great.
22:40:04 <danwent> ok, anything else on melange?
22:40:14 <troytoman> no. i don't think so
22:40:20 <danwent> #topic donabe
22:40:33 <danwent> anyone around for an update?
22:41:00 <danwent> #topic open discussion
22:41:16 <danwent> funny as it sounds, the next design summit is not too far away....
22:41:24 <salv> time flies
22:41:26 <pvo> < 3 months?
22:41:50 <danwent> I'm starting to think about exactly what we should target for netstack deliverables, and what large areas exist for blueprints.
22:41:58 <danwent> just a remind to start thinking about this :0
22:42:05 <danwent> remind -> reminder
22:42:18 <danwent> pvo: yes, and august usually flies by :)
22:42:23 <salv> Well, I had a though about it in the last few days
22:42:55 <danwent> Extensions is something I'd really like to get nailed down.  As well as basic auth.
22:43:11 <salv> On the service side there are three things we must absolutely complete, IMHO:
22:43:12 <Jamey_> extensions and federation
22:43:14 <danwent> as well as multiple plugins.
22:43:40 <salv> 1) extensions, auth, and improve the API
22:43:55 <danwent> salv: can you provide more detail on the "improve the API"?
22:44:07 <somik> we should definitely stabilize the API to tag it "1.0"
22:44:15 <danwent> somik: agreed.
22:44:19 <salv> By improving I mean fixing all the bugs I found while developing the unit test :-)
22:44:28 <danwent> or maybe 0.9, to be less confident :)
22:44:37 <salv> not a lot of them, but enough to keep me busy for a week.
22:45:19 <danwent> Ok, yes, we need to make sure everyone pitches in... you've been doing an enormous amount of work there
22:45:39 <salv> On the plugin side, I think you guys did a great job with the Open vSwitch plugin. Although I'm not sure whether it is "production ready" it is good enough for dev/test environments
22:46:12 <salv> However, I think that for the success of the project we need also a plugin which can be employed across all the hypervisor platforms, including ESX and Hyper-V
22:46:16 <danwent> salv: yes, it definitely still needs work.  right now my focus is on nova, but it will hopefully swing back there soon.
22:46:33 <danwent> salv: agreed.
22:47:14 <danwent> Ok, I think there are all good points.
22:47:18 <salv> danwent: I created theis blueprint a few weeks ago for this: https://blueprints.launchpad.net/quantum/+spec/quantum-vlan-plugin
22:47:56 <salv> The idea is to "port" the Layer-2 part of nova's VLAN network manager to Quantum
22:47:59 <danwent> salv: yeah, I think supporting vmware (at least) should be a pretty straight-forward port of the existing VLAN code.
22:48:13 <danwent> salv: I haven't looked at the hyper-v code, but I suspect it will be similar
22:48:37 <salv> danwent: I have a suspect vlans are not supported in hyper-v at the moment
22:48:53 <somik> does VLANManager support Hyper-V?
22:49:20 <salv> somik: I don't think so (at least I don't see code for setting up VLANs in hyper-v anywhere in nova trunk)
22:49:51 <danwent> if nothing else, I'd like to port something over for both vmware and hyper-v to demonstrate that the platform is sufficiently general.
22:50:05 <somik> salv: thanks thats good to know, what current state of nova networking is.
22:50:48 <danwent> Ok, so sometime in the next few weeks I'd like to create a milestone that we're targeting.... so let's keep this discussion going as to what the relative priorities should be.
22:51:02 <danwent> anything else?
22:51:12 <salv> danwent: sounds like a good plan.
22:51:36 <danwent> ok... have a good one folks.
22:51:41 <danwent> #endmeeting