22:03:09 <danwent> #startmeeting
22:03:10 <openstack> Meeting started Tue Jul 26 22:03:09 2011 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:03:11 <ttx> creiht: nah! But I feel guilty too, since tr3buchet asked me how to best handle this
22:03:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
22:03:21 <danwent> agenda: http://wiki.openstack.org/Network/Meetings
22:03:32 <danwent> #topic netstack updates
22:03:50 <danwent> I sent an email out about the lack of a license file in quantum
22:04:05 <danwent> I believe this was just an oversight, but wanted to check if there were any concerns about adding one.
22:04:27 <danwent> I am not sure if this applies to melange and donabe as well, so wanted to bring it up for nestack as a whole
22:04:55 <danwent> Ok.... sounds like we'll add it so we're aligned with nova and swift as far as licensing
22:04:56 * markvoelker hears crickets
22:04:56 <troytoman> sounds like a good idea. we'll look at it for Melange
22:05:04 <jamesurquhart> No problems here.
22:05:06 <danwent> anything else netstack wide?
22:05:20 <jamesurquhart> I'll forward to Rick for Donabe.
22:05:24 <danwent> #topic quantum
22:05:28 <danwent> james: thx
22:05:38 <danwent> first, unit test status
22:06:08 <danwent> we're holding off merging things until the unit tests are clean, but I believe we have both the extensions and the client lib that are close to being ready to land, so I wanted to find out if there were any unit test blockers
22:06:23 <danwent> salvatore: I know you have fixes for some already
22:06:37 <somik> I believe salvatore has created bugs to track unit test issues
22:06:41 <salv> danwent: Unit tests branch is merged. Many of them fail, for well-known bugs
22:07:01 <somik> and the plan was to treat those bugs with highest priority before merging new features.
22:07:05 <salv> A branch for fixing failures in unit tests is already proposed for merge
22:07:25 <danwent> ok, just waiting on review?
22:07:32 <salv> yes.
22:07:52 <danwent> #action core-devs need to review unit test fix branch
22:08:02 <salv> after merging that branch, 7 unit tests will still fail. I've created bugs for tracking those failures as well. Unfortunately I still don't have a fix for this.
22:08:21 <salv> the branch is lp:~salvatore-orlando/quantum/quantum-api
22:08:33 <danwent> salv: is it that we just haven't had the cycles to fix, or are there major questions?
22:08:49 <danwent> i.e., could anyone pick off those tests?
22:09:00 <salv> danwent: they haven't been fixed because I took some days off last weel :)
22:09:05 <salv> *week
22:09:13 <danwent> salv: you shouldn't have to be the only one fixing :P
22:09:29 <salv> the bugs are there... anyone can pick them :)
22:09:58 <danwent> ok, i see 4 that are "in progress"
22:10:03 <danwent> https://bugs.launchpad.net/quantum
22:10:45 <salv> the bugs are #814012 and #814517
22:11:27 <jamesurquhart> *enjoys listening to the crickets*
22:11:43 <danwent> ah, looks like the page I was viewing doesn't show them by default....
22:11:52 <danwent> silly launchpad.
22:11:59 <markvoelker> salv: I'll see if I can get some of my guys to break off some cycles to look at these this week....
22:12:09 <salv> On unit tests, dan in his wiki page made an interesting point on plugin-specific unit tests
22:12:16 <salv> markvoelker: thanks!
22:12:35 <salv> I have been contacted by some developers asking me about them.
22:12:40 <danwent> #action: target fix for #814012
22:12:52 <danwent> #action target fix for #814517
22:13:13 <danwent> markvoelker: thanks.  Please assign the bugs to you if you start working.  I'll try to get some cycles on them as well.
22:13:25 <markvoelker> danwent: will do
22:13:59 <danwent> yes, created a page on Quantum testing in general: http://wiki.openstack.org/QuantumTesting
22:14:06 <salv> I think that if the plugin is part of the quantum source code tree, it makes sense to have unit tests. The only open question for me is whether this tests should be in the "tests" directory or in a plugin-specific directory
22:14:08 <danwent> please add your thoughts and comments.
22:14:38 <danwent> salv:  my thinking was that they would be in the plugins directory.
22:14:49 <salv> danwent:: agrred
22:14:53 <danwent> salv: but that's more of a gut feeling
22:15:17 <danwent> anyone have concerns with plugin-specific unit tests being in the plugin's directory?
22:15:26 <danwent> rather, the plugin's own directory
22:15:41 <carlp> danwent: I think that makes sense
22:16:05 <danwent> K.  Then we'll need to figure out how to make our unit-testing framework scan for an load them.
22:16:05 <jamesurquhart> Seems logical to me. However, will they still be executed by default if that plugin is included in a test environment, or will they be executed separately?
22:16:18 <jamesurquhart> danwent: read my mind
22:16:22 <danwent> james:  my thought was that they would be executed by default.
22:16:38 <danwent> we want to be able to identify if a change to the main quantum code breaks a plugin.
22:17:14 <danwent> but this means that a plugin must be able to run on most people's system, at least well enough that they can confirm that unit tests pass
22:17:38 <SumitNaiksatam> danwent: good point
22:17:38 <jamesurquhart> Also, plug-in will likely have extensions that core Quantum tests won't understand.
22:17:56 <danwent> (i.e., if you plugin has some crazy dependency, most devs won't install it, and then they won't know that they did something to break it)
22:18:06 <danwent> this isn't all that different than the previous nova discuss (duck!)
22:18:18 <carlp> lol
22:18:39 <SumitNaiksatam> these tests should work with a "default" plugin
22:18:49 <danwent> sumit: certainly
22:19:03 <danwent> but ideally we'd even get coverage across other plugins
22:19:06 <SumitNaiksatam> there should separate tests for specific plugins (which can be run on demand)
22:19:17 <jamesurquhart> Isn't it the plug-in developers responsibility to determine if a change to Quantum core breaks their plug-in?
22:19:29 <SumitNaiksatam> james: +1
22:19:39 <somik> i agree that individual plugins that are not part of quantum shouldnt be run by default.
22:19:53 <salv> james +1 with a but...
22:19:58 <somik> especially if the plugin requires some infrastructure that will not be available in jenkins
22:20:18 <salv> We should at least make sure that the plugins keep consistent with the interface enforced by Quantum
22:20:18 <jamesurquhart> somik: However, if the plug-in is installed, the test framework should find the unit tests for that plug-in and run them
22:20:24 <danwent> james:  that would be one path to go down.  certainly easier for other developers.  but it could lead to thinks being merged into trunk that break a particular plugin without that main quantum developer knowing it.
22:20:31 <somik> james: correct, agreed
22:20:55 <SumitNaiksatam> danwent: in that case still the responsibility of the plugin-developer
22:21:02 <danwent> I think for now we can assume plugin unit tests are executed separately (e.g., we only load the unit tests for the plugin defined by the conf file)
22:21:09 <jamesurquhart> danwent: Not sure how I can see that being avoided except every core Quantum dev installing every plug-in…
22:21:30 <SumitNaiksatam> danwent: +1
22:21:33 <danwent> james: I agree.... I was just trying to figure out if there might be a way around it, as its not ideal.
22:21:40 <danwent> but I think this is the best place to start.
22:21:50 <jamesurquhart> Then again, I'll admit some naivite when it comes to unit testing in OpenStack
22:21:52 <SumitNaiksatam> plugins-specific tests can go in a plugin-specific directory
22:21:56 <danwent> no need to design a solution to a problem that's only hypothetical anyway :)
22:22:17 <SumitNaiksatam> that can include tests for extensions as well
22:22:21 <jamesurquhart> danwent: Oh, c'mon. That's the definition of "silicon valley" ;)
22:22:25 <danwent> :)
22:22:46 <jamesurquhart> Sumit: +1
22:22:59 <danwent> #action danwent create blueprint/bug to make unit test framework load tests for the "active" plugin.
22:23:07 <danwent> ok, anything else on testing?
22:23:44 <salv> danwent: we can bring this offline, but I see the concept of active plugin as something which has more to do with functional/system testing
22:23:48 <salv> rather than unit testing
22:24:35 <danwent> salv: i see where you're coming from, I think it really just comes down to whether you can assume everyone is able to even load everyone else's plugin in order to execute system tests and commit code.
22:24:39 <jamesurquhart> salv: Include me. Unit testing of plug-in is for the plug-in, not Quantum, but may be dependent on Quantum tests.
22:24:41 <danwent> let's move this to the list?
22:24:48 <jamesurquhart> Yes
22:24:51 <salv> yes
22:24:55 <danwent> great.
22:25:00 <danwent> Salv: you have an action item to review the API spec page and try to bring it inline with the implementation?
22:25:25 <danwent> I believe there's already a bug for this, right?
22:25:41 <danwent> https://bugs.launchpad.net/quantum/+bug/813433
22:25:42 <uvirtbot`> Launchpad bug 813433 in quantum "Align API implementation with specifcation" [Undecided,New]
22:25:46 <salv> I've reviewed the API spec and updated the wiki page. The bug has been created, but no progress on the code
22:25:46 <danwent> answering my own question :)
22:26:06 <danwent> ok, nothing else on that topic then.
22:26:12 <danwent> Nova work:
22:26:32 <danwent> first off, congrats to ryu for sheparding in the vif-plugging code into D-3
22:26:35 <salv> the API spec is much nicer now. And Troy sent an interesting feedback on the mailing list. Hope to reply ASAP.
22:26:36 <danwent> it is now in trunk
22:26:45 <ryu_ishimoto> the VIF plugin work was merged!
22:26:47 <salv> cheers!
22:26:51 <ryu_ishimoto> whew!
22:26:52 <SumitNaiksatam> ryu: great job!
22:26:52 <danwent> hooray :)
22:27:02 <somik> thanks ryu!
22:27:11 <ryu_ishimoto> thanks, esp Dan for your help!
22:27:31 <danwent> additional vif-plugging is now possible, you don't even have to modify nova code if you don't want to.
22:27:54 <carlp> that's the best news I've heard all week
22:27:55 <danwent> you can just use the flag-file to point to a python class that implements the vif-plugging API for the particular virt driver.
22:28:08 <danwent> very cool stuff.
22:28:23 <salv> VIF-plugging is supported for libvirt and xenapi, is that correct?
22:28:33 <danwent> salv: yes
22:28:58 <danwent> salv: we're looking for people to do it for vmware + hyperv as well, if that makes sense (we didn't have a pressing use case)
22:28:59 <salv> I hope to get someone to work on ESX, but as you might have read from the previous meeting, it is going to be thougher than expected
22:29:08 <danwent> :P
22:29:29 <danwent> D-4 will be a pretty busy period for quantum-related changes in nova.
22:29:42 <salv> Basically for both ESX and Hyper-V we first need to support multi-nic, and then we can do vif-plugging.
22:29:43 <danwent> ryu will be doing some additional network refactoring work.
22:30:14 <danwent> ryu, you are targeting the changes that make all network access via the network API, correct?
22:30:29 <ryu_ishimoto> danwent: yes that is my plan
22:30:34 <danwent> great.
22:30:44 <ryu_ishimoto> as well as VIF REST OpenStack API
22:30:55 <danwent> Yup.
22:31:14 <danwent> We also have the other blueprint, which we bumped from D-3 to D-4: https://blueprints.launchpad.net/nova/+spec/implement-network-api
22:31:36 <danwent> no spec yet, but will update it soon
22:31:51 <ryu_ishimoto> danwent: great thanks
22:31:55 <salv> danwent: I also saw you created a quantum blueprint for standardazing plugin/agent communication, is that correct?
22:31:55 <SumitNaiksatam> danwent: is there a place where we can lookup all that is lined up for D4?
22:31:56 <danwent> this work will focus on actually making calls to the quantum api
22:32:25 <danwent> I will be updating the blueprint spec soon.
22:32:34 <salv> SumitNaiksatam: https://launchpad.net/nova/+milestone/diablo-4
22:32:38 <troytoman> ryu_ishimoto: do you have a blueprint for the VIF API ? we have been thinking about this too
22:32:39 <danwent> salv: yes... that has been behind the nova work so far.
22:33:01 <danwent> sumit:  with respect to quantum, it is the above blueprint, plus ryu's original blueprint
22:33:16 <danwent> ryu, have a link?
22:33:20 <SumitNaiksatam> salv: thanks, meant Quantum
22:33:24 <SumitNaiksatam> danwent: thanks
22:33:47 <ryu_ishimoto> troytoman: not for VIF plugin, but there is one for network refactoring in general
22:34:10 <RamD> how about quantum related work..example:Openstack-dashboard changes for quantum, may be a nova-mange CLI support for Quantum and so on..where are we tracking
22:34:21 <danwent> sumit: ah, I've just started putting together a potential roadmap... thinking more in terms of what we want to have for D6, then we can work backward.
22:34:33 <troytoman> ryu_ishimoto: we have been working on a proposal to expose /interfaces in the Nova API in the future. we should probably sync up
22:34:43 <danwent> just brainstorming right now: http://wiki.openstack.org/QuantumRoadmap
22:35:01 <RamD> troytoman: me interested as well...
22:35:23 <RamD> danwent: Cool Thanks
22:35:23 <danwent> netstack list ;)
22:35:30 <ryu_ishimoto> troytoman: https://blueprints.launchpad.net/nova/+spec/network-refactoring this is the blueprint
22:35:46 <ryu_ishimoto> troytoman: yes, let's do that
22:35:49 <RamD> yep, netstack list :-)
22:35:53 <troytoman> RamD, ryu_ishimoto: trying to get something out to mailing list but may circulate something to a smaller group initially
22:36:02 <danwent> RamD:  I actually have been thinking that we may create quantum blueprints that track work happening in nova + dashboard that are critical to quantum deliverables.
22:36:32 <danwent> they would really just be "references" to other blueprints, but would make it easier for people to see everything we're hoping to deliver, even if the actual blueprint is elsewhere (e.g., in nova).
22:36:42 <RamD> danwent: I think its a good idea...that way you can include Quantum BPs to Quantum milestones
22:37:09 <danwent> RamD:  yes, am hoping to start using milestones for D-4....
22:37:23 <danwent> though with my luck, the second i figure out how they work, we will shift to github :P
22:37:36 <RamD> Yep..let's take it to netstack and decide and agree for D4
22:38:06 <danwent> Ok, anything else on quantum-related changes for nova?  expect some significant BP action on this in the next week or two.
22:38:08 <RamD> Is there a plan for Quantum to move to github
22:38:16 <danwent> RamD: ASAP :)
22:38:35 <danwent> I'm assuming we'll move when the "bulk" of openstack moves
22:38:44 <SumitNaiksatam> can we postpone it to past diablo?
22:38:47 <salv> danwent: I don't want to lose my launchpad Karma points :) I was hoping to convert them into an Amazon voucher...
22:38:49 <danwent> I think they are still kind of beta testing it on a few projects like dashboard.
22:38:55 <SumitNaiksatam> unnecessary distraction
22:39:08 <danwent> salv: haha...  I think i have the most to lose there, but I still want to move to github :)
22:39:19 <danwent> sumit:  definitely understand the concern.
22:39:27 <RamD> Sumit: +1
22:39:45 <danwent> sumit: we'll see what openstack does.  It may be that we actually stay with launchpad for planning, I'm not sure.
22:39:51 <RamD> but if the openstack itslef moves we move as well, I guess
22:39:52 <danwent> does anyone have more insight on this?
22:40:03 * markvoelker has a little
22:40:04 <troytoman> keystone has already moved
22:40:21 <danwent> #action danwent check with openstack folks about timing of move to github
22:40:28 <markvoelker> Keystone and Dashboard have moved already and mtaylor has some work going on wrt migration
22:40:42 <danwent> I'm actually wondering if it might be MORE disruptive to do it around the time of a design summit... not sure.
22:40:45 <markvoelker> Code hosting and reviews would move, but most everything else is staying in LP IIRC.
22:41:00 <danwent> salv, your karma is safe :P
22:41:05 * salv loves this discussion but thinks the ML is a better place for it
22:41:14 <danwent> mark: thanks, that's good to know.
22:41:22 <danwent> Ok, done with nova
22:41:27 <danwent> Extensions:
22:41:30 <troytoman> we should reach out to mtaylor and start the discussion. he's on point for migrations
22:41:35 <danwent> I think this is proposed for merging?
22:41:38 <troytoman> yes
22:41:40 <danwent> troy: sounds good, thanks.
22:41:58 <troytoman> the team pushed the merge prop this morning
22:42:02 <danwent> so its lined up behind the unit test fixes?
22:42:11 <danwent> (extra incentive :P)
22:42:28 <ying> We have tried with the latest extension framework, it works with our extensions
22:42:37 <danwent> Ok, if you're looking to review the extensions stuff again, please let it be known.
22:42:44 <danwent> ying: great to hear
22:43:06 <ying> I'm reviewing the code and will provide more comments
22:43:45 <danwent> OK, let's get reviews in during the next couple days, so we're ready to merge end of week if possible.
22:43:46 <ying> danwent: sure
22:44:10 <danwent> Ok, client lib & GUI
22:44:22 <danwent> I saw some sweet screenshots on the wiki
22:44:26 <danwent> mark?
22:44:35 <asomya> Put some screenshots in this morning at :
22:44:37 <asomya> http://wiki.openstack.org/QuantumClientGUI
22:44:38 <markvoelker> Yes.  Check the whiteboard here:
22:44:39 <markvoelker> https://blueprints.launchpad.net/quantum/+spec/quantum-client-gui
22:44:56 <markvoelker> Has links to screenshots and some info on Arvind's net branch in GitHub
22:45:13 <markvoelker> The screenshots are from an earlier rev so quite a bit has changed, but should give you a good idea
22:45:21 <markvoelker> We'll update those as things develop this week
22:45:34 <asomya> The screenshots are still based on the older dashboard code that has since undergone significant facial and structural changes.. the new one looks a lot better :)
22:46:00 <asomya> Preliminary integration of quantum + dashboard available here: https://github.com/CiscoSystems/dashboard-quantum-beta
22:46:33 <danwent> Great.  I think there is still some discussion about exact how interface-ids + network-ids will be exposed and bound to each other (per Ryu + Troy's previous comments)
22:46:44 <danwent> so it would be good if you all are in the loop about that as well.
22:47:04 <RamD> danwent: How/where its being discussed? Netstack??:-)
22:47:08 <danwent> I think from the screenshots it looks like you are using the VM name as the interface-id for now?
22:47:24 <danwent> RamD: discussion hasn't started yet, but Troy and Ryu just said they wanted to talk about it.
22:47:33 <asomya> Based on the old nova code before multi nic.. it only exposed instances
22:47:34 <troytoman> ramd: hasn't been discussed yet. will be discussed because I think we are all thinking about it
22:47:35 <danwent> Such discussions should happen on netstack.
22:47:45 <SumitNaiksatam> danwent: +1
22:47:56 <troytoman> will probably have to be on the openstack list because it involves Nova
22:47:58 <SumitNaiksatam> kindly cc the netstack mailer
22:48:04 <RamD> danwent: on the interface-ID ..one thing we were thinking was to have option to add labels
22:48:25 <danwent> RamD: can you expand?
22:48:50 <danwent> or better yet, send an email to the list
22:48:56 <danwent> as we're running out of time
22:49:10 <danwent> API auth
22:49:21 <markvoelker> danwent: Sure, throw a #action in for us to take that to the list and we'll make it so.
22:49:47 <salv> danwent: no progress on auth on my side. Have you heard from Keystone people?
22:49:48 <danwent> #action markvoelker, ramd send email to netstack about labels with interface-id
22:50:03 <RamD> in addition to a "quantum" spefic GUID, have a "facilty" to add labels..example my network external 1 for the client
22:50:04 <danwent> #action troy, ryu, initiate discussion about interface-id, flow on netstack.
22:50:22 <primeministerp1> #freecloud
22:50:34 <danwent> salv: yes, I have a half written email on auth.  we can discuss more on the list.  Still need to think through it some more.
22:50:35 <primeministerp1> whoos
22:50:36 <primeministerp1> p
22:50:47 <danwent> anything else on quantum?
22:51:12 <danwent> #topic melange
22:51:16 <danwent> troy?
22:51:57 <danwent> ok, well troy mentioned that he and some of the nova devs are starting to work on integrating melange code into nova
22:52:38 <danwent> sounds like nothing else to update on melange
22:52:44 <danwent> #topic donabe
22:52:53 <danwent> any updates here?
22:53:03 <troytoman> danwent: sorry slipped over to another conversation :-)
22:53:14 <danwent> ok, back to melange
22:53:26 <danwent> ignoring me again, huh troy?
22:53:34 <troytoman> not much to update on melange, we're getting blueprints updated and specs put together
22:53:48 <troytoman> plan to try and get the code dropped into the Nova project in D4.
22:53:57 <danwent> k, great.
22:54:04 <troytoman> then look at how to start integrating it into the Nova system for managing IPs
22:54:18 <danwent> #topic open discussion
22:54:26 <jamesurquhart> Donabe: Rick will send details, but he told me a framework branch has been checked in, and APIs will be checked in as early as next week.
22:54:27 <troytoman> will probably just focus on the initial quantum/melange network manager
22:54:45 <danwent> james: thanks for the update
22:54:58 <jamesurquhart> I was hoping to have more, but he's tied up with OSCON, and connectivity apparently stinks.
22:55:23 <danwent> On donabe: I've been talking to rick a bit about adding a donabe wiki page to start calling out the goals, how it differs from other projects, etc.
22:55:31 <somik> cool, I did see the first check-in on donabe, it would be great to see how we integrate all this stuff using some blueprints
22:55:38 <jamesurquhart> Yes. Needs to be done.
22:55:54 <danwent> other open discussion?
22:55:58 <jamesurquhart> I can work with Rick to get the initial pages up.
22:56:21 <salv> May I suggest we rotate the project order for next meetings?
22:56:24 <danwent> Rick said he was going to talk to the openstack folks while at OSCON about getting us access to the main openstack jenkins
22:56:38 <danwent> salv: melange and donabe first?
22:56:39 <salv> This way we won't have to discuss Melange and Donabe in injury time.
22:56:53 <danwent> haha... that seems reasonable.
22:57:04 <danwent> its just a few agenda edits away.
22:57:21 <danwent> any other open discussion?
22:57:42 <danwent> #action dendrobates provide update on jenkins infrastructure
22:57:56 <danwent> #endmeeting