21:00:56 <danwent> #startmeeting
21:00:57 <openstack> Meeting started Mon Aug 20 21:00:56 2012 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:05 <nati_ueno> Hi all
21:01:10 <danwent> #link agenda: http://wiki.openstack.org/Network/Meetings
21:01:12 <danwent> nati_ueno: hi
21:01:17 <nati_ueno> danwent: Congrat!!
21:01:17 <andrewsmedina> hi
21:01:21 <garyk> hi
21:01:22 <edgarmagana> hello world!
21:01:32 <zhuadl> dan:congratulations!
21:01:36 <danwent> ok, just want to congratulate the team again on a huge effort for F-3
21:01:40 <annegentle> danwent: wow congrats!
21:01:41 <ewindisch> danwent: congrats!
21:01:49 <danwent> made a ton of progress :)
21:01:59 <danwent> thanks all, sorry, didn't mean to throw the meeting off.
21:02:10 <danwent> release info is here: https://launchpad.net/quantum/+milestone/folsom-3
21:02:28 <SumitNaiksatam> Hi All!
21:02:33 <danwent> #topic folsom-rc1
21:03:03 <danwent> Since a lot of quantum developers are new in folsom, I wanted to spend some time explaining how feature freezes + RCs work in openstack projects
21:03:06 <arosen> HI
21:03:11 <danwent> so we're all on the same page, as there has been some confusion
21:03:36 <danwent> right now, the launchpad pages track things that we are considering for RC1
21:03:49 <danwent> but being on that page is not a guarantee that the feature will be in RC1
21:03:58 <danwent> or a bug fix
21:04:17 <danwent> if we don't make sufficient progress and it is not deemed absolutely critical to teh release, it will be dropped.
21:04:37 <danwent> So the goal of this RC phase is to stabilize and release the EXISTING quantum feature set
21:05:08 <danwent> people should be spending their time testing existing features, fixing bugs to those existing features, and helping to document the use of those existing features.
21:05:20 <danwent> on tricky aspect is that there is no single date for RC1
21:05:33 <danwent> each project will set their own date, based on how the bug-fixing is going.
21:05:46 <garyk> is there no deadline?
21:06:01 <danwent> garyk: well, it needs to be well in advance of the main openstack release at end of september
21:06:06 <ogelbukh> \о
21:06:17 <danwent> My thinking is to target Quantum RC1 for the week of 9/3
21:06:25 <danwent> which is two weeks from now
21:06:48 <gongysh> fine
21:06:50 <danwent> as for our first release, stability needs to be paramount, so we need a good amount of time between the first RC and the final.
21:07:02 * cdub notes 9/3 is us holiday
21:07:33 <danwent> cdub:  yup.  my guess is that release will be later in the week
21:08:09 <danwent> in an RC, no new features can be added unless there is a 'feature freeze exception'
21:08:10 <cdub> *nod* any thought on irc mtg on 9/3 (perhaps helpful to discuss readiness of code for rc1)
21:08:21 <danwent> this needs to be cleared by PTL (me) and Thierry (openstack release manager)
21:08:47 <danwent> cdub: good point.  i wonder if we should reschedule if we think people will be traveling
21:09:07 <danwent> #todo #danwent look into whether we need to reschedule 9/3 team meeting due to holiday
21:09:46 <danwent> core devs are responsible for enforcing feature freeze with reviews
21:10:09 <danwent> i have already -2'd a few reviews, as they should not merge until we pull the RC1 branch and open master for grizzly
21:10:31 <danwent> if there is doubt, send a not to thierry and I (or the whole list if you think there's a need for broader discussion)
21:11:22 <danwent> one key point on FFEs: the goal is not JUST minimizing code churn.  its also to free up cycles of team members for testing, docs, and reviews of critical bug fixes.
21:11:45 <danwent> another point: python-quantumclient and devstack are not subject to these rules, as they are not part of the main release cycle
21:11:50 <salv-orlando> danwent: I think relevant launchpad bps for patches you -2'ed were already deferred post folsom
21:11:55 <danwent> phew… ok, questions before we dive into specific FFEs?
21:12:23 <danwent> salv-orlando: yes, they were, but there's nothing to stop some reviewers from accidentally merging them into folsom, so I -2'd to be safe
21:12:25 <salv-orlando> nevertheless it's better the way you did, so they will not accidentally slip
21:12:27 <garyk> danwent: why is the client an exception?
21:12:37 <nati_ueno> Updating L3 function on each plugin could be FFE or not?
21:12:58 <danwent> garyk: to put it more clearly, we can define the release schedule for python-quantumclient.  we could choose to enforce our own feature-freeze
21:13:16 <garyk> danwent: ok. i think we should try and sync these.
21:13:22 <danwent> but the point is we are not forced to by main openstack release.  we can actually release a new version of python-quantumclient whenever we want.
21:13:30 <salv-orlando> nati_ueno: my view is that this could be done as a bug fix, unless it turns out to be a rearchitect of the plugin or require changes to 'common' parts
21:13:44 <danwent> garyk: agreed.  we will want target a release of python-quantumclient to be "paired" with folsom, in my opinion.
21:13:47 <garyk> danwent: ok. understood.
21:13:58 <nati_ueno> salv-orlando: I got it.
21:14:01 <danwent> nati_ueno: I wanted to talk with you about that.
21:14:34 <andrewsmedina> danwent: xml support is a FFE?
21:14:39 <danwent> Given how late the main L3 stuff dropped, if we're able to wrap up other plugin work on it this week, I'm ok with putting it under the main L3 FFE.
21:14:50 <danwent> andrewsmedina: see agenda
21:15:01 <danwent> we'll discuss specific features and their FFE status in a second
21:15:16 <danwent> i first wanted to make sure people understood how things work in general.
21:15:23 <danwent> any other general questions or opinions?
21:15:29 <nati_ueno> danwent: OK I got it. Thanks
21:15:46 <amotoki> how can we track BP defered to Grizzly? grizzly series on launchpad is now created.
21:15:55 <rkukura> danwent: is there an office FFE list core devs can check against?
21:16:04 <amotoki> are defered BP marked to G?
21:16:05 <rkukura> s/office/official/
21:16:19 <danwent> amotoki: deferred blueprints shoul have their series set to grizzly, not folsom
21:16:28 <salv-orlando> rkukura: I think you should look for "approved" bps on folsom-rc1 page
21:16:38 <danwent> salv-orlando: correct
21:16:40 <amotoki> i see.
21:16:49 <rkukura> thx
21:17:01 <danwent> if something is not linked to a bp that is approved for folsom and on the folsom-rc1 page, definitely ask for more details.
21:17:27 <danwent> Ok, granted FFEs
21:17:41 <danwent> we got an FFE for the main L3 + Floating IPs branch, as it didn't merge in time for F-3
21:18:00 <danwent> that main branch is now merged, but there will be some more "fixes" coming in.
21:18:09 <danwent> each new fix should be tracked as a bug, and linked to the blueprint.
21:18:19 <danwent> provider networks (rkukura)
21:18:37 <rkukura> working on getting agent to wire up flows for vlans and flat networks now
21:18:40 <danwent> we decided to mark the main BP done as of F-3, but there was one final patch that did not merge yet.  Bob is working on this.
21:18:57 <garyk> danwent: rkukura we should open a bug for the flat networks and linux bridge. the appliance hangs when this is configured.
21:19:03 <danwent> rkukura:  patch is pretty big.  what's an eta on a non-WIP version?
21:19:34 <rkukura> thursday, since I'm on vacation next two days, but hope to have more complete version today
21:20:11 <danwent> ok, good.  I'm trying to get all FFE items under real review (not just WIP) by end of week.
21:20:22 <rkukura> sounds doable
21:20:26 <danwent> great, thanks.
21:20:34 <danwent> nati_ueno:  test-agent for quantum
21:20:41 <danwent> https://review.openstack.org/#/c/11189/
21:21:11 <nati_ueno> I'll add unit test for that in this week. ( Sorry I'm also take off in this week )
21:21:14 <danwent> reviewed this a couple times.  seems pretty far along now.  still needs unit test coverage in my opinion
21:21:27 <danwent> shoot
21:21:54 <danwent> I was just about to say that getting this in and getting devstack gating set up for quantum was probably the most important thing we could be doing right now.
21:21:55 <nati_ueno> danwent: I got it. At first, I thought test is not needed. But I'm also don't want to decrease coverage
21:22:34 <danwent> perhaps we could get basic devstack gating working by running dhcp in non-namespace mode?
21:22:43 <danwent> I really wanted to focus on that this week
21:23:24 <nati_ueno> danwent: It is possible in this week ( this means until sunday )
21:23:30 <danwent> nati_ueno: does the new quantum.sh rely on the test-agent alread?
21:23:33 <danwent> already?
21:23:45 <nati_ueno> danwent: Not yet
21:23:59 <nati_ueno> danwent: ping is not working so it is comment outed.
21:24:08 <danwent> nati_ueno: ok, perhaps then we get that merged in, so we have at least a basic gate that can run with dhcp in non-namespace mode.
21:24:23 <danwent> nati_ueno: ok, will send you mail.  do you have least have mail access this week?
21:24:41 <nati_ueno> Yes. I'll check review and mail everyday
21:24:50 <danwent> nati_ueno: cool, thanks.
21:25:22 <danwent> ok, if others are available to pitch in on devstack exercise scripts and gating, that would be great as well, as this is really important
21:25:27 <danwent> ok, next topic
21:25:31 <danwent> rootwrap
21:25:36 <danwent> is john here?
21:25:42 <jrd-redhat> I hear somebody calling my name :-)
21:25:51 <danwent> great, was just looking up your handle :)
21:26:02 <jrd-redhat> I tried to be jrd, but it was taken
21:26:04 <danwent> review: https://review.openstack.org/#/c/11524/
21:26:25 <jrd-redhat> I uploaded corrected patch with corrected changeid
21:26:25 <danwent> jrd-redhat: is this WIP, or ready for final review?
21:26:38 <danwent> i haven't had a chance to review yet
21:26:41 <jrd-redhat> Well, I think that's up to Bob and Chris
21:26:59 <jrd-redhat> Per the latest comment, it does *not* change the default in the various agent .ini files.
21:27:07 <danwent> ok, but you're saying there are no known issues.
21:27:08 <jrd-redhat> Could be we should pull the trigger on that.
21:27:27 <jrd-redhat> I know of no issues causing things to break.
21:27:45 <rkukura> Other than not having tested it myself, my only reservation is that some agents aren't covered yet with the new mechanism.
21:27:56 <jrd-redhat> Yes, was gonna say that too.
21:28:01 <cdub> right, and that's noted in the review
21:28:06 <jrd-redhat> Yes.
21:28:08 <danwent> which ones?  i'm guessing l3?
21:28:10 <danwent> as its news?
21:28:13 <danwent> new?
21:28:28 <jrd-redhat> I didn't do ryu either
21:28:39 <garyk> dhcp agent also needs interfcace support
21:29:25 <rkukura> And iptables-firewall-agent
21:29:27 <danwent> ok, can we collect info on what is outstanding in one place?  maybe on the bug?
21:29:38 <jrd-redhat> Ok, I'll do that.
21:29:45 <danwent> thanks.
21:30:14 <jrd-redhat> I pushed as is partly to get feedback, and partly because one person suggested that the turnon and test of the rest of the agents could be done after the fact.
21:30:16 <danwent> jrd-redhat: as I mentioned before, all FFE stuff should be targeting end-of-week for a non-WIP review.
21:30:31 <rkukura> For things jrd-redhat can't easily test, does it make more sense to have someone else update?
21:30:37 <jrd-redhat> If that's icky, I have no quarrel with that.  I can work with other folks to help test
21:30:44 <danwent> yes, it could be done after the fact, but i'd also want to break things earlier, rather than later.
21:30:54 <jrd-redhat> danwent sure, no argument from me
21:31:23 <danwent> ok, let's get all outstanding items collected in teh bug.  then perhaps we'll split off separate bugs for items that he isn't able to test
21:31:38 <danwent> (e.g., split a bug out for L3/Floating IP related agents)
21:31:42 <jrd-redhat> I have another question on this thing:  I wrote a test which tests the mech by faking a command and executing it as root.
21:31:43 <danwent> or ryu agent
21:31:49 <jrd-redhat> That bug breaks tox, so I took it out.
21:32:03 <jrd-redhat> But I'd like to see it live someplace.  Where's a good place to put it?
21:32:11 <amotoki> nec plugins also uses agent. I'll check it.
21:32:12 <jrd-redhat> s/bug/test/
21:32:20 <danwent> amotoki: k, thanks
21:32:38 <danwent> jrd-redhat: is test available for viewing in your code review?
21:32:46 <danwent> I'd have to look at it more concretely.
21:32:56 <jrd-redhat> danwet no, I took it out.  I can post it as a separate changeset.
21:32:58 <danwent> perhaps ask reviewers to comment on it as part of the review.
21:33:05 <danwent> jrd-redhat: sounds like a good idea
21:33:16 <jrd-redhat> danwent ok, I'll find a way to publish it without blowing up tox.
21:33:38 <danwent> well, you can even post something for WIP that fails unit tests.
21:33:46 <danwent> if all you're doing is looking for feedback on how to do it in a better way
21:33:55 <rkukura> We don't really want unit tests doing anything as root, do we?
21:33:59 <jrd-redhat> Really?!?  Hmm.  I thought of that, but it seemed bad form.
21:34:26 <danwent> rkukura: i wouldn't think so, but I haven't put as much thought into it.  have we looked at what other projects with rootwrap do here?
21:34:41 <jrd-redhat> rkukura the test relies on sudo being set up, then uses rootwrap to test that it can correctly sudo a no-op command.
21:34:46 <danwent> jrd-redhat: not sure… i think its OK as longs as its clearly marked WIP.
21:34:46 <cdub> they just test the filters (like jrd's current patchset does)
21:34:47 <markmcclain> can't we just mock subprocess and check the results?
21:35:12 <rkukura> Maybe the test should go in tests rather than tests/unit
21:35:14 <jrd-redhat> danwent ok, I'll come up with something to get it published.
21:35:27 <danwent> ok, let's take this discussion to gerrit, so we can keep the meeting moving
21:35:29 <danwent> Ok, let's move on to our "under consideration FFEs"
21:35:40 <jrd-redhat> Thanks for feedback everybody...
21:35:42 <danwent> this is where a fair amount of discussion will be
21:35:47 <danwent> jrd-redhat: thanks for you work on this!
21:35:54 <danwent> first up, multi-host
21:35:55 <jrd-redhat> danwent my pleasure
21:36:03 <danwent> nati_ueno_2: you here?
21:36:09 <nati_ueno_2> danwent:  yes
21:36:15 <danwent> ok, saw your other nick drop
21:36:42 <nati_ueno_2> danwent: year network disconnected at while
21:36:48 <danwent> ok, so multi-host is one reason why the openstack docs may need to point users toward using the old nova-network code, rather than quantum for Folsom
21:37:00 <danwent> in general, we'd like as many people as possible to move on to quantum.
21:37:21 <nati_ueno_2> I agree
21:37:26 <danwent> multi-host also fixes some issues around the scalability of dhcp + l3/Floating-ips (though it introduces some other issues).
21:37:27 <nati_ueno_2> Yusuke updated patch https://review.openstack.org/#/c/10766/
21:38:01 <annegentle> danwent: good to know re: multi_host
21:38:17 <danwent> i'm planning on contacting thierry and talking to him about this one.
21:38:49 <danwent> from a dev perspective, i think we should keep polishing the patch and get it to the point that we're happy with it, so we're ready for it to go in, if it gets an FFE.
21:39:02 <danwent> nati_ueno_2: this is dhcp only though, right?  does not include anything with new L3 agent?
21:39:19 <danwent> (i guess the L3 agent multi-host stuff could be covered under L3 FFE)
21:39:43 <nati_ueno_2> danwent: Ah multi-host l3 could be more hard problem.. Could you discuss with me today?
21:39:54 <danwent> nati_ueno_2: ok, will take that offline.
21:40:11 <danwent> second FFE consideration topic is XML support
21:40:15 <danwent> zhuadl: here?
21:40:24 <danwent> andrewsmedina: here?
21:40:26 <zhuadl> yes, and andrews is also here
21:40:30 <andrewsmedina> danwent: ys
21:40:56 <danwent> when we talked about this last week, we agreed that zhuadl woudl send out a plan for XML support in folsom, and we'd consider it for FFE.
21:41:05 <andrewsmedina> danwent: I'm rewriting the tests to use a base test class
21:41:28 <danwent> There's an existing review from andrewsmedina, but there were some concerns around testing (as he noted).
21:41:49 <danwent> so zhuadl, do we have a clear picture of everything that would need to change to get all API code and existings using XML for Folsom?
21:41:49 <andrewsmedina> danwent: I believe that today or tomorrow I send the code to review
21:42:02 <zhuadl> Dan,  Andrews is working on that.
21:42:15 <zhuadl> I will help him to test
21:42:20 <danwent> Ok, so are you all comfortable with having this finalized by end of thish week?
21:42:28 <andrewsmedina> danwent: yes
21:43:16 <danwent> ok.  Then I'm going to ask ttx to get this confirmed for Folsom, assuming it is in final review (i.e., all major concerns addressed) by our meeting next monday, sound reasonable?
21:43:31 <danwent> i can't promise you ttx will agree
21:43:47 <danwent> but i'll ask.  and if it doesn't merge for folsom, the work will still be valuable, as it will go into grizzly.
21:43:52 <andrewsmedina> ok
21:43:56 <danwent> thanks guys
21:43:57 <zhuadl> yes for me
21:44:12 <salv-orlando> zhuadl: can you also reply on the XML support thread on the dev list about how you guys are going to address issues such as null values (I guess it's going to be xsI:nil, but sharing in advance with the community might be better)
21:44:27 <zhuadl> ok
21:44:40 <rkukura> Is the XML support addressing extended attributes?
21:44:41 <danwent> yes, that's a good idea.  do everything you can to make sure any major concerns are addressed by monday
21:45:00 <danwent> Ok, I am not aware of another other outstanding FFEs.  Did I miss anything?
21:45:13 <danwent> amotoki: i know we're working with the horizon folks to talk about public network support
21:45:20 <danwent> is there any answer on that from them?
21:45:38 <amotoki> i got an answer quicker is better.
21:45:39 <danwent> i'm not sure how much in the GUI we actually have to change
21:46:08 <amotoki> in Horizon , network list is retrieved by network_id.
21:46:22 <danwent> amotoki: tenant_id?
21:46:33 <amotoki> yes. network_id -> tenant_id
21:46:36 <amotoki> i need to change it to support public network.
21:46:54 <salv-orlando> amotoki: in this way network_list will return also public networks
21:47:03 <salv-orlando> unless you have an extra filter in horizon
21:47:15 <amotoki> in admin role, all network are listed.
21:47:21 <danwent> ok, sounds like amotoki and salv-orlando can coordinate on this
21:47:25 <danwent> thanks salv-orlando
21:47:34 <amotoki> thanks.
21:47:45 <danwent> ok, just about 15 mins left
21:47:58 <danwent> wanted to quickly cover a few other "large" bugs currently targeted for RC1
21:48:05 <danwent> markmcclain: https://bugs.launchpad.net/quantum/+bug/1028174
21:48:07 <uvirtbot> Launchpad bug 1028174 in quantum "Tenant cannot delete network when dhcp-agent is running" [Critical,Confirmed]
21:48:17 <danwent> i believe this is fixed, at least if non-polling is used
21:48:29 <markmcclain> there's still a race condition
21:48:39 <danwent> markmcclain: is that the only mode of dhcp supported, or is there still a mode where deleting networks will be broken?
21:48:51 <danwent> markmcclain: ah, ok.. was wondering why it was still open.
21:49:24 <markmcclain> I'll post a review that lets works around the race condition better
21:49:37 <danwent> ok, thanks.
21:49:38 <markmcclain> prob be tomorrow before I've got tests finished
21:50:12 <danwent> there's also two bugs that are for nova changes to make nova floating IP calls work with quantum
21:50:18 <danwent> https://bugs.launchpad.net/bugs/1023169
21:50:19 <uvirtbot> Launchpad bug 1023169 in quantum "update nova to report quantum floating IPs" [High,In progress]
21:50:24 <danwent> https://bugs.launchpad.net/bugs/1031119
21:50:25 <uvirtbot> Launchpad bug 1031119 in quantum "nova: proxy floating ip calls to quantum" [High,Confirmed]
21:50:45 <flaviamissi> i've done 1023169 bug
21:50:59 <flaviamissi> https://review.openstack.org/#/c/11514/
21:51:01 <danwent> flaviamissi: a cool
21:51:15 <danwent> ok, will check out review and link it to the quantum bug
21:51:22 <flaviamissi> danwent: it's missing a review (and some tests improvement)
21:51:45 <garyk> danwent: are these an ffe for nova?
21:51:48 <danwent> flaviamissi: great to see its started though.  i can ping the right nova devs once the quantum team has reviewed it.
21:52:01 <flaviamissi> danwent: thanks!
21:52:22 <flaviamissi> danwent: I could start 1031119, too, but I'll probably need some clarifications
21:52:34 <danwent> garyk: i'll be talking to vish about these changes.  he has a general heads up that there will be some changes to quantum/nova integration still.
21:52:51 <danwent> flaviamissi: ok, great.  please post questions on the bug, and I will follow-up
21:52:53 <amotoki> flaviamissi: the review is not linked from launchpad. could you add a pointer to the review.
21:53:01 <danwent> i just did
21:53:19 <flaviamissi> danwent: I'll do it, thanks
21:53:34 <danwent> carlp: https://bugs.launchpad.net/bugs/1038098  metadata service + overlapping ips
21:53:35 <uvirtbot> Launchpad bug 1038098 in quantum "Metadata service does not function when there are overlapping network address spaces" [High,Confirmed]
21:53:49 <markmcclain> danwent: he's in another meeting
21:53:55 <markmcclain> I've in the office with him this week
21:54:04 <markmcclain> we'll get a fix posted
21:54:12 <danwent> markmcclain:  ok, great.
21:54:25 <danwent> nati_ueno_2: https://bugs.launchpad.net/quantum/+bug/1022737
21:54:27 <uvirtbot> Launchpad bug 1022737 in quantum "host route distribution by DHCP" [High,In progress]
21:54:40 <nati_ueno_2> danwent: This is blocked by database side fix
21:54:49 <nati_ueno_2> https://review.openstack.org/#/c/11324/
21:54:59 <danwent> nati_ueno_2: we already have per-subnet hosts routes merged though, right?
21:55:15 <nati_ueno_2> danwent: Final code should be per-port
21:55:59 <danwent> nati_ueno_2: I think the original API proposal was per-port, but simon's fix only did it per subnet?
21:56:15 <nati_ueno_2> danwent: Yes. So I'm fixed per-port by 11324
21:56:37 <danwent> Ok.
21:56:39 <nati_ueno_2> typo ( fixed -> fixing )
21:57:12 <danwent> ok, and it seems like there are several other key bug fixes in need of review
21:57:13 <nati_ueno_2> danwent: I'm also fixing to let the code use quota
21:57:19 <nati_ueno_2> # fixing means under review
21:57:29 <danwent> I just wanted to call out the ones that seemed "large"
21:57:33 <danwent> in terms of code change.
21:57:41 <danwent> only 3 mins left
21:57:49 <danwent> #topic open discussion
21:57:56 <garyk> danwent: can core reviewers please update rebview days
21:58:06 <danwent> I wanted to point out that salv-orlando is working with docs team to publish v2 API
21:58:17 <cdub> danwent: is there a current list of reasons users would need old nova-network code (i.e. missing parity like the earlier multi-host discussion)?
21:58:18 <salv-orlando> review days page was updated this morning
21:58:21 <danwent> garyk: good point, we're back to our standard review days starting today
21:58:35 <garyk> salv-orlando: tx
21:58:41 <markmcclain> danwent: don't forget still 2 parts left to this bug https://bugs.launchpad.net/quantum/+bug/1022804
21:58:43 <uvirtbot> Launchpad bug 1022804 in quantum "Address re-allocation before DHCP lease's expire" [High,Fix committed]
21:58:55 <markmcclain> I'll post the next part in a few minutes
21:59:12 <danwent> markmcclain: ah, then we should switch it back to 'in progess' or file other bugs, please
21:59:21 <markmcclain> danwent: will do
21:59:39 <danwent> cdub: of the major features, its really multi-host and making sure quantum is compatible with nova security groups.
22:00:02 <nati_ueno_2> Is security groups FFE?
22:00:05 <danwent> the nova work we're doing for floating ips is to be able to let them use the legacy nov a commands to set and view floating ips.
22:00:11 <cdub> ok, fedora is planning another openstack testday, and would like to test accordingly (quantum preferred, but nova-networks as needed)...
22:00:35 <danwent> cdub: though there are probably a lot of smaller things that got wriggled into nova-network at one point or another that won't work the same in quantum
22:00:42 <danwent> (e.g., notion of a "dmz" cidr, etc.)
22:00:51 <danwent> nati_ueno_2: no, we considered that too big
22:01:01 <nati_ueno_2> danwent:  I got it
22:01:06 <cdub> *nod*
22:01:06 <danwent> so the plan is just to make sure nova's existing security groups play nicely with quantum
22:01:20 <danwent> ok, one minute over
22:01:31 <danwent> unless someone has a major concer, i'll wrap up meeting
22:01:39 <danwent> #endmeeting