03:00:05 <hongbin> #startmeeting higgins
03:00:06 <openstack> Meeting started Tue May 24 03:00:05 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:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
03:00:09 <openstack> The meeting name has been set to 'higgins'
03:00:12 <hongbin> #link https://wiki.openstack.org/wiki/Higgins#Agenda_for_2016-05-24_0300_UTC Today's agenda
03:00:18 <hongbin> #topic Roll Call
03:00:42 <yuanying> hi
03:00:48 <haiwei_> hi
03:00:53 <hongbin> hey
03:00:56 <shu-mutou> o/
03:01:05 <sheel> hi
03:01:06 <mkrai> o/
03:01:11 <Vivek___> o/
03:01:57 <hongbin> pause a few seconds for other attendees
03:02:41 <sudipto> o/
03:03:32 <hongbin> Thanks for joining the meeting yuanying haiwei_ shu-mutou sheel mkrai Vivek___ sudipto
03:03:41 <hongbin> #topic Introductions (For attendees not present on the first meeting)
03:03:50 <Namrata> O/
03:03:58 <hongbin> Namrata: hey
03:04:04 <WangJian> hi
03:04:07 <hongbin> Anyone want to introduce themselves?
03:05:11 <yanyanhu> hi, sorry, I'm late
03:05:21 <hongbin> yantarou: NP
03:05:46 <hongbin> I didn't see Vivek___ sudipto WangJian  at the first meeting
03:05:48 <sudipto> Hi, I am contributor to nova atm (and glance) and i am also looking at hyper/kubernetes as my area of interest.
03:06:04 <WangJian> I am from China, and I working in Huawei. Very glad to work with you guys
03:06:19 <hongbin> Welcome sudipto WangJian
03:06:24 <haiwei_> welcome
03:06:24 <sudipto> working for Linux Technology Center/IBM India.
03:06:42 <sudipto> thanks hongbin
03:06:49 <Vivek___> Hi Hongbin, I was there but i was bit late in that meeting.
03:06:59 <hongbin> Vivek___: Oh, sorray about that
03:07:22 <hongbin> Anyone else want to introduce themselves?
03:07:26 <Vivek___> Hi, I am Vivek Jain an individual contributor based in  India.
03:07:43 <hongbin> Vivek___: Welcome to the Higgins team
03:07:50 <mkrai> Welcome everyone!
03:07:56 <hongbin> #topic Announcements
03:08:04 <hongbin> This is the second Higgins team meeting. We will hold a team meeting at this time every weeks.
03:08:25 <sheel> 👍
03:08:27 <hongbin> Hope this is a good time for everyone
03:08:33 <hongbin> #topic Review Action Items
03:08:41 <hongbin> 1. hongbin fill FAQ to explain the relationship between Magnum and Higgins (DONE)
03:08:49 <hongbin> #link https://wiki.openstack.org/wiki/Higgins#Frequently_Asked_Questions
03:09:09 <mkrai> Thanks hongbin for this one. It is really helpful
03:09:12 <mkrai> +1
03:09:20 <hongbin> my pleasure
03:09:37 <sheel> awesome..
03:09:41 <hongbin> Please feel free to edit the answers if you have anything to add to revise
03:10:09 <hongbin> Or feel free to discuss with me if you have any inputs
03:10:16 <hongbin> 2. hongbin schedule a weekly meeting for Higgins (DONE)
03:10:22 <hongbin> #link https://review.openstack.org/#/c/318335/ meeting at every Tuesday 0300UTC
03:10:45 <hongbin> As announced, we will have a weekly team meeting
03:11:02 <hongbin> This conclude the review action items
03:11:10 <hongbin> Any comment for that?
03:11:31 <hongbin> #topic Drive consensus on project scope
03:11:37 <hongbin> #link https://etherpad.openstack.org/p/container-management-service etherpad for collaborating on project requirements
03:11:47 <hongbin> At the first meeting, we discussed a little about the project scope.
03:11:58 <hongbin> We had everyone write down their preference in the etherpad above.
03:12:09 <hongbin> Right now, we need to decide based on the proposed requirements.
03:12:18 <hongbin> First, I will pause a few minutes for everyone review the etherpad for recap.
03:12:29 <hongbin> At the bottom of the etherpad, there is a decision session. We are going to discuss each bullet in that session.
03:13:37 <flwang> o/
03:13:49 <hongbin> flwang: hey
03:13:57 <flwang> hongbin: hey hongbin
03:13:58 <hongbin> flwang: we are reviewing the etherpad
03:14:01 <flwang> sorry for the late
03:14:04 <hongbin> flwang: NP
03:14:18 <hongbin> flwang: #link https://etherpad.openstack.org/p/container-management-service
03:14:26 <flwang> hongbin: oh, the original one
03:14:34 <hongbin> yes
03:15:41 <hongbin> If everyone finish the reading, we are going to debate the descision
03:16:58 <yanyanhu> I'm done
03:17:05 <mkrai> Me too
03:17:12 <sheel> yep
03:17:16 <yuanying> ok
03:17:18 <WangJian> done
03:17:29 <Qiming> o/
03:17:32 <hongbin> OK. Let's discuss the first item
03:17:42 <hongbin> 1. Container Abstraction
03:17:54 <hongbin> Qiming: hey
03:18:30 <hongbin> In the proposed project scope, there are several proposed container technologies
03:19:02 <hongbin> First, there are container runtimes, i.e. docker, clear container
03:19:09 <Qiming> yes, different layers / approaches for abstraction
03:19:17 <hongbin> Second, there are COEs, i.e. kubernetes, docker swarm, apache mesos
03:19:35 <hongbin> We need to decide which one to integrate
03:19:51 <hongbin> At least, decide which one to start with
03:19:57 <mkrai> Docker, rocket and clearcontainer
03:19:58 <hongbin> Opinions?
03:20:01 <mkrai> Docker will be our first phase implementation.
03:20:07 <yanyanhu> IMHO, docker should be the first one
03:20:09 <Qiming> I'd vote for basic container abstraction
03:20:23 <mkrai> I have already posted a patch for docker
03:20:25 <Qiming> leave the proxying for other COEs a future decision
03:20:29 <mkrai> +1 for docker
03:20:33 <yanyanhu> agree
03:20:38 <mkrai> Yes Qiming agree
03:20:47 <hongbin> It looks everyone agree to start with docker
03:20:55 <hongbin> Any opposing point of view?
03:21:08 <sudipto> +1 for docker
03:21:16 <haiwei_> agree
03:21:19 <hongbin> #agreed pick docker as the first integrated container runtime
03:21:20 <WangJian> docker +1
03:21:24 <flwang> +1
03:21:27 <shu-mutou> +1 for docker
03:21:36 <flwang> we should use #vote
03:21:39 <hongbin> For the second item, container management
03:21:50 <hongbin> flwang: oh, yes we can
03:22:03 <Vivek___> +1
03:22:09 <hongbin> everyone want to vote?
03:22:23 <Qiming> +1 for docker, but I'd propose we do it by separating the interface and the mechanism (driver)
03:22:28 <namrata_> +1
03:22:37 <sudipto> Qiming, +1
03:22:42 <mkrai> I guess it is clear
03:22:43 <hongbin> flwang: It looks everyone agree on docker, a vote is not necessary
03:22:57 <mkrai> so vote is not needed
03:22:57 <flwang> hongbin: hah, ok
03:23:10 <hongbin> OK. Go to the second item
03:23:13 <yanyanhu> maybe we can use vote for next topic  :)
03:23:41 <hongbin> There are four proposed items
03:23:50 <hongbin> 1. Basic container operations (i.e. CRUD)
03:23:56 <hongbin> 2. Advanced operations
03:24:04 <hongbin> 3. Scheduling containers
03:24:11 <hongbin> 4. Nested containers (containers on Nova instances) VS non-nested containers (containers on compute hosts)
03:24:22 <hongbin> At the fist meeting, we agreed on #1
03:24:32 <mkrai> Yes
03:24:33 <hongbin> So, I guess we don't need to debate it further?
03:24:48 <flwang> hongbin: yes :)
03:24:48 <mkrai> Correct
03:24:52 <yanyanhu> think so
03:24:54 <haiwei_> yes
03:24:54 <hongbin> How about #2
03:25:10 <sudipto> hongbin, i read through the first meeting logs, i was wondering - will there be focus on isolated/clear containers as well?
03:25:12 <yanyanhu> I suggest we leave it to upper layer services
03:25:13 <hongbin> Should Higgins support advanced operations (i.e. keep container alive)
03:25:37 <mkrai> Sure we will be supporting advance features in future but I guess it is not the right time to discuss
03:25:51 <mkrai> sudipto, Yes we are planning to
03:25:53 <hongbin> sudipto: I believe there will be a focus (personal opinion)
03:25:53 <haiwei_> agree mkrai
03:25:54 <yuanying> +1 mkrai
03:25:54 <yanyanhu> at least in current stage, we should focus on primitive support
03:26:19 <mkrai> Yes hongbin we should support
03:26:43 <sudipto> hongbin, some of the workflow for hyper type containers actually use qemu - which kind of overlaps with nova's code. However, that is probably a topic for discussion later.
03:27:00 <hongbin> sudipto: ack
03:27:19 <hongbin> I guess everyone don't want to support advanced operations?
03:27:37 <yanyanhu> yes, at least not now :)
03:27:39 <haiwei_> no now
03:27:39 <hongbin> Then, I am going to cross it out of the list
03:27:46 <sheel> hongbin: should be supproted but in future after basic setup ready
03:27:59 <Qiming> I'd vote for keeping the scope limited for now, for several reasons: 1. personally, I'd like to view  Higgins a 'container' flavor of nova, just like Ironic, a 'bare-metal' flavor of nova, leaving upper layer orchestration to other projects; 2. lessons learned from the past, when you put something there public, you will NEVER get a chance to deprecate it ...
03:27:59 <mkrai> hongbin, I think you can mark it for later
03:28:05 <hongbin> #agreed Higgins won't consider support advanced container operation at short time
03:28:23 <hongbin> Qiming: +1
03:28:41 <hongbin> #3 support scheduling for containers
03:28:49 <hongbin> I think this is a must?
03:28:56 <mkrai> Yes a must
03:29:01 <yanyanhu> yea
03:29:15 <mkrai> And how we are going to do it in first phase?
03:29:28 <haiwei_> should we consider No4 first?
03:29:36 <hongbin> I think we can implement a very simple scheduler to start
03:29:42 <sudipto> hongbin, mkrai when we start supporting scheduling for containers - what happens when we get to the COEs (i believe at that time, we would want to be a passthrough?)
03:29:45 <hongbin> For example, randomly picking a host
03:30:16 <Qiming> we got to decide where to launch a container, but we should copy the interface design from nova
03:30:27 <hongbin> sudipto: We can decide it later, once we want to support COEs. I guess we can pass through
03:30:40 <mkrai> Yes sudipto
03:30:47 <hongbin> Qiming: Yes, copying nova scheduler is an option
03:30:53 <Qiming> a simple, naive scheduler is okay for the near future, but in the long run, we are not supposed to reinvent a scheduler
03:31:06 <mkrai> And I think it will be better
03:31:18 <hongbin> Qiming: nova is going to split out their scheduler into a separated project
03:31:27 <sheel> Qiming: +1
03:31:38 <Qiming> yes, so I said 'copy the interface design', not the code
03:31:48 <hongbin> Qiming: I see
03:32:13 <mkrai> Yes because our use case may vary
03:32:15 <flwang> and inintially, we just need to support a roundrobin and add more scheduler driver later
03:32:21 <sudipto> hongbin, mkrai - while designing the scheduler - i am bit concerned about the metrics that would be used here. Unlike nova, we should start with a pluggable architecture there - that is - there could be various sources of metrics generation and not dependence on another higgins component IMHO.
03:32:26 <Qiming> flwang, +1
03:33:12 <janonymous_> Hi
03:33:21 <haiwei_> flwang +1
03:33:27 <hongbin> sudipto: Yes, we could discuss the scheduler implementation details later
03:33:32 <sheel> flwang:  right
03:33:40 <sudipto> hongbin, sure.
03:33:41 <flwang> we don't really need a fancy scheduler for now, which could be done later after we figure out what's the metrics we really care about
03:33:42 <mkrai> It is a huge topic
03:33:48 <hongbin> Right now, we just need to decide what to do, not necessary how to do it
03:34:07 <sudipto> hongbin, mkrai sure.
03:34:09 <flwang> i'm thinking higgins cases maybe different from nova's
03:34:34 <hongbin> #4 Support nested VM (VS none-nested VM)
03:35:00 <flwang> keep it simple
03:35:03 <hongbin> Should we start with nested VM use case, or non-nested VM use case, or both?
03:35:06 <mkrai> Non nested
03:35:11 <sudipto> mkrai, +1
03:35:16 <Vivek___> +1
03:35:22 <Qiming> so the todo could be: 1. an scheduler interface design (copy from nova). 2. a dummy scheduler plugin doing things like round-robin
03:35:25 <yanyanhu> maybe we should abstract the host from the beginning?
03:35:25 <yuanying> nested VM means, user managed  VM ?
03:35:36 <hongbin> Qiming: +1
03:35:58 <hongbin> yuanying: Nested VM means running containers in VMs
03:36:05 <hongbin> yuanying: like what Magnum is doing
03:36:09 <yanyanhu> containers -> abstracted host -> VM/Baremetal?
03:36:19 <Qiming> yanyanhu, +1
03:36:32 <mkrai> yanyanhu, And compute hosts also
03:36:32 <hongbin> yanyanhu: we have a topic later to discuss host management
03:36:46 <yanyanhu> hongbin, ok
03:36:58 <hongbin> I guess everyone agree to start with non-nested VM use case
03:37:07 <hongbin> Any opposing point of view?
03:37:08 <haiwei_> agree
03:37:17 <WangJian> agree
03:37:19 <janonymous_> +1
03:37:21 <mkrai> +1
03:37:28 <yanyanhu> +1
03:37:30 <shu-mutou> +1
03:37:31 <hongbin> #agreed support non-nested container use case as a start
03:37:33 <Vivek___> +1
03:37:34 <sheel> agree
03:37:37 <namrata_> +1
03:37:50 <hongbin> #3 container composition
03:38:06 <hongbin> Should we support docker-compose like feature
03:38:30 <hongbin> opinions?
03:38:39 <yuanying> I read this document, https://coreos.com/rkt/docs/latest/running-lkvm-stage1.html
03:38:41 <Qiming> em ... sounds like a Heat job
03:38:45 <yanyanhu> +1
03:39:05 <flwang> hongbin: i vote yes
03:39:09 <yuanying> This document suppose how to use hyper/clear container technology
03:39:17 <flwang> think it's a common simple tool for developer
03:39:28 <Qiming> yes, it is simple
03:39:37 <Qiming> but maybe too simple to meet user requirements
03:39:39 <mkrai> yes we should
03:39:49 <Qiming> suppose you want to make some changes to the containers deployed
03:39:49 <mkrai> yuanying, Yes rocket supports clear container
03:39:54 <yanyanhu> I guess user can use heat to achieve this goal
03:40:03 <sudipto> Qiming, +1 -
03:40:08 <Qiming> how would you do that? change the yml file and run 'docker-compose' again?
03:40:18 <yanyanhu> so we may need to consider its relationship with heat template
03:40:30 <mkrai> the same way docker does it?
03:40:41 <mkrai> Why heat here? yanyanhu
03:41:18 <Qiming> a structured definition or a delcarative language helps simplify the initial deployment, but it is not a great tool for daily operations
03:41:21 <yanyanhu> mkrai, because heat is orchestration service, so deployment is part of its scope
03:41:32 <yanyanhu> so there should be overlap here I think
03:42:02 <hongbin> It looks there are two opposing point of view
03:42:07 <hongbin> 1. It belongs to higgins
03:42:12 <mkrai> yanyanhu, you mean deployment of containers?
03:42:12 <hongbin> 2. It belongs to Heat
03:42:14 <haiwei_> yanyanhu, you mean Heat can do the things what docker-compose does?
03:42:33 <yanyanhu> mkrai, could be
03:42:42 <yanyanhu> and also the app/service upon container
03:42:56 <hongbin> OK. I guess it is better to table this one
03:43:07 <hongbin> We can discuss it in the ML instead
03:43:08 <yanyanhu> user can use heat template to describe this kind of deployment if they will I think
03:43:31 <Qiming> yes, hongbin, we don't need to rush to a conclusion here
03:43:41 <hongbin> Qiming: ack
03:43:54 <hongbin> Next one
03:44:06 <hongbin> Conainer host management
03:44:08 <Qiming> I'm also thinking of other use cases, where users want to model things in TOSCA
03:44:13 <yanyanhu> mkrai,  maybe my misunderstanding, but I hope we can have a more thorough discussion for this topic :)
03:44:26 <mkrai> Yes sure. ML is needed
03:44:38 <hongbin> #action Hongbin start a ML to discuss the container composition topic
03:44:59 <hongbin> OK. Docker host management
03:45:19 <Qiming> the key of the docker-compose proposal is about ease-of-use, ease-of-management, that is something we should keep in mind as well
03:46:06 <hongbin> yanyanhu: you had a comment for host management before?
03:46:18 <yanyanhu> yes, about the abstraction layer
03:46:37 <yanyanhu> to hide the type of host from scheduler
03:46:52 <hongbin> like how nova does?
03:47:03 <yanyanhu> yes
03:47:10 <hongbin> ack
03:47:28 <Qiming> 'host' management is a must, IMO, but we should be careful when exposing a user API
03:47:46 <hongbin> Yes
03:47:50 <WangJian> will it include what docker machine does?
03:48:01 <Qiming> em.. interesting
03:48:12 <hongbin> I guess it is different
03:48:28 <hongbin> docker machine is for provision a machine (per my understanding)
03:48:29 <mkrai> Heat will be our first choice when supporting nested vms?
03:48:48 <hongbin> nova compute agent is for managing the hosts
03:49:12 <hongbin> mkrai: not sure from me
03:49:51 <hongbin> I agree with Qiming that host management is a must, otherwise, the scheduler is not going to work
03:50:03 <Qiming> I see, if we are never gonna support containers on VMs, host management is not that interesting, it becomes completely a nova thing
03:50:37 <mkrai> We will support it Qiming
03:50:57 <WangJian> +1 Qiming
03:51:02 <yanyanhu> agree
03:51:12 <sudipto> Qiming, hongbin by host management are we referring to Ironic sort of a thing or compute driver sort of a thing?
03:51:22 <WangJian> I think we can support docker machine later
03:51:33 <Qiming> if we will support containers on abstract hosts (VMs or baremetals), higgins has to know the nature of the 'host', what/where are they
03:51:54 <Qiming> sudipto, it is more of a compute driver thing, IMO
03:52:13 <hongbin> However, we decided to start with non-nested use case
03:52:30 <hongbin> That means we don't need to worry the containers on VMs/Ironic right now
03:52:33 <Qiming> starting from baremetal sounds good
03:52:41 <yanyanhu> hongbin, there can be an abstraction layer and bare metal can be the first kind of "physical" host
03:52:53 <sudipto> Qiming, precisely. hence my earlier comment on the metrics gathering stuff. I don't think this can be based on nova - simply because nova does it based on the hypervisor.
03:53:13 <hongbin> yanyanhu: ack
03:53:55 <haiwei_> my concern is who will control the host, in other words, where does the 'host' come from? It should come from Nova? or not
03:54:09 <sheel> we are left with 6 more minutes
03:54:09 <Qiming> agreed, sudipto, just want to remind folks ... let's keep the design open
03:54:12 <yuanying> haiwei_: We will not use nova to manage
03:54:13 <yuanying> host
03:54:43 <haiwei_> then use what?
03:54:50 <mkrai> hongbin, get this to ML?
03:55:06 <yuanying> host will be set up by operator's hand
03:55:09 <hongbin> #action hongbin start a ML to discuss container host management
03:55:18 <hongbin> #topic Open Discussion
03:55:39 <sheel> project name -do we need change?
03:55:58 <hongbin> sheel: you have a better name?
03:56:04 <mkrai> We need more contributors :)
03:56:19 <sheel> hongbin: I was looking into start casts of magnum pi
03:56:19 <sudipto> We haven't talked Image management at all, wondering if we intend to use a proxy to docker registry or something.
03:56:22 <sheel> ;)
03:56:44 <mkrai> That is still in todo sudipto
03:56:45 <hongbin> sudipto: we can cover that in the next meeting
03:57:02 <yanyanhu> sudipto, I'm not clear about the detail, but I guess we can follow the way that nova-docker is using?
03:57:23 <hongbin> I think nova-docker is using glance
03:57:28 <yanyanhu> yes
03:57:30 <sudipto> mkrai, hongbin - next meeting sounds reasonable. yanyanhu - yeah that would mean docker tar files in glance.
03:57:42 <hongbin> THe feedback is not so good, because glance don't support layers of images
03:57:45 <Qiming> then, go glance, ;)
03:58:05 <yanyanhu> hongbin, that is a problem...
03:58:08 <hongbin> For glance, the docker images don't have layers anymore
03:58:34 <Qiming> so .. no longer docker push, docker pull, ;)
03:58:42 <sudipto> hongbin, yeah - there's a new project called Glare. I will have some update on this in the next meeting.
03:58:57 <mkrai> Thanks sudipto
03:59:04 <hongbin> sudipto: ack
03:59:17 <Qiming> if Higgins is focused on providing container lifecycle/runtime management, we can ignore the 'push/pull' requirement
03:59:33 <hongbin> maybe
03:59:39 <hongbin> OK. time is up
03:59:49 <mkrai> Thanks everyone!
03:59:50 <sudipto> Alrite, thanks everyone!
03:59:53 <hongbin> Everyone. Thanks for joining the meeting
03:59:58 <Qiming> bye
03:59:59 <sheel> Thank you guys
04:00:01 <yanyanhu> thanks
04:00:03 <namrata_> Thanks ..bye
04:00:04 <Vivek___> Thanks
04:00:05 <WangJian> thx, bye
04:00:06 <haiwei_> thanks
04:00:09 <hongbin> Hope to see you all in the next meeting
04:00:10 <shu-mutou> thx, bye
04:00:13 <hongbin> #endmeeting