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