22:01:43 #startmeeting 22:01:44 Meeting started Tue Aug 9 22:01:43 2011 UTC. The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:01:45 Useful Commands: #action #agreed #help #info #idea #link #topic. 22:01:53 Agenda: http://wiki.openstack.org/Network/Meetings 22:02:14 busy meeting, lots of topics, so if something gets too detailed, we'll probably have to pull it to the netstack list 22:02:24 #general status 22:02:30 #topic general status 22:02:44 wanted to touch on issue of moving to github/gerrit 22:02:59 recent ppb meeting said that core projects are going to try and move before essex summit 22:03:16 of course, there's natural concern about it not wanting to disrupt diablo release 22:03:33 plan is to try and move after we close D-4 22:03:39 any thoughts or concerns on this? 22:03:48 better move now than later 22:03:52 mtaylor: around? 22:04:14 markvoelker: hey 22:04:17 salv: agreed... there will only be more code, more people, more merges, etc. in the future 22:04:31 mtaylor: quick overview of what's necessary to get us moved perhaps? 22:04:41 I'd say after D-4 we start a "transition period". I think the official diablo release should still come from launchpad 22:04:52 salv: yes 22:04:53 markvoelker: it's not too terrible - we have scripts to sync your user account info with gerrit already 22:05:07 why not move after essex summit? 22:05:11 mtaylor: don't oversell :P 22:05:34 markvoelker: the general steps are: 1) stop using the launchpad branches 2) let us do a few things (transitioning your branches) 3) start using gerrit 22:05:37 Sumit: I think that is what it will amount too... anything targeted for Diablo will be fully launchpad 22:05:49 ok good 22:05:49 so the main thing is just that you need to coordinate with jeblair and I 22:05:59 but anything targeted for beyond diablo will end up in git/gerrit 22:06:06 perfect 22:06:13 definitely don't want disruption to mess with the release 22:06:13 mtaylor: are the karma points migrated too? :) 22:06:24 we stay on launchpad for BP, bugs, right? 22:06:29 yes 22:06:30 thanks mtaylor. Does not sound too hard... do we have a tutorial for github/gerrit ? (we had one for bzr + launchpad) 22:06:31 as well as releases 22:06:37 mtaylor: Ok, sounds about like what I expected. I have no problems with this (kinda looking forward to it even =p). 22:06:38 and gerrit has integration with lp bugs 22:06:42 so salv, bhall.... your karma is safe 22:06:46 markvoelker: it'll be fun! 22:06:51 salv-orlando: we do 22:07:03 http://wiki.openstack.org/GerritWorkflow 22:07:09 danwent: you can buy a lot stuff on amazon with your karma points :-) 22:07:20 key points to remember there are instaling the commit hook in each repo you clone 22:07:25 mtaylor: thanks for the pointer 22:07:35 and setting up the review git alias 22:07:43 but if you do all the steps on the wiki page, you should be set 22:08:04 we're trying to keep that up to date as we migrate other people 22:08:07 great. we can play around with it a bit before making the real jump 22:08:32 any other questions/thoughts on github/gerrit? 22:08:33 also - the biggest hurdle is a slight change in mentality from bzr ... where squashing multiple commits into one to submit is the best practice here 22:08:52 but once you get used to that - it's pretty straight forward 22:09:13 there's also command line access to gerrit- https://review.openstack.org/Documentation/cmd-index.html 22:09:17 for your reading pleasure 22:09:30 ok, thanks mtaylor... much appreciated 22:09:33 mtaylor: Great. Ok, I know we have a crowded agenda tonight, so suggest we move on if no other major concerns? 22:09:35 my pleasure! 22:09:45 #topic melange 22:09:52 troy? 22:10:28 just said hello a minute ago... 22:10:31 we are moving forward on integration 22:10:46 (sorry, I have deployment going on with our UK service right now - little distracted.) 22:11:04 ok, maybe send an email to the netstack list if you have any other info to share. 22:11:07 anything else on melange? 22:11:15 we have been working on validating our ability to meet Nova needs before we drop it into a folder 22:11:22 so far, things look good 22:11:28 great 22:11:38 #topic donabe 22:12:12 any updates? 22:12:20 afaik rick is on it 22:12:46 is rick online? a couple people were asking about public code for this... I didn't really have an update for them. 22:13:11 Ok, let's ping rick to get an update as well. 22:13:13 rick/debo have started a branch 22:13:19 i dont have it here with me 22:13:27 but he had sent it out earlier 22:13:36 i will ping him again 22:13:52 ok, here's what I have: https://code.launchpad.net/~netstack-core/donabe/diablo 22:14:02 Sumit: thanks! 22:14:05 i saw the branch publicly but there was just framework stuff and some API 22:14:08 SumitNaiksatam: last time Rick was mentioning an API landing soon in that branch. Is this API there? 22:14:25 but no blueprints for the API yet 22:14:28 salv: last I looked through the branch I didn't see it. 22:14:52 it would be great to have something concrete before the essex summit 22:15:04 ok, anything else on donabe? 22:15:20 #topic quantum 22:15:36 several people have been asking about incubation, now that dashboard and keystone are incubated. 22:15:49 I definitely think we're ready 22:16:06 as far as quantum is concerned... the stats and progress on the project has been really impressive. 22:16:17 +1 22:16:22 I'd like to be incubated before the essex summit. 22:16:40 I'll be pushing on this in the next few weeks, will keep the list updated. 22:16:55 danwent: It would be great to see you incubated at the summit :-) 22:16:55 thoughts? 22:17:04 +1 22:17:10 +1 22:17:37 more importantly, anyone who feels incubation is not the right thing to do? 22:17:46 and if so, why not? 22:17:59 what's the other option? 22:18:16 limbo... which is where we are not 22:18:22 danwent: I'd say based on the progress you guys have made, it may be the right time to propose for incubation 22:18:25 + incubation :-) 22:18:30 +1 22:18:34 everyone things we're an openstack project, we act like an openstack project, but we aren't actually an openstack project 22:18:45 things -> thinks 22:18:55 Ok, sounds pretty unamimous 22:18:56 IMHO incubation has only advantages, I don't see any cons 22:19:19 we've done an incredible amount of work... definitely think it deserves official openstack incubation status. 22:19:21 cool. 22:19:26 if Quantum gets incubated does that imply we then shall run it only against Openstack? I don't think so... 22:19:43 #agreed #danwent, make progress on incubation status 22:19:50 salv: definitely not 22:20:01 I dont think thats a requirement, for e.g. swift can run against Nova or standalone serviing objects 22:20:04 salv-orlando: no - just puts it on a course to be a core openstack project 22:20:06 so I'm 101% in favour of incubation 22:20:11 it does mean adherence to PPB guidelines, etc though. 22:20:28 but that's already a core part of the project 22:20:43 D-4 milestone 22:20:44 we should also get one of us in Openstack PTL which is more than good 22:21:12 I think that would come after incubation 22:21:35 https://launchpad.net/quantum/+milestone/diablo-4 22:21:45 somik: sure I was referring to dan mentioning "official openstack project" 22:22:05 there's a lot of stuff there. I'd like to identify anything that we consider "at risk" and make sure someone is on it. 22:22:41 I think ryu is out this week, but the nova vif-id stuff is going to be a bit tricky.... 22:22:46 I think he already has a branch 22:23:13 is anyone reviewing our branch? :-) 22:23:21 we got to add more stuff 22:23:26 if you're the assignee of a D-4 item, please let me know if you consider it at risk (just send an email) 22:23:42 Sumit: we're definitely planning on reviewing (congrats on the branch) 22:23:49 branch -> merge-prop 22:23:52 Sumit: I would change the status to WIP if you want to make more changes 22:24:07 ok, you mean on the BP? 22:24:08 to avoid people reviewing code if you plan on making additional changes. 22:24:21 the merge proposal 22:24:33 oh let me clarify - the merge prop is good for review 22:24:40 SumitNaiksatam: BTW, that merge proposal does not target lp:quantum 22:24:40 Dan, is there more to the VIF-id's than just exposing them in the nova instance view builder? 22:24:48 once merged, we need to add more after that 22:25:24 asomya: yes, it is also making sure it is passed to the vif-plugin, and making sure it is globally unique (sequential integers don't tend to be) 22:25:32 Sumit: that is fine 22:25:47 salv: i am referring to: https://code.launchpad.net/~cisco-openstack/quantum/l2network-plugin/+merge/70804 22:25:54 In fact, I'd encourage you to merge in multiple chunks, as long as they can be indepdentently verified 22:26:01 SumitNaiksatam_: If the current merge-prop is self contained you can stack the other on top of it using the previous one as a pre-requisite 22:26:09 Ok, officially moving to the "merges + reviews" section of the agenda 22:26:20 danwent: Looking at that list, CI still doesn't have an assignee...but I think heckj has it? 22:26:20 . 22:26:32 https://code.launchpad.net/quantum/+activereviews 22:26:44 heckj, does that sound OK with you? 22:26:56 4907 lines... it's going to take a while :-) 22:27:19 #action #danwent, find owner for CI blueprint, possibly heckj 22:27:35 uh, just a sec - reading back 22:27:48 on the topic of merges, congrats to Vinkesh, Santhosh and team on the extensions branch. 22:27:50 danwent: yeah, good for me 22:27:58 heckj: thx 22:28:13 extensions branch is good to merge, once they clear out a couple merge conflicts. 22:28:21 thanks for all the reviews. 22:28:23 I guess I need to coordinate with mtaylor and heckj this week to get the Jenkins environment up 22:28:45 carlp: yes! we shall make everything lovely 22:28:55 danwent: ok, I managed to expose just the VIf id's with the nova network and fixed_ip details for the dashboard from nova and just pass the vif id to the quantum client to plug into a port. Should I commit this bit if it's useful? 22:29:16 carlp: that would be great. Shweta from cisco is also going to be getting involved 22:29:19 Shweta, you here? 22:29:59 asomya: cool. I think ryu has a branch as well. please send an email to the netstack list with a pointer to the branch and we'll coordinate on that. 22:30:06 * markvoelker calls over the cubical walls for shwetaap to wake up 22:30:24 danwent: soudns good 22:30:24 dawent: I am here 22:30:32 no worries, just wanted to make sure they new to keep her in the loop 22:30:53 CC'ing the list will also be sufficient. 22:31:03 danwent: better, even. =) 22:31:22 big focus of this week on merges will be getting the cisco plugin reviewed. 22:31:29 om review and merges. we have two fairly big merge-props 22:31:50 test-refactor: 896 lines, and l2network-plugin from Cisco: 5109 lines 22:31:54 and salv's API as well. 22:32:07 test-refactor is just a lot of code moved around, review should be quite simple 22:32:15 on the cisco plugin - all the code is new, so it wont break anything :-) 22:32:29 I moved api-alignment back to WIP, should be merge prop again next monday 22:32:32 we'll talk more about the API later, but getting that code frozen ASAP will be important. 22:33:05 salv: great, good to know. we should also coordinate on changing the client code, as I believe there were some changes to API attributes, no? 22:33:40 I will volunteer for reviewing the Cisco plugin, should be able to get a review in by Thursday 22:33:51 heckj: I've added carlp to openstack-ci-admins so that he can be directly involved 22:33:52 #info extension code is reviewed and ready for merge 22:33:55 salv: thanks! 22:34:07 #info major review this week are cisco plugin code 22:34:19 #info expect merge prop of API alignment next monday 22:34:35 ok, let's move on to discussing API spec alignment 22:34:38 salv? 22:34:39 Good. 22:34:50 I've taken into account your feedback 22:35:23 and updated the spec accordingly. Most of the confusion was due to the concept of port state, and of a non-up-to-date section on "theory of operation" 22:36:13 now it should all be consistent. I saw a bit of email on the enum values for port states. Whether we choose "ACTIVE" or "UP" is more or less the same for me. Personally I'd have "UP" in the API, as it makes more sense in networking terms 22:36:41 Apart from this, the merge prop will be delayed until next monday as I need to make sure the clients will not be broken 22:37:28 I also want to make sure we kind of stop changing the API spec by the end of this week. 22:37:35 salv-orlando: I was reviewing gaps in our tests and had came across a test that enforces that quantum network names are unique, but reviewing API wiki, I dont see such agreement. I believe since we already have UUID assocaited with every quantum network, there should be no requriement to have redundant uniqueness of names either. 22:37:37 salv: is plan to keep state in for v1.0, or shift it to v1.1? 22:38:13 for resource state, I still see too much noise on the mailing list to declare it could be in API 1.0 22:38:22 we should finalize what we have as 1.0 22:38:31 if anybody feels the need to have it in 1.0, please speak now. 22:39:02 I think it will be very valuable, but we need to lock down the API and it still seems to need more discussion on the details. 22:39:11 i'm in favor of leaving it out for 1.0 22:39:28 somik: about that test. You're right, but that constraint is actually in the db model. I did not want to mess with that code, but I too think we can remove this constraint. 22:39:31 mtaylor: sweet! 22:39:42 somik: please file a bug on this 22:39:46 salv : DB model != API :) 22:39:57 danwent: sure, will do. 22:40:35 I know that, but how can I possibly create two network with the same name, if then each plugin that uses that db model is going to raise an exception? :-) 22:40:37 salv: what is the plan regarding the existing "state" field in the API? keep it but define it as a logical-only "admin state"? remove it? something else? 22:40:54 logical-only administrative state. 22:41:03 salv, somik: this is outdated code in the db, will remove 22:41:05 No implications on operations you can perform 22:41:13 salv: ok, makes sense 22:41:25 Will smooth this out (the db thing) in API alignment 22:41:38 salv: anything else on API alignment? 22:41:47 Somik: if you file a bug, link lp:~salvatore-orlando/quantum/quantum-api-alignment to it 22:41:50 I guess that is all 22:41:53 thx. 22:41:54 Summarizing: 22:42:01 salv-orlando: sounds good. 22:42:02 few bits left to smooth 22:42:12 make sure clients do not break 22:42:22 and status will NOT be part of API 1.0 22:42:46 that's decided, unless you express your disagreeement now :-) 22:42:54 ok, on to nova + quantum 22:43:14 already talked about vif-id workasomya will send an email to the list, 22:43:32 #action asomya will send an email to the list about vif-id branch 22:43:49 linuxnet_vif plug branch has two approves, one needs info 22:43:53 should be merged soon. 22:44:19 what about the admin API? 22:44:27 quantum manager: I need to send out a link to this branch 22:44:49 salv: yup, I was trying to whip of a first cut at the admin api, two goals: 22:45:16 communicate ownerhship of "interface-ids" from nova to quantum, so quantum can enforce that only the owner of an interface can plug that interface in. 22:45:33 this will probably just be a simple call that includes the interface-id and the tenant-id 22:46:08 was also planning on trying to tackle a generic admin API for "interface bindings".... though this requires some more thought/input 22:46:37 I ported the code over to use the new quantum client lib though, so adding these calls once we know what they want to look like should be simple. 22:47:00 currently we copy the client.py file over, but I'd like to have the packaging so we can just install a dependency, which is definitely the right way to go. 22:47:18 danwent: elaborate on generic admin API 22:47:50 sorry, the generic referred to "interface bindings".... i.e., an interface bindings API that could work with any plugin 22:47:53 is that meant to be part of nova or quantm 22:48:33 salv: same discussion we had on the launchpad merge prop.... 22:48:53 ok, let's take it offline. move to next topic. 22:48:53 #action: #danwent, send out link to discussion on quantum admin APIs 22:49:04 Ok, GUI work 22:49:11 New screenshots for anyone who hasn't seen 'em (great work here asomya!): http://wiki.openstack.org/QuantumClientGUI 22:49:15 awesome screenshots uploaded to wiki page 22:49:30 anything else to report that wasn't already mentioned on the email list? 22:49:31 thanks guys.. Dashboard's done and ready all basic quantum operations are fully functional 22:49:43 can't wait to try it out 22:49:47 just working on a few enhancements like the breadcrumbs and instance details in the VIf column 22:49:59 plans for multi-nic support? 22:50:16 the GUI is coming along really great guys! Very good work! 22:50:35 it's totally agnostic to the instances.. just gets a list of VIF's from nova with the instance labels and prceeds to attach whatever VIF to any port 22:50:49 ok, very cool 22:51:12 salv: api auth, anything to add beyond your detail email to the list? 22:51:24 Also, there was some discussion on the ML with devcamcar regarding a possible better way to integrate with Dashboard rather than the top-level module route....haven't seen a reply lately though. 22:51:26 just that I'd like to hear your opinion 22:51:28 devcamcar: around? 22:51:59 salv: sent some questions via email, but overall sounds great. 22:52:28 about whether we should use keystone's middleware and talk to keystone people for issue, or develop our own middleware based on keystone one 22:52:29 mark: he's definitely interested in helping, so i suspect he'll respond soon 22:52:43 salv: what's your expert opinion? 22:52:47 danwent: grand. 22:53:12 I think it will surely be quicker if we develop a middleware starting from keystone 22:53:18 btw, is tyler around to talk about packaging? 22:53:30 salv: makes sense.... probably the right place to start. 22:53:36 but it would be good to talk to Ziad & other folks at keystone as well. 22:53:39 markvoelker: pong 22:53:43 danwent: unfortunately not, but should have a bp out later this week I think. 22:53:45 okay, move to packaging 22:53:46 salv-orlando, what are you looking for that keystone middleware doesn't currently provide? 22:53:54 mark: k, sounds good. 22:54:10 markvoelker: speak of the devil, I actually just hit send on a message about how best to integrate quantum and dashboard 22:54:21 it provides all that I need, the bit I don't really understand is why we have need an admin token rather than admin credentials 22:54:31 devcamcar: awesomesauce! Reading... 22:54:32 what if that token expires? 22:54:36 #action: #danwent send email to netstack list about where interface ownership should be enforced. 22:55:05 salv-orlando, reauthenticate with keystone and get a new admin token? 22:55:49 #topic open discussion 22:56:01 dolphm_: sure. that is fine. The bit that puzzles me is that the admin token goes in the configuration file 22:56:02 please continue to talk about keystone auth, as well as anything else (5 minutes left) 22:56:10 A minor dashboard thing I forgot.. quantum needs a setup script for the dashboard venv installer .. i've been using a private branch with the setup script.. i'll check the script in tomorrow to trunk 22:56:20 salv-orlando, which configuration file are you referring to?? 22:56:56 asomya: great. are there any gotchas in setting up the dashboard with quantum? definitely want to take a crack at that soon (as, I assume, will others) 22:56:58 the one for using auth_token.AuthProtocol as a middleware in your app pipeline 22:57:24 danwent: it;s fully function here : https://github.com/CiscoSystems/dashboard-quantum-beta .. just that it should grab my private branch instead of trunk 22:57:46 asomya: sweet 22:58:20 ok, will keep the logger running to capture the keystone discussion, but any other topics for opendiscussion? 22:58:38 asomya: I am guessing once you have the setup script, we are good to grab and setup dashboard 22:59:18 salv-orlando, that's a good question that i can't answer (haven't looked at the middleware much) - can you open an issue on github.com/rackspace/keystone ? 22:59:30 salv-orlando, doesn't make sense to me either 22:59:30 that would be a great UI to showcase quantum and even test quantum 22:59:35 somik: you're good to go now.. it graba a private quantum branch that has the setup script 22:59:45 mtaylor: when do you want to talk jenkins? after this? 22:59:49 dolphm_: sure. (I wanted to do that earlier today - too lazy to set up a github account) 23:00:10 ok, going once.... twice.... 23:00:13 General topic for disussion... 23:00:22 just in time :) 23:00:31 asomya: tahnks! 23:00:41 I was at CloudCamp earlier this week and got lots of questions about OpenStack in general and Quantum in particular. That's good. =) 23:01:28 very cool 23:01:40 However I noticed a few BP's were showing still in Unknown state that were actually in flight..mostly ours. =) Some of them hadn't been moved to Approved because I'm not sure we'd agreed on what it takes to be approved? 23:02:13 mark: funny, this topic has actually come up recently in email to 23:02:33 danwent: exactly. =) Partly why I thought I'd bring it up here too 23:02:42 my take is that we're still a small group of devs.... there doesn't need to be an official "approval" process. 23:02:57 right now, if your code impacts someone else, you should be sure to bring it up in the IRC Meeting. 23:03:11 danwent: +1, great. Just wanted to make sure we weren't stepping on any toes. 23:03:12 IMHO the BP approval process should be something that will come in place with time. 23:03:14 once we grow larger, this may have to change 23:03:47 +1 23:03:56 #agreed no official blueprint approval process for quantum.... feel free to move your own blueprint to approved, and be a nice community member and make sure you let people know if your changes affect code they care about 23:04:17 talking about quantum interest, my blog post has now 913 views, in 6 weeks 23:04:28 I'm super happy with the velocity we've been able to have with this project, see no reason to change. 23:04:50 salv: great 23:05:03 ok, we're 5 minutes over, anything else? 23:05:14 just goodnight from me... 23:05:18 great work folks, let's keep it up 23:05:22 #endmeeting