15:05:15 <HenryG> #startmeeting neutron_drivers 15:05:15 <openstack> Meeting started Tue Nov 10 15:05:15 2015 UTC and is due to finish in 60 minutes. The chair is HenryG. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:05:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:05:18 <openstack> The meeting name has been set to 'neutron_drivers' 15:05:36 <HenryG> #chair amotoki_ kevinbenton 15:05:37 <openstack> Current chairs: HenryG amotoki_ kevinbenton 15:06:13 <kevinbenton> does someone have an agenda link handy? 15:06:18 <amotoki_> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe 15:06:29 <HenryG> let's just go through them 15:06:36 <HenryG> #topic https://bugs.launchpad.net/neutron/+bug/1468366 15:06:36 <carl_baldwin> sounds good 15:06:37 <openstack> Launchpad bug 1468366 in neutron "RFE - Logging API for security group rules" [High,Triaged] - Assigned to Yushiro FURUKAWA (y-furukawa-2) 15:06:40 <kevinbenton> #topic RFE Triage 15:06:59 * HenryG is an amateur 15:07:00 <kevinbenton> whoops 15:07:20 <amotoki_> #undo 15:07:20 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0xa17ead0> 15:07:28 <HenryG> heh 15:07:50 <HenryG> It seems there is agreement to split this one? 15:08:05 <amotoki_> I think so. 15:08:35 <kevinbenton> generic logging API and then the security groups implementation? 15:08:36 <HenryG> But how does that tie in with common classifier stuff? 15:09:17 <amotoki_> i don't think it is related to the common classifer stuff. 15:09:20 <kevinbenton> it doesn't, does it? 15:09:34 <carl_baldwin> +1 15:09:49 <HenryG> OK I saw a comment from amotoki_ about "split the effort into SG and FWaaS" 15:10:10 <amotoki_> HenryG: this is from armax too. 15:10:26 <amotoki_> i also suggested to focus on logging API and make logging format out of scope. 15:11:00 <HenryG> So a 3-way split: logging API, logging for SG, logging for FWaaS? 15:11:40 <amotoki_> my understanding is that we dicsuss logging API thru SG logging discussion. 15:14:09 <HenryG> OK, I am a bit fuzzy on that TBH 15:14:32 <ajo> yes, me too, I thought it was all about logging "firewall" drops 15:15:11 <ajo> or also non-drops 15:15:20 <HenryG> Do we want the logging API to be a generic thing for "system logging of X"? 15:15:53 <ajo> hmmm, they are also proposing some sort of API to configure the logging backend 15:16:06 <HenryG> Maybe that RFE should be filed and it can be discussed there? 15:16:29 <ajo> wouldn't it be more reasonable to let just log firewall/sg events?, and then a second step (if necessary to setup any API they need?) 15:16:33 * mestery comes in late 15:16:36 <amotoki_> the scope of the RFE itself looks good and is well-focused. 15:16:47 <ajo> I'd say it's too much for what they want (IMHO) 15:16:59 <russellb> ajo: log to who 15:17:04 <russellb> the cloud admin, or the end user? 15:17:05 <amotoki_> ajo: I tend to agree with you 15:17:25 <HenryG> yes, I feel we may be throwing too many obstacles in front of this request 15:17:29 <amotoki_> the proposed spec looks more than needed... 15:17:53 <russellb> nm ignore me 15:18:05 <ajo> russellb , yeah, may be the use case they had in mind was letting the end user debug it's own rules 15:18:24 <ajo> and then they need to configure a backend to dump the logs too? 15:18:35 <carl_baldwin> russellb: ajo: I do recall reading that in the rfe (end user debugging) 15:18:39 <armax> hi folks, sorry I am late 15:18:42 <armax> what did I miss? 15:19:02 <kevinbenton> armax: figuring out https://bugs.launchpad.net/neutron/+bug/1468366 15:19:02 <openstack> Launchpad bug 1468366 in neutron "RFE - Logging API for security group rules" [High,Triaged] - Assigned to Yushiro FURUKAWA (y-furukawa-2) 15:19:10 <HenryG> armax: not much 15:19:11 <ajo> yup :) 15:19:16 <HenryG> #chair armax 15:19:16 <openstack> Current chairs: HenryG amotoki_ armax kevinbenton 15:19:27 <kevinbenton> #dechair kevinbenton 15:20:09 <regXboi> kevinbenton: #unchair 15:20:20 <carl_baldwin> kevinbenton: Just sit there and be still until the meeting is over. ;0 15:20:22 <carl_baldwin> ;) 15:21:04 <HenryG> armax: we are perhaps gravitating towards narrowing the focus of that RFE to what the title says 15:21:43 <armax> HenryG: I proposed the submitter to keep the use case narrow 15:21:50 <HenryG> An API for tenants to log their SGs 15:21:53 <sc68cal> I worked through that review quite a bit - the issue was they were baking their deployment's details of using rsyslog directly into the API 15:22:46 <mestery> sc68cal: That's horrible 15:22:59 <amotoki_> HenryG: "for tenants"? the first scope is 'for admins/oeprators' 15:23:09 <sc68cal> quite a few cycles were spent just teaching them to decouple the logging implementation from the API 15:23:10 <armax> I personally gather that the use case is valid 15:23:26 <regXboi> mestery: yo! 15:23:29 <amotoki_> sc68cal: yes. that's bad. i thought it should be discussed in the spec review itself. 15:23:33 <armax> but it might take quite a bit of time to get it into the right shape 15:23:45 <sc68cal> agree, usecase is valid, it just took a while to get it to a better place 15:24:21 <armax> so on that basis we can give this the thumb up 15:24:42 <carl_baldwin> Time check. We've spent 20 minutes on this one and we have 35 minutes left. 15:24:53 <armax> but then, the issue is: do we have seasoned who can help the effort move along? 15:25:16 <amotoki_> i can volunteer to help it 15:25:37 <armax> amotoki: ok 15:26:00 <armax> amotoki: are we clear though that this must be limited to secgrups to start with? 15:26:12 <sc68cal> I'll also tag along with amotoki_ 15:26:30 <sc68cal> since I trolled the spec quite a bit 15:26:34 <armax> ok 15:26:38 <amotoki_> armax: yes. it must focus on SG 15:26:45 <sc68cal> ++ 15:27:11 <armax> ok, let me act on this after this meeting 15:27:16 <armax> shall we move to the next? 15:27:32 <HenryG> please 15:27:37 <armax> https://bugs.launchpad.net/neutron/+bug/1476527 15:27:37 <openstack> Launchpad bug 1476527 in neutron "RFE - Add common classifier resource" [Undecided,Triaged] 15:27:44 <armax> this might actually turn out to be easy 15:27:53 * sc68cal runs and hides 15:28:10 <armax> sc68cal: come back 15:28:21 <armax> ajo: you there? 15:28:55 <armax> my suggestion was to treat this classifier as a reausable component across the neutron stadium projects 15:29:09 <armax> to this aim I am thinking it should be its own thing 15:29:28 <armax> so that it’ll help us work with well defined and decoupled interfaces 15:29:45 <sc68cal> ++ 15:29:50 * dougwig overslept 15:29:54 <armax> ajo’s concern was the model, however, we have plenty of subprojects with examples where they have their own model 15:29:57 <ajo> hi armax , sorry 15:30:08 <ajo> I got an interrupting call 15:30:12 <armax> and I see no problem with that 15:30:23 <ajo> classifiers 15:30:39 <armax> HenryG has been working on handling the schema across multiple projects within the neutron system 15:30:46 <ajo> armax , do you think it's doable to have the clasiffier db models shared from a library? 15:30:48 <amotoki_> we have concerns on db model, for example how db migration works. 15:31:08 <armax> amotoki_: that’s something we know it works today 15:31:10 <sc68cal> I was looking into that this morning, the question is how ugly is branches in alembic 15:31:10 <ajo> I mean, how would we do that, to let the API pull/put that to the db.., and the migrations 15:31:41 <kevinbenton> do the subprojects need to query the DB directly? can't we have them use a service plugin API or something? 15:31:59 <armax> kevinbenton: they should not 15:32:17 <armax> that’s the whole point of working decoupled and well defined interfaces 15:32:35 <armax> data should be encapsulated 15:32:42 <HenryG> You just put a depends-on in the migration(s) 15:32:45 <amotoki_> the subprojects should access through some lib interface. 15:32:47 <ajo> but the idea behind this is having a common data model for the traffic filters... to avoid reimplementing on every project 15:33:04 <armax> ajo: right 15:33:13 <armax> but the data model in OO is encapsulated 15:33:29 <kevinbenton> yes, so why do we need to worry about alembic branches? 15:33:32 <armax> data is accessed through behavior 15:33:39 <armax> kevinbenton: I don’t know 15:33:39 <HenryG> The hardest part I think will be where core depends on a subproject 15:33:41 <armax> honestly 15:34:03 <ajo> let's imagine the scenario, fwaas makes use of it... tap as a service makes use of it, qos makes use of it... 15:34:34 <dougwig> This implies release concurrent with neutron and not independent in pypi, right? 15:35:08 <HenryG> dougwig: that's what it feels like to me 15:35:11 <ajo> how would that work?, how do we make sure the db models are in place?, I'm just a bit lost about how would we handle the dependencies technically... (make sure the specific migrations have taken place, so you're able to use the "network-traffic-classifiers" api) 15:35:30 <ajo> I'm not opposed to it, the more decoupling, the better 15:35:36 <amotoki_> what I am not sure is whether it will be a library or a subproject. 15:36:04 <armax> amotoki_: why do you treat it differently? 15:36:13 <dougwig> This hits a sticky point in neutron lib, which is how to handle models. Ends in this same place. 15:36:42 <amotoki_> armax: in my mind a library just provides an interface, a model or something and anyone can consume it 15:37:00 <dougwig> Dependency graph is pretty if pulled, but it pulls a lot. 15:37:06 <amotoki_> i think it is a kind of neutron-lib 15:37:25 <armax> amotoki_: and a subproject? 15:37:49 <amotoki_> a subproject depends on neutron (core) and consume neutron-core. 15:38:20 <armax> amotoki_: ok 15:38:42 <armax> amotoki_: I don’t believe the distinction buys us anything 15:39:04 <amotoki_> it is the first case and we need to explore a way. I haven't figured out a full picture. 15:39:10 <HenryG> neutron can install without a subproject. neutron cannot install without its required libraries. 15:39:15 <armax> we’re mixing the fact that a repo falls under the neutron stadium with its dependencies 15:39:32 <ajo> HenryG , true 15:40:01 <armax> I mean, I understand why you’re making this statement 15:40:46 <armax> assumed we keep this classification for a minute 15:41:04 <armax> the classifier should not have dependencies to subprojects 15:41:23 <HenryG> s/to/on/ ? 15:41:30 <armax> HenryG: on 15:41:31 <armax> sorry 15:41:35 <dougwig> He's pointing out that it's a circular dependency. So it requires an implicit dependency. Which has been painful in aas. Likely implies we need to think about that structure a bit, though the idea of separation is correct. 15:41:37 <armax> but it would most likely depend on neutron-lib when that’s a real thing 15:41:53 <dougwig> Right 15:41:57 <sc68cal> I've tried to avoid importing things from Neutron at least in the POC 15:42:01 <sc68cal> to avoid circular dep 15:42:17 <armax> dougwig: I don’t see the circular dep, or at least if there is, then we got the design wrong 15:42:57 <armax> so assumed that the schema side of things can be dealt with 15:43:02 <armax> like other projects do 15:43:07 <ajo> It wouldn't make sense to have circular deps, that makes sense 15:43:22 <regXboi> which RFE are we discussing (I've lost track between two parallel meetings) 15:43:37 <armax> what else is the issue that could prevent us from moving forward as a ‘library’ in is own right? 15:43:40 <ajo> regXboi https://bugs.launchpad.net/neutron/+bug/1476527 15:43:40 <openstack> Launchpad bug 1476527 in neutron "RFE - Add common classifier resource" [Undecided,Triaged] 15:43:49 <regXboi> ajo: thx 15:44:30 <armax> the question is: who would be working on this? ajo, would that be you? 15:44:46 <sc68cal> armax: I thought I was? 15:44:52 <armax> sc68cal: sorry, right 15:44:57 <ajo> correct :) 15:45:13 <ajo> armax, sc68cal , btw I will be happy to review, as an interested party. 15:45:14 <armax> and you’re doing some preliminary investigation already 15:45:43 <sc68cal> armax: yep 15:45:57 <armax> before we go down the path of creating repos, launchpad project, etc some derisking is in oder 15:45:59 <armax> order 15:46:01 <armax> I imagine 15:46:30 <sc68cal> derisking? 15:46:37 <dougwig> armax: the circ dep is there today, but neutron-lib should break it. this is running into a dilemma i mentioned at the summit, and need to talk to HenryG about offline, which is how to release base model foo on a release train indepedent of the integrated-release. 15:46:52 <dougwig> armax: sorry, not awake yet, don't think it should slow this down right now. 15:47:31 <armax> sc68cal: mitigate/investigate risk 15:47:36 <ajo> sc68cal, could you link me to the current poc? 15:47:54 <sc68cal> ajo: be gentle, it's https://github.com/sc68cal/neutron-classifier 15:48:12 <armax> dougwig: I understand there may be existing complications, or unknowns 15:48:15 <ajo> sc68cal , of course, just curious, and trying to get my mind on the db & dependency issues 15:48:20 <ajo> to see if I can help somehow 15:48:39 <dougwig> can we table the db/dep issue until next week? 15:48:39 <sc68cal> ajo: cool! 15:48:55 <dougwig> we could eat the entire meeting, and we/i should prep for it more first. 15:49:16 <armax> dougwig: ok, I am assuming you and HenryG would be cracking at this? 15:49:16 <ajo> oh, sc68cal , but it's already decoupled into a separate repo, nice... I will read :) 15:49:28 <HenryG> armax: ack 15:49:41 <dougwig> armax: we'll take a stab and write something up, yes. 15:49:43 <armax> ok, let me provide some feedback on this one too 15:49:51 <armax> let’s move to the next 15:50:14 <armax> https://bugs.launchpad.net/neutron/+bug/1513144 15:50:14 <openstack> Launchpad bug 1513144 in neutron "Allow admin to mark agents down" [Undecided,Triaged] - Assigned to Carlos Goncalves (cgoncalves) 15:50:17 <armax> 10 mins left 15:51:04 <ajo> kevinbenton : just read your last comment about --admin-state-down 15:51:13 <carl_baldwin> Remind me, did we ever implement a way to put an agent in a state where it doesn't accept any more scheduled things? 15:51:17 <ajo> I guess we don't want to change the semantics or that, or wouldn't that make sense? 15:51:24 <armax> carl_baldwin: yes 15:51:27 <kevinbenton> that's what --admin-state-down does 15:51:31 <armax> kevinbenton: ++ 15:51:42 <carl_baldwin> kevinbenton: That wasn't always what it did. 15:51:42 <armax> so perhaps this needs to be elaborated more 15:51:43 <armax> besides 15:52:02 <kevinbenton> this spec is to allow immediate rescheduling 15:52:02 <carl_baldwin> kevinbenton: It used to stop functioning even with currently scheduled stuff. 15:52:06 <armax> we went down the path where we allow Neutron to be a black biox 15:52:07 <armax> box 15:52:17 <ajo> and wouldn't that suffice the RFE submitter needs? 15:52:32 <armax> where automatic rescheduling takes place if agents dies 15:52:37 <ajo> hmm 15:52:39 <armax> granted I believe that can be disabled 15:52:48 <armax> both for L3 and dhcp 15:52:51 <cgoncalves> kevinbenton: immediate rescheduling could happen yes, but not explicitely being proposed in this RFE 15:53:00 <armax> so perhaps here this applies to L2 only? 15:53:06 <armax> as for L2 I am not entirely sure what the story is 15:53:07 <carl_baldwin> armax: Part of what they claim is that Neutron can't detect some reasons for failure. 15:53:30 <cgoncalves> carl_baldwin: correct 15:53:45 <ajo> cgoncalves , you're the rfe submitter, right? 15:53:46 <armax> I am pretty sure that L3 and DHCP we already have the ability to disable services 15:53:59 <ihrachys> carl_baldwin: it could be e.g. external network access missing for l3 agent. it would be hard to detect it. 15:54:04 <armax> and move stuff around for high availability reasons 15:54:05 <carl_baldwin> For L2, we don't directly schedule anything to L2, right? L2 gets ports bound for VMs, routers, etc. 15:54:14 <cgoncalves> carl_baldwin: either cannot detect some failure or does not detect promptly due to the heartbeat 15:54:19 <cgoncalves> ajo: yes, I am 15:54:23 <kevinbenton> carl_baldwin: right, if this is for l2, i'm not sure what this accomplishes 15:54:45 <kevinbenton> cgoncalves: so if it's just an L2 agent, you could set the admin state to down to show that it's offline 15:54:54 <armax> cgoncalves: today the l2 agent detects the crash of the ovs 15:55:05 <armax> cgoncalves: now if ovs never comes back that’s a problem 15:55:41 <cgoncalves> kevinbenton: could also be other agents as well 15:55:45 <armax> however I can see that say an admin detects that something is seriously broken with a host 15:55:51 <armax> we’d want to disable the l2 agent 15:56:00 <amotoki_> can we detect D-plane disconnectivity? I think it is the role of some external monitoring. 15:56:01 <armax> but that’s as easy as disabling the nova compute host 15:56:14 <armax> and then a new VM will never land on that host 15:56:32 <cgoncalves> amotoki_: +1 15:56:45 <kevinbenton> cgoncalves: right, but if this spec isn't about forcing immediate rescheduling, why doesn't admin-state-down satisfy the requirements? 15:56:55 <armax> perhaps we can talk a bit more on the bug report, but I am wondering if this is an overkill right now 15:57:19 <ajo> I agree with kevinbenton , or wonder like him, cgoncalves , can you explain where --admin-state-down is not enough? 15:57:44 <cgoncalves> kevinbenton: it could be up the admin to decide if and how to recover 15:58:03 <kevinbenton> cgoncalves: in which case admin-state-down should work IIUC 15:58:10 <kevinbenton> right, let's move discussion to bug report to clarify 15:59:01 <armax> ok 15:59:05 <regXboi> before we break up, armax: can I suggest that 1512864 be marked as being something that should be done in oslo for all projects? the performance group in #openstack-performance is talking about osprofiler, which (with improvement) will cover this ask 15:59:18 <amotoki_> bug 1512864 15:59:18 <openstack> bug 1512864 in neutron "Application Metrics for Neutron" [Low,Triaged] https://launchpad.net/bugs/1512864 - Assigned to Ramu Ramamurthy (ramu-ramamurthy) 15:59:18 <regXboi> I think 16:00:19 <ajo> I agree, why not leveraging integration with osprofiler, and extending osprofiler where necessary 16:00:46 <ajo> (I miss where osprofiler needs extension I thought it covered it all, but I'm likely to be wrong) 16:00:51 <armax> we’re out of time 16:00:53 <carl_baldwin> time is up 16:00:56 <armax> #endmeeting