18:00:45 <SumitNaiksatam> #startmeeting networking_policy
18:00:46 <openstack> Meeting started Thu Jul 31 18:00:45 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:47 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:50 <openstack> The meeting name has been set to 'networking_policy'
18:01:07 <SumitNaiksatam> https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy#July_31st.2C_2014
18:01:14 <SumitNaiksatam> #info agenda https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy#July_31st.2C_2014
18:01:38 <SumitNaiksatam> #topic Patches in review
18:01:48 <SumitNaiksatam> #link https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy/Patches
18:02:17 <SumitNaiksatam> there is a long standing -2 on the first patch of the series from markmcclain
18:02:54 <SumitNaiksatam> i have pointed this out in the -dev mailing list
18:03:08 <SumitNaiksatam> we also requested markmcclain to attend this meeting
18:03:15 <SumitNaiksatam> however, he does not seem to be online
18:03:35 <mandeep> mestery: How should we proceed on this?
18:03:54 <SumitNaiksatam> we have one +2 from rkukura on the patch
18:04:05 <mestery> mandeep: It's hard to proceed unless markmcclain is here, I believe he's on a plane returning from the nova mid-cycle at the moment, but I'm not 100% sure.
18:04:21 <SumitNaiksatam> mestery: okay
18:04:37 <mandeep> mestery: Quoting salvatore from the mailing list:
18:04:39 <mandeep> I try to avoid -2s as much as possible. I put a -2 only when I reckon your
18:04:39 <mandeep> patch should never be merged because it'll make the software unstable or
18:04:39 <mandeep> tries to solve a problem that does not exist. -2s stick across patches and
18:04:41 <SumitNaiksatam> mestery: from a project process/policy perspective, is there any remediation to this?
18:04:41 <mandeep> tend to put off other reviewers.
18:05:15 <SumitNaiksatam> mestery: the issue has been raised in the mailing list as well
18:05:16 <mandeep> mestery: Would you consider this appropriate use of -2 (assuming that definition)?
18:05:29 <rkukura> I don’t think it would hurt to encourage other core reviewers to review the initial patches and place their votes.
18:05:33 <mestery> SumitNaiksatam: As I've indicated before, I can't make people remove -2s. We need Mark to respond to this and remove the -2 or justify it at this point, and he hasn't done either.
18:05:47 <mandeep> mestery: And also raised on 1-1 email and IRC chats
18:06:13 <SumitNaiksatam> mestery: my suggestion, and as stated before as well, was never to ask you to ask markmcclain to remove his -2
18:06:15 <mandeep> mestery: Can you, as the PTL, take the action item to follow up on this?
18:06:31 <SumitNaiksatam> mestery: the suggestion was to find out why the -2 still persists
18:06:45 <mestery> mandeep: I have already spoken to Mark many times about this to no avail.
18:06:49 <mestery> SumitNaiksatam: ++
18:06:59 <mestery> SumitNaiksatam: That's really the crux, and I haven't had luck in getting that information out.
18:07:13 <SumitNaiksatam> mestery: okay, we know you have tried
18:07:40 <SumitNaiksatam> mestery: at this point, and in this forum, we are just trying to find out, from a process perspective, what needs to be done
18:07:56 <regXboi> sorry all - ODL TSC call running late
18:08:01 <regXboi> so I'm here - but not here
18:08:09 <regXboi> so please move my agenda item to near the end
18:08:20 <ivar-lazzaro> mestery: should there be a "no answer" time limit before the community takes action in these situations? (e.g. voting in the ML so that the PTL removes the -2?)
18:08:21 <SumitNaiksatam> mestery: alternatively, if there is no process/policy in place for this, we probably need to formulate a reasonable one
18:08:28 <SumitNaiksatam> ivar-lazzaro: +1
18:08:46 <SumitNaiksatam> i believe, as a core, i am accountable to the -2 i put
18:09:16 <regXboi> ok... here now
18:09:17 <SumitNaiksatam> so, if i put a -2, and a new patch set is posted, i review the -2 again
18:09:30 <SumitNaiksatam> i believe that should be an explicit process that everyone should follow
18:09:38 <regXboi> SumitNaiksatam: you can say that here
18:10:01 <ivar-lazzaro> SumitNaiksatam: +1
18:10:03 <SumitNaiksatam> if a new patchset is posted, i think the onus is on the core who put the -2, to justify why it should persist
18:10:16 <regXboi> but since there hasn't been any email on the ML archives, I can't point to any public record of asking for the -2 to be reviewed
18:10:38 <regXboi> there is finally something in the patch set archives, but that's semi-ephermeal
18:10:55 <SumitNaiksatam> regXboi: there are explicit guidelines to not hound reviewers on the -dev mailing list for reviews
18:10:59 <mandeep> mestery: Do you agree that the process is broken and needs to be addressed? It was also being discussed on the mailing list todayt morning
18:11:05 <rkukura> regXboi: I explicitly asked Mark to either remove or justifiy his -2 in my review where I voted +2.
18:11:13 <mandeep> mestery: http://lists.openstack.org/pipermail/openstack-dev/2014-July/041651.html
18:11:25 <regXboi> rkukura: yes, that's the comment I was referring to
18:11:57 <regXboi> and mandeep: that's a reasonable email
18:11:59 <mandeep> regXboi: We are forbidden to ask for reviews on the mailing list.
18:12:36 <mandeep> regXboi: And that is why we have been sending 1-1 emails to ask for re-review
18:12:53 <SumitNaiksatam> regXboi: regardless, you cant reason that the -2 persists because there wasnt an email in the mailing list pointing to it, its the duty to of the core to remove the -2 if the circumstances under which he put the -2 have changed
18:12:58 * regXboi notes that rule is not in the interests of transparency
18:13:25 <mandeep> regXboi: I am asking mestery if the process should be updated if multiple teams are hitting similar issues?
18:13:26 <regXboi> SumitNaiksatam: that is not my point at all
18:13:54 <regXboi> my point is that a rule not asking for a re-review on the ML is not in the interests of transparency
18:14:04 <SumitNaiksatam> okay, we dont intend this to be a meeting where we fix neutorn process/policy issues, i think this team deserves to know why the patch is not allowed to make progress
18:14:14 <regXboi> because my first reaction would be (at this point) to say "d*mn the rules" :-)
18:14:19 <regXboi> but that's me
18:14:21 <SumitNaiksatam> hence this is being brought up in the agenda here
18:14:51 <SumitNaiksatam> the hope was that markmcclain would have been able to attend so that he could explain to the team
18:15:06 <mestery> regXboi: ++, there isn't any concern with sending these types of requests to the mailing list, in fact, in this case, that's where it should be discussed
18:15:20 <SumitNaiksatam> unfortunately it seems that he is travel
18:15:22 <mandeep> regXboi: And we are asking mestery (PTL) for direction
18:16:18 <SumitNaiksatam> mestery: so how is asking for a request to review a -2 different from asking for a request to review a patch (the latter is explicitly prohibited)
18:16:52 <mestery> My point here is that in this case, with a lingering -2, I fail to see how requesting on the list is out of bounds, in fact, it's like a last resort IMHO.
18:17:15 <SumitNaiksatam> mestery: okay, thanks for that guidance
18:17:35 <SumitNaiksatam> mestery: that said, this has already been raised in the email that i sent out yesterday
18:17:37 <ivar-lazzaro> mestery: well, technically they core could ignore the ML thread as well :D
18:18:10 <ivar-lazzaro> they -> the
18:18:11 <regXboi> ivar-lazzaro: true, but then the weight of public opinion shifts
18:18:47 <ivar-lazzaro> I had the impression that -2s were a technical issue, not a political one
18:18:59 <SumitNaiksatam> regXboi: why should we have to waste time in the first place having to build the weight of the public opinion in one way or the other//
18:19:00 <mandeep> regXboi: I hope we are not becoming politicians and responding to public opinion as opposed to technical concerns
18:19:14 <SumitNaiksatam> mandeep: exactly my point
18:19:17 <regXboi> ok folks, let's be real here
18:19:28 <regXboi> any time you have more than 2 people and money on the table, you have policics
18:19:31 <regXboi> er politics
18:19:51 <rkukura> we need some checks and balances, it seems
18:19:53 <SumitNaiksatam> ok i will have to reign it here!
18:19:53 <regXboi> even in the perceived optics of the situation there are politics
18:19:57 <s3wong> In terms of policy change - one way to do so may be how contributors can vote for PTL, contributors can also vote for or against cores
18:20:06 <regXboi> SumitNaiksatam: ++ :)
18:20:17 <SumitNaiksatam> ok so moving on for the time being
18:20:21 <SumitNaiksatam> all good suggestions
18:20:37 <SumitNaiksatam> had to allow everyone (including myself) to vent a little! ;-P
18:20:39 <mandeep> s3wong: That is a good idea
18:20:52 <ivar-lazzaro> s3wong: +1
18:20:58 <mandeep> s3wong: If the public opinion is going to decide it, let the ATC decide it
18:21:08 <SumitNaiksatam> the other update on the patch series is that all the three series are linear now
18:21:22 <SumitNaiksatam> that means you can go to GP-PLG-3 and be able to pull everything before it
18:21:44 <mandeep> SumitNaiksatam: Thanks. That helps a lot!
18:21:57 <SumitNaiksatam> GP-PLG-3 did not pass jenkins because a db migration is dated
18:22:06 <SumitNaiksatam> but it passes UTs, and should be functional
18:22:29 <SumitNaiksatam> mestery: before i forget, thanks for stopping by and providing guidance
18:23:07 <SumitNaiksatam> any questions on series 1, 2, and 3?
18:23:29 <regXboi> other than I have to check that I've got +1s on all of them - no :)
18:23:43 <SumitNaiksatam> regXboi: thanks ;-)
18:23:49 <SumitNaiksatam> thanks for reviewing that is
18:24:14 <SumitNaiksatam> GP-*-1, and GPM-*-1 were rebased until yesterday
18:24:28 <SumitNaiksatam> GP-*-2/3 need to rebased
18:24:59 <SumitNaiksatam> #topic Mapping model/driver update
18:25:08 <SumitNaiksatam> rkukura: over to you, anything new to report here?
18:25:16 <mandeep> with DB migrations in place we will have to rebase often, and that will keep wiping off all the +1s - perhaps gerrit should not wipe out +1s for dbmigration updates
18:25:44 <regXboi> mandeep: that's actually a good point for reviewers - be prepared to do a lot of repeat +1s :/
18:25:45 <SumitNaiksatam> mandeep: ah, did not think of that, not sure how easy/difficult it is to achive that
18:25:56 <rkukura> the DB migration for gpm-db-1 was a bit of a challenge, but thanks to HenryG and akamyshnikova, its all worked out
18:26:06 <SumitNaiksatam> regXboi: thanks for accepting that responsibility! :-)
18:26:24 <SumitNaiksatam> rkukura: that was great that you were able to fix those issues
18:26:36 <regXboi> SumitNaiksatam: I have been - I've got filters on all the re-review mails so I can hit them first thing in the morning :)
18:26:49 <SumitNaiksatam> rkukura: any short pointers for the rest of the team here in terms what you did to get around the issue?
18:26:53 <mandeep> regXboi: I agree :-(
18:26:55 <rkukura> I’ll probably include some more validation checks in a gpm-rmd-1 update at some point
18:27:06 <SumitNaiksatam> regXboi: sounds very organized, great!
18:27:24 <rkukura> One issue was that alembic sometimes does not generate the foriegn key constraints that are in the model
18:28:35 <rkukura> Also, when removing columns in a downgrade, some constraint types need to be removed first, and others don’t
18:28:41 <SumitNaiksatam> rkukura: ah okay, so you had to manually add those?
18:28:52 <rkukura> Its very easy to test the migrations if you’ve got a devstack environment
18:28:55 <SumitNaiksatam> rkukura: i mean the foreign key
18:28:56 <regXboi> rkukura: is *that* what that was all about
18:29:28 * regXboi mutters ugly things about code that sometimes does things and sometimes doesn't
18:29:34 <SumitNaiksatam> for reference, its the DB migration in this patch #link https://review.openstack.org/#/c/101795
18:29:50 <rkukura> I had to manually add the code add and remove foreign keys, and remove the generated code for removing unique constraints
18:30:09 <SumitNaiksatam> rkukura: ok cool, i guess we can follow that example in the future
18:30:17 <s3wong> rkukura: wouldn't the code be regenerated to remove your manual changes?
18:30:17 <rkukura> akamyshnikova is very helpful on reviewing these, and tested the latest version with postgresql as well
18:30:33 <SumitNaiksatam> rkukura: sweet
18:30:38 <rkukura> we don’t usually regenerate the migration code
18:30:45 <rkukura> its a generate once, then edit, process
18:30:53 <SumitNaiksatam> akamyshnikova: much appreciated!
18:30:59 <rkukura> the generated migrations always need some cleanup
18:31:03 <SumitNaiksatam> rkukura: also the issues that you ran into for generating the migration
18:31:18 <SumitNaiksatam> rkukura: is the env module change merged upstream?
18:31:47 <rkukura> SumitNaiksatam: Right, not sure if my workaround would still be needed. Hopefully its fixed.
18:32:06 <SumitNaiksatam> rkukura: ah ok
18:32:32 <SumitNaiksatam> any questions for rkukura on the mapping part? (since hopefully you are reviewing that right now ;-P )
18:33:08 <rkukura> So s3wong is making good progress on  the next step of the mapping - creating SGs for enforcement of the policy rules.
18:33:23 <SumitNaiksatam> rkukura: yeah thats next on the agenda item
18:33:38 <SumitNaiksatam> #topic Security Groups mapping update
18:33:55 <SumitNaiksatam> s3wong: your turn :-)
18:34:21 <s3wong> So I have been coding up the contract=>SG mapping
18:35:12 <s3wong> so far I coded up the create/update/delete_contract part, and the create/update_EPG part (the latter almost done)
18:35:22 <s3wong> still need to test, get them ready for gerrit
18:35:28 <SumitNaiksatam> s3wong: okay nice
18:35:29 <regXboi> s3wong: I see you want to defer the question of "which SG is matched" to the drivers, which is fair
18:35:31 <s3wong> also adding unit test as I go along
18:35:46 <SumitNaiksatam> regXboi: good point to bring up
18:35:49 <regXboi> but that begs the question of how the driver in the patch set will handle that
18:36:10 <SumitNaiksatam> so at this point, we think that the SG mapping is neutron resource mapping driver specific
18:36:27 <regXboi> SumitNaiksatam: yes I think defering to the drivers is the right answer
18:36:39 <regXboi> but if this includes a sample driver, that has to answer it :/
18:36:46 <s3wong> regXboi: yes, now it is rendered directly by the mapping driver
18:37:15 <SumitNaiksatam> regXboi: in terms of patch logistics, this will be a new GPM-RMD-3 patch, right s3wong?
18:37:38 <s3wong> SumitNaiksatam: that's correct
18:37:42 <regXboi> works for me
18:37:50 <regXboi> and I'll be reading when it arrives :)
18:38:16 <SumitNaiksatam> okay any other questions for s3wong?
18:38:24 <s3wong> so yeah, guys - stay tuned, patches will come soon
18:38:36 <SumitNaiksatam> s3wong: any blockers for you at this point?
18:38:46 <s3wong> SumitNaiksatam: no
18:39:02 <s3wong> SumitNaiksatam: able to proceed well since you rebased
18:39:22 <SumitNaiksatam> s3wong: ok good to hear
18:39:30 <SumitNaiksatam> moving on
18:39:40 <SumitNaiksatam> #topic CLI/Client
18:39:55 <SumitNaiksatam> regXboi: we will get to your part in a bit
18:39:58 <SumitNaiksatam> lets first get the update
18:40:02 <SumitNaiksatam> songole: there?
18:40:14 <songole> yes SumitNaiksatam
18:40:35 <songole> Update: posted patches for all GBP resources
18:40:43 <songole> tests are pending
18:41:12 <songole> Need to handle mapping extension
18:41:27 <LouisF> songole: what are patch numbers?
18:41:53 <mandeep> songole: I have created a couple of public devstack VMs to do integration of the mapping driver, let me know if you need access to that.
18:42:07 <songole> https://review.openstack.org/#/c/104013/
18:42:17 <songole> it has dependency links to others
18:42:17 <regXboi> um
18:42:30 <regXboi> that patch doesn't cover anything past -1
18:42:42 <regXboi> when are -2 and -3 going to be added?
18:43:04 <songole> regXboi: they are all added
18:43:13 <mandeep> regXboi: https://review.openstack.org/#/c/110798/
18:43:23 <mandeep> regXboi: https://review.openstack.org/#/c/110806/
18:43:31 <SumitNaiksatam> songole: i am not sure i understood “Need to handle mapping extension”
18:43:40 <songole> mandeep: thanks
18:43:41 <mandeep> regXboi: (added links for the record)
18:44:01 <regXboi> um... thos patches aren't listed in the wiki?!?!
18:44:04 <regXboi> *those
18:44:20 <songole> SumitNaiksatam: end point can take a port, l2 policy could take a network
18:44:30 <songole> those options need to be added to CLI-1
18:44:33 <SumitNaiksatam> songole: oh okay, got it
18:45:05 <SumitNaiksatam> regXboi: point noted
18:45:22 <SumitNaiksatam> songole: can you please update the wiki page: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy/Patches
18:45:32 <songole> mandeep: I will ping on reg those public devstack setups
18:45:39 <songole> SumitNaiksatam: will do
18:45:45 <regXboi> SumitNaiksatam, songole: thanks - I've been driving reviews based on that webpage
18:45:55 <mandeep> songole: OK
18:46:02 <SumitNaiksatam> btw, comment not directed just to songole, anyone if you see the wiki is outdated, please update with your patch link
18:46:05 <SumitNaiksatam> *links
18:46:12 <regXboi> ++
18:46:30 <SumitNaiksatam> regXboi: that was the reason we put the wiki, so you are right in going by that
18:46:37 <mandeep> regXboi: agreed
18:46:57 <SumitNaiksatam> songole: thats excellent progress, thanks much!
18:47:20 <SumitNaiksatam> ok now to regXboi’s suggestion
18:47:30 <SumitNaiksatam> #topic “Profiled” API
18:47:39 <SumitNaiksatam> regXboi: the floor is yours :-)
18:47:44 <regXboi> folks have probably all seen the email, but let's link it in for the record
18:48:26 <regXboi> the idea is to bring back support for the 2-group approach with minimal intrusiveness
18:48:46 <regXboi> #link http://lists.openstack.org/pipermail/openstack-dev/2014-July/041467.html
18:48:57 <SumitNaiksatam> regXboi: thanks was just about to post the link
18:49:17 <regXboi> the suggestion is to do this as a patch on CLI-3 (call it CLI-4) because it is a departure from normal openstack convention
18:49:25 <regXboi> and we can go that direction
18:49:45 <SumitNaiksatam> regXboi: ah cool
18:49:46 <regXboi> with the caveat that we may have to pry open the API to allow the CLI patch to make a single call to neutron
18:50:18 <mandeep> regXboi: That also answer a few questions on what a "profiled API" is,
18:50:20 <regXboi> IIRC the 2-group approach didn't discuss about reuse of policy information, so I have some freedom in trying to make that work
18:50:40 <regXboi> mandeep: the idea of a profiled API come from IETF and other places
18:50:46 * regXboi goes and gets links
18:51:07 <mandeep> regXboi: The patch can also include diffs to other resources (as required), and we can review them as a single change
18:51:10 <SumitNaiksatam> regXboi mandeep: i am still mystified by the term “profiled”, but i am just ignorant!
18:51:24 <regXboi> examples of what I mean:
18:51:33 <regXboi> OASIS (for SAMLv2): http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
18:51:41 <regXboi> Encryption and Checksum Specifications for Kerberos 5: http://tools.ietf.org/html/rfc3961
18:51:47 <regXboi> Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile: http://www.ietf.org/rfc/rfc3280.txt
18:51:49 <SumitNaiksatam> regXboi: thanks
18:51:51 <mandeep> regXboi: I am not familiar wit that, but it sounds like an interesting idea.
18:51:53 <regXboi> Internet X.509 Public Key Infrastructure Qualified Certificates Profile: http://ftp.isi.edu/in-notes/rfc3039.txt
18:52:03 <mandeep> regXboi: I will check the link. Thanks.
18:52:08 <regXboi> the point being to define common sets of values for otherwise complex things
18:52:15 <SumitNaiksatam> regXboi: can you explain what you mean by “we may have to pry open the API”
18:52:26 <regXboi> SumiNaiksatam: sure
18:52:42 <banix> SumitNaiksatam: looking at neutron client i do not see any command that leads to anything but a single crud call to neutron. don’t you think departure from that will be difficult?
18:52:54 <regXboi> the issue that may arise is that the CLI is going to make multiple calls to neutron backend
18:53:30 <regXboi> so if folks complain that is uncoventional, we may have to allow the CLI to make a single call and move the profile in to the API side of the patch
18:53:32 <SumitNaiksatam> banix: yeah, this amounts to some orchestration on the client side
18:53:48 <songole> regXboi: CLI is not an orchestrator today. Do you think heat might be a better place to put it?
18:53:52 <regXboi> point folks: HEAT is already doing some orchestration on the client side
18:54:05 <regXboi> songole: no... because that bypasses horizon
18:54:27 <SumitNaiksatam> regXboi: i think we have some freedom to do the same orchestration in Horizon
18:54:40 <regXboi> that's doing double the necessary work
18:54:44 <mandeep> regXboi: If new orchestration is involved, do you think that we will need do a BP as well?
18:55:02 <regXboi> mandeep: I don't believe so but I don't *know*
18:55:20 <SumitNaiksatam> i dont think we need a new BP if only client side changes are involved
18:55:21 <regXboi> mestery might have some input here....
18:55:32 <mandeep> regXboi: Horizon equivalent of orchestration can be a wizard, but if needed it should be able to do the orchestration
18:55:51 <SumitNaiksatam> mandeep: yeah, thats what i was thinking as well
18:55:51 <mestery> regXboi: Lets discuss this and see, I don't know off the top of my head
18:55:57 <mandeep> regXboi: But I will need to check if that is being done for now
18:56:03 <regXboi> mandeep: that's not my point - somebody sharp might go "why are you doing this twice?"
18:56:16 <SumitNaiksatam> mestery: any restrictions on doing some orchestration on the client side?
18:56:17 <regXboi> and we won't have a good answer at that point
18:56:33 <SumitNaiksatam> mestery: i am not aware that there are, but i dont think that there is a precedent either
18:56:49 <mestery> SumitNaiksatam: ++, I'm not sure either
18:56:50 * regXboi is known for setting precedents :)
18:57:08 <SumitNaiksatam> regXboi: i think if its reasonable, there is always a first!
18:57:18 <regXboi> anyway... that's the idea
18:57:29 <regXboi> I was going to say I needed CLI-3 as a starting point
18:57:32 <SumitNaiksatam> regXboi: okay thanks
18:57:37 <regXboi> but now that is there :)
18:57:55 <SumitNaiksatam> regXboi: yes we have to thank songole for getting it in expeditiously
18:57:57 <mandeep> regXboi: A quick look at the example profile API links, I would have expected a BP for such a chnage.
18:58:18 <LouisF> regXboi: should CLI be: neutron policy-apply [contract] [src group] [destination group]
18:58:40 <regXboi> LouisF: I think policy-apply will need to change to be consistent with CLI-3
18:58:42 <rkukura> One thing to keep in mind is that the GP API in Juno will be considered experimental, so tweeks to make it more usable in Kilo are certainly possible, even breaking backward compatibility. This CLI approach could be thought of as a temporary workaround.
18:58:55 <regXboi> rkukura: ++
18:59:10 <LouisF> rkukura: ++
18:59:14 <regXboi> mandeep: I'm not sure I agree with you, but that's just my opinion
18:59:23 <banix> mandeep: regXboi is not suggesting a generic profiled cli; just use of the concept; even that in my opinion it wont get through but i am a bit too cynic at this point
18:59:36 <regXboi> banix: thanks for pointing that out
18:59:40 <SumitNaiksatam> rkukura: agree
18:59:54 <regXboi> I am *NOT* suggesting a general framework - that's a whole different kettle of fish
19:00:00 <regXboi> I'm talking about a one off
19:00:01 <mandeep> banix: Thanks for the clarification
19:00:33 <mandeep> regXboi: But hopefully a one-off that sets a precedence for other similar updates ... ;-)
19:00:34 <SumitNaiksatam> regXboi: it sounds perfectly reasonable to me suggest this approach in a patch
19:00:36 <regXboi> anyway - we're at the top of the hour - any more questions?
19:00:51 <mandeep> SumitNaiksatam: +1
19:00:54 <SumitNaiksatam> regXboi: thanks for that update and clarification
19:00:55 <banix> I left a comment at #link https://review.openstack.org/#/c/103755/ a few days ago on Patch Set 3; i think regardless of what Ryan is suggesting this should be trivial to do; do you guys see any reason why it cannot be done?
19:01:08 <SumitNaiksatam> banix: sorry i missed that
19:01:09 <regXboi> and if I'm not here - reply to the thread on the ML
19:01:20 <SumitNaiksatam> banix: until you pointed out in the email thread
19:01:23 <SumitNaiksatam> banix: i will respond
19:01:44 <SumitNaiksatam> #topic API Intercept
19:01:54 * regXboi pads away
19:01:56 <SumitNaiksatam> just a quick plug for the work kevinbenton has been doing #link https://review.openstack.org/#/c/109901
19:02:09 <SumitNaiksatam> #topic Open Discussion
19:02:21 <SumitNaiksatam> we will need to wrap up quickly since we are over
19:02:32 <SumitNaiksatam> we did not touch on the vendor drivers today
19:02:37 <rkukura> I’ve started looking at the intercept patch, but need to spend more time to understand it.
19:02:46 <SumitNaiksatam> but hopefully people are thinking about it and are not overly blocked
19:02:50 <mandeep> Same here
19:03:00 <SumitNaiksatam> rkukura mandeep: thanks
19:03:02 <rms_13> +1
19:03:18 <SumitNaiksatam> rms_13: any quick update on Horizon?
19:03:32 <SumitNaiksatam> horizon integration that is
19:03:36 <rms_13> Not today. For sure next thursday as I am going to work full time on it tomorrow
19:03:49 <SumitNaiksatam> rms_13: nice, looking forward to it
19:03:49 <rms_13> Abishek is going to do initial glance
19:03:56 <SumitNaiksatam> rms_13: okay
19:04:13 <SumitNaiksatam> rms_13: you might want to look at songole’s new patches
19:04:24 <rms_13> Yes. That is going to change my current patch
19:04:44 <SumitNaiksatam> alright anything else, anyone?
19:05:11 <SumitNaiksatam> alright, thanks all for joining
19:05:17 <banix> bye
19:05:19 <rms_13> by
19:05:21 <songole> bye
19:05:24 <rkukura> bye
19:05:25 <SumitNaiksatam> until next week, but please keep reviewing
19:05:29 <LouisF> rms_13: has horizon ptach been updated?
19:05:30 <SumitNaiksatam> bye
19:05:38 <mandeep> bye
19:05:45 <SumitNaiksatam> #endmeeting