16:00:04 <hongbin> #startmeeting containers
16:00:06 <openstack> Meeting started Tue May 31 16: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.
16:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:10 <openstack> The meeting name has been set to 'containers'
16:00:11 <hongbin> #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2016-05-31_1600_UTC Today's agenda
16:00:16 <hongbin> #topic Roll Call
16:00:17 <strigazi> Spyros Trigazis
16:00:19 <muralia> Murali Allada
16:00:22 <jvgrant> Jaycen Grant
16:00:25 <dane_leblanc> o/
16:00:30 <mkrai> Madhuri Kumari
16:00:32 <tango__> Ton Ngo
16:00:32 <rpothier> Rob Pothier
16:00:42 <juggler> o/
16:00:43 <adrian_otto> Adrian Otto
16:00:56 <Drago> o/
16:01:36 <hongbin> Thanks for joining the meeting strigazi muralia jvgrant dane_leblanc mkrai tango__ rpothier juggler adrian_otto Drago
16:01:46 <hongbin> #topic Announcements
16:02:11 <hongbin> Any annoucement from our team member?
16:02:24 <strigazi> minor one
16:02:33 <hongbin> strigazi: go ahead
16:02:52 <strigazi> There is some progress on adding magnum to rally. Soon will have gate tests on rally
16:02:54 <strigazi> an
16:02:57 <strigazi> and
16:03:03 <strigazi> we'll add to CERN's infra
16:03:14 <tango__> +1
16:03:28 <hongbin> awesome
16:03:34 <strigazi> that's all
16:03:38 <hongbin> Thanks strigazi
16:03:57 <hongbin> #topic Review Action Items
16:04:01 <hongbin> None
16:04:07 <hongbin> #topic Essential Blueprints Review
16:04:12 <hongbin> 1. Support baremetal container clusters (strigazi)
16:04:17 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/magnum-baremetal-full-support
16:04:23 <strigazi> Yuanying is working on fixing the head templates
16:04:35 <strigazi> and I
16:05:00 <strigazi> I'm investigating 1.1 Upgrade the Ironic image building elements to fedora 23
16:05:13 <strigazi> not much on that for now
16:05:21 <hongbin> #link https://review.openstack.org/#/c/320968/
16:05:25 <strigazi> I'll find someone this week
16:05:44 <strigazi> that's all
16:05:47 <hongbin> strigazi: find someone for?
16:05:54 <strigazi> for 1.1
16:06:00 <hongbin> Oh, I see
16:06:14 <hongbin> Any question for strigazi ?
16:07:01 <hongbin> strigazi: Thanks. Let me know if anything you need help for this BP
16:07:10 <hongbin> 2. Magnum User Guide for Cloud Operator (tango)
16:07:10 <strigazi> hongbin: ack
16:07:16 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/user-guide
16:07:34 <tango__> Not much update for last week since I was working on Rally plugins
16:07:44 <tango__> I am working on the Kubernetes section
16:08:20 <tango__> I should have the patch uploaded shortly
16:09:11 <tango__> that's all for now
16:09:17 <hongbin> tango__: Thanks Ton
16:09:29 <hongbin> any comment for this BP?
16:09:46 <hongbin> 3. COE Bay Drivers (jamie_h)
16:09:52 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/bay-drivers
16:10:03 <muralia> looks like we've addressed all comments. The spec has 2 +2's. Someone needs to merge it if there is nothing else to be addressed
16:10:33 <hongbin> #link https://review.openstack.org/#/c/296384/
16:10:56 <hongbin> Yes, it looks ready to go
16:10:59 <muralia> I have started implementation work. I'll update the WIP with the new changes and we'll take it from there.
16:11:32 <muralia> Thats it for now
16:11:48 <tango__> I just did the honor :)  Thanks Murali and Jamie
16:11:49 <hongbin> Thanks muralia for addressing outstanding comments
16:12:16 <hongbin> Any comment for the bay driver BP?
16:12:17 <muralia> awesome. thanks tango
16:12:44 <hongbin> 4. Create a magnum installation guide (strigazi)
16:12:49 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/magnum-installation-guide
16:12:57 <strigazi> Please review:
16:13:01 <strigazi> #link https://review.openstack.org/#/c/319399/
16:13:31 <hongbin> I tested the Ubuntu part. Will find a time to test the CentOS part
16:13:45 <strigazi> I'll add links to other install guides
16:14:14 <strigazi> for neutron/lbaas, I didn't find any good content
16:14:32 <hongbin> ..........
16:14:34 <strigazi> This is road blocker  IMO
16:14:47 <tango__> Yes, I need LBaaS
16:14:47 <strigazi> #link https://wiki.openstack.org/wiki/Neutron/LBaaS/HowToRun
16:15:19 <hongbin> strigazi: I will help you to talk to the lbaas team
16:15:45 <strigazi> But, to test our content you can do it against devstack
16:15:47 <hongbin> #action hongbin send a ML to lbaas team to ask for installation instruction
16:15:51 <tango__> particularly for v1, since we don't have support for v2 yet
16:16:51 <strigazi> I don't have something else
16:16:52 <hongbin> strigazi: FYI, we plan to decouple from lbaas
16:16:59 <strigazi> I know
16:17:13 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/decouple-lbaas
16:17:20 <hongbin> ok
16:17:44 <hongbin> Any other comment for the installation guide?
16:18:08 <hongbin> #topic Magnum UI Subteam Update (bradjones)
16:18:21 <hongbin> bradjones: status?
16:18:52 <hongbin> Brad mentioned that he will join this meeting, but didn't show up in roll call
16:19:09 <hongbin> I have a note from him
16:19:22 <hongbin> (Brad) Two new BPs that Shu has proposed
16:19:30 <hongbin> (Brad) https://blueprints.launchpad.net/magnum-ui/+spec/generic-detail-framework
16:19:38 <hongbin> (Brad) https://blueprints.launchpad.net/magnum-ui/+spec/navigation-improvements
16:19:45 <hongbin> (Brad) Both of which will keep us in line with changes upstream in horizon.
16:19:49 <hongbin> That is all
16:20:01 <hongbin> Any comment?
16:20:32 <hongbin> #topic Kuryr Integration Update (tango)
16:20:49 <hongbin> tango__: any update from the Kuryr team?
16:20:56 <tango__> I talked to Mohammed to synch up on Kuryr
16:21:38 <tango__> I am working with another colleague to build a working environment with Kuryr
16:22:03 <tango__> from there we will develop Magnum support through network-driver
16:22:55 <tango__> I plan to join the Kuryr meeting to follow the discussion
16:23:38 <hongbin> A question
16:23:53 <hongbin> Is anyone in Kuryr team working on this integration?
16:24:21 <hongbin> tango__: ^^
16:24:26 <tango__> I think only in the sense of providing details to us
16:24:38 <tango__> and helping to debug if necessary
16:24:47 <hongbin> OK
16:24:53 <tango__> If we find gap, they will fill
16:25:10 <hongbin> What is the working items?
16:25:36 <hongbin> For example, what is the sub-tasks that need to be done? all in Magnum side?
16:25:37 <tango__> They are also keen on adding support for storage, so they are relying on us to drive, at least in the beginning
16:25:53 <tango__> For us:
16:26:21 <tango__> 1. Build a working environment with Swarm and Kuryr as driver
16:26:43 <tango__> 2. Add template and scripts to automate
16:27:16 <tango__> 3.  Solve the Neutron credential issue
16:27:27 <tango__> 4. Functional tests
16:27:40 <tango__> 5. Update docs
16:27:41 <hongbin> Get it
16:28:17 <hongbin> From Kuryr, is anything that is ready?
16:28:33 <tango__> It should be all ready for Swarm
16:28:41 <hongbin> OK
16:29:00 <hongbin> tango__: anything you need help from the team?
16:29:02 <tango__> We just need to validate it independently
16:29:30 <hongbin> But strange, I just saw they uploaded the spec
16:29:42 <hongbin> They doesn't seem to have implementation yet
16:29:47 <tango__> If this is interesting to anyone, please jump in
16:30:48 <hongbin> OK. Thanks tango__
16:31:14 <hongbin> #topic Other blueprints/Bugs/Reviews/Ideas
16:31:21 <hongbin> 1. Manually manage bay nodes
16:31:29 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/manually-manage-bay-nodes the BP
16:32:00 <hongbin> I would pause a few minutes for everyone to review the BP
16:32:08 <hongbin> If everything is fine, I will approve it
16:32:36 <hongbin> The idea has been discussed in the design summit and ML
16:32:55 <hongbin> It looks we agree to explore this direction
16:33:47 <hongbin> So, I drafted a BP for that
16:33:55 <hongbin> Any concern for this?
16:33:58 <adrian_otto> uuh
16:34:07 <adrian_otto> what's driving this?
16:34:17 <hongbin> ??
16:34:21 <adrian_otto> mulit-AZ, or something more?
16:34:30 <hongbin> yes, and multiple favors
16:34:52 <tango__> How about mixing VM and baremetal?
16:35:05 <hongbin> tango__: ......... it is hard
16:35:31 <hongbin> tango__: However, it is possible in theory
16:35:32 <adrian_otto> I think we should be really careful here not to become an orchestration system
16:36:01 <hongbin> adrian_otto: could you elaborate?
16:36:18 <adrian_otto> if resource groups are not the right instrument to get a multi-AZ deployment, then we should be focusing on what features are missing from the orchestration system, and asking how we can get them.
16:36:39 <rochaporto> +1
16:37:06 <adrian_otto> this blueprint strikes me as a workaround for a missing Heat feature
16:37:21 <adrian_otto> maybe I'm missing something, but that's what it looks like
16:39:11 <hongbin> not sure if it is a good idea to push it to Heat
16:39:15 <adrian_otto> if there are things that are Magnum specific, then we should implement that in custom template logic and not look back
16:39:45 <hongbin> It is about deployment vs runtime
16:39:45 <tango__> There was some discussion on multi-AZ support in Heat
16:39:49 <kebray> hongbin, I think you can likely do what you want from that blueprint in Heat today.  Have you talked to the Heat folks or considered nested stacks which might allow for nested resources groups?
16:40:00 <adrian_otto> but if we are talking about something fundamental that easily applies to any resource in a cloud, then I'd like to understand why the feature is not in Heat
16:41:04 <hongbin> My poinion, Heat template is good for statically deployment, but hard to express runtime management logic
16:41:06 <rochaporto> the AZ blueprint has a link on how to do it using heat today
16:41:43 <hongbin> By decoupleing from resourcegroup, we have flexibility at runtime
16:41:59 <hongbin> For example, kill a node, swap a node, add a node
16:42:15 <adrian_otto> Resource groups already allow you to selectively kill a node by id
16:42:29 <adrian_otto> so you can use that to implement swap
16:42:48 <hongbin> OK, that is true
16:42:49 <adrian_otto> and you can add a node by increasing the parameter for the group indicating its size
16:43:26 <hongbin> Yes, but it is hard to express the hetergenerity of nodes
16:43:36 <adrian_otto> heterogeneous groups are an idea that really worries me.
16:43:47 <hongbin> why?
16:43:55 <kebray> pets bad, cattle good.
16:44:04 <adrian_otto> because it lends to uneven staling and bad HA behaviour
16:44:08 <adrian_otto> exactly.
16:44:18 <adrian_otto> s/staling/scaling/
16:44:47 <hongbin> Well, I won't argue it is good or not, but we have reported use cases for that
16:44:51 <adrian_otto> if a node in our cluster needs to have a name, then we have a design problem.
16:45:17 <rochaporto> adrian_otto: you could want a single cluster with a couple ssd nodes while the larger set is non ssd
16:45:23 <adrian_otto> if we think in terms of individual nodes, that's problematic.
16:45:29 <rochaporto> this could be a use case... but i think we can express this today in heat
16:45:50 <adrian_otto> rochaporto: you can do that my creating multiple bays. Keep it simple.
16:47:08 <rochaporto> that's one way... but i would split my cluster description between my db (on ssds) and the rest
16:47:09 <hongbin> OK. maybe push the discussion to ML
16:48:11 <hongbin> I knew Sahara is manually manage individual Heat temaplates, instead of nesting them all in a single big templates
16:48:26 <hongbin> A single big template is problematic in update
16:48:45 <rochaporto> hongbin: one stack per node sounds very very odd
16:49:00 <rochaporto> pretty sure we can do all with heat as it is today
16:49:05 <adrian_otto> yeah, it seems really awkward
16:49:19 <adrian_otto> I can see a template per group, but per node seems really strange.
16:49:42 <hongbin> Template is per group
16:49:56 <hongbin> For example, master -> a master template
16:50:01 <hongbin> minion -> a minion template
16:50:10 <adrian_otto> the BP says "manually create Heat stack for each bay nodes"
16:50:28 <adrian_otto> if you meant per group, then the above text is really tripping me.
16:50:29 <hongbin> Oh, I can clarify it furhter
16:51:08 <hongbin> Currently, we use a global template to manage the master/minion templates
16:51:15 <rochaporto> it says 2 masters + 3 minions == 6 stacks
16:51:26 <hongbin> The proposed idea is just split it
16:51:47 <hongbin> rochaporto: Yes
16:52:09 <hongbin> So, the idea is to let ResourceGroup to manage it, or manually manage it
16:52:49 <hongbin> #topic Open Discussion
16:53:11 <hongbin> Again, we can push the discussion back to ML
16:54:24 <hongbin> I think it is a good practice to keep the depth of template as low as possible
16:54:45 <hongbin> Otherwise, it is very hard to update a stack
16:55:05 <hongbin> If we change a parameter, it might cause replacements of multiple Heat resources
16:55:38 <hongbin> my 2 cents
16:57:06 <hongbin> If nothing else to discuss, let's wrap up earlier
16:57:22 <kebray> hongbin, isn't a major selling point of containers is that when you need to change something you just redeploy to get to new state?  why is so imporant to modify infrastructure and treat it as a forever lived resource and have diversified infra in a bay?
16:57:40 <kebray> anyway, happy to take to ML
16:58:34 <hongbin> kebray: yes, I will reply in the ML
16:59:03 <hongbin> All, thanks for joining the meeting
16:59:08 <hongbin> #endmeeting