22:08:31 <dendrobates> #startmeeting
22:08:32 <openstack> Meeting started Tue Jun  7 22:08:31 2011 UTC.  The chair is dendrobates. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:08:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
22:08:43 <dendrobates> #topic project update
22:09:00 <dendrobates> I believe some code has been pushed by Rackspace
22:09:07 <dendrobates> Is anyone here to talk about it?
22:09:15 <danwent> to what project?
22:09:24 <danwent> is this the quantum extensions stuff?
22:09:29 <dendrobates> danwent: the quantum stuff
22:09:30 <dendrobates> yes
22:09:30 <somik> I just saw a merge proposal for extensions
22:09:42 <danwent> Ok, was going to bring that up in the quantum section.
22:09:55 <danwent> or perhaps we're there already :) ?
22:10:01 <dendrobates> sure, go ahead
22:10:06 <danwent> cool
22:10:15 <danwent> still need to update all blueprints, but a basic experimental version of quantum is ready to be poked at:  https://code.launchpad.net/~netstack/network-service/quantum
22:10:20 <danwent> this does not include the extensions.
22:10:31 <danwent> includes functioning API, data model, sample plugins, and CLI.  OVS plugin can be run end-to-end on XenServer.  If you just want to run API, data model, and play with CLI, you can just install the service standalone.
22:10:48 <danwent> please see the README
22:10:51 <danwent> no packaging for now.
22:11:01 <danwent> no tenant auth.  no GUI
22:11:10 <danwent> anyone who would like to see such things, let me know ;)
22:11:14 <salv-orlando> do we have any form of integration with nova? or a tweaked version of nova?
22:11:35 <danwent> Running with OVS plugin doesn't require a tweaked version of nova, standalone nova will work.
22:11:43 <danwent> I think the README for the OVS plugin describes that.
22:12:00 <salv-orlando> good
22:12:02 <danwent> working with libvirt will require some tweaks.
22:12:02 <carlp> Can the OVS plugin be run on KVM?
22:12:17 <danwent> to nova, we'll probably post a nova branch to do that soon.
22:12:19 <carlp> danwent: can we talk about that later?
22:12:25 <danwent> carlp: sure
22:12:31 <carlp> danwent: I'm interested to see what I can help contribute
22:12:45 <danwent> carlp: basic point is that you need to generate the libvirt XML a little differently.
22:12:49 <danwent> carlp: sounds good.
22:13:19 <dendrobates> carlp: Cisco is interested in libvirt/kvm support as well
22:13:30 <danwent> What dendrobates was mentioning is that there was a recent merge request from santhosh: https://code.launchpad.net/~santhom/network-service/quantum_framework/+merge/63711
22:13:50 <danwent> this arrived this morning.  I don't now if anyone has had time to take a look yet (we haven't).
22:13:52 <dendrobates> is troytoman around?
22:13:53 <salv-orlando> I had a quick look at that
22:13:57 <carlp> dendrobates: good to know
22:14:19 <danwent> it apparently includes code from nova on extensions, plus some unit test improvements, plus some pep8 fixes.
22:14:26 <dendrobates> I looked at it, and am gettng a few other cisco devs on it.
22:14:30 <danwent> I suspect most of the interest will be with respect to the exstensions.
22:14:36 <danwent> dendrobates: great.
22:14:52 <salv-orlando> yeah the extension model allows for defining new resources, new methods and new methods on existing resources
22:14:56 <danwent> if the extension stuff is contentious, we'll probably try to split it out from the unit test + pep8 stuff.
22:15:01 <danwent> as that seems pretty vanilla.
22:15:21 <dendrobates> danwent: that is a good idea
22:15:27 <danwent> I know other people had registered interest in how extensions work, so I want to make sure there's time for review.
22:15:43 <danwent> is santhosh around?
22:16:11 <dendrobates> hello rackspace?
22:16:17 <danwent> ok, i'll assume not, troy or any other rackers?
22:16:48 <dendrobates> we will have to follow up with them in email.
22:16:56 <danwent> agreed.
22:16:59 <ying> danwent: yes, I'm interested. Just briefly looked it today and will follup with emails
22:17:13 <danwent> ying: I figured :)  sounds good.
22:17:32 <danwent> in other news, I'm drafting a "what is quantum" doc based on http://www.slideshare.net/danwent/quantum-diablo-summary .  Goal is to get across key points to new people joining the project who were not at the Diablo summit.
22:17:55 <danwent> plan to have something by end of this week.
22:18:15 <danwent> Overall, quantum should be in a place were other people can start playing with it.
22:18:33 <danwent> things like donabe or other services should be able to start developing against it.
22:18:41 <dendrobates> great
22:18:43 <salv-orlando> danwent: the doc would be great. let me know if you want help preparing/reviewing it
22:18:46 <danwent> we still need more effort around system test, docs, etc.
22:19:05 <danwent> salv: yes, definitely, everyone should collaborate on it.  agreed.
22:19:10 <salv-orlando> and since we had the first merge proposal I would like to set aside some time to discuss the review process.
22:19:57 <dendrobates> salv-orlando: sure, Dan are you done?  We could do it now.
22:20:02 <salv-orlando> * current trunk has pep8 errors...
22:20:16 <danwent> salv:  Yes, agreed.
22:20:48 <dendrobates> #topic Netstack review process
22:20:53 <danwent> salv: on pep8: yes, santhosh fixed some of those in his branch, so we did not want to introduce merge conflicts by fixing them.  I'd rather have him split it out from the extension stuff and merge that.
22:21:16 <danwent> dendrobates: yes, done :)
22:21:21 <dendrobates> Is there any reason that we should not follow the openstack core processes?
22:21:54 <danwent> I think this just comes down to defining the "core" devs.
22:21:55 <salv-orlando> not from me. I think we just need to define the "netstack-core" now
22:22:09 <danwent> but i don't see a reason to diverge from opestack common practice.
22:22:17 <dendrobates> I recieved emails from only 2 people about core dev status
22:22:53 <dendrobates> Why don't I draft a core-team list and we can review it at the next meeting
22:23:01 <dendrobates> before I create it
22:23:23 <salv-orlando> dendrobates: agreed
22:23:28 <danwent> I'm fine with that.
22:23:43 <dendrobates> if anyone wants to be sure to be on it, please send me an email
22:24:01 <salv-orlando> Is there a "python reviews for dummies" manual available somewhere :-)
22:24:03 <salv-orlando> ?
22:24:26 <somik> sure.. we havesome code and as people start creating patches and submitting merge proposals we can expand the core.
22:24:36 <danwent> dendorbates: as part of that, can you put together pointers to the materials used by nova (style guides, etc?)
22:24:41 <troytoman> sorry guys ... i'm a bit late ... firefighting day for me!
22:24:42 <dendrobates> It is just one line.  " be fascist about pep8"
22:24:47 <danwent> :)
22:24:52 <dendrobates> danwent: yes I can
22:25:29 <alekibango> dendrobates: fascism = merge of corporations + government.. we maybe should use the word as it deserve
22:25:34 <dendrobates> one place tha tnova has fallen down, IMHO , is with naming standards.  I suggest we take a stab at that too
22:25:52 <danwent> dendrobates: in what sense?
22:25:57 <danwent> variables?
22:26:03 <dendrobates> danwent: yes
22:26:06 <danwent> k
22:26:33 <dendrobates> the goal is ease of understanding and a quick path to contribution
22:27:18 <danwent> ok, open discuss?
22:27:32 <dendrobates> #topic open discussion
22:28:10 <salv-orlando> since troy is here now, we can probably have an update on melange
22:28:49 <dendrobates> the dmtf has some standards for defining  network parameters that is being included with OVF 2.0
22:29:13 <troytoman> sure. We have been cleaning up our first pass and looking at integration options. we hope to have something we can merge into Nova in the next couple of weeks.
22:29:16 <dendrobates> If they are good, I suggest we standardize on them
22:29:40 <danwent> dendrobates: is there a link available yet?  I'm unfamiliar with this.
22:29:58 <troytoman> Otherwise, we are waiting for multi-nic and network refactoring to figure out how to integrate melange into Nova
22:30:08 <dendrobates> danwent: It might still be in the working group
22:30:13 <somik> I think OVF 2.0 is still under discussion
22:30:33 <danwent> dendrobates: should we consider trying to be part of the discussion?
22:31:01 <dendrobates> danwent: I think it is too late, but we should at least look at it and comment
22:31:08 <danwent> k
22:31:16 <salv-orlando> troytoman: I was looking at the IPAM protocol proposal on github.
22:31:23 <carlp> troytoman: Let me know when/if you would like us to look that over too
22:31:38 <Tv> salv-orlando: url please?
22:31:44 <salv-orlando> Does this protocol replaces normal DHCP discovery/request/offer process?
22:33:00 <salv-orlando> tv: I think is this: https://github.com/tv42/melange-discovery/blob/master/melange-discovery.rst
22:33:02 <troytoman> slv-orlando: the github proposal on the protocol is being done by tv
22:33:14 <salv-orlando> sorry I'm not at my work laptop
22:33:25 <troytoman> my team has been focused on the address tracking part
22:33:36 <Tv> ok just wanted to know if that's what you're talking about
22:33:41 <salv-orlando> troytoman: I see. Apologies for misunderstanding...
22:33:45 <Tv> salv-orlando: that is intended to look like dhcp to the vm
22:33:49 <troytoman> carlp: when we have the integration proposal together, I'll send it out more broadly. probably before end of the week
22:33:59 <carlp> troytoman: cool, thanks
22:34:29 <Tv> salv-orlando: while delegating all the decision making to the melange ipam
22:35:07 <salv-orlando> tv: that means, for instance, VM sends DHCP request, and it is then translated into Melange IPAM message?
22:35:14 <Tv> salv-orlando: roughly, yes
22:35:18 <danwent> one concern I had with the proposal is that it would seem to prevent a VM on a private network from running its own DHCP servers, is that true?
22:35:34 <Tv> danwent: private networks are basically L2 without IPAM services, so no
22:35:35 <danwent> though it seems like one valid approach if you did not care about that use case.
22:35:50 <Tv> danwent: i'd expect those interfaces are not subject to this processing at all
22:36:11 <Tv> danwent: my thinking is, it's the customer's L2, they run DHCP if they want etc, *nothing* should touch the packets
22:36:13 <danwent> OK, so this would be enabled only for certain interfaces.
22:36:22 <Tv> danwent: including the host firewall
22:36:37 <danwent> Ok, that seems reasonable :)
22:36:42 <Tv> danwent: more like, your VPC L2 networks are separate vifs
22:37:09 <Tv> (want to run non-IP in your private L2? go right ahead!)
22:37:40 <Tv> i guess the spec could talk of VPCs
22:38:14 <salv-orlando> tv: but I can still run melange ipam on my L2 network if I don't want to have my DHCP or some non-ip network... is that correct?
22:38:33 <Tv> salv-orlando: i haven't considered that use case
22:38:42 <Tv> salv-orlando: that would be.. "interesting" for the ipam component, i guess
22:39:08 <Tv> salv-orlando: like, completely different from its primary purpose of managing the outside-visible addresses
22:39:20 <Tv> salv-orlando: i'd rather ignore that for now, say that you manage the LAN as you wish
22:39:29 <danwent> Yeah, I think you basically need to be able to enable it or disable it for certain interfaces.  I'm not sure nova will have a notion of what is "private" vs. "public".
22:39:30 <salv-orlando> tv: agreed.
22:39:47 <danwent> so is IPAM only about managing public IPs?
22:40:07 <Tv> danwent: i think of VPCs as something the cloud provider should not touch, at all
22:40:13 <Tv> there may be other opinions on that
22:40:32 <danwent> Tv: sure.  don't want to derail the who meeting on this.  we can move this offline :)
22:40:39 <Tv> danwent: but i wouldn't say IPAM is only about "public" IPs.. as in, it would be useful for managing 10.x.x.x too
22:40:48 <Tv> danwent: yes
22:40:51 <danwent> Tv: agreed.
22:41:02 <salv-orlando> I think as a consumer of cloud services I might enjoy a service provided by the CSP to manage IPs in my own network...
22:41:35 <Tv> salv-orlando: sure, i'm just inclined to postpone that; the code should be reusable, but i'd rather focus on one thing at a time
22:41:59 <salv-orlando> tv: I agree with you. I don't want to push this :-)
22:42:19 <troytoman> salv-orlando: not in scope for the initial release. but, it could evolve that way
22:42:27 <Tv> and that brings harder concepts like realms (whose 10.x.x.x are you talking about) etc
22:42:46 <troytoman> also, we are setting it up to be able to track both private and public IPs. Also, track NAT relationships between the two
22:42:50 <Tv> it'd be nice to find out that that wasn't ultimately needed at all ;)
22:44:12 <danwent> ok, any other open discussion?
22:44:24 <dendrobates> not from me
22:44:28 <salv-orlando> A couple of bits on Quantum API:
22:44:28 <Tv> i have a question about quantum
22:44:36 * Tv waits for salv-orlando
22:44:37 <salv-orlando> go ahead tv
22:44:37 <danwent> Tv: shoot
22:44:41 <Tv> hah!
22:44:51 <Tv> ok so.. vlans?
22:45:03 <salv-orlando> I registered a blueprint today
22:45:11 <Tv> will quantum have other means of identifying networks on the physical network that connects the hypervisor hosts than vlans?
22:45:22 <danwent> Tv: definitely.
22:45:34 <Tv> danwent: i'd be interested in more detail
22:45:39 <danwent> Tv:  plugins should be able to use any type of mechanism for L2 segmentation.
22:45:57 <danwent> Tv: openvswitch for example can do cool things with L2-in-L3 tunneling.
22:46:14 <danwent> Tv: happy to talk more about this, but don't want to commandeer the meeting.
22:46:20 <Tv> i see just one openvswitch plugin that seems to have vlans pretty tied into the core of it
22:46:29 <ramd> salv: Are you planning the "VLAN manager port" as default-plugin?
22:46:34 <Tv> danwent: i'd very much like to know more, after the meeting
22:46:56 <danwent> Tv: yes, for the experimental plugin we just wanted to get something out the door, vlans are by far the easiest thing.
22:46:57 <salv-orlando> ramd: no I was just thinking it would be good to have it
22:48:03 <danwent> Tv: shoot me an email and we can chat.
22:48:10 <ramd> sure. I agree with dan; for quantum api level physical segmentation scheme could be anything
22:48:17 <ramd> for starters it happens to be vlan
22:48:26 <danwent> that was the whole goal of having it be a logical API.
22:48:35 <danwent> any technology could be behind it.
22:48:47 <salv-orlando> I have registered a blueprint for a porting to quantum of the 'traditional' nova's vlan manager over linux bridge.
22:49:10 <salv-orlando> I thought it would be good to have it as well.
22:49:22 <ramd> salv: +1
22:50:00 <ramd> In the design summit we also talked about retaining current network-manager as well
22:50:25 <dendrobates> anything else?
22:50:26 <Tv> danwent: my only concern is seeing "openvswitch" plugin be vlan.. should that be "openvswitch-vlan", or should it have plugins below it, or what?
22:51:19 <danwent> Tv: my guess is that we will make the openvswitch plugin be able to handle both vlans and other segmentation mechanisms
22:51:54 <danwent> Tv: that is, config options rather than separate plugins.
22:52:16 <dendrobates> Tv: do you mean should openvswitch own the vlan namespace?
22:52:33 <Tv> dendrobates: i don't mean it should; i mean that what it looks like now
22:52:58 <danwent> Tv: you'll need some plugin logic that decide who owns vlans.
22:53:01 <dendrobates> but that multiple plugins could perform that function
22:53:05 <Tv> danwent: ok so code in the most essential alternative implementations, that'll work
22:53:18 <somik> dendrobates: correct
22:53:26 <Tv> dendrobates: no you're thinking this kinda the other way
22:53:34 <Tv> dendrobates: i want to have openvswitch-but-not-vlan
22:53:39 <dendrobates> ah
22:53:54 <danwent> Tv: people can definitely write other plugins that use openvswitch as well.
22:54:08 <danwent> or they can extend the openvswitch plugin, whichever makes sense.
22:54:46 <danwent> Some people have already contacted us about building a plugin that extends the OVS plugin as a python class.
22:55:06 <danwent> you can also introduce new things into the data model, etc.  code sharing is a beautiful thing :)
22:55:15 <Tv> danwent: hence my question on whether there's code there that should be shared across openvswitch-vlan and openvswitch-tunnel, and your answer of just putting the two implementations in the same plugin
22:55:46 <danwent> Tv: K.  I think either approach would work.  Happy to chat more with you.
22:55:48 <Tv> but yeah, good to hear that the non-vlan case is still in general awareness
22:56:18 <danwent> Tv: k
22:56:59 <dendrobates> I have another question, but it can wait until next time
22:57:15 <danwent> wow, 4pm already :)
22:57:22 <salv-orlando> I too have a question on Quantum API but will send an email
22:57:30 <dendrobates> 6pm for some and later for others
22:57:35 <danwent> haha :)
22:57:39 <markvoelker> 7 for us east coasters =)
22:57:41 <salv-orlando> make it midnight for me :-)
22:57:45 <dendrobates> #endmeeting