15:00:37 <gsagie_> #startmeeting Kuryr
15:00:37 <openstack> Meeting started Mon Oct 19 15:00:37 2015 UTC and is due to finish in 60 minutes.  The chair is gsagie_. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:38 <tfukushima> Toni is on vacation, BTW.
15:00:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:41 <openstack> The meeting name has been set to 'kuryr'
15:00:49 <gsagie_> Yeah, Toni is in Tokyo :)
15:00:59 <gsagie_> setting the grounds for us
15:01:13 <tfukushima> He's visiting Kyoto actually.
15:01:22 <gsagie_> Who is in for the meeting, i see banix feisty and tfukushima
15:01:27 <gsagie_> feisky
15:02:00 <gsagie_> i think we will have a short meeting this week because everyone are probably busy with the summit..
15:02:12 <gsagie_> #topic libnetwork updates
15:02:32 <gsagie_> tfukushima: anything to update us on the progress? most patches are merged
15:02:44 <tfukushima> So my patches for catching up with the libnetwork was merged.
15:03:00 <tfukushima> Vikas is working on updading the devref.
15:03:14 <salv-orlando> aloha
15:03:21 <gsagie_> ok cool once this is done i will update our Kuryr spec at the neutron repository
15:03:24 <gsagie_> Hello salv-orlando
15:03:31 <tfukushima> Vikas is also working on the validation issue for /NetworkDriver.CreateEndpoint .
15:03:55 <gsagie_> #action gassy update Kuryr neutron spec with lib network new workflow
15:04:08 <gsagie_> #action gsagie update Kuryr neutron spec with lib network new workflow
15:04:47 <gsagie_> tfukushima: so we are right now synced with the service removal and it should work if i rebase on your Join patch?
15:05:43 <tfukushima> Actually Vikas found the behaviour of change of creating endpoints as I put above.
15:06:02 <tfukushima> Except for that I confirmed it works against the specific version of libnetwork.
15:06:12 <tfukushima> In the latest one, I found some issues.
15:06:33 <tfukushima> vagrant@devstack:~/kuryr$ sudo docker run -it --net=foo --rm ubuntu /bin/bash
15:06:34 <tfukushima> Error deleting container: Error response from daemon: Driver aufs failed to remove root filesystem f7f5134b9043da4d5d44e6849ec4a609f1e41df0942ae9581714208134080332: rename /var/lib/docker/0.0/aufs/mnt/f7f5134b9043da4d5d44e6849ec4a609f1e41df0942ae9581714208134080332 /var/lib/docker/0.0/aufs/mnt/f7f5134b9043da4d5d44e6849ec4a609f1e41df0942ae9581714208134080332-removing: device or resource busy
15:06:34 <tfukushima> Error response from daemon: Cannot start container f7f5134b9043da4d5d44e6849ec4a609f1e41df0942ae9581714208134080332: failed to create endpoint admiring_pike on network foo: driver modified interface address: endpoint interface IP present (172.19.0.2/16). Cannot be modified with (172.19.0.2/16).; rolled back
15:07:57 <tfukushima> I tested against the following version and everything works with that.
15:07:58 <tfukushima> https://apt.dockerproject.org/repo/pool/experimental/d/docker-engine/docker-engine_1.9.0~dev~git20150924.164351.0.1e514de-0~jessie_amd64.deb`
15:08:25 <gsagie_> ok good work, we will probably demo from that version anyway and not the latest
15:08:34 <vikasc__> o/
15:08:36 <tfukushima> So we'd use that version, yes.
15:08:39 <gsagie_> and nice work from both you and vikas
15:08:43 <vikasc__> sorry for being late
15:08:47 <banix> so 1.9.0-rc1 is the one we nee dto work it but I think this late in our cycle staying with a couple of commits earlier we are ok
15:08:48 <gsagie_> hi Vikas!
15:08:57 <vikasc__> Hi Gal
15:09:25 <vikasc__> yes , IMO alo we should work on 1.9.0_rc1
15:09:47 <gsagie_> okie, vikas is that the version you changed the vagrant installation to point to?
15:09:58 <vikasc__> yes Gal
15:10:27 <tfukushima> Yeah, I tested with the env created by Vagrant. Thanks for that Vikas.
15:10:40 <gsagie_> okie great, after the summit we can probably investigate the things tfukushima noticed with latest builds
15:11:06 <gsagie_> #topic demo in openstack summit
15:11:14 <gsagie_> mestery: here?
15:11:20 <mestery> gsagie_: howdy! :)
15:11:33 <gsagie_> Anything is missing on your end for the demo?
15:11:40 <gsagie_> Hi daneyon ! :)
15:12:38 <gsagie_> tfukushima, banix: i think we agreed not to demo with Docker Swarm, or has that changed?
15:13:02 <banix> gsagie_: no that’s my understanding
15:13:15 <gsagie_> okie
15:13:51 <gsagie_> anything new to update on that Integration band?
15:13:53 <gsagie_> banix
15:14:39 <banix> gsagie_: are you referring to swarm?
15:14:50 <gsagie_> yes
15:15:34 <banix> gsagie_: we have been doing some work on that area but nothing interesting to report yet; simply catching up with new changes
15:15:44 <gsagie_> okie cool
15:16:17 <gsagie_> tfukushima: is there any help you need for the demo ? i think you helping Toni on that, please let me know if there is anything you need from me
15:16:43 <vikasc__> i am also available for any help Taku
15:17:12 <banix> gsagie_:  tfukushima it’s good to know what exactly the plan is for the demo
15:17:16 <tfukushima> I don't have issues for now. So I heard no multi node connectivity demo. Am I understanding correctly?
15:17:51 <tfukushima> Basically it'd be the same as the last demo I put but with Horizon.
15:18:11 <tfukushima> banix: I heard you worked on some multi node connectivity stuff, which might be the next topic.
15:18:33 <banix> tfukushima: thanks; regarding horizon just to confirm my understanding, the conatiners show up only if we use compute:nova as owner?
15:19:06 <gsagie_> banix: i believe so, we need to add support there feisky is working on it i believe
15:19:16 <banix> tfukushima: yes, I have a multi node system but as independent docker hosts without swarm fronting them
15:19:18 <tfukushima> banix: Yes. We just show we set the device_owner field at this point.
15:19:28 <banix> ok thanks
15:19:32 <gsagie_> we want to be able to use kuryr:container as the owner
15:19:40 <gsagie_> (similar to what Ironic is doing)
15:20:14 <gsagie_> #topic trello board
15:20:54 <gsagie_> Ok, i believe everyone know but we have a Trello board for the project and after the summit i think we should start clearing it and transferring things to bugs/blue prints and track everything in launchpad
15:21:06 <gsagie_> #link https://trello.com/b/cbIAXrQ2/project-kuryr
15:21:35 <gsagie_> so we should probably clean everything that is already done, i will work on it after the summit
15:21:40 <tfukushima> I finished some tasks, I believe, i.g., "Docker 1.9 new API adjustments".
15:21:46 <tfukushima> Oh, Ok.
15:22:05 <gsagie_> tfukushima: Feel free to delete it, and anything else you finished
15:22:18 <gsagie_> i think all the members should have edit premissions
15:22:20 <tfukushima> gsagie_: Got it.
15:22:31 <gsagie_> #topic Neutron design summit
15:23:04 <gsagie_> We will have part of a session to speak about Kuryr, i am still not sure how much time exactly but wanted to make sure the time it self fits everyone
15:23:24 <gsagie_> http://mitakadesignsummit.sched.org/event/9be2ec1db45ea3267f811b8d35816e1c#.ViUK4kKfx-M
15:23:28 <gsagie_> #link http://mitakadesignsummit.sched.org/event/9be2ec1db45ea3267f811b8d35816e1c#.ViUK4kKfx-M
15:23:42 <gsagie_> If anyone has any conflict, please let me know and i will see what we can do
15:25:14 <gsagie_> And if anyone from the team has something that he/she thinks should be on the items, please let me know as we are working on the exact schedule
15:26:13 <banix> gsagie_: sounds good; it would be mice if we could find an hour or two for Kuryr to talk among ourselves. Saying it now as I am sure scheduling it will be a challenge
15:26:43 <gsagie_> banix: yeah, its actually an action item on my self, are you staying friday as well?
15:26:47 <banix> no mice, nice :)
15:26:58 <banix> yes
15:27:38 <gsagie_> so worst thing if we won't be able to find anything sooner we can do it on Friday, i will try to find something else and update everyone, would also like the Magnum team to join us
15:27:56 <gsagie_> or at least the ones that are involved with the networking part
15:28:51 <banix> sounds good
15:29:04 <gsagie_> #topic open discussion
15:29:24 <gsagie_> Anything else from anyone?
15:29:34 <tfukushima> If we don't have any other topic, I'd like to talk about the multi node configuration a little bit.
15:29:43 <gsagie_> tfukushima: sure
15:30:25 <tfukushima> So I tried --cluster-store and --cluster-adverties options of Docker 1.9.0.
15:30:32 <vikasc__> Can we discuss remote ipam driver support after that?
15:31:04 <tfukushima> vikasc__: Yeah, mine would be short.
15:31:16 <vikasc__> thanks tfukushima
15:31:30 <gsagie_> hi irenab
15:31:43 <tfukushima> Actually I tried ZooKeeper as the backend because that's what I have right now.
15:31:54 <tfukushima> From the log I can see they're communicating each other.
15:32:22 <tfukushima> However, when I create a network on a host, it's not synced on another host.
15:33:05 <tfukushima> With overlay networking driver, it'd be synched among multiple hosts.
15:33:07 <banix> tfukushima: when you say not sync, what do you mean? the network doesnt show on netowrk ls?
15:33:21 <tfukushima> banix: Yes.
15:34:00 <tfukushima> banix: How about your system? Have you experienced that? If so how did you add the capability to syncing multiple hosts?
15:34:14 <banix> tfukushima: hmmm. have tried it with consul and that works fine
15:34:18 <tfukushima> It's possible that I'm configuring it wrong.
15:35:01 <tfukushima> Ok, I'd appreciate if you could share the configuration. I must be doing wrong.
15:35:22 <banix> tfukushima:  --cluster-store=consul://localhost:8500  --cluster-advertise=<your IP>:2375
15:35:31 <tfukushima> DOCKER_OPTS="-D -H unix:///var/run/docker.sock -H tcp://0.0.0.0:2376 --cluster-advertise=192.168.11.14:2376 --cluster-store=zk://192.168.11.14:2181”
15:36:13 <tfukushima> banix: Thanks I'll try that. And I'm glad it worked on your side.
15:36:49 <banix> tfukushima: this is the command line omn one node: docker -dD -H :2375 --cluster-store=consul://localhost:8500  --cluster-advertise=192.168.122.185:2375
15:37:19 <banix> tfukushima: sure; ping on IRC if you think i can be of any help
15:37:37 <tfukushima> banix: Ok. Thank you very much.
15:38:00 <tfukushima> vikasc__: I think I finished. Please go ahead.
15:38:50 <vikasc__> how are we going to support remote ipam driver apis?
15:39:26 <vikasc__> in the same process or a seperate server for ipam driver also
15:39:45 <vikasc__> thoughts?
15:39:59 <banix> vikasc__: seperate sounds better
15:40:15 <banix> as it allows possibly having different versins of it? if need be
15:40:32 <vikasc__> banix, make sense
15:40:43 <gsagie_> Vikas: can you explain more what do you mean
15:41:23 <salv-orl_> vikasc__: yeah curious about that too. I thought we'd leverage ipam via neutron only.
15:41:57 <gsagie_> yeah same, and neutron has a pluggable IPAM already, so we will just need to connect to it
15:42:07 <vikasc__> gsagie_,  user has two options now.. either use built-in ipam of libnetwork or configure driver through docker cli
15:42:45 <vikasc__> we will not need default subnets now i guess
15:42:49 <gsagie_> vikasc__ : can you share a #link where its described maybe ?
15:43:08 <vikasc__> one moment please
15:43:33 <vikasc__> https://github.com/docker/libnetwork/blob/master/docs/ipam.md
15:43:36 <salv-orl_> vikasc__: I think I see what you mean. A user can specify a 3rd party IPAM driver in addition to the libnetwork driver?
15:43:38 <gsagie_> and are those lib network IPAM calls (that are done using docker cli) not being directed to the remote driver *Kuryr) ?
15:43:57 <gsagie_> #link https://github.com/docker/libnetwork/blob/master/docs/ipam.md
15:44:07 <vikasc__> gsagie_,  no
15:44:17 <vikasc__> gsagie_, first they will go to ipam driver
15:44:36 <vikasc__> if user has not mentioned .. libnetwork has a built it
15:44:51 <banix> well the remore drivers and the remote ipam drivers are essentially different entities; but they can of course be handled by a single kuryr driver
15:45:03 <salv-orl_> vikasc__: it is interesting that this interface seems very close to neutron's ipam driver interface
15:45:12 <banix> by remore driver i mean the dcker betwork plugin talking to the remote driver
15:45:23 <vikasc__> banix, agreed
15:45:43 <salv-orl_> vikasc__: as docker has a default driver, does this mean that neutron's IPAM is going to be pretty much bypassed by docker's now?
15:45:58 <salv-orl_> unless a kuryr IPAM driver is provided as well?
15:46:01 <gsagie_> banix: just wondering why do you think that running those separately is better?
15:46:02 <banix> salv-orl_: right now yes
15:46:12 <vikasc__> salv-orl_, yes
15:46:20 <tfukushima> vikasc__:  I'm wondering what is the interface from the perspective of Kuryr or other remote drivers?
15:46:41 <tfukushima> #link new create network API https://github.com/docker/libnetwork/blob/master/docs/remote.md#create-network
15:46:47 <banix> right now there is no option of having a “null” libnetwork ipam driver so you either have that or you bring your own that implements the api
15:46:57 <salv-orl_> banix, vikasc__: do you think an IPAM driver could just be implemented using Neutron's APIs or do you reckon we might need direct access to Neutron IPAM, which is not exposed via the API atm?
15:46:59 <vikasc__> banix, exactly
15:47:04 <banix> gsagie_: just because these are logically different components/modules
15:47:54 <tfukushima> I thought it would be in /NetworkDriver.CreateNetwork.
15:47:55 <banix> salv-orl_: i think using Neutron API would be sufficient but need to look more closely
15:48:28 <vikasc__> salv-orl_, abstraction layer need to be introduced for defining interface
15:49:39 <banix> tfukushima: there are access through /IpamDriver.RequestPool etc
15:49:47 <banix> they are accesses
15:49:51 <banix> accessed
15:49:55 <vikasc__> salv-orl_, we will have to define ipam apis. Then we can see how much we can reuse from neutron
15:50:32 <gsagie_> banix: i am afraid that splitting these two in Kuryr, might lead to all strange race conditions, but i can't really back that up until i read more and understand the lib network IPAM better
15:51:04 <vikasc__> gsagie_, thats why i brought this topic so that we can discuss more in next meeting
15:51:11 <banix> gsagie_: let’s look into it more closely and discuss further
15:51:20 <vikasc__> we will have more thoughts by then
15:51:22 <gsagie_> okie,
15:51:39 <gsagie_> #action everyone to examine the new lib network IPAM APIs
15:51:52 <gsagie_> #link https://github.com/docker/libnetwork/blob/master/docs/ipam.md
15:52:03 <salv-orl_> vikasc__: why? bike shedding about things you don't actually know if fun ;)
15:52:25 * salv-orl_ is fun
15:52:41 <vikasc__> salv-orl_, :D
15:52:46 <tfukushima> BTW, do we have the meeting next week in the same timeline?
15:52:56 <banix> is there a session on bike shedding at the summit?
15:53:11 <vikasc__> here is the blueprint i drafted for same.https://blueprints.launchpad.net/kuryr/+spec/remote-ipam-driver
15:53:12 <gsagie_> tfukushima: i don't think so
15:53:14 <banix> tfukushima: i would say let’s cancel the next week meeting
15:53:54 <tfukushima> Ok, there'd be tons of meetings next week. :-p
15:54:01 <vikasc__> :)
15:54:22 <gsagie_> yeah, we could all meet in person, no need to do it on IRC :)
15:54:50 <feisky> I'm coming back. Has the discussion finished?
15:55:29 <gsagie_> feisky: yes, but you can read the log in a minute
15:55:35 <feisky> I have two questions
15:55:53 <gsagie_> sure, but we have 2 minutes before the other meeting start
15:56:03 <salv-orl_> banix: the summit is actually all about bike shedding, as you surely know
15:56:25 <feisky> first about device_owner, we must have an agreement before take other actions to horizon
15:56:28 <banix> :)
15:57:31 <vikasc__> :)
15:57:51 <feisky> We can't expect expect horizon to accept a new device_owner since we are still be debating
15:57:56 <gsagie_> feisky: lets take this offline, we discussed about it
15:58:19 <gsagie_> feisky: we are going to use a patch with nova:compute for the demo and then proceed with what was mentioned in the patch
15:58:34 <gsagie_> i think irena was commenting
15:58:41 <feisky> OK
15:59:02 <gsagie_> ok everyone are time is up, thanks for coming
15:59:06 <gsagie_> our
15:59:13 <gsagie_> and see you all in the summit
15:59:23 <tfukushima> Have safe trips, guys!
15:59:23 <gsagie_> #endmeeting