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