21:00:11 <danwent> #startmeeting quantum
21:00:12 <openstack> Meeting started Mon Feb  4 21:00:11 2013 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:12 <mestery> danwent: Agreed, and they had 4 shots. Should have run it with the QB.
21:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:15 <openstack> The meeting name has been set to 'quantum'
21:00:23 <danwent> mestery: no kidding, my thoughts exactly
21:00:32 <danwent> #topic announcements / reminders
21:00:36 * salv-orlando2 is salv-orlando2 tonight
21:00:42 <danwent> #link: agenda: http://wiki.openstack.org/Network/Meetings
21:01:02 <danwent> this is our first meeting with all sections populated by team leads
21:01:04 <danwent> we'll see how it goes
21:01:09 <gakott> ola
21:01:10 <enikanorov> hi!
21:01:22 <markmcclain> hi
21:01:35 <danwent> one comment to team leads is that some sections seem overly full, so it may be best just to highlight the most important topics, and leave the rest for people to read
21:01:54 <danwent> #info two weeks out from feature freeze date of Feb 19th
21:02:09 <gakott> danwent: we can drop the stable today to save time (last week was the release)
21:02:21 <emagana> hi all
21:03:03 <danwent> #info we are still at 25 open blueprints, which is basically were we were at least week.  So we are not making good progress, and need to be ready for the fact that the majority of G-3 blueprints will not merge.  If you don't have high confidence that your changes will be ready, please untarget your blueprint.
21:03:06 <danwent> gakott: will do
21:03:21 <danwent> #info We will not be giving feature freeze exceptions for non high/critical issues.
21:03:30 <danwent> #info Remember to file doc bugs as we merge in G-3 features.
21:03:35 <danwent> any other announcements?
21:03:51 <danwent> if not, we'll just right into our team reports.
21:03:53 <alexpilotti> hi guys
21:04:05 <danwent> #topic API team report (salv-orlando )
21:04:22 <salv-orlando> hi
21:04:25 <danwent> salv-orlando: probably only need to cover 'high' issues in detail
21:04:37 <salv-orlando> yes and it's all about the XML support.
21:05:01 <garyk> XML is so 80's
21:05:05 <salv-orlando> Basically we are discussing whether explicitly expressing the type for attributes makes sense or not.
21:05:14 <zykes-> ability to set controllers for one
21:05:14 <nati_ueno> lol > garyk
21:05:20 <zykes-> wrong chan ;)
21:05:22 <salv-orlando> e.g.: for an integer value, like ip_version is quantum:type=int
21:05:41 <zykes-> since you're gonna support xml
21:05:45 <zykes-> why not do SOAP as well =
21:05:52 <salv-orlando> Yong came up with a case whether you need it to distinguish an empty list or dict from a null dict
21:06:04 <danwent> zykes-: please keep comments on topic
21:06:07 * mestery slaps zykes- for saying SOAP. :)
21:06:27 <salv-orlando> but we need to assess whether this is really necessary or not.
21:06:32 <danwent> salv-orlando: ok, so sounds like still minor design discussions needed here.
21:06:41 <salv-orlando> Apart from this nothing that cannot be fixed by next monday.
21:06:54 <gongysh> major problem is to keep the test cases used in json.
21:06:56 <danwent> salv-orlando: do we need to decide in meeting, or is review discussion sufficient?
21:07:11 <salv-orlando> We have enough contributors to make a decent quorum on the review.
21:07:14 <gongysh> if I have no such type information included, it is not the same as JSON format done.
21:07:30 <gongysh> JSON includes the type and data automatically.
21:08:12 <danwent> ok.  so we have core devs, we have a few questions to work through.
21:08:14 <salv-orlando> gongysh: your point is well received. I am looking for other comments on the review thread because I am too a bit rusty with xml.
21:08:31 <danwent> i think we had expected this to be merged by today, but it sounds like we're bumping to next week?
21:08:51 <salv-orlando> danwent: yes.
21:09:06 <garyk> salv-orlando: please keep https://blueprints.launchpad.net/openstack/?searchtext=configurable-ip-allocation on your radar.
21:09:11 <danwent> #info: XML api is still facing some fairly minor design discussions.  Expect merge by next week.
21:09:18 <garyk> salv-orlando: this may have potential api changes
21:09:21 <salv-orlando> For other issues with minor importance, please refer to the meeting agenda and  comment on the respective review threads on gerrit.
21:09:33 <salv-orlando> garyk: yeah i actually thought I was the approver for that one :)
21:09:42 <danwent> garyk: we bumped that out of Grizzly already
21:09:51 <garyk> danwent: ok, thanks
21:10:00 <danwent> mmm… though I see there are reviews posted
21:10:04 <markmcclain> danwent: Code has been submitted to implement it
21:10:07 <danwent> garyk: let's talk about it during the IPAM discussion
21:10:10 <danwent> which is next
21:10:20 <danwent> seems like LP and gerrit are out of sync
21:10:21 <garyk> ok
21:10:40 <danwent> #topic L3/IPAM/DHCP (markmcclain)
21:11:15 <danwent> markmcclain: so let's start out with high priority items
21:11:25 <markmcclain> Still working on L3+DHCP discussion review. Yong has been super responsive.  The review is going to be split to make it easier to review the code
21:11:42 <markmcclain> that is the reason for the −2 on that patchset.
21:12:26 <danwent> markmcclain: is this breaking base components stuff into separate commit?
21:12:28 <markmcclain> there are several other reviews that have been post that folks can checkout after hte metting
21:12:49 <danwent> ok.
21:13:02 <markmcclain> we're also investigating an IP allocation race condition, but I don't think anyone has replicated it outside of the reporter
21:13:29 <danwent> markmcclain: yeah, i'm wondering if it is postgres specific...
21:13:37 <garyk> markmcclain: danwent i think that yong also opened a bug with the dhcp leasing not working. we should prioritize that
21:13:51 <danwent> for reference, here's the race condition bug: https://bugs.launchpad.net/quantum/+bug/1110807
21:13:53 <uvirtbot> Launchpad bug 1110807 in quantum "Openstack quantum, race condition in ip address creation when starting 50 VMs on a 5-node cluster" [High,New]
21:14:09 <markmcclain> garyk: I'll check into that bug
21:14:15 <garyk> markmcclain: tx
21:14:41 <gongysh> hope we can have a configuration to disable or enable it.
21:14:52 <markmcclain> Last item: Pluggable IP allocation.  The blueprint was dropped, but code was submitted recently
21:15:03 <danwent> #info multiple agent support blueprint being broken into multiple patches.  Good progress and responsive feedback from yong, but still more review work to be done.
21:15:10 <markmcclain> it impacts both IPAM and the plugin API, so both teams should look at this:
21:15:15 <markmcclain> https://review.openstack.org/#/c/21067/
21:15:44 <markmcclain> #action markmcclain to look into DHCP lease bug
21:16:01 <markmcclain> that is all I have unless there are questions
21:16:21 <danwent> markmcclain: this seems like a useful direction, but that patch alone seems like only the first step, with multiple other patches before an end-user can actually see benefit
21:16:34 <danwent> or are those patches already done as well?
21:16:54 <markmcclain> I don't think they have been
21:16:59 <danwent> I'm just wondering if it makes sense to try and cram this in Grizzly.  Technically there's still time if we have core devs that think this is valuable
21:17:02 <yamahata> The patch is only the first clean up.
21:17:04 <markmcclain> so I'm concerned about time remaining
21:17:12 <nati_ueno> I think it has
21:17:31 <nati_ueno> https://review.openstack.org/#/c/21068/
21:17:59 <markmcclain> nati_ueno: thanks.. missed that one
21:18:03 <salv-orlando> so is the code for this feature complete?
21:18:11 <danwent> i haven't looked at the patches in detail, but it seems like a good direction in general
21:18:21 <salv-orlando> commit msg mentions a 3rd step.
21:18:23 <garyk> i have a few reservations about the change. i agree with the end goal. time may be a problem
21:18:33 <yamahata> Not yet. 3rd one isn't sent yet.
21:18:41 <nati_ueno> yamahata: when you can finish 3rd one?
21:18:52 <nati_ueno> markmcclain: np :)
21:19:14 <salv-orlando> IMHO any review cycles core team can save should be given to multi-agent patches, first.
21:19:26 <yamahata> I estimate i can  finish 3rd one in this week.
21:19:35 <danwent> #todo markmcclain decide whether to re-assign blueprint to G-3.
21:19:41 <markmcclain> salv-orlando: I agree
21:19:52 <danwent> my big concern is around whether the people who should weigh in on the design have cycles to do so
21:19:53 <salv-orlando> unless, of course somebody comes with a reason for raising its priority!
21:20:35 <danwent> #todo markmcclain decide whether to re-assign  Pluggable IP allocation blueprint to G-3.
21:21:12 <danwent> one other L3/DHCP issue I wanted to bring up was: https://bugs.launchpad.net/openstack-manuals/+bug/1099837
21:21:14 <uvirtbot> Launchpad bug 1099837 in openstack-manuals "dhcp-agent and l3-agent should not run without namespace" [High,Triaged]
21:21:37 <danwent> it seemed like amotoki_ was suggested code changes for some scenarios, not just doc changes.
21:21:43 <danwent> but that mnewby disagreed
21:22:04 <mnewby> danwent: what did i disagree about?
21:22:10 <danwent> if we are considering any code changes here, we need to get something to track the possible changes, and a spec to generate discussion ASAP.
21:22:10 <mestery> Just a note on another L3 topic: Bob submitted a devstack patch for the L3 work he's doing on this blueprint: https://blueprints.launchpad.net/devstack/+spec/quantum-l3-plugin-support
21:22:38 <danwent> mnewby: i thought you had made a comment about not using iptables for isolation when namespaces were not used (but perhaps I'm not remembering things correctly)
21:22:58 <mnewby> danwent: oh, right.
21:23:07 <danwent> amotoki_: are you here?
21:23:20 <amotoki_> danwent: yet
21:23:23 <amotoki_> yes
21:23:49 <mnewby> danwent: I'm not sure it's worth using automatic isolation via iptables when namespaces are not enabled.  It could get messy.  But that's just my opinion.
21:23:55 <danwent> amotoki_: are you still thinking you may make code changes, rather than just documentation changes?  if so, we need a bug/blueprint with proposed design.
21:24:06 <danwent> mnewby: i tend to agree as well.
21:24:19 <amotoki_> i do not think the code chnage is required.
21:24:22 <danwent> i think we should focus on the namespace design, not have two alternatives, if possible.
21:24:36 <markmcclain> +1
21:24:40 <danwent> amotoki_: ok, so no plans to use iptables for additional isolation?  thanks for clarifying.
21:25:14 <danwent> one other L3 item: https://review.openstack.org/#/c/19882/
21:25:21 <danwent> this is the static routing blueprint.
21:25:24 <amotoki_> danwent: i think so. iptable isolation can be done by manually.
21:25:38 <danwent> amotoki_: ah, ok.  i guess i misunderstood you.
21:26:07 <danwent> nati_ueno: you have now split this out separate from main l3 extension?
21:27:13 <nati_ueno> danwent: Yes I splited
21:27:38 <danwent> nati_ueno: ok, i have some additional feedback, but in interest of time, I will just make it on review
21:27:50 <danwent> markmcclain: anything else for L3/IPAM/DHCP?
21:27:51 <nati_ueno> danwent: I got it. Thanks
21:27:59 <markmcclain> danwent: no
21:28:19 <danwent> #topic nova / quantum integration (garyk)
21:28:33 <garyk> danwent: nothing much to update here.
21:28:49 <garyk> danp is working on refactoring the libvirt vif driver
21:28:55 <danwent> garyk: I believe daniel has removed the deprecation
21:29:02 <danwent> based on my latest reviews of the patches
21:29:08 <garyk> danwent: yes he has.
21:29:21 <danwent> i'm still a bit worried that it requires people to manually update thier vif-plugging type to his generic driver
21:29:36 <garyk> danwent: me too.
21:29:50 <danwent> i'd rather see a model that if the new vif-plugging quantum extension is used, the generic driver is used automatically
21:30:26 <garyk> danwent: agreed
21:31:00 <danwent> so I think its fine if the current patches merge, but I'd like to push further.  I guess this is something we could delay to Havana, but it seems cleaner to introduce it at the same time as the vif-plugging quantum extension is added.
21:31:36 <garyk> danwent: yes. agreed. i think that we need to pull in more people from nova and have a mixed discussion
21:31:47 <danwent> ok, so nothing else for nova-quantum integration (since i think arosen is handling the other item in security groups)
21:32:07 <danwent> garyk: yeah, if we could get trey on board, that would be a good idea.
21:32:11 <danwent> i'll ping him
21:32:14 <garyk> ok, i'll try
21:32:31 <danwent> #todo danwent ping trey, garyk and daniel b about vif-plugging
21:32:43 <danwent> #topic Security / Firewalling (arosen)
21:32:57 <danwent> high priority issue first (we're a bit behind schedule already)
21:33:33 <danwent> arosen? nati_ueno ?
21:33:42 <nati_ueno> OVS one is still blocked by https://review.openstack.org/#/c/19126/
21:33:49 <nati_ueno> also i got -1 from Yong
21:33:59 <nati_ueno> gongysh_: do you have still reason fro -1 ?
21:34:03 <danwent> nati_ueno: I think we're actually bocked on more than that in nova now, based on our previous discussion?
21:34:36 <nati_ueno> danwent: No, thrid change (update get_firewall_config) should be after this patch
21:35:13 <danwent> nati_ueno: really?  so we'd merge OVS security groups, even when they couldn't work yet?
21:35:15 <gongysh_> I think I just have a little comment about  the default configuration value on ovs SG.
21:35:43 <arosen> danwent:  no it hasn't merged.
21:35:45 <nati_ueno> danwent: IMO this one 1. https://review.openstack.org/#/c/19126/  2. OVS SG 3. https://bugs.launchpad.net/quantum/+bug/1112912
21:35:47 <uvirtbot> Launchpad bug 1112912 in nova "get_firewall_required should use VIF parameter from quantum" [Undecided,Confirmed]
21:36:26 <nati_ueno> gongysh_: I replied it on the review comment. We should bootstrap it. At first, it should be none firewall. then update devstack, then update default using security group
21:36:43 <danwent> nati_ueno: ok, maybe i need to look again, but it was my understanding that once daniel's new change merged, it would not be possible to run OVS with your security groups.
21:36:43 <nati_ueno> danwent: OVS sg works with https://review.openstack.org/#/c/19126/
21:37:02 <gongysh_> u want to use both sgs from nova and ovs plugin at the same time in devstack?
21:37:07 <nati_ueno> danwent: I confirmed https://review.openstack.org/#/c/19126/ is works with OVS patch
21:37:15 <nati_ueno> danwent: your double check is welcome :)
21:37:42 <nati_ueno> gongysh_: No only one. Nova or Quantum SG
21:37:56 <arosen> I've been working on the security group proxy for nova, that's up as a wip
21:37:57 <nati_ueno> gongysh_: We can't break quantum-gating
21:38:13 <danwent> nati_ueno: ok, i'll take your word for it, though it seemed from the code that the OVS hybrid vif-plugging would only happen if one was not using the noop driver
21:38:28 <danwent> whereas OVS SG would require the noop driver
21:38:51 <danwent> but i may be confused, as I haven't looked at the OVS SG patch in particular, just vif-driver
21:39:36 <nati_ueno> danwent: let's talk about this after meeting. I wanna know why you think so
21:39:42 <danwent> nati_ueno: k
21:39:54 <amotoki> i will also check vif plugging and comment it today.
21:39:57 <danwent> ok, so in terms of this review in general, seems like we think quantum code is basically good.
21:39:57 <gongysh_> mati_ueno: I moved the -1 to +1
21:40:18 <nati_ueno> gongysh_: Thanks!
21:40:38 <danwent> nati_ueno: who are the two core devs paying close enough attention that they should be able to +2?  arosen and amotoki ?
21:41:02 <danwent> gongysh_:  or you?
21:41:03 <arosen> danwent: i'll pay attension to it.
21:41:11 <amotoki> me too
21:41:22 <nati_ueno> thnks
21:41:29 <gongysh_> #info next week is chinese sprint festival.
21:41:42 <gongysh_> sprint => spring
21:42:03 <danwent> #info ovs security groups blocked on nova change https://review.openstack.org/#/c/19126/.  We think Quantum code itself is basically good to go for merge this week.
21:42:15 <danwent> gongysh_: ok… are you off the whole week?
21:42:35 <danwent> ok, arosen anything else?  we need to really keep moving
21:42:36 <gongysh_> danwent: yes. from feb 9 on.
21:42:44 <arosen> I'm still waiting on the nvp security group stuff to merge. Hopefully that will happen soon. markmcclain and salv-orlando are the 2 core devs reviewing that.
21:42:44 <danwent> gongysh_: ok, good to know
21:42:54 <arosen> we can move on  though
21:42:54 <danwent> #topic lbaas
21:43:03 <amotoki> arosen: now checking it.
21:43:15 <danwent> ok, from the mailing list, sounds like there's some uncertainty around the design here.
21:43:21 <salv-orlando> arosen: I had only minor concerns. I will have another round tomorrow morning, hopefully will +2.
21:43:27 <enikanorov> yep
21:43:31 <salv-orlando> I already stacked my l3 patch on top of yours
21:43:38 <enikanorov> so now we're focusing the use case of on-demand HAProxies
21:43:40 <danwent> the good news is that an "end-to-end" code path is up for review, so we can see concretely what is being proposed by the developers
21:43:52 <danwent> enikanorov: thanks for getting the code posted so quickly
21:44:28 <danwent> There are two blueprints here.  One for plugin framework, one for Ha proxy driver for the framework.
21:44:33 <enikanorov> yep, but it still need something to be implemented
21:44:58 <danwent> so one point that came up twice on the ML is that some of us were expecting an approach closer to what l3/dhcp does
21:45:03 <enikanorov> so... what is wrong with using ip netns exec ... ssh to haproxy VM?
21:45:58 <enikanorov> it seems to be easy way to access VM in private network without lauching additional agents
21:46:15 <danwent> enikanorov: in case of l3/dhcp, there was no need for namespaces to allow SSH access, as control software could run commands in namespace directly
21:46:50 <ilyashakhat> so, the idea is to run service-agent in tenant NS?
21:47:23 <markmcclain> ilyashakhat: yes.. the DHCP and L3 agents do that now
21:47:46 <enikanorov> so you're proposing service agent per balancer device
21:47:46 <danwent> ilyashakhat: how l3/dhcp work is that you would pick a host (and with yong's work, multiple hosts) to run a quantum-l3-agent.  then when a new "router" is needed, a message it sent to one of those l3-agents, which creates + configures a new namespace.
21:48:26 <enikanorov> it looks more complex than to run ssh through namespace
21:48:54 <danwent> enikanorov: or at least, what is what I think we were expecting….  not to say there isn't a better option :)
21:49:24 <danwent> enikanorov: someone on th ML implied that load-balancers were VMs, is that not the case anymore?
21:49:31 <enikanorov> so currently we just want to download/upload haproxy conf and then restart haproxy service via ssh
21:49:47 <enikanorov> that is done from sible service agent that can access any haproxy of any tenant via correct ns
21:49:53 <enikanorov> it is
21:49:55 <danwent> enikanorov: is the assumption that someone else started a load-balancer VM?
21:50:20 <enikanorov> the assumption that it could be both, but we're focusing that haproxy is vm that we provision
21:50:25 <danwent> enikanorov: we're running late on time.  can we stay and chat about htis after the meeting?
21:50:29 <enikanorov> within a requestor network
21:50:36 <enikanorov> sure
21:50:40 <danwent> enikanorov: i think i'm understanding your proposal a bit better now
21:51:24 <danwent> #info code for all lbaas blueprints posted, but still some significant design questions to answer.  need to get this closed this week.
21:51:34 <danwent> (in terms of key design)
21:51:50 <danwent> #topic quantum-client / cli (gongysh_ , markmcclain )
21:52:09 <gongysh_> Make QuantumClient library more pythonic
21:52:25 <gongysh_> the progress about it is unknown.
21:52:41 <danwent> gongysh_: agreed, we should clean that up.
21:52:58 <markmcclain> Working on getting that posted for next Monday
21:53:00 <danwent> gongysh_: should status of https://blueprints.launchpad.net/python-quantumclient/+spec/lbaas-cli be in review?
21:53:20 <enikanorov> it was merged, no?
21:53:24 <ilyashakhat> yes
21:53:38 <ilyashakhat> i will update
21:53:40 <gongysh_> it is merged.
21:53:43 <danwent> enikanorov: ah, great.  I knew it was at least in review.  STatus in LP was "good progress"
21:53:51 <danwent> please change to implemented
21:54:01 <gongysh_> ok
21:54:27 <amotoki_> gongysh_: could you share the release plan? we need to have released quantumclient to support lbbas and secgroup in Horizon.
21:54:31 <danwent> ok, we're skipping quantum stable update, as garyk said there is not much to add after they shipped most recent stable update
21:54:50 <gongysh_> I think we can have one for G3.
21:54:52 <garyk> :) i answered your comments
21:55:24 <gongysh_> Do u need one now?
21:55:26 <danwent> gongysh_: actually, this 3.0 release is for all of grizzly, so if there are previous "features" that went in, we should probably create retroactive blueprints, just to indicate what we shipped in this release
21:55:31 <danwent> (e.g., a blueprint for security group CLI)
21:55:52 <danwent> #topic quantum + Horizon
21:55:56 <danwent> amotoki_:
21:56:24 <danwent> amotoki_: looks like there are several things that are only 'started'?
21:56:31 <amotoki_> floating ip bp is on review.
21:56:51 <amotoki_> i am working on secgroup support.
21:57:00 <amotoki_> nati_ueno: do you have any update?
21:57:02 <danwent> lbaas stuff is making progress too, right? https://blueprints.launchpad.net/horizon/+spec/quantum-lbaas
21:57:03 <nati_ueno> We can push nic ordering in this week
21:57:18 <danwent> i saw an email from KC on that
21:57:37 <SumitNaiksatam> danwent: yes, this is in progress
21:57:49 <SumitNaiksatam> could not change the status
21:58:00 <danwent> amotoki_: great.  please just make sure gabriel is on the same page about everything his team may be being asked to review :)
21:58:28 <danwent> and if you don't think something is going to make G-3, best to have a potential feature-freeze discussion early (i'm not sure what their policy is over there)
21:58:30 <amotoki_> danwent: i will attend the horizon meeting tommorow and share the updates
21:58:41 <danwent> amotoki_: great, thanks.
21:58:45 <danwent> #topic open discussion
21:59:11 <danwent> ok, if you have a report from another sub-team, or comments on quantum system test, we'll just use open disucssion, as I didn't see anything new on the agenda
21:59:14 <gongysh_> guys, don't miss the cli patches.
21:59:16 <garyk> i am going to call it a day. goodnight!
21:59:22 <danwent> garyk: good night
21:59:32 <salv-orlando> bye
21:59:45 <danwent> gongysh_: yes, that's a very good point.  I think people (myself included) tend to look at quantum server repo more than the CLI.
22:00:09 <danwent> gongysh_: don't hesitate to send a note to the core team if there are particular reviews related to community-wide blueprints that are languishing
22:00:18 <gongysh_> ok
22:00:26 <nati_ueno> danwent: I wanna discuss with you guys about stable/folsom support on gating
22:00:33 * enikanorov suggests #quantum-lbaas for lbaas discussion
22:00:37 <danwent> salv-orlando: btw, am I the one supposed to file something on throwing errors on "extra" content in API requests?
22:00:42 <nati_ueno> garyk: good night!
22:00:48 <salv-orlando> no I am
22:00:52 <salv-orlando> I will file
22:01:00 <salv-orlando> the patch is looking small, so a bug should be enough
22:01:17 <danwent> salv-orlando: agreed. should be very simple now that we have attributes dictionary
22:01:22 <danwent> ok, any other open discussion?
22:01:26 <danwent> we're one minute over
22:01:27 <salv-orlando> this unless someone thinks there a going point in allowing the API layer to accept anything
22:01:37 <markmcclain> Quick reminder: All bugs have been tagged by team, so take a look and make the priority/status are up to date.
22:01:51 <salv-orlando> markmcclain: I forgot to thank you for that
22:01:52 <danwent> markmcclain: thanks for working on that, very valuable.
22:01:57 <mestery> Bob
22:01:59 <mestery> Sorry
22:02:01 <mestery> What about
22:02:08 <mestery> What about Bob's L3 blueprint: https://blueprints.launchpad.net/quantum/+spec/quantum-l3-routing-plugin
22:02:15 <danwent> markmcclain: sorry, i missed that you had updated the agenda witha  section for that.  will do it next week :(
22:02:25 <markmcclain> salv-orlando: I'd rather have the API fail fast when given unknown attributes… makes it easier to diagnose bugs
22:02:30 <danwent> mestery: that's in the L3/IPAM/DHCP bucket.
22:02:40 <salv-orlando> markmcclain: agreed
22:02:45 <mestery> danwent: Which is why I brough it up in that meeting slot.
22:03:00 <mestery> The point is, Bob added devstack patches to fix the jenkins failures
22:03:07 <danwent> mestery: sorry, what are you asking about then?
22:03:33 <mestery> danwent: Sorry, just wanted to bring it up, as no one is assigned to it. Does this mean it's out of G-3?
22:04:25 <danwent> mestery: this is going to be a painful milestone from that perspective.  right now, its in the "if you can convince two core devs that its important enough" category with all of the other medium stuff.
22:04:37 <mestery> danwent: Got it.
22:04:51 <danwent> mestery: i'd probably say there's more community value in that BP than most other 'medium' BPs
22:04:53 <mestery> nati_ueno: Thanks for the review on that one and the jenkins help. Bob couldn't be here today.
22:05:03 <nati_ueno> mestery: Np :)
22:05:16 <danwent> mestery: but we're in bad enough shape with our existing 'high' blupprints, that i'm loathe to add anything else to the 'high' bucket
22:05:17 <mestery> danwent: Agreed. Bob's done some nice things there.
22:05:29 <danwent> #endmeeting