22:03:14 <danwent> #startmeeting
22:03:15 <openstack> Meeting started Tue Jun 21 22:03:14 2011 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:03:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
22:03:37 <danwent> #topic netstack status
22:03:50 <danwent> was hoping to get an update from dendrobates about incubation status
22:04:00 <danwent> perhaps he will pop up later and let us know.
22:04:18 <danwent> any other general nestack topics?
22:04:35 <danwent> #topic quantum update
22:04:43 <danwent> lot's of stuff here
22:04:55 <jamesurquhart> danwent: he's not on IM. Does anyone know if he's back from vacation yet?
22:05:10 <danwent> switching from the 'network-service' to 'quantum' project caused some hiccups in merging santhosh's stuff.
22:05:25 <danwent> james: he is pretty good about emailing when he can't make it... but i'm not sure
22:05:54 <danwent> since we had already reveiwed santhosh's test + pep-8 fixes, we pushed that to network-service, then merged it into quantum
22:06:16 <danwent> since no one has yet to review the api-extensions stuff, we are going to have him re-request a new merge to the lp:quantum branch
22:06:21 <danwent> any concerns there?
22:06:30 <danwent> (we'll be talking about extensions more later)
22:06:40 <danwent> (or rather, next)
22:06:44 <salv-orlando> danwent: if you already merged the pep8 fixes into lp:quantum, what I have just approved?
22:07:00 <danwent> I think somik merged after your approval
22:07:01 <danwent> somik?
22:07:08 <somik> merdanwent: yup
22:07:08 <ying> agree for api-extension to start a new request
22:07:18 <ying> thus, we can add comments there
22:07:24 <salv-orlando> ok, I see
22:07:38 <danwent> salv-orlando: you ok with that?
22:07:43 <danwent> the merge
22:08:00 <salv-orlando> danwent: sure, I just thought I approved some other branch by mistake :-)
22:08:05 <danwent> I think it happened just in the last 30 minutes or so.
22:08:10 <danwent> ah, no, same one :)
22:08:14 <danwent> but good to check
22:08:29 <danwent> ying: yes, agreed.  we definitely want someone from Cisco reviewing that branch.
22:08:56 <danwent> shifting to the topic of API extensions in general, it seems like things are still a bit up in the air from the thread that was on the mailing list.
22:09:12 <danwent> https://lists.launchpad.net/openstack/msg02834.html
22:09:58 <danwent> For me, it would be really helpful to have someone work with Jorge and figure out how the code we borrowed from nova maps to the proposal.
22:10:05 <danwent> any takers?
22:10:43 <danwent> mmm... this doesn't bode well for the next topic either.
22:10:48 <salv-orlando> Santosh would be the ideal taker... is he around?
22:11:05 <danwent> he's in india, i think.  Is troy here?
22:11:29 <danwent> Ok, we'll take this one offline.
22:11:42 <Jamey> I think troy and erik are both out today
22:12:01 <danwent> jamey: ah, thanks.
22:12:07 <salv-orlando> oh there's the ONF thing today...
22:12:37 <danwent> next topic: salvatore wanted to bring up whether we need to support a model where multiple tenants can own a single network.
22:12:48 <danwent> I think this also ties into the keystone notion of delegation
22:13:08 <danwent> where one tenant may be able to grant others the ability to attach to a network they own.
22:13:13 <Jamey> own or attach to it?
22:13:13 <carlp> Can you define what owning a network means?
22:13:42 <danwent> Being able to change the API object (the name) create and modify ports, including adding/removing attachements.
22:13:51 <danwent> would be one definition.
22:14:06 <danwent> officially we don't have a definition yet though.
22:14:07 <jamesurquhart> Can I get a use case?
22:14:18 <danwent> salv-orlando?
22:14:21 <salv-orlando> sure.
22:14:36 <carlp> It seems to me that each network should have one owner, and the permissions for attaching to ports should be separated out and delegated
22:15:03 <carlp> For example "I own network BOB, but you can have access to port 12-24 on it"
22:15:04 <salv-orlando> Imagine we have two OUs in a company. Finance and Sales for instance. Finance wants to allow sales instances to attach to their network.
22:15:11 <Jamey> The use case is either B2B apps or community clouds
22:15:21 <salv-orlando> Jamey: right
22:15:58 <danwent> In a logical world, I wonder to what degree they have to be the same network, vs. networks that are just linked.
22:16:10 <midodan> danwent: my question exactly
22:16:24 <salv-orlando> danwent:, midodan: my question too...
22:16:26 <danwent> I don't really have a strong opinion here, but it would be great if someone who does care about this starts flushing out use cases.
22:16:30 <midodan> why would they need to be on the same network segment?
22:16:45 <danwent> (either for or against :) )
22:17:25 <Jamey> Until we offer some sort of L3 routing as a service they would
22:17:27 <jamesurquhart> I don't see the need. A solution looking for a problem, IMHO.
22:17:43 <danwent> I will make the broader point that it would be great if someone wanted to take up the broader work of Quantum API authentication and authorization.
22:17:55 <carlp> I certainly for it, as I can see the use case from a Ceph perspective.  You want access to all the nodes on the backend, so I should grant you access to that network.  Could be solved by routing too, however.
22:18:18 <danwent> Ok, sounds like no one is dying for this, so we can probably table it.
22:18:21 <salv-orlando> Or by bridging as well.
22:18:27 <primeministerp1> why can't we use LACP
22:18:31 <danwent> if you want to take it and run with it, just holler :)
22:18:34 <salv-orlando> I agree with tabling it.
22:18:45 <jamesurquhart> carlp: Right. Should be addressed by L3 abstraction, unless there is an airtight use case for doing differently. Again, IMHO.
22:18:47 <danwent> Is Ryu here?
22:18:52 <primeministerp1> to just connect into the switch
22:18:59 <danwent> or perhaps midodan, do you want to give an update on the nova refactoring?
22:19:44 <danwent> code is here: https://code.launchpad.net/~midokura/nova/network-refactoring
22:20:05 <danwent> ryu was nice enough to start writing a blueprint to share their current plans and get feedback: http://wiki.openstack.org/network-refactoring
22:20:17 <ryu_ishimoto> i can do that, right now, we're looking into two main issues:  1. how to launch a VM with network connectivity, and 2. how to handle libvirt XML generation for various interfaces
22:20:29 <primeministerp1> yes
22:20:35 <primeministerp1> for the network refactoring
22:20:38 <danwent> ryu: great, i think those are two great areas to focus on.
22:20:42 <primeministerp1> can we discuss network interface type
22:20:48 <danwent> sure
22:20:49 <primeministerp1> i.e. emul vs. vert
22:20:52 <primeministerp1> er paravirt
22:21:02 <primeministerp1> as a field option
22:21:07 <primeministerp1> in some hypervisors
22:21:07 <danwent> primeministerp1: can you explain in more detail?
22:21:12 <primeministerp1> you get different functionality
22:21:13 <danwent> is this nova related, or quantum related?
22:21:18 <primeministerp1> based on the network interface type
22:21:21 <midodan> i think that's Nova related
22:21:24 <midodan> hypervisor related
22:21:24 <primeministerp1> believe it's the new bits
22:21:27 <primeministerp1> well
22:21:33 <primeministerp1> sort of
22:21:36 <primeministerp1> for example
22:21:41 <midodan> primeministerp1: i totally agree that should be part of the model
22:21:46 <primeministerp1> on xen or hyperv you can have paravirt or full virt nics
22:22:02 <primeministerp1> one is emulated the other paravirt
22:22:06 <primeministerp1> we need to account for this
22:22:10 <primeministerp1> on hyperv for example
22:22:10 <danwent> so the goal is to have this in the nova database along with other info about the vnic?
22:22:17 <primeministerp1> we can only pxe from a emul device
22:22:25 <primeministerp1> not the enlightened/paravirt
22:22:29 <primeministerp1> so in instances
22:22:32 <danwent> or expose this to customers?
22:22:33 <carlp> KVM also has virtio NICs vs. emulated NICs.  Emulated NICs have greater compatibility, but the virtio NICs have better performance.
22:22:48 <carlp> Customers will need to be able to choose between the two
22:22:54 <primeministerp1> where we want to have a vm pxe into an iscsi initation
22:23:01 <danwent> It definitely makes sense that nova should be able to spin up either type, based on the provider's preference.
22:23:04 <primeministerp1> we need to start w/ the emul interface
22:23:13 <primeministerp1> for the connection
22:23:31 <danwent> and perhaps a provider would expose this to the customer via the nova API (would flavors be used?)
22:24:01 <danwent> I suspect the best way to resolve this would be to work with the nova team.
22:24:16 <midodan> agree
22:24:19 <midodan> this is a Nova issue
22:24:25 <midodan> should be part of the Nova model
22:24:27 <danwent> primeministerp1: does that make sense to you?
22:24:31 <primeministerp1> awesome guys
22:24:33 <primeministerp1> sounds good to me
22:24:37 <danwent> great.
22:24:38 <primeministerp1> as long as we address it
22:25:12 <SumitNaiksatam> ryu: thanks for starting the nova-refactoring blueprint
22:25:24 <danwent> ok, ryu, just wanted to give you a heads up that we'll be pulling the network-refactoring branch and starting to prototype against it.
22:25:31 <SumitNaiksatam> is there any progress on "TODO: Decide on how compute communicates with Quantum"
22:25:37 <danwent> Sumit, it would be great if you could prototype your stuff against it too.
22:25:41 <ryu_ishimoto> SumitNaiksatam: no problem, still need to update it quite a bit
22:25:57 <SumitNaiksatam> ryu: thanks
22:26:06 <danwent> ryu: yes, the code has a simple example of passing an "interface binding" to something that could be quantum.
22:26:12 <SumitNaiksatam> danwent: definitely can start prototyping
22:26:17 <danwent> good place to start
22:26:26 <danwent> anything else on nova refactoring?
22:26:31 <salv-orlando> danwent: did we put aside only the idea of shared network, or authN/authZ as well?
22:26:32 <SumitNaiksatam> however don't want to go in a completely different direction from what you guys are thinking
22:27:07 <danwent> salv-orlando:  I believe we tabled it, based on lack of interest.  If anyone wants to drive exploring this model more, they're more than welcome to
22:27:24 <danwent> salv-orlando: misunderstood
22:27:26 <danwent> sorry,
22:27:27 <ryu_ishimoto> danwent: that's it but let's keep the discussion going offline to iron out the remaining issues.  I will keep updating the wiki
22:27:35 <danwent> ryu: great, thanks.
22:27:54 <danwent> salv-orlando:  I agree, getting someone to spend time on even the basic authn/authz stuff is important.
22:28:02 <danwent> any volunteers?
22:28:04 <salv-orlando> danwent: definitely.
22:28:20 <danwent> right now, quantum really only supports a "single tenant" from an auth perspective
22:28:22 <salv-orlando> I can volunteer for that. As I've done the basic API work
22:28:36 <danwent> all right !
22:28:41 <danwent> that would be great.
22:28:54 <salv-orlando> it makes sense I do some work on making sure the api has authN/authZ as well.
22:29:14 <salv-orlando> I will start by preparing a blueprint and getting in touch with Ziad (Keystone)
22:29:17 <danwent> please take ownership of the blueprint.  Let us know how we can help out.
22:29:25 <danwent> salv-orlando: perfect
22:29:31 <Jamey> Not single tenant but single owner
22:29:42 <danwent> Jamey: yes
22:29:53 <salv-orlando> Jamey: 1 network, 1 owner
22:30:05 <salv-orlando> but possibly n users, as it happens for public networks
22:30:06 <danwent> Jamey: you can have multiple tenant strings in the URI, that is correct.
22:30:16 <danwent> I think Jamey is talking about what exists today
22:30:22 <danwent> you can technically create multiple tenants
22:30:28 <danwent> but there is no auth
22:30:49 <Jamey> I'm thinking of shared networks like the public Internet network
22:31:06 <Jamey> Or management net
22:31:08 <danwent> ah, i get it
22:31:25 <salv-orlando> Jamey: these kinds of networks are the ones for which I think we need to have both auhN and authZ
22:31:38 <danwent> Yes Jamey, VIFs from multiple tenants may be on a network, but a single auth entity controls the whole network.
22:32:02 <danwent> controls -> owns
22:32:09 <salv-orlando> as we have two 2 roles: the owner of the network, which set up the network layout, and the users of the network, which plug interfaces in its ports
22:32:10 <danwent> (using our terminology from before).
22:32:10 <Jamey> That's what I meant by single owner
22:32:51 <danwent> lots of interesting things to explore here.  look forward to seeing the blueprint :)
22:33:11 <salv-orlando> yet, better move to the next topic now, we are already halfway through the meeting!
22:33:13 <danwent> moving on to system test + api validation tests.
22:33:35 <danwent> we're going to start doing some system testing, but the more people who want to pitch in, the merrier.
22:33:49 <danwent> if you have thoughts on this, let me know.
22:33:56 <carlp> danwent: are you setting up a jenkins for that?
22:34:05 <danwent> I will be updating the blueprint for this.
22:34:24 <danwent> https://blueprints.launchpad.net/quantum/+spec/quantum-system-test
22:34:32 <danwent> carlp: haven't talked about that yet.
22:35:01 <mtaylor> I would love it if you'd integrate with the current jenkins instead of setting up a whole new one ...
22:35:07 <danwent> I think dendrobates was talking to someone about integration into that infrastructure
22:35:12 <mtaylor> so feel free to ping me whenever
22:35:19 <danwent> this is partially tied to our status as an incubated project
22:35:29 <danwent> mtaylor: thanks.  will do.
22:35:47 * mtaylor wants to make sure that we don't wind up with multiple parallel sets of infrastructure - because that's just fail
22:35:57 <danwent> I need to explore this in more detail.  Please sign up on the blueprint if you're looking to get involved.
22:36:05 <danwent> and if you want to drive, by all means :)
22:36:24 <danwent> that last message was to everyone, not mtaylor
22:36:32 <danwent> mtaylor: agreed
22:36:41 <mtaylor> well - I want to drive the infrastructure part :)
22:36:59 <danwent> great.  can you add yourself to the blueprint?
22:37:07 <danwent> as a watcher?
22:37:16 <danwent> or owner, if you want :P
22:37:24 <mtaylor> done
22:37:28 <danwent> thx
22:38:13 <danwent> Ok, and the non-system test part of this is that I'd like to review our API unit tests and make sure that we have unit tests that cover all of the corner cases documented in the API spec
22:38:26 <danwent> http://wiki.openstack.org/QuantumAPISpec
22:38:38 <salv-orlando> ok, that's another call for me :-)
22:38:51 <danwent> awesome, i don't even have to ask :)
22:39:05 <bhall> salv-orlando: I'm glad to help with those as well; we can divide it up if you want
22:39:22 <salv-orlando> bhall: sure, we can talk about this offline
22:39:27 <bhall> sounds good
22:40:12 <danwent> and one final note on quantum, i'm looking for guinea pigs who want to test out some docs for how to setup quantum + the OVS plugin on ubuntu.  They're not quite done, but I will send them your way if you're interested.
22:40:26 <carlp> danwent: Sign me up!
22:40:27 <danwent> would like to get some test eyes on them before sending it out more broadly.
22:40:35 <danwent> great carlp
22:40:45 <carlp> I have your docs from a few weeks ago, but haven been way to busy to look at them until now
22:40:45 <danwent> ok, anything else for quantum?
22:41:08 <danwent> carlp: have done more work since then.  am hoping to automate a lot of the setup.
22:41:17 <salv-orlando> on the OVS plugin: do we support multiple servers at the moment?
22:41:17 <carlp> danwent: awesome
22:41:26 <danwent> salv-orlando: yup
22:41:46 <danwent> though i've only tested with a few.
22:42:11 <salv-orlando> danwent: I ran the agent plugin but the integration bridge did not pick any physical interface....
22:42:30 <danwent> yes, as you probably figured out, we hadn't actually used that setup script yet.
22:42:40 <danwent> I just configured it to use an external bridge.
22:42:50 <salv-orlando> ok so i did the right thing by adding one with ovs-vsctl...
22:43:01 <danwent> I have a couple of OVS plugin bugfixes queued up as well.
22:43:15 <danwent> hopefully those will get merged soon though.  Might want to hold off until then :)
22:43:26 <danwent> salv-orlando: yup, exactly
22:43:52 <danwent> salv-orlando: can sync up offline if you need more details.
22:43:57 <salv-orlando> danwent: sure... maybe it would be better to post those bugs on launchpad, if you haven't already done so. This way, we will be aware of this
22:44:22 <danwent> yeah, agreed :)
22:44:38 <danwent> anyone from melange or donabe around to provide an update?
22:45:27 <carlp> I don't have any specific update for Melange
22:45:32 <danwent> #topic open-discussion
22:45:40 <salv-orlando> webex for next meeting?
22:46:02 <danwent> since rick and ram are not here, we'll probably delay the webex topic.
22:46:04 <danwent> anything else?
22:46:12 <carlp> I was curious about the Melange + Quantum integration topic, any ideas what that was about?
22:46:29 <danwent> carlp: yes, agreed.
22:46:41 <danwent> I was hoping to get an update on the status of a melange alpha.
22:47:12 <danwent> I think the high-level plan now is that melange and quantum will be independent "building blocks" that can be used directly via the APIs or by orchtestration components
22:47:23 <carlp> Me too :)  I know Troy and his team have been working on the IP management part.  Once that was done we were going to dive into the discovery integration.
22:47:31 <danwent> melange will likely have the ability to store a quantum network ID associated with a subnet
22:47:48 <danwent> Ok, let's pester troy via email :)
22:47:58 <carlp> Sounds like a plan.
22:48:03 <danwent> anything else?
22:48:21 <danwent> #endmeeting