03:00:04 <hongbin> #startmeeting zun
03:00:05 <openstack> Meeting started Tue Nov 22 03:00:04 2016 UTC and is due to finish in 60 minutes.  The chair is hongbin. Information about MeetBot at http://wiki.debian.org/MeetBot.
03:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
03:00:08 <openstack> The meeting name has been set to 'zun'
03:00:10 <hongbin> #link https://wiki.openstack.org/wiki/Zun#Agenda_for_2016-11-22_0300_UTC Today's agenda
03:00:14 <hongbin> #topic Roll Call
03:00:16 <shubhams> Shubham Sharma
03:00:17 <Namrata> Namrata
03:00:19 <mkrai_> Madhuri Kumari
03:01:07 <hongbin> Welcome to join the meeting shubhams Namrata mkrai_
03:01:17 <hongbin> #topic Announcements
03:01:31 <hongbin> I have no announcements, anyone else has?
03:01:31 <sudipto_> o/
03:01:48 <hongbin> sudipto_: hey, thanks for joining
03:02:11 <sudipto_> It's not an announcement per say, but then mfedosin yesterday - had requirements for zun...that we had a chat on the meeting room.
03:02:20 <hongbin> i knew several people cannot join the meeting today, so it will be a short meeting
03:02:30 <trinaths> hi
03:02:35 <hongbin> sudipto_: ack
03:02:48 <hongbin> trinaths: welcome to the zun meeting
03:03:00 <hongbin> sudipto_: will discuss that in open discussion
03:03:06 <hongbin> #topic Review Action Items
03:03:07 <sudipto_> hongbin, sure thing.
03:03:12 <hongbin> 1. hongbin add k8s bp to weekly meeting agenda (DONE)
03:03:18 <hongbin> #link https://wiki.openstack.org/wiki/Zun#Agenda_for_2016-11-22_0300_UTC
03:03:25 <trinaths> hongbin: I'm new to Zun, but would like to know ways to contribute for Zun.
03:03:38 <hongbin> trinaths: sure
03:03:51 <hongbin> trinaths: will talk to you later in open discussion :)
03:03:54 <hongbin> #topic Container image store (mkrai)
03:04:00 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/glance-integration The BP
03:04:04 <hongbin> mkrai_: ^^
03:04:17 <mkrai_> The glance integration bp is completed now
03:04:26 <hongbin> great
03:04:41 <mkrai_> I have submitted one patch to store docker images in glance while downloading
03:04:58 <mkrai_> But seems it is not good to do so.
03:05:38 <hongbin> yes, i don't think it is a good idea as well
03:05:40 <mkrai_> For that, we can have push image APIs
03:06:03 <mkrai_> And I will resubmit my patch to implement the new API
03:06:13 <mkrai_> That's all from my side.
03:06:16 <mkrai_> Any questions?
03:06:31 <mkrai_> If no, shubhams please update
03:06:34 <hongbin> mkrai_: the push API is in server or client?
03:06:46 <mkrai_> hongbin: Both
03:07:03 <hongbin> mkrai_: en...
03:07:05 <shubhams> From my side there is not much update as I was out for last week/ Will finish this week
03:07:17 <hongbin> shubhams: ack
03:07:55 <hongbin> mkrai_: i am not sure if it makes sense to push images from server to glance as well....
03:08:11 <hongbin> mkrai_: it makes more sense to push from client to glance ....
03:08:58 <hongbin> mkrai_: i just think in a nova way: nova never push image from hypervisor to glance
03:08:59 <mkrai_> Oh I am not sure whether its good to support any feature in clients that doesn't exist in server
03:09:12 <trinaths> yes, in all the other projects, also the images are pushed via client
03:09:37 <mkrai_> Because not everyone uses clients
03:10:24 <trinaths> mkrai_: true said, but using client is in sync with other implementations
03:11:26 <mkrai_> hongbin: trinaths Do you know reason why nova is not pushing from server?
03:11:46 <sudipto_> why are we thinking about pushing images from zunclient to the glance server btw?
03:12:05 <trinaths> mkrai_: beacause they are independant projects
03:12:15 <mkrai_> sudipto_: For users, not having access to internet
03:12:15 <hongbin> mkrai_: i am not sure exactly
03:12:40 <sudipto_> mkrai_, users without internet access, - how do they get the image in the first place?
03:13:01 <sudipto_> can't they directly store it in glance?
03:13:08 <Alagar> Iam trying to integrate openstack with xen
03:13:08 <Alagar> i have installed openstack using devstack script top of xen hypervisor, in this open stack as a virtual machine.
03:13:08 <Alagar> when i create instance in openstack,   the instance should create in xen hypervisor.  but its not happening.
03:13:08 <Alagar> Some one could you please guide me please
03:13:29 <sudipto_> Alagar, there's a meeting ongoing at the moment :)
03:13:40 <sudipto_> you may try another channel. Like openstack-nova.
03:13:45 <hongbin> sudipto_: i think the pattern of using glance is like using a private docker registry
03:13:45 <mkrai_> mkrai_: They can create their own images or download from docker for later use
03:14:01 <mkrai_> But yes it makes sense to me, if they directly store images in glance
03:14:26 <sudipto_> hongbin, understood, but they could just then store the image in glance and create that repo, no?
03:14:29 <hongbin> sudipto_: the pattern is 1) client pull from docker hub, 2) client push to private docker registry 3) server pull from private docker registry
03:14:46 <hongbin> sudipto_: yes
03:15:17 <hongbin> sudipto_: so, they can do that without any support from zun, just a command: glance upload ...
03:15:21 <sudipto_> hongbin, ok and the analogous flow here would be? 1) client has the image via a gz file 2) uses the glance client to upload it to glance 3) zun pulls it from glance while deploying
03:15:42 <hongbin> sudipto_: i guess yes
03:15:51 <sudipto_> yeah that i agree, i guess you are talking about the glance client not the zunclient...
03:16:10 <sudipto_> however, there is already a support like that in glance, is that not sufficient you mean?
03:16:30 <hongbin> sudipto_: yes, so maybe this feature is not in zun at all
03:16:50 <mkrai_> sudipto_: Does it support the case specified by hongbin ?
03:17:00 <mkrai_> Downloading from docker/URL?
03:17:05 <sudipto_> hongbin, the case being? Pulling from docker hub? NO.
03:17:33 <hongbin> sudipto_: 1) pull from docker hub , OR , docker build
03:17:39 <hongbin> 2) push to glance
03:18:07 <hongbin> sudipto_: these two steps can be done without zun
03:18:19 <sudipto_> hongbin, ok - now i understand the use case. Yes, the support does not exist today and I think, it's ok to do it without zun.
03:18:44 <mkrai_> Yes not necessarily have to be in zun
03:19:01 <hongbin> mkrai_: then maybe don't worry the push api at al
03:19:04 <sudipto_> Remember, you can only push a tar.gz file into docker - so i am not sure even if we want to do it within zun, how do we do it?
03:19:05 <mkrai_> I am ok if we don't want to support it
03:19:20 <sudipto_> typo - i meant push into glance.
03:20:14 <mkrai_> sudipto_: We download a tar file from docker and upload it to glance
03:20:25 <sudipto_> mkrai_, how do you download the tar though?
03:20:46 <sudipto_> usual way to generate that tar is to do a docker export on the running container pipe it and save it as a tar.gz
03:20:52 <sudipto_> (unless they have done something new)
03:20:58 <mkrai_> sudipto_: Sorry we are not storing it now in glance from zun
03:21:06 <mkrai_> Users manually have to do it.
03:21:22 <mkrai_> But we download image from glance to be used while creating container
03:22:03 <sudipto_> mkrai_, no i mean - when you develop the feature...
03:22:19 <sudipto_> you will have to have a way to convert the image into tar.gz before you can store it in glance...
03:22:29 <sudipto_> my question was - how would you do that from an implementation per say.
03:22:41 <sudipto_> if you have to develop that feature in zun.
03:23:52 <mkrai_> sudipto_: There is an API get_image in docker that returns you the image data
03:24:03 <sudipto_> mkrai_, ah i see.
03:24:13 <mkrai_> sudipto_: YOu can see the implementation here
03:24:18 <mkrai_> #link https://review.openstack.org/#/c/398792/1/zun/image/docker/driver.py
03:24:54 <mkrai_> Line 70
03:25:02 <sudipto_> mkrai_, are you sure that pulls the image in tar.gz format?
03:25:22 <sudipto_> anyway i think we can talk on this later as well.
03:25:29 <mkrai_> sudipto_: No it is not in tar.gz format
03:25:40 <mkrai_> It is the image content
03:26:02 <sudipto_> yeah - so it's a layered filesystem, that you need to convert to a tar format before you can store it in glance - was my point.
03:27:32 <mkrai_> sudipto_: Not exactly, we can read this response from HTTP and directly upload in glance
03:27:48 <sudipto_> mkrai_, ok.
03:28:07 <sudipto_> i just thought glance only accepted the gz format. Anyway i might be wrong.
03:28:47 <sudipto_> mkrai_, http://docs.openstack.org/developer/glance/formats.html
03:28:53 <sudipto_> we can park it for later.
03:29:10 <mkrai_> sure sudipto_
03:29:19 <hongbin> ok, advance topic
03:29:25 <hongbin> #topic Container network (hongbin)
03:29:30 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/neutron-integration The BP
03:29:35 <hongbin> #link https://review.openstack.org/#/c/365754/ The proposed spec (merged)
03:29:40 <hongbin> #link https://review.openstack.org/#/c/396896/ The patch Part 1
03:29:46 <hongbin> #link https://review.openstack.org/#/c/399248/ The patch Part 2
03:30:14 <hongbin> I split the driver into two: the pure docker driver, and a nova-docker driver
03:30:23 <hongbin> hope everything is more clear right now
03:30:27 <sudipto_> hongbin, i just had a minor doubt, once we implement the sandbox, what will happen to lib network?
03:30:49 <sudipto_> in a more crude term, what happens to the IP allocated by docker on the container?
03:31:19 <hongbin> sudipto_: i am not sure exactly (i just coped everything from nova-docker :)
03:31:48 <hongbin> sudipto_: from what i undertand from nova-docker code, they did custom container networking (disable libnetwork)
03:32:12 <sudipto_> hongbin, ok - the time nova-docker was written - was different than the time we are in right now...but maybe that works.
03:32:18 <trinaths> sudipto_: my doubt: the networking is managed by neutron here?
03:32:29 <sudipto_> trinaths, that's what we are proposing.
03:32:32 <hongbin> sudipto_: they just did something like: 1) create a veth pair, 2) plug one end to neutron bright, 3) plug another end to container nanemspace
03:33:09 <trinaths> sudipto_: then the IP given by docker must hide.
03:33:16 <sudipto_> hongbin, ok yeah - that's how docker does it too - but i wonder how they disable the docker networking.
03:33:39 <hongbin> sudipto_: by passing an option: netmode=none
03:33:47 <sudipto_> hongbin, ah i see.
03:34:06 <hongbin> sudipto_: however, we can integrate with libnetwork later if we ant
03:34:07 <hongbin> want
03:34:19 <sudipto_> so even though we have the docker0 bridge, it's basically of no use or do we disable that bridge as well?
03:34:47 <hongbin> sudipto_: per my understanding, the answer is "yes"
03:34:56 <sudipto_> hongbin, alright.
03:35:08 <hongbin> sudipto_: however, again, we are free to change it later
03:35:13 * sudipto_ fiddling with the lib network code, hence got curious.
03:35:38 <hongbin> ok
03:35:41 <trinaths> as a thought, user must have the provision to enable/disable this.
03:36:07 <sudipto_> enabling/disabling may have implications...
03:36:37 <hongbin> trinaths: i guess nobody want to get a container with no networking.... so disable it might not make sense
03:36:47 <sudipto_> the IP addressing then goes out of scope for openstack and that again is a challenge to manage...
03:36:56 <hongbin> yes
03:37:31 <trinaths> hongbin: true said, agree. But the decision is between container networking  or networking from neutron. may be i'm wrong
03:37:31 <hongbin> ok, that is all from the sandbox proposal
03:37:43 <hongbin> #topic Open Discussion
03:38:08 <sudipto_> I saw a clear containers BP owned by mkrai_ - can we talk about that a bit?
03:38:24 <hongbin> trinaths: since zun is an openstack project, so networking is always from neutron, i am afraid there are no other choice
03:38:31 <mkrai_> Yes but I haven't started it yet
03:38:44 <trinaths> hongbin: okay
03:38:46 <mkrai_> Do you have any specific question on it sudipto_ ?
03:38:51 <sudipto_> mkrai_, just wanted to know - is clear containers a part of the docker apis now?
03:39:06 <mkrai_> Yes
03:39:16 <mkrai_> It uses the same docker APIs
03:39:20 <sudipto_> mkrai_, any link would be great...
03:39:45 <sudipto_> mkrai_, basically the github link i had was based on the exec driver in docker, that no longer exists...
03:39:47 <mkrai_> Need to look
03:40:02 <sudipto_> Ok, no problem.
03:40:54 <hongbin> ok, no other topic?
03:41:04 <mkrai_> sudipto_: I will share later
03:41:08 <mkrai_> Is that fine?
03:41:17 <sudipto_> mkrai_, yup that would be great.
03:41:23 <mkrai_> Ok will do that
03:41:37 <sudipto_> Another thing quickly hongbin is the interest in zun from mfedosin and his company
03:41:50 <hongbin> sudipto_: go ahead
03:42:20 <sudipto_> they wanted to host something like NFV workloads in containers and were evaluating if it's possible to use zun. Practically, i think we are a bit far from providing that functionality - but i asked him to contribute
03:42:44 <mkrai_> sudipto_: here https://github.com/01org/cc-oci-runtime/wiki/Installing-Clear-Containers-on-Ubuntu-16.04
03:42:49 <hongbin> ok, that is a good response :)
03:43:25 <sudipto_> mkrai_, thanks :)
03:44:52 <hongbin> yes, i know other nfv folks who also interests in zun
03:45:29 <hongbin> i guess they want something that is lighter than vm, so they look into container projects
03:46:11 <sudipto_> yeah i guess that's what he was stating too. More than lighter, they wanted better performance.
03:46:24 <hongbin> i see
03:46:54 <hongbin> zun definitely has potential to solve the nfv use cases
03:47:02 <hongbin> let's work hard for that :)
03:47:11 <sudipto_> Sure :)
03:47:11 <mkrai_> +1 :)
03:47:16 <trinaths> +1 :)
03:47:32 <hongbin> ok, all, thanks for joining the meeting
03:47:44 <mkrai_> Thanks all!
03:47:44 <sudipto_> Thank you!
03:47:58 <hongbin> trinaths: i remembered you were looking for tasks? i can help you in zun channel
03:48:03 <hongbin> #endmeeting