18:00:10 <daneyon_> #startmeeting container-networking
18:00:11 <openstack> Meeting started Thu Aug 13 18:00:10 2015 UTC and is due to finish in 60 minutes.  The chair is daneyon_. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:14 <openstack> The meeting name has been set to 'container_networking'
18:00:36 <daneyon_> #topic roll call
18:00:42 <suro-patz> o/
18:00:44 <daneyon_> Daneyon Hansen
18:01:29 <daneyon_> lets wait a few min for others to join
18:01:30 <dane_leblanc> o/
18:01:38 <daneyon_> might be a light meeting this week... lol
18:02:55 <daneyon_> Thank you suro-patz dane_leblanc for joining the meeting. We'll make it a quick one this week.
18:03:00 <daneyon_> #topic Networking Spec Update
18:03:06 <daneyon_> #link https://review.openstack.org/#/c/204686/
18:03:36 <daneyon_> I received +2's from pretty much all the core's except tcammann
18:03:56 <daneyon_> he provided some good feedback and the spec has been updated to reflect his feedback
18:04:39 <daneyon_> in gernal, use specific config flags for params that are applicable across all net drivers or across the entire system, i.e. --libnetwork-driver
18:05:19 <daneyon_> i have not seen tcammann cast a vote since i provided an updated patch set, so i'll ping him to ask for him to cast a vote
18:05:28 <adrian_otto> o/
18:05:38 <eghobo> o/
18:05:44 <daneyon_> #action danehans to contact tcammann to ask for an updated vote on the net spec
18:06:01 <daneyon_> thanks adrian_otto and eghobo for joining
18:06:42 <adrian_otto> daneyon_: I have not reviewed the most recent revision yet. I don't expect to have time until tomorrow, unless I take a look right now.
18:07:42 <wznoinsk> o/
18:08:00 <daneyon_> adrian_otto I was just saying that the net spec got +2's from most of the core's except tcammann. He provided good feedback and the spec was updated to reflect his feedback. Aside from tcammaann casting a +2 and you casting a +2, are their any other blockers from merging the spec?
18:08:10 <daneyon_> wznoinsk thanks for joining
18:09:12 <daneyon_> Does anyone have questions on the spec?
18:09:25 <daneyon_> It sure has been vetted :-)
18:09:51 <daneyon_> i'll wait a moment for responses
18:10:07 <daneyon_> otherwise, we'll be on to our next topic.
18:10:20 <adrian_otto> how about this, daneyon_: I will review it today, and merge it once we hear from tcammann if I have no objections.
18:10:20 <daneyon_> #topic Kuryr Integration Brainstorming
18:10:41 <daneyon_> adrian_otto sounds like a plan
18:10:58 <daneyon_> i took an action to ping tcammann to recast his vote
18:10:59 <adrian_otto> s/today/tomorrow/
18:11:17 <daneyon_> adrian_otto tomorrow will work just fine
18:11:36 <daneyon_> so, back to to Kuryr Integration Brainstorming
18:11:59 <daneyon_> Is their anyone from the kuryr team in this meeting?
18:12:37 <daneyon_> That sounds like a no
18:12:48 <daneyon_> which may be a challenge to address this topic.
18:13:08 <daneyon_> I created an etherpad to assist with our brainstorming
18:13:08 <daneyon_> #link https://etherpad.openstack.org/p/magnum-kuryr
18:13:19 <daneyon_> I added a few sections, content, etc..
18:13:19 <hongbin> o/
18:13:32 <daneyon_> hongbin thanks for joining
18:13:41 <hongbin> sorry for late
18:13:45 <daneyon_> no problem
18:13:50 <dane_leblanc> Is the basic idea for Kuryr integration to invoke Kuryr network create for the magnum bay create, and similar for the container-create?
18:14:06 <suro-patz> daneyon_: Would you like to sum up, why we are abandoning Kuryr integration?
18:14:17 <daneyon_> hongbin we are at the Kuryr Integration Brainstorming topic
18:14:25 <hongbin> k
18:14:32 <daneyon_> with an etherpad to assist our brainstorming https://etherpad.openstack.org/p/magnum-kuryr
18:15:03 <daneyon_> Unfortunately, I do not believe anyone from the Kuryr team has joined the meeting.
18:15:16 <adrian_otto> sorry, I have to step out for a bit. will be back.
18:15:28 <suro-patz> etherpad does not really capture our conclusion and reasoning
18:15:42 <daneyon_> adrian_otto no worries
18:15:49 <suro-patz> it will be good to have a summary of our thoughts on Kuryr
18:16:09 <daneyon_> suro-patz I don't see us abandoning kuryr integration.
18:16:40 <daneyon_> libnetwork will be the integration point between magnum and kuryr
18:17:13 <daneyon_> dane_leblanc yes, that is the way i understand it
18:17:19 <suro-patz> daneyon_: I was confused with "That sounds like a no" statement
18:17:32 <daneyon_> dane_leblanc and hopefully more as kuryr and libnetwork mature
18:18:30 <daneyon_> suro-patz I tried to capture the magnum community's thoughts on kuryr in the net spec.
18:18:46 <dane_leblanc> daneyon_: Sounds like the biggest question is how Kuryr will handle containers running in a VM, which is not clear yet.
18:19:02 <daneyon_> the etherpad is really meant as a tool where both kuryr and magnum community members can share ideas and such
18:19:19 <suro-patz> I understand the proposal for Kuryr is to run as an agent on a docker host - be it a VM or BM
18:19:43 <suro-patz> dane_leblanc:^^
18:20:01 <daneyon_> suro-patz please review the kuryr language i added to the net spec. If you think information should be added/modified/subtracted, please provide details in the review
18:20:15 <suro-patz> an agent who will call back the neutron-service
18:20:21 <suro-patz> daneyon_: sure!
18:20:55 <daneyon_> suro-patz regarding I was confused with "That sounds like a no" statement are you referring to the etherpad or review?
18:21:26 <suro-patz> daneyon_: Today at IRC, on brainstorming topic
18:21:52 <daneyon_> dane_leblanc imo their is still quite a bit to be decided with kuryr. fortunately the lines of communication between both projects is open and i get the feeling the kuryr community really values our input.
18:22:51 <daneyon_> We may have to defer diving into this topic until next week when someone from the kuryr team can join.
18:23:22 <daneyon_> #action danehans to send a formal request to the kuryr team for participation in our next meeting on 8/20
18:24:25 <daneyon_> suro-patz and all, I suggest taking the time to review the kuryr design doc a few times if you have not done so already
18:24:28 <daneyon_> #link https://github.com/openstack/kuryr/blob/master/doc/source/design.rst
18:24:43 <daneyon_> as it stands today, kuryr will be a libnetwork remote driver
18:24:57 <daneyon_> it will follow the requirements of being a libnetwork remote driver
18:25:33 <daneyon_> it will proxy the driverapi calls to neutron api for reaalizing container networks
18:26:35 <daneyon_> A user/operator will start the docker daemon with the kuryr driver # docker -d --kv-store=consul:localhost:8500 --label=com.docker.network.driver.kuryr
18:27:06 <daneyon_> Create docker networks # docker network create -d kuryr prod
18:27:33 <daneyon_> which will cause neutron to do a #neutron net-create prod
18:28:24 <daneyon_> as dane_leblanc points out how this maps to magnum vm's is TBD
18:29:17 <hongbin> I guess Kuryr will use user-provided credential to call neutron?
18:29:28 <eghobo> daneyon_: can we do it without extra daemon?
18:29:54 <eghobo> we already has docker daemon at host
18:30:00 <suro-patz> hongbin: IIRC, in the demo, they were passing a hard-coded token
18:30:15 <daneyon_> suro-patz regarding Today at IRC, on brainstorming topic I did not mean to come off as magnum is not integrating with Kuryr. We will be integrating with Kuryr. The details are TBD and hopefully everyone can start using the etherpad as a toool for capturing ideas on the topic. We definitly need to sort out the integration details sooner rather than later.
18:30:41 <hongbin> suro-patz: ACK
18:30:43 <suro-patz> daneyon_: Can you please elaborate the issue with Kuryr and magnum VM? I am not clear
18:30:44 <daneyon_> eghobo can you expand upon your question?
18:31:38 <eghobo> e.g. kuryr is go driver which talk with netron and create vif
18:32:19 <daneyon_> suro-patz in the example I provided above, how will kuryr stitch together the networking on the host and vm. the kuryr community is focused on running containers directly on a host and not in a vm
18:32:20 <eghobo> or do we need neutron agent at host for vif
18:33:25 <daneyon_> when a user issues a 'docker network create -d kuryr prod' command, kuryr would need to configure the networking in the VM and on the host and tie those two together
18:34:03 <daneyon_> I understand why the kuryr team is focused on containers on hosts, they want to take small steps.
18:34:29 <daneyon_> The good thing is they really want to support magnum, so our requirements will be high on their list of TODOs
18:34:42 <suro-patz> daneyon_: when we are running Kuryr on a docker host, just like the demo, we are running kuryr agent on the host itself to act as a remote driver for libnetwork. Right?
18:35:53 <daneyon_> hongbin that is my understanding, when the docker daemon is loaded or through a conf file, credentials and all other stuff needed to communicate with the neutron api
18:36:38 <hongbin> daneyon_: I am concerning about the privilege of the credential
18:36:57 <daneyon_> eghobo docker daemon must run on vm's. when magnum support ironic bare metal driver, then only the host docker daemon will be needed
18:37:00 <suro-patz> following similar model, if we have to integrate with Kuryr, VMs in magnum Bay has to have a kuryr agent, right?
18:37:00 <hongbin> daneyon_: If it is provided by users, it won't have admin credential.
18:37:32 <daneyon_> docker daemon imports libnetwork. remote drivers are loaded using labels when the docker daemon is started
18:38:05 <daneyon_> eghobo yes, but it's in python not go
18:38:54 <daneyon_> eghobo kuryr will talk to the neutron api, neutron api will realize the net through the neutron l2 agent
18:39:08 <daneyon_> again, this breaks down in our use case b/c we run in a vm
18:39:37 <suro-patz> hongbin: I think trust token, i.e. authorization for specific action, would be the right choice to pass to the vm
18:39:50 <daneyon_> their needs to be a way for kuryr to know that it's running in a vm and create the net on the host and vm, then connect the 2
18:40:02 <dane_leblanc> suro-patz: I think there may need to be 2 agents, one in VM and one on compute host, but either way, the difficult piece is how to bind the eth in the VM to the neutron network on the compute host.
18:40:09 <adrian_otto> on the subject of trust token capability, we are currently working on that in magnum
18:40:17 <eghobo> daneyon_: not sure that run neutron l2 agent at docker host/vm is good idea
18:40:34 <adrian_otto> so we will have the ability to generate the trust tokens and inject them into vms through cloud-init
18:40:38 <daneyon_> suro-patz kuryr will run wherever docker daemon runs
18:40:46 <daneyon_> for magnum that's in the vm
18:41:04 <suro-patz> daneyon_: No confusion on that
18:41:32 <eghobo> adrian_otto: does OpenStack ecosystem still require that everything need to be written in python?
18:41:38 <daneyon_> that would also mean a neutron l2 agent would need to run in the vm, unless kuryr has the ability to realize container nets using other libnetwork remote/native drivers.
18:41:55 <adrian_otto> eghobo: no, we can use other languages
18:41:56 <daneyon_> i discussed ^ topic with Gal yesterday.
18:42:39 <adrian_otto> picking python makes it easier to leverage existing openstack libraries, but that's not officially a requirement
18:42:41 <daneyon_> hongbin can you add your thoughts/concerns to the etherpad so we get them documented and addressed by the kuryr team?
18:42:52 <hongbin> daneyon_: sure
18:43:15 <daneyon_> taking a moment to catch up on the thread
18:43:40 <hongbin> One thing is that if some agents need to run on bay, it'd better to run it in container
18:44:17 <daneyon_> dane_leblanc agreed.
18:44:27 <suro-patz> daneyon_: I thought the Kuryr agent is sufficient on docker host/VM. The issue if it requires a plumbing on compute host
18:44:50 <suro-patz> that's where the interaction with neutron-l2 agent will come in place
18:45:46 <daneyon_> eghobo I agree and that is why I asked Gal to think about kuryr not only proxying to neutron api, but to other libnetwork drivers. Therefore, kuryr could instantiate the network in the vm using the native bridge driver for example.
18:46:09 <suro-patz> hongbin: daneyon_: Is it possible to run the remote network driver as a container on this host? Docker daemon itself will be taking the service from this
18:46:23 <eghobo> daneyon_: good point
18:46:32 <hongbin> suro-patz: I see
18:46:41 <suro-patz> hongbin: Do you have a similar example? That sounds like a nice idea, but needs to be explored
18:46:43 <daneyon_> To all... please make sure you provide this feedback in the etherpad so we can keep the ball rolling on this topic
18:47:15 <hongbin> suro-patz: I am worrying about the CoreOS cases. In there, everything needs to be in a container
18:47:34 <daneyon_> I would like to move to our next agenda item
18:47:48 <suro-patz> hmm, hongbin: I think this will be a great input to the Kuryr team
18:48:03 <dane_leblanc> daneyon_: Using native bridge driver in VM makes a lot of sense, that way you only have one overlay (the one in the Neutron network on the compute host)
18:48:10 <daneyon_> lets continue the kuryr integration discussion on the etherpad and i'll make sure it's on the agenda for next week and that we have someone from the kuryr team to dive into the details
18:49:02 <daneyon_> dane_leblanc agreed. I would like to see kuryr take advantage of all the native drivers... we'll see where this goes as our two teams work together
18:49:06 <daneyon_> #topic Review Action Items
18:49:13 <daneyon_> danehans contact Gal to get Kuryr meeting details.
18:49:39 <daneyon_> I have the meeting details and joined this past Monday
18:49:49 <daneyon_> Please let me know if you want to join the kuryr irc meetings, but do not know the details.
18:49:54 <daneyon_> adrian_otto formally request the Neutron/Kuryr PTL submit a Kuryr design spec.
18:50:33 <daneyon_> While we are waiting for adrian_otto, here is the next action item update
18:50:34 <daneyon_> danehans to update network spec review to WIP and add comment to expect a revision
18:50:53 <daneyon_> done, then taken out of WIP
18:50:54 <adrian_otto> are you recording actions, don't you want a #action in front of those?
18:51:12 <daneyon_> i think the spec is just about ready to be merged... yay!
18:51:19 <daneyon_> oops
18:51:47 <daneyon_> adrian_otto i wasn;t sure if i should use action to get status updates on the action.
18:52:00 <daneyon_> #danehans contact Gal to get Kuryr meeting details.
18:52:04 <daneyon_> I have the meeting details and joined this past Monday
18:52:09 <daneyon_> Please let me know if you want to join the kuryr irc meetings, but do not know the details.
18:52:15 <adrian_otto> oh, you are requesting status on previously assigned actions
18:52:33 <daneyon_> yes
18:52:44 <daneyon_> do i use #action for that?
18:52:49 <adrian_otto> I see. Disregard my previous remark on this subject.
18:52:54 <daneyon_> #undo
18:52:55 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x9f87150>
18:53:04 <adrian_otto> the topic was ok
18:53:06 <adrian_otto> you can redu taht
18:53:11 <adrian_otto> *redo
18:53:11 <daneyon_> #redu
18:53:14 <daneyon_> #redo
18:53:16 <daneyon_> lol
18:53:25 <adrian_otto> you have to repeat the #topic ...
18:53:32 <daneyon_> thx all for your patience
18:53:45 <daneyon_> #topic Review Action Items
18:53:53 <daneyon_> danehans contact Gal to get Kuryr meeting details.
18:53:57 <daneyon_> I have the meeting details and joined this past Monday
18:53:59 <adrian_otto> we have arrived in the future where we rely on robots to get our work done ;-)
18:54:02 <daneyon_> Please let me know if you want to join the kuryr irc meetings, but do not know the details.
18:54:08 <daneyon_> danehans to update network spec review to WIP and add comment to expect a revision
18:54:14 <daneyon_> done, then taken out of WIP
18:54:24 <daneyon_> lol
18:54:26 <daneyon_> adrian_otto formally request the Neutron/Kuryr PTL submit a Kuryr design spec.
18:54:43 <daneyon_> adrian_otto did you get a chance to do ^
18:55:59 <daneyon_> i'll take that as a no adrian_otto
18:56:03 <daneyon_> #action adrian_otto formally request the Neutron/Kuryr PTL submit a Kuryr design spec.
18:56:08 <daneyon_> next topic
18:56:10 <daneyon_> #topic Open Discussion
18:56:15 <daneyon_> we only have a couple minutes
18:56:32 <adrian_otto> http://lists.openstack.org/pipermail/openstack-dev/2015-August/072005.html
18:56:34 <daneyon_> anyone have a quick discussion?
18:56:47 <adrian_otto> #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/072005.html Official Design Spec Request
18:56:57 <daneyon_> thanks adrian_otto for knocking that out
18:57:12 <daneyon_> not sure if their is a way to retract the action item i added for you
18:57:19 <adrian_otto> not important
18:57:33 <adrian_otto> we can just indicate it as complete during the next review
18:57:50 <daneyon_> I'll add the ML to the ep
18:58:26 <daneyon_> well, we actually covered a fair bit of info
18:58:37 <daneyon_> i really appreciate everyone's involvement
18:59:10 <daneyon_> to reiterate, please take time to add you ideas to the kuryr integration etherpad
18:59:26 <daneyon_> thanks everyone!
18:59:45 <daneyon_> #endmeeting