16:00:03 <hongbin> #startmeeting containers
16:00:03 <openstack> Meeting started Tue Jun  7 16: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.
16:00:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:07 <openstack> The meeting name has been set to 'containers'
16:00:09 <hongbin> #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2016-06-07_1600_UTC Today's agenda
16:00:14 <hongbin> #topic Roll Call
16:00:16 <strigazi> Spyros Trigazis
16:00:18 <Drago> o/
16:00:22 <swatson> Stephen Watson
16:00:23 <muralia> Murali Allada
16:00:31 <dane_leblanc> o/
16:00:33 <rpothier> o/
16:00:38 <mkrai> Madhuri Kumari
16:00:41 <tcammann> sup
16:01:28 <hongbin> Thanks for joining the meeting strigazi Drago swatson muralia dane_leblanc rpothier mkrai tcammann
16:01:37 <hongbin> #topic Announcements
16:01:44 <eghobo> o/
16:01:45 <hongbin> I have no announcement
16:01:56 <hongbin> Any announcement from our team members?
16:02:24 <hongbin> #topic Review Action Items
16:02:51 <hongbin> Let me pull the previous meeting
16:03:30 <hongbin> hongbin send a ML to lbaas team to ask for installation instruction
16:03:32 <hongbin> Done
16:03:59 <hongbin> #link http://lists.openstack.org/pipermail/openstack-dev/2016-June/096369.html
16:04:22 <hongbin> It looks lbaas team don't have an official guide
16:04:48 <hongbin> What they have is like a developer facing guide
16:04:59 <tcammann> Do they have any puppet or ansible modules for install?
16:05:13 <hongbin> not sure from me
16:05:18 <juggler_> o/
16:05:34 <tango> o/
16:05:44 <hongbin> strigazi: do you have any idea about tcammann question?
16:06:05 <strigazi> Didn't check, I don't think so
16:06:14 <strigazi> Best case they have a puppet module
16:06:50 <strigazi> https://github.com/openstack/puppet-neutron/blob/master/manifests/agents/lbaas.pp
16:07:20 <hongbin> Any other question?
16:07:26 <strigazi> They missing guide is another reason to decouple :)
16:07:50 <hongbin> #topic Essential Blueprints Review
16:07:55 <hongbin> 1. Support baremetal container clusters (strigazi)
16:08:00 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/magnum-baremetal-full-support
16:08:04 <hongbin> strigazi: status?
16:08:12 <adrian_otto> o/
16:08:32 <strigazi> I don't have much this week, I was busy. Yuanying did some progress today
16:08:45 <strigazi> I haven;t tested it yet
16:09:20 <hongbin> strigazi: Do you need any help for others for that?
16:09:32 <strigazi> no, but
16:09:58 <strigazi> Does anyine want to work on this 1.1 Upgrade the Ironic image building elements to fedora 23
16:10:13 <strigazi> s/anyine/anyone
16:10:37 <tango> I can give that a shot
16:10:47 <strigazi> ok, thanks tango
16:10:50 <hongbin> tango: thanks Ton
16:11:07 <hongbin> Any other comment about this BP?
16:11:34 <hongbin> 2. Magnum User Guide for Cloud Operator (tango)
16:11:39 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/user-guide
16:11:50 <tango> I have a patch for the Kubernetes section
16:11:57 <tango> Now working on the Swarm section
16:12:12 <tango> For Mesos, I will wait for DCOS
16:12:25 <hongbin> #link https://review.openstack.org/#/c/326158/ User guide for kubernetes session
16:12:26 <tango> but I will write it along side with the development
16:12:47 <tango> as WIP, so the section will be ready when we have DCOS bay
16:13:11 <tango> that's all for now
16:13:17 <hongbin> Thanks Ton
16:13:20 <muralia> tango: I can work on updating the bay driver section.
16:13:41 <tango> That would be great, please feel free to add yourself as co-author
16:13:47 <muralia> sure
16:14:01 <hongbin> Thanks muralia
16:14:08 <hongbin> 3. COE Bay Drivers (jamie_h)
16:14:14 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/bay-drivers
16:14:24 <hongbin> muralia: you have any update?
16:14:24 <muralia> So I've updated the implementation patch. https://review.openstack.org/#/c/319973
16:14:58 <muralia> please add comments. nothing is hooked up yet, but it has the new folder structure
16:15:11 <muralia> and I've split the template_def files for swarm
16:15:36 <muralia> I'm woking on adding support for stevedore this week for dynamic loading
16:15:47 <muralia> will submit another update soon
16:16:15 <muralia> thats it for now
16:16:32 <hongbin> Thanks muralia . Comments from others?
16:16:57 <hongbin> 4. Create a magnum installation guide (strigazi)
16:17:03 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/magnum-installation-guide
16:17:03 <strigazi> http://docs.openstack.org/developer/magnum/install-guide-from-source.html
16:17:07 <strigazi> \o/
16:17:22 <hongbin> Yes, the patch was landed
16:17:27 <adrian_otto> nice
16:17:30 <strigazi> I'm testing the packaged guides now
16:18:01 <strigazi> on centos7 the guide is tested tested
16:18:13 <strigazi> working in ubuntu/debian
16:18:27 <strigazi> ubuntu takes the packages from debian
16:18:49 <strigazi> the packaged guide will be in
16:18:56 <strigazi> magnum/install-guide
16:19:14 <strigazi> and will be automatically published on docs.openstack.org
16:19:57 <strigazi> https://review.openstack.org/#/c/326039/
16:20:15 <strigazi> with the above change
16:20:20 <strigazi> that is all
16:20:26 <tango> Nice
16:20:27 <hongbin> strigazi: Thanks
16:20:52 <hongbin> I want to take this chance to regconize strigazi
16:21:01 <hongbin> He did a lot of work for hte installation guide
16:21:09 <juggler_> cheers strigazi!
16:21:18 <mkrai> Thanks strigazi
16:21:36 <strigazi> thank you all
16:21:38 <hongbin> Really appreciate your contribution strigazi
16:22:03 <hongbin> #topic Magnum UI Subteam Update (bradjones)
16:22:05 <adrian_otto> well done
16:22:21 <hongbin> I updated you on behalf of Shu
16:22:25 <hongbin> (Shu) I was investigating about registry service of Horizon, and I added one more BP [1] for tracking changes in Horizon.
16:22:31 <hongbin> (Shu) For [1], I started implementing a patch [2] (but WIP). And I have set dependency for related BPs [3][4].
16:22:36 <hongbin> (Shu) [1] https://blueprints.launchpad.net/magnum-ui/+spec/angular-registry
16:22:42 <hongbin> (Shu) [2] https://review.openstack.org/#/c/326289/
16:22:47 <hongbin> (Shu) [3] https://blueprints.launchpad.net/magnum-ui/+spec/generic-detail-framework
16:22:52 <hongbin> (Shu) [4] https://blueprints.launchpad.net/magnum-ui/+spec/navigation-improvements
16:23:05 <hongbin> That's all from my side
16:23:33 <hongbin> Comment?
16:24:03 <hongbin> #topic Kuryr Integration Update (tango)
16:24:20 <hongbin> For this one, I attended the Kuryr team meeting this week
16:24:29 <hongbin> AFAIK, fawadkhaliq is splitting the blueprints into smaller items so that the work can be shared.
16:24:56 <hongbin> After that, we can work with Kuryr team to address individual items
16:25:31 <hongbin> The major the pending work is deploying Kuryr agent to bay
16:25:58 <hongbin> That is all from me
16:26:02 <tango__> My session just crashed, rejoining
16:26:04 <hongbin> tango: do you have anything to add?
16:26:15 <hongbin> tango__: ^^
16:26:28 <tango__> I connected with the Fuxi team and started a dialog with them
16:26:35 <tango__> they shared some charts
16:27:01 <tango__> I will continue the discussion to see how we can collaborate
16:27:25 <tango__> I also started working on integrating Kuryr to the Swarm bay
16:27:52 <tango__> I have Kuryr working on devstack, still debugging on Swarm.
16:29:02 <tango__> Docker is able to talk to Kuryr on Swarm, but Kuryr is not talking to Neutron yet, so some more plumbing to be done
16:29:18 <tango__> That's all for now
16:29:25 <hongbin> tango__: anything you need from the team on this efforts?
16:29:41 <tango__> I think I am OK for now
16:29:49 <hongbin> tango__: Thanks Ton
16:30:08 <hongbin> Comments from others?
16:30:34 <hongbin> #topic Other blueprints/Bugs/Reviews/Ideas
16:30:40 <hongbin> 1. Support heterogenous cluster
16:30:45 <hongbin> #link http://lists.openstack.org/pipermail/openstack-dev/2016-June/096380.html ML discussion
16:30:50 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/manually-manage-bay-nodes the BP
16:31:01 <hongbin> Let's continue the debate here
16:31:37 <hongbin> For me, I support the idea of supporting heterogenious cluster
16:31:51 <hongbin> Because there are actual use cases for that
16:32:27 <hongbin> THere are different use cases reported by different people, so I guess the demand is universal
16:32:46 <hongbin> Any opposing point of view?
16:33:05 <adrian_otto> My concern about this is that I don't want Magnum to encourage bad application architecture and ops practices.
16:33:12 <kebray> hongbin, are the use cases documented on a wiki somewhere?
16:33:31 <hongbin> kebray: I listed the reported use cases in the BP
16:33:40 <hongbin> There are several others in the ML
16:33:57 <hongbin> adrian_otto: could you elaborate it further?
16:34:19 <adrian_otto> and nobody has responded to my question about why these apps cant be deployed using multiple homogeneous bays.
16:34:29 <kebray> great. thx.
16:34:36 <kebray> reviewing now
16:34:48 <hongbin> There are several disadvantage of deploying multiple homogeneous bays
16:34:56 <hongbin> 1. The etcd is not shared
16:35:14 <hongbin> 2. Waste of resources (extra master node, floating IP, cnder volume, ...)
16:35:53 <hongbin> 3. Extra manual work to connect bays
16:36:27 <adrian_otto> so what this is really about is allowing multiple resource groups, each with a different flavor_id.
16:36:48 <adrian_otto> and uniquely tagging the members of each resource group
16:36:56 <adrian_otto> if that were the proposal, I'd be okay with that.
16:37:18 <hongbin> OK
16:37:29 <tcammann> We want to enable "life cycle management" of these nova instances also
16:38:27 <kebray> I'm coming around to the concept, but still concerned Magnum will re-invent code that would be better served in Heat.. e.g., maybe heterogenous grouping w/tagging support belongs in Heat?
16:38:53 <adrian_otto> the grouping certainly is already supported by Heat and nested templates.
16:39:03 <tango__> Worth a discussion with the Heat team
16:39:16 <Drago> I have a concern about Magnum doing more advanced management of clusters: There is a clustering service in OpenStack already - Senlin.
16:39:20 <adrian_otto> the tagging would be a function of the COE. We could make a way for a tag to be inherited from the resource group somehow.
16:40:19 <tcammann> I'm not sure it adds that much complexity. We still want to use heat to manage these clusters, I don't see how Senlin fits this picture at all.
16:40:41 <hongbin> For this requirement, Heat needs to support tagging nodes staticaly and update the tagging dynamically
16:41:05 <tango__> Should we describe the requirement and get feedback from Heat team?
16:41:19 <strigazi> +1 to tango, we should discuss with Heat team
16:41:21 <Drago> A Senlin cluster could still be a resource in a template
16:41:32 <hongbin> tango__: I think someone Heat team already response, (cannot find the link right now)
16:41:40 <adrian_otto> tcammann: Imagine we get to a point where we want Magnum to autoscale those bays. What policy should it use to decide which resource groups to scale, and under what conditions. That's where a scaling policy from Senlin may apply.
16:42:00 <tango__> +1
16:42:03 <tcammann> We agreed we weren't solving autoscaling
16:42:19 <adrian_otto> tcammann: not yet.
16:42:31 <Drago> And there has been talk about Senlin backing ResourceGroups in the future transparently
16:42:55 <hongbin> I don't support autoscaling also. It doesn't seem to fit into Magnum
16:43:10 <adrian_otto> the concept of a bay resize gets much more complicated once you have a bunch or different resource groups
16:43:33 <hongbin> We just need to have an API to list all resource groups
16:43:36 <adrian_otto> either you treat them as related entities according to a policy, or you manage each group like an individual bay.
16:44:25 <hongbin> In the proposal, I proposed to add an API to manage individual resource groups
16:44:40 <hongbin> If this is implemented, users can scale individual groups
16:44:56 <adrian_otto> let's say that a COE wants to ann resources to a bay so it can scale out. How can it indicate which resource group should be updated?
16:45:02 <adrian_otto> s/ann/add/
16:45:15 <hongbin> If there is one rsource group, scale that group
16:45:23 <tcammann> We shouldn't be mixing the discussion of heterogeneous bays with a feature (autoscaling) currently don't have an ask for and we have previously decided not to implement.
16:45:27 <hongbin> If there is more than one resource group, return an error
16:45:29 <adrian_otto> right, and if there are more than one, the choice is ambiguous
16:46:05 <hongbin> Yes, like we can have two bays with same name
16:46:13 <hongbin> THe choice is also ambigous
16:46:20 <adrian_otto> tcammann: ideally we'd like to have the COE signal when to grow a bay, but this idea makes that impractical.
16:46:22 <hongbin> But we support that, and I think it is goode
16:47:06 <tcammann> adrian_otto: you can substitute COE for human in that sentence
16:47:28 <tcammann> And I think that is a problem we can solve
16:47:53 <adrian_otto> I think that needs a clear solution as part of the blueprint
16:47:59 <tcammann> We can have a master group (for the master nodes), a main group for the minion nodes and supplementary groups
16:48:28 <hongbin> We can have one resource group by default
16:48:34 <tcammann> Yes, we certainly can't implement this without a strong blueprint. We state this in the summit
16:48:38 <tcammann> *stated
16:48:41 <hongbin> With an option to specify multiple resource groups
16:48:55 <hongbin> Yes, this BP requires a spec
16:49:23 <hongbin> In here, we need to decide if the direction is correct or not
16:49:30 <tango__> We should enumerate the different scenarios and describe the desired behavior
16:49:42 <tango__> A spec would be helpful
16:49:57 <hongbin> Everyone agree to ask for a spec?
16:50:00 <tcammann> hongbin: yes need agreement on direction then a volunteer to spec it
16:50:29 <hongbin> Or anyone want to challenge the direction?
16:50:49 <adrian_otto> so far, I'm not satisfied with it
16:51:00 <adrian_otto> but additional details could change my view.
16:51:09 <tango__> Direction = support heterogenous bay ?
16:51:15 <hongbin> tango__: yes
16:51:19 <tcammann> do you think this can be resolved in a spec discussion/review adrian_otto/
16:51:21 <tcammann> *?
16:51:37 <tango__> design issues are to be discussed
16:51:39 <adrian_otto> tcammann: yes
16:52:09 <tango__> I would favor a spec
16:52:16 <hongbin> I have concern to have developers to work on a spec, then we reject the spec
16:52:35 <hongbin> IMHO, we should agree on a direction before asking for a spec
16:52:52 <hongbin> Maybe we could use the ML to clarify the design first
16:53:06 <hongbin> Then, revisit it in the next team meeting
16:53:19 <adrian_otto> I'm open to revising the bp further
16:53:33 <adrian_otto> and I'll do my best to participate in any related discussion
16:53:43 <hongbin> OK, then let's work on the BP for now?
16:54:02 <adrian_otto> using the ML for discussion, and getting a crisp BP ready
16:54:12 <adrian_otto> then we can secure agreement, and begin spec writing
16:54:21 <hongbin> wfm
16:54:33 <adrian_otto> -or- someone can just begin workign the spec with the expectation that it may not be accepted
16:54:39 <tcammann> ML is going to attract noise...
16:55:03 <adrian_otto> I'd actually prefer jumping to a spec draft and using gerrit to work out the concerns
16:55:05 <tcammann> having a spec in review does not mean it will ever be accepted :)
16:55:11 <adrian_otto> tcammann +1
16:55:21 <hongbin> OK, then let's ask for a spec
16:55:43 <tcammann> I'll happily -2 until we get consensus :P
16:55:54 <hongbin> #agreed Ask for a spec for the idea of supporting heteregenous bay
16:56:06 <hongbin> #topic Open Discussion
16:56:12 <adrian_otto> and I'd like to to further encourage us to source input from the Heat team to confirm we are not duplicating efforts
16:56:35 <tcammann> Any plans for a midcycle? hongbin
16:56:55 <hongbin> tcammann: so far, no from me
16:57:08 <hongbin> Anyone interest to provide a host?
16:57:22 <adrian_otto> would you like to come back to Texas?
16:57:45 <tango__> Texas is hot in the summer
16:57:50 <adrian_otto> true.
16:57:52 <hongbin> :)
16:57:59 <tcammann> Can we put an ask out on the ML for a host?
16:58:19 <juggler_> fyi, Fedora 24 is about to drop 6/14/16: https://fedoraproject.org/wiki/Releases/24/Schedule
16:58:20 <hongbin> #action hongbin send a ML to ask for a host for Magnum midcycle
16:58:24 <tango__> How about a timeframe?
16:58:29 <tango__> July?
16:58:55 <hongbin> Yes, possibly late June or July. Need to have Doodle to collect the time
16:59:16 <tcammann> doodle!
16:59:43 <hongbin> #action hongbin create a doodle pool for collecting midcycle time
16:59:55 <hongbin> Last minutes
17:00:16 <strigazi> start ML dicsussion about host?
17:00:18 <hongbin> Time is up
17:00:22 <hongbin> strigazi: yes
17:00:25 <hongbin> #endmeeting