18:00:17 <bh526r> #startmeeting gluon
18:00:18 <openstack> Meeting started Wed Apr 26 18:00:17 2017 UTC and is due to finish in 60 minutes.  The chair is bh526r. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:22 <openstack> The meeting name has been set to 'gluon'
18:00:39 <bh526r> #topic Roll Call
18:00:43 <bh526r> #info Bin Hu
18:00:52 <krenczewski> #info Kamil Renczewski
18:00:57 <bh526r> Hi Kamil
18:01:01 <krenczewski> Hi Bin
18:01:13 <pcarver> #info Paul Carver
18:01:49 <jinli> Hi everyone
18:01:53 <jinli> #info JinLi
18:02:30 <bh526r> #topic Admin Update
18:03:11 <bh526r> #info Not much update, but focusing on preparing the PoC in Boston
18:03:53 <bh526r> #info such as demo script, slides, YAML files, and recorded video
18:04:24 <bh526r> #info and staffing plan for OPNFV Booth and AT&T Booth etc.
18:04:56 <bh526r> #topic PoC Status Update
18:05:29 <bh526r> #info Georg has upgraded lab deployment with most recent master branch yesterday
18:06:10 <bh526r> #info Bin and Georg will try to test adding/removing some dummy YAML and see how demo scenario should work
18:07:07 <bh526r> #info Now Contrail Status
18:07:17 <bh526r> Kamil, any new information?
18:07:32 <krenczewski> Contrail node is in pretty same state as przeviously
18:08:04 <bh526r> I see. So vRouter and Contrail Controller are still not working
18:08:04 <krenczewski> I am not sure how bad is it, is looks like most functions work correctly
18:08:28 <krenczewski> I asked Nachi and Sukhdev to verify installation and help with it
18:08:36 <krenczewski> but didn't get any response yet
18:08:43 <bh526r> I see.
18:09:00 <krenczewski> I've deployed ContrailMechanismDriver today
18:09:19 <bh526r> Anything you think I can help? e.g. should I ask Nachi and Sukhdev?
18:09:21 <krenczewski> But didn't have time to play with it yet
18:09:41 <krenczewski> I saw that it is not loaded by neutron and need to investigate this\
18:09:48 <bh526r> I see. That is a good progress of having deployed ContrailMechanismDriver
18:10:22 <bh526r> Of course, just keep on investigating it.
18:10:26 <krenczewski> I am afraid that gluon might mess up with ML2 core plugin
18:10:50 <krenczewski> I am not sure how gluon works and if it allow other ML2 mechanism drivers to work
18:11:15 <krenczewski> Do you know anything about that?
18:11:42 <bh526r> Here is the link of Gluon Core Plugin Code
18:12:02 <bh526r> https://github.com/openstack/gluon/blob/master/gluon/plugin/core.py
18:12:37 <krenczewski> I'll try to check tomorrow
18:12:57 <bh526r> Basically, Gluon Core Plugin Code extends/subclasses original Ml2Plugin
18:13:00 <pcarver> if I understand correctly the Contrail mechanism driver should be called by the Gluon core plugin instead of ML2
18:13:28 <pcarver> so Gluon replaces ML2 entirely but inherits the functionality from ML2
18:13:41 <krenczewski> So this should work the same and probably I messed up something
18:13:50 <bh526r> That's right in terms of configuration
18:14:07 <krenczewski> everything looks a little different than on devstack installations and I might forgot about something
18:14:07 <bh526r> Neutron will load Gluon Core Plugin instead of ML2 Plugin
18:14:27 <bh526r> The configuration in lab is based on Fuel
18:14:59 <bh526r> So that might be related to how to configure Mechanims Driver in Fule OpenStack, which is different from Devstack
18:15:17 <krenczewski> Probably this is the case
18:15:40 <bh526r> In terms of how Gluon Core Plugin works, Neutron loads Gluon Core Plugin instead of original ML2 Plugin
18:16:28 <bh526r> Then if the ports from Neutron is Proton port, Gluon Core Plugin will give the control to Proton Server
18:17:04 <bh526r> Otherwise, if the ports from Neutron are Neutron ports (which is for Contrail), Gluon Core Plugin gives the control to original ML2 Plugin
18:17:43 <bh526r> The the original ML2 Plugin should interact with ContrailMechanismDriver (as if it is the original Neutron)
18:18:11 <bh526r> I assume ContrailMechanismDriver works with ML2 Plugin in Devstack
18:18:39 <bh526r> But the configuration in Fuel OpenStack is different from DevStack
18:18:42 <krenczewski> Correct
18:18:52 <krenczewski> I'll investigate this tomorrow
18:19:10 <bh526r> Thank you Kamil.
18:20:43 <bh526r> If after your investigation, it can work, great
18:21:12 <bh526r> If your investigation shows some bugs in Gluon Core Plugin code, then it needs to be fixed
18:22:03 <bh526r> The whole purpose of this lab setup is to make sure that it works as expected, and fix any bugs/issues wherever it is.
18:22:26 <bh526r> So thank you Kamil for your hard work
18:24:24 <bh526r> #info Kamil deployed ContrailMechanismDriver, and will continue to investigate the issue of interacting with Neutron via ML2 Plugin through Gluon Core Plugin
18:24:56 <bh526r> #info Contrail issue still the same situation as last week. Kamil asked for help from Contrail experts, but no response yet
18:25:52 <bh526r> #info SFC YAML is still under review, and should be available later this week.
18:26:29 <pcarver> I have a general question protons
18:26:44 <bh526r> #info Robert continues to work with Ian on P2P YAML, and possibly how to demo the data from Proton API passes through etcd and reaches backend
18:26:52 <bh526r> sure, Paul
18:27:08 <pcarver> Once we have the YAML, does the particle generator automatically spit out a description of the API that can be used to invoke it?
18:27:31 <pcarver> I know we have documentation that was specifically written for the L3VPN proton
18:27:54 <pcarver> does someone need to read the YAML and write similar documentation for the SFC proton?
18:28:08 <bh526r> Good question. It should, but I haven't tested it yet, because of lack of YAML
18:28:35 <bh526r> No, user shouldn't read YAML.
18:28:50 <pcarver> is the particle generator directly runnable from a clone of the gluon repo or does it require a fully installed and running system?
18:29:24 <bh526r> It can be imported to be used for other programs
18:29:54 <bh526r> https://github.com/openstack/gluon/tree/master/gluon/particleGenerator
18:30:32 <bh526r> from gluon.particleGenerator import generator as particle_generator
18:31:09 <bh526r> So if you want to reuse it in other programs, very welcome
18:32:01 <pcarver> What I'm trying to figure out, is if I have a YAML file, can I just clone the gluon repo and run particleGenerator.py <YAML_file> and get an output where I can see the REST API calls that the generated proton will support
18:32:36 <pcarver> i.e. the GET/POST/PUT/DELETE and the corresponding URLs and the valid JSON fields that the user needs to supply
18:33:35 <bh526r> I see. No, not the original intention of using it this way.
18:33:40 <pcarver> or do I need to actually have Gluon/Proton servers up and running and issue curls against them to figure out what to expect
18:34:08 <pcarver> how does a user figure out what REST calls they can make against a given proton?
18:34:15 <bh526r> Yes, either curl or use protonclient
18:34:59 <bh526r> We are working on a general documentation of how to find it out
18:35:18 <bh526r> Similar to how Neutron documents their REST APIs
18:35:42 <pcarver> but how to figure out what the URLs are, what parameters to put in the JSON? Is that self documenting or does someone have to write both the YAML and a corresponding prediction of what the generated proton's API will look like?
18:37:01 <bh526r> Jin is working on version management improvement. Part of it is that it user hits specific version of Proton, it will return JSON of arguments of APIs
18:37:22 <bh526r> And a general documentation will describe how to interpret this JSON
18:38:01 <pcarver> every YAML will potentially create a totally new API that might look nothing like any other API, right?
18:38:24 <bh526r> https://review.openstack.org/#/c/456772/5/doc/source/devref/gluon_proton_versioning.rst
18:39:01 <bh526r> At the end, an example shows what happens after hitting "http://192.168.59.103:2705/proton/net-l3vpn/v1/"
18:39:33 <bh526r> A general documentation is needed to show user how to interpret it
18:40:24 <bh526r> And the usage of GET/POST/PUT/DELETE is standard for all Protons
18:41:02 <bh526r> If you can think of a better way to document considering new unknow Protons, please let me know
18:41:32 <pcarver> the verbs are standard, but you've got to figure out what specific URLs to use and what to put in the JSON, right? Do we essentially reverse engineer that by reading the YAML file?
18:42:54 <bh526r> YAML is based on the design, which is documented in https://github.com/openstack/gluon/blob/master/doc/source/devref/gluon_api_spec.rst
18:43:06 <bh526r> So we don't need to reverse engineer
18:43:22 <bh526r> But to document the original design in a way of more user friendly
18:43:40 <pcarver> That document doesn't say anything about SFC
18:44:37 <pcarver> I'm trying to compare the proton SFC API to https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst
18:45:49 <bh526r> If you mean how to use a particular Proton API, with a particular flow, the party who provides this Proton needs to provide a more detailed documentation of whow to use this Proton with flows and examples
18:46:43 <bh526r> e.g Step One, use <API A>, Step 2, use <API 2>, ... this sequence of using APIs to achieve a function
18:47:01 <bh526r> Those steps and flows are specific for particular Protons
18:47:04 <pcarver> yes, I'm looking to compare the API that the user would see with gluon/proton SFC to the API the user would see with networking-sfc
18:47:14 <bh526r> Every Proton will have different steps and flows
18:48:17 <bh526r> We don't have gluon/proton SFC yet. Georg/Ericsson is still reviewing it within Ericsson for IPR review before they can contribute it to community
18:48:37 <pcarver> right, I know, but I'm expecting to see it up on Gerrit any day now
18:48:51 <pcarver> and I'm trying to figure out what to do with it when I see it
18:49:11 <bh526r> Yes.
18:49:17 <pcarver> I assume that I run particleGenerator.py on it, but I'm not sure that's right and I'm not sure what output to expect
18:49:37 <bh526r> Just run it and see what will happen :)
18:50:18 <pcarver> and I'm not sure if I need a fully running gluon/proton server or if I can just run particleGenerator.py with no gluon or OpenStack or ODL/Contrail installed
18:50:22 <bh526r> But I doubt that it will give those usage documentation (flows, examples etc.)
18:50:58 <jinli> paul you can follow install_gluon.rst to set up the server, George had all the steps there. you need step 1 to step 8
18:51:14 <jinli> then you can run curl url
18:51:14 <bh526r> I would just clone the whole project, without running proton server or any configuration, run that py and see what will happen
18:52:16 <pcarver> ok
18:52:51 <bh526r> Try to break it, and it will help us improve it in terms of code, usage, documentation etc.
18:53:41 <bh526r> any question?
18:54:22 <pcarver> I'll give it a try as soon as Georg uploads the YAML for review
18:54:34 <bh526r> Great, thank you Paul
18:55:00 <bh526r> #topic Pike Tasks
18:55:28 <bh526r> Jin's patch got some comments today, https://review.openstack.org/#/c/456772/
18:55:59 <bh526r> Jin, can you fix those white space issue?
18:56:18 <jinli> yes
18:56:24 <bh526r> great.
18:56:29 <jinli> will get it done end of day
18:56:48 <bh526r> #info Jin will fix those issues in comments, and upload new patch by the end of day today
18:57:33 <bh526r> Because it has been reviewed for quite long, I suggest to approve it after new patch is uploaded
18:57:39 <bh526r> any objection?
18:58:26 <bh526r> #info Group agrees to approve and merge it once Jin uploads a net patchset that fixes the issues raised in comment
18:58:34 <bh526r> #info Bin will take the action
18:58:47 <bh526r> We are running out of time
18:58:52 <bh526r> #topic AOB
18:59:02 <bh526r> any other business/topic?
18:59:27 <bh526r> If no, we can adjourn the meeting
18:59:34 <bh526r> #info Meeting adjourned
18:59:44 <bh526r> #endmeeting