03:00:03 <hongbin> #startmeeting higgins
03:00:04 <openstack> Meeting started Tue May 31 03:00:03 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: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-31_0300_UTC Today's agenda
03:00:17 <hongbin> #topic Roll Call
03:00:23 <yuanying> OTSUKA, Yuanying
03:00:31 <madhuri> Madhuri Kumari
03:00:40 <Namrata> Namrata Sitlani
03:00:49 <yanyanhu> hi, yanyan hu
03:00:54 <haiwei_> xuhaiwe
03:00:58 <haiwei_> xuhaiwei, hi
03:01:22 <adisky> hi, aditi
03:02:02 <eliqiao> hi
03:02:26 <hongbin> Thanks for joining hte meeting yuanying madhuri Namrata yanyanhu haiwei_ adisky eliqiao
03:02:48 <hongbin> Pause a few more minutes for potential participants
03:03:09 <shu-mutou> o/
03:03:19 <hongbin> hey shu-mutou
03:03:26 <Qiming> o/
03:04:18 <hongbin> hey Qiming
03:04:20 <hongbin> #topic Announcements
03:04:31 <flwang1> o/
03:04:34 <hongbin> I have no annoucement
03:04:48 <hongbin> Anyone else has annoucement?
03:04:55 <hongbin> flwang1: hey
03:05:10 <Qiming> announcement: flwang1 joined
03:05:10 <hongbin> #topic Review Action Items
03:05:17 <hongbin> Qiming: :)
03:05:17 <flwang1> Qiming: :)
03:05:23 <hongbin> 1. Hongbin start a ML to discuss the container composition topic (DONE)
03:05:28 <hongbin> #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/095833.html
03:05:57 <hongbin> From the ML, it looks we agree to revisit the idea later
03:06:11 <hongbin> Comments?
03:06:21 <madhuri> Yes agree
03:06:24 <flwang1> hongbin: as for that thread, i think Joshua mad a valid point
03:06:38 <hongbin> flwang1: could you elaborate more?
03:06:38 <flwang1> s/mad/make
03:07:04 <flwang1> we need to define a vision for higgins
03:07:18 <hongbin> Yes, that is true
03:07:40 <hongbin> I can tell you that I have a vision, everyone else has it too
03:07:53 <hongbin> So we have a meeting to gather opinions
03:08:13 <hongbin> flwang1: you have any suggestion for that?
03:08:20 <hongbin> like actionable suggestion
03:08:57 <flwang1> hongbin: i think we should define some basic features and advanced features
03:09:07 <flwang1> and create some small sub teams
03:09:07 <hongbin> agree
03:09:14 <eliqiao> +1
03:09:20 <flwang1> to investigate those advanced topics
03:09:35 <flwang1> and report/propose in ML and with specs
03:10:00 <hongbin> wfm
03:10:22 <flwang1> IMHO, which can speed up our progress
03:10:33 <hongbin> OK
03:10:35 <flwang1> and to avoid duplication effort
03:10:43 <flwang1> duplicated
03:10:52 <flwang1> just my 2 cents
03:11:00 <hongbin> For basic features, I tried to define them in this meeting
03:11:26 <hongbin> For advanced features, I need to identify the list of features that needs to be discussed
03:11:39 <hongbin> Then, discuss it one-by-one
03:12:03 <hongbin> #action hongbin collect a list of advanced features
03:12:20 <hongbin> flwang1: sounds good?
03:12:42 <eliqiao> I have a basic question, what the archeture looks like for higgins? only higgins-api and higgins-cond?
03:12:50 <flwang1> hongbin: good, thanks
03:12:59 <eliqiao> should we run a agent on each host like nova does?
03:13:11 <madhuri> eliqiao: Yes for now
03:13:13 <flwang1> eliqiao: it's related to the scope, IMHO
03:13:19 <hongbin> eliqiao: I think yes
03:13:47 <hongbin> Let's discuss it later in the agenda
03:13:54 <eliqiao> ok
03:14:02 <hongbin> Maybe in hte open discussion
03:14:10 <hongbin> 2. hongbin start a ML to discuss container host management (DONE)
03:14:19 <hongbin> #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/095833.html
03:14:42 <hongbin> For this one, it looks we agree to not expose host to end-users
03:14:58 <yanyanhu> yea
03:15:08 <hongbin> However, I think it is really up to operators
03:15:27 <hongbin> Eventually, operators need to tune the policy.json to decide which APIs to expose
03:15:29 <flwang1> hongbin: yep, we do have host apis, but admin only
03:15:50 <hongbin> OK, Le't make the host API default to admin only
03:15:57 <hongbin> Agree?
03:16:00 <eliqiao> +1
03:16:02 <yanyanhu> hongbin, that's reasonable
03:16:03 <madhuri> Yes
03:16:19 <hongbin> #agreed make host api admin only by default
03:16:28 <hongbin> #topic Project rename (shu-mutou)
03:16:50 <hongbin> shu-mutou: could you propose the idea?
03:16:59 <hongbin> #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/095746.html ML discussion
03:17:25 <shu-mutou> How about "Gatling"? It's only association from Magnum. It's not used on both Launchpad and PYPI.
03:17:55 <madhuri> What does Gatling mean?
03:18:12 <eliqiao> madhuri: a gun
03:18:18 <shu-mutou> yes
03:18:21 <yanyanhu> machine gun :)
03:18:54 <madhuri> We could have some more options and then have a voting
03:18:58 <hongbin> shu-mutou: maybe you can explain a bit about why renaming is necessary?
03:18:59 <madhuri> What do you guys think?
03:19:33 <shu-mutou> Now, our project name on Launchpad and PYPI (=package name) is 'python-higgins', because 'higgins' is already used in other product.
03:19:56 <haiwei_> the 'Gatling' word is not using by some business use?
03:20:21 <shu-mutou> It means 'python-higgins' is used for package name.
03:20:59 <flwang1> maybe we can  ask TC or foundation to get some legal support about the name
03:21:26 <shu-mutou> haiwei_: I'm not sure, but 'gatling' is not used in Launchpad and PYPI
03:22:05 <shu-mutou> flwang1: yes. The naming 'python-higgins' is according to the guide for project naming as following. http://docs.openstack.org/infra/manual/creators.html#choosing-a-good-name-for-your-project It says, "Try 'python-' as a prefix if necessary".
03:22:54 <Qiming> I'm not sure 'gatling' is a good option
03:23:01 <haiwei_> there is a test tool named gatling https://github.com/gatling/gatling
03:23:21 <Qiming> better avoid some sensitive words in a project name
03:24:05 <hongbin> OK. Let's table this if we cannot think of a perfect name
03:24:37 <hongbin> #action hongbin raise a ML to collect idea of project naming
03:24:49 <hongbin> #topic Drive consensus on project scope
03:24:58 <hongbin> #link https://etherpad.openstack.org/p/container-management-service etherpad for collaborating on project requirements
03:25:35 <hongbin> In the etherpad, at the bottom, there is a set of decision to make
03:25:55 <hongbin> That includes the basic features and advanced features
03:26:13 <hongbin> In the last meeting, we covered half of the list
03:26:25 <hongbin> Let's start with what is left over
03:26:43 <hongbin> Topic: Integration with Other OpenStack Project
03:27:16 <hongbin> There are a list of projects were mentioned as intergration candidates
03:27:19 <hongbin> 1. Nova
03:27:25 <hongbin> 2. Magnum
03:27:31 <hongbin> 3. Heat
03:27:38 <hongbin> 4. Neutron/Kuryr
03:27:44 <hongbin> 5. Cinder
03:27:46 <hongbin> 6. Glance
03:27:52 <hongbin> 7. Keystone
03:28:46 <hongbin> For me, we should start a project with minimum dependencies
03:28:47 <Qiming> 1, 4, 5, 6, 7 sound higher priority to me
03:29:05 <hongbin> Qiming: ack
03:29:21 <hongbin> Qiming: 6 is interesting
03:29:27 <Qiming> 2, 3, are more of higher level orchestration / management
03:29:41 <Qiming> right, to start a container, you will need to provide an image somewhere
03:29:57 <Qiming> that "somewhere" in the openstack native way would be glance
03:30:00 <hongbin> An alternative is docker registry
03:30:30 <hongbin> OH, we know we can host a private docker registry backed by swift
03:30:41 <madhuri> 4 is also a priority
03:30:59 <hongbin> For glance, I know there is a drawback, which is that it cannot support layers of images
03:31:36 <eliqiao> maybe we chose swift which will be better than glance
03:31:39 <Qiming> layers of images ... is it a hard requirement?
03:31:48 <flwang1> hongbin: yep, layered images is in review
03:31:59 * flwang1 is putting his glance hat
03:32:11 <hongbin> No, layer of images is not a hard requirement
03:32:25 <hongbin> flwang1: That is great
03:32:27 <flwang1> hongbin: i can take a look at that
03:32:35 <Qiming> layered images sounds more like a docker-specific thing
03:32:35 <flwang1> i mean from the higgins side
03:33:07 <hongbin> ok
03:33:12 <Qiming> if we focus on providing a openstack native runtime support for containers, image layering is not that interesting, imho
03:33:41 <hongbin> maybe
03:34:16 <hongbin> flwang1: right now, glance supports docker image?
03:34:26 <hongbin> flwang1: if not, what is the timeline?
03:34:28 <flwang1> hongbin: yes
03:34:39 <hongbin> flwang1: do you have any link?
03:35:07 <Qiming> glare?
03:35:15 <hongbin> oh, glare?
03:35:17 <flwang1> hongbin: a good proof https://github.com/openstack/nova-docker#1-enable-the-driver-in-glances-configuration :D
03:35:30 <hongbin> nice
03:35:32 <hongbin> #link https://github.com/openstack/nova-docker#1-enable-the-driver-in-glances-configuration
03:35:40 <hongbin> Then, I have no problem for glance
03:36:27 <flwang1> hongbin: :) cool
03:36:31 <hongbin> Back to the integration list, Qiming mentioned 1, 4, 5, 6, 7
03:36:45 <hongbin> What are other opinions
03:36:52 <madhuri> 4
03:36:52 <flwang1> hongbin: yep, i will take a look at the #6, Glance part
03:37:02 <hongbin> flwang1: thx
03:37:30 <wang-jian> madhuri
03:37:30 <wang-jian> madhuri;: +1
03:37:39 <madhuri> Is Kuryr ready to be used?
03:37:39 <hongbin> Qiming: I think 1 could be optional at current stage
03:37:48 <madhuri> Agree hongbin
03:38:06 <madhuri> We are implementing non-nested containers in first stage
03:38:16 <eliqiao> what function will nova provide us?
03:38:24 <eliqiao> create vm as higgins host?
03:38:32 <hongbin> madhuri: AFAIK, it is not stable yet
03:38:33 <madhuri> Host to run containers
03:38:34 <yanyanhu> actually, even for nested cases, we may no need talk to nova directly :)
03:39:26 <yanyanhu> some services can help us manage VMs easily I think
03:39:33 <madhuri> How yanyanhu ?
03:39:59 <yanyanhu> e.g. Heat as what magnum is doing
03:40:05 <Qiming> so... we are not adopting nova-docker ?
03:40:07 <yanyanhu> or Senlin
03:40:14 <hongbin> eliqiao: 1) container host, 2) compute API to call higgins
03:40:39 <Qiming> eliqiao, I'm thinking about scheduling
03:41:05 <eliqiao> Qiming: get it
03:41:07 <Qiming> but ... maybe we can start something simple stupid
03:41:21 <flwang1> hmm... i think Higgins is on the similar position like Ironic
03:41:23 <hongbin> Qiming: Use nova scheduler, higgins as a virt-driver?
03:41:52 <flwang1> hongbin: yes, that's one of two ways
03:41:56 <Qiming> yep, I think we may take nova-docker
03:42:11 <hongbin> I think so, we are replacing nova-docker
03:42:25 <hongbin> However, I am not sure if it is a priority now
03:42:28 <madhuri> But container and vms have different use cases. So will nova-scheduler fit for us?
03:42:31 <Qiming> on one hand, we keep nova-docker alive ... and higgins provide a simple naive driver for nova
03:42:47 <Qiming> on the other hand, higgins is growing its own apis
03:43:00 <hongbin> Yes, we should support two APIs
03:43:02 <hongbin> 1. nova
03:43:10 <hongbin> 2. higgins native
03:43:21 <yanyanhu> madhuri, so I guess leveraging those services can provide higgins an easier way to manage those VM which will be used as container host
03:43:27 <flwang1> hongbin: yes, +1 for that
03:43:41 <Qiming> we don't have a lot to do regarding #1
03:43:52 <hongbin> Qiming: ack
03:44:14 <hongbin> Let's call out each one
03:44:18 <hongbin> For #1, nova
03:44:38 <hongbin> Do everyone agree this is a priority?
03:44:55 <yanyanhu> agree
03:44:59 <flwang1> hongbin: it's
03:45:03 <madhuri> Yes scheduling is
03:45:18 <hongbin> any opposing point of view?
03:45:31 <haiwei_> not a priority currently I think
03:45:58 <hongbin> haiwei_: could you elaborate a bit?
03:46:33 <haiwei_> what is the thing you want if you want to do with Nova? scheduler?
03:47:08 <haiwei_> or host?
03:47:11 <wang-jian> Maybe we can focus on higgins own apis for now, and implement a simple sheduler
03:47:19 <hongbin> I guess the benefit is a single compute API for container/VM/baremetal
03:47:44 <madhuri> hongbin: I don't get it
03:48:02 <madhuri> Could you please explain last point?
03:48:11 <hongbin> madhuri: launching vm/container/baremetal with a single API
03:48:17 <madhuri> We are writing our own APIs
03:48:24 <eliqiao> container and vm has different APIs, but how can we reuse nova API?
03:48:29 <madhuri> hongbin: From nova?
03:48:37 <hongbin> madhuri: Ironic has its own API
03:48:46 <hongbin> madhuri: but it can be called by nova api
03:49:04 <hongbin> madhuri: Ironic API is a superset of nova API
03:49:12 <madhuri> Ok got it
03:49:27 <yanyanhu> actually, there was a long discussion in ML about unified API interface for bare metal/VM/containers
03:49:30 <madhuri> hongbin: Thanks for the explanation
03:49:33 <yanyanhu> higgins will be part of it :)
03:49:48 <hongbin> Let's table the nova
03:49:59 <hongbin> We can discuss it later
03:50:14 <hongbin> 4. Kuryr/Neutron
03:50:17 <Qiming> that is interesting ... "container and VM has different APIs" ... is it a conclusion or a premise?
03:50:47 <eliqiao> Qiming: permise
03:50:48 <hongbin> Qiming: I believe they do have different API, with a common set
03:51:20 <hongbin> container and vm share some common features, but vary differently on each other
03:51:39 <Qiming> eliqiao, if that premise is true, you don't need openstack at all, ;)
03:51:50 <hongbin> ........
03:51:54 <eliqiao> ...
03:52:18 <eliqiao> Qiming: I agree that we can think higgins as Ironic
03:52:45 <flwang1> eliqiao: cool, more guys are on the same page :D
03:52:47 <Qiming> openstack is irrelevant if you really need the unique features of containers (or more specifically, dockers)
03:53:13 <Qiming> +1, on that metaphor
03:53:37 <hongbin> Qiming: that is why we need to provide both APIs, higgins and nova
03:53:50 <Qiming> yes, hongbin, totally agree
03:54:00 <madhuri> +1 hongbin
03:54:02 <hongbin> THe prboem is which one is hte priority
03:54:19 <hongbin> I guess both are needed
03:54:26 <yanyanhu> the common set?
03:54:29 <Qiming> IMHO, they are equally important
03:54:33 <hongbin> But we disagreed on which one we should focus right now
03:54:55 <hongbin> Qiming: Yes, maybe both are important
03:55:16 <madhuri> Higgins API is priority now
03:55:29 <Qiming> can we start with some use cases and work on some API design?
03:55:29 <madhuri> the basic CRUD APIs
03:55:38 <yanyanhu> madhuri, that's for sure
03:55:40 <yanyanhu> +1
03:55:46 <Qiming> yes, basic CRUD
03:55:54 <flwang1> Qiming: +1, re define core user case
03:56:17 <eliqiao> if I get the nova part correctlly, we may need to implement a virt-driver and put it to nova repo, right?
03:56:22 <madhuri> We have few mins left
03:56:23 <hongbin> #agreed define core use cases for API design
03:56:31 <madhuri> Yes eliqiao
03:56:40 <eliqiao> Nova doesn't support 3rd part driver now.
03:56:50 <hongbin> #topic Open Discussion
03:57:06 <hongbin> Sorry, don't have time to cover other integrating projects yet
03:57:07 <eliqiao> and Nova is spec freeze this thursday
03:57:14 <yanyanhu> hi, hongbin, just post some comments on your draft of announcement of higgins project
03:57:17 <yanyanhu> https://etherpad.openstack.org/p/higgins-announcing-statement
03:57:17 <madhuri> Anyone tried setting up Higgins
03:57:25 <hongbin> yanyanhu: will check that. thx
03:57:30 <yanyanhu> but they are just suggestion :)
03:57:31 <madhuri> We need it to pace up the work
03:57:40 <eliqiao> madhuri: yes, I did
03:57:56 <madhuri> DB part is not yet ready I guess
03:58:12 <madhuri> eliqiao: What were your observation?
03:58:17 <hongbin> madhuri: The API part is not ready as well
03:58:39 <madhuri> Yes I will be working on it to have a running Higgins
03:58:54 <eliqiao> we have devstack plugin now
03:58:57 <madhuri> It's at highest priority now
03:59:25 <hongbin> Last minute
03:59:32 <hongbin> Let's wrap up
03:59:37 <madhuri> Thanks everyone
03:59:43 <yanyanhu> need more eyes on this patch https://review.openstack.org/319143 I think
03:59:47 <hongbin> All, thanks for joining hte meeting. Hope to see you all in the next team meeting
03:59:53 <yanyanhu> it's important as well
03:59:55 <hongbin> #endmeeting