22:01:37 <danwent> #startmeeting
22:01:38 <openstack> Meeting started Tue Jun 28 22:01:37 2011 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:01:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
22:01:40 <jamesurquhart> Ram is presenting to Cisco's world-wide engineers on OpenStack right now, so he won't make it.
22:01:51 <danwent> cool
22:01:56 <somik> hello all
22:01:57 <danwent> (that he is presenting)
22:02:04 <danwent> agenda: http://wiki.openstack.org/Network/Meetings
22:02:13 <Jamey> hi
22:02:25 <danwent> #topic netstack updates
22:02:41 <danwent> since dendrobates is out we will skip incubation discussion
22:03:00 <danwent> incubation is tied to us getting hudson access, as well
22:03:07 <danwent> though we're still trying to figure out the details.
22:03:13 <danwent> anything else that is general netstack?
22:03:25 <danwent> #topic quantum
22:03:46 <danwent> general status, we're in a unit test/ system test/ bugfix stage right now.
22:03:51 <danwent> making good progress I feel.
22:03:56 <danwent> Three specific points on the agenda
22:04:13 <danwent> Mark Voelker's team has volunteered to take on the GUI blueprint
22:04:24 <danwent> https://blueprints.launchpad.net/quantum/+spec/quantum-client-gui
22:04:40 <danwent> As part of that work, they will also take a crack at unifying the client code into a library
22:04:59 <markvoelker> Two quick updates there....
22:05:00 <danwent> this library can be used by the GUI, cli, unit tests, and other services (e.g., donabe) that will orchestrate quantum
22:05:09 <danwent> https://blueprints.launchpad.net/quantum/+spec/quantum-client-library
22:05:12 <danwent> take it away mark
22:05:41 <markvoelker> 1.) We've mocked up a little UI just to get a feel for where we'll going...we'll push that out somewhere later this week once we tie up a few loose ends
22:05:57 <danwent> very cool
22:06:14 <markvoelker> One point where we could use some feedback is how/where to deal with extended attributes (QoS, ACL's, etc) so we can discuss that once folks can see it
22:06:16 <salv-orlando> is this UI integrated in Openstack dashboard or a separate gui?
22:06:19 <markvoelker> I'll set up an etherpad
22:06:41 <markvoelker> The plan is to do a separate Django module that will be part of the Dashboard.
22:07:02 <somik> that sounds like the right approach
22:07:41 <danwent> k, anything else to add on the GUI or client lib front?
22:07:56 <markvoelker> Second update: we'll be working on the refactor starting later this week.  May be a tad slower than we'd have liked as one of our engineers is unexpectedly traveling out of the country.
22:08:09 <markvoelker> That's all for me
22:08:26 <danwent> thanks mark.  will be great to have a GUI.
22:08:37 <danwent> Next topic is API authn/authz
22:08:48 <danwent> Salvatore wrote a blueprint here: http://wiki.openstack.org/QuantumAuthSpec
22:09:02 <danwent> I'd like to thank him for a very clearly written blueprint, very easy to follow
22:09:12 <danwent> salvatore, what is your preferred mechanism for feedback?
22:09:26 <danwent> (I know you don't like etherpad ;P)
22:09:28 <salv-orlando> email, possibly
22:09:35 <salv-orlando> or launchpad answers
22:09:45 <salv-orlando> etherpad is cool, but lacks notification
22:09:51 <danwent> agreed.
22:10:00 <danwent> launchpad answers is a clever idea.
22:10:04 <danwent> maybe give that a try?
22:10:04 <salv-orlando> launchpad answsers are probably better than emails
22:10:16 <danwent> do you want to ask a question, then post the link?
22:10:24 <danwent> so we can have a thread?
22:10:29 <salv-orlando> yes, sure
22:10:32 <danwent> or do you want to handle individual questions.
22:10:58 <salv-orlando> I can post a general question, and then people can submit specific question as well.
22:11:23 <danwent> great
22:11:40 <danwent> Third and final quantum topic: nova changes and quantum integration.
22:11:54 <danwent> Seems like the multi-nic code is still going through merge, but it very close now
22:11:58 <ryu_ishimoto> right
22:12:10 <danwent> ryu's branch is: https://code.launchpad.net/~midokura/nova/network-refactoring
22:12:21 <ryu_ishimoto> it is, and i have merged it into the refactoring branch to test it out with the current version of multi-NIC
22:12:34 <ryu_ishimoto> and identified a few places that may cause problems with Quantum integration
22:12:41 <danwent> I've pulled but have not tested much.  hoping to get to that over the long holiday (US) weekend
22:12:48 <danwent> ryu: please elaborate
22:13:27 <ryu_ishimoto> the main issue was that 'virtual_interfaces' model is tied to the 'networks' model of Nova
22:13:51 <danwent> ah, you mean whether that reference is nullable?
22:13:58 <ryu_ishimoto> virtual_interfaces is the VIF table that will be used to communicate with Quantum
22:14:26 <ryu_ishimoto> right, we need to keep the current Nova networking but it is preferable to use this table as the VIF f or Quantum
22:15:03 <danwent> ryu: can you quickly repost your spec page for those listening in?
22:15:06 <danwent> I don't have the link handy
22:15:29 <salv-orlando> ryu_ishimoto: is that a data model issue?
22:15:29 <danwent> http://wiki.openstack.org/network-refactoring
22:15:35 <danwent> found it.
22:15:36 <ryu_ishimoto> sure, it's http://wiki.openstack.org/network-refactoring  I haven't updated it with multi-NIC stuff but I will
22:15:44 <danwent> great.
22:16:04 <ryu_ishimoto> Trey just told me today that he will make that network_id field nullable so that we can keep using VIF for Quantum
22:16:14 <tr3buchet> :)
22:16:16 <salv-orlando> cool
22:16:24 <tr3buchet> better to do this now
22:16:29 <danwent> agreed.
22:16:39 <danwent> great work guys.
22:16:50 <danwent> (and tr3buchet in particular... that was a monster patch)
22:17:04 <tr3buchet> you should see the merge conflicts ;)
22:17:08 <danwent> OK, anything else for quantum?
22:17:12 <ryu_ishimoto> tr3buchet: yeah seriously.  thanks Trey!
22:17:16 <danwent> tr3buchet: ha
22:17:20 <ryu_ishimoto> that's it for now
22:17:25 <danwent> thanks ryu
22:17:26 <salv-orlando> jusrt a quick passage on API extensions...
22:17:33 <danwent> sure
22:17:44 <salv-orlando> has there been any progress? do we have an agrement on the extension model?
22:18:03 <danwent> I think we agreed on following the openstack standard model
22:18:03 * vishy notes that managing long-diverged branches in bzr often leads to re-fixing the same conflicts over and over again.  bzr merge --weave helps sometimes.
22:18:18 <danwent> whoops
22:18:44 <danwent> do we have any update on jorge's work in general?
22:18:47 <tr3buchet> vishy: yeah i played with --weave a bit
22:19:19 <danwent> I'd really like to understand better where the existing extensions proposal differs.
22:19:33 <danwent> I think we also need to figure out how plugins "register" an extension.
22:19:46 <troytoman> I don't have an update from Jorge on the extensions documentation. I don't think there are changes pending as much as clearer documentation
22:19:47 <salv-orlando> I'd like to undestand these two things as well
22:19:52 <danwent> Same call as last meeting:  if anyone wants to take a lead on this, please let me know.
22:20:19 <danwent> (someone other than salv-orlando... he has already volunteered for too much :) )
22:20:47 <jamesurquhart> The ask is to follow up on extensions progress with Jorge?
22:20:49 <salv-orlando> I might be wrong, but I think Ying was warking on this
22:20:50 <danwent> I'm hoping to get cycles to do a quick review of the current work
22:21:16 <danwent> it would be great for someone to scope out where the existing stuff falls short and call this out in the blueprint.
22:21:34 <jamesurquhart> Ying and SumitNaiksatam were tracking this, I believe.
22:21:38 <danwent> Yes, both Ying and Somik have done a review.
22:21:41 <troytoman> Ying had a number of email exchanges with my team and with Jorge this week. I think the primary gap is with dynamic loading of extenstions
22:21:53 <danwent> Ah, great.
22:22:15 <troytoman> I think it is agreed that should probably be handled in a separate blueprint. but, i don't know if everyone is agreed yet
22:22:43 <danwent> troytoman: dynamic loading be handled separately from the rest of the extension blueprint?
22:22:47 <jamesurquhart> Do we need an online meeting to sort that out?
22:23:01 <jamesurquhart> I can volunteer to get everyone together online if that is what is needed.
22:23:17 <somik> another thing is that the current extension code is falls short of jorge's extension proposal
22:23:39 <salv-orlando> somik: can you give us some details?
22:23:39 <troytoman> danwent: yes. the current extension mechanism was never intended to address that space.
22:23:55 <danwent> jamesurquhart: that could be helpful, though also just making sure that people are aware of the emails being sent is probably a good start.
22:24:09 <somik> sal-orlando: the current code is modelled on existing extension mechanism in nova
22:24:14 <danwent> troytoman: ok, i haven't put much thought in on that front.
22:24:22 <danwent> maybe a meeting on the extensions stuff would make sense.
22:24:41 <jamesurquhart> troytoman I'll follow up with Ying, but can you see that I am cc'ed on the email thread/
22:24:49 <jamesurquhart> ?
22:25:01 <troytoman> jamesurquhart: will loop you in
22:25:12 <jamesurquhart> OK. I'll get something together, starting with Ying and troytoman.
22:25:27 <danwent> Ok, that would be great.
22:26:00 <danwent> Does someone want to take a crack at a "dynamic API extension" blueprint?
22:26:12 <somik> salv-orlando: Jorge's extension proposal and our requirements are more than what nova supports. Our Pluggable backend presents additional challenges. Both these issues need to be addressed before we will be ready for merge.
22:26:14 <danwent> or are we not on the same page about this being separate?
22:26:31 <salv-orlando> somik: got it, cool
22:26:41 <salv-orlando> +1 for separation
22:26:44 <danwent> is there a point in merging the rest of the stuff before the dynamic loading is implemented?
22:26:52 <danwent> I'm not familiar enough with the code to know.
22:27:47 <somik> we might have to redo plugins an extensions
22:27:49 <danwent> Otherwise I'd probably prefer to get the model right outside of trunk, then merge.
22:28:05 <danwent> but I don't feel that strongly about this, so if someone has another opinion, holler
22:28:06 <troytoman> I think the dynamic piece should be separated. we will have to do some work to handle extensions.
22:28:12 <somik> danwent: that seems like a better idea to reduce churn therefore bugs.
22:28:29 <danwent> troy: since you have done the work here, I'm happy to yield to your take.
22:28:36 <troytoman> we can do that before or after a merge.
22:28:54 <troytoman> sounds like we want to make those changes before merging, correct?
22:29:02 <danwent> I'd prefer that
22:29:11 <danwent> Sounds like a plan unless someone objects
22:29:17 <danwent> going once, twice....
22:29:22 <danwent> ok, sounds like a plan :)
22:29:35 <danwent> anything else on quantum?
22:29:51 <danwent> #topic melange
22:29:54 <danwent> troy?
22:29:59 <danwent> general update?
22:30:24 <troytoman> we continue to evolve the base functionality given feedback and example use cases
22:30:35 <danwent> btw, troy, can you create a blueprint for the dynamic stuff (or ask Ying/Sumit to do it?)
22:30:59 <danwent> dynamic -> dynamic extension loading
22:31:10 <troytoman> jamesurquhart and I will work that out since I think ying is best suited to spec it out
22:31:22 <danwent> great, thanks.
22:31:36 <jamesurquhart> troytoman agreed
22:31:51 <troytoman> we are bringing some rackspace nova core devs into the loop to help us figure out Nova integration
22:32:34 <troytoman> i am hoping we can get the project merged into Nova in the D3 timeframe. integration of the service within Nova can start after the nova network refactoring is merged.
22:32:41 <danwent> cool.  any thoughts yet on a timeline?  I know the nova-network-refactoring is slotted for d3, which is coming up soon.  Do you see these changes as part of that?
22:32:49 <danwent> sorry, crossed wires
22:32:58 <troytoman> i plan to get blueprints/wiki/etc. updated within the next week - i'm a bit behind there
22:33:25 <jamesurquhart> danwent: Are you creating actions via eavsdrop? With hash action?
22:33:44 <danwent> I can :)
22:33:56 <jamesurquhart> Hey, I don't care. Just curious. ;)
22:34:04 <danwent> no, its a good suggestion
22:34:26 <danwent> #action jamesurquhart + troytoman will coordinate on dynamic api extension blueprint
22:35:23 <danwent> troy, do you expect that melange will replace existing nova code for IP allocation, or site along side it as an option?
22:35:49 * salv-orlando danwent stole my question :-)
22:36:06 <troytoman> we are thinking it would likely replace the existing code. that was one of the drivers behind putting it into the Nova project.
22:36:24 <troytoman> and a reason to wait for the refactoring work to be done
22:36:30 <danwent> great to hear.  makes sense.
22:36:55 <danwent> any other melange-related discussion points?
22:37:26 <danwent> #action troytoman update nova melange blueprints
22:37:34 <danwent> #topic donabe
22:37:41 <danwent> anyone around for an update?
22:37:50 <danwent> I know dendrobates mentioned an API a while ago.
22:38:24 <jamesurquhart> I'm just getting integrated into that effort, so I can't give update, but there is work underway.
22:38:25 <danwent> With quantum + multi-nic, I think we are to the point where we could at least create some interesting topologies as "containers"
22:38:35 <danwent> Ok, sounds good.
22:38:46 <danwent> #topic open discussion
22:39:01 <danwent> one question: are most people working next tuesday?
22:39:22 <salv-orlando> yes, I am... no holydays in the UK!
22:39:29 <somik> jamesurquhart: it would be good to get some blueprints for discussion before writing too much code..
22:39:39 <markvoelker> danwent: I likely will be
22:39:40 <danwent> salv: :)
22:39:53 <danwent> OK, that sounds like quorum to me :)
22:40:12 <danwent> any other open discussion?
22:40:20 <somik> salv-orlando: only monday is a holiday in US, tuesday is officially open for business here too :)
22:40:37 <salv-orlando> I'd really love to make some progress on incubation, is we need to move the meeting for having dendrobates it is fine for me
22:40:42 <jamesurquhart> somik: Right. That's the plan. Get some blueprints together quickly for discussion.
22:41:17 <danwent> salv: dendrobates was actually on vacation, then had a conflict today.  We'll ping him on that.  I believe he is making progress.
22:41:30 <salv-orlando> cool
22:41:31 <danwent> #action dendrobates to give update on quantum incubation for next meeting
22:41:42 <danwent> look at me using those action tags :)
22:41:52 <danwent> anything else?
22:42:15 <jamesurquhart> You are a hash master, danwent. ;)
22:42:28 <danwent> ok, let's call it a meeting
22:42:30 <salv-orlando> launchpad question for discussion on authN/authZ for quantum: https://answers.launchpad.net/quantum/+question/163091
22:42:31 <danwent> #endmeeting