21:00:27 <danwent> #startmeeting quantum
21:00:28 <openstack> Meeting started Mon Sep 17 21:00:27 2012 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:29 <danwent> hi folks
21:00:30 <openstack> The meeting name has been set to 'quantum'
21:00:36 <markmcclain> hi
21:00:42 <amotoki> hello
21:01:08 <zhuadl> hi
21:01:12 <mnewby> hi
21:01:23 <arosen1> hi
21:01:29 <SumitNaiksatam> Hi All!
21:01:31 <markvoelker> 0/
21:01:44 <danwent> #link agenda: http://wiki.openstack.org/Network/Meetings
21:01:58 <danwent> main focus is on discussing issues that have popped up since RC1 and docs
21:02:15 <nati_ueno> Hi
21:02:17 <garyk> hi
21:02:24 <danwent> https://bugs.launchpad.net/quantum/+bugs?field.tag=folsom-rc-potential
21:02:30 <danwent> these are the issues we're tracking
21:03:06 <danwent> plus a special security sensitive bug, though I think we don't need to be too secretive about it, as the software was not yet released.
21:03:47 <danwent> so, let's go through the list of bugs that are not fix-committed and make sure we have an action plan on getting them taken care of
21:04:16 <danwent> my operating assumtion is that anything that is fix-committed already and tagged as folsom-rc-potential will go into an RC2
21:04:33 <danwent> though we will need thierry's approval on that.  many of the issues are been low risk
21:04:46 <danwent> https://bugs.launchpad.net/quantum/+bug/1050512
21:04:47 <uvirtbot> Launchpad bug 1050512 in quantum "qr port of br-int is not set vlan after I restart machine and then restart quantum components" [Critical,Confirmed]
21:05:30 <danwent> looks like yong is not here, but i have seen this issue as well and without needing to restart anything.
21:06:06 <danwent> my best guess is some RPC messages getting lost or such.  We need to repro this and track it down though.
21:07:02 <garyk> i will try and reproduce
21:07:14 <danwent> I suspect the issue is with the agent, regardless of port type, as in the past I saw something similar with a VM.
21:07:43 <danwent> garyk: thanks.  I will work to repro as well.  let's make sure we update the bug if we find something interesting.  to me this is probably the top priority outstanding issue, so having multiple peole looking at it is a good idea.
21:07:56 <garyk> ok
21:08:28 <danwent> https://bugs.launchpad.net/quantum/+bug/1051679
21:08:29 <uvirtbot> Launchpad bug 1051679 in quantum "Error running ip netns command with l3-agent" [High,Confirmed]
21:09:17 <danwent> this one seems specific to the l3 stuff.  not clear if changing the bridge name is required to trigger this or not.. I don't see how it would be related.
21:09:28 <garyk> i think that this is lacking information (as are most of the bugs opened)
21:09:49 <danwent> i'll assign this one to me, as endre contacted me about it, and i'm familiar with the l3 code
21:10:00 <danwent> garyk: you ok if I assign the previous one to you?
21:10:08 <garyk> sure, no problem
21:10:18 <danwent> (trying to get assignees on everything… even if others will be helping as well)
21:10:49 <danwent> https://bugs.launchpad.net/quantum/+bug/1051744
21:10:50 <uvirtbot> Launchpad bug 1051744 in quantum "remove default value of 'local_ip' of 10.0.0.3 in ovs_quantum_plugin.ini " [Medium,Confirmed]
21:11:05 <danwent> this is pretty minor, config only, I just found it confusing as I was going through the setup, and thought others might as well.
21:11:21 <danwent> we won't stop a release for this, but if someone has a few minutes to clean this up, it would be nice
21:11:29 <markmcclain> I'll clean it up
21:11:34 <danwent> markmcclain: thanks
21:11:50 <danwent> https://bugs.launchpad.net/quantum/+bug/1051822
21:11:51 <uvirtbot> Launchpad bug 1051822 in quantum "use admin context when confirming that floating_Ip can reach fixed_ip" [High,In progress]
21:12:00 <danwent> i have a patch proposed for this one already.  one line code change.
21:12:26 <danwent> don't think this needs discussion unless others have concerns
21:12:35 <danwent> https://bugs.launchpad.net/quantum/+bug/1051842
21:12:36 <uvirtbot> Launchpad bug 1051842 in quantum "l3-agent should nat metadata requests even if no gateway exists" [High,In progress]
21:12:53 <danwent> this patch is larger than I would like, though its pretty much just moving code around.
21:13:39 <mnewby> danwent: I have a question
21:13:41 <danwent> we have decent test "coverage" of the agent in the sense that the tests invoke most lines of code, but we don't have unit tests that really verify correctness, so its a bit iffy
21:14:01 <danwent> there are also larger issues around metadata anyway, which might be what mnewby is bringing up :)
21:14:05 <danwent> mnewby: yes :)
21:14:33 <mnewby> danwent: I don't mean to sidetrack, so maybe it can wait, but I can't see how quantum can be used with nova unless the metadata service can identity an instance.
21:14:56 <mnewby> danwent: Later in the meeting?
21:15:20 <danwent> mnewby: well, I think its related to whether we need to make the change above, or other related changes, so I'm fine discussing it now
21:15:57 <mnewby> I've implemented a preliminary patch that would return the instance id only if only one instance was associated with a given ip.
21:16:05 <danwent> mnewby: i think that really depends on whether deployments use metadata
21:16:09 <mnewby> From your comment, though, it sounds like that won't be secure.
21:16:27 <mnewby> Revealing my ignorance, but how are instances configured otherwise?
21:16:54 <mnewby> Does quantum prevent overlapping ip ranges if namespaces are disabled?
21:16:57 <danwent> mnewby: configured in what sense?  most get their IP address from DHCP.
21:17:17 <mnewby> danwent: aren't initial passwords configured by metadata service?
21:17:25 <danwent> mnewby: no, this was something we discussed, but did not implement.  having something like that would make me feel better about allowing a mode where nova assumed no overlap
21:18:05 <mnewby> danwent: Ok, so if I submit a nova patch that presumes no overlap, is there a way for nova to detect that quantum is configured in that way?
21:18:18 <mnewby> Like some kind of 'capabilities' query?
21:18:28 <danwent> mnewby: perhaps in some circumstances….  to be honest i'm not sure.
21:18:52 <danwent> mnewby: we coud expose it via an extension… kind of clunky, but it would work.
21:19:07 <mnewby> danwent: I think it'd be better to have something working than not...
21:19:11 <danwent> (i.e., an extension that doesn't really have API calls)
21:19:22 <danwent> mnewby: I agree.  I had thought that the "assume no overlap" case was working.
21:19:37 <danwent> (albiet without good confirmation)
21:19:56 <mnewby> danwent: 'case' in the sense of nova being able to identify an instance by ip?
21:20:23 <danwent> carlp, markmcclain: any input here, as I know you two were thinking about ways to extend metadata to work with overlapping IPs, which is one step harder.
21:20:53 <danwent> mnewby: yes, as in "assuming quantum only ever responds with a single port for a given IP"
21:20:56 <markmcclain> we wanted to proxy and add  header with project_id
21:21:06 <mnewby> That's what I was thinking, too.
21:21:32 <mnewby> Does the metadata service already support a secure (aka admin-auth'd) channel?
21:21:37 <danwent> why project_id rather than network_id?  It seems like even a single tenant_id could have overlapping IPs (I know we do this internally)
21:21:55 <markmcclain> good point
21:21:55 <mnewby> Yeah, network id would probably make more sense.
21:22:08 <danwent> mnewby: I think its just a normal webserver, which access the nova DB and RPC on the backend.
21:22:21 <danwent> ok, so I don't want to get too sidetracked
21:22:39 <mnewby> danwent: then we'd have to provide an alternate channel to ensure that only authorized clients could pass network id
21:22:41 <danwent> I think we agree this is something we want to tackle for Folsom, at least in terms of the "no overlap" case
21:22:51 <mnewby> danwent: agreed.
21:23:33 <danwent> mnewby: which bug do you want to use the track this?
21:23:48 <mnewby> danwent: it should probably have a new one.
21:23:56 <danwent> we had the existing one for overlapping, but the issue you found is even more fundemental
21:24:10 <mnewby> danwent: I can file a new bug
21:24:14 <danwent> agreed.  especially since there's a decent chance that one will be fixed in folsom, but not the other
21:24:30 <danwent> (ok, please create in the background, and post it on IRC when you're done)
21:25:14 <mnewby> Will do
21:25:27 <danwent> ok, so that's a clear item to track.  are there any other known issues that should be filed and targeted with folsom-rc-potential?
21:25:50 <arosen1> The nvp plugin is missing the dhcp rpc handler but I have  a patch for that I'll put up for review shortly
21:26:01 <danwent> arosen1: how big of a patch?
21:26:29 <arosen1> danwent:  15 lines or so. It's basically the same code that's in the ovs plugin
21:26:42 <danwent> ah, ok.  that should be straight-forward.
21:26:57 <danwent> any other outstanding issues before we talk about timing of RC2?
21:27:36 <danwent> #topic quantum rc2 timing
21:27:52 <danwent> so, there's a fedora test day tomorrow that i'm hoping we'll get some good feedback from
21:28:02 <garyk> is there a version open that we can cherry pick?
21:28:14 <danwent> yeah, that's what I wanted to ask.
21:28:33 <danwent> essentially, the tip of master is what we expect to be RC2, once we close a few more bugs
21:28:42 <garyk> ok.
21:28:47 <garyk> re fedora test day - https://fedoraproject.org/wiki/Test_Day:2012-09-18_OpenStack
21:28:50 <danwent> (I dont' believe there have been any commits that are non-RC focused, but I'd have to confirm)
21:29:35 <danwent> this is great, as we really need people testing from packages, not devstack.
21:29:51 <danwent> fedora packages seem to be in good shape.
21:30:14 <danwent> ubuntu packages have seen significant improvements.  I got a setup working over the weekend with them, though there are still some items to work out.
21:30:26 <garyk> yes, they are. we have found one or 2 minor issues but things are looking pretty good
21:31:03 <danwent> garyk: so are you guys ok with there not being an official RC2 until after the test day, or would you prefer that we try to push something out (at this point, not even sure it would be feasible)
21:31:30 <markmcclain> I think we should wait after test day otherwise we're likely to need an rc3
21:31:54 <danwent> that would be my preference, but wanted to get gary's thoughts
21:31:54 <mnewby> danwent: https://bugs.launchpad.net/nova/+bug/1052196
21:31:55 <garyk> yes, i guess that we can wait. at the moment the only critical issue we have is with reboot and the l3-agent. you have fixed this. i'll document on the wiki.
21:31:55 <uvirtbot> Launchpad bug 1052196 in nova "The metadata service cannot identity an instance when using the Quantum v2 network API" [Undecided,New]
21:31:56 <SumitNaiksatam> agree
21:32:12 <danwent> mnewby: thanks!
21:32:33 <danwent> btw, I added the folsom-rc-potential tag
21:32:48 <danwent> we need to be very vigilent about triaging bugs with that tag
21:33:19 <danwent> and once we actually release folsom, we will have an equivalent tag to identify whether something should be considered for a stable/folsom backport
21:33:37 <danwent> garyk: will bugs from the test day just be filed during the course of the day?
21:33:56 <garyk> danwent: yes, i hope so.
21:34:36 <garyk> danwent: i hope that we will get some decent coverage and hopefully get a good picture of the current status.
21:34:39 <danwent> Ok, so at the end of the day tuesday, let's send out a note with any remaining issues we think are RC-relevant
21:34:59 <danwent> hopefully we can wrap up those issues quickly and have an RC2 on wed, but we don't know until we see what is filed on tuesday.
21:35:00 <amotoki> backporting to milestone-propsoed is a possible soultuion for it.
21:35:31 <danwent> amotoki: yes, anything that is in RC2 will effectively be backported to milestone-proposed
21:35:49 <danwent> ok, any concerns with that plan?
21:36:22 <garyk> danwent: douns good
21:36:26 <garyk> sounds
21:36:44 <danwent> ok, anything else on RC2 before we shift to talking about docs
21:37:05 <danwent> #topic quantum folsom docs
21:37:14 <danwent> so, first off, API doc is now published: http://docs.openstack.org/api/openstack-network/2.0/content/
21:37:23 <danwent> thanks to salv-orlando and team for all the amazing work on that.
21:37:39 <garyk> salv-orlando: great work on this. thanks!
21:38:02 <danwent> admin guide continues to grow, but still needs some TLC: https://docs.google.com/document/d/1xdovP4u8gLq3h3L2OYWhw9z5xGXFuJ3wO2NobHWof_M/edit#
21:38:08 <salv-orlando> there a few items still missing on the API doc. Especially the extensions. I am doing the l3 extension documentation, and nati-ueno should be doing extensions.
21:38:22 <salv-orlando> Some help on provider networks extension will be appreciated
21:38:26 <nati_ueno> OK I'm working on quota now
21:38:43 <danwent> if you've been watching the MLs, interest in quantum is very high and there are a lot of questions and people having bad experiences with it because its not documented, so I see getting this documentation polished as high priority as fixing bugs.
21:38:43 <annegentle> it would also be nice to get the API reference info on api.openstack.org
21:38:48 <salv-orlando> nati-ueno: thanks, I forgot to mention you were working on quota.
21:39:12 <danwent> i'm going to work on flushing out the nova + quantum section after the meeting
21:39:14 <nati_ueno> nati-ueno: :)
21:39:22 <annegentle> but I see admin docs a higher priority than api.openstack.org for sure
21:40:20 <danwent> then I will work on some of the L3 node setup stuff
21:40:27 <danwent> salv-orlando: you mentioned you were doing some diagrams
21:40:46 <danwent> I was also working on a diagram of the physical network topology.  does that overlap with yours?
21:41:21 <garyk> i am still trying to work on an example. i just have not had much time over the last few days. sorry
21:42:17 <salv-orlando> danwent: they are powerpoint - need to convert into png. Should be easy though.
21:42:19 <danwent> garyk: yeah, I was thinking of something similar.  I have a basic setup that has one "cloud controller" running all APIs, one "network node" running l3-agent and dhcp-agent, and X hypervisors.
21:42:34 <danwent> I was thinking about putting that in an appendix or something.
21:42:36 <salv-orlando> danwent: nope, I only have logical diagrams
21:42:47 <danwent> salv-orlando: ok, I will do the physical network diagram as well then.
21:42:53 <garyk> danwent: i added it towards the end of the doc. it is pretty patchy at the moment
21:43:09 <danwent> garyk: ah, is that the two node deployment picture?
21:43:19 <danwent> errr.. three node, i guess
21:43:27 <garyk> danwent: yes.
21:43:33 <danwent> ok, got it
21:43:52 <danwent> ok, i'll try to just extend that
21:44:01 <garyk> thanks
21:44:14 <danwent> we could also really use some one to write up some content around the policy.json
21:44:40 <danwent> right now that's just a TODO
21:44:47 <danwent> under Authentication and Authorization
21:45:27 <danwent> btw, starting tomorrow, Diane from the openstack docs team is going to convert the google doc over to docbook, a huge help for us
21:45:48 <danwent> but what this means is that we'll have to "freeze" the google doc, and then make subsequent changes via git + gerrit in docbook.
21:46:34 <RedValkyrie> I'd rather we left it as a google doc
21:47:06 <RedValkyrie> docbook is confusing
21:47:16 <danwent> RedValkyrie: yes, its definitely easier to edit, but as an official openstack project, our docs need to conform ot the doc teams guidelines and templates, and their choice of tool is docbook.
21:47:24 <salv-orlando> I think I left a note policy configuration is for me...
21:47:32 <salv-orlando> I will do that tomorrow
21:47:32 <danwent> salv-orlando: thanks.
21:47:49 <danwent> I've found that you can pick up docbook pretty easily
21:48:06 <danwent> and if you're heavily editing stuff, you can ask the docs team for a free license to doxygen
21:48:26 <danwent> which is a what-you-see-is-what-you-get editor for docbook
21:48:44 <RedValkyrie> I don't get what was wrong with google docs. everyone has it.
21:48:45 <danwent> using google docs was just a short-term trick to allow a lot of people to contribute quickly.
21:49:26 <salv-orlando> You can get a 60 days trial for oxygen
21:49:26 <danwent> you'd have to bring this up with the openstack docs team, like annegentle.  I'm not a docs expert.
21:49:55 <danwent> salv-orlando: actually, the openstack docs team can get you a full license
21:50:17 <salv-orlando> also, refrain from using other free tools - I've tried a few (vex for eclipse one of them) and they try to make your xml prettier, generating huge git diffs
21:50:57 <danwent> RedValkyrie: feel free to send annegentle a note.  its good for them to get feedback on tools, but i wouldn't expect things to change overnight.
21:51:21 <danwent> ok, so it sounds like we have our marching orders?
21:51:22 <RedValkyrie> okay fine. I guess I'll just have to learn this new system
21:51:24 * RedValkyrie pouts
21:52:01 <danwent> since my inherent bias is to work on bugs and fixes, i'm trying to commit to 50% time on docs
21:52:04 <salv-orlando> there's a documentation how to on the openstack wiki that will get you up and running. Setup is quite straightforward
21:52:09 <danwent> might be a useful target for others as well.
21:52:30 <danwent> #topic open discussion
21:52:33 <danwent> anything else folks?
21:52:45 <garyk> danwent: just to digress - qr tag issue does not reproduce with my setup
21:53:19 <amotoki> where are ubuntu folsom packages available? I would like to test with them.
21:53:37 <danwent> garyk: yeah, i've found it to be transient.  i'm just going to keep deploying a bug of things, and deploying them in a script
21:53:56 <garyk> danwent: i'll keep on working on it
21:54:11 <danwent> that tends to be when I see it (many things deployed all at once with a script) which is why i'm guessing its some kind of a timing issue.
21:54:23 <salv-orlando> for those who want to take the leap with docbook: http://wiki.openstack.org/Documentation/HowTo
21:54:25 <garyk> danwent: i am using a setup where the agents are started by systemd
21:54:39 <danwent> ok, let's keep in close communication as things pop up in the next week.
21:55:20 <danwent> final release is 10 days out.  let's make sure this is something we can all be proud of :)
21:55:29 <danwent> #endmeeting